Database Management Systems 17CS53

CONCEPTUAL DATA MODELLING USING ER

OUTLINE:

Design Phases.

▪ Phase 1: Requirements collection and analysis.

▪ Phase 2: Conceptual Design.

▪ Phase 3: Logical design (data model mapping).

▪ Phase 4: Physical design.

The Entity-Relationship (ER) Model.

▪ Entity Types, Entity Sets, Attributes, and Keys.

▪ Null Values.

▪ Relationship.

▪ The degree of a relationship type.

Structural Constraints on relationship.

▪ Cardinality ratio.

▪ Participation Constraints.

Weak Entity Types.

An Example of Database Application (COMPANY Database).

Specialization and Generalization

Phase 1: Requirements collection and analysis

 Interview prospective database users to understand and document their data

requirements

 The result of this phase is concisely written set of users’ requirements and functional
requirements of the application; consist of the user defined operations (or
transactions) that will be applied to the database, and they include both retrievals and
updates).

Phase 2: Conceptual Design

 Conceptual schema for the database, using High-Level Conceptual Data Model (entity
types, relationships, and constraints).Because these concepts do not include
implementation details, they are usually easier to understand and can used to

Archana Bhat, Dept of CSE Page |1

Database Management Systems 17CS53

communicate with no technical users. The high level conceptual schema can also be
used as a reference to ensure that all users' data requirements are met and that the
requirements do not include conflicts.

 The result is Conceptual Schema in high level model

Phase 3: Logical design (data model mapping)

 The actual implementation of a database, using a commercial DBMS; transformation

of conceptual schema from the high level data model into implementation data model.

 The result is Database schema in the implementation data model of the DBMS.

Phase 4: Physical design

The internal storage structures, access paths, and file organizations for the database files are
specified

Archana Bhat, Dept of CSE Page |2

Database Management Systems 17CS53

THE ENTITY-RELATIONSHIP (ER) MODEL

▪ Used for conceptual database design

▪ Relies on concepts of entities, attributes, and relationships

Entity Types, Entity Sets, Attributes, and Keys

▪ Entity: An entity is a "thing" (a being, an object, an event) in the real world and is
distinguishable from other objects (things).

Figure:1 Entities Examples

▪ Entity types represent sets of objects and are pictured by rectangular nodes

Characteristic of Entity:
 Existence: It may have a physical existence (also called concrete) (for
example, car, house, or an employee) in the real world or it may be an object
with a conceptual existence (abstract). (for example, a job, or a university
course).

 Described by its attributes (set of properties); for example an EMPLOYEE

entity may have a Name, SSN, Address, Sex, BirthDate.

 Determined by particular value of its attributes; a specific entity will have a

value for each of its attributes(domain);

▪ Example: a specific book entity will have title= “Database System

Concepts”,

pages=821, ISBN= 0-07-044756-X

▪ Example: A person name= “Mohammed”, age=21, add=salt

 Domain: the set of permitted values for each atribute

 Entity sets do not need to be disjoint. For example, it is possible to define the entity
set of all employees of a bank (employee) and the entity set of all customers of the

Archana Bhat, Dept of CSE Page |3

Database Management Systems 17CS53

bank (customer). A person entity may be an employee entity, a customer entity, both,
or neither.

 An entity type defines a collection (or set) of entities that have the same attribute (for
example, employee entity type and company entity type). An entity is an instance of
an entity type. All entities having the same set of properties are grouped into an entity
type.

 An entity set is the collection of all entities of a particular entity type in the database
at any point in time

Figure 2: Entity sets Example

 An entity set is also called an extension of the entity type.

Types of Attributes
▪ Entity types and relationship types might have attributes.

▪ Several types of attributes occur in the ER model (simple Vs. composite, single-
valued Vs. multivalued, Stored Vs. Derived Attribute, complex Attribute, and key
Attribute)

Atomic attribute types (Simple)

o Each entity has a single atomic value for the attribute; for example SSN or
Gender.

o Pictured by oval nodes

Composite attribute types

Achieved by concatenating simpler attribute types. The attribute may be composed of several
components; for example Address (Street, City, State, and Postal Code) or Name (First
Name, Middle Name, and Last Name).

