2. Syllabus
CONCEPTUAL DESIGNAND DATABASE DESIGN:
High-level Conceptual Data Models for Database
Design, A Sample Database Application, Entity
Types, Entity Sets, Attributes and Keys,
Relationship Types, Relationship Sets, Roles and
Structural Constraints, Weak Entity Types, Refining
the ER Design for the Company Database, ER
Diagrams, Naming Conventions and Design Issues,
Subclasses, Super classes and Inheritance
3. Entity
An entity is a thing in a real-world with independent
existence.
An entity can exist independently and is
distinguishable from other objects.
It can be identified uniquely.
4. Entity
An entity can be of two types :
Tangible Entity : Entities that exist in the real world
physically.
Example: Person, car, etc.
Intangible Entity : Entities that exist only logically and
have no physical existence.
Example: Bank Account, etc.
5. Entity
An Entity may be an object with a physical
existence – a particular person, car, house, or
employee – or it may be an object with a
conceptual existence – a company, a job, or a
university course.
6. Attribute
An attribute describes the property or
characteristics of an entity.
Ex: An Employee entity can be described by
employee ‘s name, age, address, salary and job.
An entity will have a value for each of its attributes
13. Derived attribute
A Derived attribute is the one which do not exit in
physical database but their values are derived from
values of the other attributes
Example: Total and average marks of a student.
20. Key Attribute
The attribute which uniquely identifies each entity
in the entity set is called key attribute.
For example, Roll_No will be unique for each
student.
In ER diagram, key attribute is represented by an
oval with underlying lines.
24. Entity type
An Entity type defines a collection of entities
having the same type.
Each entity type is described by its name and
attributes
Ex: EMPLOYEE
26. Entity Set
An Entity Set is a collection of all entities of a
particular entity type in th database at any given
time .
Entity sets usually have same name as entity
types
Ex: set of all persons who are customers at a
given Bank can be defined as entity set
Customer.
29. ER Diagram
ER diagram or Entity Relationship diagram is a
conceptual model that gives the graphical
representation of the logical structure of the
database.
It shows all the constraints and relationships that
exist among the different components.
30. ER Diagram
An ER diagram is mainly composed of following
three components-
Entity Sets
Attributes
Relationship Set
33. ER Model notations
This is an ER model of a Hospital. The entities are represented
in rectangular boxes and are Patient, Tests and Doctor.
Each of these entities have their respective attributes which are
−
Patients - ID(primary key), name, age,visit_date
Tests- Name(primary key), date, result
Doctor- ID(primary key), name, specialization
The relationships between different entities are represented by a
diamond shaped box.
35. ER Model Example of a Company
The entities in this ER model are Employee,
Department and Project. These entities have the
following attributes
Employee - ENO(Primary Key) , Name, Salary
Department - DNO(Primary key), Name, Locations
Project - PNO(Primary key), Name
The relationships in this ER model are represented as
Works for and Controls.
36. Strong Entity
Strong Entity will always have a primary key
Its existence does not depend on any other entity
A set of strong entities is called a Strong entity set
strong entity is represented by a rectangle.
The relationship between two strong entities is represented
by a single diamond.
37.
38. Example for the strong entity
Consider the ER diagram which consists of two
entities student and course
Student entity is a strong entity because it
consists of a primary key called student id which
is enough for accessing each record uniquely
In the same way, the course entity contains of
course ID attribute which is capable of uniquely
accessing each row.
39. Weak Entity
A weak entity is an entity set that does not have
sufficient attributes for Unique Identification of its
records.
i.e. It does not have primary key
A Weak entity depends on strong entity for its
existence.
A set of weak entities is known as weak entity set
Weak entity is represented by a Double rectangle.
40. Weak Entity
It contains a partial key called a discriminator
which helps in identifying a group of entities from
the entity set .
A discriminator is represented by underlining with
a dashed line
41. Identifying Relationship
The double diamond symbol is used for
representing the relationship between a strong
entity and a weak entity which is known as
identifying relationship
44. Strong Entity Vs. Weak Entity
Strong entity
Strong entity always has a primary key
It is not dependent on any other entity
Represented by a single rectangle
Relationship between two strong entities is represented by
a single diamond
A strong entity may or may not have total participation
Weak entity
Will not have a primary key but it has partial discriminator key
Which entity is dependent on the strong entity
Represented by double rectangle relationship between a strong
entity and the weak entity is represented by double Diamond
It has always total participation
45. Domain of attributes
Each simple attribute of an entity type is
associated with a value set (or domain of values),
which specifies the set of values that may be
assigned to that attribute.
The domain of the attribute is the set of all valid
values thus that the attribute can have
Ex: The domain of the attribute age of an entity
employee is set of all integers between 18 and
65.
46. Domain of attributes
If the composite attribute can have n values with
domain D1, D2,…..Dn then the domain for the
attribute is
D1 × D2 ×…….× Dn
48. Degree of a Relationship Set
The number of entity sets that participate in a
relationship set is termed as the degree of that
relationship set.
Thus
Degree of a relationship set = Number of entity sets
participating in a relationship set
49. Types of Relationship sets
On the basis of degree of a relationship set, a
relationship set can be classified into the following
types
50. Unary Relationship set
Unary relationship set is a relationship set where
only one entity set participates in a relationship set.
51. Unary Relationship set
In a particular class, we have many students, there
are monitors too. So, here class monitors are also
students. Thus, we can say that only students are
participating here. So the degree of such type of
relationship is 1.
52. Binary Relationship set
Binary relationship set is a relationship set where
two entity sets participate in a relationship set.
53. Binary Relationship set
We have two entity types ‘Student’ and ‘ID’ where
each ‘Student’ has his ‘ID’. So, here two entity types
are associating we can say it is a binary relationship.
Also, one ‘Student’ can have many ‘daughters’ but
each ‘daughter’ should belong to only one ‘father.
We can say that it is a one-to-many binary
relationship.
54. Ternary Relationship set
Ternary relationship set is a relationship set where
three entity sets participate in a relationship set..
55. Ternary Relationship set
We have three entity types ‘Teacher’, ‘Course’, and
‘Class’. The relationship between these entities is
defined as the teacher teaching a particular course,
also the teacher teaches a particular class. So, here
three entity types are associating we can say it is a
ternary relationship.
56. N-ary Relationship set
N- ary relationship set is a relationship set where ‘n’
entity sets participate in a relationship set.
Example: We have 5 entities Teacher, Class,
Location, Salary, Course. So, here five entity types are
associating we can say an n-ary relationship is 5.
58. Constraints on relationship
Relationship types usually have certain
constraints that limit the possible combination of
entities that may participate in the corresponding
relationship set
For example if the company has the rule that each
employee must work for exactly one department, then
we would like to describe this constraint in the schema.
Main types of relationship constraints are
cardinality Ratio
Participation
59. Cardinality Ration for Binary
relationship
The cardinality Ratio of a Binary Relationship
specifies the maximum number of relationship
instances an entity can participate.
60. Types of Cardinality Ratio
1. One to One (1:1)
2. One to Many (1: N)
3. Many to One (M:1 )
4. Many to Many (M: N)
61. one – to –one
By this cardinality constraint,
An entity in set A can be associated with at most one
entity in set B.
An entity in set B can be associated with at most one
entity in set A.
62. Example
. Consider the following ER diagram-
Here,
One student can enroll in at most one course.
One course can be enrolled by at most one student
63. Example
An example of a 1:1 binary relationship is MANAGES
which relates a department entity to the employee who
manages that department. This represents the mini-world
constraints that at any point in time-an employee can
manage only one department and a department has only
one manager
65. one-to - many
By this cardinality constraint,
An entity in set A can be associated with any number
(zero or more) of entities in set B.
An entity in set B can be associated with at most one
entity in set A.
66.
67. one-to - many
Here,
One student can enroll in any number (zero or more) of
courses.
One course can be enrolled by at most one student.
68. Many-to – one
By this cardinality constraint,
An entity in set A can be associated with at most one
entity in set B.
An entity in set B can be associated with any number
(zero or more) of entities in set A.
69. Many-to – one
One student can enroll in at most one course.
One course can be enrolled by any number (zero or
more) of students.
71. many to many
An entity in A is associated with many entities in
B, and an entity in B is associated with many
entities in A.
The relationship type WORKS_ON is of
cardinality ratio M:N, because the mini-world rule
is that an employee can work on several projects
and a project can have several employees.
76. participation constraints
This constraint specifies the minimum number of
relationship instances that each entity can
participate in, and is sometimes called the
minimum cardinality constraint.
There are two types of participation constraints-
Total participation
Partial participation
77. Total participation
It specifies that each entity in the entity set must
compulsorily participate in at least one relationship
instance in that relationship set.
That is why, it is also called as mandatory
participation.
Total participation is represented using a double
line between the entity set and relationship set.
78. Total participation
Consider two entities Employee and Department related via
Works For relationship. Now, every Employee works in at
least one department therefore an Employee entity exist if it
has at least one Works For relationship with Department
entity. Thus the participation of Employee in Works For is
total relationship. Total Participation is represented by
double line in ER diagram.
79. Example of total participation constraint
It specifies that each student must be enrolled in at
least one course where the “student” is the entity set
and relationship “enrolled in” signifies total
participation
It means that every student must have enrolled at least
in one course
80. partial participation
Partial participation means only some of the entities
of an entity type can be participated in a
relationship set
It specifies that each entity in the entity set may or
may not participate in the relationship instance in
that relationship set.
That is why, it is also called as optional
participation.
Partial participation is represented using a single
line between the entity set and relationship set.
81. partial participation
For example: Consider two entities Employee and
Department and they are related to each other via
Manages relationship.
An Employee must manage a Department, he or she
could be the head of the department. But not every
Employee in the company manages the department.
So, participation of employee in the Manages
relationship type is partial i.e. only a particular set of
Employees will manage the Department but not all.
84. partial participation
A single line between the entities i.e. courses and
enrolled in a relationship signifies the partial
participation, which means there might be some
courses where enrollments are not made i.e
enrollments are optional in that case
85. ER Diagram Design issues
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
86. 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
modeled 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.
87. 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.
88. 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 relationship
89. 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
modeled.
90. ER Diagram Naming Conventions
To represent each element of ER model in ER Diagram, different
naming conventions are used.
In ER diagrams, entity type and relationship type names are
represented in upper case letters and attribute names have their
initial letter capitalized and role names are in lower case letters
Another naming convention involves choosing binary relationship
names to make the ER diagram of the schema readable from left to
right and from top to bottom
91. ER Diagram Naming Conventions
To represent each element of ER model in ER Diagram, different
naming conventions are used.
In ER diagrams, entity type and relationship type names are
represented in upper case letters and attribute names have their
initial letter capitalized and role names are in lower case letters
Another naming convention involves choosing binary relationship
names to make the ER diagram of the schema readable from left to
right and from top to bottom
92. Cardinality and Cardinality Ratio
cardinality defines number of entities in one entity set
which can be associated with number of entities of
another entity set via relationship set.
Cardinality Ratio tells how many times the entity of
an entity set participates in a relationship.
93. Roles and structural constraints of
Relationship in E-R Model
The main role of Relationship is to define the link between
Entities.
Relationship in E-R Model can be represented by Diamond
symbol.
94. Roles and structural constraints of
Relationship in E-R Model
Structural Constraints are also called Structural properties of
a database management system (DBMS).
Cardinality Ratios and Participation Constraints taken
together are called Structural Constraints.
The Structural constraints are represented by Min-Max
notation. This is a pair of numbers(m, n) that appear on the
connecting line between the entities and their relationships.
95. Roles and structural constraints of
Relationship in E-R Model
The minimum number of times an entity can appear in a
relation is represented by m whereas, the maximum time it is
available is denoted by n.
If m is 0 it signifies that the entity is participating in the
relation partially, whereas, if m is either greater than or equal
to 1, it denotes total participation of the entity.
Number of times an entity participates in a relationship is
same as the number appearance of the entity in the tuples
96. EER (Enhanced Entity Relationship) Model
The ER model is generally sufficient for "traditional"
database
applications.
But more recent applications of DB technology (e.g.,
CAD/CAM,
telecommunication, images/graphics, multimedia, data
mining/warehousing, geographic info systems) require for
a richer model.
97. EER (Enhanced Entity Relationship) Model
In addition to ER model concepts EE-R includes −
Subclasses and Super classes.
Specialization and Generalization.
Category or union type.
Aggregation.
Generalization, Specialization and Aggregation in ER model are
used for data abstraction in which abstraction mechanism is used to
hide details of a set of objects.
98. advantages
It is quite simple to develop and maintain. In addition to
this, it is easy to understand and interpret as well,
technically speaking.
Everything that is visually represented is easier to
understand and maintain, and the same goes for
Enhanced ER models. It has been an efficient tool for
database designers.
Moreover, Enhanced ER Model serves as a
communication tool and helps display the relationship
between entities.
You can always convert the Enhanced ER model into a
table. Thus, it can easily be integrated into a relational
model.
99. super & sub class
A superclass is a high-level entity that can be further
segmented into subclasses or subsets.
It is also referred to as a Parent class.
A subclass can be referred to as a child or derived
class.
For example, if Shape is considered an entity, then a
Square, Circle, and Triangle are possible subclasses.
101. Generalization
Generalization is the process of extracting common
properties from a set of entities and create a generalized
entity from it.
The process of extracting the common attributes or
properties of entities (subclasses) to sum up and form a
superclass is known as Generalization.
It is a bottom-up approach in which two or more entities can
be generalized to a higher level entity if they have some
attributes in common.
For Example, STUDENT and FACULTY can be generalized
to a higher level entity called PERSON as shown below
102. common attributes like P_NAME, P_ADD become part of higher
entity (PERSON) and specialized attributes like S_FEE become
part of specialized entity (STUDENT).
103. EXAMPLE
Consider two entities Student and Patient. These two entities
will have some characteristics of their own. For example
Student entity will have Roll_No, Name and Mob_No while
patient will have PId, Name and Mob_No characteristics. Now
in this example Name and Mob_No of both Student and
Patient can be combined as a Person to form one higher level
entity and this process is called as Generalization Process.
104.
105. Specialization
In specialization, an entity is divided into sub-entities based on
their characteristics.
It is a top-down approach where higher level entity is
specialized into two or more lower level entities.
For Example, EMPLOYEE entity in an Employee management
system can be specialized into DEVELOPER, TESTER etc.
common attributes like E_NAME, E_SAL etc. become part of
higher entity (EMPLOYEE) and specialized attributes like
TES_TYPE become part of specialized entity (TESTER).
106.
107. Example
Consider an entity Account. This will have some attributes
consider them Acc_No and Balance. Account entity may have
some other attributes like Current_Acc and Savings_Acc. Now
Current_Acc may have Acc_No, Balance and Transactions
while Savings_Acc may have Acc_No, Balance and
Interest_Rate henceforth we can say that specialized entities
inherits characteristics of higher level entity.
108.
109. Generalization Specilization
Generalization works in Bottom-
Up approach.
Specialization works in top-down
approach.
In Generalization, size of schema
gets reduced.
In Specialization, size of schema
gets increased.
Generalization is normally
applied to group of entities.
We can apply Specialization to a
single entity.
Generalization can be defined as
a process of creating groupings
from various entity sets
Specialization can be defined as
process of creating subgrouping
within an entity set
In Generalization process, what
actually happens is that it takes
the union of two or more lower-
level entity sets to produce a
higher-level entity sets.
Specialization is reverse of
Generalization. Specialization is a
process of taking a subset of a
higher level entity set to form a
lower-level entity set.
There is no inheritance in
Generalization.
There is inheritance in
Specialization.
110. Aggregation
An ER diagram is not capable of representing
relationship between an entity and a relationship
which may be required in some scenarios. In those
cases, a relationship with its corresponding entities is
aggregated into a higher level entity.
Aggregation is an abstraction through which we can
represent relationships as higher level entity sets.
111. Aggregation
For Example, Employee working for a project may
require some machinery. So, REQUIRE relationship
is needed between relationship WORKS_FOR and
entity MACHINERY
Using aggregation, WORKS_FOR relationship with
its entities EMPLOYEE and PROJECT is aggregated
into single entity and relationship REQUIRE is
created between aggregated entity and
MACHINERY.
113. category of union type
A Category or Union represents a single super-class or sub-
class relationship with multiple super-classes. Participation can
be total or partial. In simpler terms, it represents an “either”
type of relationship.
For example, The Car Owner in the Car booking model can be
a Person, a bank, or a company.
The Owner (category- subclass) is the union of the three
superclasses Company, Bank, and Person. A member of a
Category must exist in at least one of its superclasses.
116. High Level Conceptual Data
Modelling for Database Design
The first step shown is requirements collection and
analysis.
During this step, the database designers interview
prospective database users to understand and document
their data requirements. The result of this step is a
concisely written set of users’ requirements.
These requirements should be specified in as detailed and
complete a form as possible It is useful to specify the
known functional requirements of the application
117. High Level Conceptual Data
Modelling for Database Design
These consist of the user-
defined operations (or transactions) that will be applied to
the database, including both retrievals and updates.
In software design, it is common to use data flow
diagrams, sequence diagrams, scenarios, and other
techniques to specify functional requirements.
118. High Level Conceptual Data
Modelling for Database Design
Once the requirements have been collected and
analysed, the next step is to create a conceptual
schema for the database, using a high-level
conceptual data model. This step is called conceptual
design.
The conceptual schema is a concise description of
the data requirements of the users and includes
detailed descriptions of the entity types, relationships,
and constraints;
these are expressed using the concepts provided by
the high-level data model.
119. High Level Conceptual Data
Modelling for Database Design
The high-level conceptual schema can also be used as a
reference to ensure that all users’ data requirements are met
and that the requirements do not conflict.
This approach enables database designers to concentrate on
specifying the properties of the data, without being
concerned with storage and implementation details.
120. High Level Conceptual Data
Modelling for Database Design
During or after the conceptual schema design, the basic data
model operations can be used to specify the high-level user
queries and operations identified during functional analysis.
This also serves to confirm that the conceptual schema
meets all the identified functional requirements.
Modifications to the conceptual schema can be introduced if
some functional requirements cannot be specified using the
initial schema.
121. High Level Conceptual Data
Modelling for Database Design
The next step in database design is the actual
implementation of the database, using a commercial DBMS.
Most current commercial DBMSs use an implementation
data model—such as the relational or the object-relational
database model—so the conceptual schema is transformed
from the high-level data model into the implementation data
model.
This step is called logical design or data model mapping; its
result is a database schema in the implementation data
model of the DBMS.
122. High Level Conceptual Data
Modelling for Database Design
The last step is the physical design phase, during which the
internal storage structures, file organizations, indexes,
access paths, and physical design parameters for the
database files are specified.
In parallel with these activities, application programs are
designed and implemented as database transactions
corresponding to the high-level transaction specifications.
