Logical Database Design and the

Relational Model
Module 4
 Objectives
 Definition of terms
 List properties of a relation
 Transform ER/EER diagrams to relations
 Define first, second, and third normal form
 Describe problems from merging relations
 Create tables with entity and relational
integrity constraints
 Use normalization to convert anomalous
tables to well-structured relations.
 The Physical Design Stage of SDLC

Project Identification
and Selection
Purpose – information requirements structure
Deliverable – detailed design specifications
Project Initiation
and Planning

Analysis

Logical
Logical Design
Design

Physical Design

Database activity –
Implementation
logical database design
Maintenance
 Logical Database Design
 Process of transforming the conceptual data
model into a logical data model.

 Relational data model – most commonly used

contemporary database application. Represents
data in the form of tables
 First introduced by E.F. Codd (1970)

 Normalization – process of designing a well-

structured relations.
 A. Relational Data model: Relation

 A named, two-dimensional table of data

 Consists of named columns and an arbitrary
number of rows.
 Attribute – is a named column of the relation.
 Record – row of the relation containing data
values for a single entity.
 Example of a relation

EMPLOYEE 1
Emp_ID Name Dept_Name Salary
100 Andy Garcia Marketing 48,000
140 Allen Beeton Accounting 52,000
110 Chris Lucero Info System 42,000
190 Lorenzo Davis Finance 55,000
150 Susan Martin Marketing 42,000

Records
Attributes
 6 Properties of a Relation
 Has a unique name.
 Every attribute value must be atomic (not
multivalued, not composite)
 Every row must be unique (no two rows in a
relation are identical).
 Attributes (columns) in tables must have
unique names
 Order of the columns must be irrelevant
 Order of the rows must be irrelevant
NOTE: all relations are in 1st Normal form
 Sample Table with Repeating groups
EMPLOYEE 1

Emp_ID Name Dept_Name Sal Course_ Date_

Title Comptd
100 Andy Garcia Marketing 48,000 SPSS 6/19/2006
Surveys 10/7/2007
140 Allen Beeton Accounting 52,000 Tax Acc 12/8/2007
110 Chris Lucero Info System 42,000 VB 1/12/2007
C++ 4/22/2007
190 Lorenzo Davis Finance 55,000
150 Susan Martin Marketing 42,000 SPSS 6/16/2008
 Removing Multivalued Attributes
EMPLOYEE 2

Emp_ID Name Dept_Name Sal Course_ Date_

Title Comptd
100 Andy Garcia Marketing 48,000 SPSS 6/19/2006

100 Andy Garcia Marketing 48,000 Surveys 10/7/2007

140 Allen Beeton Accounting 52,000 Tax Acc 12/8/2007

110 Chris Lucero Info System 42,000 VB 1/12/2007

110 Chris Lucero Info System 42,000 C++ 4/22/2007

190 Lorenzo Davis Finance 55,000

150 Susan Martin Marketing 42,000 SPSS 6/16/2008

 Relation and E-R Model
 Relations (tables) refers to entity types and
many-to-many relationship types.
 Rows – refers to entity instances and many-to-many
relationship instances.
 Columns – refers to attributes.

 NOTE: The word relation (in relational

database) is NOT the same as the word
relationship (in E-R model)
 Key Fields
 Keys are special fields that serve two main
purposes:
 Primary keys are unique identifiers of the relation in
question.
 Foreign keys are identifiers that enable a dependent
relation (on the many side of a relationship) to refer to
its parent relation (on the one side of the relationship)
 Keys can be simple (single field) or composite
(more than one field)
 Keys usually are used as indexes to speed up the
response to user queries.
Schema for 4 relations

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)
 Integrity Constraints

 Facilitates maintaining the accuracy and

integrity of data in the database.
 Domain Constraints
 Allowable values for an attribute.
 Entity Integrity
 No primary key attribute may be null. All primary
key fields MUST have data
 Referential Integrity
 Consistency among the rows of two relations
Domain definitions enforce domain integrity constraints
 Integrity Constraints
 Referential Integrity – rule stating that any foreign
