Relational model
Relational model
Sanghita Bhattacharjee
Dept of CSE, NIT Durgapur
Acknowledgement
• A Silberschatz, H F Korth and S Sudarshan, Database System Concepts, 5th Edition, 2006
• Ramez Elmasriand Shamkant, B Navathe, Fundamentals of Database Systems, 3rd
Edition, Addison Wesley, 2000
• Video lectures:
(i) Database Management System by Prof. Partha Pratim Das
(ii) Introduction to database systems by Prof. P. Sreenivasa Kumar
(iii) Online DBMS tutorials
Introduction
Student
StudentName RollNumber PhoneNumber Age Branch
Ronita 17BT1001 9834569010 19 BT
Revanth 17ECE1002 2345678910 19 ECE
Yashwant 19CSE1001 9875684321 17 CSE
Kabir 19CSE1002 8796542341 17 CSE
Relation Instance
Student
StudentName RollNumber PhoneNumber Age Branch
Ronita 17BT1001 9834569010 19 BT
Revanth 17ECE1002 2345678910 19 ECE
Yashwant 19CSE1001 9875684321 17 CSE
Kabir 19CSE1002 8796542341 17 CSE
Examples of Relations
Enrolment
Course
StudentName RollNumbe CourseNa CourseID Semester
r me
CourseNa CourseID Credit Hours
Ronita 17BT1001 DBMS CSC51 Odd me
Revanth 17ECE1002 Antenna ECC52 Odd DBMS CSC51 4 4
theory
Antenna ECC52 3 3
Yashwant 19CSE1001 DS CSC41 Even
theory
Kabir 19CSE1002 Digital CSC42 Even
DS CSC41 4 4
logic
Ronita 17BT1001 Antenna ECC52 Odd Digital CSC42 3 3
theory logic
Revanth 17ECE1002 DBMS CSC51 Odd
kabir 19CSE1002 DS CSC41 Even
Integrity Constraint
• Relational database consists of a finite no. of relations and a set of integrity
constraints
• Integrity constraints are the set of rules or necessary conditions which are
enforced on the data attributes on the relations to maintain the quality of database.
They ensure that the data insertion, deletion , update have to be performed such a
way the database integrity is not affected and consistency of database is not
affected
1. Domain constraints
2. Key constraints
3. Entity constraints
4. Referential integrity constraints
• If the database instance satisfies all the integrity constraints specified in the
database schema is called legal database
Domain Constraint
• Domain Constraints: Attributes have associated domains
• Domain–set of atomic data values of a specific type
• Domain Constraint – the actual values of an attribute in any tuple must belong to the declared
domain. It is also defined as the set of valid values for an attribute
(ii) Default constraint : We can able to set default value for an attribute
(iii) Not null constraint : Null is legal for all domains specified in SQL. But for some
attributes we don’t use NULL like EMPID, SID etc. For these, specify not null
constraint
• Drop domain , alter domain can be applied to drop domain/ alter domains that have been already created
Examples of Domain Constraint
create table Instructor {
InstrutorID varchar (10),
Name char (20) not null,
Age int check(age>25),
Salary numeric(10,2) default 0,
DeptName char (20) check (DeptName in(‘CSE’, ‘IT’, ‘ECE’,’ME’)
};
• Entity constraint states that the primary key can not be NULL
• Primary key is used to identify the tuples uniquely in a relation. So, if
its value is NULL, we can not differentiate the tuples
Referential Integrity Constraint
• Key constraints and entity constraints are specified on an individual relation
• Referential integrity constraint (RIC) is specified between two relations and is used to
maintain consistency among the tuples of the two relations
• To define RIC, we need to define the concept of foreign key
• A relation schema may have an attribute that corresponds to the primary key of another
relation. The attribute is called a foreign key
• Used to capture relationships between relations
Foreign key
Employee Department
• Example: Find the name of the employees whose departments are located in main
building
Select Ename from Employee as E, Department as P where E. Dno= P. Dnumber
and P. Location=‘Main’;
The desired output:
Smith
John
Works_for
Department
Enrolment
Course
StudentName RollNumbe CourseNa CourseID Semester
r me
CourseNa CourseID Credit Hours
Ronita 17BT1001 DBMS CSC51 Odd me
Revanth 17ECE1002 Antenna ECC52 Odd DBMS CSC51 4 4
theory
Antenna ECC52 3 3
Yashwant 19CSE1001 DS CSC41 Even
theory
Kabir 19CSE1002 Digital CSC42 Even
DS CSC41 4 4
logic
Ronita 17BT1001 Antenna ECC52 Odd Digital CSC42 3 3
theory logic
Revanth 17ECE1002 DBMS CSC51 Odd
kabir 19CSE1002 C++ CSC43 Even Not allowed as CourseID CSC43 is not defined as
primary key of Course table and CourseID in
enrolment is defined as foreign key
Referential Integrity Constraint
Insertion
Deletion
Update
Cascade Update
• If value of primary key is changed in parent table, then corresponding foreign key
value must be changed in child table
• Update operation is used to change the values of one and more attributes in a tuple
or tuples of some relation
• We can do it as follows:
update Employee set Dno= 5 where Dno=2;
• Updating an attribute that is neither primary key or foreign key causes problem
• If foreign key attribute is modified, DBMS must sure that new value refers to an
existing tuple in the referenced relation or is null
• If foreign key is defined with cascade update. It means if primary key value is
changed in parent relation, the corresponding FK value will be changed in child
table automatically
Department Employee
E1 Ranbir 20000 1
E2 Rita 40000 2
E3 Alia 40000 2
E4 Selim 20000 3
• Similarly cascade delete: A foreign key with cascade delete means that if a
tuple/record in parent table is deleted, corresponding records in the child table will be
automatically deleted
create table Employee (
EID varchar (5) Primary key NOT NULL,
EName char (20),
Salary numeric(7,2) default 0,
Dno integer,
Foreign key (Dno) references Department (Dnumber) on update cascade on delete
cascade,
);
Example of Cascade Delete
Department Employee
E1 Ranbir 20000 1
E2 Rita 40000 2
E3 Alia 40000 2
Employee
E2 Rita 40000 2
Delete * from Department where Dnumber= 1; E3 Alia 40000 2
E4 Selim 20000 Null
More on Foreign Key
• Drop command can not be used to drop table if it is referenced by
foreign key
• We can delete primary key in table. But the default behaviour of
DBMS server prevents user from deleting data in a table if other tables
referencing it. In this case, first referencing table / child table data
needs to be deleted , followed by data in parent table
• We can delete primary key in a table without deleting foreign key in
another table using “ on delete set NULL”
create table Employee (
EID varchar (5) Primary key NOT NULL,
EName char (20),
Salary numeric(7,2) default 0,
Dno integer,
Foreign key (Dno) references Department (Dnumber) on update cascade,
Foreign key (Dno) references Department (Dnumber) on delete set NULL,
);
Conversion of ER Diagram to Relations
EmpID Name 1
N Works
Ph_no on Department
Employee
1
1 1
Employee
EmpID (PK)
Name ❑ Employee with address ( composite
attribute)
City
❑ Each component of address become a
State separate attribute
Contact
❑ Multi valued attribute require a separate relation
EmpID (FK) ❑ For a multi valued attribute A in entity set E, create a
relation R to store A
Ph_no ❑ Attributes of R are : A ∪ primary key (E)
❑ Primary key of R includes all the attributes of R
❑ Foreign key constraint from R to E on primary key
(E)
❖Mapping of Weak Entity Types. For each weak entity type W in the ER schema
with owner entity type E, create a relation R and include all simple attributes (or
simple components of composite attributes) of W as attributes of R.
❖Include as foreign key attributes of R, the primary key attribute(s) of the
relation(s) that correspond to the owner entity type(s); this takes care of mapping
the identifying relationship type of W.
❖The primary key of R is the combination of the primary key(s) of the owner(s)
and the partial key of the weak entity type W, if any.
Weak entity representation
Dependent
EmpID (FK)
Name
Sex
Converting Entities in 1: 1 Relationship (Option
#1)
1 1
Manages
Department
Employee
Department
EmpID (PK)
Employee
Name DeptID (PK)
City ❑ Separate relations for the
Deptname Employee and Department
State entities, with DeptID as a foreign
DeptID (FK) key in the Employee relation
Converting Entities in 1: 1 Relationship ( Option #2)
1 1
Manages
Department
Employee
Employee
Department
Employee
Employee
EmpID (PK)
Name
❑ The two entities are combined
City
into one relation
State
DeptID
Deptname
❖Mapping of Binary 1:N Relationship Types. There are two possible approaches: (1) foreign
key approach and (2) the cross-reference or relationship relation approach. The first
approach is generally preferred as it reduces the number of tables.
❖ The foreign key approach: For each regular binary 1:N relationship type R, identify the
relation S that represents the participating entity type at the N-side of the relationship type.
❖Include as foreign key in S the primary key of the relation T that represents the other entity
type participating in R; we do this because each entity instance on the N-side is related to at
most one entity instance on the 1-side of the relationship type.
❖Include any simple attributes (or simple components of composite attributes) of the 1:N
relationship type as attributes of S.
Converting Entities in Binary Relationships: One-
to-Many
1 N
controls
Project
Department
Project
Department
PID (PK)
DeptID (PK)
Pname
Deptname
DeptID (FK)
❑ The unique identifier of the entity on the “one side” of the one-to-many relationship is placed as a foreign key in
the relation representing the entity on the “many side”
❑ So, the DeptID attribute is placed in the Project relation as a foreign key
Converting Entities in Binary Relationships:-Many to-
Many
• Each of the two entities converts to a relation with its own attributes
but with no foreign keys (regarding this relationship)
M N
Works for
Project
Employee
Start_date
EmpID Name 1
N Works
Ph_no on Department
Employee
1
1 1
DeptID (PK)
Employee Deptname
EmpID (PK)
Name Works for
Project
City
State EmpID (PK,FK)
PID (PK)
DeptID (FK)
PID (PK,FK) Pname
EmpID (PK,FK) Startdate DeptID (FK)
Name (PK)
Sex
Handling Recursive Relationship
Supervise
Employee
EmpID (PK)
Manager
Employee Name
City
EmpID (PK)
State
DeptNo(PK)
Manager no (FK)
Converting Entities in Ternary Relationships
SSN PID
Name Pname
Commission CID Customer Unit Price
Cname Qty
City
Converting Entities in Ternary Relationships
Customer
CID (PK)
Cname
City
Product
Salesman
Sales PID (PK)
SSN (PK) Pname
SSN (PK, FK)
Name Unit Price
CID (PK, FK)
Commission Qty
PID (PK, FK)
Date(PK)
❑ The primary key of the Sales relation is
the combination of the unique identifiers
of the three entities involved, plus the
descriptive attribute
Important Point to be Remembered
• Super Key and Candidate key are used to get records from tables.
These keys are also used to create relationship between tables.
• Super Key and Candidate key both are used to identify records
uniquely in a table.
• Both keys can have null values.
• Primary key is always unique and not null. But super key and
candidate can take null values , but must be unique
• Alternate is an alternative for primary key. It can take null values until
not null is specified. But it must take unique value