Lecture 3

Lecture 3
Database Modelling
Objectives
• How to use ER modeling in

database design.
• The basic concepts of an ER

model called entities,
relationships, and attributes.
Objectives
Diagrammatic technique for displaying ER model using

Unified Modeling Language (UML).
How to identify and resolve problems with ER models

called connection traps.
How to build an ER model from a requirements

specification
A diagrammatic technique for displaying an ER model.
ER diagram of Branch user views of
DreamHome
ER modeling
Top-down approach to database design.
Start by identifying the important data (called entities)

and relationships between the data.
ER modeling
• Then add more details such as the information we want to

hold about the entities and relationships (called
attributes) and any constraints on the entities,
relationships, and attributes.
Business Entities
To produce information for decision making, organizations

need data.
Although each application will have its own entities, they
generally fall into the following categories :
• Person
• Place
• Thing
• Concept
• Event
Entity – Relationship Modeling
• ER Modeling describes how business entities

are organized and related to one another.
• Purpose – to provide a set of normalized
relations which can be used to design a
database that is consistent and free from
redundancy.
Entity Relationship Symbols
Entity
Relationship
Attribute Primary Key

Entities
Entity
A set of objects with the same
properties, which are identified by a
user or organization as having an
independent existence.
Entity occurrence
Each uniquely identifiable object within
a set.
Entities with physical and conceptual existence
ER diagram of entities
Relationships
• Relationship
A set of meaningful associations among
entities.
• Relationship occurrence
Each uniquely identifiable association
within a set.
ER diagram of relationships
Relationships
Degree of a relationship
• Number of participating entities in
relationship.
Relationship of degree :
• two is binary
• three is ternary
• four is quaternary.
Binary relationship called POwns
Example of ternary relationship
Quaternary relationship called Arranges
Recursive relationships
• Relationship where same entity

participates more than once in different
roles.
• Relationships may be given role names to
indicate purpose that each participating
entity plays in a relationship.
Example of a recursive relationship
Entities associated through two distinct
relationships with role names
Attributes
• Property of an entity or a relationship.

• Hold values that describe each occurrence
of an entity or relationship, and
represent the main source of data stored
in the database.
Attributes
Attribute can be classified as being:

• simple or composite
• single-valued or multi-valued
• or derived
Attributes
• Simple attribute
Attribute composed of a single
component with an independent
existence.
• Composite attribute
Attribute composed of multiple
components, each with an independent
existence.
Attributes
• Single-valued attribute
Attribute that holds a single
value for an entity occurrence.
• Multi-valued attribute
Attribute that holds multiple
values for an entity occurrence.
Attributes
• Derived attribute
Attribute that represents a value
that is derivable from value of a
related attribute, or set of
attributes, not necessarily in
the same entity.
ER diagram of entities and their attributes
Strong and weak entities
• Strong entity
Entity that is not dependent on the
existence of another entity for its
primary key.
• Weak entity
Entity that is partially or wholly
dependent on the existence of another
entity, or entities, for its primary
key.
Strong entity type called Client and weak
entity type called Preference
Multiplicity constraints on relationships
• Represents the number of occurrences of one

entity that may relate to a single occurrence of
an associated entity.
• Represents policies (called business rules)

established by user or company.
Multiplicity constraints
• Multiplicity - number (or range) of possible

occurrences of an entity type that may
relate to a single occurrence of an
associated entity type through a particular
relationship.
The most common degree for relationships is

binary.
Multiplicity constraints
• Binary relationships are generally referred

to as being:
one-to-one (1:1)
one-to-many (1:*)
many-to-many (*:*)
1:1 relationship
– individual examples
1:1 relationship
– multiplicity
1:* relationship
1:* relationship
– multiplicity
Multiplicity of Staff Oversees
PropertyForRent (1:*) relationship type
*:* relationship
*:* relationship
– multiplicity
Multiplicity of Newspaper Advertises
PropertyForRent (*:*) relationship
Complex relationships
• Multiplicity is the number (or

range) of possible occurrences
of an entity type in an n-ary
relationship when other (n-1)
values are fixed.
Complex relationship
Complex relationship
– multiplicity
Summary of multiplicity constraints
Multiplicity
• Made up of two types of restrictions on

relationships:
cardinality and participation
Multiplicity
• Cardinality
Describes the number of possible
relationships for each participating
entity.
• Participation
Determines whether all or only some
entity occurrences participate in a
relationship.
Multiplicity as cardinality and participation constraints
Relationship with attributes
Problems with ER models
• Problems may arise when designing an ER model called

connection traps.
• Often due to a misinterpretation of the meaning of
certain relationships.
• Two main types of connection traps are called fan
traps and chasm traps.
• Fan trap
Two entities have a 1:*
relationship that fan out from a
third entity, but the two entities
should have a direct relationship
between them to provide the
necessary information.
An example of a fan trap
Fan trap
– individual example
Cannot tell which member of staff uses car SH34.
52
Restructuring ER model to remove Fan
Trap
Fan trap resolved – individual
example
Can now tell which car staff use.
54
• Chasm trap
A model suggests the existence of a
relationship between entities, but
the pathway does not exist between
certain entity occurrences.
An example of a chasm trap
Chasm trap
– individual example
Cannot tell which branch staff S0003 works at.
57
Resolving the chasm trap
Chasm trap resolved – individual
example
Can now tell which branch each member of staff works at . 59

Another design technique
DFD –
Data
Flow
Diagram
60

Lecture 3

Uploaded by

Copyright:

Available Formats

Lecture 3

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Lecture 3

Uploaded by

Copyright:

Available Formats

Lecture 3

• How to use ER modeling in

• The basic concepts of an ER

Diagrammatic technique for displaying ER model using

How to identify and resolve problems with ER models

How to build an ER model from a requirements

Top-down approach to database design.

Start by identifying the important data (called entities)

• Then add more details such as the information we want to

To produce information for decision making, organizations

• ER Modeling describes how business entities

Attribute Primary Key

• Relationship where same entity

• Property of an entity or a relationship.

Attribute can be classified as being:

• Represents the number of occurrences of one

• Represents policies (called business rules)

• Multiplicity - number (or range) of possible

The most common degree for relationships is

• Binary relationships are generally referred

• Multiplicity is the number (or

• Made up of two types of restrictions on

• Problems may arise when designing an ER model called

Cannot tell which member of staff uses car SH34.

Can now tell which car staff use.

Cannot tell which branch staff S0003 works at.

Can now tell which branch each member of staff works at . 59

You might also like