key value (on the relation of the many side) MUST
match a primary key value in the relation of the one
side. (Or the foreign key can be null)
 For example: Delete Rules
 Restrict – don’t allow delete of “parent” side if related
rows exist in “dependent” side
 Cascade – automatically delete “dependent” side rows
that correspond with the “parent” side row to be
deleted
 Set-to-Null – set the foreign key in the dependent
side to null if deleting from the parent side (not
allowed for weak entities)
Referential integrity constraints

Referential
integrity
constraints are
drawn via arrows
from dependent to
parent table
 Referential
integrity
constraints are
implemented
with foreign key
to primary key
references
 Well structured Relations
 Relation containing minimal redundancy and
allows users to insert, modify, and delete the
rows in a table without error or
inconsistencies.
 Anomaly – an error or inconsistency that may
result when a user attempts to update a table
that contains redundant data.
 Types of Anomalies
 Insertion Anomaly
 Deletion Anomaly

 Modification Anomaly
 Sample table showing types of
Anomalies
(Not a well structured relation)
Emp_ID Name Dept._Name Salary Course_title Date_Completed

100 Juan Cruz Marketing 28,000 SPSS 6/19/2000

100 Juan Cruz Marketing 28,000 Surveys 10/7/2002
140 Maria Clara Accounting 35,000 Tax Acc. 12/8/2002
190 Andres Boni Finance 55,000
150 ABC Marketing 42,000 SPSS 6/19/2000
150 ABC Marketing 42,000 Java 8/12/2005

EMPLOYEE 2 (Emp_ID, Name, Dept_Name, Salary, Course_title, Date_Completed)

Well structured Relation (revised)
Emp_ID Course_title Date_Completed
100 SPSS 6/19/2000
100 Surveys 10/7/2002
140 Tax Acc 12/8/2002
150 SPSS 6/19/2000
150 Java 8/12/2005
 Transforming EER Diagrams into
Relations
A. 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
 1. Mapping a regular entity

(a) CUSTOMER entity type with simple attributes

(b) CUSTOMER relation

 2. Mapping a composite attribute
(a) CUSTOMER
entity type with
composite
attribute

(b) CUSTOMER relation with address detail

 3. Mapping a multivalued attribute
(a)

Multivalued attribute becomes a separate relation with foreign key

(b)

1–to–many relationship between original entity and new relation

 Summary of Regular Entities
PK Attr1
Attr2
Relation1 (PK, Attr1, Attr2)
Relation1

Attr2 Attr3
PK Attr1

Composite
Relation1
Relation1 (PK, Attr1, Attr2, Attr3)

PK Attr1
Attr2
Relation1 (PK, Attr1)
Relation1 Relation2(PK, Attr2)
 Transforming EER Diagrams into
Relations (cont.)

B. Mapping Weak Entities

 Becomes a separate relation with a foreign
key taken from the superior entity
 Primary key composed of:

 Partial identifier of weak entity

 Primary key of identifying relation (strong

entity)
Mapping a weak entity
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

Composite primary key

Summary on Weak Entity

PK Attr1 PKw Attr2

Relation1 Relates Weak

Relation1 (PK, Attr1)

Weak (PKw, PK, Attr2)
 Transforming EER Diagrams into
Relations (cont.)
C. Mapping Binary Relationships
 One-to-Many - Primary key on the one side
becomes a foreign key on the many side
 Many-to-Many - Create a new relation with
the primary keys of the two entities as its primary
key
 One-to-One - Primary key on the mandatory
side becomes a foreign key on the optional side
Example of mapping a 1:M relationship

Note the mandatory one

Mapping the relationship

Again, no null value in the

foreign key…this is because
of the mandatory minimum
cardinality

Foreign key
 Example of mapping an M:N relationship

The Supplies relationship will need to become a separate relation

 Three resulting relations

Composite primary key

New
Foreign key intersection
relation
Foreign key
Mapping a binary 1:1 relationship
In_charge relationship
 Resulting relations (1:1)
Nearly always optional on another side
Summary on Binary Relations

PK1 Attr1 PK2 Attr2

