UNIT THREE

Database Design
Database design is the process of coming up with different kinds of specification for the data to
be stored in the database. The database design part is one of the middle phases we have in
information systems development (DBS) where the system uses a database approach. Design is
the part on which we would be engaged to describe how the data should be perceived at different
levels and finally how it is going to be stored in a computer system.
The DBS has different development lifecycles. From which the design part is sub divided into
three sub-phases. These sub-phases are:
1. Conceptual Database Design
2. Logical Design Database, and
3. Physical Database Design
In developing a good design, one should answer such questions as:
 What are the relevant Entities for the Organization
 What are the important features of each Entity
 What are the important Relationships
 What are the important queries from the user
 What are the other requirements of the Organization and the Users

The Three levels of Database Design

Conceptual Design

Logical Design

Physical Design
Conceptual Database Design
Conceptual design is the process of constructing a model of the information used in an
enterprise, independent of any physical considerations.

1
  It is the source of information for the logical design phase.
 Mostly uses an Entity Relationship Model to describe the data at this level.
 After the completion of Conceptual Design one has to go for refinement of the schema,
which is verification of Entities, Attributes, and Relationships.

Logical Database Design

Logical design is the process of constructing a model of the information used in an enterprise
based on a specific database model (e.g. Relational, Hierarchical or Network or Object), but
independent of a particular DBMS and other physical considerations.
Normalization process
– Collection of Rules to be maintained.
– Discover new entities in the process.
– Revise attributes based on the rules and the discovered Entities.
Physical Database Design
Physical design is the process of producing a description of the implementation of the database
on secondary storage. -- defines specific storage or access methods used by database.
o Describes the storage structures and access methods used to achieve efficient access to
the data.
o Tailored to a specific DBMS system -- Characteristics are function of DBMS and
operating systems.
o Includes estimate of storage space.

NOTE:
In conceptual data model/Design
o Identify what are the entities/entity types
o Identify what are the attributes: - the information about entities and relationship should we store
in the database.
o Identify relationship types
o Identify what are the constraints/business rules that hold?
o Draw entity-relationship diagram: - representing the database in the ER model using pictorial
representation called ER diagram
In logical data model/Design

2
o Map the conceptual model to a logical model
o Mapping entities and relationships in ER-Diagram into tables
-Translate ER-diagram with constraints
o Derive relations from the logical data model
o Validate model using normalization
o Draw entity-relationship diagram
o Define integrity constraints
o Check for future growth

NB: Startng from this we are going to design database using the relational database model.

Conceptual Database Design

Conceptual design revolves around discovering and analyzing organizational and user data
requirements. The important activities are to identify
o Entities
o Attributes
o Relationships
o Constraints
And based on these components develop the ER model using
 ER diagrams
The Entity Relationship (E-R) Model
An entity-relationship (E-R) data model is a high-level conceptual model that describes data as
entities, attributes, and relationships. The E-R model is represented by E-R diagrams that show
how data will be represented and organized in the various components of the final database.
However, the model diagrams do not specify the actual data, or even exactly how it is stored.
The users and applications will create the data content and the database management system will
create the database to store the content.
Entity-Relationship modeling is used to represent conceptual view of the database. The main
components of ER Modeling are:
 Entities
o Corresponds to entire table, not row

3
  Attributes
o Represents the property used to describe an entity or a relationship
 Relationships
o Represents the association that exist between entities
 Constraints
o Represent the constraint in the data

ENTITY - RELATIONSHIP DIAGRAMS (E-RD)

As one important aspect of E-Relationship data modeling, database designers represent their data
model by E-R diagrams. These diagrams enable designers and users to express their
understanding of what the planned database is intended to do and how it might work, and to
communicate about the database through a common language. Each organization that uses E-R
diagrams must adopt a specific style for representing the various components.

Graphical Representations in ER Diagramming

 Entity is represented by a rectangle containing the name of the entity.

Strong Entity Weak Entity

 Connected entities are called relationship participants

 Attributes are represented by ovals and are connected to
the entity by a line.
Oval
Ovals Ovals Ovals Oval

Multi-valued Composite Oval

Attribute Attribute Attribute
 A derived attribute is indicated by a dotted line. (……..)
Oval
 Primary Keys are underlined. Key
 Relationships are represented by Diamond shaped symbols
 Weak Relationship is a relationship between Weak and Strong Entities.
 Strong Relationship is a relationship between two strong Entities.

