0% found this document useful (0 votes)
6 views

Relational model

The document provides an overview of the Relational Model in database management systems, detailing its foundational concepts, including relations, domains, and integrity constraints. It discusses the significance of primary and foreign keys, as well as various types of constraints that ensure data integrity and consistency. Examples are given to illustrate how these concepts are applied in practical database scenarios.

Uploaded by

snehasis.pradhan
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
6 views

Relational model

The document provides an overview of the Relational Model in database management systems, detailing its foundational concepts, including relations, domains, and integrity constraints. It discusses the significance of primary and foreign keys, as well as various types of constraints that ensure data integrity and consistency. Examples are given to illustrate how these concepts are applied in practical database scenarios.

Uploaded by

snehasis.pradhan
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 85

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

• Invented by Ted Codd of IBM research in 1970. Known as Father of RDBMS


• A database management system that stores the data in the form of the related
tables is known as RDBMS
• Goal of RDBMS is to easy store and retrieve
• Most of the modern DBMS (MySQL, MS Access, oracle, Microsoft SQL etc.) are
relational
• Relational model is simple model with a mathematical foundations
What is Relation?
• A relation is a set of n-tuples r = (t1, t2, …, tn) where each tuple is an ordered list of n values
<v1,v2,…vn> where each vi is an element of dom(Ai) or is null value
• Let D1 is domain of (A1), D2 is domain of (A2), so on Dn , a relation r(R) is a subset of the
Cartesian product of the domains that define R:

Cartesian product specifies all possible


r ⊆ D1 × D2 × … × Dn
combinations of value from the domains
R is relation schema of A1, A2, … , An
• Example:
• StudentName = {Nitesh, Revanth, Yashwant, Ronita } /* Set of all student names */
• Branch = {CSE, ECE, BT, …} /* set of all branch names*/
• Age = {17, 18, 19, …} /* set of age */
Then r = { (Nitesh, CSE, 17),
(Revanth, CSE, 18),
(Yashwant, ECE, 19),
(Ronita, BT, 19) }
is a relation over
StudentName × Branch × Age
More on Relation
Consists of relation name and a set of attributes or field names or column names
Each attribute of a relation has a name
Example:
Student ( StudentName: string,
RollNumber: string,
PhoneNumber: integer,
Age : integer,
Relation
Branch: string )
name domain
Attribute
name
Domain in Relation
• Each attribute has a domain – the set of allowed values – datatype of relation
• Attribute values are (normally) required to be atomic; that is, indivisible
• E.g. the value of an attribute can be an phone number,
but cannot be a set of phone numbers
• Domain is said to be atomic if all its members are atomic
• The special value null is a member of every domain
• The null value causes complications in the definition of many operations
(comparison, retrieval, update )
StudentName RollNumber PhoneNumber Age Branch
Ronita 17BT1001 9834569010, 19 BT
8734565432
Revanth 17ECE1002 2345678910 19 ECE
Yashwant 19CSE1001 9875684321 17 CSE
Kabir 19CSE1002 8796542341 17 CSE
Relation Instance
• A finite set of tuples constitute a relation instance/ state/ relation

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

• Order of tuples is irrelevant (tuples may be stored in an arbitrary order)


• Example: Student relation with unordered tuples

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

• We specify several constraints under domain constraints


(i) Check constraint : Ensures that when a new tuple is inserted into the relation it
must satisfy the predicate specified in the check clause

(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’)
};

create table Student{


StudentName char(20) not null,
RollNumber varchar(10) not null,
Phonenumber int,
Age int check(age>15),
Branch char(10)
}
Examples of Domain Constraint

StudntName RollNumber Age


Rita 1001 17
Jaya 1002 20
Jeet 1003 A

Not allowed. Age must be


an integer value
Key Constraint
• Key Constraint: Relation schema has one or more associated keys
• Key is used to identify each tuple uniquely within a relation
• if K is supposed to be a key for scheme R, any relation instance r on R should not
have two tuples that have identical values for attributes in K. Key value always be
an unique. Also, none of the key attributes can have null value
InstrutorID varchar(10) NOT NULL PRIMARY KEY
Example of Key Constraint

StudntName RollNumber Age


Rita 1001 17
Jaya 1002 20
Jeet 1002 18

Not allowed. Must have


unique value
Entity Constraint

• 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

• A set of attributes FK in relation R2 is foreign key of R1 that references relation R1 if it


satisfies two rules
1. Attributes in FK must have same domain(s) as the primary key
attributes PK of R2
2. If a foreign key in R2 refers to primary key in R1, then every
value of the foreign key in R2 must be NULL or available in R1
2.1 A value of FK in a tuple t1 of relation R2 either occurs as
a value of PK for some tuple t2 in relation R1 or is null. I.e. t2[FK]= t1[PK]
Foreign key
• R2 is referencing relation or child relation. R1 is referenced relation or parent relation
• RIC ensures that references to tuples in R1 are for currently existing tuples. That is, there
are no dangling references
• Foreign keys are used to join two or more tables to retrieve the information from the
tables

Employee Department

EID Ename Salary Dno (FK) Dnumber Dname Year Location


(PK)
E1 Smith 20000 1
1 CSE 1997 Main
E2 John 40000 1
2 EE 1990 Annex1
E3 Alia 40000 2 3 BT 2010 Annex2
E4 Selim 20000 Null 4 ECE 1990 Main
Foreign key

• 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

EID PID Hours


E1 P1 5
E1 P2 6
E2 P2 8
E3 P1 8

