Download relation - University of Windsor

Chapter 1
Entity Relationship Model
Chapter 3 : Objectives
 Main Phases of Database Design
 Characteristics of ER Model
 Components of ER Model
 Definitions
 Classification of Attributes
 Entity Types
 Entity Set
 Key attribute
Ritu Chaturvedi
Some figures adapted from Fundamentals of
database systems by Elmasri and Navathe and
2
Chapter 3 : Objectives (Continued.)
 Relationship Types
 Recursive Relationships:
 Structural Constraints on Relationship Types:
 Attributes on Relationship Types
 Weak Entity Type
 Problems with ER Models
Ritu Chaturvedi
Some figures adapted from Fundamentals of
database systems by Elmasri and Navathe and
3
Main Phases of Database Design
 Database Design
Ritu Chaturvedi
Some figures adapted from Fundamentals of
database systems by Elmasri and Navathe and
4
Introduction
 E-R model facilitates database design by allowing the
specification of an “enterprise schema” which
represents the overall logical structure of a database.
 The E-R model is extremely useful in mapping the
meanings and interactions of real-world enterprises
onto a conceptual schema.
Ritu Chaturvedi
Some figures adapted from Fundamentals of
database systems by Elmasri and Navathe and
5
Characteristics of ER Model
 Express the logical properties of an
enterprise database
 No physical DBMS
 Proposed by Dr. Peter Chen
Ritu Chaturvedi
Some figures adapted from Fundamentals of
database systems by Elmasri and Navathe and
6
Components of ER Model
 Entity, Entity Type, Entity Set
 Attribute
 Key (Identifier)
 Relationship, Relationship Type, Relationship
Set
 Structural Constraints on relationships
Ritu Chaturvedi
Some figures adapted from Fundamentals of
database systems by Elmasri and Navathe and
7
Definitions
 A
Database can be modeled as :


a collection of entities
relationships among entities.
Entity:



An object in the real world with an
independent existence
Is distinguishable from other objects
could have a physical existence or a
conceptual existence
Ritu Chaturvedi
Some figures adapted from Fundamentals of
database systems by Elmasri and Navathe and
8
Example (Entity)

Example:
person, company, event, plant

More Specific example:
Consider University of Windsor as a large
enterprise.

Entities :
 Ritu (Employee)
 John Smith (Student) …
Ritu Chaturvedi
Some figures adapted from Fundamentals of
database systems by Elmasri and Navathe and
9
Attribute
Attribute: the property that describes an entity or a
relationship type.
Examples:
Student : id, fname, lname, yrAdmin
Employees: id, fname, lname, position
ER :
Domain of Attributes: Set of values that may be
assigned to that attribute for each entity (set of
permitted values) .
Ritu Chaturvedi
Some figures adapted from Fundamentals of
database systems by Elmasri and Navathe and
10
Entity Types
A collection of entities that have the same
attributes (describes the intension of a
database).
ER :
Entity Type
 Example : EMPLOYEES, STUDENTS
Ritu Chaturvedi
Some figures adapted from Fundamentals of
database systems by Elmasri and Navathe and
11
Entity Set
Entity Set : The collection of all entities of a
particular entity type in the database at any
point in time. (Extension of the database)
Attributes are properties possessed by all
members of an entity set .
Ritu Chaturvedi
Some figures adapted from Fundamentals of
database systems by Elmasri and Navathe and
12
Classification of Attributes
1.Simple ~ Composite
 Simple Attribute :

Attribute composed of a single component
with an independent existence.
 Composite Attribute

Attribute composed of multiple components,
each with an independent existence.
Ritu Chaturvedi
Some figures adapted from Fundamentals of
database systems by Elmasri and Navathe and
13
Classification of Attributes
2. Single-Valued ~ Multi-Valued
Single-valued Attribute

Attribute that holds a single value for each
occurrence of an entity type.
Multi-valued Attribute { },

Attribute that holds multiple values for each
occurrence of an entity type.
Ritu Chaturvedi
Some figures adapted from Fundamentals of
database systems by Elmasri and Navathe and
14
Classification of Attributes
3. Stored ~ Derived
Derived Attribute

