DATABASE DESIGN

Using the Relational

Model
Lecture Notes Prepared by
Prof. Melody Angelique C. Rivera
Faculty, College of Computer Studies, Silliman University
Based on:
Modern Database Systems by Hoffer, Prescott and McFadden (Chap 3)
Database Systems by Connolly & Begg (Chap 3)
CMSC F Course Material (UPOU)

Three-step Process in
Designing Databases

Functional Analysis
identifies

data and the business rules which

are to be applied to the process
The job of a database analyst is to:
Identify and understand the rules that govern data
Represent the rules so that they can be
understood by IS developers and users
Implement the rules in database technology

Three-step Process in
Designing Databases

Data Analysis
Three

(3) Phases

Conceptual Design
Logical Design
Physical Design

Physical Implementation
the

outcome of the physical design phase is

finally implemented to produce the physical
database
3

The Functional Analysis

Collection of the data requirements and
their analysis
Database designers interview prospective
database users to understand and
document their data requirements
Result: concisely written set of user
requirements

The Functional Analysis

(continued)

User requirements come in the form of

business rules and functional
requirements
contains

user-defined operations that will be

applied to the database
includes operations like retrieval and updates

The Functional Analysis

(continued)

Business Rule:
A statement

that defines or constrains some aspect of

the business
Characteristics

Declarative
Precise
Atomic
Consistent
Expressible
Distinct
Business-oriented

The Functional Analysis

(continued)

Example of a Business Rule:

A student

may enroll in a course in his/her

degree only if the prerequisites for the course
has been successfully completed.

The Functional Analysis

(continued)

Data Names and Definitions

Data

names should:

Relate to business, not technical (hardware of

software) characteristics

Example: Customer

Be meaningful (or self-documenting)

