UNIT II - Chapter 1

Data Modeling Using the Entity-Relationship (ER) Model: Using High- Level Conceptual
Data Models for Database Design - An Example Database Application - Entity Types, Entity Sets,
Attributes, and Keys - Relationship Types, Relationship Sets, Roles, and Structural Constraints -
Weak Entity Types.
 Using High- Level Conceptual Data Models for
Database Design
 The following Figure shows a simplified description of the database design process.
 Step 1: Requirements collection and analysis: During this first step, the database
designers interview prospective database users to understand and document their data
requirements.
 The result of this step is a concisely written set of user’s requirements. These
requirements should be specified in as detailed and complete a form as possible.
 In parallel with specifying the data requirements, it is useful to specify the known
functional requirements of the application. These consist of the user defined
operations (or transactions) that will be applied to the database, including both
retrievals and updates.

 Step 2: Conceptual design:Once all the requirements have been collected and
analyzed, the next step is to create a conceptual schema for the database, using a high-
level conceptual data model. This step is called conceptual design.
 Create a conceptual schema for the database, using a high-level conceptual data
model. The conceptual schema is a concise description of the data requirements of the
users and includes detailed descriptions of entity types, relationship types, and
constraints.

 Step 3: Logical Design or Data model mapping: Purpose is to transform the

conceptual schema is transformed from high-level data model into implementation
data model. The result is a database schema in the implementation data model of the
DBMS.

 Step 4: Physical Design: During which the internal storage structures, file
organizations, indexes, access paths, and physical design parameters for the database
files are specified.
 In parallel with these activities, application programs are designed and implemented
as database transactions corresponding to the high-level transaction specifications.
 ER Model Concepts
 The main components and its symbols in ER Diagramsis as follows:
o Rectangles: This Entity Relationship Diagram symbol represents entity types.
o Ellipses: Symbol represent attributes.
o Diamonds: This symbol represents relationship types.
o Lines: It links attributes to entity types and entity types with other relationship
types.
o Primary key: attributes are underlined.
o Double Ellipses: Represent multi-valued attributes.

Figure: ER Diagram Symbols

 ER (Entity Relationship) Diagram in DBMS

o ER model stands for an Entity-Relationship model. It is a high-level data
model. This model is used to define the data elements and relationship for a
specified system.
o It develops a conceptual design for the database. It also develops a very simple
and easy to design view of data.
o In ER modeling, the database structure is portrayed as a diagram called an
entity-relationship diagram.
 Entities:
o An entity may be an object with a physical existence (e.g., person, car, house,
or employee) or it may be an object with conceptual existence (e.g., a job, or a
university course).
 o Entities are specific objects or things in the mini-world that are represented in
the database.
 Attributes:
o Attributes are properties used to describe an entity.
o A specific entity will have a value for each of its attributes.
o Each attribute has a value set (or data type) associated with it – e.g. integer,
string, …

o 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.
o The company entity c1 has three attributes: Name, Headquarters, and
President; their values are "Sunco Oil," "Houston," and "John Smith,"
respectively.
o Given below is another example of ER:
 Types of Attributes in ER model:
o 1. Simple attributes:
o Each entity has a single atomic value for the attribute. Attributes that are not
divisible are called simple or atomic attributes.

o 2. Key Attribute:
o The key attribute is used to represent the main characteristics of an entity. It
represents a primary key. The key attribute is represented by an ellipse with
the text underlined.

