Data Modeling - Enhanced ER diagrams & Mapping.pdf

Data Modeling
(Part – 2)
Christalin Nelson | Systems Cluster | SOCS
2/27/2024 2

At a Glance
• Subclasses and Superclasses
• Specialization and Generalization in EER
 Constraints on Specialization and Generalization
 Specialization and Generalization Hierarchies and Lattices
 Modeling of UNION Types Using Categories
 Data Abstraction, Knowledge Representation, and Ontology Concepts
 Relational DB design using ER-to-Relational Mapping
2/27/2024
3 of 48

Enhanced Entity-Relationship (EER) Model (1/2)
• Created to design more accurate database schemas
– Reflect the data properties and constraints more precisely
• More complex requirements than traditional applications
– Suitable for CAD/CAM, Telecommunication, GIS
• EER diagrams
– Diagrammatic technique for displaying the concepts in an EER schema
• Includes all modeling concepts of ER model
2/27/2024
4 of 48

Enhanced Entity-Relationship (EER) Model (2/2)
• Includes
– Subtypes and Supertype
– Specialization and Generalization
• Similar to subtypes and supertypes, but allows for more flexibility in modeling inheritance
relationships between entities
– Attribute and relationship inheritance
• Allows attributes to be inherited from supertype entities to subtype entities, reducing
redundancy and improving data consistency
– Aggregation
• Allows relationships between entities to be treated as higher-level abstractions, representing
collections or assemblies of related entities
– Category and Union type
• Enables entities to belong to multiple categories or types simultaneously
– Used to represent a collection of objects. i.e. Union of entities of different entity types
– Constraints and Assertions
• Enables the specification of additional rules or conditions that must be satisfied by the data,
ensuring data integrity and consistency
2/27/2024
5 of 48

Subtypes and Supertype (1/2)
• Entities can be organized into hierarchies, where a supertype entity (superclass)
can have one or more subtypes (subclasses) with specialized/specific attributes or
relationships
• Example
– Entities that are members of the EMPLOYEE entity type may be distinguished further
into SECRETARY, ENGINEER, MANAGER, TECHNICIAN, SALARIED_EMPLOYEE, and so on
• Subclass or Subtype: Subgroups of the EMPLOYEE entity type like MANAGER
• Superclass or Supertype: EMPLOYEE entity type
2/27/2024
6 of 48

Subtypes and Supertype (2/2)
• Class/Subclass relationship
– Relationship between the Superclass and a Subclass
• Example: EMPLOYEE/SECRETARY and EMPLOYEE/TECHNICIAN
– Also called as Superclass/subclass (or) Supertype/subtype relationship
– It is called an IS-A (or) IS-AN relationship because of the way it is referred
• Example: a SECRETARY is an EMPLOYEE, a TECHNICIAN is an EMPLOYEE
• Type inheritance
– Subclass entity inherits all attributes and relationships of Superclass
2/27/2024
7 of 48

Specialization (1/5)
• Specialization
– Process of defining one subclass or a set of subclasses of an entity type
– Defined based on some distinguishing characteristic (specific role) of the entities in the
superclass
• Example: The following are the specializations of Superclass EMPLOYEE
– {SECRETARY, ENGINEER, TECHNICIAN} specialization based on Job type
– {SALARIED_EMPLOYEE, HOURLY_EMPLOYEE} specialization based on Method of pay
– Notation used
• Subclasses that define a specialization are attached by lines to a specialization circle that
represents the specialization, which is connected in turn to the superclass
• If a specialization consists of a single subclass only, do not use specialization circle notation
– Example: {MANAGER} specialization
• The direction of the superclass/subclass relationship is indicated with a Subset symbol on
each line connecting a subclass to the circle
2/27/2024
8 of 48

9 of 48
2/27/2024

• Subclass can define
– Specific/local attributes: Attributes that apply only to entities of a particular subclass
• Notation: They are attached to the rectangle representing that subclass
• Example: TypingSpeed attribute of SECRETARY
– Specific relationship types
• Example: HOURLY_EMPLOYEE subclass participates in the BELONGS_TO relationship
• Instances of a Specialization
– An entity that belongs to a subclass represents the same real-world entity as the
entity connected to it in the EMPLOYEE superclass, even though the same entity is
shown twice
• Example: an EMPLOYEE specialized in the role of SECRETARY
2/27/2024
10 of 48

11 of 48
2/27/2024

• Reason for including class/subclass relationships & specializations in a data model
1) Define a set of Subtypes of a Supertype
2) Certain attributes may apply to some but not all entities of the superclass
• Example: SECRETARY subclass has a specific attribute ‘Typing_speed’, ENGINEER subclass
has a specific attribute ‘Eng_type’, SECRETARY & ENGINEER share their other inherited
attributes from the EMPLOYEE entity type
3) Only those entities which are members of the subclass can participate in some
relationship types with another entity type
• Example: HOURLY_EMPLOYEE has a specific relationship with TRADE_UNION through
‘BELONGS_TO’ relationship type
2/27/2024
12 of 48

