enhanced erd

Download Enhanced Erd

Post on 20-Jan-2016




0 download

Embed Size (px)


erd 10


  • Enhanced E-R Model andBusiness RulesCS263 Lecture 4

  • IntroductionThe basic ER model was introduced in the mid 1970sSince then business relationships and business data have become more complexThe term Enhanced Entity Relationship (EER) model refers to the extension of the original ER model

  • Supertype/Subtype relationshipsMost important new modelling construct in the EER modelAllows us to model a general entity type (the supertype) and then subdivide it into several specialised entity types (called subtypes)Each subtype inherits from its supertype and may have special attributes of its own

  • Representing supertypes and subtypesThe supertype is connected with a line to a circle, which in turn is connected by a line to each subtype that has been defined (see Fig.)The U shaped symbol on each line connecting a subtype to the circle indicates that the subtype is a subset of the supertype, and also indicates the direction of the relationshipAttributes shared by all the entities are associated with the supertype, whilst attributes that are unique to a particular subtype are associated with that subtype

  • Basic notation for supertype/subtype relationships

  • An example: the EMPLOYEE supertypeSuppose that an organisation has 3 basic types of employees:Hourly: Employee_Number, Employee_Name, Address, Date_Hired, Hourly_RateSalaried: Employee_Number, Employee_Name, Address, Date_Hired, Annual_Salary, Stock_OptionContract consultants: Employee_Number, Employee_Name, Address, Date_Hired, Contract_Number, Billing_Rate

  • Employee supertypeMany attributes the same across 3 types, so we could define a supertype called EMPLOYEE, with subtypes for HOURLY_EMPLOYEE, SALARIED_EMPLOYEE and CONSULTANT (see Fig)

  • Employee supertype with three subtypesAll employee subtypes will have emp_no., name, address, and date-hiredEach employee subtype will also have its own attributes

  • When to use supertype/subtype relationsShould consider using subtypes when either (or both) of the following conditions are present:1. There are attributes that apply to some (but not all) of the instances of an entity type2. The instances of a subtype participate in a relationship unique to that subtypeBoth are true in the following Fig., where PATIENT has two subtypes: OUTPATIENT and RESIDENT PATIENT (the primary key is PATIENT_ID)All patients have an Admit_Date and a Patient_Name

  • Patient exampleEvery patient is cared for by a RESPONSIBLE_PHYSICIAN who develops a treatment plan for the patientEach subtype also has unique attributes. Outpatients have a Checkback_Date, whilst residents have a Date_Discharged and a unique relationship that assigns each patient to a bed (this is a mandatory relationship, and each bed may or may not be assigned to a patient)

  • Supertype/subtype relationships of patientsBoth outpatients and resident patients are cared for by a responsible physicianOnly resident patients are assigned to a bed

  • Generalization and specializationGeneralization: = the process of defining a more general entity type from a set of more specialized entity types. BOTTOM-UPSpecialization = the process of defining one or more subtypes of the supertype, and forming supertype/subtype relationships. TOP-DOWNFollowing Figs. Shows Generalisation in a situation where we have 3 different entity types: CAR, TRUCK and MOTORCYCLEIn second Fig. The more general entity type VEHICLE is shown

  • GeneralisationMOTORCYCLE is not shown as it does not satisfy conditions for a subtype discussed earlier the only attributes of MOTORCYCLE are those that are common to all vehicles, there are no attributes specific to motorcycles. Further, MOTORCYCLE does not have a relationship to another entity type

  • Example of generalizationThree entity types: CAR, TRUCK, and MOTORCYCLEAll these types of vehicles have common attributes

  • Generalization to VEHICLE supertypeSo we put the shared attributes in a supertypeNote: no subtype for motorcycle, since it has no unique attributes

  • SpecialisationIn an example of specialisation, an entity type PART has identifier Part_No and other attributes Description, Unit_price, Location, Qty_On_Hand, Routing_Number and Supplier (a multivalued attribute as there may be more than one supplier)Some parts are internally Manufactured Parts whilst others are externally Purchased Parts (some parts are obtained from both sources when the choice depends on factors such as manufacturing capacity, unit price of the parts etc.)

  • SpecialisationSome attributes apply to all parts regardless of source, others such as Routing_Number depend on the source as they apply only to Manufactured Parts. This suggests that PART should be specialised by defining the subtypes MANUFACTURED_PART and PURCHASED_PARTA new relationship Supplies has been created between PURCHASED_PART and SUPPLIER that allows users to more easily associate purchased parts with their suppliersThe attribute Unit_Price is now associated with the relationship Supplies so that the price may vary between suppliers

  • Example of specializationEntity type PART

    Only applies to manufactured partsApplies only to purchased parts

  • Specialization to MANUFACTURED PART and PURCHASED PARTCreated 2 subtypes

  • Completeness constraintsWhether an instance of a supertype must also be a member of at least one subtype. Has two possible rules:1:Total Specialization Rule: Yes (double line) In following Fig. A PATIENT must either be an OUTPATIENT or a RESIDENT PATIENT. Total specialisation is indicated by the double line extending from the PATIENT identity type to the circle

  • Examples of completeness constraintsTotal specialization rule

  • Completeness constraintsPartial Specialization Rule: No (single line) An entity instance of the supertype is allowed not to belong to any subtype. In the following Fig. If a VEHICLE is a car it will appear as an instance of CAR, and if a truck as an instance of TRUCK. However, if the vehicle is a motorcycle it cannot appear as an instance of any subtype. This example of partial specialisation is specified by the single line from the VEHICLE supertype to the circle

  • Partial specialization rule

  • Disjointness constraintWhether an instance of a supertype may simultaneously be a member of two (or more) subtypes. Has two possible rules:Disjoint Rule: An instance of the supertype can be only ONE of the subtypes. Following Fig. shows that at any one time a PATIENT must be either an outpatient or a resident patient but cannot be both specified by the letter dThe subclass of a patient may change over time, but at any given time a patient is of only one type

  • Disjoint ruleExamples of disjointness constraints

  • Disjointness constraintOverlap Rule: An instance of the supertype can simultaneously be a member of more than one of the subtypes. Some PARTs are both Manufactured and Purchased. An instance of PART is a particular Part Number (i.e. type of part) rather than the individual part itself (Part_No). Considering Part Number 4000, at a given time there may be 250 of this part to hand, of which 100 are manufactured and 150 are purchased. The overlap is specified by placing an o in the circleDouble line suggests any part must be either a purchased part or a manufactured part, or it may simultaneously be both of these

  • Overlap rule

  • Subtype discriminatorsAttribute of the supertype whose values determine the target subtype(s)Disjoint subtypes: a simple attribute with alternative values to indicate the possible subtypes. In the following Fig. A new attribute Employee_Type has been added to the supertype to serve as a subtype discriminator. 3 values H = Hourly, S = Salaried, C = Consultant. This is assigned the correct value when a new employee is added.

  • Subtype discriminatorsThe expression Employee_Type = (the LHS of a condition statement) is placed next to the line leading from the supertype to the circle, with the value of the attribute that selects the appropriate subtype placed adjacent to the line leading to that subtype

  • Subtype discriminator (disjoint rule)

  • Subtype discriminatorsOverlapping a composite attribute whose subparts pertain to different subtypes. Each subpart contains a boolean value to indicate whether or not the instance belongs to the associated subtype. In the following Fig. a new attribute Part_Type has been added to PART. Part_Type is a composite attribute with components Manufactured? and Purchased? Each of these attributes is a boolean variable, and can be combined as: Manufactures only = YN, Purchased only = NY, Purchased and manufactured = YY

  • Subtype discriminator (overlap rule)

  • Defining supertype/subtype hierarchiesIt is possible for any of the subtypes in these examples to have other subtypes defined on itA supertype/subtype hierarchy is a hierarchical arrangement of supertypes and subtypes, where each subtype has only one supertypeIn modelling the Human resources in a University, the most general entity type would be PERSON (sometimes called the root)Relevant attributes are SSN (Social Security Number Identifier), Name, Address, Gender and Date_Of_Birth

  • Defining supertype/subtype hierarchiesNext we define all major subtypes of the root, here there are 3, EMPLOYEE, STUDENT and ALUMNUS (already graduated)A person may belong to more than one subtype (such as ALUMNUS and EMPLOYEE) so the overlap rule is used. Overlap allows for any overlap (3-way) so if certain combinations are not allowed a more refined supertype/subtype hierarchy would have to be developed to eliminate these

  • Defining supertype/sub