Chapter-3 Data Modeling Using the Entity-Relationship Model

1
Chapter-3 Data Modeling Using the Entity-Relationship Model
3.1 INTRODUCTION Conceptual Database Design
The main phases of database design are:
 Requirements Collection and Analysis: purpose is to produce a description of the users'
requirements.
 Conceptual Design: purpose is to produce a conceptual schema for the database, including
detailed descriptions of entity types, relationship types, and constraints. All these are expressed
in terms provided by the data model being used.
 Implementation: purpose is to transform the conceptual schema (which is at a high/abstract
level) into a (lower-level) representatonal/implementational model supported by whatever DBMS
is to be used.
 Physical Design:purpose is to decide upon the internal storage structures,access paths (indexes), etc.,that
will be used in realizing the representational model produced in previous phase.
Figure 3.1 shows the database design process.
3.2 Example COMPANY Database
We need to create a database schema design based on the following (simplified) requirements of the
COMPANY Database:
 Employees, departments, and projects
 Company is organized into departments
 Department controls several projects
 Employee: require each employee’s name, Social Security number, address, salary, sex (gender),
and birth date
 Keep track of the dependents of each employee
3.3 Entity-Relationship (ER) Model
The ER model is a high-level conceptual data model. The ER model was introduced by Peter Chen in
1976, and is now the most widely used conceptual data model.
It represents real world situations using concepts, which are commonly used by people. It allows defining
a representation of the real world at logical level.ER model has no facilities to describe machine-related
aspects.
In ER model the logical structure of data is captured by indicating the grouping of data into entities. The
ER model also supports a top-down approach by which details can be given in successive stages.
In the ER model, the main concepts are entity, attribute, and relationship.
Entity Types, Entity Sets, Attributes, and Keys
1. Entities and Attributes
2. Entity Types, Entity Sets, Keys, and Value Sets
3. Initial conceptual Designfor the COMPANY Database

2
Figure 3.2: An ER Diagram of COMPANY database

3
SUMMARY OF ER DIAGRAM SYMBOLS( figure 7.14 Navathe)

4
1. Entities and Attributes
Entity: The basic object that the ER model represents is an entity which represents some "thing" (in
the mini world) that is of interest to us, i.e. about which we want to maintain some data. An entity
could represent a physical object (e.g., house, person, automobile, widget) or a less tangible concept
(e.g., company, job, academic course, business transaction).
Attribute:
• An attribute is a property or characteristic of an entity type. Each attribute has a value drawn from
some domain (set of meaningful values).
• In ER diagrams place attributes name in an ellipse with a line connecting it to its associated entity
• Attributes may also be associated with relationships
• An attribute is associated with exactly one entity or relationship
For example, an employee entity may be described by the employee’s name, age, address, salary, and job
particular entity will have a value for each of its attributes. The attribute values that describe each entity
become a major part of the data stored in the database.
Figure 3.3 shows two entities and the values of their attributes. The employee entity e1 has four
attributes: Name, Address, Age, and HomePhone; their values are "John Smith," "2311 Kirby, Houston,
Texas 77001," "55," and "713-749-2630," respectively. The company entity c1 has three attributes:
Name, Headquarters, and President; their values are "Sunco Oil," "Houston," and "John Smith,"
respectively.
Several types of attributes occur in the ER model are:
• Composite versus Simple(atomic)
• Single-valued versus Multivalued
• Stored versus Derived.
• Complex attributes
• Null values
• Composite Versus Simple (Atomic) Attributes
Composite attributes can be divided into smaller subparts, which represent more basic attributes
with independent meanings. For example, the Address attribute of the employee entity shown in Figure
03.03 can be sub-divided into Street_Address, City, State, and Postal_code, with the values "2311
Kirby," "Houston," "Texas," and "77001."

