DATABASE

ANALYSIS
SUKESH KUMAR BHAGAT
ER MODEL CONCEPT
ER (ENTITY RELATIONSHIP) DIAGRAM IN DBMS

• ER model stands for an Entity-Relationship model.

It is a high-level data model. This model is used to
define the data elements and relationship for a
specified system.
• It develops a conceptual design for the database. It
also develops a very simple and easy to design view
of data.
• In ER modeling, the database structure is portrayed
as a diagram called an entity-relationship diagram.
COMPONENT OF ER DIAGRAM
COMPONENT OF ER DIAGRAM

• 1. Entity:
• An entity may be any object, class, person or place. In the ER diagram, an entity can be represented as rectangles.
• Consider an organization as an example- manager, product, employee, department etc. can be taken as an entity.

a. Weak Entity

• An entity that depends on another entity called a weak entity. The weak entity doesn't contain any key attribute of
its own. The weak entity is represented by a double rectangle.
COMPONENT OF ER DIAGRAM

• 2. Attribute
• The attribute is used to describe the property of an entity. Eclipse is used to represent an attribute.
• For example, id, age, contact number, name, etc. can be attributes of a student.
a. Key Attribute
The key attribute is used to represent the main characteristics of an
entity. It represents a primary key. The key attribute is represented
by an ellipse with the text underlined.
b. Composite Attribute
An attribute that composed of many other attributes is known as a composite attribute. The
composite attribute is represented by an ellipse, and those ellipses are connected with an ellipse.
• c. Multivalued Attribute
• An attribute can have more than one value. These attributes are
known as a multivalued attribute. The double oval is used to
represent multivalued attribute.
• For example, a student can have more than one phone number.

• d. Derived Attribute
• An attribute that can be derived from other attribute is known as a
derived attribute. It can be represented by a dashed ellipse.
• For example, A person's age changes over time and can be derived
from another attribute like Date of birth.
RELATIONSHIP

• A relationship is used to describe the relation between entities. Diamond or rhombus is used to represent the
relationship.

• Types of relationship are as follows:

• a. One-to-One Relationship
• b. One-to-many relationship
• c. Many-to-one relationship
• d. Many-to-many relationship
ONE-TO-ONE RELATIONSHIP

• When only one instance of an entity is associated with the relationship, then it is known
as one to one relationship.
• For example, A female can marry to one male, and a male can marry to one female.
ONE-TO-MANY RELATIONSHIP

• When only one instance of the entity on the left, and more than one instance of an entity
on the right associates with the relationship then this is known as a one-to-many
relationship.
• For example, Scientist can invent many inventions, but the invention is done by the only
specific scientist.
MANY-TO-ONE RELATIONSHIP

• When more than one instance of the entity on the left, and only one instance of an entity
on the right associates with the relationship then it is known as a many-to-one
relationship.
• For example, Student enrolls for only one course, but a course can have many students.
MANY-TO-MANY RELATIONSHIP

• When more than one instance of the entity on the left, and more than one instance of an
entity on the right associates with the relationship then it is known as a many-to-many
relationship.
• For example, Employee can assign by many projects and project can have many
employees.
NOTATION OF ER DIAGRAM

• Database can be represented using the notations. In ER diagram, many notations are used
to express the cardinality. These notations are as follows:
ER DESIGN ISSUES

• the basic design issues of an ER database schema in the following points:

• 1) Use of Entity Set vs Attributes
• 2) Use of Entity Set vs. Relationship Sets
• 3) Use of Binary vs n-ary Relationship Sets
• 4) Placing Relationship Attributes
USE OF ENTITY SET VS ATTRIBUTES

• The use of an entity set or attribute depends on the structure of the real-world enterprise
that is being modelled and the semantics associated with its attributes.
• It leads to a mistake when the user use the primary key of an entity set as an attribute of
another entity set. Instead, he should use the relationship to do so. Also, the primary key
attributes are implicit in the relationship set, but we designate it in the relationship sets.
USE OF ENTITY SET VS. RELATIONSHIP SETS

• It is difficult to examine if an object can be best expressed by an entity set or relationship

set.
• To understand and determine the right use, the user need to designate a relationship set
for describing an action that occurs in-between the entities. If there is a requirement of
representing the object as a relationship set, then its better not to mix it with the entity set.
USE OF BINARY VS N-ARY RELATIONSHIP SETS

• Generally, the relationships described in the databases are binary relationships. However,
non-binary relationships can be represented by several binary relationships.
• For example, we can create and represent a ternary relationship 'parent' that may relate to
a child, his father, as well as his mother. Such relationship can also be represented by two
binary relationships i.e, mother and father, that may relate to their child. Thus, it is
possible to represent a non-binary relationship by a set of distinct binary relationships.
PLACING RELATIONSHIP ATTRIBUTES

