Presentation is loading. Please wait.

Presentation is loading. Please wait.

Author: Graeme C. Simsion and Graham C. Witt Chapter 5 Attributes and Columns.

Similar presentations


Presentation on theme: "Author: Graeme C. Simsion and Graham C. Witt Chapter 5 Attributes and Columns."— Presentation transcript:

1 Author: Graeme C. Simsion and Graham C. Witt Chapter 5 Attributes and Columns

2 Copyright: ©2005 by Elsevier Inc. All rights reserved. 2 Our Goal Revisited We want a design, made up of sound, fully normalized tables, that meets our criteria of completeness, non-redundancy, stability, flexibility, communication, rule enforcement, reusability, integration, and elegance. We are using E-R Modeling to do this that uses entity classes, relationships and attributes. We cover these three concepts in this and the next lecture.

3 Copyright: ©2005 by Elsevier Inc. All rights reserved. 3 Terminology Revisited Entity classes – categories of things of interest to the business: represented by boxes on the diagram, and generally implemented as tables Attributes – what we want to know about entitiy classes: not usually shown on the diagram and generally implemented as columns in tables Relationships – represented by lines with crows feet (we will drop the term arrow now that we are talking about conceptual models), and generally implemented through foreign keys.

4 Copyright: ©2005 by Elsevier Inc. All rights reserved. 4 Entity Classes An entity class is a real-world class of things such as Hospital that we want to keep information about. –We make the distinction between entities, such as St. Vincents Hospital and entity classes (sometimes called entity types) such as Hospital. –Many E-R modelers use the word entity loosely to mean entity class and use entity instance for those fairly rare occasions when they want to refer to a single instance.

5 Copyright: ©2005 by Elsevier Inc. All rights reserved. 5 Entity Class Complexity There is almost always an element of choice in how data is classified into entity classes. –Should a single entity class represent all employees or should we define separate entity classes for part- time and full-time employees? –Should we use separate entity classes for insurance policies and cover notes, or is it better to combine them into a single Policy entity class?

6 Copyright: ©2005 by Elsevier Inc. All rights reserved. 6 Entity Diagramming Convention Here, entity classes are represented by boxes with rounded corners. –Using rounded corners distinguishes entity classes in conceptual models from tables (represented by square-cornered boxes) in logical and physical data models. There are no restrictions on the size or color of the boxes. Communication is critical.

7 Copyright: ©2005 by Elsevier Inc. All rights reserved. 7 Entity Class Naming The name of an entity class must be in the singular and refer to a single instance. Why? –Consistency in the model – It is the beginning of a naming standard for entity classes. –Communication – An entity class is something we want to keep information about, such as a customer rather than a customer file. –Generating business assertions – If we follow some simple rules in naming the components of an E-R model, we can automatically generate grammatically sound assertions which can be checked by stakeholders.

8 Copyright: ©2005 by Elsevier Inc. All rights reserved. 8 Entity Naming Bad Habits Naming the entity class after the most important attributefor example, Drug Dose Cost rather than Standard Drug Dosage, or Specialty rather than Surgeon Naming one entity class by adding a prefix to the name of another, e.g., External Employee when there is already an Employee entity class Abbreviating names unnecessarily.

9 Copyright: ©2005 by Elsevier Inc. All rights reserved. 9 Entity Class Definitions Entity class names must be supported by definitions. Definitions provide guidance on the correct use of the resulting database by users querying or developers / implementers misusing.

10 Copyright: ©2005 by Elsevier Inc. All rights reserved. 10 Good Definitions A good entity class definition will clearly answer two questions: –What distinguishes instances of this entity class from instances of other entity classes? –What distinguishes one instance from another? Good examples of each, focusing on the marginal cases, can often help clarify the answers to these questions. The primary key and a few other sample attributes can also do much to clarify the definition prior to the full set of attributes being defined.

