Chapter Three

Database Modeling
 Introduction to ODL
• ODL(Object Definition Language) is intended
to define object types that can be
implemented in a variety of programming
languages.
• This language's purpose is to define the
structure of an Entity-relationship diagram.
 ER model

The ER model describes data as entities, relationships, and

attributes.

The basic object that the ER model represents is an entity,

which is a "thing" in the real world with an independent
existence. Example: employee

Each entity has attributes the particular properties that describe

it. For example, an employee entity may be described by the
employee's name, age, address, salary, and job.
A particular entity will have a value for each of its attributes.

3
 Types of Attributes
• Composite versus Simple (Atomic) Attributes.
Composite attributes can be divided into smaller
subparts, which represent more basic attributes with
independent meanings. Attributes that are not
divisible are called simple or atomic attributes. The
value of a composite attribute is the concatenation of
the values of its constituent simple attributes.
• Single-Valued versus Multi-valued Attributes. Most
attributes have a single value for a particular entity;
such attributes are called single-valued.

4
 Types of Attributes
• Stored versus Derived Attributes. For a particular
person entity, the value of Age can be determined
from the current (today's) date and the value of that
person's Birth Date. The Age attribute is hence called
a derived attribute and is said to be derivable from the
BirthDate attribute, which is called a stored attribute.
• Null Values. In some cases a particular entity may not
have an applicable value for an attribute. For
example, a person with no college degree would have
null for College_Degrees.
• Complex Attributes. Is a result of composite and
multi-valued attributes which are nested in an
arbitrary way 5
 Example Company Database
• We need to create a database schema design
based on the following (simplified)
requirements of the COMPANY Database:
– The company is organized into DEPARTMENTs.
Each department has a name, number and an
employee who manages the department. We
keep track of the start date of the department
manager. A department may have several
locations.
– Each department controls a number of PROJECTs.
Each project has a unique name, unique number
and is located at a single location.
ER Diagram
 Attributes of Relationship Types

Relationship types can also have attributes, similar to those of

entity types.

For many relationship types, some attributes may be

determined by the combination of participating entities in a
relationship instance, not by any single entity. Such attributes
must be specified as relationship attributes.

16
 Refining the Company database
schema by introducing relationships
• By examining the requirements, six relationship types are
identified
• All are binary relationships( degree 2)
• Listed below with their participating entity types:
– WORKS_FOR (between EMPLOYEE, DEPARTMENT)
– MANAGES (also between EMPLOYEE, DEPARTMENT)
– CONTROLS (between DEPARTMENT, PROJECT)
– WORKS_ON (between EMPLOYEE, PROJECT)
– SUPERVISION (between EMPLOYEE (as subordinate), EMPLOYEE
(as supervisor))
– DEPENDENTS_OF (between EMPLOYEE, DEPENDENT)
 Cont…
• In the refined design, some attributes from the initial entity
types are refined into relationships:
– Manager of DEPARTMENT -> MANAGES
– Works_on of EMPLOYEE -> WORKS_ON
– Department of EMPLOYEE -> WORKS_FOR, etc
• In general, more than one relationship type can exist between
the same participating entity types
– MANAGES and WORKS_FOR are distinct relationships between
EMPLOYEE and DEPARTMENT
– Different meanings and different relationship instances.
 Recursive Relationship Type
• An relationship type whose with the same participating entity
type in distinct roles
– Example: the SUPERVISION relationship
• EMPLOYEE participates twice in two distinct roles:
– supervisor (or boss) role
– supervisee (or subordinate) role
• Each relationship instance relates two distinct EMPLOYEE
entities:
– One employee in supervisor role
– One employee in supervisee role
ER Diagram Notation for ER Schemas

12
ER Diagram
 Relationships and Relationship Types
• A relationship relates two or more distinct entities with a
specific meaning. For example, EMPLOYEE Abebe
Kebede works on the ProductX PROJECT or
EMPLOYEE Zinash Solomon manages the Research
DEPARTMENT.
• Relationships of the same type are grouped or typed into
a relationship type. For example, the WORKS_ON
relationship type in which EMPLOYEEs and PROJECTs
participate, or the MANAGES relationship type in which
EMPLOYEEs and DEPARTMENTs participate.
• The degree of a relationship type is the number of
participating entity types. Both MANAGES and
WORKS_ON are binary relationships. Relationship types
of degree 2 are called binary. Relationship types of
degree 3 are called ternary and of degree n are called n-
ary
Role Names and Recursive Relationships
• The role name signifies the role that a participating entity
from the entity type plays in each relationship instance, and
helps to explain what the relationship means. For example, in
the WORKS_FOR relationship type, EMPLOYEE plays the
role of employee or worker and DEPARTMENT plays the
role of department or employer.
• In some cases the same entity type participates more than
once in a relationship type in different roles. Such
relationship types are called recursive relationships. The
SUPERVISION relationship type relates an employee to a
supervisor, where both employee and supervisor entities are
members of the same EMPLOYEE entity type. Hence, the
EMPLOYEE entity type participates twice in
SUPERVISION: once in the role of supervisor (or boss), and
once in the role of supervisee (or subordinate).
15
 Attributes of Relationship Types

Relationship types can also have attributes, similar to those of

entity types.

For many relationship types, some attributes may be

determined by the combination of participating entities in a
relationship instance, not by any single entity. Such attributes
must be specified as relationship attributes.

16
 Refining the Company database
schema by introducing relationships
• By examining the requirements, six relationship types are
identified
• All are binary relationships( degree 2)
• Listed below with their participating entity types:
– WORKS_FOR (between EMPLOYEE, DEPARTMENT)
– MANAGES (also between EMPLOYEE, DEPARTMENT)
– CONTROLS (between DEPARTMENT, PROJECT)
– WORKS_ON (between EMPLOYEE, PROJECT)
– SUPERVISION (between EMPLOYEE (as subordinate), EMPLOYEE
(as supervisor))
– DEPENDENTS_OF (between EMPLOYEE, DEPENDENT)
UML class diagram for COMPANY
database schema
 Recursive Relationship Type
• An relationship type whose with the same participating entity
type in distinct roles
– Example: the SUPERVISION relationship
• EMPLOYEE participates twice in two distinct roles:
– supervisor (or boss) role
– supervisee (or subordinate) role
• Each relationship instance relates two distinct EMPLOYEE
entities:
– One employee in supervisor role
– One employee in supervisee role
 Notation for Constraints on
Relationships
• Cardinality ratio (of a binary relationship): 1:1, 1:N, N:1,
or M:N
– SHOWN BY PLACING APPROPRIATE NUMBERS ON THE
RELATIONSHIP EDGES.
• Participation constraint (on each participating entity
type): total (called existence dependency) or partial.
– TOTAL SHOWN BY DOUBLE LINE, PARTIAL BY SINGLE LINE.
• Alternative (min, max) notation
– Specifies that each entity e in E participates in at least min
and at most max relationship instances in R
– Default(no constraint): min=0, max=n

• NOTE: These are easy to specify for Binary Relationship

Types.
Company ER Schema Diagram using (min,
max) notation
 Constraints on Relationships
• Must have minmax, min0, max 1. example
– A department has exactly one manager and an employee can manage
at most one department.
• Specify (0,1) for participation of EMPLOYEE in MANAGES
• Specify (1,1) for participation of DEPARTMENT in MANAGES
– An employee can work for exactly one department but a department
can have any number of employees.
• Specify (1,1) for participation of EMPLOYEE in WORKS_FOR
• Specify (1,n) for participation of DEPARTMENT in WORKS_FOR
 Problem with ER modeling tools
• DIAGRAMMING
– Poor conceptual meaningful notation.
– To avoid the problem of layout algorithms and aesthetics
of diagrams, they prefer boxes and lines and do nothing
more than represent (primary-foreign key) relationships
among resulting tables.(a few exceptions)
• METHODOLGY
– lack of built-in methodology support.
– poor tradeoff analysis or user-driven design preferences.
– poor design verification and suggestions for improvement.
• The entity relationship model in its original form did not
support the specialization/generalization abstractions
Solution: EER (Enhanced-ER model)
23
 EER Modeling concepts
• Includes all modeling concepts of basic ER
• classes (similar to entity types) as large rounded boxes with
three sections:
– Top section includes entity type (class) name
– Second section includes attributes
– Third section includes class operations (operations are not in
basic ER model)
• Relationships (called associations) represented as lines
connecting the classes
– Other UML terminology also differs from ER terminology
• Used in database design and object-oriented software design
• Additional concepts: subclasses/superclasses,
specialization/ generalization, categories, attribute
inheritance
• It includes some object-oriented concepts, such as
inheritance
 Specialization
• Is the process of defining a set of subclasses of a superclass
• The set of subclasses is based upon some distinguishing
characteristics of the entities in the superclass
• Example: {SECRETARY, ENGINEER, TECHNICIAN} is a
specialization of EMPLOYEE based upon job type.
– May have several specializations of the same superclass

Generalization
• The reverse of the specialization process
• Several classes with common features are generalized into a
superclass; original classes become its subclasses
• Example: CAR, TRUCK generalized into VEHICLE; both CAR,
TRUCK become subclasses of the superclass VEHICLE.

25
 Specialization and Generalization
• Eg. all person entities represented in the database are
members of the PERSON entity type, which is specialized
into the subclasses {EMPLOYEE, ALUMNUS, STUDENT}. This
specialization is overlapping; for example, an alumnus may
also be an employee and may also be a student pursuing an
advanced degree. The subclass STUDENT is the superclass
for the specialization {GRADUATE_STUDENT,
UNDERGRADUATE_STUDENT}, while EMPLOYEE is the
superclass for the specialization {STUDENT_ASSISTANT,
FACULTY, STAFF}. Notice that STUDENT_ASSISTANT is also a
subclass of STUDENT. Finally, STUDENT_ASSISTANT is the
superclass for the specialization into
{RESEARCH_ASSISTANT, TEACHING_ASSISTANT}
Specialization / Generalization Framework
Example (UNIVERSITY)
UML class diagram for COMPANY
database schema
 Constraints and Characteristics of
Specialization and Generalization
• the disjointness (or disjointedness) constraint, which
specifies that the subclasses of the specialization must
be disjoint. If the subclasses are not constrained to be
disjoint, their sets of entities may be overlapping; that
is, the same (real-world) entity may be a member of
more than one subclass of the specialization.
• the completeness (or totalness) constraint, which may
be total or partial. A total specialization constraint
specifies that every entity in the superclass must be a
member of at least one subclass in the specialization. A
single line is used to display a partial specialization,
which allows an entity not to belong to any of the
subclasses.
 Constraints and Characteristics of
Specialization and Generalization
• A subclass itself may have further subclasses
• Deleting an entity from a superclass implies that it is
automatically deleted from all the subclasses to which it
belongs.
• Inserting an entity in a superclass implies that the entity
is mandatorily inserted in all predicate-defined (or
attribute-defined) subclasses for which the entity
satisfies the defining predicate.
• Inserting an entity in a superclass of a total specialization
implies that the entity is mandatorily inserted in at least
one of the subclasses of the specialization.
ER Diagram for exercise 1