Sie sind auf Seite 1von 28

The Relational Model

-From conceptual to
logical-

Objectives
Describe the Relational Model and
differentiate it from the Conceptual
Model
Identify and describe the
components of the relational model
Identify the advantages of the
relational model when used for
database creation

Introduction
What is a flat-file database?
Aflat file databaseis adatabasethat
stores data in a plain textfile.
Example: MS Excel
Pros: Uses a simple structure, simple to
understand, low cost
Cons: Does not have referential
integrity, subject to data anomalies

Example
STUDENT

COURSE

Flat File
Database??
SUBJECT

Introduction
Logical Database Design
The process of transforming the
conceptual data model (i.e. ERDs)
into a logical database model (i.e.
relational databases)
A logical database model is a design
that conforms to the data model for a
class of Database Management System
(DBMS)

Overview of Logical Design

Overview of Logical Design

Terminology Differences
Flat-File
Relational
Conceptua
Traditiona Database
Model
l Model
l
(e.g.
(e.g.
(e.g. ERD)
Excel)
Access)
File
Table
Entity
Relation
Entity
Record
Row
Tuple
Instance
Field
Column
Attribute
Attribute
Key (or
Key
Identifier
Key
link)

Relational Database Model

Uses a collection of tables to


represent data and relationships
among data
Relations are illustrated by linking
or joining the two tables with a
common element
Links data by unique columns
Uses user-friendly query
language

Components
Data structure : data organized in
the form of tables
Data manipulation : powerful data
manipulation operations are used
Data integrity : business rules are
included to maintain data integrity

Correspondence with E-R


Model
Data is stored in relations (entities)
A relation consists of tuples/rows
(instances) and columns (attributes)
Goal: to store data without unnecessary
redundancy and to be able to process
information easily

Correspondence with E-R


Model

Relations correspond to entity types


and with many-to-many relationship types
Rows correspond to entity instances
and with many-to-many relationship
instances
Columns correspond to attributes
Note: The word relation (in the relational
database model) is NOT the same as the
word relationship (in the ERD Model)

Keys (a.k.a. Identifiers)


Keys can be simple (one field) or
composite (more than one field)
Keys are usually used as indexes to
speed up response to queries (more
on that in the future)

Keys (a.k.a. Identifiers)


Keys are special fields that serve two
main purposes
Primary Key : unique identifiers of the
relation like employee numbers, social
security numbers. It guarantees all rows
are unique
Foreign Key : any identifiers that
enable a dependent relation (on the
many side) to refer to its parent relation
(on the one side)

Foreign Key
EMPNO

ENAME

DEPTNO

DEPTNO
10

ACCOUNTING

NEW YORK

20

RESEARCH

DALLAS

30

SALES

CHICAGO

7839

KING

10

7698

BLAKE

30

7782

CLARK

10

7566

JONES

20

7654

MARTIN

30

7499

ALLEN

30

7844

TURNER

30

7900

JAMES

30

7521

WARD

20

7369

FORD

20

. . .

Foreign
Key

. . .

Primary
Key

DNAME

LOC

Relations (a.k.a. Entities)


A named, two-dimensional table of
data
Consists of a set of named columns (i.e.
the attributes) and an arbitrary number
of unnamed rows (i.e. the instances)
Can be expressed as
RELATION (attribute1, attribute2, . . .)
Example
STUDENT (ID_Num, Name, Address,
Bday)

Relations (a.k.a. Entities)


Requirements for a table to qualify as a
relation:
It must have a unique name
Every attribute value must be atomic
(not multi-valued, not composite)
Every row (a.k.a. instance) must be
unique (no two rows can have exactly
the same values for all fields)
Attributes in rows must have unique
names
The order of the columns must be

Integrity Constraints
Domain Constraints
Allowable values for an attribute

Entity Integrity
No primary key attribute may be null.
All primary key fields MUST have data.

Domain Constraints
Attribute

Domain Name

Description

Domain

Customer_ID

Customer_IDs

Set of all possible customer


IDs

character: size 5

Customer_Nam
e

Customer_Nam
es

Set of all possible customer


names

character: size 25

Customer_Addr
ess

Customer_Addr
esses

Set of all possible customer


addresses

character: size 30

Postal_Code

Postal_Codes

Set of all possible postal zip


codes

character: size 10

Order_ID

Order_IDs

Set of all possible order IDs

character: size 5

Order_Date

Order_Dates

Set of all possible order


dates

date format
mm/dd/yyyy

Product_ID

Product_IDs

Set of all possible product


IDs

character: size 5

Product_Descri
ption

Product_Descrip
tions

Set of all possible product


descriptions

character: size 25

Product_Finish

Product_Finishe
s

Set of all possible product


finishes

character: size 15

Standard_Price

Unit_Prices

Set of all possible unit prices

monetary: 6 digits

Product_Line_I
D

Product_Line_ID
s

Set of all possible product


line IDs

integer: 3 digits

Integrity Constraints
Referential integrity any foreign key
value (on the many side) must match a
primary key value (on the one side)
Note: the foreign key can be null
Example: Delete Rules
Restrict : don't allow deleting the "parent" side if rows exist
in on the "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
CUSTOMER
Customer_ID

Customer_Name

Customer_Address

City

State

Postal_Code

ORDER
Order_ID

Order_Date

Customer_ID

ORDER LINE
Order_ID

Product_ID

Ordered_Quantity

PRODUCT
Product_ID

Product_Description

Referential
integrity
constraints

Product_Finish

Standard_Price

Product_Line_ID

Data Normalization
Process of converting a relation to a
standard form to avoid unnecessary
duplication of data
Used to derive well-structured relations
that are free of anomalies when
manipulated
Often accomplished in stages or normal
form
The goal is to have tables that contain a
minimum amount of redundancy and allow
users to insert, delete, and update rows

Well-Structured Relations
A 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 Anomalyadding new rows
forces user to create duplicate data
Deletion Anomalydeleting rows may
cause a loss of data that would be needed
for other future rows
Modification Anomalychanging data in a
row forces changes to other rows because of
duplication
23

Example

24

Anomalies in this Table


Insertioncant enter a new employee without
having the employee take a class
Deletionif we remove employee 140, we lose
information about the existence of a Tax Acc
class
Modificationgiving a salary increase to
employee 100 forces us to update multiple
records

25

Functional Dependencies and Keys


Functional Dependency: The value of one
attribute (the determinant) determines
the value of another attribute
Candidate Key:
A unique identifier. One of the candidate keys
will become the primary key
E.g. perhaps there is both credit card
number and SS# in a tablein this case
both are candidate keys
Each non-key field is functionally dependent
on every candidate key

26

Normalization
First Normal Form
No multivalued attributes, all atomic

Second Normal Form


No partial functional dependency

Third Normal Form


No transitive dependency

Usually done until the 3 rd Normal form.

Sources
Hoffer, Jeffrey, Ramesh, V., and Topi,
Heikki. Modern Database
Management, 10th Edition.