Lec 3 ER Model
Lec 3 ER Model
_____________________________________________________________________________________
Data model tells how the logical structure of a database is modeled. Data Models are
fundamental entities of the DBMS. Data models define how data is connected to each other and
how it will be processed and stored inside the system.
Among these data models relational model, Network model and Hierarchical models are
called as record based models.
Entity-Relationship Model
Entity-Relationship model is based on the notion of real world entities and relationship
among them.
ER Model is best used for the conceptual design of database.
ER Model is based on:
Entities and their attributes
Relationships among entities
[Image: ER Model]
Entity
An entity in ER Model is real world entity, which has some properties called
attributes. Every attribute is defined by its set of values, called domain.
For example, in a school database, a student is considered as an entity. Student
has various attributes like name, age and class etc.
Relationship
The logical association among entities is called relationship. Relationships are
mapped with entities in various ways. Mapping cardinalities define the number of
association between two entities.
Relational Model
The most popular data model in DBMS is Relational Model. It is more scientific
model then others.
Entity
A real-world thing either animate or inanimate that can be easily identifiable and distinguishable.
For example, in a school database, student, teachers, class and course offered can be
considered as entities.
All entities have some attributes or properties that give them their identity.
An entity set is a collection of similar types of entities. Entity set may contain entities with
attribute sharing similar values. For example, Students set may contain all the student of a
school; likewise Teachers set may contain all the teachers of school from all faculties. Entities
sets need not to be disjoint.
Attributes
Entities are represented by means of their properties, called attributes. All attributes have
values.
For example, a student entity may have name, class, age as attributes.
There exists a domain or range of values that can be assigned to attributes. For example, a
student's name cannot be a numeric value. It has to be alphabetic. A student's age cannot be
negative, etc.
Types of attributes:
Simple attribute:
Simple attributes are atomic values, which cannot be divided further. For example,
student's phone-number is an atomic value of 10 digits.
Composite attribute:
Composite attributes are made of more than one simple attribute. For example, a
student's complete name may have first_name and last_name.
Derived attribute:
Derived attributes are attributes, which do not exist physical in the database, but there
values are derived from other attributes presented in the database. For example,
average_salary in a department should be saved in database instead it can be derived.
For another example, age can be derived from data_of_birth.
Single-valued attribute:
Single valued attributes contain on single value. For example: Social_Security_Number.
Multi-value attribute:
Multi-value attribute may contain more than one values. For example, a person can have
more than one phone numbers, email_addresses etc.
Entity-set and Keys
Key is an attribute or collection of attributes that uniquely identifies an entity among
entity set.
For example, roll_number of a student makes her/him identifiable among students.
Super Key: Set of attributes (one or more) that collectively identifies an entity in an
entity set.
Candidate Key: Minimal super key is called candidate key that is, supers keys for which
no proper subset are a super key. An entity set may have more than one candidate key.
Primary Key: This is one of the candidate key chosen by the database designer to
uniquely identify the entity set.
Relationship
The association among entities is called relationship.
For example, employee entity has relation works_at with department. Another example is for
student who enrolls in some course. Here, Works_at and Enrolls are called relationship.
Relationship Set:
Relationship of similar type is called relationship set. Like entities, a relationship too can have
attributes. These attributes are called descriptive attributes.
Degree of relationship
The number of participating entities in a relationship defines the degree of the relationship.
Binary = degree 2
Ternary = degree 3
n-ary = degree
Mapping Cardinalities:
Cardinality defines the number of entities in one entity set which can be associated to the
number of entities of other set via relationship set.
There are different types of mappings. They are
1. One-to-one
2. One-t-Many
3. Many-to-One
4. Many-to-Many
One-to-One: one entity from entity set A can be associated with at most one entity of
entity set B and vice versa.
One-to-Many: One entity from entity set A can be associated with more than one
entities of entity set B but from entity set B one entity can be associated with at most one
entity.
Many-to-One: More than one entities from entity set A can be associated with at most
one entity of entity set B but one entity from entity set B can be associated with more
than one entity from entity set A.
Many-to-Many: one entity from A can be associated with more than one entity from B
and vice versa.
ER Diagram Representation
Every object like entity and attributes of an entity, relationship set and attributes of relationship
set can be represented by tools of ER diagram.
An E-R diagram can express the overall logical structure of a database graphically. E-R
diagrams are simple and clear. Such a diagram consists of the following components:
Entity
Entities are represented by means of rectangles. Rectangles are named with the entity set they
represent.
Attributes
Attributes are properties of entities. Attributes are represented by means of eclipses. Every
eclipse represents one attribute and is directly connected to its entity (rectangle ).
If the attributes are composite, they are further divided in a tree like structure. Every node is
then connected to its attribute. That is composite attributes are represented by eclipses that are
connected with an eclipse.
Example: The following ER diagram represents all the attributes of the entity customer
One-to-one
When only one instance of entity is associated with the relationship, it is marked as '1'.
This image below reflects that only 1 instance of each entity should be associated with
the relationship. It depicts one-to-one relationship
[Image: One-to-one]
One-to-many
When more than one instance of entity is associated with the relationship, it is marked as
'N'. This image below reflects that only 1 instance of entity on the left and more than one
instance of entity on the right can be associated with the relationship. It depicts one-to-
many relationship
[Image: One-to-many]
Many-to-one
When more than one instance of entity is associated with the relationship, it is marked
as 'N'. This image below reflects that more than one instance of entity on the left and
only one instance of entity on the right can be associated with the relationship. It depicts
many-to-one relationship
[Image: Many-to-one]
Many-to-many
This image below reflects that more than one instance of entity on the left and more than
one instance of entity on the right can be associated with the relationship. It depicts
many-to-many relationship
[Image: Many-to-many]
Example: Consider the entity-relationship shown below, which consists of two entity sets,
customer and loan, related through a binary relationship set borrower. The attributes associated
with customer are customer-id, customer-name, customer-street, and customer-city. The
attributes associated with loan are loan-number and amount. Here, attributes of an entity set
that are members of the primary key are underlined.
• A directed line from the relationship set borrower to the entity set loan specifies that borrower
is a one-to-one or many-to-one relationship set, from customer to loan; borrower cannot be a
many-to-many or a one-to-many relationship set from the customer loan.
• An undirected line from the relationship set borrower to the entity set loan specifies that
borrower is either a many-to-many or one-to-many relationship set from customer to loan.
If the relationship set borrower were one-to-many, from customer to loan, then the line from
borrower to customer would be directed, with an arrow pointing to the customer entity set as
represented in the following diagram.
Similarly, if the relationship set borrower were many-to-one from customer to loan, then
the line from borrower to loan would have an arrow pointing to the loan entity set as
represented in the following diagram.
Finally, if the relationship set borrower were one-to-one, then both lines from borrower would
have arrows: one pointing to the loan entity set and one pointing to the customer entity set as
represented in the following diagram.
There is a possibility that a relationship set has also some attributes associated with it,
then we link these attributes to that relationship set. For example we have the access date
descriptive attribute attached to the relationship set depositor to specify the most recent date on
which a customer accessed that account. It can be represented in the as shown in the following
diagram.
Participation Constraints
Total Participation: Each entity in the entity is involved in the relationship. Total
participation is represented by double lines. For example consider the relationship
borrower between customers and loans. A double line from loan to borrower, as shown in
the below diagram, indicates that each loan must have at least one associated customer.
Partial participation: Not all entities are involved in the relationship. Partial participation is
represented by single line.
1. Specialization
The process of designating subgroupings within an entity set is called specialization.
Consider an entity set person, with attributes name, street, and city. A person may be further
classified as customer or employee. Each of these person types is described by a set of
attributes that includes all the attributes of entity set person plus possibly additional
attributes. For example, customer entities may be described further by the attribute
customer-id, whereas employee entities may be described further by the attributes
employee-id and salary. The specialization of person allows us to distinguish among
persons according to whether they are employees or customers. Thus specialization is the
result of taking a subset of a higher-level entity set to form a lower level entity set.
2. Generalization
Generalization is the result of taking the union of two or morelower-level entity sets to
produce a higher-level entity set. The attributes of higher-level entity sets are inherited by
lower-level entity sets. In our example, person is the higher-level entity set and customer
and employee are lower-level entity sets. They can be represented as superclass and
subclass. The person entity set is the superclass of the customer and employee subclasses.
Also generalization is a simple inversion of specialization. We will apply both specialization
and generalization, in combination as shown below.
3. Attribute Inheritance
A crucial property of the higher- and lower-level entities created by specialization and
generalization is attribute inheritance. The attributes of the higher-level entity sets are said
to be inherited by the lower-level entity sets. For example, customer and employee inherit
the attributes of person. Thus, customer is described by its name, street, and city attributes,
and additionally a customer-id attribute; employee is described by its name, street, and city
attributes, and additionally employee-id and salary attributes. A lower-level entity set (or
subclass) also inherits participation in the relationship sets in which its higher-level entity (or
superclass) participates.
4. Aggregation
Aggregation is an abstraction through which relationships are treated as higher level
entities. Thus, for our example, we regard the relationship set works-on (relating the entity
sets employee, branch, and job) as a higher-level entity set called works-on. Such an entity
set is treated in the same manner as is any other entity set. We can then create a binary
relationship manages between works-on and manager to represent who manages what
tasks. The diagram below represents aggregation.