1 Section 14 - Subtypes/Supertypes u Subtyping –allows our diagram to show several different...

35
1 Section 14 - Subtypes/Supertypes 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

Transcript of 1 Section 14 - Subtypes/Supertypes u Subtyping –allows our diagram to show several different...

1

Section 14 - Subtypes/Supertypes

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

What data would we need to store to record family trees?– fathers– mothers

» their marriages

– children

Graphic 4-1

3

Marriage Entity

Is the resolution of...– Person to Person in Figure A– Man and Woman in Figure B

Marriage is Many-to-Many– Because people may marry more than one

person in their lifetime» Usually not concurrently!

4

Optional Parents?

“mother of” and “father of” are optional relationships. Why?

Doesn’t everyone have to have a Father and a Mother?

5

Reality vs. Data

The rule that everyone must have a mother seems reasonable, but...

... 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

Why can’t we use “mother”, “father”, “child” as entities?

7

Nonredundancy

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

Graphic 4-1 shows two different approaches to the problem– Person Concept – Nonoverlapping concepts of man and woman

8

Differences

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

More...– Specializing Man into Married Man and

Unmarried Man– Generalizing Marriage into Personal Relationships

9

Profound Effect The choice of level of generalization will have a

profound effect on...– the database

– the total system 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

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...

Insists that a marriage consists of one man and one woman

Person model would allow same-sex offspring.– Note: We could enforce this rule in the

program logic

12

Stability Criteria

The more constraints the data model enforces, the more likely that one of more of them will change

This makes are model less stable

13

Rules for Generalization

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

Use generalization to remove unwanted rules from the data model

14

Don’t Overdo It

Very general models can seem virtually immune to criticism, on the basis that they accommodate almost anything!

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

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 Even if we don’t implement the rules in the

data model, we can pass them on to the function modeler

16

Deferring Generalization

Need a diagramming convention that will allow us to show both– Generalization– Specialization

Graphic 4-2

17

New Diagramming Convention

Box-in-Box– Adds complexity to our diagram– Adds another dimension

(generalization/specialization) to our model Using this convention is called “Subtyping”

18

Subtypes/Supertypes

Man and Women are subtypes of Person Person is a supertype of Man and of

Woman

19

Subtypes/Supertypes as Entities

1. Use round-rectangle for subtypes and supertypes

2. Subtypes and supertypes must be supported by definitions

3. Subtypes and supertypes can have attributes (Common attributes on the supertype

20

Continued

4. Subtypes and supertypes must have a primary key

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

6. Subtypes themselves can have subtypes

21

Definition

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 Record attributes that can apply to all subtypes

with the supertype– e.g. Record Date-of-Birth with the Person entity

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 Sometimes can add meaning by representing

attributes at two or more levels of generalization 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

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

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 At the end of the modeling process, we must

produce a subtype-free model– Called "leveling the model"– like Object-oriented

26

Choices Can discard Person and keep Man and Woman

entities– we will inherit the attributes from Person – must add a 'type' attribute

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

Must choose how many "type" attributes to introduce– author suggests simply using a single "type"

from the lowest level of subtyping– Graphic 4-3

Need two "types" if you want to distinguish the levels– Graphic 4-4

28

A Third Option

We can implement all three entities as tables– Graphic 4-5

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 Can use views to present data at the

subtype or supertype level 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?

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

Graphic 4-6a Graphic 4-6b Graphic 4-6c

32

Nonoverlapping & Exhaustive

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

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

Subtypes and Supertypes can be used to specialize or generalize information

Diagrammatically represented as a box-in-box

Level the model as a final step for implementation

Subtypes must be Nonoverlapping and Exhaustive

35

Section 14 - Last Slide

End of Class! Thank you