SlideShare a Scribd company logo
1 of 48
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
Christalin Nelson | Systems Cluster | SOCS
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
Christalin Nelson | Systems Cluster | SOCS
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
Christalin Nelson | Systems Cluster | SOCS
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
Christalin Nelson | Systems Cluster | SOCS
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
Christalin Nelson | Systems Cluster | SOCS
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
Christalin Nelson | Systems Cluster | SOCS
2/27/2024
8 of 48
9 of 48
Christalin Nelson | Systems Cluster | SOCS
2/27/2024
Specialization (3/5)
• 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
Christalin Nelson | Systems Cluster | SOCS
2/27/2024
10 of 48
11 of 48
Christalin Nelson | Systems Cluster | SOCS
2/27/2024
Specialization (5/5)
• 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
Christalin Nelson | Systems Cluster | SOCS
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
Christalin Nelson | Systems Cluster | SOCS
2/27/2024
13 of 48
14 of 48
Christalin Nelson | Systems Cluster | SOCS
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
Christalin Nelson | Systems Cluster | SOCS
2/27/2024
15 of 48
16 of 48
Christalin Nelson | Systems Cluster | SOCS
2/27/2024
Constraints on Generalization & Specialization (3/6)
• 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
Christalin Nelson | Systems Cluster | SOCS
2/27/2024
17 of 48
18 of 48
Christalin Nelson | Systems Cluster | SOCS
2/27/2024
Constraints on Generalization & Specialization (5/6)
• 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??
Christalin Nelson | Systems Cluster | SOCS
2/27/2024
19 of 48
Constraints on Generalization & Specialization (6/6)
• Disjointness constraints and completeness constraints are independent. Hence,
four combinations of constraints can be obtained
– Disjoint, total
– Disjoint, partial
– Overlapping, total
– Overlapping, partial
Christalin Nelson | Systems Cluster | SOCS
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
Christalin Nelson | Systems Cluster | SOCS
2/27/2024
21 of 48
Specialization & Generalization Hierarchies and Lattices (2/3)
Christalin Nelson | Systems Cluster | SOCS
2/27/2024
22 of 48
23 of 48
Christalin Nelson | Systems Cluster | SOCS
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
Christalin Nelson | Systems Cluster | SOCS
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
Christalin Nelson | Systems Cluster | SOCS
2/27/2024
25 of 48
26 of 48
Christalin Nelson | Systems Cluster | SOCS
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
Christalin Nelson | Systems Cluster | SOCS
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.
Christalin Nelson | Systems Cluster | SOCS
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
Christalin Nelson | Systems Cluster | SOCS
29 of 48
2/27/2024
Data Abstraction, KR, and Ontology Concepts (2/5)
• 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
Christalin Nelson | Systems Cluster | SOCS
30 of 48
2/27/2024
Data Abstraction, KR, and Ontology Concepts (3/5)
• 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
Christalin Nelson | Systems Cluster | SOCS
31 of 48
2/27/2024
Data Abstraction, KR, and Ontology Concepts (4/5)
• 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
Christalin Nelson | Systems Cluster | SOCS
32 of 48
2/27/2024
Data Abstraction, KR, and Ontology Concepts (5/5)
• Example: Aggregation in ER diagram
Christalin Nelson | Systems Cluster | SOCS
33 of 48
2/27/2024
Relational DB design using ER-to-Relational Mapping (1/13)
Christalin Nelson | Systems Cluster | SOCS
34 of 48
2/27/2024
Relational DB design using ER-to-Relational Mapping (2/13)
• 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
Christalin Nelson | Systems Cluster | SOCS
35 of 48
2/27/2024
Relational DB design using ER-to-Relational Mapping (2/13)
• 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
Christalin Nelson | Systems Cluster | SOCS
36 of 48
2/27/2024
Relational DB design using ER-to-Relational Mapping (3/13)
• 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
Christalin Nelson | Systems Cluster | SOCS
37 of 48
2/27/2024
Relational DB design using ER-to-Relational Mapping (4/13)
• 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
type as attributes of S
Christalin Nelson | Systems Cluster | SOCS
38 of 48
2/27/2024
Relational DB design using ER-to-Relational Mapping (5/13)
• 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
Christalin Nelson | Systems Cluster | SOCS
39 of 48
2/27/2024
Relational DB design using ER-to-Relational Mapping (6/13)
• 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
type as attributes of S
Christalin Nelson | Systems Cluster | SOCS
40 of 48
2/27/2024
Relational DB design using ER-to-Relational Mapping (7/13)
Christalin Nelson | Systems Cluster | SOCS
41 of 48
2/27/2024
Relational DB design using ER-to-Relational Mapping (8/13)
• Step-8: Mapping of Specialization or Generalization (1/5)
– Option 8A: Multiple relations – superclass and subclasses
Christalin Nelson | Systems Cluster | SOCS
42 of 48
2/27/2024
Relational DB design using ER-to-Relational Mapping (9/13)
• Step-8: Mapping of Specialization or Generalization (2/5)
– Option 8B: Multiple relations – subclass relations only
Christalin Nelson | Systems Cluster | SOCS
43 of 48
2/27/2024
Relational DB design using ER-to-Relational Mapping (10/13)
• Step-8: Mapping of Specialization or Generalization (3/5)
– Option 8C: Single relation with one type attribute
Christalin Nelson | Systems Cluster | SOCS
44 of 48
2/27/2024
Relational DB design using ER-to-Relational Mapping (11/13)
• Step-8: Mapping of Specialization or Generalization (4/5)
– Option 8D: Single relation with multiple type attributes
Christalin Nelson | Systems Cluster | SOCS
45 of 48
2/27/2024
Relational DB design using ER-to-Relational Mapping (12/13)
• Step-8: Mapping of Specialization or Generalization (5/5)
– 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
Christalin Nelson | Systems Cluster | SOCS
46 of 48
2/27/2024
Relational DB design using ER-to-Relational Mapping (13/13)
• Step-9 (contd.)
Christalin Nelson | Systems Cluster | SOCS
47 of 48
Christalin Nelson | Systems Cluster | SOCS
2/27/2024 48