11 Copyright: ©2005 by Elsevier Inc. All rights reserved. 11 An Example Entity-Class Definition Drug: –An antibiotic drug as marketed by a particular manufacturer. Variants that are registered as separate entries in Smiths Index of Therapeutic Drugs are treated as separate instances. Excluded are generic drugs such as penicillin. Examples are: Maxicillin, Minicillin, Extracycline.

12 Copyright: ©2005 by Elsevier Inc. All rights reserved. 12 Relationships Relationships are between entity classes. –In our example, there are relationships, between members in the Hospital and Surgeon entity classes and between members of Operation and Drug Administration entity classes.

13 Copyright: ©2005 by Elsevier Inc. All rights reserved. 13 Relationship Diagramming Conventions Relationships are annotated to describe their –meaning (relationship names), –cardinality (the crows foot can be interpreted as meaning many, its absence as meaning one), and –optionality (the circles and bars representing optional and mandatory respectively).

14 Copyright: ©2005 by Elsevier Inc. All rights reserved. 14 Showing Relationship Notation Relationships are named in both directions: issue and be issued by. This enables us to interpret the relationship in a very structured, formal way: –Each company may issue one or more shares., and (note: one or more instead of many) –Each share must be issued by one company. For optional relationships use might and may rather than zero or more, or zero or one to describe them.

15 Copyright: ©2005 by Elsevier Inc. All rights reserved. 15 Alternatives Notation

16 Copyright: ©2005 by Elsevier Inc. All rights reserved. 16 Tips for Drawing Relationships When drawing one-to-many relationships, locate the boxes so that the crows foot points downwards (i.e., so that the box representing the entity class at the many end of the relationship is nearer the bottom of the page). This means that hierarchies appear in the expected way. Eliminate crossing lines wherever possible Duplicate entity classes on the diagram to avoid long and difficult-to-follow relationship lines

17 Copyright: ©2005 by Elsevier Inc. All rights reserved. 17 Many-to-Many Relationships How do we represent this in tables? We cant. It must be normalised.

18 Copyright: ©2005 by Elsevier Inc. All rights reserved. 18 Implementing Many-to-Many relationships Whenever we encounter a many-to-many relationship between two entity classes, we can implement it by introducing a third table in addition to the tables derived from the two original entity classes. Note the optional/mandatory nature of the new relationships can be derived from the original many-to-many relationship: –The one ends of the new relationships will always be mandatory –The many ends of the new relationships will be optional or mandatory depending on the corresponding ends of the original relationship.

19 Copyright: ©2005 by Elsevier Inc. All rights reserved. 19 Choice of Representation We can bring the conceptual model into line with the logical model by introducing an intermediate entity class to replace the many-to- many relationship. We are faced with an interesting choice: we can represent the same real- world situation either with a many-to-many relationship or with an entity class and two new many-to-one relationships

20 Copyright: ©2005 by Elsevier Inc. All rights reserved. 20 Which one to use? The many-to-many notation preserves consistency; we use a line to represent each real-world relationship and convert at implementation. On the other hand, if we restrict ourselves to one-to-many relationships, we seem to be stuck with the clumsy idea of an entity class whose name implies that it is a relationship. There is often some choice as to whether to classify a particular concept as an entity class or a relationship: RelationshipIntersection Entity Class Students enroll in SubjectsEnrollment Companies employ PersonsEmployment Employees are responsible for Assets Responsibility

21 Copyright: ©2005 by Elsevier Inc. All rights reserved. 21 One-to-One Relationships These are rare (verify they are correct when you have them)

22 Copyright: ©2005 by Elsevier Inc. All rights reserved. 22 Self-Referencing Relationships A self-referencing or recursive relationships has the same entity class at both ends (a head scratcher or fish hook). We interpret these in the same way as any other relationship, (both participants in the relationship are the same entity class)

23 Copyright: ©2005 by Elsevier Inc. All rights reserved. 23 One-to-many Self-Referencing Relationship Each Employee may manage one or more Employees., and Each Employee may be managed by one Employee. This is a hierarchy of employees Optional relationship means the hierarchy has a top and a bottom.

