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

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.


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.


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.


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?


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.


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.


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.


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.


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.


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.


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.


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


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.


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


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


Many-to-Many Relationships

Employee Qualification be awarded

be awardedto

How do we represent this in tables? We can’t. It must be normalised.


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.


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


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


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


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)


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.


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


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)


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


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.


Relationship Transferability

Person

AmateurRadio

License

Person

PublicBroadcasting

License

beheld by

hold

(a) (b)

beheld by

hold


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


Documenting Transferability

PersonAmateur

RadioLicense

hold

be heldby

non-transferability symbol


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.


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.


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


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

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

Documents

entity instance

single entity class

word entity

entity types

separate entity classes

employee entity class

entity class complexity

surgeon entity classes