Generalization (1/2)
• Reverse process of abstraction
• Suppress the differences between Entity types
– i.e. Identify common features of Subtypes and generalize them into a single Supertype
• Process of defining a generalized entity type from the given entity types
– Here, the generalized entity type becomes a Supertype & the given entity types
become subtypes
• Note: One notation to differentiate Generalization from Specialization
– The arrow pointing to the generalized superclass represents a generalization
– The arrow pointing to the specialized subclasses represents a specialization
2/27/2024
13 of 48

14 of 48
2/27/2024

Constraints on Generalization & Specialization (1/6)
• Determine entity subtype
– Predicate-defined (or condition-defined) subclasses
• No. of subclasses?
• Define a condition on an attribute of a superclass to determine the entities that can be
members of each subclass
• Example: Specify membership condition (Job_type = ‘Secretary’) in the SECRETARY subclass
• Notation: Write predicate condition next to the line that connects subclass to specialization
circle
– Attribute-defined specialization
• All subclasses in a specialization have their membership condition on the same attribute (called
Defining attribute of specialization or discriminator in UML) of the superclass
• Notation: Place the defining attribute name next to line which connects the circle to superclass
– User-defined subclass
• Membership to a subclass is specified individually for each entity by the user & not by any
condition that may be evaluated automatically
2/27/2024
15 of 48

16 of 48
2/27/2024

• Disjointness or Disjointedness constraint
– An entity can be a member of at most one of the subclasses of the specialization
• i.e. Subclasses of the specialization must be disjoint
– An attribute-defined specialization is implied to be a disjointedness constraint if the
defining attribute used to define the membership predicate is single-valued
– Notation: Place the letter ‘d’ in the specialization circle
• This also applies to user-defined subclasses of a specialization that must be disjoint
– Example: The specialization {HOURLY_EMPLOYEE, SALARIED_EMPLOYEE}
– Nondisjointness?
• An entity can be a member of >1 subclass of the specialization
– i.e. Subclasses of the specialization are nondisjoint (their sets of entities may be overlapping)
• Default case
• Notation: Place the letter ‘o’ in the specialization circle
2/27/2024
17 of 48

18 of 48
2/27/2024

• Completeness or Totalness constraint
– Types: Total, Partial
– Total specialization constraint
• Every entity in superclass must be a member of at least one subclass in the specialization
• Example: If every EMPLOYEE must be either an HOURLY_EMPLOYEE or a
SALARIED_EMPLOYEE, then the specialization {HOURLY_EMPLOYEE, SALARIED_EMPLOYEE}
is a total specialization of EMPLOYEE
– Partial specialization constraint
• Allows an entity not to belong to any of the subclasses in the specialization
• Example: If some EMPLOYEE entities do not belong to any subclasses of the specialization
{SECRETARY, ENGINEER, TECHNICIAN}, this is a partial specialization of EMPLOYEE
– Notation:
• Total/Partial: Double/Single line connects the superclass to the specialization circle
Total & Partial Participation??
2/27/2024
19 of 48

• Disjointness constraints and completeness constraints are independent. Hence,
four combinations of constraints can be obtained
– Disjoint, total
– Disjoint, partial
– Overlapping, total
– Overlapping, partial
2/27/2024
20 of 48

Specialization & Generalization Hierarchies and Lattices (1/3)
• Specialization hierarchy (Single Inheritance)
– A subclass with only one superclass (or) only one class/subclass relationship
• i.e. Every subclass has only one superclass => Results in a tree structure or strict hierarchy
– Some models do not allow an entity to have multiple types, and hence an entity can
be a member of only one leaf class
• Specialization lattice (Multiple Inheritance)
– Shared subclass: A subclass with >1 superclass (or) >1 class/subclass relationship
– The attribute/relationship originating in the same superclass which could be inherited
more than once via different paths in lattice is included only once in shared subclass
• Note:
– The above concepts apply equally to generalization
2/27/2024
21 of 48

Specialization & Generalization Hierarchies and Lattices (2/3)
2/27/2024
22 of 48

23 of 48
2/27/2024
In the overlapping specialization
of PERSON into {EMPLOYEE,
ALUMNUS, STUDENT}, how
many subclasses of PERSON
should be created to cover all
possible types of entities?
Considering E as EMPLOYEE, A as
ALUMNUS, and S as STUDENT
there are 7 subclasses of
PERSON created. Namely, E, A, S,
E_A, E_S, A_S, and E_A_S