• The cardinality ratios can become an affective measure in the placement of the relationship attributes.
• So, it is better to associate the attributes of one-to-one or one-to-many relationship sets with any participating
entity sets, instead of any relationship set. The decision of placing the specified attribute as a relationship or
entity attribute should possess the charactestics of the real world enterprise that is being modelled.

For example, if there is an entity which can be determined by the combination of participating entity sets,
instead of determing it as a separate entity. Such type of attribute must be associated with the many-to-many
relationship sets.
• Thus, it requires the overall knowledge of each part that is involved inb desgining and modelling an ER
diagram. The basic requirement is to analyse the real-world enterprise and the connectivity of one entity or
attribute with other.
 CARDINALITY IN DBMS (MAPPING
CONSTRAINTS)
Cardinality
Cardinality means how the entities are arranged to each other or what is the relationship structure between
entities in a relationship set.
In a Database Management System, Cardinality represents a number that denotes how many times an entity is
participating with another entity in a relationship set. The Cardinality of DBMS is a very important attribute in
representing the structure of a Database. In a table, the number of rows or tuples represents the Cardinality.
Cardinality Ratio
Cardinality ratio is also called Cardinality Mapping, which represents the mapping of one entity set to another
entity set in a relationship set. We generally take the example of a binary relationship set where two entities are
mapped to each other.
Cardinality is very important in the Database of various businesses. For example, if we want to track the
purchase history of each customer then we can use the one-to-many cardinality to find the data of a specific
customer. The Cardinality model can be used in Databases by Database Managers for a variety of purposes, but
corporations often use it to evaluate customer or inventory data.
KEYS

• Keys play an important role in the relational database.

• It is used to uniquely identify any record or row of data from the table. It is also used to
establish and identify relationships between tables.
• For example, ID is used as a key in the Student table because it is unique for each
student. In the PERSON table, passport_number, license_number, SSN are keys since
they are unique for each person.
TYPES OF KEYS

1. PRIMARY KEY

2. CANDIDATE KEY

3. SUPER KEY

4. FOREIGN KEY

5. ALTERNATE KEY

6. COMPOSITE KEY

7. ARTIFICIAL KEY
PRIMARY KEY

• It is the first key used to identify one and only one

instance of an entity uniquely. An entity can contain
multiple keys, as we saw in the PERSON table. The
key which is most suitable from those lists becomes a
primary key.
• In the EMPLOYEE table, ID can be the primary key
since it is unique for each employee. In the
EMPLOYEE table, we can even select
License_Number and Passport_Number as primary
keys since they are also unique.
• For each entity, the primary key selection is based on
requirements and developers.
CANDIDATE KEY

• A candidate key is an attribute or set of attributes

that can uniquely identify a tuple.
• Except for the primary key, the remaining
attributes are considered a candidate key. The
candidate keys are as strong as the primary key.
• For example: In the EMPLOYEE table, id is
best suited for the primary key. The rest of the
attributes, like SSN, Passport_Number,
License_Number, etc., are considered a candidate
key.
SUPER KEY

• Super key is an attribute set that can uniquely

identify a tuple. A super key is a superset of a
candidate key.
• For example: In the above EMPLOYEE table,
for(EMPLOEE_ID, EMPLOYEE_NAME), the
name of two employees can be the same, but
their EMPLYEE_ID can't be the same. Hence,
this combination can also be a key.
• The super key would be EMPLOYEE-ID
(EMPLOYEE_ID, EMPLOYEE-NAME), etc.
FOREIGN KEY

• Foreign keys are the column of the table used to point to the
primary key of another table.
• Every employee works in a specific department in a
company, and employee and department are two different
entities. So we can't store the department's information in the
employee table. That's why we link these two tables through
the primary key of one table.
• We add the primary key of the DEPARTMENT table,
Department_Id, as a new attribute in the EMPLOYEE table.
• In the EMPLOYEE table, Department_Id is the foreign key,
and both the tables are related.
ALTERNATE KEY

• There may be one or more attributes or a combination of attributes

that uniquely identify each tuple in a relation. These attributes or
combinations of the attributes are called the candidate keys. One
key is chosen as the primary key from these candidate keys, and
the remaining candidate key, if it exists, is termed the alternate
key. In other words, the total number of the alternate keys is the
total number of candidate keys minus the primary key. The
alternate key may or may not exist. If there is only one candidate
key in a relation, it does not have an alternate key.
• For example, employee relation has two attributes, Employee_Id
and PAN_No, that act as candidate keys. In this relation,
Employee_Id is chosen as the primary key, so the other candidate
key, PAN_No, acts as the Alternate key.
COMPOSITE KEY

