Presentation is loading. Please wait.

Presentation is loading. Please wait.

Author: Graeme C. Simsion and Graham C. Witt Chapter 6 Primary Keys and Identity.

Similar presentations


Presentation on theme: "Author: Graeme C. Simsion and Graham C. Witt Chapter 6 Primary Keys and Identity."— Presentation transcript:

1 Author: Graeme C. Simsion and Graham C. Witt Chapter 6 Primary Keys and Identity

2 Copyright: ©2005 by Elsevier Inc. All rights reserved. 2 Attribute Identification and Definition Attributes in an E-R model generally correspond to columns in a relational model. Only a few attributes on the diagram for clarification of entity class meaning –we do not generally show all of the attributes on the diagram, primarily because we would end up swamping our big picture with detail. Attributes represent an answer to the question, What data do we want to keep about this entity class?

3 Copyright: ©2005 by Elsevier Inc. All rights reserved. 3 Primary Keys and the Conceptual Model In E-R modeling, we can identify entity classes prior to defining their keys. –In some cases, none of the attributes of an entity class (alone or in combination) is suitable as a primary key and we can invent our own key, but we can defer this step until the logical modeling stage. Since we will not have necessarily nominated primary keys for all entity classes at this stage, we cannot identify foreign keys. –Primary keys, and foreign keys are of critical importance in the relational model. ER diagrams show the importance stuff anyway. Your CASE methodology or tools may require that you identify keys at the conceptual modeling stage.

4 Copyright: ©2005 by Elsevier Inc. All rights reserved. 4 Myths and Folklore of Modeling (1) Entity Classes without Relationships –It is uncommon, but allowed, to have an entity class that is not related to any other entity class. –Some systems require data from disparate sources, for example, Economic Forecast and Competitor Profile. –Entity classes representing rules among types may be stand-alone if the types themselves are not represented by entity classes.

5 Copyright: ©2005 by Elsevier Inc. All rights reserved. 5 Allowed Combinations of Cardinality and Optionality The following have been said to be illegal. They are legitimate but rare. (See figure 3.32 – next slide) Relationships that are mandatory in both directions may be the chicken and egg question: which comes first? –We cannot record a customer without an account, and we cannot record an account without a customer. –the problem is illusory, as we create both the customer and the account within one transaction (indivisible action). Self-referencing relationships may model chains as in Figure 3.32(c) as well as other complex structures.

6 Copyright: ©2005 by Elsevier Inc. All rights reserved. 6

7 7 Creativity and E-R Modeling Choice is far more apparent in E-R modeling than in normalization. It is helpful to think of E-R modeling as putting a grid on the world. –We are trying to come up with a set of non- overlapping categories so that each fact in our world fits into one category only. Consider just one area of our drug expenditure model the classification of operations into operation types.

8 Copyright: ©2005 by Elsevier Inc. All rights reserved. 8 Drug Expenditure Mode: Operation Type We could define Operation Type to either include (original model) or exclude hybrid operations. If we chose the latter course, we would need to modify the model as in Figure 3.33(a) to allow an operation to be of more than one operation type. Alternatively, we could define two levels of operation type: Hybrid Operation Type and Basic Operation Type, giving us the model in Figure 3.33(b). We could allow operation types to be either basic or hybrid, and record the component operations of hybrid operations, resulting in Figure 3.33(c). Or, we could represent a hybrid operation as two separate operations, possibly an inelegant solution (Figure 3.33(d)).

9 Copyright: ©2005 by Elsevier Inc. All rights reserved. 9 The Alternative Solutions We have five solutions altogether (including the original one), each with different implications:

10 Copyright: ©2005 by Elsevier Inc. All rights reserved. 10 Create an Entity-Relationship Model of the following

11 Copyright: ©2005 by Elsevier Inc. All rights reserved. 11 Compare Yours with Your Neighbours Are there differences? List how they are different –Different names for similar concepts? –Level of detail? –Definitional confusion? –Extra clarification required? –Purpose?

12 Copyright: ©2005 by Elsevier Inc. All rights reserved. 12 How to be Creative Creativity in modeling is a progressively acquired skill. –Making a habit of looking for alternative models, makes finding them easier. –You also begin to recognize common structures or patterns. We can also support the search for alternative models with some formal techniques. –We will look at one of the most important of these in the next two chapters.

13 Copyright: ©2005 by Elsevier Inc. All rights reserved. 13 An Example: A Family Tree Database Suppose we are designing a database to record family trees. We need to hold data about fathers, mothers, their marriages, and children. Create an ER model of this scenario What is the most difficult part of modeling this example?

14 Copyright: ©2005 by Elsevier Inc. All rights reserved. 14 Family Tree Marriage is the resolution entity of a many-to-many relationship be married to between Person and Person in (a) and Man and Woman in (b). –A person may marry more than one other person, usually over time (at least in most of the world). mother of and father of, are optional. While the rule every person must have a mother may seem reasonable enough at first glance, it is not true of that subset of persons of interest to us.

15 Copyright: ©2005 by Elsevier Inc. All rights reserved. 15 Entity Classes in the Models We cannot use the nouns (mother, father, child) as these will overlapand we would have redundancy. We need alternative concepts from mother, father, and child. –person concept in (a) and two non-overlapping concepts of man and woman in (b). –Aside from this difference, the models are essentially the same (although they need not be). –What is happening in the modelling choices

16 Copyright: ©2005 by Elsevier Inc. All rights reserved. 16 Generalization The models have entity classes at different levels of generalization. –Person is a generalization of Man and Woman, and, –Man and Woman are specializations of Person. Recognizing this helps us to understand how the two models relate and raises the possibility that we might be able to propose other levels of generalization, and hence other models –What about specializing Man into Married Man and Unmarried Man, or generalizing Marriage to Personal Relationship?

17 Copyright: ©2005 by Elsevier Inc. All rights reserved. 17 The Effect of Levels in Generalization Generalization may help the longevity and flexibility of a model (and resultant database) Our choice of level of generalization will have a profound effect not only on the database but on the design of the total system. –Reduction in the number of entity classes and in simplifying the model. –This may translate into a significant reduction in system complexity. –In some cases, gains are offset by higher program complexity by having to handle quite different subtypes.

18 Copyright: ©2005 by Elsevier Inc. All rights reserved. 18 Generalization: Many Shapes and Sizes In the next two lectures we cover generalization We include entity, relationship and attribute generalization. We also discuss how business rules affect our choice of generalization


Download ppt "Author: Graeme C. Simsion and Graham C. Witt Chapter 6 Primary Keys and Identity."

Similar presentations


Ads by Google