This document discusses advanced data modeling techniques in database system design. It covers the extended entity relationship model, entity supertypes and subtypes, specialization hierarchies, subtype discriminators, entity clusters, primary keys, surrogate keys, and several design cases including 1:1 relationships, maintaining history, fan traps, and redundant relationships. The goal is to learn how to represent complex relationships between entities and handle special data modeling scenarios.

1. Databased System
Design, Implementation Management

2. V.
ADVANCED DATA
MODELING

3. •About the extended entity Relationship (EER) Model
•How entity Clusters are useto represents multiple entities and Relationship.
•The Characteristic of Good Primary keys and how to select them.
•How to use flexible solutions for special data modeling-cases.
In this chapter, You will learn :
Learning Objectives

4. Extended Entity Relationship Model
(EERM)
• Result of adding more semantic construct to the original entity
Relationship (ER)model
• EER diagram (EERD): Uses the EER Model

5. Entity Supertypes and Subtypes
• Entity Supertypes - Generic Entity Type relater to one more entity
Subtype.
*Contains Common Characterisctic
• Entity Subtypes - Contains unique characteristics of each entity
subtype.

6. Entity Supertypes and Subtypes
*Criteria to determine the usage :
•There must be different, Identifiable kinds of the entity in the users
environment.
•The different kinds of instance Should each have one or more attributes
that are unique to that kinds of instance.

7. Specialization Hierarchy
• Depicts arrangement of higher-level entity supertypes and lower-level entity subtypes.
• Relationships sometimes described in terms of “IS-A” relationships
• Subtype can exist only within context of supertype
• Subtype can have only one supertype to which it is directly related.
• Supertypes can have many subtypes.

8. Specialization Hierarchy
• Support attribute inheritance.
Provides the means to :
• Define special supertype attribute known as subtype discriminator
• Define disjoint/overlapping constraints and complete/partial constraints.

9. FIGURE 5.2 - Specialization Hierarchy

10. • Enables entity subtype to inherit attributes and relationships of supertype
• All entity subtypes inherit their primary key attribute from their supertype
• At implementation level, supertype and its subtype(s) depicted in specialization hierarchy
maintain a 1:1 relationship
• Entity subtype enherit all relationships in which supertype entity Participate.
INHERITANCE

11. Subtype Descriminator
• The attribute in supertype entity that determines to which entity subtype each supertype
occurrence is related
• The default comparison condition for subtype discriminator attribute is equality
comparison

12. Disjoint and Overlapping Constraints
• Disjoint Subtypes : contain unique subset of supertype entity set
*known as non-overlapping subtypes
*Implementation based onthe value of the subtypes.
• Overlapping subtypes : contain nonunique subsets of supertype entity set
* Implementation Requires to attribute for each subtypes.

13. FIGURE 5.4-Specialization hierarchy with overlapping Subtypes

14. Table 5.1 - Discriminator attributes with overlapping subtypes

15. Completeness Constraint
• Specifies whether each entity supertype occurrence must also be member of at least
one subtype
• Types :
* Partial completeness : Not every supertype occurence is a member of subtypes
* Total completeness : Every Supertype occurence must be a member of atleast one subtype.

16. Table 5.2 - Specialization hierarchy Constraint Scenarios

17. Specialization and Generalization
* Top-down process
* Identifying lower-level, more
specific entity subtypes from higher-
level entity supertype
* Based on grouping unique
characteristics and relationships of
the subtypes
* Bottom-up process
* Identifying higher-level, more
generic entity supertype from lower-
level entity subtypes
* Based on grouping common
characteristics and relationships of
the subtypes
Specialization Generalization

18. Entity Cluster
• "Virtual” entity type used to represent multiple entities and relationships in ERD
• Avoid the display of attributes to eliminates complication that result when the
inheritance rules changed.

19. FIGURE 5.5- Tiny College ERD using Entity clusters.

20. Primary Keys
• Single attribute or combination attributes, which uniquely identifies each entity
instance.
* Guarantees entity integrity.
* Works with foreign keys to implement relationship.

21. Natural Keys or Natural identifier
• Real World Identifier use to uniquely identify Real world objects.
* Familiar to end users and forms part of their day-to-day business vocabulary.
* Also Known as Natural identifier.
* Use as the Primary key of the entity Being modeled.

22. Non intellegent
No change Overtime
Preferably Single Attribute
Preferably Numeric
Security complaint
Desirable Primary Key Characteristics

23. Use of Composite Primary Key
• Useful as identifiers of composite entities,
* Each primary key combination is allowed only once in M:N relationship
• Identifiers of weak entities,
* Weak entity has strong identifying relationship with parent entity

24. Use of Composite Primary Key
• When used as idetifiers of weak entities, Represent the real world object That is:
* Existent dependent on another real-world object
* Represented in data model as two separate entities in strong identifying
relationship

25. FIGURE 5.6- The M:N Relationships Between STUDENTS and CLASS

26. Surrogate Keys
• Primary Key used to simplify the identification of entity instances useful when:
* there is No natural key
* Selected candidate key has embedded semantic contents or is too long.
• Requires ensuring that the candidate key of entity in questions perform properly.
* use of “unique index” and “not null” constraints

27. Table 5.4 - Data Use to Keep track of Events

28. Design Case 1: Implementing 1:1 Relationships
• Foreign keys work with primary keys to properly implement relationships in relational model
RULES:
* Put primary key of the “one” side on the “many” side as foreign key
• Option for selecting and placing of foreign key:
* Place a foreign key in both entities.
* Place a foreign key in one of the entities.

29. Table 5.5 - Selection of foreign Key in 1:1 Relationships

30. Figure 5.7- The 1:1 Relationships Between Department and
Employee

31. Design Case 2: Maintaining History of Time-
Variant Data
• Time Variant Data: data whose values change over time and for which you must keep a history
of data changes must be retained
* Requires Creating a new entity in 1:M relationship with the original entity.
* New Entity contains the new value, Date of the change,and other pertinent attribute.

32. Figure 5.8- Maintaining Salary History

33. Figure 5.9- Maintaining Manager History

34. Figure 5.10- Maintaining job history

35. Design Case 3: Fan Traps
• Design trap : occurs when relationship is improperly or incompletely identified
* Represented in a way not consistent in a real world.
• Fan Trap : occurs when having one entity in two 1:M relationships to other entities
* Produced an association among other entities not expressed in the model.

36. Figure 5.11- Incorrect ERD with Fan trap Problem

37. Figure 5.12- Corrected ERD after removal of the Fan Trap

38. Design Case 4: Redundant Relationships
• Occur when there are multiple relationship paths between related entities
• Need to remain consistent accross the model
• Help Simplify design.

39. Figure 5.13- A Redundant relationship

40. THANKYOUUUU
D
a
t
a
B
a
s
e
S
y
s
t
e
m
D
e
s
i
g
n
,
I
m
p
l
e
m
e
n
t
a
t
i
o
n
m
a
n
a
g
e
m
e
n
t
ADVANCED DATA
MODELING