2.

High Level Database Models

SAIT204 - Databases
 Outline
• Entity/Relationship Model
• Design Principles
• Constraints
• Unified Modeling Language
• Object Definition Language
The Design Process
 Entity/Relationship Model
• In the entity-relationship model (or E/R
model), the structure of data is represented
graphically, as an “entity-relationship
diagram,” using three principal element types:
1. Entity sets,
2. Attributes, and
3. Relationships.
 Entity
• A real-world thing either living or non-living that
is easily recognizable and nonrecognizable.
• It is anything in the enterprise that is to be
represented in our database.
• It may be a physical thing or simply a fact about
the enterprise or an event that happens in the
real world.
• An entity can be place, person, object, event or a
concept, which stores data in the database.
 Entity Sets
• An entity set is a group of similar kind of
entities. It may contain entities with attribute
sharing similar values.
• Entities are represented by their properties,
which also called attributes.
• An attribute is a single-valued property of
either an entity-type or a relationship-type.
 Weak Entities
• A weak entity is a type of entity which doesn't
have its own identifying attribute.
• It can be identified uniquely by considering an
identifying attribute of another entity.
• For that, weak entity sets need to have
participation.
 Types of Attributes
• Simple/Atomics attribute: Simple attributes
can't be divided any further.
• Composite attribute: It is an attributes made
up of a number of component and can be
broken down e.g. full name
• Derived attribute: It has is value derived from
other attributes e.g. age
• Multivalued attribute: It contains multiple
values such e.g. phone number
 Relationships
• Relationships are connections among two or
more entity sets.
• While binary relationships, those between
two entity sets, are the most common
type of relationship
• E/R model allows relationships to involve any
number of entity sets e.g. ternary
relationships.
 One-to-One Relationships
• These occur when only one instance of an
entity is associated with the relationship, it is
marked as '1:1'.
 One-to-Many Relationships
• These occur when more than one instance of
an entity is associated with a relationship, it is
marked as '1:N'.
 Many-to-One Relationships
• These occur when more than one instance of
entity is associated with the relationship, it is
marked as 'N:1‘
 Many-to-Many Relationships
• These occur when many instances in one
entity sets is related to many entities in
another entity sets.
 Multiplicity: One-to-One
• Given two entity sets E and F:
– If each entity in E can at most be related to one
entity in F, and one entity in F can at most be
related to one entity in E then the relationship is a
one-to-one from E to F
 Multiplicity: One-to-Many
• Given two entity sets E and F:
– If each entity in E can be related to many entities
in F, and one entity in F can be related to at most
entity in E then the relationship is a one-to-many
from E to F
 Multiplicity: Many-to-Many
• Given two entity sets E and F:
– If each entity in E can be related to many entities
in F, and one entity in F can be related to many
entities in E then the relationship is a many-to-
many from E to F
 Keys
• A key is a set of attributes for one entity set such that no two
entities in this set agree on all the attributes of the key.
– It is allowed for two entities to agree on some, but not all,
of the key attributes.
• A key for an entity set E is a set K of one or more attributes
such that given any two entities e1 and e2 in E, e1 and e2
cannot have identical values for all the attributes in K.
• E can have multiple keys. We usually designate one as the
primary key.
• We must designate a key for every entity set.

17
 Keys in E/R Diagrams
• Underline the key attribute(s).
• In an Isa hierarchy, only the root entity set has a key,
and it must serve as the key for all entities in the
hierarchy.
name Beers manf

isa

color Ales
18
Example: a Multi-attribute Key

dept number hours room

Courses

19
 Referential Integrity Constraint
• Asserts that exactly one value exists in a given
context.
• Usually used in the context of relationships.
• Example: Many-one Advises relationship between
Students and Lecturers.
– Many-one requirement says that no student may
have more than one advising Lecturer.
– Referential integrity constraint says that each
student must have exactly one advising Lecturer
and that professor must be present in the set.
Enforcing Referential Integrity Constraints
• We forbid the deletion of a referenced entity (e.g., a lecturer)
until the lecturer advises no students.
• We require that if we delete a referenced entity, we delete all
entities that reference it.
• When we insert a student entity, we must specify an existing
lecturer entity connected to the student by the Advises
relationship.
 Weak Entity Sets
