ER modeling

ADBMS
By: Dabbal S. Mahara
2018

Data Modeling using ER Model
• Conceptual modeling is very important phase in designing a successful database
application.
• The term database application refers to a particular database and the associated
programs that implement the database queries and updates.
• For example, a BANK database application that keeps track of customer
accounts would include programs that implement database updates
corresponding to customer deposits and withdrawals.
2

Data Modeling using ER Model
• Hence, part of database application would require the design, implementation, and testing of
these application programs.
• Traditionally, the design and testing of application programs has been considered to be part of
software engineering rather than database design.
• In many software design tools, the database design methodologies and software engineering
methodologies are intertwined since these activities are strongly related.
• The database design methodologies include more concepts for specifying operations on database
objects and software engineering methodologies specify the structure of the databases that
software programs will use and access in more detail.
3

Using High Level Conceptual Data Models for Database
Design
• Figure in the next slide shows a simplified overview of the database design process.
• 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.
• In parallel with specifying the data requirements, it is useful to specify the known functional
requirements of the application. These consist of the user defined operations (or transactions)
that will be applied to the database, including both retrievals and updates.
4

• In software design, it is common to use data flow diagrams, sequence diagrams, scenarios, and
other techniques to specify functional requirements.
• Once 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 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.
• Because these concepts do not include implementation details, they are usually easier to
understand and can be used to communicate with nontechnical users.
Design
6

• 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.
• 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.
Design
7

• 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.
Design
8

Entity-Relationship Model
• Introduction
• Basic Concepts
• Constraints
• Keys
• Entity-Relationship (ER) Diagram
9

Introduction
• The entity-relationship (E-R) model is a high-level data model based on the
perception of a real world that consists of a collection of basic objects, called
entities and relationships among these entities.
• An entity is a thing or object in the real world that is distinguishable from
other objects.
• A relationship is an association among several entities.
• Entities are described by a set of attributes.
• The set of all entities of the same type is called an entity set and the set of all
relationships of the same type is called a relationship set.
• In this model, we use E-R diagrams to express overall logical structure of
the database.
10

Basic Concepts
• The E-R model employs three basic notations: entity sets, relationship
sets, and attributes.
• Entity Sets:
 An entity is a thing or object in the real world that is distinguishable from all other
objects. For example, specific person, company, event, plant etc.
 An entity has a set of properties called attributes, and the values for some set of
properties may uniquely identify an entity. For example, people have names and
addresses as attributes.
 An entity set is a set of entities of the same type that share the same properties, or
attributes. For example, set of all persons, companies, trees, holidays etc.
 The individual entities that constitute a set are said to be the extension of the entity
set. Entity sets do not need to be disjoint.
11

Basic Concepts
Fig: Entity sets customer and loan
12

Basic Concepts
• Attributes:
 An entity is represented by a set of attributes. For example, a customer entity
can have customer-id, customer-name, customer-street, and customer-city as
attributes.
 Attributes are the descriptive properties possessed by all members of an entity
set. Each entity may have its own value for each attribute.
 For each attribute, there is a set of permitted values, called the domain or value
set of that attribute.
 The E-R model uses the different types of attributes.
 Simple and Composite Attributes:
• Simple attributes cannot be divided into subparts. For example, gender.
• Composite attributes on the other hand can be divided into subparts; that is, other
attributes. A composite attribute may appear as hierarchy. For example, name,
address etc.
13

Basic Concepts
Fig: Composite attributes
14

Basic Concepts
 Single-valued and Multi-valued Attributes:
• An attribute having a single value for a particular entity is called
the single-valued attribute. For example, gender.
• An attribute having a set of values for a particular entity is called
the multi-valued attribute. For example, phone-numbers.
 Derived Attributes:
• The value of the derived attributes can be computed from other
attributes. For example, age, given date-of-birth.
15

Complex Attributes:
 The composite and multivalued attributes can nested arbitrarily.
 We can represent arbitrary nesting by grouping components of a
composite attribute between parentheses and separating the
components with commas, and by displaying multivalued attributes
between braces. Such attributes are called complex attributes.
• For example: {Address_phone({Phone(Area_code, Phone_number)},
Address(Street_address( Number, Street, Apartment_number),City, Zip))}
1-16

Entity-Relationship Diagram
Fig: E-R diagram with composite, multivalued, and derived
attributes 17

Null Values
 All attributes take a null value when an entity does not have a value for it. The null value
