Chapter Three

‫الفصل الثالث‬
THE RELATIONAL MODEL
‫النموذج العالئقي‬

By: Dr. Hatem Moharram

‫حاتم محرم‬.‫د‬
How is data represented in the relational model?
What integrity constraints can be expressed?
How can data be created and modified?
How can data be manipulated and queried?
How can we create, modify, and query tables using
SQL?
How do we obtain a relational database design
from an ER diagram?
What are views and why are they used?
3.1 THE RELATIONAL MODEL
The main construct for representing data in the relational
model is a relation.
A relation consists of a relation schema and a relation
instance.
The relation instance is a table, and the relation schema
describes the column heads for the table.
The schema specifies the relation's name, the name of each
field (or column, or attribute), and the domain of each field.
A domain is referred to in a relation schema by the domain
name and has a set of associated values.
Ex.:
Students(sid: string, name: string, login: string, age: integer,
gpa: real)
An instance of a relation is a set of tuples, also called
records, in which each tuple has the same number of fields
as the relation schema.
A relation instance can be thought of as a table in which
each tuple is a row, and all rows have the same number of
fields.
Fields, Columns, Attributes
Field names
gpa age login St_name Sid
Tuples, 4 30 Shote ‫حاتم محرم‬ 10002
Records, 1.2 22 zhat ‫سعد مسعود‬ 10003
Rows 3.1 32 ttot ‫فرهود فهمي‬ 10004
2.3 24 tfot ‫غالب مغلوب‬ 10005
3.4 25 tyto ‫ابو سلومة األقرع‬ 10006
Notes:
1- no two rows are identical. This is a requirement of the
relational model-each relation is defined to be a set of
unique tuples or rows.

2- The order in which the rows are listed is not important

3- the order of fields does not matter.

4- The domain constraints in the schema specify an

important condition that we want each instance of the
relation to satisfy.

5- Relation instance means relation instance that satisfies

the domain constraints in the relation schema.
The degree, also called arity, of a relation is the number of
fields.

The cardinality of a relation instance is the number of tuples

in it.

Ex.: The degree of the relation (the number of columns) is

five, and the cardinality of this instance is six.

gpa age login St_name Sid

4 30 Shote ‫حاتم محرم‬ 10002
1.2 22 zhat ‫سعد مسعود‬ 10003
3.1 32 ttot ‫فرهود فهمي‬ 10004
2.3 24 tfot ‫غالب مغلوب‬ 10005
3.4 25 tyto ‫ابو سلومة األقرع‬ 10006
3.6 23 tafa ‫مغلوب غالب‬ 10007
A relational database is a collection of relations with distinct
relation names.
The relational database schema is the collection of schemas
for the relations in the database.
Students (sid:string, name: string, login: string, age:
integer, gpa: real)
Faculty (fid:string, fname:string, sal:real)
Courses (cid:string,cname:string,credits:integer)
Rooms (rno:integer, address:string,capacity:integer)
Enrooled (sid:string, cid:string,grade:string)
Teaches (fid:string, cid : string)
Meets_In (cid:string, rno:integer, ,time: string)
An instance of a relational database is a collection of
relation instances, one per relation schema in the database
schema
3.1.1 Creating and Modifying Relations Using SQL
The SQL language standard uses the word table to denote
relation.

The subset of SQL that supports the creation, deletion, and

modification of tables is called the Data Definition Language
(DDL).

The CREATE TABLE statement is used to define a new table.

Ex.: To create the Students relation, we can use the
following statement:
CREAT TABLE Students (sid CHAR(20),
st_name CHAR(30),
login CHAR(20),
age INTEGER,
gpa REAL)
Tuples are inserted ,using the INSERT command. We can
insert a single tuple into the Students table as follows:

INSERT INTO Students (sid, name, login, age , gpa)

VALUES (10002, 'Hatem Moharam',’tota ‘, 30, 4)

We can optionally omit the list of column names in the INTO

clause and list the values in the appropriate order,
We can delete tuples using the DELETE command.

Ex.: We can delete all Students tuples with name equal to

Hatem Moharram using the command:

