Chapter 3
Chapter 3
1
Outlines
Using High level Data Models for Database Design
Entity types and Sets, Attributes and Keys
Relationships, Roles and Structural Constraints
Weak Entity Types
Database Abstraction
E/R Diagram naming conventions, and Design issues
2
Database Design
Database design consists of several tasks:
Requirements Analysis,
Conceptual Design, and Schema Refinement,
Logical Design,
Physical Design and Tuning
In general, one has to go back and forth between these tasks to refine
a database design, and decisions in one task can influence the choices
in another task.
In developing a good design, one should ask:
What are the important queries and updates?
What attributes/relations are involved?
3
The Three levels of Database Design
Constructing a model independent of any physical
Conceptual considerations.
Design After the completion of Conceptual Design one has to go for
refinement of the schema, which is verification of Entities,
Attributes, and Relationships
5
The Entity Relationship (E-R) Model
Entity-Relationship modeling is used to represent conceptual view of
the database
The main components of ER Modeling are:
Entities
Corresponds to entire table, not row
Represented by Rectangle
Attributes
Represents the property used to describe an entity or a relationship
Represented by Oval
Relationships
Represents the association that exist between entities
Represented by Diamond
Constraints
Represent the constraint in the data
6
The Entity Relationship (E-R) Model … Cont’d
8
Developing an E-R Diagram … Cont’d
The basic E-R model is graphically depicted and presented for review.
The process is repeated until the end users and designers agree that the
E-R diagram is a fair representation of the organization’s activities and
functions.
Checking for Redundant Relationships in the ER Diagram.
Relationships between entities indicate access from one entity to
another.
It is therefore possible to access one entity occurrence from another
entity occurrence even if there are other entities and relationships that
separate them.
This is often referred to as Navigation' of the ER diagram
The last phase in ER modeling is validating an ER Model against
requirement of the user.
9
Graphical Representations in ER Diagramming
Entity is represented by a RECTANGLE containing the name of the
entity.
10
Graphical Representations in ER Diagramming .. Cont’d
A derived attribute is indicated by a DOTTED LINE.
(……..)
11
Graphical Representations in ER Diagramming .. Cont’d
12
Graphical Representations in ER Diagramming .. Cont’d
13
Entity versus Attributes
Consider designing a database of employees for an organization:
Should address be an attribute of Employees or an entity (connected
to Employees by a relationship)?
If we have several addresses per employee, address must be an entity
(attributes cannot be set-valued/multi valued)
If the structure (city, Woreda, Kebele, etc) is important.
E.g. want to retrieve employees in a given city, address must be
modeled as an entity (attribute values are atomic)
Cardinality on Relationship expresses the number of entity
occurrences/tuples associated with one occurrence/tuple of related
entity.
14
Entity versus Attributes … Cont’d
Existence Dependency: the dependence of an entity on the existence
of one or more entities.
Weak entity: an entity that can not exist without the entity with
which it has a relationship
Participating entity in a relationship is either optional or
mandatory.
15
Structural Constraints on Relationship
1. Constraints on Relationship / Multiplicity/ Cardinality Constraints
Multiplicity constraint is the number of 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:
A customer is associated with at most one loan via the relationship
borrower
A loan is associated with at most one customer via borrower
16
Structural Constraints on Relationship .. Cont’d
17
Structural Constraints on Relationship .. Cont’d
18
Structural Constraints on Relationship .. Cont’d
One-to-Many Relationships
In the one-to-many relationship a loan is associated with at most one
customer via borrower, a customer is associated with several
(including 0) loans via borrower
19
Structural Constraints on Relationship .. Cont’d
20
Structural Constraints on Relationship .. Cont’d
• Many-To-Many Relationship
21
Structural Constraints on Relationship .. Cont’d
22
Participation of an Entity Set in a Relationship Set
23
Participation of an Entity Set in a Relationship Set .. Cont’d
24
Problem in ER Modeling
The Entity-Relationship Model is a conceptual data model that views
the real world as consisting of entities and relationships.
The model visually represents these concepts by the Entity-
Relationship diagram.
While 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;
1. Fan trap
2. Chasm trap
25
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.
26
Fan trap … Cont’d
28
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:
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.
29
Chasm Trap … Cont’d
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 relation
ship between the extreme entities (BRANCH and PROJECT)
30