Utilizing Specialization and Generalization in Refining
Conceptual Schemas
• Specialization process
– Start with entity type
– Define subclasses by Top-down conceptual refinement process (Successive
specialization)
• Bottom-up conceptual synthesis
– Involves generalization rather than specialization
• Note:
– In practice, it is likely that neither the generalization process nor the specialization
process is followed strictly, but that a combination of the two processes is employed
2/27/2024
24 of 48

Modeling of UNION Types Using Categories (1/3)
• Union type or Category
– Represents a single superclass/subclass relationship with >1 superclass
– A subclass that represents collection of objects (i.e. subset of UNION of distinct entity
types)
– Category can be total or partial
• Total: A category that holds the union of all the entities from its superclasses
– A total category can be represented alternatively as total specialization/generalization in EER
» Note: If the two classes represent the same type of entities and share numerous attributes,
including the same key attributes, specialization/generalization is preferred
• Partial: A category that holds a subset of the union all the entities from its superclasses
• Some modeling methodologies do not have union types
2/27/2024
25 of 48

26 of 48
2/27/2024
Entity in OWNER should
be in only one of the
superclasses: PERSON,
BANK, OR COMPANY
i.e. Union of superclasses
Entities in
ENGINEERING_MANAGER
should be in all the superclasses:
ENGINEER, MANAGER, AND
SALARIED_EMPLOYEE
i.e. Intersection of Superclasses
Specialization
vs. Union

27 of 48
2/27/2024
Attribute inheritance
works more selectively
Subclass inherits all the
attributes of its Superclasses
Specialization
vs. Union
There could be some
entities in CAR & TRUCK
which are not in
REGISTERED_VEHICLE
All the entities in CAR & TRUCK
are in VEHICLE
Superclass can have
different key attributes

Design Choices for Specialization/Generalization
• Conceptual DB design is an iterative process to refine until best design is achieved
• Guidelines
– Limit specialization to essential subclasses to prevent clutter in the conceptual schema
– Merge the subclass with few local attributes and no specific relationships into the
superclass. Use NULL for non-members' specific attributes, type attribute indicates
membership.
– If all subclasses lack (or have fewer) specific attributes or relationships, they can be
combined into the superclass using type attributes to indicate each entity's subclass.
– Avoid union types and categories unless necessary, which is rare in practice
– The choice of disjoint/overlapping and total/partial constraints on specialization/
generalization depends on the modeled rules. Default is overlapping/partial if no
constraints are specified, allowing flexible subclass membership.
2/27/2024
28 of 48

2/27/2024
Data Abstraction, KR, and Ontology Concepts (1/5)
• Ontology
– Similar to a conceptual schema, but with more knowledge, rules, and exceptions
• Knowledge Representation (KR)
– Works with AI
– Develop concepts for accurately modeling some domains of knowledge by creating an
ontology
• Similarities of KR with Semantic Models (E.g. EER)
– Both use an abstraction process to identify common properties and important aspects
of objects
– Both provide concepts, relationships, constraints, operations, and languages for
defining data and representing knowledge
29 of 48

2/27/2024
• KR vs. Semantic Models (E.g. EER)
– KR uses different forms of knowledge
• Rules (used in inference, deduction, and search), Incomplete and Default knowledge,
Temporal and Spatial knowledge
– KR includes reasoning mechanisms that deduce additional facts from the facts stored
in a database
– KR allows multiple classification schemes in which one class is an instance of another
class (called a meta-class)
– Implementation of KR schemes is less efficient (vs. DBs) when a large amount of data
(facts) needs to be stored
30 of 48

2/27/2024
• Abstraction concepts used in semantic data models (EER model & KR schemes)
– Classification and instantiation
• Classification: Consider a collection of objects that share the same types of attributes,
relationships, and constraints as a Class
• Instantiation: Distinct objects of the class with IS-AN-INSTANCE-OF or IS-A-MEMBER-OF
relationship with the class
– Exception objects & Class properties (certain features applied on a class and not the object) –
Allowed with KR & UML
– Identification
• Uniquely identify classes and objects with identifiers
– Specialization and Generalization (IS-A relationship)
– Aggregation and Association
31 of 48

2/27/2024
• Aggregation
– Composition
• Building aggregate/composite/molecular objects from their component/primitive objects
with IS-A-PART-OF or IS-A-COMPONENT-OF relationship
• Deleting the aggregate object amounts to deleting all its component objects
• Example: A car contains an engine, wheels, and seats
– Association
• Associate objects from several independent classes with IS-ASSOCIATED-WITH relationship
• When an association instance is deleted, the participating objects may continue to exist
• Example: A university has professors and students. Professors teach courses, and students
enroll in courses
32 of 48

2/27/2024
• Example: Aggregation in ER diagram
33 of 48

2/27/2024
Relational DB design using ER-to-Relational Mapping (1/13)
34 of 48