DELETE
FROM Students S
WHERE s.st_name='Hatem Moharram‘
we can modify the column values in an existing row using
the UPDATE command.
Ex.: we can increment the age and decrement the gpa of the
student with sid 10002:
UPDATE Students S
SET S.age=S.age+1, S.gpa=S.gpa-1
WHERE s.sid=10002
The WHERE clause is applied first and determines which
rows are to be modified.
The SET clause then determines how these rows are to be
modified.
UPDATE Students S
SET S.gpa = S.gpa - 1
WHERE S.gpa >=3.3
gpa age login St_name Sid
4 30 Shote ‫حاتم محرم‬ 10002
1.2 22 zhat ‫سعد مسعود‬ 10003
3.1 32 ttot ‫فرهود فهمي‬ 10004
2.3 24 tfot ‫غالب مغلوب‬ 10005
3.4 25 tyto ‫ابو سلومة األقرع‬ 10006

gpa age login St_name Sid

3 30 Shote ‫حاتم محرم‬ 10002
1.2 22 zhat ‫سعد مسعود‬ 10003
3.1 32 ttot ‫فرهود فهمي‬ 10004
2.3 24 tfot ‫غالب مغلوب‬ 10005
2.4 25 tyto ‫ابو سلومة األقرع‬ 10006
3.2 INTEGRITY CONSTRAINTS OVER RELATIONS
a DBMS must help prevent the entry of incorrect
information.

An integrity constraint IC is a condition specified on a

database schema and restricts the data that can be stored in
an instance of the database.

If a database instance satisfies all the integrity constraints

specified on the database schema, it is a legal instance.

A DBMS enforces integrity constraints, in that it permits

only legal instances to be stored in the database.
Integrity constraints are specified and enforced at different
times:

1. when the DBA or end user defines a database schema,

he specifies the ICs that must hold on any instance of this
database.

2. when a database application is run, the DBMS checks for

violations and disallows changes to the data that violate
the specified ICs. It is important to specify exactly when
integrity constraints are checked relative to the
statement that causes the change in the data and the
transaction that it is part of.
3.2.1 Key Constraints
A key constraint is a statement that a certain minimal subset
of the fields of a relation is a unique identifier for a tuple.
A set of fields that uniquely identifies a tuple according to a
key constraint is called a candidate key for the relation.

There are two parts in the definition of the candidate key:

1. Two distinct tuples in a legal instance cannot have
identical values in all the fields of a key.
2. No subset of the set of fields in a key is a unique identifier
for a tuple.
Note that: every relation is guaranteed to have a key. Since a
relation is a set of tuples, the set of all fields is always a
superkey.
A relation may have several candidate keys.

Out of all the available candidate keys, a database designer

can identify a primary key.
Specifying Key Constraints in SQL
In SQL, we can declare that a subset of the columns of a
table constitute a key by using the UNIQUE constraint.

At most one of these candidate keys can be declared to be a

primary key, using the PRIMARY KEY constraint.

CREAT TABLE Students (sid CHAR(20),

st_name CHAR(30),
login CHAR(20),
age INTEGER,
gpa REAL,
PRIMARY KEY sid,
UNIQUE (st_name , age))
we can name a constraint by preceding it with CONSTRAINT
constraint-name.

If the constraint is violated, the constraint name is returned

and can be used to identify the error.

CREAT TABLE Students (sid CHAR(20),

st_name CHAR(30),
login CHAR(20),
age INTEGER,
gpa REAL,
UNIQUE (st_name , age),
CONSTRAINT StudentsKey PRIMARY KEY (sid))
3.2.2 Foreign Key Constraints
the information stored in a relation can be linked to the
information stored in another relation by using a foreign
key.

If one of the relations is modified, the other must be

checked, and perhaps modified, to keep the data consistent.

An IC involving both relations must be specified if a DBMS is

to make such checks.
Students (sid:string, name: string, login: string, age: integer,
gpa: real)

Enrooled (sid: string, cid:string, grade:string)

The sid field of Enrolled is called a foreign key and refers to

Students.

The foreign key in the referencing relation (Enrolled) must

much the primary key of the referenced relation (Students).

that is, it must have the same number of column and

compatible data types. The column names can be different
Enrolled Students

cid grade sid sid St_name login age gpa

Comp01 A 566 566 Hatem tot 20 2.0
Comp02 B 456 300 Aly tat 19 3.3
Comp03 A 671 671 Saad tet 30 3.8
Math002 C 921 303 Kalil fah 25 2.0
456 Hassan fpr 22 3
921 Mohamed got 21 2
(Referencing relation) (Referenced relation)