may indicate “not applicable”, that is, the value does not exist for the entity.
 For example: college_degree attribute applies to persons with college degrees.
 The apartment_number attribute of an address applies to addresses that are in apartment
buildings and not to other types of addresses.
 Null can also be used if we do not know the value of an attribute for a particular entity.
 either it is known that the attribute value exists but is missing, For example: height of a
person is listed as NULL.
 or, it is known whether the attribute value exists. For example: home phone number of a
person is NULL.
1-18

Keys
• Keys are used to distinguish the entities within a given entity set.
Furthermore, a key allows us to identify a set of attributes that suffice to
distinguish entities from each other. Keys also help to uniquely identify
relationships.
• Keys for Entity Sets:
 A superkey of an entity set is a set of one or more attributes whose values uniquely
determine each entity. Any superset of a superkey is also a superkey.
 A superkey may also contain extraneous attributes. A candidate key of an entity set is a
minimal superkey; that is, superkey for which no proper subset is a superkey. For
example, customer-id is candidate key of customer entity set.
 An entity set may have several candidate keys. We use the term primary key to denote a
candidate key that is chosen by the database designer for identifying entities within an
entity set.
19

Keys
 Alternate keys are the remaining candidate keys other than primary key.
 So, there is always one and only one primary key in an entity set. A primary key of an
entity set allows us to distinguish among various entities of the set.
• Keys for Relationship Sets:
 The combination of primary keys of the participating entity sets forms a superkey for
the relationship set. For example, (customer-id, account-number) is the super key of
depositor relationship set.
 Let R be a relationship set involving entities E1, E2,……, En. Let primary-key (Ei)
denotes the set of attributes that forms the primary key for entity set Ei. Assume that
the attribute names of all primary keys are unique, and each entity set participates only
once in the relationship. The superkey for the relationship set can be defined as
primary-key (E1)U primary-key (E2)U……U primary-key (En)
20

Relationships
• Relationship Sets:
 A relationship is an association among several entities.
 A relationship set is a set of relationships of the same type.
 Formally, it is a mathematical relation on n  2 entity sets. If E1, E2,…, En are entity
sets, then a relationship set R is a subset of {(e1, e2,…, en)|e1E1, e2E2,…, enEn},
where (e1, e2,….., en) is a relationship. For example, (Hayes, L-15)  borrower
relationship set.
 The association between entity sets is referred to as participation, that is, the entity
sets E1, E2,…., En participate in relationship set R.
 A relationship instance represents an association between the named entities.
21

Relationships
Fig: Relationship set borrower
22

Relationships
 A relationship set may also have attributes called
descriptive attributes. For example, the depositor
relationship set between entity sets customer and account
may have the attribute access-date. See figure on the next
slide.
 A relationship instance in a given relationship set must be
uniquely identifiable from other relationship instances,
without using descriptive attributes.
23

Relationships
Fig: Descriptive attribute 24

Relationships
 There can be more than one relationship set involving the same entity
set.
 Degree of a relationship set refers to the number of entity sets that
participate in a relationship set.
 Relationship sets that involve two entity sets are called binary
relationship sets. Most relationship sets in a database system are
binary.
 Relationship sets may involve more than two entity sets called n-ary
relationship sets but are rare. For example, suppose employees of a
bank may have jobs (responsibilities) at multiple branches, with
different jobs at different branches. Then there is a ternary relationship
set between entity sets employee, job and branch.
25

Relationships
 The function that an entity plays in a relationship is called that entity’s
role.
 In case of distinct entity sets participating in a relationship set, roles are
implicit and are not usually specified.
 When the entity sets of a relationship set are not distinct; that is, the same
entity set participates in a relationship set more than once, in different
roles, explicit role names are necessary to specify how an entity
participates in a relationship instance.
 This type of relationship set is sometimes called a recursive relationship
set.
 For example: employee entity may have role of supervisor or supervisee.
26

Constraints
• An entity relationship model may define certain constraints to
which the contents of a database must conform. The most
important constraints are: mapping cardinalities and
participation constraints.
• Mapping Cardinalities:
 These are also called cardinalities ratios and express the number of
entities to which another entity can be associated via a relationship set.
 These are most useful in describing binary relationship sets.
 For binary relationship set R between entity sets A and B, there are
four types of mapping cardinalities: one-to-one, one-to-many, many-to-
one, and many-to-many.
 One to One: 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, mapping
