National University of Modern

Languages - NUML
(Department of Computer Science)

Mr. Muhammad Nouman Farooq

BSC-H (Computer Science)
MS (Telecomm. and Networks)

Honors:
Magna Cumm Laude Honors Degree
Gold Medalist!

Official E-Mail: nouman.farooq@numl.edu.pk

Personal Email: noman.iefr@hotmail.com
Introduction to Database Systems

Logical Database Design &

Modeling
Lecture# 5
 Lecture 5: Logical Database Design & Modeling

Relational Data Structure

Constraints & Integrity Constraints

Well Structured Relation

Transforming/Mapping ENTITIES into Relations (Tables)

Transforming/Mapping Weak ENTITIES into Relation

(Tables)

3
 Continued…

Transforming/Mapping Unary Relationship into Relations (Tables)

Transforming/Mapping Binary Relationship into Relations (Tables)

Transforming/Mapping Ternary Relationship into Relations (Tables)

Case Study

 Transformation/Mapping of Database Design Phase (ERD) of Lab 1

into Relations

 Lab Activity 2 – SQL Syntax, Keywords, DDL Commands

4
 Relational Data Structure

5
Relational Data Structure

6
Continued…

7
Rows or Record or Tuples or Instances of an
ENTITY
 A record contains all the information about a single ‘member’
of a table.

 It is a collection of attributes values.

 Records are also known as tuples.

8
 Relation (Table)
A relation is a named, two-dimensional table of data. A Table
consists of rows (tuples or records) and columns (attributes or fields)

Requirements for a table to qualify as a Relation:

 Table must have a Unique Name in same Database

 Primary Key must be assigned; each record must be uniquely identified
 There are no repeating groups: two columns do not store similar information
in the same table
 Every attribute value must be atomic (no multivalued attributes are
allowed)
 Every Record in row must store unique values (can’t have two rows with
exactly the same values against all their fields/columns)
 Attributes (columns) in tables must have unique names
 The order of the columns can be irrelevant/un-ordered
 The order of the rows can be irrelevant/un-ordered

NOTE: all Relations/Tables must be in 1st Normal form 9

 Continued…

Not in a Relation but Why?

10
 Continued…

In A Relation.. Why?

11
 Continued…
Correspondence with E-R Model
 Relations/File (Tables) relates with ENTITY types in ERD

 Tupples/Records/Instance of Data (Data in Rows) relates with

ENTITY Instances in ERD

 Fields/Labels (Columns) relates with Attributes in ERD

 NOTE: The word relation is termed as Table in Relational

Database and is NOT the same as the word relationship in E-R
Model which is ENTITY to ENTITY relationship/connection
(Type of Relationship)

12
Continued…
Key Fields
 Keys are special fields that serve two main purposes:

 Primary keys are Unique Identifiers of the relation (table) with

not null constraint/check/limitation. Examples include person
Cnic Number. This is how we can guarantee that all rows
(tuples/record) are unique and having some value against the
attribute.
 Foreign keys are attribute in a relation (table) of a database
that serves in a child relation (table) connecting parent relation
(table) in the same database.

 Keys can be simple (a single field) or composite (more than one

fields)
 Keys usually are used as Indexes to speed up the response to user
queries
13
Continued…

Primary Key
Foreign Key
(implements 1:N relationship
between customer and order)

Combined, these are a composite primary key

(uniquely identifies the order line)…
individually they are foreign keys (implement
M:N relationship between order and product)

14
15
 Constraints

16
 Constraints/Limitations/Check/Restrictions

 Constraints/Limitations are the rules enforced on data columns on

table.

 These are used to limit the type of data that can go into a table.

 This ensures the accuracy and reliability of the data in the database.

17
 Type of Constraints

 NOT NULL Constraint: Ensures that a column cannot have NULL value.

 DEFAULT Constraint: Provides a default value for a column when none is