Relation1 Relates Relation2

1:M
Relation1 (PK1, Attr1)
Relation2 (PK2, PK1, Attr2)
Summary on Binary Relations

PK1 Attr1 Attr3 PK2 Attr2

Relation1 Relates Relation2

M:N
Relation1 (PK1, Attr1)
Relation2 (PK2, Attr2)
Relates (PK1, PK2, Attr3)
Summary on Binary Relations

PK1 Attr1 PK2 Attr2

Relation1 Relates Relation2

1:1
Relation1 (PK1, Attr1)
Relation2 (PK2, PK1, Attr2)
 Transforming EER Diagrams into
Relations (cont.)
D. Mapping Associative Entities
 Identifier Not Assigned
 Default primary key for the association relation
is composed of the primary keys of the two
entities (as in M:N relationship)
 Identifier Assigned
 Itis natural and familiar to end-users
 Default identifier may not be unique
Mapping an associative entity with an identifier
Associative entity
Three resulting relations
Summary on Associative Entities

Attr3 PK2
PK1 Attr1 Attr2

Relation1 Relation3 Relation2

Associative entity with NO identifier

Relation1 (PK1, Attr1)

Relation2 (PK2, Attr2)
Relation3 (PK1, PK2, Attr3)
Summary on Associative Entities

PK3 PK2
PK1 Attr1 Attr2

Relation1 Relation3 Relation2

Associative entity with identifier

Relation1 (PK1, Attr1)

Relation2 (PK2, Attr2)
Relation3 (PK3, PK1, PK2)
 Transforming EER Diagrams into
Relations (cont.)
E. Mapping Unary Relationships
 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
 Mapping a unary 1:M relationship

(a) EMPLOYEE entity with

Manages relationship

(b) EMPLOYEE
relation with
recursive foreign
key. Need not
have the same
name
Mapping a unary M:N relationship

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

(b) ITEM and

COMPONENT
relations
Summary on Unary Entities

PK1 Attr1

Relation1

Relates

1:M

Relation1 (PK1, Attr1, PrimKey)

Summary on Unary Entities

PK1 Attr1

Relation1

Relates
Attr2

M:N

Relation1 (PK1, Attr1)

Relates (PK1, PrimKey, Attr2)
 Transforming EER Diagrams into
Relations (cont.)
F. Mapping Ternary (and n-ary)
Relationships
 One relation for each entity and one for the
associative entity
 Associative entity has foreign keys to each

entity in the relationship

 Mapping a ternary relationship
Ternary relationship with associative entity
Mapping the ternary relationship

Remember that the

primary key MUST be
unique
 Transforming EER Diagrams into
Relations (cont.)
G. Mapping Supertype/Subtype
Relationships
 One relation for supertype and for each subtype
 Supertype attributes (including identifier and
subtype discriminator) go into supertype relation
 Subtype attributes go into each subtype; primary
key of supertype relation also becomes primary key
of subtype relation
 1:1 relationship established between supertype and
each subtype, with supertype as primary table
Supertype/subtype relationships
Mapping Supertype/subtype relationships to relations

These are
implemented as one-
to-one relationships
 Illustrative Example #1
Convert ER into a relation
Code Room
Instcode Day

INSTRUCTOR teach CLASS Time

es

ContactNo Name

registe
r
Address

MemName
MEMBER MemId
 Illustrative Example #2
BedNo BED Room

Convert ER into a relation assign

Date

PNo
IN-PATIENT PAddress
PName

A_Date
Procedure attend Bills Charge

PHYSICIAN ITEM

PhyName PhyID ICode Description

 Illustrative Example #3
Convert ER into a relation
Cust_ID C_Name C_Address

CUSTOMER M_ID M_Addr

Acct_ID MERCHANT
Given
Card_type
Exp_Date
Date
CARD
ACCOUNT
charge Amount
Bank_no d s
Cur_Bal

DEBIT CARD CREDIT CARD

 Data
Normalization
 Introduction
 Normalization - process of evaluating table