Attribute that represents a value that is
derivable from value of a related attribute, or
set of attributes, not necessarily in the same
entity type.
Ritu Chaturvedi
Some figures adapted from Fundamentals of
database systems by Elmasri and Navathe and
15
Classification of Attributes
 NULL
Ritu Chaturvedi
Some figures adapted from Fundamentals of
database systems by Elmasri and Navathe and
16
Key attribute
 Key attribute : An attribute of an entity type
whose values are distinct for each individual
entity in the collection.

ER :
Student_Id
Ritu Chaturvedi
Some figures adapted from Fundamentals of
database systems by Elmasri and Navathe and
17
Example : COMPANY Database:
1. 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.
2. A department controls a number of projects, each of which has a
unique name, a unique number, and a single location.
3. We store each employee’s name, social security number
,address, salary, sex, 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 number of hours per week that an employee works
on each project. We also keep track of the direct supervisor of
each employee.
4. 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.
Ritu Chaturvedi
Some figures adapted from Fundamentals of
database systems by Elmasri and Navathe and
18
Preliminary design of entity types for
the COMPANY Database
 DEPARTMENT

Name, Number, {Locations}, Manager, ManagerStartDate
 PROJECT

Name, Number, Location, ControllingDepartment
 EMPLOYEE

Name(FName, MInit, LName), SSN, Sex, Address, Salary,
BirthDate, Department, Supervisor,
{WorkOn (Project, Hours)}
 DEPENDENT

Employee, DependentName, Sex, BirthDate, Relationship
Ritu Chaturvedi
Some figures adapted from Fundamentals of
database systems by Elmasri and Navathe and
19
Relationship
 A relationship is an association among
entities.
Ritu
Teaches
Employee
Relationship
Ritu Chaturvedi
Some figures adapted from Fundamentals of
database systems by Elmasri and Navathe and
315
Course
20
Relationship Types
A relationship type R among n entity types E1 ..
En is a set of relationship instances r i where
each r i associates n individual entities (e1, e2,
…. en) and each entity ej in ri is a member of
entity type Ej, 1<=j<=n. Ej is called the
participating entity type.
Ritu Chaturvedi
Some figures adapted from Fundamentals of
database systems by Elmasri and Navathe and
21
Example
 An employee works for a department
Example relationship instances of the WORKS_FOR
relationship between EMPLOYEE and DEPARTMENT
EMPLOYEE
WORKS_FOR
DEPARTMENT
r1
e1

e2

e3

e4

e5

r5
e6

r6
e7

r7
r2
r3

d1

d2

d3
r4
Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition
Chapter 3-14
Copyright © 2004 Pearson Education, Inc.
Ritu Chaturvedi
Some figures adapted from Fundamentals of
database systems by Elmasri and Navathe and
22
Example
Relationship instances : r1(e1, d1)
r2(e2, d2)
r3(e3, d1)
Relationship type: WORKS_FOR
 ER :
EMPLOYEE
WORKS
_FOR
Ritu Chaturvedi
Some figures adapted from Fundamentals of
database systems by Elmasri and Navathe and
………..
DEPARTMENT
23
Example
 ER
Diagram?
Example
relationship instances of the WORKS_ON
relationship between EMPLOYEE and PROJECT
r9 r
1
e1

e2

e3

e4

e5

r5
e6

r6
e7

r7
r2
r3

p1

p2

p3
r4
r8
Ritu Chaturvedi
Elmasri/Navathe, Fundamentals of Database
Systems, Fourth Edition
Some
figures
adapted
Copyright © 2004 Pearson Education, from
Inc. Fundamentals of
database systems by Elmasri and Navathe and
Chapter 3-15
24
Example
ER Diagram?
Ritu Chaturvedi
Some figures adapted from Fundamentals of
database systems by Elmasri and Navathe and
25
Recursive Relationships:
The same entity type participates more than once in a
relationship type in different roles. Each role is
given a name.
Example :
Supervisee(2)
SUPERVISIO
N
EMPLOYEE
Supervisor(1)
Roles are optional – they clarify semantics of a relationship
Ritu Chaturvedi
Some figures adapted from Fundamentals of
database systems by Elmasri and Navathe and
26
Recursive Relationships
A RECURSIVE RELATIONSHIP
SUPERVISION
EMPLOYEE
e1

