author: graeme c. simsion and graham c. witt chapter 5 attributes and columns
TRANSCRIPT
Author: Graeme C. Simsion and Graham C. Witt
Chapter 5Attributes and Columns
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.
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
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
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
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
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
Company Share issue
be issuedby
"Each Companymay issue one
or more shares."
"Each Share mustbe issued by
one company."
• 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
Company Shareissuer
1
Chen notation
CompanyShare
n
is issued by
ER Studio™
issues
IDEF1X / ERwin™
Company Shareissued
by
Oracle Designer™
issuer of
Company Share
UML
+issues +is issued by
1 0..*
Company Shareissues
System Architect™Company Share
Company Shareissues
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
Employee Qualification be awarded
be awardedto
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
Employee Qualification be awarded
be awardedto
Employee Qualification
EmployeeQualificationRelationship
involve
be involved in
involve
be involvedin
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:
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)
CustomerCustomer Discount
Agreement
be entitled to
be for
SubscriberSeat at
Scheduled Performance
be allocated
be allocated to
ContractGovernment
Contract Addendum
be supplemented by
supplement
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
manage
bemanagedby
Employee
“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.
beused
in
bemade upof
ManufacturedPart
Copyright: ©2005 by Elsevier Inc. All rights reserved. 25
Resolving Many-to-many Self-Referencing Relationships
• This cannot be implemented by a single table
(a) Starting Point
be an assembly of
be acomponent of
(b) Temporarily Showing Manufactured Part as Two Entities
involve as an assembly
be involved in as assembly in
involve as a component
be involved inas component in
(c) Resolving Many-to-Many Relationship
involve asa component
be involved in as
component
(d) Re-combining the Two Manufactured Part Tables
be acomponent
of
be anassemblyof
ManufacturedPart
ManufacturedPart
(Assembly)
ManufacturedPart
(Component)
ManufacturedPart
(Component)
ManufacturedPart
(Assembly)
ManufacturedPart Usage
ManufacturedPart
ManufacturedPart Usage
involve asan assembly
be involved in as assembly
•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:
involve be involved in
involve
be involvedi n
be involvedin
(Service ID, Organization-ID, Area ID)
Service Organization
ServiceAvailability
Area
be involved in
involve
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
Person
AmateurRadio
License
Person
PublicBroadcasting
License
beheld by
hold
(a) (b)
beheld by
hold
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
PersonAmateur
RadioLicense
hold
be heldby
non-transferability symbol
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
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