structures and reorganizing them as
necessary to produce a set of stable, well-
structured relations.

 Relation - two-dimensional array that has a

single-valued entry in each cell, has no
duplicate rows, and has columns whose
meaning is identical across all rows.
 Data Normalization
 Tool to validate and improve a logical design
so that it satisfies certain constraints that
avoid unnecessary duplication of data
 Process of decomposing relations with
anomalies to produce smaller, well-
structured relations
 Well-Structured Relations
 Relation that contains minimal data redundancy
and allows users to insert, delete, and update
rows without causing data inconsistencies
 Goal is to avoid anomalies
 Insertion Anomaly – adding new rows forces user
to create duplicate data
 Deletion Anomaly – deleting rows may cause a loss
of data that would be needed for other future rows
 Modification Anomaly – changing data in a row
forces changes to other rows because of duplication

General rule of thumb: a table should not pertain to

more than one entity type
 Example

Question – Is this a relation? Answer – Yes: unique rows and no

multivalued attributes

Question – What’s the primary key? Answer – Composite: Emp_ID,

Course_Title
 Anomaly
 A condition that may prevent the storage or
retention of relevant data or may create the
potential for inconsistent data.
 Anomalies in the Table
 Insertion - can’t enter a new employee without
having the employee take a class
 Deletion - if we remove employee 140, we lose
information about the existence of a Tax Acc class
 Modification - giving a salary increase to
employee 100 forces us to update multiple
records
 Functional Dependency
 The value of one attribute determines the
value of another attribute.
 Rule: If any relation R, attribute B is functionally
dependent on attribute A if for every valid
instance of A uniquely determines the value of B.
 Represented by an arrow:
AB
Example of Functional Dependency

EMPLOYEE2(Emp_ID, Name, Address, Salary,

Course_Title, Date_Completed)

Relation (Emp_ID, Course_Title, Date_Completed)

 Examples on Functional Dependency
 In the previous example:
 Emp_ID  Name, Address, Salary
 Emp_ID, Course_Title  Date_Completed

 Other examples:
 SSN Name, Address, Bday
 Person’s Name, Address, and Bday are functionally
dependent on the person’s SSN
 VIN  Make, Model, Color
 Make, model, and color of a Vehicle are functionally
dependent on the Vehicle identification number.
 Determinant
 The attribute on the left side of the arrow in
a functional dependency.

AB
Determinant
 Candidate Key
 A unique identifier. One of the candidate
keys will become the primary key
 E.g. Emp_ID, and Couse_Title … in this case
both are candidate keys

 Each non-key field is functionally

dependent on every candidate key
 Example of functional dependencies

TABLE ( A, B, C, D, E, F, G )

Functional dependencies: Primary keys:

A  C, D A, B
C  E, F
A, B  G

Candidate keys
Steps in
normalization
 Normal form
 A state of a relation that results from
applying simple rules regarding functional
dependencies to that relation.
 Zero form
 1NF

 2NF

 3NF - an acceptable form

 Boyce-Codd NF

 4NF

 5NF
 Step 0: Zero form
 Represent the user’s view of a report in
tabular form.
UC Customer INVOICE

Customer ID :2 Order ID : 1006

Customer Name: Value Furniture Date : 10/24/2007
Address : Plano, TX

ProductID Description Finish Qty Unit Price Extended Price

7 Dining Table Natural Ash 2 800.00 1,800.00

5 Writer’s Desk Cherry 2 325.00 650.00

4 Entertainment Natural Maple 1 650.00 650.00

Center
 Sample Zero form

Table with multivalued attributes

 Step 1: First Normal Form (1NF)

 Relation that has a primary key and in

which there are no repeating groups
(multivalued attributes).

 All relations are in 1st Normal Form

 Sample First Normal Form

Note: Table with no multivalued attributes and unique rows.

 Anomalies in this Table
 Insertion – if new product is ordered for
order 1007 of existing customer, customer
data must be re-entered, causing
duplication
 Deletion – if we delete the Dining Table
from Order 1006, we lose information
concerning this item's finish and price
 Update – changing the price of product ID
4 requires update in several records
 4 Determinants found