cardinality between departments and chairpersons.
27

Constraints
 One to Many: An entity in A is associated with any number (zero
or more) of entities in B. an entity in B, however, can be associated
with at most one entity in A. For example, mapping cardinality between
mothers and children.
 Many to One: An entity in A is associated with at most one entity
in B. an entity in B, however, can be associated with any number (zero
or more) of entities in A. For example, mapping cardinality
between children and mothers.
 Many to Many: An entity in A is associated with any number (zero
or more) of entities in B, and an entity in B is associated with any
number (zero or more) of entities in A. For example, mapping
cardinality between students and courses.
28

Constraints
• Participation Constraints:
 The participation of an entity set A in a relationship set R is said to be
total if every entity in A participates in at least one relationship in R.
For example, consider customer and account entity sets in a banking
system, and a relationship set depositor between them indicating that
each customer must have an account. Then there is total participation of
entity set customer in the relationship set depositor.
 If only some entities in A participate in relationships in R, the
participation of entity set A in relationship set R is said to be partial.
For example, consider customer and loan entity sets in a banking
system, and a relationship set borrower between them indicating that
some customers have loans. Then there is partial participation of entity
set customer in the relationship set borrower.
30

• An E-R diagram expresses the overall logical structure of a
database graphically. E-R diagram consists of the following
major components:
 Rectangles represent entity sets.
 Diamonds represent relationship sets.
 Lines link attributes to entity sets and entity sets to relationship sets.
 Ellipses represent attributes
 Double ellipses represent multi-valued attributes.
 Dashed ellipses denote derived attributes.
 Underline indicates primary key attributes
 Double Lines indicate total participation of an entity set in a
relationship set.
 Double Rectangles represent weak entity sets.
 Double Diamonds represent identifying relationship sets. 31

Fig: E-R diagram corresponding to customers and loans
• To distinguish the type of the relationships, we draw either a
directed line () or an undirected line () between the
relationship set and the entity set. Directed line indicates one
and undirected line indicates many.
• Hence, the figure above has many-to-many relationship.
34

• One-to-one relationship: Suppose a customer is associated
with at most one loan and a loan is associated with at most one
customer via the relationship set borrower.
35

• One-to-many relationship: Suppose a loan is associated with
at most one customer and a customer is associated with several
(including 0) loans via borrower relationship set.
36

• One-to-many relationship: Suppose a loan is associated with
several (including 0) customers and a customer is associated
with at most one loan via borrower relationship set.
37

• If a relationship set has also some attributes associated with it,
then we link these attributes to that relationship set.
38

• We indicate roles in an E-R diagram by labeling the lines that
connect diamonds to rectangles.
39

• Double lines are used to indicate that the participation of an
entity set in a relationship set is total; that is, each entity in the
entity set occurs in at least one relationship in that relationship
set.
40

• E-R diagram also provide a way to indicate more complex
constraints on the number of times each entity participates in
relationships in a relationship set. An edge between an entity
set and a binary relationship set can have an associated
minimum and maximum cardinality, shown in the form of
L….H, where L is the minimum and H is maximum
cardinality.
41

• Non-binary relationship sets can also be specified easily in an
E-R diagram.
42

• Weak entity set:
 An entity set may not have sufficient attributes to form a primary key.
Such an entity set is termed as a weak entity set. An entity set that has
a primary key is termed as a strong entity set.
 For a weak entity set to be meaningful, it must be associated with
another entity set, called the identifying or owner entity set, using one
of the key attribute of owner entity set. The weak entity set is said to be
existence dependent on the identifying entity set. The relationship
associating the weak entity set with the identifying entity set is called
the identifying relationship. The identifying relationship is many-to-
one form the weak entity set to the identifying entity set, and the
participation of the weak entity set in the relationship set is total.
 Although a weak entity set does not have a primary key, we use
discriminator (or partial key) as a set of attributes that allows the
distinction to be made among all the entities in the weak entity set.
43

 In the figure below, payment-number is partial key and (loan-number,
payment-number) is primary key for payment entity set.
44

Example: Company Database
• The COMPANY database keeps track of a company’s employees, departments,
and projects.
• Suppose that after the requirements collection and analysis phase, the database
designers provide the following description of the miniworld-the part of the
company that will be represented in the database.
 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.
45

Company Database
 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,2 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 current 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.
46

