0% found this document useful (0 votes)
22 views

Chapter 3

Uploaded by

Mezgebe Abebe
Copyright
© © All Rights Reserved
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
22 views

Chapter 3

Uploaded by

Mezgebe Abebe
Copyright
© © All Rights Reserved
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 30

Chapter 3

Database Design using Entity Relationship Model

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

Constructing a model of the information used in an enterprise


based on a specific data model (e.g. relational, hierarchical or
Logical
network or object), but independent of a particular DBMS and
Design other physical considerations.

• Producing a description of the implementation of the


database on secondary storage.
• Describes the storage structures and access methods used to
Physical achieve efficient access to the data.
Design • Tailored to a specific DBMS system -- Characteristics are
function of DBMS and operating systems
• Includes estimate of storage space
4
Conceptual Database Design
 Conceptual design revolves around discovering and analyzing
organizational and user data requirements
 The important activities are to identify
 Entities
 Attributes
 Relationships
 Constraints
 And based on these components develop the ER model using
 ER diagrams

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

Before working on the conceptual design of the database, one has to


know and answer the following basic questions.
 What are the entities and relationships in the enterprise?
 What information about these entities and relationships should we
store in the database?
 What are the integrity constraints that hold?
 Constraints on each data with respect to update, retrieval and store.
 Represent this information pictorially in ER diagrams, then map ER
diagram into a relational schema
7
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

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.

 Connected entities are called relationship participants


 Attributes are represented by OVALS and are connected to the
entity by a line.

10
Graphical Representations in ER Diagramming .. Cont’d
 A derived attribute is indicated by a DOTTED LINE.
(……..)

 PRIMARY KEYS are underlined.

 Relationships are represented by DIAMOND shaped symbols

11
Graphical Representations in ER Diagramming .. Cont’d

Example : Build an ER Diagram for the following information:


 Students
 Have an Id, Name, Dept, Age, Gpa
 Courses
 Have an Id, Name, Credit Hours
 Students enroll in courses and receive a grade

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

Total participation: every entity in the entity set participates in at least


one relationship in the relationship set.
 The entity with total participation will be connected with the
relationship using a double line.

E.g. : Participation of EMPLOYEE in “belongs to” relationship with


DEPARTMENT is total since every employee should belong to a
department.

23
Participation of an Entity Set in a Relationship Set .. Cont’d

E.g.: Participation of EMPLOYEE in “manages” relationship with


DEPARTMENT, DEPARTMENT will have total participation but not
EMPLOYEE

Partial participation: some entities may not participate in any


relationship in the relationship set
E.g.: Participation of EMPLOYEE in “manages” relationship with
DEPARTMENT, EMPLOYEE will have partial participation since not all
employees are managers.

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

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.
27
Fan trap … Cont’d
 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.

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

You might also like