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

Copyright: ©2005 by Elsevier Inc. All rights reserved. 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. Copyright: ©2005 by Elsevier Inc. All rights reserved.

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. Copyright: ©2005 by Elsevier Inc. All rights reserved.

Copyright: ©2005 by Elsevier Inc. All rights reserved. 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. Vincent’s 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. Copyright: ©2005 by Elsevier Inc. All rights reserved.

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? Copyright: ©2005 by Elsevier Inc. All rights reserved.

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. Copyright: ©2005 by Elsevier Inc. All rights reserved.

Copyright: ©2005 by Elsevier Inc. All rights reserved. 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. Copyright: ©2005 by Elsevier Inc. All rights reserved.

Entity Naming Bad Habits Naming the entity class after the most “important” attribute—for 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. Copyright: ©2005 by Elsevier Inc. All rights reserved.

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. Copyright: ©2005 by Elsevier Inc. All rights reserved.

Copyright: ©2005 by Elsevier Inc. All rights reserved. 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. Copyright: ©2005 by Elsevier Inc. All rights reserved.

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

Copyright: ©2005 by Elsevier Inc. All rights reserved. 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. Copyright: ©2005 by Elsevier Inc. All rights reserved.

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

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. Copyright: ©2005 by Elsevier Inc. All rights reserved.

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

Tips for Drawing Relationships When drawing one-to-many relationships, locate the boxes so that the crow’s 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 Copyright: ©2005 by Elsevier Inc. All rights reserved.

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

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. Copyright: ©2005 by Elsevier Inc. All rights reserved.

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 Copyright: ©2005 by Elsevier Inc. All rights reserved.

Copyright: ©2005 by Elsevier Inc. All rights reserved. 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: Relationship Intersection Entity Class Students enroll in Subjects Enrollment Companies employ Persons Employment Employees are responsible for Assets Responsibility Copyright: ©2005 by Elsevier Inc. All rights reserved.

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

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) Copyright: ©2005 by Elsevier Inc. All rights reserved.

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. Copyright: ©2005 by Elsevier Inc. All rights reserved.

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. Copyright: ©2005 by Elsevier Inc. All rights reserved.

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) Copyright: ©2005 by Elsevier Inc. All rights reserved.

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: Copyright: ©2005 by Elsevier Inc. All rights reserved.

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. Copyright: ©2005 by Elsevier Inc. All rights reserved.

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

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

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

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 student’s enrolment in a course cannot be transferred to another student. Copyright: ©2005 by Elsevier Inc. All rights reserved.

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. Copyright: ©2005 by Elsevier Inc. All rights reserved.

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 relationship’s name will have been ‘used up’ in naming the entity that is used to contain the relationship. Naming helps clarify the cardinality of relationships Copyright: ©2005 by Elsevier Inc. All rights reserved.

Copyright: ©2005 by Elsevier Inc. All rights reserved. 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 Copyright: ©2005 by Elsevier Inc. All rights reserved.