DATABASE DESIGN

Database design
- primary objective is to create complete, normalized, non-redundant (to the extent possible), and fully
integrated conceptual design, logical and physical database models

Data Models – simple representation, basically graphical, of more complex real-world object or event

Conceptual Design
- data modeling is used to create an abstract database structure that represents real-world objects in
the most realistic way possible

Conceptual model – uses the widely used ER model which is illustrated with the help of the ERD

Logical Design
− translates the conceptual design into the internal model for a selected database management system
(DBMS) such as DB2, SQL Server, MySQL, Oracle and Access
− arrange data into a logical structure which can then be mapped into the storage objects supported by
DMBS; in case of relational databases, the storage objects are tables which store data in rows and
columns

Physical Design
− the process of selecting the data storage and data access characteristics of the database
− a detailed design of a system that includes modules and the database’s hardware and software
specifications of the system

Four steps in Conceptual Design

1) Data Analysis and Requirements

Focus on:
 Information needs. What kind of information is needed? That is, what output (reports and
queries) must be generated by the system, what information does the current system
generate, and to what extent is that information adequate?
 Information users. Who will use the information? How is the information to be used?
 Information sources. Where is the information to be found? How is the information to be
extracted once it is found?
 Information constitution. What data elements are needed to produce the information? What
are the data attributes. What relationships exist among the data? What is the data volume?
How frequently are the data used? What transformations are to be used to generate the
required information?

To develop an accurate data model, the designer must have a thorough understanding of the
business rules to fully understand how the business works and what role the data plays within
company operations. Business rules are derived from a detailed description of an organization’s
operations.
Examples of business rules are follows:
 A department employs many employees but each employee is employed by
one department.
 Some employees may be assigned to any department.
 A division operates many departments, but each department is operated by one
division.
 An employee may be assigned many projects, and a project may have many
employees assigned to it.

Database Design 1
  A project must have at least one employee assigned to it.
 One of the employees manages each department, and each department is
managed by only one employee.
2) Entity Relationship Modeling and Normalization

Entity Relationship Model (ERM)

- graphical representation of entities and their relationships in a database structure

- normally represented in an entity relationship diagram (ERD), which is a model that identifies the
concepts or entities that exist in a system and the relationships between those entities

Components of Entity Relationship Model:

 Entity
− anything (person, place, thing or event) about which data are to be collected and stored
− represents a particular type of type of object in the real world
− represented in the ERD by a rectangle, also known as the entity box
− the name of the entity is a noun which is written in the center of the rectangle and is
generally written in capital letters and in a singular form
− entity names:
 should be nouns that are familiar to business and should be short and
meaningful
 should include abbreviations, synonyms and aliases for each entity
 should be unique within the model
 for composite entities, may include a combination of abbreviated names of the
entities linked through the composite entity

Examples: TAPE, MEMBER

ERD symbol:

 Attribute
− describes a particular characteristic of an entity
− equivalent to fields in file systems
− entity CUSTOMER for example will have attributes customer_no, name, address
− represented by ovals and are connected to the entity rectangle with a line; each oval
contains the name of the attribute it represents
− attribute names:
 should be unique within the entity
 should use the entity abbreviation or prefix
 should be descriptive of the characteristic
 should use suffixes such as _id, _num or _code for the primary key attribute or
identifier (identifier is the attribute or combination of attributes that uniquely
identifies entity instances in an entity set)
 should not be a reserved word
 should not contain spaces or special characters such as @, ! or &

Database Design 2
 ERD symbol:

 Relationships
− describe the associations among entities
− the name of the relationship is an active or passive verb
− represented by a diamond
Example: rents
MEMBER rents a TAPE (MEMBER and TAPE are entities)

ERD symbol:
Sample:

Tape_Cod
Id_Num
e

Title
MEMBER rents TAPE

Name

Relationship Degree

A relationship degree indicates the number of entities or participants associated with a relationship. A unary
relationship exists when an association is maintained within a single entity. A binary relationship exists when two
entities are associated. A ternary relationship exists when three entities are associated. Although higher
degrees exist, they are rare and are not specifically named. (For example, an association of four entities is
described simply as four-degree relationship).

Unary Relationship

EMPLOYEE manage
s

Binary Relationship

teache
PROFESSOR CLASS
s

Ternary Relationship

VENDOR ships WAREHOUSE

Database Design 3
 PART

Database Design 4
CONNECTIVITY and CARDINALITY

Connectivity – used to describe the relationship classification

Data Models use 3 types of relationship:

1:1 one-to-one relationship
1:M one-to-many relationship
M:N many-to-many relationship (M:N is the standard label for many-to-many
relationship but M:M may be also be used)

