Jimma University

JIT Fundamentals of
Faculty of computing Database systems
&Informatics

Chapter Two
Database Modeling
Database Design Goes Through Stages

Problem

Requirements Analysis

Data
Requirements Data Analysis, Conceptual Design
Conceptual
Schema
Logical Database Design
Logical Schema
Physical Database Design

Physical
Schema
Slide 3- 2
 Conceptual and Logical Design

name

Conceptual Model: PRODUCT BUYS PERSON

price name ssn

Relational
Model: (plus
functional
dependencies)

Normalization:

Slide 3- 3
 Toy Example: University Database
Example queries we may want to ask:

• Which are the given and the family name of the

student with ID-number 5432?

• How many students are enrolled for the course

“Introduction to Databases”?

• For which courses is abebe enrolled?

Slide 3- 4
 University Data Requirements
• A student has a name, which consists of a given name and a family
name, and a student ID. Each student is uniquely identified by
his/her student ID.

• A course has a subject and a course ID. For each course, we want to
record the number of students taking that course. A course is
uniquely identified by its course ID.

• A student can be enrolled in an arbitrary number of courses, and an

arbitrary number of students can be enrolled in a course. For each
course in which they are enrolled students receive a lab mark and an
exam mark.

• A course cannot exist if there is no student enrolled in it.

• A school/dep’t is distinguished by the honour's degree that it awards.

We also want to record to which faculty a school belongs. A student is
registered with at most one school, while a school can have an
arbitrary number of students.

Slide 3- 5
 University Data Requirements (cntd.)
• A student is also registered for a semester of study. A semester of
study is identified by the year number between 1 and 4, and
semester number between 1 and 2. A student is registered for only
one semester of study.

• For each member of staff we want to record their name, degree

type, department and ID number. A member of staff is identified by
their ID number.

• Courses are taught by members of staff. A course can have several

teachers, and a staff member can teach several courses.

Slide 3- 6
 Conceptual Design with the ER Model
The questions to ask:
• What are the entities (= objects, individuals)
in the organization?
• Which relationships exist among the entities?
• What information (= attributes) do we want to store
about these entities and relationships?
• What are the business rules of the organization?
• Which integrity constraints do arise from them?

The answers are represented in an

Entity Relationship Diagram (ER diagram)

Slide 3- 7
 Entities and Entity Sets/Types
Entity: An object distinguishable from other objects
(e.g., an employee)
• An entity is described by a set of attributes.
Examples of entities?

Entity Set/Entity Type: A collection of similar entities

(e.g., all employees)
• All entities in an entity set have the same set of attributes.
• Each entity set has a key
(i.e., one or more attributes whose values
uniquely identify an entity)

Slide 3- 8
 Graphical Representation of Entity Sets
given family
courseno
no. of
students CrHr
name

STUDENT COURSE

IDno name

• Entity Sets are drawn as rectangles

• Attributes are drawn using ovals
• Simple attributes contain atomic values
• Composite attributes combine two or more
attributes
• Derived attributes are indicated by dashed lines
• The attributes making up the key are underlined
Slide 3- 9
 Composite Keys

Building
name
class

roomno

• Some entities cannot be uniquely identified by

the values of a single attribute …
• … but may be identified by the combination of two
or more attribute values
 several attributes together make up a
compound key

Slide 3- 10
 Multi-valued

previousDegree
STUDENT

• An entity may have multiple values for that attribute.

For example, Color of a CAR or PreviousDegrees of
a STUDENT.
• It is represented by double oval shape
 Relationships and Relationship Sets/Types
Relationship: An association between two or more
entities (e.g., “Joe Smith” is “enrolled” in “CS123”)
• Relationships may have attributes

Examples of relationships?

Relationship Set/Type: A collection of similar relationships

• An n-ary relationship type relates n entity types E1,…,En
• Each relationship involves n entities e1E1,…,en En

Examples of relationship sets?

