4.

DATABASE DESIGN
The task of creating a database application is a complex one, involving design of the
database schema, design of programs that access and update the data, and design of a security
scheme to control access to data. The complexity arises mainly because of the identification of
relationships among individual components and their representation for maintaining correct
functionality. The degree of complexity increases if there are many-to-many relationships
among individual components.
The design of a complete database application environment that meets the needs of the
enterprise being modeled requires attention to a broad set of issues. In addition, aspects of the
expected use of the database influence a variety of design choices at physical, logical and view
levels. Database design process integrates relevant data in such a manner that it can be processed
through a mechanism for recording the facts. The process of database design usually requires a
number of steps which are shown in the figure below;

Database design process

1. Feasibility study
When designing a database, the purpose for which the database is being designed must be clearly
defined, i.e., the objective of creating the database must be crystal clear.
2. Requirement Collection and Analysis

1
In this step, the database designer has to decide what data are to be stored, and to some extent,
how that data will be used. Here, the users of the database play a central role and they must be
interviewed repeatedly. This helps in defining requirements in broad spectrum.
3. Prototyping and Design
Design implies a procedure for analyzing and organizing data into a form suitable to support
business requirements and make use of the strategic technology. In relational databases, design is
carried out in three phases, namely; conceptual design phase, logical design phase, and physical
design phase.
 Conceptual design phase – once requirements are gathered, they are then translated into
a conceptual schema of the database. The schema developed at this phase provides a
detailed overview of the database. Entity-relationship (ER) model is typically used to
represent conceptual design. In terms of ER model, the conceptual schema specifies the
entities that are represented in the database, the attributes of the entities, the relationships
among the entities, and the constraints on the entities and relationships. Generally, the
conceptual design phase results in the creation of Entity-Relationship Diagram that
provides a graphical representation of the schema.
 Logical design phase – in this phase, the designer maps the high-level conceptual
schema onto the implementation data model of the database system that will be used. The
implementation data model is typically the relational data model, and this step usually
consists of mapping the conceptual schema defined using ER model into a relation
schema.
 Physical design phase – in this phase, the designer uses the resulting system-specific
database schema to specify the physical features of the database. It is the phase in which
physical features of DB are specified. These features include the form of file or
organization and choice of index structures.
NB: the physical schema of a DB can be changed relatively easily after an application has been
built. However, changes to logical schema are usually challenging to carry out since they may
affect queries and updates across DB application. It is therefore, important to carry out DB
design phases with care before building the rest of the DB application.
4. Implementation
This step involves development of code for database processing, and also the installation of new
database contents, usually from existing data sources.

2
 5. Validation and Testing
This step involves carrying out various tests to ensure that the DB application meets all the
requirements specified and conforms to the enterprise’s technological strategy.
6. Operation
Finally, the DB is installed at users’ workplaces and start serving the purpose it was intended for.
Qualities of a bad database design
In designing a database, we must ensure that we avoid two major pitfalls:
1. Redundancy: a bad design may repeat information. The biggest problem with such
redundant representation of information is that copies of a piece of information can
become inconsistent if the information is updated without taking precautions to update all
copies of the information. Ideally, with good design, information should appear in exactly
one place.
2. Incompleteness: a bad design may make certain aspects of the enterprise difficult or
impossible to model. It then becomes impossible to represent all the required information.
One might try to make a problematic design work by storing null values for information
sections but such work-around is not only unattractive, but may be prevented by various
defined constraints.
Database modeling
A model is an abstract or simplified representation of the end product. Before developing any
meaningful product, it is always important to model it first using diagrams, symbols, notations,
and in some cases, visual objects.
Models are developed due to the following reasons
1. Provides a cost effective way for analyzing and amending the requirements.
2. Provides a chance for interaction and discussion between the developer and the end user.
3. Provides blue print (template) for future developments.
4. Provides an adequate documentation opportunity.
In database development, modeling usually takes place at the conceptual level of the database
architecture. The two commonly used database modeling techniques are:
1. Entity-Relationship Modelling (ERM) using Entity-Relationship Diagrams (ERDs).
2. Data Normalization- where flat or unstructured files are converted to well-structured
relations that contain minimum redundancy or other anomalies.

