Download The Relational Model

The Relational Model
May Aldoayan
 How
to derive a set of relations from a
conceptual data model.
 To create relations for the logical data model to
represent the entities, relationships, and
attributes that have been identified.
Pearson Education © 2009
2
Simple 
uses the concept of a mathematical relation 
Oracle 
SQLServer and Acces 
the SQL query language, which is the standard for
commercial relational DBMSs.
May Aldoayan

Relational Data structure
Attributes
Figure 3.1
branchNo
Street
City
postcode
B005
22 Deer Rd
London
SW1 AEH
B007
16 Argyll St
Aberdeen
AB2 3SU
B003
163 Main St
Glasgow
G11 9QX
B004
32 Manse Rd
Bristol
BS99 1NZ
B002
56 Clover Dr
London
NW10 6EU
Degree
Primary Key
Cardinality
Relation
Branch
Foreign Key
Relation
Staff
StaffNo
fName
LName
Position
Sex
DOB
Salary
branchNo
SL21
John
White
Manager
M
1-Oct-45
30000
B005
SG37
Ann
Beech
Assistant
F
10-Nov-60
12000
B003
SG14
David
Ford
Supervisor
M
24-Mar-58
18000
B003
SA9
Mary
Howe
Assistant
F
19-Feb-70
9000
B007
SG5
Susan
Brand
Manager
F
3-Jun-40
24000
B003
SL41
Julie
Lee
Assistant
F
9000
B005
13-Jun-63
May Aldoayan
Relational Data structure

Relation: A relation is a table with columns and rows.

In the relational model, relations are used to hold information
about the object to be represented in the database.

Attribute: An attribute is a named column of a relation.

Attribute can appear in any order and the relation will still be the
same relation, and therefore convey the same meaning
May Aldoayan
Relational Data structure


Domain : A domain is the set of allowable values for one or more attributes.
A domain D is a set of atomic values.

KSA_phone_numbers. The set of ten-digit phone numbers valid in the Saudi
Arabia.

Names: The set of character strings that represent names of persons.
Grade_point_averages. Possible values of computed grade point averages; each must be a
real (floating-point) number between 0 and 4.


Domains may be distinct for each attribute, or two or more attributes may
be defined on the same domain.

Tuple: A tuple is a row of a relation.

The elements of a relation are the rows or tuples in the table.
May Aldoayan
Relational Data structure

Degree: The degree of a relation is the number of attributes it
contains.

In figure 3.1, The Branch relation has four attributes or degree four.
This means that each row of the table is a four-tuple, containing four
values.

A relation with only one attribute would have degree one and be
called unary relation or one-tuple.

A relation with two attribute is called binary, one with three attribute
is called ternary
May Aldoayan
Relational Data structure

Cardinality: The cardinality of a relation is the number of tuples it contain.

Relational database: A collection of normalized relation with distinct relation
name .
Database relations:

Relation schema: A named relation defined by a set of attribute and domain name
pairs. R(A1, A2, ..., An)

Each attribute Ai is the name of a role played by some domain D in the relation schema R

STUDENT(Name, Ssn, Home_phone, Address, Office_phone, Age, Gpa)

Relational database schema: A set of relation schema, each with a distinct name.
If R1, R2, .., Rn are a set of relation schemas, then relational schema R is:
R= {R1, R2, .., Rn}
May Aldoayan
Properties of relations







The relation has a name that is distinct from all other
relation names in the relational schema.
Each cell of the relation contains exactly single value
Each attribute has a distinct name
The values of an attribute are all of the same domain
Each tuple is distinct.There are no duplicate tuples
The order of attributes has no significance
the order of tuples has no significance; theoretically
May Aldoayan
Relational Keys

Primary Key: The candidate key that is selected to identify tuples
uniquely within the relation.

Foreign Key : is an attribute, or set of attributes, within one
relation that matches the CK of some relation. Used to represent
relationship between tuples of two relations.
May Aldoayan
Relation Schema
Student
StudentNo
FName
LName
DOB
GPA
Dept
431671078
Maha
Alsaleh
15-1-1993
4.03
D001
430670028
Reem
AlAhmed
5-6-1992
3.90
D001
431679802
Sara
AlQahtani
3-7-1993
3.50
D002
432784900
Suha
Alotaibi
10-10-1994
4.50
D002
430453772
Lamea
AlMutairi
12-3-1992
4.89
D003
STUDENT (StudentNo, Lname, Fname, DOB, GPA, Dept)
Department
DeptNo
Name Department
Location
D001
Computer Science
Build# 1
Doo2
Business Administrator
Build# 3
D003
Science
Build # 6
DEPARTMENT (DeptNo, Department Name,May
Location)
Aldoayan
Derive relations for logical data model

