Introduction to database-ER Model

Introduction to Databases
ER Model
Ajit K Nayak, Ph.D.
Siksha O Anusandhan University

AKN/IDBI.2Introduction to databases
Entity-Relationship (ER) Data Model
 The ER data model facilitates database design by
allowing specification of an enterprise schema that
represents the overall logical structure of a database.
 It is very useful in mapping the meanings and
interactions of real-world enterprises onto a
conceptual schema.
 The ER data model employs three basic concepts:
 Entity Sets,
 Relationship Sets,
 Attributes.
 The ER model also has an associated diagrammatic
representation, the ER diagram, which can express the
overall logical structure of a database graphically.

ER Data Model - II
 ER Model is said to be the high-end tool of database
design.
 This data model uses a collection of
 basic objects, called entities,
 and relationships among these objects.
 An entity is a ―thing‖ or ―object‖ in the real world that is
distinguishable from other objects.
 Ex: employee, student, account
 An entity has a set of properties that uniquely identifies
an entity called attributes.
 Ex: Employee (empNo, empName, …)
 Student (studNo, studName, branch, …)

ER Model: Entity Set
 Entity Set : is a set of entities of the same type that
share the same attributes.
 Ex: The set of all people who are instructors at a given
university, can be defined as the entity set instructor.
 Ex: The set of all students at a given university, can be defined
as the entity set student.

ER Diagram: Entity Set
 Entities are represented graphically as follows:
 A two part Rectangle represent an entity set.
 Part I: entity set name
 Part II: Attributes listed.
 Underline indicates primary key attributes

ER Model: Relationship - I
 Relationship: A relationship is an association among
several entities.
 Ex: Let‘s define a relationship advisor that associates instructor
Katz with student Shankar.
 Relationship set: is a set of relationships of same type
between two or more entity sets.
Relationship set
advisor

ER Model: Relationship Set - II
 The association between entity sets is referred to as
participation.
 Ex: Katz and Shankar participate in relationship instance of
advisor
 i.e. This relationship instance represents that in the university,
instructor Katz is advising student Shankar.
 Relationship may also have attributes called descriptive
attributes.. Ex. the advisor
relationship set
between entity sets
instructor and student
have the attribute date
which tracks when the
student started being
associated with the
advisor

ER Model: Relationship Set - III
 The function that an entity plays in a relationship is
called that entity‘s role
 Katz‘s role is „instructor‟, Shankar‘s is ‗student‟ in the relationship
of ‗advisor‟
 The same entity set participates in a relationship set
more than once, in different roles is called recursive
relationship set
 Also known as unary relationship
MTH 1001: Calculus I
MTH 2001: Calculus II
CSE1002: Discrete Maths
CSE2011: COA
MTH2002: Probability & Statistics
prerequisite
recursive relationship set
Role of MTH2001: course
Role of MTH1001: prerequisite
course

ER Model: Degree of Relationship
 The degree of a relationship set is the number of entity
sets participate in the relationship.
 The three most common relationship sets categorised
according to the degree in ER models are
 Binary: When two entity sets participates.
 Ex: Teacher teaches some Students
 Unary: when both participants are the same entity
 Ex: Subject prerequisite of another Subject
 Also known as recursive relation
 Ternary: when three entities participate in the
relationship.
 Ex1: Instructor becomes project_guide to students and
develops projects
 Ex2: Teacher teaching_activity with Branch and Subject

ER Diagram: Degree of Relationship
subject
sub_id
title
credits
prerequisite
sub_id
prereq_id
instructor
ID
name
salary
student
ID
name
tot_cred
project
. . .
proj_guid
e
teacher
ID
name
salary
branch
ID
name
tot_cred
subject
. . .
teaching
activity
Unary: The labels ―sub_id‖ and
“prereq_id” are called roles.
Ternary: 3 entity sets participate in
a relationship set
employee
ID
name
salary
department
deptNo
building
budget
belongsTo
Binary: Most of the relationships in
real world are of this type.

ER Model: Attributes
 Attributes are the properties of an entity set that are
relevant to the database and about which the data
values need to be stored.
 For each attribute, there is a set of permitted values,
called domain or value set
 An attribute of an entity set is a function that maps
from the entity set in to a domain.
 Each entity can be described by a set of (attribute,
value) pair.
 Ex. A particular instructor entity may be represented as
{(ID, 76766), (name, Crick), (dept, CSIT), (salary, 50000)}
 Similarly a particular student entity
{(ID, 34721),(name, Sid),(DoB, 30-12-1997),(branch, CSIT)}