ER Diagram for Company database
47

Exercises
1. Construct an ER diagram for a car-insurance company whose
customers own one or more cars each. Each car has
associated with it zero to any number of recorded accidents.
2. Construct an ER diagram for a hospital with a set of patients
and a set of doctors. Associate with each patient a log of the
various tests and examinations conducted.
3. Construct an ER diagram of the library system in your
college.
4. Construct an ER diagram to maintain data about students,
instructors, semester, and courses in a college.
5. Construct an ERD to record the marks that students get in
different exams of different course offerings.
48

3
1-51
Librarian
password
Issue

Converting an E-R Diagram to a
Relational Schema
54

Converting an E-R diagram to a relational schema
1.Strong Entity to Relation Conversion
• For each regular (strong) entity type E in the ER schema, create a
relation R that includes all the simple attributes of E.
• Include only the simple component attributes of a composite attribute.
• Choose one of the key attributes of E as the primary key for R.
• If the chosen key of E is a composite, then the set of simple attributes
that form it will together form the primary key of R.
55

• In our example, we create the relations EMPLOYEE, DEPARTMENT,
and PROJECT to correspond to the regular entity types EMPLOYEE,
DEPARTMENT, and PROJECT .
• The foreign key and relationship attributes, if any, are not included yet;
they will be added during subsequent steps.
1.Strong Entity to Relation Conversion
56

2. Mapping of Weak Entity Types
• For each weak entity type W in the ER schema with owner entity type E,
create a relation R and include all simple attributes (or simple components
of composite attributes) of W as attributes of R.
• In addition, include as foreign key attributes of R, the primary key
attribute(s) of the relation(s) that correspond to the owner entity type(s);
this takes care of mapping the identifying relationship type of W.
• The primary key of R is the combination of the primary key(s) of the
owner(s) and the partial key of the weak entity type W, if any.
57

2. Mapping of Weak Entity Types
• In our example, we create the relation DEPENDENT in this step to correspond to the
weak entity type DEPENDENT .
• We include the primary key Ssn of the EMPLOYEE relation—which corresponds to
the owner entity type—as a foreign key attribute of DEPENDENT; we rename it
Essn, although this is not necessary.
• The primary key of the DEPENDENT relation is the combination {Essn,
Dependent_name}, because Dependent_name (also renamed from Name ) is the
partial key of DEPENDENT.
58

Step 3: Mapping of Binary 1:1 Relationship Types.
• For each binary 1:1 relationship type R in the ER schema, identify the
relations S and T that correspond to the entity types participating in R.
• Choose one of the relations—S, say—and include as a foreign key in
S the primary key of T.
• It is better to choose an entity type with total participation in R in the
role of S.
• Include all the simple attributes (or simple components of composite
attributes) of the 1:1 relationship type R as attributes of S.
59

• In our example, we map the 1:1 relationship type MANAGES from Figure by
choosing the participating entity type DEPARTMENT to serve in the role of S
because its participation in the MANAGES relationship type is total (every
department has a manager).
• We include the primary key of the EMPLOYEE relation as foreign key in the
DEPARTMENT relation and rename it Mgr_ssn.
• We also include the simple attribute Start_date of the MANAGES relationship type in
the DEPARTMENT relation and rename it Mgr_start_date.
Step 3: Mapping of Binary 1:1 Relationship Types
Department
60

• Note that it is possible to include the primary key of S as a foreign key in T
instead.
• In our example, this amounts to having a foreign key attribute, say
Department_managed in the EMPLOYEE relation, but it will have a NULL
value for employee tuples who do not manage a department.
• If only 2 percent of employees manage a department, then 98 percent of the
foreign keys would be NULL in this case.
• Another possibility is to have foreign keys in both relations S and T
redundantly, but this creates redundancy and incurs a penalty for consistency
maintenance.
61

Cross-reference or relationship relation approach:
• The alternative option is to set up a third relation R for the purpose of cross-
referencing the primary keys of the two relations S and T representing the entity
types.
• The relation R is called a relationship relation (or sometimes a lookup table),
because each tuple in R represents a relationship instance that relates one tuple
from S with one tuple from T.
• The relation R will include the primary key attributes of S and T as foreign keys
to S and T.
• The primary key of R will be one of the two foreign keys, and the other foreign
key will be a unique key of R.
• The drawback is having an extra relation, and requiring an extra join operation
when combining related tuples from the tables.
62