every sid value that appears in the instance of the Enrolled

table appears in the primary key column of a row in the
Students table.
If we try to insert the tuple (math003, F, 331) into Enrolled,
the IC is violated because there is no tuple in Students with
sid 331; the database system should reject such an insertion.
Enrolled Students
cid grade sid sid St_name login age gpa
Comp01 A 566 566 Hatem tot 20 2.0
Comp02 B 456 300 Aly tat 19 3.3
Comp03 A 671 671 Saad tet 30 3.8
Math002 C 921 303 Kalil fah 25 2.0
456 Hassan fpr 22 3
921 Mohamed got 21 2

if we delete the tuple (566, hatem, tot, 20, 2.0) from

Students, we violate the foreign key constraint because the
tuple (comp01, A,566) in Enrolled contains sid value 566, the
sid of the deleted Students tuple.
Specifying Foreign Key Constraints in SQL
Enrooled (sid: string, cid:string, grade:string)
CREAT TABLE Enrolled (sid CHAR(20),
cid CHAR(30),
grade CHAR(2),
PRIMARY KEY (sid , cid),
FOREIGN KEY (sid) REFERENCES Students)
The foreign key constraint states that every Sid value in
Enrolled must also appear in Students.

the primary key constraint for Enrolled states that a student

has exactly one grade for each course he or she is enrolled
in.
3.3 ENFORCING INTEGRITY CONSTRAINTS
ICs are specified when a relation is created and enforced
when a relation is modified.

The impact of domain, PRIMARY KEY, and UNIQUE

constraints is straightforward: If an insert, delete, or update
command causes a violation, it is rejected.

Every potential IC violation is generally checked at the end

of each SQL statement execution, although it can be
deferred until the end of the transaction executing the
statement.
INSERT
INTO Students( sid , st_name, login , age , gpa)
VALUES (300, 'Sayed', ‘hota’, 17,3.7)
Students
sid St_name login age gpa
566 Hatem tot 20 2.0
300 Aly tat 19 3.3
671 Saad tet 30 3.8
303 Kalil fah 25 2.0
456 Hassan fpr 22 3
921 Mohamed got 21 2

The insertion violates the primary key constraint because

there is already a tuple with the Sid 300, and it will be
rejected by the DBMS.
INSERT
INTO Students( sid , st_name, login , age , gpa)
VALUES (null, 'Sayed', ‘hota’, 17,3.7)

The insertion violates the constraint that the primary key

cannot contain null.
Deletion does not cause a violation of domain, primary key
or unique constraints.

update can cause violations, similar to an insertion:

UPDATE Students S
SET S.sid = 566
WHERE S.sid = 921
Students
sid St_name login age gpa
566 Hatem tot 20 2.0
303 Kalil fah 25 2.0
921 Mohamed got 21 2

This update violates the primary key constraint because

there is already a tuple with sid 566.
The impact of foreign key constraints is more complex
because SQL sometimes tries to repair a foreign key
constraint violation instead of simply rejecting the change.

Deletions of Enrolled tuples do not violate referential

integrity, but insertions of Enrolled tuples could.

Enrolled Students
cid grade sid sid St_name login age gpa
Comp01 A 566 566 Hatem tot 20 2.0
Comp02 B 456 300 Aly tat 19 3.3
Comp03 A 671 671 Saad tet 30 3.8
Math002 C 921 303 Kalil fah 25 2.0
456 Hassan fpr 22 3
921 Mohamed got 21 2
 INSERT
INTO Enrolled (cid, grade, sid)
VALUES (comp01, 'B', 333)
Enrolled Students
cid grade sid sid St_name login age gpa
Comp01 A 566 566 Hatem tot 20 2.0
Comp02 B 456 300 Aly tat 19 3.3
Comp03 A 671 671 Saad tet 30 3.8
Math002 C 921 303 Kalil fah 25 2.0
456 Hassan fpr 22 3
921 Mohamed got 21 2

The following insertion is illegal because there is no

Students tuple with sid 333.
insertions of Students tuples do not violate referential
integrity.

deletions of Students tuples could cause violations.

updates on either Enrolled or Students that change the sid