Slide 3- 12
An Instance of a Relationship Type
Student Enrolled Course
St1 r1
C1
St2
r2 C2
St3
r3 C3
St4
r4
St5
….
St6 r5
…. r6
….

Student Enrolled Course

Slide 3- 13
 Graphical Representation of
Relationship Types

given family
courseno
no. of
name labmark students equip

STUDENT Enrolled COURSE

studno exammark subject

• Relationship sets are drawn as diamonds

Slide 3- 14
 Roles and Recursive Relationships
An entity type can
• participate in several name
relationship sets STAFF

and IDno
• participate more than once appraiser appraisee
in one relationship set Appraisal
(taking on different “roles”)

Which are other examples of recursive

relationships?

Slide 3- 15
 Multiplicity (cardinality) of
Relationship Types

1 1
• one-one: 1 a
2 b
3 c
d 1

• many-one: 1 a
2 b
3 c
d

1 a Sometimes the letters m, n are used

• many-many: 2 b
3 c to indicate the “many” side of
d relationships.

Slide 3- 16
 Participation Constraints

• Participation constraints specify whether or not an

entity must participate in a relationship set

• When there is no participation constraint, it is possible

that an entity will not participate in a relationship set

• When there is a participation constraint, the entity

must participate at least once

• Participation constraints are drawn using a

double line from the entity set to the relationship set

Slide 3- 17
 Mandatory Participation
Staff Works_for Department
St1 r1
D1
St2
r2 D2
St3
r3 D3
St4
r4
St5
….
St6 r5
…. r6
….

1
Staff Works_for Department

Slide 3- 18
 Many:many Relationship Type
with Optional and Mandatory Participation
Staff Teaches Course
St1 r1 C1
St2
r2 C2
St3
C3
St4 r3
r4 C4
St5
….
….
r5
r6
….

Staff Teaches Course

Slide 3- 19
 Recursive Relationship Type
with Optional Participation
Staff r1 Manages
St1 M
unmana St2 M
ged St3 E r2
E E
St4 r3
E M
St5 r4
E
St6 r5
…. M ….
M
Staff
M: Manager
E: Employee Manager Employee
Manages

Slide 3- 20
 Summary: Properties of Relationship Types
Degree
– The number of participating entity types

Cardinality ratios
– The number of instances of each of the participating
entity types which can partake in a single instance
of the relationship type:
1:1, 1:many, many:1, many:many

Participation
– Whether an entity instance has to participate
in a relationship instance
– Represented with a double line

Slide 3- 21
 Relationships of Higher Degree
Degree

– Relationship types of degree 2 are called binary

– Relationship types of degree 3 are called ternary

and of degree n are called n-ary

– In general, an n-ary relationship is not equivalent to

n binary relationships

Slide 3- 22
 Attributes in ER Modeling
• For every attribute we define
– Domain or data type
– Format, i.e., composite or atomic
– whether it is derived

• Every entity type must have as key an attribute

or a set of attributes
given family
courseno
no. of
name labmark student equip
s
STUDENT Enrolled COURSE

studno exammar subject

k

Slide 3- 23
 ER Model of the University DB
given family 1
SCHOO
studno name Reg L
hons
faculty
STUDENT

m year
YearReg
1
labmark YEAR

Enrolled Tutor 1

slot YearTut
exammark
or
1 1
n n name
courseno STAFF
m
COURSE Teach 1 m IDno
subject
appraiser appraisee
name
Apprais
al

Slide 3- 24
 Multiway (non-binary) Relationship
Relationships can involve more than two entity
types…
roomno
STAFF
STAFF
name
p
given family courseno
equip
name TUTOR
m S n
COURSE
STUDENT
subject
studno

Slide 3- 25
 Constraints: Definition

• A constraint is an assertion about the database that

must be true at all times

• Constraints are part of the database schema

Slide 3- 26
 Modeling Constraints