Full dependency

Partial dependencies Partial dependencies

Transitive dependencies
 Partial Dependency
 A dependency in which the value of a non-
key attribute can be uniquely identified using
only part of a concatenated primary key

Pk1 Pk2 Nk1 Nk2 Nkn

 Transitive Dependency
 A dependency in which the value of one non-
key attributes is functionally determined by
another non-key attribute

Pk1 Pk2 Nk1 Nk2 Nkn

 Step 2: Second Normal Form

 1NF PLUS every non-key attribute is

fully functionally dependent on the
ENTIRE primary key
 Every non-key attribute must be defined by
the entire key, not by only part of the key
 No Partial functional dependencies.
Order_ID  Order_Date, Customer_ID, Customer_Name, Customer_Address
Customer_ID  Customer_Name, Customer_Address
Product_ID  Product_Description, Product_Finish, Unit_Price
Order_ID, Product_ID  Order_Quantity

Therefore, NOT in 2nd Normal Form

 Sample Second Normal Form

Partial Dependencies are removed, but there are still transitive

dependencies
 Another example

 Transform the relation into 2NF.

A B C D E F G H I J K
 Step 3: Third Normal Form
 2NF PLUS no transitive dependencies
(functional dependencies on non-primary-key
attributes)
 Note: this is called transitive, because the
primary key is a determinant for another
attribute, which in turn is a determinant for a
third
 Solution: non-key determinant with transitive
dependencies go into a new table; non-key
determinant becomes primary key in the new
table and stays as foreign key in the old table
 Sample Third Normal Form




Transitive dependencies are removed
 Exercise:
 Given the form below, determine and write
the 1st, 2nd and 3rd NFs relations.
XYZ UNIVERSITY
REPORT ON GRADES
2ND TRIMESTER, SY 2005-2006
ID Number: 9729344
Name: Emily Williams
Course: BSIT
Course Instructor
Description Instructor Units Grade
Code Code
CSC 222 Database Management Einstein Eins 3 85
CSC 223 Programming Languages Mozart Moz 3 82

Math 4 Statistics Bohr Bohr 3 84

 Zero form
ID Name Course Course Description Instructor Instructo Units Grade
number Code r Code
9729344 Emily BSIT CSC 222 Database Einstein Eins 3 85
Williams Management

CSC 223 Programming Mozart Moz 3 82

Languages

Math 4 Statistics Bohr Bohr 3 84

9722565 Steve BSIM Physics 1 College Physics White Wht 3 79

Roberts

CSC 222 Database Einstein Eins 3 81

Management
 First Normal form
ID Name Course Course Description Instructor Instructo Units Grade
number Code r Code
9729344 Emily BSIT CSC 222 Database Einstein Eins 3 85
Williams Management

9729344 Emily BSIT CSC 223 Programming Mozart Moz 3 82

Williams Languages

9729344 Emily BSIT Math 4 Statistics Bohr Bohr 3 84

Williams

9722565 Steve BSIM Physics 1 College Physics White Wht 3 79

Roberts

9722565 Steve BSIM CSC 222 Database Einstein Eins 3 81

Roberts Management

GRADE_REPORT (ID NUMBER, NAME, COURSE, COURSE CODE,

DESCRIPTION, INSTRUCTOR, INSTRUCTOR CODE ,UNITS, GRADE)
 Second Normal Form

ID NUMBER NAME COURSE COURSE CODE DESCRIPTION INSTRUCTOR INSTRUCTOR CODE UNITS GRADE

 ID NUMBER  NAME, COURSE

 COURSE CODE  DESCRIPTION, UNITS,
INSTRUCTOR, INSTRUCTOR CODE
 ID NUMBER, COURSE CODE  GRADE
 2nd NF tables (cont.)
Student Registration
ID Name Course ID Course Code Grade
Number Number

Emily
9729344 BSIT 9729344 CSC 222 85
Williams

Steve
9722565 BSIM 9729344 CSC 223 82
Roberts

9729344 Math 4 84

9722565 Phys 1 79

9722565 CSC 222 81

 2nd NF tables (cont.)

