Skip to main content

Codd's Rule- Fully relatoinal DBMS

The founder of the relational data base theory Dr. E F Codd has outlined twelve rules (modified to 333 rules) to test whether a product that is claimed to be fully relational really is an RDBMS. The twelve rules are based on a single foundation principle which is called as rule zero.
RULE ZERO : For any system that is claimed to be RDBMS, that system must be able to manage databases entirely through its relational capabilities.
RULE ONE Information representation
All information in RDB is represented explicitly as values in tables.
[ The metadata i.e., table name, column name etc. should also be stored in tables]
RULE TWO Guaranteed access
Each and every data item (atomic values) in a relational data base is guaranteed to be logically accessible by giving the table name, primary key value and column name.
[This rule specifies the need for a primary key to access the data in the data base]
RULE THREE Systematic treatment of null values
Null values are supported for representing missing information and inapplicable information in a systematic way, independent of data type.
[The systematic, uniform representation means that only one technique can be used for dealing with null values]
RULE FOUR Dynamic online catalogue (Data dictionary) based on relational data model 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.
[Only one data model is used for data and metadata, and only one manipulation sublanguage is used for querying]

RULE FIVE Comprehensive Data Sublanguage
A relational system may support several languages and various models for terminal use. But these must be at least one language whose statements can express all of the following items:
1. Data Definitions, 2. View definitions, 3. Data Manipulation [interactive and by Program], 4. Integrity Constraints, 5. Authorization, 6. Transaction Boundaries [Begin, Commit and Roll back]
RULE SIX View updating
All views that are theoretically updateable are also updateable by system.
RULE SEVEN High level insert, update and delete
The capability of handling a base relation and a derived relation or view on a single operand applies not only to the retrieval of data but also to the insertion, updating and deletion of data.
[This means that all the operators are set operators, not records or tuple operators i.e., a set of rows can be deleted in one statement (in one command) or a set of rows can all be modified or inserted]
RULE EIGHT Physical Data Independence
Application programs and terminal activities remain logically unaffected whenever any changes are made in either storage representation and access methods.
RULE NINE Logical Data Independence
Application programs and terminal activities remain logically unimpaired when information preserving changes of any kind that theoretically permit unimpairement, are made to the base tables.
RULE TEN Integrity Independence
Integrity constraints specific to a particular data base must be definable in the relational sub language and storable in catalogue, not in the application program.
RULE ELEVEN Distribution Independence
The data manipulation sub language of a relational DBMS must enable application programs and queries to remain logically the same whether and whenever the data are physically centralized or distributed. [In a distributed data base data are physically dispersed (distributed) across several remote computer sites and data processing requests at any one of these sites may require data stored at several of the sites. Each program treats the data base as it were all local. So Distribution and redistribution do not change the logic of the program]
RULE TWELVE Non Subversion
If a relational system has a low level (single record at a time) language, that low level language cannot be used subvert or bypass the integrity rules and constraints expressed in the higher level relational language. (Multiple records at a time).
[This means that all DML supported by the DBMS must rely only on the stored data base definition, including integrity rules and security constraints for processing of data.]


Popular posts from this blog

KTU-FOSS LAB Solutions

Write shell scripts to show the following  ( you can write menu driven programs)
 Currently logged user and his logname ( logname)  Your current shell ( echo $SHELL)  Your home directory ( echo $HOME)  Your operating system type (echo $OSTYPE)  Your current path setting ( echo $PATH)  Your current working directory ( echo $PWD )  Show Currently logged  users ( w or who -H)      Show only the user name of logged users in the host ( users)      Details of last login ( last cek....where cek is the user id )  About your OS and version, release number, kernel version ( uname -a or  cat  /proc/version)  Show all available shells ( cat /etc/shells )  Show mouse settings (cat  /sys/class/input/mouse*/device/name )  Show computer CPU information       CPU details      ( cat /proc/cpuinfo | more )       Show information on  CPU architecture ( lscpu)       Number of Processor core ( nproc)  Show memory information       Memory details ( cat /proc/meminfo | more )       Display file system disk usage ( d…

Important Directories and Files

Important Directories
/bin                            holds the “essential” Linux commands and utilities /boot                          holds files required for boot process (kernel, vmlinuz, grub) /dev                            holds device files (hard drive, USB, CD-ROM, etc.) /etc                             holds system configuration files /etc/init.d                    holds scripts to start/stop network services /etc/rc.d                     holds system startup/shutdown scripts /etc/X11                      holds configuration files for X-windows /home                        holds user home directories (except for the root account) /lib                               holds system/shared library files /lost+found                holds files restored after system crash /mnt                            used as temporary mount point for CD-ROM, floppy, etc. /opt                              typically where large software applications are installed /proc                           holds kerne…

ER Diagrams to Table

REDUCING E-R DIAGRAM TO TABLE - A database which conforms to an E R diagram can be represented by collection of tables .For each entity set and for each relationship set in the database, we will create unique tables, which is assigned the name of the corresponding entity set or relationship sets . Each table has a no. of columns which have unique names. Each row in the table corresponds to an entity or a relationship.

REPRESENTATION OF STRONG ENTITY SET -Let E be a strong entity set with descriptive attributes a1, a2....aN . We represent this entity by table called E with N distinct columns, each of which corresponds to one of the attributes of E.

REPRESENTATION OF RELATIONSHIP SET - Let R be a relation ship set involving entity set E1,E2....En Let attribute(R) consists of 'm' attributes We can represent this relation ship set by a table called R with m distinct columns, each of which corresponds to one of the attributes in attribute (R) plus the primary key of E1..En.