specified.

 PRIMARY Key: Uniquely identified each rows/records in a database table.

 CHECK Constraint: The CHECK constraint ensures that all values in a column
satisfy certain conditions.

18
 Integrity Constraints

19
  Integrity
Types Constraints
of Integrity Constraints:

1) Domain Constraints:

 Allowable values for an Attribute (Data Type of a Label/Column/Attribute).

See Table 5-1 on next slide.

2) Entity Integrity:

 No primary key attribute have null value. All primary key fields must contain
Unique data.

20
Continued…

21
Domain definition Enforces Domain Integrity Constraints
 Continued…
3) Referential Integrity:
This rule states that any foreign key value (on the
relation/table of the many side) MUST match a primary key value in the
relation/table of the one side in one_to_many type of relationship.
(Foreign key may store a null value but not Primary key)
 For example: Update/Delete/Restrict Rules
 Restrict: don’t allow update or delete of parent side records
(P.K) if related records that exists in dependent side/child table
(F.K)
 Cascade: automatically update or delete dependent side/child
table records (F.K) that relates with the parent side records (P.K)
 Set-to-Null: the foreign key (F.K) in the dependent side set to
null if deleting from the parent side (P.K).
Example:
EMPLOYEE to PARKING_PLACE (one_to_one type of relationship in
slide no. 52) 22
23
24
SQL table definitions

Referential
integrity
constraints are
implemented with
foreign key to
primary key
references

25
26
27
 Well Structured Relation

28
Well Structured Relation

29
1. Insertion Anomaly/Irregularity/Inconsistency : Suppose that
we need to add a new employee to the table shown in next
slide. The primary key for this relation is the combination of
Emp_ID and Course_Title. Therefore, to insert a new record,
the user must supply values for both Emp_ID and Course_Title
(because primary key values cannot be null or nonexistent).
This is an anomaly. because the user should not be able to
enter only employee data without supplying course data.

30
Example of an Insertion, Deletion & Modification
Anomaly/Irregularity/Inconsistency

31
 Solution to Remove Anomalies in a Relation via Database Design Phase :-

EMPLOYEE_to_COURSE :-
An EMPLOYEE must studies at least/more than
one COURSE’s. A COURSE must be studied by exactly one EMPLOYEE.
(ONE_to_MANY type of Relationship)
EMPLOYEE_to_DEPARTMENT :-
An EMPLOYEE must do his/her job in at most one
DEPARTMENT. In a DEPARTMENT at most one EMPLOYEE must do his/her
job (ONE_to_ONE type of Relationship)

Important Note:
All the Relationships are made as per given/provided
Record/Instance/Tuples in a Relation on slide no. 31
32
EMPLOYEE_to_COURSE :-
An EMPLOYEE must studies at least/more than
one COURSE’s. A COURSE must be studied by exactly one EMPLOYEE.
(ONE_to_MANY type of Relationship)

33
Transformation/Mapping of One_to_Many type of Relationship
from Conceptual Data Model into Logical Data Model:

34
EMPLOYEE_to_DEPARTMENT :-
An EMPLOYEE must do his/her job in at most one
DEPARTMENT. In a DEPARTMENT at most one EMPLOYEE must do his/her
job (ONE_to_ONE type of Relationship)

35
Transformation/Mapping of One_to_One type of Relationship
from Conceptual Data Model into Logical Data Model:

36
37
 Transforming/Mapping ENTITIES into
Relations (Tables)

38
 Transforming/Mapping ENTITIES into Relations
(Tables)

Mapping Regular Entities to Relations

1. Simple Attributes: E-R attributes map directly onto the

relation

2. Composite Attributes: Use only their simple, component

attributes

3. Multivalued Attribute: Becomes a separate relation with a

foreign key taken from the superior entity

39
Continued…

Mapping a Regular Entity

(a) CUSTOMER
entity type with
simple attributes

(b) CUSTOMER Relation

40
Continued…

