Er Diagram

Entity-Relationship Model
Introduction to ER Model
ER model represents real world situations using concepts, which are commonly used by people.
It allows defining a representation of the real world at logical level.ER model has no facilities to
describe machine-related aspects. In ER model the logical structure of data is captured by
indicating the grouping of data into entities. Diagrammatic representation of ER model is called
ER Diagram.
Using High-Level Conceptual Data Model for Database Design
1
Kavitha J, Dept of CSE,RYMEC
 Requirements Collection and Analysis:
o purpose is to produce a description of the users' requirements. During this
step the database designers interview prospective database users to
understand and document their data requirements. The result of this step is
written set of user’s requirements.
o In parallel with specifying the data requirements, it is useful to specify
the known functional requirements of the application. These consists of
user defined operations that is applied to the database, including both
retrievals and updates.
o Data flow diagrams, sequence diagrams and other techniques can be used
to specify functional requirements.
 Conceptual Design:
o purpose is to produce a conceptual schema for the database, including
detailed descriptions of entity types, relationship types, and constraints.
All these are expressed using a high level conceptual data model.
o These concepts do not include implementation details. They are easier to
understand and can be used to communicate with non technical users
o The high level conceptual schema can also be used as a reference to
ensure that all user’s data requirements are met and the requirements do
not conflict.
o This approach enables the database designers to concentrate on specifying
the properties of the data without concerned with storage details.
o During or after the conceptual schema design, the basic data model
operations can be used to specify the high level user operations identified
during functional analysis.
 Logical design :
o purpose is to transform the conceptual schema (which is at a high/abstract
level) into a (lower-level) representational/implementation model
supported by whatever DBMS is to be used.
o Most commercial DBMS use an implementation data model such as
relational or object relational database model.
 Physical Design: purpose is to decide upon the internal storage structures, access paths
