SlideShare ist ein Scribd-Unternehmen logo
1 von 25
© Shamkant B. Navathe
        CC
Chapter 4 - Part I
Enhanced Entity-Relationship
    and UML Modeling




         Copyright © © Shamkant B. Navathe
                     2004 Ramez Elmasri and Shamkant Navathe.
                               CC
Enhanced-ER (EER) Model
              Concepts
 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
           Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition
                      Copyright © 2004 Ramez Elmasri and Shamkant Navathe
Subclasses and Superclasses (1)
 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.
 Example: EMPLOYEE/SECRETARY,
  EMPLOYEE/TECHNICIAN

             Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition
                        Copyright © 2004 Ramez Elmasri and Shamkant Navathe
Subclasses and Superclasses (2)
 These are also called IS-A relationships (SECRETARY IS-A
  EMPLOYEE, TECHNICIAN IS-A EMPLOYEE, …).
 Note: An entity that is member of a subclass represents the same real-
  world entity as some member of the superclass
   – The Subclass member is the same entity in a distinct specific role
   – An entity cannot exist in the database merely by being a member
     of a subclass; it must also be a member of the superclass
   – A member of the superclass can be optionally included as a
     member of any number of its subclasses
 Example: A salaried employee who is also an engineer belongs to the
  two subclasses ENGINEER and SALARIED_EMPLOYEE
   – It is not necessary that every entity in a superclass be a member of
     some subclass



               Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition
                          Copyright © 2004 Ramez Elmasri and Shamkant Navathe
Attribute Inheritance in
           Superclass / Subclass
                Relationships
 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




           Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition
                      Copyright © 2004 Ramez Elmasri and Shamkant Navathe
Specialization
 Is the process of defining a set of subclasses of a superclass
 The set of subclasses is based upon some distinguishing characteristics
  of the entities in the superclass
 Example: {SECRETARY, ENGINEER, TECHNICIAN} is a
  specialization of EMPLOYEE based upon job type.
   – May have several specializations of the same superclass
 Example: Another specialization of EMPLOYEE based in method of
  pay is {SALARIED_EMPLOYEE, HOURLY_EMPLOYEE}.
   – Superclass/subclass relationships and specialization can be
       diagrammatically represented in EER diagrams
   – Attributes of a subclass are called specific attributes. For example,
       TypingSpeed of SECRETARY
   – The subclass can participate in specific relationship types. For
       example, BELONGS_TO of HOURLY_EMPLOYEE

               Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition
                          Copyright © 2004 Ramez Elmasri and Shamkant Navathe
Example of a Specialization




  Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition
             Copyright © 2004 Ramez Elmasri and Shamkant Navathe
Generalization
 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.
   – We can view {CAR, TRUCK} as a specialization of VEHICLE
   – Alternatively, we can view VEHICLE as a generalization of CAR
     and TRUCK



             Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition
                        Copyright © 2004 Ramez Elmasri and Shamkant Navathe
Generalization and
                      Specialization
 Diagrammatic notation sometimes used to distinguish between
  generalization and specialization
   – Arrow pointing to the generalized superclass represents a
     generalization
   – Arrows pointing to the specialized subclasses represent a
     specialization
   – We do not use this notation because it is often subjective as to
     which process is more appropriate for a particular situation
   – We advocate not drawing any arrows in these situations
 Data Modeling with Specialization and Generalization
   – A superclass or subclass represents a set of entities
   – Shown in rectangles in EER diagrams (as are entity types)
   – Sometimes, all entity sets are simply called classes, whether they
     are entity types, superclasses, or subclasses

               Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition
                          Copyright © 2004 Ramez Elmasri and Shamkant Navathe
Constraints on Specialization
          and Generalization (1)
 If we can determine exactly those entities that will become members of each
  subclass by a condition, the subclasses are called predicate-defined (or
  condition-defined) subclasses
    – Condition is a constraint that determines subclass members
    – Display a predicate-defined subclass by writing the predicate condition
       next to the line attaching the subclass to its superclass
 If all subclasses in a specialization have membership condition on same
  attribute of the superclass, specialization is called an attribute defined-
  specialization
    – Attribute is called the defining attribute of the specialization
    – Example: JobType is the defining attribute of the specialization
       {SECRETARY, TECHNICIAN, ENGINEER} of EMPLOYEE
 If no condition determines membership, the subclass is called user-defined
    – Membership in a subclass is determined by the database users by applying
       an operation to add an entity to the subclass
    – Membership in the subclass is specified individually for each entity in the
       superclass by the user
                 Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition
                            Copyright © 2004 Ramez Elmasri and Shamkant Navathe
Constraints on Specialization
          and Generalization (2)
 Two other conditions apply to a specialization/generalization:
 Disjointness Constraint:
    – Specifies that the subclasses of the specialization must be disjointed (an
      entity can be a member of at most one of the subclasses of the
      specialization)
    – Specified by d in EER diagram
    – If not disjointed, overlap; that is the same entity may be a member of
      more than one subclass of the specialization
    – Specified by o in EER diagram
 Completeness Constraint:
    – Total specifies that every entity in the superclass must be a member of
      some subclass in the specialization/ generalization
    – Shown in EER diagrams by a double line
    – Partial allows an entity not to belong to any of the subclasses
    – Shown in EER diagrams by a single line

                Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition
                           Copyright © 2004 Ramez Elmasri and Shamkant Navathe
