Enhanced Entity Relation (EER) Enhanced Entity Relation (EER) DiagramsDiagrams

Chapter 4 Almasri & Navathe Chapter 4 Almasri & Navathe bookbook

(Section 4.8 Knowledge Representation is excluded)

Fundamentals of Data ModelingFundamentals of Data Modeling

1 Inputs to Data Modeling1 Inputs to Data Modeling2 The Process of Modeling2 The Process of Modeling3 Data Modeling Abstractions3 Data Modeling Abstractions4 Classification4 Classification5 Aggregation5 Aggregation6 Identification6 Identification7 7 GeneralisationGeneralisation8 Coverage Constraints in 8 Coverage Constraints in GeneralisationGeneralisation9 Cardinality and Participation 9 Cardinality and Participation ConstraintsConstraints

Inputs to Data ModelingInputs to Data Modeling

Using the products of Using the products of requirements analysisrequirements analysis

Verbal and written Verbal and written communication among users communication among users and designersand designers

Knowledge of meaning of dataKnowledge of meaning of data– Existing ProgramsExisting Programs– Existing FilesExisting Files– Existing DocumentsExisting Documents– Existing ReportsExisting Reports

Application Planning / Application Planning / Documentation and DesignDocumentation and Design

Overall Process of ModelingOverall Process of Modeling

AbstractionAbstraction

Use of some modeling discipline Use of some modeling discipline (Data Model)(Data Model)

Use of a representation techniqueUse of a representation technique

– LanguageLanguage– DiagrammingDiagramming– ToolsTools

Analysis of business rules/semantic Analysis of business rules/semantic constraints (these are typically constraints (these are typically beyond the capability of the data beyond the capability of the data model)model)

Types of AbstractionsTypes of Abstractions

ClassificationClassification A is a A is a member of member of class Bclass B

AggregationAggregation B,C,D are aggregated into B,C,D are aggregated into AA

A is A is made ofmade of//composed of composed of B,C,DB,C,D

GeneralisationGeneralisation B,C,D can be B,C,D can be generalised into Ageneralised into A, , B B is-anis-an A, C A, C is- anis- an A, D A, D is-anis-an A A

SpecialisationSpecialisation A can be specialised into A can be specialised into B,C,DB,C,D B,C,D (special cases of A)B,C,D (special cases of A)

Classification AbstractionClassification Abstraction Relationship between a class and its Relationship between a class and its

membersmembers

John Smith, Sheela Patel, and Peter Wang are John Smith, Sheela Patel, and Peter Wang are all employees. They are all members of a all employees. They are all members of a class: EMPLOYEE classclass: EMPLOYEE classEMPLOYEE

John Smith Peter Wang

Sheela Patel

Each individual employee is a member of the class EMPLOYEE

Classification Abstraction Classification Abstraction (contd.)(contd.)

MONTH

January DecemberFebruary

January, February etc. are members of the class “MONTH”Represents “member-of” relationship

In object-oriented modeling :MONTH : an Object type or classJanuary … December : objects that belong to class MONTH

Exhaustive enumeration of members:

Classification - Class PropertiesClassification - Class Properties

Collection of similar entities or Collection of similar entities or concepts into a higher level conceptconcepts into a higher level concept

EMPLOYEE class collects all employees EMPLOYEE class collects all employees into one classinto one class

A class has properties called “class A class has properties called “class properties”properties”

EMPLOYEE class has EMPLOYEE class has class propertiesclass properties - e.g., average salary, total number of - e.g., average salary, total number of employeesemployees

Each member has values for own Each member has values for own properties (e.g. name, address, properties (e.g. name, address, salary): called salary): called member propertiesmember properties

Aggregation AbstractionAggregation Abstraction

Defines a new class from a set of classes which Defines a new class from a set of classes which are identified as are identified as components of components of the root classthe root class

CAR

Chasis OtherSystems

Drive-train

represents IS-PART-OF (component) relationshipRoot class: CARComponent Classes: Chassis, Drive-Train, Other Systems, WheelsRoot class: WheelsComponent Classes: Tires, Tubes, Hub-Caps

Wheels

Tires Hub-CapsTubes

Classification and AggregationClassification and Aggregation

Classification and Aggregation are used to build Classification and Aggregation are used to build schemasschemas

Person

NameSex

Example: class PersonRepresentation:

Position

Ram John Carlos Male Female Manager EmployeeName, Sex, and Position aggregate into Person. They are classes themselves.Ram, John, Carlos are classified into Name or Name is a classification of Ram, John, Carlos

Two Contexts for AggregationTwo Contexts for Aggregation

