Enhanced Entity Relation (EER) Diagrams Chapter 4 Almasri & Navathe book

(Section 4.8 Knowledge Representation is excluded)

Fundamentals of Data Modeling

1 2 3 4 5 6 7 8 9 Inputs to Data Modeling The Process of Modeling Data Modeling Abstractions Classification Aggregation Identification Generalisation Coverage Constraints in Generalisation Cardinality and Participation Constraints

Inputs to Data Modeling

q

Using the products of requirements analysis Verbal and written communication among users and designers Knowledge of meaning of data

Existing Programs Existing Files Existing Documents Existing Reports

Application Planning / Documentation and Design

Overall Process of Modeling

q q q

Abstraction Use of some modeling discipline (Data Model) Use of a representation technique

Language Diagramming Tools

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

Types of Abstractions
Classification A is a member of class B Aggregation B,C,D are aggregated into A A is made of/composed of B,C,D

Generalisation B,C,D can be generalised into A, B is-an A, C is- an A, D is-an A Specialisation A can be specialised into B,C,D B,C,D (special cases of A)

Classification Abstraction
q

Relationship between a class and its members John Smith, Sheela Patel, and Peter Wang are all employees. They are all members of a class: EMPLOYEE class

EMPLOYEE John Smith Sheela Patel Peter Wang

Each individual employee is a member of the class EMPLOYEE

Classification Abstraction (contd.)

Exhaustive enumeration of members: MONTH January February December

January, February etc. are members of the class MONTH

Represents member-of relationship

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

Classification - Class Properties

q

Collection of similar entities or concepts into a higher level concept EMPLOYEE class collects all employees into one class A class has properties called class properties EMPLOYEE class has class properties - e.g., average salary, total number of employees Each member has values for own properties (e.g. name, address, salary): called member properties

q q q

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

CAR Chasis Drive-train Other Systems Tires Wheels Tubes Hub-Caps

represents IS-PART-OF (component) relationship

Root class: CAR Component Classes: Chassis, Drive-Train, Other Systems, Wheels Root class: Wheels Component Classes: Tires, Tubes, Hub-Caps

Classification and Aggregation

Classification and Aggregation are used to build schemas

Example: class Person Representation:

Person Name Ram John Carlos Sex Male Female Position

Manager Employee

Name, 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 Aggregation

Aggregate two or more classes into a higher level concept. It may be considered a relationship or association between them. Context1: CAR is an aggregate (composition) of Chassis, Drive-train, Other Systems, Wheels. Context 2: OWNERSHIP is an aggregate (relationship) of CAR and OWNER

OWNERSHIP

CAR

OWNER

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

BUILDING Identifies ROOM

Name

Number

Data Abstraction (contd.)

Process of hiding (suppressing) unnecessary details so that the high level concept can be made more visible. This enables programmers, designers, etc., To communicate easily and to understand the applications data and functional requirements easily. TYPES OF ABSTRACTION Classification: IS-A-MEMBER-OF Aggregation: IS-MADE-OF, IS-ASSOCIATED-WITH Composition: IS-MADE-OF (similar to aggregation) (A COMPRISES B,C,D) Identification: IS-IDENTIFIED-BY Generalisation: IS-A IS-LIKE IS-KIND-OF

Cardinality Constraints
Cardinality Constraint: Quantification of the relationship between two concepts or classes (a constraint on aggregation) MINIMUM (A,B) = n
At a minimum, one instance of A is related to at least n instances of B. n=0 n=1 n = inf. MIN(A,B) = 0 MIN(A,B) = 1 Min (A,B) = inf. MIN(Person, Car) = 0 MIN(Cust, Ship-address) = 1 Not possible MIN(Car, Wheels) = 4

n = x (fixed) MIN(A,B) = x

Cardinality Constraints (contd.)

MAXIMUM (A,B) = n
At a maximum, one instance of A is related to at most n instances of B.
n=0 n=1 n = inf. MAX(A,B) = 0 MAX(A,B) = 1 DOES NOT ARISE MAX(Cust, Ship-address) = 1

MAX(A,B) = inf. MAX(Cust, Orders) = inf. MAX(Stud, Course) = 6

n = x (fixed) MAX(A,B) = x

Participation Constraints

MIN (A,B) = 0 MIN (A,B) = 1 MAX (A,B) = 0

Optional Participation Mandatory Participation No Participation

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

What is an EER Model?

Enhanced

Modeling EER shows complex relationships between objects in a database (multimedia, geographical). Concepts of subclasses and superclasses, specialisations and generalisations. Put concepts in diagram to form EER model

Entity Relationship (EER) Data

Model Shapes
When

you have more than one subclass based on the same defining attribute (JobType), use To show class/subclass relationships, use
Used

for relationships between entity types

To

show relationship between two different entity types, use