Strong Relationship Weak Relationship

4
Developing an E-R Diagram
Designing conceptual model for the database is not a one linear process but an iterative activity
where the design is refined again and again. To identify the entities, attributes, relationships, and
constraints on the data, there are different set of methods used during the analysis phase. These
include information gathered by.
 Interviewing end users individually and in a group
 Questionnaire survey
 Direct observation
 Examining different documents
Example 1: Build an E-R Diagram for the following information:
A student record management system will have the following two basic data object categories
with their own features or properties: Students will have an Id, Name, Dept, Age, GPA and
Course will have an Id, Name, Credit Hours. Whenever a student enroll in a course in a specific
Academic Year and Semester, the Student will have a grade for the course.

Name Dept DoB Id Name Credit

Id Gpa
Students Courses

Age

Enrolled_In Semester
Academic
Year

Grade

Example 2: Build an ER Diagram for the following information:

A Personnel record management system will have the following two basic data object categories
with their own features or properties: Employee will have an Id, Name, DoB, Age, Tel and

5
 Department will have an Id, Name, Location. Whenever an Employee is assigned in one
Department, the duration of his stay in the respective department should be registered.

Structural Constraints on Relationship

1. Constraints on Relationship/Multiplicity/ Cardinality Constraints: Multiplicity constraint is the
number or range of possible occurrence of an entity type/relation that may relate to a single
occurrence/tuple of an entity type/relation through a particular relationship. Mostly used to insure
appropriate enterprise constraints.
One-to-one relationship:
E.g.: Relationship Manages between STAFF and BRANCH.
The multiplicity of the relationship is:
 One branch can only have one manager.
 One employee could manage either one or no branches.

1..1 0..1
Employee Manages Branch

One-To-Many Relationships
E.g.: Relationship Leads between STAFF and PROJECT
The multiplicity of the relationship is:
 One staff may Lead one or more project(s)
 One project is Lead by one staff

1..1 0..*
Employee Leads Project

Many-To-Many Relationship
E.g.: Relationship Teaches between INSTRUCTOR and COURSE
The multiplicity of the relationship
 One Instructor Teaches one or more Course(s)
 One Course Thought by Zero or more Instructor(s)

6
 0..* 1..*
Instructor Teaches Course

2. Participation of an Entity Set in a Relationship Set=Particpation constraints

Participation constraint of a relationship is involved in identifying and setting the mandatory or
optional feature of an entity occurrence to take a role in a relationship. There are two distinct
participation constraints with this respect, namely: Total Participation and Partial Participation.
1. Total participation: every tuple in the entity or relation participates in at least one
relationship by taking a role. This means, every tuple in a relation will be attached with at
least one other tuple. The entity with total participation in a relationship will be
connected to the relationship using a double line.
2. Partial participation: some tuple in the entity or relation may not participate in the
relationship. This means, there is at least one tuple from that Relation not taking any role
in that specific relationship. The entity with partial participation in a relationship will be
connected to the relationship using a single line.
E.g. 1: Participation of EMPLOYEE in “belongs to” relationship with
DEPARTMENT is total since every employee should belong to a department.
Participation of DEPARTMENT in “belongs to” relationship with EMPLOYEE is
total since every department should have more than one employee.

Employee Belongs To Department

E.g. 2: Participation of employee in “manages” relationship with Department, is

partial participation since not all employees are managers. Participation of department
in “Manages” relationship with employee is total since every department should have
a manager.
Problem in ER Modeling
While Employee Manages Department
designing
the ER model one could face a problem on the design which is called a connection traps.
Connection traps are problems arising from misinterpreting certain relationships.
There are two types of connection traps;
7
 1. Fan trap:
Occurs where a model represents a relationship between entity types, but the pathway
between certain entity occurrences is ambiguous.
May exist where two or more one-to-many (1:M) relationships fan out from an entity.
The problem could be avoided by restructuring the model so that there would be no 1:M
relationships fanning out from a singe entity and all the semantics of the relationship is
preserved.
Example:
1..* 1..1 IsAssigned
Works 1..*
Employee 1..1 Branch Car
Semantics description of the problem;
For

Emp1 Bra1 Car1

Emp2 Bra2 Car2
Emp3 Bra3 Car3
Emp4 Bra4 Car4
Emp5 Car5
Emp6 Car6
Emp7 Car7