value could potentially violate referential integrity.
SQL provides several alternative ways to handle foreign key
violations.
three basic questions:

1. What should we do if an Enrolled row is inserted, with a

sid column value that does not appear in any row of the
Students table?
In this case, the INSERT command is simply rejected.
2. What should we do if a Students row is deleted?
The options are:
• Delete all Enrolled rows that refer to the deleted Students
row.
• Disallow the deletion of the Students row if an Enrolled
row refers to it.
• Set the sid column to the sid of some (existing) 'default'
student, for every Enrolled row that refers to the deleted
Students row.
• For every Enrolled row that refers to it, set the studid
column to null.

3. What should we do if the primary key value of a Students

row is updated?
The options here are similar to the previous case.
SQL allows us to choose any of the four options on DELETE
and UPDATE.
Ex: we can specify that when a Students row is deleted, all
Enrolled rows that refer to it are to be deleted as well, but
that when the sid column of a Students row is modified, this
update is to be rejected if an Enrolled row refers to the
modified Students row:
CREAT TABLE Enrolled ( sid CHAR(20),
cid CHAR(30),
grade CHAR(2),
PRIMARY KEY (sid , cid),
FOREIGN KEY (sid) REFERENCES Students
ON DELETE CASCADE deleted, all

ON UPDATE NO ACTION ) reject

3.3.1 Transactions and Constraints
a program that runs against a database is called a
Transaction.
a Transaction can contain several statements (queries,
inserts, updates, etc.) that access the database.

If (the execution of) a statement in a transaction violates an

integrity constraint, should the DBMS detect this right away
or should all constraints be checked together just before the
transaction completes?

By default, a constraint is checked at the end of every SQL

statement that could lead to a violation, and if there is a
violation, the statement is rejected.
Sometimes this approach is too inflexible.
Ex.: every student is required to have an honors course, and
every course is required to have a grader “student at certain
grade” , who is some student.
CREATE TABLE Students ( sid CHAR(20) ,
name CHAR(30),
login CHAR (20) ,
age INTEGER,
honors CHAR(10) NOT NULL,
gpa REAL)
PRIMARY KEY (sid),
FOREIGN KEY (honors) REFERENCES Courses (cid))
CREATE TABLE Courses (cid CHAR(10),
cname CHAR ( 10) ,
credits INTEGER,
grader CHAR(20) NOT NULL,
PRIMARY KEY (cid)
FOREIGN KEY (grader) REFERENCES Students (sid))

whenever a Students tuple is inserted, a check is made to

see if the honors course is in the Courses relation.

whenever a Courses tuple is inserted, a check is made to see

that the grader is in the Students relation.
How are we to insert the first course or student tuple?

One cannot be inserted without the other.

The only way to accomplish this insertion is to defer the

constraint checking that would normally be carried out at
the end of an INSERT statement.
3.4 QUERYING RELATIONAL DATA

A relational database query (query, for short) is a question

about the data, and the answer consists of a new relation
containing the result.
Ex.: find all students younger than 21.
SELECT * The symbol ,*, means that
FROM Students S we retain all fields of
WHERE S.age <= 20 selected tuples in the result.

S is a variable that
sid St_name login age gpa
takes on the value
566 Hatem tot 20 2.0 of each tuple in
300 Aly tat 19 3.3 Students, one tuple
671 Saad tet 30 3.8 after the other.
303 Kalil fah 25 2.0
the answer to this query
sid St_name login age gpa
566 Hatem tot 20 2.0
300 Aly tat 19 3.3
Ex.: fined the names and logins of students who are younger
than 21.
SELECT S.st_name, S.login
FROM Students S
WHERE S.age <= 20
sid St_name login age gpa
566 Hatem tot 20 2.0
300 Aly tat 19 3.3
671 Saad tet 30 3.8
303 Kalil fah 25 2.0
the answer to this query
it is obtained by applying the
selection to the instance <= 20 of St_name login
Students followed by removing hatem tot
aly tat
unwanted fields.
Ex.: fined the names of all students who obtained an A and
the id of the course in which they got an A.
SELECT S.st_name, E.cid
FROM Students S, Enrolled E
WHERE S.sid=E.sid AND E.grade=’A’
Enrolled Students
cid grade sid sid St_name log age gpa
in
Comp01 A 566 566 Hatem tot 20 2.0
Comp02 B 456 300 Aly tat 19 3.3
Comp03 A 671 671 Saad tet 30 3.8
Math002 C 300 303 Kalil fah 25 2.0
456 Hassan fpr 22 3