Mapping a Composite Attribute

(a) CUSTOMER entity type with composite attribute

(b) CUSTOMER relation with address detail

41
42
Continued…

43
Removing Multivalued Attributes from Tables

44
Continued…

Mapping an Entity with a Multivalued Attribute

(a)

Multivalued attribute becomes a separate relation with foreign key

(b)

One–to–Many relationship between original entity and new relation

46
47
48
empId and skillId can act as a
Composite Primary Key

49
 Transforming/Mapping Weak ENTITIES
into Relation (Tables)

50
Mapping Weak Entities into Relation
(Tables)

 Becomes a separate relation with a foreign key taken from the

superior entity

 Primary Key composed of:

 Primary Key of identifying relation (Strong Entity)

51
 Continued…

Example of Mapping a Weak Entity

a) Weak Entity (Dependent ENTITY)

52
Continued…

Example of mapping a Weak ENTITY (cont.)

b) Relations resulting from Weak ENTITY

NOTE: the domain

constraint for the foreign key
should NOT allow null value
if DEPENDENT is a weak
entity

Foreign key

Cumbersome Key (more than two Composite Primary Keys)

53
Strong and Weak Entity Type Symbol of
Representation

54
 Transforming/Mapping Unary
Relationship into Relations (Tables)

55
 Transforming/Mapping Unary Relationship into
Relations (Tables)

 One-to-Many–Recursive foreign key in the same relation

 Many-to-Many–Two relations:
 One for the entity type

 One for an associative relation in which the primary key has

two attributes, both taken from the primary key of the entity

56
Continued…

Mapping a unary 1:N relationship

(a) EMPLOYEE entity with

unary relationship

(b) EMPLOYEE
relation with
recursive foreign
key

57
58
Continued…

Mapping a unary M:N relationship

(a) Bill-of-materials
relationships (M:N)

(b) ITEM and

COMPONENT
relations

59
 Transforming/Mapping Binary Relationship into
Relations (Tables)

60
Transforming/Mapping Binary Relationship into
Relations (Tables)

One-to-Many:
Primary key on the one side becomes a foreign key on
the many side

Many-to-Many:
Create a new relation named as Associative/Junction
Table with the primary keys of the two entities as its primary
key in Binary Degree of Relationship

One-to-One:
Primary key on the Strong/Independent side becomes a
foreign key on the Weak/Dependent side
61
Continued…

Example of Mapping a 1:M relationship

a) Relationship between CUSTOMER and ORDER

b) Mapping the relationship

62
 Continued…
Example of mapping an M:N relationship
a) Completes relationship (M:N)

The Completes name of relationship will need to become a separate relation

63
Continued…

Example of mapping an M:N relationship (cont.)

b) Three resulting relations

Composite Primary Key

Foreign Key New

Foreign Key intersection
relation

64
Strong and Weak Entity Type Symbol of
Representation

65
Continued…

Example of mapping a binary 1:1 relationship

a) In_charge relationship (1:1)

Often in 1:1 relationships, one direction is Strong/Independent.

66
Continued…

Example of mapping a binary 1:1 relationship (cont.)

b) Resulting relations

Foreign key goes in the relation on the dependent side,

Matching the primary key on the independent side

67
 Transforming/Mapping Ternary Relationship
into Relations (Tables)

68
Transforming/Mapping Ternary Relationship into
Relations (Tables)

 One relation for each entity and one for the

Associative entity

 Associative/Junction entity has foreign keys to

each entity in the relationship

69
Continued…

Mapping a ternary relationship

a) PATIENT TREATMENT Ternary relationship with
associative entity

70
Continued…

Mapping a ternary relationship (cont.)

b) Mapping the ternary relationship PATIENT TREATMENT

Remember This is why But this makes a

that the treatment date very It would be better to create a
primary key and time are Cumbersome Surrogate Key like treatmentId
MUST be included in the Key… in PATIENT_TREATMENT
unique composite table
primary key 71
Continued…

