1 Section 14 - Subtypes/Supertypes u Subtyping –allows our diagram to show several different options at the same time –is useful for concisely representing rules and constraints, and for managing complexity

2 Levels of Generalization u What data would we need to store to record family trees? –fathers –mothers »their marriages –children u Graphic 4-1

3 Marriage Entity u Is the resolution of... –Person to Person in Figure A –Man and Woman in Figure B u Marriage is Many-to-Many –Because people may marry more than one person in their lifetime »Usually not concurrently!

4 Optional Parents? u “mother of” and “father of” are optional relationships. Why? u Doesn’t everyone have to have a Father and a Mother?

5 Reality vs. Data u The rule that everyone must have a mother seems reasonable, but... u... we cannot identify all the mothers from historical data –We will run out of data long before we need to face the problem of “who was the first woman?”

6 Choice of Entities u Why can’t we use “mother”, “father”, “child” as entities?

7 Nonredundancy u Since a person can be both a mother and a child we would compromise our objective of nonredundancy if we carried the same data about a person in two tables u Graphic 4-1 shows two different approaches to the problem –Person Concept –Nonoverlapping concepts of man and woman

8 Differences u The level of generalization is the difference between the two models –Person is a generalization of Man and Woman –Man and Woman are a specialization of Person u More... –Specializing Man into Married Man and Unmarried Man –Generalizing Marriage into Personal Relationships

9 Profound Effect u The choice of level of generalization will have a profound effect on... –the database –the total system u Obvious effect is to reduce the number of entities which will... –Reduce system complexity, through generalization program logic OR... –Increase complexity if the logic needed to handle different subtypes outweighs the gains

10 Selecting the Appropriate Level u Start by looking at an important difference between the models: the number and type of rules (constraints) that each supports. –Man-Woman model has three entities and six relationships –Person model has two entities and four relationships

11 More Differences... u Insists that a marriage consists of one man and one woman u Person model would allow same-sex offspring. –Note: We could enforce this rule in the program logic

12 Stability Criteria u The more constraints the data model enforces, the more likely that one of more of them will change u This makes are model less stable

13 Rules for Generalization u Don’t build a rule into the data structure of a system unless you are reasonably sure the rule will remain in force for the life of the system u Use generalization to remove unwanted rules from the data model

14 Don’t Overdo It u Very general models can seem virtually immune to criticism, on the basis that they accommodate almost anything! u This is NOT brilliant data modeling, but an abdication of design in favor of the function modeler, or the user, who will have to pick up all the business rules missed

15 Representing Subtypes/Supertypes u As we generalize the model it is good not to “lose” the rules we have gathered –e.g If we use the Person model we want to save the “man and woman in a marriage” rule u Even if we don’t implement the rules in the data model, we can pass them on to the function modeler

16 Deferring Generalization u Need a diagramming convention that will allow us to show both –Generalization –Specialization u Graphic 4-2

17 New Diagramming Convention u Box-in-Box –Adds complexity to our diagram –Adds another dimension (generalization/specialization) to our model u Using this convention is called “Subtyping”

18 Subtypes/Supertypes u Man and Women are subtypes of Person u Person is a supertype of Man and of Woman

19 Subtypes/Supertypes as Entities u 1.Use round-rectangle for subtypes and supertypes u 2.Subtypes and supertypes must be supported by definitions u 3. Subtypes and supertypes can have attributes (Common attributes on the supertype

20 Continued u 4. Subtypes and supertypes must have a primary key u 5. Subtypes and supertypes can participate in relationships (Notice in figure 4-2 how “mother-of” and “father-of” are tied to the appropriate level u 6. Subtypes themselves can have subtypes

21 Definition u An entity inherits the definition of its supertype –if the entity Job Position is subtyped into Permanent Position and Temporary Position then the definition of Permanent Position would begin with “a Job Position that...”

22 Attributes of Subtypes u Record attributes that can apply to all subtypes with the supertype –e.g. Record Date-of-Birth with the Person entity u Record attributes that can only apply to the subtype with the subtype –e.g. Record “maiden name” with the Woman entity –Constraint - “a woman can only have a maiden name”

23 Attributes Recorded at Both Levels u Sometimes can add meaning by representing attributes at two or more levels of generalization u For example, we might have an entity Contract, subtyped into Renewable Contract and Fixed-term Contract –subtypes might include Renewal Date and Expiration Date, respectively –supertype might generalize this attribute to End-Date

24 Primary Key u If Woman entity has woman_id as a primary key and Man entity has man_id as a primary key, then Person entity might have person_id plus a male/female flag as its primary key

25 Conversion to a Relational Model u When we started with a set of tables and drew an E-R diagram, we didn't show any supertypes –Relational notation does not support subtypes or supertypes u At the end of the modeling process, we must produce a subtype-free model –Called "leveling the model" –like Object-oriented

26 Choices u Can discard Person and keep Man and Woman entities –we will inherit the attributes from Person –must add a 'type' attribute u Or, keep Person and discard Man and Woman entity –we will roll-up the attributes from Man and Woman, these attributes become optional in Person (null values are permissible); some attributes may be combined

27 Rolling up Two or More Levels u Must choose how many "type" attributes to introduce –author suggests simply using a single "type" from the lowest level of subtyping –Graphic 4-3 u Need two "types" if you want to distinguish the levels –Graphic 4-4

28 A Third Option u We can implement all three entities as tables –Graphic 4-5 u Link the tables by carrying the foreign key of Person in the Man and Woman tables –Pro: We don't need to discard any of the previous concepts –Con: We may end up with a proliferation of tables... violating simplicity criteria

29 Using Views u Can use views to present data at the subtype or supertype level u Some limitations... –Not all views allow the data presented to be updated »restrictions of a DBMS »Ambiguously presented data (data combined from two or more tables)

30 What happens to Relationships? u We need to do something about relationships involving discarded entities –We inherit relationships from discarded supertypes –We roll-up relationships from discarded subtypes »Makes some relationships optional »May generalize a relationship

31 Examples u Graphic 4-6a u Graphic 4-6b u Graphic 4-6c

32 Nonoverlapping & Exhaustive u Subtypes are... –Nonoverlapping - a given person cannot be both a man and a woman –Exhaustive - a given person must be either a man or a woman, nothing else

33 Reality vs. What We Know u It may be true that all people are either a man or a woman, but our data may be incomplete –e.g. Terry is a parent of John, is Terry a man or a woman?

34 Summary u Subtypes and Supertypes can be used to specialize or generalize information u Diagrammatically represented as a box-in- box u Level the model as a final step for implementation u Subtypes must be Nonoverlapping and Exhaustive

35 Section 14 - Last Slide u End of Class! u Thank you