Module 2

DATA MODELING
USING ENTITY –
Relationship Model: Using High Level Conceptual Data Models for Database Design,
Example Database applications. Entity types, Entity Sets, Attributes and Keys. Relationships,
Relationship types, Roles and Structural constraints. Weak Entity Types and Drawing E- R
Diagrams.
CONCEPTUAL DATA MODELING
• Conceptual modeling is a very important phase in designing a successful
database application.
• The term database application refers to a particular database and the
associated programs that implement the database queries and updates
• For example, a BANK database application that keeps track of customer
accounts would include programs that implement database updates
corresponding to customer deposits and withdrawals. These programs would
provide user-friendly graphical user interfaces (GUIs) utilizing forms and menus
for the end users of the application—the bank customers or bank tellers in this
example
• Hence, a major part of the database application will require the design,
implementation, and testing of these application programs
• Traditionally, the design and testing of application programs has been
considered to be part of software engineering rather than database
design.
• In many software design tools, the database design methodologies
and software engineering methodologies are intertwined since these
activities are strongly related.
Using High-Level Conceptual Data Models for Database Design
• The first step shown is requirements collection and analysis. During this
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 users’ 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.
• In software design, it is common to use data flow diagrams, sequence
diagrams, scenarios, and other techniques to specify functional
requirements. Once 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.
• The conceptual schema is a concise description of the data requirements of the
users and includes detailed descriptions of the entity types, relationships, and
constraints; these are expressed using the concepts provided by the high-level
data model.
• Because these concepts do not include implementation details, they are usually
easier to understand and can be used to communicate with nontechnical 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 conflict.
• This approach enables database designers to concentrate on specifying the
properties of the data, without being concerned with storage and implementation
details, which makes it is easier to create a good conceptual database design.
During or after the conceptual schema design, the basic data model operations
can be used to specify the high-level user queries and operations identified during
functional analysis. This also serves to confirm that the conceptual schema meets
all the identified functional requirements. Modifications to the conceptual schema
can be introduced if some functional requirements cannot be specified using the
initial schema.
• During or after the conceptual schema design, the basic data model
operations can be used to specify the high-level user queries and operations
identified during functional analysis.
• This also serves to confirm that the conceptual schema meets all the
identified functional requirements.
• Modifications to the conceptual schema can be introduced if some functional
requirements cannot be specified using the initial schema.
• The next step in database design is the actual implementation of the
database, using a commercial DBMS.
• Most current commercial DBMSs use an implementation data model—such
as the relational (SQL) model—so the conceptual schema is transformed from
the high-level data model into the implementation data model.
• This step is called logical design or data model mapping; its result is a
database schema in the implementation data model of the DBMS. Data
model mapping is often automated or semiautomated within the database
design tools.
• The last step is the physical design phase, 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.
A Sample Database Application:
In this section we describe a sample database application, called
COMPANY, which 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 as we introduce the modeling
concepts of the ER model.
• The COMPANY database keeps track of a company’s employees,
departments, and projects.
• A department controls a number of projects, each of which has a
unique name, a unique number, and a single location.
• The database will store each employee’s name, Social Security
number,2 address, salary, gender 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. It is required to keep track of the current number of
hours per week that an employee works on each project, as well as
the direct supervisor of each employee (who is another employee).
• The database will keep track of the dependents of each employee for
insurance purposes, including each dependent’s first name, gender,
birth date, and relationship to the employee.
ER MODEL
ENTITY AND ATTRIBUTE
• The basic concept that the ER model represents is an entity, which is a
thing or object in the real world with an independent existence.
• An entity may be an object with a physical existence (for example, a
particular person, car, house, or employee) or it may be an object
with a conceptual existence (for instance, a company, a job, or a
university course).
• Each entity has attributes—the particular properties that describe it.
• The attribute values that describe each entity become a major part of
the data stored in the database.
Figure shows two entities and the values of their attributes.
• The EMPLOYEE entity e1 has four attributes: Name, Address, Age, and
Home_phone; 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:
• Simple versus composite,
• Single valued versus multivalued, and
• Stored versus derived
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 can be
subdivided into Street_address, City, State, and Zip, 3 with the values
‘2311 Kirby’, ‘Houston’, ‘Texas’, and ‘77001’.
• Attributes that are not divisible are called simple or atomic attributes.
• Composite attributes can form a hierarchy; for example,
Street_address can be further subdivided into three simple
component attributes: Number, Street, and Apartment_number, .
• The value of a composite attribute is the concatenation of the values
of its component simple attributes.
Single-Valued versus
Multivalued Attributes
• 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 a person.
• In some cases an attribute can have a set of values for the same entity
—for instance, a Colors attribute for a car, or a College_degrees
attribute for a person.
• Cars with one color have a single value, whereas two cars have two
color values.
• Similarly, one person may not have any college degrees, another
person may have one, and a third person may have two or more
degrees; therefore, different people can have different numbers of
values for the College_degrees attribute.
• Such attributes are called multivalued.
• A multivalued attribute may have lower and upper bounds to
constrain the number of values allowed for each individual entity.
• For example, the Colors attribute of a car may be restricted to have
between one and two values, if we assume that a car can have two
colors at most.
Stored versus Derived
Attributes
• In some cases, two (or more) attribute values are related—for example,
the Age and Birth_date 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 Birth_date.
• The Age attribute is hence called a derived attribute and is said to be
derivable from the Birth_date attribute, which is called a stored
attribute.
• Some attribute values can be derived from related entities; for example,
an attribute Number_of_employees of a DEPARTMENT entity can be
derived by counting the number of employees related to (working for)
that department
NULL Values
• In some cases, a particular entity may not have an applicable value for an attribute.
• For example, the Apartment_number attribute of an address applies only to addresses
that are in apartment buildings and not to other types of residences, such as single-
family homes.
• Similarly, a College_degrees attribute applies only to people with college degrees. For
such situations, a special value called NULL is created.
• An address of a single-family home would have NULL for its Apartment_number
attribute, and a person with no college degree would have NULL for College_degrees.
• NULL can also be used 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. The first case
arises when it is known that the attribute value exists but is missing—for instance, if the
Height attribute of a person is listed as NULL. The second case arises when it is not
known whether the attribute value exists—for example, if the Home_phone attribute of
a person is NULL.
Complex Attributes
• Notice that, in general, composite and multivalued attributes can be
nested arbitrarily.
• We can represent arbitrary nesting by grouping components of a
composite attribute between parentheses ( ) and separating the
components with commas, and by displaying multivalued attributes
between braces { }.
• Such attributes are called complex attributes. For example, if a person
can have more than one residence and each residence can have a
single address and multiple phones, an attribute Address_phone for a
person can be specified as given below.
• {Address_phone( {Phone(Area_code,Phone_number)},Address(Street
_address (Number,Street,Apartment_number),City,State,Zip) )}
Entity Types, Entity Sets, Keys,
and Value Sets
Entity Types and Entity 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.
• 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.
• 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 is grouped into an entity
set, which is also called the extension of the entity type.
Key attribute
• An entity type usually has one or more attributes whose values are distinct
for each individual entity in the entity set. Such an attribute is called a key
attribute, and its values can be used to identify each entity uniquely.
Types of Keys:
• Primary Key
• Candidate Key
• Super Key
• Foreign Key
• Alternate Key
• Composite Key
Primary Key
• It is the first key used to identify one and only one instance
of an entity uniquely. An entity can contain multiple keys, as
we saw in the PERSON table. The key which is most suitable
from those lists becomes a primary key.
• In the EMPLOYEE table, ID can be the primary key since it is
unique for each employee. In the EMPLOYEE table, we can
even select License_Number and Passport_Number as
primary keys since they are also unique.
• For each entity, the primary key selection is based on
requirements and developers.
 Candidate key
