Chapter-3

Relational Model

Introduction
The entire database and more particularly the modern database uses a very important data model called as the Relational Model. This model was proposed by Codd in the year 1970. During that time the popular models were only Network model and Hierarchical model.

Relation
The relational model represents the database as a collection of relations. Each relation resembles a simple table, having a set of rows and set of columns. Each relation consists of a relational schema and relational instance. The instance is nothing but a relation having a set of specific values for the records in the database at a particular time.

Example
Name Prasad Gaurav Ayswaria RegNo 1BI99CS045 1BI98CS012 1BI97CS044 Addr 456, Koramangala 2, J.C. Road 12, K.S. Layout Phone 5567234 6623109 6669456 DBirth 23-Mar-67 10-Dec-66 04-Aug-65 GPA 8.9 4.5 9.0

BrName VV Puram JC Road Jayanagar MG Road Gandhinagar

BrCity Bangalore Mysore Bangalore Belgaum Belgaum

Assets 10034567 2390156 6784560 12445566 67888888

Relation - Definition
A relation R is a subset of the Cartesian product of the domains that define R R (dom(A1)) (dom(A2)) . . . (dom(An)) This actually gives the total number of tuples in the Cartesian product. R is represented as, R (A1, A2, . . ., An). The degree of a relation is the number of attributes that a relation has and the cardinality of the relation instance is the number of tuples in it.

Relational Model Constraints

An integrity constraint is a restriction specified on a database schema. The term integrity refers to the accuracy or correctness of data in the database. Example: an attribute Marks in a Student relation can take values only from 0 to 100.

Domain Constraints
The domain constraints specifies the value of each attribute A that must be an atomic value from the domain dom(A). Example: The type integer may hold all the integer values may be allowed. Oracle allows VARCHAR2, NUMBER, CHAR, INTEGER, DATE, LONG, RAW, LONG RAW, BLOB, CLOB, BFILE.

Key Constraints
A key constraint is a declaration to specify a minimal set of attributes to find a tuple uniquely in a relation. Candidate Key: Definition Let K be a set of attributes of the relation R. Then, K is a candidate key if and only if it satisfies the following two conditions: (1) Uniqueness: No legal values of R ever contain two distinct tuples with the same value. (2) Irreducibility: No proper subset of K has the uniqueness property. Eg-1: {Sid, Name} is not a candidate key, because this set properly contains the key {Sid} Eg-2: {BranchName, BranchCity} is not a candidate key

Key Constraints
Super Key A superset of a candidate key is a super key. A super key has the uniqueness property but not necessarily the irreducible property. Eg: {Sid, Name} is a super key Primary Key It is customary to have one of the candidate keys as the primary key of the relation. It is better to choose a primary key with minimal set of attributes. Eg: {SSN}, {RegNo}, {PartNo}, etc. Can the subset {CFirstName, CLastName, CPhone} form a primary key?

Key Constraints
Foreign Key A foreign key is a set of attributes of a relation, say, R2 whose values are required to match values of some primary key of some other relation R1. The foreign key constraint is necessary between any two relations to maintain the data consistency. Eg: Employees(SSN, Name, .., DNo) Departments(DNo, DName) DNo in Employees relation is called as foreign key. What happens when insertion, deletion, or modification is done to the records with the enforced constraints?

ER to Relational mapping (ER to Tables)

Strong Entity to Table: For every strong entity E, create a table R that includes all the simple attributes of E.
Addr Name SSN Salary Sex DateOfBirth

Employees

Employees(SSN,Name,BDate,Addr,Sex,Salary)

Weak Entity to Table: Create a table Dependent for the weak entity by including all the attributes of Dependent entity. However, the primary key for this table should be selected as
<SSN, DependentName>

One-to-One cardinality:
Name SSN Addr StartDate DName DNo Dlocation

Employees

Manages

Departments

Departments (DNo, DName, SSN, StartDate)

Suppose a full participation exits on both the sides of the relations, merge both into a single table. The primary key for this merged table will be the combination of primary keys of both the entities.

One-to-Many cardinality
Name SSN Addr StartDate DNo DName DLocations

Employees

Works_for

Departments

Employees(SSN,Name,DateOfBirth,Addr,Sex,Salary, DNo) Include DNo (primary key of Departments) in the manyside (Employees).

Many-to-Many cardinality Translating many-to-many relationship set to table is very simple; create a new table with the relationship set name. Include the primary keys of the participating entities as the composite primary key for the new table.
Name SSN Addr M Hours PNo N PName PLocation

Employees

Works_On

Projects

Works_On (SSN, PNo, Hours)

Handling multi valued attribute: Each multi valued

attribute should be translated into a table. Then the primary key for this table is nothing but the primary key of the participating entity.

Ternary Relationship set to Table: For a ternary

relationship set, say s, you must create a new table with primary keys of the three participating entities. Obviously, these attributes form the composite key for the new tables.

DName DNo

DLocations

DNo 1 2 3 2

DLocation Bangalore Belgaum Bangalore Chennai

Departments

Handling Generalization
Tables to be created are: (Method-1) AccNo Balance Account 1. Account(AccNo, Balance) 2. SB(AccNo, Int_Amt) Method-2: SB(AccNo, Balance, Int_Amt) FD(AccNo, Balance, Dep_Amt)
ISA

3. FD(AccNo, Dep_Amt) 4. RD(AccNo, Rec_Amt) 5. CA(AccNo, Od)

SB

FD

RD

CA

Int_Amt

Dep_Amt

Rec_Amt

Od

Handling Aggregation:
RegNo StdName

Students
PName SSN

Attends
CourseId

CourseTiitle Credits

Professors

Teaches

Courses

Professors(SSN, PName) Courses(CourseId, CourseTitle, Credits) Students(RegNo, Stdname) Attends(RegNo, CourseId, SSN) Teaches(CourseId, SSN)

End of Chapter 3