Archana Bhat, Dept of CSE Page |4

Database Management Systems 17CS53

Figure 3: Composite Attribute Examples

Composite Attribute Pictured by trees of atomic attributes

Figure 4: Hierarchy Composite Attribute Example

Multivalued attribute

o An entity may have multiple values for that attribute; for example Color of a CAR or
PreviousDegrees of a STUDENT. Denoted as {Color} or {PreviousDegrees}.

o Displayed in two nested ovals

Derived attribute

o Some attribute values can be derived from related attributes or entities; for example
an attribute Age of employee entity can be determined from the current date and the
value of stored attribute (BirthDate).

o It is displayed in dashed ovals

Complex Attribute

o Composite and multi-valued attributes may be nested arbitrarily to any number of

levels although this is rare. For example, PreviousDegrees of a STUDENT is a
composite multi-valued attribute denoted by {PreviousDegrees(College, Year,
Degree, Field)}.

Example: {AddressPhone ( { Phone ( AreaCode, PhoneNumber ) }, Address (

StreetAddress ( Number, Name ), City, State, Zip ) ) }

Archana Bhat, Dept of CSE Page |5

Database Management Systems 17CS53

Figure 5: AddressPhone Complex Attribute

Key Attribute (identifier)

o An attribute whose values are distinct for each individual entity in the collection. In
other words, an attribute of an entity type for which each entity must have a unique
value is called a key attribute of the entity type. For example SSN of EMPLOYEE.

o Displayed with underlined attribute type names

o Key attribute may be composite. For example, VehicleRegistrationNumber is a key of

the CAR entity type with components (Number, State).

o An entity type may have more than one key. For example, the CAR entity type may
have two keys: VehicleIdentificationNumber (popularly called VIN) and
VehicleTagNumber (Number, State), number.

The following ER diagram for car:

Archana Bhat, Dept of CSE Page |6

Database Management Systems 17CS53

Figure 6: Car Entity Set with three entities.

The following figure contains all of the above types of attributes

Figure 7: Entity Type with all attributes types.

Null Values

▪ There are two situations for null values:

o In some cases a particular entity may not have an applicable value for an
attribute. Example, the ApartmentNumber attribute of an address applies only
to addresses that are in apartment buildings and not to single-family homes.

o If we do not know the value of an attribute for a particular entity. The

unknown category of null can be further classified into two cases:

A. The first case arises when it is known that the attribute value is
applicable, but it is missing—for example, if the height attribute of a
person is listed as null.

B. The second case arises when it is not known whether the attribute
value applicable —for example, if the HomePhone attribute of a person is
null.

Archana Bhat, Dept of CSE Page |7

Database Management Systems 17CS53

▪ Example: Appartment-Number attribute:

o Not applicable: if the address does not include a apartment-number.

o Missing: an apartment-number exists but we do not know what it is.

o Unknown: we do not know whether or not an apartment-number is part of the

customer’s address

Relationship

▪ A relationship is an association among at least two entities belonging to one or more

entity sets. For example, EMPLOYEE Sami works for IT DEPARTMENT.

▪ Relationship types associate entity types. For example, the WORKS_FOR

relationship type in which EMPLOYEEs and DEPARTMENTs participate. They are
pictured by Diamond nodes, and edges connecting to the related entity types

▪ Example:

Figure 8: “Works for” Relationship set ER diagram.

▪ A relationship set is the collection of instances (i.e., relationships between objects)

represented by a relationship type.

▪ Relationship type vs. relationship set

Relationship Type:

▪ Is the schema description of a relationship

▪ Identifies the relationship name and the participating entity types

▪ Also identifies certain relationship constraints

Relationship Set:

▪ The current set of relationship instances represented in the database

▪ The current state of a relationship type

▪ Relationship types may associate an entity type with itself. In such a case, the
roles of the entity types in the relationship type are listed on the edges, and the
relationship is said to be recursive.

Archana Bhat, Dept of CSE Page |8

Database Management Systems 17CS53

Figure 9: Recursive Relationship

▪ More than one relationship type can exist with the same participating entity types; for
example the WORKS_FOR relationship type in which EMPLOYEEs and
DEPARTMENT participate, or the MANAGES relationship type in which
EMPLOYEEs and DEPARTMENTs participate.