• A candidate key is an attribute or set of attributes that
can uniquely identified.
• Except for the primary key, the remaining attributes are
considered a candidate key. The candidate keys are as
strong as the primary key.
• For example: In the EMPLOYEE table, id is best suited
for the primary key. The rest of the attributes, like SSN,
Passport_Number, License_Number, etc., are considered
a candidate key.

Candidate Key
Super Key
• Super key is an attribute set that can uniquely identify a tuple. A super
key is a superset of a candidate key.

For example: In the above EMPLOYEE table, for(EMPLOEE_ID,

EMPLOYEE_NAME), the name of two employees can be the same, but their
EMPLYEE_ID can't be the same. Hence, this combination can also be a key.
• The super key would be EMPLOYEE-ID (EMPLOYEE_ID, EMPLOYEE-NAME).
Foreign key

• Foreign keys are the column of the table used to point to

the primary key of another table.
• Every employee works in a specific department in a
company, and employee and department are two
different entities. So we can't store the department's
information in the employee table. That's why we link
these two tables through the primary key of one table.
• We add the primary key of the DEPARTMENT table,
Department_Id, as a new attribute in the EMPLOYEE
table.
• In the EMPLOYEE table, Department_Id is the foreign key,
and both the tables are related.
 Composite key
• Whenever a primary key consists of more than one
attribute, it is known as a composite key. This key is also
known as Concatenated Key.
• For example, in employee relations, we assume that
an employee may be assigned multiple 06 roles, and
an employee may work on multiple projects
simultaneously. So the primary key will be composed of
all three attributes, namely Emp_ID, Emp_role, and
Proj_ID in combination. So these attributes act as a
composite key since the primary key comprises more
than one attribute.
ER Diagram with Primary key and Composite key

