Introduction to Data Modeling and Conceptual Database Design

DATA BASE MANAGEMENT SYSTEM (P18IS42)
Introduction to Data Model and Data modeling:

What is Data Model?
Data Model is a Collection of concepts that can be used to
describe (or shows) the logical structure of a database. Structure of a
database means the data types, relationships and constraints that should hold
for the data.
The logical structure of a database includes entities, attributes, the
relationships and constraints that determine how data will be stored, accessed
and updated in a database management system.
Data models are categorized into three categories. They are:

1. Conceptual: This Data Model defines WHAT the system contains. This model
is typically created by Business stakeholders and Data Architects. The
purpose is to organize scope and define business concepts and rules.
2. Logical: Defines HOW the system should be implemented regardless of the
DBMS. This model is typically created by Data Architects and Business
Analysts. The purpose is to developed technical map of rules and data
structures.
3. Physical: This Data Model describes HOW the system will be implemented
using a specific DBMS system. This model is typically created by DBA and
developers. The purpose is actual implementation of the database.
Types of Data Models:
There are many kinds of data models. Some of the most
common data models are,
 Hierarchical database model
 Relational model
 Network model
 Object-oriented database model
 Entity-relationship model
 Document model
PUTTASWAMY B. S. Assistant Professor, Dept. of IS&E, PESCE Mandya Page 1

What is Data Modeling?
Data modeling is the process of documenting a complex
software system design as an easily understandable diagram, using text and
symbols to represent the way data needs to flow. This Data modeling diagram
can be considered as a blueprint for the construction of new software or for
re-engineering a legacy application.
Why Data Modeling?
To understand “meaning” or “semantics” of data. To
communicate about information requirements (among the project members and
customers). To use it as conceptual data model of database (our interest).
Conceptual Data Model:
A conceptual data model also called as abstract level
data model or theoretical data model or summary-level data model. A
conceptual model is a representation of a system, made of the composition of
concepts which are used to help people know, understand, or simulate a subject
the model represents. Typically conceptual data model describes an entire
enterprise.
It is helpful for communicating ideas to a wide range of stakeholders because
of its simplicity. Therefore platform-specific information, such as data
types, is omitted from a Conceptual data model.
Conceptual data model includes all major entities and relationships and does
not contain much detailed level of information about attributes. So,
conceptual data model as initial planning phase.
Conceptual data model is created by gathering requirements from various
sources, discussion with functional teams, business analyst, smart management
experts and end users who do the reporting on the database. conceptual data
model developers develop conceptual data model and forward that model to
functional team for their review.

Conceptual modeling is a very important phase in designing a successful

database application. Entity-Relationship (ER) model is a popular high-level
conceptual data model. This model and its variations are frequently used for
the conceptual design of database applications, and many database design tools
employ its concepts.
Using High-Level Conceptual Data Models for Database Design:

Conceptual modeling is a very important phase in designing a successful
database application. The below figure illustrates various phases of database
design. Database design is connected with application design.
Step 1: Requirements Collection and Analysis: It is the first phase of
database design. Database designers interview the future database users to
collect data (understand data requirements) and prepare report. There are two
types of report produced such as data requirements and functional
requirements.

The data requirements is a detailed and complete form of data requirements are
used as a source of database design.
In parallel with specifying the data requirements, it is useful to specify the
known functional requirements of the application. Functional requirements
consist of user defined 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, scenarios, etc.
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 phase is called conceptual
design (Conceptual design is also called as conceptual schema).
Conceptual schema: brief description of data requirements of the users and
includes a detailed description of the entity types, relationships and
constraints. Conceptual schema 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.

The result of this phase is an Entity-Relationship (ER) diagram or UML class

diagram. It is a high-level data model of the specific database application
area. It describes how different entities (objects, items) are related to each
other. It also describes what attributes (features) each entity has. It
includes the definitions of all the concepts (entities, attributes) of the
application area.
During or after the conceptual schema design, the basic data model operations
can be used to specify the high-level user operations identified during the
functional analysis. This also serves to confirm that the conceptual schema
meets all the identified functional requirements.
Step 3: Logical Design: Many DBMS systems use an implementation data model,
so the conceptual schema is transformed from the high-level data model into
the implementation data model.
The result of the logical design phase (or data model mapping phase) is a set
of relation schemas. The ER diagram or class diagram is the basis for these
relation schemas.
Relation schema defines the design and structure of the relation like it
consists of the relation name, set of attributes/field names/column names and
every attribute would have an associated domain
To create the relation schemas is quite a mechanical operation. There are
rules how the ER model or class diagram is transferred to relation schemas.
The relation schemas are the basis for table definitions. In this phase (if
not done in previous phase) the primary keys and foreign keys are defined.

Step 4: Physical Design: Physical design is the last phase of database

design. The goal of the physical design is to implement the actual database.
At this phase one must know which database management system (DBMS) is used.
For example, different DBMS's have different names for datatypes and have
different datatypes.
The SQL clauses to create the database are written. The indexes, the integrity
constraints (rules) and the users' access rights are defined. Finally the data
to test the database is added in.
In parallel with these activities, application programs are designed. The
implementation of the programs can start when the database is created and data
has been added in.