5
Attributes that are not divisible are called simple or atomic attributes. Composite attributes can
form a hierarchy; for example, Address can be subdivided into simple attributes Street_Address, city,
state and postal_code as shown in Figure a. The value of a composite attribute is the concatenation of the
values of its constituent simple attributes.
Figure a: A Composite attribute b. Multivalued attribute (Skill) and Derived attribute (Years_Employed)
• Single-Valued versus Multivalued Attribute
Most attributes have a single value for a particular entity; such attributes are called single-valued.
For example, Age is a single-valued attribute of person.
It frequently happens that there is an attribute that may have more than one value for a given
instance, e.g. EMPLOYEE may have more than one Skill. A multivalued attribute isone that may take
on more than one value – it is represented by an ellipse with double lines. Figure b shows an entity with
a multivalued attribute (Skill) and derived attribute (Years_Employed)
• Stored versus Derived Attributes
In some cases two (or more) attribute values are related—for example, the Age and BirthDate attributes
of a person. 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 BirthDate. 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.
• Some attribute values can be calculated or derived from others
• e.g.if no_of_experience needs to be calculated for EMPLOYEE, it can be calculated using
Date_of_joining and Today's_Date
• d attribute values.
A derived attribute is signified by an ellipse with a dashed line. Figure b shows an entity with
derived attribute (Years_Employed)
• The Null value: In some cases a particular entity might not have an applicable value for a particular
attribute Or that value may be unknown. Example: The attribute DateOfDeath is not applicable to
a living person and its correct value may be unknown for some persons who have died. In such
cases, we use a special attribute value (non-value?), called null.

6
2. Entity Types, Entity Sets, Keys, and Value Sets
A database usually contains groups of entities that are similar. For example, a company employing
hundreds of employees may want to store similar information concerning each of the employees. These
employee entities share the same attributes, but each entity has its own value(s) for each attribute.
Entity type : An entity type defines a collection (or set) of entities that have the same attributes. Each
entity type in the database is described by its name and attributes. The figure below shows two entity
types, named EMPLOYEE and COMPANY, and a list of attributes for each. A few individual entities of
each type are also illustrated, along with the values of their attributes.
Entity set : The collection of all entities of a particular entity type in the database at any point in time is
called an entity set; the entity set is usually referred to using the same name as the entity type. For
example, EMPLOYEE refers to both a type of entity as well as the current set of all employee entities in
the database.
An entity type is represented in ER diagrams (Figure 3.2) as a rectangular box enclosing the entity type
name. Attribute names are enclosed in ovals and are attached to their entity type by straight lines.
Composite attributes are attached to their component attributes by straight lines. Multivalued attributes
are displayed in double ovals.
An entity type describes the schema or intension for a set of entities that share the same structure. The
collection of entities of a particular entity type are grouped into an entity set, which is also called the
extension of the entity type.
Key Attributes of an Entity Type
An important constraint on the entities of an entity type is the key or uniqueness constraint on
attributes. An entity type usually has an attribute whose values are distinct for each individual entity in
the collection. Such an attribute is called a key attribute, and its values can be used to identify each
entity uniquely. For example, the Name attribute is a key of the COMPANY entity type in above figure,
because no two companies are allowed to have the same name. In a STUDENT entity rollno is the key

7
attribute because no 2 students have the same roll numbers. In ER diagrammatic notation, each key
attribute has its name underlined inside the oval.
Some entity types have more than one key attribute. E.g. Entity Type CAR with two keys and a
corresponding Entity Set
Value Sets (Domains) of Attributes
Each attribute of an entity type is associated with a value set or domain of values, which specifies the
set of values that may be assigned to that attribute. E.g. in CAR entity, the domain for year attribute is
{2004,2005,2002}.
3. Initial conceptual Design for the COMPANY Database
Based on the requirements, we can identify four initial entity types in the COMPANY database:
DEPARTMENT, PROJECT, EMPLOYEE, DEPENDENT

8
3.4 Relationships, Relationship Types, Roles and Structural Constraints
Relationship
An interaction/association between two or more entities based on a key attributes.
Relationship Types, Sets and Instances
A Relationship type R among n entity types E1, E2, ..., En defines a set of associations or a relationship
set-among entities from these entity types. Mathematically the relational set R is a set of relationship
instances ri
Relationship instance ri
• Each ri associates n individual entities (e1, e2, ..., en)
• Each entity ej in ri is a member of entity set Ej
• Relationships uniquely identified by keys of participating entities.
In the figure 3.9 employees e1, e3, and e6 work for department d1; employees e2 and e4 work
for department d2 and e5 and e7 work for d3.
2. Relationship Degree, Role Names, and Recursive Relationships
Degree of a relationship type
It is the number of participating entity types. e.g. a relationship type of degree 1 is unary, a relationship
type of degree 2 is binary, a relationship type of degree 3 is ternary , a relationship type of degree N is
called N-ary.

