Relational Database Management System:
Dr.E. F. Codd(IBM Scientist), released article with twelve rules that a database must satisfy, if it is to be considered truly relational ,in Computerworld Magazine at 1985.C J Date is credited with releasing Codd’s work after his death.Before the arrival of RDBMS Rules,Vendors had secured market in Hierarchical, Network and Hybrid Databases.Because of Normalization,Vendors&developers showed more interest on the implementation of RDBMS. Based on these given twelve rules Oracle Corporation implemented Relational Database Management Server with the help of C language at very first.Later Sybase,IBM,Microsoft and other vendors developed relational Database Management Systems.Let's move on to the Rules with summarized information.
Rule 0:
Rule 0 forces the database to be relational and expects to satisfy the all below given rules.
Rule 1:Information rule.
Rule 1:Information rule.
The information rule simply requires all information in the database to be represented in one and only one way, Namely by values in column positions within rows of tables.
Rule 2:Guaranteed access rule
All data should be accessible without ambiguity.This means each data item can be uniquely identified using the table name, primary key, and column name.
Rule 3:Systematic treatment of null values
Null values (distinct from empty character string or a string of blank characters and distinct from zero or any other number) are supported in the fully relational DBMS for representing missing information in a systematic way, independent of data type.
Rule 4:Dynamic online catalog based on the relational model
The DBMS must provide access to its structure through the same tools that are used to access the data. This is accomplished by storing the structure definition within tables, the same as data is stored.
Rule 5:Comprehensive data sub-language rule
A relational system may support several languages and various modes of terminal use. However, there must be at least one language whose statements are expressible, per some well-defined syntax, as character strings and whose ability to support all of the following is comprehensible:
- data definition
- view definition
- data manipulation (interactive and by program)
- integrity constraints
- authorization
- transaction boundaries (begin, commit, and rollback).
Relational databases use forms of standard SQL as their supported comprehensive language.
Rule 6:View updating rule
Data can be presented to the user in different logical combinations called views. Each view should support the same full range of data manipulation that direct-access to a table has available. (This is only partially fulfilled in current implementations since update and delete access through logical views conflicts with the common use of logical views to provide read-only access for query and reporting. There is no universally agreement that it is a good idea in any case.)
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
Applications must still work using the same syntax, even when changes are made to the way in which the database internally implements data storage and access methods. This rule implies that the way the data is stored physically must be independent of the logical manner in which it’s accessed. This is saying that users shouldn't be concerned about how the data is stored or how it’s accessed. In fact, users of the data need only be able to get the basic definition of the data they need. Other things that shouldn't affect the user’s view of the data are as follows:
• Adding indexes: Indexes determine how the data is stored, yet the user, through SQL, will never know that indexes are being used.
• Changing the file-group of an object: Just moving a table to a new file-group will not affect the application. You access the data in the same way no matter where it is physically located.
• Using partitioning: Beyond moving entire tables around to different file-groups, you can move parts of a table around by using partitioning technologies to spread access around to different independent subsystems to enhance performance.
• Modifying the storage engine: From time to time, Microsoft has to modify how SQL Server operates (especially in major version upgrades). However, SQL statements must appear to access the data in the same manner as they did in any previous version, only (we hope) faster.
Microsoft has put a lot of work into this area, because SQL Server has a separate relational engine and storage engine, and OLE DB is used to pass data between the two. Further reading on this topic is available in SQL Server 2008 Books Online in the “Database Engine Components” topic
or in Inside Microsoft SQL Server 2005: The Storage Engine by Kalen Delaney (Microsoft Press, 2006).
• Adding indexes: Indexes determine how the data is stored, yet the user, through SQL, will never know that indexes are being used.
• Changing the file-group of an object: Just moving a table to a new file-group will not affect the application. You access the data in the same way no matter where it is physically located.
• Using partitioning: Beyond moving entire tables around to different file-groups, you can move parts of a table around by using partitioning technologies to spread access around to different independent subsystems to enhance performance.
• Modifying the storage engine: From time to time, Microsoft has to modify how SQL Server operates (especially in major version upgrades). However, SQL statements must appear to access the data in the same manner as they did in any previous version, only (we hope) faster.
Microsoft has put a lot of work into this area, because SQL Server has a separate relational engine and storage engine, and OLE DB is used to pass data between the two. Further reading on this topic is available in SQL Server 2008 Books Online in the “Database Engine Components” topic
or in Inside Microsoft SQL Server 2005: The Storage Engine by Kalen Delaney (Microsoft Press, 2006).
Rule 9:Logical data independence
This rule insulates the user or application program from the low-level implementation of the database. Together, they specify that specific access or storage techniques used by the RDBMS—and even changes to the structure of the tables in the database—shouldn't affect the user’s ability to work with the data. In this way, if you add a column to a table and if tables are split in a manner that doesn't add or subtract columns, then the application programs that call the database should be unimpaired.
For example, say you have the table in Figure A-1.
For example, say you have the table in Figure A-1.
The user should be unaffected. If you were to implement INSTEAD OF triggers on the view that had the same number of columns with the same names, you could seamlessly meet the need to manage the view in the exact manner the table was managed. Note that the handling of identity columns can be tricky in views, because they require data to be entered, even when the data won’t be used. See Chapter 6 for more details on creating INSTEAD OF triggers.
Of course, you cannot always make this rule work if columns or tables are removed from the system, but you can make the rule work if columns and data are simply added.
Rule 10:Integrity independence
Integrity constraints specific to a particular relational database must be definable in the relational data sub-language and storable in the catalog, not in the application programs. The database must support a minimum of the following two integrity constraints:
• Entity integrity: No component of a primary key is allowed to have a NULL value.
• Referential integrity: For each distinct non-NULL foreign key value in a relational database, there must exist a matching primary key value from the same domain. This rule says that the database language should support integrity constraints that restrict the data that can be entered into the database and the database modifications that can be made. In other words, the RDBMS must internally support the definition and enforcement of entity integrity (primary keys) and referential integrity (foreign keys).
• Entity integrity: No component of a primary key is allowed to have a NULL value.
• Referential integrity: For each distinct non-NULL foreign key value in a relational database, there must exist a matching primary key value from the same domain. This rule says that the database language should support integrity constraints that restrict the data that can be entered into the database and the database modifications that can be made. In other words, the RDBMS must internally support the definition and enforcement of entity integrity (primary keys) and referential integrity (foreign keys).
Rule 11:Distribution independence
This rule says that the database language must be able to manipulate data located on other computer systems. In essence, we should be able to split the data on the RDBMS out onto multiple physical systems without the user realizing it. SQL Server 2008 supports distributed transactions among SQL Server sources, as well as other types of sources using the Microsoft Distributed Transaction Coordinator service
Rule 12:Non subversion rule
For most SQL Server 2008 applications, this rule is followed, because there are no methods of getting to the raw data and changing values other than by the methods prescribed by the database. However, SQL Server 2008 violates this rule in two places:
• Bulk copy: By default, you can use the bulk copy routines to insert data into the table directlyand around the database server validations.
• Disabling constraints and triggers: There’s syntax to disable constraints and triggers, thereby subverting this rule.It’s always good practice to make sure you use these two features carefully. They leave gapingholes in the integrity of your data, because they allow any values to be inserted in any column.Because you’re expecting the data to be protected by the constraint you've applied, data valueerrors might occur in the programs that use the data, without re-validating it first
No comments:
Post a Comment