• Whenever a primary key consists of more than one

attribute, it is known as a composite key. This key is
also known as Concatenated Key.
• For example, in employee relations, we assume that
an employee may be assigned multiple roles, and an
employee may work on multiple projects
simultaneously. So the primary key will be composed
of all three attributes, namely Emp_ID, Emp_role, and
Proj_ID in combination. So these attributes act as a
composite key since the primary key comprises more
than one attribute.
ARTIFICIAL KEY

• The key created using arbitrarily assigned data are

known as artificial keys. These keys are created
when a primary key is large and complex and has
no relationship with many other relations. The data
values of the artificial keys are usually numbered
in a serial order.
• For example, the primary key, which is composed
of Emp_ID, Emp_role, and Proj_ID, is large in
employee relations. So it would be better to add a
new virtual attribute to identify each tuple in the
relation uniquely.
• CREATE TABLE Persons (
ID int NOT NULL PRIMARY KEY,
LastName varchar(255) NOT NULL,
FirstName varchar(255),
Age int
);
-- Using a nested query
SELECT *
FROM orders
WHERE customer_id IN (SELECT customer_id FROM customers WHERE city = 'New York');

-- Using INNER JOIN

SELECT employees.employee_name, departments.department_name
FROM employees
INNER JOIN departments ON employees.department_id = departments.department_id;

-- Using nested queries and joins

SELECT orders.order_id, customers.customer_name, products.product_name
FROM orders
JOIN customers ON orders.customer_id = customers.customer_id
JOIN products ON orders.product_id = products.product_id;
GENERALIZATION

• Generalization is like a bottom-up approach in which two or more entities of

lower level combine to form a higher level entity if they have some attributes in
common.
• In generalization, an entity of a higher level can also combine with the entities of
the lower level to form a further higher level entity.
• Generalization is more like subclass and superclass system, but the only
difference is the approach. Generalization uses the bottom-up approach.
• In generalization, entities are combined to form a more generalized entity, i.e.,
subclasses are combined to make a superclass.
• For example, Faculty and Student entities can be generalized and create a higher
level entity Person.
SPECIALIZATION

• Specialization is a top-down approach, and it is opposite to Generalization.

In specialization, one higher level entity can be broken down into two lower
level entities.
• Specialization is used to identify the subset of an entity set that shares some
distinguishing characteristics.
• Normally, the superclass is defined first, the subclass and its related attributes
are defined next, and relationship set are then added.
• For example: In an Employee management system, EMPLOYEE entity can
be specialized as TESTER or DEVELOPER based on what role they play in
the company.
AGGREGATION

• In aggregation, the relation between two entities is

treated as a single entity. In aggregation, relationship
with its corresponding entities is aggregated into a
higher level entity.
• For example: Center entity offers the Course entity act
as a single entity in the relationship which is in a
relationship with another entity visitor. In the real world,
if a visitor visits a coaching center then he will never
enquiry about the Course only or just about the Center
instead he will ask the enquiry about both.
REDUCTION OF ER DIAGRAM TO TABLE

• The database can be represented using the notations, and these notations can be reduced to a
collection of tables.
• In the database, every entity set or relationship set can be represented in tabular form.
• The ER diagram is given below:
REDUCTION OF ER DIAGRAM TO TABLE
There are some points for converting the ER diagram to the table:

• Entity type becomes a table.

• In the given ER diagram, LECTURE, STUDENT, SUBJECT and COURSE forms individual tables.
• All single-valued attribute becomes a column for the table.
• In the STUDENT entity, STUDENT_NAME and STUDENT_ID form the column of STUDENT table. Similarly, COURSE_NAME and COURSE_ID form the
column of COURSE table and so on.
• A key attribute of the entity type represented by the primary key.
• In the given ER diagram, COURSE_ID, STUDENT_ID, SUBJECT_ID, and LECTURE_ID are the key attribute of the entity.
• The multivalued attribute is represented by a separate table.
• In the student table, a hobby is a multivalued attribute. So it is not possible to represent multiple values in a single column of STUDENT table. Hence we create a
table STUD_HOBBY with column name STUDENT_ID and HOBBY. Using both the column, we create a composite key.
• Composite attribute represented by components.
• In the given ER diagram, student address is a composite attribute. It contains CITY, PIN, DOOR#, STREET, and STATE. In the STUDENT table, these attributes
can merge as an individual column.
• Derived attributes are not considered in the table.
• In the STUDENT table, Age is the derived attribute. It can be calculated at any point of time by calculating the difference between current date and Date of Birth.
REDUCTION OF ER DIAGRAM TO TABLE