Since Employee_id is primary key it is under lined in the ER Diagram

Since Address is the combination of simple attributes like house_no, street, location the address is the
composite attribute and marked with double oval
Relationships , Relationship types, Roles and Structural constraints
Figure Preliminary design of entity types for the COMPANY database. Some of the
shown attributes will be refined into relationships.
• In Figure there are several implicit relationships among the various entity types.
• In fact, whenever an attribute of one entity type refers to another entity type, some
relationship exists.
• For example, the attribute Manager of DEPARTMENT refers to an employee who
manages the department; the attribute Controlling_department of PROJECT refers
to the department that controls the project; the attribute Supervisor of EMPLOYEE
refers to another employee (the one who supervises this employee); the attribute
Department of EMPLOYEE refers to the department for which the employee works;
and so on.
• In the ER model, these references should not be represented as attributes but as
relationships .
• In the initial design of entity types, relationships are typically captured in the form
of attributes. As the design is refined, these attributes get converted into
relationships between entity types.
 Relationship Types, Sets, and Instances

Some instances in the WORKS_ON relationship set, which represents a relationship type WORKS_On between
EMPLOYEE and Project.
• 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.
• Similar to the case of entity types and entity sets, a relationship type and its
corresponding relationship set are customarily referred to by the same name, R.
• Mathematically, the relationship set R is a set of relationship instances ri, where
each ri associates n individual entities (e1, e2, . . . , en), and each entity ej in ri is a
member of entity set Ej , 1 ≤ j ≤ n. Hence, a relationship set is a mathematical
relation on E1, E2, . . . , En; alternatively, it can be defined as a subset of the
• Cartesian product of the entity sets E1 × E2 × . . . × En. Each of the entity types E1,
E2, . . . , En is said to participate in the relationship type R; similarly, each of the
individual entities e1, e2, . . . , en is said to participate in the relationship instance ri
= (e1, e2, . . . , en).
• Informally, each relationship instance ri in R is an association of entities, where the
association includes exactly one entity from each participating entity type. Each
such relationship instance ri represents the fact that the entities participating in ri
are related in some way in the corresponding real world situation.
• 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. Each
relationship instance in the relationship set WORKS_FOR associates
one EMPLOYEE entity and one DEPARTMENT entity. Figure illustrates
this example, where each relationship instance ri is shown connected
to the EMPLOYEE and DEPARTMENT entities that participate in ri. The
employees e1, e3, and e6 work for department d1; the employees e2
and e4 work for department d2; and the employees e5 and e7 work
for department d3
Relationship Degree, Role Names, and Recursive Relationships
• Degree of a Relationship Type. The degree of a relationship type is the
number of participating entity . There are 4 types of degrees of
relationship based on the involved entities-
• Unary relationship
• Binary relationship
• Ternary relationship
• N-ary relationship
Unary Relationship
• As the name suggests, in a unary relationship, only one entity is involved.
There is only a single entity set, i.e., the association is between a single
entity. Here, the degree of relationship is 1. The unary relationship is also
known as a recursive relationship.
 Managed
Employee
by

Example: Employee is managed by another Employee . So the degree of

