the relational model

1. 6 September 2019 1
Lesson 03
The Relational Model

2. 6 September 2019 2
 Relational Databases
 represent data as a collection of tables
 each row in a table represents a collection of related values
Example
S# SNAME STATUS CITY
S1 Smith 20 London
S2 Jones 10 Paris
S3 Blake 30 Paris
S4 Clark 20 London
S5 Adams 30 Athens
Supplier S

3. 6 September 2019 S M Irteza / Dr Rafi Ullah 3
Relational Model
 Why is it called relational?
 a table is similar to the concept of a relation in mathematics

4. 6 September 2019 S M Irteza / Dr Rafi Ullah 4
Relation
 Set/Subset
Examples of sets
D1 = {blue; yellow; white} and D2 ={ 1 , 2 }
 Tuple
Examples of tuples
– order of the elements within the tuple is important
< blue, blue > and < yellow, 1 , Paris >

5. 6 September 2019 5
Relation
 Consider D1 = {blue; yellow; white} and D2 = {1; 2}
Cartesian Product
 The set of all (binary) tuples such that the first argument
belongs to D1 and the second argument belongs to D2 is
denoted D1xD2.
 A relation on D1xD2 is a collection of tuples < x, y > where all x’s
are taken from D1 and all y’s are taken from D2.
 In other words, a relation on D1xD2 is a subset of D1xD2.

6. 6 September 2019 6
 Example:
D1 = {blue, yellow, white} and D2 = { 1 , 2}
D1xD2
{ < blue, 1 >,< blue, 2 >,
< yellow, 1 >,< yellow, 2 >,
< white, 1 >,< white, 2 > }

7. 6 September 2019 7
Relational Model
 Association between tables and relations
 Rows in a table are associated with the tuples in the relation
 Columns in a table are associated with the arguments in the
tuples
 The columns are usually called attributes
 Number of attributes = degree of the relation

8. 6 September 2019 8
Relational Model
Concepts carried over
 The sets of the relations are called domains in the relational model
 Domains define all possible values in the columns in the table
Less obvious implications to the model
 Tuples are unordered
 Location of the attributes within the relation is irrelevant
 but the position of the values in the tuple should match their logical
meaning
 Because a relation is a set of tuples, there are no duplicates
 tuples can always be uniquely identified

9. 6 September 2019 9
Important Dissimilarity
 Domains are required to be atomic
 In other words, elements of the domain are indivisible units

10. 6 September 2019 10
Relational Model – Quick Recap
 Tables (relations)
 Rows (tuples)
 Columns (attributes)
 Unordered tuples
 Atomic attributes
 No duplicate tuples
 Domains

11. 6 September 2019 11
Relational Data Structure
 Table is the Data Structure for relational model
 Relation = Table
 name of this relation is S.
 Tuple = Row
 This relation has 5 tuples
 Each tuple represents a record of one supplier, so tuples
are seldom called records also.
S# SNAME STATUS CITY
S1 Smith 20 London
S2 Jones 10 Paris
S3 Blake 30 Paris
S4 Clark 20 London
S5 Adams 30 Athens
Supplier S

12. 6 September 2019 12
Relational Data Structure
 Cardinality = # of rows with data in the relation
 so for S, cardinality = 5.
 Attribute = Columns or fields.
 Degree = # of columns or fields of a relation.
 The relation S has a degree of 4.
S# SNAME STATUS CITY
S1 Smith 20 London
S2 Jones 10 Paris
S3 Blake 30 Paris
S4 Clark 20 London
S5 Adams 30 Athens
Supplier S

13. 6 September 2019 13
Relational Data Structure
 Domain = A pool of legal values
 For example:
 For S# we have S followed by a positive number.
 For Year we might have a four digit positive number between
1000 and 2003.
 Primary Key = A unique identifier, used to identify one
specific record from among all other records.
S# SNAME STATUS CITY
S1 Smith 20 London
S2 Jones 10 Paris
S3 Blake 30 Paris
S4 Clark 20 London
S5 Adams 30 Athens
Supplier S

14. 6 September 2019 14
Relations
 A relation consists of 2 parts
 Heading:
 Consists of a fixed set of attributes or columns or fields.
 Defined through the DDL, and usually remains the
