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

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

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

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

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

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

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

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

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

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

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

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

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

15. Alternatives Notation
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 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.

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

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

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

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

28. Relationship Transferability
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 (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.

30. Documenting Transferability
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 student’s enrolment in a course cannot be transferred to another student.
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.
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 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.

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