Finding constraints is part of the modeling process.
They reflect facts that hold in the world or
business rules of an organization.

Examples:
Keys: codice fiscale uniquely identifies a person
Single-value constraints: a person can have only one father
Referential integrity constraints: if you work for a company,
it must exist in the database
Domain constraints: peoples’ ages are between 0 and 150
Cardinality constraints: at most 100 students enroll in a course

Slide 3- 27
 Keys
A key is a set of attributes that
uniquely identify an object or entity:

Person: social-security-number (U.S.)

national insurance number (U.K.)
codice fiscale (Italy)
name
name + address
name + address + dob
(Why not “age”?)

Perfect keys are often hard to find,

so organizations usually invent something.

Slide 3- 28
 Variants of Keys

• Multi-attribute (composite) keys:

– E.g. name + address

• Multiple keys:
– E.g. social-security-number, name + address

Slide 3- 29
 Existence Constraints
Sometimes, the existence of an entity of type X
depends on the existence of an entity of type
Y:

Examples:
• Book chapters presume the existence of a book
• Tracks on a CD presume the existence of the CD
• Orders depend on the existence of a customer

We call Y the dominating entity type and

X the subordinate type

strong and weak entities
Slide 3- 30
 Weak Entity Types
 An entity that does not have a key attribute
 A weak entity must participate in an identifying
relationship type with an owner or identifying entity type
 Entities are identified by the combination of:
– A partial key of the weak entity type
– The particular entity they are related to in the
identifying entity type
Example:
Suppose that a DEPENDENT entity is identified by the
dependent’s first name and birhtdate, and the specific
EMPLOYEE that the dependent is related to.
DEPENDENT is a weak entity type with EMPLOYEE as
its identifying entity type via the identifying relationship
type DEPENDENT_OF
Slide 3- 31
 Strong and Weak Entities
Dominating and subordinate types are modeled as
• Entities
(also “strong”, or “identifying” entities)
and
• Weak entities
customer
Identifyin CUSTOMER
g entity address
1
Supporting, CUST-ORDER
or
identifying m orderid
relationship
ORDER
Weak
entity date

Slide 3- 32
 SUMMARY OF ER-DIAGRAM
NOTATION FOR ER SCHEMAS
Symbol Meaning

ENTITY TYPE

WEAK ENTITY TYPE

RELATIONSHIP TYPE

IDENTIFYING RELATIONSHIP TYPE

ATTRIBUTE

KEY ATTRIBUTE

MULTIVALUED ATTRIBUTE

COMPOSITE ATTRIBUTE

DERIVED ATTRIBUTE

E1 R E2 TOTAL PARTICIPATION OF E2 IN R

N CARDINALITY RATIO 1:N FOR E1:E2 IN R

E1 R E2

(min,max) STRUCTURAL CONSTRAINT (min, max) ON PARTICIPATION

R E OF E IN R

Slide 3- 33
 PROBLEM with ER notation

The Entity Relationship Model In Its Original

Form Did Not Support The Specialization/
Generalization Abstractions

Slide 3- 34
Extended Entity-Relationship (EER) Model

 Incorporates Set-subset relationships

 Incorporates Specialization/Generalization
Hierarchies

 Constraints on specialization/generalization
relationship ( Reading assignment)

Slide 3- 35
 Specialization/Generalization
 It is a relationships types between 2 entities; one
will be more general entity type and the other
entity type is specialized based on the general
entity.
 A superclass is an entity type that includes one or
more distinct subgroupings of its occurrences,

 A subclass is a distinct subgrouping of

occurrences of an entity type

Slide 3- 36
EER model
Example

Slide 3- 37
 EER model

StaffNo Name Postion Salary

STAFF

MANAGER SECRATERY SECRATERY

MgrStartDate Bonus SalesArea TypigSpeed

CarAllowance

Slide 3- 38
ER vs EER

Slide 3- 40
EER model

Attribute inheritance

Slide 3- 41
End!!!