relationship is unary relationship
Binary Relationship
• In a binary relationship, there are two entities
involved. There are two entities that are
participating in the relationship. The degree of
relationship is 2. This is the most common type
of relationship.
• Example- Each Indian citizen has their own
Aadhar Card so we can say that citizen and
Aadhar Card are two entities involved.
Citizen Aadhar card
Ternary Relationship
• In a ternary relationship, there are three entities
involved. There are three entities that are participating
in the relationship created. The degree of the
relationship is 3. As in this relationship, the number of
entities increases, it is a bit difficult to convert it to
a relational
Student table. Related Department

Faculty
N-ary Relationship
• This is a generalized form of a relationship when the n number of
total entities are participating. When there is an n number of involved
entities, we can say that they have an N-ary relationship. As there are
many entities involved, it is hard to convert them to a relational table.
It is an uncommon relationship that is not as widely used as a
binary relationship. The degree of relationship is 'n'.

Student Related Department

Exam_cell
Placement_cell Library
Relationships as Attributes:
In ER model, entities have attributes which can be of various types like
single-valued, multi-valued, composite, simple, stored, derived and
complex. But relationships can also have attributes associated to them.
Let us see the example how attributes associate with entity
One to One relationship: Start date
1 1

Employee Department
Manages

One to many relationship:

Start date

n
Employee Works 1 Department
for
Many to Many relationship: Number of
working
hours

Employee
m n
Works Project
on
Recursive Relationship
• A relationship between two entities of a similar entity
type is called a recursive relationship. Here the same
entity type participates more than once in a relationship
type with a different role for each instance. In other
words, a relationship has always been between
occurrences in two different entities. However, the same
entity can participate in the relationship. This is termed
a recursive relationship.
Structural Constraints of
Relationship
• To understand Structural Constraints, we must take a look at
Cardinality Ratios and Participation Constraints.
• Cardinality Ratios of relationships : The entities are denoted
by rectangle and relationships by diamond.

• There are numbers (represented by M and N) written above the

lines which connect relationships and entities. These are called
cardinality ratios. These represent the maximum number of entities
that can be associated with each other through relationship, R.
 Types of Cardinality : There can be 4 types of
cardinality –
1.One-to-one (1:1) – When one entity in each entity set takes
part at most once in the relationship, the cardinality is one-to-
one.

2.One-to-many (1: N) – If entities in the first entity set take

part in the relationship set at most once and entities in the
second entity set take part many times (at least twice), the
cardinality is said to be one-to-many.
3.Many-to-one (N:1) – If entities in the first entity set
take part in the relationship set many times (at least
twice), while entities in the second entity set take part at
most once, the cardinality is said to be many-to-one.
4.Many-to-many (M: N) – The cardinality is said to be
many to many if entities in both the entity sets take part
many times (at least twice) in the relationship set.
• 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. This constraint specifies the minimum number of relationship
instances that each entity can participate in and is sometimes called
the minimum cardinality constraint. There are two types of
participation constraints—total and partial—that we illustrate by
example.
• Participation Constraints : Participation Constraints
tell us that the participation in a relationship can either
be total or partial.
When each entity in an entity set participates in a relation, it is called Total
Participation. However, when all entities in the given entity set do not participate
in a relation, it is called Partial Participation.
Structural Constraints : Structural Constraints are also called Structural properties
of a database management system (DBMS). Cardinality Ratios and Participation
Constraints taken together are called Structural Constraints. The name constraints
refer to the fact that such limitations must be imposed on the data, for the DBMS
system to be consistent with the requirements.
• The Structural constraints are represented by Min-Max notation. This
is a pair of numbers(m, n) that appear on the connecting line
between the entities and their relationships. The minimum number of
times an entity can appear in a relation is represented by m whereas,
the maximum time it is available is denoted by n. If m is 0 it signifies
that the entity is participating in the relation partially, whereas, if m is
either greater than or equal to 1, it denotes total participation of the
entity
Weak Entity
• A weak entity is an entity that cannot be uniquely identified by
its attributes alone; therefore, it must use a foreign key in
conjunction with its attributes to create a primary key
• For example, a DRIVER_LICENSE entity cannot exist unless it is related
to a PERSON entity, even though it has its own key (License_number)
and hence this has become weak entity
ER Diagram
OR
ER Diagrams