cid St_name
Comp01 Hatem
Comp03 Saad
3.5 LOGICAL DBASE DESIGN: ER TO RELATIONAL
Here we describe how to translate an ER diagram into a
collection of tables with associated constraints, that is, a
relational database schema.

3.5.1 Entity Sets to Tables

Each attribute of the entity set becomes an attribute of the
table.
Employees (ssn: string, name:string, lot: integer)
CREAT TABLE Employees (ssn CHAR(11), ssn name lot
name CHAR(30),
lot INTEGER, Employees
PRIMARY KEY (ssn)),
3.5.2 Relationship Sets (without Constraints) to Tables
the attributes of the relation include:

1- The primary key attributes of each participating entity

set, as foreign key fields.

2- The descriptive attributes of the relationship set.

The set of nondescriptive attributes is a superkey for the

relation.

If there are no key constraints, this set of attributes is a

candidate key.
 since
ssn name lot did dname budget

Employees Works_In2 Departments

capacity Locations address

Works_In2(ssn:string,did:integer, address: string, since:date)

CREAT TABLE Works_In2 (ssn CHAR(11),

did INTEGERE,
address CHAR(20),
since DATE,
PRIMARY KEY (ssn, did , address),
FOREIGN KEY (ssn) REFERENCES Employees,
FOREIGN KEY (did) REFERENCES Departments,
FOREIGN KEY (address) REFERENCES Locations)
 ssn name lot

Employees

Supervisor Subordinate
Reports_To

Reports_To(supervisor_ssn :string, subordinate_ssn :string)

CREAT TABLE Reports_To (supervisor_ssn CHAR(11),

subordinate_ssn CHAR(11),
PRIMARY KEY (supervisor_ssn, subordinate_ssn),
FOREIGN KEY (supervisor_ssn) REFERENCES Employees (ssn),
FOREIGN KEY (subordinate_ssn) REFERENCES Employees (ssn))
3.5.3 Translating Relationship Sets with Key Constraints

If a relationship set involves n entity sets and some m of

them are linked via arrows in the ER diagram, the key for
anyone of these m entity sets constitutes a key for the
relation to which the relationship set is mapped.

Hence we have m candidate keys, and one of these should

be designated as the primary key.
r
b1 b2 b3 a1 a2 a3

B R A

c2 C c1
First Approach:
since
ssn name lot did dname budget

Employees Manages Departments

Manages (did: integer, ssn:string ,since: date)

CREAT TABLE Manages (did INTEGERE,
ssn CHAR(11),
since DATE,
PRIMARY KEY (did),
FOREIGN KEY (ssn) REFERENCES Employees,
FOREIGN KEY (did) REFERENCES Departments)
Second Approach:
include the information about the relationship set in the
table corresponding to the entity set with the key.

Employees (ssn , name, lot),

Dept_Mgr (did, dname, budget, ssn , since)

CREAT TABLE Dept_Mgr (did INTEGERE,

dname CHAR(20),
budget REAL,
ssn CHAR(11),
since DATE,
PRIMARY KEY (did),
FOREIGN KEY (ssn) REFERENCES Employees)
3.5.4 Translating Relationship Sets with Participation Constraints

ssn name lot since did dname budget

Employees Manages Departments

ssn cannot take on null values

CREAT TABLE Dept_Mgr ( did INTEGERE,

dname CHAR(20),
budget REAL,
ssn CHAR(11) NOT NULL
since DATE,
PRIMARY KEY (did),
FOREIGN KEY (ssn) REFERENCES Employees,
ON DELETE NO ACTION) Employees tuple cannot be deleted while it is
pointed to by a Dept-Mgr tuple.
3.5.5 Translating Weak Entity Sets
A weak entity set always participates in a one-to-many
binary relationship and has a key constraint and total
participation.
cost pname
ssn name lot age
Employees Policy Dependents

Dep_Policy(ssn, pname, cost, age)