▪ Example: We can have two binary relationship types associating the student and team
types, TeamMemberOf and LeaderOf. In the former case, a student entity is a
member of a team entity; in the later case, a student can be a leader of a team.

A relationship type can have attributes called descriptive attributes:

 For example, HoursPerWeek of WORKS_ON

 Its value for each relationship instance describes the number of hours per week
that an EMPLOYEE works on a PROJECT.
 A value of HoursPerWeek depends on a particular (employee, project)
combination
 Most relationship attributes are used with M:N relationships

Archana Bhat, Dept of CSE Page |9

Database Management Systems 17CS53

Figure 10: Descriptive attribute

The degree of a relationship type

It is the number of participating entity types.

Unary: related to another of the same entity type. Also called recursive relationships.

▪
Binary: entities of two different types related to each other. (Two participating entities).

Ternary: entities of three different types related to each other. (three participating entities).

Archana Bhat, Dept of CSE P a g e | 10

Database Management Systems 17CS53

Figure 11: Ternary Relationship set

n-ary: entities of more than three different types related to each other.

Structural Constraints on relationship

Cardinality ratio (of a binary relationship)

▪ Mapping cardinalities, or cardinality ratio, express the number of entities to which

another entity can be associated via a relationship set. (Specifies maximum
participation).

▪ There are four types of cardinality: 1:1, 1:N, N:1, or M:N.

One-to-One (1:1) cardinality ratio, an entity in one set is associated with at most one entity
in another.

Figure 12: One to One relationship set

Archana Bhat, Dept of CSE P a g e | 11

Database Management Systems 17CS53

Figure 13: One to One relationship

One-to-many (1: N) cardinality ratio, an entity in the first set is associated with 0 or more
entities in the second set. However, those entities in the second set can be associated with at
most one entity in the first.

Figure 14: One to Many relationship set

Figure 15: One to Many relationship

Many-to-one (N: 1) cardinality ratio is just the reverse of the 1:N cardinality ratio. You can
think of whichever entity set you like as being the first set. Just specify the direction that
makes sense for your application, and then be consistent.

Many-to-many (N:M) cardinality ratio, entities of either set may be associated with any
number of entities in the other.

Figure 16: Many to Many relationship set

Archana Bhat, Dept of CSE P a g e | 12

Database Management Systems 17CS53

Figure 17: Many to Many relationship

Attributes of relationship types:

 The descriptive attribute of 1:1 or 1:N relationship type can be migrated to one of the
participating entity types:
 In 1:1 relationship type, a descriptive attribute can be an attribute of either entity type
1 or entity type 2.
 In 1:N relationship type, a descriptive attribute can be migrated only to the entity type
at the N-side of the relationship.
 For N:M relationship type, some attribute must be specified as descriptive attribute.

 The cardinality ratio depends on the real-world situation.

 Example: there are two situation of the borrower relationship between customer and
loan:
 If a loan can belong to only one customer, and a customer can have several loans,
then the relationship type from customer to loan is one-to-many.
 If a loan can belong to several customers, the relationship type is many-to-many.

Participation Constraints (Existence Dependency Constraints)

▪ Specifies minimum participation

▪ Specifies whether the existence of an entity e ϵ entity type E depends on its being
related to another entity via the relationship type R.

▪ The participation of an entity set E in a relationship set R is said to be:

Partial: if only some entities in E participate in relationships in R.

▪ Each entity e ϵ E can participate in a relationship set.

▪ Optional participation, not existence-dependent.

▪ The minimum value is zero.

▪ Shown by a single line.

Archana Bhat, Dept of CSE P a g e | 13

Database Management Systems 17CS53

Total: if every entity in E participates in at least one relationship in R.

▪ Each entity e ϵ E must participate in a relationship set.

▪ mandatory participation, existence-dependent

Example: if a company policy states that every employee must work for a department, then
an employee entity can exist only if it participates in a works-for relationship instance.

 The minimum value is one or more.

 Every entity in E participates in at least one relationship in R

Figure: Total/ Partial Participation

Weak Entity Types

