Data Modeling and Relational Database Design

Data Modeling and Relational Database Design
Volume 1 Instructor Guide ...........................................................................................
Course Code 20000GC10 Edition 1.0 M08988
Authors
Jan Speelpenning Patrice Daux Jeff Gallus
Copyright Oracle Corporation, 1998, 1999. All rights reserved. This documentation contains proprietary information of Oracle Corporation. It is provided under a license agreement containing restrictions on use and disclosure and is also protected by copyright law. Reverse engineering of the software is prohibited. If this documentation is delivered to a U.S. Government Agency of the Department of Defense, then it is delivered with Restricted Rights and the following legend is applicable:
Technical Contributors and Reviewers

Simmie Kastner Stijn Vanbrabant Joni Lounsberry Kate Heap Gabriella Varga
Restricted Rights Legend

Use, duplication or disclosure by the Government is subject to restrictions for commercial computer software and shall be deemed to be Restricted Rights software under Federal law, as set forth in subparagraph (c) (1) (ii) of DFARS 252.227-7013, Rights in Technical Data and Computer Software (October 1988). This material or any portion of it may not be copied in any form or by any means without the express prior written permission of the Worldwide Education Services group of Oracle Corporation. Any other copying is a violation of copyright law and may result in civil and/or criminal penalties. If this documentation is delivered to a U.S. Government Agency not within the Department of Defense, then it is delivered with Restricted Right, as defined in FAR 52.227-14, Rights in Data-General, including Alternate III (June 1987).
Publishers
Avril Price-Budgen Fiona Simpson Don Griffin
The information in this document is subject to change without notice. If you find any problems in the documentation, please report them in writing to Education Products, Oracle Corporation, 500 Oracle Parkway, Box 659806, Redwood Shores, CA 94065. Oracle Corporation does not warrant that this document is error-free. Oracle, SQL*Plus, SQL*Net, Oracle Developer, Oracle7, Oracle8, Oracle Designer and PL/SQL are trademarks or registered trademarks of Oracle Corporation. All other products or company names are used for identification purposes only, and may be trademarks of their respective owners.
Contents .....................................................................................................................................................
Contents
Lesson 1: Introduction to Entities, Attributes, and Relationships Introduction 1-2 Why Conceptual Modeling? 1-4 Entity Relationship Modeling 1-7 Goals of Entity Relationship Modeling 1-8 Database Types 1-9 Entities 1-10 Entities and Sets 1-12 Attributes 1-13 Relationships 1-15 Entity Relationship Models and Diagrams 1-17 Representation 1-18 Attribute Representation 1-19 Relationship Representation 1-20 Data and Functionality 1-23 Types of Information 1-24 Other Graphical Elements 1-27 Summary 1-28 Practice 11: Instance or Entity 1-29 Practice 12: Guest 1-30 Practice 13: Reading 1-31 Practice 14: Read and Comment 1-32 Practice 15: Hotel 1-33 Practice 16: Recipe 1-34 General Instructor Notes 1-35 Practices 1-38 Suggested Timing 1-41 Workshop Interviewing 1-42 Instructor Notes 1-44 Instructor Post Lesson Teaching Evaluation 1-53 Suggested Graphics 1-55
..................................................................................................................................................... iii
Contents .....................................................................................................................................................
Lesson 2: Entities and Attributes in Detail Introduction 2-2 Data Compared to Information 2-4 Data 2-5 Tracking Entities 2-7 Electronic Mail Example 2-9 Evolution of an Entity Definition 2-11 Functionality 2-13 Tracking Attributes 2-14 Subtypes and Supertypes 2-17 Summary 2-20 Practice 21: Books 2-21 Practice 22: Moonlight 2-22 Practice 23: Shops 2-23 Practice 24: Subtypes 2-24 Practice 25: Schedule 2-25 Practice 26: Address 2-26 Practice 26: Address (continued) 2-27 Instructor Notes 2-28 Instructor Post Lesson Teaching Evaluation Suggested Graphics 2-37
2-35
Lesson 3: Relationships in Detail Introduction 3-2 Establishing a Relationship 3-4 Relationship Types 3-9 Relationships and Attributes 3-16 Attribute Compared to Relationship 3-18 Relationship Compared to Attribute 3-19 m:m Relationships May Hide Something 3-20 Resolving Relationships 3-25 Summary 3-28 Practice 31: Read the Relationship 3-29 Practice 32: Find a Context 3-30 Practice 33: Name the Intersection Entity 3-31 Practice 34: Receipt 3-32
..................................................................................................................................................... iv Data Modeling and Relational Database Design
Contents .....................................................................................................................................................
Practice 35: Moonlight P&O 3-33 Practice 36: Price List 3-35 Practice 37: E-mail 3-36 Practice 38: Holiday 3-37 Instructor Notes 3-38 Instructor Post Lesson Teaching Evaluation Suggested Graphics 3-51
3-49
Lesson 4: Constraints Introduction 4-2 Identification 4-4 Unique Identifier 4-6 Arcs 4-12 Arc or Subtypes 4-16 More About Arcs and Subtypes 4-17 Hidden Relationships 4-18 Domains 4-19 Some Special Constraints 4-20 Summary 4-24 Practice 41: Identification Please 4-25 Practice 42: Identification 4-26 Practice 43: Moonlight UID 4-28 Practice 44: Tables 4-29 Practice 45: Modeling Constraints 4-30 Instructor Notes 4-31 Instructor Post Lesson Teaching Evaluation 4-41 Suggested Graphics 4-43 Lesson 5: Modeling Change Introduction 5-2 Time 5-4 Date as Opposed to Day 5-5 Entity DAY 5-6 Modeling Changes Over Time 5-7 A Time Example: Prices 5-10 Current Price 5-16 Journalling 5-17
..................................................................................................................................................... v
Contents .....................................................................................................................................................
Summary 5-19 Practice 51: Shift 5-20 Practice 52: Strawberry Wafer 5-21 Practice 53: Bundles 5-22 Practice 54: Product Structure 5-24 Instructor Notes 5-25 Instructor Post Lesson Teaching Evaluation Suggested Graphics 5-33 Lesson 6: Advanced Modeling Topics Introduction 6-2 Patterns 6-4 Master Detail 6-5 Basket 6-6 Classification 6-7 Hierarchy 6-8 Chain 6-10 Network 6-11 Symmetric Relationships 6-13 Roles 6-14 Fan Trap 6-15 Data Warehouse 6-16 Drawing Conventions 6-17 Generic Modeling 6-19 Generic Models 6-20 More Generic Models 6-21 Most Generic Model 6-22 Summary 6-23 Practice 61: Patterns 6-24 Practice 62: Data Warehouse 6-25 Practice 63: Argos and Erats 6-26 Practice 64: Synonym 6-27 Instructor Notes 6-28 Instructor Post Lesson Teaching Evaluation Suggested Graphics 6-39
5-31
6-37
..................................................................................................................................................... vi
Contents .....................................................................................................................................................
Lesson 7: Mapping the ER Model Introduction 7-2 Why Create a Database Design? 7-4 Transformation Process 7-6 Naming Convention 7-8 Basic Mapping 7-12 Relationship Mapping 7-14 Mapping of Subtypes 7-20 Subtype Implementation 7-23 Summary 7-29 Practice 71: Mapping Supertype 7-30 Practice 72: Quality Check Subtype Implementation 7-31 Practice 73: Quality Check Arc Implementation 7-32 Practice 74: Mapping Primary Keys and Columns 7-33 Instructor Notes 7-34 Instructor Post Lesson Teaching Evaluation 7-43 Suggested Graphics 7-45 Lesson 8: Denormalized Data Introduction 8-2 Why and When to Denormalize 8-4 Storing Derivable Values 8-6 Pre-Joining Tables 8-8 Hard-Coded Values 8-10 Keeping Details With Master 8-12 Repeating Single Detail with Master 8-14 Short-Circuit Keys 8-16 End Date Columns 8-18 Current Indicator Column 8-20 Hierarchy Level Indicator 8-22 Denormalization Summary 8-24 Practice 81: Name that Denormalization 8-25 Practice 82: Triggers 8-26 Practice 83: Denormalize Price Lists 8-29 Practice 84: Global Naming 8-30 Instructor Notes 8-31
..................................................................................................................................................... vii
Contents .....................................................................................................................................................
Instructor Post Lesson Teaching Evaluation Suggested Graphics 8-39
8-37
Lesson 9: Database Design Considerations Introduction 9-2 Reconsidering the Database Design 9-4 Oracle Data Types 9-5 Most Commonly-Used Oracle Data Types 9-6 Column Sequence 9-7 Primary Keys and Unique Keys 9-8 Artificial Keys 9-11 Sequences 9-13 Indexes 9-16 Choosing Columns to Index 9-19 When Are Indexes Used? 9-21 Views 9-23 Use of Views 9-24 Old-Fashioned Design 9-25 Distributed Design 9-27 Benefits of Distributed Design 9-28 Oracle Database Structure 9-29 Summary 9-31 Practice 91: Data Types 9-32 Practice 92: Artificial Keys 9-34 Practice 93: Product Pictures 9-35 Instructor Notes 9-36 Instructor Post Lesson Teaching Evaluation 9-43 Suggested Graphics 9-45 Appendix A: Solutions Introduction to Solutions A-2 Practice 11 Instance or Entity: Solution A-4 Practice 12 Guest: Solution A-5 Practice 13 Reading: Solution A-6 Practice 14 Read and Comment: Solution A-7 Practice 15 Hotel: Solution A-8 Practice 16 Recipe: Solution A-9
..................................................................................................................................................... viii
Contents .....................................................................................................................................................
Practice 21 Practice 22 Practice 23 Practice 24 Practice 25 Practice 26 Practice 31 Practice 32 Practice 33 Practice 34 Practice 35 Practice 36 Practice 37 Practice 38 Practice 41 Practice 42 Practice 43 Practice 44 Practice 45 Practice 51 Practice 52 Practice 53 Practice 54 Practice 61 Practice 62 Practice 63 Practice 64 Practice 71 Practice 72 Practice 73 Practice 74 Practice 81 Practice 82 Practice 83 Practice 84 Practice 91
Books: Solution A-11 Moonlight: Solution A-12 Shops: Solution A-13 Subtypes: Solution A-14 Schedule: Solution A-15 Address: Solution A-16 Read the Relationship: Solution A-18 Find a Context: Solution A-19 Name the Intersection Entity: Solution A-20 Receipt: Solution A-21 Moonlight P&O: Solution A-23 Price List: Solution A-27 E-mail: Solution A-28 Holiday: Solution A-30 Identification Please: Solution A-32 Identification: Solution A-34 Moonlight UID: Solution A-37 Tables: Solution A-38 Constraints: Solution A-39 Shift: Solution A-40 Strawberry Wafer: Solution A-41 Bundles: Solution A-42 Product Structure: Solution A-44 Patterns: Solution A-45 Data Warehouse: Solution A-46 Argos and Erats: Solution A-47 Synonym: Solution A-48 Mapping Supertype: Solution A-49 Quality Check Subtype Implementation: Solution A-50 Quality Check Arc Implementation: Solution A-51 Primary Keys and Columns: Solution A-52 Name that Denormalization: Solution A-53 Triggers: Solution A-54 Denormalize Price Lists: Solution A-56 Global Naming: Solution A-58 Data Types: Solution A-59
..................................................................................................................................................... ix
Contents .....................................................................................................................................................
Practice 92 Artificial Keys: Solution A-61 Practice 93 Product Pictures: Solution A-62 Appendix B: Normalization Introduction B-2 Normalization and its Benefits B-3 First Normal Form B-7 Second Normal Form B-9 Third Normal Form B-11 Normalization During Data Modeling Summary B-16 Instructor Notes B-17
B-13
..................................................................................................................................................... x
1
.................................
Introduction to Entities, Attributes, and Relationships
Lesson 1: Introduction to Entities, Attributes, and Relationships .........................................................................................................................................
Introduction
Lesson Aim This lesson explains the reasons for conceptual modeling and introduces the key role players: entities, attributes, and relationships. Schedule See Page 44 About the slide See Page 44
Overview
Why conceptual modeling? Introduction of the Key role players:
Entities Attributes Relationships
1-2
Topic Introduction Why Conceptual Modeling? Entity Relationship Modeling Goals of Entity Relationship Modeling Database Types Entities Entities and Sets Attributes Relationships Entity Relationship Models and Diagrams Representation Attribute Representation Relationship Representation Data and Functionality
See Page 2 4 7 8 9 10 12 13 15 17 18 19 20 23
............................................................................................................................................. 1-2 Data Modeling and Relational Database Design
Introduction .........................................................................................................................................
Topic Types of Information Other Graphical Elements Summary Practice 11: Instance or Entity Practice 12: Guest Practice 13: Reading Practice 14: Read and Comment Practice 15: Hotel Practice 16: Recipe
See Page 24 27 28 29 30 31 32 33 34
Objectives At the end of this lesson, you should be able to do the following: Explain why conceptual modeling is important Describe what an entity is and give examples Describe what an attribute is and give examples Describe what a relationship is and give examples Draw a simple diagram Read a simple diagram
......................................................................................................................................... 1-3
Why Conceptual Modeling?

This is a course on conceptual data modeling and physical data modeling. Why do you need to learn this? Why invest time in creating entity models when you need tables? Why bother about business functionality and interviews and feedback sessions when you need programs? In this course you learn why. You learn why it is a wise decision to spend time in modeling and why it is a good investment. You will learn even more, including how to create, read, and understand models and how to check them, as well as how to derive table and key definitions from them. About the slide See Page 44
Why Create a Conceptual Model?
It describes exactly the information needs of the business It facilitates discussion It helps to prevent mistakes, misunderstanding It forms important ideal system documentation It forms a sound basis for physical database design It is a very good practice with many practitioners
1-3
This list shows the reasons for creating a conceptual model. The most important reason is that a conceptual model facilitates the discussion on the shape of the future system. It helps communication between you and your sponsor as well as you and your colleagues. A model also forms a basis for the default design of the physical database. Last but not least, it is relatively cheap to make and very cheap to change. What You Learn in This Course In this course you learn how to analyze the requirements of a business, how to represent your findings in an entity relationship diagram and how to define and refine the tables and various other database objects from that model. In summary, as a result of what you learn in this course you will know: How to model the information needs of a business and the rules that apply. Which tables you need in your database, and why. Which columns you need in your tables, and why.
Why Conceptual Modeling? .........................................................................................................................................
Which constraints and other database objects you require. You will also know how to explain this to: Your sponsors. The developers. Your fellow designers. The House Building Metaphor Imagine someone who wants to have a house built. Initially, the house only exists in the minds of the future home owners as ideas, or as pieces of various dreams. Sometimes the future inhabitants may not even know what they want, or know if what they want is even feasible. Dreams may be full of internal contradictions and impossibilities.This is not a problem in the dream world, but in the physical realm any inconsistencies and obstacles need to be resolved before someone can construct the house. About the slide See Page 44
Between Dream and Reality...
1-4
A building contractor needs a solid plan, a set of blueprints of the house with a description of the materials to be used, the size of the roof beams, the capacity of the plumbing and many, many other things. The contractor follows the plan, and has the knowledge to construct what is on the blueprint. But how do the ideas of the home owner become the blueprint for contractor? This is where the architect becomes involved.
......................................................................................................................................... 1-5
The Architect The architects are the intermediary between sponsor and constructor. They are trained in the skills of translating ideas into models. The architect listens to the description of the ideas and asks all kinds of questions. The architects skills in extracting the ideas, putting it down in a format that allows discussion and analysis, giving advice, describing sensible options, documenting it, and confirming it with the home owners, are the cornerstones to providing the future home-owner with a plan of the home they want. Sketches The architects understanding of the dreams is transformed into sketches of the new houseonly sketches! These consist of floor plans and several artists impressions, and show the functional requirements of the house, not the details of the construction. This is a conceptual model, the first version. Easy Change If parts of the model are not satisfactory or are misunderstood, the model can easily be changed. Such a change would only need a little time and an eraser, or a fresh sheet of paper. Remember, it is only changing a model. The cost of change at this stage is very low. Certainly it is far less costly than making changes to the floor plan or roof dimensions after construction has started. The house model is then reviewed again, and further changes are made. The architect continues to explore and clarify the dreams and make alternative suggestions until all controversial issues are settled, and the model is stable and ready for the final approval by the sponsor. Technical Design Then the architect converts the model into a technical design, a plan the contractor can use to build the house. Calculations are made to determine, for example, the number of doors, how thick the walls and floor beams must be, the dimensions of the plumbing, and the exact construction of the roof. These are technical issues that need not involve the customer. What? as Opposed to How? While the conceptual model addresses the What? phase in the process, the design addresses the question of How? it is to be constructed. Conceptual modeling is similar to the work of an architecttransforming things that only exist in peoples minds into a design that is sufficiently substantial to be created physically.
Entity Relationship Modeling .........................................................................................................................................
Entity Relationship Modeling

Entity Relationship Modeling
PRICE LEVEL
# CODE * DESCRIPTION
defined by
applied to
part of ORGANIZATION
Models business, not implementation Is a well-established technique Has a robust syntax Results in easy-toread diagrams ...although they may look rather complex at first sight
PUBLICATION
at
TITLE MOVIE
# PRODUCT CODE* CATEGORY * TITLE o AGE RATING o DESCRIPTION * DURATION * MONOCHROME o AUDIO o PREVIEW
o * o o o o o o o
EMAIL NAME POSTAL CODE REGION STREET TOWN TELEPHONE NUMBER CONTACT NAME CONTACT EXTENSION
parent organization o
the
GAME
* CATEGORY * MEDIUM o MINIMUM MEMO
SUPPLIER
for
PRICE HISTORY
# EFFECTIVE DATE * PRICE * DEFAULT DAYS * OVERDUE RATE
available available as reviewed in on
# SUPPLIER CODE o EMAIL * APPROVED * REFERENCE
the source of
OTHER ORGANIZATION
# REFERENCE * TITLE o VOLUME o ISSUE o PUBLISH DATE
CATALOG
# REFERENCE o CATALOG DAT o DESCRIPTION
the holder o
CUSTOMER managed b EMPLOYEE
* POSITION * LAST NAME o FIRST NAME o OTHER INITIALS o EMAIL o * * * o * * * * o o o o o EMAIL DESIGNATION FIRST NAME LAST NAME OTHER INITIALS STREET TOWN POSTAL CODE REGION HOME PHONE WORK EXTENSION WORK PHONE PHOTOGRAPH STAFF REMARKS
the source of the source of
the manager o
of
COPY
acquired fro m
the cancellor of responsible for
responsible for
* ACQUIRE DATE * PURCHASE COST * SHELF CODE o CONDITION o CUSTOMER REMARKS ...
the holder of responsible for

MEMBERSHIP TYPE
# CODE * DESCRIPTION * DISCOUNT PERCENTAGE o STANDARD FEE
rented on reserved on
held by held by in in
REVIEW
# SEQUENCE * ARTICLE * HOT o AUTHOR o URL
the type o of
of
MEMBERSHIP
approved by
# NUMBER o TERMINATION REASON o TERMINATION DATE
the reservation for for cancelled by
renewed fo r authorized by of requested against the PERIOD requestor MEMBERSHIP # START DATE o ACTUAL FEE PAID of approved by
used fo r
BOOKING
* BOOK DATE o EXPIRE DATE o NOTIFY DATE o RESERVE DATE o STAFF REMARKS
fulfilled as
RENTAL
* RENTAL DATE o STAFF REMARKS o COMPLETED
for
composed of for
RENTAL ITEM
# LINE NO * RENTAL PERIOD * PRICE PAID o RETURN DATE o STAFF REMARKS
the rental for
part of
1-5
What is Involved in Modeling? Entity Relationship modeling is about modeling a business. To be more precise: it is about modeling the data requirements for a business based on the current or desired functionality of the future system. To model a business you have to understand to a fair degree of detail what the business is about. Entity Relationship modeling is a technique used to describe the shared understanding of the information needs of a business. It is a well-established technique that leads to diagrams which are quite easy to read and therefore also easy to check.
......................................................................................................................................... 1-7
Goals of Entity Relationship Modeling

Goals of Entity Relationship Modeling
About the slide See Page 45
Capture all required information Information appears only once Model no information that is derivable from other information already modeled Information is in a predictable, logical place
1-6
The goals of conceptual data modeling are to ensure that: All pieces of information that are required to run a business properly are recognized. Models should be complete. Requirements should be known before you start implementing. Dependencies must be clear. Every single piece of required information appears only once in the model. This is an important goal. As soon as a system stores particular information twice, you run into the possibility that this information is not the same in both places. If you are a user of an information system and discover inconsistencies in the data, which information would you to trust? This goal implies that an ideal system does not contain derivable information. In the future system, the information is made available in a predictable, logical place; related information is kept together. A proper Entity Relationship model leads to a set of logically coherent tables.
Database Types .........................................................................................................................................
Database Types
Database Types
ER Model
Hierarchical Relational
Network
1-7
Entity Relationship modeling is independent of the hardware or software used for implementation. Although you can use an Entity Relationship model as a basis for hierarchical databases, network databases, and relational databases, it is strongly connected to the latter.
......................................................................................................................................... 1-9
Entities
This section gives definitions and examples. About the slide See Page 45
Entity
An Entity is:
Something of significance to the business about which data must be known. A name for the things that you can list. Usually a noun.
Examples: objects, events Entities have instances.
1-8
Definition of an Entity There are many definitions and descriptions of an entity. Here are a few; some are quite informal, some are very precise. An entity is something of interest. An entity is a category of things that are important for a business, about which information must be kept. An entity is something you can make a list of, and which is important for the business. An entity is a class or type of things. An entity is a named thing, usually a noun. Two important aspects of an entity are that it has instances and that the instances of the entity somehow are of interest to the business. Note the difference between an entity and an instance of an entity.
Entities .........................................................................................................................................
More on Entities About the slide See Page 46
Entities and Instances
PERSON PRODUCT PRODUCT TYPE EMPLOYMENT CONTRACT JOB SKILL LEVEL TICKET RESERVATION PURCHASE ELECTION PRINTER PREFERENCE DOCUMENT VERSION
1-9
Mahatma Gandhi 2.5 x 35 mm copper nail nail my previous contract violinist fluent tonight: Hamlet in the Royal the CD I bought yesterday for parliament next fall ...
The illustration shows examples of entities and examples of instances of those entities. Note: There are many entities. Some entities have many instances, some have only a few. Entities can be: Tangible, like PERSON or PRODUCT. Nontangible, like REQUIRED SKILL LEVEL. An event, like ELECTION. An instance of one entity may be an entity in its own right: the instance violinist of entity JOB could be the name of another entity with instances like David Oistrach, Kyung-Wha Chung.
......................................................................................................................................... 1-11
Entities and Sets

Entities and Sets
An entity represents a set of instances that are of interest to a particular business.

JOB
manager cook waitress dish washer financial controller waiter porter piano player
1-10
You can regard entities as sets. The illustration shows a set JOB and the set shows some of its instances. At the end of the entity modeling process entities are transformed into tables; the rows of those tables represent an individual instance. During entity modeling you look for properties and rules that are true for the whole set. Often you can decide on the rules by thinking about example instances. The following lessons contain many examples of this. Set Theory Entity relationship modeling and the theory of relational databases are both based on a sound mathematical theory, that is, set theory.
Attributes .........................................................................................................................................
Attributes
Attribute
Also represents something of significance to the business Is a single valued property detail of an entity Is a specific piece of information that:
Describes Quantifies Qualifies Classifies Specifies

an entity.
1-11
What is an Attribute? An attribute is a piece of information that in some way describes an entity. An attribute is a property of the entity, a small detail about the entity. Entities Have Attributes For now, assume that all entities have at least one attribute. Later, you discover exceptions to this assumption. The attribute describes, quantifies, qualifies, classifies, and specifies an entity. Usually, there are many attributes for an entity, but again, we are only interested in those attributes that are of importance to the business. Values and Data Types Attributes have values. An attribute value can be a number, a character string, a date, an image, a sound, and even more. These are called data types or formats. Usually the values for a particular attribute of the instances of an entity all have the same data type. Every attribute has a data type. Attribute is Single Valued An attribute for an entity must be single valued. In more precise terms, an entity instance can have only one value for that attribute at any point in time. This is the most important characteristic of an attribute. The attribute value, however, may change over time.
......................................................................................................................................... 1-13
Attribute Examples About the slide See Page 46 Practices See Page 47 This is a suitable place to do practices 1-1 and 1-2
Attribute Examples
Entity EMPLOYEE CAR ORDER JOB TRANSACTION EMPLOYMENT CONTRACT
Attribute Family Name, Age, Shoe Size, Town of Residence, Email, ... Model, Weight, Catalog Price, Order Date, Ship Date, Title, Description, ... Amount, Transaction Date, Start Date, Salary, ...
1-12
Note: Attribute Town of Residence for EMPLOYEE is an example of an attribute that is quite likely to change, but is probably single valued at any point in time. Attribute Shoe Size may seem to be of no importance, but that depends on the business: if the business supplies industrial clothing to its employees, this may be a very sensible attribute to take. Attribute Family Name may not seem to be single-valued for someone with a double name. This double name, however, can be regarded as a single string of characters that forms just one name. Volatile Attributes Some attributes are volatile (unstable). An example is the attribute Age. Always look for nonvolatile, stable, attributes. If there is a choice, use the nonvolatile one. For example, use the attribute Birth Date instead of Age.
Relationships .........................................................................................................................................
Relationships
Relationships
Also represent something of significance to the business Express how entities are mutually related Always exist between two entities (or one entity twice) Always have two perspectives Are named at both ends
1-13
Entities usually have relationships. Here are some examples. About the slide See Page 47
Relationship Examples
EMPLOYEES have JOBS JOBS are held by EMPLOYEES PRODUCTS are classified by a PRODUCT TYPE PRODUCT TYPE is a classification for a PRODUCT PEOPLE make TICKET RESERVATIONS TICKET RESERVATIONS are made by PEOPLE
1-14
......................................................................................................................................... 1-15
A relationship connects two entities. A relationship represents a significant dependency of two entitiesalways two entities. A particular relationship can be worded in many ways: An EMPLOYEE has a JOB, or an EMPLOYEE performs a JOB, or an EMPLOYEE holds a JOB. An EMPLOYEE applies for a JOB expresses a different relationship. Note that this example shows that two entities can have more than one relationship. About the slide See Page 47
Employees have Jobs

JOB EMPLOYEE
Shintaro Jill Ahmed Maria Adam waitress dish washer financial controller waiter porter piano player manager cook
Numerical observation:

1-15
All EMPLOYEES have a JOB

No EMPLOYEE has more than one JOB
Not all JOBS are held by an EMPLOYEE

Some JOBS are held by more than one EMPLOYEE
Based on what you know about instances of the entities, you can decide on four questions: Must every employee have a job? In other words, is this a mandatory or optional relationship for an employee? Can employees have more than one job? and Must every job be done by an employee? In other words, is this a mandatory or optional relationship for a job? Can a job be done by more than one employee? Later on we will see why these questions are important and why (and how) the answers have an impact on the table design.
Entity Relationship Models and Diagrams .........................................................................................................................................
Entity Relationship Models and Diagrams

An Entity Relationship Model (ER Model) is a list of all entities and attributes as well as all relationships between the entities that are of importance. The model also provides background information such as entity descriptions, data types and constraints. The model does not necessarily include a picture, but usually a diagram of the model is very valuable. An Entity Relationship Diagram (ER Diagram) is a picture, a representation of the model or of a part of the model. Usually one model is represented in several diagrams, showing different business perspectives. Graphical Elements Entity Relationship diagramming uses a number of graphical elements. These are discussed in the next pages. Unfortunately, there is no ISO standard representation of ER diagrams. Oracle has its own convention. In this course we use the Oracle diagramming technique, which is built into the Oracle Designer tool.
......................................................................................................................................... 1-17
Representation
Entity About the slide See Page 48
Entity Representation in Diagram

Drawn as a softbox Name singular Neither size, nor position has a special meaning
ELECTION
Name inside
EMPLOYEE
JOB
ORDER
TICKET RESERVATION
JOB ASSIGNMENT
During design, entities usually lead to tables.

1-16
In an ER diagram entities are drawn as soft boxes with the entity name inside. Borders of the entity boxes never cross each other. Entity boxes are always drawn upright. Throughout this book, entity names are printed in capitals. Entity names are preferably in the singular form; you will find that diagrams are easier to read this way. Box Size Neither the size of an entity, nor its position, has a special meaning. However, a reader might construe a larger entity to be of more importance than a smaller one. Where Entities Lead During the design for a relational database, an entity usually leads to a table.
Attribute Representation .........................................................................................................................................
Attribute Representation
Attributes in Diagrams
EMPLOYEE JOB
o
o o o
* Family Name * Address

Birth Date Shoe Size Email
* Title
Description
Mandatory attribute, that is, known and available for every instance to know for some instances
o Optional attribute, that is, unknown or unimportant
During design, attributes lead to columns.

1-17
Attributes are listed within the entity box. They may be preceded by a * or an O. These symbols mean that the attribute is mandatory or optional, respectively. Throughout this book attributes are printed in Initial Capital format.
* Mandatory:
It is realistic to assume that for every instance of the entity the attribute value is known and available when the entity instance is recorded and that there is a business need to record the value. o Optional: The value of the attribute for an instance of the entity may be unknown or unavailable when that instance is recorded or the value may be known but of no importance. Not all attributes of an entity need to be present in the diagram, but all attributes must be known before making the table design. Often only a few attributes are shown in a diagram, for reasons of clarity and readability. Usually you choose those attributes that help understanding of what the entity is about and which more or less define the entity. Where Attributes Lead During design an attribute usually leads to a column. A mandatory attribute leads to a not null column.
......................................................................................................................................... 1-19
Relationship Representation
Relationships are represented by a line, connecting the entities. The name of the relationship, from either perspective, is printed near the starting point of the relationship line. The shape of the end of the relationship line represents the degree of the relationship. This is either one or many. One means exactly one; many means one or more. About the slide See Page 48
Relationship in Diagrams
An employee has exactly one job
EMPLOYEE
has held by
JOB
Jobs are held by one or more employees
During design, relationships lead to foreign keys.

1-18
In the above example, it is assumed that JOBS are held by one or more EMPLOYEES. This is shown by the tripod (or crowsfoot), at EMPLOYEE. An EMPLOYEE, on the other hand, is assumed here to have exactly one JOB. This is represented by the single line at JOB. The relationship line may be straight, but may also be curved; curves have no special meaning, nor does the position of the starting point of the relationship line. The diagram below represents exactly the same model, but arguably less clearly.
has
JOB EMPLOYEE
held by
Relationship Representation .........................................................................................................................................
Mandatory and Optional Relationships Relationships can be mandatory or optional, in the same way as attributes. Mandatory relationships are drawn as a solid line; optional relationships as dotted lines.
mandatory: optional:
Relationship and Relationship Ends Here, the relationship between EMPLOYEE and JOB is modeled using the optional relationship end and mandatory relationship end notation. About the slide See Page 48
EMPLOYEE has
held by
JOB
When you read the relationship, imagine it split into two perspectives: About the slide See Page 48
EMPLOYEE has
held by
JOB
Every EMPLOYEE has exactly one JOB or, alternatively: An EMPLOYEE must have exactly one JOB.
EMPLOYEE has
held by
JOB
A JOB may be held by one or more EMPLOYEES.
......................................................................................................................................... 1-21
Reading a Relationship End About the slide See Page 49 Practices See Page 49 This is a suitable place to do practices 1-1 and 1-2
Reading a Relationship End

P
split into part of
must be exactly one Q Each oneinto or more Qs Each P P may be split into split may be one or more Qs
must be exactly one P of Each Q Each Q must be partpart of exactly one P may be one or more Ps
1-24
A relationship from entity1 to entity2 must be read: Each entity1 {must be | may be} relationship_name {one or more | exactly one} entity2 Where Relationships Lead During design relationships lead to foreign keys and foreign key columns. An optional relationship leads to non mandatory foreign key columns. Relationship Name in the Diagram Throughout this book relationship names in the diagrams are printed in lower case italics. For reasons of space and readability of the diagrams in this book, relationship names are sometimes kept very short, and sometimes only a preposition is used.
Data and Functionality .........................................................................................................................................
Data and Functionality

Functions Drive Data
Business functions are always present.
Explicit Assumed
Business functions need data. An entity, attribute, or relationship may be modeled because:
It is used by a business function. The business need may arise in the near future.
1-25
Functions Drive the Conceptual Data Model Although this course does not cover the method of function modeling, functions are present at any time, in any discussion on a conceptual data model. You cannot talk about, nor judge a conceptual data model without knowing or assuming the desired functionality of the future system. Often a conceptual data model discussion may seem to be about the data structure but actually is about functionality, usually unclear or undetermined pieces of functionality. The language used is that of the conceptual data model, the representation used is that of the entity relationship diagram, but the discussion in fact is about functionality. Functions drive the conceptual data model. The question Do we need to take Shoe Size for an employee? can only be answered by answering positively the question Is there a business function that needs it? Consider the conceptual data model as the shadow of the functions of a system. Most of the time during this course, functionality is only briefly sketched, or merely assumed, to prevent you from reading page after page of functional descriptions.
......................................................................................................................................... 1-23
Types of Information
Weather Forecast -DQXDU\ .EHQKDYQ %UHPHQ %HUOLQ 0QFKHQ $PVWHUGDP %UX[HOOHV 3DULV %RUGHDX[
1-26

What Information is Available? The illustration shows a piece of a weather forecast torn from a European newspaper, showing various types of information. What are the types of information? One of the first things you will see are, for example, Kbenhavn, Bremen. These are cities, or more precisely, names of cities. The little drawings represent the type of weather; these drawings are icons. The next columns are temperatures, probably maximum and minimum; the arrows indicate wind direction and the number next to it is the wind force. Then there is a date on top which is the forecast date. Therefore we have: City Name of the city (such as Kbenhavn) Weather type (such as cloudy with rain) Icon of the weather type Minimum temperature Maximum temperature Wind direction arrow Wind force Forecast date Is this all? No, you can find out even more information. To do this you have to have some business knowledge. In this case it is geographical knowledge.
Types of Information .........................................................................................................................................

DK IR UK NL BE Bruxelles
(Brussels) Bremen Berlin Amsterdam Kbenhavn (Copenhagen)
DE
Mnchen (Munich)
LU
Paris
FR
Bordeaux
CH IT
1-27
You may notice that the cities in the weather forecast are not printed in a random order. The German cities (Bremen, Berlin and Munchen) are grouped together, just as the French cities are. Moreover, the cities are not ordered alphabetically by name but seem to be ordered North-South. Apparently this report knows something to facilitate the grouping and sorting. This could be: Country of the city Geographical position of the city and maybe even Geographical position of the country Next Step Try to identify which of the above types of information is probably an entity, which is an attribute and which is a relationship. City and Country are easy. These are entities, both with, at least, attribute Name and Geographical Position. Weather Type could also be an entity as there is an attribute available: Icon. For the same reason there could be an entity Wind Direction. Now, where does this leave the temperatures and forecast date? These cannot be attributes of City as the forecast date is not single value for a City: there can be many forecast dates for a city. This is how you discover that there is still one entity missing, such as Forecast, with attributes Date, Minimum and Maximum Temperature, Wind Force.
......................................................................................................................................... 1-25
There are likely to be relationships between: COUNTRY and CITY CITY and FORECAST FORECAST and WEATHER TYPE FORECAST and WIND DIRECTION. About the slide See Page 50
Weather Forecast, a Solution

CITY * Name o Geographical Position
located in having
COUNTRY * Name o Geographical Position
subject of about
FORECAST * Date o Minimum Temperature o Maximum Temperature o Wind Force
referring to
WEATHER TYPE * Icon referred in * Description
referring to
WIND DIRECTION * Icon referred in * Description
1-28
In this entity relationship diagram some assumptions are made about the relationships: Every FORECAST must be about one CITY, and not all CITIES must be in a FORECASTbut may be in many Every CITY is located in a COUNTRY, and every COUNTRY has one or more CITIES A FORECAST must not always contain a WEATHER TYPE, and not all WEATHER TYPES are in a FORECASTbut may be in many A FORECAST must not always contain a WIND DIRECTION, and not all WIND DIRECTIONS are in a FORECASTbut may be in many The rationale behind these assumptions is that we consider an incomplete FORECAST still to be a FORECAST, unless we do not know the date or the CITY the FORECAST refers to.
Other Graphical Elements .........................................................................................................................................
Other Graphical Elements

Graphical Elements of ER Diagram

Entity Attribute Relationship Subtype Unique identifier Arc Nontransferability
# o #
* *
o
* *
1-29
The illustration shows all graphical elements you can encounter in a ER diagram. You saw earlier how to represent an entity, an attribute, and a relationship. The lessons following this one discuss the remaining four types of elements: Subtype, represented as an entity within the boundary of another entity Unique identifier, represented as a # in front of an attribute or as a bar across a relationship line Arc, represented as an arc-shaped line across two or more relationship lines Nontransferability symbol, represented as a diamond across a relationship line Limited Set of Graphical Elements As you can see, the set of graphical elements in ER diagramming is very limited. The complexity of ER modeling is clearly not in the representation. The main complexity of ER modeling lies in the understanding of the business, in the recognition of the entities that play a role in that business, the relevant attributes that describe the entities, and the relationships that connect them.
......................................................................................................................................... 1-27
Summary
Conceptual models are created to model the functional and information needs of a business. These models may be based on the current needs but can also be a reflection of future needs. This course is about modeling the information needs. Functional needs cannot be ignored while modeling data, as these form the only legitimate basis for the data model. Ideally, the conceptual models are created free of any consideration of the possible technical problems during implementation. Consequently the model is only concerned with what the business does and needs and not with how it can be realized.
Summary
ER Modeling models information conceptually Based on functional business needs What, not How Diagrams provide easy means of communication Detailed, but not too much
1-30
Entity Relationship modeling is a well-established technique for catching the information needs. The ER model forms the basis for the technical data model. Technical considerations take place at that level. Entity Relationship diagrams provide an easy-to-read and relatively easy-to-create diagrammatic representation of the ER model. These diagrams initially form the foundation for the discussion of business needs. Later they provide the best possible map of a future system. The diagrams show a fair amount of detail, but are not too detailed to become cluttered.
Practice 11: Instance or Entity .........................................................................................................................................
Practice 11: Instance or Entity

Goal (See Page 47) The goal of this practice is to learn to make a distinction between an entity, an attribute, and an instance of an entity. Your Assignment List which of the following concepts you think is an Entity, Attribute, or Instance. If you mark one as an entity, then give an example instance. If you mark one as an attribute or instance, give an entity. For the last three rows, find a concept that fits.
Practice: Instance or Entity?

Concept
PRESIDENT ELLA FITZGERALD DOG ANIMAL HEIGHT E A I CAR CAR CAR
E/A/I? Example Instance or Entity
1-32
......................................................................................................................................... 1-29
Practice 12: Guest

Goal (See Page 47) The goal of this practice is to recognize attributes for an entity. Scenario On the left side of the illustration are three entities that play a role in a hotel environment: GUEST, HOTEL, and ROOM. On the right is a choice of attributes. Your Assignment Draw a line between the attribute and the entity or entities it describes.
Practice: Guest
Address Arrival Date Family Name GUEST HOTEL ROOM Room Number Floor Number Number of Beds Number of Parking Lots Price TV set available?
1-33
Practice 13: Reading .........................................................................................................................................
Practice 13: Reading

Goal (See Page 49) The goal of this practice is to read a relationship. Your Assignment Which text corresponds to the diagram?
Practice: Reading
EMPLOYEE
assigned to responsible for
DEPARTMENT
Each EMPLOYEE may be assigned to one or more DEPARTMENTS Each DEPARTMENT must be responsible for one or more EMPLOYEES
Each EMPLOYEE must be assigned to one or more DEPARTMENTS Each DEPARTMENT may be responsible for one or more EMPLOYEES
Each EMPLOYEE must be assigned to exactly one DEPARTMENT Each DEPARTMENT may be responsible for exactly one EMPLOYEE
1-34
......................................................................................................................................... 1-31
Practice 14: Read and Comment

Your Assignment (See Page 49) 1 Read each of the relationships in the model presented here. 2 Next, comment on the relationship you just read. Use your knowledge of people and towns.
Practice: Read and Comment

PERSON
born in birthplace of living in home town of visitor of visited by mayor of with mayor
TOWN
1-35
Practice 15: Hotel .........................................................................................................................................
Practice 15: Hotel

Your Assignment (See Page 51) 1 Comment on the relationships of the model presented here.
Practice: Hotel
HOTEL * Address
the lodging for host of
ROOM * Room Number

with in in of guest in
STAY * Arrival Date
PERSON with * Name
1-36
2 Make up two more possible relationships between PERSON and HOTEL that
might be of some use for the hotel business.
......................................................................................................................................... 1-33
Practice 16: Recipe

Goal (See Page 51) The goal of this practice is to discover the various types of information that are present in a given source of information. Scenario You work as an analyst for a publishing company that wants to make recipes available on the Web. It wants the public to be able to search for recipes in a very easy way. Your ideas about easy ways are highly esteemed. Your Assignment 1 Analyze the example page from Ralphs famous Raving Recipes book and list as many different types of information that you can find that seem important.
Ralphs Raving Recipes
Soups
vegetarian 15 min easy
Aorda alentejana
bread soup from Portugal
for 4 persons:
1 onion 4 cloves of garlic 1 red pepper 1 liter of vegetable broth 4 tablespoons of olive oil 4 fresh eggs 1 handful of parsley or coriander salt, pepper 9-12 slices of (old) bread Cut the onion into small pieces and fry together with the garlic. Wash the red pepper, cut it in half, remove the seeds and fry it for at least 15
page 127
preparation
1-37
2 Group the various types of information into entities and attributes. 3 Name the relationships you discover and draw a diagram.
General Instructor Notes .........................................................................................................................................
General Instructor Notes

Course characteristics Data modeling is a topic that has been taught by Oracle in many countries for a considerable time. It is probably a course with the least number of changes and the longest history in Oracle Education. It is also a course with many different local flavors that have grown over time. In some countries the modeling course currently is a three-day event, with a lot of emphasis on database issues, in other countries the modeling course is a four-day course and only concerned with Entity Relationship Modeling. With this new course we had to provide material for both a three-day class and a fourday class, with centre of gravity in ER Modeling. Audience The audience for an ER modeling course today is different from the audience ten years ago. Some of Entity Relationship modeling is common knowledge today. That means this course can go beyond what a modeling course could achieve in the old days. As there is not more ER modeling to teach, the extension is mostly in the area of more (and more complex) business contexts, and that reflects changes in businesses of today as well. There are three main groups of attendees that form a very heterogeneous audience: (Future) database administrators (Future) analysts (Future) all-round Oracle specialists, focussed on developing applications Global perspective The course is intentionally a course with an international, global, perspective. Examples come from various parts of the world; entities like LANGUAGE and CURRENCY are made explicit in examples and practices. Database Design This course covers the initial transformation of the ER model into relational objects, of all elements of a ER model. Most of the elements have a clear counterpart in the physical world; sometimes there is choice, sometimes there is no general relational translation. This is partially related to relational databases in general, partially to Oracle in particular. In the chapter on Design Considerations we cover some of the design considerations that are specific to an Oracle environment.
......................................................................................................................................... 1-35
Normalization Normalization sits uneasily within the context of this course. We had long discussions about where to position the chapter in the text. Some wanted the topic removed from this course completely, others wanted it in the modeling part of the book, again others see it as a design topic. To cut the knot in a pragmatic way we have decided to put the chapter on Normalization in the appendix. One reason for this decision is that the material is already quite sizeable without this chapter. Moreover, this gives ample freedom to ignore it altogether or to teach it at the time you consider best (our suggestion would be to do it just before the chapter on Denormalization). Moonlight Coffees Moonlight Coffees is the name of the fictional global company that forms the central context in the practices. Many practices focus on various aspects of Moonlight. The case is built up in many steps. Be aware that you may know much more about Moonlight than the students do initially. Moonlight is a multinational like Starbucks and Seattles First. Its internal organization resembles the way Oracle is organized. ElectronicMail ElectronicMail is the name of another fictional company that forms the major context in the lessons and electronic presentation. Wherever it made sense we have used this context to illustrate modeling issues. In addition to that, we used many other smaller contexts that need no special introduction. Educational remarks This Data Modeling and Relational Database Design course is different from the other courses in the Designer area. This course is about a theory, about a method, about considerations and not about the use of software. This determines the different nature of the course. This course is typically a course that is based on interaction, particularly discussion. This course, and in particular the part about Entity Relationship modeling, is about gaining insights, rather than collecting knowledge. In many situations a student would not be helped at all by being presented with just the solution to a practice. They would probably even be further away from mastering the content of a practice (because they were not initially aware of the problem). They would not go through the mental process of, for example, analyzing, proposing, weighing-up, rejecting, and refining. This process, however, forms the basis of the skill of performing an analysis. Giving out a solution is killing this process. Some wheels have to be reinvented over and over again. Most practices win in effect, if they are discussed in the group. These discussions can take place at any time: at the start, at the end, and during the practice.
General Instructor Notes .........................................................................................................................................
Although students start working individually, they usually soon start discussing the work amongst themselves. After some time you should try to encourage everyone to participate in the discussion. Modeling is not a bag of tricks. Modeling is more a state of mind, an attitude. You learn modeling while you do it, and this is also true for someone who has already done a lot of modeling. This means that it really helps delegates to do as many practices as possible during the course when there is an environment for discussion and feedback. The total of theory on ER modeling is limited. This can be taught in, say, two hours, but that would only be touching the surface. Applying the modeling technique in real life (or almost real life) situations is the best way to learn it. Solutions Solutions to all practices are supplied at the end of the book. That means that delegates are able to cheatand some will do this. There is not much we can do about that. However, do not view this negatively. When students get stuck, the solutions help to get them moving again, but they will have learned less than they could have done. Tell your class cheating is allowed, but let them promise you that they ask you first before they cheat. That, probably, is the best way to handle it.
......................................................................................................................................... 1-37
Practices
There are many practices in this course. You are invited to make your selection. Use practices that you feel comfortable with, where you like the specific context, where you have additional experience. Classroom Discussion We strongly advise you to discuss every practice you do with the whole group. This will lead to more discussion and this type of discussion is very valuable. These discussions are probably as near to real life data modeling as you can get in a classroom situation. When to Do the Practices We strongly advise you not to postpone all practices till the end of the lesson (except for the last lessons). This table below suggests where to place the practices. You can use most of the suggested mid-lesson practices to check if the students have understood what you have just taught. Suggested Use In the table below practices are classified with one of Yes, Opt or Cha. Yes means we advise you to do this practice. Most of these are fairly short and are suggested as mid-lesson practice. Opt means we suggest to see this practice as optional. We advise you to select at least one of the optional practices per chapter. Cha means we think this practice is more challenging. Consider these optional as well. The challenging practices are mostly open-ended, more likely to end in a discussion about possible solutions than in the solution. These practices require some more insight and ask to apply things that were taught in other lessons than the last one or were not yet taught at all. Some may require problem-solving skills.
Ch 1 No 1 2 3 4 5 6 1 2 3 4 5 Practice When After Slide 1-12 After Slide 1-12 After Slide 1-24 After Slide 1-24 End of Lesson End of Lesson After Slide 2-12 After Slide 2-17 After Slide 2-17 End of Lesson End of Lesson 3 day event Yes Yes Yes Yes Yes Cha Yes Yes Yes Yes Cha 4 day event Yes Yes Yes Yes Yes Cha Yes Yes Yes Yes Cha
Instance or Entity
Guest Reading Read and Comment Hotel Recipe Books Moonlight Coffees Shops Subtypes Schedule
Practices .........................................................................................................................................
Ch
No 6 1 2 3 4 5 6 7 8 1 2 3 4 5 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3
Practice Address Read the Relationship Find a Context Name the Intersection Entity Receipt Moonlight P&O Price List E-Mail Holiday Identification Please Identification Moonlight UID Tables Constraints Shift Strawberry Wafer Bundles Product Structure Patterns Data Warehouse Argos and Erats Synonym Mapping Supertype Quality Check Subtype Implementation Quality Check Arc Implementation Primary Keys and Columns Name that Denormalization Triggers Denormalize Price Lists Global Naming Data Types Artificial Keys Product Pictures
When End of Lesson After Slide 3-11 After Slide 3-19 After Slide 3-34 End of Lesson End of Lesson End of Lesson End of Lesson End of Lesson After Slide 4-5 After Slide 4-10 End of Lesson End of Lesson End of Lesson End of Lesson End of Lesson End of Lesson End of Lesson After Slide 6-17 End of Lesson End of Lesson End of Lesson End of Lesson End of Lesson End of Lesson End of Lesson End of Lesson End of Lesson End of Lesson End of Lesson End of Lesson End of Lesson End of Lesson
3 day event Opt Yes Cha Yes Yes Opt Yes Opt Opt Yes Yes Opt Opt Cha Yes Opt Cha Opt Yes Opt Cha Opt Yes Yes Opt Opt Yes Yes Opt Opt Yes Opt Opt
4 day event Yes Yes Cha Yes Yes Cha Yes Cha Cha Yes Yes Yes Cha Yes Yes Yes Cha Cha Yes Yes Cha Cha Yes Yes Yes Yes Yes Yes Opt Cha Yes Cha Opt
Practice slides We have added slides for most of the practices, wherever it seemed practical. These often help to do practices as a classroom activity. The practice slides are located at the end of the presentation. You may want to reposition the practice slides within the presentation, but we strongly advise you not to do that. By changing the position of the
......................................................................................................................................... 1-39
slides, you change the slide numbers as they are visible during the show. Students use the slide numbers as a means to synchronize their book with your presentation and get very confused if the primary key has changed.
Suggested Timing .........................................................................................................................................
Suggested Timing
If you teach the three- day event, please tell your students that you will only do a selection of the practices and why. The schedule is based on a 6 hour teaching day. Three-Day Event
Day Three-Day Event Approximate Duration (min.) 180 180 60 210 90 60 60 60 60 60 60
1 2
Chapter 1 Chapter 2 (partial) Chapter 2 (rest) Chapter 3 Chapter 4 (partial) Chapter 4 (rest) Chapter 5 Chapter 6 Chapter 7 Chapter 8 Chapter 9
The Appendix on Normalization may take 30 minutes. Four-Day Event

Day Four-Day Event Approximate Duration (min.) 180 180 60 300 240 120 90 90 90 90
1 2 3 4
Chapter 1 Chapter 2 (partial) Chapter 2 (rest) Chapter 3 Chapter 4 Chapter 5 Chapter 6 Chapter 7 Chapter 8 Chapter 9
The Appendix on Normalization may take 30 minutes.
......................................................................................................................................... 1-41
Workshop Interviewing
Some of the practices can be done in different ways. In particular, the practice on Moonlight P&O in Lesson 3 can easily be transformed into a interview session. Other elements of Moonlight can be used in the same way. Usually delegates appreciate this kind of session very much, not only because it is fun to do, but certainly also because it opens their eyes to something that seems to be straightforward. This section describes a possible setup for an interview session. Goal The goal of this way of working is modest: to let delegates experience some of the problems that may occur when you have to acquire information through an interview. Your role You as the instructor play the role of the head of Moonlight Personnel and Organization (P&O) Department, Mr. or Mrs. Shadow. Prepare yourself using the text, and use whatever you know about Oracles internal organization as if it were the Moonlight organization. During the interviews, volunteer only a little information. Anything the students dont ask dont tell them! Talk about irrelevancies and about specific cases in much detail After the interviews let the groups work for some time without your interference. Start moving around doing some quality checks on the model when you see groups think they are ready. Search for similarities and distinctions between the solutions. Finally, the groups write their model on a large sheet of paper. Hang these on the wall for discussion. Ask one or two of the groups (draw lots if they are all eager to do it) to explain their solution. After the presentation you should do a short evaluation of what happened. Examples of things you can focus on: The type of questions they asked you The questions they did not ask you How well they used their time If they were carried away by a Moonlight Shadow The assumed information in the data models (you know what you told them!) Delegates role The delegates work in small teams of three or four and play the role of analysts. They are in the early stages of an analysis and they need to collect information. After data collection each group makes a model.
Workshop Interviewing .........................................................................................................................................
Instruction for the delegates This is your chance to practice interviewing. You will meet the head of Moonlight P&O, Mr. or Mrs. Shadow, and have a first opportunity to ask questions. You will be divided into groups. One group is randomly selected to start interviewing, getting 15 minutes interviewing time. The other groups may listen, but may not ask questions or give comments. The second group gets 10 minutes, the third and other groups 5 minutes each. Groups will have time to prepare the interview. The groups should make sure that responsibilities are clear. Who conducts the interview? Who takes notes? Who guards the time? After the interviews every group creates a model, only one solution per group, even if everyone in the group does not agree. After some time (about 20 minutes) you have a second chance to ask Mr. or Mrs. Shadow two questions per group to clarify what is still unclear. This interview time is your time. Use it well. What is needed? For the delegates Pencil Eraser Large sheets of paper for the presentation Felt tip pens Adhesive tape For you A cap or hat to wear when you play the role of Mr. or Mrs. Shadow
......................................................................................................................................... 1-43
Instructor Notes
1 1
Introduc tion to Entities, A ttribu tes , and R elatio nsh ips
Topic Lecture Practice Total
Timings 60 minutes 120 minutes 180 minutes
O verview
W h y co n c ep tu al m o d elin g ? Intro d u c tio n o f th e K ey role p lay ers :
E n tities A ttrib u tes R e la tio ns h ip s
1 -2
This chapter introduces entities, attributes and relationships, their representation and the mapping information of the database objects they map to. ER modeling in a mini-nutshell. Lesson 1 is a First Class chapter to the Focus chapters that follow. We believe this is a good approach from a educational point of view. Participants get an overall picture in an early stage of the course and can add details into that framework during the rest of the course. Creating conceptual models is relatively cheap as it has a great impact on the efficiency during the actual development of a system. For example, far fewer ambiguities, errors, and frustration. At the other hand: far better documentation, better understanding of what the business really wants, better decision processes. This is, of course, specially true when you use a Case tool like Oracle Designer where the transformers and generators do a lot of the work after analysis. The house metaphor is a metaphor for a method, not for modeling only. The analyst is the person between the dream and reality.
W hy C reate a C on ceptua l M odel?
It d e s crib e s ex ac tly th e in fo rm a tio n n ee d s o f th e b u s in es s It fa cilitates d is cu s s io n It h e lp s to p rev e nt m ista ke s, m is u n d ers tan d in g It fo rm s im p o rtan t id e al sy ste m d o cu m en tatio n It fo rm s a s ou n d ba s is fo r p h ys ica l da tab a se d e sig n It is a v ery g o o d p ra c tic e w ith m a n y p rac titio n ers
1 -3
B etw ee n D ream and R eality...
1 -4
Instructor Notes .........................................................................................................................................
Entity R ela tion ship M o delin g

PRICE LEVEL
# CODE * DESCRIPTION
defined by
applied to
ORGANIZATION
part of
M o d e ls b u s in e ss , n o t im plem en tatio n Is a w e ll-e stab lish e d tec h n iq u e H a s a ro b u s t sy n ta x R e su lts in e as y -to re ad d iag ram s ...a lth ou g h th e y m ay loo k ra the r c o m p le x a t first s ig h t
PUBLICATION
# REFERENCE * TITLE o VOLUME o ISSUE o PUBLISH DATE
at
TITLE
# PRODUCT CODE * TITLE o DESCRIPTION
MOVIE
* CATEGORY o AGE RATING * DURATION * MONOCHROME o AUDIO o PREVIEW
o EMAIL * NAME o POSTAL CODE o REGION o STREET o TOWN o TELEPHONE NUMBER o CONTACT NAME o CONTACT EXTENSION
parent organization of
the
GAME
* CATEGORY * MEDIUM o MINIMUM MEMORY
SUPPLIER
for
PRICE HISTORY
# EFFECTIVE DATE * PRICE * DEFAULT DAYS * OVERDUE RATE
available reviewed in available as on the source of
# SUPPLIER CODE o EMAIL * APPROVED * REFERENCE
OTHER ORGANIZATION
CATALOG
# REFERENCE o CATALOG DATE o DESCRIPTION
the holder o
CUSTOMER managed by EMPLOYEE
* POSITION * LAST NAME o FIRST NAME o OTHER INITIALS o EMAIL o EMAIL * DESIGNATION * FIRST NAME * LAST NAME o OTHER INITIALS * STREET * TOWN * POSTAL CODE * REGION o HOME PHONE o WORK EXTENSION o WORK PHONE o PHOTOGRAPH o STAFF REMARKS
the source of the source of
the manager of
of
COPY
acquired fro m
the cancellor of
responsible for
responsible for
* ACQUIRE DATE * PURCHASE COST * SHELF CODE o CONDITION o CUSTOMER REMARKS ...
the holder of responsible for

MEMBERSHIP TYPE
# CODE * DESCRIPTION * DISCOUNT PERCENTAGE o STANDARD FEE
rented on
reserved on
held by in in
REVIEW
# SEQUENCE * ARTICLE * HOT o AUTHOR o URL
the type o held by of
of
MEMBERSHIP
# NUMBER o TERMINATION REASON o TERMINATION DATE
approved by
the reservation for for cancelled by requested against
renewed fo r authorized by the requestor of
used fo r
of
BOOKING
* BOOK DATE o EXPIRE DATE o NOTIFY DATE o RESERVE DATE o STAFF REMARKS
MEMBERSHIP PERIOD
# START DATE o ACTUAL FEE PAID
fulfilled as
approved by
RENTAL
* RENTAL DATE o STAFF REMARKS o COMPLETED
for
composed of for
RENTAL ITEM
# LINE NO * RENTAL PERIOD * PRICE PAID o RETURN DATE o STAFF REMARKS
the rental for
part of
1 -5
G oa ls o f En tity R ela tion ship M o delin g
C a ptu re a ll req u ired info rm atio n Info rm atio n a p p ears o nly on ce M o d e l n o in fo rm a tio n th at is d eriv ab le fro m o th er info rm atio n a lre ad y m o d e led Info rm atio n is in a p red ic ta b le , lo g ica l p la ce
1 -6
The only once criterion is important, maybe even more important than the all. You could refer to the experience many delegates will have when searching for information on the Web. There are many Web sites with many internal information inconsistencies, sometimes even within one and the same web page. A normal and sensible reaction is to distrust all information on that site. A classical picture that tells that an ER model captures business information that can be used as a basis for any database, as the model tells something about the business, not about the implementation. Having said that, in practice 99.99% of the ER models lead to relational database implementations. Mention that an Entity was originally called an instance of an Entity Type which was a more accurate naming. That is history now. In this book we use the commonly-used words entity and instance.
D atabas e Ty pes
E R M odel
H ierarchical R elational
N etw ork
1 -7
En tity
A n E n tity is :
S o m e th in g o f sig n ific an ce to th e b u sin es s a b o u t w h ic h d ata m u s t be k n o w n . A n am e fo r th e th in g s th at y o u ca n list. U s u ally a n o u n .
E xa m p le s: o b je cts , e ve n ts E n tities h av e in stan ce s.
1 -8
......................................................................................................................................... 1-45
E ntities and Instanc es
P ER S O N PRODUCT P R O D U C T TY P E E M P LO Y M E N T C O N T R A C T JO B S K ILL LE V E L TIC K E T R ES E R VA TIO N P U R C H A SE E L EC T IO N P R IN TE R P R E FE R E N C E D O C U M E N T V ER S IO N

1 -9
M ah atm a G a nd hi 2 .5 x 35 m m co pp er nail n ail m y previo us co ntrac t v iolinist flue nt ton igh t: H am let in the Ro ya l the C D I b oug h t yes te rd ay for pa rliam ent ne xt fall ...
Some entities are simple, tangible concepts, like PERSON or COMPANY. Some entities are almost tangible such as the event ELECTION. Some can be surprisingly complex concepts, such as a DOCUMENT VERSION. There is no clear line between entity and instance. Entity can be seen as the name of a set. Set theory is the basic mathematical concept behind ER modeling and Relational Databases.
E ntities and S ets
A n e n tity re p re se nts a s et o f in sta n ce s th a t are o f inte res t to a p a rtic u lar b u sin e ss .

JO B
m anager cook w aitres s dish w ash er financial controller w aiter porter piano p layer
1 -1 0
A ttribu te
A ls o re p re sen ts so m eth in g o f s ig n ifica n ce to th e b u s in es s Is a s in g le va lu e d p ro p erty d eta il o f a n en tity Is a s p ec ific piec e o f in fo rm atio n th a t:
The crucial issue here is the fact that an attribute must be single valued at any point in time. If that is not the case, the attribute hides a relationship.
D e sc rib e s Q u an tifie s Q u alifies C las sifie s S p ec ifie s
a n e n tity .
1 -1 1
A ttrib ute E xam ples
E n tity EMPLOYEE C AR ORDER JO B T R A N S A C T IO N EM PLOYM ENT C O N T R A CT
A ttrib u te F a m ily N a m e , A g e, S h o e S ize, T o w n o f R e s id en c e, E m a il, ... M o d e l, W eig h t, C atalo g P rice , O rd er D ate, S h ip D ate, T itle, D esc riptio n , ... A m ou n t, Tran s ac tio n D ate, S tart D a te , S ala ry , ...
1 -1 2
There are, on purpose, some disputable attributes here. You could ask delegates to comment on them in the light of the previous slide. You might ask delegates to make up more attributes per entity. It is likely the implicit definitions of the entities start to move after adding attributes, for example, when someone suggests Color or Licence Number as attribute for CAR.
Practice: Instan ce or E ntity?

C o nc ep t
P R E S ID E N T E LLA FITZG E R A LD DOG A N IM A L H E IG H T E A I CAR CAR CAR
E /A /I? E xam ple Ins tan ce or E ntity
Practice Good practice to discuss jointly. Initially, let the students find examples individually.
1 -3 2
Prac tice: G u est

A d d re ss A rriva l D a te F a m ily N a m e GUEST H O TE L RO O M R o o m N u m be r F lo o r N um b er N u m b e r o f B ed s N u m b e r o f P a rk in g L o ts P ric e T V s et av a ilab le?
1 -3 3
Practice Good practice to do jointly. Allow the students some time to think about it.
R elatio nsh ips
A ls o re p re sen t s o m e th in g o f sig n ific an ce to th e b u s in es s E xp re ss h o w en titie s a re m u tu ally re la ted A lw ay s e x ist b e tw ee n tw o e n tities (o r o n e en tity tw ice ) A lw ay s h a v e tw o p e rs p ec tive s A re n a m ed at b o th en d s
1 -1 3
Note that the wording is not yet standardized.

R elatio nship Ex am ples
E M P L O Y E E S h av e JO B S J O B S are h e ld b y E M P L O Y E E S P R O D U C TS a re cla ss ifie d b y a P R O D U C T T Y P E P R O D U C T T Y P E is a c la ss ific atio n fo r a P R O DU C T P E O P L E m ak e T IC K E T R E S E R V AT IO N S T IC KE T R E S E R V A T IO N S a re m a de b y P E O P L E
1 -1 4
E m ployees h ave Job s

JOB EM P LO Y E E
S hintaro Jill A hm ed M aria A dam w aitre ss dish w as her financial controller w aiter porter piano p layer m anager cook
N u m e ric al o b se rv atio n :
The numerical observations form the basis for the optionality and degree of the relationship. The next step is to generalize from the observation: is it always the case that no employee has more than one job?

1 -1 5
A ll E M P L O Y E E S h av e a J O B
N o E M P L O Y E E h as m o re th an on e J O B
N o t a ll J O B S are h e ld b y an E M P L O Y E E
S o m e JO B S are he ld b y m o re th an on e E M P L O Y E E
......................................................................................................................................... 1-47
Entity R epres entatio n in D iag ra m

D ra w n a s a s o ftb o x N a m e sin gu la r N e ith er s ize , n o r p os itio n h a s a s p ec ia l m e an in g
ELECTION
Do not mention any details now, but you should disclose the fact that entities lead to tables.
N a m e in s id e
E M P LO Y E E
JO B
ORDER
TIC K E T R E S E R V A TIO N
JO B A S S IG N M E N T
D u rin g d es ig n , e n tities u su ally lea d to ta b le s.

1 -1 6
A ttribu tes in D iag ra m s

EM PLOYEE JO B
o
o o o
* Fam ily N am e * A dd ress

B irth D ate S ho e S ize E m ail
* T itle
D e scriptio n
*
o
M an d ato ry a ttrib u te , th at is , kn o w n a n d a va ila b le for ev ery in stan c e O p tio n al attrib u te, th at is , u n k n ow n o r un im p o rtan t to kn o w fo r so m e in s tan c es
We use an initial capital for attributes throughout the book. This is different from what Designer shows. It takes, however, far less space to print them and it is easier to write in longhand.
D u rin g d es ig n , a ttrib u te s lea d to c olu m n s.

1 -1 7
R elationsh ip in D iagram s
ex actly ne A n e m p loy ee h as e xac tly o on e jo b
E M P L O YE E
has held by
JO B
The build in this slide shows step by step how the degree of a relationship is represented. The first step of the build turns the word has to italic and green. This is not immediately obvious so point it out to the class.
Job s a re he held ld b y o ne or m o re em ploye es ore
D u rin g d es ig n , re la tio n sh ip s le a d to fo re ig n k ey s.
1 -1 8
Tw o Persp ective s
Degree of the relationship, from two perspectives. This is only touched here. More details in the chapter on Relationships
JO B
E M P L O YE E
has
held by
1 -2 1
One Way
E M P L O YE E
has held by
JO B
A relationship end (this is Oracle Designer jargon) is drawn in three pieces: The name, near the entity The optionality, near the entity The degree, near the opposite entity
1 -2 2
The O th er W ay
E M P L O YE E
has
JO B
held by
1 -2 3
The reading formula.

R ea ding a R elatio nsh ip En d
P
split in to pa rt o f
m ust be e xa ctly o ne Q E ach P m ay be sp lit intosplit o nein oto r m o re Q s E a ch P m ay be o n e o r m ore Q s
m u st b e e xactly on e P E a ch Q E a ch Q m u st b e pa rtpa o frteof xactly on e P m ay b e on e or m ore P s

1 -2 4
Prac tice: R ead in g

E M P LO YE E
assigne d to responsible for
Practice Good practice to do jointly.
D E PA R T M E N T
E ach E M P LO Y E E m ay be assigned to one or m ore D E P A R TM E N TS E ach D E P A R TM E N T m ust be resp onsible for one or m ore E M P LO Y E E S
E ach E M P LO Y E E m ust be assigne d to one or m ore D E P A R TM E N TS E ach D E P A R TM E N T m ay be respo nsible for one or m ore E M P LO Y E E S
E ach E M P LO Y E E m ust be assigne d to exactly one D E P A R TM E N T E ach D E P A R TM E N T m ay be respo nsible for exactly one E M P LO Y E E
1 -3 4
Prac tice: R ead and C o m m ent

PERSON
born in birthplace of living in hom e tow n of visitor of visite d by m ayor of w ith m ayor
TOW N
1 -3 5
Practice Good practice to do jointly. Let the delegates read a relationship end aloud. This is much more difficult for a novice than you and they are likely to be aware of. It helps to overcome the embarrassment when everyone has some problems. It also sets the scene for many joint discussions and activities.
......................................................................................................................................... 1-49
Fu nctions D rive D ata
B u sin es s fu n c tio ns a re alw ay s p re sen t.
E xp licit A s su m ed
B u sin es s fu n c tio ns n e ed da ta. A n e n tity , attrib u te , o r re latio n s hip m a y be m o d ele d b ec au s e:
It is u se d b y a b u s in e ss fu nc tio n . T he b u s in es s ne e d m a y a ris e in th e ne ar fu tu re .
Functionality drives data. This course is not about function modeling. Nevertheless, functions are always in the background. It does not make sense to create a data model when there is no information about the functions that define the scope.
1 -2 5
W ea th er F orecas t
Eh h ! % F i r u h 7 r r 7 r yv H pur 6 r q h 7 r yyr Q h v 7 q rh

1 -2 6
This example introduces the idea of types of information. Almost everything on this overview can be named as a particular type of information. Some clearly are entities, some clearly are attributes, some are unclear. Let the delegates make suggestions. They will be surprised by the number of different types of information. The hidden information is also important. This may become clear when the map is shown and people discover the North/South sorting.
DK IR UK NL BE B ruxelles
( B russels ) B rem en A m sterdam
K benhavn ( C openhagen )
DE
B erlin
LU
P aris
M nchen ( M unich )
FR
B ordeaux
CH IT
1 -2 7
W eathe r Fo rec ast, a So lution

C IT Y * N am e G e ographical P osition
loc ated in having
C O U N TR Y * N am e o G eographica l P osition
subject of ab out
FO R E C A S T * D ate o M inim u m Tem perature o M axim um Tem perature o W ind F orce
referring to
W E A TH E R TY P E * Icon referre d in * D escription W IN D D IR E C TIO N * Icon referre d in * D esc ription
referring to
The model is, of course, only one possible solution. It is made quite overwhelming on purpose. The simple clipping from the paper can contain 5 entities, 10 attributes and 4 relationships. In other words: there is a danger of underestimating.
1 -2 8
G raph ical Elem ents of E R D iag ra m

E n tity A ttrib u te R elatio n s h ip S u b typ e U n iq u e id en tifie r A rc N o n tra n sfe rab ility
# o #
* *
o
* *
This slide is to show that the set of graphical elements of ER diagrams is very limited. Modeling is not about learning a lot of syntax. Modeling is about understanding business contexts, about analyzing real world things.
1 -2 9
Sum m ary
E R M o de ling m o d els info rm a tio n c o nc e p tu a lly B a se d o n fu n ctio n a l b u s in es s ne e ds W h a t, n o t H ow D ia g ra m s p ro vid e e as y m ea n s of c o m m u n ic a tio n D e ta ile d , b u t n o t to o m u c h
1 -3 0
Suggested Use of Practices

Prac tices
Ins tan c e o r E n tity G ue s t R e ad in g H o tel R e cipe
1 -3 1
Practice Instance or Entity Guest Reading Read and Comment Hotel Recipe
3day Yes Yes Yes Yes Yes Cha
4day Yes Yes Yes Yes Yes Cha
Pra ctice : H o tel

H O T EL * A ddress
the lodgin g fo r host of
ROOM * R o om N um ber
w ith in in of guest in
Practice Do not explicitly go into the notion of an intersection entity, such as STAY. This will be covered in Chapter 3.
S TA Y * A rrival D ate
P ER S O N
w ith * N am e
1 -3 6
R alphs R avin g R ecipes
So ups
vegetarian 15 m in easy
A ord a a len tejan a

b read soup from P ortugal
fo r 4 p erso ns:
1 on ion 4 clo ves of garlic 1 red pepper 1 lite r of vegetable broth 4 tab lespoons of olive o il 4 fre sh eggs 1 ha ndful of parsley or c oriander salt, pepper 9-12 slices of (old) brea d C ut the onio n into sm all pieces and fry tog ether w ith the garlic. W ash the red pepper, cut it in half, rem ove the seeds and fry it for at least 15
page 127
preparation
Practice Allow the students some time (say ten minutes) to find types of information individually. Next, collect the results on the white board, making a long list. Accept whatever is given for now, and discuss later.
1 -3 7
......................................................................................................................................... 1-51
Instructor Post Lesson Teaching Evaluation .........................................................................................................................................
Instructor Post Lesson Teaching Evaluation

Name: Full Email:
Course Name: Data Modeling and Relational Database Design Lesson number: 1 Number of teaches before filling this form: 1 - 2 - 3 to 5 - >5 Global comments: (circle all that apply) Lesson content: Trivial - Too easy - OK - Difficult - Too difficult Slide content: Too many slides - Too few slides - O.K Text content.Too much text - Not enough text - Unclear - O.K. Practice content: Too difficult - Too easy - Problems - O.K. Detail comments Content type: Slide - Text - Practice - Instructor notes Note: 1:needs animation - 2:too much animation - 3:needs more text - 4:too much text - 5:Unclear - 6:not necessary - 7:Other
Content
Type
Page Number
Note
Comments/Suggestions
Photocopy this page and fax to: Oracle Designer Education Products @ +(44) 118.924.5181 Additional sheets are available at the end of the instructors guide. If you draw additional diagrams on white board use the Graphic sheet in the Instructor Evaluation section at the end of this book.
......................................................................................................................................... 1-53
Suggested Graphics .........................................................................................................................................
Suggested Graphics
Instructor name: Full email:
Course Name:Data Modeling and Relational Database Design Lesson No: 1 Page No: Please sketch your additional diagram below.
......................................................................................................................................... 1-55
Oracle Designer Education Products Curriculum Development 520 Oracle Parkway Thames Valley Park Reading - Berkshire England
fold here
2
.................................
Entities and Attributes in Detail
Lesson 2: Entities and Attributes in Detail .........................................................................................................................................
Introduction
Lesson Aim This lesson provides you with a detailed discussion about entities and attributes and how you can track these in various sources of information. The lesson looks at the evolution of an entity definition and the concept of subtype and supertype entity. The lesson also introduces the imaginary business of ElectronicMail Inc.which is used in many examples throughout this book. Schedule See Page 28 About this slide See Page 28
Overview
Data compared to information Entities and how to track them down Attributes Subtypes and supertypes
2-2
Topic Introduction Data Compared to Information Data Tracking Entities Electronic Mail Example Evolution of an Entity Definition Functionality Tracking Attributes Subtypes and Supertypes Summary Practice 21: Books
See Page 2 4 5 7 9 11 13 14 17 20 21
Introduction .........................................................................................................................................
Topic Practice 22: Moonlight Practice 23: Shops Practice 24: Subtypes Practice 25: Schedule Practice 26: Address
See Page 22 23 24 25 26
Objectives At the end of this lesson, you should be able to do the following: Track entities from various sources Track attributes from various sources Decide when you should model a piece of information as an entity or an attribute Model subtypes and supertypes
......................................................................................................................................... 2-3
Data Compared to Information

Data Compared to Information
About this slide See Page 28
Data
Facts given from which other facts may be inferred Raw material
Example: Telephone Directory
Information
Knowledge, intelligence
Example: Telephone number of florist
2-3
The words data and information are often used as if they are synonyms. Nevertheless, they have a different meaning. Data: Raw material, from which you can draw conclusions. Facts from which you can infer new facts. A typical example is a telephone directory. This is a huge collection of facts with some internal structure. Information: Knowledge, intelligence, a particular piece of data with a special meaning or function. Often information leads to data. In reverse, information is often the result of the deriving process from datathis may be a particular piece of data. If data is structured in some way, this is very helpful in the process of finding information. To expand the telephone directory data example, information is the telephone number of your dentist or the home address of a colleague.
Data .........................................................................................................................................
Data
Data
Data~
Modeling, Conceptual Structuring data concepts into logical, coherent, and mutually related groups Modeling, Physical Modeling the structure of the (future) physical database Base A set of data, usually in a variety of formats, such as paper and electronically-based Warehouse A huge set of organized information
2-4
Conceptual Data Modeling Conceptual data modeling is the examination of a business and business data in order to determine the structure of business information and the rules that govern it. This structure can later be used as the basis for the definition of the storage of the business data. Conceptual data modeling is independent of possible technical implementations. For that reason, a conceptual data model is relatively stable over longer periods of time, as businesses change, often only gradually, over a period of time. Conceptual Data modeling is also called Information Engineering. Physical Data Modeling Physical data modeling is concerned with implementation in a given technical software and hardware environment. The physical implementation is highly dependent on the current state of technology and is subject to change as available technologies rapidly change. A technical design made five years ago is likely to be quite outdated today. By distinguishing between the conceptual and physical models, you separate the rather stable from the rather unstable parts of a design. This is true for both data models and functional specifications.
......................................................................................................................................... 2-5
Database A database is a set of data. The various parts of the data are usually available in different forms, such as paper and electronic-based. The electronic-based data may reside, for example, in spreadsheets, in all kinds of files, or in a regular data base. Today, relational databases are very common; but many older systems are still around. The older systems are mostly hierarchical databases and network databases. Systems of more recent date are semantic databases and object oriented databases. Data Warehouse A data warehouse is composed of data from multiple sources placed into one logical database. This data warehouse database, (or, more correctly, this database structure), is optimized for Online Analytical Processing (OLAP) actions. Often a data warehouse contains summarized data from day-to-day transaction systems with additional information from other sources. An example is a phone company that tracks the traffic load for a routing system. The system does not store the individual telephone calls, but stores the data summarized by hour. From a data analysis point of view a data warehouse is just a database, like any other, only with very specific and characteristic functional requirements.
Tracking Entities .........................................................................................................................................
Tracking Entities
The nouns in, for example, the texts, notes, brochures, and screens you see concerning a business often refer to entities, attributes of entities, or instances of entities. About this slide See Page 29
Entities
Give the entity a unique name Create a formal description of the entity Add a few attributes, if possible Be aware of homonyms Check entity names and descriptions regularly Avoid use of reserved words Remove relationship name from entity name
2-5
Naming an Entity Uniquely First distinguish an entity by outlining the concept in your mind. Next, try to find a unique and clear name for an entity. This is not always easy as there are far more concepts than clear names. Use your imagination. Use a dictionary. Use a combination of words, use X if necessary, but do not let the lack of a good name stop you from modeling. Good names evolve over time. Check the names you used every now and then. The implicit definition of an entity may change during analysis, for instance, as a result of adding an attribute or changing the optionality of a relationship. Creating a Formal Description Create a formal description of the entity. This is usually not difficult and the writing helps clarify your thinking about what you are talking about. Check this description regularly. Sometimes concepts evolve during the modeling process. The definitions, of course, should follow that evolution. Be Aware of Synonyms In many business contexts one and the same concept is known under different names. Select one and mention the synonyms in the description: ...also known as ....
......................................................................................................................................... 2-7
Avoid Homonyms Often in a business one word is used for different concepts. Sometimes even the same person will use the same word but with different meanings as you can see in the next example. The data modeling course you attend now was written in 1999 and requires modeling skills to teach. In this sentence the word course refers to three different concepts: a course event (like the one you are attending today), a course text (which was written in 1999) and the course type (that apparently needs particular skills). Avoid Reserved Words Although you are free to use any name you want for an entity, try to avoid database and programming terms as entity names if possible. This may prevent naming problems and confusion later on in the design stage. Remove Relationship Name from Entity Name Often you can select entity names in a more or less generic way. In the example, both diagrams model the same context. In the first the guest aspect is part of the entity name as well as part of the relationship name. About this slide See Page 29
GUEST
guest of host of
HOTEL
PERSON
guest of host of
ACCOMMODATION
The second model is more general in its naming. There a guest is seen as a PERSON playing the role of being a guest. As a rule, if there is choice take the more general name. It allows, for example, for the addition of a second relationship between the same entities that shows, for example, person is working for or is owning shares in the accommodation. The first model would require new entities. This subject is closely related to the concept of subtypes and roles. You find more on this later in this lesson and when we discuss Patterns.
Electronic Mail Example .........................................................................................................................................
Electronic Mail Example

In this course we investigate various business contexts. One is that of ElectronicMail, a company that supplies an e-mail service. Here is some background information. About this slide See Page 29
Some Background Information

ElectronicMail (EM) wants to provide an attractive and user- friendly Web-based e-mail system. Important concepts are user and message. An EM user has a unique address of 30 characters at most and a password supplied by the person who set up the EM user. Who the person really is, we do not know, although we ask for some additional information, such as the name, country, birth date, line of business, and a few more things. Users must be able to send and receive mail messages. A mail message is usually a piece of straight text. A message may have attached files. An attachment is a file, like a spreadsheet, that is sent and kept with the message, but not created with our software. Messages are kept in folders. Every user has three folders to start with: Inbox, Outbox, and Wastebasket. Additional folders can be created by the user.
2-7
(0
&RPSRVH
Ayqr 6qqrr U) Qrsrrpr 8p) BrIrHhvy @v
ORJR
&RPSRVH
Tiwrp)
DGYHUWLVHPHQW DUHD s
Uryhr
default
test bipi, giovanni_papini@yahoo.com myself
7pp)
Hrhtr
DGYHUWLVHPHQW DUHD
r)
e tc sk
fs o h
en cre
this is a test and a text as well tralalalala pompidom
to
s po m co
il m a m
sa es
ge
Trq
Thr9hs
ThrUryhr 8hpry
Frr 8
6hpur) 6qq Tvthr
Ur)
abc.html xyz.doc
Hypertext Word document
2-8
......................................................................................................................................... 2-9
The screenshots may give an idea of how the Compose a Mail Message screen and the Maintain Addresses screen will look like.
(0
&RPSRVH
Ayqr
ORJR
DGYHUWLVHPHQW DUHD
$GGUHVVHV
Ivpxhr 6yvh @hvyhqqr
$GGUHVVHV
Qrsrrpr BrIrHhvy @v
apple bipi joe myself
DGYHUWLVHPHQW DUHD
e tc k s
fs ho bipi
svrq
e cre
nt
a om
w.j.appletree@cats.com sabine_papini @yahoo.com j.suspender@last.com jtiddlywink@em.com
in
na i a t
s se s dre
joe giovanni_papini@yahoo.com p.g.m.papini@em.com
2-9
Some Desired Functionality

Users of ElectronicMail must be able to address messages to a mail list, for example, a group of e-mail addresses. The system should only keep one copy of the message sent (to save database space) plus information about whom the message was sent to. Users must be able to create templates for their messages. A template must be named and may contain everything a real message contains. A template may be used for new messages. Users must be able to reply to a message. By replying the user creates a new message to which the old message is added. Users must be able to create an alias for an e-mail address, to hide the often complex addresses behind an easy-to-remember nickname.
About this slide See Page 30 Practice See Page 30 This is a suitable place to do practices 2-1.
2-10
Evolution of an Entity Definition .........................................................................................................................................
Evolution of an Entity Definition

To illustrate the evolution of a concept, consider ElectronicMails entity MESSAGE. The first intuitive description of this entity may be:
A message is a piece of text sent by a user.
Any user? Well, no.

A message is a piece of text sent by an EM user.
Must every message contain text? Should it not be possible to send a message that only transports an attachment, without additional text?
A message is a note that is sent by an EM user. A message does not necessarily contain text, nor a subject, etc.
And what about a message that comes from an external source and is received by a EM user? Should those not be kept as well?
A message is a note that is sent by an EM user or received by an EM user or both. A message does not necessarily contain text, nor a subject, etc.
Now suppose a message is sent by an EM user to an external e-mail address only. Suppose the EM user does not want to keep a copy of the mail message. In that case there is no need for the system to keep the message as there is no internal EM user that needs the message. In fact, it is not important at all to keep messages that were sent by a EM user; only those that were actually received by an EM user are of interest.
A message is a note that is received by an EM user. A message does not necessarily contain text, nor a subject, etc.
The thinking process shown here is typical for the change of a definition from the first idea to something that is much more well thought-outthough this does not mean that the definition is final.
......................................................................................................................................... 2-11
Entity Life Cycle It often helps to make things clear if you think about the life cycle of an entity. The life cycle refers to the functional steps of the entity. For example, how can the entity instance come into existence? How can it change? How does it disappear? In case of entity MESSAGE the questions are: When does something become a message? When does a message change? When can a message be removed? Creating a Message When I type in some text in the compose screen, is that text a message? You will probably agree that it does not make much sense to consider it as a message until some fields are completed, such as the To or Subject field. The checks must take place after I hit the send key. Only after all checks have been made is the message born. Removing a Message When can the system remove a message? When a user hits the delete key? But what should the system do when there are other receivers of that same message? It is better to consider the deleting of a message as the signal to the system that you no longer need the right to read the message. When all users that did receive the same message have done this, then the message can be deleted. Apparently, for a message to exist it must have receivers that still need the message. Changing a Message Changing a message? As long as the text is not sent, it is no problem as it is not yet considered to be a message. Changing it after sending it? Changing something that is history? This cannot be done. Changing the text should lead to a new message. Draft What about a message that is not yet ready for sending? Suppose a user wants to finish a message at a later date. Is there a place for this? Do we want an unsent, or draft, message in the system? Is a DRAFT a special case of entity MESSAGE, or should we treat a DRAFT as a separate entity? Template What about the templates? A template is about everything a message can be, but a template is only used as a kind of stamp for a message. Templates are named, messages are not. Is TEMPLATE a special case of entity MESSAGE, or should we look upon it as a separate entity?
Functionality .........................................................................................................................................
Functionality
In the previous evolution of the entity definition, the definition changes were invoked by thinking and rethinking the functionality of the system around messaging. This illustrates the statement made earlier: functions drive the conceptual data model.
Business Functions
Users of ElectronicMail must be able to address messages to a mail list, for example, a group of e-mail addresses. The system should only keep one copy of the message sent (to save data base space) plus information about whom the message was sent to. Users must be able to create templates for their messages. A template must be named and may contain everything a real message contains. A template may be used for new messages. Users must be able to reply to a message. By replying the user creates a new message to which the old message is added. Users must be able to create an alias for an e-mail address, to hide the often complex addresses behind an easy-to-remember nickname.
2-11
The first idea of the functionality of a system, or desired functionality, can be derived from the verbs in, for example, descriptive texts and interview notes. In the above text the functionality is expressed at a high level, without much detail. Nevertheless, you can probably imagine more detailed functionality. In this course functionality is always present, often implicitly assumed, sometimes in detail.
......................................................................................................................................... 2-13
Tracking Attributes
An Attribute...
Always answers of what? Is the property of entity, not of relationship Must be single valued Has format, for example:
Character string Number Date Picture Sound
2-13
Is an elementary piece of data
As discussed earlier, the nouns in, for example, the texts, notes, brochures, and screens you see used in a business often refer to entities, attributes of entities, or instances of entities. You can usually easily recognize attributes by asking the questions Of what? and Of what format?. Attributes describe, quantify, qualify, classify, specify or give a status of the entity they belong to. We define an attribute as a property of an entity; this implies there is no concept of a standalone attribute. In the background information text on ElectronicMail that is shown below, the first occurrence of the (probable) entities are capitalized, the attributes are boxed and instances are shown in italics.
ElectronicMail (EM) wants to provide an attractive and user friendly Web-based email system. Important concepts are user and message. An EM USER has a unique address of 30 characters at most and a password supplied by the PERSON who set up the EM user. Who the person really is, we do not know, although we ask for some additional information, like the name, COUNTRY, birth date, line of business, and a few things more. Users must be able to send and receive mail MESSAGES. A mail message is usually a piece of straight text. A message may have attached files. An ATTACHMENT is a file, like a spreadsheet, that is sent and kept with the message, but not created with our software. Messages are kept in FOLDERS. Every user has three folders to start with: Inbox, Outbox and Wastebasket. Additional folders can be created by the user.
Tracking Attributes .........................................................................................................................................
List the types of information, distinguish the probable entities and attributes and group them. Add attributes, if necessary, (like Name of COUNTRY) in the example. Distill one or more attributes from the instances (like Name of FOLDER).
EM Entities and Attributes

Nouns
user address password person name country birth date occupation message text attachment file folder inbox outbox wastebasket
Entities/Attributes/ Instances
USER Address Password PERSON Name COUNTRY Birth Date Occupation MESSAGE Text ATTACHMENT File FOLDER Inbox Outbox Wastebasket
Entities with their Attributes

USER - Address - Password PERSON - Name - Birth Date - Occupation COUNTRY - Name MESSAGE - Text ATTACHMENT - Filename FOLDER - Name
Naming Attributes Attribute names become the candidate column names at a later stage. Column names must follow conventions. Try to name attributes avoiding the use of reserved words. Do not use abbreviations, unless these were decided beforehand. Examples of frequently-used abbreviations are Id, No, Descr, Ind(icator). Do not use attribute names like Amount, Value, Number. Always add an explanation of the meaning of the attribute name: Amount Paid, Estimated Value, Licence No. Always put frequently-used name components, such as date or indicator, of attribute names in the same position, for example, at the end Start Date, Creation Date, and Purchase Date. Do not use underscores in attribute names that consist of more than one word. Keep in mind that attribute names, like entity names, must be as clear and understandable as possible.
......................................................................................................................................... 2-15
Entities Compared to Attributes Sometimes a piece of information that is an attribute in one context is an entity in another context. This is purely specific to the business. A typical attribute, like Name, may need to be modeled as an entity. This happens, for example, when the model needs an extra dimension, such as the language. If product names must be kept in several languages and prices must be kept in various currencies, you may suddenly find one product has several names. For example: This particular article of clothing is named Acapulco swimming trunks in English, and Akapulko Badehose in German. A commonly encountered dimension is time. This is discussed later. About the slide See Page 31
Attribute and Entity

GARMENT Name Price
Attributes in one model can be entities in another.
GARMENT
CURRENCY
PRICE
NAME
LANGUAGE
2-16
Redundancy You should take special care to prevent using redundant attributes, that is, attribute values that can be derived from the values of others. An example is shown below. Using derivable information is typically a physical design decision. This is also true for audit type attributes such as Date Instance Created, and User Who Modified. About the slide See Page 31 Practice See Page 31 This is a suitable place to do practices 2-2 and 2-3
COMMODITY * Name * Price exclusive VAT * Price inclusive VAT * VAT %
Subtypes and Supertypes .........................................................................................................................................
Subtypes and Supertypes

Sometimes it makes sense to subdivide an entity X into subtypes. This may be the case when a group of instances has special properties, such as attributes or relationships that only exist for that group, or a fixed value for one of the attributes, or when there is some functionality that only applies to the group. Such a group is called a subtype of X. Entity X is called the supertype as a consequence. Subtypes are also modeled when particular constraints apply to the subtype only. This is discussed further in the lesson on Constraints. About the slide See Page 32
A Subtype ...
Inherits all attributes of supertype Inherits all relationships of supertype Usually has its own attributes or relationships or business functions Is drawn within supertype Never exists alone May have subtypes of its own Is also known as Subentity LIST ADDRESS USER
2-18
Subtypes have all properties of X and usually have additional ones. In the example, supertype ADDRESS is divided into two subtypes, USER and LIST. One thing USER and LIST have in common is an attribute NAME and the functional fact that they can both be used in the To field when writing a message. Inheritance In the next illustration, is a new entity, COMPOSITION, as a supertype of MESSAGE, DRAFT, and TEMPLATE. The subtypes have several attributes in common. These common attributes are listed at the supertype level. The same applies to relationships. Subtypes inherit all attributes and relationships of the supertype entity.
......................................................................................................................................... 2-17
COMPOSITION
o o o o
Subject Cc Bcc Text
DRAFT * Name TEMPLATE * Name
MESSAGE
Read the diagram as: Every MESSAGE (DRAFT, or TEMPLATE) is a COMPOSITION and thus has attributes like Subject and Text. Conversely: Every COMPOSITION is either a MESSAGE, a DRAFT, or a TEMPLATE Always More Than One Subtype Entity relationship modeling prescribes that when an ER model is complete subtypes never stand alone. In other words, if an entity has a subtype, there should always be at least a second subtype. This makes sense. What use would there be for distinguishing between an entity and the single subtype? This idea leads to the two subtype rules. About the slide See Page 32
Subtype: Rules
Subtypes of the same entity must be:
Exhaustive: Every instance of a supertype is also instance of one of the subtypes Mutually exclusive: Every instance of the supertype is of one and only one subtype
and
Name subtypes adequately:
A B C NON B OTHER A
2-20
Subtypes and Supertypes .........................................................................................................................................
Nested Subtypes You can nest Subtypes. For readability, you would not usually subtype to more than two levels, but there is no major reason not to do so. Reconsider the placement of the attributes and relationships after creating a new level. About the slide See Page 33
COMPOSITION OTHER o Subject COMPOSITION o Cc * Name

o Bcc o Text
DRAFT *DRAFT Name
MESSAGE
TEMPLATE TEMPLATE * Name
Subtypes Always Exist Every entity can always be subtyped. You can always make up a rule to subdivide the instances in groups, but that is not the issue. The reason for subtyping should always be that there is a business need to show similarities and differences at the same time. About the slide See Page 33
More on Subtypes
Subtypes always exist...

EMPLOYEE
CURRENT EMPLOYEE OTHER EMPLOYEE
... but do not all make sense

EMPLOYEE
EMPLOYEE WITH SHOE SIZE > 45 OTHER EMPLOYEE
2-22
Implementing Subtypes You can implement subtype entities in various ways, for example, as separate tables or as a single table, based on the super entity.
......................................................................................................................................... 2-19
Summary
Entities can often be recognized as nouns in texts that functionally describe a business. Entities can be tangible, intangible, and events. Subtypes of an entity share all attributes and relationships of that entity, but may have additional ones.
Summary
Entities
Nouns in texts Tangible, intangible, events
Attributes
Single-valued qualifiers of entities

Subtypes
Inherit all attributes and relationships of supertype May have their own attributes and relationships
2-23
Attributes are single-valued elementary pieces of information that describe, qualify, quantify, classify, specify or give a status of the entity they belong to. Most entities have attributes. Every attribute can be promoted to a separate entity which is related to the entity the attribute initially belonged to. You must do this when you discover that the attribute is not single valued, for example, when names must be kept in multiple languages or values in multiple currencies.
Practice 21: Books .........................................................................................................................................
Practice 21: Books

Goal (See Page 30) The goal of this practice is to differentiate between various meanings of a word used in a text. Your Assignment 1 In this text the word book is used with several meanings. These meanings are different entities in the context of a publishing company or a book reseller. Try to distinguish the various entities, all referred to as book. Give more adequate names for these entities and make up one or two attributes to distinguish them.
1. I have just finished writing a book. Its a novel about justice and power. 2. We have just published this book. The hard cover edition is available now. 3. Did you read that new book on Picasso? I did. It's great! 4. If you like you can borrow my book. 5. I have just started translating this book into Spanish. I use the modern English text as a basis and not the original, which is 16th century. 6. I ordered that book for my parents. 7. Yes, we have that book available. You should find it in Art books. 8. A second printing of the book War and Peace is very rare. 9. I think My name is Asher Lev is one of the best books ever written. Mine is autographed. 10. I want to write a book on entity relationship modeling when I retire.
2-25
2 Create an ER model based on the text. Put the most general entity at the top of your
page and the most specific one at the bottom. Fit the others in between. Do not worry about the relationship names.
......................................................................................................................................... 2-21
Practice 22: Moonlight

Moonlight Coffees
Scenario (See Page 31) You work as a contractor for Moonlight Coffees Inc. One of your colleagues, who is a business analyst, has prepared some documentation. Below you find an extract from the summary document.
Your Assignment 1 Make a list of about 15 different entities that you think are important for Moonlight Coffees. Use your imagination and common sense and, of course, use what you find in the summary that is printed below.
Moonlight Coffees
Summary
Moonlight Coffees is a fast growing chain of high quality coffee shops with currently over 500 shops in 12 countries of the world. Shops are located at first-class locations, such as major shopping, entertainment and business areas, airports, railway stations, museums. Moonlight Coffees has some 9,000 employees.
Products
All shops serve coffees, teas, soft drinks, and various kinds of pastries. Most shops sell nonfoods, like postcards and sometimes even theater tickets.
Financial
Shop management reports sales figures on a daily basis to Headquarters, in local currency. Moonlight uses an internal exchange rates list that is changed monthly. Since January 1, 1999, the European Community countries must report in Euros.
Stock
Moonlight Coffees is a public company; stock is traded at NASDAQ, ticker symbol MLTC. Employees can participate in a stock option plan.
2-26
2 Write a formal definition of the entity that represents:
The coffee shops. The Moonlight employees.
Practice 23: Shops .........................................................................................................................................
Practice 23: Shops

Moonlight Coffees
Scenario (See Page 32) You work as a contractor for Moonlight Coffees. Your task is to create a conceptual data model for their business. You have collected all kinds of documents about Moonlight. Below is a page of a shop list.
Your Assignment Use the information from the list as a basis for an ER model. Pay special attention to find all attributes.
Shop List
Moonlight Coffees
Shoplist, ordered to date opened
page 4
181 The Flight, JFK Airport terminal 2, New York, USA, 212.866.3410, Airport, 12-oct-97 182 Hara, Kita Shinagawa,Tokyo, JP, 3581.3603/4, Museum, 25-oct-97 183 Phillis, 25 Phillis Rd, Atlanta, USA, 405.867.3345, Shopping Centre, 1-nov-97 184 JFK, JFK Airport terminal 4, New York, USA, 212.866.3766, Airport, 1-nov-97 185 VanGogh, Museumplein 24, Amsterdam, NL, 76.87.345, Museum, 10-nov-97 186 The Queen, 60 Victoria Street, London, UK, 203.75.756, Railway Station, 25-nov-97 187 Wright Bros, JFK Airport terminal 1, New York, USA, 212.866.9852, Airport, 6-jan-98 188 La Lune, 10 Mont Martre, Paris, FR, 445 145 20, Entertainment, 2-feb-98 189
2-27
......................................................................................................................................... 2-23
Practice 24: Subtypes

Goal (See Page 34) The goal of this practice is to determine correct and incorrect subtyping. Your Assignment Find all incorrect subtyping in the illustration. Explain why you think the subtyping is incorrect. Adjust the model to improve it.
Subtypes
DISABLED PERSON
DEAF BLIND OTHER DISABLED PERSON
CAR
STATION WAGON SEDAN
BUILDING
HOUSE
HOTEL
ROOM WITH BATH OTHER ROOM
DOG
DOMESTIC ANIMAL MAMMAL
2-28
Practice 25: Schedule .........................................................................................................................................
Practice 25: Schedule

Moonlight Coffees
Scenario (See Page 34) You work as a contractor for Moonlight Coffees.
Your Assignment Use the schedule that is used in one of the shops in Amsterdam as a basis for an entity relationship model. The schedule shows, for example, that in the week of 12 to 18 October Annet B is scheduled for the first shift on Monday, Friday, and Saturday.
van Gogh, Museumplein, Amsterdam Schedule Oct 12 - Oct 18 Shift Annet S Annet B Dennis Jrgen Kiri Wil 3 4 1 2 2 1 2 Mon Tue Wed 2 prepared by Janet Thu Fri 2 1 3 5 4 4 Sat 2 1 Sun 1
2-29
The scheme suggests there is only one shift per person per day.
......................................................................................................................................... 2-25
Practice 26: Address

Goal (See Page 34) The goal of this practice is to sort out various ways of modeling addresses. Your Assignment An entity, possibly PERSON (or ADDRESS) may have attributes that describe the address as in the examples below.
Practice: Address (1/2)
Rheingasse 123 53111 Bonn Germany 1020 Maple Drive Kirkland WA 98234 USA
34 Oxford Road Reading Berkshire RG1 8JS UK
1 How would you model the address information if the future system is required to
produce accurate international mailings?
Practice 26: Address (continued) .........................................................................................................................................
Practice 26: Address (continued)

Your Assignment (See Page 34) 2 Would your model from the previous practice also accept the addresses below?
P.O. Box 66708 Nairobi Kenya
c/o Mrs Smith Maude Street Sandton Johannesburg 2144 South Africa
3 Check if your model would be different if the system is also required to have
facilities to search addresses in the following categories. Make the necessary changes, if any. All addresses: In Kirkland With postal code 53111 in Bonn That are P.O. Boxes On: Oxford Road or Oxford Rd or OXFORD ROAD or OXFORD RD in Reading
......................................................................................................................................... 2-27
Instructor Notes
Instructor Note Topic Timings Lecture 60 minutes Practice 180 minutes Total 240 minutes
2 2
E ntities and A ttrib utes in D etail
O verview
D a ta c o m p are d to in fo rm a tio n E n tities an d h o w to trac k th e m d o w n A ttrib u te s S u bty p es a nd su p e rtyp e s
This chapter addresses how to track entities, the importance of naming and clear definitions. Then attributes are discussed and the thin line between entity and attribute. Subtypes are introduced and the reasons for modeling subtypes. This is followed by a large number of practices. There is a distinction between data and information, although both terms are often used interchangeably.
2 -2
D ata C om pared to Info rm a tion
D a ta
F acts g iv en fro m w h ic h o the r fa cts m ay b e in fe rre d R a w m aterial
E xa m p le : T elep h o n e D irec to ry
Info rm atio n
K n o w led g e , in te llig e n ce
E xa m p le : T elep h o n e n u m be r of flo rist
2 -3
Some definitions.
D ata
D ata ~
M o d elin g , C o nc ep tu al S tru c tu rin g d ata c o n ce p ts in to lo g ic al, co h e re nt, a nd m u tu a lly re lated g ro up s M o d elin g , P h y sic al M o d elin g th e stru ctu re o f the (fu tu re ) ph y sic a l d ata ba se B as e A s et o f d ata, u su a lly in a va rie ty o f fo rm ats, s u ch a s p a p er a n d e lec tro n ica lly -b a sed W are h ou s e A h u g e s e t of o rg a nized in fo rm a tio n
2 -4
E ntities
G ive th e e n tity a u n iq u e n a m e C re ate a fo rm al d es cription o f th e en tity A d d a few attrib u tes , if p os sib le B e a w are o f h o m o n y m s C h ec k en tity n am e s an d de sc rip tio n s re g u larly A v oid u se o f re se rv ed w o rd s R e m o ve re la tio ns h ip n a m e fro m e n tity n am e
A working description of an entity. The formal definition is important. Attributes help define the entity.
2 -5
R elation ship N am e in Entity N am e
GUEST
guest of host of
HOTEL
PERSON
gu est of host of
A C C O M M O D A T IO N
Although it is not always possible to avoid it, try not to have the relationship as part of the entity name. Typical examples that are hard to get rid of: EMPLOYEE should be a PERSON that is employed by ... This is related to the concept of roles. In the lesson texts the company ElectronicMail plays a prominent role. Many examples refer to their mail business. The context of e-mail is a very convenient one for this purpose as almost every student has a fairly good understanding of e-mail from the perspective of a user. This context is 100% similar in various places around the world. More on ElectronicMail. This screen is for composing messages and templates, for example. You can see the possibility of adding attachments to a mail. Note the single line field for multiple addresses. As often: buttons represent functionality.
2 -6
S om e B a ckg ro und Inform ation

E lectronicM ail (E M ) w ants to provide an attractive and user- friendly W e b-based e-m ail syste m . Im portant concepts are user and m essage . A n E M user has a uniq ue address of 30 c haracters at m ost and a pa ssw ord supplied by the person w ho set up the E M user. W ho the pe rson really is, w e do not know , although w e ask for som e addition al info rm ation, such as th e nam e, country, birth da te, line of business, and a few m ore things. U s ers m ust be able to send and receive m ail m e ssages. A m ail m e ssage is usually a p iece of straight text. A m e ssage m ay have attached files. A n attac hm ent is a file, like a sp readsheet, that is sen t an d kept w ith the m es sage, but not create d w ith our softw are. M e ssages are kept in folders. E very user has th ree folders to start w ith: Inb ox, O utbox, and W astebasket. A ddition al folders can be created by the user.
2 -7
&RPSRVH
A yq r 6 q q rr
(0 ORJR
&RPSRVH
T i wrp ) U)
DGYHUWLVHP HQW DUHD es ag

U r yh r
d efault
Qr sr r p r 8 p) B rI r H h vy 7 pp )
@ v
H r h t r
DGYHUWLVHPHQW DUHD
r )
sk
e tc
f ho
sc
ma bipi, giovan ni_ pa pin i@ ya ho o.com se m yself po m co to th isn a test e is a tex t as we ll r eand tra lalala la
te st pom p ido m
il m
es
T r q T h r 9 h s
Th rU r yh r
8 h p ry
F rr 8
6 h p u r ) 6 qq T vt h r
U r)
a bc.htm l xyz.do c
Hyp ertext W ord d ocum e nt
2 -8
&RP SRVH
A yq r
(0 ORJR
$GGUHVVHV
I vp x h r 6 yvh
DGYHUWLVHP HQW DUHD es

@ h vyh q q r
$GGUHVVHV
Qr sr r p r B rI r H h vy
ap ple bipi jo e m yself
@ v
DGYHUWLVHPHQW DUHD
sk
sc of t c h bipi
B
re
w.j.ap pletree@ cats.com in sab ina e_p apini @ yaho o.com j.susp m en der@ last.com t o jtid dlyw ink@ em .com n e
n ta i
ad
dr
es
Screen to create aliases and to create and maintain user lists. These concepts will be used later on in many examples. Make sure everybody knows these ideas.
svr q
jo e giova nni_pa pini@ yaho o.com p.g.m .pa pin i@ e m .co m
2 -9
......................................................................................................................................... 2-29
E volutio n of an Entity D efin ition

A m es s ag e is a p iec e o f te xt s en t b y a us e r. A m es s ag e is a p iec e o f te xt s en t b y an E M u se r. A m es s ag e is a n ote th at is s en t b y an E M u se r. A m e ss a g e d o e s n ot n e ce ss arily co n ta in tex t, n o r a s u b jec t, e tc . A m es s ag e is a n ote th at is s en t b y an E M u se r o r re ce iv ed b y a n E M u s er o r b o th . A m e ss a g e d o e s n ot n e ce ss arily co n tain tex t, n o r a su b jec t, etc . A m es s ag e is a n ote th at is re ce iv ed b y a n E M u s er. A m e ss a g e d o e s n ot n e ce ss arily co n ta in tex t, n o r a s u b jec t, e tc .
2 -1 2
This slide shows clearly the evolution of a definition. The initial definition seemed simple and to the point, but after some iterations the definition seems much better. This process is important. Later, during practices, you should often ask students what their definition is of an entity that seems odd, instead of showing what (you think) is wrong. Practice This is quite a complex practice. It forces students to think about implicit definitions and the differences between them. A good question to start the discussion: which text lines use book for the same concept?
1. I have just finished w riting a book. Its a nove l about justice and pow er. 2. W e have just publis hed this book. The ha rd cover edition is available now . 3. D id you read that n ew book on P icasso ? I did. It's great! 4. If you like you can borrow m y book. 5. I have just started translating this book into S panish. I use the m odern E nglish text as a ba sis and not the orig inal, w hich is 16th century . 6. I ordered that book for m y parents. 7. Y es, w e have that book available. Y ou should find it in A rt boo ks. 8. A second printing o f the book W ar and P eace is very rare. 9. I think M y nam e is A sher Lev is one of the best books ever w ritte n. M ine is autographe d. 10. I w ant to w rite a bo ok on entity relationship m odeling w hen I retire.
2 -2 5
A n A ttribu te...
A lw ay s a n s w e rs o f w ha t? Is th e p ro p erty o f en tity, n o t o f rela tio n s hip M u st be s in g le va lu e d H a s fo rm a t, fo r e xa m p le :

C haracter string N um ber D ate P icture S ound
The third bullet: single-valued is probably the most important. You will often use phrase this to show that something cannot be an attribute of a suggested entity
2 -1 3
Is a n e lem en tary p ie ce o f d a ta
N oun s, En titie s, A ttrib ute s

E lectronicM ail (E M ) w ants to provide an attractive and user friendly W e b-based em ail system . Im portant concepts a re user and m essage . A n E M U S E R has a uniq ue address of 30 chara cters at m ost and a pa ssw ord supplied by the P E R S O N w ho set up the E M user. W ho the pe rson really is, w e do not know , although w e ask for som e addition al info rm ation, like the na m e, C O U N TR Y , birth date , line of business, and a few things m ore. U s ers m ust be able to send and receive m ail M E S S A G E S . A m ail m e ssage is usually a p iece of straight text. A m e ssage m ay have attached files. A n A TT A C H M E N T is a file, like a spreadsheet , that is sen t and kept w ith the m essage, but not c reated w ith our softw are. M e ssages are kept in FO LD E R S . E very user has three folders to sta rt w ith: Inbox , O utbox and W as tebasket . A dditional fo lders can be created by the user.
Nouns in (spoken) text often lead to Entities Attributes Instances of entities
2 -1 4
E M E ntitie s a nd A ttribu tes

N o uns
u ser ad d ress p asswo rd p erso n n am e co u ntry b irth date o ccup atio n m essag e text attach m en t file fo lder in b ox o u tb ox w astebasket
E n tities/A ttributes/ Ins tances

U SE R A d dress Passw ord PE R SO N N am e COUNTRY B irth D ate O ccu patio n M E SS A G E Text A T TA C H M E N T File FO L D ER Inb ox O utb ox W asteb as ket
E n tities w ith their A ttributes

U SE R - A d d ress - P assw o rd PE R SO N - N am e - B irth D ate - O ccup atio n COUNTRY - N am e M ESS A G E - T ext A T TA C H M E N T - F ilen am e FO L D ER - N am e
2 -1 5
A ttribute and E ntity

GARMENT N am e P rice
A ttrib u te s in o n e m o d el c an b e e n titie s in a n o th e r.
GARMENT
CU RRENCY
P R IC E
NAME
LANGUAGE
If a business is language-dependent, the model will contain many entities that would have been an attribute in a single language environment. When you do an analysis for a system that may be used in other countries, be aware of this language layer. Currency is another layer, but usually of less impact. Redundancy usually leaves you with a choice. Which of the attributes can remain, which is removed? Of course, redundancy can be more complex than the example, when several entities are involved.
2 -1 6
R edu ndan cy
C O M M O D IT Y * N am e * P ric e exclu sive V AT * P ric e inclu sive V AT * VAT %
2 -1 7
M o on lig h t C o ffees
S um m ary
M oonlight C offe es is a fast grow ing chain of high quality coffee shops w ith currently over 500 sho ps in 12 countries of th e w orld. S hops are located at first-clas s locations, such as m ajor shopping, entertainm ent and business areas, airp orts, railw ay stations , m useum s. M oonlig ht C offees has som e 9,000 em ployees.
P roducts
A ll shops serve coffees, teas, soft d rinks, and various k inds of pastries. M ost sho ps sell nonfoo ds, like postcards and som etim es even theater tick ets.
Financial
S hop m ana gem ent reports sales fig ures on a daily bas is to H eadquarters, in local currency. M oon light uses an interna l exchange rates lis t that is changed m onthly. S ince Janua ry 1, 1999, the E urope an C om m unity coun tries m ust report in E uros.
S tock
M oonlight C offe es is a public com p any; stock is traded at N A S D A Q , ticker sym b ol M LTC . E m ploye es can participate in a stock option pla n.
2 -2 6
Practice Introduction of Moonlight Coffees, the chain of coffeeshops that we will visit in many practices. This text provides a general overview, shows some of the business areas. List the entities on the white board and leave it there for the rest of the week. During the next days you can mark the entities that have been investigated more closely and the entities that have been replaced by others.
......................................................................................................................................... 2-31
Sh op List
M oo n lig h t Co ffee s
Practice Straightforward practice.

page 4
Shoplist, ordered to date opened 181 182 183 184 185 186 187 188 189
T he Flight, JF K Airport term inal 2, N ew York, U SA , 212.866.3410, Airport, 12-oct-97 H ara, Kita Shinagaw a,Tokyo, JP, 3581.3603/4, M useum , 25-oct-97 P hillis, 25 Phillis R d, A tlanta, U SA , 405.867.3345, Shopping C entre, 1-nov-97 JF K , JF K A irport term inal 4, N ew Y ork, U S A, 212.866.3766, Airport, 1-nov-97 V anGogh, M useum plein 24, Am sterdam , N L, 76.87.345, M useum , 10-nov-97 T he Q ueen, 60 V ictoria Street, London, U K, 203.75.756, R ailw ay S tation, 25-nov-97 W right Bros, JFK Airport term inal 1, N ew York, U SA , 212.866.9852, A irport, 6-jan-98 La Lune, 10 M ont M artre, Paris, F R , 445 145 20, E ntertainm ent, 2-feb-98
2 -2 7
A Sub type ...
Be aware that the word inheritance is a loaded term in Object Modeling.
Inh e rits all a ttribu te s o f s u p erty pe Inh e rits all re la tion s h ip s o f su p e rtyp e U s ua lly h a s its o w n attrib u tes o r re la tio n sh ip s o r b u s in es s fun ctio n s Is d raw n w ith in s up ertyp e N e ve r e xists a lo n e M ay h a ve s u bty p es o f its o w n Is a ls o kn o w n as S u be n tity L IS T A DD RE S S USER
2 -1 8
S ubtyp e: E xam ple
C O M P O S ITIO N
o o o o
S ubject Cc B cc Text MESSAGE
D R A FT * N am e TE M P LA TE * N am e
2 -1 9
Sub typ e: R ules

S u b ty p es o f th e s a m e en tity m u st b e :
E xh a u stiv e: E ve ry in s ta n ce o f a su p e rty p e is also in s tan c e o f o n e o f th e s u b ty p es M u tu ally e xc lu s ive : E ve ry in s ta n ce o f th e s u p erty p e is o f o n e an d on ly o n e s ub ty p e
and
Often the second subtype is called NON-B. This naming is fine as long as there are only two subtypes. When there is a third, the name should be replaced by, for example, OTHER A.
Na m e s u bty p es ad e q ua tely:
A B C NON B O TH E R A
2 -2 0
Sub typ es: T hree Le vels
C O M P O S ITIO N O TH E R o S ubject C O M P O S IT IO N o Cc * Name

o B cc o Text
D R A FT *D N am e R A FT
MESSAGE
TE TEM MP PLA LATE TE * N am e
2 -2 1
There is no formal limit to the number of subtypes you can or should use, but more than the 3 levels is for most people difficult to comprehend. The models should help you to understand the business. Note the move of attribute Name during the build of the slide. Introducing subtypes usually means a reshuffle of attributes (and a redirection of relationships). The rule is: model subtypes not because they exist, but because there is a business need to distinguish them.
M ore on S ubtype s
S u b ty p es a lw a ys e xis t...
E M P L O YE E
CURRENT E M P LO Y E E O TH E R E M P LO Y E E
... b u t d o n o t all m a ke s en s e
EM P LO Y E E
E M P LO Y E E W ITH S H O E S IZE > 4 5 O TH E R E M P LO Y E E
2 -2 2
Sum m ary
E n tities
N o u n s in te xts T an g ib le , in ta n g ib le, e ve n ts S in g le -valu ed q ua lifie rs o f en titie s In h erit all attrib u tes a nd relatio n sh ip s o f s u p erty p e M a y h av e th eir o w n a ttrib u tes an d rela tio n sh ips
A ttrib u te s
S u bty p es
2 -2 3
Suggested use of practices

Prac tices
Books M o o n lig h t C o ffe es S h op s S u bty p es S ch e d u le A d d re ss
2 -2 4
Practice Books Moonlight Coffees Shops Subtypes Schedule Address
3day Yes Yes Yes Yes Cha Opt
4day Yes Yes Yes Yes Cha Yes
......................................................................................................................................... 2-33
S ubtyp es
D IS AB LE D P ER S O N
DEAF B LIN D O TH E R D IS A B LE D PERSON
C AR
S TA TIO N W A G O N SEDAN
Practice Youll find that the HOTEL example, in particular, is difficult. The DOG example is more difficult to explain.
B U IL D IN G
HOUSE
H O TE L
R O O M W ITH B A TH O TH E R R O O M
DOG
D O M E S TIC A N IM A L MAMMAL
2 -2 8
van G ogh, M useum plein, A m s terdam S ched ule O c t 12 - O c t 18 S hift A n ne t S A n ne t B D e nn i s J rg e n K i ri Wil 3 4 1 2 2 1 2 M on Tu e W ed 2 prepared by J an e t T hu Fri 2 1 3 5 4 4 S at 2 1 S un 1
Practice When the quicker working students have completed this and while others are still working on it, ask if the model would change when someone could do both shift 2 and 3 on a particular day.
2 -2 9
Practice: A ddre ss ( 1 /2 )
R he in gasse 123 53 111 Bo nn G erm a ny 10 20 M aple D rive K irklan d W A 982 34 USA
3 4 O xfo rd R o ad R e ading B erkshire R G 1 8 JS UK
Practice Every analyst will run into this address problem. It has been solved many times in many different ways (some of which should be on the black list of awful solutions!).
2 -3 0
Practice: A ddre ss ( 2 /2 )
Practice Did the previous solution include PO boxes and other uncommon but not impossible addresses?
P .O . Box 667 08 N airo bi K eny a
c/o M rs S m ith M aude S tree t S an dton Jo hann esbu rg 214 4 S ou th A frica
2 -3 1

Name: Full Email:
Content
Type
Page Number
Note
......................................................................................................................................... 2-35
Suggested Graphics
......................................................................................................................................... 2-37
fold here
3
.................................
Relationships in Detail
Lesson 3: Relationships in Detail .........................................................................................................................................
Introduction
Lesson Aim This lesson discusses in detail how to establish a relationship between two entities. You meet the ten types of relationship and examples of the less frequent types. This lesson looks at nontransferable relationships and discusses the differences and similarities between relationships and attributes. It also provides a solution for the situation where a relationship seems to have an attribute. Schedule See Page 38 About the slide See Page 38
Overview
Relationships Ten different relationship types Nontransferability Relationships that seem to have attributes
3-2
Topic Introduction Establishing a Relationship Relationship Types Relationships and Attributes Attribute Compared to Relationship Relationship Compared to Attribute m:m Relationships May Hide Something Resolving Relationships Summary Practice 31: Read the Relationship Practice 32: Find a Context
See Page 2 4 9 16 18 19 20 25 28 29 30
Introduction .........................................................................................................................................
Topic Practice 33: Name the Intersection Entity Practice 34: Receipt Practice 35: Moonlight P&O Practice 36: Price List Practice 37: E-mail Practice 38: Holiday
See Page 31 32 33 35 36 37
Objectives At the end of this lesson, you should be able to do the following: Create a well-defined relationship between entities Identify which relationship types are common and which are not Give real-life examples of uncommon relationship types Choose between using an attribute or a relationship to model particular information Resolve a m:m relationship into an intersection entity and two relationships Resolve other relationships and know when to do so
......................................................................................................................................... 3-3
Establishing a Relationship
Establishing a Relationship
Determine the existence of a relationship Choose a name for the relationship from both perspectives Determine optionality Determine degree Determine nontransferability
3-3
Determining the Existence of a Relationship Ask, for each of your entities, if it is somehow related to one or more of the entities in your model, and, if so, draw a dotted skeleton relationship line. Usually all entities in a model are related to at least one other entity. Exceptions are rare, but they do exist. Two entities can be related more than once. For example, in the ElectronicMail system there are two relationships between entities MESSAGE and USER, one is about who is sending a MESSAGE and one about who receives a MESSAGE. An entity can be related to itself. This is called a recursive relationship. For example, a MESSAGE can be a reply to another MESSAGE. See the paragraph on recursive relationships for more details on this. About the slide See Page 38
MESSAGE
sending receiving
USER
replying
Establishing a Relationship .........................................................................................................................................
Choosing Name for the Relationship Sometimes the relationship name for the second perspective is simply the passive tense of the other one, such as is owner of and is owned by. Sometimes there are distinct words for both concepts, such as parent of / child of or composed of / part of. Try to use names that end in a preposition. If you cannot find a name, you may find these relationship names useful: Consists of / is part of Is classified as / is classification for Is assigned to / is assignment of Is referred to / referring to Responsible for / the responsibility of Sometimes a very short name is sufficient, for example, with, in, of, for, by, about, at, into. About the slide See Page 39
Relationship Names
MESSAGE sent by
sent to reply of replied to by
sender USER of
receiver of
3-5
Are sent to and receiver of really opposite? If so, the assumption is that if a MESSAGE is sent to a USER, it also arrives. Maybe it is safer to name the relationship received by / receiver of...
......................................................................................................................................... 3-5
Determining Optionality of Both the Relationship Ends Answer the questions: Must every MESSAGE be sent by a USER? Must every USER be sender of an MESSAGE? Must every MESSAGE be sent to a USER? Must every USER be addressed in a MESSAGE? When an answer is Yes the relationship end is mandatory, otherwise it is optional. Be careful at this point. Often a relationship end seems to be mandatory, but actually it is not. In the ElectronicMail example it seems that every MESSAGE must be sent by a USER. But a MESSAGE that was sent by an external user to an internal USER has no relationship to a USER, unless the system were to keep external users as well. Sometimes a relationship is ultimately mandatory, but not initially. Such a relationship should be modeled as optional.
Optionality
MESSAGE written by
received by reply of replied to by
author USER of
receiver of
3-7
Establishing a Relationship .........................................................................................................................................
Determining Degree of Both the Relationship Ends Answer the questions: Can a MESSAGE be written by more than one USER? Can a USER be author of more than one MESSAGE? If the answer is No the degree is called 1. If the answer is Yes the degree is called many or just m. This must be determined for all relationship ends. Note that a mandatory many relationship end from A to B does not mean that it is mandatory for A to be split into more than one B. One B is fine. Read it as: every A must be split into at least one B. About the slide See Page 39
split into part of
An optional many relationship end means zero, one or more. In the e-mail example a USER can be author of 0,1 or more MESSAGES. Sometimes the degree is a fixed value, or there is a maximum number. Assume a MESSAGE may be containing one or more ATTACHMENTS, but for some business reason, the number of ATTACHMENTS per MESSAGE may not exceed 4. The degree then is <5. The diagram, however, shows a crowsfoot. Practice See Page 39 This is a suitable place to do practice 3-1.
author of USER
Degree
MESSAGE
written by received by reply of
receiver of
containing with <5
replied to by
ATTACHMENT
3-10
......................................................................................................................................... 3-7
Determine Nontransferability of Both the Relationship Ends When a MESSAGE is created, the USER who is the author of the MESSAGE is a fact. It would be strange if a mail system allowed you to change the author after the MESSAGE is completed. Often relationships have the following property: you cannot change the connection, once made. That property is called nontransferability. Nontransferability leads to nonupdatable foreign keys. Nontransferability is shown in the diagram with a little diamond shaped symbol through the line of the relationship end. About the slide See Page 40
Nontransferability
FOLDER
containing filed in author USER of
MESSAGE
written by received by reply of
receiver of
replied to by
3-12
Not all relationships are nontransferable. Assume the mail system allows a user to file a MESSAGE in a FOLDER. This is only a valuable functionality if the user is allowed to change the FOLDER in which a MESSAGE is filed.
Relationship Types .........................................................................................................................................
Relationship Types
There are three main groups of relationships, named after their degrees: One to many (1:m) Many to many (m:m) One to one (1:1) This paragraph discusses the various types and gives some examples of their variants. Relationships1:m The various types of 1:m relationships are most common in an ER Model. You have seen several examples already. About the slide See Page 40
Relationship Types 1:m
(a) (b) (c) (d)
3-13
Mandatory at both ends. This type of relationship typically models entities that cannot exist without each other. Often the existence of mandatory details for a master is more wishful thinking than a strict business rule. Often the relationship expresses that an entity is always split into details. Seen from the other perspective, it often expresses an entity that is always classified, assigned.
......................................................................................................................................... 3-9
Circumventing Mandatory 1 to Mandatory m Usually you would try to avoid relationship type (a) in favor of type (b), by taking a different perspective on the subject. For example, suppose an order is defined as something with at least one order item. In other words, an order is regarded as a composed concept. You can avoid modeling order as an entity as you can decide to model a slightly different concept instead, say ORDER HEADER. Next, define an ORDER HEADER to have zero, one or more ORDER ITEMS. An order would then be a thing composed of two entities: any ORDER HEADER with one or more ORDER ITEMS. Empty headers would not be considered to be an order. Why Circumvent? Implementing a 1:m relationship that is mandatory at both ends causes technical problems. In particular it is difficult to make sure details exist for a newly-created record. In most relational database environments it is even impossible.
b
Optional 1: mandatory m. This is a very common type of relationship, together with (d). Normally, at least 90% all relationships are of type (b) and (d). The relationship expresses that the entity at the 1-end can stand alone, whereas the entity at the many end can only exist in the context of the other entity. Mandatory 1: optional m. This is not common. You will see it only when the relationship expresses that an entity instance only exists when it is a non-empty set, and where the elements of the set can exist independently. In the example below a PRODUCT may be part of one BUNDLE. According to the model, a BUNDLE is of no interest if it is empty.
PRODUCT
part of consists of
BUNDLE
Optional at both ends. See remarks for (b).
Relationshipsm:m The various types of m:m relationships are common in a first version of an ER Model. In later stages of the model most m:m relationships, and possibly all, will disappear. About the slide See Page 40
Relationship Types m:m
(e) (f) (g)
3-15
Mandatory at both sides is very uncommon in normal circumstances. This relationship seems to mean that an entity instance can only be created if it is immediately assigned to an instance of the other entity, and vice versa. But how can this occur when we do not have an instance of either entity? Enforcing the mandatory rule from scratch leads to a conflict. The relationship can, however, be part of a model of a theoretical nature, like the mathematical: a LINE always consists of many POINTS and a POINT is always part of many LINES. It can also describe an existing situation: a DEPARTMENT always has EMPLOYEES and an EMPLOYEE is always assigned to a DEPARTMENT. Here the question may arise if it is guaranteed that the situation will always remain this way. A m:m relationship that is mandatory at both sides can occur when the relationship is part of an arc. See the lesson on Constraints for more details.
......................................................................................................................................... 3-11
Mandatory at one end is not uncommon in early versions of a model although they usually disappear at a later stage. About the slide See Page 41
part of consists of
USER LIST
Optional at both ends is common in early versions of a model. These also usually disappear at a later stage.
Relationships1:1 Usually you will find just a few of the various types of 1:1 relationships in every ER Model. About the slide See Page 41
Relationship Types 1:1
(h) ( i) (j)
3-17
A 1:1 relationship, mandatory at both ends, tightly connects two entities: when you create an instance of one entity there must be exactly one dedicated instance for the other simultaneously; for example, entity PERSON and entity BIRTH. This leads to the question why you want to make a distinction between the two entities anyway. The only acceptable answer is: only if there is a functional need. If you have this relationship in your model, it is often, possibly always, part of an arc. Mandatory at one end is often in a model where roles are modeled, for example, in this hospital model.
PERSON * Name
acting as
PATIENT role of * Blood Type EMPLOYEE role of * Job
acting as
Note: These role-based relationships are often named is / is type of or simply is / is.
......................................................................................................................................... 3-13
Both PATIENT and EMPLOYEE are roles played by a PERSON. The attribute BLOOD TYPE is, according to this model, only of interest when this person is a PATIENT. Note that PATIENT and EMPLOYEE cannot be modeled as subtypes of PERSON, as a PERSON may play both roles. You meet the concept of roles again in a later lesson. Optional at both ends is uncommon. However, they can occur, for example, when there is a relationship between two entities that are conceptually the same but exist in different systems. An example of this is entity EMPLOYEE in one system and entity PERSON in a different, possibly a third-party, system. Many 1:1 relationships (of all three variants) do occur when some of the entities represent various stages in a process, such as in the next example. Relationship names in this case can always be leads to / result of or something similar. Practice See Page 42 This is a suitable place to do practice 3-2.
MESSAGE DRAFT
basis for result of
If you consider a person to be a process as well, the earlier example of BIRTH and PERSON fit nicely into this general idea.
Redundancy Like attributes, relationships can be redundant. About the slide See Page 42
Redundant Relationships
COUNTRY
location of of located in
COUNTRY
location of located in of birth of
TOWN
hometown of living in living in
TOWN
hometown of living in born in
PERSON
PERSON
3-20
In the left-hand example the relationship from PERSON to COUNTRY can be derived from the other two relationships and should be removed from the model. This is a semantic issue and cannot be concluded from the structure alone, as the righthand example shows.
......................................................................................................................................... 3-15
Relationships and Attributes

Attributes can hide a relationship. In fact, any attribute can hide a relationship. About the slide See Page 43
Relationships and Attributes
An attribute can hide a relationship Relationship can be downgraded to attribute

ATTACHMENT TYPE * Name
of with
ATTACHMENT * Type * Content ATTACHMENT * Content
3-21
In the example, attribute TYPE of entity ATTACHMENT can be replaced by an entity ATTACHMENT TYPE plus a relationship from ATTACHMENT to ATTACHMENT TYPE. You would have no choice other than to model it this way as soon as you need to keep extra attributes for ATTACHMENT TYPE. But, if there are no important attributes for ATTACHMENT TYPE to keep other than the Name of the type, you could consider removing the entity and take Type as an attribute of ATTACHMENT. You could also consider using the left-hand option when the number of types is a fixed and small amount, such as in the context of a chain of hotels where there are only three types of rooms: single, double, and suite.
Relationships and Attributes .........................................................................................................................................
Attribute Compared to Relationship

Easy model Fewer tables No join
Value control List of values Other relationships

ATTACHMENT TYPE * Name
of with
ATTACHMENT * Type * Content ATTACHMENT * Content
3-22
The table based on entity ATTACHMENT would contain the same columns in both situations, but the Attachment Type Name column would be a foreign key column in the second implementation. This would mean that an Attachment Type Name entered for an ATTACHMENT can only be taken from the types listed in the table based on entity ATTACHMENT TYPE. The list serves as a pick list and spelling check. There are advantages and disadvantages for both models. The one entity model is somewhat easier to read because it is less packed with lines. In the table implementation you would need no joins to get the required information. However, a two-entity model is usually far more flexible. It leaves the option open to create relationships from other entities to the new entity. You would have control over the values entered as they are checked against a given set. Usually, the two-table implementation takes less (sometimes even much less) space in the database. Use your common sense when you select the attributes and entities.
NAME SALARY GENDER TEAM JOB BADGE NATIONALITY ADDRESS
EMPLOYEE * Id
......................................................................................................................................... 3-17

There is no such thing as a foreign key attribute. Usually, the attribute name should not contain an entity name.
FOLDER * Name
containing placed in
MESSAGE * Message Id * Text * Folder Name
3-24
Nonexistence of Foreign Key Attributes Be aware of foreign key attributes such as attribute Folder Name of entity MESSAGE in the example. In ER modeling there is no such thing as a foreign key attribute. The future foreign key is represented by the relationship between MESSAGE and FOLDER. A foreign key column (or columns) will result from the primary unique identifier of the entity FOLDER. See the lesson on CONSTRAINTS for more details on unique identifiers. No Entity Name in Attribute Name When an attribute name contains an entity name, it usually comes from one of the following situations: The attribute hides a relationship to an entity, as in the above example. The second entity was probably added in a later stage. The attribute hides an entity. A typical example is an attribute Employment Date of entity EMPLOYEE. This might hide the entity EMPLOYMENT, as there is probably no rule that an employee may be employed by the same company only once. The entity name in the attribute name is redundant. A typical example is attribute Message Id of entity MESSAGE. The name Id would suffice. The attribute is the result of a one-to-one relationship that is not modeled, for example, attributes Birth Date and Birthplace of entity EMPLOYEE. These are in fact attributes of an entity BIRTH that is not (and probably will never be) modeled.
Relationship Compared to Attribute .........................................................................................................................................
Relationship Compared to Attribute

Relationship Compared to Attribute
MESSAGE
addressed to addressee of
USER
MESSAGE * Addressee
USER
MESSAGE addressed to o Addressee
USER
addressee of
3-25
Sometimes a piece of information looks like a relationship between entities, but actually is not a relationship. In ElectronicMails Compose Message screen there is a field labeled To where the user is supposed to enter the names of the addressees. Initially you may want to model that as a relationship addressed to / addressee of between MESSAGE and USER, but this is a questionable approach. If a message is sent to an external user would it make sense for ElectronicMail to keep track of all external user addresses that were used to send messages to, just for the sake of maintaining the relationship? Would this be possible? In this case it would be a better choice to see the Addressee as an attribute of the MESSAGE. This attribute may contain a value that is also known as a USER. In other words, entity USER contains only suggestions for addressees. Another possibility is to do bothmodel an optional relationship and an optional attribute that cooperatively handle the addressee. An extra constraint (which cannot be shown in the diagram) must then make sure that at least one of the attribute and the relationship is actually given a value for a MESSAGE.
......................................................................................................................................... 3-19
m:m Relationships May Hide Something

During the process of modeling you will find many relationships to be of type m:m. Often this is a temporary thing. After you have been able to add more details to the model, a lot of the m:m relationships will disappear as, after consideration, they simply do not model the business properly. A typical example is about the CUSTOMER/PRODUCT relationship. About the slide See Page 44
m:m Relationships May Hide Something
CUSTOMER * Id * Name
buyer of bought by
PRODUCT * Code * Name
3-26
Suppose you make a model for a retail company that sells PRODUCTS. A CUSTOMER buys PRODUCTS. Suppose future customers are accepted into the system as well. This would mean: A CUSTOMER may buy one or more PRODUCTS A PRODUCT may be bought by one or more CUSTOMERS A typical event for this company would be customer Nick Sanchez buying two shirts. Nick Sanchez is a CUSTOMER Name, shirt is a PRODUCT Name. This leaves the question of where to put the two, the quantity information.
m:m Relationships May Hide Something .........................................................................................................................................
Quantity is Attribute of ...

CUSTOMER * Id * Name Quantity
buyer of bought by
?
buyer of bought by
PRODUCT * Code * Name Quantity
3-27
It is clear that Quantity is neither a property of CUSTOMER nor of PRODUCT. Quantity seems to be an attribute of the relationship between CUSTOMER and PRODUCT.
buyer of bought by
Quantity
Relationships do not and cannot have attributes. Apparently an entity of which quantity is a property is missing. For that reason we need to change the model. Entity ORDER (or SALE or PURCHASE) enters the scene.
......................................................................................................................................... 3-21
New Entity ORDER

CUSTOMER * Id * Name PRODUCT * Code * Name
with of with for
ORDER *Quantity Sold
CUSTOMERS PRODUCTS Id Name 1 Sanchez 2 Lowitch 3 Yomita 4

3-29
ORDERS Ctr_id Pdt_code Quantity_sold 1 1 2 3 2 3 2 2 2 1
Code Name 1 Jeans 2 Shirt 3 Tie 4
The table design here is the default design for implementing the model. Note the two foreign key columns in the ORDERS table, Ctr_id (foreign key to CUSTOMERS) and Pdt_code (to PRODUCTS). Now suppose Pepe Yomita enters the store and buys one pair of jeans, two shirts, and one silk tie. Given the current model this would mean that Pepe places three orders: one for the jeans, one for the shirts and one for the tie. Three orders, all at the same time, from one and the same customer. No problem so far, the model allows for this. Now suppose the store wants to automate the billing of the orders. (This is probably one of the reasons for making the model anyway.) Using the above model, this would mean three orders and, as a consequence, three bills as the system has no way to know these three orders somehow belong to each other. It is better to change the model in such a way that one order can be for more than one product. That means we should have a m:m relationship between ORDER and PRODUCT, which we should investigate next.
m:m Relationships May Hide Something .........................................................................................................................................
Multiple PRODUCTS for an ORDER
with of with for
ORDER * Id * Date
Qu ant ity
3-30
Then there is the question again: where do you put quantity? Quantity can now no longer be an attribute of an order because the attribute must be single-valued and cannot contain three values 1, 2 and 1 at the same time. Quantity has become a property of the m:m relationship between PRODUCT and ORDER.
......................................................................................................................................... 3-23
This leads to: About the slide See Page 45
Another New Entity: ORDER ITEM

with for for
with of
ORDER HEADER * Id * Date

with
ORDER ITEM *Quantity Sold
3-31
Note the name change from ORDER to ORDER_HEADER, to avoid the 1: m relationship that is mandatory at both ends. The set of tables for this model could be: About the slide See Page 45
Tables
CUSTOMERS Id Name ORDER_HEADERS Id Ctr_id 1 2 3 4 1 2 1 Date_ordered 25-MAY-1999 25-MAY-1999 25-MAY-1999 1 Sanchez 2 Lowitch 3 Yomita 4
ORDER_ITEMS Ohd_id Pdt_code Quantity_sold 1 2 3 4

3-32
PRODUCTS Code Name 1 Jeans 2 Shirt 3 Tie 4 2 2 1
2 2 1
Resolving Relationships .........................................................................................................................................
Resolving Relationships
Relationships and Intersection Entities In the previous pages you have seen a typical example where relationships seem to have attributes. The relationships in the example were many to many relationships. This situation was handled by creating a new entity, an intersection entity, that replaces the relationship and can hold attributes. This leads to the following questions: What are the steps in resolving a relationship in general? Should every m:m relationship be resolved? Can other relationships than m:m be resolved? Resolving a Relationship Suppose we want to resolve the m:m relationship between entities A and B. About the slide See Page 45 Practice See Page 46 This is a suitable place to do practice 3-3.
Resolving m:m Relationship

A A
in of xxx yyy
A/B COMBINATION
B
in
of

3-33
Create new intersection entity Create two m:1 relationships, derive optionality Remove m:m relationship
1 First create a new intersection entity. You will experience that sometimes there is
no good word available for the concept you are modeling. The new entity can always be named with the neologism A/B COMBINATION, or a name that is somehow derived from the name of the original m:m relationship. Do not let the unavailability of a proper name for the entity stop you from modeling it. 2 Next create two new m:1 relationships from entity A/B COMBINATION, one to A and one to B. Initially, draw these as mandatory at A/B COMBINATION, as you will probably only be interested in complete pairs of A and B. If the original m:m
......................................................................................................................................... 3-25
relationship was optional (or mandatory) at As side, then the new relationship from A to A/B COMBINATION is also optional (or mandatory). 3 Name the relationships. You can often name both relationships in / of. 4 The next step is to remove the m:m relationship you started with. 5 Finally, reconsider the newly-drawn relationships. Given a second thought they may be optional at the A/B COMBINATION side. Also, they may turn out to be of type m:m and need to be resolved, as you have seen in the example on customers buying products. Should Every m:m Relationship be Resolved? The answer depends on a number of factors. Given the usual scenario, when you start creating an ER model you will discover that many of the relationships you draw are of type m:m. Most of these will appear to hide entities that you need in a later stage as you need to have a place to put specific attributes. Finally, you will have only a few genuine m:m relationships left. No Purely from a conceptual data modeling point of view, there is no need to resolve these genuine m:m relationships. The model is rich enough to be the basis for table design. A m:m relationship will transform into a binary table; this is a table that consists of the columns of two foreign keys only. This is exactly the same table as the one that would result from the intersection entity when you resolved the m:m relationship. A m:m relationship in a conceptual data diagram needs less space than a separate entity plus two relationships. For this reason a diagram with unresolved m:m relationships is more transparent and easier to read. Yes From a function modeling point of view the answer is different. If your model contains a true m:m relationship there is apparently a business need to keep information on the combinations of, say, entity A and B. In other words, the system would contain at least one business function that creates the relationship. This create relationship cannot be expressed as a usage of entities of attributes, although this is usually what design tools require of the functional model. Oracle Designer is no exception. This means that when you create an ER model in Oracle Designer you would always resolve the m:m relationships in order to create a fully-defined functional model with all data usages included. Resolving Other Relationships Can relationships other than m:m be resolved? Yes. Every relationship, even a 1:1, can be resolved into an intersection entity and two relationships, just like a m:m relationship. When would you want to do this? It is quite rare to find a situation where you have to. A typical situation where you may like to resolve a non m:m relationship is when one entity represents something that is outside your system, for example, when the entity is part of a third-party package.
Resolving Relationships .........................................................................................................................................
Suppose you need your system to create a m:1 relationship from external entity PERSON to CUSTOMER TYPE, one of your internal entities:
Resolving m:1 Relationship
external
PERSON
classified as classification of TYPE
CUSTOMER
internal
3-35
This would result later on in a change of the table structure of the third-party PERSONS table. This is undesirable (third parties often ask you to you sign a contract that simply forbids you to do that) and sometimes even impossible if you have no authority over that table. About the slide See Page 46
CUSTOMER TYPE
with for in with
external
PERSON
CLASSIFICATION
internal
The above model leaves the external entity PERSON as is and does the referencing from inside. The m:1 relationship is replaced by an entity CLASSIFICATION and two relationships.
......................................................................................................................................... 3-27
Summary
Relationships connect entities and express how they are connected. There are ten types of relationships, 4 of type1:m, 3 of type m:m and 3 of type 1:1. The m:1 relationship that is optional at the 1 side is by far the most common type in finished ER models. This one is very easy to implement in a relational database. At the beginning of the process of creating an ER model, there are often many m:m relationships. Many of these disappear after closer investigation. Relationships cannot have attributes. If this seems to be the case, you need to resolve the relationship into an intersection entity plus two relationships. The other types are less commonsome express more a desired situation rather than reality, such as the m:1 relationship that is mandatory at both ends.
Summary
Relationships express how entities are connected. Initially relationships often seem to be of type m:m. Finally relationships are most often of type m:1. Relationships can be resolved into:
Two new relationships. One intersection entity.
3-37
Practice 31: Read the Relationship .........................................................................................................................................
Practice 31: Read the Relationship

Goal (See Page 39) The goal of this practice is to learn to read relationships from an ER diagram. Your Assignment Read the diagrams aloud, from both perspectives. Make sentences that can be understood and verified by people who know the business area, but do not know how to read ER models.
Practice: Read the Relationship

ALU
of with
BRY
PUR
bazooned in bazooned by
YOK
KLO
bilought in glazoed with
HAR
3-39
......................................................................................................................................... 3-29
Practice 32: Find a Context

Goal (See Page 42) The purpose of this practice is to use your modeling skills. Your Assignment Given the following ER diagrams, find a context that fits the model.
1
Practice 33: Name the Intersection Entity .........................................................................................................................................
Practice 33: Name the Intersection Entity

Goal (See Page 46) The goal of this practice is to find a proper name for the intersection entity after resolving the m:m relationship. Your Assignment 1 Resolve the following m:m relationships. Find an acceptable name for the intersection entity.
Practice: Name the Intersection Entity
PRODUCT
sold by selling
DEPARTMENT STORE
PERSON
crewing crewed by
SAILBOAT
INTERPRETER fluent in
spoken by
LANGUAGE
3-44
2 Invent at least one attribute per intersection entity that could make sense in some
serious business context. Give it a clear name.
......................................................................................................................................... 3-31
Practice 34: Receipt

Moonlight Coffees
Goal (See Page 47) The purpose of this practice is to use a simple source of real life data as a basis for a conceptual data model.
Scenario You work as a contractor for Moonlight Coffees. Your task is to create a conceptual data model for their business. You have collected all kinds of documents about Moonlight. Below you see an example of a receipt given at one of the shops. Your Assignment Use the information from the receipt and make a list of entities and attributes.
Served by: Dennis Till: 3 Dec 8, 4:35 pm ----------------------CAPPUCC M 3.60 * 2 7.20 CREAM .75 * 2 1.50 APPLE PIE 3.50 BLACKB MUF 4.50 <SUB> 16.70 tax 12% 2.00 <TOTAL> 18.70 ======= CASH 20.00 RETURN 1.30 ----------------------Hope to serve you again @MOONLIGHT COFFEES 25 Phillis Rd, Atlanta
3-45
Practice 35: Moonlight P&O .........................................................................................................................................
Practice 35: Moonlight P&O

Moonlight Coffees
Goal (See Page 47) The purpose of this practice is to create a ER model iteratively, based on new pieces of information and new requirements.
Scenario You are still working as a contractor for Moonlight Coffeesapparently you are doing very well! Your Assignment 1 Create a entity relationship model based on the following personnel and organization information:
All Moonlight Coffee employees work for a department such as Global Pricing or HQ, or for a shop. All employees are at the payroll of one of our country organizations. Jill, for example, works as a shop manager in London; Werner is a financial administrator working for Accounting and is located in Germany.
2 Extend or modify the diagram based on this information:
All shops belong to one country organization (the countries). There is only one country organization per country. All countries and departments report to HQ, except HQ itself.
3 And again:
Employees can work part time. Lynn has had an 80% assignment for Product Development since the 1st September. Before that she had a full-time position.
......................................................................................................................................... 3-33
4 Change the modelif necessary and if possibleto allow for the following new
information. a Jan takes shifts in two different shops in Prague. b Last year Tess resigned in Brazil as a shop manager and moved to Toronto. Recently she joined the shop at Toronto Airport. c To reduce the number of direct reports, departments and country organizations may also report to another department instead of Headquarters. d The shops in Luxembourg report to Belgium. e To prevent conflicting responsibilities, employees are not allowed to work for a department and for a shop at the same time. 5 Would your model be able to answer the next questions? a Who is currently working for Operations? b Who is currently working for Moonlight La Lune at the Mont Martre, France? c Are there currently any employees working for Marketing in France? d What is the largest country in terms of number of employees? In terms of managers? In terms of part-timers? e When can we celebrate Lynns fifth year with the company? When can we do the same with Tess fifth year with Moonlight? f What country has the lowest number of resignations?
Practice 36: Price List .........................................................................................................................................
Practice 36: Price List

Moonlight Coffees
Goal (See Page 47) The purpose of this practice is to use a simple source of real life data as a basis for a conceptual data model.
Scenario You work as a contractor for Moonlight Coffees. Your Assignment Make a ER model based on the pricelist from one of the Moonlight Coffee Stores.
Practice: Practice: Price List List Price
SULFH OLVW
small medium
regular coffee 2.25 2.90 cappuccino 2.90 3.60 caf latte 2.60 3.20 special coffee 3.10 3.70 espresso 2.25 2.90 coffee of the day 2.00 2.50 decaffeinated .25 .50 black tea 2.25 2.90 infusions 2.60 3.20 herbal teas 2.90 3.60 tea of the day 2.00 2.50 decaffeinated .25 .50 milk 1.25 1.90 soft drinks 2.25 2.90 soda water 2.25 2.90 mineral water 2.90 3.60 apple pie strawberry cheesecake whole wheat oats muffin with almonds blackberry muffin fruitcake cake of the day additional whipped cream
!$QuvyyvShq6yhh vvhZZZPRRQOLJKWFRP
large
3.50 4.20 3.90 4.40 3.50 3.00 .75 3.50 3.90 4.20 3.00 .75 2.50 3.50 3.50 4.20
extra
extra
q r q y p v h U r y h T
% r i r r T
3.50 3.50 3.90 4.50 4.50 4.00 .75
3-47
......................................................................................................................................... 3-35
Practice 37: E-mail

Goal (See Page 48) The goal of this practice is to extend an existing conceptual data model. Scenario.
FOLDER
COMPOSITION written by
MESSAGE
received by
author of
USER
part of
LIST
OTHER COMPOSITION
containing with <5 replied to by reply of
receiver of
consists of
ATTACHMENT
ATT. TYPE
3-48
Your Assignment Take the given model as starting point. Add, delete, or change any entities, attributes, and relationships so that you can facilitate the following functionality: 1 A user must be able to create nick names (aliases) for other users. 2 A folder may contain other folders. 3 A user must be able to forward a composition. A forward is a new message that is automatically sent together with the forwarded message. 4 All folders and lists are owned by a user. Challenge: 5 A mail list may contain both users and other lists. 6 A mail list may contain external addresses, like giovanni_papini@yahoo.com. 7 A nickname may be an alias for an external address.
Practice 38: Holiday .........................................................................................................................................
Practice 38: Holiday

Goal (See Page 48) The purpose of this practice is to do a quality check on a conceptual data model. Scenario Paul and I hiked in the USA. Eric and I hiked in France and we rented a car in the USA last year. Your Assignment Comment on the model given below that was based on the scenario text.
COUNTRY France USA USA
TRANSPORT Boots Boots Car

TR Bo AN C o ts S P O Bo ar RT ot s
3-49
......................................................................................................................................... 3-37
C Er OM E ic PA NI Pa ric ON ul
C TRANSPORT COUNTRY F r OU a US n NT US A ce RY A C Er OM COMPANION E ic PA NI Pa ric O ul N
Instructor Notes
Instructor Note Topic Timings Lecture 45- 60 minutes Practice 165- 240 minutes Total 210- 300 minutes
3 3
R elationsh ip s in D e ta il
O verview
R e la tio n s h ip s T e n d iffe re n t relatio n sh ip typ e s N o n tran s fera b ility R e la tio n s h ip s th a t se em to h av e a ttrib u tes
3 -2
This chapter goes into the details of Relationships, covering naming issues, optionality and degree, nontransferability. It discusses the 10 types of relationships with examples. Attributes compared to Relationships. Resolving m:m relationships. Resolving 1:m relationships. Again, lots of practices. This slide and the following are a recap of what was earlier discussed in lesson 1, but now in more detail.
Es tablish in g a R elatio nship
D e te rm in e th e ex iste n ce o f a relatio n sh ip C h o o s e a n am e fo r th e re latio n s h ip fro m bo th p e rs pe ctives D e te rm in e o p tio n ality D e te rm in e d e g ree D e te rm in e n o n tran s fera b ility
3 -3
Es tab lishing the R elations hip
In step one the existence of the relationships is identified. New is the recursive relationship.
M E S SA G E
sending receiving
U S ER
replyin g
3 -4
N am ing the R ela tion ship
receiving
M E S SA G E
received by receiver of
USER
Note that the next few illustrations in the book are different from the ones in the presentation. This is because of the builds in the presentation. The slide titles correspond.
A M E S S A G E is rec eive d b y a U S E R A U S E R is re c eiv e r o f a M E S S A G E
3 -6
O ptio nality
N o:
M E S SA G E
Y es:
USER
M u s t ev ery M E S S A G E b e re ceive d b y a U S E R ? Y es M u s t ev ery U S E R b e rec eive r o f a M E S S A G E ?
No
3 -8
M andatory 1: M an datory m
split into part of
E ve ry A m u st be s p lit in to a t lea st on e B E ve ry B m u st be p a rt o f ex ac tly o n e A
ER diagrams can only represent 0, 1 or more as the values of the degree of a relationship. If a value is known, like <5, you should add that to the description of the entity. Oracle Designer allows you to enter any value: you can set the cardinality to 4.
3 -9
D eg re e
O n e: O n e or m ore:
M E S SA G E
USER
C an a M E S S A G E b e rec eive d b y m o re Y es tha n o n e U S E R? C a n a US E R b e th e rec eive r o f m o re th an o n e Y es M ESSAG E ?
3 -1 1
Practice: R ead the R ela tions hip

AL U
of w ith
BRY
Practice Read the diagrams without a possible interpretation.
PU R
bazoone d in bazo oned by
YOK
KL O
bilought in glaz oed w ith
HAR
3 -3 9
......................................................................................................................................... 3-39
N ontran sferability
F O LD E R
c ontaining filed in author U S ER of
M E S SA G E
w ritten by receiv ed by reply of
receiver of
replie d to by
3 -1 2
Another example of nontransferability: TICKET - PASSENGER. Once a ticket is assigned, the name of the passenger is printed on the ticket and can not be transferred to another passenger. The ticket must be destroyed and a new ticket must be created in order to make the change. In theory nontransferability can occur at both sides of a relationship. In practice they can only be implemented at the side where the future foreign key will come. As a 1-end of a relationship can also be implemented as a foreign key, you cannot say in general that the diamond can only occur on the m-ends of a relationship. Usually the concept of a 1:m relationship that is mandatory at the 1-end leads to a lot of discussion. Such a relationship is perfectly all right in business situations, but is difficult (and used to be impossible) to implement and used to be avoided for that reason. More on this in the Mapping chapter.
R elatio nship Typ es 1:m
(a) (b) (c) (d)
3 -1 3
R elatio nship Typ es m :1
PRODUCT
part of consists of
B UN DL E
3 -1 4
R elatio nship Typ es m :m
(e) (f) (g)
3 -1 5
A relationship type that leads to much discussion is the m:m that is mandatory at both ends. The discussion is usually about implementation issues. In business contexts this relationship is uncommon, but not impossible. Another discussion is about the question whether every m:m relationship should be resolved. See slide 3-33
R elatio nship Typ es m :m
Some mail systems do not allow empty mail lists.
U SE R
pa rt of consists of
LIS T
3 -1 6
R elatio nship Typ es 1:1
(h) ( i) (j)
3 -1 7
Entities that have a 1:1 relationship always lead to the question: why make the distinction anyway? Entities that have a 1:1 relationship can always be merged into one new entity, maybe with loss of knowledge such as the attributes that now become optional. Often the distinction has to do with functionality of the system or with completely different responsibilities. This cannot be modeled with both PATIENT and EMPLOYEE as subtypes of PERSON as there is potentially overlap between these two sets.
1 :1 R elations hip s R oles
PERSON * Name
acting as
P A TIE N T
role of * B lood Typ e
acting as role of
EM PL O Y E E * Job
3 -1 8
1 :1 R elations hip s P rocess
M E SS A G E D RA F T
basis for result of
3 -1 9
......................................................................................................................................... 3-41
Find a C on te xt (1)
Practice These practices seem to be easy, but they are not. You will often discover students misconceptions here.
3 -4 0
Practice
3 -4 1
Practice
3 -4 2
Practice The first reaction of some will be: this is impossible. When delegates assume a 1:m relationship to stand for something like is divided into they think the entity at the many end represents something smaller than the other entity. To check for redundancies, you must read and understand the model, use good common sense and have a good long term memory.
of birth of
3 -4 3
R edu ndan t R ela tion ship s
C O U N TR Y
location of of located in
C O U N TR Y
location of located in
TOW N
ho m etow n of liv ing in living in
TO W N
hom e tow n of living in born in
PE R S O N
P ER S O N
3 -2 0
R elatio nsh ips a nd A ttribu te s
A n a ttrib u te ca n h id e a re latio n s h ip R e la tio n s h ip c an b e d o w n g rad ed to attrib u te

A T TA C H M E N T TY P E * N am e
of w ith
A TT AC H M EN T * T ype * C onte nt A TTA C H M E N T * C onte nt
3 -2 1
A useful guideline is to upgrade every attribute with a limited set of allowable values as a relationship to an entity and decide its implementation at design time. Using Oracle Designer, you have the option to create a domain and connect the attribute to the domain. Such a domain, however, is not a concept in Relational Theory.
A ttribu te C om pared to R e lations hip

E as y m o d el F e w e r tab le s N o jo in
V alu e c o n tro l L ist o f v alu e s O the r rela tio n sh ip s

A T TA C H M E N T TY P E * N am e
of w ith
A TT AC H M EN T * T ype * C onte nt A TTA C H M E N T * C onte nt
3 -2 2
A ttrib ute or E ntity
NAME S A LA R Y GENDER T EA M
E M P LO YE E * Id
JO B BADGE N A TIO N AL ITY A D D R E SS
3 -2 3
Not all make sense here (although this is hard to judge in the absence of a business context). Let the students judge. NAME, SALARY and ADDRESS do not (seem to) make much sense. JOB, BADGE and TEAM may have attributes of their own and seem to be solid entities. GENDER and NATIONALITY seem to be potential domains. This may lead to a discussion on naming, in particular the suggestion that attribute Message Id should be replaced by Id. Other entity names in attribute names very often hide an entity or relationship.
A ttribu te C om pared to R e lations hip

T h e re is n o su c h th in g a s a fo reig n ke y attrib u te. U s ua lly, th e a ttrib u te n am e s h o u ld n o t co n ta in an e n tity n a m e.
F O LD E R * N am e
M E S SA G E * M essa ge Id * T ext * F old er N a m e
3 -2 4
......................................................................................................................................... 3-43
R elationsh ip C om pared to A ttrib ute
M E SS A G E
addressed to a ddressee of
U SE R
M E S SA G E * A dd resse e
U SE R
M E S SA G E o A dd resse e
addressed to addressee of
U SE R
3 -2 5
Using a single attribute Addressee where a string like alison, fred, giovanni_papini@yahoo.com can be entered seems relationally incorrect. That string clearly contains multiple addresses. At the other hand, the message only has one addressee string, which, after parsing, can contain only unknown users. The middle model is most likely to be used for Addressee. For MESSAGES that are received by USERS, the story is different. Then a m:m relationship is the best model. The next slides show an example where close investigation of a m:m relationship leads to the conclusion that there in something missing in the model. Here the model misses a place to put Quantity. This is not the same as resolving a m:m relationship.
m :m R e lationsh ip s M ay H id e Som ething
C U S TO M E R * Id * N am e
buyer of bought by
PRODUCT * C o de * Name
3 -2 6
Q ua ntity is A ttrib ute of ...

C U S TO M E R * Id * N am e Q u antity
buyer of bought by
PRODUCT * C o de * Name
C U ST O M E R * Id * Name
?
buyer of bou ght by
P RO D U C T * C ode * N am e Q uan tity
3 -2 7
A ttrib ute of R ela tion ship?
C U S TO M E R * Id * N am e
buyer of bought by
PRODUCT * C od e * N am e
Q ua ntity
3 -2 8
N ew E ntity O R D E R
C U S TO M ER * Id * N am e PRODUCT * C ode * N am e
w ith of w ith for
O R D ER *Q ua ntity S old
C U S TO M E R S P R O D U C TS Id N am e 1 S anchez 2 Low itch 3 Y om ita 4

3 -2 9
ORDERS C tr_id P dt_code Q uantity_s old 1 1 2 3 2 3 2 2 2 1
C ode N am e 1 Jeans 2 S hirt 3 Tie 4
Although you are probably used to a model with ORDER ITEM this model is fine. Everything that is ordered can be recorded. An additional business need, as in this example, to create one bill for several products bought, leads to the ITEM entity
M ultip le P R O D U C T S fo r an O R D ER
C US T O M E R * Id * N am e P RO D U C T * C o de * N am e
w ith of w ith for
ORDER * Id * D ate
Qu
a n ti
ty ?
3 -3 0
A noth er N ew E ntity: O R D E R IT EM
C U S TO M ER * Id * N am e PRODUCT * C ode * N am e
w ith for for
w ith of
O R D ER H E A D ER * Id * D ate
w ith
O R D ER ITE M *Q u antity So ld
ORDER ITEM is introduced. ORDER disappeared and becomes ORDER HEADER. Of course, a model with entity ORDER and ORDER ITEM connected with a m:m relationship that is mandatory at both ends is correct as well. Do not touch the naming of tables and columns now. This is discussed in the chapter on Mapping.
3 -3 1
Tab les
C U S TO M E R S Id 1 2 3 4 N am e S anche z Low itch Y om ita O R D E R _H E A D E R S Id 1 2 3 4 C tr_id 1 2 1 D ate_o rdered 25-M A Y -1999 25-M A Y -1999 25-M A Y -1999
O R D E R _ITE M S O hd_id 1 2 3 4
3 -3 2
P R O D U C TS C ode N am e 1 Jeans 2 S hirt 3 Tie 4 2 2 1
P dt_code Q uantity_s old 2 2 1
R eso lv ing m :m R elatio nship

A A
in of x xx yyy
A /B C O M B IN A TIO N
B
in
of
The animation shows the steps in resolving a m:m relationship. Underline the need to check the new relationships. These may be of type m:m after closer inspection.

3 -3 3
C re ate n ew in ters ec tio n e n tity C re ate tw o m :1 relatio n s h ip s, d erive o p tio n ality R e m o ve m :m rela tio n sh ip
......................................................................................................................................... 3-45
P ractice : N a m e the Intersec tion En tity
PRODUCT
sold b y selling
D E P AR T M E N T S TO RE
P E R SO N
crew ing crew ed by
SA IL BO AT
IN TE R P RE T ER
fluent in spoken by
LA N G U A G E
Practice Some intersection entities are easy to find as there is a good name available. Others are more difficult as there is no appropriate word around. Then you have to make up a name for the concept.
3 -4 4
R es olvin g m :1 R e lationsh ip
extern al
P E R SO N
c lassified as clas sification of T YP E
C U S TO M ER
in ternal
3 -3 5
R es olvin g m :1 R e lationsh ip
extern al
P E R SO N C U S TO M ER TY P E
w ith for in w ith
C LA SS IF IC A TIO N
Delegates may want to see the consequences of this solution in terms of tables. The table based on CLASSIFICATION would be a binary table where the foreign key column(s) to the table based on PERSON are primary key columns as well.
in ternal
3 -3 6
Sum m ary
R elatio n sh ips e xp re ss h o w e ntitie s are co n n e cted . In itia lly re latio n s hip s often s ee m to b e of typ e m :m . F in a lly relatio n sh ip s a re m o st o fte n o f ty p e m :1 . R elatio n sh ips c an b e re so lv ed in to :
T w o n e w re la tion s h ip s. O n e in tersec tio n en tity.
3 -3 7

Prac tices
R e ad th e R ela tio n sh ip F in d a C o n tex t N a m e th e In terse ctio n E n tity R e ce ip t M o o n lig h t P &O P ric e L ist E M a il H o lid ay
3 -3 8
Practice Read the Relationship Find a Context Name the Intersection Receipt Moonlight P&O Price List E-mail Holiday
3day Yes Cha Yes Yes Opt Yes Opt Opt
4day Yes Cha Yes Yes Cha Yes Cha Cha
S e rv e d b y: De n ni s T il l : 3 D e c 8 , 4 :3 5 p m - - -- - -- - -- - -- - -- - -- -- - C AP P UC C M 3 . 60 * 2 7. 2 0 C RE A M . 75 * 2 1. 5 0 A PP L E P IE 3. 5 0 B LA C KB MU F 4. 5 0 < S UB > 1 6. 7 0 t a x 1 2% 2. 0 0 < T OT A L> 1 8. 7 0 = == == = = C A SH 2 0. 0 0 R E TU R N 1. 3 0 - - -- - -- - -- - -- - -- - -- -- - H o pe to se r ve yo u a ga i n @M O ON L IG H T C OF F EE S 2 5 P hi l li s R d , A tl an t a

3 -4 5
Practice If delegates want to know what BLACKB MUF etc. stand for, you can tell them to take a look at the price list that is printed in one of the next practices. A hidden attribute is the name of the a product; clearly the short name is used here. Practice This practice can very easily be replaced by an interview session. See the remarks about interview sessions. A complexity here is the idea of a department that is not located anywhere. Departments are virtual and should probably be defined as a set of tasks instead of a set of people. The departments are a functional split up of the company, the country organizations a geographical split up of the company (forced by the tax laws in most or all countries). Practice An important question here is: do you want to see regular coffee or regular coffee small as a product? And how about decaffeinated? Or is regular coffee small decaffeinated a product?
A ll M oo nlight C o ffee em ployee s w ork for a dep artm en t such as G lob al P ricing or H Q , or for a sh op. A ll e m ploye es a re a t the payroll of one of ou r co untry organiz ations . Jill, for exam ple, w orks a s a s hop m an age r in L ondo n; W erne r is a finan cia l adm inistra tor w orkin g for A ccoun ting a nd is lo cate d in G erm any. A ll sh ops belon g to one coun try o rga nizatio n (the coun tries). Th ere is only o ne c ountry organ ization per coun try. A ll co untries and dep artm ents re port to H Q , excep t H Q itse lf. E m ploy ees ca n w ork pa rt tim e . Lyn n ha s ha d an 80% assign m en t for P rod uct D eve lopm ent sin ce th e 1 st Se pte m be r. B efore tha t she ha d a fu ll-tim e position.
3 -4 6
Practice: Practice: Price List List Price
vp ryv
!$ Qu vyyvS hq6yh h vvh Z Z Z P RRQOLJKWFRP
sm all
m edium
large
3.5 0 4.2 0 3.9 0 4.4 0 3.5 0 3.0 0 .7 5 3.5 0 3.9 0 4.2 0 3.0 0 .7 5 2.5 0 3.5 0 3.5 0 4.2 0
q r q y p v h U r y h T
% r
i r r T
reg ular coffee 2 .2 5 2 .90 ca p pu ccin o 2 .9 0 3 .60 ca f la tte 2 .6 0 3 .20 sp e cial coffee 3 .1 0 3 .70 e sp ress o 2 .2 5 2 .90 co ffee o f the da y 2 .0 0 2 .50 d e caffeina ted .2 5 .50 b la ck te a 2 .2 5 2 .90 infu sion s 2 .6 0 3 .20 h e rba l te as 2 .9 0 3 .60 te a o f th e d ay 2 .0 0 2 .50 d e caffeina ted .2 5 .50 m ilk 1 .2 5 1 .90 so ft d rin ks 2 .2 5 2 .90 so d a w a ter 2 .2 5 2 .90 m ine ra l w a ter 2 .9 0 3 .60 a p ple pie stra w b e rry ch ee se cake w ho le w he a t o ats m u ffin w ith alm o nd s b la ckbe rry m uffin fru itca ke ca ke o f th e d a y a d ditio n al w hip p ed cre am
e xtra
e xtra
3 .5 0 3 .5 0 3 .9 0 4 .5 0 4 .5 0 4 .0 0 .7 5
3 -4 7
......................................................................................................................................... 3-47
F O LD E R
co n taining p laced in
C O M P O S ITIO N w ritten by
M ESSAGE
received b y
autho r of
U SE R
part of
Practice Typical situation: new functional wishes may or may not affect a model.
LIS T
co n sists of
O TH E R C O M P O S ITIO N
co ntainin g w ith <5 replied to by rep ly of
receiver of
A T TA C H M E N T
A TT . T YP E
3 -4 8
C O U N TR Y France USA USA

C F OU U ran N T S c R Y SA A e
TR A N S P O R T B oots B oots C ar TRANSPORT

TR Bo A N C o ts S P a O Bo r RT ot s
C O U N TR Y
3 -4 9
CO Er M PA E r ic N IO P a ic N ul
E OM E ri c P A P r ic N au IO l N
C O M P A N IO N
Practice This type of situation is called a fan trap. The tables presented produce more combinations than the given scenario contains. The solution can be described as resolving the relationship between 3 entities. This is an example of an even more general n-entities situation.

Name: Full Email:
Content
Type
Page Number
Note
......................................................................................................................................... 3-49
Suggested Graphics
......................................................................................................................................... 3-51
fold here
4
.................................
Constraints
Lesson 4: Constraints .........................................................................................................................................
Introduction
This lesson is about constraints that apply to a business. Constraints are also known as business rules. Some of these constraints can be easily modeled. Some can be diagrammed but the resulting decreased clarity may not be acceptable. Some constraints cannot be modeled at all. These should be listed in a separate document. Schedule See Page 31 About the slide See Page 31
Overview
Unique Identifiers Arcs Domains Various other constraints
4-2
Topic Introduction Identification Unique Identifier Arcs Arc or Subtypes More About Arcs and Subtypes Hidden Relationships Domains Some Special Constraints Summary Practice 41: Identification Please Practice 42: Identification Practice 43: Moonlight UID
See Page 2 4 6 12 16 17 18 19 20 24 25 26 28
Introduction .........................................................................................................................................
Topic Practice 44: Tables Practice 45: Modeling Constraints
See Page 29 30
Objectives At the end of this lesson, you should be able to do the following: Describe the problem of identification in the real world Add unique identifiers to your model and know how they are represented Recognize correct and incorrect unique identifiers Decide when an arc is needed in your model Describe the similarities between arcs and subtypes Describe various types of business constraints that cannot be represented in an ER diagram
......................................................................................................................................... 4-3
Identification
What Are We Talking About? It is not unreasonable to assume everybody knows Rembrandt was born in the Netherlands. What most people probably do not know is that Rembrandt was born on a farm as the son of Pajamas and an unknown father. Rembrandt had a twin sister. Although Rembrandt never married, he was the father of numerous children. You can easily recognize Rembrandt and his offspring as they all have four white stripes at the end of their tails.
Identification is about knowing what or who you are talking about. Obviously, the name Rembrandt is not unique to the famous painter; other human beings and even cats have the same name. In day-to-day conversations, you can usually assume that you and the people you talk to share enough of the same context and know enough about each others jobs and interests, to understand what you are both talking about. Language is always a rather nonspecific way to communicate, with lots of ambiguities, but people are very capable of interpretation. Computers must communicate in a more specific way that is not open to much interpretation. It would help a system to be told Rembrandt the painter or Rembrandt van Rijn, born in 1606 or maybe even the combination of all: Rembrandt van Rijn, the painter, born in 1606, to distinguish this Rembrandt from the other famous creatures with the same name. The Problem of Identification There are three sides to the problem of identification. One is identification in the real worldhow do we distinguish two real world things that have very similar properties? This is the most difficult side. The second is identification within a database system how do we distinguish rows in tables? This one is far less complex. A third issue deals with representation: how do we know what real world thing a row in a table represents?
Identification .........................................................................................................................................
Identification in the Real World Many things in the real world are difficult, if not impossible, to identifydistinguishing between two cabs, two customers, two versions of a contract, or two performances of the fourth string quartet by Shostakovich. As a general rule, real world things cannot be identified with certainty. You have to live with a substantial level of ambiguity. For example, how can I be sure that the car at the other side of the street with license plate MN4606 is the same car as the one I saw last week with that number? I cannot even be sure it is the same license plate. In normal circumstances there in no reason for doubt, but that is not the same as certainty. Sometimes people have their reasons for creating confusion. Fortunately, some things in the real world are easier as they are within your reach. There you can define the rules. When a company sends out, for example, invoices, it can give every single invoice a unique number. When a business lets people create ElectronicMail usernames (identities), they can force these names to be unique. Identification Within a Database Usually, database systems can make sure that a row is not stored twice, or, to be more exact, that a particular combination of values is not stored twice, within the same table. The technical problem is solved for you by the standard software you use. Representation The remaining problem is to make sure that you can always know what real world thing is represented by a particular row in a table. The solution to this problem depends highly on the context. How likely do you consider it to be that two different employees for the same company have the same family name, or the same family name plus initials, or the same family name plus initials plus birthdate? About the slide See Page 31
G. Papini, please?
EMPLOYEES Name Initials PAPINI HIDE PAPINI BAKER G. T.M. G. S.J.T. Birthdate 02-FEB-1954 11-JUN-1961 02-FEB-1945 24-SEP-1958
Clearly, the answer could be different when your company employs five or 50,000 employees. Be aware that adding a new identifying attribute for EMPLOYEE, say, Id, only partially solves the above problem. It would be very useful within the database. It would not help much in the real world where employees usually would not know their IDs, let alone the IDs of others. This kind of Id attribute often works only as an internal, but not as an external identification.
......................................................................................................................................... 4-5
Unique Identifier
To know what you are talking about, you need to find, for every entity, a value, or a combination of values, that uniquely identifies the entity instance. This value or combination is called the Unique Identifier for the entity. About the slide See Page 31 Practice See Page 32 This is a suitable place to do practice 4-1.
Unique Identifier Examples

JOB COMPUTER IN NETWORK TELEPHONE Name IP Address Country code, Area code, Telephone number EMPLOYEE Employee number Name, Initials, Birth Date MAIL LIST Name, Owner
4-5
or
The MAIL LIST example shows that a unique identifier is not necessarily a combination of attributes: the owner of a MAIL LIST is actually represented by a relationship. UID Representation In an ER diagram, the components of the UID of an entity are marked: # for attributes. With a small bar across the relationship end for relationships (a barred relationship).
Indicates Unique Identifier
ORDER # Date
by responsible for
CUSTOMER # Family Name o Initials # Address o Telephone
Indicates Unique Identifier
Unique Identifier .........................................................................................................................................
USER # Name
part of contains owner of owned by
MAIL LIST # Name
Single Attribute UID The model shows that a USER of ElectronicMail is identified by attribute Name only. Many entities will be identified by a single attribute. Typical candidate attributes, if available, for single attribute UIDs are: Id, Code, Name, Description, Reference. Multiple Attribute UID An entity may have a UID that consists of multiple attributes; for example, a software package can usually be identified by its Name and its Version, such as Oracle Designer, version 7.0. Composed UID A MAIL LIST, illustrated above, is identified by the Name of the LIST plus the USER that owns the LIST. That means that the combination of OWNER and a Name of a list must be a unique pair. This means that every USER must name their LIST instances uniquely, but need not worry about names given by other users. It also means that the system may have many LIST instances with the same name, as long as they are owned by different USERS. You may argue that a USER also has a composed UID, as the Name must be unique, within this mail system. To show this, you could add an extra high level entity, MAIL PROVIDER, plus a relationship form USER to PROVIDER. The relationship then is part of the UID of a USER. Cascade Composed UID It is not uncommon that an entity has a barred relationship to another entity that has a barred relationship to a third entity, and so on. About the slide See Page 32
ROOM # No
FLOOR # No
HOTEL # Name
......................................................................................................................................... 4-7
UID: Relationships Only About the slide See Page 32
Multiple Relationship UID

USER # Name
part of contains owner of owned by
USER # Name
is referred to owner of owned by
LIST # Name
LIST # Name
contains referring to contained in
LIST ITEM
4-8
A Unique Identifier can also consist of relationships only. At the lower right side of the diagram, entity LIST ITEM is shown, which resulted from the resolved m:m relationship between LIST and USER. The model shows that a LIST ITEM is identified by the combination of the USER and the LIST. In other words, the model says that a LIST may contain as many ITEMS as you like, as long as they refer to different USERS. This results in the next definition: A Unique Identifier (UID) of an entity is a constraint that declares the uniqueness of values; a UID is composed of one or more attributes, one or more relationships, or a combination of attributes and relationships of the entity. Consequently, not all components of the UID may be optional. Indirect Identification Identification regularly takes place using an indirect construction, that is, when the instance of an entity is identified only by the instance of another entity it refers to. Examples In many office buildings employees are identified by their badge, which is identified by a code. Around the world a person is identified by the picture on their passport.
All cows in the European Community are identified by the number of the tag they are supposed to wear in their ear. When you park a car at Amsterdam International Airport you enter the parking lot by inserting a credit card into a slot at the gate. The parking event is identified by the credit card of the person that parked the car. This is a double indirect identification. Clearly, these identification constructions are not 100% reliable, but are probably as far as you can go in a situation. The model of these indirect identifications is shown in the next illustration, at the right bottom corner. An instance of S is identified by the single instance of T it refers to. In other words, the UID consists of one relationship only. Multiple UIDs Entities may have multiple UIDs. Earlier, you saw the example of entity EMPLOYEE that can be identified by an Employee Number, and possibly by a combination of, for example, Name, Initials and Birth Date. At some point in time, usually at the end of your analysis, you promote one of the UIDs to be the primary UID. All the other UIDs are called secondary UIDs. You would usually select the UID that is most compact or easy to remember to become primary UID. The reason, of course, is that the UID leads to one or more foreign key columns in related tables. These columns should not be too sizeable. Preferably, the primary UID of an entity does not consist of optional elements. UID in Diagram Only the primary UID is shown in ER Diagrams. Where UIDs Lead Unique Identifiers lead to Primary Key and Unique Key constraints.
......................................................................................................................................... 4-9
Unique Identifier Examples About the slide See Page 32
Well-defined Unique Identifiers

Z # Z1 o Z2 o Z3 # Z4 Q # Q1 Y # Y1 # Y2 K L # L1 M # M1 R # R1 T # T1 P # P1
X # X1
XY
4-9
Examples of Incorrect Unique Identifiers About the slide See Page 33 Practice See Page 33 This is a suitable place to do practice 4-2.
Incorrect Unique Identifiers

K # K1 L # L1 F # F1 P # P1 G # G1
KL
R # R1
T
o
# T1 H
Q # Q1
G # G1
4-10
Information-Bearing Identifiers When things in the real world are coded, you need to be especially careful. Codes that have been used for some time are often information bearing. An example is a company that uses product codes like 54.0.093.81, where 54 refers to the product group, 0 shows that the product is still in production, 093 identifies the factory where the product is made and 81 is a sequence number. These codes come from the time when a maximum amount of information had to be squeezed into a minimum number of bits. The example above would be modeled conceptually: About the slide See Page 35
Information-Bearing Codes
54.0.093.81
Product Group In Production? Factory Sequence Number
PRODUCT # Code * In Production? * Sequence No
PRODUCT GROUP # Code FACTORY # Id
4-11
The Code attribute would contain the same codes, for reasons of compatibility, but now without meaning, as the old meaning is transferred to the attributes and relationships. Product 54.0.093.81 may now be produced by factory 123 and may no longer be in Product Group 54.
......................................................................................................................................... 4-11
Arcs
Suppose ElectronicMail rents the Advertisement Areas that are located in their various mail screens on the Web. This renting is controlled by contracts; contracts consist of one or more standard conditions and customized conditions. This can be modeled with four entities: CONTRACT, CONTRACT COMPONENT, STANDARD CONDITION and CUSTOMIZED CONDITION. See the model below. How do we model the following constraint: every instance of CONTRACT COMPONENT refers to either a STANDARD CONDITION or a CUSTOMIZED CONDITION, but not to both at the same time? An arc is a constraint about two or more relationships of an entity. An arc indicates that any instance of that entity can have only one valid relationship of the relationships in the arc at any one time. An arc models an exclusive or across the relationships. An arc is therefor also called exclusive arc. There is no similar constraint construct for attributes of an entity. About the slide See Page 35
Arcs
Contract
Conditions 1 2 3 4 5 6
Std?
A contract consists of contract components; these are standard conditions or customized conditions
CONTRACT STANDARD basis for CONDITION based consists in on of CUSTOMIZED CONDITION Arc in
Indicates relationship in arc
part of referring to referring to CONTRACT COMPONENT
4-12
Arc Representation The arc is drawn as an arc-shaped line, around an entity. Where the arc crosses a relationship line a small circle is drawn, but only if the relationship participates in the arc.
Arcs .........................................................................................................................................
Mandatory Compared to Optional Relationships in an Arc When the arc is drawn across two mandatory relationships, as in the example above, it means that every instance of CONTRACT COMPONENT must have one valid relationship. When the arc is drawn across two optional relationships, it would mean that an instance may have one valid relationship. Another Arc Example About the slide See Page 35
Exclusive Arc
USER owner of
owned by
LIST
is referred to container of contained in is referred to
referring to
referring to
LIST ITEM
4-13
Suppose a MAIL LIST may contain USERS as well as other MAIL LISTS. This means that a particular LIST ITEM may refer to a USER or a LIST. To be more precise, it must be a reference to a USER or to a LIST, but not to both at the same time. Note The relationship contained in/container of from LIST ITEM to LIST (the one that is printed in gray) is not part of the arc as there is no small circle at the intersection with the arc. A relationship that is part of a UID may also be part of an arc. The constraint that a LIST may only contain LISTS other than itself cannot be shown in the model. Where Arcs Lead An arc is normally implemented as a check constraint in an Oracle database. Note that a check constraint is not an ISO standard relational database object. In other words, an arc must be implemented differently in other database systems.
......................................................................................................................................... 4-13
Possible Arc Constructs
4-14
Some Rules About Arcs An arc always belongs to one entity. Arcs can include more than two relationships. Not all relationships of an entity need to be included in an arc. An entity may have several arcs. An arc should always consist of relationships of the same optionality: all relationships in an arc must be mandatory or all must be optional. Relationships in an arc may be of different degree, although this is rare. Tips About Arcs Do not include a relationship in more than one arc, for clarity reasons. Consider modeling subtypes instead of arcs (see the next paragraph).
Arcs .........................................................................................................................................
Incorrect Arcs About the slide See Page 36
Some Incorrect Arc Constructs
The arc belongs to one entity Relationships in the arc must be of the same optionality Arcs must contain at least two relationships
An arc may be correct, but is quite difficult to implement ...

4-15
You cannot capture all possible relationship constraints with arcs. For example, if two out of three relationships must be valid, this cannot be represented. The table below shows what an arc can express. Number of Valid Relationships in Arc Per Entity Instance Minimum Maximum }n n n
}n
}n
}n
4-16
......................................................................................................................................... 4-15
Arc or Subtypes
Relationships within an arc are often of a very similar nature. They frequently carry exactly the same names. If that is the case, an arc can often be replaced by a subtype construction, as the illustration shows. On the left you see the arc that contains both referring to relationships of LIST ITEM. In the model on the right there is only one relationship left, now connected to an entity ADDRESS, a new supertype entity of USER and LIST. Both models are equivalent. About the slide See Page 36
Arc or Subtype
USER
owner of owned by
ADDRESS USER
owner of owned by
LIST
is referred to contains referring to in is referred to referring to
LIST
contains is referred to referring to in
LIST ITEM
LIST ITEM
4-17
The model on the left emphasizes the difference between USER and LIST, which clearly exists; the other model emphasizes the commonality. This commonality is mainly a functional issue. Both USERS and LISTS can be part of a LIST and both can be used as the address in the To, Cc or Bcc field in the screen for composing a message. Generally speaking, you can replace every arc with a supertype/subtype construction and every supertype/subtype construction with an arc.
More About Arcs and Subtypes .........................................................................................................................................
More About Arcs and Subtypes

Arcs and Subtypes are similar notions. The five models that are printed below all show the same context. Model 1 and 2 are equivalent models to what you have seen before. If every instance of A is related to a P or a Q, then you could say there are P-relatedAs and Q-related-As. These two subtypes of A are shown in model 3. Model 4 goes one step beyond this and shows subtypes of entity A and a supertype R of P and Q. Though models 3 and 4 are completely correct, it is likely they both model something twice. About the slide See Page 36
Arc and Subtypes

A 1 R P 2 A
Q A C
A A 3 B C 4 R P B
C 5 Q
P
4-18
R P
Note that only model 5 does not present the same information. In model 5, an instance of B may be related to an instance of Q, unlike that which is modeled in 3 and 4.
......................................................................................................................................... 4-17
Hidden Relationships
Every subtype hides a relationship between the subtype and its supertype. Moreover, the relationships are in an arc, as the next illustration shows. Both relationships are mandatory 1:1 is/is relationships. About the slide See Page 37
Subtypes Hide Relationships in Arc
A B C
A
is B is is is

4-19
Every A is either a B or a C Every B is an A Every C is an A
Every A must be a B or be a C Every B must be an A Every C must be an A
Domains .........................................................................................................................................
Domains
A very common type of attribute constraint is a set of values that shows the possible values an attribute can have. Such a set is called a domain. Very common domains are, for example: Yesno: Yes, No Gender: Male, Female, Unknown Weekday: Sun, Mon, Tue, Wed, Thu, Fri, Sat In a conceptual data model you can recognize these as entities with, usually, only two attributes: Code and Description. These domain entities are referred to frequently but do not have any many relationships of their own, (see model A below). Typically, you would know all the values before the system is built. The number of values is normally low. Often you would deliver such a system with non-empty code tables An alternative model for the (sometimes many) code entities is a more generic, twoentity approach: CODE and CODE TYPE, model B. Model A has the advantage of fewer relationships per entity as well as easy-tounderstand entities; B has obviously fewer entities and therefore will lead to fewer tables.
.
Value sets
CODE TYPE # Id * Name * Max Length of Description
YESNO # Code * Description
A B
GENDER # Code * Description
WEEKDAY # Code * Description
CODE # Code * Description
4-20
Domains that have a large number of values, such as all positive integers up to a particular value, are usually not modeled. You should list and describe such a constraint in a separate document.
......................................................................................................................................... 4-19
Some Special Constraints

Although an entity relationship model can express many of the constraints that are not too complex, there are many types of constraints left that cannot be modeled. These constraints must be listed on a separate document and often need to be handled programmatically. Categories: Examples Conditional domain: The domain for an attribute depends on the value of one or more attributes of the same entity. State value transition: The set of values an attribute may be changed to depends on the current value of that attribute. Range check: A numeric attribute must be between attribute values of a related instance. Front door check: A valid relationship must only exist at creation time. Conditional relationship: A relationship must exist or may not exist, if an attribute (of a related entity) has a special value. State value triggered check: A check must take place when an attribute is given a value that indicates a certain state. There are also combinations of the above. Range Check: Example About the slide See Page 37
EMPLOYEE * Name * Address JOB * Title * Minimum Salary * Maximum Salary
between
with for
of referring to
EMPLOYMENT * Start Date o End Date * Salary
Constraint: Employee salary must be within the salary range of the job of the employee.
Some Special Constraints .........................................................................................................................................
State Value Transition: Example About the slide See Page 38
EMPLOYEE * Name * Address * Current Marital Status
Possible to Marital Status Transitions from Single Married Widowed Divorced Domestic Partnership
Constraint: Marital Status of employees cannot change from any value to all other values. Conditional Relationship: Example About the slide See Page 38
STANDARD basis for CONDITION based on in CUSTOMIZED CONDITION in
CONTRACT # Id * Standard Indicator
consists of
part of referring to
CONTRACT COMPONENT
referring to
4-23
Constraint: If a CONTRACT has Standard Indicator set to Yes, the CONTRACT COMPONENT may not refer to a CUSTOMIZED CONDITION.
......................................................................................................................................... 4-21
Sin Mar Wid Div DP
Derived Attribute? You may argue that the attribute Standard Indicator of CONTRACT is derivable. If the contract contains CUSTOMIZED CONDITIONS, it is, by consequence, not a standard CONTRACT. This may be true, but it is not necessarily so. Suppose the contract is created in various steps, by various people with different responsibilities. Then, the creation of a CONTRACT is a process that may take days. The Standard Indicator, then, is an attribute of that process. Only when the CONTRACT is finalized, should a check be made that the Indicator corresponds with the actual STANDARD and CUSTOMIZED CONDITIONS. In those situations, the entity CONTRACT will usually have an attribute Completed Indicator that triggers the check when set to Yes. Rules May Lead to Attributes If you cannot capture a constraint in the model, the best you can do within the model is make the model rich enough so that a program for constraint checking performs well. Consider the rule: If the Standard Indicator is set to No, and there is no CUSTOMIZED CONDITION, then the CONTRACT is not yet ready for being sent to the CUSTOMER. This rule deals with a procedure and cannot be modeled as such, but it calls for an indicator at entity CONTRACT to indicate something like a Ready To Send status. Model for Overview An analyst often runs into constraints that cannot be modeled and thus must be documented separately. This is not a weakness of the model. An important goal of a diagram is to give an overall picture, not all the details. The model should let you view the key areas clearly.
Some Special Constraints .........................................................................................................................................
Boundaries More than once the checking of constraints or special rules needs to use information that is not directly related to one of the entities in the model. Typical examples are rules and boundaries set by external sources, like a mother company or national legislation. If reasonably possible, these rules should be part of your conceptual data model, and should not be hard coded in your programs. The reason is obvious: if the rule changes, which is beyond your power, there is a chance you do not have to make changes to your programs. Only an update of a value in a table would be necessary. The time spent developing a complete model is fully justified by the programming time saved. About the slide See Page 38
Boundaries
EXTERNAL # Id * Description * Value
unrelated entity
and possible implementation

EXTERNALS Id Description 1 2 3 4 Value added tax % Maximum available Space per Mail User in Mbyte Maximum level of Nested Mail Folders Maximum level of Nested Mail Lists Value 15 500 3 16
4-24
......................................................................................................................................... 4-23
Summary
Entities in the real world must be individually identified before they can be represented in a database. You would not know what you are talking about, otherwise. Some entities are really difficult to identify, such as people and paintings. Some are more easy, especially when they are part of the domain as you can make up the rules, such as a unique number for each of the invoices you send to your customers. Some unique identifiers are already present in the real world, often as a combination of attributes and relationships of the entity.
Summary
Identification
Can be a real problem in the real world Models cannot overcome this
Entities must have at least one Unique Identifier Unique Identifiers consist of attributes or relationships or both Arcs Many types of constraint are not represented in ER model
4-25
Arcs in a diagram represent a particular type of constraint for the relationships of one entity. Many business constraints cannot be represented in a diagram and must be listed separately. This way the model remains clear and not too full of graphical elements.
Practice 41: Identification Please .........................................................................................................................................
Practice 41: Identification Please

Your Assignment (See Page 32) Describe how you would identify the following entities, making up any attributes and relationships you consider appropriate.
Practice: Identification Please
A city A contact person for a customer A train A road A financial transaction An Academy Award (Oscar) A painting A T.V. show
4-27
......................................................................................................................................... 4-25
Practice 42: Identification

Your Assignment (See Page 33) Are the entities in the next diagrams identifiable?
1
A # Xx
B * Yy
C # Zz
2
A C # Code B # Id
3
A * Xx B # Yy
C # Zz
with of
D # Id
4
P Q # Id
Practice 42: Identification .........................................................................................................................................
P # Name
Note: the next model describes a context that may be different from the world you are familiar with.
PERSON MALE # Seqno

son of
FEMALE # Name mother of # Birth Date

partner in
partner in
with husband
with wife
MARRIAGE # Start Date
7 Given the above model, answer the following questions. a b c d e f
Can person A marry twice? Can person A marry twice on the same day? Can person A marry with person B twice? Can person A marry with person B twice on the same day? Can person A be married to person B and person C simultaneously? Can person A be married to person A?
......................................................................................................................................... 4-27
Practice 43: Moonlight UID

Moonlight Coffees
Goal (See Page 39) The purpose of this practice is to define UIDs for given entities.
Scenario Moonlight Coffees, organization model. Your Assignment Use what you know about Moonlight Coffees by now, and, most importantly, use your imagination. 1 Given the model below, indicate UIDs for the various entities. Add whatever attributes you consider appropriate. Country organizations have a unique tax registration number in their countries. 2 Are there any arcs missing?
reporting to
report of
DEPARTMENT OTHER DEPARTMENT

with
HQ
report of reporting to
COUNTRY in ORGANIZATION
of with with belongs to
COUNTRY
with in
EMPLOYEE
with of for for
SHOP
with
PAYROLL ENTRY
to for
to as in
ASSIGNMENT
JOB
4-34
Practice 44: Tables .........................................................................................................................................
Practice 44: Tables

Goal (See Page 39) The purpose of this practice is to match a given context with a ER model. Your Assignment Read the text on ISO Relational tables. Do a quality check on the ER model based on the quoted text and what you know about this subject. Also list constraints that are mentioned in the text but not modeled.
Practice: Table 1
In a relational database system, data is stored in tables. Tables of a database user must have a unique name. A table must have at least one column. A column has a unique name within the table. A column must have a data type and may be Not Null. Tables can have one primary key and any number of unique keys. A key contains one or more columns of the table. A column can be part of more than one key. A table can have foreign keys. A foreign key always connects one table with another. A foreign key consists of one or more columns of the one table that refers to key columns of the other table. The sequence of columns within the key and foreign key is important.
FOREIGN KEY # Name
from to
with
TABLE # Name
with of
KEY # Name PRIMARY UNIQUE
with
referenced in
with
with for ASSOCIATION # Seqno from in in COLUMN # Name in * Data Type o Not Null for USAGE of # Seqno
in
to
......................................................................................................................................... 4-29
Practice 45: Modeling Constraints

Goal (See Page 39) The purpose of this practice is to learn what constraints can be modeled and how, and which cannot be modeled. Your Assignment Change the diagrams to model the constraint given.
EMPLOYEE # Name
managed by
manager of
1 Every EMPLOYEE must have a manager, except the Chief Executive Officer.
USER # Name
owned by LIST owner of # Name owned by NICKNAME # Alias
owner of
2 A user may not use the same name for both NICKNAME and LIST name.
with subfolder
FOLDER Name
within owner of owned by
USER # Name
3 A top level FOLDER must have a unique name per user; sub folders must have a
unique name within the folder where they are located.
Instructor Notes
Instructor Note Topic Timings Lecture 60 minutes Practice 90 - 180 minutes Total 150 - 240 minutes
4 4
C o nstrain ts
O verview
U n iq u e Id e n tifiers A rc s D o m a in s V ario u s o th er co n s train ts
This lesson describes business constraints and how these may be captured in an ER model. Unique identifiers and arcs are discussed in detail. Of course, many types of business constraints cannot be modeled at all. Examples of these are discussed in the second part of this lesson. If you saw this information in a table, would you suspect its correctness? Possibly the system had checked the unicity of the combination of Name, Initials and Birthdate. For the table there are two employees called G. Papini. This is an example of the problem of identification. The bad news is: you cannot prevent this happening. The identification of employee is very disputable. Although unlikely, the combination may have duplicates. Students may suggest using a Social Security Number. This, however, is not a safe identifier within some countries (like the USA) and is not available in every country around the world. The safest identifiers are the abstract and technical ones, like those for JOB and TELEPHONE.
4 -2
R em b randt
4 -3
U nique Iden tifier Exa m ples

JO B C O M P U T E R IN N E T W O R K TELEPHONE N am e IP A d d re ss C o u n try co d e, A re a c o d e, T elep h o n e n u m b e r EM PLOYEE E m p lo ye e n u m b er N am e, In itials , B irth D a te M A IL L IS T N am e, O w n er
4 -5
or
......................................................................................................................................... 4-31
Prac tice: Id entification Ple ase
A c ity A c o n tact pe rs o n fo r a cu s to m er A tra in A ro a d A fin a n cia l tra n sa ction A n A c ad e m y A w ard (O sc ar) A p a in tin g A T .V . sh o w
Practice 4-1 Good practice for joint class activity and discussion.
4 -2 7
U nique Identifier
Indicates U nique Identifier
O R D ER # D ate
by responsible for
C U S TO M E R # F am ily N am e o Initials # A dd ress o Telepho ne
Indicates U nique Identifier
The drawing technique suggests that you do not need to show the optionality of an attribute that is part of a UID. This wrongly suggests that the attributes in a UID are always mandatory. Columns in a primary key in an Oracle RDBMS must be mandatory, but that is another issue.
4 -6
U n iq ue Ide ntifie rs
USER # N am e
part of contains o w ner of ow ned by
Entities can have several relationships. The barred relationship is not an arbitrary choice. Avoid the discussion about the implementation of cascade barred relationships. This is covered in the chapter on Mapping.
M AIL LIS T # N am e
ROOM # No
F LO O R # No
H O T EL # N am e
4 -7
M ultip le R ela tion ship U ID

U S ER # Name
part of contain s contains ow o w ner of of ow ned by
U SE R # N am e
is refe rred to ow ner of ow ne d by ned
Resolved relationships usually lead to intersection entities that are identified by their relationships.
LIS T # Name
LIS T # Name
contains referring to contained in
LIS T ITE M
4 -8
W ell-de fine d U nique Iden tifiers

Z # Z1 o Z2 o Z3 # Z4 Q # Q1 Y # Y1 # Y2 K L # L1 M # M1 R # R1 T # T1 P # P1
X # X1
XY
Entity P is well identified as it refers to Q which is well identified as it refers to R which is well identified. Entity K is well identified as each of its subtypes is well identified. Entity S is well identified by a single relationship.
4 -9
In correct U nique Iden tifie rs

K # K1 L # L1 F # F1 P # P1 G # G1
KL
R # R1
T
o
# T1 H
Q # Q1
G # G1
4 -1 0
This slide can be used as a class discussion: explain why the entity is not well defined. KL in not well identified as there are possibly KL instances that are not related to a K nor an L. G is not well identified as you would not know which F it refers to. You cannot model that a set is identified by its elements. T is not well identified because the attribute is optional. P, Q and R are not well identified as the identifiers have a circular structure. H is not well identified because two instances of H can refer to the same instance of G. The identifier of that instance is therefore not unique for H. Practice 4.2.1 Good practice for joint class activity and discussion
P ractice : Identification 1
A # Xx
B * Yy
C # Zz
4 -2 8
A C # C o de
Practice 4.2.2 Good practice for joint class activity and discussion.
B # Id
4 -2 9
A * Xx B # Yy
C # Zz
w ith of
D # Id
4 -3 0
......................................................................................................................................... 4-33
Q # Id
4 -3 1
P # N am e
4 -3 2
P E R SO N M A LE # S eqn o
son of
FE M A LE # N am e
partner in
m other of # B irth D ate
partner in
w ith hu sband
w ith w ife
M A R R IA G E # S ta rt D ate
Practice 4.2.6, 4.2.7 Good practice for joint class activity and discussion. Do not forget the extra questions (4.2.7) as these really focus on the understanding of what is in the model and what not.
4 -3 3
In form ation -B earing C o des

54.0.093.81
P rod u c t G ro u p In P ro d u ctio n ? F ac tory S e q u en c e N u m b er
PRODUCT # C ode * In Produ ction? * S equ ence N o
PRODUCT GROUP # C o de F A C TO R Y # Id
4 -1 1
There is a a great deal to explain about the problems of information-bearing numbers (codes). The older the codes the more suspicious you should be, but these codes are an undeniable part of the world today. Some examples: Social Security numbers that have gender coded into them. What if someone has a change of gender? Bank account numbers that have a branch office coded into them. What should a bank do when their customers do not accept the change in their bank account number when they move to another city? An e-mail account that carries the name of the internet provider. What do you do when you want to change to another provider? Guidelines: Do not introduce new information-bearing codes Try to bury existing ones If that is impossible, try to neutralize old ones by treating them as codes that do not bear information Give the delegate time to absorb this contract context as it contains much detail. Explain that an arc softens a constraint that was modeled earlier: where you had two mandatory relationships now one is enough.
A rcs
C on tra ct
Co nditions 1 2 3 4 5 6
S td?
A co n tra ct c o ns is ts o f c o n tra ct co m p o n e n ts ; th e s e a re sta n da rd co n d itio n s o r c u sto m iz ed c o n ditio n s

C O N TR A C T S T A N D A R D ba sis for basis C O N D ITIO N based consists in on of C U S TO M IZE D C O N D ITIO N A rc in
In dic ate s re latio n ship in arc
part of refe rring to referring to C O N TR A C T C O M P O N E N T
4 -1 2
Exc lus ive A rc
The example shows why the little circles are of value. Moreover, it shows that relationships in an arc may also be barred.
USER
ow ner of ow ned by
LIS T
is referred to container of is referred to
conta ined contained referring to in
referring to
LIS T ITE M
4 -1 3
......................................................................................................................................... 4-35
Pos sible A rc C on stru cts
4 -1 4
Arcs may: Contain more than two relationships Contain optional relationships, but then they must all be optional Cross 1-ends of relationships Cross relationships of different degree. Some schools of thought say the degree must be the same, but there is no reason for this. As long as both relationships will result into foreign keys for the same table, the implementation is no problem. An entity can have several arcs. The most common mistakes about arcs. For Oracle Designer users: in Oracle Designer it is possible to create an arc across one relationship, by drawing a regular one and then deleting one of the arced relationships...
Som e Inco rre ct A rc C ons truc ts
T h e a rc b e lo n g s to o n e e n tity R elatio n s h ip s in the a rc m u s t b e o f th e sa m e o p tio n ality A rcs m us t c on ta in a t lea st tw o re la tio n sh ip s
A n arc m a y be c o rrec t, b u t is q u ite d ifficu lt to im p le m en t ...

4 -1 5
A rc or S ubtyp e
U SE R
ow ner ne r of of ow ned by
A DD R E S S USER
ow ner of ow ned by
LIS T
is referred co ntains to contains referring to in is referred to referring to
LIS T
conta ins is referred to referring to in
LIS T IT EM
LIS T IT EM
4 -1 7
Arcs can always be replaced by a subtype/ supertype construction, if you are allowed to create the supertype. This is allowed if the (future) subtypes are mutually exclusive. And this should be the case when you were modeling with one of the goals of entity modeling in mind: create a model where the important real world things are represented only once. This can be put in other words: a correct entity model should always allow any two entities to become subtypes of a new super entity. In model 3 and 4 entity B and C show expicitly what is sometimes referred to as implicit subtypes of A, as entity B (C) can be defined as those instances of A that refer to P (Q).
A rc a nd Sub types
A 1 R P 2 A
Q A C
A A 3 B C 4 R P B
C 5 Q
P
4 -1 8
R P
Sub ty pes H ide R elation ships in A rc
A B C
A
is is is is
Knowledge of this subtype/arc model is important as one of the possible table implementations (arc implementation) of the left-hand model is based on the right-hand model.

4 -1 9
E v ery A is eith e r a B o r a C E v ery B is a n A E v ery C is a n A
E v ery A m us t be a B or be a C E v ery B m us t b e an A E v ery C m us t b e an A
Va lu e se ts
C O D E TY P E # Id * N am e * M ax Length of D escription
YESNO # C ode * D escription
A B
GENDE R # C ode * D esc ription
W EEKDAY # C ode * D escription
CODE # C ode * D escription
4 -2 0
Domains in the sense used by Oracle Designer are only known within the context of the tool. Domains are no ISO object, nor an Oracle database object. When you use Oracle Designer, you would very likely model the code/description entities as domains. The important property of a domain is the fact that the values are known and set before the system goes live. You would model all the other ones as entities as every now and then new values are introduced. Using the generic model leads to the need of additional, though simple, coding. The multiple table variant gives some loss of performance, but may reduce the number of tables and maintenance applications dramatically. This comes down to a non-equijoin at table level. This constraint cannot be diagrammed.
O ther C on stra in ts: R an ge C heck
E M P LO Y E E * N am e * A ddress
w ith for
JO B * Title * M inim um S alary * M axim um S alary
betw een
of referring to
E M P LO Y M E N T * S tart D ate o E n d D ate * S alary
4 -2 1
......................................................................................................................................... 4-37
O ther C on stra in ts: State Value Tran sition
E M P LO Y E E * N am e * A ddress * C urrent M arital S ta tus
P ossible to M arital S tatu s Transitions from S ingle M arrie d W idow ed D ivorc ed D om estic P a rtnership
Note that you can model the Allowed Transitions, as status pairs. This, however, does not check the transitions. It only keeps information about what is allowed and what not. You must code an additional check to compare the old and new value after an update of Current Marital Status. In general, no constraints can be modeled that depend on attribute values. ER models do not have a representation of values as the models only deal with data structure.
4 -2 2
C ond itio nal R elatio nship

C O N TR A C T # Id * S tandard In dicator
consists of
S TA N D A R D basis for C O N D ITIO N based on in C U S TO M IZE D C O N D ITIO N in
part of referring to
C O N TR A C T C O M P O N E N T
referring to
4 -2 3
Sin Mar Wid Div DP
B oun daries
E X TE R N A L # Id * D escription * V alue
u n re late d en tity
a n d p o ss ib le im p lem e n tatio n
E X TE R N A LS Id D e scription 1 2 3 4 V a lue added tax % M a xim um available S p ace per M ail U ser in M by te M a xim um level of N ested M ail Folders M a xim um level of N ested M ail Lists V a lue 15 500 3 16
This picture is, of course, not 100% safe, particularly when the nature of a rule changes, for example, if new legislation determines that the tax on added value (sales tax) is a fixed value and not a percentage or when the percentage depends on the nature of the product.
4 -2 4
Sum m ary
Ide n tifica tio n
C a n b e a rea l p rob le m in th e re a l w o rld M o d e ls ca n n ot o v erco m e th is
E n tities m u st h a ve a t lea s t o n e U n iq u e Id e ntifie r U n iq u e Id e n tifiers c o ns is t o f attrib u te s o r re la tio n sh ip s o r b o th A rc s M an y typ e s o f co n s tra in t a re n ot rep re se n te d in E R m o d e l
4 -2 5

Prac tices
Ide n tifica tio n P lea se Ide n tifica tio n M o o n lig h t U ID T a b le s M o d e lin g C o n stra in ts
4 -2 6
Practice Identification Please Identification Moonlight UID Tables Constraints
3day Yes Yes Opt Opt Cha
4day Yes Yes Yes Cha Yes
rep ortin g to
rep ort o f
D E P A RT M E N T OTHER D E P A RT M E N T
w ith
HQ
rep ort o f repo rtin g to
COUNTRY in O R G AN IZ A TIO N
of w ith w ith b elon g s to
COUNTRY
w ith in
EM P LO Y E E
w ith of fo r for
SHOP
w ith
P AY R O L L E N TR Y
to fo r
Practice 4.3 The model is based on the result of practice 3-5: Moonlight P&O. If the delegates did not perform that practice, spend a little time reading the model to make sure they understand the business context.
to as in
AS S IG N M E N T
JO B
4 -3 4
Prac tice: Table 1

In a relational database sy stem , data is stored in tables. Tables of a databas e user m ust have a unique nam e. A ta ble m ust have at lea st one colum n. A colum n has a unique nam e w ith in the table. A colu m n m ust ha ve a data type and m ay be N ot N ull. Tables can have one prim a ry key and any num ber of unique keys. A key con tains one or m ore c olum ns of the table . A colum n can be part of m ore than one key. A table can have foreign ke ys. A foreign key a lw ays connects one table w ith another. A foreig n key consists of on e or m ore colum ns of the one table that refers to key colum ns of the other table. The seq uence of colum ns w ithin the key and fo reign key is im portant.
Practice 4.4 When your students do not know much about tables and keys, this is a good practice.On one hand it gives business information about tables, columns, and keys, but on the other hand the practice is about identification and constraints. Practice 4.5.1 You can model constraints in 4.5.1 - 4.5.3 using subtypes, UIDs, arcs or combinations of these.
4 -3 5
Pra ctice : C o nstrain ts 1
EM PL O Y E E # N am e
m anag ed by
m anager of
4 -3 7
......................................................................................................................................... 4-39
USER # N am e
ow ner of
ow ned by LIS T # N am e ow n ed by N IC K N A M E # A lias
Practice 4.5.2 Typical example of supertype modeling where various entities share the same namespace.
ow ner of
4 -3 8
w ith subfolder
F O LD E R N am e
w ithin ow ner of ow ned by
U SE R # N am e
Practice 4.5.3 This is the most complex of the three. The endless loop (see 4.2.5) can be broken because the top level folder is identified differently.
4 -3 9

Name: Full Email:
Content
Type
Page Number
Note
......................................................................................................................................... 4-41
Suggested Graphics
......................................................................................................................................... 4-43
fold here
5
.................................
Modeling Change
Lesson 5: Modeling Change .........................................................................................................................................
Introduction
Every update of an attribute or transfer of a relationship means loss of information. Often that information is no longer of use, but some systems need to keep track of some or all of the old values of an attribute. This may lead to an explicit time dimension in the model which is usually quite a complicated issue. Lesson Aim Time is often present in a business context, as many entities are in fact a representation of an event. This lesson discusses the possibilities and difficulties that arise when you incorporate time in your entity model. Schedule See Page 25 About the slide See Page 25
Overview
Date and time Modeling change over time Prices change Journalling
5-2
Topic Introduction Time Date as Opposed to Day Entity DAY Modeling Changes Over Time A Time Example: Prices Journalling Summary Practice 51: Shift
See Page 2 4 5 6 7 10 17 19 20
Introduction .........................................................................................................................................
Topic Practice 52: Strawberry Wafer Practice 53: Bundles Practice 54: Product Structure
See Page 21 22 24
Objectives At the end of this lesson, you should be able to do the following: Make a well considered decision about using entity DATE or attribute Date Model life cycle attributes to all entities that need them List all constraints that arise from using a time dimension Cope with journalling
......................................................................................................................................... 5-3
Time
Modeling Time In many models time plays a role. Often entities that are essentially events are part of a model, for example, PURCHASE, ASSIGNMENT. One of the properties you record about these entities is the date or date and time of the event. Often the date and time are part of a unique identifier. About the slide Change and Time See Page 25
Every update means loss of information. Time in your model makes the model more complex. There are often complex join conditions. Users can work in advance. When do you model date/time as an entity? What constraints do arise? How do you handle journalling?
A second time-related issue often helps to increase the usability of a system dramatically. By adding dates like Start, Expiry, End Date, to data in the system, you allow users to work in advance. Suppose a particular value, say the price of gas or diesel, will change as of January 1. It is very useful to be able to tell the system the new value long before New Years Eve. By adding a time dimension to the model you make the system independent of the now. As always, there is a price for adding things such as this. Adding a time dimension to your conceptual data model makes the model considerably more complex. In particular, the number of constraints and business rules that must be checked will increase. A third time-related issue in conceptual data models is connected to the concept of logging or journalling. Suppose you allow values to be updated, but you want to keep track of some of the old values. In other words, what do you do when you need to keep a record of the history of attribute values, of relationships, of entire entities? The following issues arise: When do you model date/time as an entity, and when as an attribute? How do you handle the constraints that arise in systems that deal with time-related data? How do you handle journalling?
Date as Opposed to Day .........................................................................................................................................
Date as Opposed to Day

Probably all current operating systems and database systems have types date and time available that know, for example, that 29-OCT-1983 was a Saturday in the 10th month, called October, of 1983. Some database systems, like Oracle, see time as a component of a date and store them in one. Knowing that, you are likely to decide that dates can be modeled as attributes with the format date. About the slide See Page 26
Entity DAY or Attribute Date
PURCHASE
on
Single attribute entity without m:1 relationships is usually replaced by attribute
of
DAY # Date
PURCHASE * Date
5-4
A day, however, is not just a date. My great-grand father was born on a day in 1852, but the exact date is unknown. A Genealogical Register System should therefore be able to store fragments of a date, such as 1852, or even a description, such as around 1765. Systems that store historical information often have to deal with several dates for one event, according to multiple sources with nonidentical information. Some systems have to take dates in conjunction with the reliability of that date. Clearly, in these cases a simple attribute would not suffice. Loosely speaking, when you are interested in the date only, and these dates are known to the user, model an attribute; on the other hand, when you are interested in the day, model it as an entity with attribute Date, which is possibly a unique identifying attribute.
......................................................................................................................................... 5-5
Entity DAY
It is not only systems that deal with historical information that struggle with dates. Sometimes a system needs to know more about a day than can be derived from its date. A planning system, for example, often needs to know if a particular day is a public holiday. Many data warehouse systems use a calendar that is different from the normal one, for example, where a year is divided into four-week periods or 30 day Months or Quarters where Q1 starts in the middle of May. Some warehouses need weather information about days in order to do statistical analysis about the influence of the weather on, for example, their sales. In these cases a day has attributes or relationships of its own and should be modeled as entity DAY. About the slide See Page 26
Entity DAY
DAY # Date * Public Holiday Indicator
first day of starts on for TASK ASSIGNMENT * Duration in Hours of
TASK in # Id EMPLOYEE with # Name
5-5
The above model shows part of a planning system where tasks are assigned to employees. Tasks may take from a few hours to, at maximum, several days. Based on this model, table TASK_ASSIGNMENTS will contain a date column that is a foreign key column to the DAYS table. Date and Time As stated earlier, an Oracle DATE column always contains date and time. This needs some special attention as two DATE columns may apparently contain the same date but they are not equal because of a difference in their time component. While modeling, always make explicitly clear when time of the day is an issue, for instance, by naming the attribute DateTime. As soon as hours and minutes play a role, the concepts of time zone and daylight saving time may become important.
Modeling Changes Over Time .........................................................................................................................................
Modeling Changes Over Time

Date and Time in your models may substantially increase the complexity of your system, as the next example shows. The context for this example is that of an Embassy Information System, but could have been chosen from almost any business area. Embassy employees have an assignment for a country, but, of course, the assignments may change over time. Therefore, the model would need an entity ASSIGNMENT with a mandatory attribute Start Date and an optional End Date. Start Date is modeled as part of the UID for ASSIGNMENT. This means that the model allows an employee to have two assignments in the same country, as long as they start on different days. It also allows the employee to have two assignments that start on the same day, as long as these are for different countries. Suppose we know today that Jacqueline will switch from Chili to Morocco on the first of next month. This fact can be fed into the system immediately, by creating a new instance of ASSIGNMENT with a Start Date that is still in the future at create time. The future users will appreciate this kind of functionality.
EMPLOYEE # Id
of
COUNTRY # Name
in
for
as
ASSIGNMENT # Start Date o End Date
End Date Redundant? You may argue that attribute End Date of ASSIGNMENT is redundant because Jacquelines assignments follow each other: the End Date of Jacquelines assignment in Chili matches the Start Date of the one in Morocco. This may be true, but it does not take into consideration that embassy people may take a leave and return after a couple of years. In other words, if you do not model attribute End Date you ignore the possibility that the assigned periods of a person are not contiguous. Note that the model does allow an employee to have two assignments in, for example, Honduras, that overlap! The unique identifier does not protect the data against overlapping periods. Adding End Date to the UID does not help. You would need a whole series of extra constraints to cope with this.
......................................................................................................................................... 5-7
Countries Have a Life Cycle Too Suppose the Embassy Information System contains data that goes back to at least the late eighties. In those days the USSR and Zaire were still countries. Suppose there are ASSIGNMENTS that refer to the USSR and Zaire. In the case of Zaire, you could consider an update of the Name of the COUNTRY: Democratic Republic Congo is essentially just the new name for Zaire. In case of the USSR this would not make sense. There is not a new name for the old country. The old country simply ceased to exist when it broke into several countries. Although the concept of a country seems very stable, countries may change fundamentally during the lifetime of the information system. This leads to the next model. About the slide See Page 26
Even a Country Has a Life Cycle
EMPLOYEE # Id
of
COUNTRY # Name # Start Date * End Date

in
for
as
life cycle attributes
ASSIGNMENT # Start Date o End Date
5-7
Time-related Constraints Be aware of the numerous constraints that result from the time dimension! Here is a selection: An ASSIGNMENT may only refer to a COUNTRY that is valid at the Start Date of the ASSIGNMENT. The obvious one: End Date must be past Start Date. A business rule: ASSIGNMENT periods may not overlap. The Start Date of an ASSIGNMENT for an EMPLOYEE may not be between any Start Date and End Date of an other ASSIGNMENT for the same EMPLOYEE. As for the previous constraint, but for End Date.
Modeling Changes Over Time .........................................................................................................................................
You would probably not allow an ASSIGNMENT to be transferred to another COUNTRY, unless the ASSIGNMENT has not yet started, that is, the Start Date of the ASSIGNMENT is still in the future. This is an example of conditional nontransferability. For updates of the attribute Start Date here are some possible constraints: A Start Date of an ASSIGNMENT may be updated to a later date, unless this date is later then the End Date (if any) of the COUNTRY it refers to. A Start Date of an ASSIGNMENT may be updated to a later date, if the current Start Date is still in the future. A Start Date of an ASSIGNMENT may be updated to an earlier date, unless this date is earlier than the Start Date of the COUNTRY it refers to. A Start Date of an ASSIGNMENT may be updated to an earlier date, if this new date is still in the future. A Start Date of a COUNTRY may be updated to a later date, if there are no ASSIGNMENTS that would get disconnected. Similar constraints apply to attribute End Date. Referential Logic Note that, except for two, these constraints result from referential logic only. There may be more additional business constraints. Imagine the sheer number of constraints if a time-affected entity is related to several other time-affected entities! Fortunately, these constraints all have a similar pattern; these result from the referential, time related, logic. Not in Diagram You cannot model any of these constraints in the diagram as they all have to be listed separately. Implementation In an Oracle environment, one of these constraints can be implemented as a check constraint, (End Date must be later than Start Date). All the others will be implemented as database triggers.
......................................................................................................................................... 5-9
A Time Example: Prices

Products and Prices
PRODUCT # Id * Name
with of
PRICE * Price in $ # Start date o End Date
PRICE = PRICED PRODUCT= HISTORICAL PRICE
5-8
Products have a price. Prices change. Old prices are probably of interest. That leads to a model with entities PRODUCT and PRICE. The latter entity contains the prices and the time periods they are applicable. In real-life situations you find the concept of PRICE also named PRICED PRODUCT, HISTORICAL PRICE (and less appropriate: price list or price history); all these names more or less describe the concept. You may argue the need for an End Date attribute. If the various periods of a product price are contiguous, End Date is obsolete. If, on the other hand, the products are not always available, as in the fruit and vegetable market, the periods should have an explicit End Date.
A Time Example: Prices .........................................................................................................................................
Introducing Order Header and Order Item About the slide See Page 27
What Price to Pay?
be tw ee
PRODUCT # Id * Name
with of
referred by
n
ORDER HEADER # Id * Order Date

with of
PRICE * Price in $ # Start date o End Date
referring to
ORDER ITEM * Quantity Ordered
5-9
Here, entities ORDER HEADER and ORDER ITEM are introduced. An ORDER HEADER holds the information that applies to all items, like the Order Date and the relationship to the CUSTOMER that placed the order or the EMPLOYEE that handled it. (For clarity, these relationships are not drawn here.) The ORDER ITEM holds the Quantity Ordered and refers to the PRODUCT ordered. The price that must be paid can be found by matching the Order Date between Start Date and End Date of PRICE. Note that you cannot model this between relationship. This model is a fairly straightforward product pricing model and is often used. Order Note that the concept of an order in this model is composed of ORDER HEADER and ORDER ITEM. To find the order total for an order, it would need a join over four tables.
......................................................................................................................................... 5-11
Price List A variant on the above model is often used when prices as a group are usually changed at the same time. The period that prices are valid is the same for many prices; that would lead to this model:
Price List Search

between PRICE LIST # Id * Start Date o End Date
with on of
PRODUCT # Id * Name
with

referred by with
of
PRICED PRODUCT * Price in $
ORDER ITEM * Quantity referring Ordered

to
5-10
Entity PRICE LIST represents the set of prices for the various products; PRICED PRODUCT represents the price list items. To know the price paid for an ordered item, you take the Order Date of the ORDER HEADER, and take the PRICE LIST that is applicable at that date. Next, you go from ORDER ITEM to the PRODUCT that is referred to and from there to the PRICED PRODUCT of the PRICE LIST you have just found. To find the order total for an order, it would need a join over five tables.
Buying a PRODUCT or a PRICED PRODUCT? Another variant of a pricing model is shown here. About the slide See Page 27
Order for Priced Products
PRICE LIST # Id * Start Date o End Date

with on
PRODUCT # Id * Name
with of referred by

with
of
ORDER ITEM * Quantity referring Ordered

to
5-11
Here an ORDER ITEM refers directly to a PRICED PRODUCT. At create time of the ORDER ITEM the constraint is applied that the Order Date must mach the correct PRICE LIST period. To find the order total for an order now only requires three tables.
......................................................................................................................................... 5-13
Negotiated Prices
Negotiated Prices
PRICE LIST # Id * Start Date o End Date

with on
ORDER HEADER PRODUCT # Id # Id * Order Date * Name with referred by

with of
of
ORDER ITEM * Quantity Ordered referring * Negotiated Price

to
5-12
When prices are subject to negotiation, the model becomes simpler. Negotiated Price is now an attribute of entity ORDER ITEM; ORDER ITEM refers to PRODUCT. Every referential constraint can be modeled. This model may seem to hold derivable information, but this is not true. Even in the case that almost all Negotiated Prices are equal to the current product price, you have to model Negotiated Price at ORDER ITEM level, just because of the small chance of an exception. To find the order total you require only two tables. You can imagine that many analysts choose this variant of the model as a safeguard, even if there is nothing to negotiate at present.
Which Variant to Use and When? Typically, the model with the negotiated prices will occur where the number of ORDER ITEMS per ORDER HEADER is low, often just a single one, and where the value is high, as, for example, in the context of a used car business. You see ORDER ITEM referring to a PRODUCT most often in the situation where prices do not change frequently. The number of items per ORDER HEADER is often well over one, and the overall value limited. Typical examples are the fashion industry and grocery stores. The model with ORDER ITEM referring to PRICED PRODUCT is often used in businesses where prices often change, as in the fresh fruit and vegetable markets. Prices there may even change during the day. The model with attribute Current Price for a PRODUCT is typically the model for the supermarket environment where instant availability of prices at the checkouts is vital. As stated earlier, the best model for a particular context depends on functional needs. See more on this in the chapters on Denormalized Data and Design Considerations.
......................................................................................................................................... 5-15
Current Price
Current Prices
PRODUCT # Id * Name * Current Price
with old of

PRODUCT # Id * Name
with
PRODUCT # Id * Name * Current Price

with of
of
PRICE * Price in $ # Start Date * End Date
PRICE * Price in $ # Start Date o End Date
PRICE * Price in $ # Start date o End Date o Current Indicator
5-13
These models are variants on the PRODUCT-PRICE model you have seen before. In the left-hand model the 1:m relationship between PRODUCT and PRICE shows the real historical prices only. You can guess that only historical prices are kept because attribute End Date is mandatory; an additional constraint is that this value should always be in the past. The Current Price of a PRODUCT is represented as an attribute. This model does not have any redundancies. In many situations it would be a good design decision to keep the current product prices as well as the old prices in one table based on entity PRICE. The middle model is an ER representation of that situation. Note that End Date is now optional. The right-hand model is another model that contains a subtle redundancy. See more on this type of redundancy in the lesson on Denormalized Data.
Journalling .........................................................................................................................................
Journalling
When a system allows a user to modify or remove particular information, the question should arise if the old values must be kept on record. This is called logging or journalling. You will often encounter this when the information is of a financial nature. Consequences for the Model About the slide See Page 28
Journalling
by by
PAYMENT *Date Paid *Amount in $
to
PAYMENT o Date Paid * Amount in $

with of
to
AMOUNT MODIFICATION * Old Amount in $ * Modified by * Date Modification

5-14
A journal usually consists of both the modified value and the information about who did the modification and when it was done. This extra information can, of course, be expanded if you wish. Apart from the consequences for the conceptual data model, the system needs special journalling functionality: any business function that allows an update of Amount In should result in the requested update, plus the creation of an entity instance AMOUNT MODIFICATION with the proper values. Of course, the system would need special functions as well in order to do something with the logged data. No Journal Entity When several, or all, attributes of an entity need to be journalled, it is often implemented by maintaining a full shadow table that has the same columns as the original plus some extra to store information about the who, when, and what of the change. This table does not result from a separate entity; it is just a second, special, implementation of one and the same entity.
......................................................................................................................................... 5-17
Journalling Registers Only Note that logging does not prevent a user from making updates. Preventing updates entirely is a functional issue and is invisible in the conceptual data model. Be aware that preventing updates altogether would also block the possibility to change typos or other mistakes. At this stage, decisions must be made about the behavior of the system with respect to updates; sometimes this leads to modifications in the conceptual data model. For example, suppose that in a particular business context a certain group of users is allowed to create instances of PAYMENT but is not allowed to change them. Changes can only be made by, say, a financial manager. Suppose you just created a PAYMENT instance and you discover you made a mistake. For those cases the business would need some mechanism to stop the erroneous instance. One mechanism would be to ask one of the financial managers to make the change. A far better mechanism would be to add functionality so that a payment can be neutralized. This may be represented in the model as an attribute Neutralized Indicator that users can set to Yes.
Summary .........................................................................................................................................
Summary
Every update in a system means loss of information. To avoid that you can create your model to keep a history of the old situations. Sometimes relationships refer to a timedependent state of an entity. In other words, the updated entity is in fact a new instance of the entity and not an updated existing instance. If this is the case, the timedependent referential constraints cannot be modeled by a relationship only. Time in your model is a complicated issue. Many models have some time-related entities.
Summary
Consider the need for keeping old values. Time in your model is complicated:
Implicit versions References
Journalling
5-15
......................................................................................................................................... 5-19
Practice 51: Shift

Moonlight Coffees
Goal (See Page 29) The purpose of this practice is to model various aspects of time.
Scenario Some shops are open 24 hours a day, seven days a week. Others close at night. Employees work in shifts. Shifts are subject to local legislation. Below you see the shifts that are defined in one of the shops in Amsterdam. Your Assignment List the various date/time elements you find in this Shift scheme and make a conceptual data model.
Practice: Shift
Museumplein, Amsterdam, March 21 Shift Mon Tue Wed Thu Fri Sat/Sun 1 2 3 4 5
-
6:30 11:30 16:00 20:30 11:30 16:00 20:30 23:00 7:00 11:30 16:00 20:30 11:30 16:00 20:30 23:00 7:00 11:30 16:00 20:30 11:30 16:00 20:30 23:00 7:00 11:30 16:00 20:30 11:30 16:00 20:30 23:00 7:00 11:30 16:00 20:30 11:30 16:00 20:30 24:00
8:00 11:30 15:00 18:00 21:00 11:30 15:00 18:00 21:00 24:00
5-17
Practice 52: Strawberry Wafer .........................................................................................................................................
Practice 52: Strawberry Wafer

Moonlight Coffees
Scenario (See Page 29) You have modeled a price list in an earlier lesson. Now some new information is available.
Your Assignment Revisit your model and make changes, if necessary, given this extra information.
Prices are at the same level within a country; prices are determined by the Global Pricing Department. Usually the prices for regular, global products are re-established once a year. Prices and availability for local specialties are determined by the individual shops. For example, the famous Norwegian Vafler med Jordbr (a delicious wafer with fresh strawberries) is only available in summer. Its price depends on the current local market price of fresh strawberries.
SULMVOLMVW
qrFrrFrryrv $6rr irrxXri)ZZZPRRQOLJKWFRP
X U 7 s r v y p v
r i r r T %
klein gewone koffie 60 cappuccino 90 koffie verkeerd 75 speciale koffies 99 espresso 60 koffie van de dag 45 caffeine vrij 5 zwarte thees 60 vruchten thees 75 kruiden thees 80 dag thee 50 caffeine vrij 5 frisdranken 60 diverse sodas 60 mineraal water 75 appel taart brusselse wafel portie chocolade bonbons koekje van eigen deeg portie slagroom
middel 90 110 100 125 95 75 10 100 110 120 85 10 100 100 120
groot 120 140 130 150 110 100 15 120 130 140 100 15 130 130 140
toeslag
toeslag
180 150 150 120 30
5-19
......................................................................................................................................... 5-21
Practice 53: Bundles

Moonlight Coffees
Goal (See Page 30) The purpose of this practice is to expand the concept of an old entity.
Scenario As a test, Moonlight sells bundled products in some shops, for a special price. Here are some examples.
A SweetTreat(tm) consists of a large soft drink plus cake of the day. A BigBox(tm) consist of a large coffee of the day plus two cakes of the day. A SuperSweetTreat(tm) consists of a SweetTreat(tm) plus whipped cream (on the cake). A FamilyFeast(tm) consists of two BigBoxes(tm) plus two SweetTreats plus a small surprise.
Bundles sell very well; all kinds of new bundles are expected to come. The system should know how all these products are composed, in order to complete various calculations. Your Assignment 1 Modify the product part of the model in such a way that the desired calculations can be completed.
PRODUCT GROUP # Name

classification for
classified as
PRODUCT # Id * Name
Practice 53: Bundles .........................................................................................................................................
2 Change the model in such a way that it allows for:
A DecafPunch(tm) consists of a regular decaffeinated coffee or a regular decaffeinated tea, plus a blackberry muffin.
......................................................................................................................................... 5-23
Practice 54: Product Structure

Moonlight Coffees
Goal (See Page 30) The purpose of this practice is to model a hierarchical structure.
Scenario Moonlight needs to make sales information available as a tool to optimize its business. A hierarchical product structure is being developed to be able to report on different summary levels. This hierarchical structure should replace the single level product group classification. Below you see the current idea about a product structure. This structure is far from complete, but it should give you an idea of the shape the structure will take. The + signs mean that the structure will be expanded at that point. Your Assignment 1 Create a model for a product classification structure.
+ Products + Drinks + Coffees Regular Cappuccino Caf Latte + Special Coffee Teas + Black Chinese Indian English + Infusions + Herbal Soft drinks Juices Orange Grape + Waters + Sodas + Dairy Products +Foods + Pastry + Candy Bars + Local Specialties +Non Foods Merchandise CDs + Stationary Other + Tickets + Art
5-22
2 (Optional) How would you treat the bundled products?
Instructor Notes
Topic Lecture Practice Total Timings 15-20 minutes 45-100 minutes 60-120 minutes
5 5
M odelin g C h ange
Before you start with lesson 5 It is a good idea to summarize what you have covered so far. A nice way to do that is to create an ER model about the concepts they have seen: entities, attributes, relationships, unique identifiers, arcs. You will find this a very valuable activity. You may use ERSUMMARY.ppt that contains a build of the model. You find this in the PowerPoint presentation as a separate file.
O verview
D a te a n d tim e M o d e lin g c h an g e o ve r tim e P ric es ch an g e J o u rn allin g
5 -2
In many ways change (and therefore, time) is part of an ER model. This is often a hugely complicating factor. Suddenly you must be able to cope with information such as in her capacity as senior counsellor, Jane worked between April 95 and July97 for ABC Inc. that has been part of XYZ International since May 99. The difference between Day and Date is discussed as well as the need for an entity DAY. Various examples of modeling price changes are presented and discussed. Time in a model is a complication, but you do not have much choice other than to accept it. At the other hand, a well-designed time-related system can be very user friendly and functional, coping with simple things such as working in advance (like being able to enter a new price or code that will be effective as of tomorrow) to very complex calculations over periods of time.
C h ange an d Tim e
E ve ry u pd ate m ea n s lo ss o f in fo rm a tio n . T im e in yo u r m o d el m a ke s th e m o d e l m o re c o m p le x. T h e re are o fte n c o m p le x jo in c on d ition s. U s ers c an w o rk in a d van ce . W h e n do yo u m o de l da te/tim e a s an e n tity? W h a t c o n stra in ts d o a ris e ? H o w d o yo u h a n d le jo u rn a llin g ?
5 -3
......................................................................................................................................... 5-25
E ntity D A Y or A ttribu te D ate
P U R C H A SE
on
S ingle attribute entity w ithout m :1 rela tionships is usually repla ced by attribute
of
DAY # D a te
P U R C H AS E * D ate
5 -4
A date is the identifying attribute of entity DAY. When you can use a nice rich data type like Oracles DATE you do not need to worry about, for example, the weekday, month name, or quarter of a particular day. Choosing not to model this means you assume this will be available at implementation time. If not, you should model all these date-related pieces of information as separate entities and attributes! You need entity DAY when nonderivable attributes are needed, such as whether or not a day is a public holiday or a bank holiday. Many planning systems use a list of days, for instance to facilitate reporting on individual schedules.
Entity D A Y
DAY # D ate * P ublic Ho liday In dicato r
first day of starts on
T AS K A SS IG N M E N T * D ura tion in H ours
for in of w ith
TA S K # Id E M PL O Y EE # N am e
5 -5
M odelin g C h ange
E M P LO Y E E # Id
of
COUNTRY # N am e
in
for
as
A SS IG N M E N T # S tart D a te o E nd D a te
5 -6
Eve n a C oun try H as a L ife C y cle
E M P LO Y E E # Id
of
COUNTRY # N am e # Start Da te * E nd Da te
in
for
as
life cycle attribu tes
A SS IG N M E N T # S tart D a te o E nd D a te
5 -7
Be aware that because that particular things have not changed during your lifetime does not mean they will never change. Countries that cease to exist, currencies that change, telephone numbers that are no longer related to the physical hardware, are all examples of change that many systems did not foresee. Referential logic is only concerned with a reference to a record in another table, not with a reference to a valid record (according to some rule) in another table. This is why you need to make many extra checks in these situations.
P roduc ts a nd Pric es
PRODUCT # Id * N am e
w ith of
P R IC E * P rice in $ # Start date o E nd D ate
P RICE = P RICE D P R O D U C T = H IS TO R IC A L PR IC E
5 -8
The next few slides show all variants of product-price models. These are used here as a real-life metaphor of a time-related problem. Another name for the PRICE entity you run into quite often is PRICE HISTORY although this name is, strictly speaking, not correct (similar to using the name company for the table of employees). None of the time-related constraints can be modeled.
W h at P rice to Pay ?
w ith of
be
tw e
PR O D U C T # Id * N am e
referred by
en
O R D ER H EA D E R # Id * O rde r D ate
w ith of
P RICE * Price in $ # S tart da te o E nd Da te
referring to
O R D ER IT E M * Q u antity O rde red
5 -9
Price List S earch

b etw ee n P R IC E L IS T # Id * S tart D a te o E nd D ate
w ith on of referring to
w ith
O R D E R H E AD E R # Id * O rd er D a te
referred by w ith
of
P RICE D P R O D U C T * Price in $
O R D ER ITE M * Q uantity O rdere d
5 -1 0
O rd er fo r Priced Pro duc ts
P R IC E L IS T # Id * S tart D a te o E nd D ate
w ith on
w ith of referred by referring to
w ith
of
O R D ER ITE M * Q uantity O rdere d
Sometimes it makes sense to model things in such a way that you do not order a product but a priced product as it is called here. It is a different way of seeing the same thing happen. The consequence during implementation is different tables and different join conditions.
5 -1 1
N eg otiate d P rice s
P R IC E L IS T # Id * S tart D a te o E nd D ate
w ith on
w ith of
referred by w ith
of
referring to
O R D ER ITE M * Q u antity O rd ered * N eg otiate d P rice
5 -1 2
......................................................................................................................................... 5-27
C urrent Pric es
PR O DU C T # Id * Name * C u rre nt P rice
w ith old of
PR O D U C T # Id * N am e * C u rre nt P rice
w ith of
P RO DU CT # Id * Name
w ith
A few more models to be more or less complete. The last one is used in the lesson on Denormalized Data.
of
P RIC E * Price in $ # S ta rt D ate * En d D ate
P RIC E * Price in $ # S ta rt D ate o E nd D ate
P R IC E * P rice in $ # S tart date o E nd D ate o C urren t Ind icator
5 -1 3
J ourna llin g
by by
PAYMENT *D ate P aid *A m ou nt in $
to
P A YM E N T o D a te P aid * A m ou nt in $
w ith of
to
AMOUNT M O D IFIC A T IO N * O ld A m o unt in $ * M od ified b y * D ate M odification

5 -1 4
Journalling is often seen as a functional issue; with Oracle Designer it is very easy to get the general journalling done. However, if you only need partial journalling, it makes sense to explicitly model it. This allows you to describe constraints that apply (for example, only log when the amount is increased), and the desired functionalities and responsibilities.
Sum m ary
C o n s id er th e n e ed fo r k e ep in g o ld va lu e s. T im e in yo u r m o d el is co m p lic ated :
Im p lic it v ers io n s R e fere n ce s
J o u rn allin g
5 -1 5

Prac tices
S h ift S tra w b e rry W afer B u n d le s P ro d u ct S tru c tu re
Practice Shift Strawberry Wafer Bundles Product Structure
3day Yes Opt Cha Opt
4day Yes Cha Cha Cha
5 -1 6
Pra ctice : Sh ift

M useum plein, A m sterdam , M arch 2 1 S hift M on Tue W ed Thu Fri 1 2 3 4 5
-
6:30 11:3 0 1 6:00 20: 30 1 1:30 16:0 0 2 0:30 23: 00 7:00 11:3 0 1 6:00 20: 30 1 1:30 16:0 0 2 0:30 23: 00 7:00 11:3 0 1 6:00 20: 30 1 1:30 16:0 0 2 0:30 23: 00 7:00 11:3 0 1 6:00 20: 30 1 1:30 16:0 0 2 0:30 23: 00 7:00 11:3 0 1 6:00 20: 30 1 1:30 16:0 0 2 0:30 24: 00
Practice 5.1 Time and weekday here are both independent of date. The date at the top of the list, March 21, is probably a date, but could be a day without a year (such as the new schedule at the start of each new season).
S at/S un 1 1:30 15:0 0 1 8:00 21: 00 24 :00

5 -1 7
8:00 11:3 0 1 5:00 18: 00 21 :00
Prac tice: Straw berry W afer
P rices are at the sam e level w ithin a country; p rices are determ ine d b y the G lobal P ricing D epartm ent. U sually the prices for regular, g lobal products are re-established once a year. P rices and availability for local specialties are determ ined by the in dividual shops. For exam ple, the fam ous N orw egian V afler m ed J ordb r (a delicious w afe r w ith fresh straw berries) is only available in sum m er. Its price dep ends on the current lo cal m arket price of fresh straw berries.
5 -1 8
Practice 5.2 The global products and local products behave in the same way the same from a selling point of view but act differently from the perspective of pricing. This practice is again another variant of a pricing model, with a different method for the global and local prices. This price list is intentionally a version other than the one that was printed in practice 3.6. This implicitly describes something about currencies and language. The question arises if there are basic differences between the two lists, or if it is just a translation issue.
S ULMVOLMVW
qrFrrFrryrv
$6rr
i rrxX ri)ZZZP RRQOLJKWFRP
X U 7 s r v y p v
r i r r T %
klein gew one koffie 60 cappuccino 90 koffie verkeerd 75 speciale koffies 99 espresso 60 koffie van de dag 45 caffeine vrij 5 zw arte thees 60 vruchten thees 75 kruiden thees 80 dag thee 50 caffeine vrij 5 frisdranken 60 diverse sodas 60 m ineraal w ater 75 appel taart brusselse w afel portie chocolade bonbons koekje van eigen deeg portie slagroom
m iddel 90 110 100 125 95 75 10 100 110 120 85 10 100 100 120
groot 120 140 130 150 110 100 15 120 130 140 100 15 130 130 140
toeslag
toeslag
180 150 150 120 30
5 -1 9
......................................................................................................................................... 5-29
A Sw ee tT reat (tm ) c o n sists of a larg e so ft d rin k p lu s ca k e o f the d a y. A B ig B o x (tm ) co n s ist o f a la rg e co ffee o f th e d a y p lu s tw o ca ke s o f th e d a y. A S u p e rSw ee tT re at (tm ) c o n sists of a S w e etT re at (tm ) p lu s w h ip p e d crea m (o n th e c ak e). A F am ily F ea st (tm ) co n s is ts o f tw o B ig B o x es (tm ) p lu s tw o S w e e tT re ats p lu s a sm all su rp rise . A D ec afP un c h (tm ) co n s is ts o f a reg ular d eca ffein a te d c o ffee o r a re g u lar d ec affein a te d tea , plu s a b lac kb e rry m u ffin.
5 -2 0
Practice 5.3.1 This practice results in a model for a Bill of Material. Let the students sweat! Many will model a recursive relationship of PRODUCT or will have a separate BUNDLE entity. Why is this all incorrect? A product can be part of various bundles in different quantities (like cake of the day that occurs once in a StweetTreat and twice in a BigBox). An instance of BUNDLE can consist of other instances of BUNDLE (like a SuperSweetTreat), so BUNDLE should have a recursive relationship as well. Practice 5.3.2 This is a hard one. Modeling the or makes it much more complex. Do not let them spend too much time on this one.
+ P rod u cts + D rin ks + Co ffees R eg u la r C ap p uc cin o C af L atte + S p ec ia l C offe e T eas + B la ck Ch in ese Ind ian E n g lish + In fus io n s + H erb al S o ft d rin ks J u ic es O ra ng e G ra pe + W ate rs + S o d as + Dairy P ro du cts +Fo o d s + P astry + Can d y Ba rs + Lo ca l S p ec ia lties +No n F o od s M erch an dise C Ds + S ta tio n ary O the r + T icke ts + A rt
Practice Typical classification for desired decision support functionality. How did Herbal teas do it compared to Black teas? How did teas do it compared to coffees?
5 -2 2

Name: Full Email:
Content
Type
Page Number
Note
......................................................................................................................................... 5-31
Suggested Graphics
......................................................................................................................................... 5-33
fold here
6
.................................
Advanced Modeling Topics
Lesson 6: Advanced Modeling Topics .........................................................................................................................................
Introduction
Lesson Aim This lesson gives an overview of patterns you can discover in data models. This lesson introduces some generic models. You can use these to make your model withstand future changes that are predictable but not yet known. Objectives Schedule See Page 28 About the slide See Page 28
Overview
Patterns Drawing conventions Generic modeling
6-2
Topic Introduction Patterns Master Detail Basket Classification Hierarchy Chain Network Symmetric Relationships Roles Fan Trap
See Page 2 4 5 6 7 8 10 11 13 14 15
Introduction .........................................................................................................................................
Topic Data Warehouse Drawing Conventions Generic Modeling Generic Models Summary Practice 61: Patterns Practice 62: Data Warehouse Practice 63: Argos and Erats Practice 64: Synonym
See Page 16 17 19 20 23 24 25 26 27
At the end of this lesson, you should be able to do the following: Recognize common patterns in conceptual data models Know the general behavior, such as the common constraints, of these patterns Use particular drawing conventions Create a more generic model for selected sections of a conceptual data model
......................................................................................................................................... 6-3
Patterns
Similar Structure Many models contain parts that have a similar structure, although the context may be completely different. For example, the structure of a conceptual data model in the context of a dictionary that deals with concepts such as headword, entry, meaning, synonym is, surprisingly, almost identical to the structure of a railroad with track, station, connection, and also to the structure of a baseball or soccer competition. Easier to see are the similarities between, for example, ORDER HEADER with ORDER ITEM and QUOTATION HEADER with QUOTATION ITEM, or between MARRIAGE and JOB ASSIGNMENT.
Similar structure Similar rules and constraints?
Why Search for Similarities? The main reason why it is important to look for similarities is that it will save you time. If you have solved a problem in a particular context and you can apply the solution to another, it obviously saves time. Moreover, you will feel confident that you know about the situation. It will help you to ask the right questions. It will help you identify the really complex and unpleasant things and will prevent you from making the same mistakes twice. Are there similarities between marriage and job assignment? Of course, the business rules in the context of a marriage are different, because they are determined differently compared to those of a job assignment. But when you are aware of the similarities, you can easily check if business rules of the first context apply in the second, by asking, for example: Can an assignment be for more than one job? Can someone have two assignments simultaneously? Unofficially? How does an assignment start? How does it end? The following paragraphs discuss a series of patterns that you will encounter while creating your models. For all these patterns you will see the characteristics and the rules that usually apply.
Master Detail .........................................................................................................................................
Master Detail
Patterns: MasterDetail
A
consists of part of

6-3
Characteristic: consists of An instance of B only exists in the context of an A Metaphor: MasterDetail
Master-detail constructions are very common, as 1:m relationships are very common. Distinguish between a 1:m relationship that is typically directed from the 1 to the many and a relationship that is directed the other way around (see below). Masterdetail is characterized by the fact that the master A is divided into Bs. Bs do not exist alone; they are always in the context of an A. It is very rare that these relationships are transferable; if an instance of B is connected to the wrong instance of A, it is far more likely that the instance of B is deleted and then recreated in the context of the correct A. Typical master-detail relationship names: Consists of Divided into Made of (Exists) With Often a master A is of no value when it has no Bs, for example, the relationship is mandatory at the 1 side. This mandatory relationship end can usually be circumvented, as you have seen before. Implementation The tables that come from this master-detail pattern should be considered as clustered.
......................................................................................................................................... 6-5
Basket
Pattern: Basket
A X
consists of part of
A B
X Y Z
Y Z

6-4
Characteristic: container for various types of items Items may be of different types Metaphor: Shopping Basket
A basket construction is a special case of a master-detail pattern. A basket can contain one or more things, but these things (often named: items) can be of different types. A single item is always of one type only. That is the reason for the arc. The arc shows that an item must be of one and only one of the types.
Classification .........................................................................................................................................
Classification
Patterns: Classification
Q
classifying classified by

6-5
Characteristic: classified by, grouped by Q exists independently, may be related Metaphor: EMPLOYEEDEPARTMENT
This is again a 1:m relationship, but now the main orientation is from P to Q. This is typically the case when Q can exist independently from P. Q acts as a class for P, something with which to group Ps. Usually entities in a conceptual data model have several of these classes. Typical classification-type relationship names: Classified by Grouped by Assigned to (Exists) In The relationship is usually transferable as classifications may change over time.
......................................................................................................................................... 6-7
Hierarchy
Patterns: Hierarchy
A # Id

6-6
Characteristic: manager of / subordinate of Additional constraints to guard hierarchical nature Metaphor: MotherChild
Most hierarchical structures have a known limit for the maximum number of levels. If that is the case and the limit is a low number of 5, for example, then usually the best model is the one that is shown in the left of the illustration, one entity per level. Model the structure with the recursive relationship if: The structure has no known level limit. The structure has a level limit, but the limit is high, say six or more. An instance of the structure can easily have a change of position, thus changing its level. You like maintaining constraints. Disputable or False Hierarchies Often structures should be hierarchical but you cannot be sure. Sometimes they seem hierarchical but actually are not so. You can have, for example, the is owner of relationship between companies. Suppose company C1 owns company C2, company C2 owns company C3, could it be that company C3 owns the shares of company C1? Even if legislation would prohibit such strange constructions, would you be sure? Many people see the parent/child relationship as a metaphor for a hierarchical relationship. Clearly this is wrong as a child usually has two parents and can have stepparents as well.
Hierarchy .........................................................................................................................................
Also the hierarchical structure of a FILE SYSTEM with files and folders, which are files of a particular type, is a disputable hierarchy when you think of the concept of a shortcut in Windows (or a Link in UNIX). These shortcuts transform the hierarchy conceptually into a network although technically a shortcut and a link are just files with a special role. Recursive Relationship and Optionality Recursive relationships that describe a real hierarchy are usually optional at both ends, as the hierarchy must start or end somewhere. Constraints Applying to a Hierarchy The recursive model, as you see in the centre of the illustration, only requires an instance of A to refer to a valid instance of A. A1 referring to A1 is fine, according to the model. A2 referring to A3 and A3 referring to A2 is fine as well. These are the only obvious diversions from a real hierarchy. Constraints that apply in a hierarchical structure deal with safeguarding the hierarchy and should prevent the table from containing the above kind of data. Implementation The first constraint, A1 may not refer to A1, and you can easily check this with an Oracle check constraint. The others need some programming and lead to database triggers. Possibly you may have to check extra business rules, for example, when the number of levels may not exceed a given value.
......................................................................................................................................... 6-9
Chain
Patterns: Chain
preceded by
B
BEAD # Id
followed by A
CHAIN
BEAD # Seqno

6-7
Characteristic: preceded by / followed by Sequence is important Metaphor: Elephants
A Chain (of beads) can be regarded as a special kind of hierarchy. A chain is a recursive relationship of an entity. The relationship of the chain is a 1:1 relationship as a chain is characterized by the fact that an object in the chain is preceded and followed by one object at most. A chain is a structure where sequence is of importance, for example, the sequence of the pages in a chapter and of the chapters in a document, of the critical path in a procedure, of the preferred road from A to B. A chain can also be modeled as a master-detail. The recursive model allows an easy insertion in the chain. The right-hand model with entity CHAIN and BEAD may need to change the sequence numbers of all the beads behind the inserted one.
Network .........................................................................................................................................
Network
Patterns: Network
A A A

6-8
Characteristic: pairs Every A can be connected to every A (sometimes: to every other A) Metaphor: Web Document with Hyperlinks
Network structures typically describe pairs of things of the same type, for example, marriage, railroad track (pair of start and end stations), synonyms (two words with the same meaning), and Web documents with hyperlinks to other Web documents. Characteristics Often: The m:m relationship must be resolved to hold specific information about the pair such as the date of the marriage, or the length of the railroad track. The two relationships of the intersection entity form the unique identifier. Time-related constraints apply in networks that must guard, for example, the kind of rules that deal with sequentially monogamous. The two relationships refer to different subtypes of the entity:
Note that a hierarchy is a network where a particular set of business rules apply.
......................................................................................................................................... 6-11
Bill of Material A special example of a network structure is a Bill of Material (BOM). A BOM describes the way things are composed of other things, and how many of these other things (here it is instances of PRODUCT) are needed. Entity COMPOSITION is the intersection entity with attribute Quantity Needed. About the slide See Page 29
Bill of Material
product of with part in in
PRODUCT # Code
COMPOSITION * Quantity Needed
PRODUCTS
Code 914.53 914.54 914.55 914.56 Name AAAAAAAAA AA BBBBBBBBB CCCCCCC DDDDD
COMPOSITIONS
Prod_code 854.01 854.01 854.01 914.54 914.54 934.76 Part_code Quantity 604.18 1 604.19 1 914.54 2 914.55 1 914.56 1 915.12 3
6-10
854.01
914.54
914.54
604.18
914.55 914.56
604.19
6-11
Symmetric Relationships .........................................................................................................................................
Symmetric Relationships
Symmetric recursive relationships cause a very special kind of problem which is more complex than you would assume. In most contexts a record of a pair (A1, A2) has a different meaning when referred to as (A2, A1). For example, if the model is about entity PERSON and the relationship is mother of /daughter of, then the existence of person pair (P1, P2) would mean the exclusion of the possibility of pair (P2, P1). The recursive relationship of PERSON and family of / family of. Here, if (P1, P2) is true, then (P2, P1) is equally true. This is called a symmetric relationship. There are other symmetric recursive relationships such as: STATION directly connected by rail with STATION, Symmetric Relationships: Problem When in a symmetric relationship the pair (S1, S2) is valid, the pair (S2, S1) must be valid as well. Nevertheless, it would not make much sense to record both pairs as that would essentially store the same information twicewhich would oppose one of the basic principles of database design. But if we record only one pair, which should we record? And how would you know which of the two pairs was used if someone else had recorded it? Symmetric Relationships: Solution A way which is often used to model these symmetric situations is based on the following idea: think of (S1, S2) as Group1, (S3, S4) as Group2 and so on. Looking at the relationship this way, you can say that a GROUP always consists of exactly two instances of S. The model and the table implementation are shown below. About the slide See Page 30
GROUP # Id
consists of 2 in
S
Group_id 1 1 2 2 3 3
S S1 S2 S3 S4 S5 S6
......................................................................................................................................... 6-13
Roles
Patterns: Roles
P

6-13
Characteristic: is / is 1:m (or 1:1) relationships Metaphor: PersonMany Hats (not necessarily concurrent...)
Roles often occur when a system needs to know more about people than the basic Name/Address/City information. Modeling the roles as separate entities offers the possibility to show which attributes are mandatory for a particular role, and, if necessary, to show relationships between the various roles. The example below shows that a person in their role as president of a country can appoint a person in the role of minister of a department. Possibly the words presidency and ministership are closer to the concepts than the ones in the diagram.
PERSON ROLE TYPE
roles
PERSON PRESIDENT
ROLE
COUNTRY
appointing appointed by
MINISTER PARTY LEADER DEPARTMENT PARTY
Fan Trap .........................................................................................................................................
Fan Trap
Fan Trap
A C B
A AB AC BC B
Characteristic: ring of m:m related entities Metaphor: ABC Combination
6-15
A Fan Trap (named after the characteristic shape of the solution) occurs when three or more entities are related through m:m relationships and form a ring. Usually you should replace the relationships with a central entity having several m:1 relationships. Preventing a fan trap is similar to resolving a m:m relationship between two entities. Why Traps Occur Resolving the three m:m relationships results into three intersection entities, AB, BC and AC. These will contain related pairs. Joining AB and BC may, however, result in different information to what AC contains which you may have seen in practice 3-8. Note there are various ways of avoiding the trap, as is shown in the illustration. All can be correct, depending on the context. About the slide See Page 31
AB
BC
ABC
ABC
ABC
......................................................................................................................................... 6-15
Data Warehouse
About the slide
Patterns: Data Warehouse

B A F X E C D
July
See Page 31 Practice See Page 31 This is a suitable place to do practices 6-1.

6-17
Characteristic: multidimensional, many, many detail instances Metaphor: star model Stars may be strangely shaped: Snowflake model
A data warehouse system can be modeled as any system. Data warehouses contain the same sort of information as any straightforward transaction processing information system. Data warehouses usually contain less detailed, summarized, information as warehouses are mainly built for overview and statistical analysis. However, Data warehouses in general receive the input from online transaction systems that do contain details. Data warehouses often have a star-shaped model: this is made up of one central entity (the facts) containing the condensed, summarized, information, and several dimensions that classify and group the details. Common dimensions represent entities such as: Time Geography Actor (for example, salesperson, patient, customer, instructor) Product (for example, article, medical treatment, course) Often the dimensions are classified as well. Time may be structured in day, week, month, quarter, year. You can classify products in various ways as you have seen in earlier examples. If this is the case, the model is usually described as the Snowflake model, as it looks like the crystal shape of a snowflake.
Drawing Conventions .........................................................................................................................................
Drawing Conventions
Drawing Conventions
high volumes
high volumes
Not important which convention you choose, as long as you follow one of them
6-18
Two drawing conventions are widely in use: one that positions the entities with the high volumes at the top of the paper and one that does the opposite. Both try to avoid crossing relationship lines, partially overlapping entities, and relationship lines that cross entities. Whatever convention you choose, choose one and use it consistently. This will prevent errors and make the reading of large diagrams much easier. Keep the overall structure of the layout unchanged during the modeling project as many people are disoriented when you change the structure. Make separate diagrams for every business area. These may have a different layout; these diagrams are mainly used for communication with subject matter experts. At the end of this course, you should be able to read models created in any drawing convention, and you should be able to complete a model following any convention used.
......................................................................................................................................... 6-17
Use Conventions Sensibly
But: Readability first
The major goal of creating the diagram (but not the model) is to give a representation of the model that can be used for communication purposes. This means that you must never let a convention interfere with readability and clarity. Do not be concerned that readability takes space. Usually an entity model is represented by several diagrams that show only the entities and relationships that deal with a particular functional part of the future system. Splitting the model over various diagrams adds to the readability. About the slide See Page 32 B
Model Readability
A B C E D F D E C A

6-20
Takes space Subject to taste
Generic Modeling .........................................................................................................................................
Generic Modeling
Generic Modeling
MANUFACTURER * Name MANUFACTURER * Name ARTICLE TYPE
FILM * AsaTRIPOD * Height LENS CAMERA * Focal BODY Distance * Weight
ARTICLE o Weight o Focal Distance o Height o Asa Number o ...
6-21
What is Generic Modeling? Generic modeling is looking at the same context from another, more distant perspective. From a distance many things looks the same. Suppose you are to make a model for a photographers shop. The business typically sells many different articles, for example, camera bodies, compact cameras, lenses, films. For each type of article, there are between, say, 10 and 500 different types. You can model every type as an entity, for example, CAMERA BODY, LENS, FILM. You could also model them all as subtypes of the entity ARTICLE, or all as just ARTICLE, without the subtypes. This, however, would not work. For example, there is the fact that every now and then new kinds of articles are stocked in the shop. Every time this happens it leads to a new entity with its own attributes in the model. The model with entity ARTICLE would only be a workable model if there were no (or possibly only very few) new instances of ARTICLE TYPE during the life cycle of the system.
......................................................................................................................................... 6-19
Generic Models
More generic models are shown below. They may be useful in particular situations.
ARTICLE TYPE * Definition Prop1 o Definition Prop2 o Definition Prop3 o Definition Prop4 ...
MANUFACTURER * Name
ARTICLE o Property1 o Property2 o Property3 o Property4 o Property5 o Property6 o Property7 o Property8
Recycling of Attributes You can use this model if it is safe to assume the articles will have a limited number of attributes. This limit may be a high number but must be set beforehand. Property1 may contain the Asa Number for instances of ARTICLE of TYPE Film and may contain Weight for instances of ARTICLE of TYPE Camera Body and so on. The major advantage of this model is the possibility of adding new instances of ARTICLE TYPE without the need to change the model. The type of information that should be entered for Property1, Property2, and so on can be described by using, for example, the Definition Prop1, attributes of ARTICLE TYPE. Here you can also store information about the data type of these properties. About the slide See Page 32
ARTICLE TYPE
ARTICLE
PROPERTY
ARTICLE PROPERTY VALUE o Value
Attributes Modeled as PROPERTY Instance This model takes another approach. Every value for a PROPERTY of an ARTICLE is stored separately. This model gives a lot of freedom to define new articles and properties during the life cycle of the system.
More Generic Models .........................................................................................................................................
More Generic Models

Everything is a Thing The world is full of things that may be related to things:
having some kind of relationship with
THING
having some kind of relationship with
Resolving the m:m relationship:
THING ASSOCIATION
Now add some definition information: About the slide See Page 33
THING TYPE ASSOCIATION TYPE
THING ASSOCIATION
6-26
This is a rather generic model. In fact, it is a model of the universe and beyond. Note that the number of attributes for entity THING may be substantial.
......................................................................................................................................... 6-21
Most Generic Model

THING TYPE ASSOCIATION TYPE
THING
ASSOCIATION PROPERTY
THING PROPERTY VALUE
6-27
This model combines the concepts of thing and the property/property value and thus allows everything to be represented with a free number of properties per type. Value of Generic Modeling The use of generic modeling is mainly to reduce to a minimum the number of possible future changes of the conceptual data model. This can be an enormous advantage as it cuts maintenance costs during the lifetime of a system. The other side of the coin is that the initial coding of the programs is more complex as the entities are not downto-earth things. Best of Two Worlds In many models you would use a mix of the easy-to-understand, straightforward entities and the more generic thing-like entities.
CUSTOMER
generic
ARTICLE TYPE
ORDER HEADER
ARTICLE
ORDER ITEM
PROPERTY
down to earth
ARTICLE PROPERTY VALUE
Summary .........................................................................................................................................
Summary
Summary
Patterns
Show similarities Invent your wheel only once
Generic models
Reduce the number of entities dramatically Are more complex to implement Are very flexible Are usually the best choice in unstable situations
6-29
Thinking in terms of patterns forms a valuable way of doing quality checks on a conceptual data model. Often constraints and considerations in one context can be transferred to the other context with a simple translation. Using a drawing convention in your models helps to improve readability and clarity. This may prevent mistakes and inaccuracies. Generic modeling can prevent the need to change data structures in the future and can reduce the number of tables and programs dramatically. The price is increased complexity in both data model and programs.
......................................................................................................................................... 6-23
Practice 61: Patterns

Goal (See Page 31) The purpose of this practice is to predict the main pattern in a given context. Your Assignment What pattern do you expect to find in the given contexts? If you do not see it, make a quick sketch of the model. Use your imagination and common sense.
Practice: Patterns
Model of moves in a chess game Model of tenders (quotations) Model of recipes Model of all people involved in college: students, teachers, parents, Rentals in a video shop Model of phases in a process
6-31
Practice 62: Data Warehouse .........................................................................................................................................
Practice 62: Data Warehouse

Moonlight Coffees
Goal (See Page 34) In this practice you create a conceptual data model for a data warehouse for Moonlight Coffees Inc.
Scenario Moonlight wants to build a data warehouse based on the detailed sales figures the shops report back on a daily basis. Examples of questions Moonlight wants the data warehouse to answer are printed below.
What is the sales volume in $ of coffee last month compared with the coffee sales volume same month last year? What is the sales volume in $ of coffee per head in Japan compared with the average coffee sales volume in the Moonlight countries around the world? What is the growth of the sales volume in $ of coffee in Sweden compared with the growth of sales volume of all products in the same geographical area? What is the growth in local currency? What was the total sales volume in $ of coffee last month, compared with the total coffee sales volume in the same month last year, for the shops that have been open for at least 18 months? What is the growth of the sales volume in $ of nonfoods compared to that of foods? What is the best day of the week for total sales in the various countries? How is that related to the average? Is the best day of the week dependent on the type of location? What products are most profitable per country? Globally? Does the service level (#employees per 1000 items sold) have influence on sales?
6-32
Your Assignment 1 Check the Moonlight models you created so far. Do they cater for answering the listed questions. If not, make the appropriate changes. 2 For a data warehouse data model, suggest the central facts entity.
......................................................................................................................................... 6-25
Practice 63: Argos and Erats

Goal (See Page 35) When you model information, you make a lot of assumptions, often without being aware of this. Most of these assumptions are likely to be correct as they are usually based on experience in similar contexts or common. This practice helps to increase your awareness of this. Scenario The scenario for this practice is Stranger in a Strange Land. Lost in Darkness. The Wanderer in the Mist. You name it! Your Assignment Make a conceptual data model based on the information in the text. Mark all the pieces in the diagram that can be confirmed from the text.
"Erats have names that are unique. Erats can have argos. Argos have names as well. The name of an argo must be unique within the erat it belongs to. Erats mutually have rondels. There are only a few different types of rondels. Erats can have one or more ubins. A ubin always consists of one or more argos of the erat, one or more rondels of the erat, or combinations of the two."
Practice 64: Synonym .........................................................................................................................................
Practice 64: Synonym

Scenario (See Page 35) A synonym is, according to a dictionary, a word having the same meaning with another (usually almost the same). Examples:
practice order entity order
- exercise - command - being - sequence
order - arrangement command - demand
Your Assignment Make a conceptual data model that could be the basis for a dictionary of synonyms.
......................................................................................................................................... 6-27
Instructor Notes
Instructor Note Topic Timings Lecture 30 minutes Practice 30-60minutes Total 60-90 minutes
6 6
A dva nced M od eling T opics
O verview
Some of the patterns in this chapter have only been touched in the practices.
P atte rn s D ra w in g c o n ve n tio n s G en e ric m o d elin g
6 -2
P atte rn s: M aster D etail

A
consists of part of
Very common pattern. In object modeling there is a special name for this relationship: an aggregation. Do not use parent/child as metaphor as this is a false one.

6 -3
C h arac te ristic: c o n sists of A n in stan c e o f B o n ly e x ists in th e co n tex t o f an A M eta p h o r: M a s te r D etail
Pattern: B as ket
A X
consists of part of
A B
X Y Z
Y Z
Special case of Master-Detail. Note not only different products in the basket, but also different types of products. Here: groceries and a clock.

6 -4
C h arac te ristic: ris tic: co n tain r fo rv ariou on ta in e er for va rio u s typ es e s o f item ite m s Ite m s m ay b e o f d iffere n t ty p es Item iffe ren pe s M eta p h o r: S h o p p in g B a sk et ph as ke t
Patterns: C lass ific ation

Q
classifying classified by

6 -5
Ch a ra cteristic : cla s sifie d b y, g ro u p ed b y Q e xis ts in d ep e nd e n tly, m a y be re la te d M e ta p h o r: E M P LO Y E E D E P A R T M E N T
Patterns: H ierarchy
A # Id

6 -6
C h arac te ris tic: m a n ag e r o f / s u b o rd in a te o f A d d itio n al co n s traints to g u ard hiera rc h ica l na tu re M eta ph o r: M o th er C h ild
Many people think a hierarchy is equivalent to a recursive 1:m relationship. This is not true. A hierarchy has many internal rules (such as you cannot be your boss boss) which are not represented by the recursive relationship. Do not use parent/child as a metaphor as this is a false one. A Chain is a special case of a hierarchy and a special case of a network as well.
P atte rn s: C hain
preceded by
B
B EA D # Id
follow e d by A
C H A IN
B E AD # Se qno

6 -7
C h arac te ris tic: p re ce d ed b y / fo llo w e d b y S e q u en c e is im p o rtan t M eta ph o r: E le p h an ts
Very common structure.

P atte rns: N etw o rk
A A A

6 -8
Ch a ra cteristic : p airs E ve ry A c an b e c on ne cte d to ev ery A (s o m etim es : to eve ry o th er A ) M e ta p h o r: W eb D o c u m en t w ith H y p erlin k s
Very powerful structure.

B ill of M aterial
product of w ith part in in
PRODUCT # C ode
C O M P O S IT IO N * Q uan tity N ee ded
PR P R O DU D UC T S
C ode 914.53 914.54 914.55 914.56 N am e AAAAAAAAA AA BBBBBBBBB CCCCCCC DDDDD
C O M P O S ITIO N S
P rod_code 854.01 854.01 854.01 914.54 914.54 934.76 P art_code Q uantity 604.18 1 604.19 1 914.54 2 914.55 1 914.56 1 915.12 3
6 -1 0
......................................................................................................................................... 6-29
854.0 1 854.01
The data in the table in the previous illustration match the information given in this picture.
914.54 914.54 91 4.54
60 4.18 604.18
914.55 914.56
604.19
6 -1 1
Sy m m e tric R elationsh ip
GROUP # Id
c onsists of 2 consists in
S
G ro up_ id 1 1 2 2 3 3
S S1 S2 S3 S4 S5 S6
This is a complex notion that you may run into every now and then. Other examples: Alternative for Synonym for (see practice)
6 -1 2
Patterns: R o les
P
Most often the role model is used when subtyping does not work due to overlap in the roles. In this example a president may have been minister or party leader.

6 -1 3
Ch a ra cteristic : is / is 1 :m (o r 1 :1 ) relatio n s h ip s M e tap h o r: P ers o n M an y H ats (n o t n e ce ss arily co n c u rren t...)
R oles
P ER S O N R O LE TY PE
roles
PERSON P R E S ID E N T
R O LE
C O U N TR Y
a ppointing ap pointed by
M IN IS TE R P A R TY LE A D E R D E P A R TM E N T P A R TY
The PERSON-ROLE-ROLE TYPE model uses ROLE as a supertype for all possible roles. This model is very useful if the variety of roles may change during the life cycle of the system. Refer to the section on generic modeling for more on this.
6 -1 4
F an T rap
A C B
A AB AC BC B
Fan trap is the subject of practice 3-8 Holiday and possibly in individual solutions to other practices. This trap is always near.
Ch a ra cteristic : rin g o f m :m related e n tities M e ta p h o r: A B C C om b in a tio n
6 -1 5
Fan Trap R eso lve d
AB
BC
ABC
ABC
ABC
A B fu nc tio n s a s lis t o f v alue s

6 -1 6
B C fu n ctio n s as lis t o f va lu es
An example where the left and right model make sense: A: Translation Agency B: Language C: Translator AB combines the available languages at an agency. BC combines the available languages per translator. A data warehouse usually has the fact/ dimensions structure that is represented by the star or snowflake model.
P atte rns: D ata W a rehou se

B A F X E C D
July

6 -1 7
C h arac te ristic: m u ltid im e n sio n a l, m an y , m a n y d e ta il in sta n ce s M eta p h o r: star m o d e l S ta rs m a y b e s tran g ely s h ap e d : S n ow flak e m o d el
Good practice to do jointly as a whole group.

Prac tice: Patterns
M o d e l o f m o ve s in a c he s s g a m e M o d e l o f ten d e rs (q u o tatio n s ) M o d e l o f re cip e s M o d e l o f all p e o ple in vo lved in c o lle g e: s tu d e n ts , tea ch ers , pa re n ts , R e nta ls in a v id eo s h o p M o d e l o f p h as es in a p ro c es s
6 -3 1
D raw in g C onv entions
high volum es
high v olum es
N o t im p o rta nt w hich co n v en tio n y o u ch o o s e, as lon g as y ou fo llo w o n e o f th e m

6 -1 8
The main message should be: It does not matter what convention you use as long as you use one. Note that the conventions apply mainly to the diagrams you make for your own and your teams understanding. Diagrams for the individual business areas may use a different layout as these diagrams are supposed to communicate with the subject matter experts.
......................................................................................................................................... 6-31
U se C o nven tions S ensibly
Bu t: Re a da b ility firs t
6 -1 9
M ode l R e ada bility

A B C E D F C E A B
The right-hand model requires less careful reading and is therefore more accessible.

6 -2 0
T ak es s pa c e S u b je ct to tas te
G ene ric M odeling

M A N U FA C TU R E R * N am e M A N U F A C TU R E R * N am e A R TIC LE TY P E
FILM * A sa TR IP O D * H eight LE N S CAM ERA * Focal BOD Y D istance * W eight
A R TIC LE o W eight o Focal D istance o H eight o A sa N um ber o ...
6 -2 1
G ene ric M odeling
A R TIC LE TY P E * D efinition P rop 1 o D efinition P ro p2 o D efinition P rop 3 o D efinition P ro p4 ...
M A N U FA C TU R E R * N am e
A R TIC LE o P roperty1 o P roperty2 o P roperty3 o P roperty4 o P roperty5 o P roperty6 o P roperty7 o P roperty8
This model works when the number of properties per article type is limited. In Oracle Designer, the User Defined Objects make use of this concept.
6 -2 2
G en eric M odel
A R TIC LE T Y P E
A R TIC LE
P R O P E R TY
A R TIC LE P R O P E R TY V A LU E o V alue
Expensive, but very flexible. A single column value in a normal table is now stored as row in the table based on ARTICLE PROPERTY VALUE. Searching for articles using some property value is much more complex using this structure.
6 -2 3
G en eric
h aving som e kind of having relationship w ith
TH IN G
having som e kin d of kind relationship w ith
6 -2 4
M ore G ene ric
TH IN G A S S O C IA TIO N
6 -2 5
M ore G eneric Plu s
This used to be the internal model for Oracle Designer. Views based on this model showed the actual object types.
TH IN G TY P E
A S S O C IA TIO N TY P E
TH IN G A S S O C IA TIO N
6 -2 6
M ost G ene ric?

TH IN G TY P E A S S O C IA TIO N TY P E
T H IN G
A S S O C IA TIO N P R O P E R TY
TH IN G P R O P E R TY V A LU E
6 -2 7
B es t of T w o W o rlds
C U S TO M E R
generic
A R TIC LE TY P E
ORDER HEADER
A RT R T IC LE
O R D E R ITE M
P R O P E R TY
Many real-life systems combine generic and down-to-earth structures. Generic modeling is not better than down-toearth modeling, nor the other way around. Both have advantages.
dow n to ea rth
6 -2 8
A R TIC LE P R O P E R TY V A LU L UE
......................................................................................................................................... 6-33
Sum m ary
P atte rn s
S h o w s im ilarities In ve n t yo u r w h ee l o n ly o n c e R e d u ce th e nu m b er o f e n tities d ra m atic ally A re m ore c o m p le x to im p le m en t A re v ery fle xible A re u s u ally th e b es t ch o ic e in u n s ta b le s itu atio n s
G en e ric m o d els
6 -2 9

Prac tices
P atte rn s D a ta W are h o u se A rg o s an d E ra ts S yn o n y m
Practice Patterns Data Warehouse Argos and Erats Synonyms
3day Yes Opt Cha Opt
4day Yes Yes Cha Cha
6 -3 0
W hat is the sa les volum e in $ of c offee last m onth co m pared w ith the coffee sa les volum e sam e m onth la st year? W hat is the sa les volum e in $ of c offee per head in Ja pan com pared w ith the ave rage coffee sales v olum e in the M oon light countries around th e w orld? W hat is the grow th of the sales vo lum e in $ of coffee in S w eden com pared w ith the gro w th of sales volum e of all products in the sa m e geographical are a? W hat is the gro w th in local currenc y? W hat w as the total sales volum e in $ of coffee last m onth, com pared w ith the to tal coffee sales volum e in the sam e m onth last yea r, for the shops that have been open for at least 18 m onths? W hat is the grow th of the sales vo lum e in $ of nonfoo ds com pared to tha t of foods? W hat is the be st day of the w eek for total sales in the various countries? H ow is that related to the average ? Is the best day of the w eek dependen t on the type of loc ation? W hat products are m ost profitable per country? G lob ally? D oes the serv ice level (#em ploye es per 1000 item s s old) have influence o n sales?
6 -3 2
... coffee per head in Japan... leads to an attribute population per country. The other pieces of information were probably already found in an earlier stage.
P ractice: A rg os and E rats
"E rats have nam es th at are u nique . E rats can have arg os. Argos h ave nam es a s w ell. Th e n am e of an argo m ust be uniq ue w ithin the erat it be longs to. E rats m utua lly have ron dels. There a re o nly a few differen t typ es of ron dels. Erats can h ave one or m ore ubin s. A ubin alw ays consists o f on e o r m ore argos of th e erat, o ne o r m ore ron dels o f th e era t, o r com b inatio ns of the tw o."
6 -3 3
This is a very difficult practice and clearly shows how much of your own interpretation you would usually use when you make a model. Here interpretation is impossible as the central concepts are nonsense words. When people were asked to model the original text it seemed much easier; many things that you cannot really tell from the text were assumed, and nobody noticed this! (For your eyes only: the text is a summary of entity modeling, read entity for erat, attribute for argo, relationship for rondel and uid for ubin and immediately it falls into place!) Synonym itself is not an entity, although most analysts will start with it. A synonym leads to a symmetric relationship: if two or more words share the same meaning then apparently a synonym exists.
Prac tice: Syn ony m
p rac tice o rd er en tity
- e xe rc ise - com m and - b e in g
o rd er - s eq u e n ce o rd er - a rra n g em en t co m m a n d - de m a n d
6 -3 4
......................................................................................................................................... 6-35

Name: Full Email:
Content
Type
Page Number
Note
......................................................................................................................................... 6-37
Suggested Graphics
......................................................................................................................................... 6-39
fold here
7
.................................
Mapping the ER Model
Lesson 7: Mapping the ER Model .....................................................................................................................................................
Introduction
Lesson Aim This lesson describes some principles of relational databases and presents the various techniques that can be used to transform your Entity Relationship model into a physical database design.
Overview
Schedule See Page 34 About the slide See Page 34
Why use design modeling? Introduction to the components:
Tables Columns Constraints
Basic Mapping Complex mapping
7-2
Topic Introduction Why Create a Database Design? Transformation Process Naming Convention Basic Mapping Relationship Mapping Mapping of Subtypes Summary Practice 71: Mapping Supertype Practice 72: Quality Check Subtype Implementation
See Page 2 4 6 8 12 14 20 29 30 31
..................................................................................................................................................... 7-2 Data Modeling and Relational Database Design
Introduction .....................................................................................................................................................
Topic Practice 73: Quality Check Arc Implementation Practice 74: Mapping Primary Keys and Columns
See Page 32 33
Objectives At the end of this lesson, you should be able to do the following: Understand the need of a physical database design Know the concepts of the relational model Agree on the necessity of naming rules Perform a basic mapping Decide how to transform complex concepts
..................................................................................................................................................... 7-3
Why Create a Database Design?

The Entity Relationship model describes the data required for the business. This model should be totally independent from any implementation considerations. This same ER model could also be used as a basis for implementation of any type of DBMS or even a file system.
Why Create a Data Design Model?
Closer to the implementation solution Facilitates discussion Ideal model can be adapted to an RDBMS model Sound basis for physical database design
7-3
A New Starting Point An Entity Relationship model is a high-level representation which cannot be implemented as is. People creating these models may not be aware of physical and database constraints, but they still have to provide a conceptually workable solution. This is why it is important to have a validated and agreed ER model before going into the physical database design. Transforming the ER model, creates a first-cut database design. This first-cut design is intended to serve as a new basis for defining the physical implementation of the database. This new model can easily be used for further discussions between designers, developers, and database administrators.
Why Create a Database Design? .....................................................................................................................................................
Presenting Tables Tables are supported by integrity rules that protect the data and the structures of the database. Integrity rules require each table to have a primary key and each foreign key to be consistent with its corresponding primary key. About the slide See Page 34
Presenting Tables
Table: EMPLOYEES columns
Id 126 349 785 Name Address Birth_date Dpt_id PAGE 12, OXFORD ST 03-03-66 10 PAPINI 53, HAYES AVE 10-08-77 20 GARRET 08-12-55 10
rows
primary key column
unique key column EMPLOYEES (EPE)
foreign key column
Table diagram: EMPLOYEES
pk * Id uk1 * Name o Address uk1 * Birth_date fk * Dpt_id
foreign key
7-4
Tables A table is a very simple structure in which data is organized and stored. Tables have columns and rows. Each column is used to store a specific type of value. In the above example, the EMPLOYEES table is the structure used to store employees information. Rows Each row describes an occurrence of an employee. In the example, each row describes in full all properties required by the system. Columns Each column holds information of a specific type like Id, Name, Address, Birth Date, and the Id of the department the employee is assigned to. Primary keys The Id column is a primary key, that is, every employee has a unique identification number in this table which distinguishes each individual row. Unique keys Both columns Name and Birth_date are associated with a Unique key constraint which means that the system does not allow two rows with the same name and Birth_date. This restriction defines the limits of the system. Foreign keys The foreign key column enables the use of the Dpt_id value to retrieve the department properties for which a specific employee is working.
..................................................................................................................................................... 7-5
Transformation Process
Using transformation rules you create a new model based on the conceptual model. About the slide See Page 35
Transformation Process
Conceptual Model
Relational Model
7-5
Conceptual Model The way you can describe requirements for the data business requires using a semantically rich syntax through graphical representation. As you have seen in previous chapters, many of the business rules can be described with graphical elements such as subtypes, arcs, relationships (barred and nontransferable ones). The only constraints in expressing business complexity that you have encountered so far are the graphical limitations. We know that this model acts as a generic one, because it is not related to any physical considerations. Therefore it can be used for any type of database. Nevertheless, it may be that the DBMS type you want to use (relational or others) does not support all of the semantic rules graphically expressed in your ER model. Relational Model. The Relational model is based on mathematical rules. This means that when you try to fit all of the syntax from the ER model into the physical database model, some of it may not have any correspondence in the relational model. To preserve these specified rules, you have to keep track of them and find the correct way to implement them.
Transformation Process .....................................................................................................................................................
Terminology Mapping
Terminology Mapping
ANALYSIS
ER Model Entity Attribute Primary UID Secondary UID Relationship Business Constraints
DESIGN
Physical Design Table Column Primary Key Unique Key Foreign Key Check Constraints
7-6
Changing from one world to an other also means changing terminology. Using a very simple basis: An entity leads to a table. An attribute becomes a column. A primary unique identifier produces a Primary key. A secondary unique identifier produces a Unique key. A relationship is transformed into a Foreign key and foreign key columns. Constraints are the rules with which the database must cope to be consistent. Some of the business rules are translated into Check Constraints, other complex ones require additional programming and can be implemented at client side or server side or both. This initial mapping of an ER model is limited to the design of tables, columns. and constraints that can be declared. A declarative constraint is a business constraint that can be ensured at the server level using database language statements only and requires no coding.
..................................................................................................................................................... 7-7
Naming Convention
Before transforming the ER diagram you probably need to define a naming convention so that people working on the project use the same standards and produce the same model from the same source. Rules explained here are the ones used within Oracle. Even though they are efficient, they are not the only ones that you can use and you or your company may provide the companys own standard as part of its method. About the slide See Page 35
General Naming Topics
Decide on a convention for: Table names Special characters (%, *, #, -, space, ) Table short names Column names Primary and Unique Key Constraint names Foreign Key Constraint names Foreign Key Column names
7-7
Naming of Tables The plural of the entity name is used as the corresponding table name. The idea is that the Entity is the concept of an abstract thingyou can talk about EMPLOYEE, CUSTOMER, and so on, so singular is a good naming rule, but a table is made up of rows (the EMPLOYEES table, or CUSTOMERS table) where the plural is more appropriate. Naming of Columns Column names are identical to the attribute names, with a few exceptions. Replace special characters with an underscore character. In particular, remove the spaces from attribute names, as SQL does not allow spaces in the names of relational elements. Attribute Start Date converts to column Start_date; attribute Delivered Y/N transforms to Delivered_y_n (or preferably Delivered_Ind). Often column names use more abbreviations than attribute names.
Naming Convention .....................................................................................................................................................
Short Names A unique short name for every table is a very useful element of the name of foreign key columns or foreign key constraints. A suggested way to make these short names is based on the following rules: For entity names of more than one word, take the: First character of the first word. First character of the second word. Last character of the last word. For example entity PRICED PRODUCT produces PPT as a short table name. For entity names of one word but more than one syllable, take the: First character of the first syllable. First character of the second syllable. Last character of the last syllable. For example EMPLOYEE gives EPE as a short name. For entity names of one syllable, but more than one character, take the: First character. Second character. Last character. For example FLIGHT gives FLT. This short name construction rule does not guarantee uniqueness among short names but experience has proved that duplicated names are relatively rare. In case two short names happen to be the same, just add a number to the one that is used less often giving, for example, CTR for the most frequently used one and then CTR1 for the second one. Naming of Foreign Key Constraints The recommended rule for naming foreign key constraints is <short name of the from table> _ < short name of the to table> _ < fk>. For example, a foreign key between tables EMPLOYEES and DEPARTMENT results in constraint name epe_dpt_fk. Naming of Foreign Key Columns Foreign key columns are prefixed with the short name of the table they refer to. This leads to foreign key column names like dpt_no. Limiting the attribute name to 22 characters enables you to add two prefixes plus two underscores to the column name. This may occur in the event of cascade barred relationships. This is discussed later in the lesson.
..................................................................................................................................................... 7-9
Multiple Foreign Keys Between Two Tables If there are two (or more) foreign keys between two tables then the foreign keys and foreign key columns would be entitled to the same name. In this situation, add the name of the relationship to both foreign key names. Do the same with the foreign key columns. This way you will never mistake the one foreign key for the other. For example, in the model of Electronic Mail entity LIST ITEM has two relationships with ALIAS (one of them is at the subtype level). The naming would result in the two foreign key names: lim_als_in and lim_als_referring_to. The foreign key columns would be named Als_id_in and Als_id_referring_to. Naming of Check Constraints Check Constraints are named <table short name>_ck_<sequence_number>, such as epe_ck_1, epe_ck_2 for the first and second check constraint on table EMPLOYEES. Naming Restrictions with Oracle Each RDBMS can have its own naming restrictions. You need to know if the convention you decide to use is compatible with it.
Naming Restrictions with Oracle
Table and column names:
Must start with a letter May contain up to 30 alphanumeric characters Cannot contain space or special characters
Table names must be unique within a schema. Column names must be unique within a table.
7-8
You can use any alpha-numeric character for naming tables and columns as long as the name: Starts with a letter. Is up to 30 characters long. Does not include special characters such as !.
Naming Convention .....................................................................................................................................................
Table names must be unique within the name space that is shared with views and synonyms. Within the same table two columns cannot have the same name. Be aware also of the reserved programming language words that are not allowed to be used for naming objects. Avoid names like Number Sequence Values Level Type for naming tables or columns. Refer to the RDBMS reference books for these.
..................................................................................................................................................... 7-11
Basic Mapping
Entity Mapping Before going into complex transformation we will look at the way to transform simple entities.
Basic Mapping
1 - Entities 2 - Attributes 3 - Unique identifiers Table Name: EMPLOYEES Short Name: EPE Primary UID
EMPLOYEE # Id * Name o Address * Birth Date
EMPLOYEES (EPE)
pk * Id uk1 * Name o Address uk1 * Birth_date
Secondary UID
7-11
1 Transform entities into tables using your own naming convention or the one
previously described. In this example the entity EMPLOYEE produces a table name EMPLOYEES and a short name EPE. Use a box to represent tables on a diagram. 2 Each attribute creates a column in the table and the characteristics such as mandatory or optional have to be kept for each column. Using the same notation * or o facilitates recognition of these characteristics on a diagram. 3 All unique identifiers are transformed. A primary unique identifier is transformed into a Primary key. The notation pk next to the column name indicates the Primary key property. If more than one column is part of the primary key, use the pk notation for each column. Secondary unique identifiers, even if they do not appear on your ER diagram, need to be implemented. To preserve this property, secondary UIDs are transformed as unique keys. In the above example, the values for the combination of two columns must be unique. They belong to the same unique key and each column has a uk1 notation to indicate this. If, in future, another unique key might exist for that table, it would be notated as uk2.
Basic Mapping .....................................................................................................................................................
Rules for Relationships About the slide See Page 36
Rules for Relationships

EMPLOYEE # Id * Name o Address * Birth Date fk2 = epe_epe_fk EMPLOYEES (EPE) pk * Id * Name fk1 * Dpt_id fk2 o Epe_id
DEPARTMENT # Id * Name
DEPARTMENTS (DPT) pk fk1 = epe_dpt_fk uk
* Id * Name
7-12
Foreign Key Columns: A relationship creates one or more foreign key columns in the table at the many side. Using previous naming rules, the name of this foreign key column is Dpt_id for the relationship with Department and Epe_id for the recursive relationship. This ensures that column names such as Id, coming from different tables, still provide a unique column name in the table. Depending on whether or not the relationship is required, the foreign key column is mandatory or optional. Foreign Key Constraints: The foreign key constraints between EMPLOYEES and DEPARTMENTS is epe_dpt_fk. The recursive one between EMPLOYEES and EMPLOYEES is called epe_epe_fk.
..................................................................................................................................................... 7-13
Relationship Mapping
Mapping of One-to-Many Relationships As previously mentioned, some of the meaning that is expressed in an ERD cannot be reproduced in the physical database design.
.
Mapping 1:m Relationships

XS
fk
o Y_id
XS
fk
Y_id
7-13
A relationship in an ER Diagram expresses the rules that apply between two entities, from two points of view. The notation used in the ERD is rich enough to tell, for example, that the relationship is mandatory on both sides. The illustration shows that the 1:m relationships that are mandatory at the one side are implemented in exactly the same way as the ones that are optional at the one side. This means that part of the content of the ER model is lost during transformation, due to the relational model limitations. You need to keep track of these incomplete transformations; they must be implemented using a mechanism other than a declarative constraint. Mapping of Mandatory Relationship at the One Side In case of the implementation of a relationship that is mandatory at the one side you need to check two things. You cannot create any master record without at least one detail record. When deleting details you must be sure that you do not delete the last detail for a master record, or alternatively, you must delete the master record together with its last detail.
Relationship Mapping .....................................................................................................................................................
You can implement code to check this on the server side or on the client side. In an Oracle environment this was usually done at the client side. Since Oracle 8, on the server side Oracle offers implementation possibilities that were not available in previous releases. Optional Composed Foreign Keys When a foreign key is made of two or more columns, and the foreign key is optional, all foreign key columns must be defined as optional. Note that if you enter a value in one of the foreign key columns, but not in the other one, Oracle will not fire the foreign key constraint check. You would need additional code to check that either all or none of the foreign key columns have a value, but exclude the possibility of a partially-entered key. Mapping of Nontransferable Relationships About the slide See Page 37
Mapping Barred and Nontransferable Relationships

X # Id * C1 Y # Id * C2
XS (X) pk
YS (Y) Id C1
* *
fk = y_x_fk
* pk pk, fk * *
Id X_id C2
7-14
This relationship property does not migrate to the physical database design because it has no natural counterpart in an RDBMS, although you can code a solution at the server side. In the example, you would create an update trigger at table YS that fails when the foreign key column X_id is updated. Mapping Barred Relationships A barred relationship, like any other relationship, is mapped into a foreign key. The foreign key column is also part of the primary key, and thus plays a double role.
..................................................................................................................................................... 7-15
Mapping of Cascade Barred Relationships A Cascade Barred relationship may lead to long column names as the illustration shows.
Mapping Cascade Barred Relationships

A # Id * C1 B # Id * C2 C # Id * C3 D # Id * C4
AS (A) pk * Id * C1
BS (B) pk * Id * C2 fk,pk * A_id
CS (C) * * fk,pk * fk,pk * pk Id C3 B_id B_a_id
DS (D) pk fk fk fk * * * * * Id C4 C_id C_b_id C_a_id
fk = b_a_fk fk = c_b_fk
fk = d_c_fk
7-15
To avoid column names that could end up with more than 30 characters, the suggested convention is never to use more than two table prefixes. The usual choice for the foreign key column names is: <nearest by table short name> _ <farthest table short name> _ <column name> In the above example the foreign key column in DS that comes all the way from AS via BS and CS is named C_a_id instead of C_b_a_id. As the short names are usually three characters long, this rule explains why attribute names should not have more than 22 characters.
Mapping of Many-to-Many Relationships When transforming a many-to-many relationship, you create an intersection table.
Mapping m:m Relationships
X # Id * C1
Y # Id * C2
XS pk * * Id C1 X_YS pk,fk1 * X_id pk,fk2 * Y_id fk1 = xy_x_fk

7-16
YS pk * * Id C2
fk2 = xy_y_fk
The intersection table contains all the combinations that exist between XS and YS. This table has no columns other than foreign key columns. These columns together form the primary key. The rule for naming this table is short name of the first table (in alphabetical order) and full name of the second one. This would give a many-to-many relationship between tables EMPLOYEES and PROJECTS an intersection table named EPE_PROJECTS. Whether the relationship was mandatory or not, the foreign key columns are always mandatory. Note this table is identical (maybe except for its name) to the table that would result from an intersection entity that could replace the m:m relationship.
..................................................................................................................................................... 7-17
Mapping of One-to-One Relationships
Mapping 1:1 Relationships

X # Id * C1 Y # Id * C2
XS (X) pk * * Id C1
YS (Y) fk = y_x_fk pk * Id * C2 fk,uk * X_id
Choose which side for FK for other cardinalities

7-17
When transforming a one-to-one relationship, you create a foreign key and a unique key. All columns of this foreign key are also part of a unique key. If the relationship is mandatory on one side, the foreign key is created at the corresponding table. If the relationship is mandatory on both sides or optional on both sides, you can choose on which table you want to create the foreign key. There is no absolute rule for deciding on which side to implement it. If the relationship is optional on both sides you may decide to implement the foreign key in the table with fewer numbers of rows, as this would save space. If the relationship is mandatory at both ends, we are facing the same RDBMS limitation you saw earlier. Therefore, you need to write code to check the mandatory one at the other side, just as you did to implement m:1 relationships that are mandatory at the one end. Alternative Implementations A 1:1 relationship between two entities can be implemented by a single table. This is probably the first implementation to consider. It would not need a foreign key constraint. A third possible implementation is to create an intersection table, as if the relationship was of type m:m. The columns of each of the foreign keys of the intersection table would be part of unique keys as well.
Mapping of Arcs
Mapping Arcs
Explicit implementation USER # Id * Name ALIAS # Id fk1 = lim_x_fk USERS (USR) LIST_ITEMS (LIM) pk,fk1 * X_id fk2 o Usr_id fk3 o Als_id fk3 = lim_als_fk fk2 = lim_usr_fk pk * * Id Name
LIST ITEM
ALIASES (ALS) pk * Id
+ check constraint
7-18
The first solution illustrated above shows that there are as many foreign keys created as there are relationships. Therefore a rule must be set to verify that if one of the foreign keys is populated, the others must not be populated (which is the exclusivity principle of the relationships in an arc) and that one foreign key value must always exist (to implement the mandatory condition). From a diagram point of view, all foreign keys must be optional, but additional code will perform the logical control. One solution on the server side is to create a check constraint at LIST_ITEMS as is:
CHECK OR ( AND ( AND usr_id IS NOT NULL als_id IS NULL) usr_id IS NULL als_id IS NOT NULL).
This controls the exclusivity of mandatory relationships. In case the relationships are optional, you need to add:
OR (usr_id IS NULL AND als_id IS NULL) DECODE (usr_id,NULL,0,1) + DECODE (als_id,NULL,0,1)=1; (or =<1 for optional relationship).
An other syntax that is often used:
You can also map arcs in a different way using the generic arc implementation. This is a historical solution that you may encounter in old systems. You should not use it in new systems. It is discussed in the lesson on Design Considerations.
..................................................................................................................................................... 7-19
Mapping of Subtypes
In mapping subtypes, you must make a choice between three different types of implementations. All three are discussed in detail.
Mapping Subtypes
Variety of implementation choices
P # Id * Xxx Q o Yyy R * Zzz K # Id A # Id B # Id
Supertype Subtype Both Supertype and Subtype (Arc)
L # Id
7-19
Supertype Implementation This choice produces one single table for the implementation of the entities P, Q, and R. The supertype implementation is also called single (or one) table implementation. Rules 1 Tables: Independent of the number of subtypes, only one single table is created. 2 Columns: The table gets a column for all attributes of the supertype, with the original optionality. The table also gets a column for each attribute belonging to the subtype but the columns are all switched to optional. Additionally, a mandatory column should be created to act as a discriminator column to distinguish between the different subtypes of the entity. The value it can take is from the set of all the subtype short names (DBE, DBU in the example). This discriminator column is usually called <table_short_ name> _ type, in the example Dba_type. 3 Identifiers: Unique identifiers translate into primary and unique keys.
Mapping of Subtypes .....................................................................................................................................................
Unique identifiers at subtype level usually translate into a unique key or check constraint only. About the slide See Page 38
Supertype Implementation
P # Id * Xxx Q o Yyy R * Zzz K # Id A # Id B # Id PS (P) pk Id Xxx o Yyy o Zzz * A_id o B_id * P_type
* *
L # Id
Mandatory discriminator column Additional constraints
fk1 fk2
7-20
4 Relationships:
Relationships at the supertype level transform as usual. Relationships at subtype level are implemented as foreign keys, but the foreign key columns all become optional. 5 Integrity constraints: For each particular subtype, all columns that come from mandatory attributes must be checked to be NOT NULL. For each particular subtype, all columns that come from attributes or relationships of other subtypes must be checked to be NULL. Note: You may avoid the use of the discriminator column if you have one mandatory attribute in each subtype. The check is done directly on these columns to find out what type a specific row belongs to. When to Consider Supertype Implementation The single table implementation is a common and flexible implementation. It is the one you are likely to consider first and is specially appropriate when: Most of the attributes are at the supertype level. Most of the relationships are at the supertype level. The various subtypes overlap in the required functionality.
..................................................................................................................................................... 7-21
The access path to the data of the various types is the same. Business rules are globally the same for the subtypes. The number of instances per subtype does not differ too much, for example, one type having more than, say, 1000 times the number of instances of the other. An instance of one subtype can become an instance of another, for example, imagine an entity ORDER with subtypes OPEN ORDER and PROCESSED ORDER, each subtype having its own properties. An OPEN ORDER may eventually become a PROCESSED ORDER.
Additional Objects Usually you would create a view for every subtype, showing only the columns that belong to that particular subtype. The correct rows can be selected using a condition based on the discriminator column. These views can be used for all data operations, including inserts and updates. All applications can be based on the view, without loss of performance. The supertype table plus subtype views is an elegant and appropriate implementation and should be considered as first choice. Consequences for Tables Based on K and L The foreign key in the table based on K is straightforward. The foreign key of the table based on L is more complex. The supertype implementation would mean that the foreign key refers to a valid P, not to the more limited set of Rs. This must be checked with an additional constraint.
Subtype Implementation .....................................................................................................................................................
Subtype Implementation
This subtype table implementation (often loosely referred to as two-table implementation) produces one table for each of the subtypes, assuming there are only two subtypes, such as Q and R.
Subtype Implementation
P # Id * Xxx Q o Yyy R * Zzz K # Id A # Id B # Id QS (Q) pk fk * *
o
Id Xxx Yyy A_id
q_a_fk
RS (R) pk * Id * Xxx * Zzz * A_id * B_id fk1=r_a_fk fk2=r_b_fk
L # Id
fk1 fk2
7-21
Rules 1 Tables: One table per first level subtype. 2 Columns: Each table gets a column for all attributes of the supertype, with the original optionality. Each table also gets a column for each attribute belonging to the subtype, also with the original optionality. 3 Identifiers: The primary unique identifier at the supertype level creates a primary key for each of the tables. Alternatively, if the subtypes had their own UID, this one can be used as the basis for the primary key. Secondary identifiers of the supertype become unique keys within each table. 4 Relationships: All tables get a foreign key for a relationship at the supertype level with the original optionality.
..................................................................................................................................................... 7-23
For the relationships at the subtype levels, the foreign key is implemented in the table it is mapped to. The original optionality is retained. 5 Integrity constraints: No specific additional checks are required. Only when the Id values must be unique across all subtypes would it need further attention. When to Consider a Subtype Implementation You can regard this implementation as a horizontal partitioning of the supertype. It may be appropriate when: The resulting tables will reside in different databases (distribution). This may occur when different business locations are only interested in a specific part of the information. When the common access paths for the subtypes are different. Subtypes have almost nothing in common. This may occur when there are few attributes at the supertype and many at the subtype levels. An example can be found in the Electronic Mail model. Entity ADDRESS has two subtypes: MAIL LIST and ALIAS. These subtypes only share the fact that they can be used as addressee for a message, but their other properties are completely different. Most of the relationships are at the subtype level. This is the case especially if both tables are to be implemented in different databases, and the foreign key integrity constraint for the supertype may not be verified in all cases. Business functionality and business rules are quite different between subtypes. The way tables are used is different, for example, one table being queried while the other one is being updated. A one-table solution could result in performance problems. The number of instances of one subtype is very small compared to the other one. Additional Objects Usually you would create an additional view that represents the supertype showing all columns of the supertype and various subtypes. The view select statement must use the union operator. The view can be used for queries only, not for data manipulation. Consequences for Tables Based on K and L The foreign key in the table based on L is straightforward and should refer to the table based on R. The foreign key of the table based on K is now more complex. This must be implemented as two optional foreign keys, one to each of the tables based on Q and R. An extra check is needed to make sure that both foreign keys do not have a value at the same time; this is identical to an ordinary arc check.
Both Supertype and Subtype Arc Implementation
Supertype and Subtype (Arc) Implementation

P # Id * Xxx Q Yyy PS (P) K # Id A # Id B # Id pk
fk1,uk1 o fk2,uk2 o fk3 *
* Id * Xxx
Q_id R_id A_id
fk3 = p_a_fk
R * Zzz
fk1 = p_q_fk QS (Q)
fk2 = p_r_fk RS (R) pk * Id * Zzz fk * B_id
L # Id
pk
* Id
o
r_b_fk
Yyy
7-22
This choice produces one table for every entity, linked to foreign keys in an exclusive arc at the PS side. It is the implementation of the model as if the subtypes were modeled as standalone entities with each one having an is subtype of / is supertype of relationship to the supertype. These relationships are in an arc. Therefore this implementation is also called Arc Implementation. See also the chapter on Constraints for more details about subtypes compared to the arc. Rules 1 Tables: As many tables are created as there are subtypes, and one for the supertype. 2 Columns: Each table gets a column for all attributes of the entity it is based on, with the original optionality. 3 Identifiers: The primary UID at the supertype level creates a primary key for each of the tables. All other unique identifiers transform to unique keys in their corresponding tables. 4 Relationships: All tables get a foreign key for a relevant relationship at the entity level with the original optionality.
..................................................................................................................................................... 7-25
5 Integrity constraints:
Two additional columns are created in the table based on the supertype. They are foreign key columns referring to the tables that implement the subtypes. The columns are clearly optional as the foreign keys are in an arc. The foreign key columns are also part of the unique keys because, in fact, they implement a mandatory one-to-one relationship. An additional check constraint is needed to implement the arc.
When to Consider a Both Supertype and Subtype Implementation This solution performs a double partitioning. It is used relatively rarely, but could be appropriate when: The resulting tables reside in different databases (distribution). This may occur when different business locations are only interested in a specific part of the information. Subtypes have almost nothing in common and each table represents information that can be used independently. For example, when the PS table gives all global information and both QS and RS give specific information, and the combination of global and specific information is hardly ever needed. Business rules are quite different between all types. The way tables are used and accessed is different. Users from different business areas need to work with the same rows at the same time, but with different parts of the rows, which could result in locking problems and a performance issue. Additional Objects Although you would hardly use them, you could consider creating additional views that represent the supertype and various subtypes in full. Consequences for Tables Based on K and L Both foreign keys can be implemented straightforwardly without additional checks.
Storage Implication The illustrations show the differences between the one, two and three table implementations. In most database systems empty column values do take some bytes of database space (although this sounds contradictory). In Oracle this is very low when the empty columns are at the end of the table and when the data type is of variable size. Supertype Implementation All rows for both types are in one table. Note the empty space in the Q rows at the R columns and vice-versa.
Storage Implication Supertype Implementatioin

discriminator column cols cols cols P Q R rows Q
P Q R
rows R
Subtype Implementation In the two table implementation the empty space of the one-table implementation is gone. This is a horizontal split of the table.
Storage Implication Subtype Implementation
cols P
cols R rows Q
cols P
cols Q
rows R
..................................................................................................................................................... 7-27
Arc Implementation In this three table implementation the one table is sliced vertically into a P-columns-only portion. The remaining part is horizontally split into the Q and R columns and rows. An additional foreign key column at P, or a foreign key column at Q and R each is needed to connect all the pieces together.
Storage Implication Supertype and Subtype (Arc) Implementation

cols P rows Q rows Q rows R rows R fk cols Q fk cols R
7-26
Summary .....................................................................................................................................................
Summary
Summary
Relational concepts Naming rules convention Basic mapping Complex mapping
7-27
Relational databases implement the relational theory they are based on. A coherent naming rule can prevent many errors and frustrations and adds to the understanding of the structure of the database schema. You have seen how to map basic elements from an ER model such as entities and relationships. These can be done in a very simple way. There are also complex structures which require decisions on how to transform them. Some ER model elements can only be implemented by coding check constraints or database triggers. These are specific to Oracle and not part of the ISO standard for relational databases.
..................................................................................................................................................... 7-29
Practice 71: Mapping Supertype

Moonlight Coffees
Goal (See Page 40) In this practice, you create a complex mapping and test your understanding of the transformation process.
Scenario Here is part of the Moonlight ER model showing the entity DEPARTMENT. One of the analysts has decided to implement the DEPARTMENT entity and its subtypes as a single table.
pp g
reporting to
DEPARTMENT # Id * Name * Head Count
yp
report of
HQ * Address
report of
COUNTRY ORGANIZATION reporting # Tax Id Number to
OTHER DEPARTMENT
Your Assignment 1 What would have been the rationale of this choice? 2 On the table diagram, name all the elements that must be created following this supertype implementation. Use the naming convention as described in this lesson, or use your own rules. Give proper names to the columns and foreign key constraints and identify check constraints, if any.
DEPARTMENTS (
7-29
Practice 72: Quality Check Subtype Implementation .....................................................................................................................................................
Practice 72: Quality Check Subtype Implementation

Moonlight Coffees
Goal (See Page 40) In this practice you perform a quality check on table mappings that were created by someone else who is supposed to use the naming convention that is described in this lesson.
Scenario Here is a part of the Moonlight ER model.
COUNTRY # Code
with
with with
in
with in for
PRICE LIST # Start Date * End Date PRODUCT GLOBAL # Code o Size
of
LOCAL # Name
SHOP # No * Name * Address * City
with in
with of
GLOBAL PRICE * Amount

7-30
Your Assignment Perform a quality check on the proposed subtype implementation of entity PRODUCT.
lpt_shop_fk
GLOBAL_PRODUCTS (GPT) pk *
o
LOCAL_PRODUCTS (LPT) pk fk fk
Code Size Pgp_name
# Name * Shop_no * Pgp_name
..................................................................................................................................................... 7-31
Practice 73: Quality Check Arc Implementation

Moonlight Coffees
Goal (See Page 41) The purpose of this practice is to do a quality check on table mappings that were created by someone else who is supposed to use the naming convention that is described in this lesson.
Scenario This practice is based on the same ER diagram as the previous practice.
Practice: Quality Check Arc Implementation

PRODUCTS (PDT)
pk
fk1=pdt_pgp_name fk2=pdt_gpt_code fk3=pdt_lpt_name
fk1 * fk2 * fk3 *
Code Pgp_name Gpt_code Lpt_name
GLOBAL_PRODUCTS (GPT) pk * Code o Size LOCAL_PRODUCTS (LPT) pk * Name pk, fk1 o Shp_no * Pgp_name fk1
7-32
gpt_pgp_fk
fk1=shp_lpt_fk fk2=pgp_lpt_fk
Your Assignment Perform a quality check on the proposed supertype and subtype implementation of the entity PRODUCT and its subtypes. Also, check the selected names.
Practice 74: Mapping Primary Keys and Columns .....................................................................................................................................................
Practice 74: Mapping Primary Keys and Columns

Moonlight Coffees
Goal (See Page 41) The purpose of this practice is to do a complex mapping of primary keys and columns.
Scenario This practice is based on the same model that was used in the previous practice. Your Assignment Identify the Primary key columns and names resulting from the transformation of the GLOBAL PRICE entity. Give the short name also.
GLOBAL_PRICES (
..................................................................................................................................................... 7-33
Instructor Notes
Instructor Note Topic Timings Lecture 45 minutes Practice 15-45 minutes Total 60-90 minutes
7 7
M apping the Entity M od el
O verview
W h y u se d es ig n m o de lin g ? Intro d u c tio n to th e c o m p o n en ts:
T ab le s C o lum n s C o n s train ts
B a sic M ap ping C o m p lex m a pp in g
This lesson deals with a relational database design. The approach would be the same independently of the RDBMS used. It applies as well to DB2, Sybase, Informix, SQL sever, or Oracle. It is technique dependent (relational) but software independent
7 -2
W hy C re ate a D ata D esign M ode l?
C lo s er to th e im plem en tatio n s o lu tio n F a cilitates d is c us sio n Ide al m o d e l c an b e a d ap ted to a n R D B M S m o d e l S o un d b as is fo r p h ys ica l d atab a se d es ig n
A data design model can be derived from an ER model (which is the flow down approach we advise and follow in this course), but it could also be created directly from an existing database.
7 -3
Pres enting Tables

Ta ble: E M P LO YE E S c olu m n s
Id 12 6 34 9 78 5 N a me A dd r es s B ir t h_ d a te D p t_ i d P A GE 1 2, OX FO R D S T 0 3 -0 3 - 66 10 P A PI N I 5 3, HA YE S AV E 1 0 -0 8 - 77 20 G A RR E T 0 8 -1 2 - 55 10
ro w s
prim ary ke y co lum n
un iqu e k ey co lu m n EM P LO Y E ES (EP E )
fo re ign key co lum n
Ta ble d ia gram : E M P LO Y E E S
pk * uk 1 *
o
uk 1 * fk *
7 -4
Id Name A d dress B irth_date D p t_id
fo re ign key
Students should be aware of Table structures. Theoretically every single table must have a primary key. Oracle allows tables to be created without primary keys. Oracle also allows a foreign key to reference a unique key instead of a primary key. This slide shows the way a table can be visualized and the way we represent tables in this book in the table diagrams. The notation is similar (but not identical) to the one used in Oracle Designer.
Instructor Notes .....................................................................................................................................................
Trans form ation Proc ess

C onceptual M o del
The bits and pieces that go into the wastebasket are the things that have no counterpart that can be declared in the relational world. Most of these pieces however, can be coded manually.
R elational M o del
7 -5
Te rm ino lo gy M a pping
A N A L Y S IS
E R M odel E ntity A ttribute P rim ary U ID S econdary U ID R elationship B usin ess C onstraints
DE S IG N
P hysical D es ign Table C olum n P rim a ry K ey U niqu e K ey Foreig n K ey C heck C onstraints
Note there are physical objects that do not have a ER counterpart. The most obvious one is a view. Primary key, unique key and foreign key are constraints that can be declared, that is, they can be created without any coding in thirdgeneration languages. The naming convention described here and used in this book is the one used in Oracles method: CDM.
7 -6
G en era l N a m ing T opics
D ecide on a convention for: T able n am es S pe cia l ch aracte rs (% , *, #, -, sp ac e, ) T able sh ort nam es C o lum n na m es P rim a ry an d U n iqu e K ey C on straint n am es F oreig n K e y C o nstra int nam es F oreig n K e y C o lum n nam es
7 -7
N am ing R estrictions w ith O racle
T a b le an d c o lu m n n am e s:
M u s t start w ith a letter M a y c o n tain up to 30 alp h an u m e ric c ha ra cters C a n n o t co n tain sp a ce o r s p ec ia l c h ara cte rs
T a b le n am e s m u st b e u n iq u e w ith in a s ch e m a . C o lu m n n am e s m u st b e u n iq u e w ith in a tab le.
7 -8
..................................................................................................................................................... 7-35
First map entities to tables.

B asic M apping for E ntities
1 - En tities T able N am e: E M P LO Y E ES S ho rt N am e: EP E
E M P LO Y E E E M P LO Y E E S (E P E )
7 -9
Next map attributes to columns.

B asic M apping for A ttrib utes
1 - En tities 2 - A ttrib ute s T able N am e: E M P LO Y E ES S ho rt N am e: EP E
E M P LO Y E E # Id * N am e o A d dress * B irth D ate E M P LO Y E E S (E P E ) * *
o
Id N am e A ddress B irth_da te
7 -1 0
B as ic M app ing
1 - En tities 2 - A ttrib ute s 3 - U niq ue ide ntifiers T able N am e: E M P LO Y E ES S ho rt N am e: EP E Prim ary U ID

E M P LO Y E E # Id * N am e o A d dress * B irth D ate
Create primary and unique keys. Then the foreign keys and all additional constraints can be defined.
E M PL O Y EE S (E P E )
pk uk 1 uk 1 * *
o
Id N am e A ddress B irth_da te
Se cond ary U ID
7 -1 1
R ules fo r R elation ships

E M P LO Y E E # Id * N am e o A ddress * B irth D ate fk 2 = epe_ep e_fk E M P LO Y E E S (E P E ) pk * Id * N am e fk 1 * fk 2 o D pt_id E pe_id
D E P A R TM E N T # Id * N am e
D E P A R TM E N TS (D P T ) pk fk 1 = epe_d pt_fk uk
* Id * N am e
7 -1 2
A relationship is mapped into two things: A foreign key constraint One or more foreign key columns The representation of the tables and foreign keys does not correspond to an official standard as there is no official convention. The convention used here is selected for educational reasons.
M app ing 1 :m R elationsh ip s

XS
fk
Y _id
XS
fk
Y _id
7 -1 3
The mapping of a 1:m relationship that is mandatory at the 1-end is initially identical to that of a 1:m relationship which is optional at the 1-end. Very often the mandatory 1 was not implemented at all, or was implemented in the applications. Since Oracle 8i there are possibilities for implementing it at the server side. Solutions involve triggers and need to make use of the deferrable option for constraints. The fact that a relationship is barred is mapped on a primary key. Nontransferability cannot be declared. The code on the server side must check that foreign key columns are not updatable. You could use a before update trigger for each row to check this. Clearly, the table based on entity D has a foreign key that consists of a lot of columns. Note the name of the foreign key columns in table DS: C_id, C_b_id and C_a_id (instead of C_b_a_id). We do not use a barred foreign key notation as this is very confusing for Oracle Designer users. There the bar across a foreign key has the completely different meaning of restrict delete. Whatever the optionalities of a m:m relationship, it will be implemented as an intersection or binary table. The intersection table always has two mandatory foreign keys.
M ap pin g B arred an d N on tra nsferable R elatio nsh ips

X # Id * C1 Y # Id * C2
X S (X ) pk
Y S (Y ) Id C1
* *
fk = y_x_fk
pk pk, fk
* * *
Id X _id C2
7 -1 4
M app ing C asca de B a rre d R elatio nships

A # Id * C1 B # Id * C2 C # Id * C3 D # Id * C4
A S (A ) pk * Id * C1
B S (B ) pk * Id * C2 fk,pk * A _id
C S (C ) pk * Id * C3 fk ,pk * B _id fk ,pk * B _a_id
D S (D ) pk fk fk fk * Id * C4 * C _id * C _b_id * C _a_id
fk = b_a_fk fk = c_b_fk
fk = d_c_fk
7 -1 5
M ap pin g m :m R elationsh ip s
X # Id * C1
Y # Id
* C2
XS pk * * Id C1 X _Y S pk,fk1 * pk,fk2 * fk1 = xy_x_fk

7 -1 6
YS pk X _ id Y _ id fk2 = xy_y_fk * * Id C2
..................................................................................................................................................... 7-37
M app in g 1:1 R elation ships

X # Id * C1 Y # Id * C2
X S (X ) pk * * Id C1
Y S (Y ) fk = y_ x_fk pk * Id * C2 fk, uk * X _ id
C ho ose w hich side fo r F K fo r other ca rd ina lities

7 -1 7
A 1:1 relationship is implemented as a 1:m relationship. The foreign key columns are also part of a unique key to safeguard the 1. Note that the first implementation to consider is a single table implementation. In this case you would consider table XS with mandatory columns Id, C1 and optional C2. Foreign keys in an arc consist of optional columns only. An additional check constraint must be created to safeguard the fact that at least one of the foreign keys has a value.
M app in g A rcs
E xplicit im plem en tation USER # Id * N am e A LIA S # Id fk1 = lim _x_fk U S E R S (U S R ) LIS T_ITE M S (LIM ) pk,fk 1 * X _id fk 2 o U sr_id fk 3 o A ls_ id fk3 = lim _als_fk fk2 = lim _usr_fk pk * * Id N am e
LIS T ITE M
A LIA S E S (A LS ) pk * Id
+ che ck c on strain t
7 -1 8
M app in g Sub typ es

Va rie ty of im p lem en tation ch oic es
P # Id * X xx Q
o
K # Id A # Id B # Id
Y yy
R * Zzz
S upe rtype S ubtyp e B oth S up ertyp e an d S ub typ e (A rc)
L # Id
7 -1 9
Su pertype Im plem entatio n

P # Id * X xx Q
o
K # Id A # Id B # Id P S (P ) pk
Y yy
R * Zzz
* * * *
o o
L # Id
M a n d ato ry d isc rim in ato r co lu m n A d ditio n al co n s tra in ts
fk 1 fk 2
Id X xx Y yy Zzz A _id B _id P _type
7 -2 0
Supertype or single table implementation is a straightforward implementation that ignores the differences between the subtypes and acknowledges what they have in common. Mandatory attributes and relationships for the subtypes translate to optional columns and need additional checks. Entities referring to a subtype need an extra check to make sure the reference is to a valid row.
Sub type Im p lem e nta tion

P # Id * X xx Q
o
K # Id A # Id B # Id
Q S (Q ) pk fk * *
o
Id X xx Y yy A _id
q_a_fk
Y yy
R * Zzz
R S (R ) pk * * * * * Id X xx Zzz A _id B _id fk 1 = r_a_fk fk 2 = r_b_fk
L # Id
fk 1 fk 2
7 -2 1
Subtype or two-table implementation is also a straightforward implementation. This implementation mainly acknowledges the differences. All attributes and relationships translate into columns of the right optionality. An incoming relationship at supertype level needs extra attention as the single relationship must be implemented as two foreign keys with an arc. Both supertype and subtype implementation or arc implementation for short. Rather unknown but interesting implementation when the subtype details can often be used apart from the supertype information. All attributes and relationships translate into columns of the right optionality. All incoming relationships map to appropriate foreign keys. The major drawback is the fact that you may need to join QS and RS with PS too often. An alternative implementation would be to create foreign keys at the side of table QS and RS both referring to PS. The arc would remain in place at PS. Supertype or single table implementation: empty space in the R columns for Q rows and vice-versa. Additional type column. Subtype or two-table implementation: no empty space, no additional columns needed. Arc implementation: no empty space, additional foreign key columns.
Sup erty pe and S ubtype (A rc) Im p lem e nta tion

P # Id * X xx Q
o
P S (P ) K # Id A # Id B # Id pk
Y yy
fk 1 ,uk 1 o fk 2 ,uk 2 o fk 3 *
* *
Id X xx Q _id R _id A _id
fk 3 = p_a_fk
R * Zzz
fk 1 = p_q_fk Q S (Q ) R S (R ) pk * fk
fk 2 = p_r_fk
L # Id
pk
*
o
Id Y yy
* *
Id Zzz B _id
r_b_fk
7 -2 2
Sto ra ge Im plication S upe rtyp e Im plem entatioin

discrim inato r colu m n co ls cols cols P Q R row s Q
P Q R
ro w s R
7 -2 4
Sum m ary
R e la tio n a l c o n ce p ts N a m in g ru les c on v e ntio n B a sic m a p p in g C o m p lex m a pp in g
7 -2 7
..................................................................................................................................................... 7-39

Practice
M ap p in g S u p e rtyp e Q ua lity C h ec k S u bty p e Im p le m en ta tion Q ua lity C h ec k S u pe rtyp e a n d S u b typ e (A rc) Im p le m en tatio n M ap p in g P rim ary K e ys a n d C o lu m n s
Practice Mapping Supertype Quality Check Subtype Impl. Quality Check Arc Impl. Synonyms
3day Yes Yes Opt Opt
4day Yes Yes Yes Cha
7 -2 8
Prac tice: M a pping Su pertype

repo rtin g to
D E PA R T M EN T # Id * N am e * H ead C o un t
repo rt o f
HQ * A d dress
repo rt of
COUNTRY O R G A N IZ A T IO N rep orting # Tax Id N um ber to
O T H ER D E PA R TM EN T
Practice 7-1 If delegates want to use their own naming convention it is fine, of course. The goal of this practice is to understand the mapping.
D E P A R TM E N TS (
7 -2 9
P ractice : Q uality C h eck Sub type Im p lem e nta tion
lpt_shop_ fk
G L O B A L _PR O D U C T S (G P T) pk *
o
Practice 7-2 This practice should not take much time and can be done as a joint class activity.
LO C A L_PR O D U C TS (L PT ) pk fk fk
C od e Size Pg p_n am e
# N am e * Sh o p_no * Pg p _n am e
7 -3 1
P ractice : Q uality C h eck A rc Im p le m e ntation

PR OD U C T S (PD T )
pk
fk 1 = pdt_pgp _nam e fk 2 = pdt_gpt_ code fk 3 = pdt_lpt_n am e
fk 1 fk 2 fk 3
* * * *
Code P gp _nam e G p t_co de L pt_na m e
G L OB A L_P R O D U C T S (G PT ) pk
o
gpt_pgp_fk
Code S ize
LO C A L_PR O D U C TS (L PT ) pk pk, fk 1
o
* *
fk 1
7 -3 2
N am e Sh p _n o Pg p _n am e
fk 1 = shp_lpt_fk fk 2 = pgp_lpt_ fk
Prac tice: M a pping Prim a ry K eys and C olum ns

G LO B A L_P R IC E S ( )
7 -3 3
..................................................................................................................................................... 7-41
Instructor Post Lesson Teaching Evaluation .....................................................................................................................................................

Name: Full Email:
Content
Type
Page Number
Note
..................................................................................................................................................... 7-43
Suggested Graphics .....................................................................................................................................................
Suggested Graphics
..................................................................................................................................................... 7-45
fold here
8
.................................
Denormalized Data
Lesson 8: Denormalized Data .........................................................................................................................................
Introduction
Lesson aim This lesson shows you the most common types of denormalization with examples. Schedule See Page 31 About the slide See Page 31
Overview
Denormalization Benefits Types of denormalization
8-2
Topic Why and When to Denormalize Storing Derivable Values Pre-Joining Tables Hard-Coded Values Keeping Details With Master Repeating Single Detail with Master Short-Circuit Keys End Date Columns Current Indicator Column Hierarchy Level Indicator Denormalization Summary Practice 81: Name that Denormalization Practice 83: Denormalize Price Lists Practice 84: Global Naming
See Page 4 6 8 10 12 14 16 18 20 22 24 25 29 30
Introduction .........................................................................................................................................
Objectives At the end of this lesson, you should be able to do the following: Define denormalization and explain its benefits Differentiate and describe the different circumstances where denormalization is appropriate
......................................................................................................................................... 8-3
Why and When to Denormalize

Definition of Denormalization Denormalization aids the process of systematically adding redundancy to the database to improve performance after other possibilities, such as indexing, have failed. You will read more on indexing in the lesson on Design Considerations. Denormalization can improve certain types of data access dramatically, but there is no success guaranteed and there is always a cost. The data model becomes less robust, and it will always slow DML down. It complicates processing and introduces the possibility of data integrity problems. It always requires additional programming to maintain the denormalized data. About the slide See Page 31
Denormalization Overview
Denormalization
Starts with a normalized model Adds redundancy to the design Reduces the integrity of the design Application code added to compensate
8-3
Hints for Denormalizing Always create a conceptual data model that is completely normalized. Consider denormalization as the last option to boost performance. Never presume denormalization will be required. To meet performance objectives, denormalization should be done during the database design. Once performance objectives have been met, do not implement any further denormalization. Fully document all denormalization, stating what was done to the tables, what application code was added to compensate for the denormalization, and the reasons for and against doing it.
Why and When to Denormalize .........................................................................................................................................
Denormalization Techniques and Issues In the next pages you see a number of denormalization techniques that are used regularly. For every type of denormalization you see an indication of when it is appropriate to use it and what the advantages and disadvantages are. About the slide See Page 31
Denormalization Techniques
Storing Derivable Values Pre-joining Tables Hard-Coded Values Keeping Details with Master Repeating Single Detail with Master Short-Circuit Keys
8-4
The following topics are covered: Storing Derivable Values Pre-joining Tables Hard-Coded Values Keeping Details with Master Repeating Single Detail with Master Short-Circuit Keys and the most common specific examples: Derivable End Date Column Derivable Current Indicator column Hierarchy Level Indicator
......................................................................................................................................... 8-5
Storing Derivable Values

When a calculation is frequently executed during queries, it can be worthwhile storing the results of the calculation. If the calculation involves detail records, then store the derived calculation in the master table. Make sure to write application code to recalculate the value, each time that DML is executed against the detail records. In all situations of storing derivable values, make sure that the denormalized values cannot be directly updated. They should always be recalculated by the system. About the slide See Page 32
Storing Derivable Values

Before A pk * * Id X B pk,fk * A_id pk * Sequence_No * Quanity
Add a column to store derivable data in the referenced end of the foreign key. A After pk * Id * X * Total_quantity
8-5
Appropriate: When the source values are in multiple records or tables When derivable values are frequently needed and when the source values are not When the source values are infrequently changed Advantages: Source values do not need to be looked up every time the derivable value is required The calculation does not need to be performed during a query or report Disadvantages: DML against the source data will require recalculation or adjustment of the derivable data Data duplication introduces the possibility of data inconsistencies
Storing Derivable Values .........................................................................................................................................
E-mail Example of Storing Derivable Values
EMail Example of Storing Derivable Values

Before USERS (USR) pk * Id * Per_name REC_MESSAGES (RME) pk,fk * Usr_Id pk,fk * Mse_Id MESSAGES (MSE) pk * * * Id Subject Text
Store derivable column in the referenced end of the foreign key. MESSAGES (MSE) After pk * * * * Id Subject Text Number_of_times_received
8-6
When a message is delivered to a recipient, the user only receives a pointer to that message, which is recorded in RECEIVED_MESSAGES. The reason for this, of course, is to prevent the mail system from storing a hundred copies of the same message when one message is sent to a hundred recipients. Then, when someone deletes a message from their account, only the entry in the RECEIVED_MESSAGES table is removed. Only after all RECEIVED_MESSAGE entries, for a specific message, have been deleted, the should the actual message be deleted too. We could consider adding a denormalized column to the MESSAGES table to keep track of the total number of RECEIVED_MESSAGES that are still kept for a particular message. Then each time users delete a row in RECEIVED_MESSAGES, in other words, they delete a pointer to the message, the Number_of_times_received column can be decremented. When the value of the denormalized column equals zero, then we know the message can also be deleted from the MESSAGES table.
......................................................................................................................................... 8-7
Pre-Joining Tables
You can pre-join tables by including a nonkey column in a table, when the actual value of the primary key, and consequentially the foreign key, has no business meaning. By including a nonkey column that has business meaning, you can avoid joining tables, thus speeding up specific queries. You must include application code that updates the denormalized column, each time the master column value changes in the referenced record. About the slide See Page 32
Pre-Joining Tables
Before A pk B * Id * Col_a pk fk * * Id A_id
Add the non_key column to the table with the foreign key. B After pk fk * * * Id A_id A_col_a
8-7
Appropriate: When frequent queries against many tables are required When slightly stale data is acceptable Advantages Time-consuming joins can be avoided Updates may be postponed when stale data is acceptable Disadvantages Extra DML needed to update original nondenormalized column Extra column and possibly larger indices require more working space and disk space
Pre-Joining Tables .........................................................................................................................................
EMail Example of Pre-Joining Tables

Before FOLDERS (FDR) pk * * Id Name RECEIVED_MESSAGES (RME) pk,fk * Mse_id pk,fk * Flr_id * Date_received
Create a table with all the frequently queried columns. RECEIVED_MESSAGES (RME) After pk,fk pk,fk * * * * Mse_id Flr_id Date_received Fdr_Name
8-8
Example Suppose users often need to query RECEIVED_MESSAGES, using the name of the folder where the received message is filed. In this case it saves time when the name of the folder is available in the RECEIVED_MESSAGES table. Now, if a user needs to find all messages in a particular folder, only a query on RECEIVED_MESSAGES is needed. Clearly, the disadvantage is extra storage space for the extra column in a, potentially, very large table.
......................................................................................................................................... 8-9
Hard-Coded Values
If a reference table contains records that remain constant, then you can consider hardcoding those values into the application code. This will mean that you will not need to join tables to retrieve the list of reference values. This is a special type of denormalization, when values are kept outside a table in the database. In the example, you should consider creating a check constraint to the B table in the database that will validate values against the allowable reference values. Note that a check constraint, though it resides in the database, is still a form of hardcoding. Whenever a new value of A is needed the constraint must be rewritten. About the slide See Page 32
Hard-Coded Values
Before A pk * * Id Type B pk fk * * Id A_id
Remove the foreign key and hard code the allowable values and validation in the application. B After pk * * Id A_Type
8-9
Appropriate When the set of allowable values can reasonably be considered to be static during the life cycle of the system When the set of possible values is small, say, less than 30 Advantages Avoids implementing a look-up table Avoids joins to a look-up table Disadvantages Changing look-up values requires recoding and retesting
Hard-Coded Values .........................................................................................................................................
Email Example of Hard-Coded Values

Before BUSINESS_TYPES (BTE) pk * Id Name USERS (USR) pk fk * * * Id Bte_id Per_name
Hard code the allowable values and validation in the application. After USERS (USR) pk * * * Id Business_type Per_name
8-10
Example ElectronicMail would like to know some background information about their users, such as the type of business they work in. Therefore EM have created a table to store all the valid BUSINESS_TYPES they want to distinguish. The values in this table are set up front and not likely to change. This is a candidate for hard-coding the allowable values. You could consider placing a check constraint on the column in the database. In addition to that, or instead of that, you could build the check into the field validation for the screen application where users can sign in to the EM service.
......................................................................................................................................... 8-11
Keeping Details With Master

In a situation where the number of detail records per master is a fixed value (or has a fixed maximum) and where usually all detail records are queried with the master, you may consider adding the detail columns to the master table. This denormalization works best when the number of records in the detail table are small. This way you will reduce the number of joins during queries. An example is a planning system where there is one record per person per day. This could be replaced by one record per person per month, the table containing a column for each day of the month. About the slide See Page 32
Keeping Details with Master

Before A pk * Id B pk,fk pk * * * A_id Type Amount
Add the repeating detail columns to the master table. A After pk * * * * * * * Id Type1 Amount_1 Type2 Amount_2 Type3 Amount_3
8-11
Appropriate When the number of detail records for all masters is fixed and static When the number of detail records multiplied by the number of columns of the detail is small, say less than 30 Advantages No joins are required Saves space, as keys are not propagated Disadvantages Increases complexity of data manipulation language (DML) and SELECTs across detail values Checks for Amount column must be repeated for Amount1, Amount2 and so on Table name A might no longer match the actual content of the table
Keeping Details With Master .........................................................................................................................................
EMail Example Keeping Detail with Master

Before STORAGE_QUOTAS (SQA) USERS (USR) pk * * Id Name pk,fk * pk * * * Usr_Id Storage_type Allocated Available
Add the repeating detail columns to the master table. USERS (USR) pk * Id * Name * Message_Quota_Allocated * Message_Quota_Available * File_Quota_Allocated * File_Quota_Available
After
8-12
Example Suppose each e-mail user is assigned two quotasone for messages and one for files. The amount of each quota is different, so both have to be tracked individually. The quota does not change very frequently. To be relationally pure, we would create a tworecord STORAGE_TYPES table and a STORAGE_QUOTAS table with records for each user, one for each quota type. Instead, we can create the following denormalized columns in the USER table: Message_Quota_Allocated Message_Quota_Available File_Quota_Allocated File_Quota_Available Note that the name of table USERS does not really match the data in the denormalized table.
......................................................................................................................................... 8-13
Repeating Single Detail with Master

Often when the storage of historical data is necessary, many queries require only the most current record. You can add a new foreign key column to store this single detail with its master. Make sure you add code to change the denormalized column any time a new record is added to the history table. About the slide See Page 33
Repeating Current Detail with Master

Before B A pk * Id pk,fk pk * A_Id * Start_date * Price
Add a column to the master to store the most current details. A After pk * Id * Current_price
8-13
Appropriate When detail records per master have a property such that one record can be considered current and others historical When queries frequently need this specific single detail, and only occasionally need the other details When the Master often has only one single detail record Advantages No join is required for queries that only need the specific single detail Disadvantages Detail value must be repeated, with the possibility of data inconsistencies Additional code must be written to maintain the duplicated single detail value at the master record.
Repeating Single Detail with Master .........................................................................................................................................
Before
EMail Example of Repeating Single Detail with Master

MESSAGES (MSE) pk * Id * Subject * Text ATTACHMENTS (ATT) pk pk,fk * * * Id Mse_id Name
Add a column to the master to store the most current details.
After
MESSAGES (MSE) pk * * * * Id First_attachment_name Subject Text
8-14
Example Any time a message is sent, it can be sent with attachments included. Messages can have more than one attachment. Suppose in the majority of the messages that there is no or only one attachment. To avoid a table join, you could store the attachment name in the MESSAGES table. For those messages containing more than one attachment, only the first attachment would be taken. The remaining attachments would be in the ATTACHMENTS table.
......................................................................................................................................... 8-15
Short-Circuit Keys
For database designs that contain three (or more) levels of master detail, and there is a need to query the lowest and highest level records only, consider creating short-circuit keys. These new foreign key definitions directly link the lowest level detail records to higher level grandparent records. The result can produce fewer table joins when queries execute. About the slide See Page 33
Short-Circuit Keys
Before A pk * Id B pk fk * * Id A_id C pk * Id fk * B_id
Create a new foreign key from the lowest detail to the highest master. A After pk * Id B pk fk * * Id A_id C pk * Id fk * B_id fk * A_id
8-15
Appropriate When queries frequently require values from a grandparent and grandchild, but not from the parent Advantages Queries join fewer tables together Disadvantages Extra foreign keys are required Extra code is required to make sure that the value of the denormalized column A_id is consistent with the value you would find after a join with table B.
Short-Circuit Keys .........................................................................................................................................
EMail Example of Short-Circuit Keys

Before USERS (USR) pk * Id * Name FOLDERS (FDR) pk fk * Name * Usr_id RECEIVED_ MESSAGES (RME) pk fk * * Id Fdr_name
Create a new foreign key from the lowest detail to the highest master. After USERS (USR) pk * Id uk * Name FOLDERS (FDR) pk fk * Name * Usr_id RECEIVED_ MESSAGES (RME) pk * Id fk * Fdr_name fk * Usr_name
8-16
Example Suppose frequent queries are submitted that require data from the RECEIVED_MESSAGES table and the USERS table, but not from the FOLDERS table. To avoid having to join USERS and FOLDERS, the primary or a unique key of the USERS table can been migrated to the RECEIVED_MESSAGES table, to provide information about USERS and RECEIVED_MESSAGES with one less, or no, table join.
......................................................................................................................................... 8-17
End Date Columns

The most common denormalization decision is to store the end date for periods that are consecutive; then the end date for a period can be derived from the start date of the previous period. If you do this, to find a detail record for a particular date you avoid the need to use a complex subquery. About the slide See Page 33
End Date Column

Before B A pk * Id pk,fk pk * * A_id Start_date
Add an end date column to speed up queries so that they can use a between operator. B After pk,fk pk * * * A_Id Start_date End_date
8-17
Appropriate When queries are needed from tables with long lists or records that are historical and you are interested in the most current record Advantages Can use the between operator for date selection queries instead of potentially timeconsuming synchronized subquery Disadvantages Extra code needed to populate the end date column with the value found in the previous start date record
End Date Columns .........................................................................................................................................
Example of End Date Column

Before PRODUCTS (PDT) pk * * Id Name PRICES (PCE) pk,fk pk * * * Pdt_id Start_date Price
Create an extra column derivable End_date column.
After
PRICES (PCE) pk,fk pk * * *

o
Pdt_id Start_date Price End_date
8-18
Example When a business wishes to track the price history of a product, they may use a PRICES table that contains columns for the price and its start date and a foreign key to the PRODUCTS table. To avoid using a subquery when looking for the price on a specific date, you could consider adding an end date column. You should then write some application code to update the end date each time a new price is inserted. Compare:
...WHERE AND pdt_id = ... start_date = ( SELECT max(start_date) prices start_date <= sysdate pdt_id = ... FROM WHERE AND )
and
...WHERE pdt_id = ... AND sysdate between start_date and nvl(end_date, sysdate)
Note that the first table structure presupposes that products always have a price since the first price start date of that product. This may very well be desirable but not always the case in many business situations. Note also that you would need code to make sure periods do not overlap.
......................................................................................................................................... 8-19
Current Indicator Column

This type of denormalization can be used in similar situations to the end date column technique. It can even be used in addition to an end date. It is a very common type of denormalization. Suppose most of the queries are to find the most current detail record. With this type of requirement, you could consider adding a new column to the details table to represent the currently active record. You would need to add code to update that column each time you insert a new record. About the slide See Page 33
Current Indicator Column

Before A pk * Id B pk,fk * A_id pk * Start_date
Add a column to represent the most current record in a long list of records . After B pk,fk pk * A_Id * Start_date o Current_indicator
8-19
Appropriate When the situation requires retrieving the most current record from a long list Advantages Less complicated queries or subqueries Disadvantages Extra column and application code to maintain it The concept of current makes it impossible to make data adjustments ahead of time
Current Indicator Column .........................................................................................................................................
Example of Current Indicator Column

Before PRODUCT (PDT) pk * * Id Name PRICES (PCE) pk,fk pk * * * Pdt_id Start_date Price
Add a column to represent the most current record, in a long list of records. PRICES (PCE) After pk,fk * Pdt_id pk * Start_date * Price o Current_indicator
8-20
Example In the first table structure, when the current price of a product is needed, you need to query the PRICES table using:
...WHERE pdt_id = ... AND start_date = ( SELECT FROM WHERE AND ) max(start_date) prices start_date <= sysdate pdt_id = ...
The query in the second situation would simply be:

...WHERE pdt_id = ... AND current_indicator = Y
......................................................................................................................................... 8-21
Hierarchy Level Indicator

Suppose there is a business limit to the number of levels a particular hierarchy may contain. Or suppose in many situations you need to know records that have the same level in a hierarchy. In both these situations, you will need to use a connect-by clause to traverse the hierarchy. This type of clause can be costly on performance. You could add a column to represent the level of a record in the hierarchy, and then just use that value instead of the connect-by clause in SQL. About the slide See Page 33
Hierarchy Level Indicator

Before A pk fk * * Id A_id
Create a column to represent the hierarchy level of a record.
After
A pk fk * Id * A_id * Level_no
8-21
Appropriate When there are limits to the number of levels within a hierarchy, and you do not want to use a connect-by search to see if the limit has been reached When you want to find records located at the same level in the hierarchy When the level value is often used for particular business reasons Advantages No need to use the connect-by clause in query code Disadvantages Each time a foreign key is updated, the level indicator needs to be recalculated, and you may need to cascade the changes
Hierarchy Level Indicator .........................................................................................................................................
Example of Hierarchy Level Indicator

Before FOLDERS (FDR) pk * Id fk * Fdr_id * Name Create a column to represent the hierarchy level of a record.
After
FOLDERS (FDR) pk * fk * * * Id Fdr_id Name Level_no
8-22
Example Imagine that because of storage limitations, a limit has been placed on the number of nested folders. Each time a user wants to create a new instance of a folder within an existing folder instance, code must decide if that limit has been reached. This can be a slow process. If you add a column to indicate at what nested level a FOLDER is, then when you create a new folder in it, you can decide immediately if this is allowed. If it is, the level of the new folder is simply one more than the level of the folder it resides in.
......................................................................................................................................... 8-23
Denormalization Summary
Denormalization is a structured process and should not be done lightly. Every denormalization step will require additional application code. Be confident you do want to introduce this redundant data.
Denormalization Summary
Denormalization Techniques
Storing Derivable Information

End Date Column Current Indicator Hierarchy Level Indicator

8-23
Pre-Joining Tables Hard-Coded Values Keeping Detail with Master Repeating Single Detail with Master Short-Circuit Keys
Practice 81: Name that Denormalization .........................................................................................................................................
Practice 81: Name that Denormalization

Moonlight Coffees
Goal (See Page 34) Learn to discriminate the type of denormalization depicted.
Your Assignment For the following table diagrams, decide what type of denormalization is used and explain why the diagram depicts the denormalization you have listed. Use one of: Storing derivable information Pre-Joining Tables Hard-Coded Values Keeping Details with Master Repeating Single Detail with Master Short-Circuit Keys
1
WEEKDAYS (WDY) pk * * Code Name SHIFTS (SFT) pk * No fk Wdy_code * Start_time * End_time * Wdy_name *
2
PROD_GRPS (PGP) pk * Name PRODUCTS (PDT) pk fk * Code * Pgp_Name PROD_NAMES (PNE) pk fk fk * * * Name Pdt_code Pgp_name
3
PRICE_LISTS (PLT) COUNTRIES (CTY) pk * Code * Name pk,fk pk * Cty_code * Start_date o End_date * Current_price_ind
......................................................................................................................................... 8-25
Practice 82: Triggers

Goal (See Page 35) The purpose of this practice is to investigate which database triggers are needed to handle a suggested denormalization. Your Assignment 1 Indicate which triggers are needed and what they should do to handle the denormalized column Order_total of ORDER_HEADERS.
ORDER_HEADERS (OHR) pk * * Id Order_total
ORDER_ITEMS (OIM) pk * Ohr_id pk * Seqno * Item_total
Table OHR
Trg Type Insert Delete Update
Column
Needed? What should it do?
Id Order_total
OIM
Insert Delete Update Ohr_id Item_total
8-29
Practice 82: Triggers .........................................................................................................................................
2 Indicate which triggers are needed and what they should do to handle the
denormalized column Lcn_address of EMPLOYEES.
LOCATIONS (LCN) pk * * Id Address
EMPLOYEES (EPE) pk * Id fk * Lcn_id * Name * Lcn_address
Table LCN
Column
Address
other cols
EPE Insert Delete Update Lcn_id Lcn_address
8-31
......................................................................................................................................... 8-27
3 Indicate which triggers are needed and what they should do to handle the
denormalized column Curr_price_ind of table PRICES.
PRODUCTS (PDT) pk * * Id Name
PRICES (PCE) pk * Pdt_id pk * Start_date o End_date * Curr_price_ind
Table Trg Type Column PDT Insert Delete PCE Insert Delete Update Pdt_id Start_date End_date Curr_price_Ind
8-33
Practice 83: Denormalize Price Lists .........................................................................................................................................
Practice 83: Denormalize Price Lists

Moonlight Coffees
Goal (See Page 36) The aim of this practice is to decide on the type of denormalization you could use, and what code is needed to ensure database integrity.
Scenario End users have started to complain about query performance. One of the areas where this is particularly noticeable is when querying the price of a global product. Since there is a large list of records in the GLOBAL_PRICES table, and it needs to be joined with the PRICE_LISTS table, it is not surprising the queries can take a long time. Optimizing the queries using other techniques have failed to result in acceptable response times.Therefore the decision is to use some denormalization to correct this problem. The corporate office also has another concern. They would like to notify the local shops of any new price list changes of global products, prior to their effective date. They would like to enter the new price list information when it is decided, not when the start date is reached. You need to add provision to alleviate this restriction. Your Assignment Describe what type of denormalization you would implement and what code you would add to ensure the database does not lose any integrity. The next diagram shows the current table schema. Consider both issues described above when deciding which types of denormalization to implement.
PRICE_LISTS (PLT) pk * Start_date pk,fk * Cty_code
GLOBAL_PRICES (GPE) pk,fk * Plt_start_date pk,fk * Plt_cty_code * Amount
......................................................................................................................................... 8-29
Practice 84: Global Naming

Moonlight Coffees
Goal (See Page 36) To convert user requirements into denormalized table designs
Scenario The corporate office has decided to formalize English as the corporate language. Headquarters has asked the IS department to arrange for all global products to store their names in English. On the other hand, countries must be able to store their native language equivalent. Your Assignment Using the design below, denormalize the table design and describe the additional code that will allow this requirement to be implemented.
LANGUAGES (LGE) pk * Code * Name
PRODUCTS (PDT) pk * Code o Size
PRODUCT_NAMES (PNE) pk,fk * Pdt_code pk,fk * Lge_code * Name
Instructor Notes
Instructor Note Topic Timings Lecture 45 minutes Practice 15-45 minutes Total 60-90 minutes
8 8
D enorm alize d D ata
O verview
D e no rm aliza tio n B e ne fits T y p es o f d en o rm alizatio n
Set the scene. Define denormalization and explain the benefits. The majority of this lesson covers examples of denormalization. The presentation makes use of a generic table scheme. The matching slide of the e-mail system is only printed. You could consider reversing this. Emphasize you need to start with normalized data. As you denormalize the schema, you add redundancy and will need to write code to support the integrity of the database. The process of denormalization is ongoing, and you should consider adding or removing it, depending on the database performance. Just name the six types of denormalization, and explain there may be more, but these are the only ones we will cover in this course. Remember, any time you add redundancy to the schema, you denormalize, and will have to write (and maintain) code.
8 -2
D en orm alization O verview
De n o rm a liza tio n
S tarts w ith a n o rm a liz ed m od e l A d d s re d u n d an c y to th e d es ig n Re d u ce s th e in te g rity of th e d es ig n A p p lica tio n c od e a d d ed to c o m p en s ate
8 -3
D en orm alization Tec hnique s
S to rin g D eriva b le V a lu es P re-jo inin g T ab les H a rd -Co d e d V a lu e s K e ep in g D e tails w ith M as te r R e pe a ting S in g le D e ta il w ith M as ter S h ort-C irc u it K ey s
8 -4
......................................................................................................................................... 8-31
Storing D eriva ble V alues

B e fore A pk * * Id X B pk,fk * A _id pk * S equence_ N o * Q uanity
In all cases of denormalized data, you need code to prevent direct updates of the denormalized values. These should always be recalculated by the system. You will need to add code to B to make sure that any time records in B are inserted, updated, or deleted, the total_quantity is recalculated for every row in A that is referred to in an affected row of B. You will need to add code to the A table so that any time Col_a is changed all those corresponding denormalized values in the A_col_a column of table B are changed too.
A dd a colum n to store de rivable data in the refere nced end of the foreign key. A A fter pk * * * Id X Total_quantity
8 -5
Pre-Joining Ta ble s
B e fore A pk * * Id C ol_ a B pk fk * * Id A _id
A d d the non_key colum n to the table w ith the foreign key. B A fter pk fk * * * Id A _id A _col_a
8 -7
H ard-C od ed Value s
B efore A pk * * Id Type B pk fk * * Id A _ id
There must be code to check the values in the A_type column against the allowable values, regardless of how records are entered into the database.
R em ove the fo reign key and hard code the allow able valu es and validation in the application. B A fter pk * * Id A _Type
8 -9
K eeping D eta ils w ith M as te r

B e fore A pk * Id B pk,fk pk * * * A _id Type A m ount
A dd the repeating detail colum ns to th e m aster table. A A fter pk * * * * * * * Id Type1 A m ount_1 Type2 A m ount_2 Type3 A m ount_3
This is considered to be denormalized although there is no derivable information involved here. Code to check a condition for Amount1 must be repeated for Amount2 and so on.
8 -1 1
R epe ating C urrent D etail w ith M aster

B e fore B A pk * Id pk,fk pk * * * A _Id S tart_date P rice
A dd a colum n to the m aster to store th e m ost current details. A A fter p k * Id * C urrent_price
Code in B is required which fires when a record in B is updated or a new record is inserted in B. The code should find out if the new value has consequences for a Current_price in A and update column Current_price if so.
8 -1 3
Sh ort-C irc uit K ey s

B e fore A pk * Id B pk fk * * Id A _id C pk fk * Id * B _id
You need to have code on insert and update of the B table so that when the value of A_id changes, the column A_id in table C is updated correspondingly.
C reate a new foreign key from the low est detail to the highest m aster. A A fter pk * Id B pk fk * * Id A _id C pk fk fk * Id * B _id * A _id
8 -1 5
End D ate C o lum n

B e fore B A pk * Id pk,fk pk * * A _id S tart_date
A dd an e nd date colum n to spee d up queries so that they can use a betw een operator. B A fter pk,fk pk * * * A _Id S tart_date E nd_date
Add code to fire on the insert of the B table to take the value of the new Start_date record and populate the preceding End_date column. Note that the current B record for a record of A is not necessarily the record where B.End_date is NULL.
8 -1 7
C u rre nt Indicator C o lum n

B e fore A pk * Id B pk,fk pk * A _id * S tart_date
A dd a co lum n to represent the m ost current record in a long list o f records . A fter B pk,fk pk * *
o
A _Id S tart_d ate C urren t_indicator
8 -1 9
You will need code to fire on insert or update of B, to check if updates of the Current_indicator column are necessary and if so, set the new value. Note that usually two updates are needed: one to reset the record with Current _indicator = Y (the old current) and one to set the indicator of the new current record. The code should fire on insert and delete of the A table, and when the A.A_id column is updated. Level_no must be recalculated for the records of A which are affected.
H ie ra rchy Lev el Indicator

B e fore A pk fk * * Id A _id
C reate a colum n to represent the hierarchy level of a reco rd.
A fter
A pk fk * * * Id A _id Level_no
8 -2 1
......................................................................................................................................... 8-33
D en orm alization Su m m a ry
D e no rm aliza tio n Te c h niq u es
S to ring D eriva ble In fo rm atio n

E nd D ate C o lum n C u rren t In dicator H ie ra rch y Leve l In dicato r

8 -2 3
P re-Jo in in g T ab les H a rd -C o d e d V a lu e s K e ep in g D e tail w ith M a ster R e pe ating S in g le D e ta il w ith M as ter S h ort-C irc u it K ey s

Prac tices
N a m e th a t D en o rm a liza tio n T rigg ers D e no rm alize P rice L is ts G lo b al N am ing
Practice Name that denormalization Triggers Denormalize Price Lists Global Naming
3day Yes Yes opt opt
4day Yes Yes opt cha
8 -2 4
Practice : N a m e T hat D en orm alization (1/3 )
Practice 8-1 1 This practice should not take much time and can be done as a joint class activity.
W E E K D A Y S (W D Y ) pk * * C ode N am e
S H IFTS (S FT) pk No * fk W dy_co de * S tart_tim e * E nd_tim e * W dy_n am e *
8 -2 5
P R O D _G R P S (P G P ) pk * N am e
P R O D U C TS (P D T) pk fk * C ode * P gp_N a m e
P R O D _N A M E S (P N E ) pk fk fk * * * N am e P dt_code P gp_nam e
8 -2 6
P R IC E _LIS TS (P LT) C O U N TR IE S (C TY ) pk * C od e * N am e pk,fk pk * C ty_code * S tart_date o E nd_date * C urrent_price_in d
8 -2 7
Practice: Trigge rs (1/6)

O R D E R _H E A D E R S (O H R ) pk * * Id O rder_total O R D E R _ITE M S (O IM ) pk * O hr_id pk * S eqno * Item _total
Practice 8-2 1 It is important that the students are complete in the list of needed triggers and that they are confident about that. That takes away the fear of denormalizing from some and the nonchalance from others. Practice 8-2
8 -2 8

LO C A TIO N S (LC N ) pk * * Id A d dress E M P LO Y E E S (E P E ) pk * Id fk * Lcn_id * N am e * Lcn_address
8 -3 0
Practice 8-2
P R O D U C TS (P D T) pk * * Id Name P R IC E S (P C E ) pk * P dt_id pk * S tart_date o E nd_date * C urr_price_ind
8 -3 2
......................................................................................................................................... 8-35
T able PDT
T rg Ty pe In sert D elete
C o lum n
N ee ded ? W h at sho uld it do ?
PCE
In sert D elete U pd ate P d t_id S tart_da te E n d_d ate C u rr_p rice_In d
The triggers alone are not enough. As time goes by a new price may become current. The system needs a time-related mechanism to set the indicator, not just a mechanism that depends on DML operations.
8 -3 3
Prac tice: D en orm alize Price Lists

P R IC E _ LIS TS (P LT) pk * pk,fk * S tart_date C ty_ code G LO B A L_P R IC E S (G P E ) pk,fk * P lt_start_date pk,fk * P lt_cty_code * A m ount
Practice 8-3 If there is time, discuss the type of code needed to set the denormalized values.
S p ee d u p p erfo rm an c e fo r q u e rie s o n A m o u n t. Ins e rt n ew pric e lists b efo re the ir effec tive d ate .
8 -3 4
P ractice : G lo bal N am in g
LA N G U A G E S (LG E ) pk * C ode * N am e
Practice 8-4 If there time allows, discuss the type of code needed to set the denormalized value.
P R O D U C TS (P D T) pk *
o
P R O D U C T_N A M E S (P N E ) pk,fk * P dt_cod e pk,fk * Lge_co de * N am e
C ode S ize
8 -3 5

Name: Full Email:
Content
Type
Page Number
Note
......................................................................................................................................... 8-37
Suggested Graphics
......................................................................................................................................... 8-39
fold here
9
.................................
Database Design Considerations
Lesson 9: Database Design Considerations .....................................................................................................................................................
Introduction
Lesson Aim This lesson illustrates some principles of the Oracle RDBMS and presents the various techniques that can be used to refine the physical design. Schedule See page 36 About the slide See page 36
Overview
Oracle specific Design Considerations Data Integrity Issues Performance Considerations Storage Issues
9-2
Topic Introduction Reconsidering the Database Design Oracle Data Types Most Commonly-Used Oracle Data Types Column Sequence Primary Keys and Unique Keys Artificial Keys Sequences Indexes Choosing Columns to Index When Are Indexes Used?
See Page See page 2 See page 4 See page 5 See page 6 See page 7 See page 8 See page 11 See page 13 See page 16 See page 19 See page 21
Introduction .....................................................................................................................................................
Topic Views Use of Views Old-Fashioned Design Distributed Design Benefits of Distributed Design Oracle Database Structure Summary Practice 91: Data Types Practice 92: Artificial Keys Practice 93: Product Pictures
See Page See page 23 See page 24 See page 25 See page 27 See page 28 See page 29 See page 31 See page 32 See page 34 See page 35
Objectives At the end of this lesson, you should be able to do the following: Describe which data types to use for columns Evaluate the quality of the Primary key Use artificial keys and sequences where appropriate Define rules for referential integrity Explain the use of indexes Discuss partitioning and views Recognize old-fashioned database techniques Explain the principle of distributed databases Describe the Oracle database model
..................................................................................................................................................... 9-3
Reconsidering the Database Design

Each RDBMS has its own internal mechanism. This lesson discusses the major features provided by Oracle to get the best RDBMS performance. About the slide See page 36
Why Adapt Data Design?

Volumes Hardware Network O.S.
Initial design
User Expectations
Adapted Physical Design
9-3
Oracle specifics
You have to analyze a large number of parameters to obtain a correct adapted physical design from the initial design. Note the a correct, not the correct. Like many design issues, there is no absolute truth here. The points noted here are the most important onesthere are others. The expected volume of tables, the hardware characteristics like CPU speed, memory size, number of disks and corresponding space, the architectureclient/ server or three tier, the network bandwidth, speed, and the operating systems are determinants. User requirements are an other big issue. Depending on the response time, the GUI and the frequency of use of modules, they influence the objects that can be used in Oracle to cope with user expectations. Depending on the version of Oracle you are using, some elements may or may not exist.
Oracle Data Types .....................................................................................................................................................
Oracle Data Types

Oracle Data Types
Depending on:
About the slide See page 36
Domains Storage issue Performance Use
Select a data type for columns:
Character Number Date Large Objects

9-4
When you create a table or cluster, you must specify an internal data type for each of its columns. These data types define a generic domain of values that each column can contain. Some data types have a narrow focus, like number and date. Some data types are general purpose data types, like the various character data types. Some data types allow for variable length, some do not. Choosing a large fixed length for a column to store very few bytes for most of the rows can result in a huge table size. This may affect performance as a row may actually contain only a few bytes and yet be stored on multiple blocks, resulting in a great number of I/Os, and therefore decreasing performance. One cannot search against the Large Object Data Types; they cannot be used in a where clause. They are only retrievable by searching against other columns.
..................................................................................................................................................... 9-5
Most Commonly-Used Oracle Data Types

CHAR(size) These are fixed-length character data of length-sized bytes. Maximum size is 2000 bytes. Typical use: for official International Currency Codes which are a fixed three characters in length such as USD, FFR. VARCHAR2(size) Variable-length character string having maximum length-sized bytes. Maximum size is 4000, and minimum is 1. This is the most commonly-used data type and you should use it if you are not sure which one to use. It replaces the old Oracle version 6 CHAR data type. Typical use: for storing individual ASCII text lines of unlimited length ASCII texts on which you need to be able to search using a wildcard. NUMBER This data type is used for numerical values, with or without a decimal, of virtually unlimited size. Use this data type for data on which calculation or sorting should be possible. Avoid its use for numbers like a phone number, where the value does not have any meaning. Typical use: amount of money, quantities, generated unique key values. DATE Valid date range from January 1, 4712 BC to December 31, 4712 AD. A date data type also contains time components. You should use it only when you know the full date including day, month, and year. The time component is often set to 00:00 (midnight) in normal use of dates. Typical use: any date where the full date is known. LONG Character data of variable length up to 2 gigabytes. Obsolete since Oracle8. Was used for ASCII text files where you do not need to search using the wildcard or substring functionality. Use CLOB data type instead. Typical use: for storing the source code of HTML pages. LONG RAW Raw binary data of variable length up to 2 gigabytes. Obsolete since Oracle8. Was used for large object types where the database should not try to interpret the data. Use BLOB data type instead. Typical use: images or video clips. CLOB Character large object type. Replaces LONG. Major difference: a table can have more than one CLOB column where there was only one LONG allowed. Maximum size is 4 gigabytes. Typical use: see LONG. BLOB Character large object type. Replaces LONG RAW. Major difference: a table can have more than one BLOB column where there was only one LONGRAW allowed. Maximum size is 4 gigabytes. Typical use: see LONG RAW. BFILE Contains a locator to a large binary file stored outside the database to enable byte stream I/O access to external LOBs residing on the database server. Typical use: movies
Column Sequence .....................................................................................................................................................
Column Sequence
The sequence of columns in a table is relevant, although any column sequence would allow all table operations. The column sequence can influence, in particular, the performance of data manipulation operations. It may also influence the size of a table. About the slide See page 37
Suggested Column Sequence
Primary key columns Unique Key columns Foreign key columns Mandatory columns Optional columns Large object columns always at the end
9-5
The suggested optimal column sequence is the following: 1 Primary key columns 2 Unique key columns 3 Foreign key columns 4 Remaining mandatory columns * 5 Remaining optional columns *
*
In cases where the table contains a LONG or LONG RAW column, even if it is a mandatory column, make it the last column of the table. The rationale is that null columns should be at the end of the table; columns that are often used in search conditions should be up front. This is for both storage and performance reasons.
..................................................................................................................................................... 9-7
Primary Keys and Unique Keys

Primary Keys
CREATE TABLE countries ( code , name NUMBER(6) VARCHAR2(25) NOT NULL NOT NULL NOT NULL
, currency NUMBER (10,2) ); ALTER TABLE countries
ADD CONSTRAINT cty_pk PRIMARY KEY (code);
Constraint and Index name
9-6
Primary Keys They are a strong concept that is usually enforced for every table. They can be made up of one or more columns; each has to be mandatory. They are declarative as a constraint and can be named. When creating a primary key constraint, Oracle automatically creates a unique index in association with it. A foreign key usually refers to the primary key of a table, but may also refer to a unique key. Tables that do not have a primary key should have a unique key. Note: Although Oracle allows a primary key to be updated, relational theory strongly advises against this. Unique Keys A unique key is a key that for some reason was not selected to be the primary key. The reasons may have been: Allowed nulls. Nulls may be allowed in Unique keys columns. Updatable. Unique key values may change but still need to remain unique. For example, the home phone number of an employee or the license plate for a car. There may be more than one unique key for each table. Note: A Unique index is the additional structure Oracle uses to check the uniqueness of values for primary keys and unique keys. Creating a unique key results automatically in the creation of a unique index.
Primary Keys and Unique Keys .....................................................................................................................................................
How to Choose the Primary Key Following analysis there is a choice of what you want to use for a primary key. It does not have to be seen or known by the userit can do its work completely in the background. About the slide See page 37
Primary Keys
Choosing the Right Key Simplicity Ease of use Performance Size Meaningless Stability
9-7
Desirable Properties for Primary Key Simple: A primary key should be as simple as possible although Oracle8 allows it to consist of up to 32 columns. Primary key columns can be of various data types. Note that UIDs, as they arise from data analysis, are often composed, not simple. You need to consider replacing such a primary key by a simple key. Easy to Use: Primary keys are normally used in join statements, so a primary key should be easy to use. Writing a SQL statement to create a join between two tables is easier if two columns only, rather than a large number, are involved in the join predicate. Does Not Kill Performance: A join operation using a single key usually performs much better than a join using four key columns. Small Size: Large-sized primary keys lead to large-sized foreign keys referencing them. In general, the referencing table contains far more rows than the referenced table. An oversized primary key can lead to a multiple of unnecessary bytes.
..................................................................................................................................................... 9-9
Meaningless: You could, for example, choose to use the name of a country as a primary key, but even recent history has shown that countries may change their names. Opt for numeric values rather than character values, and if using numbers, avoid numbers with any particular meaning. Stable: You should try to avoid selecting a primary key that is likely to be updated. Bear in mind that it is very rare for real world things to stay stable for ever.
Artificial Keys .....................................................................................................................................................
Artificial Keys
An artificial key is a meaningless, usually numeric, value that is assigned to a record which functions as the primary key for the table. Artificial keys provide an interesting alternative to complex primary keys. Artificial keys are also called surrogate keys. About the slide See page 37
CS (C) pk * Id * C3
Artificial Keys
AS (A) pk * Id * C1 BS (B) pk * Id * C2
fk1 = d_a_fk
fk2 = d_b_fk
DS (D) u pk ,fk1 * A_id u pk ,fk2 * B_id u pk ,fk3 * C_id * C4 pk * Id
fk3 = d_c_fk
XS (X) pk fk1 fk1 fk fk1 * * ** *

o
Id D_a_id fk = x_d_fk D_b_id D_id D_c_id C5
9-8
Advantages Artificial keys have the following advantages over composed keys: The extra space that is needed for the artificial key column and index is less, often far less, than the space you save for the foreign key columns of referring tables. Join conditions consist of a single equation. The joins perform better. Internal references, which are completely invisible to the user, can be managed. The modeled UID can than be implemented as a unique key, and made updatable without needing cascade updates. Because they are meaningless, it is difficult to memorize them. Users will not even attempt this. Some people really like them. Disadvantages Disadvantages of artificial keys are: Because they are meaningless, they always require joins to collect the meaning of the foreign key column.
..................................................................................................................................................... 9-11
More space is required for the indexes, if you decide to create an additional unique key that consists of the original primary key columns. Because they are meaningless, it is difficult to memorize them. Users always need a list of values or other help for entering the foreign key values. Some people really hate them.
Deciding About Artificial Keys? Before Design Negative: It would corrupt your data model, as you would add elements that have no business meaning. Positive: There is a close mapping between the conceptual and technical model that reduces the chances of misunderstanding. After Design Positive: It really is a design decision based on current performance considerations. Tools like Oracle Designer let you decide about artificial keys during the initial mapping of the ER model. This is a nice compromise.
Sequences .....................................................................................................................................................
Sequences
Sequences
225 224
223
CREATE SEQUENCE sequence_name INCREMENT BY number START WITH number MINVALUE number MAXVALUE number CACHE number | NOCACHE CYCLE | NOCYCLE;
9-9
Some Sequence Characteristics A sequence is a database object that can generate a serial list of unique numbers for columns of database tables. A sequence provides the quickest way of generating unique numbers. Sequences simplify application programming by automatically generating unique numerical values that can be used as artificial key values. A sequence may be used to generate sequence numbers for any number of tables. Usually a separate sequence is created for each table with an artificial key, although there is no special need for that. A sequence guarantees generation of unique ascending or descending numbers. A sequence does not guarantee that all consecutive numbers are actually used.
..................................................................................................................................................... 9-13
Foreign Key By definition, Foreign Keys must refer to primary key or unique key values. You should consider what should happen if the primary key (or unique key) value changes. About the slide See page 38
Foreign Key Behavior
Delete Restrict Cascade
Update
Default / Nullify
Supported by Oracle through declaration
9-10
Referential Integrity There are two aspects to consider: The rules you want to implement to support business constraints The functionalities Oracle provides for these rules Relational theory describes four possible kinds of behavior for a foreign key. For every foreign key decide what kind of behavior you want it to have. The behaviors describe what the foreign key should do when the value of the key it refers to changes. Restrict Delete Restrict delete means that no deletes of a primary (or unique) key value are allowed when referencing values exist. This is supported by Oracle. This is the most commonly used foreign key behavior. Restrict Update Restrict update means that no updates of a primary (or unique) key value are allowed when referencing values exist. This is supported by Oracle. Note that this behavior is unnecessary in the case of artificial keys as these are probably never updated.
Sequences .....................................................................................................................................................
Note that restrict update is not the same concept as nontransferability. Restrict update prevents the update of a referenced primary key value. Nontransferability means that the foreign key columns are not updatable. Cascade Delete Cascade delete means that deletion of a row causes all rows that reference that row through a foreign key marked as cascade will be deleted automatically. Cascade delete is an option that Oracle supports. The complete delete operation will fail if, during the cascade, there is a record somewhere that cannot be deleted. This may happen if the record to be deleted is referred to through a restrict delete foreign key. Cascade delete is a very powerful mechanism that should be used with care. Cascade Update Cascade update means that after a primary key value is updated, this change is propagated to all the foreign key columns referencing it. Cascade update and nontransferability often come together. Default and Nullify The default and the nullify option mean that on delete or update of the primary key value, the related foreign key values will acquire a default value or will be set to NULL. These options can be implemented by creating an update database trigger on the table referred to by the foreign key. Clearly, the nullify option is only valid if the foreign key is optional. Typical Use Usually, many foreign keys are defined as restrict delete. This does not prevent the referred record being deleted; it just forces the user to consciously remove or transfer all referring rows. Of course, when you use artificial keys you can set all foreign key update properties to restrict as there will never be a good reason for updating an artificial key value.
..................................................................................................................................................... 9-15
Indexes
Indexes are database structures that are stored separately from the tables they depend on. In a relational database you can query any column, independently of the existence of an index on that column. About the slide See page 38
Indexes
Performance
Name ALBERT ALFRED ALICE ALLISON ALVIN ALPHONSO Phone
b
2655 3544 7593 3456 8642 2841
c d ef gh ij kl m no pq rs tu vw xyz
9-11
Uniqueness
Indexes are used for two reasons: To speed up queries To ensure uniqueness if required Performance Indexes are created to provide a fast method to retrieve values. However, indexes can slow down performance on DML statements. Oracle provides a wide range of index types. You must choose the type which is suitable for its intended use. Uniqueness A unique index is an efficient structure to ensure that the values are not duplicated within the set of columns included in the index. Unique indexes are automatically created when you create a primary or unique key. The name of the index in that case is the same as the name of the key constraint.
Indexes .....................................................................................................................................................
Index Types About the slide See page 38
Choosing Indexes
B*tree Bitmap
aba .1.2.5 abb .1.4.5 bba .1.3.5 cba .1.1.5 ...
aba .1.2.5 abb .1.3.5 abc .1.1.5 bba .1.4.5 ...
Reverse
X 0 1 0 1 0
Y 1 0 0 0 0
Z 0 0 1 0 1
C1
aba abb abc bba bbc
9-12
C2
X Z Y Z X
I.O.Table
C1
abc aba abb bba bbc
C2
Y X Z X Z
B*Tree The classical structure of an index, if not explicitly specified otherwise, is the B*Tree (also known as Tree balanced) index. It is specially designed for online transaction processing systems. They have a proven efficiency and Oracle has offered them for some time. They easily support insert, update, and delete. Typical use: General purpose
Reverse Key Based on that classical structure of the B*Tree, Oracle offers a reverse key index which has most of the properties of the B*Tree but in which the bytes of each indexed column are reversed. Typical use: In an Oracle Parallel Server environment, where such an arrangement can help avoid performance degradation in indexes Bitmap A bitmap index stores for each individual value of the indexed column, if a row contains this value or not. Typical use: Data warehouse environment. Bitmap indexes have a proven efficiency in On Line Analytical Process systems when ad-hoc queries can be intensive and the number of distinct values for the indexed column is not high.
..................................................................................................................................................... 9-17
Bitmap indexes require less space than a B*Tree index but they do not support inserts, updates, and deletes as well as a B*Tree. Index Organized Table An index organized table is a table that contains rows that are stored in an ordered way, using the B*Tree technique. It provides the speed that indexes provide and does not require a separate index. The only restriction in its use is that you cannot create additional indexes for this Index Organized table. Typical use: Tables that are always accessed through exactly the same path, in particular when storing large objects. Concatenated Index You can create an index that includes more than one column. These are called concatenated indexes. The order in which you specify the columns has a strong impact on the way Oracle can use the index. Set the column that is always in a Where clause as the first column of the index. This is called the leading part of the index. Function Based Index Since Oracle8i it is possible to create an index based on a SQL function. Typical use: Create an index on the first three characters of a name using the substr function or the year component of a date using the to_char function.
Choosing Columns to Index .....................................................................................................................................................
Choosing Columns to Index

Which Columns to Index?
Primary key columns and Unique Key columns (Up to Version 6) Foreign Key columns When significant better performance can be observed in SELECT statements
!

9-13
Avoid indexing:
Small tables Columns frequently updated
Candidate Columns for Regular B*Tree Indexing Columns used in join conditions to improve performance on joins Columns that contain a wide range of values Columns that are often used in the Where clause of query Columns that are often used in an Order By clause of a query Candidate Columns for Bitmap Indexing Columns that have few distinct values such as, for example, a column containing indicator values (Y/N) or a column for gender Columns Less Suitable for Indexing Columns that contain many NULL values where you usually search rows with the NULL values Columns that Cannot or Should Not be Indexed LONG and LONG RAW columns cannot be indexed Columns that are hardly ever used in Where / Order By clauses Small tables occupying only few data blocks
..................................................................................................................................................... 9-19
Temporary Indexes Indexes can be created and dropped for a particular incidental use. For example, you can decide to create an index right before a report is run and then drop it afterwards. General Recommendations Limit the number of indexes per table. Although a table can have any number of indexes this does not necessarily improve performance; the more indexes, the more overhead is incurred when there are updates or deletes. As a rule of thumb, if there is any doubt, do not create the index. You can always create it later. It is very likely that the initial set of indexes will have to change after some time, because of changes of the characteristics of the system. Typically, the number of different values in a column can initially be very low but increase during the life cycle of a system. Initially, an index would not be of value but it would be later.
When Are Indexes Used? .....................................................................................................................................................
When Are Indexes Used?

When Can Indexes be Used?
When referenced in a Where clause or Order By When the Where clause does not include some operators When the optimizer decides With hints in the SQL statement
9-14
You may have created an index to improve performance but without seeing any benefits. For Oracle to use them, indexed columns need to be referenced in the Where clause of a SQL statement, or in the order by, while the Where clause must not include the following: IS NULL IS NOT NULL != LIKE When the column is affected by an operation or function (unless you use a function-based index and the condition uses the same function) For example, suppose column X contains many nulls and a few numeric, positive values. Suppose queries often select all rows having a NOT NULL value. Finally, suppose an index is created on X. In this case, the condition WHERE X > 0 is preferable to WHERE X IS NOT NULL because in the first situation Oracle would use an index on X and in the second Oracle would not. Yet, even if it was written in this way, it is the optimizers choice to decide whether to use indexes or not. The decision is based on rules or on statistics.You can stimulate the optimizer to use indexes using hints in your SQL statements.
..................................................................................................................................................... 9-21
Table Partitioning Oracle provides an interesting feature to solve performance and administration problems on tables with a large number of rows. About the slide See page 39
Partitioning Tables and Indexes

CUSTOMERS
Col1 Col2 Col3 Region
CUSTOMERS_R1
CUSTOMERS_R2
9-15
Partitioned Table Since Oracle8, when creating a table, you can specify the criteria on which you want to divide the table and make a horizontal partitioning. There are then as many partitioned tables as there are distinct values in the column. Each partitioned table has a specific name but access is made referring to the global name of the table. The optimizer then decides which partition to access, depending on the value of the Where clause. The main issue of this feature is to manipulate considerably smaller pieces of data and then improve the speed of SQL statements. Suppose you want to query on customers located in a specific region, Oracle does not need to access all rows of the CUSTOMERS table but can limit its search to the piece holding all customers of this region only. Logically, the table behaves as one object; physically, data is stored in different places. Partitioned Index Using the same idea, an index may be partitioned. It does not need to match with the table partitioning. It may have different partitioning criteria and have a different number of partitions to the table. This may be useful in the situation where the answer to particular queries can always be found in the partitioned index.
Views .....................................................................................................................................................
Views
A view is a window onto the database. It is defined by a SELECT statement which is named and stored in the database. Therefore a view has no data of its ownit relays information from underlying tables. About the slide See page 39
T4
Views
T1 T2 T3
V1
V2
V3
V4

9-16
Restricting access Presentation of data Isolate applications from data structure Save complex queries Simplify user commands
Usages of Views Restricting access: The view mechanism is one of the possible ways to hide columns and rows from the tables it is based on. Presenting data: A view can be used to present data in a more understandable way to end-users. For example, a view can present calculated data built from elementary information that is stored in tables. Isolating application from data structures: Applications may be based on views rather than tables, where there is a high risk that the structure might change. If a view is used, the application would need no maintenance providing the view remains untouched, even though the underlying tables were modified. Saving complex queries and simplifying commands: Views can be used to hide the complexity of the data structure, allowing users to create queries over multiple tables without having to know how to join the tables together. Simplifying user commands.
..................................................................................................................................................... 9-23
Use of Views
Reasons for Views
Advantages
Dynamic views Present denormalized data from normalized tables Simplify SQL statements
Disadvantages
May affect performances Restricted DML in some cases
9-17
Advantages You can use a view to present derived data to end users without having to store them in the database. Typically, you would show completely denormalized, prejoined information in views that would allow end users to write simple SELECT statements like SELECT * FROM ... WHERE ... Views can be made dynamic, for example, showing data that depend on which user you are or what day it is. For example, you could create a view that shows localized help messages. According to the user name, the system can find the preferred language in a PREFERENCES table and next return a message in this language. A single view returns different values depending on the name of the user. Another example type of view can be used to allow a user to access data between 8:00 am and 6:00 pm on weekdays only. Disadvantages Views are always somewhat slower, which is due to the fact that the parse time is slightly longer. Once a table and its columns are found, the query can be immediately executed. Query criteria are linked with and to the criteria of the view. This can affect the execution plan generated by the optimizer. Even if views behave almost like tables, there are still some restrictions when using views for insert, update, and delete statements.
Old-Fashioned Design .....................................................................................................................................................
Old-Fashioned Design
Going through existing systems, you may find some old-fashioned design techniques. These techniques were used at the time the RDBMS features were not so advanced. About the slide See page 40
Old Fashioned Design
Unique index Views with Check option clause Generic Arc implementation
9-18
Unique Index Unique Indexes used to be created manually on the primary key columns because the primary key constraint could not be declared up to Oracle7. Check Option Views In earlier versions of Oracle, it was not unusual to create a view with a check option. These views, now obsolete, could be used to some extent to enforce data integrity and referential integrity before Oracle7. There is no functionality in a view with a check option that cannot be coded in a database trigger. The declaration of integrity constraints and coding of database triggers is now the preferred way to handle this.
..................................................................................................................................................... 9-25
Generic Arc Implementation About the slide See page 40
Generic Arc Implementation

A # Id * Name X # Id * Name Y # Id * Name
AS (A) ...
* Table_name * Fk_id
(X or Y)
9-19
The generic arc implementation is a fossil construction you may find in old systems. In the implementation of the arc of entity A in the example, the three relationships in the arc were merged into one generic foreign key column Fk_id. Added to table AS is a NOT NULL column that keeps the information about which table the foreign key value refers to. This used to be a popular technique because it could make use of a NOT NULL constraint on Fk_id when the arc was mandatory. This solution for implementing arcs should now be avoided for the following limitations: Since Oracle7 the arc can now be implemented by simply declaring two foreign keys and writing one check constraint. The joins may be very inefficient as, in many cases, you would need the timeconsuming union operator:
select from where union select from where A.Name, Y.Name, Y AS A, YS Y ... A.Name, X.Name, X Type AS A, XS X ...
Foreign key constraint for the foreign key column cannot be declared since it cannot reference more than one primary key.
Distributed Design .....................................................................................................................................................
Distributed Design
This is characterized as many physical databases, located at different nodes, but appearing to be a single logical database. About the slide See page 40
Distributed Database
Different physical databases appear as one logical database
9-20
Characteristics Multiple physical databases One logical database view Possibly dissimilar processors Kernel runs wherever a part of the database exists The multiple physical databases are not necessarily copies of each other or part of each other. You can decide on how to spread the individual table content across the different databases on the different partitioning principles. You can decide for a vertical or horizontal technique, or a combination of both.
..................................................................................................................................................... 9-27
Benefits of Distributed Design

Benefits of Distributed Databases
Resilience Reduced line traffic Location transparency Local autonomy Easier growth path Increased, distributed, complexity
but
9-21
Improved flexibility and resilience. Access to data is not dependent on only one machine or link. If there is any failure then some data is still accessible on the local nodes. A failing link can automatically be rerouted via alternative links. Improved response time by having the data close to the usual users of the data. This may reduce the line traffic dramatically. For example, in the model of ElectronicMail, it is very likely that each country will have its own database. This database will store in its own messages table the messages that belong to the people registered in that country. Location transparency allows the physical data to be moved without the need to change applications or notify users. Local autonomy allows each of the physical databases: To be managed independently. To have definitions and access rights created and controlled locally. An easier growth path is achieved: More processes can be added to the network More databases can be included on a node. Software update is independent of physical structure.
Disadvantage A major disadvantage of distributed design is the often very complex configuration: with the data the complexity is also distributed. System maintenance is complicated.
Oracle Database Structure .....................................................................................................................................................
Oracle Database Structure

DATABASE
Database Structure
consists of part of TABLESPACE consists of part of resides container in SEGMENT of OTHER TABLE INDEX SEGMENT SEGMENT SEGMENT sliced in sliced in located in part of part of TABLE OR INDEX PARTITION
EXTENT USED
consists of part of
FREE
residence of
DATA FILE
consists of
resides in residence of
part of DATA BLOCK
9-22
Tablespaces The diagram shows the structure of a Oracle database. An Oracle database consists of one or more tablespaces. Each tablespace can hold a number of segments, and each segment must be wholly contained in its tablespaces. The SYSTEM tablespace is created as part of the database creation, and should be reserved for the Oracle Data Dictionary and related tables only. You should not create application data structures in this tablespace. You are advised to create separate tablespaces for different types of segments. Segments A segment is the space occupied by a database object. There are three types of segments: a table segment, an index segment or an other segment, that is used for clusters. Only the other segments must be part of one tablespace. Partitions Usually, a segment is assigned to a single tablespace. However, with Oracle8 it is possible to spread a table or index segment into more than one tablespace. This technique is called partitioning. A partition is the part of a table segment (or index segment) that resides in one tablespace.
..................................................................................................................................................... 9-29
Extents Each time more space is needed by a segment, a number of contiguous blocks is allocated as an extent. There is no maximum limit on the number of extents that can be allocated to a segment. It is usually preferable to avoid an excessive number of small extents by ensuring that the segment has a sufficiently large initial extent. Data Files Data files are the operating system files that physically contain the database data. Data files consist of data blocks. Data Blocks A data block is the smallest amount of data Oracle reads in one read operation. A data block always contains information from one extent only. There is a distinction between the logical table, made up of rows with columns, and the physical table, taking space that is made up of database blocks organized in extents and located in data files.
Summary .....................................................................................................................................................
Summary
Summary
Data Types Primary, Foreign, and Artificial Keys Indexes Partitioning Views Distributed design
9-23
Oracle provides a large choice of data types for the columns of the tables. Primary keys are needed for tables. Artificial keys can be a good solution to implement complex primary keys. Indexes improve performance of queries and provide a mechanism for guaranteeing unique values. Partitioning tables can also be a solution to performance problems. Views are a flexible, secure, and convenient object for users. Distributed Design is a complex technique. It allows data to be located closer to the user.
..................................................................................................................................................... 9-31
Practice 91: Data Types

Moonlight Coffees
Goal (See page 41) The purpose of this practice is to perform a quality check on proposed data types.
Scenario Use the model that illustrates Moonlight pricing.

CURRENCY # Code
of with
COUNTRY # Code
Moonlight Pricing
with
in from to
in
with
in
with in
PRODUCT
EXCHANGE RATE # Month * Rate
of
LOCAL # Name
with SHOP # No * Name * Address * City
for
PRICELIST # Start Date * End Date
GLOBAL # Code o Size
with of
LOCAL PRICE # Start Date o End Date * Amount LANGUAGE # Code
with in
with of
with
of
of in
PRODUCT NAME * Name

9-25
Practice 91: Data Types .....................................................................................................................................................
Your Assignment 1 Here you see table names and column names and the suggested data type. Do a quality check on these. If you think it is appropriate, suggest an alternative.
Table COUNTRIES CURRENCIES EXCHANGE_RATES PRICE_LISTS PRODUCT_GROUPS PRODUCTS
Column Code Code Month Rate Start_date End_date Name Code Size Pdt_type
Suggested Data Type Varchar2(2) Varchar2(3) Date Number(8,4) Date Date Char(8) Char(10) Number(4,2) Number(1)
Your Choice Data Type
2 Suggest data types for the following columns. They are all based on previous
practices.
Table GLOBAL_PRICES LOCAL_PRICES SHOPS
Column Amount Start_date End_date Amount Name Address City
Your Choice Data Type
3 What data type would you use for a column that contains times only?
..................................................................................................................................................... 9-33
Practice 92: Artificial Keys

Moonlight Coffees
Goal (See page 42) You are coming to the end of your contract for Moonlight Coffees. The job is almost finished!
Scenario You need to make decisions on possible artificial keys for some of the Moonlight tables. The model is the same as the one used in the previous practice. Your Assignment 1 Indicate for each table if you see benefits of creating an artificial key and why. COUNTRIES GLOBAL_PRICES PRICE_LISTS
2 For which tables (if any) based on the Moonlight model does it not make any sense
at all to create artificial keys?
Practice 93: Product Pictures .....................................................................................................................................................
Practice 93: Product Pictures

Moonlight Coffees
Goal (See page 42)
The purpose of this practice is to modify a design to serve new requirements. Scenario This is your last task for Moonlight coffees. Tomorrow you are free to forget all about Moonlight and only drink coffee! The decision has been made to make the first steps into the e-commerce market. One objective is to allow customers to consult Moonlights website. This site should provide product information. For each product at least two additional attributes have been identified. The first is the attribute Picture for images of the products. The second is an attribute HTML Document that holds the product description that can be displayed with a browser. Other attributes may follow. Your Assignment 1 Decide what data type you would advise to be used for each column. 2 You have heard that an old Oracle version would not accept more than one long type column per table. You are not sure if this is still a limitation. Advise about the implementation.
..................................................................................................................................................... 9-35
Instructor Notes
Instructor Note Topic Timings Lecture 45-60 minutes Practice 15-30 minutes Total 60-90 minutes
9 9
D ataba se D e sign C on sid eration s
O verview
O ra cle sp ec ific D es ig n C o n s id eratio n s D ata In teg rity Is su e s P e rfo rm a nc e C o n sid e ra tio n s S to ra ge Iss u es
9 -2
This chapter deals with Oracle in particular. The suggestions made here are directly influenced by properties and behavior of the Oracle database. Some of the objects discussed here, such as sequences, do not exist in other databases; the various database systems use different ways to organize memory and the various optimizers do not behave in the same way. These parameters are generic ones. Many more exist behind each one.
W hy A dapt D ata D e sign?

V o lu m e s H a rd w a re N e tw o rk O .S .
Initial design
U s er E x pe cta tion s
A d a p ted P h ys ic al D e sig n
9 -3
O rac le sp e cific s
O rac le D a ta T ypes
D ep e n d in g o n :
D o m a in s S to ra g e is su e P erfo rm a n ce Use C h arac te r Num ber D a te L a rg e O b je cts
Be aware of restrictions that may apply according to the programming language used for coding applications. You may have problems with large object type data types.
S e le ct a d a ta typ e fo r c o lu m n s:

9 -4
This sequence is suggested by Oracle CDM.

Sug gested C olum n Seq uenc e
P rim a ry ke y co lu m n s U n iq u e K ey c o lu m n s F o re ig n k ey c o lu m n s M an d ato ry co lu m n s O ptio n a l c o lu m n s L a rg e o bjec t co lum n s a lw ays a t th e e n d
9 -5
P rim ary K e ys
C R E A TE TA B LE countries ( code , nam e N U M B E R (6) V A R C H A R 2(25) N O T N U LL N O T N U LL N O T N U LL
Up to release 6 of Oracle, users had to create the unique indexes for Primary keys manually.
, currency N U M B E R (10,2 ) ); A LTE R TA B LE countries
A D D C O N S TR A IN T cty_pk P R IM A R Y K E Y (code );
C on strain t an d Inde x n am e
9 -6
P rim ary K e ys
C h oo sin g the R igh t K ey S im plicity E a se o f u se P e rfo rm a nce S ize M ean in gles s S tability
9 -7
Since Oracle8, 32 columns can be concatenated in an index. Prior to Oracle8 the limit was 16 columns. When you use a meaningful primary key, it is most likely that you may have to update it some day. If this happens once during the life cycle of a system it may not be a problem, but if it happens far more frequently, you should reconsider the choice. There are a lot of advantages in choosing artificial keys, but it should be a wellconsidered choice, not an automatism.
A rtificia l K e ys
A S (A ) pk * Id * C1 B S (B ) pk * Id * C2 C S (C ) pk * Id * C3
fk 1 = d_a_fk
fk 2 = d_ b_fk
D S (D ) u pk ,fk 1 * u pk ,fk 2 * u pk ,fk 3 * * pk * A _id B _id C _id C4 Id
fk 3 = d_c _fk
X S (X ) pk fk1 fk1 fk fk1 * * ** *

o
Id D _a_id D _b_id _id D _c_id C5
fk = x_d_fk
9 -8
..................................................................................................................................................... 9-37
S equ ence s
2 25 2 24
2 23
C R E A TE S E Q U E N C E se quence_nam e IN C R E M E N T B Y nu m ber S TA R T W ITH nu m ber M IN V A LU E nu m ber M A X V A LU E nu m ber C A C H E num ber | N O C A C H E C Y C LE | N O C Y C LE ;
Sequences are specific to Oracle. If, for some reason, no gap between numbers is allowed (other than the gap explicitly chosen by the value of increment by), you need to use a different mechanism.
9 -9
Foreign K e y B eh avior
D ele te R e strict C a scade
U pdate
This is relational theory. Nullify can be seen as a special case of Default. Oracle supports all through coding, the marked ones can be declared.
D e fault / N ullify
Su pp orted b y O racle th ro u gh de claration
9 -1 0
Inde xes
P erfo rm an ce
N am e A LB ER T A LF R E D A LIC E A LL IS O N A LV IN A LP H O N S O P hone
b
26 55 35 44 75 93 34 56 86 42 28 41
c d ef gh ij kl m no pq rs tu vw xyz xy z
9 -1 1
U niqu en ess
Indexes are very a very powerful means to improve performance. Nevertheless, it is always a matter of balancing between better performances on queries on one side and poorer DML statements on the other. Usually only few indexes are created when a system goes live. During the life cycle of a system indexes are added if performance so dictates. The function-based index is not represented here (the reverse index can be seen as a special case). Note that delegates may assume that table data are always stored in an ordered way.
C hoos in g Ind exes

B *tree B itm ap
a ba a bb bb a c ba ... .1 .2.5 .1.4 .5 .1.3 .5 .1 .1.5
a ba a bb a bc b ba ...
.1 .2.5 .1 .3 .5 .1 .1.5 .1 .4 .5
R everse
X 0 1 0 1 0
Y 1 0 0 0 0
Z 0 0 1 0 1
C1
aba abb abc bb a bb c
9 -1 2
C2
X Z Y Z X
I.O .Table
C1
ab c ab a ab b bb a bb c
C2
Y X Z X Z
W hich C olum ns to Ind ex?
P rim a ry ke y co lu m n s a n d U n iq u e K ey co lum n s (U p to V e rs io n 6) F o re ig n K e y c o lu m n s W h e n sig n ific a nt b e tte r p e rfo rm an c e ca n b e o b s erv ed in S E L E C T s ta tem e n ts
General rule: start with a few indexes and add new ones when necessary. Some of the best performance improvements have been accomplished by dropping excessive indexes.
!

9 -1 3
A vo id in dexin g:
S m a ll ta bles C o lum n s fre q u en tly u p d ated
W he n C an Inde xes be U s ed?
To force the use of indexes, you can use hints. For example, you can use the following syntax:
SELECT /*+ INDEX (employees I_name) */ Id , name , address FROM employees WHERE name > L;
W h e n re fe ren ced in a W h ere c lau s e or O rd e r B y W h e n th e W h ere c la u se d o es n o t in c lu d e so m e o pe ra to rs W h e n th e o p tim izer d ec id es W ith h in ts in th e S Q L sta te m en t
9 -1 4
Partitioning Tab le s a nd In dexe s

C U S TO M E R S
C o l1 C ol2 C o l3 R eg io n
Table partitions help to keep local tables small and focussed on local needs.
C U S TO M E R S _R 1
C ol1 C o l2 C ol3 R egio n
C U S TO M E R S _R 2
C ol1 C o l2 C ol3 R egio n
9 -1 5
View s
T1 T1 T2 T 3 T3 T4
Views do not have a counterpart in ER modeling, although some may result from supertype/subtype implementation.
V1
V2
V3
V4

9 -1 6
R es trictin g ac cess P resen ta tion o f d ata Iso la te a pp lica tion s fro m data s tru cture S av e co m p lex qu eries S im plify u ser co m m an ds
..................................................................................................................................................... 9-39
R easo ns for V iew s
A d va n tag e s
D y n am ic vie w s P re se n t de n o rm a lize d d ata fro m n o rm alized ta b les S im p lify S Q L s tatem en ts M a y a ffe ct pe rfo rm a n ce s R e stricted DM L in so m e c as es
D is a dv an ta g es
9 -1 7
O ld Fashion ed D es ig n
U n iq u e in d e x V iew s w ith C h e ck o p tio n c lau s e G en e ric A rc im p le m e nta tio n
Some checks can be implemented in a view with check option. We advise that view should not be used but database triggers should be used instead. The reason is primarily to keep all checks in one place.
9 -1 8
G en eric A rc Im plem entatio n

A # Id * N am e X # Id * Name Y # Id * Name
Generic arcs should not be used in any new system.
A S (A ) ...
* Table_nam e * Fk_id
(X o r Y )
9 -1 9
D istrib uted D a tab ase
D ifferen t p h ys ic al d atab a se s ap p e ar as o n e lo g ic al d a ta b as e
Distributed database: one database design, implemented in several physical databases, acting as one logical database.
9 -2 0
B ene fits of D istributed D ata base s
R e silien c e R e du ce d lin e traffic L o c atio n tra n sp a ren c y L o c al au to n o m y E as ie r g ro w th p a th Inc re as ed , d istribu te d , c o m p le xity
Do not go into details about two-phase commit and transaction mechanisms and so on. Only touch the surface.
but
9 -2 1
Database Structure described in ER terms.

DATABASE
D atab ase Structure
consists o f part of TA B LE S P A C E consists of part of resides container in SEGMENT of O TH E R TA B LE SEGMENT SEGMENT
IN D E X SEGMENT
residence of
D A T A FILE
sliced in sliced in located in part of part of TA B LE O R IN D E X P A R T ITIO N

E X TE N T U S E D
consists of part of
FR E E
consists of
resides in residence of
part of D A TA B LO C K
9 -2 2
Sum m ary
D a ta T y pe s P rim a ry , F o re ig n , a n d A rtificial Ke y s Ind e x es P artitio n in g V iew s D is trib u ted d e sign
9 -2 3

Prac tices
D a ta T y pe s A rtific ial K ey s P ro d u ct P ictu re s
Practice Data Types Artificial Keys Product Pictures
3day Yes Opt opt
4day Yes Cha opt
9 -2 4
C U R R EN C Y # C od e
of w ith
C O U N TR Y # C o de
M oon ligh t Pricing

w ith
PRODUCT GROUP # N am e
Practice 9-1
in fro m to
in
w ith w ith
in
w ith in
PR O D U C T
EX C H A N G E RATE # M o n th * R ate
of
LO C A L # N am e
SH O P # No * N am e * A d dress * C ity
for
P R IC EL IST # Start D ate * En d D ate
GLOBAL # C o de o Size
w ith of
LO C A L P R IC E # Start D ate o En d D ate * A m o un t LA N G U A G E # C od e
w ith in
w ith of
w ith
G L OB A L P R IC E * A m o un t
of
of in
PRODUCT NAME * N am e
9 -2 5
..................................................................................................................................................... 9-41
D a ta T ypes (1)
Table C O U N TR IE S C U R R E N C IE S E X C H A N G E _ R A TE S P R IC E _LIS TS P R O D U C T_G R O U P S P R O D U C TS C o lum n C o de C o de M o nth R a te S ta rt_date E n d_date Name C o de S iz e P d t_type S uggested D ata Type V archar2(2) V archar2(3) D ate N um ber(8,4) D ate D ate C har(8) C har(10) N um ber(4,2) N um ber(1) Y our C hoice D ata Type
9 -2 6
D a ta T ypes (2)
Table G LO B A L_P R IC E S LO C A L_P R IC E S S HOPS C olu m n A m o unt S tart_date E nd_ date A m o unt N am e A ddress C ity Y our C hoice D ata Type
9 -2 7
Instructor Post Lesson Teaching Evaluation .....................................................................................................................................................

Name: Full Email:
Content
Type
Page Number
Note
Photocopy this page and fax to :Oracle Designer Education Products @ +(44) 118.924.5181 Additional sheets are available at the end of the instructors guide. If you draw additional diagrams on white board use the Graphic sheet in the Instructor Evaluation section at the end of this book.
..................................................................................................................................................... 9-43
Suggested Graphics .....................................................................................................................................................
Suggested Graphics
..................................................................................................................................................... 9-45
fold here
A
................................
Solutions
Appendix A: Solutions .....................................................................................................................................................
Introduction to Solutions
Before You Proceed In this section you find solutions to the practices. A set of solutionsnot the definitive solutions. Solutions for practices are highly dependent on the business context. Although some background is given in the practice text, a lot remains unsaid. You have had to use your imagination and make your assumptions to fill in the blanks. Even in the real-life modeling world of the analyst there is no such thing as the conceptual model. You could even argue that there is no such thing as the real world. There is no is. Everything is perceived by an observer and it is the perception only that you can model. Bear this in mind when you compare the given solutions with those you created. If there are discrepancies, try to be aware of your assumptions and try to find those that are at the basis of the presented solutions. This text is not meant to be a disclaimer. The solutions presented here were created with care, and are as close as possible to the likely direction a real-life model would take. Solution List
Practice Practice 11 Instance or Entity: Solution Practice 12 Guest: Solution Practice 13 Reading: Solution Practice 14 Read and Comment: Solution Practice 15 Hotel: Solution Practice 16 Recipe: Solution Practice 21 Books: Solution Practice 22 Moonlight: Solution Practice 23 Shops: Solution Practice 24 Subtypes: Solution Practice 25 Schedule: Solution Practice 26 Address: Solution Practice 31 Read the Relationship: Solution Practice 32 Find a Context: Solution Practice 33 Name the Intersection Entity: Solution Practice 34 Receipt: Solution Practice 35 Moonlight P&O: Solution Practice 36 Price List: Solution See Page 4 5 6 7 8 9 11 12 13 14 15 16 18 19 20 21 23 27
..................................................................................................................................................... A-2 Data Modeling and Relational Database Design
Introduction to Solutions .....................................................................................................................................................
Practice Practice 37 E-mail: Solution Practice 38 Holiday: Solution Practice 41 Identification Please: Solution Practice 42 Identification: Solution Practice 43 Moonlight UID: Solution Practice 44 Tables: Solution Practice 45 Constraints: Solution Practice 51 Shift: Solution Practice 52 Strawberry Wafer: Solution Practice 53 Bundles: Solution Practice 54 Product Structure: Solution Practice 61 Patterns: Solution Practice 62 Data Warehouse: Solution Practice 63 Argos and Erats: Solution Practice 64 Synonym: Solution Practice 71 Mapping Supertype: Solution Practice 72 Quality Check Subtype Implementation: Solution Practice 73 Quality Check Arc Implementation: Solution Practice 74 Primary Keys and Columns: Solution Practice 81 Name that Denormalization: Solution Practice 82 Triggers: Solution Practice 83 Denormalize Price Lists: Solution Practice 84 Global Naming: Solution Practice 91 Data Types: Solution Practice 92 Artificial Keys: Solution Practice 93 Product Pictures: Solution
See Page 28 30 32 34 37 38 39 40 41 42 44 45 46 47 48 49 50 51 52 53 54 56 58 59 61 62
..................................................................................................................................................... Data Modeling and Relational Database Design A-3
Practice 11 Instance or Entity: Solution

List which of the following concepts you think is an Entity, Attribute, or Instance. If you mark one as an entity, then give an example instance. If you mark one as an attribute or instance, give an entity. For the last three rows, find a concept that fits. A possible solution:
Concept
E/A/I? Example Instance or Entity
PRESIDENT DOG ANIMAL HEIGHT

TYPE OF TRANSPORT Number of Wheels My current car
E E E A E A I
Gandhi, Washington, Gorbachov STAR, SINGER, PERSON Snoopy Cat, Dog, ... PERSON, BUILDING, ...
ELLA FITZGERALD I
CAR CAR CAR
A-1
In fact, all concepts can be both an entity and an instance of an entity. This depends on the business perspective. Some businesses have strange perspectives... Even Ella Fitzgerald could be an entity. Think in the context of a look-alike contest or the context of an art collection where there may be several instances of an Ella Fitzgerald.
Practice 12 Guest: Solution .....................................................................................................................................................
Practice 12 Guest: Solution

Draw a line between the attribute and the entity or entities it describes. A possible solution:
Address Arrival Date Family Name
GUEST HOTEL ROOM
Room Number Floor Number Number of Beds Number of Parking Lots Price TV set available?
A-2
Note that several entities seem to have the same attribute. In fact you should view this as entities having different attributes that, by coincidence, have the same name. The rule is that an attribute always belongs to one entity. Per entity the data type or length of the attribute may be different. Some of the presented answers are disputable. You could argue that a GUEST has an Arrival Date when old arrival dates are not of interest and may be overwritten. If you want to keep the number of beds per room, you do not need to keep it at the level of the hotel, as you can derive the value based on the sum of all beds per room.
Practice 13 Reading: Solution

Which text corresponds to the diagram?
EMPLOYEE
assigned to responsible for
DEPARTMENT
A Each EMPLOYEE may be assigned to one or more DEPARTMENTS

Each DEPARTMENT must be responsible for one or more EMPLOYEES
B Each EMPLOYEE must be assigned to one or more DEPARTMENTS

Each DEPARTMENT may be responsible for one or more EMPLOYEES
C Each EMPLOYEE must be assigned to exactly one DEPARTMENT

Each DEPARTMENT may be responsible for exactly one EMPLOYEE
A-3
Option B is the correct reading.
Practice 14 Read and Comment: Solution .....................................................................................................................................................
Practice 14 Read and Comment: Solution

1 Read each of the relationships in the model presented here. 2 Next, comment on the relationship you just read. Use your knowledge of people and towns.
Practice: Read and Comment

PERSON
born in birthplace of living in home town of visitor of visited by mayor of governed by (as mayor)
A-4
TOWN
From top to bottom: Each Person must be born in one or more Towns. Each Town may be birthplace of exactly one Person. Comment: both sides seem te be of the wrong degree. Each Person must be living in one or more Towns. Each Town may be home town of one or more Persons. Comment: The first certainly has a wrong degree. The optionality seems wrong as well. Each Person may be visitor of one or more Towns. Each Town must be visited by one or more Persons. Comment: The optionality of the second seems very likely, but is probably wrong, depending of the definition of Town. Each Person may be mayor of exactly one Town. Each Town may be governed by (as mayor) exactly one Person. Comment: Both seem fine, except that if you need to keep historical information, then both sides of the relationship must be many.
Practice 15 Hotel: Solution

1 Comment on the relationships of the model presented here. 1 Possible comments: The relationship the lodging for/ in between entity STAY and HOTEL should be replaced by a relationship between ROOM and HOTEL, such as located in/location for. Every PERSON should have the possibility of more than one STAY; a STAY should be for a single person only. When two persons sign in it should lead to two instances of STAY. The relationship between PERSON and HOTEL seems to be redundant. This is a possible model:
HOTEL * Address
location for located in owned by known by favored by
ROOM * Room Number

location for taking place in
owner of
aware in favor of of
STAY * Arrival Date
endured by
PERSON enduring * Name
A-5
2 Make up two more possible relationships between PERSON and HOTEL that might be of some use for the hotel business. 2 See the diagram for possible relationships between person and hotel.
Practice 16 Recipe: Solution .....................................................................................................................................................
Practice 16 Recipe: Solution

1 Analyze the example page from Ralphs famous Raving Recipes book and list as many different types of information that you can find that seem important. 2 Group the various types of information into entities and attributes. 3 Name the relationships you discover and draw a diagram.
5DOSKV 5DYLQJ 5HFLSHV
6RXSV
vegetarian 15 min easy
$oRUGD DOHQWHMDQD
bread soup from Portugal for 4 persons:
1 onion 4 cloves of garlic 1 red pepper 1 liter of vegetable broth 4 tablespoons of olive oil 4 fresh eggs 1 handful of parsley or coriander salt, pepper 9-12 slices of (old) bread Cut the onion into small pieces and fry together with the garlic. Wash the red pepper, cut it in half, remove the seeds and fry it for at least 15
page 127
preparation
A-6
Here is a list of types of information. There may be others and you may have named them differently. An example from the text is given in italics. Recipe (Aorda) Original Name (Aorda alentejana) Description (Bread Soup from Portugal) Vegetarian Indicator (Vegetarian) Number of Persons (4) Ease of Preparation (Easy) Preparation Time (15 min) Preparation Description (Cut the onion ...) Ingredient (Garlic, bread) Quantity (4, for the cloves of garlic, 1 for the pepper) Unit (liter, piece, handful) Recipe Group (Soups)
Note that the ingredients are somehow sorted. There must be hidden intelligence to do that. This might lead to: Ingredient Type (vegetable, spice) A possible model for the recipes:
BOOK -Title containing published in
a RECIPE must be classified in exactly one RECIPE GROUP A RECIPE GROUP may be
RECIPE classification for one or more -Name RECIPES -Description -Vegetarian? -Number of People classified RECIPE in -Preparation Time GROUP -Preparation Ease classification -Name -Preparation Text for prepared with used in INGREDIENT -Name -Quantity -Unit -Type
A-7
a RECIPE must be prepared with one or more INGREDIENTS An INGREDIENT may be used in exactly one RECIPE
Other solutions may include entity AUTHOR, BOOK, BOOK TYPE, RECIPE, RECIPE ITEM, INGREDIENT and INGREDIENT GROUP.
Practice 21 Books: Solution .....................................................................................................................................................
Practice 21 Books: Solution

1 In this text the word book is used with several meanings. These meanings are different entities in the context of a publishing company or a book reseller. Try to distinguish the various entities, all referred to as book. Give more adequate names for these entities and make up one or two attributes to distinguish them. 2 Create an ER model based on the text. Put the most general entity at the top of your page and the most specific one at the bottom. Fit the others in between. Do not worry about the relationship names. Different meanings of the word Book from the text. Attributes are between brackets. Attributes marked with an asterisk should preferably be modeled as a relationship to another entity. MANUSCRIPT (Title, Year of Completion, Author*) EDITION (Sequence Number of Printing) COPY (position on the shelf) TRANSLATION IN LANGUAGE (Language*, Translator*) TITLE (Authorized Text) PRINTING (Font*, Year of Printing) VERSION (Hardcover Indicator) and maybe more. These may be related in this way:
MANUSCRIPT TRANSLATION TITLE EDITION PRINTING VERSION COPY

A-8
LANGUAGE
A particular copy of a book is a copy of a version of a printing of an edition of a title of a translation in a language of a manuscript.
Practice 22 Moonlight: Solution

1 Make a list of about 15 different entities that you think are important for Moonlight Coffees. Use your imagination and common sense and, of course, use what you find in the summary that is printed below. 1 Possible entities sorted alphabetically:
COUNTRY COUNTRY COMMUNITY CURRENCY DEPARTMENT DRINK EMPLOYEE EXCHANGE RATE FOOD JOB LOCATION TYPE PASTRY
PRODUCT PRODUCT GROUP PRICE SALE SHOP STOCK OPTION STOCK PRICE TICKER SYMBOL
A-9
2 Write a formal definition of the entity that represents: 2 Possible definition: A shop is a place where Moonlight sells, did sell, or will sell products to customers, a retail outlet. An example of a shop is the one in ... that was opened in ... . An employee is a person that works, did work or will work for Moonlight in a named job and is paid by Moonlight. An example of an employee is ... who works as ... in ... .
Practice 23 Shops: Solution .....................................................................................................................................................
Practice 23 Shops: Solution

Use the information from the list as a basis for an ER model. Pay special attention to find all attributes.
SHOP * Number * Name * Location * City o Telephone * Open Date
in of located in
COUNTRY * Code * Name
LOCATION TYPE * Description of
or
SHOP * Number * Name o Telephone * Open Date
A-10
COUNTRY * Code * Name

of located in in
LOCATION * Name of
located in of
LOCATION TYPE * Description
Both solutions are fine. The second sees a location like JFK Airport as a possible location for several shops. Maybe most locations have one shop only. Note that in the second solution a location does not necessarily have a shop. This allows for future locations. In this respect the second model is somewhat more flexible.
Practice 24 Subtypes: Solution

Find all incorrect subtyping in the illustration. Explain why you think the subtyping is incorrect. Adjust the model to improve it. All examples are cases of wrong subtyping. The subtypes of DISABLED PERSON are not mutually exclusive: DEAF and BLIND may overlap. The subtypes of CAR ar not exhaustive: there are cars that are neither a station wagon nor a sedan. Entity BUILDING should have at least two subtypes. If ROOM WITH BATH is a subtype of HOTEL this would mean that every ROOM WITH BATH is a HOTEL. DOMESTIC ANIMAL and MAMMAL are not mutually exclusive. In fact, DOG is subtype of both, instead of the other way around.
Improvements
Solution: Subtypes
DISABLED PERSON DEAF AND BLIND CAR STATION WAGON SEDAN
DEAF, NOT BLIND BLIND, NOT DEAF

OTHER DISABLED
OTHER CAR
BUILDING
HOUSE OTHER
HOTELROOM ROOM WITH BATH OTHER ROOM
DOG
yo beMAMMAL
a DOMESTIC rep d ANIMAL n
ir
A-11
Practice 25 Schedule: Solution .....................................................................................................................................................
Practice 25 Schedule: Solution

Use the schedule that is used in one of the shops in Amsterdam as a basis for an entity relationship model. The schedule shows, for example, that in the week of 12 to 18 October Annet B is scheduled for the first shift on Monday, Friday, and Saturday.
SHOP * Name * Location * City

with for
SCHEDULE prepared by EMPLOYEE * Start Date * Family Name maker of * End Date * First Name * Short Name with
within
SCHEDULE for ENTRY with * Weekday * Shift Number

A-12
An alternative solution models SCHEDULE ENTRY differently:

with within
SCHEDULE for ENTRY with * Monday Shift * Tuesday Shift * Wednesday Shift * Thursday shift * Friday Shift * Saturday Shift * Sunday Shift
The first model does allow for more than one shift per employee per day; the second does not.
Practice 26 Address: Solution

An entity, possibly PERSON (or ADDRESS) may have attributes that describe the address as in the examples below. 1 How would you model the address information if the future system is required to produce accurate international mailings?
PERSON Address text line1 Address text line2 Address text line3 Address text line4
COUNTRY
PERSON Street or PO Box Indicator Street House Number City Post Code Province or State
ADDRESS TYPE
COUNTRY
1 Solution 1 can easily cope with the various address formats. It simply
recognizes the fact that an address may consist of 4 lines of text at maximum. This avoids the need to interpret a given address. Is 1045 ST 88 the house numbered 1045 on Street 88 or is it the house numbered 88 at 1045 Street? 2 Solution 2 cuts the address into individual pieces and accounts for post boxes as well. It assumes the interpretation is no problem. By adding entity ADDRESS TYPE the sequence of display of the various address pieces can be set. 2 Would your model from the previous practice also accept the addresses below? 3 Check if your model would be different if the system is also required to have facilities to search addresses in the following categories. Make the necessary changes, if any. All addresses: In Kirkland With postal code 53111 in Bonn That are P.O. Boxes On: Oxford Road or
Practice 26 Address: Solution .....................................................................................................................................................
Oxford Rd or OXFORD ROAD or OXFORD RD in Reading 3 The second model does allow most of the required queries, although the last one may need some trials. If a system needs to allow quick and easy searches on the address information, often a separate attribute is added that stores the address information in uppercase using a particular set of rules to sort street name elements and to abbreviate. For example, a street name like President A. B. Collins Road would be taken as COLLINS, RD PRES A B. Such an attribute is not derivable from the address line unless the system has a built-in parser for this purpose.
Practice 31 Read the Relationship: Solution

Read the diagrams aloud, from both perspectives. Make sentences that can be understood and verified by people who know the business area, but do not know how to read ER models.
ALU
of with
BRY
Every ALU must be of exactly one BRY Every BRY may be with one or more ALUS
Every PUR may be bazooned in one or more YOKS Every YOK may be bazooned by one or more PURS
PUR
bazooned in bazooned by
YOK
KLO
bilought in glazoed with
HAR
Every KLO must be bilought in one or more HARS Every HAR may be glazoed with exactly one KLO
A-15
Even if the phrases sound as if they come from some strange Science Fiction movie, make sure you are fluent in reading them. Only start judging what you have just heard after reading the lines. In a real life context, you sometimes read what you think is represented, rather than what is actually modeled. It is really hard to switch off your interpretation machine.
Practice 32 Find a Context: Solution .....................................................................................................................................................
Practice 32 Find a Context: Solution

Given the following ER diagrams, find a context that fits the model. Here are just some examples of possible contexts.
COUNTRY
birthplace of born in location of located in
PERSON
TOWN
PERSON FEMALE
PERSON
mother of son of
MALE
MALE FEMALE
child of
PERSON
mother of most popular movie star in COUNTRY with most popular movie star born in birthplace of
A-16
Practice 33 Name the Intersection Entity: Solution

1 Resolve the following m:m relationships. Find an acceptable name for the intersection entity. 2 Invent at least one attribute per intersection entity that could make sense in some serious business context. Give it a clear name.
PRODUCT
DEPARTMENT STORE
in of
SALE * Date
with at
PERSON
SAILBOAT
in of
with at
INTERPRETER
LANGUAGE
with
CREW MEMBERSHIP * Role
with in of FLUENCY * Score
A-17
These are only possible solutions, based on just one possible context and one assumption on desired functionality.
Practice 34 Receipt: Solution .....................................................................................................................................................
Practice 34 Receipt: Solution

Use the information from the receipt and make a list of entities and attributes.
Served by: Dennis Till: 3 Dec 8, 4:35 pm ----------------------CAPPUCC M 3.60 * 2 7.20 CREAM .75 * 2 1.50 APPLE PIE 3.50 BLACKB MUF 4.50 <SUB> 16.70 tax 12% 2.00 <TOTAL> 18.70 ======= CASH 20.00 RETURN 1.30 ----------------------Hope to serve you again @MOONLIGHT COFFEES 25 Phillis Rd, Atlanta
A-18
An assumption is that all, non-derivable, information that is displayed on the receipt must be stored for at least some time.
COUNTRY * Name with in SHOP * Name o VAT%
with in TILL PERSON PRODUCT * Number * First Name * Short Name with with * Price at at SALES HEADER in * Date & Time * Amount Cash referring with to part of SALES ITEM * Quantity
A-19
This model is based on several assumptions. One is that all entities may exist in isolation: for example, there may be countries (recorded in the system) without shops, shops without tills, and tills without sales. This explains all 1:m relationships that are optional at the 1 side. Sales tax or VAT percentage for these kinds of products is a fixed value at a local shop level, such as in, for example, the USA, or at Country level, such as for example in many European countries. In this model the choice is made to model it at shop level. Many countries know two VAT percentages: a low percentage for normal and a high percentage for luxury goods. Moonlight may have to deal with both as mineral water and coffee possibly fall in different categories. (The day after writing this text the Dutch parliament accepted two VAT percentages for one and the same productdrinking water. The initial amount is seen as normal consumption, the excess as luxury.) The Attribute Price of PRODUCT could be modeled as a separate entity as products may have various prices over time.
Practice 35 Moonlight P&O: Solution .....................................................................................................................................................
Practice 35 Moonlight P&O: Solution

1 Create a entity relationship model based on the following personnel and organization information: 1 Note the optional relationships from EMPLOYEE to DEPARTMENT and SHOP. These result from ... country organizations or for a shop.
All Moonlight Coffee employees work for a department such as Global Pricing or HQ, or for a shop. All employees are at the payroll of one of our country organizations. Jill, for example, works as a shop manager in London; Werner is a financial administrator working for Accounting and is located in Germany DEPARTMENT * Name
with
SHOP * Name * City

with
COUNTRY ORGANIZATION
with
works for
works for
at payroll of
EMPLOYEE * Name * Job

A-20
2 Extend or modify the diagram based on this information:

2
reporting to
report of
DEPARTMENT * Name OTHER DEPARTMENT
HQ
with
with All shops belong with to one country belongs organization (the to countries). There is SHOP only one country * Name organization per * City country. All countries with works and departments for works for report to HQ, except EMPLOYEE HQ itself * Name * Job
A-21
on payroll of
3 And again:
3
reporting to
report of
DEPARTMENT
* Name
HQ
OTHER DEPARTMENT Employees can work part time. Lynn has had an 80% assignment for Product Development since the 1st September. Before that she had a full-time position. to
with with
with at payroll of belongs to
SHOP
* Name * City with
EMPLOYEE
* Name
with of to
ASSIGNMENT
* Job * Start Date * Part Time %
A-22
Practice 35 Moonlight P&O: Solution .....................................................................................................................................................
4 Change the modelif necessary and if possibleto allow for the following new information. a Jan takes shifts in two different shops in Prague. 4 a. Does not require changes in the model. People can be employed in various placesthe model allows that. e To prevent conflicting responsibilities, employees are not allowed to work for a department and for a shop at the same time. b. See diagram. b Last year Tess resigned in Brazil as a shop manager and moved to Toronto. Recently she joined the shop at Toronto Airport. c. See diagram. c To reduce the number of direct reports, departments and country organizations may also report to another department instead of Headquarters. d. See diagram. d The shops in Luxembourg report to Belgium. e. Cannot be modeled with what you have learned so far.
4a: COUNTRY ORGANIZATION

with
reporting to
report of
4c DEPARTMENT * Name
OTHER DEPARTMENT
HQ
report of
4b
EMPLOYEE
with for for
PAYROLL ENTRY
* Start Date
in COUNTRY ORGANIZATION of with
COUNTRY
* Name
4d
SHOP
* No * Name
of belongs to located in
4e: A-23
5 Would your model be able to answer the next questions? a Who is currently working for Operations? b Who is currently working for Moonlight La Lune at the Mont Martre, France? 5 a, b. Given the previous models, these questions can be answered.
c Are there currently any employees working for Marketing in France? c. Departments are not related to Countriesso there is no Marketing in France. However, we can find who (if anyone) is working for the Marketing Department who is also on the French payroll. d What is the largest country in terms of number of employees? In terms of managers? In terms of part-timers? d. The question can be answered by counting the distinct current assignments per country organization. e When can we celebrate Lynns fifth year with the company? When can we do the same with Tess fifth year with Moonlight? e. The model does not (yet) contain an attribute End Date for ASSIGNMENT and PAYROLL ENTRY. Given Tess career at Moonlight, there is a need for attribute End Date as the periods are not necessarily contiguous. f What country has the lowest number of resignations? f. Can be answered. Note: This model is quite complex, as both departments and country organizations are part of the organization. Departments do not have a location, unlike country organizations. Departments are virtual organizations. Think about a department as a collection of tasks rather than a group of people. A department can still exist even if there are no people working for it - the tasks still remain. The location of the department may be defined by the office of that country organization which currently has the manager of the department on its payroll. A country organization is not the same as a country. It is wise to distinguish the two as countries are beyond the scope of Moonlights power, whereas country organizations can be defined by Moonlight. A country organization in Haiti may not (yet) exist, but the country does.
Practice 36 Price List: Solution .....................................................................................................................................................
Practice 36 Price List: Solution

Make a ER model based on the pricelist from one of the Moonlight Coffee Stores.
COUNTRY * Currency
with in
SHOP * Name * Address * City

with at
PRODUCT GROUP
with in
coffees teas foods nonfoods supplements
PRICE LIST * Start Date * End Date

with in
PRODUCT * Short Name o Size

with
of
PRICE * Amount
A-24
One of the questions that arises here is the following: is decaffeinated a PRODUCT? In some respects it behaves differently from other productsyou cannot buy it separately, nor in combination with, for example, apple pie. On the other hand it is something you can buy, and it has a price just like the other products. In this solution, decaffeinated is regarded as a product in a special product group: supplements (maybe you have a suggestion for a better name...). Products in this group need special attention, but otherwise can be treated as products. Note also the entity PRODUCT GROUP. PRODUCT GROUP instances are represented by the lines between the various products on the price list.
Practice 37 E-mail: Solution

Take the given model as starting point. Add, delete, or change any entities, attributes, and relationships so that you can facilitate the following functionality: See the numbers in the illustration for the various assignments. 1 A user must be able to create nick names (aliases) for other users. 2 A folder may contain other folders. 3 A user must be able to forward a composition. A forward is a new message that is automatically sent together with the forwarded message. 4 All folders and lists are owned by a user.
USER
owner of owned by referred to for
NICK NAME
containing within
FOLDER
4
forwarded with
USER
owner of owner of owned owned by by
COMPOSITION
containing within
is forward of
FOLDER
LIST
A-25
Practice 37 E-mail: Solution .....................................................................................................................................................
Challenge: 5 A mail list may contain both users and other lists. 6 A mail list may contain external addresses, like giovanni_papini@yahoo.com. 7 A nickname may be an alias for an external address.
USER
owner of owned by
USER
owner of owned by
5
owner of owned by
LIST
is referred to referring to is referred to referring to is referred to referring to owner of owned by
LIST
is referred to referring to
LIST ITEM
LIST ITEM o External User

owner of
USER
NICK NAME
owned by o For External User referred to for
A-26
Practice 38 Holiday: Solution

Comment on the model given below that was based on the scenario text.
Paul and I hiked in the USA. Eric and I hiked in France and we rented a car in the USA last year.
COUNTRY France USA USA TRANSPORT Boots Boots Car
TR Bo AN C ots SP O Bo ar RT ot s
A-27
When you join the information in COUNTRY-COMPANION table and COMPANION-TRANSPORT table, this is the result:
COUNTRY France France USA USA USA
COMPANION Eric Eric Eric Eric Paul
TRANSPORT Boots Car Boots Car Boots
This is obviously wrong. The model somehow generated more than was put into it! The reason? It is the combination of Paul, Hiking, USA that is important, just as the combination of Eric, Hiking, France is important. It is the combination of the three values that matter. See the model and table structure in the next illustration.
C Er OM i E c PA NI Pa ric ON ul
C TRANSPORT COUNTRY F r OU US an NT US A ce RY A C Er OM COMPANION E ic PA NI Pa ric O ul N
Practice 38 Holiday: Solution .....................................................................................................................................................
COUNTRY France USA
COMPANION Eric Paul
TRANSPORT Boots Car
COUNTRY
COMPANION
TRANSPORT
HOLIDAY
COUNTRY France USA USA
COMPANION Eric Eric Paul
TRANSPORT Boots Car Boots
A-29
Practice 41 Identification Please: Solution

Describe how you would identify the following entities, making up any attributes and relationships you consider appropriate. A city Name and Country is not always sufficient. In some countries you would also need Province or State when there are more cities with the same name. Some countries use a postal code that is unique per town or city. Of course geographical identification, like Latitude 4 East, Longitude 53 North is unique, but only practical in specific situations. A Contact Person for a Customer This is within our reach. Name, Job (or Telephone Number) and Customer is probably enough. Or, maybe, just an Id. A Train If you think of the hardware, trains have a Id and often also a unique Name. If you think of the 9:05 from Paris to Madrid, the identification consists of the Time, the Start, and Destination. The railroad company uses a simple Code for internal use. A Road In most countries the important roads have a Name. This name may be a number or a combination of characters and numbers, like Route 69 or N356, but this is still a name. Unimportant roads may be unnamed. These can only be identified by using geographical information, like both Ends. Ends may be given as a City or as geographical coordinates. A Financial Transaction Use the combination of the From Account, the To Account, the Date and Time. Note that you need Time because there may be several transactions with the same From and To Account on the same Date. An Academy Award A person would receive an Oscar in a particular year because of a particular reason (best supporting actress, best music score) that is related to a movie, or for all of their activities in the movie world. An Oscar is identified by the Person Receiving, the Year, the Movie (optional), and the Reason.
Practice 41 Identification Please: Solution .....................................................................................................................................................
A Painting This is a difficult one. Although probably all famous paintings have a title or name, not all paintings can be identified by Title and Painter and (optional) the Year or Date. Paintings in art collections are often identified indirectly by an Id on a sticker at the back of the painting, plus electronic photographs and descriptive texts. The latter provide a possible check that stickers have not been switched. Paintings are often not simply identified and also often simply not identified. A T.V. show This is also a tricky one from the perspective of a consumer. Often a show has a Name and a Sequence Number (or Broadcast Date). Often Names are so common, for example, News, that the Television Company is added. This, however, is not enough, for example, when there is a rerun of the show by another company. For the production company a T.V. show is probably just a project with an Id.
Practice 42 Identification: Solution

Are the entities in the next diagrams identifiable?
1
A
A # Xx
B * Yy
C # Zz
C # Code
B # Id
3
A-30
A * Xx B # Yy
C # Zz
with of
D # Id
1 Because every A is identifiable by attribute Xx, every B and C are as well. 2 B is identifiable by Id. A is identifiable, only if B and C are. This leaves C.
Because of the arc, not every C will have the barred relationship with B. But that leaves Cs unidentified. 3 D is identifiable by Id. Every C is identifiable by ZZ and D. Every B is identifiable by Yy. As every B and every C is identifiable, so is every A.
Practice 42 Identification: Solution .....................................................................................................................................................
Solution: Identification 1
4
P Q # Id
5
P # Name
PERSON MALE # Seqno
son of mother of
FEMALE # Name # Birth Date

partner in with wife
partner in with husband
MARRIAGE # Start Date

A 31
4 Every Q is identifiable by Id. Ps that are related to an instance of Q are
identifiable by that instance, but not every P is related. 5 Conceptually there is no problem here. Every P is identified by its Name and the reference to its predecessor. You could argue about how to deal with the first P, but the question in return would be: who told you there is a first P? More of a problem is the fact that the identification of an instance of the n th generation takes n+1 names. This in particular makes this type of identification highly impractical. Note: the next model describes a context that may be different from the world you are familiar with. 6 Entity FEMALE is identified by Name and Birth Date. This may not be true for the entire population of the world, but may be true for a much smaller set of people a business is interested in. Entity MALE is identifiable as well: I am the only second son of my mother. Every PERSON is identifiable because every person is female or male. Entity MARRIAGE is identifiable by the combination of both MALE and FEMALE that participates and the Date of the marriage. 7 Given the above model, answer the following questions.
7
Can person A marry twice? a Yes b Can person A marry twice on the same day? b Yes
Can person A marry with person B twice? c Yes d Can person A marry with person B twice on the same day? d No e Can person A be married to person B and person C simultaneously? e Yes f Can person A be married to person A? f No, because a marriage is always between a male and a female and person. A cannot be both male and female as these are distinct subtypes of person.
Practice 43 Moonlight UID: Solution .....................................................................................................................................................
Practice 43 Moonlight UID: Solution

Use what you know about Moonlight Coffees by now, and, most importantly, use your imagination. 1 Given the model below, indicate UIDs for the various entities. Add whatever attributes you consider appropriate. Country organizations have a unique tax registration number in their countries. 2 Are there any arcs missing?
reporting to
report of
DEPARTMENT
# Name
HQ
OTHER DEPARTMENT
with
COUNTRY
in of with located in
# Code
COUNTRY with ORGANIZATION

with
EMPLOYEE
# Id
with for of for
assigned to
SHOP
# No
PAYROLL ENTRY
# Start Date
with to as in
to
for
ASSIGNMENT
# Start Date
A-32
JOB
# Title
For transparency reasons, only the attributes that are needed for identification are added in this model.
Practice 44 Tables: Solution

Read the text on ISO Relational tables. Do a quality check on the ER model based on the quoted text and what you know about this subject. Also list constraints that are mentioned in the text but not modeled. Erroneous: Both relationships from FOREIGN KEY to TABLE should not be barred. A Table is not identified by Name only, but also by the owning USER. The same is true for a KEY and a FOREIGN KEY. Every KEY, PRIMARY, UNIQUE and FOREIGN must be named uniquely per USER. These errors have been removed in the diagram below.
USER
owner of in
FOREIGN KEY # Name
from to
owner of in with TABLE # Name
with of with of
owner of in KEY # Name PRIMARY

UNIQUE
with
referenced in with
with for ASSOCIATION # Seqno from in COLUMN in # Name in * Data Type o Not Null for USAGE # Seqno
in of
to
A-33
Not shown: COLUMN in a KEY must be a COLUMN of the TABLE the KEY belongs to. COLUMNS in a FOREIGN KEY must refer to COLUMNS in a KEY of the TABLE the FOREIGN KEY refers to. These constraints cannot be shown and must be listed separately.
Practice 45 Constraints: Solution .....................................................................................................................................................
Practice 45 Constraints: Solution

Change the diagrams to model the constraint given.
1
EMPLOYEE # Name OTHER CEO EMPLOYEE
managed by
2
manager of
USER # Name
ALIAS # Name
owned by owner of
LIST NICKNAME
with subfolder
FOLDER # Name
within owner of owned by
USER # Name
A-34
1 Every EMPLOYEE must have a manager, except the Chief Executive Officer. 1 By creating a CEO subtype of EMPLOYEE the constraint is easily modeled. You may argue the use of this CEO subtype if modeling the constraint is the only reason for its existence. 2 A user may not use the same name for both NICKNAME and LIST name. 2 LIST and NICKNAME share the same namespace.This can be modeled with a supertype. Note the repositioning of attribute Name. 3 A top level FOLDER must have a unique name per user; sub folders must have a unique name within the folder where they are located. 3 Adding the arc and barred relationships is enough. Note that the recursive relationship from FOLDER to FOLDER is made mandatory at the many end. See also the remark at Practice 4- Identification 5: Solution about recursive identification.
Practice 51 Shift: Solution

List the various date/time elements you find in this Shift scheme and make a conceptual data model.
SHOP * Name
CALENDAR DAY # Date * Public Holiday Indicator
with
WEEKDAY # Code * Name
of starting starting on
on
SHIFT SCHEDULE
with on
SHIFT # No * Start Time * End Time
A-35
with on
or
on
SHIFT SCHEDULE * Start Date
with
In this solution, entity CALENDAR DAY is used. This might be sensible in the context of a resource-planning environment where public holidays usually play a role. Be aware of the fact that the dates of public holidays are completely different around the world. In other terms, Public Holiday Indicator is not single valued in a international context. In a global context the issue of daylight saving time (which is not common and certainly does not start at the same date around the world) and TIME ZONE play a role.
Practice 52 Strawberry Wafer: Solution .....................................................................................................................................................
Practice 52 Strawberry Wafer: Solution

Revisit your model and make changes, if necessary, given this extra information.
COUNTRY # Code with PRODUCT GROUP # Name with in PRODUCT
with with in SHOP # No * Name * Address * City
of
LOCAL # Name
for PRICE LIST # Start Date * End Date with in with of
GLOBAL # Code o Size
with of
LOCAL PRICE # Start Date o End Date * Amount LANGUAGE # Code
with
of
of in
PRODUCT NAME * Name

A-36
In this model several minor and major changes were made, compared to the model that was presented earlier (Practice 3 - Price List: Solution). The major change is the issue of the prices that are either determined on national level or at shop level. This has lead to two price entities: GLOBAL and LOCAL PRICE. Note the different attributes and relationships of these two. The price list also shows the same product range as the earlier one, but now products can be named in various languages.
Practice 53 Bundles: Solution

1 Modify the product part of the model in such a way that the desired calculations can be completed.
1
BUNDLE
with
PRODUCT GROUP PRODUCT BUNDLE
PRODUCT GROUP
PRODUCT
of
in referring to BUNDLE ITEM
OTHER PRODUCT
with
* Quantity Needed
PRODUCT GROUP
in referring to BUNDLE ITEM * of
Quantity Needed
3
PRODUCT
ASSEMBLY ITEM * Quantity Needed

A-37
1 The first model is probably what you came up with first. A bundle consists of
several products. You model this using the BUNDLE ITEM entity. But this solution is not correct as a bundle can consist of another bundle as well, such as SuperSweetTreat. Model 2 takes care of that. A BUNDLE ITEM can now consist of one or more instances of BUNDLE and instances of OTHER PRODUCT. Note that model 2 assumes there is always a clear distinction between a product and a bundle, because they are modeled as subtypes. Model 3 does not assume that. A bundle is treated as any product here. You do not need to worry if you should consider apple pie with whipped cream as a bundle or as a single product.
Practice 53 Bundles: Solution .....................................................................................................................................................
2 Change the model in such a way that it allows for:
DecafPunch (DP) = {Coffee (C) or Tea (T)} and {Blackberry Muffin (BM)} PRODUCT GROUP # Name Consider this as: AS1 = (C or T) DP = (AS1 and BM)
PRODUCT # Code o And/Or Indicator
PRODUCTS Code And_or C T AS1 OR DP AND ASSEMBLY ITEMS Prod_code AS1 AS1 DP DP
Pg_name .. . ..
ASSEMBLY ITEM * Quantity Needed
Using_code Quantity 1 C 1 T 1 AS1 1 BM
A-38
2 This is a tricky one. You can regard a DecafPunch as a product group with
two products: DecafPunch Coffee and DecafPunch Tea, both with the same price (because of the or). This point of view is already covered in the PRODUCT GROUP / PRODUCT model. In the solution presented, this aspect is ignored. This solution focuses on how you can model the and or or type of constructions. You see that DecafPunch can be regarded as a series of elementary groups that are connected with and or or. An elementary group is seen as a group that consists of either a single product or a product pair that is connected with an and or or. Products can always be described this way (this follows from mathematical logic). See the table structure to check that the model works. Note This model complexity may not make much sense in the context of Moonlight. However, this type of model certainly does make sense for the bill of material structures many production companies use for storing the composition information of their products, with alternative compositions and suchlike.
Practice 54 Product Structure: Solution

1 Create a model for a product classification structure.
LEVEL1
fixed number of levels
with
LEVEL2
LEVEL3
or generic:
PRODUCT CLASS # Name
within
LEVEL4
2
LEVEL5 product
PRODUCT
+ coffees + teas + foods + nonfoods + supplements + bundles
A-39
1 When the number of levels is known and fixed, the left model can be used.
Note that the model forces you to use all five levels for every product. To avoid this you could create a relationship from PRODUCT to all LEVEL entities, plus an arc across all. The left model gives a lot of freedom. No limits to the minimum or maximum number of levels. Freedom to change the classification during the lifetime of the system. 2 (Optional) How would you treat the bundled products? 2 The problem with the bundles is that, strictly speaking, they cannot be classified in class Drinks nor Foods as they can consist of both. Probably the easiest way to handle this is to regard a bundle as an instance of PRODUCT CLASS.
Practice 61 Patterns: Solution .....................................................................................................................................................
Practice 61 Patterns: Solution

What pattern do you expect to find in the given contexts? If you do not see it, make a quick sketch of the model. Use your imagination and common sense.
Model of moves in a chess game Model of quotations Model of recipes Model of all people involved in college: students, teachers, parents, Rentals in a video shop Model of phases in a process
Chain or Network M/D or Basket Bill of Material Roles
M/D or Basket Chain or Network
Moves in a Chess Game A MOVE moves a chess piece from one FIELD to another. This is a typical Network pattern. You can also see the MOVES as a Chain of ordered steps in the chess game. Quotations A quotation makes an offer to deliver a number of products of a certain quantity. This structure is similar to a ORDER and will have the Master-Detail or the Basket pattern. Recipes A recipe usually describes how to make something: in order to create a ... you need two ..., one ... and so on. This is typical Bill of Material pattern. People Involved in a College Pattern: Roles. A teacher can also be parent of a student, a parent can be an former student and so on. Rentals in Video Shop A RENTAL is an event such as a sale or a quotation: Master-Detail or the Basket pattern. Phases in a Process PROCESS and PHASE have a Master-Detail pattern. Be careful at this point. The crucial thing about phases in a process is that the phases are usually ordered. The phases may form a Chain if there is always one phase at most that precedes and follows a particular phase. If, on the other hand, the phases can be preceded and followed by any number of phases (maybe even including itself) than the structure would be a Network.
Practice 62 Data Warehouse: Solution

1 Check the Moonlight models you created so far. Do they cater for answering the listed questions. If not, make the appropriate changes. 1 No formal solution.
YEAR # No
with in with
QUARTER
with in assigned to with within with
MONTH # No
with
WEEK # No
with in in
PRODUCT CLASS
with of
DAY # No
with of
PRODUCT # Id
in of
GEOGRAPHY * Number of Inhabitants * Number of Employees

with of
within
SALES VOLUME * Quantity * Value in Local Currency * Value in $

A-41
2 For a data warehouse data model, suggest the central facts entity. 2 The diagram answers more than the practice asked for. The central entity is SALES VOLUME. This is a typical snowflake model, rather than a star model. All three dimensions, time, geography, and products, have their own internal structure. Note that a week is not assigned to a month. Weeks are assigned to a year, even though not all weeks fit exactly into a calendar year. Weeks have a fixed length, like day and year, but behave differently as a week is not based on an astronomical fact. The product structure we defined earlier can be used here. The distinction between local and global products has gone. Geography is the generic word for an area (such as a part of country or a country or a continent) that is of interest.
Practice 63 Argos and Erats: Solution .....................................................................................................................................................
Practice 63 Argos and Erats: Solution

Make a conceptual data model based on the information in the text. Mark all the pieces in the diagram that can be confirmed from the text.
ERAT # Name
have have of of have belongs to have of
unknown optionality unknown degree
RONDEL * Type
in with
ARGO # Name
in with
UBIN
with with
UBIN ITEM Constraint not shown: A ubin always consists of one or more argos of the erat, one or more...
A-42
Not all information you need is present in the given text. You may be surprised how much actually is still left to check. The only part you can be sure about is the UBIN - UBIN ITEM to model the given A ubin always consist of one or more .... This is a typical basket construction. Note: this text was created by using some find/replace commands in a normal text. Ask your instructor about the original text.
Practice 64 Synonym: Solution

Make a conceptual data model that could be the basis for a dictionary of synonyms.
MEANING # Id * Description
shared by with
synonym
WORDS Mng_id Word 1 Practice 1 Exercise 2 Order 2 Sequence 2 Arrangement 3 Order 3 Command 3 homonym Demand 4 Bike
WORD # Word MEANINGS Id Description 1 Action, actual doing ... 2 Regular arrangement ... 3 Order, command ... 4 A vehicle with two wheels ... 5
The solution is, probably, surprisingly and frustratingly easy. Think of synonyms as words that share the same meaning. Do not confuse the concept meaning with the concept word. Although you express a meaning using a word or words, it is not the same as a word. Words are representations of meaning. Note that there is no entity SYNONYM. A synonym is something circumstantial: if there is a MEANING shared by two or more words, then there is a synonym. Conversely, if there is a WORD with two or more MEANINGS, there is a homonym.
Practice 71 Mapping Supertype: Solution .....................................................................................................................................................
Practice 71 Mapping Supertype: Solution

1 What would have been the rationale of this choice? 1 Possible considerations: The number of departments is probably not large, say 100 or less. There are only few specific attributes for the subtypes. One subtype, HQ may have only one instance. HQ seems to be modeled only to show the fact that all departments except HQ must report to a department. 2 On the table diagram, name all the elements that must be created following this supertype implementation. Use the naming convention as described in this lesson, or use your own rules. Give proper names to the columns and foreign key constraints and identify check constraints, if any. 2 See the diagram below.
dpt_dpt_fk
DEPARTMENTS (DPT) pk * Id
o Address fk o Dpt_id_reporting_to
* Name * Dpt_type * Headcount
Note the optional Address column. Note also the optional foreign key column and its name. Following the rules, the name could have been Dpt_id. As many people would assume that to be a primary key column name, the name is followed by the name of the relationship that the foreign key represents. Two constraints are needed: To guard the subtype:
( Dpt_type = HQ and Address is not null and Dpt_id_reporting_to is null) or ( Dpt_type <> HQ and Address is null and Dpt_id_reporting_to is not null)
To guard the hierarchical structure of the organization.
Practice 72 Quality Check Subtype Implementation: Solution

Perform a quality check on the proposed subtype implementation of entity PRODUCT.
gpt_pgp_fk
GLOBAL_PRODUCTS (GPT) pk * fk
o
lpt_shp_fk
LOCAL_PRODUCTS (LPT) pk * pk,fk * fk * Name Shp_no Pgp_name
Code Size Pgp_name
Errors: GLOBAL_PRODUCTS The foreign key column Pgp_name is not marked with fk. LOCAL_PRODUCTS Column Shop_no should be named Shp_no Column Shp_no is also part of the primary key. The foreign key to table SHOPS should be named lpt_shp_fk
Practice 73 Quality Check Arc Implementation: Solution .....................................................................................................................................................
Practice 73 Quality Check Arc Implementation: Solution

Perform a quality check on the proposed supertype and subtype implementation of the entity PRODUCT and its subtypes. Also, check the selected names. Errors: PRODUCTS Gpt_code and Lpt_name are both part of a unique key uk1 The last characters of the names of the foreign keys should all read _fk A fk column is missing as the primary key of LOCAL_PRODUCTS consists of two columns. Column Lpt_shp_no must be added. This column is part of fk3 and part of uk2. GLOBAL_PRODUCTS This is an awkward one: The foreign key line in the diagram must be removed as GLOBAL_PRODUCTS does not have its own foreign key to PRODUCT_GROUPS. LOCAL_PRODUCTS Column Pgp_name must be removed. Shp_no is the only foreign key column of this table.
PRODUCTS (PDT) pk * Code fk1 Pgp_name * fk2, uk1 o Gpt_code fk3, uk2 o Lpt_name fk3, uk2 o Lpt_shp_no
fk1=pdt_pgp_fk fk2=pdt_gpt_fk
GLOBAL_PRODUCTS (GPT) pk * Code o Size LOCAL_PRODUCTS (LPT)
fk3=pdt_lpt_fk
lpt_shp_fk
pk * Name pk, fk * Shp_no
A-46
Practice 74 Primary Keys and Columns: Solution

Identify the Primary key columns and names resulting from the transformation of the GLOBAL PRICE entity. Give the short name also.
GLOBAL_PRICES (GPE) pk, fk1 * pk, fk1 * pk, fk2 * Plt_cty_code Plt_start_date Gpt_code Amount
fk1= gpe_plt_fk fk2= gpe_gpt_fk
Note that GLOBAL_PRICES has three columns that are part of its primary key. All these columns are also part of foreign keys. The first two come from PRICE_LISTS and have prefix Pct_. The third comes from GLOBAL_PRODUCTS and has prefix Gpt_. Note the double prefix in column name Pct_cty_code as this column refers to Cty_code of PRICELISTS, which is a foreign key column itself.
Practice 81 Name that Denormalization: Solution .....................................................................................................................................................
Practice 81 Name that Denormalization: Solution

For the following table diagrams, decide what type of denormalization is used and explain why the diagram depicts the denormalization you have listed. Use one of: Pre-Joining Tables Hard-Coded Values Keeping Details with Master Repeating Single Detail with Master Short-Circuit Keys
Type Prejoin tables Why The Name column from the WEEKDAYS table has been added to the SHIFTS table, as the Wdy_name column.
2
Type Short-Circuit Key Why A new foreign key constraint and column has been added to the PROD_NAMES table, to join to the PROD_GRPS table.
3
Type Invalid (could have been either End Date Column or Current Indicator) Why When you add a column to a table to facilitate issues concerning date retrieval or insert, add either an end-date column or current indicator column, not both.
Practice 82 Triggers: Solution

1 Indicate which triggers are needed and what they should do to handle the denormalized column Order_total of ORDER_HEADERS. 1 How to handle Order_total for ORDER_HEADERS
ORDER_HEADERS (OHR) pk * * Id Order_total
ORDER_ITEMS (OIM) pk * Ohr_id pk * Seqno * Item_total
Table OHR
Column
Needed? What should it do? Y N Order_total := 0
Id Order_total
N Y Y Y prevent update recalculate Order_total recalculate Order_total recalculate Order_total recalculate Order_total
OIM
Insert Delete Update Ohr_id Item_total
Y Y
2 Indicate which triggers are needed and what they should do to handle the denormalized column Lcn_address of EMPLOYEES. 2 How to handle Lcn_address for EMPLOYEES
LOCATIONS (LCN) pk * * Id Address
EMPLOYEES (EPE) pk * Id fk * Lcn_id * Name * Lcn_address
Practice 82 Triggers: Solution .....................................................................................................................................................
Table LCN
Column
Needed? What should it do? N N
Address
Y Y Y N
Cascade to Employees If pk updated than extended cascade Set correct Lcn_address
other cols
EPE Insert Delete Update Lcn_id
Set correct Lcn_address Prevent update
Lcn_address Y
3 Indicate which triggers are needed and what they should do to handle the denormalized column Curr_price_ind of table PRICES. 3 How to handle Curr_price_ind for PRICES
PRODUCTS (PDT) pk * * Id Name
PRICES (PCE) pk * Pdt_id pk * Start_date o End_date * Curr_price_ind
Table Trg Type Column PDT Insert Delete PCE Insert Delete Update Pdt_id Start_date End_date
Needed? What should it do? N N Y N Y Y Y Set Curr_price_ind to NULL Re-evaluate Curr_price_ind Re-evaluate Curr_price_ind Prevent update by user Prevent overlap in price periods
Curr_price_Ind Y
Note that this solution is incomplete. There is no guarantee that the Curr_price_ind is indeed set for a price with Start_date Sysdate End_date. To achieve that you need to set a timer that checks, say once a day, if the End_date of a price that is marked as current has expired.
Practice 83 Denormalize Price Lists: Solution

Describe what type of denormalization you would implement and what code you would add to ensure the database does not lose any integrity. The next diagram shows the current table schema. Consider both issues described above when deciding which types of denormalization to implement. You could handle the design using two denormalization techniques. You could use the Current Column Indicator technique for the performance issue, and the End Date Column to allow managers to pre-enter price lists. Slow Performance You can increase performance on queries, by adding a denormalized column to the GLOBAL_PRICES table. Since this table will store a large volume of records of which only very few will be current, you could consider adding a Current_indicator column to the table. Some additional code is required to populate the column correctly. The code we need to add should read the Start_date column in the PRICE_LISTS table and set the current record indicator to reflect the current amount. This code will populate the current record indicator, but when should it fire? Let us assume the price of a product can only change once a day. With this scenario, we can simply set a timer for twenty-four hours, and when it expires, fire the code to update current record indicators, if there have been any changes in the price lists. Pre-entering Price Lists The issue of pre-entering price list information, before its effective date will require another type of denormalization. Implementing the corporate policy of not waiting to make changes to the Price list requires a similar, and different, type of denormalization. We need to add an End Date Column to the PRICE_LISTS table. If we add this new column, then we can use it to show a prices expiration date, before that date is reached. So, rather than calculating the expiration date for a price to be equal to the start date of the next sequential price, we can enter the start date, price, and end date for the price when we insert the original record. In some cases the end date may not be known at the time the record is inserted, so we will make that column optional. The code we need to add should fire any time a price list is inserted or updated. The code will read the start date of the current price list, then update the end date of the prior price list record. There is a small cost during DML, but it is minimal. The diagram below shows the table diagram after both denormalization techniques have been implemented.
Practice 83 Denormalize Price Lists: Solution .....................................................................................................................................................
PRICE_LISTS (PLT) pk * Start_date pk,fk * Cty_code * End_date
GLOBAL_PRICES (GPE) pk,fk * Plt_start_date pk,fk * Plt_cty_code * Amount * Current_indicator
Practice 84 Global Naming: Solution

Using the design below, denormalize the table design and describe the additional code that will allow this requirement to be implemented. One solution to this requirement could be to store the Name for a PRODUCT with English as language in a new denormalized column in the PRODUCTS table. This Corporate_name column would then contain the corporate names for every global product. You would also need to add some application code to update the Corporate_name column in the PRODUCTS table, if there are any inserts in the PRODUCT_NAMES table and if there are changes made to the Name column from the PRODUCT_NAMES table where the language is English. The diagram below show the way the tables design could be structured.
LANGUAGES (LGE) pk * Code * Name
PRODUCTS (PDT) pk *
o
PRODUCT_NAMES (PNE) pk,fk * Pdt_code pk,fk * Lge_code * Name
Code Size Corporate_Name
Practice 91 Data Types: Solution .....................................................................................................................................................
Practice 91 Data Types: Solution

1 Here you see table names and column names and the suggested data type. Do a quality check on these. If you think it is appropriate, suggest an alternative.
1
yp
Table COUNTRIES CURRENCIES EXCHANGE_RATES PRICE_LISTS PRODUCT_GROUPS PRODUCTS Column Code Code Month Rate Start_date End_date Name Code Size Pdt_type Suggested Data Type
( )
Your Choice Data Type?
Char(2) Char(3) Number(2) Number(12,4)
Varchar2(2) Varchar2(3) Date Number(8,4) Date Date Char(8) Char(10) Number(4,2) Number(1)
Date Date
Varchar2(15) Varchar2(15) Char(1) Char(3)
Fixed length values, like the codes for countries and currencies, can best be stored using a Char data type. Month is not a date and can best be stored using a number as this allows sorting. In general: do not be hesitant to allow long character names and other values. You will regret it if you are a little too economical! 2 Suggest data types for the following columns. They are all based on previous practices.
2
yp
Table GLOBAL_PRICES LOCAL_PRICES SHOPS Column Amount Start_date End_date Amount Name Address City
( )
Your Choice Data Type Number(15,3) Date Date Number(15,3) Varchar2(50) Varchar2(50) Varchar2(50)
3 What data type would you use for a column that contains times only? 3 A time (like attribute Start_time and End_time in entity SHIFT) can be implemented in several ways. One is to use a CHAR(5) to record times like 08:55. If calculations are needed, it is often implemented as two Number(2,0) columns, one for the hours and the second one for the minutes. A third possibility is to store it as a DATE column with a fixed date (like 01/01/01 but perhaps on second thoughts, ...!). Most countries around the world use the two-decimal format for money amounts in the local currency. The other countries use no decimals. There is, as far as is known, only one country that uses three decimal places.
Practice 92 Artificial Keys: Solution .....................................................................................................................................................
Practice 92 Artificial Keys: Solution

1 Indicate for each table if you see benefits of creating an artificial key and why. COUNTRIES GLOBAL_PRICES PRICE_LISTS
1
COUNTRIES have an three-character internationally-used code, which can be used as a primary key. This code is like an abbreviation and is quite easy to memorize. I am not sure what happens when a country renames itself. This may result in a new code. Not the most convincing candidate for an artificial key. b GLOBAL_PRICES has no need for an artificial key as there are currently no tables referring to it. If, however, there is a chance there will be references in the future, an artificial key would make sense. c PRICE_LISTS seems a good candidate for an artificial key, as the UID consists of two components, one of which is a date. 2 For which tables (if any) based on the Moonlight model does it not make any sense at all to create artificial keys? 2 An artificial key on tables EXCHANGE_RATES, GLOBAL_PRICES (see above), LOCAL_PRICES, PRODUCT_NAMES would only be an interesting alternative if the primary key for these tables was referenced in other (future) tables.
a
Practice 93 Product Pictures: Solution

1 Decide what data type you would advise to be used for each column. 1 Which data type would you use for each column? Picture LONG RAW Html_doc LONG 2 You have heard that an old Oracle version would not accept more than one long type column per table. You are not sure if this is still a limitation. Advise about the implementation. 2 Advise about the implementation. See the table structure diagram. There can be one table for multiple LONG columns for a product. There must be a second table for the LONG RAW columns. This model is, in fact, a vertical partitioning of a product record. It would also be a good structure when tables allow more than one long type column. Separating the huge columns from the small ones increases the speed of a read considerably.
PRODUCTS (PDT) pk * Code .
TEXT_DOCUMENTS (TDT) pk,fk pk * Pdt_code * Info_type o Information varchar2(3) varchar2(20) CLOB
BINARY_DOCUMENTS (BDT) pk,fk pk * Pdt_code * Info_type o Information varchar2(3) varchar2(20) BLOB
A-58
B
.................................
Normalization
Lesson B: Normalization .........................................................................................................................................
Introduction
Lesson aim This lesson describes the steps to normalizing table data to the third normal form for those cases when there is no possibility to perform a full data analysis.
Overview
Table Normalization Normal Forms of Tables
8-2
Topic Introduction Normalization and its Benefits First Normal Form Second Normal Form Third Normal Form Normalization During Data Modeling Summary
See Page 2 3 7 9 11 13 16
Objectives At the end of this lesson, you should be able to do the following: Define normalization and explain its benefits Place tables in Third Normal Form
............................................................................................................................................. B-2
Normalization and its Benefits .........................................................................................................................................
Normalization and its Benefits

Why and When to Normalize Tables Before we even talk about why you should normalize, first consider when you should normalize. If you are developing an application system, and use the techniques of entity relationship modeling, then you will not need to normalize. One of the advantages of entity modeling is that the resulting table design is already normalized, provided there are no obvious errors in the ER model. The only time you will need to normalize the data is if there has been no time to build an entity model and when a set of tables is already available. You can then employ the normalization techniques following the initial database design as a last chance to check for existing database integrity. History of Normalization Normalization is a technique established by the originator of the relational model, E.F. Codd. The complete set of normalization techniques, include twelve rules that databases need to follow in order to be described as truly normalized. It is a technique that was created in support of relational theory, years before entity modeling was developed. The entity modeling process has incorporated many of the normalization techniques to produce a normalized entity relationship diagram. Two terms that have their origins in the normalization technique are still widely in use. One is normalized data, the other is denormalization. Objective of Normalization The major objective of normalization is to remove redundant data from an existing set of tables or table definitions, thereby increasing the integrity of the database design and to maximize flexibility of data storage. Removing redundant data helps to eliminate update anomalies. The first three normal forms progress in a systematic manner to achieve this objective. There are many other normal forms in addition to the first three, and they deal with more subtle anomalies. In general, the IT industry considers normalization to the Third form an acceptable level to remove redundancy. With a few exceptions, higher normalization levels are not widely used. The major subject of normalization is tables, not entities.
......................................................................................................................................... B-3
Why Normalize?
An Entity Model is not always available as a starting point for design To reduce redundant data in existing design To increase integrity of data, and stability of design To identify missing tables, columns and constraints
Note: Third normal form is the generally-accepted goal for a database design that eliminates redundancy.
8-3
Normalization Compared to Normalized Data Normalized data is data that contains no redundancies. This is important as data redundancy may cause integrity problems. Normalization is the activity, the process, that leads to a normalized data structure as does entity relationship modeling. Benefits of Normalized Data The major benefits of a correctly normalized database from an Information Systems perspective include: Refinement of the strategy for constructing tables and selecting keys. Improved communication with the end-users application activities. Reduced problems associated with inserting and deleting data. Reduced enhancement and modification time associated with changing the data structure. Improved information for decisions relating to the physical database design. Identification of potential problems that may have been overlooked during analysis.
............................................................................................................................................. B-4
Normalization and its Benefits .........................................................................................................................................
Recognize Unnormalized Data

USER _ID ---2301 2301 2301 5607 5607 5607 7773 7773 0022 0022 USER _NAME ----Smith Smith Smith Jones Jones Jones Walsh Walsh Patel Patel MSE _ID ----54101 54098 54445 54101 54512 54660 54101 54554 54101 54512 REC_ DATE ----05/07 07/12 10/06 05/07 06/07 12/01 05/07 03/17 05/07 06/07 SRVR _ID ---3786 3786 3786 6001 6001 6001 9988 9988 2201 2201 SERVER _NAME -----IMAP05 IMAP05 IMAP05 IMAP08 IMAP08 IMAP08 EMEA01 EMEA01 EMEA09 EMEA09
SUBJECT --------------Meeting Today Promotions Next Assignment Meeting Today Lunch? Jogging Today? Meeting Today Stock Quote Meeting Today Lunch?
TEXT ---------There is.. I like to. Your next. There is.. Can you... Can you... There is.. The latest There is.. Can we ...
8-4
Unnormalized Data Data that has not been normalized is considered to be unnormalized data or data in zero-normal form. This data is not to be confused with data that is denormalized. If no ERM was created at the start of a database design project, you are likely to have unnormalized data, not denormalized data. If you want to add redundancy, for faster performance or other reasons, you follow the rules defined during the process of denormalization. But, to denormalize data you must start with normalized data. You cannot denormalize an unnormalized design, just as you cannot de-ice your car, if there is no ice on it.
......................................................................................................................................... B-5
Normalization Normalization consists of a series of rules that must be applied to move from a supposedly unnormalized set of data to a normalized structure. The process is described in various steps which lead to a higher level of normalization. These levels are called normal forms.
Normalization Rules
Normal Form Rule First Normal Form (1NF) Description The table must express a set of unordered, two-dimensional tables. The table cannot contain repeating groups. The table must be in 1NF. Every non-key column must be dependent on all parts of the primary key. The table must be in 2NF. No non-key column may be functionally dependent on another non-key column.
Second Normal Form (2NF)
Third Normal Form (3NF)
Each non-primary key value MUST be dependent on the key, the whole key, and nothing but the key.
8-5
............................................................................................................................................. B-6
First Normal Form .........................................................................................................................................
First Normal Form

Definition of First Normal Form (1NF) The table must express a set of unordered, two-dimensional tables structures. A table is considered in the first normal form if it contains no repeating groups. Steps to Remove Repeating Groups 1 Remove the repeating columns from the original unnormalized table. 2 Create a new table with the primary key of the base table and the repeating columns. 3 Add another appropriate column to the primary key, which ensures uniqueness. 4 Create a foreign key in the new table to link back to the original unnormalized table.
Converting to First Normal Form

USER _ID ---2301 2301 2301 5607 5607 5607 7773 7773 0022 0022 USER _NAME ----Smith Smith Smith Jones Jones Jones Walsh Walsh Patel Patel MSE _ID ----54101 54098 54445 54512 54101 54660 54101 54554 54101 54512 REC_ DATE ----05/07 07/12 10/06 06/07 05/07 12/01 05/07 03/17 05/07 06/07 SUBJECT --------------Meeting Today Promotions Next Assignment Lunch? Meeting Today Jogging Today? Meeting Today Stock Quote Meeting Today Lunch? SRVR TEXT _ID --------------There is.... 3786 I like to... 3786 Your next... 3786 Can you..... 6001 There is.... 6001 Can you..... 6001 There is.... 9988 The latest.. 9988 There is.... 9988 Can we ..... 9988 SERVER _NAME -----IMAP05 IMAP05 IMAP05 IMAP08 IMAP08 IMAP08 EMEA01 EMEA01 EMEA01 EMEA01
1. Remove repeating group from the base table. 2. Create a new table with the PK of the base table and the reporting group.
8-6
......................................................................................................................................... B-7
First Normal FormSingle Record

USERS (unnormal) USER USER MSE _ID _NAME _ID ---- ----- ----2301 Smith 54101 REC_ SRVR SERVER DATE SUBJECT TEXT _ID _NAME ----- ------------- ---------- ---- -----05/07 Meeting Today There is.. 3786 IMAP05 Can you... 6001 IMAP08
5607 Jones 54512 06/07 Lunch?
7773 Walsh 54101 05/07 Meeting Today There is.. 9988 EMEA01 0022 Patel 54101 05/07 Meeting Today There is.. 9988 EMEA01 USER _ID ---2301 5607 7773 0022 USER _NAME ----Smith Jones Walsh Patel SRVR _ID ---3786 6001 9988 9988 SERVER _NAME -----IMAP05 IMAP08 EMEA01 EMEA01
USERS (normal)
8-7
First create a second table to contain the repeating group columns. Then create a primary key composed of the primary key from the unnormalized table and another column that is unique. Finally create a foreign key to link back to the first table.
First Normal FormRepeating Groups

RECEIVED_ MESSAGES (1NF) USER _ID ---2301 2301 2301 5607 5607 5607 7773 7773 SRVR 0022 _ID 0022 ---3786 6001 9988 9988 MSE REC_ _ID DATE SUBJECT ----- ----- --------------54101 05/07 Meeting Today 54098 07/12 Promotions 54445 10/06 Next Assignment 54101 05/07 Meeting Today 54512 06/07 Lunch? 54660 12/01 Jogging Today? 54101 05/07 Meeting Today 54554 SERVER03/17 Stock Quote 54101 _NAME05/07 Meeting Today 54512 ------06/07 Lunch? IMAP05 IMAP08 USERS (normal) EMEA01 EMEA01 TEXT ---------There is.. I like to. Your next. There is.. Can you... Can you... There is.. The latest There is.. Can we ...
USER _ID ---2301 5607 7773 0022
USER _NAME ----Smith Jones Walsh Patel
8-8
............................................................................................................................................. B-8
Second Normal Form .........................................................................................................................................
Second Normal Form

Definition of Second Normal Form (2NF) A table is in second normal form if the table is in the first normal form and every nonprimary key column is functionally dependent upon the entire primary key. No nonprimary key column can be functionally dependent on part of the primary key. Depends on is defined as: a column B depends on column A this means that B must be re-evaluated whenever A changes. A table in the first normal form will be in second normal form if any one of the following apply: The primary key is composed of only one column. No nonkeyed columns exist in the table. Every nonkeyed attribute is dependent on all of the columns contained in the primary key.
Converting to Second Normal Form
1. Determine which non-key columns are not dependent upon the tables entire primary key. 2. Remove those columns from the base table. 3. Create a second table with those columns and the columns from the PK that they are dependent upon.
8-9
Steps to Remove Partial Dependencies 1 Determine which nonkey columns are dependent upon the tables entire primary key. 2 Remove those columns from the base table. Create a second table with those nonkeyed columns and a copy of the columns from the primary key that they are dependent upon. 3 Create a foreign key from the original base table to the new table, linking to the new primary key.
......................................................................................................................................... B-9
Tables Already in Second Normal Form

USERS USER _ID ---2301 5607 7773 0022 USER _NAME ----Smith Jones Walsh Patel SRVR _ID ---3786 6001 9988 9988 SERVER _NAME -----IMAP05 IMAP08 EMEA01 EMEA01
Is the USERS table already in 2NF?
8-10
Convert to Second Normal Form

RECEIVED_ MESSAGES (1NF) RECEIVED_ MESSAGES (2NF) USER MSE _ID _ID ---- ----2301 54101 2301 54098 2301 54445 5607 54101 5607 54512 5607 54660 7773 54101 7773 54554 0022 54101 0022 54512
8-11
USER MSE REC_ _ID _ID DATE SUBJECT TEXT ---- ----- ----- -------------- --------2301 54101 05/07 Meeting Today There is. 2301 54098 07/12 Promotions I like to 2301 54445 10/06 Next Assignmen Your next 5607 54101 05/07 Meeting Today There is. 5607 54512 06/07 Lunch? Can you.. 54660 12/01 Jogging Today? Can you.. REC_5607 54101 05/07 Meeting Today There is. DATE7773 7773 54554 03/17 Stock Quote The lates ----0022 54101 05/07 Meeting Today There is. 05/07 0022 54512 06/07 Lunch? Can we .. 07/12 10/06 MESSAGES MSE 05/07 _ID SUBJECT TEXT (2NF) 06/07 ----- ------------ --------12/01 54101 Meeting Toda There is. 05/07 54098 Promotions I like to 03/17 54445 Next Assignm Your next 05/07 54512 Lunch? Can you.. 06/07 54660 Jogging Toda Can you.. 54554 Stock Quote The lates
............................................................................................................................................. B-10
Third Normal Form .........................................................................................................................................
Third Normal Form

Definition of Third Normal Form (3NF) A table is in third normal form if every nonkeyed column is directly dependent on the primary key, and not dependent on another nonkeyed column. If the table is in second normal form and all of the transitive dependencies are removed, then every nonkeyed column is said to be dependent upon the key, the whole key, and nothing but the key.
Converting to Third Normal Form
Remove any columns that are dependent upon another non-key column: 1. Determine which columns are dependent upon another non-key column. 2. Remove those columns from the base table. 3. Create a second table with those columns and the non-key columns that they are dependent upon.
8-12
Steps to Remove Transitive Dependencies 1 Determine which columns are dependent on another non-keyed column. 2 Remove those columns from the base table. 3 Create a second table with those columns and the non-key columns that they are dependent upon. 4 Create a foreign key in the original table linking to the primary key of the new table.
......................................................................................................................................... B-11
Tables Already in Third Normal Form

No non-key column can be functionally dependent upon another non-key column.
RECEIVED_ MESSAGES (2NF) USER MSE _ID _ID ---- ----2301 54101 2301 54098 2301 54445 5607 54101 5607 54512 5607 54660 7773 54101 7773 54554 0022 54101 0022 54512
8-13
REC_ DATE ----05/07 07/12 10/06 05/07 06/07 12/01 05/07 03/17 05/07 06/07
MESSAGES (2NF) ID SUBJECT ----- -------------54101 Meeting Today 54098 Promotions 54445 Next Assignmen 54512 Lunch? 54660 Jogging Today? 54554 Stock Quote
TEXT --------There is. I like to Your next Can you.. Can you.. The lates
Are these two tables in third normal form? Why?
Converting to Third Normal Form

USERS ID ---2301 5607 7773 0022 NAME ----Smith Jones Walsh Patel SRVR _ID ---3786 6001 9988 9988
USERS USER _ID ---2301 5607 7773 0022 USER _NAME ----Smith Jones Walsh Patel SRVR _ID ---3786 6001 9988 9988 SERVER _NAME -----IMAP05 IMAP08 EMEA01 EMEA01
MAIL_ ID SERVER ---3786 6001 9988
NAME -----IMAP05 IMAP08 EMEA01
8-14
The theory of normalization goes further than the third normal form to cater for several problematic constructions that may remain. Those normal forms are outside the scope of this lesson.
............................................................................................................................................. B-12
Normalization During Data Modeling .........................................................................................................................................
Normalization During Data Modeling

If you have created a correct entity model, then the tables created during design will conform to the rules of normalization. Each formal normalization rule has a corresponding data model interpretation. The interpretations are as follows:
First Normal Form in Data Modeling

USER # Name * Person Name * Message Receive Date o Message Subject o MessageText First Normal Form Rule A table must contain no repeating groups. Corresponding Data Modeling Rule All attributes must be single-valued.
RECEIVED MESSAGE # Receive Date o Subject o Text

8-15
USER # Name * Person Name
First Normal Rule A table must contain no repeating groups. Corresponding Data Modeling Rule All attributes must be single-valued. You can often recognize the misplaced attributes by the fact that there is the same (entity) name in the attribute name, such as Message Subject and Message Text.
......................................................................................................................................... B-13
Second Normal Form in Data Modeling

Second Normal Form Rule Every non-key column must be dependent upon all the parts of the primary key. Corresponding Data Modeling Rule An attribute must be dependent upon its entitys entire unique identifier.
RECEIVED MESSAGE # User Name * Receive Date * Subject RECEIVED MESSAGE # User Name * Receive Date
8-16
including included in
MESSAGE # Id o Text
including
MESSAGE # Id included o Text in * Subject
Second Normal Rule Every nonkeyed column must be dependent upon all parts of the primary key. Corresponding Data Modeling Rule entitys entire unique identifier. An attribute must be dependent upon its
............................................................................................................................................. B-14
Normalization During Data Modeling .........................................................................................................................................
Third Normal Form in Data Modeling

USER # Name * Person Name * Password * Server Id * Server Name
Third Normal Form Rule No non-key column can be functionally dependent upon another non-key column. Corresponding Data Modeling Rule No non-UID attribute can be dependent upon another nonUID attribute.
USER # Name * Person Name * Password
8-17
assigned to
MAIL SERVER # Id distribute * Name

mail to
Third Normal Rule No nonkeyed column can be functionally dependent upon another nonkeyed column. Corresponding Data Modeling Rule another non-UID attribute No non-UID attribute can be dependent upon
......................................................................................................................................... B-15
Summary
Summary
1NF The table must express a set of unordered, twodimensional tables. The table cannot contain repeating groups. 2NF The table must be in 1NF. Every non-key column must be dependent on all parts of the primary key. 3NF The table must be in 2NF. No non-key column may be functionally dependent on another non-key column. An entity model transforms into normalized data design.
8-18
............................................................................................................................................. B-16
Instructor Notes
Instructor Note Topic Timings Lecture xx minutes Practice xx minutes Total xx minutes
A A
N orm alization
Co pyrig ht O racle Co rpora tion , 19 99. A ll rights reserve d.
O verview
Tell the students you will show them how to remove redundancy in an existing set of tables.
T a b le N orm aliza tio n N o rm al F o rm s o f T a b le s
8 -2
W h y N o rm a lize?
A n E n tity M o d e l is n o t a lw a ys a va ila b le as a startin g p o in t for d es ig n T o re d uc e red un d a n t d ata in e xis tin g d e sig n T o in c re ase in te g rity o f d a ta , an d s ta b ility o f d es ig n T o id e n tify m iss in g tab le s, c olu m n s an d co n s traints
N o te: Th ird n o rm a l fo rm is th e g en e ra lly -a cc e pte d g o a l fo r a d ata b as e de s ig n th at e lim in ates re d u n d an c y.

8 -3
Things have changed over the past ten years or so. More people create data models, and fewer start outright at table design. An ERM will translate to a normalized database design. So, why would you need to normalize a table design? Typically an effort to take existing table structures and move them to new implementation technology, without revisiting the business requirements, are candidates for normalization. In this course we will only look at normalization at the third level, but Codd described twelve normal levels in his original assertions. Unnormalized data is not de-normalized. Point out some of the repeating values.
R eco gnize U nn orm alize d D ata

U SE R _I D - -- 2 30 1 2 30 1 2 30 1 5 60 7 5 60 7 5 60 7 7 77 3 7 77 3 0 02 2 0 02 2 U S ER _ N AM E - - -- S m it h S m it h S m it h J o ne s J o ne s J o ne s W a ls h W a ls h P a te l P a te l MSE _ID - -- - 5 41 0 1 5 40 9 8 5 44 4 5 5 41 0 1 5 45 1 2 5 46 6 0 5 41 0 1 5 45 5 4 5 41 0 1 5 45 1 2 R EC _ D AT E - -- - 0 5/ 0 7 0 7/ 1 2 1 0/ 0 6 0 5/ 0 7 0 6/ 0 7 1 2/ 0 1 0 5/ 0 7 0 3/ 1 7 0 5/ 0 7 0 6/ 0 7 SR V R _I D -- - 37 8 6 37 8 6 37 8 6 60 0 1 60 0 1 60 0 1 99 8 8 99 8 8 22 0 1 22 0 1 S ER V ER _ NA M E - -- - -I MA P 05 I MA P 05 I MA P 05 I MA P 08 I MA P 08 I MA P 08 E ME A 01 E ME A 01 E ME A 09 E ME A 09
S UB J EC T - -- - -- - -- - -- - -M ee t in g T o da y P ro m ot i on s N ex t A s si g nm e nt M ee t in g T o da y L un c h? J og g in g T o da y ? M ee t in g T o da y S to c k Q uo t e M ee t in g T o da y L un c h?
TE XT -- -- - - -- -Th er e is .. I li k e t o. Yo ur n ex t. Th er e is .. Ca n y o u. .. Ca n y o u. .. Th er e is .. Th e l a te st Th er e is .. Ca n w e . ..
8 -4
......................................................................................................................................... B-17
N orm alizatio n R u les

N orm al Form R ule First N orm al Form (1N F) D escription The table m u st express a set of unordered, tw o-dim ensional tables. The table can not contain repeating groups. The table m u st be in 1N F. E very non-key colu m n m ust be dependent on all parts o f the prim ary key. The table m u st be in 2N F. N o non-key colum n m ay be functionally depende nt on another no n-key colum n.
Normalization at the table level produces the same table structure as one created following a completed entity model.
S econd N orm al Form (2 N F)
Third N orm al Form (3N F )
E ach non-prim ary key value M U S T be dep endent on the key, the w hole key, and noth ing but the key.
8 -5
C onv erting to Firs t N orm al Form

U S ER _ID - - -2 3 01 2 3 01 2 3 01 5 6 07 5 6 07 5 6 07 7 7 73 7 7 73 0 0 22 0 0 22 US E R _N A ME -- - -Sm i th Sm i th Sm i th Jo n es Jo n es Jo n es Wa l sh Wa l sh Pa t el Pa t el MSE _ID - -- - 5 41 0 1 5 40 9 8 5 44 4 5 5 45 1 2 5 41 0 1 5 46 6 0 5 41 0 1 5 45 5 4 5 41 0 1 5 45 1 2 R EC _ D AT E - -- - 0 5/ 0 7 0 7/ 1 2 1 0/ 0 6 0 6/ 0 7 0 5/ 0 7 1 2/ 0 1 0 5/ 0 7 0 3/ 1 7 0 5/ 0 7 0 6/ 0 7 SU B J EC T -- - - -- - -- -- - -- Me e t in g T od a y Pr o m ot i on s Ne x t A s si gn m en t Lu n c h? Me e t in g T od a y Jo g g in g T od a y? Me e t in g T od a y St o c k Q uo te Me e t in g T od a y Lu n c h? SR V R TE XT _ID -- -- - -- - -- --- -Th er e i s .. .37 . 86 I li k e t o. .37 . 86 Yo ur ne x t. .37 . 86 Ca n y ou . .. .60 . 01 Th er e i s .. .60 . 01 Ca n y ou . .. .60 . 01 Th er e i s .. .99 . 88 Th e l at e st .99 . 88 Th er e i s .. .99 . 88 Ca n w e . .. .99 . 88 S ER V ER _N A ME - -- - -I MA P 05 I MA P 05 I MA P 05 I MA P 08 I MA P 08 I MA P 08 E ME A 01 E ME A 01 E ME A 01 E ME A 01
Purple highlights the columns removed from the unnormalized table.
1. R em o ve repeating group from the base table. 2. C reate a new table w ith the P K of the base table and the reporting group .
8 -6
Firs t N o rm al Form S in gle R eco rd

U S E R S (unnorm al) U SE R U S ER MSE _ ID _ N AM E _ ID - -- - - - -- - -- - -2 30 1 S m it h 54 1 01 RE C _ S R VR SE R VE R DA T E SU B JE CT TE X T _ ID _ N AM E -- - -- -- - -- -- - - -- - - -- - -- - - -- - - - -- -- - -- 05 / 07 Me e ti ng T od a y Th e re i s. . 3 7 86 IM A P0 5 Ca n y o u .. . 6 0 01 IM A P0 8
Just show them the new table structure. Point out the primary key of the USERS table: USER_ID.
5 60 7 J o ne s 54 5 12 06 / 07 Lu n ch ?
7 77 3 W a ls h 54 1 01 05 / 07 Me e ti ng T od a y Th e re i s. . 9 9 88 EM E A0 1 0 02 2 P a te l 54 1 01 05 / 07 Me e ti ng T od a y Th e re i s. . 9 9 88 EM E A0 1 US ER _I D -- -23 01 56 07 77 73 00 22 US E R _N A M E -- - - Sm i t h Jo n e s Wa l s h Pa t e l S RV R _I D - -- 3 78 6 6 00 1 9 98 8 9 98 8 S E RV E R _ NA M E - - -- - I M AP 0 5 I M AP 0 8 E M EA 0 1 E M EA 0 1
USERS (norm al)
8 -7
First N orm al Fo rm R e peating G ro ups

R E C E IV E D _ MESSAGES (1N F) US E R _I D -- - 23 0 1 23 0 1 23 0 1 56 0 7 56 0 7 56 0 7 77 7 3 77 SR 7 V3 R 00 _2 I2 D 00 -- 2 -2 37 8 6 60 0 1 99 8 8 99 8 8 MS E R EC _ _I D D AT E S UB J EC T - - -- - - -- - - - -- - -- - -- - -- -- 5 4 10 1 0 5/ 0 7 M ee t in g T o da y 5 4 09 8 0 7/ 1 2 P ro m ot i on s 5 4 44 5 1 0/ 0 6 N ex t A s si g nm en t 5 4 10 1 0 5/ 0 7 M ee t in g T o da y 5 4 51 2 0 6/ 0 7 L un c h? 5 4 66 0 1 2/ 0 1 J og g in g T o da y? 5 4 10 1 0 5/ 0 7 M ee t in g T o da y 5 4 55 SE R V4 ER0 3/ 1 7 S to c k Q uo t e 54 _10 N A1 ME0 5/ 0 7 M ee t in g T o da y 5 4 51 -- -2 --0 6/ 0 7 L un c h? IM A P 05 IM A P 08 U S E R S (norm al) EM E A 01 EM E A 01 TE X T -- - -- -- - -Th e re i s .. I l ik e t o. Yo u r ne x t. Th e re i s .. Ca n y ou . .. Ca n y ou . .. Th e re i s .. Th e l at e st Th e re i s .. Ca n w e . ..
Primary key of RECEIVED_MESSAGES is User_id and Message_id. The foreign key constraint that refers to USERS includes the User_id column.
U SE R _ ID - -- 2 30 1 5 60 7 7 77 3 0 02 2
U S ER _ N AM E - - -- S m it h J o ne s W a ls h P a te l
8 -8
C o nvertin g to S econd N orm al F orm
1 . De te rm in e w h ich n o n-k ey co lu m n s are n o t d ep e n d en t u p o n th e ta b le s en tire p rim ary k ey . 2 . Re m o ve th o se c o lu m n s fro m th e b ase ta ble. 3 . C re a te a se co n d ta b le w ith th o se c olu m n s an d th e c olu m n s from th e P K th a t th ey are d e p en d e n t upon.
8 -9
............................................................................................................................................. B-18
T ables A lready in Sec ond N orm al Fo rm

USER S U S ER _ID - - -2 3 01 5 6 07 7 7 73 0 0 22 US E R _N A ME -- - -Sm i th Jo n es Wa l sh Pa t el S R VR _ ID - - -3 7 86 6 0 01 9 9 88 9 9 88 S E RV E R _ NA M E - - -- - I M AP 0 5 I M AP 0 8 E M EA 0 1 E M EA 0 1
Moving to second normal form removes partial dependencies. The mandatory requirement for any table to be considered for second normal form is a concatenated primary key. You gotta be a girl to try out for the girls team.
Is the U S E R S table already in 2N F?
8 -1 0
C o nvert to S econd N orm al F orm

R E C E IV E D _ MESSAGES (1N F) R E C E IV E D _ MESSA GES (2N F) U S ER MS E _ID _I D - - -- - - -- 2 3 01 5 4 10 1 2 3 01 5 4 09 8 2 3 01 5 4 44 5 5 6 07 5 4 10 1 5 6 07 5 4 51 2 5 6 07 5 4 66 0 7 7 73 5 4 10 1 7 7 73 5 4 55 4 0 0 22 5 4 10 1 0 0 22 5 4 51 2
8 -1 1
US ER MS E R E C _ _I D _I D D A T E S U BJ E CT T E XT -- -- -- -- - - - - -- - - -- - -- - -- - -- - - - -- -- - -23 01 54 10 1 0 5 / 07 M e et i ng To d ay T h er e i s. 23 01 54 09 8 0 7 / 12 P r om o ti o ns I li ke to 23 01 54 44 5 1 0 / 06 N e xt As s ig n me n Y o ur n e xt 56 07 54 10 1 0 5 / 07 M e et i ng To d ay T h er e i s. 56 07 54 51 2 0 6 / 07 L u nc h ? C a n yo u .. 07 54 66 0 1 2 / 01 J o gg i ng To d ay ? C a n yo u .. R E C_ 56 73 54 10 1 0 5 / 07 M e et i ng To d ay T h er e i s. D A TE 77 73 54 55 4 0 3 / 17 S t oc k Q u ot e T h e la t es - - -- 77 54 10 1 0 5 / 07 M e et i ng To d ay T h er e i s. 0 5 /0 00 7 22 C a n we .. 0 7 /1 00 2 22 54 51 2 0 6 / 07 L u nc h ? 1 0 /0 6 MESSAGES M SE 0 5 /0 7 _ ID SU B JE C T T E XT (2N F) 0 6 /0 7 -- - -- -- - -- - -- - -- - - - -- -- - -1 2 /0 1 54 1 01 Me e ti n g T od a T h er e i s. 0 5 /0 7 54 0 98 Pr o mo t io n s I li ke to 0 3 /1 7 54 4 45 Ne x t A ss i gn m Y o ur n e xt 0 5 /0 7 54 5 12 Lu n ch ? C a n yo u .. 0 6 /0 7 54 6 60 Jo g gi n g T od a C a n yo u .. 54 5 54 St o ck Qu o te T h e la t es
The primary key of Received_Messages is User_Id and Mse_Id. Primary key of MESSAGES is Mse_Id. Only the column (Rec_Date) representing the date a particular message was received by a specific user, belongs in RECEIVED_MESSAGES. The Mse_Id, in RECEIVED_MESSAGES, is the foreign key column in the fk constraint to the MESSAGES table. Moving to third normal form removes transitive dependencies. Make sure no non-keyed column is dependent on any other non-keyed column. You must have a direct dependency on the primary key, not an indirect one through another non-keyed column
C onve rting to T hird N orm al F orm
R e m o v e a n y co lu m n s th at a re d ep e n d en t u p o n a n o the r n o n -ke y co lu m n : 1 . D eterm in e w h ic h c olu m n s a re d ep e n d en t u p o n a n o the r n o n -ke y co lu m n . 2 . R em o v e th o s e co lu m n s fro m th e b as e ta b le . 3 . C rea te a s ec o n d ta b le w ith th o se c o lu m n s an d th e n o n -ke y co lu m ns th at th e y a re d ep e n d en t u p o n .
8 -1 2
Tab les A lre ady in T hird N orm al Fo rm

N o n o n -k ey c o lu m n c an b e fu n ctio n a lly d ep e n d en t u po n an o th er n on -k ey c olu m n .
R E C E IV E D _ ME SSAGES (2N F) U S ER MS E _ID _I D - - -- - - -- 2 3 01 5 4 10 1 2 3 01 5 4 09 8 2 3 01 5 4 44 5 5 6 07 5 4 10 1 5 6 07 5 4 51 2 5 6 07 5 4 66 0 7 7 73 5 4 10 1 7 7 73 5 4 55 4 0 0 22 5 4 10 1 0 0 22 5 4 51 2
8 -1 3
R E C_ D A TE - - -- 0 5 /0 7 0 7 /1 2 1 0 /0 6 0 5 /0 7 0 6 /0 7 1 2 /0 1 0 5 /0 7 0 3 /1 7 0 5 /0 7 0 6 /0 7
MESSAGES (2N F) ID SU B JE C T -- - - - -- - -- - -- - -- - -54 1 0 1 Me e ti n g T od a y 54 0 9 8 Pr o mo t io n s 54 4 4 5 Ne x t A ss i gn m en 54 5 1 2 Lu n ch ? 54 6 6 0 Jo g gi n g T od a y? 54 5 5 4 St o ck Qu o te
TE X T -- - -- - -- Th e re is . I l ik e t o Yo u r n ex t Ca n y o u. . Ca n y o u. . Th e l a te s
A re th ese tw o tables in third norm al form ? W hy?
The RECEIVED_MESSAGES table is in third normal form., due to tricky circumstances. It has only one non-keyed column, so there is no way it could be dependent on another nonkeyed column. In the MESSAGES table you just want to ask Is the Subject of the message, dependent on the text, or is the text dependent on the subject, or are both dependent on the Mse_Id?. In this case, both are directly dependent on the primary key (Mse_Id).
......................................................................................................................................... B-19
C o nverting to Th ird N orm al Fo rm

USERS ID -- - 23 0 1 56 0 7 77 7 3 00 2 2 NA M E -- - - Sm i t h Jo n e s Wa l s h Pa t e l S R VR _ ID - - -3 7 86 6 0 01 9 9 88 9 9 88
USERS US E R _I D -- - 23 0 1 56 0 7 77 7 3 00 2 2 US E R _N A M E -- - - Sm i t h Jo n e s Wa l s h Pa t e l SR VR _ ID -- -37 86 60 01 99 88 99 88 SE R V ER _ N A ME -- - - -IM A P 05 IM A P 08 EM E A 01 EM E A 01
M A IL_ SERVER
ID - -- 3 78 6 6 00 1 9 98 8
N A ME - - -- - I M AP 0 5 I M AP 0 8 E M EA 0 1
8 -1 4
The USERS table does need a little work. Column Server_Name is directly dependent on the Srvr_Id, not the User_Id. A new table is created containing both the column violating the dependency (Server_Name) and the column it is dependent on (Srvr_id). The Srvr_Id is still part of the USERS table, but only fills the role of foreign key column to the MAIL_SERVERS table. The next three slides highlight the connection of normalization to the entity modeling. Each of the three normal forms is shown with its corresponding data model rule.
First N orm al F orm in D a ta M ode ling

U SER # N am e * P erson N am e * M essage R eceive D ate o M essage S ubject o M essageText First N orm al Form R ule A table m ust c ontain no repeating grou ps. C orresponding D ata M o deling R ule A ll attributes m ust be single-value d.
R E C E IV E D MESSAGE # R eceive D ate o S ubject o Text

8 -1 5
USER # N am e * P erson N am e
Sec ond N orm al Fo rm in D ata M odeling

S eco nd N orm a l F orm Ru le E very n on -ke y co lum n m u st be dep en den t upo n all the pa rts of th e p rim ary k ey. C orresp on din g D a ta M od elin g Ru le A n attrib ute m ust be de pe nde nt up on its en tity s e ntire un iqu e ide ntifier.
R E C E IV E D MESSAGE # U ser N am e * R eceive D ate * S ubject R E C E IV E D MESSAGE # U ser N am e * R eceive D ate
8 -1 6
Second normal form - remove partial dependencies.
in clud ing inclu ded in
MESSAGE # Id o Text
inclu din g inclu ded in
MESSAGE # Id o Text * S u bject
............................................................................................................................................. B-20
Th ird N o rm a l Form in D ata M o delin g

USER # N am e * P erson N am e * P assw ord * S erver Id * S erver N am e
Third normal form - remove transitive dependencies
T hird N o rm al Fo rm R u le N o non -k ey colu m n ca n b e fun ctio na lly dep en den t u po n an other n on -ke y co lum n . C orresp on din g D ata M od elin g Ru le N o non -U ID attrib ute c an b e d epe nd en t u po n a nothe r n on U ID attribu te .
USER # N am e * P erson N am e * P assw ord
8 -1 7
assig ned to d istribu te m ail to
M A IL S E R V E R # Id * N am e
Sum m ary
1N F Th e table m ust exp ress a se t o f u no rd ered , tw o dim en sio na l ta bles . T he tab le cann o t co ntain re pe atin g grou ps. 2N F Th e table m ust be in 1N F. E very n on -ke y co lum n m u st be de pen de nt on all parts of th e prim ary k ey. 3N F Th e table m ust be in 2N F. N o n on -ke y co lu m n m ay b e fu nc tion ally de pe nd ent on an other n on -ke y co lu m n . A n en tity m od el tran sform s into n orm alize d d ata de sig n.
8 -1 8
......................................................................................................................................... B-21
............................................................................................................................................. B-22
Index .....................................................................................................................................................
Index
A
arc 1-27, 4-12 both supertype and subtype implementation 7-25 exclusive 4-12 rules 4-14 arc implementation 7-25 generic 9-26 rules 7-25 arc or subtypes 4-16 arcs incorrect 4-15 mapping 7-19 artificial key 9-11 attribute 1-13 multiple UID 4-7 redundancy 2-16 single UID 4-7 single valued 1-13 attribute constraint 4-19 attribute representation mandatory 1-19 optional 1-19 attributes 3-19 naming 2-15 recycling 6-20 tracking 2-14 volatile 1-14 attributes modeled as PROPERTY instance 6-20
BLOB 9-6 business function 1-23 business rules 4-2
C
cascade composed UID 4-7 cascade delete 9-15 cascade update 9-15 chain pattern 6-10 CHAR 9-6 check conditional domain 4-20 conditional relationship 4-20 front door 4-20 range 4-20 state value transition 4-20 state value triggered 4-20 check constraint 4-13 classification, pattern 6-7 CLOB 9-6 column current indicator 8-20 column sequence 9-7 columns 7-5 choosing for index 9-19 end date 8-18 foreign key naming 7-9 composed UID 4-7 concatenated index 9-18 concept evolution 2-11 conceptual data modeling 1-8, 2-5, 3-26 conceptual model 7-6 conceptual modeling 1-4 conceptual models 1-28 conditional domain check 4-20 conditional nontransferability 5-9 conditional relationship 4-20 constraint check 4-13 declarative 7-7 constraints 4-2 check
B
B*Tree index 9-17 barred relationship 4-6 basket, pattern 6-6 BFILE 9-6 bill of material pattern 6-12 binary table 3-26 bitmap index 9-17
..................................................................................................................................................... Index-1
Index .....................................................................................................................................................
naming 7-10 foreign key naming 7-9 hierarchy 6-9 special 4-20 time-related 5-8 convention naming 7-8 conventions sensible use 6-18 crowsfoot 3-7 current indicator column 8-20 D
data 2-4 normalized B-3 unnormalized B-5 data blocks 9-30 data files 9-30 data modeling conceptual 2-5 physical 2-5 data type BFILE 9-6 BLOB 9-6 CHAR 9-6 CLOB 9-6 DATE 9-6 LONG 9-6 LONG RAW 9-6 NUMBER 9-6 VARCHAR2 9-6 data types Oracle 9-5 data warehouse 2-6 pattern 6-16 data warehouse system design strategy 7-8 star model 7-10, 9-14 database hierarchical 2-6 network 2-6 object oriented 2-6 relational 2-6 semantic 2-6 database structure
data blocks 9-30 data files 9-30 extents 9-30 Oracle 9-29 partitions 9-29 segments 9-29 tablespaces 9-29 DATE 9-6 date end 5-7 start 5-7 date as Opposed to day 5-5 date or day 5-5 date time 5-6 declarative constraint 7-7 default and nullify 9-15 definition denormalization 8-4 definition of an entity 1-10 degree 3-7 delete cascade 9-15 restrict 9-14 denormalization definition 8-4 denormalization techniques derivable values 8-5 hard-coded values 8-5 pre-joining tables 8-5 derivable 1-8 derivable values storing 8-6 design distributed 9-27 old fashioned 9-25 design strategy client-server 7-12 data warehouse approach 7-8 discriminator column 7-20 distributed design 9-27 benefits 9-28 domain 4-19 conditional 4-20 drawing conventions 6-17
..................................................................................................................................................... Index-2
Index .....................................................................................................................................................
E
electronic mail 2-9 elements arc 1-27 nontransferability 1-27 subtype 1-27 unique identifier 1-27 end date 5-7 end date columns 8-18 entities event 2-20 intangible 2-20 tangible 2-20 entity 3-25 formal description 2-7 inheritance 2-17 intersection 3-25 naming 2-7 subtypes 2-17 supertype 2-17 entity DAY 5-6 entity definition evolution 2-11 entity life cycle 2-12 entity relationship diagram 1-17 entity relationship model 1-17 entity relationship modeling 1-7, 1-28 ER diagram soft box 1-18 ER model transform 7-4 evolution of a concept 2-11 exclusive arc 4-12 extents 9-30
optional composed 7-15 foreign keys 7-5 form first normal B-7 second normal B-9 formal description of the entity 2-7 front door check 4-20 function business 1-23 modeling 1-23 function based index 9-18 functionality 1-23, 2-13
G
generic arc implementation 9-26 generic model 6-22 generic modeling 6-19 generic models 6-20, 6-21 graphical elements 1-17
H
hard-coded values 8-10 hidden relationships 4-18 hierarchies disputable 6-8 false 6-8 hierarchy constraints 6-9 pattern 6-8 hierarchy level indicator 8-22 historical price 5-10 homonyms 2-8 house building metaphor 1-5
F
fan trap pattern 6-15 first normal form B-7 foreign key cascade delete 9-15 cascade update 9-15 columns 7-13 constraints 7-13 default and nullify 9-15
I
identification 4-4 in database 4-5 indirect 4-8 problems 4-4 real world 4-5 identifiers information-bearing 4-11 incorrect arcs 4-15 incorrect UIDs 4-10
..................................................................................................................................................... Index-3
Index .....................................................................................................................................................
index choosing columns 9-19 partitioned 9-22 unique 9-8 when used 9-21 index organized table 9-18 index types 9-17 B*Tree 9-17 bitmap 9-17 concatenated index 9-18 function based index 9-18 reverse key 9-17 tree balanced 9-17 indexes 9-16 indicator hierarchy level 8-22 indirect identification 4-8 information 2-4 types 1-24 information-bearing identifiers 4-11 inheritance 2-17 instances 1-10, 1-11 integrity referential 9-14 intersection entity 3-25
entity 2-12 logging 5-4, 5-17 logic referential 5-9 LONG 9-6 LONG RAW 9-6
M
mandatory 3-7, 3-10 many to many (m:m) 3-9 mapping basic 7-12 entity 7-12 nontransferable relationships 7-15 relationship 7-14 terminology 7-7 mapping arcs 7-19 mapping barred relationships 7-15 mapping many-to-many relationships 717 mapping one-to-one relationships 7-18 mapping subtypes 7-20 master keeping details 8-12 repeating single detail 8-14 master detail, pattern 6-5 model conceptual 7-6 relational 7-6 modeling generic 6-19 modeling time 5-4 multiple attribute UID 4-7
J
journalling 5-4, 5-17
K
keeping details with master 8-12 key artificial 9-11 foreign 9-14 primary desirable properties 9-9 keys foreign 7-5 primary 7-5, 9-8 short-circuit 8-16 unique 7-5, 9-8
N
name space 7-11 naming attributes 2-15 check constraints 7-10 convention 7-8 entities 2-7 foreign key columns 7-9 foreign key constraints 7-9 relationships 3-5
L
life cycle
..................................................................................................................................................... Index-4
Index .....................................................................................................................................................
restrictions with Oracle 7-10 tables 7-8 naming relationships 3-5 negotiated prices 5-14 nested subtypes 2-19 network pattern 6-11 network structures 6-11 nontransferability 1-27, 3-8 conditional 5-9 normalization B-3 normalized data B-3 nouns 2-7 NUMBER 9-6
O
old fashened design generic arc implementation 9-26 unique index 9-25 old fashioned design check option views 9-25 OLTP system 7-6 one to many (1:m) 3-9 one to one (1:1) 3-9 onstraint attribute 4-19 optional 3-7 optionality 3-6 Oracle data types 9-5 Oracle database structure 9-29
roles 6-14 patterns 6-4 physical data modeling 2-5 pre-joining tables 8-8 price 5-10 negotiated 5-14 price history 5-10 price list 5-10, 5-12 priced product 5-10 primary key desirable properties 9-9 primary keys 7-5, 9-8 primary UID 4-9 primary unique identifier 3-18 product 5-10 properties primary key 9-9
R
range check 4-20 recursive relationship 3-4 recycling of attributes 6-20 redundancy 2-16 relationships 3-15 referential integrity 9-14 referential logic 5-9 relational databases 2-6 relational model 7-6 relationship conditional 4-20 many to many 3-11 mapping 7-14 master-detail 6-5 one to many 6-5 recursive 3-4 relationship ends degree 3-7 optionality 3-6 relationship name 3-5 relationship representation 1-20 relationships 1-15, 3-19 barred mapping 7-15 hidden 4-18 mandatory 1-21 many to many 3-9
P
partitioned index 9-22 partitioning tables 9-22 partitions 9-29 pattern basket 6-6 bill of material 6-12 chain 6-10 classification 6-7 data warehouse 6-16 fan trap 6-15 hierarchy 6-8 master detail 6-5 network 6-11
..................................................................................................................................................... Index-5
Index .....................................................................................................................................................
mapping 7-17 many to one 3-9 mapping nontransferable 7-15 mapping one to many 7-14 one to many 3-9 one to one 3-13 one-to-one mapping 7-18 resolving 3-25 resolving other 3-26 symmetric 6-13 UID 4-8 relationsships optional 1-21 repeating single detail with master 8-14 representation 4-4 reserved words. 2-15 resolving other relationships 3-26 resolving relationships 3-25 restrict delete 9-14 update 9-14 reverse key index 9-17 roles pattern 6-14 rows 7-5 rules about arcs 4-14 business 4-2 subtype 2-18 transformation 7-6 S
second normal form B-9 secondary UID 4-9 segments 9-29 sequences 9-13 set theory 1-12 sets. 1-12 short-circuit keys 8-16 similar structure 6-4 single attribute UID 4-7 Snowflake model 6-16 soft box 1-18 special constraints 4-20
start date 5-7 state value transition check 4-20 state value triggered check 4-20 storage implication 7-27 arc implementation 7-28 subtype implementation 7-27 supertype implementation 7-27 storing derivable values 8-6 subtype 1-27 implementatioin rules 7-23 implementation 7-23 rules 2-18 subtypes 2-17 mapping 7-20 nested 2-19 subtypes or arcs 4-16 supertype 2-17 implementatioin rules 7-20 implementation 7-20 supertype and subtype implementation arc 7-25 symmetric relationships 6-13 problem 6-13 solution 6-13 synonyms 2-7
T
table binary 3-26 index organized 9-18 naming 7-8 tables 7-5 partitioning 9-22 pre-joining 8-8 tablespaces 9-29 terminology mapping 7-7 three-tiered architecture 7-13 time modeling 5-4 time-related constraints 5-8 tracking attributes 2-14 transformation rules 7-6 transforming the ER model 7-4 tree balanced index 9-17
..................................................................................................................................................... Index-6
Index .....................................................................................................................................................
types of information 1-24
U
UID cascade composed 4-7 composed 4-7 multiple attribute 4-7 primary 4-9 relationships 4-8 secondary 4-9 single attribute 4-7 unique identifier 1-27, 4-6 primary 3-18 unique index 9-8 unique key 7-18 unique keys 7-5, 9-8 unnormalized data B-5 update cascade 9-15 restrict 9-14
V
values 1-13 derivable
storing 8-6 hard-coded 8-10 VARCHAR2 9-6 views usage 9-23 volatile attributes 1-14 W
words reserved 2-15
..................................................................................................................................................... Index-7
Index .....................................................................................................................................................
..................................................................................................................................................... Index-8

Data Modeling and Relational Database Design

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Data Modeling and Relational Database Design

Uploaded by

Copyright:

Available Formats

Data Modeling and Relational Database Design

Volume 1 Instructor Guide ...........................................................................................

Course Code 20000GC10 Edition 1.0 M08988

Technical Contributors and Reviewers

Restricted Rights Legend

..................................................................................................................................................... iv Data Modeling and Relational Database Design

Instructor Post Lesson Teaching Evaluation Suggested Graphics 8-39

Introduction to Entities, Attributes, and Relationships

Lesson 1: Introduction to Entities, Attributes, and Relationships .........................................................................................................................................

Why conceptual modeling? Introduction of the Key role players:

Entities Attributes Relationships

............................................................................................................................................. 1-2 Data Modeling and Relational Database Design

Lesson 1: Introduction to Entities, Attributes, and Relationships .........................................................................................................................................

Why Conceptual Modeling?

Why Create a Conceptual Model?

............................................................................................................................................. 1-4 Data Modeling and Relational Database Design

Why Conceptual Modeling? .........................................................................................................................................

Between Dream and Reality...

Lesson 1: Introduction to Entities, Attributes, and Relationships .........................................................................................................................................

............................................................................................................................................. 1-6 Data Modeling and Relational Database Design

Entity Relationship Modeling .........................................................................................................................................

Entity Relationship Modeling

available available as reviewed in on

# SUPPLIER CODE o EMAIL * APPROVED * REFERENCE

# REFERENCE * TITLE o VOLUME o ISSUE o PUBLISH DATE

the source of the source of

the cancellor of responsible for

the holder of responsible for

# NUMBER o TERMINATION REASON o TERMINATION DATE

the reservation for for cancelled by

the rental for

Lesson 1: Introduction to Entities, Attributes, and Relationships .........................................................................................................................................

Goals of Entity Relationship Modeling

............................................................................................................................................. 1-8 Data Modeling and Relational Database Design

Database Types .........................................................................................................................................

About the slide See Page 45

Lesson 1: Introduction to Entities, Attributes, and Relationships .........................................................................................................................................

Examples: objects, events Entities have instances.

............................................................................................................................................. 1-10 Data Modeling and Relational Database Design

More on Entities About the slide See Page 46

Entities and Instances

Lesson 1: Introduction to Entities, Attributes, and Relationships .........................................................................................................................................

Entities and Sets

An entity represents a set of instances that are of interest to a particular business.

............................................................................................................................................. 1-12 Data Modeling and Relational Database Design

Describes Quantifies Qualifies Classifies Specifies

Lesson 1: Introduction to Entities, Attributes, and Relationships .........................................................................................................................................

Entity EMPLOYEE CAR ORDER JOB TRANSACTION EMPLOYMENT CONTRACT

............................................................................................................................................. 1-14 Data Modeling and Relational Database Design

Lesson 1: Introduction to Entities, Attributes, and Relationships .........................................................................................................................................

Employees have Jobs

All EMPLOYEES have a JOB

Not all JOBS are held by an EMPLOYEE

............................................................................................................................................. 1-16 Data Modeling and Relational Database Design

Entity Relationship Models and Diagrams .........................................................................................................................................

Entity Relationship Models and Diagrams

Lesson 1: Introduction to Entities, Attributes, and Relationships .........................................................................................................................................

Entity Representation in Diagram

During design, entities usually lead to tables.

............................................................................................................................................. 1-18 Data Modeling and Relational Database Design

Attribute Representation .........................................................................................................................................

About the slide See Page 48

* Family Name * Address