• Using these rules, you can

convert the ER diagram to tables
and columns and assign the
mapping between the tables.
Table structure for the given ER
diagram is as below:
RELATIONSHIP OF HIGHER DEGREE

• The degree of relationship can be defined as the number of occurrences in one entity that
is associated with the number of occurrences in another entity.
• There is the three degree of relationship:
1. One-to-one (1:1)
2. One-to-many (1:M)
3. Many-to-many (M:N)
ONE-TO-ONE

• In a one-to-one relationship, one occurrence of an entity relates to only one occurrence in

another entity.
• A one-to-one relationship rarely exists in practice.
• For example: if an employee is allocated a company car then that car can only be driven
by that employee.
• Therefore, employee and company car have a one-to-one relationship.
 ONE-TO-MANY MANY-TO-MANY

• In a many-to-many relationship, many occurrences in an

• In a one-to-many relationship, one occurrence in an
entity relate to many occurrences in another entity.
entity relates to many occurrences in another entity.
• Same as a one-to-one relationship, the many-to-many
• For example: An employee works in one relationship rarely exists in practice.
department, but a department has many employees.
• For example: At the same time, an employee can work on
• Therefore, department and employee have a one-to- several projects, and a project has a team of many
many relationship. employees.
• Therefore, employee and project have a many-to-many
relationship
Company Database
 TABLE NAME: DEPENDENT

Field Description Type Length

Name Name of the dependent Varchar 255

Sex Gender of the dependent Varchar 255

Birth_date Date of birth of the dependent Varchar 255

Relationship Relationship of the company varchar

TABLE NAME: DEPARTMENT

Field Description Type Length

Name Department varchar 255
name
location Department varchar 255
location
TABLE NAME: PROJECT

Field Description Type Length

Name Name of the project Varchar 255

Budget Budget of the Int 11

project

Location Location of the Varchar 255

project
TABLE NAME: EMPLOYEE

Field Description Type Length

First_name First name of employee Varchar 255
Middle_initial Middle name of employee Varchar 255
Last_name Last name of employee Varchar 255
Status Status of employee Varchar 255
Address Address of employee Varchar 255
Salary Salary of the emplyee int 10
Sex Gender of the employee Varchar 255
ssn Seriel number of number Int 10
CONCEPTUAL MODELING USING THE
ENTITY-RELATIONSHIP MODEL
CONTENT

• Basic concepts: entities and entity types, attributes and keys, relationships and relationship
types
• Entity-Relationship schema (aka ER diagram)
• Constraints on relationship types
• Design choices
• Enhanced Entity-Relationship model features
• Steps in designing an ER schema
• Translation of an ER schema to tables
WHAT DOES CONCEPTUAL DESIGN INCLUDE?

• Entity-Relationship model is used in the conceptual design of a database

(☞ conceptual level, conceptual schema)

• Design is independent of all physical considerations (DBMS, OS, . . . ).

Questions that are addressed during conceptual design:

– What are the entities and relationships of interest (miniworld)?
– What information about entities and relationships among entities needs to be stored in the database?
– What are the constraints (or business rules) that (must) hold for the entities and relationships?

• A database schema in the ER model can be represented pictorially

(Entity-Relationship diagram)
ENTITY TYPES, ENTITY SETS, ATTRIBUTES AND
KEYS
• Entity: real-world object or thing with an independent existence and which is distinguishable from other
objects. Examples are a person, car, customer, product, gene, book etc.
• Attributes: an entity is represented by a set of attributes (its descriptive properties), e.g., name, age, salary,
price etc. Attribute values that describe each entity become a major part of the data eventually stored in a
database.
• With each attribute a domain is associated, i.e., a set of permitted values for an attribute. Possible domains
are integer, string, date, etc.
• Entity Type: Collection of entities that all have the same attributes, e.g., persons, cars, customers etc.
• Entity Set: Collection of entities of a particular entity type at any point in time; entity set is typically referred
to using the same name as entity type.
KEY ATTRIBUTES OF AN ENTITY TYPE

• Entities of an entity type need to be distinguishable.

• A superkey of an entity type is a set of one or more attributes whose values uniquely
determine each entity in an entity set.
• A candidate key of an entity type is a minimal (in terms of number of attributes)
superkey.
• For an entity type, several candidate keys may exist. During conceptual design, one of the
candidate keys is selected to be the primary key of the entity type.
RELATIONSHIPS, RELATIONSHIP TYPES, AND
RELATIONSHIP SETS
• Relationship (instance): association among two or more entities,
• e.g., customer Smith orders product PC42
• Relationship Type: collection of similar relationships An n-ary relationship type R links n entity
types E1…….. En. Each relationship in a relationship set R of a relationship type involves entities e1
E1 ,…., En