▪ An entity type that does not have a key attribute.

▪ A weak entity type must participate in an identifying relationship type with an

owner or identifying entity type.

▪ Identifying relationship type is pictured by diamond with double lines.

▪ Entities are identified by the combination of:

▪ A partial key of the weak entity type .It is underlined with a dashed or dotted
line. The particular entity they are related to in the identifying entity type

▪ A weak entity type may have more than one identifying entity type and an identifying
relationship type of degree higher than two.

o A DEPENDENT entity is identified by the dependent’s first name, and the specific
EMPLOYEE with whom the dependent is related.

 Name of DEPENDENT is the partial key

 DEPENDENT is a weak entity type

Archana Bhat, Dept of CSE P a g e | 14

Database Management Systems 17CS53

 EMPLOYEE is its identifying entity type via the identifying relationship type
DEPENDENT OF.

An Example of Database Application (COMPANY Database)

The database designers stated the following description of the “miniworld”—the part of the
company to be represented in the database:

 The company is organized into departments. Each department has a unique name, a
unique number, and a particular employee who manages the department. We keep
track of the start date when that employee began managing the department. A
department may have several locations.
 A department controls a number of projects, each of which has a unique name, a
unique number, and a single location.
 We store each employee’s name, social security number, address, salary, sex, and
birth date. An employee is assigned to one department but may work on several
projects, which are not necessarily controlled by the same department. We keep track
of the number of hours per week that an employee works on each project. We also
keep track of the direct supervisor of each employee.
 We want to keep track of the dependents of each employee for insurance purposes.
We keep each dependent’s first name, sex, birth date, and relationship to the
employee.

Archana Bhat, Dept of CSE P a g e | 15

Database Management Systems 17CS53

Archana Bhat, Dept of CSE P a g e | 16

Database Management Systems 17CS53

Specialization
Specialization is the process of defining a set of subclasses of an entity type; this entity type
is called the superclass of the specialization. The set of subclasses that forms a specialization
is defined on the basis of some distinguishing characteristic of the entities in the superclass.
For example, the set of subclasses {SECRETARY,ENGINEER, TECHNICIAN} is a
specialization of the superclass EMPLOYEE that distinguishes among employee entities
based on the job type of each employee entity.

There are two main reasons for including class/subclass relationships and specializations in a
data model.
1. Certain attributes may apply to some but not all entities of the superclass. A subclass
is defined in order to group the entities to which these attributes apply.
2. Some relationship types may be participated in only by entities that are members of
the subclass.

The specialization process allows us to do the following:

■ Define a set of subclasses of an entity type
■ Establish additional specific attributes with each subclass
■ Establish additional specific relationship types between each subclass and other entity types
or other subclasses

Archana Bhat, Dept of CSE P a g e | 17

Database Management Systems 17CS53

Generalization
A reverse process of abstraction in which we suppress the differences among several entity
types, identify their common features, and generalize them into a single superclass of which
the original entity types are special subclasses.

Constraints on Specialization and Generalization

In some specializations we can determine exactly the entities that will become members of
each subclass by placing a condition on the value of some attribute of the superclass. Such
subclasses are called predicate-defined (or condition-defined) subclasses

If all subclasses in a specialization have their membership condition on the same attribute of
the superclass, the specialization itself is called an attribute-defined specialization, and the
attribute is called the defining attribute of the specialization.

When we do not have a condition for determining membership in a subclass, the subclass is
called user-defined. Membership is specified individually for each entity by the user, not by
any condition that may be evaluated automatically

Archana Bhat, Dept of CSE P a g e | 18

Database Management Systems 17CS53

disjointness (or disjointedness) constraint, which specifies that the subclasses of the
specialization must be disjoint. This means that an entity can be a member of at most one of
the subclasses of the specialization. A specialization that is attribute-defined implies the
disjointness constraint

Archana Bhat, Dept of CSE P a g e | 19

Database Management Systems 17CS53

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.

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 partial specialization, which allows an entity not to belong to any of the subclasses.

The following four constraints are possible on specialization:

■ Disjoint, total
■ Disjoint, partial
■ Overlapping, total
■ Overlapping, partial

Archana Bhat, Dept of CSE P a g e | 20