Aggregate two or more classes into a Aggregate two or more classes into a higher level concept. It may be higher level concept. It may be considered a relationship or considered a relationship or association between them.association between them.

Context1: CAR is an aggregate Context1: CAR is an aggregate ((compositioncomposition) of Chassis, Drive-train, ) of Chassis, Drive-train, Other Systems, Wheels.Other Systems, Wheels.

Context 2: OWNERSHIP is an Context 2: OWNERSHIP is an aggregate (aggregate (relationshiprelationship) of CAR and ) of CAR and OWNEROWNER OWNERSHIP

CAR OWNER

IdentificationIdentification

Identifies one concept (an instance of it) from Identifies one concept (an instance of it) from another concept.another concept.

BUILDING

ROOM

Name

Number

Identifies

Data Abstraction (contd.)Data Abstraction (contd.)

Process of hiding (suppressing) unnecessary details Process of hiding (suppressing) unnecessary details so that the high level concept can be made more so that the high level concept can be made more visible.visible.

This enables programmers, designers, etc., To This enables programmers, designers, etc., To communicate easily and to understand the communicate easily and to understand the application’s data and functional requirements application’s data and functional requirements easily.easily.

TYPES OF ABSTRACTIONTYPES OF ABSTRACTION

Classification:Classification: IS-A-MEMBER-OFIS-A-MEMBER-OF Aggregation:Aggregation: IS-MADE-OF, IS-ASSOCIATED-WITHIS-MADE-OF, IS-ASSOCIATED-WITHComposition:Composition: IS-MADE-OF (similar to IS-MADE-OF (similar to aggregation)aggregation) (A COMPRISES B,C,D)(A COMPRISES B,C,D)IdentificationIdentification:: IS-IDENTIFIED-BYIS-IDENTIFIED-BY Generalisation:Generalisation: IS-AIS-A IS-LIKEIS-LIKE IS-KIND-OFIS-KIND-OF

Cardinality ConstraintsCardinality Constraints

Cardinality Constraint: Cardinality Constraint: Quantification of the Quantification of the relationship between two concepts or classes (a relationship between two concepts or classes (a constraint on aggregation)constraint on aggregation)

MINIMUM (A,B) = nMINIMUM (A,B) = n

At a minimum, one instance of A is related to at least n At a minimum, one instance of A is related to at least n instances of B.instances of B.

n = 0n = 0 MIN(A,B) = 0MIN(A,B) = 0 MIN(Person, Car) = 0MIN(Person, Car) = 0

n = 1n = 1 MIN(A,B) = 1MIN(A,B) = 1 MIN(Cust, Ship-address) = MIN(Cust, Ship-address) = 11

n = inf.n = inf. Min (A,B) = inf.Min (A,B) = inf. Not possibleNot possible

n = x (fixed)n = x (fixed) MIN(A,B) = xMIN(A,B) = x MIN(Car, Wheels) = 4MIN(Car, Wheels) = 4

Cardinality Constraints (contd.)Cardinality Constraints (contd.)

MAXIMUM (A,B) = nMAXIMUM (A,B) = n

At a maximum, one instance of A is related to At a maximum, one instance of A is related to at most n instances of B.at most n instances of B.

n = 0n = 0 MAX(A,B) = 0MAX(A,B) = 0 DOES NOT ARISEDOES NOT ARISE

n = 1n = 1 MAX(A,B) = 1 MAX(A,B) = 1 MAX(Cust, Ship-address) MAX(Cust, Ship-address) = 1= 1

n = inf.n = inf. MAX(A,B) = inf.MAX(A,B) = inf. MAX(Cust, Orders) = inf.MAX(Cust, Orders) = inf.

n = x (fixed)n = x (fixed) MAX(A,B) = xMAX(A,B) = x MAX(Stud, Course) = 6MAX(Stud, Course) = 6

Participation ConstraintsParticipation Constraints

MIN (A,B) = 0MIN (A,B) = 0 Optional ParticipationOptional Participation

MIN (A,B) = 1MIN (A,B) = 1 Mandatory ParticipationMandatory Participation

MAX (A,B) = 0MAX (A,B) = 0 No ParticipationNo Participation

MIN (A,B) = x, MAX (A,B) = y Range MIN (A,B) = x, MAX (A,B) = y Range Constrained Constrained

ParticipationParticipation

What is an EER Model?What is an EER Model?

Enhanced Entity Relationship (EER) – Enhanced Entity Relationship (EER) – Data ModelingData Modeling

EER shows complex relationships EER shows complex relationships between objects in a database between objects in a database (multimedia, geographical).(multimedia, geographical).

Concepts of subclasses and Concepts of subclasses and superclasses, specialisations and superclasses, specialisations and generalisations.generalisations.