Model Shapes (Cont.)

Entities, Attributes

We

classify entities according to their type:

Strong

Entity

Weak

Entity:Entity sets that are not uniquely identified by their attributes A weak entity set has an "identifying relationship" with an entity set that is the "identifying owner" of the weak entity set

Student

Lecture

Dependants

Subclasses and Superclasses of Entity Types

EMPLOYEE MANAGER SECRETARY, ENGINEER,

superclass subclass of entity type EMPLOYEE superclass/subclass relationship class/subclass EMPLOYEE/ENGINEER

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

Type inheritance
Subclass

entities inherit attributes/relationships of superclass entity + Own specific (local) attributes/relationships

Avoid

describing similar concepts more than once Add more semantic information to design

Specialisation
Subgrouping into subclasses (top-down approach) Example: EMPLOYEE -> SECRETARY MANAGER, etc. Inheritance Inherit attributes and relationships from superclass (Name, Birthdate, etc.) Subclasses may have unique attributes
SECRETARY

has TypingSpeed attribute, MANAGER has BusinessUnitManaged, etc.

Specialisation (cont.)
Primary key attribute are underlined SSN Name EMPLOYEE JobType d PayMethod WORKS_IN

U
ENGINEER d

DEPARTMENT

SECRETARY

SOFTWARE_ENGINEER

U
U

U
SALARY_EMP.

U
HOURLY_EMP.

Generalisation
Reverse processes of defining subclasses (bottomup approach) Bring together common attributes in entities Example: CAR (with attributes color, Nopass, max speed) and Truck (with attributes price, NoAxles) can be generalised into VEHICLE (with attributes color and price).
price

VEHICLE
d

VehID

Nopass CAR
Maxspeed

NoAxles

TRUCK
Tonnage

Constraints
Disjoint

an entity can be a member of at most one subclass of a specialization d Overlap an entity may belong to more than one subclass of a specialization o Total specialisation each entity of a superclass belongs to some subclass of a specialisation Partial specialization each entity of a superclass does not have to belong to some subclass of a specialisation

Partial category
Fax Address PERSON u Tel Name
ACCOUNT_ HOLDER

COMPANY Tel

BName BAddress

Total category
Selling Price

Type SALE RENT u

Closing Date

Rent

IDP

PROPERTY

Address

Every occurrence of superclass must appear in the category Better represented as specialisation (share many attributes and keys)

Hierarchies and Lattices

Hierarchy subclass participates in one class/subclass relationship

EMPLOYEE
SOFTWARE ENGINEER has all the attributes of an ENGINEER and EMPLOYEE

SECRETARY

U
ENGINEER

U
SOFTWARE ENGINEER

Hierarchies and Lattices

Lattice subclass participates in more than one class/subclass relationship

EMPLOYEE

SECRETARY

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

ENGINEER

U
U
U

MANAGER

ENGINEERING MANAGER

Union Types/Categories
Models

a class/subclass with more than one superclass of distinct entity types. 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

Mathematical Notation
Super/Subclass

Relationship

subclass: S, superclass: C (S is part of C) IS-A relationship: an entity in S is also in C

Specialization/Generalization

a set of subclasses: Z = {S1, S2, .. , Sn}

a superclass: G (Si) G

Mathematical Notation
Constraints

Total: U (Si) = G Partial: U (Si) G Disjoint: Si Sj = (empty set) for i j Overlap: Si Sj (empty set) for i j a set of superclasses: (D1, D2, .. , Dn) T (D1, D2, .. , Dn)

Categorisation

Conceptual Object Modeling

Object

Modeling Methodologies

in software engineering: UML, OMT, specify operations applied to objects (entities) class = entity type (attributes) + operations

Object

Modeling Concepts (vs. EER)

class: entity type, object: entity association (link): relationship (rel. instance) multiplicity: relationship constraint

Multiplicities limit) class name attributes composite attributes operations domain

link attribute (relationship attribute) role role reflexive association (recursive relationship)

min..max (* : no maximum

(relationship constraints)

association
(relationship types)

qualified aggregation (identifying relationshi p)

multivalue attribute is modeled a class

4-33.1

a relationship between a whole object and its component parts 34

generalization / specialization overlapping

disjoint

4-33.2

35

Relationships of Higher Degree

Relationship

types of degree 2 are called binary Relationship types of degree 3 are called ternary and of degree n are called n-ary In general, an n-ary relationship is not equivalent to n-binary relationships
4-34 36

EER vs. UML Terminology

UML Class Diagram Class Object Attribute Domain Structured Domain Operation Association Link Multiplicities

EER Diagram Entity Type Entity Attribute Domain Composite Attribute ~ [Derived Attribute] Relationship Type Relationship Instance Cardinality & Participation

EER Diagram Overview

EER to UML #1

EER to UML #2