1. Author: Graeme C. Simsion and Graham C. Witt Chapter 7 Extensions and Alternatives

2. Copyright: ©2005 by Elsevier Inc. All rights reserved. 2 Family Tree Options: Rules Versus Stability Which model do we select? Look at the number and type of business rules (constraints) that each supports. –The man-woman model has three entity classes and six relationships, –the person model has only two entity classes and four relationships. –The man-woman model seems to be representing more rules about the data.

3. Copyright: ©2005 by Elsevier Inc. All rights reserved. 3 Coping with Change Man-woman model –insists that a marriage consists of one man and one woman, –insists that the mother must be a woman, and the father a man. Person model –allows a marriage between two men or two women –would allow a person to have two parents of the same gender; Change Where rules are enforced

4. Copyright: ©2005 by Elsevier Inc. All rights reserved. 4 Rule of Thumb The more likely it is that a rule will change during the life of the system, the less appropriate it is to enforce that rule by data structures rather than some other mechanism. –We trade off the power of representing the rules about marriage in data structures against the risk that the rules may change during the life of the system.

5. Copyright: ©2005 by Elsevier Inc. All rights reserved. 5 A Data Model where Rule Implementation is in Program Logic

6. Copyright: ©2005 by Elsevier Inc. All rights reserved. 6 Rule implementation in data and/or data structures

7. Copyright: ©2005 by Elsevier Inc. All rights reserved. 7 Flexibility Requirement Do not build a rule into the data structure of a system unless you are reasonably confident that the rule will remain in force for the life of the system. (can add some flexibility a la health insurance example) and, we can add: Use generalization to remove unwanted rules from the data model.

8. Copyright: ©2005 by Elsevier Inc. All rights reserved. 8 Using Subtypes and Supertypes Many of the arguments that arise in data modeling are about the appropriate level of generalization defer the decision on generalization, and treat the problem of finding the correct level as an opportunity to explore different options. To do this, we allow two or more models to exist on top of one another on the same E-R diagram. Figure 4.2 shows how this is achieved.

9. Copyright: ©2005 by Elsevier Inc. All rights reserved. 9 Different Levels of Generalization on a Single Diagram

10. Copyright: ©2005 by Elsevier Inc. All rights reserved. 10 Specialization / Generalization We call the use of generalization and specialization in a model subtyping. Man and Woman are subtypes of Person. Person is a supertype of Man and of Woman. The previous slide highlights three implementation options: –A single Person table –Separate Man and Woman tables –A Person table holding data common to both men and women, supplemented by Man and Woman tables to hold data relevant only to men or women respectively

11. Copyright: ©2005 by Elsevier Inc. All rights reserved. 11 Subtypes and Supertypes are just Entity classes Remember, subtypes and supertypes are entity classes, we use the same diagramming convention, and: –Subtypes and supertypes must be supported by definitions. –Subtypes and supertypes can have attributes. –Subtypes and supertypes can participate in relationships. –Subtypes can themselves have subtypes

12. Copyright: ©2005 by Elsevier Inc. All rights reserved. 12 Rules (1): Definitions Every entity class in a data model must be supported by a definition –a simple rule applies to the definition of a subtype: An entity class inherits the definition of its supertype. our task is to specify what differentiates it from its sibling subtypes.

13. Copyright: ©2005 by Elsevier Inc. All rights reserved. 13 Rules (2): Attributes of Supertypes and Subtypes Where do we record the attributes of an entity class that has been divided? –In the example, it makes sense to document attributes that can apply to all persons against Person and those that can apply only to men or only to women against the respective entity classes: we would hold Birth Date as an attribute of Person; Maiden Name (family name prior to marriage) as an attribute of Woman. By adopting this discipline, we are actually modeling constraints: Only a woman can have a maiden name. –Note: Maiden Name is a culture-specific concept and term; and there are other subtleties! Simple examples are not so simple!

14. Copyright: ©2005 by Elsevier Inc. All rights reserved. 14 Rules (2) ctd. adding meaning Sometimes we can add meaning through attributes in generalization: –Eg. Entity class Contract, subtyped into Renewable Contract and Fixed-Term Contract. –Attributes of subtypes could include attributes Renewal Date and Expiry Date respectively. –If we generalize these attributes to End Date, as an attribute of Contract. We loose meaning: it is vital that the differences be documented should this be done!

15. Copyright: ©2005 by Elsevier Inc. All rights reserved. 15 Rules (3): Non-Overlapping and Exhaustive The subtypes in our family tree model obeyed two important rules: –They were non-overlapping: a person cannot be both a man and a woman at the same time. –They were exhaustive: a person must be either a man or a woman, nothing else. these two rules are necessary in order for each level of generalization to be a valid implementation option in itself.

16. Copyright: ©2005 by Elsevier Inc. All rights reserved. 16 Not so simple Not exhaustive as it stands –A look at medical data standards (for example, ISO 5218 or the Australian Health Data Dictionary) will show that gender is a complex and controversial issue, not easily reduced to a simple division between male and female. –Nevertheless for a specific purpose what we have suggested is OK. The real world of data collection –What about a person whose gender was unknown or uncertain?

17. Copyright: ©2005 by Elsevier Inc. All rights reserved. 17 Why limit sub-types? Isnt the value of our models reduced if we cannot represent common but overlapping business concepts? –Typical businesses deal with people and organizations in many roles: supplier, customer, investor, account holder, guarantor, and so forth. –The same person or organization can fill more than one of these roles; –We need a way to deal with this!

18. Copyright: ©2005 by Elsevier Inc. All rights reserved. 18 Other forms of Generalization ? Violating non-overlapping sub-types When to stop sub-typing We have considered sub-typing / super- typing generalization, but other generalizations exist: –Relationship generalization –Attribute generalization We cover all this in the next lecture