Be unique (or distinct from every other data object

Bad Example: Date

Good Example: Birthdate

The Functional Analysis

(continued)
Data

names (continued)

Be readable
Be composed of words taken from an approved list
Repeatable

Different people at different times should develop exactly

or almost the same name
There must be a standard or pattern for names
Example: StudentBirthDate

The Functional Analysis

(continued)
Data

Definitions

Considered a type of business rule

An explanation of a term or a fact
Term

a word or phrase that has a specific meaning for the

business
Example: course, reservation

Fact
An association between two or more terms
Example of a fact that is a definition (the defined
term is underlined): A course is a module of
instruction in a particular subject area

10

Data Analysis:
Phase 1
Conceptual Database Design

Conceptual Database Design

The goal is to create a conceptual data
model, which is a brief description of the
data requirements
Shows detailed descriptions of data types,
relationships, and data constraints
Expressed using the concepts provided by
the data model

12

Entity-Relationship Model
(ER Model)
a popular conceptual data model
there are several variations but there is
one feature that is common to all -- all
data may be represented using any one of
the following major constructs:

ENTITY
ATTRIBUTE
RELATIONSHIP
13

Entity-Relationship Model
(ER Model) (continued)

ENTITY
an

abstract or concrete thing in the real world

which is of interest to the organization
ex: EMPLOYEE

ATTRIBUTE
a

named property or characteristic that

describes an entity or a relationship
ex: name, address, age, date_hired
14

Entity-Relationship Model
(ER Model) (continued)

RELATIONSHIP
an

association between two entities

ex: works on
EMPLOYEE works on PROJECT

EMPLOYEE and PROJECT are entities

15

Conceptual
Database Design
The Entity-Relationship
Diagram (ERD)

The ERD Symbols

a graphical representation of entities and
their relationships
Basic symbols:

entity

attribute

relationship
17

ERD Example

attributes

DateBorrowed

MemberNo
MEMBER
MemLast Name

BookNo
borrows

BOOK

MemAddress

BookTitle
MemFirstName

BookAuthor

relationship
entities
18

The Entity

19

Entity

Entity Type or Set

A collection

of entities that share common

properties or characteristics
The name is always singular and written in
uppercase or capital letters

Entity Instance
A single

occurrence of an entity type

In simple terms, the record itself
20

The Attribute

21

Attribute

Types of Attributes
Simple
Composite
Single-Valued
Multivalued
Stored
Derived
Required
Optional
22

Simple Attribute
An attribute that cannot be broken down
into smaller components
Example: STUDENT entity

StudentID
StudentLastName
StudentDegree

STUDENT

StudentID

StudentLastName
StudentDegree
23

Composite Attribute
An attribute that can be broken down into
component parts
Component attributes may appear above
or below the composite attribute on an ER diagram
The decision whether to subdivide an
attribute into its component parts depends
on whether user will need to refer to those
individual components

24

Composite Attribute Example

Semester
Year

Number
STUDENT
StudentID
Address
Street_Address
City

ZipCode
Province

25

Required Attribute
An attribute that must have a value for
each entity instance
Example: STUDENT entity

StudentID
StudentLastName
StudentFirstName
StudentDegree

26

Optional Attribute
An attribute that may not have a value for
every entity instance
Example: STUDENT entity

StudentMajor
StudentHomePhone

27

Required vs Optional Attributes

Entity Type: STUDENT
Attribute Name

Data Type

Entity Instance

Entity Instance

StudentID

Char (12)

2007-1-01254

2007-2-00349

StudentLastName

Char (20)

Pineda

Gonzalez

StudentFirstName

Char (30)

Katherine

Bernardo

StudentDegree

Char (10)

BSMT

BBA

StudentMajor

Char (10)

Management

StudentHomePhone

Char (11)

032-4125621

28

Single-Valued Attribute
An attribute that has only one value
Example: STUDENT entity

StudentGender

Possible values: Female or Male

StudentCivilStatus

Possible values: Single, Married, Separated,

Widowed

29

Multivalued Attribute
An attribute that may take on more than
one value for a given entity instance
Example: EMPLOYEE entity

EmpSkill

An employee may have more than one skill (C

programmer, Java Programmer, Web Designer)

Notation: Double oval or ellipse

30

Multivalued vs Single-valued
Attribute Example
EmpID

EmpName
EMPLOYEE

EmpDateEmployed
EmpSkill

EmpGender
Multivalued Attribute
Single-valued Attributes

31

Transforming (Exploding)
Multivalued Attributes
Dorm_No

Dorm_Name
Manager

DORMITORY
Location
Rooms

Original Diagram

Multivalued Attribute
32

Transforming (Exploding)
Multivalued Attributes (continued)
Dorm_No
Dorm_Name

DORMITORY
Location
Manager

Start_Rent

has

Room_No

Capacity

ROOM

End_Rent

Room_Name

Transformation of the Multivalued Attribute

How to read: A dormitory has one or more rooms
33

Another Multivalued Attribute

Example
Course_ID

Course_Title
COURSE

Prerequisite
Original Diagram
34

Entities with Multivalued

Attributes (continued)
Course_ID

Course_Title

COURSE

Transformation of the
Multivalued Attribute

Is_A_Prerequisite_for

35

Stored Attribute
An attribute that gets its value directly from
an input device (e.g. keyboard)
Example: STUDENT entity

StudentID
StudentLastName
StudentFirstName
StudentDegree

36

Derived Attribute
An attribute whose values can be
calculated from related attribute values
(and possibly data not in the database)
Example: EMPLOYEE entity

EmpYearsEmployed

May be calculated as:

PresentDate EmpDateEmployed

Notation: Oval or ellipse with a dashed

line
37

Derived Attribute Example

EmpID

EmpName
EMPLOYEE

EmpYearsEmployed

EmpDateEmployed
EmpSkill
EmpPhoneNo

Derived Attribute

38

Key Attribute

Identifier
An

attribute or combination of attributes that

uniquely identifies individual instances of an
entity type
More commonly known as Primary Key
It is unique (no two instances of an entity type
may have the same value)
Underlined (solid) in the ERD
39

Identifier Example
EmpID

EmpName
EMPLOYEE

Identifier or
Primary key
(Simple key
attribute)

EmpDateEmployed
EmpSkill

EmpYearsEmployed

A simple key attribute is an identifier that consists of a

simple or single attribute.

40

Identifier Example
Year

Semester

StudentNo

StudentID

Composite key attribute

STUDENT
StudentLastName
StudentCourse

A composite key attribute is an identifier that consists of a

composite attribute.

41

The Relationship

42

Relationship Names
A verb
Present tense
Examples:

Manages

(or Is_Managed)
Receives (or Is_Received)
Enrolls (or Is_Enrolled)
Stays / Occupies (or Is_Occupied)
Marries (or Is_Married)
43

Relationships between entities

Degree of a Relationship
the number of entities that participate in a relationship
unary, binary, ternary or n-ary

UNARY RELATIONSHIP
- Only one entity
is involved in the
relationship

EMPLOYEE

supervises

An employee supervises another employee. For example, one of the employees is

a manager/supervisor and the other one is a clerk.
44

Relationships between entities

(continued)
BINARY RELATIONSHIP
- Only two entities are involved
in the relationship

EMPLOYEE

manages

DEPARTMENT

An employee manages a department.

45

Relationships between entities

(continued)
TERNARY RELATIONSHIP
- Three entities are
involved in the relationship

VENDOR

PART

ships

WAREHOUSE

A vendor ships a part to the warehouse. or

A part is being shipped by a vendor to the warehouse
46

Relationships between entities

(continued)
N-ARY
RELATIONSHIP

VENDOR

PART

ships

A vendor ships a part to the

warehouse through a
transportation.

WAREHOUSE

TRANSPORTATION
47

Relationships between entities

(continued)
MULTIPLE
RELATIONSHIPS
owns

PERSON

CAR
registers

A person owns a car. and

A person registers a car.
48

Relationships with attributes

Attributes that do not belong to any entity

should be placed on the relationship
Date_bor
M_no

V_code

V_title

M_name

MEMBER

borrows

VCD
V_avail

Date_due
49

Cardinalities in Relationships

50

The Cardinality Ratio

Specifies the number of instances of entity B that

can (or must) be associated with each instance of
entity A
One-to-one (1:1)
when

only one entity can have that relationship with

another entity
Example 1: in a monogamous society, one husband
can only have one wife (legally)
Example 2: by default, a student takes up only one
degree (at a time) in a college
51

Cardinalities in Relationships
(continued)

Many-to-many (M:N)
we

can have any number of relationships with other

entities
ex: in joint accounts

One-to-many (1:M)
one

entity can have more than one of that type of

relation
ex: if a customer can own many accounts, but each
account can only be owned by one customer (no joint
accounts) then the relationship is one-to-many
from the perspective of the back account, the
relationship is many-to-one
52

McFaddens Notation for Minimum

and Maximum Cardinality

Mandatory One
Mandatory One or Many
Optional Zero or One

Minimum
Cardinality

-the smallest number of

instances allowed to
participate in a
relationship

Maximum
Cardinality
- the greatest number of
instances allowed to
participate in a
relationship

Optional Zero, One or Many

53

Example of a Mandatory Oneto-One Relationship

PERSON

owns

CAR

1:1
Mandatory One

An instance of a person owns one car. (read from left to right )

An instance of a car is owned by one person (read from right to left )

54

Example of a Mandatory Oneto-Many Relationship

MEMBER

borrows

VCD

1:M

Mandatory One or Many

An instance of a member borrows one or more VCDs.
An instance of a VCD is borrowed by one member.

55

Example of a Mandatory Manyto-Many Relationship

STUDENT

takes

COURSE

M:N

Mandatory
One or Many
An instance of a student takes one or more courses.
An instance of a course is taken by one or more students.

56

Example of an Optional Zero,

One or Many Relationship
EMPLOYEE

Is
assigned
to

PROJECT
Optional Zero, One
or Many

The corresponding rule is that:

An employee is assigned to a number of projects, possibly none.
An instance of an employee is assigned to zero, one or many projects.
Given a project, there should be at least one employee (possibly many employees)
assigned to it.
57

Existence Dependency and

Weak Entity

58

Existence Dependency
Occurs

when an instance of one

entity cannot exist without the
existence of an instance of some
other (related) entity
PATIENT

has

HISTORY

59

PatientName

PatientNo

PatientNo

PATIENT

HistoryNo

HISTORY

has
Diagnosis

ConsultationDate

60

Weak and Strong Entities

Since HISTORY cannot exist without the

PATIENT entity, it is considered a weak
entity
NOTATION:

double rectangle

The PATIENT entity is called a strong

entity (others call it the mother entity)

61

Another way of explaining this:

The entity HISTORY has an existence
dependency on the entity PATIENT
That is, an instance of HISTORY cannot
exist unless the related PATIENT entity
exists

62

Two Approaches in
Conceptual Design

Top Down vs. Bottom-Up

top down
identify

the entity
identify the attributes
identify the relationship

bottom-up
entity,

attribute, and relationship names are

already given
just attach the attribute to its entity and
connect to the relationship
64

Top-down Example

in a video shop
entities

identified: media, member

attributes to be attached?
Availability

MemName

MemAddr

MEDIA

MediaNo

MEMBER
MemNo

Main_Actor

MediaTitle
65

Bottom-up Example

list given:
s_name
code
location

student
room
enrolls

course
address
yr_level

teacher
time
title

the ERD:
s_name

STUDENT

teacher

code

address

time

COURSE

has
location

yr_level

room

title

66