Presentation On CODDs Rules

SUBMITTED TO:
Lec. Rajan Manroo SUBMITTED BY: Shallu Puri(76), Shilpa Mahajan(78) MCA 2nd(B).

21-03-2013

CODDs RULES
Dr. E.F. Codd (Edgar Frank Codd), the founder of the relational database systems framed 13 (0 to 12) rules in June 1970,in ACM (Association of Computer Machinery) to define how to determine whether a DBMS is relational and to what extent it is relational. An RDBMS product has to satisfy at least six of the 12 rules of Codd to be accepted as a full-fledged RDBMS.

21-03-2013

Rule 0: Foundation
A relational database management system must use only its relational capabilities to manage the information stored in the database.

21-03-2013

Rule 1: Information
All information in the database should be represented in one and only one way -Namely by values in column positions within rows of tables. Everything within the database exists in tables and is accessed via table access routines.

21-03-2013

Rule 2: Guaranteed Access

This rule is essentially a restatement of the fundamental requirement for primary keys. Every individual scalar value in the database must be logically addressable by specifying the name of the containing table, the name of the containing column and the primary key value of the containing row.

21-03-2013

Rule 3: Comprehensive Data Sub-Language (Contd..)

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, having well-defined syntax and ability to support all of the following is comprehensible:
21-03-2013

 data definition

View definition
data manipulation (interactive and by program) integrity constraints Authorization transaction boundaries (begin, commit and rollback).

21-03-2013

Rule 4: View Updating

A View can represent a subset of the data contained in a table. Views can limit the degree of exposure of a table. All views that are theoretically updatable are also updatable by the system . Not only can the user modify data, but so can the RDBMS when the user is not logged-in.

21-03-2013

Rule 5: High Level Insert, Update & Delete

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. This means that data can be retrieved from a relational database in sets constructed of data from multiple rows and/or multiple tables. The user should be able to modify several tables by modifying the view to which they act as base tables.
21-03-2013

Rule 6: Physical Data Independence

The ability to change the physical schema without changing the logical schema is called physical data independence.
For example a change to the internal schema such as using different file organization or storage structure, storage devices or indexing strategy should be possible without having to change the conceptual/external schema.

21-03-2013

Rule 7: Logical Data Independence

The ability to change the logical schema without changing the external schema or application programs is called as Logical Data Independence. For example: the addition or removal of new entities, attributes or relationship to the conceptual schema should be possible without having to change the existing external schemas or having to rewrite existing application programs.
21-03-2013

Rule 8: Integrity Independence

The database language must be capable of defining integrity rules. They must be stored in the online catalog , not in the application programs. There are two integrity constraints that must be supported: Entity integrity: It states that no primary key value can be null. Referential integrity: The referential integrity constraint is specified between two relations and is used to maintain the consistency among tuples in the two relations.
21-03-2013

Rule 9: Distribution Independence

The RDBMS may spread across more than one system and across several networks, however to the end-user the tables should appear no different to those that are local. It enable application programs and terminal activities to remain logically unimpaired whether and whenever data are physically centralized or distributed.
21-03-2013

Rule 10: Non Subversion

If a relational system has a low-level (single-record-at-a-time) language, that low level cannot be used to subvert or bypass the integrity Rules and constraints expressed in the higher level relational language (multiple-records-ata-time) i.e. in SQL server whatever integrity rules are applied on every record are also applicable when you process a group of records using application program in any other language (e.g. C#, VB.net etc.)

21-03-2013

Rule 11: Systematic Treatement Of Null Values

If data does not exist or does not apply then a value of NULL is applied, this is understood by the RDBMS as meaning non-applicable data. The DBMS must have a consistent method of representing null values.For example, for numeric data it must be distinct from zero or any other numeric value & for character data it must be different from a string of blanks.

21-03-2013

Rule 12:Data Description

The data base description is represented at the logical level in the same way as-ordinary data, so that authorized users can apply the same relational language to its interrogation as they apply to the regular data .Create, Drop, Alter are the statements that comes in data description/definition language to modify the schema of the database by adding, changing, or deleting definitions of tables .

21-03-2013

21-03-2013