Keys - I
 The values of the attributes of an entity must be such
that, they uniquely identify the entity.
 No two entities in an entity set are allowed to have
exactly the same value for all of its attributes.
 A Key makes one entity distinguishable from other entity
in the same entity set.
 A key for an entity set is a set of attributes, whose value
uniquely determines each and every entity in an entity
set.
 Different keys used are
 Candidate key
 Super key
 Primary Key
 Alternate key

Keys - II
 Ex. Consider the entity set
 Student(reg_no, name, branch, address, ph_no, DoB)
 Candidate key: is an attribute who‘s value uniquely
determine each and every entity in an entity set.
 Ex. Candidate keys {name, ph_no}, {name, address} or {reg_no}
 For a given entity set, more than one candidate keys can be
designed.
 Super Key: any superset of an candidate key is referred
as super key
 i.e. A candidate key is the minimal super key, of which no
proper subset can again act as a key.
 Ex. Super Keys: {reg_no, name}, {reg_no, name, ph_no},
{reg_no, name, branch}, {reg_no, name, address} or {reg_no,
name, DoB}, . . .

Keys - III
 Primary key: Out of multiple candidate keys, one of the
key is chosen by the database engineer as the primary
key.
 Primary key is used as principal means to uniquely
identify each and every entity in the entity set.
 Ex. Primary key {reg_no}
 Alternate Key: Rest of the candidate keys (excluding
primary key) are called alternate keys
 Ex. Alternate Keys {name, ph_no} and {name, address}
 Keys are represented in ER Diagram by underlining the key
attribute(s)

ER Model: Category of Attributes- I
 Simple and Composite
 Simple attributes are atomic and cannot be divided further.
 Ex. (regNo)
 Composite attributes are sub-divided further.
 Ex. (name{first_name, middle_name, last_name})
 Composite attributes may be represented in a hierarchy.
Composite attributes are useful when it is needed to use either
whole or part of the information of an attribute

ER Model: Category of Attributes- II
 Single Valued and Multivalued
 Attribute that maps to only one value in a domain are called
single valued attribute
 Ex. DoB, reg_no
 Attribute that maps to more than one values in a domain are
called multivalued attribute.
 Ex. phone_no, email_id
 Derived
 If the value for an attribute can be computed from the values
of other related attributes then is called derived attribute
 Ex. age, net_salary, can be calculated from DoB and other
salary components respectively.

ER Diagram: Attributes
 Composite attribute: represented in
indentation.
 Ex. name with component attributes
first_name,…, last_name
 Ex. address with , city, state, and zip.
 Ex. street with street_no, street name and
apt_number
 Multivalued attribute: represented
using curly braces.
 Ex. {phone_number} of instructor
 Derived attribute: represented
using parenthesis. Ex. age( )

ER Model: Constraints
 Constraints are the reflections of business rules/logic to
which the database design must comply to.
 These are the characteristics of relationship set.
 ER Model supports two types of constraints:
 Mapping Cardinalities
 How many entities in one entity set is associated with entities
of another entity set?
 Participation Constraints.
 Tells about the total or partial participation of an entity set
in a relationship set.
 i.e. Whether all entities or few of them are participating in a
relationship set.
 Ex. Participation of Student entity set in the relationship
advisor is total. But participation of Instructor may be partial

ER Model: Mapping Cardinalities - I
 Mapping cardinalities or
cardinality ratios tells the number
of entities to which another entity
can be associated via a
relationship set.
 One-to-One: An entity in entity set A is
associated with at most one entity in
another entity set B.
 Ex. One Student enrolls in One course
 One-to-Many: An entity in entity set A is
associated with any number of entities in
entity set B.
 Ex. One Teacher advises Multiple
students

ER Model: Mapping Cardinalities - II
 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 of
entities in A.
 Ex. Many Students are enrolled in One
Course
 Many-to-Many: 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.
 Ex. One Customer have Many bank
Accounts and One Account can have
Multiple number of Customers.

ER Diagram: Cardinality Constraints-I
 One: A directed line () from relationship set to entity
set
 Many: an undirected line (—)
 One-to-One relationship between an instructor and a
student :
 A student is associated with at most one instructor via the
relationship advisor
 Task: Draw ER diagram where, A student is associated with at
most one department via stud_dept