Step 4: Mapping of Binary 1:N Relationship Types
• For each regular binary 1:N relationship type R, identify the relation S that
represents the participating entity type at the N-side of the relationship
type.
• Include as foreign key in S the primary key of the relation T that represents
the other entity type participating in R; we do this because each entity
instance on the N-side is related to at most one entity instance on the 1-
side of the relationship type.
• Include any simple attributes (or simple components of composite
attributes) of the 1:N relationship type as attributes of S.
63

• In our example, we now map the 1:N relationship types
WORKS_FOR, CONTROLS, and SUPERVISION from figure.
• For WORKS_FOR we include the primary key Dnumber of the
DEPARTMENT relation as foreign key in the EMPLOYEE relation
and call it Dno.
64

• For SUPERVISION we include the primary key of the EMPLOYEE
relationas foreign key in the EMPLOYEE relation itself—because the
relationship is recursive— and call it Super_ssn.
• The CONTROLS relationship is mapped to the foreign key attribute
Dnum of PROJECT, which references the primary key Dnumber of the
DEPARTMENT relation.
65

• An alternative approach is to use the relationship relation
(cross-reference) option as in the third option for binary 1:1
relationships.
• We create a separate relation R whose attributes are the primary
keys of S and T, which will also be foreign keys to S and T.
• The primary key of R is the same as the primary key of S.
• This option can be used if few tuples in S participate in the
relationship to avoid excessive NULL values in the foreign key.
66

Step 5: Mapping of Binary M:N Relationship Types.
• For each binary M:N relationship type R, create a new relation S to
represent R.
• Include as foreign key attributes in S the primary keys of the relations
that represent the participating entity types; their combination will
form the primary key of S.
• Also include any simple attributes of the M:N relationship type (or
simple components of composite attributes) as attributes of S.
• Notice that we cannot represent an M:N relationship type by a single
foreign key attribute in one of the participating relations (as we did for
1:1 or 1:N relationship types) because of the M:N cardinality ratio; we
must create a separate relationship relation S.
67

• In our example, we map the M:N relationship type WORKS_ON by
creating the relation WORKS_ON shown below
• We include the primary keys of the PROJECT and EMPLOYEE
relations as foreign keys in WORKS_ON and rename them Pno and
Essn, respectively.
• We also include an attribute Hours in WORKS_ON to represent the
Hours attribute of the relationship type.
• The primary key of the WORKS_ON relation is the combination of the
foreign key attributes {Essn, Pno}.
Step 5: Mapping of Binary M:N Relationship Types.
68

Step 6: Mapping of Multivalued Attributes.
• For each multivalued attribute A, create a new relation R.
• This relation R will include an attribute corresponding to
A, plus the primary key attribute K—as a foreign key in
R—of the relation that represents the entity type or
relationship type that has A as a multivalued attribute.
• The primary key of R is the combination of A and K.
• If the multivalued attribute is composite, we include its
simple components.
69

• In our example, we create a relation DEPT_LOCATIONS.
• The attribute Dlocation represents the multivalued attribute LOCATIONS of
DEPARTMENT, while Dnumber—as foreign key—represents the primary
key of the DEPARTMENT relation.
• The primary key of DEPT_LOCATIONS is the combination of {Dnumber,
Dlocation}.
• A separate tuple will exist in DEPT_LOCATIONS for each location that a
department has.
Step 6: Mapping of Multivalued Attributes.
70

Step 7: Mapping of N-ary Relationship Types
• For each n-ary relationship type R, where n > 2, create a new relation S to
represent R.
• Include as foreign key attributes in S the primary keys of the relations that
represent the participating entity types.
• Also include any simple attributes of the n-ary relationship type (or simple
components of composite attributes) as attributes of S.
• The primary key of S is usually a combination of all the foreign keys that
reference the relations representing the participating entity types.
71

• However, if the cardinality constraints on any of the entity types E
participating in R is 1, then the primary key of S should not include the
foreign key attribute that references the relation E corresponding to E.
• For example, consider the relationship type SUPPLY in Figure below.
72

This can be mapped to the relation SUPPLY shown below, whose
primary key is the combination of the three foreign keys {Sname,
Part_no, Proj_name}.
73

ER modeling

Recommended

More Related Content

What's hot (20)

Similar to ER modeling (20)

More from Dabbal Singh Mahara (20)

Recently uploaded (20)

ER modeling