Constraints on Specialization
          and Generalization (3)
 Hence, we have four types of specialization/generalization:
    –   Disjoint, total
    –   Disjoint, partial
    –   Overlapping, total
    –   Overlapping, partial
 Note: Generalization usually is total because the superclass is derived
  from the subclasses.




                 Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition
                            Copyright © 2004 Ramez Elmasri and Shamkant Navathe
Example of disjoint partial
    Specialization




 Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition
            Copyright © 2004 Ramez Elmasri and Shamkant Navathe
Specialization / Generalization
          Hierarchies, Lattices and Shared
                    Subclasses
 A subclass may itself have further subclasses specified on it
 Forms a hierarchy or a lattice
 Hierarchy has a constraint that every subclass has only one superclass (called single
  inheritance)
 In a lattice, a subclass can be subclass of more than one superclass (called multiple
  inheritance)
 In a lattice or hierarchy, a subclass inherits attributes not only of its direct
  superclass, but also of all its predecessor superclasses
 A subclass with more than one superclass is called a shared subclass
 Can have specialization hierarchies or lattices, or generalization hierarchies or
  lattices
 In specialization, start with an entity type and then define subclasses of the entity
  type by successive specialization (top down conceptual refinement process)
 In generalization, start with many entity types and generalize those that have
  common properties (bottom up conceptual synthesis process)
 In practice, the combination of two processes is employed

                   Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition
                              Copyright © 2004 Ramez Elmasri and Shamkant Navathe
 The database keeps track of three types of
  people: Employees , Alumni and students.
  A person can belong to one ,two or all three
  of these types. Each person has a name ,
  SSN, sex, address and birth date.
 Every employee has a salary and are three
  types of employees: Faculty , Staff and
  Student assistants. Each employee belongs
  to exactly one of these types. For each
  alumnus , a record of the degree or degrees
  that he or she earned at the university is
  kept including the name of the degree ,
         Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition
                    Copyright © 2004 Ramez Elmasri and Shamkant Navathe
year granted and the major department. Each
  student has a major department.
 Each faculty has a rank , whereas each staff
  member has a staff position.Student
  assistants are classified further as either
  research assistants or teaching assistants
  and the percent of time they work is
  recorded in the database. Research
  assistants have their research projects stored
  whereas teaching assistants have the current
  course they work on.

          Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition
                     Copyright © 2004 Ramez Elmasri and Shamkant Navathe
 Students are further classified as either
 graduate or undergraduate with the specific
 attributes degree program (M.S., Ph.D ,
 M.B.A and so on) and class respectively.




         Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition
                    Copyright © 2004 Ramez Elmasri and Shamkant Navathe
Specialization / Generalization
 Lattice Example (UNIVERSITY)




    Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition
               Copyright © 2004 Ramez Elmasri and Shamkant Navathe
Categories (UNION TYPES)
 All of the superclass/subclass relationships we have seen thus far have a single
  superclass
 A shared subclass is subclass in more than one distinct superclass/subclass
  relationships, where each relationships has a single superclass (multiple
  inheritance)
 In some cases, need to model a single superclass/subclass relationship with
  more than one superclass
 Superclasses represent different entity types
 Such a subclass is called a category or UNION TYPE
 Example: Database for vehicle registration, vehicle owner can be a person, a
  bank (holding a lien on a vehicle) or a company.
    – Category (subclass) OWNER is a subset of the union of the three superclasses
      COMPANY, BANK, and PERSON
    – A category member must exist in at least one of its superclasses
 Note: The difference from shared subclass, which is subset of the intersection
  of its superclasses (shared subclass member must exist in all of its
  superclasses).

                 Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition
                            Copyright © 2004 Ramez Elmasri and Shamkant Navathe
Example of categories
  (UNION TYPES)




Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition
           Copyright © 2004 Ramez Elmasri and Shamkant Navathe
Formal Definitions of EER
                  Model (1)
 Class C: A set of entities; could be entity type, subclass, superclass,
  category.
 Subclass S: A class whose entities must always be subset of the
  entities in another class, called the superclass C of the
  superclass/subclass (or IS-A) relationship S/C:
        S⊆C
 Specialization Z: Z = {S1, S2,…, Sn} a set of subclasses with same
  superclass G; hence, G/Si a superclass relationship for i = 1, …., n.
    – G is called a generalization of the subclasses {S1, S2,…, Sn}
    – Z is total if we always have:
        S1 ∪ S2 ∪ … ∪ Sn = G;
      Otherwise, Z is partial.
    – Z is disjoint if we always have:
        Si ∩ S2 empty-set for i ≠ j;
      Otherwise, Z is overlapping.

                Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition
                           Copyright © 2004 Ramez Elmasri and Shamkant Navathe