ER Diagram: Cardinality Constraints-II
 One-to-Many: an instructor is associated with several
(including 0) students via advisor
 Many-to-One: a student is associated with several (including
0) instructors via advisor

ER Diagram: Cardinality Constraints-III
 Many-to-Many:
 An instructor is associated with several (possibly 0) students via
advisor
 A student is associated with several (possibly 0) instructors via
advisor

ER Diagram: Total and Partial Participation
 Total participation is indicated by double line:
 i.e. every entity in the entity set participates in at least one
relationship in the relationship set
Ex. participation of student in advisor relation is total
 every student must have an associated instructor
 Partial participation: some entities may not
participate in any relationship in the relationship set
 Ex. participation of instructor in advisor is partial

ER Diagram: Complex Constraints
 A line may have an associated minimum and
maximum cardinality, shown in the form l..h, where
 A minimum value of 1 indicates total participation
 A maximum value of 1 indicates that the entity participates in
at most one relationship
 A maximum value of * indicates no limit.
Instructor can advise 0 or more students. A student must
have 1 advisor; cannot have multiple advisors

Example: Represent Entities
 Consider a retail store
 Order 1
Date: 26-8-16,
Amount:1620.00
Add: BBSR,
Item1: rice, qty: 2, Price:90.00,
Item2: trouser, qty:1, Price1200.00,
Item3:soap, qty:3, Price150.00,
Item4:biscuit, qty:3, Price:180.00
 Order 2: . . .
 Order 3: . . .

ER Model: Weak Entity Set - I
 An entity set that cannot be uniquely identified by its
attributes alone are called weak entity sets.
 i.e. the entity set does not have sufficient attributes to form a
primary key and are dependent on other entity sets for their
existence.
 An entity having own primary key is called a strong
entity.
 The strong entity upon which the weak entity depends
is refereed as identity entity
 The relationship set through which the weak entity is
connected to its identity (strong) entity set is called
identifying relationship set.

ER Diagram: Weak Entity Set
 Ex. orderItem(item_no, quantity, price, discount)
orderItem
sitem_no
quantity
price
discount
order
order_no
order_date
payment_info
shipping_add
contains
 The relationship set with its identity entity (strong) set is
represented using double line diamond
 The line from weak entity to identifying relationship set is double
lined
 A set of attributes of a weak entity set is referred as the
discriminator (or partial key) that is used as a means of
distinguishing among all those entities in the weak entity set that
depend on one particular strong entity

Weak Entity Set - III
 The discriminator of a weak entity is underlined with
dashed line.
 The primary key of a weak entity set is formed by
 the primary key of the identifying entity set, plus
 the weak entity set‘s discriminator.
 In the case of the entity set order, its primary key is
{order_no, item_no, quantity, price, discount}
 The participation of the weak entity set with its
identifying relationship set is always total.
 The cardinality of the identifying relationship set is
always many-to-one from the weak entity set to its
identifying entity set

Weak Entity Set - III
 Discriminator?
 Primary key?
 primary key of section {course_id, sec_id, year,
semester}
 The identifying relationship set is not allowed to have
any descriptive attribute
 Weak entity can participate in any other relationship
set after forming the primary key.
section
section_id
semester
year
course
course_id
title
credits
secCourse

Participation Constraints
account
accNum
balancedeposits
loan
loanNum
loanAmt
branch
brID
brName
brAdd
loanBranch
borrows accWith
lastAccessDate
customer
custNum
name
fName
lName
address
{phoneNum}
• Participation of entity
set account in
deposit relationship &
accWith relationship
is total
• Participation of loan
entity set in
loanBranch
relationship &
borrows relationship
is total

Extended ER Features
 The extended ER features are
 Specialization
 Generalization
 Aggregation

Specialization
 An entity set may allow further sub-grouping within it
based on the distinctive features (attributes)
 Specialization is a technique of designating sub-
grouping of entities within an entity set based upon
the distinct attributes that the entity possess
 Specialization is a refinement approach that stems
from an entity set (higher level entity set ) in order to
form multiple entity sets (lower level entity set )
 The entities in the lower level entity sets are the sub-
sets of the entities in its higher level entity set.
 This is known as „IS A‟ relationship.
 Ex. Tiger is an Animal, Cheetah is a Tiger
 Also referred as ―Superclass – subclass‖ relationship

Generalization
 Generalization is the approach of synthesizing multiple
