2. The schema for database application displayed by
graphical notation . It mainly comprises :
• Entity and its attributes
• Relationship, which is association among entities
Ideas ER Design Relational Schema
Relational DBMS
Implementation
3. Entity types represent collection of entities that
have same attributes and are pictured by
rectangular nodes. Basically the relation name.
Weak – Entity
Types
4. A Relationship type R among entities types
defines a set of associations.
Relationship types associate entity types. They
are pictured by Diamond nodes.
5.
6.
7.
8.
9. • Create a new relation.
• Include the simple attributes
• Include the simple components of the composite
attributes
• Identify the primary keys. If the chosen key is
composite, the set of simple attributes that form
it will together form the primary key.
• Don’t include: non-simple components of
composite attributes, foreign keys, derived
attributes.
10.
11. • Create a new relation.
• Include simple attributes
• Add the owner’s primary key attributes, as
foreign key attributes
• Declare into a primary key the partial keys of the
weak entity type combined with those imported
from the owner
12.
13. There are Three possible approaches:
1) Foreign key approach
2) Merged relation option
3) Cross-reference or relationship relation
option
14. 1) Foreign Key approach
• Identify the relations S and T that correspond to
the entity types participating in R.
• Include as foreign keys, in the relation of one
entity type, the primary keys of the other entity
type
• The entity having total participation must have
the foreign key of the other entity.
• Include also the simple attributes of the
relationship type
15. DEPARTMENT has total participation. Therefore,
DEPARTMENT contains the foreign key, the
primary key of EMPLOYEE.
Example :
16.
17. 2) Merged relation option:
• Merge the two entity types and the relationship
into a single relation.
• This may be appropriate when both
participations are total.
18. 3)Cross-reference or relationship
relation option:
• Create a third relation R for the purpose of
cross-referencing the primary keys of the two
relations S and T representing the entity types.
19.
20. • Add as foreign keys, to the relation of the entity
type at the N side, the primary keys of the entity
type at the 1 side (don’t duplicate records!)
• Include also the simple attributes of the
relationship type
21.
22. • Create a new relation.
• Add as foreign keys the primary keys of the
participating entity types to the relationship
type(their combination will form the primary
key)
• Include the simple attributes of the relationship
type
23.
24. • Create a new relation
• Include the given attribute
• Include as foreign keys the primary attributes of
the entity/relationship type owning the
multivalued attribute.
• The primary key is combination of the attribute
as well as the foreign key.
• If the multivalued attribute is composite, we
include its simple components.
25. Example:
• The relation DEPT_LOCATIONS is created.
• 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 is the combination of
{DNUMBER,DLOCATION}.
26.
27. Includes all modeling concepts of basic ER
Additional concepts: subclasses/superclasses,
specialization/generalization, categories,
attribute inheritance
The resulting model is called the enhanced-
ER or Extended ER (E2R or EER) model
It is used to model applications more
completely and accurately if needed
It includes some object-oriented concepts,
such as inheritance
28. An entity type may have additional meaningful
subgroupings of its entities
Example: EMPLOYEE may be further grouped into
SECRETARY, ENGINEER, MANAGER, TECHNICIAN,
SALARIED_EMPLOYEE, HOURLY_EMPLOYEE
Each of these groupings is a subset of EMPLOYEE
entities
Each is called a subclass of EMPLOYEE
EMPLOYEE is the superclass for each of these
subclasses
These are called superclass/subclass relationships.
29. Example
An entity that is
member of a
subclass
represents the
same real-world
entity as some
member of the
superclass
30. An entity that is member of a subclass inherits
all attributes of the entity as a member of the
superclass
It also inherits all relationships
31. • Is the process of defining a set of subclasses of a
superclass
• May have several specializations of the same superclass
Example :
{SECRETARY, ENGINEER, TECHNICIAN} is a
specialization of EMPLOYEE based upon job type.
Another specialization of EMPLOYEE based in method of
pay is {SALARIED_EMPLOYEE, HOURLY_EMPLOYEE
• Attributes of a subclass are called specific attributes
32. The subset symbol
on each line
connecting a
subclass to the
circle indicates
direction of the
superclass/subclass
relationship.
Example of Specialization
33. The reverse of the specialization process
Several classes with common features are
generalized into a superclass; original classes
become its subclasses
Example: CAR, TRUCK generalized into
VEHICLE; both CAR, TRUCK become subclasses
of the superclass VEHICLE.
Both Specializations and Generalizations are shown in
rectangles in EER diagrams (as are entity types)
34. a) Predicate-defined - The subclass is defined
through a predicate on the attributes of the
superclass
Defining
predicate of
the Sub class
EMPLOYEE
d
Salaried
employee
Hourly_employee
Salary > 30000Hours<6
35. b) Attribute-defined - The subclasses in the
specialization are all defined by the same attribute
of the superclass
c) User-defined – Membership determined
during insertion
Defining
attribute of the
Super class
36. Disjoint (d)
The subclasses must have disjoint sets of entities
Overlap (o)
The subclasses may have overlapping sets of entities
Partial - An entity may not belong to any of the
subclasses. Represented by
Total - Every entity in the superclass must be a member
of some subclass. Represented by
Disjointness and completeness constraints are independent
38. Every subclass participates as a subclass in only one
class/subclass relationship
Single Inheritance
Results in a tree structure or strict hierarchy
PURCHASED
d
WHOLESALERETAIL
COOKIE
HOME-MADE
d
39. Subclass can be a subclass in more than one class/subclass
relationship
Multiple Inheritance
Also called Shared subclasses
In a lattice or
hierarchy, a
subclass inherits
attributes not
only of its direct
superclass, but
also of all its
predecessor
superclasses
40. Subclass related to a collection of superclasses
Each instance of subclass belongs to one, not
all of the superclasses
Superclasses form a union
Category can be total or partial
Subclass is called a category or UNION TYPE
Note: The difference from shared subclass is that the
member must exist in all of its superclasses).
43. To Convert each Specialization and Generalized Superclass into
a relational schema :
a. Multiple relations-Superclass and subclasses
b. Multiple relations-Subclass relations only
c. Single relation with one type attribute
d. Single relation with multiple type attributes
NOTATION :
Super class : C Primary Key : K Attributes : A(i)
Sub class : S
Relation : L
44.
45. a.Multiple relations-Superclass and
subclasses
Create a relation L for C with attributes
Attrs(L) = {K, A1, A2, …, An} and PK(L) = K.
Create a relation Li for each subclass Si, 1 < i < m,
with the attributes
ATTRS(Li) = {K} U {attributes of Si} and
PK(Li) = K.
This option works for any constraints: disjoint or
overlapping; total or partial.
46.
47. b. Multiple relations-Subclass relations
only
Create a relation Li for each subclass Si, 1 < i < m, with
ATTRS(Li) = {attributes of Si} U {K, A1, A 2, …, An }
PK(Li) = K
This option works well only for disjoint and total
constraints.
If the specialization is overlapping, the same entity may be
duplicated in several relations.
If not total, entity not belonging to any sub-class is lost.
49. c. Single relation with one type attribute
Create a single relation L with attributes Attrs(L) = {K,
A1, …, A n} U {attributes of S1} U… U {attributes of S
m} U {T} and PK(L)=K
This option is for specialization whose subclasses are
DISJOINT, and T is a type/discriminating attribute
that indicates the subclass to which each tuple belongs,
if any. This option may generate a large number of null
values.
Not recommended if many specific attributes are
defined in subclasses (will result in many null values!)
51. d. Single relation with multiple type
attributes
Create a single relation schema L with attributes
Attrs(L) = {K, A1, …, A n} U {attributes of S1} U…
U {attributes of Sm} U {T1, …, T n} and PK(L)=K
This option is for specialization whose subclasses
are overlapping, and each Ti, 1 < i < m, is a
Boolean attribute indicating whether a tuple
belongs to subclass Si.
53. Approach Pre-conditions Considerations Trade-off
A(Super and Sub
relations)
None Most flexible but
incurs a join cost
B(Sub relations) Specialization
must be total
Specialization
must be disjoint
In order to query
all entities of the
supertype one
must OUTER
UNION the
subtype relations
(and project to
Attr(C),
technically)
C (One relation,
one type)
Specialization
must be disjoint
If one table is
desirable
Potential for a
large NULL cost
D (One relation,
Multiple type)
None One table is
desired but
specialization is
overlapping
Also very flexible
but incurs a NULL
cost
54. All the Superclasses and the subclass must have
the same primary key. Otherwise model as a
Category
Apply any of the options discussed in
Generalization/Specialization mapping(former
topic)
55. For mapping a category whose defining superclass have
different keys, it is customary to specify a new key
attribute, called a surrogate key, when creating a relation
to correspond to the category.
Let C₁,C₂,…,Cm be the entity types participating in the
union and S be the union type. Create a relation for S and
surrogate key ks so that PK(S)=ks, and also add ks to
each Attr(Ci) as a foreign key into S. If all the Cis have the
same primary key type, use that as PK(S) instead.