More Related Content

What's hot

What's hot (20)

Indexing Structures in Database Management system.pdf
Indexing Structures in Database Management system.pdfIndexing Structures in Database Management system.pdf
Indexing Structures in Database Management system.pdf
 
Sql commands
Sql commandsSql commands
Sql commands
 
Database overview
Database overviewDatabase overview
Database overview
 
Storage system architecture
Storage system architectureStorage system architecture
Storage system architecture
 
Oracle statistics by example
Oracle statistics by exampleOracle statistics by example
Oracle statistics by example
 
SKILLWISE-DB2 DBA
SKILLWISE-DB2 DBASKILLWISE-DB2 DBA
SKILLWISE-DB2 DBA
 
Ibm db2
Ibm db2Ibm db2
Ibm db2
 
My First 100 days with an Exadata (PPT)
My First 100 days with an Exadata (PPT)My First 100 days with an Exadata (PPT)
My First 100 days with an Exadata (PPT)
 
RMAN in 12c: The Next Generation (PPT)
RMAN in 12c: The Next Generation (PPT)RMAN in 12c: The Next Generation (PPT)
RMAN in 12c: The Next Generation (PPT)
 
Mysql database
Mysql databaseMysql database
Mysql database
 
Oracle Database Performance Tuning Advanced Features and Best Practices for DBAs
Oracle Database Performance Tuning Advanced Features and Best Practices for DBAsOracle Database Performance Tuning Advanced Features and Best Practices for DBAs
Oracle Database Performance Tuning Advanced Features and Best Practices for DBAs
 
DB2 DOCUMENT
DB2 DOCUMENTDB2 DOCUMENT
DB2 DOCUMENT
 
Best Practices For Optimizing DB2 Performance Final
Best Practices For Optimizing DB2 Performance FinalBest Practices For Optimizing DB2 Performance Final
Best Practices For Optimizing DB2 Performance Final
 