2/27/2024
• Step-1: Mapping of Regular (Strong) Entity Types
– For each Strong Entity type
• Create relation & include only simple attributes (applicable for composite attributes also)
• Choose one of the key attributes as Primary key
– The chosen key can be a composite
– If multiple keys were identified during the conceptual design, the information describing the
attributes that form each additional key is kept
» i.e. To specify secondary (unique) keys, for indexing purposes and other types of analyses
35 of 48

2/27/2024
• Step-2: Mapping of Weak Entity Types
– For each weak entity type W in the ER schema with owner entity type E
• Create a relation R
• Include all simple attributes (applicable for composite also)
• The primary key attribute(s) of the relation(s) that correspond to the owner entity type(s)
are included as foreign key attributes of R, for mapping 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 W (if any)
– If there is a weak entity type E2 whose owner is also a weak entity type E1, then E1
should be mapped before E2 to determine its primary key first
36 of 48

2/27/2024
• Step-3: Mapping of Binary 1:1 Relationship Types
– Approaches
• (1) Foreign key approach (when one relation has total participation in a 1:1 relationship)
– Choose one of the relations (say S) with total participation. The other relation is T.
– Migrate all simple attributes (applicable for composites also) of 1:1 relationship type as attributes of S
– The primary key of T becomes the foreign key in S
• (2) Merged relationship approach (If both relations have total participation in 1:1 relationship)
– Merge the two relations and the relationship into a single relation
• (3) Cross-reference or relationship relation approach (When few relationship instances exist, to
avoid NULL values in foreign keys)
– Create a new relationship relation R (also called look-up table) for the participating Entity types S and
T of the 1:1 relationship type
» A tuple in R represents a relationship instance that relates one tuple from S with one tuple from T
» Primary key attributes of S and T become foreign keys in R referencing S and T
» Primary key of R will be one of two foreign keys. The other foreign key will be a unique key of R
37 of 48

2/27/2024
• Step-4: Mapping of Binary 1:N Relationship Types
– For each regular binary 1:N relationship type
• Identify relation S (N-side) and T (1-side)
• The Primary key of T becomes the foreign key in S
• Migrate any simple attributes (applicable to composite attributes also) of 1:N relationship
type as attributes of S
• Step-5: Mapping of Binary M:N Relationship Types
– For each binary M:N relationship type R
• Create a new relation S to represent R. S is called relationship relation or look-up table
• The primary keys of the participating relations become foreign key attributes in S & their
combination will form the primary key of S
• Migrate any simple attributes (applicable to composite attributes also) of M:N relationship
38 of 48

2/27/2024
• Step-6: Mapping of multivalued attributes
– For each multivalued attribute A
• Create a new relation R
• Include an attribute corresponding to A
• Primary key attribute K of the relation that represents the entity type or relationship type
that has A as a multivalued attribute, becomes the foreign key in R
• The primary key of R is the combination of A and K
• If the multivalued attribute is composite, we include its simple components
39 of 48

2/27/2024
• Step-7: Mapping of n-ary Relationship Types
– For each n-ary relationship type, where n > 2
• Create a new relation S to represent n-ary relationship type
• The primary keys of the participating relations become the foreign key attributes in S
• Primary key of S is a combination of all foreign keys that reference participating relations
– Note: If the cardinality constraint of any participating relation is 1, then the primary key of S
should not include the foreign key attribute that references this relation
• Migrate any simple attributes (applicable to composite attributes also) of n-ary relationship
40 of 48

2/27/2024
41 of 48

2/27/2024
• Step-8: Mapping of Specialization or Generalization (1/5)
– Option 8A: Multiple relations – superclass and subclasses
42 of 48

2/27/2024
– Option 8B: Multiple relations – subclass relations only
43 of 48

2/27/2024
– Option 8C: Single relation with one type attribute
44 of 48

2/27/2024
– Option 8D: Single relation with multiple type attributes
45 of 48

2/27/2024
– Hybrid
– Mapping of Shared Subclasses (Multiple Inheritance)
• A shared subclass is a subclass of several superclasses
• The superclasses must all have the same key attribute
• Apply any of the options discussed in Step-8
• Step-9: Mapping of Categories (Union Types)
– A category (or union type) is a subclass of the union of two or more defining
superclasses
– The superclasses have different keys
• Specify a new key attribute (called a surrogate key) when creating a relation to correspond
to the category
46 of 48

2/27/2024
• Step-9 (contd.)
47 of 48

2/27/2024 48

Data Modeling - Enhanced ER diagrams & Mapping.pdf

More Related Content

What's hot (20)

Similar to Data Modeling - Enhanced ER diagrams & Mapping.pdf (20)

More from Christalin Nelson (15)

Recently uploaded (20)

Data Modeling - Enhanced ER diagrams & Mapping.pdf