Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
Volume One
Student Guide
ORACLE
Enabling the Information Age ™
1
Data Modeling and Database
Design
Student Guide • Volume One
June 1992
M00475
ORACLE
2
Data Modelling and Database Design
This software/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 software/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:
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 and as set forth in subparagraph (c) (1) (ii) of DFARS 252.227-
7013, Rights in Technical Data and Computer Software (October 1988).
Use, duplication, or disclosure is subject to restrictions stated in your contract with Oracle Corporation.
If this software/documentation is delivered to a U.S. Government Agency not within the Department of Defense, then it is
delivered with "Restricted Rights." as defined in FAR 52.227-14, Rights in Data-General, including Alternate III (June
1987).
The information in this document is subject to change without notice. If you find any problems in the documentation, please
report them to us in writing to Oracle Corporation. 500 Oracle Parkway, Redwood Shores. CA 94065-9815. Oracle
Corporation does not warrant that this document is error free.
Lotus and 1-2-3 are trademarks of Lotus Development Corporation. Macintosh and HyperCard are registered trademarks and
HyperTalk is a trademark of Apple Computer. Inc. dBase is a trademark of Ashton-Tate Corporation. IBM. MVS. DB2,
SQL/DS, and IBM PC are trademarks of International Business Machines Corporation. Microsoft and MS-DOS are
registered trademarks and Windows is a trademark of Microsoft Corporation. Paintbrush is a trademark of Zsoft Corporation.
3
CONTENTS
CONTENTS .............................................................................................................................. 4
1 INTRODUCTION.....................................................................................9
SECTION OBJECTIVES...................................................................................................... 16
SECTION OBJECTIVES...................................................................................................... 24
ENTITIES ............................................................................................................................... 29
RELATIONSHIPS ................................................................................................................. 37
4
EXERCISE 3-4 ....................................................................................................................... 43
ATTRIBUTES ........................................................................................................................ 64
ATTRIBUTE OPTIONALITY............................................................................................. 71
IDENTIFY ATTRIBUTES.................................................................................................... 73
SECTION OBJECTIVES...................................................................................................... 93
5
RESOLVE M:M RELATIONSHIPS ................................................................................... 99
6
MAP SIMPLE ENTITIES................................................................................................... 158
7 TABLE NORMALIZATION................................................................201
7
SPECIFY REFERENTIAL INTEGRITY......................................................................... 220
8
1
INTRODUCTION
9
COURSE OBJECTIVES
10
ORACLE OVERVIEW
11
ORACLE Overview - cont'd
*
Data Modelling and Database Design are techniques for analyzing
information requirements and designing relational databases.
12
ORACLE'S CASE APPROACH
Business Requirements
Operational System
13
CASE*METHOD DEVELOPMENT CYCLE
Data modeling and database design support the first three stages of the
CASE*Method Development cycle.
14
2
OVERVIEW OF
DATABASE DEVELOPMENT
15
SECTION OBJECTIVES
16
DATABASE DEVELOPMENT PROCESS
17
BUSINESS INFORMATION REQUIREMENTS
Example
"I manage the Human Resources Department for a large company. We need to keep information
about each of our company's employees. We need to track each employee's first name, last
name, job or position, hire date, and salary. For any employees on commission, we also need to
track their potential commission. Each employee is assigned a unique employee number.
Some of the employees are managers. We need to know each employee's manager, and the
employees each manager manages."
Quick Notes
• The scope of a set of information requirements may vary from the needs of a department to
the needs of a total company.
• Information requirements are tightly coupled with business function requirements. For
example, the Human Resources Department's business function requirements include Manage
employee information.
18
CONCEPTUAL DATA MODELLING OVERVIEW
Example
The following entity-relationship model represents the information requirements of the Human
Resources Department.
19
DATABASE DESIGN OVERVIEW
Example
A design for the Human Resources database is shown in the following table instance charts.
Column Name EMPN FNAM LNAME JOB HIREDATE SA COM MGR DEPTN
Key Type O
PK E L M FK1 O
FK2
Key Type PK
The Table Instance Chart for each relational table identifies the table's
columns, primary key, and any foreign keys and provides a visual view of
sample data.
20
DATABASE BUILD OVERVIEW
Example
The following Structured Query Language (SQL) statements will create the DEPARTMENT and
EMPLOYEE tables.
21
DATABASE AND APPLICATION DEVELOPMENT
22
3
BASIC
CONCEPTUAL DATA MODELLING
23
SECTION OBJECTIVES
24
CONCEPTUAL DATA MODELLING
25
Conceptual Data Modelling-cont'd
Example
The following entity-relationship model represents the information requirements of the Human
Resources Department.
26
Conceptual Data Modelling-cont'd
Robust Syntax
User Communication
Ease of Development
Definition of Scope
Quick Notes
27
Conceptual Data Modelling-cont'd
28
ENTITIES
Examples
The following might be things of significance about which a business needs to hold information:
EMPLOYEE
DEPARTMENT
PROJECT
Attributes describe entities and are the specific pieces of information, which
need to be known.
Examples
Quick Note
• An entity must have attributes that need to be known from the business's viewpoint or it is not
an entity within the scope of the business's requirements.
29
Entities - cont'd
Examples
Quick Notes
• Synonyms are useful when two groups of users have different names for the same thing of
significance.
30
Entities - cont'd
Examples
The entity EMPLOYEE has one occurrence for each employee in the business:
Jim Brown, Mary Jones, Juan Gomez, and Jill Judge are all occurrences of the entity
EMPLOYEE.
The entity DEPARTMENT has one occurrence for each department in the company:
The Finance Department, the Sales Department, and the Development Department are all
instances of the entity DEPARTMENT.
Each entity instance has specific values for the entity's attributes.
Example
The entity EMPLOYEE has attributes of name, badge number, date of birth, and salary.
The instance Jim Brown has the following values: name Jim Brown, badge number 1322, date
of birth 15-MAR-50, and salary $55,000.
Quick Notes
31
Entities - cont'd
Each instance must be uniquely identifiable from other instances of the same entity. An attribute or set
of attributes that uniquely identify an entity is called a Unique Identifier (UID).
Example
Each employee has a unique badge number. Badge number is a candidate for the entity EMPLOYEE'S
UID.
Example
Quick Notes
32
IDENTIFY AND MODEL ENTITIES
Follow the steps below to identify and model entities from a set of interview
notes.
• Is there information of interest about the entitiy that the-business needs to hold?
• Is each instance of the entity uniquely identifiable? Which attribute or attributes could serve as
its UID?
• Write a description of it. "An EMPLOYEE has significance as a paid worker at the company.
For example, John Brown and Mary Smith are EMPLOYEES."
Quick Note
• Do not disqualify a candidate entity too soon. Additional attributes of interest to the business
may be uncovered later.
33
Identify and Model Entities - cont'd
Example
Identify and model the entities in the following set of information requirements.
"I'm the manager of a training company that provides instructor-led courses in management
techniques. We teach many courses, each of which has a code, a name, and a fee. Introduction
to UNIX and C Programming-are two of our more popular courses. Courses vary in length from
one day to four days. An instructor can teach several courses. Paul Rogers and Maria Gonzales
are two of our best teachers. We track each instructor's name and phone number. Each course is
taught by only one instructor. We create a course and then line up an instructor. The students
can take several courses over time, and many of them do this. Jamie Brown from AT&T took
every course we offer! We track each student's name and phone number. Some of our students
and instructors do not give us their phone numbers.
34
Identify and Model Entities - cont'd
Solution
Entity Descriptions
• A COURSE has significance as a training event offered by the Training Company. For
example, Introduction to UNIX and C Programming.
• A STUDENT has significance as a participant in one or more COURSES. For example, Jamie
Brown.
• An INSTRUCTOR has significance as a teacher of one or more COURSES. For example, Paul
Rogers and Maria Gonzales.
35
EXERCISE 3-1
1. Identify and model the entities in the following set of information requirements. Write a brief
description of each entity. Show at least two attributes for each entity.
"I'm the owner of a small video store. We have over 3,000 videotapes that we need to keep track
of.
Each of our videotapes has a tape number. For each movie, we need to know its title and
category (e.g. comedy, suspense, drama, action, war, or sci-fi). Yes, we do have multiple copies
of many of our movies. We give each movie a specific id, and then track which movie a tape
contains. A tape may be either Beta or VHS format. We always have at least one tape for each
movie we track, and each tape is always a copy of a single, specific movie. Our tapes are very
long and we don't have any movies, which require multiple tapes.
We are frequently asked for movies starring specific actors. John Wayne and Katherine
Hepburn are always popular. So we'd like to keep track of the star actors appearing in each
movie. Not all of our movies have star actors. Customers like to know each actor's "real" birth
name and date of birth. We track only actors who appear in the movies in our inventory.
We have lots of customers. We only rent videos to people who have joined our "video club." To
belong to our club, they must have good credit. For each club member, we’d like to keep his/her
first and last name, current phone number, and current address. And, of course each club
member has a membership number.
Then we need to keep track of what videotapes each customer currently has checked out. A
customer may check out multiple videotapes at any given time. We just track current rentals.
We don't keep track of any rental histories."
36
RELATIONSHIPS
Relationship Syntax
Example
Quick Notes
37
Relationships - cont'd
Diagramming Conventions
• Optionality
• Degree
38
Relationships - cont'd
First read a relationship in one direction, and then read the relationship in
the other direction.
Example
Read this relationship first from left to right, and then from right to left.
39
Relationships - cont'd
Example
Example
40
EXERCISE 3-2
Read relationships.
41
EXERCISE 3-3
42
EXERCISE 3-4
Optional Exercise
b. Each TABLESPACE must be part of one and only one ORACLE DATABASE.
43
RELATIONSHIP TYPES
Relationship Types
All relationships should represent the information requirements and rules of the business.
44
Relationship Types - cont'd
Example
Each CUSTOMER must be visited by one and only one SALES REPRESENTATIVE.
Quick Notes
45
Relationship Types - cont'd
Examples
Quick Notes
• Many to Many relationships are usually optional in both directions, although a Many to Many
Relationship may be optional in just one direction.
46
Relationship Types - cont'd
A One to One Relationship (1 to 1 or 1:1) has a degree of one and only one
in both directions.
Example
Each MICROCOMPUTER must be the host for one and only one MOTHERBOARD.
Each MOTHERBOARD may be incorporated into one and only one MICROCOMPUTER.
Quick Notes
• Entities, which seem to have a 1:1 relationship, may really be the same entity.
47
USING A RELATIONSHIP MATRIX
• A relationship matrix shows if and how each row entity on the left-hand side of the matrix is
related to each column entity shown across the top of the matrix.
• All the entities are listed along both the left-hand side of the matrix and the top of the matrix.
• If a row entity is related to a column entity, then the name of that relationship is shown in the
intersection box.
• If a row entity is not related to a column entity, then a long dash is shown in the intersection
box.
• Each relationship above the diagonal line is the inverse or mirror image of a relationship
below the line.
• Recursive relationships (between an entity and itself) are represented by the boxes on the
diagonal.
Example
The following relationship matrix shows a set of relationships between four entities.
CUSTOMER is related to ORDER and the name of the relationship is the originator of.
ORDER is related to CUSTOMER and the name of the relationship is originated by.
48
Using a Relationship Matrix - cont'd
Example
Draw a softbox for each entity and add the entity's attributes. Draw a relationship line for each
relationship, write-in the relationship's name, and add each relationship's optionality and degree.
49
ANALYZE AND MODEL RELATIONSHIPS
Steps
50
DETERMINE A RELATIONSHIP'S EXISTENCE
Example
Example
51
Determine a Relationship's Existence - cont'd
Example
52
NAME THE RELATIONSHIP
Example
Example
Log the relationship names for the relationship between DEPARTMENT and EMPLOYEE.
53
Name the Relationship - cont'd
Quick Note
54
DETERMINE RELATIONSHIP'S OPTIONALITY
Example
Example
55
DETERMINE RELATIONSHIP'S DEGREE
Example
Example
56
VALIDATE THE RELATIONSHIP
Example
57
EXERCISE 3-5
1. Analyze and model the relationships in the following set of information requirements. Use a
relationship matrix to track the existence of relationships between the entities.
"I'm the manager of a training company that provides instructor-led courses in management
techniques. We teach many courses, each of which has a code, a name, and a fee. Introduction
to UNIX and C Programming are two of our more popular courses. Courses vary in length from
one day to four days. An instructor can teach several courses. Paul Rogers and Maria Gonzales
are two of our best teachers. We track each instructor's name and phone number. Each course is
taught by only one instructor. We create a course and then line up an instructor. The students
can take several courses over time, and many of them do this. Jamie Brown from AT&T took
every course we offer! We track each student's name and phone number. Some of our students
and instructors do not give us their phone numbers."
58
Exercise 3-5 - cont'd
59
EXERCISE 3-6
1. Analyze and model the relationships in the following set of information requirements from
Exercise 3-1. Use a relationship matrix to track the existence of relationships between the
entities.
"I'm the owner of a small video store. We have over 3,000 videotapes that we need to keep track
of.
Each of our videotapes has a tape number. For each movie, we need to know its title and
category (e.g. comedy, suspense, drama, action, war, or sci-fi). Yes, we do have multiple copies
of many of our movies. We give each movie a specific id, and then track which movie a tape
contains. A tape may be either Beta or VHS format. We always have at least one tape for each
movie we track, and each tape is always a copy of a single, specific movie. Our tapes are very
long, and we don't have any movies, which require multiple tapes.
We are frequently asked for movies starring specific actors. John Wayne and Katherine
Hepburn are always popular. So we'd like to keep track of the star actors appearing in each
movie. Not all of our movies have star actors. Customers like to know each actor's "real" birth
name and date of birth. We track only actors who appear in the movies in our inventory.
We have lots of customers. We only rent videos to people who have joined our "video club." To
belong to our club, they must have good credit. For each club member, we'd like to keep their
first and last name, current phone number, and current address. And, of course each club
member has a membership number.
Then we need to keep track of what videotapes each customer currently has checked out. A
customer may check out multiple videotapes at any given time. We just track current rentals.
We don't keep track of any rental histories."
60
Exercise 3-6 - cont'd
61
LAY OUT THE E-R DIAGRAM
Make an E-R Diagram easy to read and applicable to the people who need
to work with it.
• Use an angle of 30° to 60°, which is easier to follow when relationship lines must cross.
• Avoid the use of many closely parallel lines, which are difficult to follow.
Unambiguous Text
• Put relationship names at the ends of the line and on opposite sides of the line.
Memorable Shapes
• Make the E-R Diagram memorable. People remember shapes and patterns.
• Stretch or shrink entity boxes to help the layout of the dia gram.
62
Lay Out the E-R Diagram - cont'd
Layout Rules
• Try to position a crowsfoot on the left end or the top end of the relationships line.
• Position higher volume, more volatile entities toward the top and left of the diagram.
• Position lower volume, less volatile entities toward the bottom and right of the diagram.
Quick Note
• Until an M:M relationship is resolved, at least one end of the relationship will point down or
to (he right.
63
ATTRIBUTES
Example
Example
Quick Notes
• Attribute names should be clear to the user, not codified for the developer.
• The entity's name is always a qualifier of the attribute name - e.g., code of COURSE.
Therefore, an attribute's name should not include its entity's name.
• Attribute names should be specific - e.g., is it quantity, quantity returned, or quantity
purchased?
• Always clarify a date attribute with a descriptor or verb phrase, e.g. date of contact, date
ordered.
• An attribute should only be assigned to a single entity.
64
Attributes - cont'd
Diagramming Conventions
Example
65
Attributes - cont'd
Examples
The name of a PERSON can be broken down into last name and first name.
Break down aggregate attributes and embedded code fields into simple
attributes.
Quick Notes
• Attributes containing dates, times, social security numbers, and zip codes are generally not
decomposed further.
• An attribute of address is frequently left as an aggregate and then decomposed during Design.
Alternative ly it can be decomposed into multiple attributes: apartment/suite, street address,
city, state, and zip code.
• The level of attribute decomposition will depend upon the business requirements.
66
Attributes - cont'd
Verify that each attribute has a single value for each entity instance. A
multi-valued attribute or repeating group is not a valid attribute.
Example
No, a CLIENT may be contacted multiple times, and the business needs to keep all dates of
contact. The entity CONTACT is missing.
Quick Note
67
Attributes - cont'd
Verify that an attribute is not derived or calculated from the existing values
of other attributes.
Quick Notes
• Redundant data can lead to inconsistent data values. The derived data must be revised
whenever the attributes upon which it is based are revised.
68
DISTINGUISH ATTRIBUTES AND ENTITIES
Example
Initially the user identified color scheme as an attribute of VEHICLE. Later, the user defined the
requirement to track the paint color, paint type, and trim color for each color scheme. Color
scheme then had attributes of its own, and became an entity with a relationship to VEHICLE.
Example
Quick Notes
69
Distinguish Attributes and Entities - cont'd
All entities are nouns, but not all nouns are entities.
Possesses one or more attributes Does not possess attribute (s) of its own
May have multiple occurrences associated Has a single value for each entity occurrence (no
with another entity via a relationship repeating groups)
Quick Notes
• Do not disqualify a candidate entity too quickly. Attributes for that entity may appear later.
70
ATTRIBUTE OPTIONALITY
Mandatory Attributes
• Tagged with *.
Optional Attributes
• Tagged with o.
Example
Identify the attributes for the PERSON entity. Determine their optionality.
The title and weight attributes are optional. The remaining attributes are mandatory.
71
Attribute Optionality - cont'd
Example
Are the mandatory and optional attribute tags for the PERSON entity correct? Use an Entity Instance
Chart to validate that the mandatory and optional attribute tags for the PERSON entity are correct.
Quick Note
72
IDENTIFY ATTRIBUTES
• Nouns.
73
Identify Attributes - cont'd
Sort Orders
Quick Notes
74
EXERCISE 3-7
1. Develop an E-R Diagram for the following situation. Be sure to tag each attribute with its
optionality.
"Our regional Oracle User's Group has grown to include over 200 members. We're an all
volunteer organization, and our records are a mess. We need an information system to help us
keep track of all our affairs.
We definitely need to automate our membership records. For each member, we need to keep the
member's name, title, mailing address, office phone number, type of membership (individual or
corporate), and whether or not the member is current on dues. We collect dues on a yearly basis,
and everyone's dues are due in January.
We also like to know which company a member works for, but keeping this information current
is a real chore because our members are always changing companies. We only try to track a
single current employer for each member. Our members come from many different companie s
including Coors, EG&G, and Storage Tech. A few of our members are unemployed. For each
company, we keep the company name, address, and type of business. We have a standard set of
type of business codes. We only keep the main company address for each company.
We hold various events during the year, and we'd like to track information about each event.
Some of our annual events include the September Meeting, the November Meeting, the annual
Training Day in January, and our April Meeting. We also hold specia l events each year. For
example, we held a special CASE day last May, and Richard Barker from ORACLE U.K. came
and spoke. We hold our events at several different locations around town including AT&T,
Redrocks Community College, and D.U. We'd like to track each event's date, an optional
description of the event, number of attendees, where it was held, how much money we spent on
it, and any comments on the event. We treat all comments as if they came from an anonymous
submitter. A set of comments is just a free form text statement of any length. We number each
set of comments, and we frequently get multiple sets of comments for an event.
We also track which members attended which events. Some of our members are really active,
and others attend very infrequently or just enjoy receiving our newsletter.
(continued)
75
Exercise 3-7 - cont'd
"We also need to track what type of computer platforms our members are using. We have a
unique, three-digit system identification tag for each type of platform. For example, 001 is for
IBM/MVS; 002 is for IBM/VM; 003 is for VAX/VMS; 020 is for OS/2; 030 is for PC/DOS:
050 is for Sun Unix; and 080 is for other Unix platforms.
We also like to track which application areas each member is interested in. For example,
accounting, human resources, oil and gas, pharmaceuticals, and health systems. The
applications should be portable, so we don't need to know which platforms they run on."
76
ASSIGN UNIQUE IDENTIFIERS
Example
Example
For a small theatre, each ticket is uniquely identified by its date of performance and its seat number.
The UID for the entity THEATRE TICKET is the combination of the two attributes date of
performance and seat number.
Quick Notes
77
Assign Unique Identifiers - cont'd
Example
In the banking industry, each bank is assigned a unique bank number. Within a bank, each account has
a unique account number. What is the UID of the entity ACCOUNT?
ACCOUNT is uniquely identified by its attribute number and the specific BANK the account is
related to.
Use a UID bar to indicate that a relationship is part of the entity's UID.
Example
The UID bar indicates that the relationship with BANK is part of the UID of ACCOUNT.
Quick Note
• A relationship included in a UID must be mandatory and one and only one in the direction that
participates in the UID.
78
Assign Unique Identifiers - cont'd
Example
A business needs to track the work assignments of its employees. Employees are given work
assignments to projects. An employee may be given multiple assignments to a single project, each
with a different date of assignment.
A WORK ASSIGNMENT is uniquely identified by the EMPLOYEE the WORK ASSIGNMENT is for,
the PROJECT the WORK ASSIGNMENT is to, and the date assigned.
Quick Note
• Both relationships are mandatory and one and only one in the direction included in the UID.
79
Assign Unique Identifiers - cont'd
Example
1. badge number
2. payroll number
Are they all unique? The first name/last name combination is probably not unique.
Select one candidate UID to be the primary UID, and the others to be
secondary UIDs.
Quick Notes
80
Assign Unique Identifiers - cont'd
Example
Possibly the CUSTOMER'S first and last name could be a UID. However, there could be two
CUSTOMERS with the same name.
Create an artificial attribute called CUSTOMER code which will be unique for each instance of
CUSTOMER.
Quick Notes
• Define an artificial code when the business does not have a natural attribute which uniquely
identifies an entity.
81
Assign Unique Identifiers - cont'd
• What mandatory attributes identify the entity? Seek out additional attributes that help identify
the entity. Consider creating artificial attributes for identification.
• Is the relationship mandatory and one and only one in the direction from the entity?
• Examine sample data. Does the selected combination of attributes and relationships uniquely
identify each instance of an entity?
• Are all the attributes and relationships that are included in the UID mandatory?
82
EXERCISE 3-8
Identify UIDs.
1. For the Training Company situation and E-R model from Exercise 3-5, supply attribute tags
for each attribute, and identify a UID for each entity. Add these attribute tags and UID's to the
E-R model.
"I'm the manager of a training company that provides instructor-led courses in management
techniques. We teach many courses, each of which has a code, a name, and a fee. Introduction
to UNIX and C Programming are two of our more popular courses. Courses vary in length from
one day to four days. An instructor can teach several courses, Paul Rogers and Maria Gonzales
are two of our best teachers. We track each instructor's name and phone number. Each course is
taught by only one instructor. We create a course and then line up an instructor. The students
can take several courses over time, and many of them do this. Jamie Brown from AT&T took
every course we offer! We track each student's name and phone number. Some of our students
and instructors do not give us their phone numbers."
83
EXERCISE 3-9
Identify UIDs.
1. For the Video Store situation and E-R Model from Exercise 3-6, identify a UID for each entity
and add these UIDs to the E-R model. Also, supply attribute tags for each attribute.
"I'm the owner of a small video store. We have over 3,000 video tapes that we need to keep
track of.
Each of our video tapes has a tape number. For each movie, we need to know its title and
category (e.g. comedy, suspense, drama, action, war, or sci-fi). Yes, we do have multiple copies
of many of our movies. We give each movie a specific id, and then track which movie a tape
contains. A tape may be either Beta or VHS format. We always have at least one tape for each
movie we track, and each tape is always a copy of a single, specific movie. Our tapes are very
long, and we don't have any movies, which require multiple tapes.
We are frequently asked for movies starring specific actors. John Wayne and Katherine
Hepburn are always popular. So we'd like to keep track of the star actors appearing in each
movie. Not all of our movies have star actors. Customers like to know each actor's "real" birth
name and date of birth. We track only actors who appear in the movies in our inventory.
We have lots of customers. We only rent videos to people who have joined our "video club." To
belong to our club, they must have good credit. For each club member, we’d like to keep his or
her first and last name, current phone number, and current address. And, of course each club
member has a membership number.
Then we need to keep track of what video tapes each customer currently has checked out. A
customer may check out multiple video tapes at any given time. We just track current rentals.
We don't keep track of any rental histories."
84
Exercise 3-9 - cont'd
85
EXERCISE 3-10
Identify UIDs.
1. For the Oracle User's Group situation and E-R Model from Exercise 3-7, identify a UID for
each entity and add these UIDs to the E-R Model.
"Our regional Oracle User's Group has grown to include over 200 members. We're an all-
volunteer organization, and our records are a mess. We need an information system to help us
keep track of all our affairs.
We definitely need to automate our membership records. For each member, we need to keep the
member's name, title, mailing address, office phone number, type of membership (individual or
corporate), and whether or not the member is current on dues. We collect dues on a yearly basis
and everyone's dues are due in January.
We also like to know which company a member works for, but keeping this information current
is a real chore because our members are always changing companies. We only try to track a
single current employer for each member. Our members come from many different companies
including Coors, EG&G, and Storage Tech. A few of our members are unemployed. For each
company, we keep the company name, address, and type of business. We have a standard set of
type of business codes. We only keep the main - company address for each company.
We hold various events during the year, and we'd like to track information about each event.
Some of our annual events include the September Meeting, the November Meeting, the annual
Training Day in January, and our April Meeting. We also hold special events each year. For
example, we held a special CASE day last May, and Richard Barker from ORACLE U.K. came
and spoke. We hold our events at several different locations around town including AT&T.
Redrocks Community College, and D.U. We'd like to track each event's date, an optional
description of the event, number of attendees, where it was held, how much money we spent on
it, and any comments on the event. We treat all comments as if they came from an anonymous
submitter. A set of comments is just a free form text statement of any length. We number each
set of comments, and we frequently get multiple sets of comments for an event.
We also track which members attended which events. Some of our members are really active,
and others attend very infrequently or just enjoy receiving our newsletter.
(continued)
86
Exercise 3-10 - cont'd
We also need to track what type of computer platforms our members are using. We have a
unique, three-digit system identification tag for each type of platform. For example, 001 is for
IBM/MVS; 002 is for IBM/VM; 003 is for VAX/VMS; 020 is for OS/2; 030 is for PC/DOS;
050 is for Sun Unix;, and 080 is for other Unix platforms.
"We also like to track which application areas each member is interested in. For example,
accounting, human resources, oil and gas, pharmaceuticals, and health systems. The
applications should be portable, so we don't need to know which platforms they run on."
87
REVIEW: BASIC CONCEPTUAL DATA MODELLING
Diagramming Conventions
• Soft box
• Any dimensions
3. Is there information of interest about the entity that the business needs to hold?
4. Is each instance of the entity uniquely identifiable? Which attribute or attributes could serve as
its UID?
5. Write a description of it. "An EMPLOYEE has significance as a paid worker at the company.
For example, John Brown and Mary Smith are EMPLOYEES."
88
Review: Basic Conceptual Data Modelling - cont'd
Relationship Syntax
Diagramming Conventions
89
Review: Basic Conceptual Data Modelling - cont'd
Diagramming Conventions
• Attribute names are singular, lower case, and do not include the entity's name.
90
Review: Basic Conceptual Data Modelling - cont'd
Diagramming Conventions
91
4
ADVANCED
CONCEPTUAL DATA MODELLING
92
SECTION OBJECTIVES
1. Validate that an attribute is properly placed based upon its dependence on its entity's UID.
3. Identify and model advanced data constructs including recursive relationships, subtypes, and
exclusive relationships.
93
NORMALIZE THE DATA MODEL
Second Normal Form (2NF) An attribute must be dependent upon its entity's entire unique
identifier.
Third Normal Form (3NF) No non-UID attribute can be dependent on another non-UID
attribute.
Quick Notes
• Third normal form is the generally accepted goal for a database design that eliminates
redundancy.
94
Normalize the Data Model - cont'd
Validation Check:
• Validate that each attribute has a single value for each occurrence of the entity. No attribute
should have repeating values.
Example
Does the entity CLIENT comply with 1NF? If not, how could it be converted to 1NF?
The attribute date contacted has multiple values, therefore the entity CLIENT is not in 1NF
Create an additional entity CONTACT with a M:1 relationship to CLIENT.
95
Normalize the Data Model - cont'd
Validation Check:
• Validate that each attribute is dependent upon its entity's entire unique identifier. Each specific
instance of the UID must determine a single in stance of each attribute.
• Validate that an attribute is not dependent upon only part of it's entity's UID.
Example
Each instance of a course code determines a specific value for name duration and fee. The
attributes are properly placed.
Example
Validate the placement of the attributes for the ACCOUNT and BANK entities.
Each instance of a BANK and account number determine specific values of balance and date
opened for each account. The attribute bank location is misplaced. It is dependent on BANK,
but not on account number. It should not be an attribute of ACCOUNT.
96
Normalize the Data Model - cont'd
Validation Checks:
• Validate that each non-UID attribute is not dependent upon another non-UID attribute.
• Move any non-UID attribute that is dependent upon another non-UID attribute.
Example
Are any of the non-UID attributes for this entity dependent upon another non-UID attribute?
The attributes customer name and state are dependent upon the customer id. Create another
entity called CUSTOMER with a UID of customer id, and place the attributes accordingly.
Quick Note
• If an attribute is dependent upon a non-UID attribute, move both the dependent attribute and
the attribute it is dependent upon to a new, related entity.
97
EXERCISE 4-1
1. For the following E-R Model, evaluate each entity against the rules of normalization, identify
the misplaced attribute, and explain what rule of normalization each misplaced attribute
violates.
98
RESOLVE M:M RELATIONSHIPS
Example
Consider the M:M relationship between PRODUCT and VENDOR. What is the current price of a
specific PRODUCT from a specific VENDOR?
current price seems to be an attribute of the relationship between PRODUCT and VENDOR.
99
Resolve M:M Relationships - cont'd
Example
The M:M relationship between PRODUCT and VENDOR can be resolved by adding the intersection
entity CATALOG ITEM. Current price is really an attribute of the entity CATALOG ITEM.
Once the entity CATALOG ITEM is defined, the requirement for additional attributes of
CATALOG ITEM surfaced: package quantity and unit of measure are also attributes of CATALOG
ITEM. The UID for CATALOG ITEM is composed of its two relationships.
Quick Notes
• An Intersection Entity is frequently identified by its two originating relationships - note the
two UID bars.
• Intersection entit ies usually contain consumables like quantity used and dates. They tend to be
high volume and volatile entities.
100
Resolve M:M Relationships - cont'd
Quick Notes
• A Reference Entity is an entity that has no mandatory rela tionship ends connected to it.
• When M:M relationships are resolved, the layout of the entire diagram may need to be
shuffled.
101
Resolve M:M Relationships - cont'd
Example
"Track the date each student enrolled in a course, the date the student completed the course, and
the student's grade."
Solution
ENROLLMENT has attributes of date enrolled, date completed, and grade. The UID of
ENROLLMENT is made up of its relationships to STUDENT and COURSE.
Quick Note
• This model only tracks the last date the student enrolled in a specific course. If multiple
enrollments need to be kept, include the attribute date enrolled as part of the UID.
102
Resolve M:M Relationships - cont'd
Example
"Track the date each employee is assigned to a project, and the duration of that assignment."
Add an intersection entity called WORK ASSIGNMENT with attributes date assigned and duration.
WORK ASSIGNMENT is partially identified by its relationships to EMPLOYEE and PROJECT, but
those two relationships are not enough to uniquely identify a WORK ASSIGNMENT. An employee
may have multiple assignments to a project, with different assignment dates. Therefore, the UID of
WORK ASSIGNMENT must include the related EMPLOYEE, the related PROJECT, and the
attribute date assigned.
103
Resolve M:M Relationships - cont'd
Example
What information needs to be known about the relationship between PRODUCT and VENDOR? "We
need to track the current price of a specific PRODUCT from a specific VENDOR.
Add the intersection entity VENDOR ITEM with an attribute of current price.
104
Resolve M:M Relationships - cont'd
Example
How do you identify each VENDOR ITEM? Do you use the combination of the related VENDOR
code and the PRODUCT id?
"No, we have a catalog of all orderable VENDOR ITEMs, and each VENDOR ITEM has a unique
catalog number."
According to the rules of the business, each VENDOR ITEM has a unique catalog number. So the
attribute catalog number should be the UID of VENDOR ITEM.
105
Resolve M:M Relationships - cont'd
Resolve all M:M relationships by the end of the Analysis phase. This forced
resolution may result in an Intersection Entity with no attributes.
Example
In the Video Store situation, the following M:M relationship was defined.
At the end of the Analysis Stage, the user has not identified any attributes that are associated with the
M:M relationship. Resolve the M:M relationship with an Intersection Entity with no attributes.
Quick Notes
• An Intersection Entity with no attributes is the exception to the rule that an entity must have
attributes to be an entity.
• The UID for an empty Intersection Entity is always composed of the relationships of the two
entities from which it or iginated.
106
EXERCISE 4-2
1. In the E-R Model for the Oracle User's Group from Exercise 3-10, a M:M relationship was
initially modelled between the MEMBER entity and the APPLICATION AREA entity.
Resolve that M:M relationship based upon the following additional requirements.
Additional Requirements
"We would also like to keep a brief description of each member's interest in each specific
application area. For example, one member might already have a large accounting application
system that they developed in house. Another member might be interested in an application area
without describing that interest."
107
EXERCISE 4-3
1. Resolve the following M:M Relationship between CUSTOMER and PRODUCT. Add the
attributes date ordered, quantity ordered, and price.
108
MODEL HIERARCHICAL DATA
Example
Quick Note
• Oracle's E-R Diagram layout rule Crows fly east or south causes hierarchies to be drawn
upside-down or sideways!
109
Model Hierarchical Data - cont'd
Example
What are the UIDs of the entities FLOOR, SUITE, and ROOM?
The UID of ROOM is the room id and the SUITE it is located within.
The UID of SUITE is the suite number and the FLOOR it is located on.
The UID of FLOOR is the floor number and the BUILDING it is contained in.
110
Model Hierarchical Data - cont'd
Example
In a typical organization structure, what could uniquely identify instances of the entities DIVISION,
DEPARTMENT, and TEAM?
Each TEAM could be identified based upon its DEPARTMENT, DIVISION, and COMPANY. Or
each entity could have a unique, independent, artificial identification code.
Quick Notes
111
MODEL RECURSIVE RELATIONSHIPS
Example
Each EMPLOYEE may be managed by one and only one EMPLOYEE. Each EMPLOYEE may be
the manager of one or more EMPLOYEES.
Quick Notes
• The E-R diagramming convention that shows a recursive relationship is known as a pig's ear.
• The loop can appear on any side of the entity's box, but remember that crows always fly east
or south.
112
Model Recursive Relationships - cont'd
Example
Quick Notes
• The single recursive entity must include all of the attributes of each individual entity. Ideally,
the entities at each level of the hierarchy would have the same attributes.
113
Model Recursive Relationships - cont'd
Bill of Materials data can be modelled with multiple entities for each
category of "part" and a set of relationships between each of those entities.
Example
114
Model Recursive Relationships - cont'd
Example
For the automobile manufacturing organization, consider all elementary parts, subassemblies,
assemblies, and products as instances of an entity called COMPONENT. Then the previous complex
E-R Model can be remodelled as a simple recursive relationship.
115
Model Recursive Relationships - cont'd
Example
Consider the recursive model of a Bill of Materials structure. This model will track information about
which components are part of a fan. But if a washer is part of a fan, will it also track how many
washers are parts of a fan?
Resolve this M:M recursive relationship by adding the intersection entity ASSEMBLY RULE and two
M:1 relationships back to the COMPONENT entity. ASSEMBLY RULE will have an attribute of
quantity.
The two M:1 relationships from an instance of ASSEMBLY RULE will be associated with different
instances of the COMPONENT entity. For example, the ASSEMBLY RULE instance for washers to
fan will have a M:1 relationship to the COMPONENT instance for washer and a second M:1
relationship to the COMPONENT instance for fan. The ASSEMBLY RULE entity will record the
quantity of washers, which are a part of a single fan.
116
EXERCISE 4-4
1. Develop two E-R diagrams to represent the following situation. Develop one as a hierarchical
structure, and one as a recursive structure.
"Our company sells products throughout the United States. So we've divided the U.S. into four
major sales regions: the Northern, Eastern, Southern, and Western Regions. Each sales region
has a unique region code. Each sales region is then divided into sales districts. For example, the
Western Region is divided into the Rocky Mountain, Northwest, Pacific Coast, and Pacific
Districts. Each district has a unique district code.
Each district is made up of sales territories. The Rocky Mountain District is composed of three
territories: Wyoming-Montana, Colorado, and Utah-New Mexico. The northwest District is
made up of two territories: The Washington and Oregon-Idaho territories. The Pacific Coast
District is composed of two territories: the California and Nevada territories. The Pacific
District includes the Hawaii territory and the Alaska territory. Each territory has a unique
territory code.
Then each sales territory is broken down into sales areas. For example, Colorado is made up of
two sales areas: the Front Range and the Western Slope sales areas. Each sales area has a unique
sales area code.
Each salesperson is responsible for one or more sales areas, and has a specific sales quota. We
also have sales managers who are responsible for one or more sales districts, and sales directors
who are responsible for one or more sales regions. Each sales manager is responsible for the
territories within his districts. We don't overlap our employees' responsibilities - a sales area is
always the responsibility of a single salesperson, and our managers and director's
responsibilities don't overlap. Sometimes our salespersons, managers, and directors will be on
leave or special assignments arid will not have sales turf responsibilities. We identify all our
sales personnel by their employee ids."
117
MODEL ROLES WITH RELATIONSHIPS
Example
In the E-R Model for the Training Company, we defined an INSTRUCTOR entity and a STUDENT
entity. This model works fine if an INSTRUCTOR is never a STUDENT, and a STUDENT is never
an INSTRUCTOR. But what if an INSTRUCTOR is also a STUDENT?
118
Model Roles with Relationships - cont'd
Example
For the Training Company, define a PERSON entity, which may take on the roles of instructor and/or
student.
119
MODEL SUBTYPES
Use subtypes to model exclusive entity types which have common attributes
and common relationships.
Example
"A business has defined two types of employees: exempt and non-exempt. For all employees, track
each employee's badge number, first name, last name, and assigned department. For the exempt
employees, also track employee salary. For the non-exempt employees, track the employee's hourly
rate, overtime rate, and membership in a union."
Create an EMPLOYEE supertype with two subtypes. Each EMPLOYEE is either an EXEMPT
EMPLOYEE or a NON-EXEMPT EMPLOYEE.
Quick Note
• Beware of instances that could be both subtypes - the subtype/supertype construct is incorrect
in those instances.
120
Model Subtypes - cont'd
Example
Example
All EMPLOYEES must have the attributes badge number, first name, and last name. All EMPLOYEES
Example
The NON-EXEMPT EMPLOYEE subtype has attributes of hourly rate and overtime rate, and a
relationship with the entity UNION.
Quick Note
• A subtype with no attributes or relationships of its own may be a synonym for the supertype
entity and not a subtype.
121
Model Subtypes - cont'd
All instances of the supertype entity must belong to one and only one of the
subtype entities. Subtypes must form a complete set with no overlaps.
Example
In general, a job is either a MANUAL JOB or a CLERICAL JOB, but there might be a few excep-
tions.
Example
"Each JOB must be either a MANUAL JOB, a CLERICAL JOB, or OTHER JOB."
Example
Always use the subtype OTHER when unsure about the set's completeness.
122
Model Subtypes - cont'd
Example
JET PLANE inherits the attributes and relationships of POWERED AIRPLANE, AIRPLANE, and
AIRCRAFT.
123
MODEL EXCLUSIVE RELATIONSHIPS
Model two or more mutually exclusive relationships from the same entity
using an arc.
Example
Example
Each BANK ACCOUNT either must be owned by one and only one INDIVIDUAL or must be owned
by one and only one COMPANY.
• An arc belongs to a single entity, and must only include relationships originating from that
entity.
• An entity may have multiple arcs, but a specific relationship can only participate in a single
arc.
124
Model Exclusive Relationships - cont'd
A dot on the arc is used to signify that a relationship belongs to the arc.
Any relationship crossed by the arc belongs to the arc. A break in the arc indicates a relationship,
which is not included in the arc.
125
EXERCISE 4-5
"The Right-Way Rental Truck Company rents small moving trucks and trailers for local and
one-way usage. We have 34 7 rental offices across the western United States. Our rental stock
includes a total of 5,780 vehicles including various types of trucks and trailers. We need to
implement a system to track our rental agreements and our vehicle assignments. Each rental
office rents vehicles that they have in stock to customers ready to take possession of the vehicle.
We don't take reservations, or speculate on when the customer will return rented vehicles. The
central office oversees the vehicle distribution, and directs transfers of vehicles from one rental
office to another.
Each rental office has an office name like "Littleton Right-Way." Each office also has a unique
three-digit office number. We also keep each office's address. Each office is a home office for
some of our vehicles, and each vehicle is based out of a single home office.
Each vehicle has a vehicle id, state of registration, and a license plate registration number. We
have five different types of vehicles: 36' trucks, 24' trucks, 10' trucks, 8' covered trailers, and 6'
open trailers. Yes, we do have a vehicle type code. For all our vehicles, we need to track the last
maintenance date, and expiration date of its registration. For our trucks, we need to know the
current odometer reading, the gas tank capacity, and whether or not it has a working radio. For
long moves, customers really prefer a radio. We log the current mileage just before we rent a
truck, and then again when it is returned.
Most of our rental agreements are for individual customers, but a rental agreement can either be
for an individual or for a company. We do rent a small percentage of our trucks to companies.
We assign each company an identifying company number and track the company's name and
address. No, we don't need to worry about any additional infor mation about a company. Our
corporate sales group handles all that information separately.
(Continued)
126
Exercise 4-5 - cont'd
"For each individual customer, we record the customer's name. home phone, address, and
driver's license state, number, and expiration date. We like to keep track of all our customers. If
a customer damaged a vehicle, abandoned it, or didn't fully pay the bill, then we tag the
customer as a poor risk, and won't rent to that customer again.
We only allow a single individual or company for a given rental agreement, and we write a
separate rental agreement for each vehicle. Yes, we do have customers rent two or more
vehicles at the same time. Each rental agreement is identified by the originating rental office
number and a rental agreement number. We also need to track the rental date, the anticipated
duration of the rental, the originating rental office, the drop-off rental office, the amount of the
deposit paid, the quoted daily rental rate, and the quoted rate per mile. Of course for the trailers,
there isn't a mileage charge. No, we don't need to automate the financial side of our business,
just our rental agreement tracking and vehicle assignment functions."
127
MODEL DATA OVER TIME
Quick Note
• Validate any requirements for storing historical data with the user. Storing unnecessary
historical data can be costly.
128
Model Data Over Time - cont'd
Example
A consulting firm needs to keep information about its contracts. Each contract has a unique contract
id, and they need to keep a description of the contract, the contract's status (e.g. open, closed, or
suspended.) Initially the following CONTRACT entity was modelled.
The above CONTRACT entity supports a single current status value for CONTRACT. The law Firm
wants to track the dates each contract was opened, was closed, and was suspended. To model status
values over time add a STATUS entity.
The UID of the STATUS entity is the related CONTRACT and the effective date.
Quick Note
• Use a single entity to record the values over time of multiple attributes associated with an
entity (such as CONTRACT).
129
Model Data Over Time - cont'd
Example
An apartment owner wants to track the tenants in each of his apartments. (The apartment only writes
rental contracts with a single person, not multiple people.) The following E-R Model will only track
the current renter of an APARTMENT.
Add the entity RENTAL HISTORY ENTRY to capture the values of the rental relationship over time.
130
Model Data Over Time - cont'd
Example
A professional society wants to track the companies that its members have been employed by over
time and the term of each employment (e.g. from date and to date). There is an M:M rela tionship
between each member and each company.
Add an intersection entity, EMPLOYMENT HISTORY ENTRY, to track each employee's em-
ployments over time and the dates of those employments.
By including the attribute from date in the UID of EMPLOYMENT HISTORY ENTRY, this model
will track any multiple terms of employment at a single company by a single employee.
131
EXERCISE 4-6
1. Modify the Video Store E-R Model to accommodate the following additional requirements.
"You know, we really need to keep a history of all our rentals. Each time a customer rents a
tape, we would like to keep the rental date/time and the return date/time. All our tapes are due
back the next day, so we don't need to keep a due date.
Keeping this rental history will allow us to analyze the pattern of our rentals. We will be able to
determine how many tapes each customer rents and how many times a customer has returned a
tape late. We will also know how many times a particular tape has been used, and will then
know when to retire each tape. We will also be able to analyze our customers' movie
preferences."
132
MODEL COMPLEX RELATIONSHIPS
Example
Develop an E-R model for employment history. For each person, track the position held, the company
worked for, and the dates the posit ion was held. A person may hold a specific position within the same
company multiple times during their career. Initially the following E-R Model was defined.
The dates of the position seem to be an attribute of a relationship. So resolve each of the M:M
relationships.
Which intersection entity are the dates of the position attributes of? All of them? None of them?
133
Model Complex Relationships - cont'd
Example
A person's employment history is really a 3-way relationship between the PERSON, COMPANY, and
POSITION entities. Use a single intersection entity called EMPLOYMENT HISTORY to model this
relationship.
Quick Notes
• An intersection entity for a complex relationship always has mandatory relationships back to
the entities to which it relates.
• For an intersection entity representing a complex relationship, follow the rules of basic E-R
Modelling to name the entity, and to analyze and model its relationships, its attributes, and its
UID.
134
EXERCISE 4-7
1. In the E-R Model for the Oracle User's Group from Exercise 3-10, a M:M relationship was
initially modelled between the MEMBER entity and the COMPUTER PLATFORM entity.
Revise that relationship based upon the following revised requirements.
Revised Requirements
"No, we really don't need to know what computer platform each member is using. Instead, what
we really need to know is which Oracle products (RDBMS, Pro*C, SQL*Forms,
SQL*TextRetrieval, CASE, Financials, etc.) each member is using on which computer
platforms. No, we don't need to keep the specific version of each product, just the general
product name."
135
EXERCISE 4-8
Optional Exercise
"I am the senior partner in a large, diversified law firm. My firm Bailey and Associates, handles
a wide variety of cases including traffic violations, domestic disputes, civil suits, and homicide
cases.
We have retained a database administrator to organize and track various data because the firm
grew faster than we had imagined and now there are "cases lying all over the place."
Our firm is made up of departments such as litigation, homicide, etcetera, and each case is
assigned to a particular department for administrative purposes. Attorneys are also assigned to a
particular department, but this is only for billing/payroll purposes since an attorney can work on
cases in other departments.
We need a list of events for a given case (essentially a history of the case) that includes a log of
events and the date the event became effective, Cases have to be identifiable by a unique
number which appears on a list with every event date and event description. Events have special
codes like O for Open, T for Trial, L for Lost, and there must always be an event status for
every case.
We want to keep track of important information associated with a case including the department
to which it is assigned and a brief description (such as Jones vs. Jones). After a case has been
closed, it may be reopened at some future date. We assign reopened cases new case numbers,
but we need to tie the new case number to the previous case number.
(continued)
136
Exercise 4-8 - cont'd
Attorneys can be party to multiple cases the same way a number of people can be party to
multiple cases. For example, Jones may be a judge on one case and an eyewitness on another.
We are only interested in keeping track of parties and the roles that they play in the context of a
particular case. Parties should be identified by their name and date of birth, and some kind of
unique numbering system.The kinds of people that may be involved in cases include judges
(JG), eyewitnesses (EW), defendants (DE) and of course attorneys (AT). For example, we have
a murder case, and we're working for the defendant.One attorney is assigned to the case, and
there is, of course, a judge presiding over the case. There is also an eyewitness. Thus, there are
four people who are parties to this case, and we'd like to know about all four. In this context, we
are not tracking the attorney in terms of billing, but simply as party to a case.
To elaborate on the varying roles that people can play, assume that a given party can serve in
different roles in different cases, but a party can only serve in one role on a given case."
137
EXERCISE 4-9
Optional Exercise
"I'm Phil Sales with Shipmore Cruises. We've decided that our manual system of booking
passengers onto our ships won't hold up when we get our new ship. so I guess that's why you're
here. Yes. we'll have two ships, no not boats, boats can fit onto ships, and we'll probably expand
to 5 or 6 by 1995. Each one has the name "Goodsea," "Goodwind," and the new one.
"Goodsky," and each one has a specific passenger capacity and registry. Registry is the country
that it is registered with. No. we don't need to worry about tonnage or draft or anything else
about the ship.
Each year we put out a brochure with the information on each cruise that we offer. Every cruise
has a name, length in number of days - huh? Oh, three, seven, eleven and fourteen day cruises.
Each cruise also has a specific ship assigned to it, some people want to go on only the newer
ships. Yes, I guess we would need the age of each ship. So, for each cruise we also have
different ports that we stop at. A three day cruise will have only one stop, always on the second
day of the cruise, a seven day cruise will stop at three ports, and so on. We vary ports depending
on where the cruise originates. What? The ports of Los Angeles, CA. and Miami, FL, as well as
Anchorage, AK. See. the LA cruises go down to Mexico ports like Cabo San Lucas and Mexico
City; the Miami cruises go to the Bahamas and the Virgin Islands: and the Anchorage cruises
make stops all through Alaska. Depending upon the length of each cruise, each cruise will make
port calls on different days out.
Passengers who sail with us will pick a given cruise, which has a certain length and number of
ports, and which cruise they pick will tell us which cabins are available. Once they choose from
what is available, we can then price them. That depends on the number of people in the cabin
and the "class" of the cabin. Huh? Whenever we book a cabin under the manual system we
remove the cabin from the availability board, unless it's not full and that passenger wants to
share with someone else. If the cabin can hold four people, and they are travelling alone, then
it's gonna cost 'em more. Once passengers are booked, and we get a deposit from them, then we
can pay the travel agent who made the reservation their commission."
138
5
RELATIONAL
DATABASE CONCEPTS
139
SECTION OBJECTIVES
140
RELATIONAL DATABASE OVERVIEW
Example
Quick Notes
• A relational database must possess data integrity, i.e., its data must be accurate and consistent.
141
Relational Database Overview - cont'd
Example
To select all employees who work in Department 10, use the following SQL statement.
Quick Notes
• The American National Standards Institute (ANSI) has established SQL as the standard
language for operating upon relational databases.
• A relational database can support a full set of relational operations. Relational operations
manipulate sets of data values. Tables can be operated on to create other tables. Rela tional
operations can be nested.
142
PRIMARY KEYS
Example
The primary key for the EMPLOYEE table consists of the EMP_NO column. Each row in the table is
uniquely identified by its EMP_NO value.
Quick Notes
• No duplicates are allowed in a Primary Key. The primary key must be unique.
143
Primary Keys - cont'd
Example
The composite primary key for the ACCOUNT table consists of the combination of the BANK_NO
and ACCOUNT_NO columns. Each row in the table is uniquely identified by its BANK NO and
ACCOUNT NO values.
Quick Note
• The columns of a composite primary key must be unique in combination. The individual
columns can have duplicates, but in combination, no duplicates are allowed.
144
Primary Keys - cont'd
Example
EMP_NO is the primary key of the EMPLOYEE table. Therefore EMP_NO must be defined as NOT
NULL.
Example
How does the ACCOUNT table violate the rules of Primary Keys?
Two of the rows contain NULL values in part of the composite PK. Both BANK_NO and
ACCOUNT_NO must be defined as NOT NULL.
145
Primary Keys - cont'd
A table can have more than one column or combination of columns that can
serve as the table's primary key. Each of these is called a Candidate Key.
Example
Select one candidate key to be the Primary Key for the table. The other
candidates become Alternate Keys (or Unique Keys).
Example
Quick Notes
• Person names are not normally candidate keys because their uniqueness cannot be guaranteed.
For example, in the EMPLOYEE Table, the combination LNAME/ FNAME would probably
not be a candidate key.
146
FOREIGN KEYS
Example
DEPT_NO is a FK in the EMPLOYEE Table, and refers to values in the DEPT_NO column of the
DEPARTMENT Table.
Quick Notes
• Foreign keys are based on data values and are purely logical.
Foreign Keys - cont'd
A foreign key must match an existing primary key value (or else be NULL).
Example
The FK DEPT_NO in the EMPLOYEE table refers to values of the PK DEPT_NO in the DEPART-
MENT table.
Example
In the ACCOUNT table, the FK BANK_NO must be NOT NULL because it is part of the PK.
DATA INTEGRITY
Data integrity constraints define the relationally correct state for a database.
Data integr ity constraints ensure that users perform only operations which leave the database in a
correct, consistent state.
Column Integrity A column must contain only values consistent with the defined
data format of the column.
User-Defined Integrity The data stored in a database must comply with the rules of the
business.
Quick Note
• Data is inconsistent if multiple copies of an entry exist, and not all copies have been updated.
An inconsistent database can supply incorrect or contradictory information to its users.
Data Integrity - cont'd
The rules of a business can also determine the correct state for a database.
Such business rules are called User-Defined Data Integrity Constraints.
Example
An exempt employee is not paid for the tirst 5 hours of overtime worked.
"Programmer".
Quick Notes
• Frequently these business rules are completely arbitrary, or at least seem to be arbitrary.
• User-defined data integrity constraints may involve multiple columns and tables.
6
INITIAL DATABASE DESIGN
SECTION OBJECTIVES
1. Explain how Database Design fits into the Database Development Process.
The Database Design Stage produces design specifications for a relational database including
definitions for relational tables, indexes, views, and storage space.
INITIAL DATABASE DESIGN OVERVIEW
Quick Notes
• The valid Key Types are PK for a Primary Key column, and FK for a Foreign Key column.
• Use suffixes to distinguish between multiple FK columns in a single table, for example, FK1
and FK2. Label multiple column keys with the same suffix.
• If multiple columns must be unique in combination, label them with a suffix, for example U1.
This familiar Training Company E-R Model will be used to illustrate the
activities of Initial Database Design.
Example
Create a Table Instance Chart for the INSTRUCTOR entity. Name the table
INSTRUCTOR.
Column
Name
Key Type
Nulls/
Unique
Sample
Data
Quick Notes
• The table name should be easy to trace back to the entity name. The plural of the entity name
is sometimes used because the table will contain a set of rows.
• A simple entity is not a subtype or supertype. In Step 6, the designer must decide how to map
a supertype/subtype construct to tables.
MAP ATTRIBUTES TO COLUMNS
Example
Quick Notes
• Avoid the use of SQL reserved words as column names - for example, NUMBER.
• Use consistent abbreviations to avoid programmer and user confusion. For example, will
Number be abbreviated as NO or NUM. Is it DEPTNO or DEPTNUM?
• Short column names will reduce the time required for SQL command parsing.
Map Attributes to Columns - cont'd
Example
Example
Quick Notes
• Map a UID, which includes multiple attributes to a composite PK. Label those columns NN
and U1
Map UID's to Primary Keys - cont'd
Example
Quick Notes
• Choose a unique name for each FK column, and label the column(s) PK, NN, and FK.
• If multiple FK columns exist in a table, use suffixes to distinguish between them, for example,
FK1 and FK2. Label multiple column keys with the same suffix.
For M:1 relationships, take the PK at the one end and put
it in the table at the many end.
Example
Take the PK INST_ID at the one end, and put it in the table COURSE at the
many end.
Quick Notes
• Choose a unique name for the FK column, and label the column (s) FK.
Example
The PK for the ENROLLMENT table included both the foreign key
COURSE_CODE and the foreign key ST_ID. Therefore, these two columns
already exist, and do not need to be added to support the relationships.
Map Relationships to Foreign Keys - cont'd
Example
Column INV_NUM CASE_TYPE POWER_ MB_ID Column MB_ID PROC_ PROC_ COPROC_
Name SUPPLY Name CHIP SPEED CHIP
Key PK FK Key PK
Type Type
Nulls/ NN, U NN NN NN, U Nulls/ NN, U NN NN NN
Unique Unique
Sample 1045 BABY AT 150 4579 Sample 9978 486 33 N
Data Data
0437 BABY AT 200 8731 4517 386 40 Y
Example
For the optional 1:1 relationship between BERTH and SHIP, the FK column
could also be placed either in the BERTH or SHIP table. The B_NUM column is
added to the SHIP table, and labeled Unique to enforce the 1:1 relationship.
Map Relationships to Foreign Keys - cont'd
For a 1:M recursive relationship, add a FK column to the single table. This FK
column will refer to values of the PK column.
1.1.1. Example
For this 1:M recursive relationship, add an FK column to the EMPLOYEE table
for each employee's manager. Name the column MGR_ID to reflect the
relationship.
Quick Notes
Example
For this 1:1 recursive relationship, add a unique column to the PERSON table.
Quick Notes
• The combination of the PK and FK columns must always be unique in order to ensure the 1:1
relationship.
• The additional constraint that a PERSON cannot be married to him/herself would have to be
implemented separately by the application programs or stored procedures.
REVIEW: MAPPING SIMPLE E-R MODELS TO TABLES
Steps
1. Follow the first four steps of Initia l Database Design to map this E-R Model to a set of initial
table designs. Document your table designs on the supplied set of Table Instance Charts.
Create sample data as required.
Exercise 6-1 - cont'd
Table Name:
Column
Name
Key Type
Nulls/ Unique
Sample Data
Table Name:
Column
Name
Key Type
Nulls/
Unique
Sample Data
EXERCISE 6-2
1. Follow the first four steps of Initial Database Design to map this E-R Model to a set of initial
table designs. Document your table designs on the supplied set of Table Instance Charts.
Create sample data as required.
Exercise 6-2 - cont'd
Table Name:
Column
Name
Key Type
Nulls/
Unique
Sample Data
Table Name:
Column
Name
Key Type
Nulls/
Unique
Sample Data
Table Name:
Column
Name
Key Type
Nulls/
Unique
Sample
EXERCISE 6-3
1. Follow the first four steps of Initial Database Design to map this E-R Model to a set of initial
table designs. Document your table designs on the supplied set of Table Instance Charts.
Create sample data as required.
Table Name:
Column
Name
Key Type
Nulls/
Unique
Sample Data
Exercise 6-3 - cont'd
Table Name:
Column
Name
Key Type
Nulls/
Unique
Sample Data
Table Name:
Column
Name
Key Type
Nulls/
Unique
Sample Data
Table Name:
Column
Name
Key Type
Nulls/
Unique
Sample
EXERCISE 6-4
Optional Exercise
1 Follow the first four steps of Initial Database Design to map this E-R Model to a set of initial
table designs. Document your table designs on the supplied Table Instance Charts. Use the
interview notes on the following page to select sample data for the Table Instance Charts.
Exercise 6-4 - cont'd
Table Name:
Column
Name
Key Type
Nulls/
Unique
Sample Data
Table Name:
Column
Name
Key Type
Nulls/
Unique
Sample Data
Exercise 6-4 - cont'd
2 Use the following interview notes to select sample data for the Table Instance Charts.
"Our company sells products throughout the United States. So we've divided the U.S. into four
major sales regions: the Northern, Eastern, Southern, and Western Regions. Each sales region
has a unique region code. Each sales region is then divided into sales districts. For example, the
Western Region is divided into the Rocky Mountain, Northwest, Pacific Coast, and Pacific
Districts. Each district has a unique district code.
Each district is made up of sales territories. The Rocky Mountain District is composed of three
territories: Wyoming-Montana, Colorado, and Utah-New Mexico. The northwest District is
made up of two territories: The Washington and Oregon-Idaho territories. The Pacific Coast
District is composed of two territories: the California and Nevada territories. The Pacific
District includes the Hawaii territory and the Alaska territory. Each territory has a unique
territory code.
Then each sales territory is broken down into sales areas. For example, Colorado is made up of
two sales areas: the Front Range and the Western Slope sales areas. Each sales area has a unique
sales area code.
Each salesperson is responsible for one or more sales areas, and has a specific sales quota. We
also have sales managers who are responsible for one or more sales districts, and sales directors
who are responsible for one or more sales regions. Each sales manager is responsible for the
territories within his districts. We don't overlap our employees' responsibilities - a sales area is
always the responsibility of a single salesperson, and our managers and director's
responsibilities don't overlap. Sometimes our salespersons, managers, and directors will be on
leave or special assignments and will not have sales turf responsibilities. We identify all our
sales personnel by their employee ids."
MAP COMPLEX E-R MODELS TO TABLES
Additional Steps
Alternative Designs
Example
This E-R Model will map to four tables. The OFFICE SUITE entity has an arc across the many ends
of three relationships, and corresponding FK columns must be added to the OFFICE_SUITE table.
Use either an Explicit Arc Design or a Generic Arc Design to add these multiple alternative foreign
keys.
Quick Notes
• Also use an Explicit Arc Design or a Generic Arc Design to implement multiple foreign keys
when an arc spans a set of 1:1 relationships.
• Arcs can only span relationship ends that are either all mandatory or all optional.
Choose Arc Options - cont'd
Example
The following E-R Model contains four simple entities, and will be mapped to
four separate tables. The arc spans the many end of three relationships.
Therefore, FKs must be added to the OFFICE_SUITE table. Using an Explicit
Arc Design, create a FK column for each rela tionship.
Quick Notes
• The Explicit Arc Design will support multiple Foreign keys with different formats. For
example, INDIV_ID, PARTNER_CODE, and COMPANY_ID could all have a different
column format.
• Application software must enforce relationship exclusivity between the foreign keys.
Choose Arc Options - cont'd
Example
Again, create four separate tables for this E-R Model - one for each entity. Since
the arc spans the many end of the relationships, add the to the OFFICE_SUITE
table. Using the Generic Arc Design, create a single foreign key column, and
add a type column to indicate which of the three tables is referenced by the FK
column in each row. For example, J for INDIVIDUAL, P for PARTNERSHIP,
and C for COMPANY.
Quick Notes
• If the relationships under the arc are mandatory, make both added columns NOT NULL.
• The foreign keys must share the same format for all referenced tables.
EXERCISE 6-5
1 Using an Explicit Arc Design, develop a table design for this Entity-Relationship Model.
Document your design on the provided Table Instance Charts.
Column Name
Key Type
Nulls/ Unique
Sample Data
Exercise 6-5 - cont'd
Table Name: COUNTY
Column Name
Key Type
Nulls/ Unique
Sample Data
Column Name
Key Type
Nulls/ Unique
Sample Data
2 Using a Generic Arc design, develop a table design for this Entity-Relationship Model.
Document your design on the provided Table Instance Charts.
Column Name
Key Type
Nulls/ Unique
Sample Data
Exercise 6-5 - cont'd
Table Name: COUNTY
Column Name
Key Type
Nulls/ Unique
Sample Data
Column Name
Key Type
Nulls/ Unique
Sample Data
Column Name
Key Type
Nulls/ Unique
Sample Data
CHOOSE SUBTYPE OPTIONS
Example
Map the subtypes onto a single table for the supertype. The
single table will contain instances of all sub types.
Create
Use a single table design when the subtypes have few subtype-specific
attributes and relationships.
Choose Subtype Options - cont'd
Example
Map the EMPLOYEE supertype and its subtypes onto a single EMPLOYEE
table.
The columns of the EMPLOYEE table are derived from the attributes and
relationships of the supertype and all its subtypes.
Quick Note
• The single table subtype design requires that a new type column be created to identify each
row's subtype. The EMP_TYPE column was added to the EMPLOYEE table for this purpose.
Choose Subtype Options - cont'd
Use the Single Table Subtype Design when there are few
subtype-specific attributes and relationships.
Design Advantages
Design Disadvantages
• Application logic will have to cater to different sets of attributes, depending on TYPE.
Choose Subtype Options - cont'd
Create
• a column for each attribute of the supertype in each of the subtype's table.
• an FK column for each relationship to the supertype in each of the subtype's tables.
Choose Subtype Options - cont'd
Example
Map the EMPLOYEE supertype onto two tables - one for each subtype. First
create a separate table for the EXEMPT EMPLOYEE subtype.
Example - cont'd
Design Advantages
Design Disadvantages
• Access to the supertype requires the UNION operator or a view with the UNION operator.
1 Using a Single Table Subtype Design, develop a table design for this Entity-Relationship
Model. Document your design on the supplied Table Instance Charts. Sample data is not
required.
Nulls/
Unique
Sample
Data
Exercise 6-6 - cont'd
2 Using a Separate Tables Subtype Design, develop a table design for this Entity-Relationship
Model. Document your design on the supplied Table Instance Charts. Sample data is not
required.
Nulls/
Unique
Sample
Data
Nulls/
Unique
Sample
Data
REVIEW: INITIAL DATABASE DESIGN
First Normal Form (1NF) The table must be expressed as a set of unordered, two-
dimensional tables. The table cannot contain repeating
groups.
Second Normal Form (2NF) The table must be in INF. Every non-key column must be
dependent on all parts of the primary key.
Third Normal Form (3NF) The table must be 2NF. No non-key column may be
functionally dependent on another non-key column.
"Each non-primary key value MUST be dependent on the key, the whole
key, and nothing but the key."
• Data redundancy causes integrity problems. Update and delete transactions may not be
consistently applied to all copies of the data causing inconsistencies in the data.
Quick Notes
• Third normal form is the generally accepted goal for a database design that eliminates
redundancy.
Unnormalized data does not comply with any of the rules of normalization.
Example
Consider the following set of data. Three variable length records are shown - one for each
ORDER_ID. Why is this data unnormalized?
It contains a repeating group of ITEM NUM, ITEM DESCRIPTION, QUANTITY, and PRICE. First
Normal Form prohibits repeating groups.
CONVERT TO FIRST NORMAL FORM
Steps
2 Create a new table with the PK of the base table and the repeating group.
Example
Remove the repeating group of ITEM NUM, ITEM DESCRIPTION, QUA NTITY, and PRICE. The
PK of the remaining table is ORDER ID. Create a new ORDERJTEM table with ORDER ID and
the repeating group.
ORDER
ORDER ID DATE CUSTOMER ID CUSTOMER NAME STATE
PK
2301 6/23 101 Volleyrite IL
2302 6/25 107 Herman's WI
2303 6/26 110 We-R-Sports MI
ORDER ITEM
ORDER ID ITEM NUM ITEM DESCRIP QUANTITY PRICE
PK,FK PK
2301 3786 Net 3 35.00
2301 4011 racket 6 65.00
2301 9132 3-pack 8 4.75
2302 5794 6-pack 4 5.00
2303 4011 racket 2 65.00
2303 3141 cover 2 10.00
CONVERT TO SECOND NORMAL FORM
Remove any non-key columns that are not dependent upon the table's
entire primary key.
Steps
1 Determine which non-key columns are not dependent upon the table's entire primary key.
3 Create a second table with those columns and the column(s) from the PK that they are
dependent upon.
Example
ORDER
ORDER ID DATE CUSTOMER ID CUSTOMER NAME STATE
PK
2301 6/23 101 Volleyrite IL
2302 6/25 107 Herman's WI
2303 6/26 110 We-R-Sports MI
The ORDER table is already in 2NF. Any value of ORDERJD uniquely determines a single value
of each column. Therefore, all columns are dependent on the PK ORDERJD.
Quick Notes
• If each column is not dependent upon the entire primary key, the table is not in 2NF.
Remove any non-key columns that are not dependent upon the table's
entire primary key.
Example
ORDER ITEM
ORDER ID ITEM ITEM QUANTITY PRICE
NUM DESCRIP
PK,FK PK
2301 3786 Net 3 35.00
2301 4011 racket 6 65.00
2301 9132 3-pack 8 4.75
2302 5794 6-pack 4 5.00
2303 4011 racket 2 65.00
2303 3141 cover 2 10.00
The ORDERJTEM table is not in 2NF since PRICE and DESCRIPTION are dependent upon ITEM
NUM, but not dependent upon ORDER ID.
To convert the table to 2NF, remove any partially dependent columns. Create an ITEM table
with those columns and the column from the PK that they are dependent upon.
ORDER ITEM ITEM
2301 3786 3 PK
Remove any columns that are dependent upon another non-key column.
Steps
3 Create a second table with those columns and the non-key column that they are dependent
upon.
Example
ORDER
ORDER ID DATE CUSTOMER ID CUSTOMER NAME STATE
PK
2301 6/23 101 Volleyrite IL
2302 6/25 107 Herman's WI
2303 6/26 110 We-R-Sports MI
CUSTOMER NAME and STATE are dependent upon CUSTOMER ID. CUSTOMER ID is not the PK.
Therefore, the ORDER table is not in 3NF.
Move the dependent non-key columns with the non-key column they depend upon Into a new
CUSTOMER table.
ORDER CUSTOMER
PK FK NAME
Quick Note
• A table is in Third Normal Form if no non-key column is functionally dependent upon another
non-key column.
Convert to Third Normal Form - cont'd
Example
ORDER ITEM
2301 3786 3
2301 4011 6
2301 9132 8
2302 5794 4
2303 4011 2
2303 3141 2
All non-key attributes are dependent on the key, the whole key, and nothing but the key. The
ORDERJTEM table is in 3NF.
Example
All non-key attributes are dependent on the key, the whole key, and nothing but the key. The ITEM
table is in 3NF.
EXERCISE 7-1
1. Put the following data into First, Second, and Third Normal Form on the supplied Table
Instance Charts. Three variable length records are shown-one for each EMP_NUM.
EMPLOYEE
Nulls/
Unique
Sample
Data
Table Name:
Column
Name
Key Type
Nulls/
Unique
Sample
Data
Exercise 7-1 - cont'd
Table Name:
Column
Name
Key Type
Nulls/
Unique
Sample
Data
Table Name:
Column
Name
Key Type
Nulls/
Unique
Sample
Data
Table Name:
Column
Name
Key Type
Nulls/
Unique
Sample
Data
Exercise 7-1 - cont'd
Table Name:
Column
Name
Key Type
Nulls/
Unique
Sample
Data
Table Name:
Column
Name
Key Type
Nulls/
Unique
Sample
Data
Table Name:
Column
Name
Key Type
Nulls/
Unique
Sample
Data
Exercise 7-1 - cont'd
Table Name:
Column
Name
Key Type
Nulls/
Unique
Sample
Data
NORMALIZE DURING DATA MODELLING
Example
The attribute date contacted has multiple values, therefore the entity CLIENT is not in 1NF. Create an
additional entity CONTACT with a M:1 relationship to CLIENT. Create an additional entity and 1 :M
relationship to ensure 1 NF.
Normalize During Data Modelling - cont'd
• Every non-key column must be dependent upon all parts of the primary key.
Example
Are all of the attributes in the following E-R diagram dependent upon their entity's UID?
The attribute bank location is not dependent upon the UID of ACCOUNT. It is dependent upon
the UID of BANK.
Move the attribute and place it where it depends upon the UID of it's entity.
Normalize During Data Modelling - cont'd
Example
Are any of the non-UID attributes for this entity dependent upon another non-UID attribute?
The attributes customer name and state are dependent upon the customer id.
Create another entity called CUSTOMER with a UID of customer id, and place the attributes
accordingly.
8
FURTHER DATABASE DESIGN
SECTION OBJECTIVES
2. Design indexes.
Activities
• Design indexes.
• Establish views.
A foreign key column value must match an existing primary key column
value (or else be NULL). Use referential integrity constraints to specify how
referential integrity is to be maintained.
Delete Constraint
Update Constraint
Example
Consider the EMPLOYEE and DEPARTMENT tables. What should happen if a DEPT.NO for which
employees work is deleted from the DEPARTMENT table?
CASCADE The deletion should cascade to the matching employees. The matching
EMPLOYEE rows should also be deleted.
NULLIFY The foreign key should be nullified (valid only for FK's allowing NULLs)
when the referenced PK is deleted.
Specify Referential Integrity - cont'd
Example
What should happen if a DEPT_NO for which employees work is changed to another
DEPT_NO?
CASCADE The update should cascade to the matching employees. The matching
EMPLOYEE rows should also be updated to reflect the new PK value.
NULLIFY The foreign key should be nullified (valid only for FK's allowing NULLs)
when the referenced PK is updated to a new PK value.
DESIGN INDEXES
An index is associated with a single physical table and contains the values of
one or more columns from that table.
Physical Representations
COURSE Table
Indexes
• Provide quick access to rows of data and avoid full table scans
• Are used automatically when. referenced in the WHERE clause of a SQL statement if the
column is not modified
Example
The ENROLLMENT table has a composite PK of COURSE_CODE and ST_ID. Create a composite
key called I_ENROLL_PRIME on both columns.
ENROLLMENT Table
Physical ROW ENROLL_ DATE_ GRADE COURSE_ ST_ID
Tables ID DATE COMPLETED CODE
5011 20-JUL-91 19-AUG- 91 - 344 47592
5012 05-SEP-91 - - 401 15402
5015 14-J UN- 91 28-JUL-91 A 717 51394
5013 08- MAY-91 28-JUL-91 B 717 94572
5014 05- MAY-91 21- MAY-91 A 401 51394
I_ENROLL_PRIME Index
(Unique)
COURSE_ ST_ID ROW ID
CODE
344 47592 5011
401 15402 5012
401 51394 5014
717 51394 5015
Consider indexing
Quick Notes
• A unique index references a column or set of columns that has unique values in the table.
• A non-unique index references a column or set of columns that are not unique in a table.
• Be aware that under certain conditions, indexes are not used by the RDBMS.
• restricting access.
Quick Notes
• A view has no data of its own and merely relays informa tion from underlying tables.
• A view is defined by a SELECT statement that is named and stored in the ORACLE Data
Dictionary.
Examples
A View of the EMP table could be used to restrict users from seeing the employees' salaries.
A view can be used to present normalized data in a denormalized form.
Example
Following the rules of normalization, the ORDER and CUSTOMER tables are separate.
A view defined across both tables could be used to pre-join the tables so the user would only see a
single table.
Establish Views - cont'd
Use views with caution. Access through a view is slower because it requires
an extra access to the data dictionary, and may cause query optimization to
be slower.
View Limitations
• For a view based upon a single table, the SQL INSERT, UPDATE, and DELETE commands
have no limitations.
• For multi-table views with virtual columns, INSERT, UPDATE, and DELETE are restricted.
• When accessing tables through a view, it is possible to add rows not visible through the view
unless the WITH CHECK OPTION is specified.
DENORMALIZE THE DATABASE DESIGN
Beware of Denormalization!
• high throughput.
• high frequency.
Example
If high-volume account queries always access the bank name, a combined table might be worth
the data redundancy. The ACCOUNT table and the BANK table are combined on BANK_NUM.
Denormalize the Database Design - cont'd
Example
The following separate codes tables are required for an application system. They are used to provide
the SQL*Forms list of values feature and to validate table values for INSERT or UP DATE.
Combine all the tables into a single table with an additional column, CODE_TYPE, that defines
which set of values the code belongs to. Create a view for each CODE_TYPE.
Denormalize the Database Design - cont'd
Example
The CHAR_CODE table on the previous page includes four different types of codes. Each of these
code types has a different valid length for its code description. Set up a CODE_TYPE table for
validating the length of the descriptions.
The table contains two columns, CODE_TYPE and LENGTH. LENGTH is the maximum
description length for each CODE_TYPE.
Denormalize the Database Design - cont'd
Choose the table design for vector data based upon the functional access
requirements.
• On the input form, all data values can appear on a single line.
Example
A regional sales manager has 200 salespersons working for him. He frequently queries the total sales
quota and sales-to-date for his region. The sales quotas are established quarterly. Sales data is updated
weekly. Maintaining sales quota data by region would be desirable, and maintaining sales-to-date
might also be desirable.
PLAN PHYSICAL STORAGE USAGE
Considerations
• For each table and index, estimate the amount of disk space required.
• Decide on the placement of tables and indexes on logically separate tablespaces and
physically separate disks.
• Define storage allocation parameters based upon the expected patterns of data update and
growth.
• Design indexes.
• Establish views.
This course has covered the first two steps of the top-down database
development process. The last step is Database Build.
DATABASE BUILD OVERVIEW
Example
The following Structured Query Language (SQL) statements will create the DEPARTMENT and
EMPLOYEE tables.