DATA MODELING USING THE ENTITY

RELATIONSHIP (ER) MODEL

UNIT - 2
Using High-Level
Conceptual Data Models
for Database Design
Main phases of database design

► Requirements Collection and Analysis: During this step, the database designers
interview prospective database users to understand and document their data
requirements.
► This step results in a concise set of user requirements, which should be detailed
and complete.
► The functional requirements should be specified, as well as the data
requirements. Functional requirements consist of user operations that will be
applied to the database, including retrievals and updates.
► Functional requirements can be documented using diagrams such as sequence
diagrams, data flow diagrams etc.
Main phases of database design (Contd…)

► Once the requirements have been collected and analysed, the next step is to
create a conceptual schema for the database, using high level conceptual data
model.
► Conceptual schema: includes descriptions of data requirements of the users, and
detailed description of the entity types, relationships and constraints.
► The concepts do not include implementation details; therefore the end users
easily understand them, and they can be used as a communication tool.
► The conceptual schema is used to ensure all user requirements are met, and they
do not conflict.
Main phases of database design (Contd…)

► Implementation: 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.
► Physical Design : Purpose is to decide upon the internal storage structures,
access paths(indexes), etc, that will be used.
► In parallel with these activities, application programs are designed and
implemented as database transactions corresponding to the high level transaction
specifications.
Entity Relationship (ER) Model

► It is a high-level data model that is useful in developing a conceptual design for a

database.

► Creation of an ER diagram, which is one of the first steps in designing a

database, helps the designer(s) to understand and to specify the desired
components of the database and the relationships among those components.

► An ER model is a diagram containing entities or "items", relationships among

them, and attributes of the entities and the relationships.
ER Model Concepts – Entities

► Entity : An entity represents a thing in the real world with an independent existence, i.e., about
which we want to maintain some data.

► An entity could represent a physical object (eg. house, person, automobile, widget) or less
tangible concept (eg. Company, job, academic course).

► Entities are specific objects or things in the mini-world that are represented in the database.

► For example the EMPLOYEE John Smith, the Research DEPARTMENT, the ProductX
PROJECT
 Attributes

► Attributes are properties used to describe an entity.

► For example an EMPLOYEE entity may have a Name, SSN, Address, Gender, Birthdate.

► A specific entity will have a value for each of its attributes.

► For example a specific employee entity may have Name='John Smith', SSN='123456789',
Address ='731, Fondren, Houston, TX', Gender='M', Birthdate='09-JAN-55‘

► Each attribute has a value set (or data type) associated with it – e.g. integer, string, subrange,
enumerated type, …
 Types of Attributes

► Simple/ atomic vs. Composite

► Single-valued vs. Multi-values (or set - valued)

► Stored vs. Derived

 Simple Attributes

► Simple attributes are atomic values, which cannot be divided further.

► For example, a student's phone number is an atomic value of 10 digits.

 Composite Attributes

► Composite attributes are made of more than one simple attribute.

► For example, a student's complete name may have first_name and last_name.

► Here, the attributes “Name” and “Address” are composite attributes as they are
composed of many other simple attributes.
 Single Valued Attributes

► Single valued attributes are those attributes which can take only one value for a
given entity from an entity set.
► For example − Social_Security_Number.

Here, all the attributes are single valued attributes as they can take only one specific value for each
entity.
 Multi Valued Attributes

► Multi valued attributes are those attributes which can take more than one value
for a given entity from an entity set.

Here, the attributes “Mob_no” and “Email_id” are multi valued attributes as they can take
more than one values for a given entity.
 Derived Attributes vs Stored Attribute

► Derived attributes are those attributes which can be derived from other attribute(s).
► Derived attributes are the attributes that do not exist in the physical database, but their values
are derived from other attributes present in the database.
► For example, average_salary in a department should not be saved directly in the database,
instead it can be derived. For another example, age can be derived from data_of_birth.

► The age attribute is hence called a derived attribute and is said to be derivable from the
birth_date attribute, which is called stored attribute.
Key Attribute

► Key attributes are those attributes which can identify an entity uniquely in an
entity set.

Here, the attribute “Roll_no” is a key attribute as it can identify any student uniquely.
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, Or, in the case of a multi-valued attribute,
the appropriate value might be the empty set.

► Example: The attribute DataOfDeath is not applicable to a living person who have
died.

► In such cases, we use a special attribute value called null.

Complex Attributes

► complex Attribute is a type of attribute in database. It is formed by nesting

composite attributes and multi-valued attributes in arbitrary way. We can say this as the both
are in the attribute.

