Entity Relationship (ER) Modeling

You might also like

Download as pptx, pdf, or txt
Download as pptx, pdf, or txt
You are on page 1of 64

Entity relationship (ER)modeling

By Jahfar khan saidzai


CS331
saidzai@live.com
 Entity
 Entity set
 Relationship
 Relationship set
 Domain of attribute
Type of attribute

 Simple vs composite
 Single valued vs multi valued
 Deriver attribute vs stored attribute
Concept of Null value
 If attribute I not applicable /spouse name
 If attribute is applicable but not specified
/telephone nuber
 If attribute is applicable and specified but its
value is not known to the agency
maintaining the information
• When not mandatory or constraint the
primary key
Degree of relation ship
• The degree of a relationship is the number of
entities associated with the relationship.
• The n-ary relationship is the general form
for degree n.
• Special cases are the binary, and
ternary ,where the degree is 2, and 3,
respectively.
• Binary relationships, the association between
two entities is the most www.google.com
• common type in the real world. A recursive
binary relationship occurs when an entity is
related to itself. An example might be "some
employees are married to other employees".
• A ternary relationship involves three entities
Relationship constraints
• Mapping cardinality constraint
• Participation constraint
– Mapping cardinality constraint
• One to one mapping cardinality
• One to many mapping cardinality
• Many to one mapping cardinality
• Many to many mapping cardinality
One to one mapping cardinality

Each Entity in A associated with at most one entity in B and each entity in B
is associated with at most one entity in A the ER Modeling , R is linked to A
and B by directed edges
One to many mapping Cardinality

One to many cardinality form A to B ,Each Entity in A can associated with


many (nil/one/more then one) entities in B , but each entity in B will be
associated with at most one entity in A the ER Modeling , it is repesented by
a directed edge for R to A ; and non directed edge from R to B
Many to one cardinality

many to one cardinality form A to B that an entity in A associated with at


most one entity in B , however , one entity in B can be associated with any
number of entities in A , at is represented in ER as above
Many to many mapping cardinality

many to many cardinality form A to B that an entity in A can be associated


with any number of entites in B and an entity in B can be associated with
any number of entites in A , at is represented in ER as above
Relationship Example
Participation constraints
 Total participation
 Partial participation
Total participation
An entity set E is said to have a total
participation in a relationship set R if each in E
is participating at least in one relationship
through R /in ER represented Double line
Partial participation
An entity set E is said to have partial
participation in relationship set R if some of
entities in E are not participating in any
relationship // single line
Key of an entity
The relational data model uses keys to define
identifiers for a relation’s tuples. The keys are
used to enforce rules and/or constraints on
database data. Those constraints are essential
for maintaining data consistency and
correctness.
Super key
the super key of an entity set E is define as the
subset of its attributes which when taken
together , uniquely determine each entity in the
entity set E . Roll_No in
(Roll_No,Name,Branch,father_Name,
address,DoB ,Tel_No)
Candidate key
A candidate key is a unique identifier for the
tuples of a relation. By definition, every
relation has at least one candidate key (the first
property of a relation). In practice, most
relations have multiple candidate keys.
Primary keys
A primary key is a unique identifier of the
relation tuples. As mentioned already, it is a
candidate key that is chosen to represent the
relation in the database and to provide a way to
uniquely identify each tuple of the relation. A
database relation always has a primary key.
Let R be a binary relationship between entity
sets E1 and E2 . Let K1 and K4 be respective
primary keys of E1 and E2 then the primary
key of relationship set R will be a function of
the mapping cardinality of relationship set R
Foreign keys
A foreign key is an attribute (or attribute
combination) in one relation R2 whose values
are required to match those of the primary
key of some relation R1 (R1 and R2 not
necessarily distinct)
• Relational data model constraints
• In a relational data model, data integrity can
be achieved using integrity rules or
constraints. Those rules are general,
specified at the database schema level,
Referential integrity constraint
The referential integrity constraint says that if
a relation R2 includes a foreign key FK
matching the primary key PK of other
relation R1, then every value of FK in R2
must either be equal to the value of PK in
some tuple of R1 or be wholly null (each
attribute value participating in that FK value
must be null). R1 and R2 are not necessarily
distinct
• Semantic integrity constraints
• A semantic integrity constraint refers to the
correctness of the meaning of the data. For
example, the street number attribute value
from the OWNERS relation must be
positive, because the real-world street
numbers are positive.
• Domain constraint
• Null constraint
• Unique constraint
• Check constraint
Primary key of relationship set
One to one mapping cardinlity from E1 to E2
PK(R) =PK(E1) or PK(E2)
One to many mapping cardinality from E1 to E2
Here entity set E2 called many side
PK(R) =PK(E2)
Many to one mapping cardinality from E1 to E2
Here entity set E1 called many side
PK(R) =PK(E1)
Many to many Relationship from E1 to E2
PK(R) =PK(E1) PK(E2)
One to one relationship