• Degree of a relationship: refers to the number of entity types that participate in the relationship type
(binary, ternary, . . . )
• Roles: The same entity type can participate more than once in a relationship type.

• Role labels clarify semantics of a relationship, i.e., the way in which an entity participates in a relationship.

~recursive relationship
• Relationship Attributes: A relationship type can have attributes describing properties of a relationship. customer
Smith ordered product PC42 on January 11, 2005, for $2345 .
• These are attributes that cannot be associated with participating entities only, i.e., they make only sense in the
context of a relationship.
• Note that a relationship does not have key attributes! The identification of a particular relationship in a relationship
set occurs through the keys of participating entities.
EXAMPLE OF AN ENTITY-RELATIONSHIP
DIAGRAM
• Rectangles represent entity types
• Ellipses represent attributes
• Diamonds represent relationship types
• Lines link attributes to entity types and entity types to relationship types
• Primary key attributes are underlined
• Empty Circle at the end of a line linking an attribute to an entity type represents an optional (null)
attribute (not mentioned in textbook) Not in the above diagram, but later in examples:
• Double Ellipses represent multi-valued attributes
CONSTRAINTS ON RELATIONSHIP TYPES

• Limit the number of possible combinations of entities that may participate in a

relationship set.
• There are two types of constraints:
• cardinality ratio and participation constraints
• Very useful concept in describing binary relationship types. For binary relationships, the
cardinality ratio must be one of the following types
CONSTRAINTS ON RELATIONSHIP TYPES (CONT.)
QUESTION-ANSWER
QUESTION BANK
1. Define (i)Entity (ii)Attribute

2. Define Relationship and Relationship set?

3. Explain about query in relational data?

4. Explain different type of Entities.

5. Explain different types of Attributes.

6. What are the basic constructs of ER model?

7. Write a short note on Entity-Relationship model.

8. Define weak Entity set.

9. Explain Referential Integrity.

10. Define Entity, Entity Set, and extensions of entity set.

11. Define and give examples to illustrate the four types of attributes in database.

12. Define relationship and participation

13. Define mapping cardinality or cardinality ratio.

14. Define single valued and multi valued attributes.

15. Define the terms i)Key attribute ii)Value set

16. Explain candidate key, primary key and foreign key.

17. Define database state or snapshot?

18. How are complex attributes represented?

19. Define value sets of attributes.

20. Define degree of relationship type?

1. Describe about Data Models and explain E-R model.

2. What is mapping cardinalities? Explain it with realtime examples.

3. Explain Specialization feature of ER diagram with example.

4. Explain Generalization feature of E-R Diagram.

5. Explain aggregation operation of ER diagram.

6. What is constraint in database? Explain types of constraints with suitable example.

7. Explain with example various keys used in Database management

8. Distinguish between simple and composite attributes

9. Explain Degree of Relationship and its types.

10. Define Null Values?

11. Explain specialization and generalization concepts in ER diagram with Suitable example.

12. What is Functional dependency? Explain its usage in database design. Explain various types of Functional dependency.

13. Explain following terms in detail. Entity set, Simple attribute, Composite attribute, single valued attribute, multi valued attribute, Null attribute,
derived attribute.

14. Construct E-R diagram for a hospital with a set of patients and medical

15. Doctors. Associate with each patient a log of various tests and examinations conducted.

16. Give Symbol used in E-R Diagram and Draw the E-R diagram of Library Management System.

17. Draw symbols for following in E-R diagram: .Weak Entity set, Derived attribute, Multi valued .Relationship Set ,and Primary key attribute.
Q.37
38.Convert following ER Diagram into database using Queries:
39.Construct ER Diagram & ER Model for the given problem:
40. Construct ER Diagram & ER Model for the given problem:
1.DEFINE (I) ENTITY (II) ATTRIBUTE
• Entity
• An entity is an object that data is captured about. It can be a person, place, thing, event, or concept. An entity can contain many
attributes, which further define the information stored.

• Attribute
• An attribute is a property or characteristic of an entity. For example, a person's attributes might include their height, weight, and
date of birth. An entity can contain multiple attributes, but one attribute is considered the primary key.
2. DEFINE RELATIONSHIP AND RELATIONSHIP
SET?
• In a database, a relationship is a connection between two tables.
• A relationship set is a collection of relationships that are all of the same type.