CREAT TABLE Dep_Policy (ssn CHAR(11) NOT NULL,
pname CHAR(20),
age INTEGERE,
cost REAL,
PRIMARY KEY (ssn,pname), ssn cannot take on null values
FOREIGN KEY (ssn) REFERENCES Employees,
ON DELETE CASCADE)
3.5.6 Translating Class Hierarchies
ssn name lot
Employees

hours_worked contractid
Manages
hourly_wages Hourly_Emps Contact_Emps

two basic approaches to handling ISA hierarchies

1- Create a distinct relation to each entity set participating in
the IS hierarchy and each attribute of the entity set becomes
an attribute of the corresponding relation. Also the primary
key of the superclass is added to each subclass as primary
key for the subclass in the same time it is a foreign key. Note
that if the superclass tuple is deleted, the delete must be
cascaded to the subclasses.
ssn name lot
Employees

hours_worked Manages contractid

hourly_wages Hourly_Emps Contact_Emps
Employees (ssn, name, lot),
Hourly_Emps( ssn, hourly_wages , hours_worked ),
Contact_Emps( ssn , contactid).
2- Create a distinct relation to each subclass participating in
the IS hierarchy and each attribute of the subclass becomes
an attribute of the corresponding relation plus the attributes
of the superclass.
ssn name lot
Employees

hours_worked Manages contractid

hourly_wages Hourly_Emps Contact_Emps

Hourly_Emps(ssn, hourly_wages, hours_worked, name, lot ),

Contact_Emps( ssn , contacted , name , lot).

The first approach is general and always applicable.

3.5.7 Translating ER Diagrams with Aggregation
since
Started_on pbudget did dname budget
pid Projects Sponsors Departments

Monitors until

name Employees ssn

lot
Projects(pid, started_on, pbudget),
Employees(ssn, sname, lot),
Departments( did , dname , budget).
Sponsors( pid, did, since).
Monitors( ssn , pid , did , until).
3.5.8 ER to Relational: Additional Examples
ssn name lot pname age
Employees Dependents

Purchaser Beneficiary

Policy
policyid cost
CREAT TABLE Policies (policyid INTEGER
ssn CHAR(11) NOT NULL,
cost REAL,
PRIMARY KEY (policyid),
FOREIGN KEY (ssn) REFERENCES Employees,
ON DELETE CASCADE)
 ssn name lot pname age
Employees Dependents

Purchaser Beneficiary

Policy
policyid cost
CREAT TABLE Dependents (pname CHAR(20)
age INTEGERE,
policyid INTEGER,
PRIMARY KEY (pname,policyid)
FOREIGN KEY (policyid) REFERENCES Policies
ON DELETE CASCADE )
3.6 INTRODUCTION TO VIEWS
A view is a table whose rows are not explicitly stored in the
database but are computed as needed from a view
definition.

Ex.: Consider the Students and Enrolled relations. Suppose

we are often interested in finding the names and student
identifiers of students who got a grade of B in some course,
together with the course identifier. we can define a view for
this purpose. Using SQL notation:

CREATE VIEW B-Students (name, sid, course)

AS SELECT S.name, S.sid, E.cid
FROM Students S, Enrolled E
WHERE S.sid=E.sid AND E.grade=’B’
CREATE VIEW B-Students (name, sid, course)
AS SELECT S.name, S.sid, E.cid
FROM Students S, Enrolled E
WHERE S.sid=E.sid AND E.grade=’B’

whenever B-Students is used in a query, the view

definition is first evaluated to obtain the corresponding
instance of B-Students, then the rest of the query is
evaluated treating B-Students like any other relation
referred to in the query.
3.6.1 Views, Data Independence, Security
The view mechanism provides the support for logical data
independence in the relational model. That is, it can be used
to define relations in the external schema that mask
changes in the conceptual schema of the database from
applications.

Views are also valuable in the context of security: We can

define views that give a group of users access to just the
information they are allowed to see.
3.6.2 Updates on Views
The motivation behind the view mechanism is to tailor how
users see the data.
a view can be used just like any other relation in defining a
query.

update is the distinction between a view and a base table.

The SQL-92 standard allows updates to be specified only on

views that are defined on a single base table using just
selection and projection.

Updating a view can always be implemented by updating

the underlying base table.
Ex.:
CREATE VIEW GoodStudents (sid, gpa)
AS SELECT S.sid, S.gpa
FROM Students S
WHERE S.gpa> 3.0