o 3. Composite attributes:
o The attribute may be composed of several components. Component attributes
can be divided into smaller subparts, which represent more basic attributes
with independent meaning.
o The composite attribute is represented by an ellipse, and those ellipses are
connected with an ellipse.
o For example, 1:
Name (FirstName, MiddleName, LastName).
o For example, 2:
Address (Apt#, House#, Street, City, State, ZipCode, Country).

o 3. Single-valued attributes:
o Most attributes have a single value for a particular entity; such attributes are
called single-valued.

o 4. Multi-valued attributes:
o An entity may have multiple values for that attribute.
o The double oval is used to represent multivalued attribute.
o Example 1 : PreviousDegrees of a STUDENT, Denote by {PreviousDegrees}.
o Example 2: a student can have more than one phone number.
o 5. Stored vs. Derived attributes:
o A derived attribute is one whose value can be calculated from the values of
other attributes. Those other attributes are called stored attributes.
o Example, Age can be calculated from Birth_date.
o The age attribute is hence called derived attribute and is said to be derivable
from the Birth_date attribute, which is called a stored attribute.

o 6. Complex attribute:
o The complex attribute in DBMS involves both multivalued and composite
attributes.
o For example, someone might have more than one house, and each house might
have more than one phone. The phone is then considered a complex attribute.
o 7. NULL values:
o (a) Unknown value.
o (b) Unavailable or withheld.
o (c) Not applicable.
o (a) Unknown value. A person’s date of birth is not known, so it is represented
by NULL in the database.
o (b) Unavailable or withheld value. A person has a home phone but does not
want it to be listed, so it is withheld and represented as NULL in the database.
o (c) Not applicable attribute. An attribute LastCollegeDegree would be
NULL for a person who has no college degrees because it does not apply to
that person.
o Example:
 Entity Types and Entity Sets
 Entity Types:
o Entities with the same basic attributes are grouped or typed into an entity type.
or
o An entity type defines a collection of entities that have the same attributes.
o Each entity type in the database is described by its name and attributes.
o For example, the entity type EMPLOYEE and PROJECT.
 Entity Sets:
o The collection of 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.
o For example, EMPLOYEE refers to both a type of entity as well as current set
of all employee entities in the database.
o An entity type describes the schema or intension for a set of entities that share
the same structure.
o The collection of entities of a particular entity type is grouped into an entity
set, which is also called the extension of the entity type.
 Attributesand Keys
 An important constraint on the entities of an entity type is the key or uniqueness
constraint on attributes.
 An attribute of an entity type for which each entity must have a unique value is
called a key attribute of the entity type. or
 An entity type has one or more attributes whose values are distinct for each
individual entity in the entity set. Such attribute is called a key attribute
(composite key), and its value can be used to identify each entity uniquely.

 Example for a key attribute is: StudentID and so on.

 A key attribute may be composite:

o VehicleTagNumber is a key of the CAR entity type with components
(Number, State).
 An entity type may have more than one key.
o The CAR entity type may have two keys:
VehicleIdentificationNumber (popularly called VIN)
VehicleTagNumber (Number, State), license plate number.
 Each key is underlined.
 Note: For example, Name attribute is a key of the COMPANY entity type, because no
two companies are allowed to have the same name.
 Relationship Types and Relationship Sets
 ER model has three main concepts:
o Entities (and their entity types and entity set)
o Attributes (simple, composite, multivalued)
o Relationships (and their relationship types and relationship set)

 Relationship:
o A relationship relates two or more distinct entities with a specific meaning.

 Relationship type:
o Relationship Type can be defined the association between two entities.
o In a school database, a student enroll a course. Here enroll is a relationship.

 Relationship Set:
o A relationship set is a set of relationships of same type.
o Relationship Set can be defined a set of similar type relationship. It is
represented by a diamond and connecting the entities by line.
o In a school database, there is a relationship between student set and course set.
 Degree of a Relationship Set:

o The number of entity sets that participate in a relationship set is termed as the
degree of that relationship set. Thus,

 Types of Relationship Sets:

o Unary relationship set
o Binary relationship set
o Ternary relationship set
o N-ary relationship set

o 1. Unary Relationship Set:

o Unary relationship set is a relationship set where only one entity set
participates in a relationship set.
o 2. Binary Relationship Set-
o Binary relationship set is a relationship set where two entity sets participate in
a relationship set.

o 3. Ternary Relationship Set-

o Ternary relationship set is a relationship set where three entity sets participate
in a relationship set.

o 4. N-ary Relationship Set-

o N-ary relationship set is a relationship set where ‘n’ entity sets participate in a
relationship set.
 Instance
o A relationship instance is the instance that associates an entity from an entity
type to another entity of another entity type, in order to establish a relationship
among various participating entity types.
o The relationship set R is a set of relationship instances ri, where
each ri associates n individual entities (e1, e2, ..., en),
o For example, consider a relationship type WORKS_FOR between
the two entity types EMPLOYEE and DEPARTMENT, which associates
each employee with the department for which the employee works in the
corresponding entity set. Each relationship instance in the relationship set
WORKS_FOR associates one EMPLOYEE entity and one DEPARTMENT
entity. Figure illustrates this example, where each relationship.

o instance ri is shown connected to the EMPLOYEE and DEPARTMENT

entities that participate in ri . In the Mini world represented by , employees
e1,e3, and e6 work for department d1; employees e2 and e4 work for
department d2; and employees e5 and e7 work for department d3. In ER
diagrams, relationship types are displayed as diamond-shaped boxes, which
are connected by straight lines to the rectangular boxes representing the
participating entity types. The relationship name is displayed in the diamond-
shaped box.
 Roles
 Each entity type that participates in a relationship type plays a particular role in the
relationship. 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.
o EMPLOYEE participates twice in two distinct roles:
 supervisor (or boss) role
 supervisee (or subordinate) role
o Each relationship instance relates two distinct EMPLOYEE entities:
 One employee in supervisor role
 One employee in supervisee role
o In following figure, first role participation labeled with 1 and second role
participation labeled with 2.
o In ER diagram, need to display role names to distinguish participations.
o Figure shows an example. The SUPERVISION relationship typerelates an
employee to a supervisor, where both employee and supervisor entities
aremembers of the same EMPLOYEE entity type. Hence, the EMPLOYEE
entity type participates twicein SUPERVISION: once in the role of supervisor
(or boss), and once in the role of supervisee (orsubordinate).
o InFigurethe lines marked "1" represent the supervisor role, and those marked
"2"represent the supervisee role; hence, e1 supervises e2 and e3, e4 supervises
e6 and e7 and e5supervises el and e4.
 Recursive Relationship Type
 In some cases, the same entity type participates more thanonce in a relationship type
in different roles. In such cases the role name becomes essentialfor distinguishing the
meaning of each participation. Such relationship types are calledrecursive
relationships.
 Figure shows an example. The SUPERVISION relationship typerelates an employee
to a supervisor, where both employee and supervisor entities aremembers of the same
EMPLOYEE entity type. Hence, the EMPLOYEE entity type participates twicein
SUPERVISION: once in the role of supervisor (or boss), and once in the role of
supervisee (orsubordinate).
 Structural Constraints (or)
Constraints on Relationship Types
 Constraints are used for modeling limitations on the relations between entities.
 There are two types of constraints on the Entity Relationship (ER) model −
o 1. Mapping cardinality or cardinality ratio.
o 2. Participation constraints.
 1. Mapping Cardinality:
 It is expressed as the number of entities to which another entity can be associated via
a relationship set.
 For the binary relationship set there are entity set A and B then the mapping
cardinality can be one of the following −
o One-to-one
o One-to-many
o Many-to-one
o Many-to-many
o One-to-one relationship:
o An entity set A is associated with at most one entity in B and an entity in B is
associated with at most one entity in A.

o One-to-many relationship:
o An entity set A is associated with any number of entities in B with a
possibility of zero and an entity in B is associated with at most one entity in A.
 o Many-to-one relationship:
o An entity set A is associated with at most one entity in B and an entity set in B
can be associated with any number of entities in A with a possibility of zero.

o Many-to-many relationship
o An entity set A is associated with any number of entities in B with a
possibility of zero and an entity in B is associated with any number of entities
in A with a possibility of zero.

 2. Participation Constraints:
 Participate constraints are two types as mentioned below −
o Total participation
o Partial Participation
 The participation constraints are explained in the diagram below −

 Here, the customer to Loan is partial participation and the loan to the customer is total
participation.
o Total participation:
o The participation of an entity set E in a relationship set R is said to be total if
every entity in E Participates in at least one relationship in R.
o For Example − Participation of loan in the relationship borrower is total
participation.
o Partial Participation:
o If only some of the entities in E participate in relationship R, then the
participation of E in R is said to be partial participation.
o For example − Participation of customers in the relationship borrower is
partial participation.
 Weak Entity Types

 What is a Strong Entity?

o A strong entity is complete by itself and is not dependent on any other
entity type. It possesses a primary key which describes each instance in the
strong entity set uniquely. That means any element in the strong entity set can
be uniquely identified. A strong entity is represented by a square with a single
line unlike a Weak Entity which contains double lines.

 What is a Weak Entity?

o A weak entity cannot be used independently as it is dependent on a strong
entity type known as its owner entity. Also, the relationship that connects
the weak entity to its owner identity is called the identifying relationship.
o A weak entity always has a total participation constraint with respect to its
identifying relationship because it cannot be identified independently of its
owner identity. A weak entity may have a partial key, which is a list of
attributes that identify weak entities related to the same owner entity.
o In the above example, "Address" is a weak entity type with attributes such as
House No., City, Location, and State.
o The relationship between a strong and a weak entity type is known as an
identifying relationship.
o Using a double diamond, the Entity-Relationship Diagram represents a
relationship between the strong and the weak entity type.
o Let us see an example of the relationship between the Strong entity type and
weak entity type with the help of ER Diagram:
 o Difference between Strong Entity and Weak Entity:

Factor Strong Entity Weak Entity

Definition A strong entity is A weak entity cannot be used

complete by itself and is independently as it is
not dependent on any dependent on a strong entity
other entity type. type known as its owner
entity.

Nature Strong entity is Weak entity is dependent in

independent in nature. nature. That means, it depends
on the strong entity.

Primary key Strong entity has Weak entity does not have
primary key. any primary key. But, it has a
partial discriminator key.

Key attribute Strong entity has a key Weak entity does not have
attribute. any key attribute.

Representation Strong entity can be Weak entity can be

represented by using a represented using a double
single rectangular box. rectangular box.

Participation Strong entity can either Weak entity always have total
have no participation or participation.
total participation.

Relationship The relationship The relationship between a

between two between two strong weak entity and a strong
entities entities is represented entity is represented by a
by a single diamond. double diamond.
 An Example Database Application
 In this section we describe an example database application, called COMPANY, that
serves to illustrate the basic ER model concepts and their use in schema design. We
list the data requirements for the database here, and then create its conceptual schema
step by step aswe introduce the modeling concepts of the ER model.
 The COMPANY database keeps track of a company's employees, departments, and
projects. Suppose that after the requirements collection and analysis phase, the
database designers provided the following description of the "Mini world"-the part of
the company to be represented in the database:
 1. 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.
 2. A department controls a number of projects, each of which has a unique name, a
unique number, and a single location.
 3. 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.
 4. 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.
 Figure, shows how the schema for this database application can be displayed by
means of the graphical notation known as ER diagrams. We describe the step-by-step
process of deriving this schema from the stated requirements-and explain the ER
diagrammatic notation-as we introduce the ER model concepts in the following
section.
Summary of notation for ER diagrams
--------------------------------------------------------------------------------