Skillwise JCL
Skillwise JCLSkillwise JCL
Skillwise JCL
 
Db2 and storage management (mullins)
Db2 and storage management (mullins)Db2 and storage management (mullins)
Db2 and storage management (mullins)
 
SQL-Server Database.pdf
SQL-Server Database.pdfSQL-Server Database.pdf
SQL-Server Database.pdf
 
Chasing the optimizer
Chasing the optimizerChasing the optimizer
Chasing the optimizer
 
Conhecendo Apache Cassandra @Movile
Conhecendo Apache Cassandra  @MovileConhecendo Apache Cassandra  @Movile
Conhecendo Apache Cassandra @Movile
 
Awr + 12c performance tuning
Awr + 12c performance tuningAwr + 12c performance tuning
Awr + 12c performance tuning
 
SQL Monitoring in Oracle Database 12c
SQL Monitoring in Oracle Database 12cSQL Monitoring in Oracle Database 12c
SQL Monitoring in Oracle Database 12c
 

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

8 oo approach&uml-23_feb
8 oo approach&uml-23_feb8 oo approach&uml-23_feb
8 oo approach&uml-23_feb
Raj Shah
 
27f157al5enhanceder diagram-111005002740-phpapp02
27f157al5enhanceder diagram-111005002740-phpapp0227f157al5enhanceder diagram-111005002740-phpapp02
27f157al5enhanceder diagram-111005002740-phpapp02
marangburu42
 
Enhanced E-R diagram
Enhanced E-R diagramEnhanced E-R diagram
Enhanced E-R diagram
Mayank Jain
 
Lecture#01, object orientation
Lecture#01, object orientationLecture#01, object orientation
Lecture#01, object orientation
babak danyal
 
lkjhlkjhjhkjhlkjhkjhkjhkjhkjhkjhjhkjh.ppt
lkjhlkjhjhkjhlkjhkjhkjhkjhkjhkjhjhkjh.pptlkjhlkjhjhkjhlkjhkjhkjhkjhkjhkjhjhkjh.ppt
lkjhlkjhjhkjhlkjhkjhkjhkjhkjhkjhjhkjh.ppt
EliasPetros
 

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

3_EERD.pdf
3_EERD.pdf3_EERD.pdf
3_EERD.pdf
 
EER modeling
EER modelingEER modeling
EER modeling
 
Uml package diagram
Uml package  diagramUml package  diagram
Uml package diagram
 
8 oo approach&uml-23_feb
8 oo approach&uml-23_feb8 oo approach&uml-23_feb
8 oo approach&uml-23_feb
 
SysCon 2013 SysML & Requirements
SysCon 2013 SysML & RequirementsSysCon 2013 SysML & Requirements
SysCon 2013 SysML & Requirements
 
CS8592-OOAD Lecture Notes Unit-2
CS8592-OOAD Lecture Notes Unit-2CS8592-OOAD Lecture Notes Unit-2
CS8592-OOAD Lecture Notes Unit-2
 
27f157al5enhanceder diagram-111005002740-phpapp02
27f157al5enhanceder diagram-111005002740-phpapp0227f157al5enhanceder diagram-111005002740-phpapp02
27f157al5enhanceder diagram-111005002740-phpapp02
 
Enhanced E-R diagram
Enhanced E-R diagramEnhanced E-R diagram
Enhanced E-R diagram
 
Software Testing and UML Lab
Software Testing and UML LabSoftware Testing and UML Lab
Software Testing and UML Lab
 
Analysis
AnalysisAnalysis
Analysis
 
Lecture#01, object orientation
Lecture#01, object orientationLecture#01, object orientation
Lecture#01, object orientation
 
Chapter 4_Introduction to Patterns.ppt
Chapter 4_Introduction to Patterns.pptChapter 4_Introduction to Patterns.ppt
Chapter 4_Introduction to Patterns.ppt
 
Chapter 4_Introduction to Patterns.ppt
Chapter 4_Introduction to Patterns.pptChapter 4_Introduction to Patterns.ppt
Chapter 4_Introduction to Patterns.ppt
 