Problem: Which car (Car1 or Car3 or Car5) is used by Employee 6. Emp6 working in Branch 1
(Bra1). Thus from this ER Model one can not tell which car is used by which staff since a branch
can have more than one car and also a branch is populated by more than one employee. Thus we
need to restructure the model to avoid the connection trap.

To avoid the Fan Trap problem we can go for restructuring of the E-R Model. This will result in
the following E-R Model.
1..1 Has 1..* 1..* Used By 1..*
Branch Car Employee
Semantics description of the problem;
Car1
Bra1 Emp1
Car2
Bra2 Emp2
Car3
Bra3 Emp3
Car4 8
Bra4 Emp4
Car5
Emp5
Car6
Emp6
 2. Chasm Trap:
Occurs where a model suggests the existence of a relationship between entity types, but
the path way does not exist between certain entity occurrences.
May exist when there are one or more relationships with a minimum multiplicity on
cardinality of zero forming part of the pathway between related entities.
Example:

1..1 Has 1..* 0..1 Manages 0..*

Branch Employee project

If we have a set of projects that are not active currently then we can not assign a project manager
for these projects. So there are project with no project manager making the participation to have
a minimum value of zero.
Problem:
How can we identify which BRANCH is responsible for which PROJECT? We know that
whether the PROJECT is active or not there is a responsible BRANCH. But which branch is a
question to be answered, and since we have a minimum participation of zero between employee
and PROJECT we can’t identify the BRANCH responsible for each PROJECT.

The solution for this Chasm Trap problem is to add another relationship between the extreme
entities (Branch and Project).

1..1 Has 1..* 0..1 Manages 0..*

Branch Employee project

1..1 Responsible for 1..*

Enhanced E-R (E-ER) Model

9
Object-oriented extensions to E-R model. EER is important when we have a relationship
between two entities and the participation is partial between entity occurrences. In such cases
EER is used to reduce the complexity in participation and relationship complexity. ER diagrams
consider entity types to be primitive objects. EER diagrams allow refinements within the
structures of entity types.

EER Concepts: In this part we will discuss the following basic EER concepts.
Generalization
Specialization
Sub classes
Super classes
Attribute Inheritance
Constraints on specialization and generalization
Generalization
Generalization occurs when two or more entities represent categories of the same real-world
object. Generalization is the process of defining a more general entity type from a set of more
specialized entity types. A generalization hierarchy is a form of abstraction that specifies that
two or more entities that share common attributes can be generalized into a higher level
entity type. Generalization is considered as bottom-up definition of entities.
Generalization hierarchies can be nested. That is, a subtype of one hierarchy can be a
supertype of another. The level of nesting is limited only by the constraint of simplicity.
Example: Account is a generalized form for Saving and Current Accounts.

Specialization

10
Specialization is the result of subset of a higher level entity set to form a lower level entity set.
The specialized entities will have additional set of attributes (distinguishing characteristics) that
distinguish them from the generalized entity. Is considered as Top-Down definition of entities.
Specialization process is the inverse of the Generalization process. Identify the distinguishing
features of some entity occurrences, and specialize them into different subclasses.

Reasons for Specialization are:

 Attributes only partially applying to superclasses.
 Relationship types only partially applicable to the superclass.
Example: Saving Accounts and Current Accounts are Specialized entities for the generalized
entity Accounts. Manager, Sales, Secretary: are specialized employees.

Subclass/Subtype
An entity type whose tuples have attributes that distinguish its members from tuples of the
generalized or Superclass entities. When one generalized Superclass has various subgroups with
distinguishing features and these subgroups are represented by specialized form, the groups are
called subclasses. Subclasses can be either mutually exclusive (disjoint) or overlapping
(inclusive). A single subclass may inherit attributes from two distinct superclasses. A mutually
exclusive category/subclass is when an entity instance can be in only one of the subclasses. E.g.:
An EMPLOYEE can either be SALARIED or PART-TIMER but not both.
An overlapping category/subclass is when an entity instance may be in two or more subclasses.
E.g.: A person who works for a university can be both employee and a student at the same time.
Superclass /Supertype
An entity type whose tuples share common attributes. Attributes that are shared by all entity
occurrences (including the identifier) are associated with the supertype. Superclass /Supertype Is
the generalized entity.