Course_Instructor
Course Instructor
Description Instructor Units
code Code
Database
CSC 222 Einstein Eins 3
Management
Programming
CSC 223 Mozart Moz 3
Languages
Math 4 Statistics Bohr Bohr 3
Phys 1 College Physics 1 White Wht 3
Database
CSC 222 Binstein Bins 3
Management
 Third Normal Form

COURSE CODE DESCRIPTION UNITS INSTRUCTOR CODE INSTRUCTOR

COURSE CODE  DESCRIPTION, UNITS, INSTRUCTOR CODE , INSTRUCTOR

INSTRUCTOR CODE  INSTRUCTOR

 3rd NF Relations

 Student (IDNumber, Name, Course)

 Registration (IDNumber, CourseCode,
Grade)
 Course (Course Code, Description, Instructor
Code, Units)
 Instructor (Instructor Code, Instructor)
BOYCE-CODD Normal Form (BCNF)
 A special case of 3NF that requires every
determinant in the table be a candidate key.
BCNF can be violated only if the table
contains more than one candidate key.
 Example:
3NF, but not BCNF
A B C D E

As you examine, note these functional dependencies:

A, B  C, D, E
CB
 BCNF (cont.)
 To convert the table structure that meets
both 3NF and in BCNF, first change the
primary key (A, C).

A C B D E

new new
Pk Nk

 It is in 1NF, remove partial dependency.

A C D E C B
 Sample BCNF Problem
 Each CLASS_CODE identifies a class uniquely.
 A student can take many classes, therefore
can earn many grades.
 A staff member can teach many classes, but
each class is taught by only one staff
member.

StudID StaffId ClassCode Grade

 Solution to the Problem

3NF but not in BCNF:

StudID StaffId ClassCode Grade

3NF and in BCNF:

StudID ClassCode Grade ClassCode StaffID

 Exercise:
 Using the following INVOICE table structure, draw
its dependency diagram and identify all
dependencies. You can assume that the table does
not contain repeating groups and that any invoice
number may reference more than one product.
(Hint: this table uses a composite primary key.)

Attribute Name Sample Value

INV_NUM 211347
Prod_Num AA_E1234QW
Sale_Date 06/22/2006
Pro_Desc B&D sander, 6 in. Disk
Vend_code 211
Vend_Name NerverFail, Inc.
Number_sold 2
Prod_price P125.75
 Fourth Normal Form (BCNF)
 It is in 3NF and has no multiple sets of
multivalued.
 Example: Suppose employee 12345 does
volunteer work for the Red Cross and United Way.
In addition, the employee might be assigned to
work on three projects: 1, 5, and 12.
Employee (EMP_Num, Emp_Service, Emp_Assign)
 4NF (cont.)
Emp_Num Emp_Service Emp_Assign
Version 1: 12345 Red Cross 1
12345 United way 5
12345 12

Emp_Num Emp_Service Emp_Assign

Version 2: 12345 Red Cross 1
12345 United way 5
12345 12
12345
12345

Emp_Num Emp_Service Emp_Assign

Version 3: 12345 Red Cross 1
12345 Red Cross 5
12345 United way 12
 4NF Solution (cont.)
 Note:
 All attributes must be dependent on the primary
key, but they must be independent of each other.
 No row can contain two or more multivalued
facts about an entity.

Employee_Service (Emp_Num, Emp-Service)

Employee_AsProject (Emp_Num, Emp_Assign)

Database Schema in 4NF

 See MSWord handout
for other sample problems
 Merging Relations
 View Integration – Combining entities from multiple
ER models into common relations
 Issues to watch out for when merging entities from
different ER models:
 Synonyms – two or more attributes with different names
but same meaning
 Homonyms – attributes with same name but different
meanings
 Transitive dependencies – even if relations are in 3NF prior
to merging, they may not be after merging
 Supertype/subtype relationships – may be hidden prior to
merging
 Enterprise Keys

 Primary keys that are unique in the whole

database, not just within a single relation
 Corresponds with the concept of an object
ID in object-oriented systems