Formal Definitions of EER
                     Model (2)
 Subclass S of C is predicate defined if predicate p on attributes of C is used to
  specify membership in S; that is, S = C[p], where C[p] is the set of entities in
  C that satisfy p
 A subclass not defined by a predicate is called user-defined
 Attribute-defined specialization: if a predicate A = ci (where A is an attribute
  of G and ci is a constant value from the domain of A) is used to specify
  membership in each subclass Si in Z
 Note: If ci ≠ cj for i ≠ j, and A is single-valued, then the attribute-defined
  specialization will be disjoint.
 Category or UNION type T
     – A class that is a subset of the union of n defining superclasses
       D1, D2,…Dn, n>1:
          T ⊆ (D1 ∪ D2 ∪ … ∪ Dn)
       A predicate pi on the attributes of T.
     – If a predicate pi on the attributes of Di can specify entities of Di that are members
       of T.
     – If a predicate is specified on every Di: T = (D1[p1] ∪ D2[p2] ∪…∪ Dn[pn]
     – Note: The definition of relationship type should have 'entity type' replaced with
       'class'.
                   Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition
                              Copyright © 2004 Ramez Elmasri and Shamkant Navathe
UML Example for Displaying
Specialization / Generalization




    Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition
               Copyright © 2004 Ramez Elmasri and Shamkant Navathe
Alternative Diagrammatic
                     Notations
Symbols for entity type / class,                          Displaying attributes
attribute and relationship




Notations for displaying                                    Various (min,                Displaying
specialization / generalization                             max) notations               cardinality ratios




                 Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition
                            Copyright © 2004 Ramez Elmasri and Shamkant Navathe

Weitere ähnliche Inhalte

Was ist angesagt?

Er & eer to relational mapping
Er & eer to relational mappingEr & eer to relational mapping
Er & eer to relational mapping
saurabhshertukde
 

Was ist angesagt? (20)

Er diagrams presentation
Er diagrams presentationEr diagrams presentation
Er diagrams presentation
 
ER-Model-ER Diagram
ER-Model-ER DiagramER-Model-ER Diagram
ER-Model-ER Diagram
 
Advantages of DBMS
Advantages of DBMSAdvantages of DBMS
Advantages of DBMS
 
Modelo relacional
Modelo relacionalModelo relacional
Modelo relacional
 
Er & eer to relational mapping
Er & eer to relational mappingEr & eer to relational mapping
Er & eer to relational mapping
 
Object oriented database concepts
Object oriented database conceptsObject oriented database concepts
Object oriented database concepts
 
Codds rule
Codds ruleCodds rule
Codds rule
 
Data mining query language
Data mining query languageData mining query language
Data mining query language
 
Validation based protocol
Validation based protocolValidation based protocol
Validation based protocol
 
Chapter-4 Enhanced ER Model
Chapter-4 Enhanced ER ModelChapter-4 Enhanced ER Model
Chapter-4 Enhanced ER Model
 
Distributed Query Processing
Distributed Query ProcessingDistributed Query Processing
Distributed Query Processing
 
Major and Minor Elements of Object Model
Major and Minor Elements of Object ModelMajor and Minor Elements of Object Model
Major and Minor Elements of Object Model
 
DBMS 3 | ER Diagram to Relational Schema
DBMS 3 | ER Diagram to Relational SchemaDBMS 3 | ER Diagram to Relational Schema
DBMS 3 | ER Diagram to Relational Schema
 
Database : Relational Data Model
Database : Relational Data ModelDatabase : Relational Data Model
Database : Relational Data Model
 
Functional dependency
Functional dependencyFunctional dependency
Functional dependency
 
Types Of Keys in DBMS
Types Of Keys in DBMSTypes Of Keys in DBMS
Types Of Keys in DBMS
 
Transaction management DBMS
Transaction  management DBMSTransaction  management DBMS
Transaction management DBMS
 
Entity Relationship Diagrams
Entity Relationship DiagramsEntity Relationship Diagrams
Entity Relationship Diagrams
 
Functional dependencies in Database Management System
Functional dependencies in Database Management SystemFunctional dependencies in Database Management System
Functional dependencies in Database Management System
 
ER DIAGRAM & ER MODELING IN DBMS
ER DIAGRAM & ER MODELING IN DBMSER DIAGRAM & ER MODELING IN DBMS
ER DIAGRAM & ER MODELING IN DBMS
 

Andere mochten auch

Chapter 12 transactions and concurrency control
Chapter 12 transactions and concurrency controlChapter 12 transactions and concurrency control
Chapter 12 transactions and concurrency control
AbDul ThaYyal
 
Ch17 introduction to transaction processing concepts and theory
Ch17 introduction to transaction processing concepts and theoryCh17 introduction to transaction processing concepts and theory
Ch17 introduction to transaction processing concepts and theory
meenatchi selvaraj
 
Object relational and extended relational databases
Object relational and extended relational databasesObject relational and extended relational databases
Object relational and extended relational databases
Suhad Jihad
 

Andere mochten auch (20)

Fundamentals of Database system
Fundamentals of Database systemFundamentals of Database system
Fundamentals of Database system
 
Chapter18
Chapter18Chapter18
Chapter18
 
EER Model
EER ModelEER Model
EER Model
 
Chapter 12 transactions and concurrency control
Chapter 12 transactions and concurrency controlChapter 12 transactions and concurrency control
Chapter 12 transactions and concurrency control
 
Ch17 introduction to transaction processing concepts and theory
Ch17 introduction to transaction processing concepts and theoryCh17 introduction to transaction processing concepts and theory
Ch17 introduction to transaction processing concepts and theory
 
Colorectal Cancer-A Rising Concern
Colorectal Cancer-A Rising ConcernColorectal Cancer-A Rising Concern
Colorectal Cancer-A Rising Concern
 
Payilagam oracle sql & plsql training syllabus
Payilagam oracle sql & plsql training syllabusPayilagam oracle sql & plsql training syllabus
Payilagam oracle sql & plsql training syllabus
 
Oracle Baisc Tutorial
Oracle Baisc TutorialOracle Baisc Tutorial
Oracle Baisc Tutorial
 
En ch23
En ch23En ch23
En ch23
 
Database lab manual
Database lab manualDatabase lab manual
Database lab manual
 
Transaction Management - Lecture 11 - Introduction to Databases (1007156ANR)
Transaction Management - Lecture 11 - Introduction to Databases (1007156ANR)Transaction Management - Lecture 11 - Introduction to Databases (1007156ANR)
Transaction Management - Lecture 11 - Introduction to Databases (1007156ANR)
 
Joins in databases
Joins in databases Joins in databases
Joins in databases
 
Adbms
AdbmsAdbms
Adbms
 
enhanced er diagram
enhanced er diagramenhanced er diagram
enhanced er diagram
 
PLSQL Cursors
PLSQL CursorsPLSQL Cursors
PLSQL Cursors
 
PLSQL Tutorial
PLSQL TutorialPLSQL Tutorial
PLSQL Tutorial
 
Chapter02
Chapter02Chapter02
Chapter02
 
Everything about Database JOINS and Relationships
Everything about Database JOINS and RelationshipsEverything about Database JOINS and Relationships
Everything about Database JOINS and Relationships
 
Object relational and extended relational databases
Object relational and extended relational databasesObject relational and extended relational databases
Object relational and extended relational databases
 
Lecture 14 requirements modeling - flow and behavior
Lecture 14   requirements modeling - flow and  behaviorLecture 14   requirements modeling - flow and  behavior
Lecture 14 requirements modeling - flow and behavior
 

Ähnlich wie Eer case study

Module 5 oodb systems semantic db systems
Module 5 oodb systems  semantic db systemsModule 5 oodb systems  semantic db systems
Module 5 oodb systems semantic db systems
Taher Barodawala
 
Data Modeling - Enhanced ER diagrams & Mapping.pdf
Data Modeling - Enhanced ER diagrams & Mapping.pdfData Modeling - Enhanced ER diagrams & Mapping.pdf
Data Modeling - Enhanced ER diagrams & Mapping.pdf
Christalin Nelson
 
27 f157al5enhanced er diagram
27 f157al5enhanced er diagram27 f157al5enhanced er diagram
27 f157al5enhanced er diagram
dddgh
 
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
 
Jedi slides 2.1 object-oriented concepts
Jedi slides 2.1 object-oriented conceptsJedi slides 2.1 object-oriented concepts
Jedi slides 2.1 object-oriented concepts
Maryo Manjaruni
 

Ähnlich wie Eer case study (20)

EER-database.ppt
EER-database.pptEER-database.ppt
EER-database.ppt
 
Chapter04
Chapter04Chapter04
Chapter04
 
Module 5 oodb systems semantic db systems
Module 5 oodb systems  semantic db systemsModule 5 oodb systems  semantic db systems
Module 5 oodb systems semantic db systems
 
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
 
3_EERD.pdf
3_EERD.pdf3_EERD.pdf
3_EERD.pdf
 
Data Modeling - Enhanced ER diagrams & Mapping.pdf
Data Modeling - Enhanced ER diagrams & Mapping.pdfData Modeling - Enhanced ER diagrams & Mapping.pdf
Data Modeling - Enhanced ER diagrams & Mapping.pdf
 
27 f157al5enhanced er diagram
27 f157al5enhanced er diagram27 f157al5enhanced er diagram
27 f157al5enhanced er diagram
 
27f157al5enhanceder diagram-111005002740-phpapp02
27f157al5enhanceder diagram-111005002740-phpapp0227f157al5enhanceder diagram-111005002740-phpapp02
27f157al5enhanceder diagram-111005002740-phpapp02
 
Fundamentals of oops in .Net
Fundamentals of oops in .NetFundamentals of oops in .Net
Fundamentals of oops in .Net
 
Enhanced E-R diagram
Enhanced E-R diagramEnhanced E-R diagram
Enhanced E-R diagram
 
Jedi slides 2.1 object-oriented concepts
Jedi slides 2.1 object-oriented conceptsJedi slides 2.1 object-oriented concepts
Jedi slides 2.1 object-oriented concepts
 
Software Testing and UML Lab
Software Testing and UML LabSoftware Testing and UML Lab
Software Testing and UML Lab
 
Lecture 12
Lecture 12Lecture 12
Lecture 12
 
ER Diagram
ER DiagramER Diagram
ER Diagram
 
Concepts of oops
Concepts of oopsConcepts of oops
Concepts of oops
 
Enhance ERD(Entity Relationship Diagram)
Enhance ERD(Entity Relationship Diagram)Enhance ERD(Entity Relationship Diagram)
Enhance ERD(Entity Relationship Diagram)
 
C# program structure
C# program structureC# program structure
C# program structure
 
Abstract class and Interface
Abstract class and InterfaceAbstract class and Interface
Abstract class and Interface
 
SAP ABAP Latest Interview Questions with Answers by Garuda Trainings
SAP ABAP Latest Interview Questions with Answers by Garuda TrainingsSAP ABAP Latest Interview Questions with Answers by Garuda Trainings
SAP ABAP Latest Interview Questions with Answers by Garuda Trainings
 
Unit 3 Java
Unit 3 JavaUnit 3 Java
Unit 3 Java
 

Mehr von saurabhshertukde (18)

Revision sql te it new syllabus
Revision sql te it new syllabusRevision sql te it new syllabus
Revision sql te it new syllabus
 
Oodbms ch 20
Oodbms ch 20Oodbms ch 20
Oodbms ch 20
 
Introduction er & eer
Introduction er & eerIntroduction er & eer
Introduction er & eer
 
Introduction er & eer
Introduction er &  eerIntroduction er &  eer
Introduction er & eer
 
Integrity & security
Integrity & securityIntegrity & security
Integrity & security
 
Er model
Er modelEr model
Er model
 
Chapter 2
Chapter 2Chapter 2
Chapter 2
 
Chapter 1
Chapter 1Chapter 1
Chapter 1
 
Chapter 9
Chapter 9Chapter 9
Chapter 9
 
J2 ee archi
J2 ee archiJ2 ee archi
J2 ee archi
 
J2 ee architecture
J2 ee architectureJ2 ee architecture
J2 ee architecture
 
Software project-scheduling
Software project-schedulingSoftware project-scheduling
Software project-scheduling
 
Softwareproject planning
Softwareproject planningSoftwareproject planning
Softwareproject planning
 
Pressman ch-3-prescriptive-process-models
Pressman ch-3-prescriptive-process-modelsPressman ch-3-prescriptive-process-models
Pressman ch-3-prescriptive-process-models
 
Design concepts and principles
Design concepts and principlesDesign concepts and principles
Design concepts and principles
 
Analysis modelling
Analysis modellingAnalysis modelling
Analysis modelling
 
Analysis concepts and principles
Analysis concepts and principlesAnalysis concepts and principles
Analysis concepts and principles
 
Risk analysis
Risk analysisRisk analysis
Risk analysis
 

Kürzlich hochgeladen

Modular Monolith - a Practical Alternative to Microservices @ Devoxx UK 2024
Modular Monolith - a Practical Alternative to Microservices @ Devoxx UK 2024Modular Monolith - a Practical Alternative to Microservices @ Devoxx UK 2024
Modular Monolith - a Practical Alternative to Microservices @ Devoxx UK 2024
Victor Rentea
 
+971581248768>> SAFE AND ORIGINAL ABORTION PILLS FOR SALE IN DUBAI AND ABUDHA...
+971581248768>> SAFE AND ORIGINAL ABORTION PILLS FOR SALE IN DUBAI AND ABUDHA...+971581248768>> SAFE AND ORIGINAL ABORTION PILLS FOR SALE IN DUBAI AND ABUDHA...
+971581248768>> SAFE AND ORIGINAL ABORTION PILLS FOR SALE IN DUBAI AND ABUDHA...
?#DUbAI#??##{{(☎️+971_581248768%)**%*]'#abortion pills for sale in dubai@
 
Cloud Frontiers: A Deep Dive into Serverless Spatial Data and FME
Cloud Frontiers:  A Deep Dive into Serverless Spatial Data and FMECloud Frontiers:  A Deep Dive into Serverless Spatial Data and FME
Cloud Frontiers: A Deep Dive into Serverless Spatial Data and FME
Safe Software
 

Kürzlich hochgeladen (20)

Introduction to use of FHIR Documents in ABDM
Introduction to use of FHIR Documents in ABDMIntroduction to use of FHIR Documents in ABDM
Introduction to use of FHIR Documents in ABDM
 
AI+A11Y 11MAY2024 HYDERBAD GAAD 2024 - HelloA11Y (11 May 2024)
AI+A11Y 11MAY2024 HYDERBAD GAAD 2024 - HelloA11Y (11 May 2024)AI+A11Y 11MAY2024 HYDERBAD GAAD 2024 - HelloA11Y (11 May 2024)
AI+A11Y 11MAY2024 HYDERBAD GAAD 2024 - HelloA11Y (11 May 2024)
 
Modular Monolith - a Practical Alternative to Microservices @ Devoxx UK 2024
Modular Monolith - a Practical Alternative to Microservices @ Devoxx UK 2024Modular Monolith - a Practical Alternative to Microservices @ Devoxx UK 2024
Modular Monolith - a Practical Alternative to Microservices @ Devoxx UK 2024
 
Apidays New York 2024 - Passkeys: Developing APIs to enable passwordless auth...
Apidays New York 2024 - Passkeys: Developing APIs to enable passwordless auth...Apidays New York 2024 - Passkeys: Developing APIs to enable passwordless auth...
Apidays New York 2024 - Passkeys: Developing APIs to enable passwordless auth...
 
Introduction to Multilingual Retrieval Augmented Generation (RAG)
Introduction to Multilingual Retrieval Augmented Generation (RAG)Introduction to Multilingual Retrieval Augmented Generation (RAG)
Introduction to Multilingual Retrieval Augmented Generation (RAG)
 
"I see eyes in my soup": How Delivery Hero implemented the safety system for ...
"I see eyes in my soup": How Delivery Hero implemented the safety system for ..."I see eyes in my soup": How Delivery Hero implemented the safety system for ...
"I see eyes in my soup": How Delivery Hero implemented the safety system for ...
 
+971581248768>> SAFE AND ORIGINAL ABORTION PILLS FOR SALE IN DUBAI AND ABUDHA...
+971581248768>> SAFE AND ORIGINAL ABORTION PILLS FOR SALE IN DUBAI AND ABUDHA...+971581248768>> SAFE AND ORIGINAL ABORTION PILLS FOR SALE IN DUBAI AND ABUDHA...
+971581248768>> SAFE AND ORIGINAL ABORTION PILLS FOR SALE IN DUBAI AND ABUDHA...
 
MINDCTI Revenue Release Quarter One 2024
MINDCTI Revenue Release Quarter One 2024MINDCTI Revenue Release Quarter One 2024
MINDCTI Revenue Release Quarter One 2024
 
Platformless Horizons for Digital Adaptability
Platformless Horizons for Digital AdaptabilityPlatformless Horizons for Digital Adaptability
Platformless Horizons for Digital Adaptability
 
Apidays New York 2024 - APIs in 2030: The Risk of Technological Sleepwalk by ...
Apidays New York 2024 - APIs in 2030: The Risk of Technological Sleepwalk by ...Apidays New York 2024 - APIs in 2030: The Risk of Technological Sleepwalk by ...
Apidays New York 2024 - APIs in 2030: The Risk of Technological Sleepwalk by ...
 
Exploring Multimodal Embeddings with Milvus
Exploring Multimodal Embeddings with MilvusExploring Multimodal Embeddings with Milvus
Exploring Multimodal Embeddings with Milvus
 
Strategize a Smooth Tenant-to-tenant Migration and Copilot Takeoff
Strategize a Smooth Tenant-to-tenant Migration and Copilot TakeoffStrategize a Smooth Tenant-to-tenant Migration and Copilot Takeoff
Strategize a Smooth Tenant-to-tenant Migration and Copilot Takeoff
 
FWD Group - Insurer Innovation Award 2024
FWD Group - Insurer Innovation Award 2024FWD Group - Insurer Innovation Award 2024
FWD Group - Insurer Innovation Award 2024
 
Six Myths about Ontologies: The Basics of Formal Ontology
Six Myths about Ontologies: The Basics of Formal OntologySix Myths about Ontologies: The Basics of Formal Ontology
Six Myths about Ontologies: The Basics of Formal Ontology
 
DBX First Quarter 2024 Investor Presentation
DBX First Quarter 2024 Investor PresentationDBX First Quarter 2024 Investor Presentation
DBX First Quarter 2024 Investor Presentation
 
Artificial Intelligence Chap.5 : Uncertainty
Artificial Intelligence Chap.5 : UncertaintyArtificial Intelligence Chap.5 : Uncertainty
Artificial Intelligence Chap.5 : Uncertainty
 
Corporate and higher education May webinar.pptx
Corporate and higher education May webinar.pptxCorporate and higher education May webinar.pptx
Corporate and higher education May webinar.pptx
 
Rising Above_ Dubai Floods and the Fortitude of Dubai International Airport.pdf
Rising Above_ Dubai Floods and the Fortitude of Dubai International Airport.pdfRising Above_ Dubai Floods and the Fortitude of Dubai International Airport.pdf
Rising Above_ Dubai Floods and the Fortitude of Dubai International Airport.pdf
 
Cloud Frontiers: A Deep Dive into Serverless Spatial Data and FME
Cloud Frontiers:  A Deep Dive into Serverless Spatial Data and FMECloud Frontiers:  A Deep Dive into Serverless Spatial Data and FME
Cloud Frontiers: A Deep Dive into Serverless Spatial Data and FME
 
Vector Search -An Introduction in Oracle Database 23ai.pptx
Vector Search -An Introduction in Oracle Database 23ai.pptxVector Search -An Introduction in Oracle Database 23ai.pptx
Vector Search -An Introduction in Oracle Database 23ai.pptx
 

Eer case study

  • 1. © Shamkant B. Navathe CC
  • 2. Chapter 4 - Part I Enhanced Entity-Relationship and UML Modeling Copyright © © Shamkant B. Navathe 2004 Ramez Elmasri and Shamkant Navathe. CC
  • 3. Enhanced-ER (EER) Model Concepts  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 Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition Copyright © 2004 Ramez Elmasri and Shamkant Navathe
  • 4. Subclasses and Superclasses (1)  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.  Example: EMPLOYEE/SECRETARY, EMPLOYEE/TECHNICIAN Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition Copyright © 2004 Ramez Elmasri and Shamkant Navathe
  • 5. Subclasses and Superclasses (2)  These are also called IS-A relationships (SECRETARY IS-A EMPLOYEE, TECHNICIAN IS-A EMPLOYEE, …).  Note: An entity that is member of a subclass represents the same real- world entity as some member of the superclass – The Subclass member is the same entity in a distinct specific role – An entity cannot exist in the database merely by being a member of a subclass; it must also be a member of the superclass – A member of the superclass can be optionally included as a member of any number of its subclasses  Example: A salaried employee who is also an engineer belongs to the two subclasses ENGINEER and SALARIED_EMPLOYEE – It is not necessary that every entity in a superclass be a member of some subclass Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition Copyright © 2004 Ramez Elmasri and Shamkant Navathe
  • 6. Attribute Inheritance in Superclass / Subclass Relationships  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 Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition Copyright © 2004 Ramez Elmasri and Shamkant Navathe
  • 7. Specialization  Is the process of defining a set of subclasses of a superclass  The set of subclasses is based upon some distinguishing characteristics of the entities in the superclass  Example: {SECRETARY, ENGINEER, TECHNICIAN} is a specialization of EMPLOYEE based upon job type. – May have several specializations of the same superclass  Example: Another specialization of EMPLOYEE based in method of pay is {SALARIED_EMPLOYEE, HOURLY_EMPLOYEE}. – Superclass/subclass relationships and specialization can be diagrammatically represented in EER diagrams – Attributes of a subclass are called specific attributes. For example, TypingSpeed of SECRETARY – The subclass can participate in specific relationship types. For example, BELONGS_TO of HOURLY_EMPLOYEE Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition Copyright © 2004 Ramez Elmasri and Shamkant Navathe
  • 8. Example of a Specialization Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition Copyright © 2004 Ramez Elmasri and Shamkant Navathe
  • 9. Generalization  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. – We can view {CAR, TRUCK} as a specialization of VEHICLE – Alternatively, we can view VEHICLE as a generalization of CAR and TRUCK Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition Copyright © 2004 Ramez Elmasri and Shamkant Navathe
  • 10. Generalization and Specialization  Diagrammatic notation sometimes used to distinguish between generalization and specialization – Arrow pointing to the generalized superclass represents a generalization – Arrows pointing to the specialized subclasses represent a specialization – We do not use this notation because it is often subjective as to which process is more appropriate for a particular situation – We advocate not drawing any arrows in these situations  Data Modeling with Specialization and Generalization – A superclass or subclass represents a set of entities – Shown in rectangles in EER diagrams (as are entity types) – Sometimes, all entity sets are simply called classes, whether they are entity types, superclasses, or subclasses Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition Copyright © 2004 Ramez Elmasri and Shamkant Navathe
  • 11. Constraints on Specialization and Generalization (1)  If we can determine exactly those entities that will become members of each subclass by a condition, the subclasses are called predicate-defined (or condition-defined) subclasses – Condition is a constraint that determines subclass members – Display a predicate-defined subclass by writing the predicate condition next to the line attaching the subclass to its superclass  If all subclasses in a specialization have membership condition on same attribute of the superclass, specialization is called an attribute defined- specialization – Attribute is called the defining attribute of the specialization – Example: JobType is the defining attribute of the specialization {SECRETARY, TECHNICIAN, ENGINEER} of EMPLOYEE  If no condition determines membership, the subclass is called user-defined – Membership in a subclass is determined by the database users by applying an operation to add an entity to the subclass – Membership in the subclass is specified individually for each entity in the superclass by the user Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition Copyright © 2004 Ramez Elmasri and Shamkant Navathe
  • 12. Constraints on Specialization and Generalization (2)  Two other conditions apply to a specialization/generalization:  Disjointness Constraint: – Specifies that the subclasses of the specialization must be disjointed (an entity can be a member of at most one of the subclasses of the specialization) – Specified by d in EER diagram – If not disjointed, overlap; that is the same entity may be a member of more than one subclass of the specialization – Specified by o in EER diagram  Completeness Constraint: – Total specifies that every entity in the superclass must be a member of some subclass in the specialization/ generalization – Shown in EER diagrams by a double line – Partial allows an entity not to belong to any of the subclasses – Shown in EER diagrams by a single line Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition Copyright © 2004 Ramez Elmasri and Shamkant Navathe
  • 13. Constraints on Specialization and Generalization (3)  Hence, we have four types of specialization/generalization: – Disjoint, total – Disjoint, partial – Overlapping, total – Overlapping, partial  Note: Generalization usually is total because the superclass is derived from the subclasses. Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition Copyright © 2004 Ramez Elmasri and Shamkant Navathe
  • 14. Example of disjoint partial Specialization Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition Copyright © 2004 Ramez Elmasri and Shamkant Navathe
  • 15. Specialization / Generalization Hierarchies, Lattices and Shared Subclasses  A subclass may itself have further subclasses specified on it  Forms a hierarchy or a lattice  Hierarchy has a constraint that every subclass has only one superclass (called single inheritance)  In a lattice, a subclass can be subclass of more than one superclass (called multiple inheritance)  In a lattice or hierarchy, a subclass inherits attributes not only of its direct superclass, but also of all its predecessor superclasses  A subclass with more than one superclass is called a shared subclass  Can have specialization hierarchies or lattices, or generalization hierarchies or lattices  In specialization, start with an entity type and then define subclasses of the entity type by successive specialization (top down conceptual refinement process)  In generalization, start with many entity types and generalize those that have common properties (bottom up conceptual synthesis process)  In practice, the combination of two processes is employed Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition Copyright © 2004 Ramez Elmasri and Shamkant Navathe
  • 16.  The database keeps track of three types of people: Employees , Alumni and students. A person can belong to one ,two or all three of these types. Each person has a name , SSN, sex, address and birth date.  Every employee has a salary and are three types of employees: Faculty , Staff and Student assistants. Each employee belongs to exactly one of these types. For each alumnus , a record of the degree or degrees that he or she earned at the university is kept including the name of the degree , Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition Copyright © 2004 Ramez Elmasri and Shamkant Navathe
  • 17. year granted and the major department. Each student has a major department.  Each faculty has a rank , whereas each staff member has a staff position.Student assistants are classified further as either research assistants or teaching assistants and the percent of time they work is recorded in the database. Research assistants have their research projects stored whereas teaching assistants have the current course they work on. Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition Copyright © 2004 Ramez Elmasri and Shamkant Navathe
  • 18.  Students are further classified as either graduate or undergraduate with the specific attributes degree program (M.S., Ph.D , M.B.A and so on) and class respectively. Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition Copyright © 2004 Ramez Elmasri and Shamkant Navathe
  • 19. Specialization / Generalization Lattice Example (UNIVERSITY) Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition Copyright © 2004 Ramez Elmasri and Shamkant Navathe
  • 20. Categories (UNION TYPES)  All of the superclass/subclass relationships we have seen thus far have a single superclass  A shared subclass is subclass in more than one distinct superclass/subclass relationships, where each relationships has a single superclass (multiple inheritance)  In some cases, need to model a single superclass/subclass relationship with more than one superclass  Superclasses represent different entity types  Such a subclass is called a category or UNION TYPE  Example: Database for vehicle registration, vehicle owner can be a person, a bank (holding a lien on a vehicle) or a company. – Category (subclass) OWNER is a subset of the union of the three superclasses COMPANY, BANK, and PERSON – A category member must exist in at least one of its superclasses  Note: The difference from shared subclass, which is subset of the intersection of its superclasses (shared subclass member must exist in all of its superclasses). Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition Copyright © 2004 Ramez Elmasri and Shamkant Navathe
  • 21. Example of categories (UNION TYPES) Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition Copyright © 2004 Ramez Elmasri and Shamkant Navathe
  • 22. Formal Definitions of EER Model (1)  Class C: A set of entities; could be entity type, subclass, superclass, category.  Subclass S: A class whose entities must always be subset of the entities in another class, called the superclass C of the superclass/subclass (or IS-A) relationship S/C: S⊆C  Specialization Z: Z = {S1, S2,…, Sn} a set of subclasses with same superclass G; hence, G/Si a superclass relationship for i = 1, …., n. – G is called a generalization of the subclasses {S1, S2,…, Sn} – Z is total if we always have: S1 ∪ S2 ∪ … ∪ Sn = G; Otherwise, Z is partial. – Z is disjoint if we always have: Si ∩ S2 empty-set for i ≠ j; Otherwise, Z is overlapping. Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition Copyright © 2004 Ramez Elmasri and Shamkant Navathe
  • 23. Formal Definitions of EER Model (2)  Subclass S of C is predicate defined if predicate p on attributes of C is used to specify membership in S; that is, S = C[p], where C[p] is the set of entities in C that satisfy p  A subclass not defined by a predicate is called user-defined  Attribute-defined specialization: if a predicate A = ci (where A is an attribute of G and ci is a constant value from the domain of A) is used to specify membership in each subclass Si in Z  Note: If ci ≠ cj for i ≠ j, and A is single-valued, then the attribute-defined specialization will be disjoint.  Category or UNION type T – A class that is a subset of the union of n defining superclasses D1, D2,…Dn, n>1: T ⊆ (D1 ∪ D2 ∪ … ∪ Dn) A predicate pi on the attributes of T. – If a predicate pi on the attributes of Di can specify entities of Di that are members of T. – If a predicate is specified on every Di: T = (D1[p1] ∪ D2[p2] ∪…∪ Dn[pn] – Note: The definition of relationship type should have 'entity type' replaced with 'class'. Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition Copyright © 2004 Ramez Elmasri and Shamkant Navathe
  • 24. UML Example for Displaying Specialization / Generalization Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition Copyright © 2004 Ramez Elmasri and Shamkant Navathe
  • 25. Alternative Diagrammatic Notations Symbols for entity type / class, Displaying attributes attribute and relationship Notations for displaying Various (min, Displaying specialization / generalization max) notations cardinality ratios Elmasri and Navathe, Fundamentals of Database Systems, Fourth Edition Copyright © 2004 Ramez Elmasri and Shamkant Navathe