Enhanced ER(database)
Enhanced ER(database)Enhanced ER(database)
Enhanced ER(database)
 
5 transition to design
5 transition to design5 transition to design
5 transition to design
 
Chapter 4: Enhanced Entity-Relationship and Object Modeling
Chapter 4:  Enhanced Entity-Relationship and Object ModelingChapter 4:  Enhanced Entity-Relationship and Object Modeling
Chapter 4: Enhanced Entity-Relationship and Object Modeling
 
classdiagram.pptx
classdiagram.pptxclassdiagram.pptx
classdiagram.pptx
 
ERD.ppt
ERD.pptERD.ppt
ERD.ppt
 
ERD.ppt
ERD.pptERD.ppt
ERD.ppt
 
lkjhlkjhjhkjhlkjhkjhkjhkjhkjhkjhjhkjh.ppt
lkjhlkjhjhkjhlkjhkjhkjhkjhkjhkjhjhkjh.pptlkjhlkjhjhkjhlkjhkjhkjhkjhkjhkjhjhkjh.ppt
lkjhlkjhjhkjhlkjhkjhkjhkjhkjhkjhjhkjh.ppt
 

More from Christalin Nelson

More from Christalin Nelson (18)

Packages and Subpackages in Java
Packages and Subpackages in JavaPackages and Subpackages in Java
Packages and Subpackages in Java
 
Bitwise complement operator
Bitwise complement operatorBitwise complement operator
Bitwise complement operator
 
Advanced Data Structures - Vol.2
Advanced Data Structures - Vol.2Advanced Data Structures - Vol.2
Advanced Data Structures - Vol.2
 
Deadlocks
DeadlocksDeadlocks
Deadlocks
 
CPU Scheduling
CPU SchedulingCPU Scheduling
CPU Scheduling
 
Process Synchronization
Process SynchronizationProcess Synchronization
Process Synchronization
 
Process Management
Process ManagementProcess Management
Process Management
 
Applications of Stack
Applications of StackApplications of Stack
Applications of Stack
 
Data Storage and Information Management
Data Storage and Information ManagementData Storage and Information Management
Data Storage and Information Management
 
Application Middleware Overview
Application Middleware OverviewApplication Middleware Overview
Application Middleware Overview
 
Network security
Network securityNetwork security
Network security
 
Directory services
Directory servicesDirectory services
Directory services
 
System overview
System overviewSystem overview
System overview
 
Storage overview
Storage overviewStorage overview
Storage overview
 
Computer Fundamentals-2
Computer Fundamentals-2Computer Fundamentals-2
Computer Fundamentals-2
 
Computer Fundamentals - 1
Computer Fundamentals - 1Computer Fundamentals - 1
Computer Fundamentals - 1
 
Advanced data structures vol. 1
Advanced data structures   vol. 1Advanced data structures   vol. 1
Advanced data structures vol. 1
 
Programming in c++
Programming in c++Programming in c++
Programming in c++
 

Recently uploaded

Personalisation of Education by AI and Big Data - Lourdes Guàrdia
Personalisation of Education by AI and Big Data - Lourdes GuàrdiaPersonalisation of Education by AI and Big Data - Lourdes Guàrdia
Personalisation of Education by AI and Big Data - Lourdes Guàrdia
EADTU
 
Orientation Canvas Course Presentation.pdf
Orientation Canvas Course Presentation.pdfOrientation Canvas Course Presentation.pdf
Orientation Canvas Course Presentation.pdf
Elizabeth Walsh
 

Recently uploaded (20)

PANDITA RAMABAI- Indian political thought GENDER.pptx
PANDITA RAMABAI- Indian political thought GENDER.pptxPANDITA RAMABAI- Indian political thought GENDER.pptx
PANDITA RAMABAI- Indian political thought GENDER.pptx
 
HMCS Max Bernays Pre-Deployment Brief (May 2024).pptx
HMCS Max Bernays Pre-Deployment Brief (May 2024).pptxHMCS Max Bernays Pre-Deployment Brief (May 2024).pptx
HMCS Max Bernays Pre-Deployment Brief (May 2024).pptx
 