e2

e3

e4

e5

e6

e7

SUPERVISION
r1
2
1
1
r2
2
2
r3
1
2
1
1
2
r4
r5
1
2
r6
© The Benjamin/Cummings Publishing Company, Inc. 1994, Elmasri/Navathe, Fundamentals of Database Systems, Second Edition
Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition
Chapter 3-24
Copyright © 2004 Pearson Education, Inc.
Ritu Chaturvedi
Some figures adapted from Fundamentals of
database systems by Elmasri and Navathe and
27
Attributes of Relationship Types
 A relationship type can have attributes.
Attribute of a Relationship Type is:
Hours of WORKS_ON
Ritu Chaturvedi
Some figures adapted from Fundamentals of
Elmasri/Navathe, Fundamentals
ofby
Database
Systems,
Edition
database systems
Elmasri and
Navathe Fourth
and
Copyright © 2004 Pearson Education, Inc.
28
Chapter 3-27
Degree of a relationship
Degree of a relationship: Number of relations
taking part in a relationship type.
 Binary
Ritu Chaturvedi
Some figures adapted from Fundamentals of
database systems by Elmasri and Navathe and
29
Structural Constraints on Relationship
Types:
 Limit the possible combination of entities
 Represent business rules established by the
user or company.
 2 Structural Constraints :


Cardinality Ratio
Participation Constraint
Ritu Chaturvedi
Some figures adapted from Fundamentals of
database systems by Elmasri and Navathe and
30
Cardinality Ratio
Cardinality Ratio : number of relationship
instances that an entity can participate in.
SHOWN BY PLACING APPROPRIATE NUMBER ON
THE LINK.
Examples : 1:N, 1:1 , M:N
Ritu Chaturvedi
Some figures adapted from Fundamentals of
database systems by Elmasri and Navathe and
31
Participation Constraint
Participation Constraint: specifies whether the
existence of an entity depends on its being
related to another entity via the relationship
type.
SHOWN BY DOUBLE LINING THE LINK
- Total (Existence dependency)
ER :
=
- Partial
Ritu Chaturvedi
Some figures adapted from Fundamentals of
database systems by Elmasri and Navathe and
32
Weak Entity Type
Definition: A weak entity type is one that meets
2 conditions :
1. It is existence dependent; that is, it cannot
exist without the entity with which it has a
relationship.
2. It has a (primary) key that is partially or
totally derived from the parent entity in the
relationship.
Ritu Chaturvedi
Some figures adapted from Fundamentals of
database systems by Elmasri and Navathe and
33
Weak Entity Type
-don't have key attributes of their own
-Partial key
-Identifying Entity Type
ER -Weak entity types always have a total
participation constraint with respect to its
identifying relationship.
Ritu Chaturvedi
Some figures adapted from Fundamentals of
database systems by Elmasri and Navathe and
34
Example :ER for COMPANY database
ER DIAGRAM – Entity Types are:
EMPLOYEE, DEPARTMENT, PROJECT, DEPENDENT
Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition
Chapter 3-12
Copyright © 2004 Pearson Education, Inc.
Ritu Chaturvedi
Some figures adapted from Fundamentals of
database systems by Elmasri and Navathe and
35
Alternate ER Diagram
COMPANY ER Schema Diagram
using (min, max) notation
Ritu
ChaturvediSystems, Fourth Edition
Elmasri/Navathe, Fundamentals of
Database
Some
figures
adapted
from Fundamentals
of
Copyright © 2004 Pearson Education,
Inc.
database systems by Elmasri and Navathe and
Chapter 3-31
36
Example 1 :
Ritu Chaturvedi
Some figures adapted from Fundamentals of
database systems by Elmasri and Navathe and
37
Example 2
 Draw an ER diagram to show the relationship
between CLUB_MEMBER and LOCKER.
 Assume that every club member must have a
locker, though a locker need not have a club
member assigned to it.
Ritu Chaturvedi
Some figures adapted from Fundamentals of
database systems by Elmasri and Navathe and
38
Phases of DB Design
Ritu Chaturvedi
Some figures adapted from Fundamentals of
database systems by Elmasri and Navathe and
39
Relational DB Model :Logical View of Data
- Logical Model proposed in 1970 by Codd
- Designer focuses on logical representation
rather than physical
- Use of table advantageous
Structural and data independence
Related records stored in independent tables
Logical simplicity