Put concepts in diagram to form EER Put concepts in diagram to form EER modelmodel

Model ShapesModel Shapes

When you have more than one subclass When you have more than one subclass based on the same defining attribute based on the same defining attribute ((JobTypeJobType), use), use

To show class/subclass relationships, To show class/subclass relationships, useuse

Used for relationships between entity types Used for relationships between entity types To show relationship between two To show relationship between two

different entity types, usedifferent entity types, use

U

Model Shapes (Cont.)Model Shapes (Cont.) Entities, Entities,

AttributesAttributes

We classify entities according to their type:We classify entities according to their type:Strong EntityStrong Entity

Weak Entity:Entity sets that are not uniquely Weak Entity:Entity sets that are not uniquely identified by their attributesidentified by their attributes

A weak entity set has an "identifying A weak entity set has an "identifying relationship" with an entity set that is the relationship" with an entity set that is the "identifying owner" of the weak entity set"identifying owner" of the weak entity set

Student Lecture

Dependants

Subclasses and Superclasses Subclasses and Superclasses of Entity Typesof Entity Types

EMPLOYEEEMPLOYEE SECRETARY, ENGINEER,SECRETARY, ENGINEER,

MANAGERMANAGER

superclasssuperclass subclasssubclass of entity type of entity type EMPLOYEEEMPLOYEE

superclass/subclass relationshipsuperclass/subclass relationship

class/subclassclass/subclass

EMPLOYEE/ENGINEEREMPLOYEE/ENGINEER

Each member of subclass is a member of its superclassEach member of subclass is a member of its superclass Not all elements in superclass need to be in subclassNot all elements in superclass need to be in subclass

Type inheritanceType inheritance

Subclass entities inherit Subclass entities inherit attributes/relationships of superclass entityattributes/relationships of superclass entity

++ Own specific (local) attributes/relationshipsOwn specific (local) attributes/relationships

Avoid describing similar concepts more Avoid describing similar concepts more than oncethan once

Add more semantic information to designAdd more semantic information to design

SpecialisationSpecialisation

Subgrouping into subclasses (top-down Subgrouping into subclasses (top-down approach)approach)

Example: EMPLOYEE -> SECRETARY Example: EMPLOYEE -> SECRETARY MANAGER, etc.MANAGER, etc.

Inheritance – Inherit attributes and Inheritance – Inherit attributes and relationships from superclass (Name, relationships from superclass (Name, Birthdate, etc.)Birthdate, etc.)

Subclasses may have unique attributesSubclasses may have unique attributes SECRETARY has TypingSpeed attribute, SECRETARY has TypingSpeed attribute,

MANAGER has BusinessUnitManaged, etc.MANAGER has BusinessUnitManaged, etc.

Specialisation (cont.)Specialisation (cont.)

EMPLOYEE

SSN Name

WORKS_IN

DEPARTMENT

d

SECRETARY ENGINEERd

SALARY_EMP. HOURLY_EMP.

JobType PayMethod

U

U

U

U

SOFTWARE_ENGINEER

U

Primary key attribute are underlined

GeneralisationGeneralisationReverse processes of defining subclasses (bottom-Reverse processes of defining subclasses (bottom-

up approach)up approach) Bring together common attributes in entitiesBring together common attributes in entities Example: CAR (with attributes color, Nopass, max Example: CAR (with attributes color, Nopass, max

speed) and Truck (with attributes price, NoAxles) speed) and Truck (with attributes price, NoAxles) can be generalised into VEHICLE (with attributes can be generalised into VEHICLE (with attributes color and price).color and price).

VEHICLE

TRUCKCAR

Nopass

Maxspeed

NoAxles

VehID

Tonnage

d

price

ConstraintsConstraints

Disjoint – an entity can be a member of at Disjoint – an entity can be a member of at most one subclass of a specializationmost one subclass of a specialization

Overlap – an entity may belong to more Overlap – an entity may belong to more than one subclass of a specializationthan one subclass of a specialization

Total specialisation – each entity of a Total specialisation – each entity of a superclass belongs to some subclass of a superclass belongs to some subclass of a specialisationspecialisation

Partial specialization – each entity of a Partial specialization – each entity of a superclass does not have to belong to superclass does not have to belong to some subclass of a specialisationsome subclass of a specialisation

d

o

Partial categoryPartial category

PERSON COMPANY

ACCOUNT_HOLDER

u

Address

Tel

NameBAddress

BName

Tel

Fax

Total categoryTotal category

Every occurrence of superclass must appear in the Every occurrence of superclass must appear in the categorycategory