Relationship Between Superclass and Subclass

The relationship between a superclass and any of its subclasses is called a superclass/subclass or
class/subclass relationship. An instance can not only be a member of a subclass. i.e. Every
instance of a subclass is also an instance in the Superclass. A member of a subclass is
represented as a distinct database object, a distinct record that is related via the key attribute to its

11
super-class entity. An entity cannot exist in the database merely by being a member of a
subclass; it must also be a member of the super-class. An entity occurrence of a sub class not
necessarily should belong to any of the subclasses unless there is full participation in the
specialization. The relationship between a subclass and a Superclass is an “IS A” or “IS PART
OF” type.
 Subclass IS PART OF Superclass
 Manager IS AN Employee

All subclasses or specialized entity sets should be connected with the superclass using a line to a
circle where there is a subset symbol indicating the direction of subclass/superclass relationship.

We can also have subclasses of a subclass forming a hierarchy of specialization. Superclass

attributes are shared by all subclasses f that superclass. Subclass attributes are unique for the
subclass.

Attribute Inheritance
An entity that is a member of a subclass inherits all the attributes of the entity as a member of the
superclass. The entity also inherits all the relationships in which the superclass participates. An
entity may have more than one subclass categories. All entities/subclasses of a generalized entity
or superclass share a common unique identifier attribute (primary key). i.e. The primary key of
the superclass and subclasses are always identical.

12
Consider the EMPLOYEE supertype entity shown above. This entity can have several different
subtype entities (for example: HOURLY and SALARIED), each with distinct properties not
shared by other subtypes. But whether the employee is Hourly or Salaried, same attributes
(EmployeeId, Name, and DateHired) are shared. The Supertype EMPLOYEE stores all
properties that subclasses have in common. And HOURLY employees have the unique attribute
Wage (hourly wage rate), while SALARIED employees have two unique attributes, StockOption
and Salary.

Constraints on specialization and generalization

1. Completeness Constraint.
The Completeness Constraint addresses the issue of whether or not an occurrence of a Superclass
must also have a corresponding Subclass occurrence. The completeness constraint requires that
all instances of the subtype be represented in the supertype. The Total Specialization Rule
specifies that an entity occurrence should at least be a member of one of the subclasses. Total
Participation of superclass instances on subclasses is diagrammed with a double line from the
Supertype to the circle as shown below. E.g.: If we have Extention and regular as subclasses of a
superclass student, then it is mandatory that each student to be either Extention or regular
student. Thus the participation of instances of student in Extention and regular subclasses will be
total.

13
The Partial Specialization Rule specifies that it is not necessary for all entity occurrences in the
superclass to be a member of one of the subclasses. Here we have an optional participation on
the specialization. Partial Participation of superclass instances on subclasses is diagrammed with
a single line from the Supertype to the circle. E.g.: If we have Manager and Secretary as
subclasses of a superclass Employee, then it is not the case that all employees are either manager
or secretary. Thus the participation of instances of employee in manager and secretary subclasses
will be partial.

2. Disjointness Constraints
Specifies the rule whether one entity occurrence can be a member of more than one subclasses.
i.e. it is a type of business rule that deals with the situation where an entity occurrence of a
Superclass may also have more than one Subclass occurrence. The Disjoint Rule restricts one
entity occurrence of a superclass to be a member of only one of the subclasses. Example: a
Employee can either be salaried or part-timer, but not the both at the same time. The Overlap
Rule allows one entity occurrence to be a member f more than one subclass. Example:
Employee working at the university can be both a Student and an employee at the same time.
This is diagrammed by placing either the letter "d" for disjoint or "o" for overlapping inside the
circle on the Generalization Hierarchy portion of the E-R diagram.

The two types of constraints on generalization and specialization (Disjointness and

Completeness constraints) are not dependent on one another. That is, being disjoint will not
favour whether the tuples in the superclass should have Total or Partial participation for that
specific specialization.

From the two types of constraints we can have four possible constraints
@ Disjoint AND Total :- E.g: Employee is always be salaried or part time, but it can’t be
both.
@ Disjoint AND Partial :- E.g: Employe can’t be manager and secretary, also can be none
of the two.
@ Overlapping AND Total :- E.g: Student is always be regular or extension, and it can be
both.

14
@ Overlapping AND Partial :- E.g: Person can be employee and student, also can be none
of the two.

15