- Allows for more effective design strategies
Ritu Chaturvedi
Some figures adapted from Fundamentals of
database systems by Elmasri and Navathe and
40
Definitions
 A relation is a table with columns and rows.
 Only applies to logical structure of the
database, not the physical structure.
 Attribute is a named column of a relation.
 Attribute Domain is the set of allowable
values for one or more attributes.
 Tuple is a row of a relation : rows represent
a single entity
Ritu Chaturvedi
Some figures adapted from Fundamentals of
database systems by Elmasri and Navathe and
41
Definitions
 Row/column intersection represents single
value
 Degree is the number of attributes in a
relation.
 Cardinality is the number of tuples in a
relation.
 Relational Database is a collection of
normalized relations with distinct relation
names.
Ritu Chaturvedi
Some figures adapted from Fundamentals of
database systems by Elmasri and Navathe and
42
Properties of a relation
 The relation has a name that is distinct from all other






relation names in the database schema.
Theoretically, ordering of tuples may have no
significance.
The order of attributes has no significance.
Each cell of a relation contains exactly one atomic
value.
Each attribute has a distinct name.
The values of an attribute are all from the same
domain.
Each tuple is distinct – there are no duplicate tuples.
Ritu Chaturvedi
Some figures adapted from Fundamentals of
database systems by Elmasri and Navathe and
43
Examples of relation
Ritu Chaturvedi
Some figures adapted from Fundamentals of
database systems by Elmasri and Navathe and
44
Examples of Attribute Domains
Ritu Chaturvedi
Some figures adapted from Fundamentals of
database systems by Elmasri and Navathe and
45
Mathematical Definition of Relation
- Consider two sets, D1 & D2, where D1 = {2, 4} and D2 = {1, 3, 5}.
Cartesian product, D1 X D2, is set of all ordered pairs, where first
element is member of D1 and second element is member of D2.
=> D1 X D2 = {(2, 1), (2, 3), (2, 5), (4, 1), (4, 3), (4, 5)}
- Any subset of Cartesian product is a relation
e.g: R = {(2,1),(4,1)}
- Mathematically, r(R) is a subset of the Cartesian product of the
domains that define R.
=> r(R) subsetOf (dom(A1) × dom(A2) ….× dom(An))
Ritu Chaturvedi
Some figures adapted from Fundamentals of
database systems by Elmasri and Navathe and
46
Definitions
 Relation Schema R denoted by R(A1,A2, …. An) is made up of
a relation name R and a list of attributes A1, A2….An and
domain name D1,D2,….Dn pairs. ( Each Ai has a Di )
 Relational database schema is a set of relational schemas,
each with a distinct name.
 Relation instance ( relation) r of a relation R(A1,A2,…..An)
also denoted by r(R) is a set of n-tuples {t1….tm}where each ntuple t is a list of n-values t=<v1,v2….vn> where 1≤vi≤n is an
element of dom(Ai)
 R: schema of the relation
 R is also called the intension of a relation
 r is also called the extension of a relation
Ritu Chaturvedi
Some figures adapted from Fundamentals of
database systems by Elmasri and Navathe and
47
Relational keys
 Superkey
 Candidate Key (K)
 Primary Key
 Alternate keys
 Foreign Keys
 Surrogate keys
Ritu Chaturvedi
Some figures adapted from Fundamentals of
database systems by Elmasri and Navathe and
48
Superkey

An attribute or set of attributes that uniquely
identifies a tuple in a relation.

Every relation has at least one super key.
Ritu Chaturvedi
Some figures adapted from Fundamentals of
database systems by Elmasri and Navathe and
49
Candidate Key (K)
 Superkey such that no proper subset of K is a




superkey within the relation.
K is a minimal superkey.
K is a super key of R with the additional property that
removing any attribute A from K leaves a set of
attributes K’ that is not a superkey of R.
In each tuple of a relation R, values of K uniquely
identify that tuple (Uniqueness).
No proper subset of K has the uniqueness property
(irreducibility).
Ritu Chaturvedi
Some figures adapted from Fundamentals of
database systems by Elmasri and Navathe and
50
Primary Key
 Candidate key selected to identify tuples