(indexes), etc., that will be used in realizing the representational model produced in
previous phase.
` In parallel with these activities, application programs are designed and implemented as
database transactions corresponding to the high level transaction specification.
2
Entity Types, Entity sets, Attributes, keys
 Entity
o An entity is an object in the real world that is distinguishable from other objects.
o It is a thing in the real world with an independent existence.
o An entity may be
 An object with physical existence(ex, person, car, house, employee)
 Or it may be an object with conceptual existence(ex: a company, a job. Or
a university course).
Types of Entity Sets-

An entity set may be of the following two types-
1. Strong entity set

2. Weak entity set
1. Strong Entity Set-
A strong entity set is an entity set that contains sufficient attributes to uniquely identify all its
entities.
 In other words, a primary key exists for a strong entity set.
 Primary key of a strong entity set is represented by underlining it.
Symbols Used-
 A single rectangle is used for representing a strong entity set.
 A diamond symbol is used for representing the relationship that exists between two strong
entity sets.
 A single line is used for representing the connection of the strong entity set with the
relationship set.
 A double line is used for representing the total participation of an entity set with the
relationship set.
 Total participation may or may not exist in the relationship.
3
1. Strong Entity Set-
A strong entity set is an entity set that contains sufficient attributes to uniquely identify all its
entities.
 In other words, a primary key exists for a strong entity set.
 Primary key of a strong entity set is represented by underlining it.
Symbols Used-
A single rectangle is used for representing a strong entity set.
 A diamond symbol is used for representing the relationship that exists between two strong
entity sets.
 A single line is used for representing the connection of the strong entity set with the
relationship set.
 A double line is used for representing the total participation of an entity set with the
relationship set.
 Total participation may or may not exist in the relationship.
Example-
Consider the following ER diagram-
In this ER diagram,
Two strong entity sets “Student” and “Course” are related to each other.
 Student ID and Student name are the attributes of entity set “Student”.
 Student ID is the primary key using which any student can be identified uniquely.
 Course ID and Course name are the attributes of entity set “Course”.
 Course ID is the primary key using which any course can be identified uniquely.
 Double line between Student and relationship set signifies total participation.
 It suggests that each student must be enrolled in at least one course.
 Single line between Course and relationship set signifies partial participation.
 It suggests that there might exist some courses for which no enrollments are made.
4
2. Weak Entity Set-
A weak entity set is an entity set that does not contain sufficient attributes to uniquely identify
its entities.
 In other words, a primary key does not exist for a weak entity set.
 However, it contains a partial key called as a discriminator.
 Discriminator can identify a group of entities from the entity set.
 Discriminator is represented by underlining with a dashed line.
Symbols Used-
 A double rectangle is used for representing a weak entity set.
 A double diamond symbol is used for representing the relationship that exists between the
strong and weak entity sets and this relationship is known as identifying relationship.
 A double line is used for representing the connection of the weak entity set with the
relationship set.
 Total participation always exists in the identifying relationship.
Example-
Consider the following ER diagram-
5
Differences between Strong entity set and Weak entity set-
Strong entity set Weak entity set
A single rectangle is used for the representation A double rectangle is used for the representation
of a strong entity set. of a weak entity set.
It contains sufficient attributes to form its It does not contain sufficient attributes to form
primary key. its primary key.
A diamond symbol is used for the representation A double diamond symbol is used for the
of the relationship that exists between the two representation of the identifying relationship that
strong entity sets. exists between the strong and weak entity set.
Attribute
Attribute: An entity is described by its attributes, which are properties that describe entities.
Each attribute has a value drawn from some domain (set of meaningful values). Example: A
PERSON entity might be described by Name, Birth Date, Sex, etc., attributes, each having a
particular value.
Different types of attributes

It is sometimes said that an entity has an independent existence, whereas an attribute does
not. In performing data modeling, however, it is not always clear whether a particular
concept deserves to be classified as an entity or "only" as an attribute. We can classify
attributes along these dimensions:
 simple/atomic vs. composite
 single-valued vs. multi-valued (or set-valued)
 stored vs. derived
 composite
 NULL
6
1. Simple/atomic vs. composite attributes
 Simple/Atomic Attributes :
The attributes which cannot be divided into smaller subparts are called simple or atomic
attributes. For example, age of employee entity
 A composite attribute is one that is composed of smaller parts. An atomic attribute is

indivisible or indecomposable.
Example 1: A Birth Date attribute can be viewed as being composed of (sub-) attributes
for month, day, and year.
Example 2: An Address attribute (Figure 3.4) can be viewed as being composed of (sub-)
attributes for street address, city, state, and zip code. A street address can itself be viewed
as being composed of a number, street name, and apartment number. As this suggests,
composition can extend to a depth of two (as here) or more.
To describe the structure of a composite attribute, one can draw a tree (Figure 3.4).. For the
examples mentioned above, we would write BirthDate(Month, Day, Year)
Address(StreetAddr(StrNum, StrName, AptNum), City, State, Zip)
2. Single- vs. multi-valued attribute:
Single valued Attributes : An attribute, that has a single value for a particular
entity. For example, SSN,DOB,age of an employee entity.
Multi valued Attributes : An attributes that may have multiple values for the
same entity. For example colors of a car entity, zero or more academic degree .
3. Stored vs. derived attribute:

Stored Attribute : An attribute, which cannot be derived from other attribute,
is known as stored attribute. For example, BirthDate of employee.
Derived Attribute : Attributes derived from other stored attribute. For

example age from Date of Birth and Today’s date.
4. Complex Attributes : If an attribute of an entity, is built using composite and

multivalued attributes, then these attributes are called complex attributes. For
example, a person can have more than one residence and each residence can have
7
multiple phones, an addressphone for a person entity can be specified as –
{Addressphone (phone {(Area Code, Phone Number)}, Address(Sector Address
(Sector Number,House Number), City, State, Pin))}
Here {} are used to enclose multivalued attributes and () are used to enclose composite
attributes with comma separating individual attributes.
The Null value: In some cases a particular entity might not have an applicable value for a
particular attribute. Or that value may be unknown. Or, in the case of a multi-valued attribute, the
appropriate value might be the empty set. Example: The attribute DateOfDeath is not applicable
to a living person and its correct value may be unknown for some persons who have died. In
such cases, we use a special attribute value (non-value?), called null. There has been some
argument in the database literature about whether a different approach (such as having distinct
values for not applicable and unknown) would be superior.
Attributes in ER Diagram-
 Attributes are the descriptive properties which are owned by each entity of an Entity Set.
 There exist a specific domain or set of values for each attribute from where the attribute can
take its values.
types of Attributes-
In ER diagram, attributes associated with an entity set may be of the following types-
8
1. Simple attributes
2. Composite attributes
3. Single valued attributes
4. Multi valued attributes
5. Derived attributes
6. Key attributes
1. Simple Attributes-
Simple attributes are those attributes which can not be divided further.
Example-
Here, all the attributes are simple attributes as they can not be divided further.
2. Composite Attributes-
Composite attributes are those attributes which are composed of many other simple attributes.
Example-
9
Here, the attributes “Name” and “Address” are composite attributes as they are composed of
many other simple attributes.
3. Single Valued Attributes-
Single valued attributes are those attributes which can take only one value for a given entity
from an entity set.
Example-
Here, all the attributes are single valued attributes as they can take only one specific value for
each entity.
4. Multi Valued Attributes-
Multi valued attributes are those attributes which can take more than one value for a given entity
from an entity set.
Example-
Here, the attributes “Mob_no” and “Email_id” are multi valued attributes as they can take more
than one values for a given entity.
5. Derived Attributes-
Derived attributes are those attributes which can be derived from other attribute(s).
Example-
10
Here, the attribute “Age” is a derived attribute as it can be derived from the attribute “DOB”.
6. Key Attributes-
Key attributes are those attributes which can identify an entity uniquely in an entity set.
Example-
Here, the attribute “Roll_no” is a key attribute as it can identify any student uniquely.
11
Relationship
Relationship Set-
A relationship set is a set of relationships of same type.
Example-
Set representation of above ER diagram is-
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
Types of Relationship Sets-

On the basis of degree of a relationship set, a relationship set can be classified into the following
types-
12
1. Unary relationship set
2. Binary relationship set
3. Ternary relationship set
4. N-ary relationship set
1. Unary Relationship Set-
Unary relationship set is a relationship set where only one entity set participates in a relationship
set.
2. Binary Relationship Set-
Binary relationship set is a relationship set where two entity sets participate in a relationship set.
3. Ternary Relationship Set-

Ternary relationship set is a relationship set where three entity sets participate in a relationship
set.
4. N-ary Relationship Set-

N-ary relationship set is a relationship set where ‘n’ entity sets participate in a relationship set.
Constraints on relationship type
There are two types of relationship constraints:
1. Cardinality ratio
2. Participation constraints
13
Cardinality ratio for binary relationship
The mapping cardinalities or the cardinality ratio represents the number of
relationship instances that an entity can participate in, i.e. the number of entities to
which another entity can be associated via a relationship set. In other words,
number of entities in one entity set which can be associated with the number of
entities of other set via relationship set. Mapping cardinalities are most useful in
describing binary relationship sets.
For a binary relationship set R between entity sets A and B, the mapping cardinality
must be one of the following –
 One to One (1:1)

An entity in A is associated with at most one entity in B, and an entity in B is
associated with at most one entity in A.
For example: If Employee and Department are 2 entity sets, then we can
define a one to one relationship ‘Manages’ between an Employee entity and a
Department entity i.e. one employee manages at most one department and one
department is managed by at most one employee.
The 1:1 relationship ‘Manages’ that shows total participation of Department
entity set and partial participation of Employee entity set.
 One to Many (1: M)

An entity in A is associated with many entities of B, and an entity in B can be
associated with atmost one entity in A.
For example: A 1:M relationship ‘CAN-HAVE’can be defined between entity
sets, Department and Employee i.e. one department can have any number of
14
employees, but an employee works in only one department.A 1:M relationship
between Department and Employee entity sets.
DEPT CAN_HAVE EMP
 Many to One (M: 1)

An entity in A is associated with atmost one entity in B. and an entity in B can
be associated with any number of entities in A.
For example: A M:1 relationship studying-in between two entity sets, student
entity set and a class entity set i.e. A student can belongs to atmost
one class but one class can have many students.
A M:1 relationship between Student and Class entity sets.
 Many to Many (M: M)

An entity in A is associated with any number of entities in B and an entity in
B is associated with any number of entities in A.
For example: Consider 2 entity sets Employee and Project. We can define a
many to many relationship as ‘Works-In’, which states that an employee can
work in many projects and a project can have many employees working in it.
15
Participation constraints and Existence Dependencies
The participation constraint specifies whether the existence of an entity depends on its being
related to another entity via the relationship type. This constraint specifies the minimum number
of relationship instances that each entity can participate in, and is sometimes called the minimum
cardinality constraint.
There are two types of participation constraints-
Total Participation or Existence Dependency-

 It specifies that each entity in the entity set must compulsorily participate in at least one
relationship instance in that relationship set.
 That is why, it is also called as mandatory participation.
 Total participation is represented using a double line between the entity set and relationship
set.
 Total participation is also called existence dependency
The participation of EMPLOYEE in WORKS_FOR is called total participation, meaning that

every entity in the total set of employee entities must be related to a department entity via
WORKS_FOR.
Partial Participation
 It specifies that each entity in the entity set may or may not participate in the relationship
instance in that relationship set.
 That is why, it is also called as optional participation.
 Partial participation is represented using a single line between the entity set and relationship
set.
16
For example
we do not expect every employee to 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.
structural constraints
Cardinality ratio and participation constraints, together is called as structural constraints of a
relationship type.
Role names
 Role names are not technically necessary in relationship types where all the partici-
pating 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.
Recursive Relationship Type

An relationship type whose with the same participating entity type in distinct roles
Example: In the SUPERVISION relationship EMPLOYEE participates twice in two
distinct roles:
supervisor (or boss) role
supervisee (or subordinate) role
Each relationship instance relates two distinct EMPLOYEE entities:
One employee in supervisor role
One employee in supervisee role
Displaying a recursive relationship
17
In a recursive relationship type. Both participations are same entity type in different roles.F or
example, SUPERVISION relationships between EMPLOYEE (in role of supervisor or boss) and
(another) EMPLOYEE (in role of subordinate or worker).In following figure, first role
participation labeled with 1 and second role participation labeled with 2.In ER diagram, need to
display role names to distinguish participations.
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.
Notice that attributes of 1:1 or 1:N relationship types can be migrated to one of the participating
entity types. For example, the Start_date attribute for the MANAGES relationship can be an
attribute of eitherEMPLOYEE or DEPARTMENT, although conceptually it belongs
to MANAGES. This is becauseMANAGES is a 1:1 relation-ship, so every department or
employee entity participates in at most one relationship instance. Hence, the value of
the Start_date attribute can be determined separately, either by the participating department
entity or by the participating employee (manager) entity.
For a 1:N relationship type, a relationship attribute can be migrated only to the entity type on the
N-side of the relationship. For example, in Figure 7.9, if the WORKS_FOR relationship also has
an attributeStart_date that indicates when an employee started working for a department, this
attribute can be included as an attribute of EMPLOYEE. This is because each employee works
18
for only one department, and hence participates in at most one relationship instance
in WORKS_FOR. In both 1:1 and 1:N relationship types, the decision where to place a
relationship attribute—as a relationship type attribute or as an attribute of a participating entity
type—is determined subjectively by the schema designer.
For M:N relationship types, some attributes may be determined by the combination of
participating entitiesin a relationship instance, not by any single entity. Such attributes must be
specified as relationship attributes. An example is the Hours attribute of the M:N
relationship WORKS_ON (Figure 7.13); the number of hours per week an employee currently
works on a project is determined by an employee-project combination and not separately by
either entity.
ER diagram
Different notations used in 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.
Components of ER diagram-
An ER diagram is mainly composed of following three components-
1. Entity Sets
2. Attributes
3. Relationship Set
Example-
Consider the following Student table-
Roll_no Name Age
1 Akshay 20
2 Rahul 19
3 Pooja 20
19
4 Aarti 19
This complete table is referred to as “Student Entity Set” and each row represents an “entity”.
Representation as ER Diagram-
The above table may be represented as ER diagram as-
Here,
 Roll_no is a primary key that can identify each entity uniquely.
 Thus, by using student’s roll number, a student can be identified uniquely.
ER Diagram Symbols-
An ER diagram is composed of several components and each component in ER diagram is
represented using a specific symbol.
ER diagram symbols are discussed below-
1. For Entity Sets-
An entity set is a set of same type of entities.
 An entity refers to any object having- Either a physical existence such as a particular person,
office, house or car.
 Or a conceptual existence such as a school or a company.
An entity set may be of the following two types-
1. Strong entity set
20
2. Weak entity set
Strong Entity Set-
 A strong entity set possess its own primary key.
 It is represented using a single rectangle.
2. Weak Entity Set-
 A weak entity set do not possess its own primary key.
 It is represented using a double rectangle.
2. For Relationship Sets-

 Relationship defines an association among several entities.
 A relationship set is a set of same type of relationships.
A relationship set may be of the following two t
1. Strong relationship set

2. Weak relationship set
1. Strong Relationship Set-
 A strong relationship exists between two strong entity sets.
 It is represented using a diamond symbol.
2. Weak Relationship Set-
 A weak or identifying relationship exists between the strong and weak entity set.
 It is represented using a double diamond symbol.
21
3. For Attributes-
 Attributes are the properties which describes the entities of an entity set.
 There are several types of attributes.
4. For Participation Constraints-

Participation constraint defines the least number of relationship instances in which an entity has
to necessarily participate.
There are two types of participation constraints-
22
1. Partial participation
2. Total participation
1. Partial Participation-
Partial participation is represented using a single line between the entity set and relationship set.
2. Total Participation-
Total participation is represented using a double line between the entity set and relationship set.
5. For Specialization and Generalization-
 Generalization is a process of forming a generalized super class by extracting the common

characteristics from two or more classes.
 Specialization is a reverse process of generalization where a super class is divided into sub
classes by assigning the specific characteristics of sub classes to them.
23
6. For Cardinality Constraints / Ratios-

Cardinality constraint defines the maximum number of relationship instances in which an entity
can participate.
There are 4 types of cardinality ratios-
1. Many-to-many cardinality (m:n)

2. Many-to-one cardinality (m:1)
3. One-to-many cardinality (1:n)
4. One-to-one cardinality (1:1)
24
25
Proper Naming of Schema Constructs

Naming conventions used for ER diagrams
 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.
 One should 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.
 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 bot-tom.
the DEPENDENTS_OF relationship type, which reads from bottom to top. When
we describe this relationship, we can say that the DEPENDENT entities (bottom entity
type) are DEPENDENTS_OF(relationship name) an EMPLOYEE (top entity type). To
change this to read from top to bottom, we could rename the relationship type
to HAS_DEPENDENTS, which would then read as follows: An EMPLOYEE entity
(top entity type) HAS_DEPENDENTS (relationship name) of
type DEPENDENT (bottom entity type).
Design Choices for ER Conceptual Design
26
 Model concept first as an attribute: 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.
 Attribute that exists in several entity types may be elevated to an independent entity
type.
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 choose to create an entity type department
with single attribute dept_name and relate it to three entities.
 An inverse refinement to the previous case may be applied.
Example: Entity DEPARTMENT exists in the initial design with the attributer
dept_name and is related to other entity STUDENT. In this case DEPARTMENT
may be reduced to an attribute of STUDENT.
Alternative Notations for ER Diagrams

Specified on each participation of an entity type E in a relationship type R Specifies that each entity e in
E participates in at least min and at most max relationship instances in R.
Default(no constraint): min=0, max=n (signifying no limit)Must have min_max, min_0, max _1
Derived from the knowledge of mini-world constraints
Examples:
 A department has exactly one manager and an employee can manage at most one
department.
Specify (0,1) for participation of EMPLOYEE in MANAGES
Specify (1,1) for participation of DEPARTMENT in MANAGES
 An employee can work for exactly one department but a department can have any
number of employees.
Specify (1,1) for participation of EMPLOYEE in WORKS_FOR
Specify (0,n) for participation of DEPARTMENT in WORKS_FOR
27
n- ary relationships(n>2)
In general, 3 binary relationships can represent different information than a single ternary
relationship (see Figure 3.17a and b ).If needed, the binary and n-ary relationships can all be
included in the schema design(see Figure 3.17a and b, where all relationships convey different
meanings). In some cases, a ternary relationship can be represented as a weak entity if the data
model allows a weak entity type to have multiple identifying relationships (and hence multiple
owner entity types) (see Fig 3.17c)
28
If a particular binary relationship can be derived from a higher-degree relationship at all times,
then it is redundant. For example, the TAUGHT_DURING binary relationship in Figure 3.18 can
be derived from the ternary relationship OFFERS (based on the meaning of the relationships).
29
SPECIALIZATION AND GENERALIZATION
Specialization is the process of defining a set of subclasses of an entity type,: this

entity type is called the superclass of the specialization.
Example: EMPLOYEE may be further grouped into:
 SECRETARY, ENGINEER, TECHNICIAN, …

 Based on the EMPLOYEE’s Job
 MANAGER
 EMPLOYEEs who are managers
 SALARIED_EMPLOYEE, HOURLY_EMPLOYEE
 Based on the EMPLOYEE’s method of pay
EER diagrams extend ER diagrams to represent these additional subgroupings, called

subclasses or subtypes
Each of these subgroupings is a subset of EMPLOYEE entities Each is called a

subclass of EMPLOYEE EMPLOYEE is the superclass for each of these subclasses
These are called superclass/subclass relationships:
30
 EMPLOYEE/SECRETARY
 EMPLOYEE/TECHNICIAN
 EMPLOYEE/MANAGER
 …
Generalization is the reverse of the specialization process . Generalization is a process in which

the common attributes of more than one entities form a new entity. This newly formed entity is
called generalized entity.
The ER diagram before generalization looks like this:
These two entities have two common attributes: Name and Address, we can make a generalized
entity with these common attributes. Lets have a look at the ER model after generalization.
The ER diagram after generalization:We have created a new generalized entity Person and
this entity has the common attributes of both the entities. As you can see in the following ER
diagram that after the generalization process the entities Student and Teacher only has the
specialized attributes Grade and Salary respectively and their common attributes (Name &
Address) are now associated with a new entity Person which is in the relationship with both the
31
entities (Student & Teacher).
Note:
1. Generalization uses bottom-up approach where two or more lower level entities combine
together to form a higher level new entity.
2. The new generalized entity can further combine together with lower level entity to create a
further higher level generalized entity.
Example: CAR, TRUCK generalized into VEHICLE;
 both CAR, TRUCK become subclasses of the superclass VEHICLE.

 We can view {CAR, TRUCK} as a specialization of VEHICLE
 Alternatively, we can view VEHICLE as a generalization of CAR and
TRUCK
32
Example Database Application: COMPANY
Suppose that Requirements Collection and Analysis results in the following (informal)
description of the COMPANY mini world: The Company is organized as a collection of
departments.
Each department
 has a unique name
 has a unique number
 is associated with a set of locations
 has a particular employee who acts as its manager (and who assumed that position on
some date)
 has a set of employees assigned to it
 controls a set of projects
Each project
 has a unique name
 has a unique number
 has a single location
 has a set of employees who work on it
33
 is controlled by a single department
Each employee
 has a name
 has a SSN that uniquely identifies her/him
 has an address
 has a salary
 has a sex
 has a birth date
 has a direct supervisor
 has a set of dependents
 is assigned to one department
 works some number of hours per week on each of a set of projects (which need not all be
controlled by the same department)
Each dependent
 has first name
 has a sex
 has a birth date
 is related to a particular employee in a particular way (e.g., child, spouse, pet)
 is uniquely identified by the combination of her/his first name and the employee of
which (s)he is a dependent
Initial Conceptual Design of COMPANY database

 Using the above structured description as a guide, we get the following preliminary
design for entity types and their attributes in the COMPANY database:
 DEPARTMENT(Name, Number, { Locations }, Manager, ManagerStartDate, {
Employees }, { Projects })
 PROJECT(Name, Number, Location, { Workers }, ControllingDept)
 EMPLOYEE(Name(FName, MInit, LName), SSN, Sex, Address, Salary, BirthDate,
Dept, Supervisor, { Dependents }, { WorksOn(Project, Hours) })
 DEPENDENT(Employee, FirstName, Sex, BirthDate, Relationship)
Initial Design of Entity Types for the COMPANY Database Schema

Based on the requirements, we can identify four initial entity types in the COMPANY database:
1. DEPARTMENT
2. PROJECT
3. EMPLOYEE
4. DEPENDENT
Their initial design is shown below. The initial attributes shown are derived from the
requirements description
34
Refining the initial design by introducing relationships

From our preliminary COMPANY schema, we identify the following relationship types (using
descriptive names and ordering the participating entity types so that the resulting phrase will be
in active voice rather than passive):
 EMPLOYEE MANAGES DEPARTMENT (arising from Manager attribute in
DEPARTMENT)
 DEPARTMENT CONTROLS PROJECT (arising from ControllingDept 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)
In ER diagrams, relationship types are drawn as diamond-shaped boxes connected by lines to

the entity types involved.
35
ER DIAGRAM
36
EMP
DEPEN
DENTS
-DF BOTTOM TO TOP
DEPENDENT
EMP
TOP TO BOTTOM
HAS
DEPENDENTS
37
ER diagram for UNIVERSITY database
38
ER diagram for HOSPITAL Management System
39
ER diagram for BANK Database
40
ER diagram for AIRLINE Database
41
ER diagram for MOVIE Database
42

Er Diagram

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Er Diagram

Transféré par

Droits d'auteur :

Formats disponibles

Entity-Relationship Model

Using High-Level Conceptual Data Model for Database Design

Types of Entity Sets-

1. Strong entity set

Strong entity set Weak entity set

Different types of attributes

 A composite attribute is one that is composed of smaller parts. An atomic attribute is

2. Single- vs. multi-valued attribute:

3. Stored vs. derived attribute:

Derived Attribute : Attributes derived from other stored attribute. For

4. Complex Attributes : If an attribute of an entity, is built using composite and

Degree of a Relationship Set-

Degree of a relationship set = Number of entity sets participating in a relationship set

Types of Relationship Sets-

3. Ternary Relationship Set-

4. N-ary Relationship Set-

 One to One (1:1)

 One to Many (1: M)

 Many to One (M: 1)

 Many to Many (M: M)

Total Participation or Existence Dependency-

The participation of EMPLOYEE in WORKS_FOR is called total participation, meaning that

we do not expect every employee to manage a department, so the participation of EMPLOYEE

Recursive Relationship Type

Attributes of Relationship Types

Roll_no Name Age

1. Strong entity set

2. For Relationship Sets-

1. Strong relationship set

4. For Participation Constraints-

5. For Specialization and Generalization-

 Generalization is a process of forming a generalized super class by extracting the common

6. For Cardinality Constraints / Ratios-

1. Many-to-many cardinality (m:n)

Proper Naming of Schema Constructs

Design Choices for ER Conceptual Design

Alternative Notations for ER Diagrams

Specialization is the process of defining a set of subclasses of an entity type,: this

Example: EMPLOYEE may be further grouped into:

 SECRETARY, ENGINEER, TECHNICIAN, …

EER diagrams extend ER diagrams to represent these additional subgroupings, called

Each of these subgroupings is a subset of EMPLOYEE entities Each is called a

Generalization is the reverse of the specialization process . Generalization is a process in which

The ER diagram before generalization looks like this:

Example: CAR, TRUCK generalized into VEHICLE;

 both CAR, TRUCK become subclasses of the superclass VEHICLE.

Example Database Application: COMPANY

Initial Conceptual Design of COMPANY database

Initial Design of Entity Types for the COMPANY Database Schema

Refining the initial design by introducing relationships

In ER diagrams, relationship types are drawn as diamond-shaped boxes connected by lines to

ER diagram for UNIVERSITY database

ER diagram for HOSPITAL Management System

ER diagram for BANK Database

Vous aimerez peut-être aussi