EID Ename Salary Dno


E1 Smith 20000 1
Employee E2 John 40000 1
E3 Alia 40000 2
E4 Selim 20000 Null
Foreign Key Definition
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)
);

create table Department(


Dnumber integer Primary key NOT NULL,
Dname char (10),
Year integer,
Location char(20)
);
Create table Employee Create table Works_for
( (
EID varchar(5) Primary key NOT NULL Unique, EID varchar(5),
Ename char(20) NOT NULL, PID integer,
Salary numeric (7,2) Default 0, Hours integer,
Dno integer Primary key (EID, PID)
); );

Create table Works_for


(
EID varchar(5), Query to implement candidate key:
PID integer,
Hours integer, Alter table Works_for add key E_P (EID,PID);
);
Foreign key
Primary key
Enrolment Course

StudentName RollNumber CourseName CourseID Semester

Ronita 17BT1001 DBMS CSC51 Odd CourseNa CourseID Credit Hours


me
Revanth 17ECE1002 Antenna ECC52 Odd
theory DBMS CSC51 4 4
Yashwant 19CSE1001 DS CSC41 Even Antenna ECC52 3 3
Kabir 19CSE1002 Digital logic CSC42 Even theory
DS CSC41 4 4
Ronita 17BT1001 Antenna ECC52 Odd Digital CSC42 3 3
theory logic
Revanth 17ECE1002 DBMS CSC51 Odd
kabir 19CSE1002 DS CSC41 Even
Foreign key
Primary key

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

EID Ename Salary Dno (FK)

E1 Ranbir 20000 1

E2 Rita 40000 2

E3 Alia 40000 2

E4 Selim 20000 3

Update Department set Dnumber=‘5’ where Dnumber=‘2’;


Employee
Department
Dnumber Dname Year Location EID Ename Salary Dno
1 CSE 1997 Main E1 Ranbir 20000 1
5 EE 1990 Annex1 E2 Rita 40000 5
3 BT 2010 Aneex2 E3 Alia 40000 5
4 ECE 1990 Main E4 Selim 20000 3
Cascade Delete

• 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

EID Ename Salary Dno (FK)

E1 Ranbir 20000 1

E2 Rita 40000 2

E3 Alia 40000 2

E4 Selim 20000 Null

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

• Each entity will convert to a relation


• Multi valued attributes require a separate relation ( no such thing as a
multi valued attribute in relational model)
• Each many-to-many relationship or associative entity will convert to a
relation
• During the conversion, certain rules must be followed to ensure that
foreign keys appear in their proper places in the relations
ER Diagram # Example
DeptID Deptname

EmpID Name 1
N Works
Ph_no on Department

Employee
1
1 1

Address manages controls


ha
s
startdate N
M N
City State
Dependent Project
Works
for
Name Sex PID Pname
Steps for ER to Relation Mapping
❖ Mapping of Regular Entity Types. For each regular (strong) entity type E in the
ER schema, create a relation R that includes all the simple attributes of E.
❖Include only the simple component attributes of a composite attribute.
❖Choose one of the key attributes of E as the primary key for R.
❖If the chosen key of E is a composite, then the set of simple attributes that form it
will together form the primary key of R.
❖If multiple keys were identified for E during the conceptual design, the
information describing the attributes that form each additional key is kept in order
to specify additional (unique) keys of relation R. Knowledge about keys is also
kept for indexing purposes and other types of analyses.
❖Mapping of Multivalued Attributes. For each multivalued attribute A, create a new
relation R.
❖This relation R will include an attribute corresponding to A, plus the primary key
attribute K—as a foreign key in R—of the relation that represents the entity type
or relationship type that has A as a multivalued attribute.

❖The primary key of R is the combination of A and K. If the multivalued attribute


is composite, we include its simple components.
Composite and Multi valued Attributes

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

EmpID (PK) ❑ Separate relations for the


DeptID (PK)
Name Employee and Department
Deptname entities, with EmpID as a
City
EmpID (FK) foreign key in the Dept
State relation
Converting Entities in 1: 1 Relationship (Option
#3)
1 1
Manages
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

• An E-R diagram with two entities in a many-to-many relationship


converts into three relations

• Each of the two entities converts to a relation with its own attributes
but with no foreign keys (regarding this relationship)

• In addition, there must be a third “many-to-many” relation for the


many-to-many relationship
❖Mapping of Binary M:N Relationship Types. For each binary M:N relationship
type R, create a new relation S to represent R.
❖Include as foreign key attributes in S the primary keys of the relations that
represent the participating entity types;
❖their combination will form the primary key of S.
❖Also include any simple attributes of the M:N relationship type (or simple
components of composite attributes) as attributes of S
Converting Entities in Binary Relationships:-Many to-
Many

M N
Works for
Project

Employee

Start_date

Employee Works for Project


EmpID (PK,FK) PID (PK)
Pname
PID (PK,FK)

Start_date ❑ The primary key of Works for is the


combination of the unique identifiers of the
two entities in the many-to-many relationship.
Additional attributes are the intersection data /
descriptive attribute
ER Diagram # Example
DeptID Deptname

EmpID Name 1
N Works
Ph_no on Department

Employee
1
1 1

Address manages controls


ha
s
startdate N
M N
City State
Dependent Project
Works
for
Name Sex PID Pname
Relational Schema with RIC
Department

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

• Salesman sales product for customer: Ternary relationship


Date

Salesman Sales Product

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

You might also like