entity set (lower level) in order to form a higher level
entity set based upon common features (attributes)
posses by the lower level entity sets
 Generalization stems from multiple lower level entity
sets and forms a single higher level entity set.
 In ER diagram it is represented in same way as
specialization.
 Ex. Given: Cat, Tiger, Wolf, Lion, elephant entity sets,
we extract and use all the common features available
in all entity sets to form another Animal entity set.

Specialization Examples
MTechStud
. . .
MCAStud
. . .
student
stud_id
name
. . .
PGStud
. . .
UGStud
. . .
employee
emp_id
name
desig
regEmp
salary
leave
partEmp
perkPerHr
hourPerWk

Attribute Inheritance
 All the attributes including the primary key of the
higher level entity set are inherited/derived and
associated to all lower level entity sets
 Ex. student and employee inherit the attributes of person.
 Thus, student is described by its ID, name, and address
attributes, and additionally a tot_cred attribute;
 employee is described by its ID, name, and address attributes,
and additionally a salary attribute.

Participation Inheritance
 A lower-level entity set also inherits participation in the
relationship sets in which its higher-level entity
participates.
 Participation inheritance applies through all tiers of lower-level
entity sets.
 Ex. suppose the person entity set participates in a relationship
person_dept with department.
 Then, the student, employee, instructor and secretary entity
sets, which are subclasses of the person entity set, also
implicitly participate in the person_dept relationship with
department.
 The above entity sets can participate in any relationships in
which the person entity set participates.

Overlapping and Disjoint Constraints
 Specialization is said to be overlapping if there exists at
least one entity in the higher entity set that belongs to
more than one lower level entity sets, otherwise called
disjoint.
Overlapping specialization
disjoint specialization
Overlapping Specialization
the same entity may belong to
more than one lower-level entity set
within a single generalization
Disjoint Specialization
If an entity belong to no more
than one lower-level entity set

Membership Constraint
 To model an enterprise more accurately, certain constraints may
be place on a particular generalization
 Condition-defined Membership
 A membership is confirmed if an entity satisfies an explicit
condition.
 Ex. student has an attribute student_type. Whose value can
be „undergraduate‟ or „graduate‟
 Then all entities that satisfy the condition student type =
“undergraduate” are included in UGStud.
 User-defined Membership
 after 3 months of employment, university employees are
assigned to one of four work teams.
 The teams are represented as four lower-level entity sets of the
higher-level employee entity set.
 A given employee is assigned to a specific team entity set
manually.

Completeness Constraint
 Total generalization or specialization.
 Each higher-level entity must belong to a lower-level entity set.
 Ex. The student generalization is total: All student entities must
be either post graduate or undergraduate.
 Partial generalization or specialization.
 Some higher-level entities may not belong to any lower-level
entity set.
 Partial generalization is the default.
 Ex. The employee generalization is partial. Some employees
are there who are neither an instructor nor a secretary.

Specialization/Generalization
• Design two sub entity sets of account as sbAcc and
currAcc.
account
accNum
balancedeposits
loan
loanNum
loanAmt
branch
brID
brName
brAdd
loanBranch
borrows accWith
lastAccessDate
customer
custNum
name
fName
lName
address
{phoneNum}
installment
instNum
instAmt
instDate
payBack
sbAcc
rateOfInt
currAcc
odAmt
• It is a disjoint
specialization!

Problem
 How to Modify the model s.t. an Instructor guiding a
student on a project can file a monthly evaluation
report containing instructor, student and project
information
instructor
ID
name
salary
student
ID
name
tot_cred
project
. . .
proj_guide

Aggregation -I
 It can express relationship among relationship sets
 Aggregation facilitates to treat a relationship set
(along with all of its associated entity sets) as a higher
level entity set and can participate in another
relationship set.
 i.e. Aggregation is an abstraction through which relationships
are treated as higher-level entities.

Aggregation -II
 The relationship set proj_guide is represented as a
higher-level entity set called proj guide.
 Such an entity set is treated in the same manner as is
any other entity
 We then create a binary relationship
eval_for between proj_guide and
evaluation to represent which
combination an evaluation is for.

Reduction to Relational Schema
 An E-R design can be Translated/mapped/reduced
into a relational design.
 Entity sets and relationship sets can be expressed
uniformly as relation schemas that represent the
contents of the database.
 A database which confirms to an E-R diagram can be
represented by a collection of schemas.
 For each entity set and relationship set there is a