9
• Is_Married_To’ is a one-to-one relationship between instances of the PERSON entity type
• ‘Manages’ is a one-to-many relationship between instances of the EMPLOYEE entity type
Example of degree 3 (ternary) relationship called SUPPLY
Role Names and Recursive Relationships
 Each entity type in a relationship plays a particular role. The role name specifies the role that a
participating entity type plays in the relationship and explains what the relationship means.
 In a recursive relationship type, both participations are same entity type in different roles.
 For example, SUPERVISION relationships between EMPLOYEE (in role of supervisor or boss) and
(another) EMPLOYEE (in role of subordinate or worker).
 In following figure, first role participation labeled with 1 and second role participation labeled with 2.
 In ER diagram, need to display role names to distinguish participations.

10
A relationship type can have attributes:
For example, HoursPerWeek of WORKS_ON,Hours of WORKS_ON
Constraints on Relationship Types
 Relationship types have certain constraints that limit the possible combination of entities that may
participate in relationship.
 An example of a constraint is that if we have the entities Doctor and Patient, the organization may
have a rule that a patient cannot be seen by more than one doctor. This constraint needs to be
described in the schema. Another example , if the company has a rule that each employee must work
for exactly one department, then this constraint needs to be described in the schema.
 There are two main types of relationship constraints
a. Cardinality ratio for binary relationship constraints and
b. Participation constraints and Existence Dependencies.
a. Cardinality ratio for Binary Relationship
Binary relationships are relationships between exactly two entities. The cardinality ratio specifies the
maximum number of relationship instances that an entity can participate in. The possible cardinality
ratios for binary relationship types are: 1:1, 1:N, N:1, M:N. Cardinality ratios are shown on ER diagrams
by displaying 1, M and N on the diamonds.
Fig:a. 1 : 1(one to one) b. 1 : M(one to many) c. M : 1(many to one) d. M : M(many to many)
b. Participation Constraints and Existence Dependencies
The participation constraint specifies whether the existence of an entity depends on its being related to
another entity via the relationship type. The constraint specifies the minimum number of relationship
instances that each entity can participate in. There are two types of participation constraints:
 Total:
 If an entity can exist, only if it participates in at least one relationship instance, then
that is called total participation, meaning that every entity in one set, must be related
to at least one entity in a designated entity set.
 An example would be the Employee and Department relationship. If company policy
states that every employee must work for a department, then an employee can exist
only if it participates in at lest one relationship instance (i.e. an employee can’t exist
without a department)
 It is also sometimes called an existence dependency.

11
 Total participation is represented by a double line, going from the relationship to the
dependent entity.
 Partial:
 If only a part of the set of entities participate in a relationship, then it is called partial
participation.
 Using the Company example, every employee will not be a manager of a department,
so the participation of an employee in the “Manages” relationship is partial.
 Partial participation is represented by a single line.
3.4 Attributes of Relationship Types
Relationship types can have attributes similar to entity types. For example, in the relationship
Works_On, between the Employee entity and the Department entity we would like to keep track of
the number of hours an employee works on a project. Therefore we can include Number_of_Hours
as an attribute of the relationship.
 Another example is for the “manages” relationship between employee and department, we can add
Start Date as an attribute of the Manages relationship.
3.5 Weak Entity Types
 Entity types that do not have key attributes are called weak entity types. The regular entity type that
do have a key attributes are called strong entity.
 Entities that belong to a weak entity type are identified by being related to specific entities from
another entity type in combination with one of their attribute values. This entity type is called an
identifying or owner entity type.
 The relationship that relates the identifying entity type with the weak entity type is called an
identifying relationship.
 A weak entity type always has a total participation constraint with respect to the identifying
relationship, because a weak entity cannot exist without its owner.
 Not all existence dependencies result in a weak entity type; if an entity has a key attribute then it is
not a weak entity.
 A weak entity type usually has a partial key, which is the set of attributes that can uniquely identify
weak entities that are related to the same owner entity.
Example: Consider figure 3.2
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. EMPLOYEE is its identifying entity type via the identifying relationship type DEPENDENT_OF

12
Some examples of ER- Diagram
1: M( ONE TO MANY)
M : 1(MANY TO ONE)
M : M(MANY TO MANY)

Chapter-3 Data Modeling Using the Entity-Relationship Model

Recommended

More Related Content

What's hot (20)

Similar to Chapter-3 Data Modeling Using the Entity-Relationship Model (20)

More from Raj vardhan (20)

Recently uploaded (20)

Chapter-3 Data Modeling Using the Entity-Relationship Model