same.
 Body
 Consists of the tuples or rows or records.
 Time varying set, i.e., at different intervals of time
there may be different contents in the body of a
relation.

15. 6 September 2019 15
RELVARS
 In the book, a relation is usually referred to as a
relation variable, or simply called relvar
 Because a relation is not constant at all the given
time intervals.
 Values might be different.

16. 6 September 2019 16
2 Key Properties of Relations
 No Duplicate tuples
 In other words, not all fields are same
 All cells have a single value
 A relation which follows this rule is said to be in the
first normal form.

17. 6 September 2019 17
Why Normalize?
 A Normalized relation provides a
 Simpler structure
 Simpler procedures
 FIRST NORMAL FORM
 One cell has one value ONLY

18. 6 September 2019 18
Relational Integrity
 The ultimate purpose of a DB is to store
information about the real world.
 It is possible that some information submitted to
the DB does not correspond to any possible
configuration of the real world.
 negative salaries
 impossible dates: 30/02/1999
 negative quantities in stock, etc

19. 6 September 2019 19
Relational Integrity Rules
- To prevent invalid or illegal values from occurring in the
database we have some rules
 Specific Integrity Rules
 Apply to a specific database, I.e. years may not be
less than zero, and 0 < age < 200 .
 General Integrity Rules
 Apply to all the relational databases.
 Like no two same tuples etc.

20. 6 September 2019 20
Candidate Keys
 A relation might have more than one unique identifiers. We
simply choose one as our primary key.
 Attribute K (possibly composite) of relation R is a candidate
key for R , if it satisfies the following two properties.
 UNIQUENESS: no 2 tuples of relation R have the
same values of K.
 MINIMILITY: If K is composite then no subset of K
has the unique property.
- i.e. if you find any column that is unique, don’t add
any more column to the primary key, because this
column by itself is a suitable primary key