(1) Strong entity types
– For each strong entity in the data model, create a relation that
includes all the simple attributes of that entity. For composite
attributes, include only the constituent simple attributes.
(2) Weak entity types
– For each weak entity in the data model, create a relation that
includes all the simple attributes of that entity.
– A weak entity must include its Partial key and its owner entity
type PK as a FK. The combination of the two keys form the PK
of the weak entity.
Pearson Education © 2009
12
Example
Employee
Emp_NO{PK}
Name
Fname
Mname
Lname
Sex
Partial Key of
Salary
Week entity
Dep NO
Dependent
1..1
Dependents of
0..*
Name
Sex
Relationship
Employee (Emp_NO, Fname,Mname ,Lname, Sex, Salary)
Primary Key Emp_NO
DEPENDENT (DepNo, EmpNo, Name, Sex, Relationship )
Primary Key DepNo, EmpNo
Foreign Key EMpNo refrences Employee (Emp_NO)
Pearson Education © 2009
13
1:1 Relationship  Relational Model
Identify an entity type (S) (preferably total participator)
 Include the PK of the other entity (T) as a FK in S
 Add attributes that describes the relationship.
LName
FName
EmpNo
Name
BrnNo
DOB
1
1
EMPLOYEE


(0,1)
manage
(1,1)
EMPLOYEE(EmpNo, Lname, Fname, DOB)
BRANCH(BrnNo, Name, EmpNo)
May Aldoayan
BRANCH
1:M Relationship  Relational Model
Identify a participating entity type (S) on the m-side
 Include the PK of the other entity type (T) as a FK in S
if S is at “M-side” of relationship type then include primary key of T in S
 Add attributes that describes the relationship

LName
StafNo
FName
Name
Address
DOB
M
1
Staff


(0,*)
PropertyNo
Oversees
(1,1)
STAFF (StaffNo, Lname, Fname, DOB)
PropertForRent(ProertyNo, Address, StaffNo)
May Aldoayan
ProperyForRent
M:N Relationship  Relational Model
Create a new relation R to represent the relationship
 Include the PK of participating entity types (T & S) as FK in R. The
combination of the two FK will form the PK of R
 Add attributes that describes the relationship

EmpNo
Fname
LName
Employee



DOB
M
Name
hours
N
Work-on
Peoject
EMPLOYEE(StaffNo, Lname, Fname, DOB)
Project(ProjNo, Name)
Work-on(EmpNo, ProjNo , hours)
May Aldoayan
ProjNo
n-ary Relationship  Relational
Model
 Create a new relation R to represent the relationship
 Include
the PK of the participating entities as FK in R. The combination
of all FK form the PK of R.
 Add attributes that describes the relationship
StartD
BizNo
BUSINESS
LawNo
EndD
contract
SupNo
SUPPLIER
Lawyer
BUSINESS(BizNo)
LAWYER(LawNo)
SUPPLIER(SupNo)
May Aldoayan
contract(BizNo, SupNo, LawNo, StartDate,
EndDate)
Composite Attribute Relational Model

Include its simple components in the relation
LName
initial
FName
name
DOB
emp_no
EMPLOYEE

EMPLOYEE(EmpNo, Fname, initial, Lname, DOB)
May Aldoayan
Multi Valued Attribute Relational Model
Suppose A is a relation that contains the multi valued attribute
 Create a relation R to represent the attribute
 Include the PK of A as FK in R
The
PK of R is the combination of the PK of A (FK) & the multivalued
attribute
DOB
EmpNo
Tel_no
EMPLOYEE
EMPLOYEE(EmpNo, DOB)
TELEPHONE(EmpNo, tel_no)
May Aldoayan
EER Relational Model Mandatory/NonDisjoint
Suppose
specialization with subclasses (S1, S2, .., Sm} & a
superclass C
 Create a relation L to represent C with PK & attributes
 Include the unshared
attributes for each subclass Si, 1 i  m
 Add discriminator to distinguish the type of each tuple
May Aldoayan
EER Relational Model
Mandatory/NonDisjoint
EmpNo
Fname
Salary
LName
DOB
EMPLOYEE
o
Typing
Speed
SECRETARY
TECHNICIAN
ENGINEER
EngType
TGrade
EMPLOYEE(EmpNo, Fname, Lname, DOB,Salary,TypingSpeed,TGrade,
EngType, Secretary Flag, Technician Flag, Engineer Flag)
May Aldoayan
EER Relational Model
Mandatory/Disjoint
Suppose
specialization with subclasses (S1, S2, .., Sm} & a
superclass C.
a relation Li, 1 i  m, to represent each combination
of super/subclass
 Create
May Aldoayan
EER Relational Model
Mandatory/Disjoint
EmpNo
Fname
Salary
LName
EMPLOYEE
DOB
d
Typing
Speed
SECRETARY
TECHNICIAN
ENGINEER
EngType
TGrade
SECRETARY(EmpNo, Fname, Lname, DOB, Salary,TypingSpeed)
TECHNICIAN(EmpNo, Fname, Lname, DOB, Salary,Tgrade)
ENGINEER(EmpNo, Fname, Lname, DOB, Salary, EngType)
May Aldoayan
EER Relational Model
Optional/NonDisjoint
 Suppose