24 Copyright: ©2005 by Elsevier Inc. All rights reserved. 24 Many-to-many Self- Referencing Relationship Are common and used for hierarchies, networks, and chains. In business terms, we are saying that a part can be made up of parts, which themselves can be made up of parts and so on. We allow a given part to be used in the construction of more than one part hence, the many-to-many relationship.

25 Copyright: ©2005 by Elsevier Inc. All rights reserved. 25 Resolving Many-to-many Self- Referencing Relationships This cannot be implemented by a single table MANUFACTURED PART (Manufactured Part Number, Description, {Component Manufactured Part Number, Quantity Used}) Removing repeating group… MANUFACTURED PART (Manufactured Part Number, Description) MANUFACTURED PART USAGE (Assembly Manufactured Part Number*, Component Manufactured Part Number*, Quantity Used)

26 Copyright: ©2005 by Elsevier Inc. All rights reserved. 26 Relationships Involving Three or More Entity Classes A welfare authority might need to record which services were provided by which organizations in which areas. –Our three basic tables might be Service, Organization, and Area. –The objective is to record each allowable combination of the three. –We can easily do this by defining a table in which each row holds an allowable combination of the three primary keys:

27 Copyright: ©2005 by Elsevier Inc. All rights reserved. 27 Cardinality for Relationships Involving Three or More Entity Classes It is tricky to talk about the cardinality and optionality of higher degree relationships prior to their resolution. –The concepts are certainly applicable, but they are difficult to come to grips with for most data modelers, –Not all diagramming conventions support the direct representation of higher degree relationships. Some advice… use an intersection entity class to represent the relationships in the conceptual model, then work with the familiar two-entity-class relationships that result.

28 Copyright: ©2005 by Elsevier Inc. All rights reserved. 28 Relationship Transferability

29 Copyright: ©2005 by Elsevier Inc. All rights reserved. 29 The Importance of Transferability In the case of amateur licence relationship (non-transferrable relationship) the primary key of the licence is stable (doesnt change) In the public broadcasting licence the relationship is transferrable. –documenting audit trails (history) of the relationship

30 Copyright: ©2005 by Elsevier Inc. All rights reserved. 30 Documenting Transferability

31 Copyright: ©2005 by Elsevier Inc. All rights reserved. 31 Optionality of non- transferrable relationships Non-transferable one-to-many relationships are usually, but not always, mandatory in the one direction. Many-to-many relationships may be transferable or non-transferable. A many-to-many relationship may be transferable in only one direction. –A student may transfer his or her enrolment from one course to another course, but a students enrolment in a course cannot be transferred to another student.

32 Copyright: ©2005 by Elsevier Inc. All rights reserved. 32 Dependent and Independent Entity Classes Related to non-transferrability An independent entity class is one whose instances can have an independent existence. A dependent entity class is one whose instances can only exist in conjunction with instances of another entity class, and cannot be transferred between instances of that other entity.

33 Copyright: ©2005 by Elsevier Inc. All rights reserved. 33 Tips for Naming Relationships In the early stages of modeling, it is OK to leave relationships unnamed. The final E-R model should always be properly annotated with meaningful relationship names (not associated with or related to). –But, the two relationships that arise from resolving a many- to-many relationship, can have involve and be involved in as workable names. This is because the relationships name will have been used up in naming the entity that is used to contain the relationship. Naming helps clarify the cardinality of relationships

34 Copyright: ©2005 by Elsevier Inc. All rights reserved. 34 Attributes We have concentrated on entity classes and relationships Thus far, only keys (identifying attributes) have rated much of a mention Next lecture we cover attributes and tackle some myths and folklore about data modeling


Download ppt "Author: Graeme C. Simsion and Graham C. Witt Chapter 5 Attributes and Columns."

Similar presentations


Ads by Google