EER

New applications of databases require more complex semantic data modeling concepts Many appropriate such new semantic data modeling concepts have been proposed The ER model can be enhanced/extended to include these concepts EER
Classes, Subclasses, Superclasses, Inheritance (familiar concepts from an OOP course) Specialization & Generalization Categories Aggregation & Association

Subclasses, Superclasses, Inheritance

Entity types represent both kinds of entities and sets of entities of that kind that exist in the database (e.g. entity type EMPLOYEE) Often an entity type has different subgroups of its entities that need to be represented explicitly in the database because of their significance (e.g. SECRETARY, ENGINNER, MANAGER, TECHNICIAN ) The set of entities in each of these subgroups is a subset of the EMPLOYEE entity set (every entity that is a member of one of these subgroups is also an EMPLOYEE entity)

 Each of these subgroups is called a subclass of the EMPLOYEE entity type The EMPLOYEE entity type is called the superclass of each of these subclasses The relationship between a superclass and any one of its subclasses is called a superclass/subclass or
class/subclass or IS-A (IS-AN) relationship (e.g. EMPLOYEE/SECRETARY EMPLOYEE/MANAGER)

Member entities of subclasses represent the same real-world object as the corresp. member of the superclass, but in a specific role

An entity in the database must be a member of a superclass entity. It can belong to more than one subclasses.

Entities of a superclass dont have to belong to some subclass Entity types are specified by their attributes and the relationships in which they participate. Subclass entities have their own specific attributes. They also have the same attributes and participate in the same relationships as the superclass The subclass entity inherits all attributes and relationships of its superclass (subclasses can be considered as separate entity types)

Specialization
Defining a set of subclasses of an entity type based on a distinguishing feature An entity type can have several specializations
{permanent faculty, sessional instructor, lab supervisor} {secretary, engineer, technician}

In EER diagrams specializations are represented by the subset symbol placed into lines connecting the subclass entities to a circle, connected to the superclass Subclasses have specific attributes/relationships

Generalization
Inverse process: identify common features between several different entity types, and generalize them into a single superclass. The original entity types become subclasses of the new superclass type. example: CARs TRUCKs == VEHICLEs Because Generalization can be thought of as the inverse of Specialization, we will use the same notation (subset symbol)

Specialization/Generalization Constraints We can have one or more specializations of the same entity type (superclass) Entities of the superclass can belong to entity types (subclasses) of one or more specializations Each specialization can consist of one or more entity types (subclasses) we distinguish 3 types of constraints on spec/tions:
definition-related, disjointness, completeness

predicate-defined subclass: subclass of which the entities are determined by imposing a condition on an attribute of the superclass e.g. JobType=Secretary EMPLOYEE/SECRETARY JobType is called the defining predicate of the subclass SECRETARY This condition must be satisfied by all members of the subclass SECRETARY and all entities of the EMPLOYEE entity type whose attribute value for JobType is Secretary must belong to the subclass
In EER, pred-def subcl. are denoted by placing the predicate condition next to the line subclass/circle

 attribute-defined specialization: the membership condition of all subclasses of a specialization is expressed through the same attribute of the superclass This unique attribute is called defining attribute In EER def-attr are denoted by placing their name next to the line superclass/circle user-defined subclasses: no condition to determine membership. Whether or not an entity belongs to a userdefined subclass is specified by the user

Disjointness Constraint: the subclasses of a specialization must be disjoint An entity can be a member of at most one subclass of the specialization If the defining attribute of a specialization is single-valued, then the disj-constr is satisfied In EER disj-constr is illustrated by placing the letter d inside the circle In case overlap between subclasses is allowed, we place the letter o inside the circle.

 Completeness constraint: total & partial Total specializationevery superclass entity must be a member of some subclass in the spec/tion In EER diagrams total spec/tion is denoted by a double line connecting the superclass and the circle Partial specializationsome superclass entities are allowed not to belong to any subclass in the spec In EER diagrams this is denoted by a single line The disjointness and completeness constraints are independent

Insertion/Deletion rules for Specializations The 3 types of constraints on specializations impose some rules on updates
delete an entity from a superclass insert an entity to a superclass insert an entity to a superclass of total spec/tion

Specialization/Generalization Hierarchies & Lattices

Subclasses might have their own subclasses Specialization Hierarchy: every subclass can have only one superclass Specialization Lattice:a subclass can have more than one superclasses Difference between trees and graphs In a Spec Hierarchy or Lattice, subclasses inherit attributes of all predecessors recursively

Leaf Nodes: classes without any subclasses of their own Shared Subclass: a subclass with more than one superclasses Shared subclasses inherit attributes & relationships from all of their superclasses: Multiple Inheritance The existence of even one shared subclass means we have a lattice Important MI rule: if an attribute is inherited via 2 different paths, then it is included only once

Specialization in conceptual database design

Start with an entity type, define successive specializations PERSON {EMPLOYEE,ALUMNUS,STUDENT} overlapping specialization EMPLOYEE {STAFF, FACULTY,STUDENT_ASSISTANT} STUDENT {GRADUATE,UNDERGRADUATE} STUDENT_ASSISTANT {Research_A,Teaching_A} Top-down conceptual designHierarchy STUDENT_ASSISTANT is a shared subclass Lattice

UNION TYPES, CATEGORIES

So far we have seen superclass/subclass relationships with only one superclass Sometimes we need to model a superclass/subclass relationshop with more than one superclasses The superclasses represent different entity types In this case, the subclass will be a subset of the UNION of distinct entity types Such a subclass is called a Union Type or Category Example: PERSON, BANK,COMPANY,OWNER

In EER diagrams union types (categories) are denoted by placing the letter U inside the circle and the subset symbol on the line connecting the subclass with the circle Differences between union types & shared subclasses
An entity of a shared subclass must exist in all superclasses An entity of a union type must exist in only one superclass Entities in shared subclasses inherit attributes of all superclasses Entities in union types inherit attributes of only one superclass Total Categories & Partial Categories

Higher-degree relationships
Degree 2, binary relationships Degree 3,4, higher-degree relationships A ternary relationship can be described by 3 binary relationships which of these two alternatives represents more information? Example 1: Ternary relationship SUPPLY (s,p),(j,p),(s,j) does not imply (s,j,p) Example 2: Ternary relationship OFFERS (i,s),(s,c),(i,c) does not imply (i,s,c)

Constraints on Higher-Degree Relationships Ternary relationship instances ( instr, semest, course) must imply the corresp. 3 binary relationship instances (i,s),(s,c),(i,c) The opposite, can be made true by imposing certain additional constraints (CAN_TEACH 1:1) Cardinality constraints for higher degree relationships (display 1,N,M on each line)

Aggregation
A relationship set is an ass/tion between entity sets Sometimes we want to model a relationship between a collection of entities and relationships Entities Project, Department, Employee
Each Project is sponsored by one or more Departments A dpt that Sponsors a project assigns employees to monitor Monitors is a relationship among Sponsors rel and an employee

Aggregation allows us to indicate that a rel/ship set (enclosed in a dashed box) participates in another one

 Alternatively, can we express the Monitors relationship by making Sponsors a ternary relationship? Monitors and Sponsors are really two distinct relationships with different attributes Attribute until of the Monitors relationship Attribute since of the Sponsors relationship

Conceptual Database Design with ER/EER

Should a concept be modeled as an entity or an attribute? Should a concept be modeled as an entity or a relationship? What are the key attributes of the entity types? What are the relationships and their participating entities? Should we use binary or ternary relationships? Should we use aggregation? Should we use specialization? Are there any shared subclasses? What are the cardinality ratios of the binary relationships?