Surrogate Key:
A Surrogate Key is any column or set of
columns that can be declared as the primary key instead of more
than two composite Primary keys that jointly makes a Cumbersome
key (CUMBERSOME meaning: Large Set).

Example of Cumbersome key and Surrogate key

is shown in last slide.
 Case Study

73
Case Study

 Odeon Cinema and other international cinemas have decided to

install a centralized database. This database should keep
information regarding cinemas including its name, address and
phone number. Each CINEMA must have one or more THEATERs and
each THEATER must have many number of SHOW_TIME. During
these SHOW_TIMEs in a particular THEATER; A particular MOVIE
must be shown to the general public.
Entities

 CINEMA

 THEATER

 SHOW_TIME

 MOVIE

75
Relationships as per Business Rule
 Each CINEMA must contain one or more THEATER and each
THEATER must belong to only and only one CINEMA.

 Each THEATER must have many number of SHOW_TIME. A particular

SHOW_TIME for a movie must belongs to only and only one
THEATER.

 A MOVIE may have many SHOW_TIME and a particular SHOW_TIME

must belongs to one MOVIE only.

76
Reasoning for Type of Relationships: -

77
Reasoning behind finding Type of Relationships with a Associative/Junction Table: -
cinemaPhoneNumber is a Multi-Valued attribute, so it must be transformed into new ENTITY
 Always check on instances of entity type; If the instance is
redundant/repeated in relational database in any of the two related
tables than it is not in a Well Structured Relation as per definition of
a Well Structured Relation.

 If all the instances are redundant in a table than we cannot assign

Primary Key against that table as per definition of Primary Key.

 We transform these entities type of relations to achieve the core

objective of Relational Database into:
One to Many (Foreign Key on MANY type of relation side).
One to One (Foreign Key on Weak/Dependent type of relation side).
Many to Many type of Relation is transformed by using
Associative/Junction Entity/Relation and making a Surrogate Key
instead of Cumbersome Key in Associative/Junction Entity/Relation.

81
Lab Activity 2 – SQL Syntax, Keywords,
DDL Commands

82
Lab Activity 2 – SQL Syntax, Keywords, DDL Commands

Lab Activity from:

Lab Activities from Laboratory Manual (A Guide to

MySQL) prepared by Muhammad Nouman Farooq (Page
No. 7-15)

83
 Transformation/Mapping of Database Design
Phase (ERD) of Lab 1 into Relations

84
Transformation/Mapping of Database Design Phase
(ERD) of Lab 1 into Relations

Lab Activity from:

Lab Activities from Laboratory Manual (A Guide to

MySQL) prepared by Muhammad Nouman Farooq (Page
No. 3-6)

85
 Recommended Readings

Chapter 5 from:

Modern Database Management by Jeffrey A. Hoffer, Mary B.

Prescott & Fred R. McFadden, 8th Edition (Page No. 220-272)

Lab Activities from:

Lab Activities from Laboratory Manual (A Guide to MySQL)

prepared by Muhammad Nouman Farooq (Page No. 3-15)

86
 Summary of Lecture
➦ Lecture 5

 Relational Data Structure

 Constraints & Integrity Constraints

 Well Structured Relation

 Transforming/Mapping ENTITIES into Relations (Tables)

 Transforming/Mapping Weak ENTITIES into Relation (Tables)

87
 Summary of Lecture (Continued…)
➦ Lecture 5

 Transforming/Mapping Unary Relationship into Relations (Tables)

 Transforming/Mapping Binary Relationship into Relations (Tables)

 Transforming/Mapping Ternary Relationship into Relations (Tables)

 Case Study

 Transformation/Mapping of Database Design Phase (ERD) of Lab 1 into

Relations

 Lab Activity 2 – SQL Syntax, Keywords, DDL Commands

88
 END OF LECTURE 5

89