Sample Database Application:
In this section, we describe a COMPANY
database application, which is used to illustrate the basic ER model concepts
and their use in schema design.
We list the data requirements for the COMPANY database here, and then create
its conceptual schema step-by-step as we introduce the modeling concepts of
the ER model.
■ 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 (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. 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 (who is another 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.
Entity Types, Entity Sets, Attributes, and Keys:

ER Model:
ER Diagram is a visual representation of data that describes how data
is related to each other. In ER Model, we disintegrate (break up) data into
entities, attributes and setup relationships between entities; all this can be
represented visually using the ER diagram. An ER model is a diagram containing

entities or "items", relationships among them, and attributes of the entities
and the relationships.
An Entity Relationship model is also called an entity-relationship (ER)
diagram, is a graphical representation of entities and their relationships to
each other.
In 1976, Chen developed the Entity-Relationship (ER) model; ER model 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.
Why we need ER diagram?
 Giving you image of how the tables should connect
 What fields are going to be on each table?
 The table’s connection, if many-to-many, one-to-many.
ER diagrams are easy for non-technical people to understand, and thus are
typically used by database designers before the schema ever exists”
3.4.2 Entities and Attributes:

Entity: Entity is an object or real world object (Any real-world object can
be represented as an entity about which data can be stored in a database). All
the real world objects like a book, an organization, a product, a car, a
person are the examples of an entity. Any living or non-living objects can be

represented by an entity. An entity is symbolically represented by a rectangle
enclosing its name.
Entity
Entities may be,

 Physical - Can be touched (sensed) Example Fan.
 Conceptual - Cannot be touched. Example course offered, brand name etc.
For example: specific person, employee, company, student, videos,
appointments, patients, Books, Exam sessions, Products, Teacher etc.
For example: In a school database, students, teachers, classes, and courses
offered can be considered as entities. In a banking environment, entities are
CUSTOMERS, BANK SUPPLIERS etc.
Attribute: Attributes are the descriptive properties which are owned by each
entity (An attribute is a real world property or characteristic of an entity).
Attribute is the name of the column. An entity may contain any number of
attributes. One of the attributes is considered as the primary key. In an
Entity-Relation model, attributes are represented in an oval or ellipse
(elliptical) symbol. Every ellipse represents one attribute and is directly
connected to its entity (rectangle).
For example: In Bank database, Customer is considered as one entity and
customer entity describes various data elements (data field, a field, a data

item, or an elementary item) such as name, address, customer ID number. These
data elements are called as attributes of customer entity in bank database.
Entity Types: Entities are mainly classified into two types. There are,
1. Strong Entity Types
2. Weak Entity Types
Some other types of entities are,
1. Recursive Entity Types
2. Composite Entity Types or Associative Entity Types
3. SuperType and SubType Entities
Strong Entity Type:
Strong entity is the entity which has a key attribute (primary
key) in its attribute list to uniquely identify each entity. The strong entity type
is also called as regular entity type. Symbol of strong entity is same as an
entity.
Strong Entity
For example: STUDENT entity has STUDENT_ID as primary key. Hence it is a

STUDENT entity is a strong entity.

The ROLLNO in Student entity will identify the each student uniquely. So,
ROLLNO is set to be the Primary Key of the STUDENT entity, & Hence STUDENT is
a strong entity type because has its own key attribute ROLLNO.
Weak Entity:
Entity type doesn’t have any key attribute or Primary Key of its
own is called weak entity Type. Weak entity depends on other strong entity via
foreign key. A weak Entity is represented using double rectangular boxes.
Weak Entity
Example of weak entity type is –
Children Entity is depending upon Strong Entity Employee (as it has a unique
ID named SSN). The relationship is established to associate children with
their parents for insurance coverage.

Attributes of CHILDREN entity are-
 CNAME (name of Child)
 Age of Child
 Type of Insurance
So, none of the attributes of CHILDREN does not give a unique ID to the
entity. And the CHILDREN Entity has to depend on EMPLOYEE entity for
identification.
Composite Entity:
Entities participating in the many to many relationships are
called composite entity. In this case, apart from two entities that are part
of relation, we will one more hidden entity in the relation. We will be
creating a new entity with the relation, and create a primary key by using the
primary keys of other two entities.
Consider the example, multiple students enrolled for multiple courses. In this
case, we create STUDENT and COURSE. Then we create one more table for the
relation ‘Enrolment’ and name it as STUD_COURSE. Add the primary keys of
COURSE and STUDENT into it, which forms the composite primary key of the new
table.
Recursive Entity:
If a relation exists between the same entities, then such
entities are called as recursive entity. For example, mapping between manager
and employee is recursive entity. Here manager is mapped to the same entity
Employee. HOD of the department is another example of having recursive entity.

For example: A supervisor and subordinate relationship sets-one Supervisor can
supervise multiple subordinates but each subordinate reporting to at most one
supervisor.
Notations Of different Entity Type in ER Diagram:
Recursive Entity Type

Entity
Composite Entity Type

Strong Entity
(or)
Type
Associative Entity
Subtypes and Supertypes
Weak Entity Type

Type of Attributes in DBMS:
Attributes are classified into various
categories. They are,
 Single valued attributes

 Multi valued attributes
 Compound /Composite attributes
 Simple / Atomic attributes
 Stored attributes
 Derived attributes
 Complex attributes
 Key attributes
 Non key attributes
 Required attributes
 Optional/ null value attributes
Single valued Attributes: If an attribute of a particular entity represents

single value for each instance, then it is called a single-valued attribute
(It is an attribute with only one value).
For example: Ramesh, Kamal and Suraj are the instances of entity ‘student’
and each of them is a separate roll number. A single oval is used to represent
this attribute.
For example: Age of an employee entity.
Example: Any manufactured product can have only one serial no, but the single
valued attribute cannot be simple valued attribute because it can be sub

divided. Likewise in the above example the serial no. can be subdivided on the
basis of region, part no. etc.
Multi valued attribute: An attribute which can hold more than one value, (there
are many distinct values entered for it in the same column of the table) then it is
called a multi-valued attribute. Multi valued attribute is represented by a

double oval (Double Ellipse), one inside another, represents the attribute
which can have multiple values.
For example, each user can have several different hobbies, therefore the
“hobby” can be considered as a multivalued attribute for the “user”
entity:
For example, phone number of a person. Symbol of multi-valued attribute is

shown below,
Multi Valued Attribute

For example: In company database, the locations of a department may have more
than one value at the same time.

For example: a teacher entity can have multiple subject values.
Simple / Atomic attribute: The attributes which cannot be further divided

into smaller subparts are called simple or atomic attributes. A simple
attribute is represented by an oval
For example, a student's phone number is an atomic value of 10 digits. age
and sex of a person.
For example, age of employee entity.
Example: The entities like age, marital status cannot be subdivided and are
simple attributes.
Composite attribute: A composite attribute can be subdivided into smaller
components which further form attributes.
If the attributes are composite, they are further divided in a tree like
structure. Every node is then connected to its attribute. That is, composite
attributes are represented by ellipses that are connected with an ellipse.

For example, ‘name’ attribute of an entity “person” can be broken down
into first name and last name which further form attributes. Grouping of these
related attributes forms a composite attribute. name is the composite
attribute in this example.
For example, the Address attribute consists of several domains such as house
number, street number, city, country, etc.
Derived attribute: Derived attributes are the attributes that do not exist in
the physical database (The derived attribute may or may not be physically
stored in the database), but their values are derived from other attributes
present in the database.

If an attribute’s value can be determined from the values of other
attributes, then the attribute is derivable, and is said to be a derived
attribute.
These attributes are derived from other attributes. It can be derived from
multiple attributes and also from a separate table. To represent a derived
attribute, another dotted ellipse is created inside the main ellipse.
For example, having given the price excluding VAT and the VAT rate, we can
calculate the price including VAT:
For example: ‘age’ is a derived attribute if it calculates its value from

‘current date’ & ‘birth date’ attributes. A derived attribute is
represented by a dashed oval.
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.
Example: consider attributes for an employee: birth date, current age; here,
age is derivable by subtracting the birth date from the current date.

Example: Today’s date and age can be derived. Age can be derived by the
difference between current date and date of birth.
For example, we can know the number of employees work on a specific department
by counting the number of rows.
Key Attribute:
It is an attribute that has primary key to distinct value for
each entity/element in an entity set. The name of a key attribute is
underscored
Example: The entity student ID is a key attribute because no other student

will have the same ID.
For example, since the Vehicle Identification Number (VIN) is a unique code
used to identify individual vehicles (no two vehicles have the same VIN),
“VIN” can be considered as the key attribute for the “CAR” entity:

Non Key Attributes: These are attributes other than candidate key attributes
in a table. (Excluding the candidate key attributes in an entity set are the
non key attributes).
Example: First name of a student or employee is a non-key attribute as it does
not represent main characteristic of an entity.
Required Attribute: A required attribute is an attribute that must have a

data value. These attributes are required because they describe what is
important in the entity (Required attribute must have a data because they
describe the vital part of entity).
Example: Taking the example of a college, there the student’s name is a vital
thing.

For example, In a STUDENT entity, firstname and lastname is a required
attribute.
Optional / Null value Attributes: It does not have a value and can be left
blank, it’s optional can be filled or cannot be.
Example: Considering the entity student there the student’s middle name and
the email ID is optional.
For example, In a STUDENT entity, Middlename or email address is an optional

attribute. as some students may not have middlename or email address.
Stored Attributes: Attribute that cannot be derived from other attributes is
called as stored attributes. The attribute which gives the value to get the
derived attribute are called Stored Attribute. In example above, age is derived using
Date of Birth. Hence Date of Birth is a stored attribute.
Example: Birth date of an employee is a stored attribute.

Complex Attributes: For an entity, if an attribute is made using the multi
valued attributes and composite attributes then it is known as complex
attributes.
Example: A person can have more than one residence; each residence can have
more than one phone.
Partial key attribute (discriminator): An attribute that, when combined with
the key attribute of the owner entity, provides a unique identification for
the weak entity. We underline the discriminator with a dashed line:

7.3.2 Entity Types, Entity Sets, Keys, and Value Sets
Entity Types: Entity type defines a collection (or set) of entities that have
the same attributes.
Entities with the same basic attributes are grouped or typed into an entity
type. A database usually contains group of entities that are similar
properties or characteristics.
For example: the Employee entity type or the project entity type.
For example a company employing hundreds of employees may want to store
similar information concerning each of the employees.
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 (An entity set is a
collection of similar types of entities. An entity set may contain entities
with attribute sharing similar values).
For example, a Students set may contain all the students of a school; likewise
a Teachers set may contain all the teachers of a school from all faculties.
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 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.

For example: the Name attribute is a key of the COMPANY entity type because
no two companies are allowed to have the same name. For the PERSON entity
type, a typical key attribute is Ssn (Social Security number).
In ER diagrammatic notation, each key attribute has its name underlined
inside the oval.
Some entity types have more than one key attribute. For example, each of
the Vehicle_id and Registration attributes of the entity type CAR is a key in
its own right.
Value sets (Domains) of Attributes: A set of values that may be assigned to
the attributes of each individual entity, in an entity set is called the value
set or domain.

For example: in employee entity, if age limit is 25 to 58 then the value set
(domain) of attribute age consist of integer from 25 to 58. The value set for
name attribute is a set of alphabets and some special characters such as [a-
z], [A-Z], blank space and dot.
Initial Conceptual Design of the COMPANY Database:

An entity type DEPARTMENT with
attributes Name, Number, Locations, Manager, and Manager_start_date. A
location is the only multivalued attribute. We can specify that
both Name and Number are (separate) key attributes because each was specified
to be unique.
An entity type PROJECT with attributes Name, Number, Location,
and Controlling_department. Both Name and Number are (separate) key
attributes.
An entity type EMPLOYEE with attributes Name, Ssn, Sex, Address, Salary,
Birth_date, Department, and Supervisor. Both Name and Address may be
composite attributes; however, this was not specified in the requirements. We
must go back to the users to see if any of them will refer to the individual
components of Name—First_name, Middle_initial, Last_name—or of Address.
An entity type DEPENDENT with attributes Employee, Depenent_name, sex,
Birth_date and Relationship (to the employee).

Relationship Types, Relationship Sets, Roles, and Structural
Constraints:
Relationship: Any association between two entity types is called as
Relationship. We have two entity types of 'Customer'(Customer_id, Name, City,
Phone) and 'Account'(Account_no, Type, Balance). We store the data of
'Customer' in one table and his accounts details in the 'Account' table. Now,
to link these two tables we need to insert the primary key 'Customer_id' of
the 'Customer' table in the 'Account' table. This key acts as a foreign key
for the 'Account' table and refers to a column with the same name in the
'Customer' table. This is how a relationship between two tables is
established.
For example: A teacher teaches students. Here, "teaches" is a relationship
and this is the relationship established between a Teacher entity and a
Student entity.
Example: A STUDENT entity being associated to an ACADEMIC_COURSE entity via,
say, an ENROLLED_IN relationship.
Relationship or Actions are represented by diamond shapes, it shows how two
entities share information in the database.
Relationship represents an association between two or more entities.

An example of a relationship would be:
 Employees are assigned to projects
 Projects have subtasks
 Departments manage one or more projects

3.4 Relationship Types, Relationship Sets, Roles and Structural

Constraints:
What is relationship?
The association (connection or friendship
or alliance) among entities is called a relationship. (Establishes a
connection between a pair of tables that are logically related to each
other). A relationship, are connected to it by a line.
For example:-
An employee works_at a department, a student enrolls in a
course. Here, Works_at and Enrolls are called relationships.
Relationship Types: Relationship type can be defined the association

between two entities. (A relationship type R among n entity types E1, E2, ...,
En defines a set of associations) (A Relationship Type defines a
relationship set among entities of certain entity types)
In ER diagrams, relationship types are drawn as diamond-shaped boxes connected
by lines to the entity types involved.
A relationship type is illustrated in an ERD using a diamond symbol.
Example: In a school database, a student enrolls a course. Here enroll is a

relationship
Consider the following diagram that shows two entity types (Department and
Instructor) and the concept (a relationship) that instructors work in
departments. This relationship involves two entity types and is referred to as
a binary relationship.
Consider COMPANY schema, we identify the following relationship types

� EMPLOYEE MANAGES DEPARTMENT (arising from Manager attribute in DEPARTMENT)
� DEPARTMENT CONTROLS PROJECT (arising from Controlling Dept attribute in
PROJECT and the Projects attribute in DEPARTMENT)
� EMPLOYEE WORKS_FOR DEPARTMENT (arising from Dept attribute in EMPLOYEE and
the Employees attribute in DEPARTMENT).
� EMPLOYEE SUPERVISES EMPLOYEE (arising from Supervisor attribute in
EMPLOYEE) � EMPLOYEE WORKS_ON PROJECT (arising from WorksOn attribute in
EMPLOYEE and the Workers attribute in PROJECT)
� DEPENDENT DEPENDS_ON EMPLOYEE (arising from Employee attribute in DEPENDENT
and the Dependents attribute in EMPLOYEE)

Relationship types are useful for capturing/expressing certain business rules.

Relationship Set: A Relationship Set is a collection of relationships all
belonging to one relationship type. (Relationship Set can be defined a set of
similar type relationship).
If a relationship type is registration then each enrollment of a student in a

course is an instance of registration and appears is in the relationship set.

Relationship Degree, Role Names, and Recursive
Relationships:
Degree of a Relationship Type:
The number of entities (entity sets) that are
participated (associated or connected) in that relationship is called
Relationship Degree. (The number of participating entities in a relationship
defines the degree of the relationship.)
Degree of relationship also called as cardinality. 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.
Based on the degree, the relationships may be identified as
1. Unary (one entity is involved in the relationship and degree is 1)
2. Binary (two entities are involved in the relationship and degree is 2)
3. Ternary(three entities are involved in the relationship and degree is 3)
4. N-ary (n entities involved in the relationship and degree is n)
Unary Relationship:
When there is only ONE entity set participating in a
relation, An entity type linked with itself that type of relationship is
called as unary relationship. Unary relationship is also called as
recursive relationship.

For example, one person is married to only one person.
Example: Roommate, where STUDENT is linked with STUDENT
Binary Relationship:
When there are TWO entities set participating in a
relation, a one Entity type linked with another entity type that type of
relationship is called as binary relationship. The degree of binary
relationship is 2.
For example, Student is enrolled in Course.

Ternary Relationship:
A relationship exists when three entities are associated
(connected) is called ternary relationship.
N-ary Relationship:
When there are n entities set participating in a
relation, the relationship is called as n-ary relationship.
The most common relationship in ER diagram is Binary Relationship.

Relationships as Attributes:
It is sometimes convenient to think of a binary
relationship type in terms of attributes.
Consider the WORKS_FOR relationship type in Figure 7.9.
One can think of an attribute called Department of the EMPLOYEE entity type,
where the value of Department for each EMPLOYEE entity is (a reference to) the
DEPARTMENT entity for which that employee works. Hence, the value set for this
Department attribute is the set of all
DEPARTMENT entities, which is the DEPARTMENT entity set. This is what we did
in Figure 7.8 when we specified the initial design of the entity type EMPLOYEE
for the COMPANY database. However, when we think of a binary relationship as
an attribute, we always have two options. In this example, the alternative is
to think of a multivalued attribute Employee of the entity type DEPARTMENT
whose values for each DEPARTMENT entity is the set of EMPLOYEE entities who
work for that department.
The value set of this Employee attribute is the power set of the EMPLOYEE
entity set. Either of these two attributes—Department of EMPLOYEE or Employee
of DEPARTMENT—can represent the WORKS_FOR relationship type. If both are
represented, they are constrained to be inverses of each other.8

Role Names and Recursive Relationships:
Recursive Relationships:
An entity set can participate more than once in a
relationship that type of relationship is called recursive
relationship.
Role Names:
Each entity type that participates in a relationship type plays a
particular role in the relationship. The role name signify the role that a
participating entity from the entity type plays in each relationship instance,
and helps to explain what the relationship means.
Role names are not technically necessary in relationship types where all the
participating entity types are distinct, since each participating entity type
name can be used as the role name.However, in some cases the same entity type
participates more than once in a relationship type in different roles. In such
cases the role name becomes essential for distinguishing the meaning of the
role that each participating entity plays. Such relationship types are called
recursive relationships.
For example:- in the WORKS_FOR relationship type, EMPLOYEE plays the role of
employee or worker and DEPARTMENT plays the role of department or employer.

However, in some cases the same entity type participates more than once in a
relationship type in different roles. In such cases the role name becomes
essential for distinguishing the meaning of the role that each participating
entity plays. Such relationship types are called recursive relationships.
3.4.3 Constraints on Binary Relationship Types:

In ER model, a relationship is an association (connection) among entities
(records) of one or more entity sets. Relationship types usually have certain
constraints that limit the possible combinations of entities that may
participate in the corresponding relationship set. These constraints are
determined from the mini-world situation that the relationships represent.

For example: if the company has a rule that each employee must work for
exactly one department, and then we would like to describe this constraint in
the schema.
The numbers of entities participate to establish relationship is called as the
degree of relationship. Based on the degree, the relationships may be
identified as
1. Unary (degree 1)
2. Binary (degree 2)
3. Ternary (degree 3)
In binary relationship, there are two types of constraints. They are,
1. Cardinality ratio
2. Participation.
Cardinality Ratios for Binary Relationships:
In ER model, a relationship is
an association (connection) among entities (records) of one or more entity
sets. The number of times an entity of an entity set participates in a
relationship set is known as cardinality.
Cardinality ratio or mapping cardinalities is a concept that describes binary
relationship (a relationship that connects two entity sets)
type. 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.
It is about the maximum number of entities of one entity set that are
associated with the maximum number of entities of the other entity set.
For example:
Let us assume a student entity set (student’s information) and course entity
set (courses that are registered by a student).

To establish a link (relationship) between these two entity sets we need to
define the number of entities (records) of student that are associated with
number of entities (records) of course.
The possible cardinality ratios for binary relationship types are:

1. One-to-one relationship (1:1)
2. One-to-many relationship (1: N)
3. Many-to-one relationship (N: 1)
4. Many-to-many relationship (M: N)
Notations of Different Types of Cardinality In ER Diagram
One-to-one relationship:
If an entity [a record] of one
entity set A is associated with at most one entity in entity set B and entity
in entity set B is associated with at most one entity in entity set A. this

type of cardinality is called as one-to-one relationship (cardinality).
One-to-One Relationship is represented 1:1.
Example:

Let us assume a database for Airline Reservation System. Further assume that
there are two entity sets Passengers and Boarding-Pass represent the passenger
details and the flight tickets details respectively. If it is decided to issue
each passenger a boarding pass, then the relationship between the entity sets
Passengers and Boarding-Pass will be One-to-one.
As shown in the figure below, each passenger is allotted only one seat. Each
passenger entity is associated with exactly one Boarding_Pass entity.

Observe carefully from the above figure the following:

 Each passenger is allotted with exactly one seat. [look from passenger to
boarding_pass]
 Also, each seat is allotted to exactly one passenger. [look from
Boarding_Pass to passenger]
The ER diagram for this is as follows:
One-to-one relationship between two entity sets Passengers and Boarding_Pass
Look at the ERD carefully. Arrow head is used in either side of the
relationship Given. It indicates, one passenger for one boarding_pass, also
one boarding_pass for one passenger.
Some other examples:
A country has only one capital city, and a capital city is the capital of only
one country.
 Each student fills one seat and one seat is assigned to only one
student.

 Each professor has one office space.
The above example describes that one student can enroll only for one course
and a course will also have only one Student. This is not what you will
usually see in real-world relationships.
When we would say the relationship is one-to-one?
Assume two entity sets A and B. The
relationship between A and B is one-to-one if and only if “an entity in A is
associated with only one entity (record) in B and an entity in B is associated
with only one entity (record) in A”.
If we put in simpler terms, entity set B is the one side for A and entity set
A is the one side for B.
One-to-Many relationship:
If an entity [a record] of one
entity set is associated with zero or more entities of the other entity set,
then the cardinality ratio is said to be one-to-many from one side entity set
to the many side entity set.
One entity from entity set A can be associated with more than one entities of
entity set B however an entity from entity set B, can be associated with at
most one entity.

Example:
1 student can opt for many courses, but a course can only
have 1 student. Sounds weird! This is how it is.
Example:
Let us assume a database for Airline Reservation System.
Further assume that there are two entity sets Flights and Flight_Attendants to
model the flight details and the flight attendants details respectively. If
one flight can have many attendants, then this relationship can be modeled as
one-to-many from Flight to Flight_Attendants.
When we say that the relationship type is either one-to-many or many-to-one,
it is always important to say which side is one and which side is many to
avoid ambiguity.

Sample one-to-many relationship between entity sets
Observe carefully from the above figure the following;

 Each flight is having one or more attendants. [look from flight to
flight_attendant]
 Each flight attendant is allotted with exactly one flight. [look from
flight_attendant to flight]
The ER diagram for this case is shown below;
One-to-many relationship Has between entity sets Flight and Flight_Attendant
This can be read as, one flight has many flight attendants and one flight
attendant is attending only one flight.
When we would say the relationship is one-to-many?
Assume two entity sets A and B. The relationship is one-to-many from A to B if

and only if “an entity in A is associated with zero or more entities
(records) in B and an entity in B is associated with only one entity (record)
in A”.
If we put in simpler terms, entity set B is the many side for A and entity set
A is the one side for B.

Many -to- One relationship:

More than one entities from
entity set A can be associated with at most one entity of entity set B,
however an entity from entity set B can be associated with more than one
entity from entity set A.
Example:
Student enrolls for only one Course but a Course can have
many Students.

Multiple entities of the first set are related to one entities of the second
set. E.g. Teachers teach a student. Many teachers are teaching only one
student. This can be expressed in the following diagram as:
Many -to- Many relationships:

Multiple entities of the
first set is related to multiple entities of the second set and vice versa.

Example:
Teachers teach students. In any school or college many
teachers are teaching many students. This can be considered as a two way
many-to-many relationship. This can be expressed in the following diagram as:

The above diagram represents that one student can enroll for more than one
courses. And a course can have more than 1 student enrolled in it.
Cardinality ratios for binary relationships are represented on ER

diagrams by displaying 1, M, and N on the diamonds.
Participation Constraints and Existence Dependencies:

What is Participation Constraints?
Participation Constraint is a type of relationship constraint. The

participation constraint specifies (describes) whether the existence of an
entity depends on its being related to another entity via the relationship
type. (It describes that whether the existence of an entity is dependent on
its relationship with another entity via the relationship type).
This constraint specifies the minimum number of relationship instances that
each entity can participate in.
There are two kinds of participation constraints.
1. Total Participation
2. Partial Participation
Total Participation:

Total Participation is when each entity in the
entity set occurs in at least one relationship in that relationship set.
A total participation of an entity set in a relationship set when every entity

in that entity set has is at least one relationship in that relationship set.
Each entity is involved in the relationship. Total participation is
represented by double lines connecting entities in relationship.
Partial Participation:
Partial Participation is when each
entity in the entity set may not occur in at least one relationship in that
relationship set.
Not all entities are involved in the relationship. Partial participation is
represented by single lines connecting entities in relationship.
Example of Partial Participation:

If a company policy
states that employee (manager) must manage a department, However every
employee may not manage a department, so the participation of EMPLOYEE in the
MANAGES relationship type is partial, meaning that some or part of the set of
employee entities are related to some department entity via MANAGES, but not
necessarily all.

Example of Total Participation:
Consider the
relationship borrower between customers and loans. A double line from loan to
borrower, as shown in figure below indicates that each loan must have at least
one associated customer.
Minimum cardinality constraint:

Minimum cardinality
is the minimum number of entity instances that must participate in a
relationship. This number is generally zero or one.
Participation constraint specifies the minimum number of relationship
instances that each entity can participate in, and is sometimes called the
minimum cardinality constraint
Remember that a relationship is a one-to-one, one-to-many, or many-to-many
matching of rows between two tables, characterized by their maximum
cardinality ratios: 1:1, 1:M, or M:M.
Existence dependency:
When each entity in the entity set
occurs in at least one relationship in that relationship set. Total
participation is also called existence dependency.
Attributes of Relationship Types:

Relationship types can also have attributes, similar to those of entity types.
For example:-
To record the number of hours per week that an employee
works on a particular project, we can include an attribute Hours for the
WORKS_ON relationship type.
Another example is to include the date on which a manager started managing a

department via an attribute Start_date for the MANAGES relationship type.
Refining the ER Design for the COMPANY Database:

We can now refine (purify or
improve) the database design in Figure 7.8 by changing the attributes that
represent relationships into relationship types. The cardinality ratio and
participation constraint of each relationship type are determined from the
requirements listed in Section 3.2. If some cardinality ratio or dependency
cannot be determined from the requirements, the users must be questioned
further to determine these structural constraints.
In our example, we specify the following relationship types:

■ MANAGES, a 1:1 relationship type between EMPLOYEE and DEPARTMENT. EMPLOYEE
participation is partial. DEPARTMENT participation is not clear from the
requirements. We question the users, who say that a department must have a

manager at all times, which implies total participation.13 The attribute
Start_date is assigned to this relationship type.
■ WORKS_FOR, a 1:N relationship type between DEPARTMENT and EMPLOYEE. Both

participations are total.
■ CONTROLS, a 1:N relationship type between DEPARTMENT and PROJECT. The
participation of PROJECT is total, whereas that of DEPARTMENT is determined to
be partial, after consultation with the users indicates that some departments
may control no projects.
■ SUPERVISION, a 1:N relationship type between EMPLOYEE (in the supervisor
role) and EMPLOYEE (in the supervisee role). Both participations are
determined to be partial, after the users indicate that not every employee is
a supervisor and not every employee has a supervisor.
■ WORKS_ON, determined to be an M:N relationship type with attribute Hours,
after the users indicate that a project can have several employees working on
it. Both participations are determined to be total.
■ DEPENDENTS_OF, a 1:N relationship type between EMPLOYEE and DEPENDENT,
which is also the identifying relationship for the weak entitytype DEPENDENT.
The participation of EMPLOYEE is partial, whereas that of DEPENDENT is total.
After specifying the above six relationship types, we remove from the entity
types in Figure 7.8 all attributes that have been refined into relationships.
These include Manager and Manager_start_date from DEPARTMENT;
Controlling_department from PROJECT; Department, Supervisor, and Works_on from
EMPLOYEE; and Employee from DEPENDENT. It is important to have the least
possible redundancy when we design the conceptual schema of a database.
ER Diagrams, Naming Conventions, and Design Issues

Summary of Notation for ER Diagrams:

ERD entity symbols: Entities are objects or concepts that represent important data.
Entities are typically nouns such as product, customer, location, or promotion. There
are three types of entities commonly used in entity relationship diagrams.
Entity Name Description

Symbol
Strong These shapes are independent from other entities,

entity and are often called parent entities, since they
will often have weak entities that depend on
them. They will also have a primary key,
distinguishing each occurrence of the entity.
Weak entity Weak entities depend on some other entity type.

They don't have primary keys, and have no meaning
in the diagram without their parent entity.
Associative Associative entities relate the instances of

entity several entity types. They also contain
attributes specific to the relationship between
those entity instances.
ERD relationship symbols: Within entity-relationship diagrams, relationships are

used to document the interaction between two entities. Relationships are usually
verbs such as assign, associate, or track and provide useful information that could
not be discerned with just the entity types.
Relationship
Name Description
Symbol
Relationship Relationships are associations between or

among entities.

Relationship
Name Description
Symbol
Weak Weak Relationships are connections between

relationship a weak entity and its owner.
1. Similarly to the Barker’s notation, a mandatory relationship is

represented by a solid line:
2. An optional relationship is represented by a dashed line like in Barker’s

notation:
ERD attribute symbols: ERD attributes are characteristics of the entity that
help users to better understand the database. Attributes are included to
include details of the various entities that are highlighted in a conceptual
ER diagram.
Attribute
Name Description
Symbol
Attribute Attributes are characteristics of an entity,

a many-to-many relationship, or a one-to-one
relationship.
Multivalued Multivalued attributes are those that are can

attribute take on more than one value.

Attribute
Name Description
Symbol
Derived Derived attributes are attributes whose value

attribute can be calculated from related attribute
values.
Relationship Relationships are associations between or

among entities.
There are many notation styles that express cardinality.

Information Engineering Style
Symbol Shape Name Symbol Description

Entities
An entity is
represented by a
Entity rectangle which
contains the
entity’s name.

An entity that
cannot be
uniquely
identified by its
attributes alone.
The existence of
a weak entity is
dependent upon
another entity
Weak Entity called the owner
entity. The weak
entity’s
identifier is a
combination of
the identifier of
the owner entity
and the partial
key of the weak
entity.
An entity used in
a many-to-many
relationship
(represents an
Associative
extra table). All
Entity
relationships for
the associative
entity should be
many
Attributes
In the Chen
notation, each
attribute is
Attribute
represented by an
oval containing
atributte’s name

An attribute that
uniquely
identifies a
particular
Key attribute
entity. The name
of a key
attribute is
underscored.
An attribute that
can have many
values (there are
many distinct
values entered
Multivalued for it in the
attribute same column of
the table).
Multivalued
attribute is
depicted by a
dual oval.
An attribute
whose value is
calculated
(derived) from
other attributes.
The derived
attribute may or
Derived
may not be
attribute
physically stored
in the database.
In the Chen
notation, this
attribute is
represented by
dashed oval.
Relationships

A relationship
where entity is
existence-
independent of
other entities,
and PK of Child
Strong
doesn’t contain
relationship
PK component of
Parent Entity. A
strong
relationship is
represented by a
single rhombus
A relationship
where Child
entity is
existence-
dependent on
Weak parent, and PK of
(identifying) Child Entity
relationship contains PK
component of
Parent Entity.
This relationship
is represented by
a double rhombus.
Entity Relationship Diagram Symbols — Crow’s Foot notation
Symbol Meaning
Relationships (Cardinality and Modality)
Zero or One
One or More
One and only One
Zero or More

Many - to - One
a one through many
notation on one side
of a relationship and
a one and only one on
the other
a zero through many
a one and only one on
the other
a one through many
a zero or one
notation on the other
a zero through many
a zero or one
notation on the other
Many - to - Many
a zero through many
on both sides of a
relationship
a zero through many
on one side and a one
through many on the
other
a one through many on
both sides of a
relationship
a one and only one
a zero or one on the

other
a one and only one
notation on both
sides

Proper Naming of Schema Constructs:

When
designing a database schema, the choice of names for entity types, attributes,
relationship types, and (particularly) roles is not always straightforward.
One should choose names that convey, as much as possible, the meanings
attached to the different constructs in the schema. We choose to 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. In our ER
diagrams, we will use the convention that entity type and relationship type
names are uppercase letters, attribute names have their initial letter
capitalized, and role names are lowercase letters
As a general practice, given a narrative description of the database

requirements, the nouns appearing in the narrative tend to give rise to entity
type names, and the verbs tend to indicate names of relationship types.
Attribute names generally arise from additional nouns that describe the nouns
corresponding to entity types.
Another naming consideration involves choosing binary relationship names to
make the ER diagram of the schema readable from left to right and from top to
bottom.
Design Choices for ER Conceptual Design:
It is occasionally difficult to decide whether a particular concept in the miniworld
should be modeled as an entity type, an attribute, or a relationship type. In this
section, we give some brief guidelines as to which construct should be chosen in
particular situations.
In general, the schema design process should be considered an iterative refinement
process, where an initial design is created and then iteratively refined until the most
suitable design is reached. Some of the refinements that are often used include the

following:
■ A concept may be first modeled as an attribute and then refined into a relationship
because it is determined that the attribute is a reference to another
entity type. It is often the case that a pair of such attributes that are inverses
of one another are refined into a binary relationship.We discussed this type
of refinement in detail in Section 7.6. It is important to note that in
our notation, once an attribute is replaced by a relationship, the attribute
itself should be removed from the entity type to avoid duplication and
redundancy.
■ Similarly, an attribute that exists in several entity types may be elevated or
promoted to an independent entity type. For example, suppose that several
entity types in a UNIVERSITY database, such as STUDENT, INSTRUCTOR, and
COURSE, each has an attribute Department in the initial design; the designer
may then choose to create an entity type DEPARTMENT with a single attribute
Dept_name and relate it to the three entity types (STUDENT,
INSTRUCTOR, and COURSE) via appropriate relationships. Other attributes/
relationships of DEPARTMENT may be discovered later.
■ An inverse refinement to the previous case may be applied—for example, if
an entity type DEPARTMENT exists in the initial design with a single attribute
Dept_name and is related to only one other entity type, STUDENT. In this
case, DEPARTMENT may be reduced or demoted to an attribute of STUDENT.
■ Section 7.9 discusses choices concerning the degree of a relationship. In
Chapter 8, we discuss other refinements concerning specialization/generalization.
Chapter 10 discusses additional top-down and bottom-up refinements
that are common in large-scale conceptual schema design.
Alternative Notations for ER Diagrams

There are many alternative diagrammatic notations for displaying ER diagrams. the Unified
Modeling Language (UML) notation for class diagrams, which has been
proposed as a standard for conceptual object modeling.
In this section, we describe one alternative ER notation for specifying structural
constraints on relationships, which replaces the cardinality ratio (1:1, 1:N, M:N)
and single/double line notation for participation constraints. This notation involves
associating a pair of integer numbers (min, max) with each participation of an
entity type E in a relationship type R, where 0 ≤min ≤max and max ≥1. The numbers
mean that for each entity e in E, e must participate in at least min and at most max
relationship instances in R at any point in time. In this method, min = 0 implies partial
participation,
whereas min > 0 implies total participation.

How to Create an Entity Relationship Diagram (ERD)

Entity-relationship diagrams are incredibly useful, and you can easily create
ER diagram by following these simple steps.
1. Identify all the entities in the system (database system): The first step
in making an Entity-relationship diagram is to identify all of the
entities you will use in the system. An entity should appear only once in
a particular diagram. Create rectangles for all entities and name them
properly. For example, a customer, a manager, an invoice, a schedule, etc.
In the case of this cell phone purchase flow, the entities are: the
customer, the type of phone, the bill, and the login.
In this example, the three entities are “Student,” “Course,” and

“Professor.”
2. Identify relationships between entities and describe the relationship:

Look at entities (two entities), look at what kind of relationships
governs the interaction between different entities. If so draw a solid
line connecting the two entities. Describe the relationship: How are the
entities related? Draw an action diamond between the two entities on the
line you just added. In the diamond write a brief description of how they
are related.
Relationships are typically verbs such as “buys,” “contain,” or
“does.” In our example, the relationships “Registers for” and

“Teaches” effectively explain the interactions between the three
entities.
3. Add attributes for entities: Next, determine the attributes (or column
names) your entities will have. For the customer, we’ll need to know
name, customer id, their phone number, where they live and the amount they
need to pay. Go through each of your entities and determine what
attributes they need to have. Give meaningful attribute names so they can
be understood easily.
4. The last step is to decide whether the interactions will be one-to-one,

one-to-many, many-to-one and many-to-many cardinality ratios and choose
the appropriate cardinality ratio and participation constraints connectors
before completing the Entity relationship diagram.
5. Complete the diagram. Continue to connect the entities with lines, and
adding diamonds to describe each relationship until all relationships have
been described. Each of your entities may not have any relationships, some
may have multiple relationships. That is okay.
Examples:
Design an Entity Relationship (ER) model for a college database.
Data requirements are,
1. A college contains many departments

2. Each department can offer any number of courses
3. Many instructors can work in a department
4. An instructor can work only in one department
5. For each department there is a Head
6. An instructor can be head of only one department
7. Each instructor can take any number of courses
8. A course can be taken by only one instructor
9. A student can enroll for any number of courses
10. Each course can have any number of students
Before will start design Entity Relationship diagram, remember the notations
we have used for entities, attributes, relations etc.
Step 1: Identify the Entities
What are the entities here? From the data
requirements given, the entities are
1. Department
2. Course
3. Instructor
4. Student
Step 2: Identify the relationships
1. One department offers many courses. But one particular course can be
offered by only one department. hence the cardinality between department
and course is One to Many (1:N)
2. One department has multiple instructors . But instructor belongs to only
one department. Hence the cardinality between department and instructor is
One to Many (1:N)
3. One department has only one head and one head can be the head of only one
department. Hence the cardinality is one to one. (1:1)

4. One course can be enrolled by many students and one student can enroll for
many courses. Hence the cardinality between course and student is Many to
Many (M:N)
5. One course is taught by only one instructor. But one instructor teaches
many courses. Hence the cardinality between course and instructor is Many
to One (N :1)
Step 3: Identify the key attributes
 "Departmen_Name" can identify a department uniquely. Hence Department_Name
is the key attribute for the Entity "Department".
 Course_ID is the key attribute for "Course" Entity.
 Student_ID is the key attribute for "Student" Entity.
 Instructor_ID is the key attribute for "Instructor" Entity.
Step 4: Identify other relevant attributes
 For the department entity, other attributes are location
 For course entity, other attributes are course_name,duration
 For instructor entity, other attributes are first_name, last_name, phone
 For student entity, first_name, last_name, phone
Step 5: Draw complete ER diagram
By connecting all these details, we can now draw ER diagram as given below.

The University Database:

The university database stores details
about university students, courses, the semester a student took a particular
course (and his mark and grade if he completed it), and what degree program
each student is enrolled in. The database is a long way from one that’d be
suitable for a large tertiary institution, but it does illustrate
relationships that are interesting to query, and it’s easy to relate to when
you’re learning SQL. We explain the requirements next and discuss their
shortcomings at the end of this section.
Consider the following requirements list:
o The university offers one or more programs.
o A program is made up of one or more courses.
o A student must enroll in a program.
o A student takes the courses that are part of her program.
o A program has a name, a program identifier, the total credit points
required to graduate, and the year it commenced.

o A course has a name, a course identifier, a credit point value, and the
year it commenced.
o Students have one or more given names, a surname, a student identifier,
a date of birth, and the year they first enrolled. We can treat all given
names as a single object—for example, “John Paul.”
o When a student takes a course, the year and semester he attempted it are
recorded. When he finishes the course, a grade (such as A or B) and a mark
(such as 60 percent) are recorded.
o Each course in a program is sequenced into a year (for example, year 1)
and a semester (for example, semester 1).
The ER diagram derived from our requirements is shown in Figure 4-12. Although
it is compact, the diagram uses some advanced features, including
relationships that have attributes and two many-to-many relationships.
Figure 4-12. The ER diagram of the university database

In our design:
o Student is a strong entity, with an identifier, student_id, created to
be the primary key used to distinguish between students (remember, we could
have several students with the same name).

o Program is a strong entity, with the identifier program_id as the
primary key used to distinguish between programs.
o Each student must be enrolled in a program, so the Student entity
participates totally in the many-to-one Enrolls In relationship with Program.
A program can exist without having any enrolled students, so it participates
partially in this relationship.
o A Course has meaning only in the context of a Program, so it’s a weak
entity, with course_id as a weak key. This means that a Course is uniquely
identified using its course_id and the program_id of its owning program.
o As a weak entity, Course participates totally in the many-to-one
identifying relationship with its owning Program. This relationship
has Year and Semester attributes that identify its sequence position.
o Student and Course are related through the many-to-many Attempts
relationships; a course can exist without a student, and a student can be
enrolled without attempting any courses, so the participation is not total.
o When a student attempts a course, there are attributes to capture
the Year and Semester, and the Mark and Grade.
The Flight Database:
The flight database stores details about an airline’s
fleet, flights, and seat bookings. Again, it’s a hugely simplified version of
what a real airline would use, but the principles are the same.
Consider the following requirements list:
o The airline has one or more airplanes.
o An airplane has a model number, a unique registration number, and the
capacity to take one or more passengers.
o An airplane flight has a unique flight number, a departure airport, a
destination airport, a departure date and time, and an arrival date and time.
o Each flight is carried out by a single airplane.

o A passenger has given names, a surname, and a unique email address.
o A passenger can book a seat on a flight.
The ER diagram derived from our requirements is shown in Figure 4-13:
Figure 4-13. The ER diagram of the flight database

o An Airplane is uniquely identified by its Registration-Number, so we use
this as the primary key.
o A Flight is uniquely identified by its Flight-Number, so we use the
flight number as the primary key. The departure and destination airports are
captured in the From and To attributes, and we have separate attributes for
the departure and arrival date and time.
o Because no two passengers will share an email address, we can use
the Email-Address as the primary key for the Passenger entity.
o An airplane can be involved in any number of flights, while each flight
uses exactly one airplane, so the Flies relationship between
the Airplane and Flight relationships has cardinality 1:N; because a flight
cannot exist without an airplane, the Flight entity participates totally in
this relationship.

o A passenger can book any number of flights, while a flight can be booked
by any number of passengers. As discussed earlier in Intermediate Entities,”
we could specify an M:N Books relationship between the Passenger and
Flight relationship, but considering the issue more carefully shows that there
is a hidden entity here: the booking itself. We capture this by creating the
intermediate entity Booking and 1:N relationships between it and
the Passenger and Flight entities. Identifying such entities allows us to get
a better picture of the requirements. Note that even if we didn’t notice this
hidden entity, it would come out as part of the ER-to-tables mapping process
we’ll describe next in Using the Entity Relationship Model.”
Music Database:
We first draw up a clear list of requirements for our database:
o The collection consists of albums.
o An album is made by exactly one artist.
o An artist makes one or more albums.
o An album contains one or more tracks
o Artists, albums, and tracks each have a name.
o Each track is on exactly one album.
o Each track has a time length, measured in seconds.
o When a track is played, the date and time the playback began (to the
nearest second) should be recorded; this is used for reporting when a track
was last played, as well as the number of times music by an artist, from an
album, or a track has been played.
There’s no requirement to capture composers, group members or sidemen,
recording date or location, the source media, or any other details of artists,
albums, or tracks.
The ER diagram derived from our requirements is shown in Figure 4-11. You’ll
notice that it consists of only one-to-many relationships: one artist can make

many albums, one album can contain many tracks, and one track can be played
many times. Conversely, each play is associated with one track, a track is on
one album, and an album is by one artist. The attributes are straightforward:
artists, albums, and tracks have names, as well as identifiers to uniquely
identify each entity. The track entity has a time attribute to store the
duration, and the played entity has a timestamp to store when the track was
played.
Figure 4-11. The ER diagram of the music database

The only strong entity in the database is Artist, which has an artist_id
attribute that uniquely identifies it. Each Album entity is uniquely
identified by its album_id combined with the artist_id of the
corresponding Artist entity. A Track entity is similarly uniquely identified
by its track_id combined with the related album_id and artist_id attributes.
The Played entity is uniquely identified by a combination of its played time,
and the related track_id, album_id, and artist_id attributes.
What it doesn’t do

We’ve kept the music database simple because adding extra features doesn’t
help you learn anything new, it just makes the explanations longer. If you
wanted to use the music database in practice, then you might consider adding
the following features:
o Support for compilations or various-artists albums, where each track may
be by a different artist and may then have its own associated album-like
details such as a recording date and time. Under this model, the album would
be a strong entity, with many-to-many relationships between artists and
albums.
o Playlists, a user-controlled collection of tracks. For example, you
might create a playlist of your favorite tracks from an artist.
o Track ratings, to record your opinion on how good a track is.
o Source details, such as when you bought an album, what media it came on,
how much you paid, and so on.
o Album details, such as when and where it was recorded, the producer and
label, the band members or sidemen who played on the album, and even its
artwork.
o Smarter track management, such as modeling that allows the same track to
appear on many albums.
ER diagram of Library Management System
https://www.albany.edu/~goel/classes/spring2007/pwsp/database/
The Library Management System database keeps track of readers with the
following considerations –
 The system keeps track of the staff with a single point authentication
system comprising login Id and password.
 Staff maintains the book catalog with its ISBN, Book title, price(in INR),
category(novel, general, story), edition, author Number and details.

 A publisher has publisher Id, Year when the book was published, and name
of the book.
 Readers are registered with their user_id, email, name (first name, last
name), Phone no (multiple entries allowed), communication address. The
staff keeps track of readers.
 Readers can return/reserve books that stamps with issue date and return
date. If not returned within the prescribed time period, it may have a due
date too.
 Staff also generate reports that has readers id, registration no of
report, book no and return/issue info.
ER Diagram of Library Management System

This Library ER diagram illustrates key information about the Library,
including entities such as staff, readers, books, publishers, reports, and
authentication system. It allows for understanding the relationships between
entities.
Entities and their Attributes –
 Book Entity : It has auth-no, isbn number, title, edition, category,
price. ISBN is the Primary Key for Book Entity.
 Reader Entity : It has User-Id, Email, address, phone no, name. Name is
composite attribute of first-name and last-name. Phone no is multi valued
attribute. User-Id is the Primary Key for Readers entity.
 Publisher Entity : It has Publisher-Id, Year of publication, name.
Publisher-ID is the Primary Key.
 Authentication System Entity : It has Login-Id and password with Login-ID
as Primary Key.
 Reports Entity : It has User-Id, Reg-no, Book-no, Issue/Return date. Reg-
no is the Primary Key of reports entity.
 Staff Entity : It has name and staff-id with staff-id as Primary Key.
 Reserve/Return Relationship Set : It has three attributes: Reserve date,
Due date, Return date.
Relationships between Entities –
 A reader can reserve N books but one book can be reserved by only one
reader. The relationship 1:N.
 A publisher can publish many books but a book is published by only one
publisher. The relationship 1:N.
 Staff keeps track of readers. The relationship is M:N.
 Staff maintains multiple reports. The relationship 1:N.
 Staff maintains multiple Books. The relationship 1:N.

 Authentication system provides login to multiple staffs. The relation is
1:N.
ER diagram of Bank Management System

 Difficulty Level : Hard
 Last Updated : 25 Jun, 2020
ER diagram is known as Entity-Relationship diagram. It is used to analyze to
structure of the Database. It shows relationships between entities and their
attributes. An ER model provides a means of communication.
ER diagram of Bank has the following description :
 Bank have Customer.
 Banks are identified by a name, code, address of main office.
 Banks have branches.
 Branches are identified by a branch_no., branch_name, address.
 Customers are identified by name, cust-id, phone number, address.
 Customer can have one or more accounts.
 Accounts are identified by acc_no., acc_type, balance.
 Customer can avail loans.
 Loans are identified by loan_id, loan_type and amount.
 Account and loans are related to bank’s branch.
ER Diagram of Bank Management System :

This bank ER diagram illustrates key information about bank, including

entities such as branches, customers, accounts, and loans. It allows us to
understand the relationships between entities.
Entities and their Attributes are :
 Bank Entity : Attributes of Bank Entity are Bank Name, Code and Address.
Code is Primary Key for Bank Entity.
 Customer Entity : Attributes of Customer Entity are Customer_id, Name,
Phone Number and Address.
Customer_id is Primary Key for Customer Entity.
 Branch Entity : Attributes of Branch Entity are Branch_id, Name and
Address.
Branch_id is Primary Key for Branch Entity.

 Account Entity : Attributes of Account Entity are Account_number,
Account_Type and Balance.
Account_number is Primary Key for Account Entity.
 Loan Entity : Attributes of Loan Entity are Loan_id, Loan_Type and Amount.
Loan_id is Primary Key for Loan Entity.
Relationships are :
 Bank has Branches => 1 : N
One Bank can have many Branches but one Branch can not belong to many
Banks, so the relationship between Bank and Branch is one to many
relationship.
 Branch maintain Accounts => 1 : N
One Branch can have many Accounts but one Account can not belong to many
Branches, so the relationship between Branch and Account is one to many
relationship.
 Branch offer Loans => 1 : N
One Branch can have many Loans but one Loan can not belong to many
Branches, so the relationship between Branch and Loan is one to many
relationship.
 Account held by Customers => M : N
One Customer can have more than one Accounts and also One Account can be
held by one or more Customers, so the relationship between Account and
Customers is many to many relationship.
 Loan availed by Customer => M : N
(Assume loan can be jointly held by many Customers).
One Customer can have more than one Loans and also One Loan can be availed
by one or more Customers, so the relationship between Loan and Customers is
many to many relationship.



We will follow the 3 basic rules in creating the ER Diagram.
1. Identify all the entities.
2. Identify the relationship between entities and
3. Add meaningful attributes to our entities.
Step 1. In the Bus Booking System we have the following entities

 User
 Bus
 Travel Schedule
 Driver
 Booking
 Payment
 Customer
Our design of Bus Booking System consists of 7 entities; the specified
entities will be our database tables in the design and implementation of Bus
Booking database schema.
We will now draw the entities of the Bus Booking System specified above and it
will be represented by a rectangle shape. The image below is the entities
identified in the scope of the Bus Booking System.
Bus Booking System ER Diagram – Step 1 Identify Entities

Step 2. After we have specified our entities, it is time now to connect or
establish a relationship among the entities.
Bus Booking System ER Diagram – Step 2 Table Relationship

 The user encode/manage/update the bus information (1 to many
relationship).
 The bus has schedule of trips/travel (1 to many relationship).
 The user encode/manage/update the travel schedule of buses (1 to many
relationship).
 Travel schedule has booking transactions (1 to many relationship).
 Booking of the travel will be managed by the user (1 to many
relationship).
 The user encode/manage/update the customer information (1 to many
relationship).
 Customer processes and transacts booking of travel (1 to many
relationship).
 Booking will be paid by the customer (1 to 1 relationship).
 Payment transactions will be managed by the user The user
encode/manage/update the bus information (1 to many relationship).
 The user encode/manage/update the driver information (1 to many
relationship).
 The driver has schedule of trips/travel (1 to many relationship).
Step 3. The last part of the ERD process is to add attributes to our
entities.
Bus Booking System ER Diagram- Step 3 Complete ERD
User Entity has the following attributes:
 ID – primary key represented with underline
 Fullname
 Contact
 Email address
 Username
 Password

 Category
 Status
Bus Entity has the following attributes:
 Number
 Plate Number
 Type
 Capacity
 User ID – foreign key
Travel Schedule Entity has the following attributes:
 Driver ID – foreign key
 Bus ID – foreign key
 Starting Point
 Destination
 Departure Time
 Estimated Arrival Time
 Schedule Date
 Fare Amount
 Remarks
Driver Entity has the following attributes:
 Name
 Contact
Booking Entity has the following attributes:

 Customer ID – foreign key
 Schedule ID – foreign key
 Number of Seats
 Fare Amount
 Date of Booking
 Total Amount
 Status
Payment Entity has the following attributes:
 Booking ID – foreign key
 Amount Paid
 Date
Customer Entity has the following attributes:
 Name
 Contact
 Status
 Email
 Username
 Password
Note: all attributes with underline represents the primary key of the entity
or table.




a

How to Draw an Entity Relationship Diagram

There are a few basic steps to take to draw an ER diagram anywhere: in Gliffy,
with Powerpoint, a whiteboard, or even on the back of a napkin. Here’s the
basic order to follow.
1. Determine the Entities in Your ERD


Start by identifying the “what”s in your system or architecture. Entities
are represented with a rectangle, and you’ll want to give them plenty of room
so that you can add to your diagram in the next steps.
2. Add Attributes to Each Entity

Next, consider the attributes that you need to describe each entity. These are
drawn and labeled inside ovals. Connect these to the relevant entity and

position your attributes to the outside of your diagram, which leaves room for
relationships.
3. Define the Relationships Between Entities

Now, think through the relationships or verbs taking place within your system.
The easiest way to do this is to look at each entity and try to connect it to
another by saying, “What does the ___ do with the ___.” The customer
purchases the phone. The cell service maintains the phone. The cell service
creates a bill. The customer pays the bill.
4. Add Cardinality to Every Relationship

The final step for this simple ER diagram is to define the amount of data that
will come from each entity. Cardinality is a simple notation that quickly
tells your ERD reader whether there are zero, one, many, or some combination

of those factors between each entity. Your customer can purchase one or many
phones. The cell service maintains many phones. The customer pays one bill.
5. Finish and Save Your ERD
This is just a high-level ER model, but it provides enough detail that you
should now have a teammate or partner check your work. One of the best ways to
do this is to simply have them try to read your diagram out loud. If they end
up telling a different story than you intended, you need to do some tweaking.
Another good step to take is to clean up or polish your diagram — if you were
drawing by hand, you might have some stray eraser marks. Take a moment to
finalize your diagram by aligning shapes, adding color, or redrawing lines to
more clearly connect your entities, attributes, and relationships. All these
steps are easy if you’re using an online diagramming tool like Gliffy!
Why Draw an Entity Relationship Diagram Online?
There are a few benefits to using software to complete the above steps and
draw an entity relationship diagram. With Gliffy, you can:
 Track changes and create versions or your diagrams
 Embed your diagram in popular tools like Slack
 Quickly redraw lines and relationships without cluttering your diagram
 Use previous diagrams as a template for your next
You can give these features a try with a free trial of Gliffy Online. Or, if
your team uses Jira or Confluence, we’ve got an app for that, too!


Introduction to Data Modeling and Conceptual Database Design

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Introduction to Data Modeling and Conceptual Database Design

Uploaded by

Copyright:

Available Formats

DATA BASE MANAGEMENT SYSTEM (P18IS42)

Introduction to Data Model and Data modeling:

Data models are categorized into three categories. They are:

PUTTASWAMY B. S. Assistant Professor, Dept. of IS&E, PESCE Mandya Page 1

PUTTASWAMY B. S. Assistant Professor, Dept. of IS&E, PESCE Mandya Page 2

Conceptual modeling is a very important phase in designing a successful

Using High-Level Conceptual Data Models for Database Design:

PUTTASWAMY B. S. Assistant Professor, Dept. of IS&E, PESCE Mandya Page 3

PUTTASWAMY B. S. Assistant Professor, Dept. of IS&E, PESCE Mandya Page 4

The result of this phase is an Entity-Relationship (ER) diagram or UML class

PUTTASWAMY B. S. Assistant Professor, Dept. of IS&E, PESCE Mandya Page 5

Step 4: Physical Design: Physical design is the last phase of database

PUTTASWAMY B. S. Assistant Professor, Dept. of IS&E, PESCE Mandya Page 6

PUTTASWAMY B. S. Assistant Professor, Dept. of IS&E, PESCE Mandya Page 7

PUTTASWAMY B. S. Assistant Professor, Dept. of IS&E, PESCE Mandya Page 8

Entity Types, Entity Sets, Attributes, and Keys:

PUTTASWAMY B. S. Assistant Professor, Dept. of IS&E, PESCE Mandya Page 9

In 1976, Chen developed the Entity-Relationship (ER) model; ER model is a

3.4.2 Entities and Attributes:

PUTTASWAMY B. S. Assistant Professor, Dept. of IS&E, PESCE Mandya Page 10

Entities may be,

PUTTASWAMY B. S. Assistant Professor, Dept. of IS&E, PESCE Mandya Page 11

is also called as regular entity type. Symbol of strong entity is same as an

For example: STUDENT entity has STUDENT_ID as primary key. Hence it is a

PUTTASWAMY B. S. Assistant Professor, Dept. of IS&E, PESCE Mandya Page 12

Example of weak entity type is –

PUTTASWAMY B. S. Assistant Professor, Dept. of IS&E, PESCE Mandya Page 13

PUTTASWAMY B. S. Assistant Professor, Dept. of IS&E, PESCE Mandya Page 14

Notations Of different Entity Type in ER Diagram:

Recursive Entity Type

Composite Entity Type

Weak Entity Type

PUTTASWAMY B. S. Assistant Professor, Dept. of IS&E, PESCE Mandya Page 15

 Single valued attributes

Single valued Attributes: If an attribute of a particular entity represents

PUTTASWAMY B. S. Assistant Professor, Dept. of IS&E, PESCE Mandya Page 16

called a multi-valued attribute. Multi valued attribute is represented by a

For example, phone number of a person. Symbol of multi-valued attribute is

Multi Valued Attribute

PUTTASWAMY B. S. Assistant Professor, Dept. of IS&E, PESCE Mandya Page 17

Simple / Atomic attribute: The attributes which cannot be further divided

PUTTASWAMY B. S. Assistant Professor, Dept. of IS&E, PESCE Mandya Page 18

PUTTASWAMY B. S. Assistant Professor, Dept. of IS&E, PESCE Mandya Page 19

For example: ‘age’ is a derived attribute if it calculates its value from

PUTTASWAMY B. S. Assistant Professor, Dept. of IS&E, PESCE Mandya Page 20

Example: The entity student ID is a key attribute because no other student

PUTTASWAMY B. S. Assistant Professor, Dept. of IS&E, PESCE Mandya Page 21

Required Attribute: A required attribute is an attribute that must have a

PUTTASWAMY B. S. Assistant Professor, Dept. of IS&E, PESCE Mandya Page 22

For example, In a STUDENT entity, Middlename or email address is an optional

Example: Birth date of an employee is a stored attribute.

PUTTASWAMY B. S. Assistant Professor, Dept. of IS&E, PESCE Mandya Page 23

Key Attributes of an Entity Type:

PUTTASWAMY B. S. Assistant Professor, Dept. of IS&E, PESCE Mandya Page 24

PUTTASWAMY B. S. Assistant Professor, Dept. of IS&E, PESCE Mandya Page 25

Initial Conceptual Design of the COMPANY Database:

PUTTASWAMY B. S. Assistant Professor, Dept. of IS&E, PESCE Mandya Page 26

Relationship represents an association between two or more entities.

 Employees are assigned to projects

 Projects have subtasks

 Departments manage one or more projects

PUTTASWAMY B. S. Assistant Professor, Dept. of IS&E, PESCE Mandya Page 27

3.4 Relationship Types, Relationship Sets, Roles and Structural