3
Entity-Relationship Modeling (ERM)
This is a set of diagrammatic standards for representing a database structure. This concept was
initially proposed by Peter Chen in 1976. ER diagram is the graphical modeling tool that is used
to standardize ER modeling. It consists of three building blocks which are; Entity, Attribute and
Relationship.
1. Entity
An entity is an object that exists and is distinguishable from other objects. In other words, it is a
real life object that is capable of independent existence and that can be uniquely identified.
For example, a particular student, say Berly Awiti is an entity. A particular department, say IT
department is an entity.
An entity has a set of properties, and values for some set of properties may uniquely identify that
entity. Entities may share same properties or attributes, i.e., a set of entities of the same type,
forms an entity set. For example, a set of all people who are instructors at a given university can
form entity set Instructor, and set of all students in university represent entity set student.
Entity sets can be strong or weak entities. A strong entity is one whose existence does not
depend on other entity. For example, a student takes a course. Here the student is a strong entity
because if there are no students to take a particular course, then that course cannot be offered. On
the other hand, a weak entity is one whose existence depends on other entity. For example,
course entity is considered weak.
In ER model, entities are represented by a rectangular box with the entity name inside it. That is,

E.g.
Entityname STUDENT

Entity names should always be in singular forms, e.g., STUDENT but not STUDENTS. This is
done for the following reasons;
 Consistency –so as to conform to the standards of naming entities
 Communication- as it is something that we want to keep information about.
 For compatibility with relationship names
2. Attributes
Attributes are descriptive properties possessed by each member of an entity set. That is, they are
properties or characteristics that further describe a given entity. Each entity in an ERD is
assigned its relevant attributes which are classified into key attributes (primary and foreign keys)

4
and non-key attributes. A good start point is identification of primary keys. These are usually
depicted alongside their associated entities and underlined. For example,

STUDENT RegNo, Surname, othernames,……..,etc.

NB: after adding the key attributes, non-key attributes are added and separated by commas.
Other previously used methods for allocating attributes to entities are;
 The ORACLE CASE Tool format

STUDENT
RegNo
Surname
Othernames
.
.
etc

 The data dictionary format

STUDENT = RegNo, Surname, othernames, …..etc
STUDENT

NB: Attributes can be characterized by the following attribute types;

 Simple and composite attributes – Simple attributes cannot be divided into subparts but
composite attributes can be divided into subparts.
 Single-valued and multivalued attributes – Single-valued attributes have single values for
a particular entity, e.g. ID number. That is, there is only one value associated with that
attribute while multivalued attributes, there are more than one value associated with that
attribute, e.g. Employee skills.
 Derived attribute – attribute whose value can be derived from values of other related
attributes or entities, e.g. age can be derived from date of birth of a person.

3. Relationships
A relationship is an association among several entities. It indicates an interaction or a link
between the two entities involved. It’s mainly between the primary key of one entity and foreign
key in the other entity. Straight line between entities usually indicates a relationship.
Relationships can be broadly classified into three types (mapping cardinalities), namely;
 One-to-one (1:1) relationship – the relationship signifies that for each instance of an
entity, there is one related instance of the other. That is, an entity in A is associated with
at most one entity in B, and an entity in B is associated with at most one entity in A. It is
shown via straight-line joining the two entities, e.g.

CAR DRIVER5
 Where this type of relationship exists, the primary key of each entity exists as a foreign
key in the other. The primary keys in such relationships are also usually the same and it is
often questioned whether or not the two entities should be separate. Thus why the model
acknowledges 1:1 existence and it is not often used or seen in full scale relational
databases.
 One-to-Many (1:M) relationship – this signifies that for each instance of an entity there is
1 or more related instances of the other. That is, an entity in A is associated with any
number (zero or more) of entities in B, and an entity in B can be associated with at most
one entity in A.
For example,

BUS PASSENGER

The relationship shows a straight line with a crow’s foot on the many side of the
relationship. Where this type of relationship exists, the primary key of the one side entity
also exist a foreign key on the many side entity. The many side entity primary key is
however not a foreign key on the other side entity. This is the most commonly used
relationship in database modeling and occurs in almost every ER model.
 Many-to-Many (M:M) – this signifies that for each instance of A, there is 1 or more
related instance of B and vice-versa. That is, an entity A is associated with any number
(zero or more) of entities in B, and an entity B is associated with any number (zero or
more) of entities in A.
This is shown by a straight line that has crow’s feet on both sides.
For example,

STUDENT UNIT

Where this type of relationship exists, the primary keys of each entity should exist as
foreign keys in the other entity. Due to the complexity of actual implementation of the
logic behind this relation, the diagram is usually modified, that is, Resolved.
This process is achieved through three steps as follows;
 A new entity is created as an intermediary between the two existing entities.
 The original entities both form a 1:M relationship with an intermediary entity.
 The new entity inherits the primary key attributes of the two entities.
For example, we can resolve the above ERD to

STUDENT CLASS UNIT

6
 While naming the newly created entity, it is important to consider whether it is a real life
object and give it a corresponding name. If not, then a common technique is to name the entity
with a hybrid name of the two original entities. For example,

STUDENT STUDENT_UNIT UNIT

To increase the amount of information on an ER model, occurrences or optionalities of the