How to Manage Call for Tendor in Odoo 17
How to Manage Call for Tendor in Odoo 17How to Manage Call for Tendor in Odoo 17
How to Manage Call for Tendor in Odoo 17
 
REMIFENTANIL: An Ultra short acting opioid.pptx
REMIFENTANIL: An Ultra short acting opioid.pptxREMIFENTANIL: An Ultra short acting opioid.pptx
REMIFENTANIL: An Ultra short acting opioid.pptx
 
HMCS Vancouver Pre-Deployment Brief - May 2024 (Web Version).pptx
HMCS Vancouver Pre-Deployment Brief - May 2024 (Web Version).pptxHMCS Vancouver Pre-Deployment Brief - May 2024 (Web Version).pptx
HMCS Vancouver Pre-Deployment Brief - May 2024 (Web Version).pptx
 
Accessible Digital Futures project (20/03/2024)
Accessible Digital Futures project (20/03/2024)Accessible Digital Futures project (20/03/2024)
Accessible Digital Futures project (20/03/2024)
 
Details on CBSE Compartment Exam.pptx1111
Details on CBSE Compartment Exam.pptx1111Details on CBSE Compartment Exam.pptx1111
Details on CBSE Compartment Exam.pptx1111
 
Wellbeing inclusion and digital dystopias.pptx
Wellbeing inclusion and digital dystopias.pptxWellbeing inclusion and digital dystopias.pptx
Wellbeing inclusion and digital dystopias.pptx
 
Towards a code of practice for AI in AT.pptx
Towards a code of practice for AI in AT.pptxTowards a code of practice for AI in AT.pptx
Towards a code of practice for AI in AT.pptx
 
80 ĐỀ THI THỬ TUYỂN SINH TIẾNG ANH VÀO 10 SỞ GD – ĐT THÀNH PHỐ HỒ CHÍ MINH NĂ...
80 ĐỀ THI THỬ TUYỂN SINH TIẾNG ANH VÀO 10 SỞ GD – ĐT THÀNH PHỐ HỒ CHÍ MINH NĂ...80 ĐỀ THI THỬ TUYỂN SINH TIẾNG ANH VÀO 10 SỞ GD – ĐT THÀNH PHỐ HỒ CHÍ MINH NĂ...
80 ĐỀ THI THỬ TUYỂN SINH TIẾNG ANH VÀO 10 SỞ GD – ĐT THÀNH PHỐ HỒ CHÍ MINH NĂ...
 
Personalisation of Education by AI and Big Data - Lourdes Guàrdia
Personalisation of Education by AI and Big Data - Lourdes GuàrdiaPersonalisation of Education by AI and Big Data - Lourdes Guàrdia
Personalisation of Education by AI and Big Data - Lourdes Guàrdia
 
Orientation Canvas Course Presentation.pdf
Orientation Canvas Course Presentation.pdfOrientation Canvas Course Presentation.pdf
Orientation Canvas Course Presentation.pdf
 
Including Mental Health Support in Project Delivery, 14 May.pdf
Including Mental Health Support in Project Delivery, 14 May.pdfIncluding Mental Health Support in Project Delivery, 14 May.pdf
Including Mental Health Support in Project Delivery, 14 May.pdf
 
Jamworks pilot and AI at Jisc (20/03/2024)
Jamworks pilot and AI at Jisc (20/03/2024)Jamworks pilot and AI at Jisc (20/03/2024)
Jamworks pilot and AI at Jisc (20/03/2024)
 
AIM of Education-Teachers Training-2024.ppt
AIM of Education-Teachers Training-2024.pptAIM of Education-Teachers Training-2024.ppt
AIM of Education-Teachers Training-2024.ppt
 
How to Add New Custom Addons Path in Odoo 17
How to Add New Custom Addons Path in Odoo 17How to Add New Custom Addons Path in Odoo 17
How to Add New Custom Addons Path in Odoo 17
 