• Occasionally, entities of an entity set need
“help” to identify them uniquely.
• Entity set E is said to be weak if in order to
identify entities of E uniquely, we need to
follow one or more many-one relationships
from E and include the key of the related
entities from the connected entity sets.

22
 Database anomalies
• Insertion Anomaly: Inability to capture data as a
result of missing data that is related to the data
to be captured.
• Update Anomaly: a data inconsistency resulting
from missing an update to data due to the fact
that multiple copies of the data exists in multiple
locations.
• Deletion Anomaly: occurs when the deletion os
unwanted data results in the loss of important
data connected the data.
 Design Principles
• Faithfulness: Design should be faithful to the specifications of the
application. That is, entity sets and their attributes should reflect
reality.
• Avoiding Redundancy: Everything should be stated once so that we
do not encounter insertion, deletion and update anomalies in
future.
• Simplicity Counts: Avoid introducing more elements into your
design than is absolutely necessary.
• Choosing the Right Relationships: Entity sets can be connected in
various ways by relationships. However, adding to our design every
possible relationship is not often a good idea. Doing so can lead to
redundancy, update anomalies, and deletion anomalies, where the
connected pairs or sets of entities for one relationship can be
deduced from one or more other relationships.
 Design Principles
• Picking the Right Kind of Element: At times there
are options regarding the type of design element
used to represent a real-world concept. Many of
these choices are between using attributes
and using entity set/relationship combinations. In
general, an attribute is simpler to implement
than either an entity set or a relationship.
However, making everything an attribute will
usually results in anomalies.
 Example
• name is almost a key for football players, but there might be two
with the same name.
• number is certainly not a key, since players on two teams could
have the same number.
• But number, together with the Team related to the player by Plays-
on should be unique.

name number name

Players Plays- Teams

on

• Double diamond for supporting one-many relationship.

• Double rectangle for the weak entity set. 26
 Example: Bad

name name addr

Beers ManfBy Manfs

manf

This design states the manufacturer of a beer twice: as an

attribute and as a related entity.

27
 Example: Bad

name manf manfAddr

Beers

This design repeats the manufacturer’s address once for each

beer; loses the address if there are temporarily no beers for a
manufacturer.

28
 Example: Good

name name addr

Beers ManfBy Manfs

This design gives the address of each manufacturer exactly once.

29
 Entity Sets Versus Attributes
• An entity set should satisfy at least one of
the following conditions:
– It is more than the name of something; it has at
least one nonkey attribute.
or
– It is the “many” in a one-many or many-many
relationship.

30
 Example: Good

name name addr

Beers ManfBy Manfs

•Manfs deserves to be an entity set because of the nonkey

attribute addr.
•Beers deserves to be an entity set because it is the “many” of
the many-one relationship ManfBy.

31
 Example: Bad

name name

Beers ManfBy Manfs

Since the manufacturer is nothing but a name, and is not at the

“many” end of any relationship, it should not be an entity set.

32
 Example: Good

name manf

Beers

There is no need to make the manufacturer an entity set,

because we record nothing about manufacturers besides their
name.

33
Steps in Creating ERD
 Exercise
In a university, a Student enrolls in Courses. A
student must be assigned to at least one or
more Courses. Each course is taught by a single
Lecturer. To maintain instruction quality, a
Lecturer can deliver only one course
 From E/R Diagrams to Relations
1. Entity Type Rule: Each entity type (except subtypes)
becomes a table. The PK of ET (if not weak) becomes the
PK of the table. The attributes of the ET become columns
in the table. This rule should be used first before the
relationship rules.
2. 1-M Relationship Rule: Each 1-M relationship becomes a
FK in the table corresponding to the child type (the entity
type near Crow’s Foot symbol). If the minimum cardinality
on the parent side of the relationship is one, the FK
cannot accept null values (NOT NULL must be used).
3. M-N Relationship Rule: Each M-N relationship becomes a
separate table. The PK of the table is a combined
key consisting of the primary keys of the entity types
participating in the M-N relationship.