uniquely within a relation.
Ritu Chaturvedi
Some figures adapted from Fundamentals of
database systems by Elmasri and Navathe and
51
Alternate keys
 Candidate keys that are not selected to be
primary key.
Ritu Chaturvedi
Some figures adapted from Fundamentals of
database systems by Elmasri and Navathe and
52
Surrogate Key
 A surrogate key is a system-generated (non-
meaningful from a business perspective)
primary key for purposes of ensuring
uniqueness within a database table.
Ritu Chaturvedi
Some figures adapted from Fundamentals of
database systems by Elmasri and Navathe and
53
Foreign Keys
 A set of attributes FK in a relation R1 is a
foreign key of R1 that references relation R2
if it satisfies the following rules :


The attributes in FK have the same domain as
the primary key attributes in PK of R2
A value of FK in a tuple t1 of R1 either occurs
as a value of PK for some tuple t2 in R2 or is
null.
Ritu Chaturvedi
Some figures adapted from Fundamentals of
database systems by Elmasri and Navathe and
54
Relational Schema of Company
Database (with PKs and FKs) :
To be done in class.
Ritu Chaturvedi
Some figures adapted from Fundamentals of
database systems by Elmasri and Navathe and
55
Relational Integrity Constraints
 Constraints are conditions that must hold on
all valid relation instances. There are 4 main
types of constraints:




Domain Constraint
Key constraints
Entity Integrity Constraint
Referential Integrity Constraint
Ritu Chaturvedi
Some figures adapted from Fundamentals of
database systems by Elmasri and Navathe and
56
Domain Constraint:
Specifies that the value of each attribute A in a
relation Ri must be an atomic value from
the dom(A)
Ritu Chaturvedi
Some figures adapted from Fundamentals of
database systems by Elmasri and Navathe and
57
Entity Integrity Constraint
 Specifies that no primary key value can be null.
 The primary key attributes PK of each relation
schema R in S cannot have null values in any tuple of
r(R). This is because primary key values are used to
identify the individual tuples.
t[PK]  null for any tuple t in r(R)
 Note: Other attributes of R may be similarly
constrained to disallow null values, even though they
are not members of the primary key.
=>
Ritu Chaturvedi
Some figures adapted from Fundamentals of
database systems by Elmasri and Navathe and
58
Referential Integrity Constraint
 A constraint involving two relations (the previous constraints





involve a single relation).
Used to specify a relationship among tuples in two relations: the
referencing relation and the referenced relation.
Tuples in the referencing relation R1 have attributes FK (called
foreign key attributes) that reference the primary key attributes
PK of the referenced relation R2.
A tuple t1 in R1 is said to reference a tuple t2 in R2 if t1[FK] =
t2[PK].
A referential integrity constraint can be displayed in a relational
database schema as a directed arc from R1.FK to R2.
Used to maintain consistency among tuples of two relations
Ritu Chaturvedi
Some figures adapted from Fundamentals of
database systems by Elmasri and Navathe and
59
Statement of the RI constraint
 The value in the foreign key column (or
columns) FK of the referencing relation R1
can be either:
(1) a value of an existing primary key
value of the corresponding primary key PK in
the referenced relation R2, or
(2) a null.
 In case (2), the FK in R1 should not be a part
of its own primary key.
Ritu Chaturvedi
Some figures adapted from Fundamentals of
database systems by Elmasri and Navathe and
60
Enforcing Referential Integrity
(Update Operations on Relations)
- INSERT a tuple.
- DELETE a tuple.
- MODIFY a tuple.
Ritu Chaturvedi
Some figures adapted from Fundamentals of
database systems by Elmasri and Navathe and
61
Update Operations on Relations
 Integrity constraints should not be violated by the update
operations.
 Updates may propagate to cause other updates automatically.
This may be necessary to maintain integrity constraints.
 In case of integrity violation, some actions that can be taken:



Cancel the operation that causes the violation (REJECT
option)
Perform the operation but inform the user of the violation
Trigger additional updates so the violation is corrected
(CASCADE option, SET NULL option)
Ritu Chaturvedi
Some figures adapted from Fundamentals of
database systems by Elmasri and Navathe and
62
ER-to-Relational Mapping :Step 1
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 primary key for R. If the chosen key of E
is composite, the set of simple attributes that
form it will together form the primary key of R.
Ritu Chaturvedi
Some figures adapted from Fundamentals of
database systems by Elmasri and Navathe and
63
ER-to-Relational Mapping :Step 2
 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 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.
Ritu Chaturvedi
Some figures adapted from Fundamentals of
database systems by Elmasri and Navathe and
64
ER-to-Relational Mapping :Step 3
 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 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.
Ritu Chaturvedi
Some figures adapted from Fundamentals of
database systems by Elmasri and Navathe and
65
ER-to-Relational Mapping :Step 4
 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; this is 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.
Ritu Chaturvedi
Some figures adapted from Fundamentals of
database systems by Elmasri and Navathe and
66
ER-to-Relational Mapping :Step 5
 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.
Ritu Chaturvedi
Some figures adapted from Fundamentals of
database systems by Elmasri and Navathe and
67
ER-to-Relational Mapping :Step 6
 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 an attribute.
The primary key of R is the combination of A
and K. If the multivalued attribute is
composite, we include its simple components
Ritu Chaturvedi
Some figures adapted from Fundamentals of
database systems by Elmasri and Navathe and
68
ER-to-Relational Mapping :Step
7(beyond the scope of 315(I 2008))
 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. 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 .This concludes the mapping
procedure.
Ritu Chaturvedi
Some figures adapted from Fundamentals of
database systems by Elmasri and Navathe and
69
Example : ER – to – Relational
1
PERSON
Parent_Chil
d
N
SIN
Ritu Chaturvedi
Some figures adapted from Fundamentals of
database systems by Elmasri and Navathe and
70
Example : Course and Section
Ritu Chaturvedi
Some figures adapted from Fundamentals of
database systems by Elmasri and Navathe and
71
Existence-Dependency Revisited
 Existence-dependency means that one
entity cannot exist independent of a related
entity. In database terms, existencedependency can be explained this way:


If an entity’s FK cannot contain nulls – that is,
the FK entry is mandatory -- the entity is
existence-dependent on the related entity.
If an entity’s FK can be null, then the entity is
existence-independent of the related entity.
Ritu Chaturvedi
Some figures adapted from Fundamentals of
database systems by Elmasri and Navathe and
72
Example :
 COURSE(CRS_CODE, CRS_DESCRIPTION, CRS_CREDIT)
 SECTION (CRS_CODE, SECTION#, YEAR, SEM,
CLASS_TIME, ROOM_CODE, PROF_NUM)
 SECTION cannot exist unless it has a FK CRS_CODE that
points to an existing COURSE row. But this condition means
that SECTION is existence-dependent on COURSE.
 Incidentally, in this example SECTION is also a weak ENTITY to
COURSE. That’s because a weak entity is defined as one that
inherits at least part of its PK from the (parent) COURSE entity
and it is existence-dependent on the (parent) COURSE entity.
(Note that there are two requirements that must be met before
an entity can be classified as weak).
Ritu Chaturvedi
Some figures adapted from Fundamentals of
database systems by Elmasri and Navathe and
73
Example (Contd).
 COURSE(CRS_CODE, CRS_DESCRIPTION, CRS_CREDIT)
 SECTION (CLASS_CODE, CRS_CODE, SECTION#, CLASS_TIME,
ROOM_CODE, PROF_NUM )
 CLASS_CODE is a surrogate key
 Let’s assume that the CRS_CODE FK in the SECTION is declared to
be “not null.”
 The SECTION entity is existence-dependent on COURSE. (That’s
because it is reasonable to assume that COURSE is mandatory to
SECTION, since a section does not appear in the class schedule
unless there is a course description for it in the course catalog. Note
that the "not null" FK requirement means that the CRS_CODE FK in
the CLASS entity is mandatory.)
 SECTION is not a weak entity (That’s because although the SECTION
is existence-dependent on COURSE -- the SECTION entity’s PK does
not contain the PK of the COURSE entity.)
Ritu Chaturvedi
Some figures adapted from Fundamentals of
database systems by Elmasri and Navathe and
74