►Data Modelling Using Entity:

►Relationship Model: Using High Level Conceptual Data Models for Database Design,
Example Database applications. Entity types, Entity Sets, Attributes and Keys.
Relationships, Relationship types, Roles and Structural constraints. Weak Entity Types
and Drawing E- R Diagrams..
ER Models

► An entity-relationship (ER) model is a tool for database design.

Example

University
► Want to store data about:
► • employees
► • students
► • courses
► • departments
Entities

► Entities: the “Things”

► • Represented using rectangles.
► • Examples:
Attributes

► Associated with entities are attributes that describe them. (Attributes – set of properties or
characteristics of an entity).
► • represented as ovals connected to the entity by a line
► • double oval = attribute that can have multiple values
► • dotted oval = attribute that can be derived from other attributes

► Entity-student
► Attributes-name,id,add,course,
► Entiity-emp
► Attribute-eid,name,add,phon
Example
entity-course
attribute-name,room,
st-jan
et-April
l-4-1=3
exam date-5 dates
 age
degree

Workin emp jod

g year

Id salary
Name

dob
Street
House no Near
no
landmark

Address
pincode
Primary key
Relationships Between Entities

► Relationships between entities are represented using diamonds that are connected to the
relevant entity sets.
► • For example: students are enrolled in courses
► • Another example: courses meet in rooms
►Many Employees can work in oracle:1
►M:1
►Teacher/prof teach many students 1:m

teacher student
teach
Cardinality Constraints

► The presence or absence of cardinality constraints divides relationships into three types:
• many-to-one (M:1)
• one-to-many (1:N)
• one-to-one (1:1)
• many-to-many (M:N)
►One person has one laptop
M-manges –branch 1:1
Branch- manages –account 1:m
Cust-owns-accounts m:m
Translating relationship into table
(many to many Relationship)
• Create a table for the relationship set.
• Add all primary keys of the participating entity sets as
fields of the table.
• Add a field for each attribute of the relationship.
• Declare a primary key using all key fields from the entity
sets.
• Declare foreign key constraints for all these fields from
the entity sets.
Draw an ER Diagram for College Database

► STUDENT e (USN -pk, SName, Address-ca, Phone, Gender)

► SEMSEC e (SSID-pk, Sem, Sec)
► CLASS e (USN, SSID)
► SUBJECT e (Subcode, Title, Sem, Credits)
► IAMARKS e (USN, Subcode, SSID, Test1, Test2, Test3, FinalIA)
Convert ER Diagram into Relational Schema for College Database
Key
► An attribute that can uniquely identify a tuple in a relation is
called the key of the table.
► The value of the attribute for different tuples in the relation has
to be unique.
 CandidateKey
►Candidate key is a set of attributes (or attribute) which
uniquely identify the tuples in a relation or table.
►Ex. Student{ID, F_name, M_name, L_name, Age}
two candidate keys ID and {First_name, Last_name,
DOB}. So here, there are present more than one candidate
keys, which can uniquely identifies a tuple in a relation.
Ck-id,usn,phon no,email
pk-id
Ak-usn,phon no,email id
id usn name add email Phon age course
no
 Super key
► A super key is an attribute or a set of attributes used to identify the
records uniquely in a relation.
► Empssn,empnum,{empssn,empname},{empssn,empnum},
{empssn,empnum,empname},{empnum,empname}
 PrimaryKey
► Primary Key is a set of attributes (or attribute) which uniquely identify
the tuples in a relation or table.
► Primary key is a minimal super key, so there is one and only one primary
key in any relation.
► Ex. Student{ID, F_name, M_name, L_name, Age} Here only ID can be
primary key because name, age and address can be same but ID can’t be
same.
Alternate key
► A table can have multiple candidate keys. Among these
candidate keys, only one key gets selected as primary key, the
remaining keys are known as alternative or secondary keys.
 Foreign key
► Foreign keys are the columns of a table that points to the primary key of another table.
They act as a cross-reference between tables.
► Fk is used to link 2 tables together

► 1table-pk but 2 table-simple attribute

► Student-stu_id-pk,stu_name,stu_age
► Course-stuid-simple attribute,cou_id-pk,cname

► Plz ask me details about stu_id 103,course_name

► Student and course