Better represented as specialisation (share many Better represented as specialisation (share many attributes and keys)attributes and keys)

SALE RENT

PROPERTY

u

Address

Rent

Type

ClosingDate

SellingPrice

IDP

Hierarchies and LatticesHierarchies and Lattices

Hierarchy – subclass participates in one Hierarchy – subclass participates in one class/subclass relationshipclass/subclass relationship

EMPLOYEE

ENGINEERSECRETARY

SOFTWARE ENGINEER

SOFTWARE ENGINEER has all the attributes of an ENGINEER and EMPLOYEE

U

U

U

Hierarchies and LatticesHierarchies and Lattices

Lattice – subclass participates in more than one Lattice – subclass participates in more than one class/subclass relationshipclass/subclass relationship

EMPLOYEE

ENGINEERSECRETARY

ENGINEERING MANAGER

MANAGER

ENGINEERING MANAGER (shared subclass) is a MANGER and an ENGINEER

U

U

UU

U

Union Types/CategoriesUnion Types/Categories Models a class/subclass with more than Models a class/subclass with more than

one superclass of one superclass of distinctdistinct entity types. entity types. Attribute inheritance is selective.Attribute inheritance is selective.

PERSON BANK COMPANY

U

OWNER

The category, OWNER, is a subclass of the union of PERSON, BANK, and COMPANY. OWNER is either a PERSON or a BANK or a COMPANY

U

Mathematical NotationMathematical Notation

Super/Subclass Relationship Super/Subclass Relationship • subclass: subclass: SS, superclass: , superclass: CC• ((SS is part of is part of CC))• IS-A relationship: an entity in IS-A relationship: an entity in SS is also in is also in CC

Specialization/Generalization Specialization/Generalization • a set of subclasses: a set of subclasses: Z Z { {SS11, , SS22, .. , , .. , SSnn}}• a superclass: a superclass: GG ((SSii) ) GG

Mathematical NotationMathematical Notation

Constraints Constraints • Total: U (Total: U (SSii) ) GG

• Partial: U (Partial: U (SSii) ) GG

• Disjoint: Disjoint: SSii SSjj (empty set) for i (empty set) for i j j

• Overlap: Overlap: SSii SSjj (empty set) for i (empty set) for i j j

CategorisationCategorisation• a set of superclasses: (a set of superclasses: (DD11, , DD22, .. , , .. , DDnn))

• TT ( (DD11, , DD22, .. , , .. , DDnn))

Conceptual Object ModelingConceptual Object Modeling

Object Modeling MethodologiesObject Modeling Methodologies• in software engineering: UML, OMT, …in software engineering: UML, OMT, …• specify specify operationsoperations applied to objects (entities) applied to objects (entities)• class = entity type (attributes) + operationsclass = entity type (attributes) + operations

Object Modeling Concepts (vs. EER)Object Modeling Concepts (vs. EER)• class: entity type, object: entityclass: entity type, object: entity• association (link): relationship (rel. instance)association (link): relationship (rel. instance)• multiplicity: relationship constraintmultiplicity: relationship constraint

4-33.14-33.1 3434

classname

attributes

compositeattributes

operations

domain

qualifiedaggregation

(identifyingrelationship)

Multiplicities min..max (* : no maximum limit)(relationship constraints) association(relationship types)

link attribute(relationship attribute)

role

role

reflexiveassociation(recursive relationship)

multivaluedattributeis modeleda class

a relationship between a whole object and its component parts

4-33.24-33.2 3535

generalization / specialization

overlapping

disjoint

4-344-34 3636

Relationships of Higher Relationships of Higher DegreeDegree

Relationship types of degree 2 are Relationship types of degree 2 are called called binarybinary

Relationship types of degree 3 are Relationship types of degree 3 are called called ternaryternary and of degree n are and of degree n are called called n-aryn-ary

In general, an n-ary relationship In general, an n-ary relationship is notis not equivalent to n-binary relationshipsequivalent to n-binary relationships

EER vs. UML TerminologyEER vs. UML Terminology

UML Class DiagramUML Class Diagram ClassClass ObjectObject AttributeAttribute DomainDomain Structured DomainStructured Domain OperationOperation AssociationAssociation LinkLink MultiplicitiesMultiplicities

EER DiagramEER Diagram Entity TypeEntity Type EntityEntity AttributeAttribute DomainDomain Composite AttributeComposite Attribute ~ [Derived Attribute]~ [Derived Attribute] Relationship TypeRelationship Type Relationship InstanceRelationship Instance Cardinality & Cardinality &

ParticipationParticipation

EER Diagram OverviewEER Diagram Overview

EER to UML #1EER to UML #1

EER to UML #2EER to UML #2