unique schema that is assigned the name of the
corresponding entity set or relationship set.
 Each schema has a number of columns (generally
corresponding to attributes), which have unique
names

(R1) Mapping Strong Entity sets
 A strong entity set reduces to a schema with the same
attributes as in entity set.
A
a1
a2
a3
 Mapping: A(a1,a2,a3)
student
ID
name
tot_cred
 student(ID, name, tot_cred)

(R2) Mapping Relationship sets
 A relationship set reduces to a schema with the
primary key attributes of participating entities and
descriptive attributes.
 (R2.1) For a binary many-to-many relationship, the
union of the primary-key attributes from the
participating entity sets becomes the primary key.
A
a1
a2
a3
B
b1
b2
b3
R
r1
 A(a1, a2, a3)
 B(b1, b2, b3)
 R(a1, b1, r1)

(R2) Mapping Relationship sets - II
 (R2.2)For a binary one-to-one relationship set, the
primary key of either entity set can be chosen as the
primary key. The choice can be made arbitrarily
A
a1
a2
a3
B
b1
b2
b3
R
 A(a1, a2, a3)
 B(b1, b2, b3)
 R(a1, b1) or
 R(a1, b1)

(R2) Mapping Relationship sets - III
 (R2.3) For a binary many-to-one or one-to-many
relationship, the primary key of the entity set on the
―many‖ side of the relationship set serves as the
primary key.
A
a1
a2
a3
B
b1
b2
b3
R
 A(a1, a2, a3)
 B(b1, b2, b3)
 R(a1, b1)

(R2) Mapping Relationship sets - IV
 (R2.4) For an n-ary relationship set without any arrows on its
edges, the union of the primary key-attributes from the
participating entity sets becomes the primary key.
 (R2.5) For an n-ary relationship set with an arrow on one of its
edges, the primary keys of the entity sets not on the ―arrow‖
side of the relationship set serve as the primary key for the
schema.
 A(a1, a2, a3)
 B(b1, b2, b3)
 B(c1, c2, c3)
 R(a1, b1 , c1)
A
a1
a2
a3
B
b1
b2
b3
R
C
c1
c2
c3

(R3) Referential Integrity
 For each entity set Ei related to relationship set R, we
create a foreign-key constraint from relation schema
R, with the attributes derived from primary-key
attributes of Ei.
A
a1
a2
a3
B
b1
b2
b3
R
 Two foreign key constraints are created on relation R
 i.e. attribute r_a1 referencing primary key of A and
attribute r_b1 referencing primary key of B.
 A(a1, a2, a3)
 B(b1, b2, b3)
 R(r_a1, r_b1)

(R3) Mapping Composite attributes
 While mapping a composite attribute to a relation, we
form one attribute in the relation schema for each
sub-attribute in the composite attribute of ER diagram.
 Attribute is not created for the composite attribute
itself.
 A(a1, a21, a22, a3)A
a1
a2
a21
a22
a3
B
b1
b2
b21
b211
b212
b22
b3
 B(b1, b211, b212, b22,b3)

(R4) Mapping Multivalued attributes
 For a multivalued attribute m, we create a separate
relation schema R with an attribute a that corresponds
to m and the primary key of the entity set.
 All of the attributes of R becomes the primary key of
the relation R.
 R(a1, m)A
a1
a2
{m}
instructor
id
name
address
{phone_no}
 instructorPhone(id1, phone_no)
 We create a foreign-key constraint on the relation
schema created from the multivalued attribute.

(R5) Mapping Weak Entity Set
 For schemas derived from a weak entity set, the
combination of the primary key of the strong entity set
and the discriminator of the weak entity set serves as
the primary key of the schema.
 No separate relation for R is required, however, if R
contains a descriptive attribute, then it is added in A
A
a1
a2
B
b1
b2
R
 Primary key of B: b1
 Discriminator of A: a1,a2
 A foreign-key constraint is created on the relation A,
specifying that the attributes b1, b2 reference the
primary key of the relation B.
 A(a1, b1, a2) and B(b1,b2)

(R2.5) Referential Integrity
 For each entity set Ei related to relationship set R, we
create a foreign-key constraint from relation schema
R, with the attributes derived from primary-key
attributes of Ei.
A
a1
a2
a3
B
b1
b2
b3
R
 Two foreign key constraints are created on relation R
 i.e. attribute r_a1 referencing primary key of A and
