Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                

Lecture 2 Entity Relationship Modelling

Download as pdf or txt
Download as pdf or txt
You are on page 1of 55

By:

OkelloEmmanuel

Email: emmokelloj@gmail.com
Phone: 0784990516
 How to use Entity–Relationship (ER) modeling
in database design.
 Basic concepts associated with ER model.
 Diagrammatic technique for displaying ER
model using Unified Modelling Language (UML).
 How to identify and resolve problems with ER
models called connection traps.
 How to build an ER model from a requirements
specification.

2
 This involves transforming human level data
collected in form of user requirements into a
universally understandable entity relationship
model.
This helps in the following:
 Identifying and resolving traps: Traps may occur
where in real life relationships cannot be
represented and after computerizing may
actually get lost.
 Elimination of ambiguity: Ambiguity can be
caused about due to different interpretation of
a problem, hence different representation.

3
 Foundation for entity and referential
integrity:
ER Modelling provides a foundation for
integrity before the database is
implemented.

4
 Entity
 Entity types
 Relationship types
 Attributes
 Entity Occurrence (Instance)

5
 Entity: An entity is a data object to be
modelled/stored in a database
application. The entity may be physical
(like student, staff) or logical (like course
unit). An entity can be strong or weak.
 Entity type
◦ The set of all possible values for an entity,
such as all possible students.
 Entity occurrence (Instance)
◦ Uniquely identifiable object of an entity type
e.g. employee john.

6
7
 Strong Entity Type: This is an entity whose
occurrences exist in their own rights in the
modelled system. If one is developing a
database application for university students,
then a course unit, student, staff, lecture
theater, etc are strong entities.
 Weak Entity Type: This is an entity whose
occurrences’ existence depend on the existence
of specific occurrences in other entities. In a
database application for university students,
parent and next of kin are weak entities.

8
9
 Attribute: Is a characteristic that helps
distinguish different occurrences of the same
entity. For example for a student entity, the
possible attributes are registration number,
student number, names, date of birth, etc
 Attribute Domain
◦ Set of allowable values for one or more
attributes. For example the types of values,
whether numeric or alphabet, the number of
digits, etc

10
 Simple Attribute (SA)
◦ Attribute composed of a single component with an
independent existence.

 Composite Attribute (CA)


◦ This is an attribute that can have different
components for the same entity occurrence.
Examples of composite attribute include address,
etc

11
 Single-valued Attribute
◦ Attribute that holds a single value for
each occurrence of an entity type e.g. a
person can have only one NIN.
 Multi-valued Attribute (MVA)
◦ This is an attribute that can have
different entries/values for the same
entity occurrence. Examples of multi-
valued attributes include telephone
number, academic qualifications
12
 Derived Attribute (/)
◦ This is an attribute whose value can be
derived from another attribute, not
necessarily in the same entity type. Age, for
example, is a derived attribute of date of
birth.
The size of the attribute set depends
on the amount of information required in
the application being developed.
13
 Candidate Key
◦ Minimal set of attributes that uniquely identifies
each occurrence of an entity type.
 Primary Key
◦ Candidate key selected to uniquely identify each
occurrence of an entity type.
 Composite Key
◦ A candidate key that consists of two or more
attributes.

14
 Alternate Keys
◦ Candidate keys that are not selected to be
primary key.

 Foreign Key
◦ Attribute, or set of attributes, within one
relation that matches candidate key of some
(possibly same) relation.

15
16
 Derived from the fact that a database consists of
related data meaning that the entities must be
related according to the application being
developed.
 Relationship type
◦ Set of meaningful associations among entity types.

 Relationship occurrence
◦ Uniquely identifiable association, which includes
one occurrence from each participating entity type.

17
18
19
 Degree of a Relationship
◦ Number of participating entities in relationship.
 Types
◦ One is cyclic
◦ two is binary
◦ three is ternary
◦ four is quaternary.
◦ More than two is tertiary. These are normally broken
down into multiple cyclic and binary relationships.

20
21
22
23
 Recursive Relationship
◦ Relationship type where same entity type participates
more than once in different roles.

 Relationships may be given role names to


indicate purpose that each participating entity
type plays in a relationship.

24
25
26
27
28
 Main type of constraint on relationships is called
multiplicity.
 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.
 Represents policies (called business rules)
established by user or company.

29
 Multiplicity is made up of two types of restrictions
on relationships: cardinality and participation.
 Cardinality
◦ Describes maximum number of possible
relationship occurrences for an entity
participating in a given relationship type.
 Participation
◦ Determines whether all or only some entity
occurrences participate in a relationship.

30
31
 The most common degree for relationships
is binary.
 Binary relationships are generally referred
to as being:
◦ one-to-one (1:1)
◦ one-to-many (1:*)
◦ many-to-many (*:*)

32
 Entities A and B have a one-to-one
relationship if a single occurrence in A
can be mapped onto at most one
occurrence in B and a single occurrence
in B can be mapped onto a maximum of
one occurrence in A.
 Examples include the relationships
between

◦ A football team and a captain,


◦ A president and a country
◦ A university and a vice chancellor, etc

33
34
35
 Entities A and B have a one-to-many
relationship if a single occurrence in A
(B) can be mapped onto a maximum of
one occurrence in B (A) but a single
occurrence in B(A) can be mapped onto a
maximum of more than one occurrences
in A(B).
 Examples include a relationship between
◦ a child and a mother,
◦ a soldier and an army,
◦ a student and a university, etc

36
37
38
 Entities A and B have a many-to-many
relationship if a single occurrence in A
can be mapped onto more than one
occurrences in B and a single occurrence
in B can be mapped onto multiple
occurrences in A.
 Examples include the relationship
between

◦ students and course units they offer

39
40
41
42
 Problems may arise when designing a
conceptual data 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.

43
 Fan Trap
◦ Where a model represents a relationship
between entity types, but pathway between
certain entity occurrences is ambiguous.
 Chasm Trap
◦ Where a model suggests the existence of a
relationship between entity types, but
pathway does not exist between certain
entity occurrences.

44
45
 At
which branch office does staff
number SG37 work?

46
47
 SG37 works at branch B003.

48
49
 At which branch office is property PA14
available?

50
51
52
53
54
1. Identify entity types (entity type vs. attribute)
2. Identify relationship types
3. Identify and associate attributes with entity and
relationship types
4. Determine attribute domains
5. Determine primary key attributes for entity types
6. Associate (refined) cardinality ratio(s) with
relationship types
7. Design generalization/specialization hierarchies
including constraints (includes natural language
statements as well)

55

You might also like