Relational data base models Codds Rules 1.

Information Rule: All data is represented in the form of relations / tables (with rows & columns) 2. Guaranteed Access Rule: The DBMS can refer to every single value in the database (by using a combination of the table name & the primary key) 3. Systematic Treatment of Null Values: The concept of missing / non-available values should be distinct from blank fields / fields with 0s in it 4. Active On-Line Catalog: based on the relational model i.e. the database schema / definitions can be represented in the form of tables (and retrieved as such) 5. Comprehensive Data Sub-Language Rule: The system must support at least one relational language (based on either Relational Algebra / Relational Calculus) and should allow the definition & manipulation of database objects using this 6. View Updating Rule: Any views that are theoretically updateable, should be allowed to be so 7. High Level Update: The user should be allowed to Delete / Update a set of tuples (rather than row by row) Physical Data Independence: Application programs and terminal activities remain logically unimpaired whenever any changes are made in either storage representation or access methods. 6. View Updating Rule: Any views that are theoretically updateable, should be allowed to be so 7. High Level Update: The user should be allowed to Delete / Update a set of tuples (rather than row by row) 8. Physical Data Independence: Application programs and terminal activities remain logically unimpaired whenever any changes are made in either storage representation or access methods. 9. Logical Data Independence: Application programs and terminal activities remain logically unimpaired when information preserving changes of any kind that theoretically permit unimpairment are made to the base tables. 10. Integrity Independence: The DBMS should allow the definition of constraints (rules / triggers / etc.) independent of application programs 11. Distribution Independence: If the database were to be taken and split into parts residing in different places, this should be invisible to the users 12. Non-Subversion Rule: Even if the system allowed access to the data through a low level language (e.g. access a tuple at a time through 'C') it should go through the DBMS and hence ensure that the constraints are not violated

2) Composite key:

It is always a collection of more than one attribute and if a primary key is formed with more than one attribute then it is called composite primary key. For example: Consider the following STUDENTCOURSE relation in which we have the following attributes {STUDID,COURSEID,INSTITUTENAME} In the above example one student may join in several courses in the same institute so we cannot differentiate with student id so it has to be a combination of student id with course id i.e., {STUDID,COURSEID} which is what we call it as composite key. 3) Foreign key: A foreign key some thing with the help of which we will be able to establish a relationship between two or more tables. It can be a collection of more than one attribute also i.e., a composite key. For every foreign key value there must be an associated primary key value Which is being referred by that particular foreign key. For example: Consider the following STUDENT and STUDENTCOURSE relation in which we have the following attributes STUDENT {STUDID, SNAME, SADDR, GENDER} STUDENTCOURSE {STUDID,COURSEID,INSTITUTENAME} In the above example STUDID attribute of STUDENTCOURSE table will become the foreign key referring to STUDID attribute of STUDENT table which is a primary key for STUDENT relation. 4) Super key: A superkey is defined in the relational model of database organization as a set of attributes of a relation variable for which it holds that in all relations assigned to that variable, there are no two distinct tuples (rows) that have the same values for the attributes in this set. i.e., the collection of attributes of super key should contain distinct values so as to find a row or tuple uniquely in a data base. Example: Consider the following EMPLOYEE relation in which we have the following attributes {EMPNO, ENAME, SAL, JOB, SSN} In the above relation we can form super keys like {EMPNO} {SSN} {EMPNO, SSN} {EMPNO, ENAME} {EMPNO, ENAME, JOB} {EMPNO, ENAME, DEPTNO} 5) Candidate key: A minimal super key is called as a candidate key. For example:

In the above EMPLOYEE relation {EMPNO} and {SSN} are the candidate keys.

Removing multi valued attributes from table The values for the columns of each row should be atomic i.e., a column for a particular row should not contain more than one value. In the above example a single employee(Fred Bloggs in the example) can join in more than one course(Delphi, VB) in that case the question will be raised on how to make the values in a column for each row atomic? The solution is to divide the row (with Ename Fred Bloggs in the example) into two parts on for each course (i.e., one for Delphi and another for VB) with same values for attributes empid,ename,company In designing any database, the first step is to gather the requirements for the database which is what we call it as requirement analysis. Second step is to give the shape to the database which is done it the conceptual phase of the database design Example: Designing an ER-Model comes under conceptual phase. Third step is to map that ER-Model to relational model i.e., in terms of tables, comes under logical representation of the design. Expressing conceptual schema In conceptual schema, each relation is listed with attributes enclosed in parentheses. Above mentioned relations are some of the examples of conceptual schema. In schema diagram primary key is denoted with a dashed line and foreign key is denoted with dotted line. As you can see : CUSTOMER relation with primary key CUSTOMER_ID. ORDER relation with ORDER_ID as primary key and CUSTOMER_ID as foreign key referring to primary key(CUSTOMER_ID) of CUSTOMER relation. ORDERLINE relation with a composite primary key (ORDER_ID,PRODUCT_ID) and with two foreign keys ORDER_ID referring to primary key(ORDER_ID) of ORDER relation PRODUCT_ID referring to primary key(PRODUCT_ID) of PRODUCT relation We can also witness many-many relationship between order and product with ORDERLINE relation where a single order can have multiple products and a single product can be ordered by more than one person. The word integrity in database means the correctness of the data in the database.

Integrity constraint is the condition which will ensure the integrity of the data in the database. For each and every attribute defined in a relation it has its own domain from where that attribute is allowed to take the values. This kind of constraint is called domain constraint. Entity integrity explains the rules of primary key like if a column or attribute is defined with primary key then that column should not contain null or duplicate values. Null is something for which there is no datatype in the database. If a relation contains an attribute for which we cannot assign any values then we will assign those attributes with NULLs. Null is different from 0(zero) which is a number type and space( ) which is a charcter type. But if an attribute is defined as primary key then that attribute should not be assigned null. If there is a primary key-foreign key relationhip between two or more tables then that relation has to satisfy constraint called referential integrity constraint. It states that every foreign key value has to have an associated (match) primary key value in the other or the same table to which the foreign key is referring. The table which contains the foreign key is referred to as child table and the table which contains the attribute that is being referred by the foreign key is called parent table. There is no restriction that a foreign key should be null. It may be assigned with NULL. How? Before that can I delete the record from the parent table? We cannot delete the parent table record directly if it has any dependencies in the child record. For example, you cannot delete the record from CUSTOMER table (parent) directly if that record has any dependencies in the ORDER (child) table. If you want to delete a record from parent table though there are dependencies existing in the child table. Then there are two ways of doing it Cascading in which if we delete a record from the parent table with the dependencies existing in the child table then even the dependent records in the child table gets deleted automatically. Set-to-null in which if we delete a record from the parent table with the dependencies existing in the child table then the dependent records in the child table will be assigned NULLs. So, we can say that foreign key may contain NULLs also. While creating relational tables each and every relation is converted into table and each and every attribute of a relation is converted into columns of that particular table.