► For example, A person can have many phone numbers,many e-mail addresses,home addresses
etc. So if there is a attribute in the name of 'Contact detail',it can be a complex attribute.
 Entity Types, Entity Sets, Keys, and Domains

► For example, a company employing hundreds of employees may want to

store similar information concerning each of the employees.
► The 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.
 Entity Types, Entity Sets

► 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.
Entity Types, Entity Sets
Entity Types, Entity Sets

► 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 Attributes of an Entity Type

► 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.

► A key attribute may be composite. For example, VehicleTagNumber is a key of the CAR entity
type with components (Number, State).

► 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), also known as license_plate number.
 ENTITY SET corresponding to the
ENTITY TYPE CAR

CAR
Registration(RegistrationNumber, State), VehicleID, Make, Model, Year, (Color)

car1
((ABC 123, TEXAS), TK629, Ford Mustang, convertible, 1999, (red, black))
car2
((ABC 123, NEW YORK), WP9872, Nissan 300ZX, 2-door, 2002, (blue))
car3
((VSY 720, TEXAS), TD729, Buick LeSabre, 4-door, 2003, (white, blue))
.
.
.
 Value Sets (Domains) of Attributes

► Each simple 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 for each individual entity.

► Value sets are not displayed in ER diagrams. Value sets are typically specified using the basic
datatypes available, such as integer, string, Boolean, float and so on.

► Additional data types to represent date, time, and other concepts are also employed.
Initial Conceptual Design of the COMPANY Database
 Relationship Type

► Relationship : This is an association between two entities.

► As an example, one can imagine a STUDENT entity being

associated to an ACADEMIC_COURSE entity via, say, an
ENROLLED_IN relationship.
► In ER diagrams, Relationship types are drawn as
diamond-shaped boxes connected by lines to the entity types
involved.
Relationship Types from COMPANY Schema

► EMPLOYEE MANAEGES DEPARTMENT

► DEPARTMENT CONTROLS PROJECT
► EMPLOYEE WORKS_FOR DEPARTMENT
► EMPLOYEE SUPERVISES EMPLOYEE
► EMPLOYEE WORKS_ON PROJECT
► DEPENDENT DEPENDS_ON EMPLOYEE
 Relationship Set

► A relationship set is a set of instances of a relationship type.

► Then the WORK_FOR relation set will include as instances the
ordered pairs (e1, d1), (e2, d2),(e3, d1), (e4, d2), (e5, d3),(e6, d1),
and (e7, d3)

Relationship Type
► A relationship type R among n entity types E1, E2,
E3,….En defines a set of associations or a relationship set
among entities from these entity types.
 Relationship Degree

►
 Relationship Degree

► In Ternary relationship three different Entities takes part in a

Relationship.
► Relationship Degree = 3
► For Example: Consider a Mobile manufacture company.
► Three different entities involved:
•Mobile - Manufactured by company.
•Part - Mobile Part which company get from Supplier.
•Supplier - Supplier supplies Mobile parts to Company.
Relationship Degree

► Relationship can generally be of

any degree, but the ones most
common are binary relationships.

► Higher degree relationships are

generally more complex than binary
relationships.
 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.

► Role names are not technically necessary on relationship types where all the
participating entity types are distinct.
Recursive Relationships

► When there is a relationship between two entities of the same type, it is

known as recursive relationship.
► This means that the relationship is between different instances of the same
entity type.

Supervisor Supervisee
Recursive Relationship

► The same entity type participates more then once in a relationship

type in different roles.

► In such cases the role name becomes essential for distinguishing

the meaning of each participation, such relationship types are
called as recursive relationships.
Recursive Relationship
 Constraints on Relationship Types

► Constraints, that limit the possible combinations of entities that may participate
in the corresponding relationship set.

► For example, if the company has a rule that each employee must work for
exactly one department, then this constraint is described in the schema.

2 main types of relationship constraints:

► Cardinality ratio
► Participation
 Cardinality Ratios for Binary Relationships

► The cardinality ratio for a binary relationship specifies the maximum number of
relationship instances that an entity can participate in.

► For example, in the WORKS_FOR binary relationship type, DEPARTMENT :

EMPLOYEE is of cardinality ratio 1:N.

► Means that, each department can be related to(that is employs) any number of
employees, but an employee can be related to (works for) only one department.
Cardinality Ratios for Binary Relationships

Possible cardinality ratios for binary relationship

types are
►1:1
►1:N
►N:1
►M:N
 Cardinality Ratio (1:1)

