Database Systems: _ Design, Implementation, and Management Tenth Edition Chapter 5 Advanced Data ModelingObjectives * In this chapter, students will learn: — About the extended entity relationship (EER) model — How entity clusters are used to represent multiple entities and relationships — The characteristics of good primary keys and how to select them — How to use flexible solutions for special data modeling cases Database Systems, 10th EditionThe Extended Entity Relationship Model + Result of adding more semantic constructs to original entity relationship (ER) model * Diagram using this model is called an EER diagram (EERD) Database Systems, 10th EditionEntity Supertypes and Subtypes + Entity supertype — Generic entity type related to one or more entity subtypes — Contains common characteristics * Entity subtype — Contains unique characteristics of each entity subtype Database Systems, 10th EditionFIGURE 5a Database name: Ch0S_AirCo ie nt [BP LANE | Ee UNE [OW NITAL | EAP_LEERSE | eve RATINGS [WP NED_IVPE | Bae HRE_OATE a i 15M a “SELneLnekcA 4 Database Systems, 10th EditionSpecialization Hierarchy Depicts arrangement of higher-level entity supertypes and lower-level entity subtypes Relationships described in terms of “IS-A” relationships Subtype exists only within context of supertype Every subtype has only one supertype to which it is directly related Can have many levels of supertype/subtype relationships Database Systems, 10th EditionFIGURE 5.2 SuPERTYPE. ———p> EMPLOYEE DEPENDENT Pk [EMe_NUM PICFAY TEMP_NUM, ea PK |DPNT_NUM faecal EMP_LNAME non EMP_FNAME [DPN FNAM EMP_INTIAL (TLNAME tibutes inhorted EMP_HIRE_OATE JDPNT_ RELATION yall subtypes) EMe—TYPe Inherited relationship atogory symbol vee Disjoinvoveriapping constraint (alo) oer Eup PE <¢-—— Subtype iscriminator Database Systems, 10th Edition SUBTYPES: raComplete constraint —P = ea ae POF MECHANIC EEOUNTANT PCPA [EME MUM Pare [ene wu | [Pax [ene now Unie u_ucense mec me fact ame. enroute PL RATINGS mMEC=ceR JActicpa pare | (ants PiMeD. TYPE pen) SInheritance Enables entity subtype to inherit attributes and relationships of supertype All entity subtypes inherit their primary key attribute from their supertype At implementation level, supertype and its subtype(s) maintain a 1:1 relationship Entity subtypes inherit all relationships in which supertype entity participates Lower-level subtypes inherit all attributes and relationships from all upper-level supertypes Database Systems, 10th EditionFIGURE 5.3 Database name: Ch05_AirCo, “Table name: EMPLOYEE ‘Table name: PILOT [eesee Lee pai [ne poe oem [Serre [eT] [Beasst [mcm | —mparis [pe] oe eT Sav ‘in hres Zacar wea it von a Booms te cow ice aoa Big? ‘co tou ta one Soca ie oec nro teow ites ea feasoiF ocemas San ouaons SOURCE: Can ecoteyCoge ting Database Systems, 10th EditionSubtype Discriminator + Attribute in supertype entity — Determines to which entity subtype each supertype occurrence is related + Default comparison condition for subtype discriminator attribute is equality comparison * Subtype discriminator may be based on other comparison condition Database Systems, 10th EditionDisjoint and Overlapping Constraints * Disjoint subtypes — Also called nonoverlapping subtypes — Subtypes that contain unique subset of supertype entity set * Overlapping subtypes — Subtypes that contain nonunique subsets of supertype entity set Database Systems, 10th Edition aFIGURE 34 PERSON Px [eo user pis eve ©) Piss HPL OVEE ae Paras [PD pcr em ese is PRO rue uP 16 00M @) EAP IS PROF d stu Tre ees. —t eS Pras [20 ocras [210 PRra [e10 crx [em pow nite [PROF RANK Sead ESS fox neues Database Systems, 10th Edition 2Completeness Constraint Specifies whether entity supertype occurrence must be a member of at least one subtype Partial completeness — Symbolized by a circle over a single line — Some supertype occurrences are not members of any subtype Total completeness — Symbolized by a circle over a double line — Every supertype occurrence must be member of at least one subtype Database Systems, 10th Edition 14DISJOINT CONSTRAINT Supertype has optional subiypes. Subtype discriminator can be null. ‘Subtype sets are unique. Partial Specialization Hierarchy Constraint Scenarios OVERLAPPING CONSTRAINT Supertype has optional subtypes. Subtype discriminators can be null. Subtype sets are not unique. only one subtype. Subtype discriminator cannot be nul Subtype sets are unique. b Every supertype occurrence is a member of Every supertype occurrence is a member of at Teast one subtype. Subtype discriminators cannot be null. Subtype sets are not unique. Database Systems, 10th Edition 15Specialization and Generalization * Specialization — Identifies more specific entity subtypes from higher-level entity supertype — Top-down process — Based on grouping unique characteristics and relationships of the subtypes Database Systems, 10th Edition 16Specialization and Generalization (cont’d.) * Generalization — Identifies more generic entity supertype from lower-level entity subtypes — Bottom-up process — Based on grouping common characteristics and relationships of the subtypes Database Systems, 10th EditionEntity Clustering “Virtual” entity type used to represent multiple entities and relationships in ERD Considered “virtual” or “abstract” because it is not actually an entity in final ERD Temporary entity used to represent multiple entities and relationships Eliminate undesirable consequences — Avoid display of attributes when entity clusters are used Database Systems, 10th Edition 18gus 55 Database Systems, 10th Edition 19Entity Integrity: Selecting Primary Keys Primary key is the most important characteristic of an entity — Single attribute or some combination of attributes Primary key’s function is to guarantee entity integrity Primary keys and foreign keys work together to implement relationships Properly selecting primary key has direct bearing on efficiency and effectiveness Database Systems, 10th EditionNatural Keys and Primary Keys + Natural key is a real-world identifier used to uniquely identify real-world objects — Familiar to end users and forms part of their day- to-day business vocabulary * Generally, data modeler uses natural identifier as primary key of entity being modeled * May instead use composite primary key or surrogate key Database Systems, 10th Edition 21Primary Key Guidelines Attribute that uniquely identifies entity instances in an entity set — Could also be combination of attributes Main function is to uniquely identify an entity instance or row within a table Guarantee entity integrity, not to “describe” the entity Primary keys and foreign keys implement relationships among entities — Behind the scenes, hidden from user Database Systems, 10th EditionPond Unique values “The PK must uniquely identify each entity instance, A primary key mst be able {o guarantee unique valves. Itcannot contain nulls. Nonintelligent The PK should not have embedded semantic meaning other than to uniquely Identiy each emit instance. An atwibute with embedded semantic meaning 's probably better used asa descriptive characteristic of the entity than as an identifier. For example, a student ID of 650973 would be preferred aver Smith, Martha las. a primary key identificr. No change over time Ian atribute has semantic meaning, I might be subject to updates, which why’ ames do not make good primary Keys. Ii Vickie Smith isthe primary key. ‘wit happens ifshe changes her name when she gets martied? Ifa primary key is subject to change, the foreign key values must be updated, thus adding tothe database workload. Furthermore, changing a primary key value means that you are basicaly changing the identity of an entity. In short, the PK should be perma- ent and unchangeable, Preierably Single-attribute ‘A primary key should have the minimum numberof avibutes posible irede= ible, Single-atribute primary keys are desirable but not required. Single-atibute primary keys simplify the implementation of foreign keys. Having muliple= attribute primary keys can cause primary keys of related entities to grows though the possible addition of many attributes, thus adding tothe database workload, andl making (application) coding more cumbersome. Preierably numeric Unique values can be better managed when they are numeric, because the database can use internal routines to implement a counter-stye atribute that automatically increments values withthe addition of each new row. In fact, most database systems include the ability to use special constructs, such as Autonumber in Microsoft Access, 1 suppor selF-incrementing primary key atuibuts, Securty-compliant “The selected primary Key must not be composed of any atibutet) that might be considered a security rsk or violation. For example, using a Social Security umber as PK in an EMPLOYEE table i nota good idea Database Systems, 10th Edition 23When to Use Composite Primary Keys * Composite primary keys useful in two cases: — As identifiers of composite entities * In which each primary key combination is allowed once in M:N relationship — As identifiers of weak entities * In which weak entity has a strong identifying relationship with the parent entity « Automatically provides benefit of ensuring that there cannot be duplicate values Database Systems, 10th Edition 24FIGURE Database name: Ch05_Tinycollege CLASS, Pk [CLASS CODE ‘cRS_CODE CLASS_SECTION 5.6 ‘STUDENT ENROLL PK [STU NUM PK.FKt [CLASS CODE PRP | STU_NOM /STU_LNAME. /STU_FNAME. JENROLL_GRADE STUNT Table name: STUDENT Table name: CLASS Database Systems, 10th Edition (first four fields) ‘Table name: ENROLL (first three fields) “STU_NUMT STU_LNAME | STU_FNAME | STU IIT } LASS, cove | STu WM | ENROLL GRADE | [GLASS cove | cS cove | CASS_SECTION] ————— i —eeet oe eee a : 32081 Feboten Goad a —_S—t Se aie ce lore cea 2 oo a a ae cya Ling,When to Use Composite Primary Keys (cont’d.) + When used as identifiers of weak entities normally used to represent: — Real-world object that is existent-dependent on another real-world object — Real-world object that is represented in data model as two separate entities in strong identifying relationship + Dependent entity exists only when it is related to parent entity Database Systems, 10th Edition 26When To Use Surrogate Primary Keys + Especially helpful when there is: — No natural key — Selected candidate key has embedded semantic contents — Selected candidate key is too long or cumbersome Database Systems, 10th EditionWhen To Use Surrogate Primary Keys (cont’d.) + If you use surrogate key: — Ensure that candidate key of entity in question performs properly — Use “unique index’ and “not null” constraints Database Systems, 10th Edition 28Pern co mice ganar a aN) 6/17/2012 11:00AM 2:00PM Allure Burton Wedding 60. 6/17/2012 11:00AM 2:00PM Bonanza ‘Adams Office 12. 6/17/2012 3:00PM. 5:30PM. Allure Smith Family 15, 6/7/2012 3:30PM. 5:30PM, Bonanza, ‘Adams Office 2 6/18/2012 1:00PM 3:00PM Bonanza Boy Scouts: 33, 6/18/2012 11:00AM 2:00PM Allure: March of Dimes 25 6/18/2012 11:00AM. 12:30PM. Bonanza ‘Smith Family 12 Database Systems, 10th Edition 29Design Cases: Learning Flexible Database Design Data modeling and design requires skills acquired through experience Experience acquired through practice Four special design cases that highlight: — Importance of flexible design — Proper identification of primary keys — Placement of foreign keys Database Systems, 10th Edition 30Design Case 1: Implementing 1:1 Relationships + Foreign keys work with primary keys to properly implement relationships in relational model * Put primary key of the “one” side on the “many” side as foreign key — Primary key: parent entity — Foreign key: dependent entity Database Systems, 10th Edition 31Design Case 1: Implementing 1:1 Relationships (cont’d.) * In 1:1 relationship, there are two options: — Place a foreign key in both entities (not recommended) — Place a foreign key in one of the entities * Primary key of one of the two entities appears as foreign key of other Database Systems, 10th EditionPete UN SEAN LN ' ‘One side is mandatory and the other side jection of Forcign Key in a 1:1 Relationship Raion Place the PK ofthe entity on the mandatory side in the is optional. entity on the optional side as a FK, and make the FK mandatory. W Both sides are optional. Select the FK that causes the fewest nulls, or place the FK in the entity in which the (relationship) role is played. Wi Both sides are mandatory. See Case I, or consider revising your model to ensure that the two entities do not belong, together in a single entity. Database Syst tems, 10th Edition 33FIGURE 57 ‘A One-to-One (1:1) Relationship’ ‘An EMPLOYEE manages zero or one DEPARTMENT; each DEPARTMENT is managed by one EMPLOYEE. EMPLOYEE Pk |EMP_NUM manages DEPT EMP_LNAME DEPT_NAME EMP_FNAME Kt | EmP_NUM SOURCE Caine TcnolegCenge Lenin, Database Systems, 10th Edition 34Design Case 2: Maintaining History of Time-Variant Data * Normally, existing attribute values are replaced with new value without regard to previous value * Time-variant data: — Values change over time — Must keep a history of data changes * Keeping history of time-variant data equivalent to having a multivalued attribute in your entity + Must create new entity in 1:M relationships with original entity « New entity contains new value, date of change Database Systems, 10th EditionFIGURE 5.8 ENPLOVEE, Px [EMP_NUM jewe tame JEMP_FNAME JeMP_INiTiAL. JEMP_E MAIL }J08_cODE JEMP_SALARY ; Emp_SAL| HISTORY PR FIG [EMP NUM Pk | SALARY START DATE [SALARY AMT Database Systems, 10th Edition SOURCE Cane Tchr agyCorgegeEMP_J9B_HIST ‘SOURCE Cau Techs Congage ng, Database Systems, 10th EditionDesign Case 3: Fan Traps Design trap occurs when relationship is improperly or incompletely identified — Represented in a way not consistent with the real world Most common design trap is known as fan trap Fan trap occurs when one entity is in two 1:M relationships to other entities — Produces an association among other entities not expressed in the model Database Systems, 10th Edition 38FIGURE 5.1 Fan Trap Due to Misidentification of Relationships DIVISION PLAYER PK | TEAM ID. bo--H4PK [DW 10 H--OgPK |PLAYER ID TEAM NAME DIV_NAME PLAYER_NAME FK1 |DIV_ID FKt |DIV_ID SOUR: Cane TencegyCenpae Leaning 39 Database Systems, 10th EditionFIGURE Sa Fan Trap Eliminated by Proper Identification of Relationships DIVISION PLAYER [ow_nane | TEAM_NAME PLAYER NAME “Jordan Bryant Ginobit Iverson Database Systems, 10th Edition 40Design Case 4: Redundant Relationships Redundancy is seldom a good thing in database environment Occurs when there are multiple relationship paths between related entities Main concern is that redundant relationships remain consistent across model Some designs use redundant relationships to simplify the design Database Systems, 10th Edition 4Database Systems, 10th Edition 42Summary * Extended entity relationship (EER) model adds semantics to ER model — Adds semantics via entity supertypes, subtypes, and clusters — Entity supertype is a generic entity type related to one or more entity subtypes * Specialization hierarchy — Depicts arrangement and relationships between entity supertypes and entity subtypes + Inheritance means an entity subtype inherits attributes and relationships of supertype Database Systems, 10th Edition 43Summary (cont’d.) Subtype discriminator determines which entity subtype the supertype occurrence is related to: — Partial or total completeness — Specialization vs. generalization Entity cluster is “virtual” entity type — Represents multiple entities and relationships in ERD — Formed by combining multiple interrelated entities and relationships into a single object Database Systems, 10th Edition 44Summary (cont’d.) Natural keys are identifiers that exist in real world — Sometimes make good primary keys Characteristics of primary keys: — Must have unique values — Should be nonintelligent — Must not change over time — Preferably numeric or composed of single attribute Database Systems, 10th EditionSummary (cont’d.) Composite keys are useful to represent — M:N relationships — Weak (strong-identifying) entities Surrogate primary keys are useful when no suitable natural key makes primary key In a 1:1 relationship, place the PK of mandatory entity: — As FK in optional entity — As FK in entity that causes least number of nulls — As FK where the role is played Database Systems, 10th Edition 46Summary (cont’d.) * Time-variant data — Data whose values change over time — Requires keeping a history of changes * To maintain history of time-variant data: — Create entity containing the new value, date of change, other time-relevant data — Entity maintains 1:M relationship with entity for which history maintained Database Systems, 10th Edition