21. 6 September 2019 21
Candidate Keys
 Composite Key Example
 (S#, sname)
 (P#,S#)
 (pname, sname, address, S#)
 Atomic Key Example
 S#
 P#
 sname
 pname

22. 6 September 2019 22
Primary Keys and Alternate Keys
 A Unique Identifier.
 The primary key is chosen from a set of candidate
keys.
 The primary key is the candidate key chosen to be the
main key for the relation
 The other candidate keys are called alternate keys
 Not duplicable
 NULLS are not allowed in the primary key field.

23. 6 September 2019 23
Primary Keys
 In the relation/table primary key is “S#”
 As sname, status and city are assumed to be
repeatable or can be duplicate.
S# SNAME STATUS CITY
S1 Smith 20 London
S2 Jones 10 Paris
S3 Blake 30 Paris
S4 Clark 20 London
S5 Adams 30 Athens
Supplier S

24. 6 September 2019 24
Primary Keys
 The primary key in SP is (S#,
P#)
 It is composite, as there is no
single choice for P.K due to the
format of the table or data.
 So P.K = (S#, P#)
//composite P.K
 CAUTION:
 Do not be mistaken by seeing
the data at a time interval, in
the table and assuming your
primary keys.
S# P# QTY
S1 P1 300
S1 P2 200
S1 P3 400
S1 P4 200
S1 P5 100
S1 P6 100
S2 P1 300
S2 P2 400
S3 P2 200
S4 P2 200
S4 P4 300
S4 P5 400
Supplier & Parts SP

25. 6 September 2019 25
Foreign Keys
 A foreign key is an attribute of one
relation R2 whose values are required to
match those values of the primary key
of some relation R1.

26. Foreign Keys
 Foreign Keys are used to link data in
two relations. A set of attributes in
the first (referencing) relation is a
foreign key if its value always either:
 Matches a candidate key value in the
second (referenced) relation; or
 Is wholly NULL.
 This is called Referential Integrity
6 September 2019 26

27. Foreign Keys: Example
Department:
DID is a Candidate Key for the
Department relation. Each entry
has a unique value for DID
Employee:
DID is a Foreign Key in the Employee
relation– each Employee’s DID value is
either NULL, or matches an entry in
the Department relation. This links
each employee to (at most) one
Department
6 September 2019 27
DID DName
13 Marketing
14 Accounts
15 Personnel
EID EName DID
15 Yunus Sami 13
16 Mirza Barki 14
17 Malik Jahan 13
18 Jan Sher NULL

28. Foreign Keys: Example
Student:
{First, Last} is a Candidate Key
for the Student relation – no
entries have the same value for
both First and Last.
Enrolment:
{First, Last} is a Foreign Key in the
Enrolment relation - each {First, Last}
pair matches exactly one entry in the
Student relation.
6 September 2019 S M Irteza / Dr Rafi Ullah 28
ID First Last
S01 Ahmad Khan
S02 Athar Khalid
S03 Sameer Shahid
S04 Sameer Khan
First Last Course
Ahmad Khan CS101
Ahmad Khan CS222
Sameer Shahid CS101
Sameer Khan CS222

29. 6 September 2019 S M Irteza / Dr Rafi Ullah 29
Relational Integrity Rules
To prevent invalid or illegal values from occurring in the
database we have some rules
 Specific Integrity Rules
 Apply to a specific database, i.e., Years may not be
less than zero, and 0 < Age < 200 .
 General Integrity Rules
 Apply to all the relational databases.
 Like no two same tuples etc.

30. 6 September 2019 S M Irteza / Dr Rafi Ullah 30
General Integrity Rules
We have basically two general integrity
rules
1. Entity Integrity Rule.
2. Referential Integrity Rule.

31. 6 September 2019 S M Irteza / Dr Rafi Ullah 31
1: Entity Integrity Rule
 “No Component of the P.K of a relation is allowed to
accept NULLs”.
 NULL (null value) = unknown or missing value.
 Note that a NULL value is not zero, it is not infinity, or
negative, or FI value. It is simply non existent for the
system.
 P.K = (S#,NULL) is illegal.

32. 6 September 2019 S M Irteza / Dr Rafi Ullah 32
2: Referential Integrity Rule
 “The DB must not contain any unmatched foreign key values”.
 e.g., shipment should not have S6 which is not in the suppliers
table as a P.K
 Any state of the DB that doesn't satisfy the integrity rules is
ILLEGAL.
S# SNAME STATUS CITY
S1 Smith 20 London
S2 Jones 10 Paris
S3 Blake 30 Paris
S4 Clark 20 London
S5 Adams 30 Athens
Supplier S
P# PNAME COLOR WEIGHT CITY
P1 Nut Red 12 London
P2 Bolt Green 17 Paris
P3 Screw Blue 17 Rome
P4 Screw Red 14 London
P5 Cam Blue 12 Paris
P6 Cog Red 19 London
Parts P
S# P# QTY
S1 P1 300
S1 P2 200
S1 P3 400
S1 P4 200
S1 P5 100
S1 P6 100
S2 P1 300
S2 P2 400
S3 P2 200
S4 P2 200
S4 P4 300
S4 P5 400
Supplier & Parts SP

33. 6 September 2019 S M Irteza / Dr Rafi Ullah 33
How to Avoid Illegal States?
1. Simply reject any operation that would result in an
illegal state, for example:
 if we try to store “S5” in table S with an “S5” entry
existing, then the system should reject that.
2. Accept the operation but perform some additional
compensating operations in order to guarantee the
overall result is still in a legal state.
 E.g. to delete a supplier for which there exists some
shipments, lets say we try to delete “S3” from
supplier, so violation at shipment table occurs as
shipment had “S3” entry as a F.K.

34. 6 September 2019 S M Irteza / Dr Rafi Ullah 34
CASCADING
 to delete a supplier for which there exists some shipments,
lets say we try to delete “S3” from supplier, so violation at
shipment table occurs as shipment had “S3” entry as a F.K.
 So what we can do is called “CASCADING”.
 In which deletion process does the following
 Deletes all entries for “S3” from shipment.
 And then deletes the supplier “S3” from supplier table.
 Now no violation will occur.
 This is called cascading.

35. 6 September 2019 S M Irteza / Dr Rafi Ullah 35
End
END OF LESSON 03
(these slides were adapted from original slides of M Ali Shahid)