Logical

Database
Design and the
Relational
Model
Chapter 4 (Part 1)
 The Relational Data Model

 Introduced in a journal article written in

1970 by E. F. Codd, a scientist with IBM

 Early research prototypes of relational

systems were developed throughout the
1970s

 Commercial RDBMS emerged in the 1980s

and came to dominate the database market,
a situation that continues to the present
time

2
 Components of the Relational
Data Model
1. Data Structure - Data are organized in two-dimensional
tables (called relations) with rows and columns

2. Data Manipulation - Data stored in the tables may be

manipulated through the use of a command language
(e.g., SQL)

3. Data Integrity - Business rules may be defined that

maintain the integrity of data that is manipulated

3
 Relational Data Structure

 Relations (Tables, Relational Tables)

 A set of named columns and an arbitrary number of
unnamed rows
 Each row corresponds to a record that contains data
(attribute) values for a single entity.

 Attributes (Fields, columns)

 A named column of a relation

 Structure of a relation
 Relation name (attribute1, attribute2, etc.)
 E.g., EMPLOYEE (EMP_ID, Name, Dept_Name, Salary)

4
 Relational Keys

 Primary Key
 An attribute (or combination of attributes) that uniquely
identifies each row in a relation.
 EMPLOYEE (EMP_ID, Name, Dept_Name, Salary)

 Composite Key
 A primary key that consists of more than one attribute
 DEPENDENT(EMP_ID, Dependent_Name)

5
 Relational Keys

Foreign Key
 To represent the relationship between two
tables
 Attribute in one relation that serves as the
primary key of another relation in the
same database (i.e., linking field)
 EMPLOYEE (EMP_ID, Name, Dept_Name, Salary)
 DEPARTMENT (Dept_Name, Location, Fax)

6
 Customer_id Order_Id Product_Id

Customer Makes Order Consists Product

city Customer_name Order_date Product_price

address Product_name
First_name Last_name
state
Middle_name
zip

7
 Example of Four Relations
PK

PK FK Note the Primary Keys

(underlined), including
the composite primary
key, and the Foreign
Keys (either dashed
CPK underline or solid
underline) if the
foreign key is also part
of a composite primary
FK PK FK key

8
Instance of a relational schema

9
 Integrity Constraints
Domain Constraint
 constrains allowable values for an attribute (e.g.,
domain name, meaning, data type, field
size/length, allowable values/range)
Entity Integrity Rule
 No primary key attribute (or component of a
primary key attributes) can be null
Referential Integrity Constraint
 A rule that states that either each foreign key
value must match a primary key value in the
other relation or else the foreign key value must
be null

10
Diagramming Referential Integrity
Constraints

11
 A well structured relation

Employee1 is a well structured relation

Any modification to an employee’s data such
as a change in salary, is confined to one row of
the table

EMPLOYEE1

12
 Is this a well structured relation?

EMPLOYEE2

 This table has a considerable amount of redundancy

e.g., EMP_ID, NAME, DEPT, and SALARY appear in two
separate rows for some employees
 If the salary of those employees change, we must record this
information in two or more rows
 Therefore, this is not a well structured relation

13
 Well-Structured Relations

“A relation that contains minimal

redundancy and allows users to insert,
modify, and delete the rows in a table
without errors or inconsistencies”

14
 Why minimize redundancies?

Redundancies in a table may result in errors

and inconsistencies (called anomalies)
when a user attempts to update the data in
the table

Three types of anomalies

 Insertion anomaly
 Deletion anomaly
 Modification anomaly
15
 Anomalies

I nsertion Anom alies

 are experienced when we attempt to
store a value for one attribute but
cannot because the value of another
attribute is unknown

16
 Insertion anomaly

If we want to add a new employee to

EMPLOYEE2, the user must supply values
for EMPID and COURSE which are composite
primary key

This is because the primary key values

cannot be Null

In reality, employee should be able to enter

employee data without supplying course
data

17
 Anomalies

Deletion Anomalies
 are experienced when a value for one attribute
we wish to keep is unexpectedly removed
when a value for another attribute is deleted

18
 Deletion anomaly

If the data for employee number 234

is deleted, we will also lose the
information that this employee
completed the course 111

In fact, we lose information about

the course altogether

19
 Anomalies

Modification Anomalies
 are experienced when changes to multiple
instances of an entity (rows of a table) are
needed to effect an update to a single value of
an attribute

20
 Modification anomaly

Suppose that employee number 100

gets a salary increase, we must
record this increase in each of the
rows for that employee

Otherwise the data will be

inconsistent

21