Ernest Hemingway's For Whom the Bell Tolls
Ernest Hemingway's For Whom the Bell TollsErnest Hemingway's For Whom the Bell Tolls
Ernest Hemingway's For Whom the Bell Tolls
 
How to Add a Tool Tip to a Field in Odoo 17
How to Add a Tool Tip to a Field in Odoo 17How to Add a Tool Tip to a Field in Odoo 17
How to Add a Tool Tip to a Field in Odoo 17
 
Observing-Correct-Grammar-in-Making-Definitions.pptx
Observing-Correct-Grammar-in-Making-Definitions.pptxObserving-Correct-Grammar-in-Making-Definitions.pptx
Observing-Correct-Grammar-in-Making-Definitions.pptx
 
How to setup Pycharm environment for Odoo 17.pptx
How to setup Pycharm environment for Odoo 17.pptxHow to setup Pycharm environment for Odoo 17.pptx
How to setup Pycharm environment for Odoo 17.pptx
 

Data Modeling - Enhanced ER diagrams & Mapping.pdf

  • 1.
  • 2. Data Modeling (Part – 2) Christalin Nelson | Systems Cluster | SOCS 2/27/2024 2
  • 3. 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 Christalin Nelson | Systems Cluster | SOCS 2/27/2024 3 of 48
  • 4. 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 Christalin Nelson | Systems Cluster | SOCS 2/27/2024 4 of 48
  • 5. 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 Christalin Nelson | Systems Cluster | SOCS 2/27/2024 5 of 48
  • 6. 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 Christalin Nelson | Systems Cluster | SOCS 2/27/2024 6 of 48
  • 7. 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 Christalin Nelson | Systems Cluster | SOCS 2/27/2024 7 of 48
  • 8. 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 Christalin Nelson | Systems Cluster | SOCS 2/27/2024 8 of 48
  • 9. 9 of 48 Christalin Nelson | Systems Cluster | SOCS 2/27/2024
  • 10. Specialization (3/5) • 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 Christalin Nelson | Systems Cluster | SOCS 2/27/2024 10 of 48
  • 11. 11 of 48 Christalin Nelson | Systems Cluster | SOCS 2/27/2024
  • 12. Specialization (5/5) • 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 Christalin Nelson | Systems Cluster | SOCS 2/27/2024 12 of 48
  • 13. 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 Christalin Nelson | Systems Cluster | SOCS 2/27/2024 13 of 48
  • 14. 14 of 48 Christalin Nelson | Systems Cluster | SOCS 2/27/2024
  • 15. 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 Christalin Nelson | Systems Cluster | SOCS 2/27/2024 15 of 48
  • 16. 16 of 48 Christalin Nelson | Systems Cluster | SOCS 2/27/2024
  • 17. Constraints on Generalization & Specialization (3/6) • 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 Christalin Nelson | Systems Cluster | SOCS 2/27/2024 17 of 48
  • 18. 18 of 48 Christalin Nelson | Systems Cluster | SOCS 2/27/2024
  • 19. Constraints on Generalization & Specialization (5/6) • 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?? Christalin Nelson | Systems Cluster | SOCS 2/27/2024 19 of 48
  • 20. Constraints on Generalization & Specialization (6/6) • Disjointness constraints and completeness constraints are independent. Hence, four combinations of constraints can be obtained – Disjoint, total – Disjoint, partial – Overlapping, total – Overlapping, partial Christalin Nelson | Systems Cluster | SOCS 2/27/2024 20 of 48
  • 21. 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 Christalin Nelson | Systems Cluster | SOCS 2/27/2024 21 of 48
  • 22. Specialization & Generalization Hierarchies and Lattices (2/3) Christalin Nelson | Systems Cluster | SOCS 2/27/2024 22 of 48
  • 23. 23 of 48 Christalin Nelson | Systems Cluster | SOCS 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
  • 24. 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 Christalin Nelson | Systems Cluster | SOCS 2/27/2024 24 of 48
  • 25. 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 Christalin Nelson | Systems Cluster | SOCS 2/27/2024 25 of 48
  • 26. 26 of 48 Christalin Nelson | Systems Cluster | SOCS 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. 27 of 48 Christalin Nelson | Systems Cluster | SOCS 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
  • 28. 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. Christalin Nelson | Systems Cluster | SOCS 2/27/2024 28 of 48
  • 29. 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 Christalin Nelson | Systems Cluster | SOCS 29 of 48
  • 30. 2/27/2024 Data Abstraction, KR, and Ontology Concepts (2/5) • 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 Christalin Nelson | Systems Cluster | SOCS 30 of 48
  • 31. 2/27/2024 Data Abstraction, KR, and Ontology Concepts (3/5) • 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 Christalin Nelson | Systems Cluster | SOCS 31 of 48
  • 32. 2/27/2024 Data Abstraction, KR, and Ontology Concepts (4/5) • 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 Christalin Nelson | Systems Cluster | SOCS 32 of 48
  • 33. 2/27/2024 Data Abstraction, KR, and Ontology Concepts (5/5) • Example: Aggregation in ER diagram Christalin Nelson | Systems Cluster | SOCS 33 of 48
  • 34. 2/27/2024 Relational DB design using ER-to-Relational Mapping (1/13) Christalin Nelson | Systems Cluster | SOCS 34 of 48
  • 35. 2/27/2024 Relational DB design using ER-to-Relational Mapping (2/13) • 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 Christalin Nelson | Systems Cluster | SOCS 35 of 48
  • 36. 2/27/2024 Relational DB design using ER-to-Relational Mapping (2/13) • 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 Christalin Nelson | Systems Cluster | SOCS 36 of 48
  • 37. 2/27/2024 Relational DB design using ER-to-Relational Mapping (3/13) • 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 Christalin Nelson | Systems Cluster | SOCS 37 of 48
  • 38. 2/27/2024 Relational DB design using ER-to-Relational Mapping (4/13) • 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 type as attributes of S Christalin Nelson | Systems Cluster | SOCS 38 of 48
  • 39. 2/27/2024 Relational DB design using ER-to-Relational Mapping (5/13) • 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 Christalin Nelson | Systems Cluster | SOCS 39 of 48
  • 40. 2/27/2024 Relational DB design using ER-to-Relational Mapping (6/13) • 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 type as attributes of S Christalin Nelson | Systems Cluster | SOCS 40 of 48
  • 41. 2/27/2024 Relational DB design using ER-to-Relational Mapping (7/13) Christalin Nelson | Systems Cluster | SOCS 41 of 48
  • 42. 2/27/2024 Relational DB design using ER-to-Relational Mapping (8/13) • Step-8: Mapping of Specialization or Generalization (1/5) – Option 8A: Multiple relations – superclass and subclasses Christalin Nelson | Systems Cluster | SOCS 42 of 48
  • 43. 2/27/2024 Relational DB design using ER-to-Relational Mapping (9/13) • Step-8: Mapping of Specialization or Generalization (2/5) – Option 8B: Multiple relations – subclass relations only Christalin Nelson | Systems Cluster | SOCS 43 of 48
  • 44. 2/27/2024 Relational DB design using ER-to-Relational Mapping (10/13) • Step-8: Mapping of Specialization or Generalization (3/5) – Option 8C: Single relation with one type attribute Christalin Nelson | Systems Cluster | SOCS 44 of 48
  • 45. 2/27/2024 Relational DB design using ER-to-Relational Mapping (11/13) • Step-8: Mapping of Specialization or Generalization (4/5) – Option 8D: Single relation with multiple type attributes Christalin Nelson | Systems Cluster | SOCS 45 of 48
  • 46. 2/27/2024 Relational DB design using ER-to-Relational Mapping (12/13) • Step-8: Mapping of Specialization or Generalization (5/5) – 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 Christalin Nelson | Systems Cluster | SOCS 46 of 48
  • 47. 2/27/2024 Relational DB design using ER-to-Relational Mapping (13/13) • Step-9 (contd.) Christalin Nelson | Systems Cluster | SOCS 47 of 48
  • 48. Christalin Nelson | Systems Cluster | SOCS 2/27/2024 48