A Relational Database Management
System (RDBMS) is a database management system (DBMS) that is based on the
relational model as introduced by Dr. Edgar F. Codd. Strictly speaking it
should also satisfy Codd’s 12 rules, but in practice there is no DBMS that
satisfies all these rules. In fact, most successful DBMS that are
considered to be relational violate the relational model in several important
ways, including the Structured Query Language (SQL).
Relational DataBase
Management Systems (RDBMS) stores data in the form of related
tables. RDBMS are powerful because they require few assumptions about how data
is related or how it will be extracted from the database. As a result, the same
database can be viewed in many different ways.
An important feature of
relational systems is that a single database can be spread across several
tables.
The first released RDBMS
that was a relatively faithful implementation of the relational model was the Multics
Relational Data store first sold in 1978. Others have been Berkeley Ingres,
QUEL and IBM BS12.
Today, popular commercial
RDMBS for large database include Oracle, Microsoft SQL Server, Sybase SQL
server and IBM’s DB2. The most commonly used free RDBMS are MySQL, PostgreSQL.
Dr. E.F. Codd is an IBM
researcher who first developed the relational data model in 1970. In 1985, Dr.
Codd published a list of 12 rules that define an ideal relational database and
has provided a guideline for the design of all relational database systems.
Dr. Codd has used the term guideline
because till date no commercial relational database system fully conforms to
all 12 rules. Today, the rules are not talked about as much but remain a goal
for relational database design.
Rule 1: The Information
Rule: All data should be presented in table form.
Rule 2:
Guaranteed Access Rule: All data should be accessible without
ambiguity. This can be accomplished through a combination of the table name,
primary key and column name.
Rule 3: Systematic Treatment of Null Values: A
field should be allowed to remain empty. This involves the support of a null
value, which is distinct from an empty string or a number with a value of zero.
Of course, this can't apply to primary keys. In addition, most database
implementations support, the concept of a not null field constraint that
prevents null values in a specific table, column.
Rule 4: Dynamic On Line Catalog based on the Relational
Model: A relational database must provide access to its structure through the
same tools that are used to access the data. This is usually accomplished by
storing the structure definition within special system tables.
Rule 5: Comprehensive Data Sublanguage Rule:
The database must support at least one clearly defined language that includes
functionality for data definition, data manipulation, data integrity and
database transaction control. All commercial relational databases use forms of standard SQL (i.e. Structured Query
Language) as their supported comprehensive language.
Rule 6: View Updating Rule: Data can be
presented in different logical combinations called views. Each view should
support the same full range of data manipulation that has direct access to a
table available. In practice, providing update and delete access to logical
views is difficult and is not fully supported by any current database.
Rule
7: High level Insert, Update, and Delete: Data can be retrieved from
a relational database in sets constructed of data from multiple rows and/or
multiple tables. This rule states that insert, update, and delete operations
should be supported for any retrievable set rather than just for a single row
in a single table
Rule
8: Physical Data Independence: The user is
isolated from the physical method of storing and retrieving information from
the database. Changes can be I made to the underlying architecture (hardware,
disk storage methods) without affecting how the user accesses it
Rule 9: Logical Data Independence: How data is viewed should
not be changed when the logical ,structure (table's structure) of the database
changes. This rule is particularly difficult to satisfy. Most databases rely on
strong ties between the data viewed and the actual structure of the underlying
tables
Rule 10: Integrity Independence: The database language (like
SQL) should support constraints on user input that maintain database integrity.
This rule is not fully implemented by most major vendors. At a minimum, all
databases do preserve two constraints through SQL. No component of a primary
key can have a null value. If a foreign key is defined in one table, any value
in it must exist as a primary key in another table.
Rule 11: Distribution Independence: A user should be totally
unaware of whether or not the database is distributed (whether parts of the
database exist in multiple locations). A variety of reasons 'make this rule
difficult to implement.
Rule 12: Non subversion Rule: There should be no
way to modify the database structure other than through the multiple row
database language (like SQL). Most databases today support administrative tools
that allow some direct manipulation of the data structure.
No comments:
Post a Comment