attribute r_b1 referencing primary key of B.
 A(a1, a2, a3)
 B(b1, b2, b3)
 R(r_a1, r_b1)

(R3) Mapping Composite attributes
 While mapping a composite attribute to a relation, we
form one attribute in the relation schema for each
sub-attribute in the composite attribute of ER diagram.
 Attribute is not created for the composite attribute
itself.
 A(a1, a21, a22, a3)A
a1
a2
a21
a22
a3
B
b1
b2
b21
b211
b212
b22
b3
 B(b1, b211, b212, b22,b3)

(R4) Mapping Multivalued attributes
 For a multivalued attribute m, we create a separate
relation schema R with an attribute that corresponds
to m and the primary key of the entity set.
 All of the attributes of R becomes the primary key of
the relation R.
 A(a1,a2)
 R(a1, m)
A
a1
a2
{m}
instructor
id
name
address
{phone_no}
 Instructor(id,name,address)
 instructorPhone(id, phone_no)
 We create a foreign-key constraint on the relation
schema created from the multivalued attribute.

(R5) Mapping Weak Entity Set
 For schemas derived from a weak entity set, the
combination of the primary key of the strong entity set
and the discriminator of the weak entity set serves as
the primary key of the schema.
 No separate relation for R is required, however, if R
contains a descriptive attribute, then it is added in A
A
a1
a2
B
b1
b2
R
 Primary key of B: b1
 Discriminator of A: a1,a2
 A foreign-key constraint is created on the relation A,
specifying that the attributes b1 references the
primary key of the relation B.
 A(a1, b1, a2) and B(b1,b2)

(R6) Combination of Schemas
 If entity sets participate in a total participation with
cardinality constraint as many-to-one, then the
schema for entity set in total participation and the
relationship set may be reduced to a single schema.
 The relation schema for other entity set remain as it is.
 Now the first two schemas may further be reduced
to one schema as
 A(a1, a2, b1), where b1 is the foreign key for b1 in B
A
a1
a2
B
b1
b2
R
 A(a1, a2),
 R(a1, b1)
 B(b1, b2)

(R7.1) Mapping Generalization - I
 Case I: (Overlapping, disjoint and partial)
 Create a schema for higher level entity set.
 Again create a schema for each lower level entity sets with
attributes as follows
 Primary key of higher level entity set
 All attributes of lower level entity set A
a1
a2
B
b1
b2
C
c1
c2
 A(a1,a2)
 B(a1,b1,b2)
 C(a1,c1, c2);
 Foreign key constraints
 a1 of B and C refers to a1
of A

(R7.2) Mapping Generalization - II
 Case II: (Disjoint and complete Generalization)
 Schema for higher level entity set is created only with primary
key attribute.
 And The schema for lower level entities will have following
attributes.
 All higher level attributes.
 All attributes of lower level entity set
 A(a1)
 B(a1,a2,b1,b2)
 C(a1,a2,c1, c2);
 Foreign key constraints?
A
a1
a2
B
b1
b2
C
c1
c2
total

(R8) Mapping Aggregation
 The schema for the
relationship set R between
the aggregation of R and
the entity set D includes an
attribute for each attribute
in the primary keys of the
entity set D, and the
relationship set R.
C
c1
c2
A
a1
a2
B
R
R
D
d1
d2
b1
b2
 A(a1,a2), B(b1, b2), C(c1, c2), D(d1, d2)
 R(a1,b1,c1), R(a1,b1,c1,d1)
 Foreign key constraints?

Schema Diagram
 A database schema, along with primary key and
foreign key dependencies, can be depicted by
schema diagrams.
 Each relation appears as a box, with the relation
name at the top, and the attributes listed inside the
box.
 Primary key attributes are shown underlined.
 Foreign key dependencies appear as arrows from
the foreign key attributes of the referencing relation
to the primary key of the referenced relation.

Example: Schema Diagram
A
a1
a2
a3
B
ba1
b1
b2
bc1
C
c1
c2
c3
 ba1 is the foreign key attribute of the referencing
relation B to the primary key attribute a1 of the
referenced relation A
 Similarly bc1 is the foreign key attribute of the
referencing relation B to the primary key attribute c1
of the referenced relation C

Thank You

Introduction to database-ER Model

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (20)

Ähnlich wie Introduction to database-ER Model

Ähnlich wie Introduction to database-ER Model (20)

Mehr von Ajit Nayak

Mehr von Ajit Nayak (19)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Introduction to database-ER Model