► Cardinality defines the number of entities in one entity set, which can be associated
with the number of entities of other set via relationship set.
• When a single instance of an entity is associated with a single instance of another
entity, then it is called as one to one cardinality
• Here each entity of the entity set participate only once in the relationship
Cardinality Ratio (1:1)

► Using Sets, it can be represented as:

Cardinality Ratio (1:1) - ER Diagram Representation

1 1
Employee WORKS_FOR Department
 Cardinality Ratio (1:N)

► One-to-many − When is a single instance of an entity is associated with more than

one instance of another entity then this type of relationship is called one to many
relationships.
► Here entities in one entity set can take participation in any number of times in
relationships set and entities in another entity set can take participation only once in a
relationship set
► Example for one to many cardinalities
For example in the Real world, many students can study in a single college but the
student cannot apply to more than one college at the same time
 N
1
CUSTOMER PLACES ORDER

Cardinality Ratio (1:N) - ER Diagram Representation

 Cardinality Ratio (N:1)

► Many-to-one − When entities in one entity set can participate only once in a
relationship set and entities in another entity can participate more than once in the
relationship set, then such type of cardinality is called many-to-one.

► Example for many to one cardinality

• In real time a student takes only one course but a single course can be taken by any
number of students. so many to one relationship is observed here
• It means that one course can be taken by any number of students but only one course
can be allotted to one student
 N 1
STUDENT JOINED COLLEGE

Cardinality Ratio (N:1) - ER Diagram Representation

 Cardinality Ratio (N:N)

• Many-to-many − Here more than one instance of an entity is associated with more
than one instance of another entity then it is called many to many relationships

• In this cardinality, entities in all entity sets can take participate any number of
times in the relationship cardinality is many to many.

► Example for many to many cardinality

• In the Real world assume that a student can take more than one course and the
single course can be taken by any number of students this relationship will be many
to many relationship
 M N
STUDENT JOINED COURSES

Cardinality Ratio (N:N) - ER Diagram Representation

Participation Constraints and Existence Dependencies

► Participation constraints define the least number of relationship

instances in which an entity must compulsorily participate.
► Types of Participation Constraints
 Total Participation

• It specifies that each entity in the entity set must compulsorily

participate in at least one relationship instance in that relationship set.
• That is why, it is also called as mandatory participation.
• Total participation is represented using a double line between the
entity set and relationship set.
Total Participation

► Here, Double line between the entity set “Student” and relationship set
“Enrolled” in signifies total participation.

► It specifies that each student must be enrolled in t least one course.

 Partial Participation

• It specifies that each entity in the entity set may or may not participate in the
relationship instance in that relationship set.
• That is why, it is also called as optional participation.
• Partial participation is represented using a single line between the entity set and
relationship set.
Partial Participation

► Here, Single line between the entity set “Course” and relationship set
“Enrolled in” signifies partial participation.
► It specifies that there might exist some courses for which no enrolments are
made.
Relationship between Cardinality and Participation
Constraints

► Minimum cardinality tells whether the participation is partial or total.

• If minimum cardinality = 0, then it signifies partial participation.
• If minimum cardinality = 1, then it signifies total participation.

► Maximum cardinality tells the maximum number of entities that participates in a

relationship set.
Attributes of Relationship Types

► Relationship types can also have attributes, similar to those of entity types.
► For example: Hours for the works on relationship type.

Hours

EMPLOYEE WORKS_ON PROJECT

Weak Entity Types

► Entity types that do not have key attributes of their own are called as weak entity
types.
► Entity types that do have key attributes are called as regular entity types or
strong entity types.
► An entity of a weak identity type is uniquely identified by the specific entity to
which it is related in combination with some set of its own attributes.
► A relationship type that relates a weak entity type to its owner is called the
identifying relationship of the weak entity type.
Weak Entity Types

► A weak entity type always has a total participation constraint(existence

dependency) with respect to its identifying relationship.
► Because a weak entity cannot be identified without an owner entity.
► Example : A DEPENDENT entity is identified by its first name together with the
EMPLOYEE entity to which it is related via DEPENDS_ON.

EMPLOYE HAS DEPENDENT

Notations of ER diagram
Proper Naming of Schema Constructs

► Use singular Names for Entity Types, rather than plural ones, because the entity
type name applies to each individual entity belonging to that entity type.
► Entity Type names and relationship types are written in uppercase.
► Attribute names are initial capitalized.
► Role names are in lower case letters.
► Nouns will be taken as entities and verbs as relationship types.
► Attribute names generally arise from additional nouns that describe the nouns
corresponding to entity types.
ER diagram for COMPANY Database