specialization with subclasses (S1, S2, .., Sm} & a
superclass C
 Create a relation L to represent C with PK & attributes
 Create a relation Li to represent each subclass Si, 1 i  m
May Aldoayan
EER Relational Model
Optional/NonDisjoint
EmpNo
Fname
Salary
LName
EMPLOYEE
DOB
o
Typing
Speed
SECRETARY
TECHNICIAN
ENGINEER
TGrade
EMPLOYEE(EmpNo, Fname, Lname, DOB, Salary)
SUB-EMP(EmpNo, TypingSpeed,TGrade, EngType,
Secretary Flag, Technician Flag, Engineer Flag)
May Aldoayan
EngType
EER Relational Model Optional/Disjoint
 Suppose
specialization with subclasses (S1, S2, .., Sm} & a
superclass C
 Create a relation L1 to represent C with PK & attributes
 Create a relation L2 to represent all subclasses Si, 1 i  m
 Add discriminator to distinguish the type of each tuple
May Aldoayan
EER Relational Model Optional/Disjoint
EmpNo
Fname
Salary
LName
DOB
EMPLOYEE
d
Typing
Speed
SECRETARY
TECHNICIAN
ENGINEER
TGrade
EMPLOYEE(EmpNo, Fname, Lname, DOB, Salary)
SECRETARY(EmpNo, TypingSpeed)
TECHNICIAN(EmpNo, Tgrade)
ENGINEER(EmoNo, EngType)
May Aldoayan
EngType
Guidelines for representation of
superclass / subclass relationship
28
Pearson Education © 2009
E/R  Relational Model
E/R Model
Relational Model
Entity Type
Relational
1:1 or 1:M Relationship Type
FK or relation
M:N Relationship Type
Relation & 2 FK
n-ary Relationship Type
Relation & n FK
Simple attribute
Attribute
Composite attribute
Simple component attribute
Multivalued attribute
Relation and FK
Value set
Domain
Key attribute
PK
May Aldoayan
Entity Integrity

The first integrity rule applies to the primary Keys of base
relations.
Entity integrity :
In a base relation, no attribute of a primary key can be null

May Aldoayan
Integrity Constraints
 Null
– Represents value for an attribute that is
currently unknown or not applicable for tuple.
– Deals with incomplete or exceptional data.
– Represents the absence of a value and is not the
same as zero or spaces, which are values.
Pearson Education © 2009
31
Integrity Constraints
 General
Constraints
– Additional rules specified by users or
database administrators that define or
constrain some aspect of the enterprise.
Pearson Education © 2009
32
Relational Integrity
The second integrity rule applies to foreign key.
Referential Integrity: If a foreign key exists in a relation, either
the foreign key value must match a candidate key value of some
tuple in its home relation or the foreign key value must be wholly
null.
Enterprise constraints: Additional rules specified by the users
or DBA of the DB.
based on the ways an organization perceives and uses its data
(e.g. number of staff working in a branch is at most 20)
May Aldoayan
Views
Base relation is a named relation corresponding to an entity in
the conceptual schema, whose tuples are physically stored in the
DB
View is a derived relation. Virtual, may not exist, but dynamically
derived from one or more base relations.
The only information about a view that is stored in the database is
its structure.
The external model can consist of both conceptual level relations
(base relations) and derived views.
May Aldoayan
Views
STUDENT
StudentNo
FName
LName
DOB
GPA
Dept
431671078
Maha
Alsaleh
15-1-1993
4.03
D001
Reem
AlAhmed
5-6-1992
3.90
D001
431679802
Sara
AlQahtani
3-7-1993
3.50
D002
432784900
Suha
Alotaibi
10-10-1994
4.50
D002
430453772
Lamea
AlMutairi
12-3-1992
4.89
D003
Base
430670028
Relation
STUDENT_GPA
View
StudentNo
GPA
431671078
4.03
430670028
3.90
431679802
3.50
432784900
4.50
430453772
4.89
May Aldoayan
Purpose of Views
It
provides a powerful and flexible security mechanism by
hiding parts of the DB from certain users.
 It
permits users to access data in a way that is customized to
their needs, so that the same data can be seen by different
users in different ways, at the same time.
 It
can simplify complex operations. It allow you to work
with data from different tables simultaneously.
 Supports
logical data independence
May Aldoayan
Updating Views
All updates to a base relation should be immediately reflected
in all views that reference that base relation.
All updates to a view should be reflected in the underlying
base relation, under the following rules:
 Updates are allowed through a view defined using a simple
query involving a single base relation & containing either the
PK or a CK of the base relation
Update are NOT allowed through views involving multiple
base relations
Updates are not allowed through views involving aggregation
or grouping operations
May Aldoayan
May Aldoayan