Example1 (1:1): An EMPLOYEE manages one STORE; each STORE is managed by one EMPLOYEE.

1 1
manag
EMPLOYEE STORE
es

Example2 (1:M): A PAINTER can paint many PAINTINGs; each PAINTING is painted by one PAINTER.

1 M
paint
PAINTER PAINTING
s

Example3 (M:N): An EMPLOYEE can learn many job SKILLs; each job skill can be learned by many
EMPLOYEEs.

M N

EMPLOYEE learns SKILL

Cardinality
− expresses the minimum and maximum number of entity occurrences associated with one
occurrence of the related entity

Minimum Cardinality
− the smallest number of instance allowed to participate in a relationship
− 0 or 1 (if 0, participation is optional; if 1, participation is mandatory)
− Ex. the minimum number of mother that a person can have is 1

Maximum Cardinality
− the greatest number of instances allowed to participate in a relationship
Ex. a STUDENT is allowed to retake the COURSE twice

Database Design 5
Notation:

One and only one. One side is mandatory.

One or many. Many side is mandatory.

Zero or one. One side is optional.

Zero or many. Many side is optional.

Example1: An EMPLOYEE manages one STORE; each STORE is managed by one EMPLOYEE.

manag
EMPLOYEE STORE
es

Example2: A PAINTER can paint many PAINTINGs; each PAINTING is painted by one PAINTER.

paint
PAINTER s PAINTING

Example3: An employee can learn many skills; each skill can be learned by many employee.

EMPLOYEE learns SKILL

Example4:

is
EMPLOYEE assigne PROJECT
d

Example5: A class may exist (at least at the start of registration) even though it contains no students. When a
student is admitted to college, that student has not (yet) signed up for any classes, therefore, at least initially,
class is optional to student.

STUDENT enrolls CLASS

Database Design 6
n

Database Design 7
Existence Dependency and Weak Entity

− occurs when an instance of one entity cannot exist without the existence of an instance of some other
(related) entity

Example:

PATIENT has HISTORY

 an instance of HISTORY cannot exist unless the related PATIENT entity exists
 in this case, HISTORY is a weak entity (an entity type that has an existence dependency)

Multivalued Attributes
− attributes that can have many values
− example: person having several college degrees and mobile numbers
− multivalued attributes are shown as follows:

Example:

nam addres
e s

skill
emp
EMPLOYEE
#

 skill is a special kind of attribute because an instance of an EMPLOYEE can have more than one value for
the attribute skill. Simply put “an employee may have/possess more than one skill”
 in a relational database model, the multivalued attribute is removed as an attribute of the original entity and is
made into a separate entity. The relationship HAS is established as the relationship between the original entity
and the newly created entity, originally the multivalued attribute.

nam addres skill#

e s Skill_nam
e

emp#
EMPLOYEE has SKILL

Repeating Group
− a set of two or more multivalued attributes that are logically related
Example: PATIENT chart

Database Design 8
 Patient No. : 02-1234
Patient Name : Macario, Jose
Address : Dumaguete City

Date of Visit Physician Symptom

07/23/2006 Dr. Gonzales Fever
02/15/2007 Dr. Suarez Cough
12/03/2008 Dr. Lim …

This can be represented by:

symptom
name

visit_date
patient# PATIENT

physician

address

 the repeating group is removed and a separate entity type will be created where these attributes will be
associated

symptom
name patient# patient#

physician

address
PATIENT has HISTORY

visit_date

 take note that patient# is one of the primary keys of the entity HISTORY. Since HISTORY is a weak entity
and is therefore dependent on the existence of PATIENT, an identifying relationship will exist. In this
relationship, the primary key of the parent entity is used as part of the primary key of the dependent entity. This
usually exists whenever existence dependency occurs between entities

RELATIONSHIPS WITH ATTRIBUTES

Example:
date_re
id# t
date_borr

address book# title

name

STUDENT borro BOOK

ws

Database Design 9
 this indicates that if a student will borrow a book, your database design should be able to record when that
book was borrowed and when it is supposed to be returned.

(Continuation – Four Steps in Conceptual Design)

3) Data Model Verification
ER model must be verified against the proposed system processes in order to confirm that the intended
processes can be supported by the database model

4) Distributed Database Design

Portions of a database may reside in several physical locations. If the database process is to be
distributed across the system, the designer must also develop the data distribution and allocation
strategies for the database.

References:
• Carlos, P. and Coronel, R. Database Systems. Philippines: Course Technology, 2009.
• Hoffer, J., Prescott, M. and McFadden, F. Modern Database Management 7th Edition © 2005

Database Design 10