PK(Depositor)={CN} or {AN}
One to many relationship

PK(Depositor)= {AN}
Many to one Relationship PK(Depositor)={CN}

Many to many Relationship PK(Depositor)={CN,AN} PK(Customer) υ


PK(Account)
Weak entity
Weak entity set will have a set of attribute
called discriminator

Ex
Employee(ID,name, salary,dependents)
Dependents is multi value attribute can be
better Modeled as a weak entity
Special features of an identifying relationship
i. The identifying relationship will be one to many
from owner Entity set to the weak Entity set
ii. The participation of owner entity ser in the
identifying relationship will partial & weak entity
will by total

Advantages of modeling a multi-valued attribute


as weak entity set
Feature of Extended E-R MODEL
• Specialization
– Entity set E may have sub-groups of
Entity(E1,E2…En)
– Sub groups have some common attributes
– And sub group has some distinct attributes
– On the basis of difference of some attributes is
called specialization .
– E is called Higher level Entity set or super class
– …,En lower level Entity sets of sub-class
The common to all sub groups are
represented with super class and the
attribute specific to each sub clsss
represented with respective sub class
Inheritance of attribute in specialization
Sub class have inherits all the attributes of its
super class pluse it has its own attributes
Ex account – account_number and balance
Account may specify like saving _account
Current_account , Fixed_deposit(FD) and
Recurring_deposit(RD)
Saving_account – interest rate and current
Account
Current_account -- overdraft-limit
Specialization constraint
Disjoint VS overlapping specialization
Disjoint: It implies that each entity in the
higher-level entity set is associated with at
most one lower-level entity set
Overlapping : It implies that each entity in the
higher-level entity set is associated with at
most one lower-level entity set
Total VS partial Specialization
Total : it implies that each Entity in higher-
level entity set will be associated with at
least one lower level entity set /double line ia
Partial : it implies that some of the higher level
entity may not be associated with any lower
level entity set/single line
A total and disjoint specialization implies that
each entity is super-class is associated with
precisely one Entity in sub-class
Generalization
Generaliztion is reverse of specialization
Specialization is a top-down approach
Generalization is a bottom-up approach
wherein lower level entity sets are fused into
higher-level entity set on the basis of
commonality of attributes of the lower level
entity
ER-Model of Generalization and specialization
is same manner
Aggregation
One limitation of the E-R model
Aggregation provide the necessary solution
It si abstraction treats relationship as higher-
level entity set , which can then participate in
relationship with other entity sets or other
relationsip sets
Ex
Employee , Branch , job – relationship EBJ
i. The set of employees managed by a
manager
ii. The set of jobs managed by a manager
iii. The branch managed by a manager
(assuming a manager manages only one
branch
There are three relationship
Can be better modeled by using
aggregation
Reduction of E-R Schema to table
Tabular representation of strong Entity
Simple, single valued attribute //column
Composite value //column for each sub-part
like Name
Derived attribute //No column
Multi value //in separate table like Tell No
Age is not represented
Tell no will be derived form DOB// represented in a separate table
Tabular representation of Relationship
Let R Relation set and let a1,a2,…am set of attribute
fromed by the union of the primary keys
b1, b2,……bn descriptive attribute
Then relationship R will be represented by a table
name R which will have (M+N) columns
Depositor will be represented by a table name depositor
The entity sets customer and account primary key C_ID and account No
Shifting of descriptive attributes of a
Relationship table with the tables of participating
The descriptive attribute of the relationship set
can be shifted to one of the participating
entity set
Also a relationship set table can be combined
with the table of one of the participating
entity
One to One Relationship
One to one relationship
In one to one can be shifted an any table
One to many
Many to one
The table can be combined with many side
Many to Many
The table cannot be combined with any entity set and it has be
created as separated table
Tabular representation of weak Entity set

There will be the table LOAN and PAYMAENT

The table for identifying Relationship LOAN-PAY-MENT is not


required
Tabular Representation of Generalization
Create a Each table for Higher level Entity set
and for each lower level entity set . The table
for lower level entity set will include its own
attribute plus all the primary key attribute of
higher level
Combining of table in Generalization
No need for higher level Entiy

You might also like