participants in the relationship are indicated. This depicts an entity as mandatory or optional to
the other. Consider the example below.

1 0 1- Mandatory
WOMAN CHILD
0- optional

The child entity is optional to the woman since a woman can exist with or without the child
while the woman entity is said to be mandatory to child since the child cannot exist without
woman. Similarly, in the diagram below,

1 1
SURGEON SURGERY
1

OR

2 1 0
SURGEON SURGERY

In the first figure, every surgeon must have performed surgery and a surgery must have been
performed by a surgeon. In the second figure, a surgeon may or may not have performed surgery.

NB: a common task for a database designer is to create an ER model from a written problem
statement provided to them by a client.

Examples

1. In a given housing unit, there may be a given number of tenants at any given time. Each
of these tenants owns specific possessions; however, it is possible for certain possessions
to be jointly owned by two or more tenants. The company requires a database that will
allow tenants to track down which possessions they have ownership of and their values so
as to allow fair distribution of property when a unit is vacated. At the moment each tenant
fills out a form which his/her ID number and personal details along with serial number,
brand, description, and cost of any item they own.
Draw an ER diagram depicting all the relationships and any occurrences or optionality.
Solution
First, determine the Entities and the associated attributes.

7
 Entities Attributes
1. TENANT ID#, surname, othernames, phoneno, address
2. UNIT Unit#, location, size, rent_amount
3. POSSESSION Serial#, brand, description, cost

This can be modeled as shown in the ER diagram below

UNIT TENANT POSSESSION

Unit#, ….. ID#, …. Serial#, …….

However, the relationship that exists between TENANT and POSSESSION entities
is a many-to-many relationship and must be resolved. Therefore, we create a new entity that will
be an intermediary between these two entities and inherit their primary key attributes. Since a
tenant owns a possession, we call the new entity OWNERSHIP and introduce it in the initial ER
diagram. We then add optionalities for the purpose of depicting mandatory and optional entities.
Thus, the final ER diagram, which has no complexity of actual implementation, resembles the
following;

UNIT 1 0 TENANT 1 1 OWNERSHIP

ID#, Serial#
1
Unit#, … ID#, …, Unit#
1 Serial#, ….
POSSESSION

NB: attributes underlined with a single line are primary keys and those underlined with
double lines are foreign keys.

2. A database is required to help schedule events for a fitness center. The center consists of
many participants who are allowed to take part in either one, two or three events. The
participant’s number, name, gender and number of events registered for are captured. In
addition, the event number and number of participants in the event are also detailed. This
is because an event must consist of at least eight participants. Event managers are
strategically placed such that one manager can take care of at most three events.
However, an event is handled by only one manager. Manager number, names and number
of events he/she is handling is recorded.
Draw an ERD to illustrate the above requirements. Provide relevant relationships and
optionalities.

8
Solution

Entities Attributes

PARTICIPANT Participant#, name, gender, no_of_events

EVENT Event#, no_of_participants
MANAGER Manager#, name, events_handled
CENTER Center#, location, no_of_participants

CENTER PARTICIPANT EVENT

Resolve MANAGER

Introduce an intermediary entity

CENTER 1 0 PARTICIPANT 1 0 REGISTRATION

Center#,.. Participant#,..., Center# Participant#,
0 Event#

1
Event#,…, Manager#
EVENT

1
Manager#,….. MANAGER

A company has several departments each department has a supervisor and at least one
employee. Employee must be assigned to at least one, but possibly more departments. At least
one employee is assigned to a project, but an employee may be on vacation and not assigned to
any projects. The important data fields are the names of the employees, as well as the
supervisor and employee number and unique project number.

9
 Develop and draw a fully attributed ERD

SUPERVISOR
DEPATMENT
Supervisor Number (PK)
Department Name (PK)

EMPLOYEE
EMPLOYEE-DEPARTMENT
Employee Number(PK)
Department Name (PK)(FK)

EMPLOYEE-PROJECT
PROJECT
Employee Number(PK)(FK)
Project Number(PK)

UPS prides itself on having up-to-date information on the processing and current location of each
shipped item. To do this, UPS relies on a company-wide information system. Shipped items are
the heart of the UPS product tracking information system. Shipped items can be characterized by
item number (unique), weight, dimensions, insurance amount, destination, and final delivery
date. Shipped items are received into the UPS system at a single retail center. Retail centers are
characterized by their type, uniqueID, and address. Shipped items make their way to their
destination via one or more standard UPS transportation events (i.e., flights, truck deliveries).
These transportation events are characterized by a unique scheduleNumber, a type (e.g, flight,
truck), and a deliveryRoute.
Create an Entity Relationship diagram that captures this information about the UPS system. Be
certain to indicate identifiers and cardinality constraints.

10
11