Data Modeling and Database Design

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 Contributors: Ann Horton Howard Benbrook Dean Dameron Art Hetherington Jeff Jacobs Steve Strickland Publishing: Copyright © Oracle Corporation, 1992 All rights reserved. Printed in the U.S.A. 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: 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 and as set forth in subparagraph (c) (1) (ii) of DFARS 252.2277013, 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. ORACLE, SQL*Plus, SQL*Connect, SQL*Net, SQL*DBA, SQL*Report, SQL*ReportWriter, SQL*Forms, SQL*Menu, SQL*Loader, Easy*SQL, Pro*C, Pro*COBOL, Pro*Ada, Pro*Fortran, Pro*PL/I, Pro*Pascal, SQL*Calc, SQL*QMX, Oracle Financials, and CASE*Dictionary are registered trademarks. Oracle General Ledger. Oracle Assets. Oracle Payables and Oracle Purchasing. Oracle*Mail, SQL*TextRetrieval, PL/SQL, Oracle Graphics, Hyper*SQL, Oracle Card. CASE*Designer, and CASE*Generator are trademarks of Oracle Corporation. 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. Scott Knudtson Kathy Andronica Pete Cassidy Claudia Herzog Bill Hopkins Cliff Longman Tom Traver Rich Marinaccio

3

CONTENTS
CONTENTS .............................................................................................................................. 4

1 INTRODUCTION.....................................................................................9
COURSE OBJECTIVES ....................................................................................................... 10 ORACLE OVERVIEW ......................................................................................................... 11 ORACLE'S CASE APPROACH .......................................................................................... 13 CASE*METHOD DEVELOPMENT CYCLE.................................................................... 14

2 OVERVIEW OF DATABASE DEVELOPMENT..................................15
SECTION OBJECTIVES...................................................................................................... 16 DATABASE DEVELOPMENT PROCESS ........................................................................ 17 BUSINESS INFORMATION REQUIREMENTS .............................................................. 18 CONCEPTUAL DATA MODELLING OVERVIEW ....................................................... 19 DATABASE DESIGN OVERVIEW .................................................................................... 20 DATABASE BUILD OVERVIEW....................................................................................... 21 DATABASE AND APPLICATION DEVELOPMENT ..................................................... 22

3 BASIC CONCEPTUAL DATA MODELLING......................................23
SECTION OBJECTIVES...................................................................................................... 24 CONCEPTUAL DATA MODELLING ............................................................................... 25 ENTITIES ............................................................................................................................... 29 IDENTIFY AND MODEL ENTITIES ................................................................................. 33 EXERCISE 3-1 ....................................................................................................................... 36 RELATIONSHIPS ................................................................................................................. 37 EXERCISE 3-2 ....................................................................................................................... 41 EXERCISE 3-3 ....................................................................................................................... 42

4

.............................................................................................................................................................................. 64 DISTINGUISH ATTRIBUTES AND ENTITIES ..................................................................................... 86 REVIEW: BASIC CONCEPTUAL DATA MODELLING......................... 48 ANALYZE AND MODEL RELATIONSHIPS ........................................................................................................................................................................................................ 88 4 ADVANCED CONCEPTUAL DATA MODELLING......................................................................................... 77 EXERCISE 3-8 ............. 53 DETERMINE RELATIONSHIP'S OPTIONALITY............. 58 EXERCISE 3-6 ............................................................................ 84 EXERCISE 3-10 ........................................................................................................... 51 NAME THE RELATIONSHIP............................................................................................... 62 ATTRIBUTES ...................................................................................................................................................................................................................................................................................................................................................... 98 5 ................ 56 VALIDATE THE RELATIONSHIP............................................... 55 DETERMINE RELATIONSHIP'S DEGREE ..................................................................................................................................................92 SECTION OBJECTIVES.................................................................... 93 NORMALIZE THE DATA MODEL ........................................ 75 ASSIGN UNIQUE IDENTIFIERS .................................... 43 RELATIONSHIP TYPES .................................................. 94 EXERCISE 4-1 ......................................... 83 EXERCISE 3-9 .................................................................................................................................................... 71 IDENTIFY ATTRIBUTES..............................................................................EXERCISE 3-4 ....................................................... 69 ATTRIBUTE OPTIONALITY............................................................................................ 73 EXERCISE 3-7 ................................................................................................................................. 44 USING A RELATIONSHIP MATRIX........................................................................................................... 57 EXERCISE 3-5 ............................ 50 DETERMINE A RELATIONSHIP'S EXISTENCE ... 60 LAY OUT THE E-R DIAGRAM ....................................................................

..........................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................151 SECTION OBJECTIVES............................................................ 143 FOREIGN KEYS ..................... 109 MODEL RECURSIVE RELATIONSHIPS ............... 155 6 .....................139 SECTION OBJECTIVES....................................................................................................................... 153 INITIAL DATABASE DESIGN OVERVIEW ........................ 136 EXERCISE 4-9 .......... 132 MODEL COMPLEX RELATIONSHIPS ............................................. 108 MODEL HIERARCHICAL DATA ................................................................................................................................... 133 EXERCISE 4-7 ....................................................................... 128 EXERCISE 4-6 ....... 124 EXERCISE 4-5 ................................ 135 EXERCISE 4-8 ............................................................................................... 140 RELATIONAL DATABASE OVERVIEW .............. 107 EXERCISE 4-3 .................................................................................................... 118 MODEL SUBTYPES .............................. 126 MODEL DATA OVER TIME.......................................................................... 147 DATA INTEGRITY............................................................................... 152 DATABASE DESIGN .......................................... 149 6 INITIAL DATABASE DESIGN .............................................................................................................................. 117 MODEL ROLES WITH RELATIONSHIPS ................... 138 5 RELATIONAL DATABASE CONCEPTS.............................................................................................................................................................................................. 99 EXERCISE 4-2 ........ 112 EXERCISE 4-4 ........................................................... 120 MODEL EXCLUSIVE RELATIONSHIPS ..................................................................................................................................................................................................................................................................................RESOLVE M:M RELATIONSHIPS .......................... 141 PRIMARY KEYS .......................................................................

........................................................................................................................................................................................................................................................................................................................................................ 158 MAP ATTRIBUTES TO COLUMNS.............................................................................................................................................................................................................................. 214 8 FURTHER DATABASE DESIGN..................................................................................................................................................................................... 163 REVIEW: MAPPING SIMPLE E-R MODELS TO TABLES ................................................................................................................................................................... 196 REVIEW: INITIAL DATABASE DESIGN ..................................... 202 NORMALIZE TABLES ......... 210 NORMALIZE DURING DATA MODELLING............ 187 EXERCISE 6-6 ......... 183 CHOOSE SUBTYPE OPTIONS ............................... 219 7 .............................................................................................................................. 172 EXERCISE 6-3 .................. 208 EXERCISE 7-1 ............ 218 FURTHER DATABASE DESIGN .................................................................... 159 MAP UID'S TO PRIMARY KEYS ............................217 SECTION OBJECTIVES.............................................................................. 169 EXERCISE 6-1 ............................................................................................................................................................................................................................................... 203 RECOGNIZE UNNORMALIZED DATA ................................................................. 179 EXERCISE 6-5 ................................................................MAP SIMPLE ENTITIES.......201 SECTION OBJECTIVES...................... 174 EXERCISE 6-4 ............................................................................................................... 176 MAP COMPLEX E-R MODELS TO TABLES ................................................. 204 CONVERT TO FIRST NORMAL FORM........... 200 7 TABLE NORMALIZATION...................................................... 161 MAP RELATIONSHIPS TO FOREIGN KEYS .................................................................................................................................................................................... 205 CONVERT TO SECOND NORMAL FORM.............................................. 206 CONVERT TO THIRD NORMAL FORM.......................................................... 170 EXERCISE 6-2 ..............

..... 237 SUMMARY: DATABASE DESIGN .......................................................................................................................................................................................................................... 238 SUMMARY: DATABASE DEVELOPMENT . 240 8 .............................. 222 ESTABLISH VIEWS ...................................................................................... 220 DESIGN INDEXES .............................................................................................SPECIFY REFERENTIAL INTEGRITY............................................................................................................. 239 DATABASE BUILD OVERVIEW....................................................................................................... 227 DENORMALIZE THE DATABASE DESIGN........ 230 PLAN PHYSICAL STORAGE USAGE............

1 INTRODUCTION 9 .

2 Develop a rela tional database design from an entity-relationship model. you will be able to: 1 Analyze user information requirements and develop an entity-relationship model to express those requirements.COURSE OBJECTIVES At the end of this course. 10 .

ORACLE OVERVIEW 11 .

12 .cont'd * Data Modelling and Database Design are techniques for analyzing information requirements and designing relational databases.ORACLE Overview .

techniques and tools.ORACLE'S CASE APPROACH Oracle's CASE (Computer-Aided Systems Engineering) approach provides a full-suite of CASE methods. Business Requirements Operational System 13 .

14 .CASE*METHOD DEVELOPMENT CYCLE Data modeling and database design support the first three stages of the CASE*Method Development cycle.

2 OVERVIEW OF DATABASE DEVELOPMENT 15 .

Explain what Conceptual Data Modelling and Database Design involve. Understand the parallel phases of the Application Development Process.SECTION OBJECTIVES At the end of this section. 16 . you will be able to: 1 2 3 Understand the phases of the Database Development Process.

DATABASE DEVELOPMENT PROCESS Database development is a top-down. The Database Development Process is a vertical slice of the CASE*Method Development Cycle. systematic approach that transforms business information requirements into an operational database. 17 .

BUSINESS INFORMATION REQUIREMENTS Top-down database development begins with the information requirements of the business. We need to keep information about each of our company's employees. Our company is divided into departments. accounting is 10 and sales are 30. We need to know the department responsible for each employee and the department's location. We need to know each employee's manager. we also need to track their potential commission. 18 . • Information requirements are tightly coupled with business function requirements. Example Here is a set of information requirements: "I manage the Human Resources Department for a large company. for example. hire date. For example. last name. For any employees on commission. We need to track each employee's first name. the Human Resources Department's business function requirements include Manage employee information." 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. accounting. Each employee is assigned to a department-for example. Some of the employees are managers. Each employee is assigned a unique employee number. or development. job or position. Each department has a unique number. and the employees each manager manages. sales. and salary.

CONCEPTUAL DATA MODELLING OVERVIEW In Conceptual Data Modelling. Example The following entity-relationship model represents the information requirements of the Human Resources Department. 19 . and the relationships between them. define and model the things of significance about which the business needs to know or hold information. An Entity-Relationship Data Model should accurately model the organization's information needs and support the functions of the business.

U 10 20 30 40 50 NN ACCOUNTING RESEARCH SALES OPERATIONS DEVELOPMENT NN NEW YORK DALLAS CHICAGO BOSTON ATLANTA DNAME LOC The Table Instance Chart for each relational table identifies the table's columns. Example A design for the Human Resources database is shown in the following table instance charts. U 7369 7902 7521 7698 7839 FNAM LNAME JOB E NN MARY HENR SUE BOB BOB NN SMITH FORD WARD BLAKE KING CLERK ANALYST SALESMA NN 17.NOV. and any foreign keys and provides a visual view of sample data.DATABASE DESIGN OVERVIEW In Database Design.81 50 50 Table Name: DEPARTMENT Column Name Key Type Nulls/ Unique Sample Data DEPTNO PK NN.DEC-80 03. map the information requirements reflected in an Entity-Relationship Model into a relational database design. Table Name: EMPLOYEE Column Name Key Type Nulls/ Unique Sample Data EMPN O PK NN. primary key. 20 .FEB-81 80 30 12 7902 7566 6000 7698 1000 7839 0 5000 HIREDATE SA COM L M MGR FK1 DEPTN O FK2 NN 20 50 30 30 10 N MANAGER 01.DEC-81 22.MAY-81 51 28 PRESIDEN 17.

DNAME CHAR(20) NOT NULL. 21 . Example The following Structured Query Language (SQL) statements will create the DEPARTMENT and EMPLOYEE tables. MGR CHAR(4) REFERENCES EMPLOYEE(EMPNO). COMM NUMBER (7. SAL NUMBER (7.2).DATABASE BUILD OVERVIEW In Database Build. 2). create physical relational database tables to implement the database design. LNAME CHAR(15) NOT NULL. SQL> 2 3 4 SQL> 2 3 4 5 6 7 8 9 10 CREATE TABLE DEPARTMENT (DEPTNO NUMBER(2) NOT NULL PRIMARY KEY. The Structured Query Language (SQL) is used to create and manipulate relational databases. FNAME CHAR(15) NOT NULL. LOC CHAR 115) NOT NULL ). DEPTNO NUMBER(2) NOT NULL REFERENCES DEPARTMENT (DEPTNO) ). HIREDATE DATE NOT NULL. CREATE TABLE EMPLOYEE (EMPNO NUMBER (5) NOT NULL PRIMARY KEY. JOB CHAR(9).

DATABASE AND APPLICATION DEVELOPMENT The Database Development Process is tightly coupled with the Application Development Process. 22 .

3 BASIC CONCEPTUAL DATA MODELLING 23 .

you will be able to: 1.SECTION OBJECTIVES At the end of this section. Identify and model entities. 24 . Develop a basic entity-relationship model from a statement of information requirements and user interviews. Analyze and model the relationships between entities. 3. Identify unique identifiers for each entity. 4. 2. 5. Analyze and model attributes.

and is performed during the Strategy and Analysis stages of the System Development Cycle. 25 .CONCEPTUAL DATA MODELLING Conceptual Data Modelling is the first step of the top-down Database Development Process.

Conceptual Data Modelling-cont'd The goal of Conceptual Data Modeling is to develop an entity-relationship model that represents the information requirements of the business. Relationships-how the things of significance are related. Attributes-the specific information. Entity-Relationship Model Components • • • Entities . 26 . which needs to be held. Example The following entity-relationship model represents the information requirements of the Human Resources Department.the things of significance about which information needs to be held.

and/or purchased application packages. precise format. Quick Notes • Be sure to fully establish an organization's information requirements during the conceptual data modelling stage. Definition of Scope • An E-R Model provides a clear picture of the scope of an organization's information requirements. Robust Syntax • An E-R Model documents an organization's information requirements in a clear. User Communication • Users can easily understand the pictorial form of an E-R Model.Conceptual Data Modelling-cont'd An entity-relationship model is an effective means for collecting and documenting an organization's information requirements. • Use views or subsets of an E-R Model as a communication aide. Integration of Multiple Applications • An E-R Model provides an effective framework for integrating multiple applications. Requirements changes during later stages of the development life-cycle can be extremely expensive. Ease of Development • An E-R Model can be easily developed and refined. development projects. 27 .

network. or relational database.Conceptual Data Modelling-cont'd Conceptual Data Modelling is independent of the hardware or software to be used for implementation. 28 . An E-R Model can be mapped to a hierarchical.

29 . 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. Alternate Entity Definitions • • • An object of interest to the business.ENTITIES An entity is a thing of significance about which information needs to be known or held. An entity is a named thing. which need to be known. date of birth. Examples Possible attributes for the entity EMPLOYEE are: badge number. name. An entity is a class or category of thing. and location 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. and salary Possible attributes for the entity DEPARTMENT are: Name. number.

30 .cont'd Entity Diagramming Conventions • • • • • Soft box with any dimensions Singular.Entities . Synonyms are useful when two groups of users have different names for the same thing of significance. unique entity name Entity name in upper case Optional synonym name (in parentheses) Attribute names in all lower case Examples Quick Notes • • A synonym is an alternate name for an entity.

Each entity instance has specific values for the entity's attributes. badge number.cont'd Each entity must have multiple occurrences or instances. the Sales Department. Mary Jones. Example The entity EMPLOYEE has attributes of name.e.Entities . date of birth 15-MAR-50. Juan Gomez. 31 . Quick Notes • • • Instances are sometimes mistaken for entities. date of birth. and Jill Judge are all occurrences of the entity EMPLOYEE. An entity is a class or category of thing . The instance Jim Brown has the following values: name Jim Brown. The entity DEPARTMENT has one occurrence for each department in the company: The Finance Department.e. EMPLOYEE.000.g.g. An instance is a specific thing . and salary. and salary $55. badge number 1322. and the Development Department are all instances of the entity DEPARTMENT. Examples The entity EMPLOYEE has one occurrence for each employee in the business: Jim Brown. the employee Jim Brown.

it may not be an entity. Example Each employee has a unique badge number. which uniquely identify an entity and are part of the entity's UID are tagged with #*.cont'd Each instance must be uniquely identifiable from other instances of the same entity. Badge number is a candidate for the entity UID. Attributes. 32 . Example What attributes might uniquely identify the following entities? Quick Notes • • If an entity cannot be uniquely identified. An attribute or set of attributes that uniquely identify an entity is called a Unique Identifier (UID). EMPLOYEE'S Look for attributes that uniquely identify an entity.Entities .

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. • • • • Examine the nouns. Additional attributes of interest to the business may be uncovered later.IDENTIFY AND MODEL ENTITIES Follow the steps below to identify and model entities from a set of interview notes. For example. John Brown and Mary Smith are EMPLOYEES. 33 . Quick Note • Do not disqualify a candidate entity too soon. Are they things of significance? Name each entity." • Diagram each entity and a few of its attributes. "An EMPLOYEE has significance as a paid worker at the company.

"I'm the manager of a training company that provides instructor-led courses in management techniques. We teach many courses. Courses vary in length from one day to four days. a name.Identify and Model Entities . each of which has a code. Each course is taught by only one instructor. 34 . Jamie Brown from AT&T took every course we offer! We track each student's name and phone number. We create a course and then line up an instructor. The students can take several courses over time. We track each instructor's name and phone number. Some of our students and instructors do not give us their phone numbers. Introduction to UNIX and C Programming-are two of our more popular courses. An instructor can teach several courses. Paul Rogers and Maria Gonzales are two of our best teachers. and a fee.cont'd Example Identify and model the entities in the following set of information requirements. and many of them do this.

For example. For example. • An INSTRUCTOR has significance as a teacher of one or more COURSES.cont'd Solution The following entities model the Training Company's information requirements. 35 . Paul Rogers and Maria Gonzales.Identify and Model Entities . Jamie Brown. For example. Introduction to UNIX and C Programming. Entity Descriptions • A COURSE has significance as a training event offered by the Training Company. • A STUDENT has significance as a participant in one or more COURSES.

specific movie. For each club member. 1. and each tape is always a copy of a single.000 videotapes that we need to keep track of.g. Not all of our movies have star actors. We have over 3. John Wayne and Katherine Hepburn are always popular. We always have at least one tape for each movie we track. Yes. "I'm the owner of a small video store. And. Identify and model the entities in the following set of information requirements. we need to know its title and category (e." To belong to our club. We just track current rentals. Write a brief description of each entity. comedy. we’d like to keep his/her first and last name. we do have multiple copies of many of our movies. of course each club member has a membership number. and current address. war. drama." 36 . For each movie. A tape may be either Beta or VHS format. We give each movie a specific id. suspense. We have lots of customers. Show at least two attributes for each entity. We are frequently asked for movies starring specific actors. Then we need to keep track of what videotapes each customer currently has checked out. or sci-fi). We only rent videos to people who have joined our "video club.EXERCISE 3-1 Identify and model entities. Our tapes are very long and we don't have any movies. Customers like to know each actor's "real" birth name and date of birth. and then track which movie a tape contains. So we'd like to keep track of the star actors appearing in each movie. current phone number. which require multiple tapes. they must have good credit. We track only actors who appear in the movies in our inventory. We don't keep track of any rental histories. A customer may check out multiple videotapes at any given time. Each of our videotapes has a tape number. action.

either must be or may be.g. Relationship Syntax Example The relationship between INSTRUCTOR and COURSE is: Each COURSE may be taught by one and only one INSTRUCTOR.RELATIONSHIPS A relationship is a two-directional. or between an entity and itself. Quick Notes • • Cardinality is a synonym for the term degree. a degree . taught by or assigned to. Each INSTRUCTOR may be assigned to one or more courses..either one and only one or one or more. Each direction of a relationship has: • • • a name . 37 . A degree of 0 is addressed by may be. an optionality . significant association between two entities.e.

cont'd Diagramming Conventions • • • • A line between two entities Lower case relationship names Optionality Degree 38 .Relationships .

and then from right to left. Relationship from Left to Right (partial diagram) Each EMPLOYEE must be assigned to one and only one DEPARTMENT. Read this relationship first from left to right. Relationship from Right to Left (partial diagram) Each DEPARTMENT may be responsible for one or more EMPLOYEES. 39 .cont'd First read a relationship in one direction.Relationships . Example Read the relationship between EMPLOYEE and DEPARTMENT. and then read the relationship in the other direction.

Each EMPLOYEE may be the receiver of one or more PAYCHECKs. Each COURSE may be taken by one or more STUDENTS. Each STUDENT may be enrolled in one or more COURSES.Relationships .cont'd Example Read the relationship between STUDENT and COURSE. 40 . Example Read the relationship between PAYCHECK and EMPLOYEE. Each PAYCHECK must be for one and only one EMPLOYEE.

EXERCISE 3-2 Read relationships. 1. Write the relationship sentences for this E-R diagram. 41 .

Each DEPARTMENT may be responsible for one or more EMPLOYEES. d. Each EMPLOYEE may be assigned to one or more ACTIVITIES.EXERCISE 3-3 Draw an Entity-Relationship Diagram. c. Each ACTIVITY may be performed by one or more EMPLOYEES. Draw an Entity-Relationship diagram to represent the following: a. Each EMPLOYEE must be assigned to one and only one DEPARTMENT. b. 1. 42 .

* Some operating systems may allow a file to span disks. * l. Draw an Entity-Relationship diagram to represent the following: a.EXERCISE 3-4 Optional Exercise Draw an Entity-Relationship Diagram. Each TABLESPACE must be made up of one or more FILEs. h. g. Each SEGMENT must be included in one and only one TABLESPACE. 43 . Each FILE may be part of one and only one TABLESPACE. j. Each TABLESPACE must be part of one and only one ORACLE DATABASE. Each FILE must be resident on one and only one DISK. Each EXTENT must be included in one and only one SEGMENT. Each SEGMENT must be inclusive of one or more EXTENTS. k. Each EXTENT must be composed of one or more BLOCKs. e. f. Each BLOCK must be part of one and only one EXTENT. i. Each TABLESPACE may be divided into one or more SEGMENTS. 1. Each ORACLE DATABASE must be made up of one or more TABLESPACEs. Each DISK may be the host for one or more FILEs. d. c. b.

44 . Relationship Types • • • Many to One Relationships Many to Many Relationships One to One Relationships All relationships should represent the information requirements and rules of the business.RELATIONSHIP TYPES There are three types of relationships.

M:1 relationships that are mandatory in both directions are rare. Quick Notes • • M:1 relationships are very common.cont'd A Many to One Relationship (M to 1 or M:1) has a degree of one or more in one direction and a degree of one and only one in the other direction. 45 . Each CUSTOMER must be visited by one and only one SALES REPRESENTATIVE. Each SALES REPRESENTATIVE may be assigned to visit one or more CUSTOMERS. Example There is a M:1 relationship between CUSTOMER and SALES REPRESENTATIVE.Relationship Types .

cont'd A Many to Many Relationship (M to M or M:M) has a degree of one or more in both directions. Many to Many relationships are usually optional in both directions. although a Many to Many Relationship may be optional in just one direction. Each EMPLOYEE may be assigned to one or more JOBs. Each STUDENT may be enrolled in one or more COURSES.Relationship Types . Examples There is a M:M relationship between STUDENT and COURSE. Quick Notes • • Many to Many Relationships are very common. Each JOB may be carried out by one or more EMPLOYEES. Each COURSE may be taken by one or more STUDENTS. 46 . There is a M:M relationship between EMPLOYEE and JOB.

A 1:1 Relationship that is mandatory in both directions is very rare. Quick Notes • • • 1:1 Relationships are rare.Relationship Types . Entities. Each MOTHERBOARD may be incorporated into one and only one MICROCOMPUTER. which seem to have a 1:1 relationship. may really be the same entity. Each MICROCOMPUTER must be the host for one and only one MOTHERBOARD. 47 . Example There is a 1:1 relationship between MICROCOMPUTER and MOTHERBOARD.cont'd A One to One Relationship (1 to 1 or 1:1) has a degree of one and only one in both directions.

• Each relationship above the diagonal line is the inverse or mirror image of a relationship below the line. then the name of that relationship is shown in the intersection box. If a row entity is related to a column entity. Example The following relationship matrix shows a set of relationships between four entities. Relationship Matrix Conventions • 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. • If a row entity is not related to a column entity. 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 . then a long dash is shown in the intersection box. • Recursive relationships (between an entity and itself) are represented by the boxes on the diagonal.USING A RELATIONSHIP MATRIX Use a relationship matrix as an aide for the initial collection of information about the relationships between a set of entities. • • All the entities are listed along both the left-hand side of the matrix and the top of the matrix.

cont'd Map the contents of a relationship matrix to an E-R diagram. and add each relationship's optionality and degree. 49 . Draw a softbox for each entity and add the entity's attributes. Example Map the following relationship matrix to an E-R diagram. Draw a relationship line for each relationship.Using a Relationship Matrix . write-in the relationship's name.

Name each direction of the relationship. 50 . Read the relationship aloud to validate it. Determine the degree of each direction of the relationship. Steps • • • • • Determine the existence of a relationship.ANALYZE AND MODEL RELATIONSHIPS Follow a series of five steps to analyze and model relationships. Determine the optionality of each direction of the relationship.

there is not a significant relationship between DEPARTMENT and ACTIVITY.DETERMINE A RELATIONSHIP'S EXISTENCE Determine the existence of a relationship. Is there a significant relationship between DEPARTMENT and EMPLOYEE? Yes. Example Consider the entities DEPARTMENT and ACTIVITY. Is there a significant relationship between DEPARTMENT and ACTIVITY? No. 51 . Ask About a Relationship's Existence • Does a significant relationship exist between ENTITY A and ENTITY B? Example Consider the entities DEPARTMENT and EMPLOYEE. Examine each pair of entities to determine if a relationship exists. there is a significant relationship between DEPARTMENT and EMPLOYEE.

Example Log the relationships among ACTIVITY. and EMPLOYEE on a relationship matrix.Determine a Relationship's Existence . DEPARTMENT. 52 .cont'd Use a relationship matrix to systematically examine each pair of entities. The check marks indicate that a relationship exists.

• How is an ENTITY B related to an ENTITY A? An ENTITY B is relationship name an ENTITY A. Ask a Relationship's Name • How is an ENTITY A related to an ENTITY B? An ENTITY A is relationship name an ENTITY B. Optionally. How is a DEPARTMENT related to an EMPLOYEE? Each DEPARTMENT is responsible for an EMPLOYEE. How is an EMPLOYEE related to a DEPARTMENT? Each EMPLOYEE is assigned to a DEPARTMENT. Example Consider the relationship between DEPARTMENT and EMPLOYEE. Example Log the relationship names for the relationship between DEPARTMENT and EMPLOYEE. log the relationship names in a relationship grid.NAME THE RELATIONSHIP Name each direction of a relationship. 53 .

page C-10 54 . 5456-V1.Name the Relationship .0.cont'd Use a list of relationship name pairs to assist in naming relationships. Useful Relationship Name Pairs • • • • • • based on bought from description of operated by represented by responsible for the basis for the supplier of for the operator for the representation of the responsibility of Quick Note • Do not use related to or associated with as relationship names. For further information on the subject see: CASE*Method Entity Relationship Modelling.

a DEPARTMENT does not have to be responsible for an EMPLOYEE. Must an EMPLOYEE be assigned to a DEPARTMENT? Always? Is there any situation in which an EMPLOYEE will not be assigned to a DEPARTMENT? No. an EMPLOYEE must always be assigned to a DEPARTMENT. Must a DEPARTMENT be responsible for an EMPLOYEE? No. with the relationship names. Draw the relationship lines.DETERMINE RELATIONSHIP'S OPTIONALITY Determine the optionality of each direction of the relationship. Example 55 . Ask About a Relationship's Optionality • • Must ENTITY A be relationship name ENTITY B? Must ENTITY B be relationship name ENTITY A? Example Consider the relationship between DEPARTMENT and EMPLOYEE.

May an EMPLOYEE be assigned to more than one DEPARTMENT? No.DETERMINE RELATIONSHIP'S DEGREE Determine the degree of the relationship in both directions. an EMPLOYEE must be assigned to only one DEPARTMENT. Ask About a Relationship's Degree • May ENTITY A be relationship name more than one ENTITY B? • May ENTITY B be relationship name more than one ENTITY A? Example Consider the relationship between DEPARTMENT and EMPLOYEE. Add the relationship degrees to the E-R Diagram. Example 56 . a DEPARTMENT may be responsible for one or more EMPLOYEES. May a DEPARTMENT be responsible for more than one EMPLOYEE? Yes.

VALIDATE THE RELATIONSHIP Re-examine the E-R Model and validate the relationship. Each EMPLOYEE must be assigned to one and only one DEPARTMENT. Read the Relationship Aloud • Relationships must be readable and make business sense. 57 . Example Read the relationship represented by the following diagram. Each DEPARTMENT may be responsible for one or more EMPLOYEES.

Jamie Brown from AT&T took every course we offer! We track each student's name and phone number. Paul Rogers and Maria Gonzales are two of our best teachers. Analyze and model the relationships in the following set of information requirements. Introduction to UNIX and C Programming are two of our more popular courses. Use a relationship matrix to track the existence of relationships between the entities." 58 . 1. We create a course and then line up an instructor. and many of them do this. Courses vary in length from one day to four days. each of which has a code. a name. An instructor can teach several courses.EXERCISE 3-5 Analyze and model relationships. We teach many courses. and a fee. We track each instructor's name and phone number. The students can take several courses over time. Some of our students and instructors do not give us their phone numbers. Each course is taught by only one instructor. "I'm the manager of a training company that provides instructor-led courses in management techniques.

cont'd The following entities were previously modelled.Exercise 3-5 . 59 .

" To belong to our club. current phone number. we need to know its title and category (e. We just track current rentals. Not all of our movies have star actors. 1. or sci-fi). specific movie." 60 . which require multiple tapes. comedy. We have lots of customers.000 videotapes that we need to keep track of. We don't keep track of any rental histories. action. We always have at least one tape for each movie we track. suspense. Each of our videotapes has a tape number. and each tape is always a copy of a single.g. of course each club member has a membership number. John Wayne and Katherine Hepburn are always popular. We only rent videos to people who have joined our "video club. we do have multiple copies of many of our movies. and we don't have any movies. A tape may be either Beta or VHS format. We are frequently asked for movies starring specific actors. they must have good credit. For each club member. And.EXERCISE 3-6 Analyze and model relationships. Customers like to know each actor's "real" birth name and date of birth. For each movie. Use a relationship matrix to track the existence of relationships between the entities. and current address. drama. We give each movie a specific id. Yes. Analyze and model the relationships in the following set of information requirements from Exercise 3-1. We track only actors who appear in the movies in our inventory. We have over 3. "I'm the owner of a small video store. we'd like to keep their first and last name. A customer may check out multiple videotapes at any given time. Then we need to keep track of what videotapes each customer currently has checked out. and then track which movie a tape contains. war. So we'd like to keep track of the star actors appearing in each movie. Our tapes are very long.

cont'd The following entities were modelled earlier in Exercise 3-1.Exercise 3-6 . 61 .

Memorable Shapes • • • Make the E-R Diagram memorable. People remember shapes and patterns. which is easier to follow when relationship lines must cross. Stretch or shrink entity boxes to help the layout of the dia gram.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. Draw relationship lines straight and either horizontal or vertical. Use an angle of 30° to 60°. Align text horizontally. Use plenty of white space to avoid the look of congestion. Unambiguous Text • • • • • Make all text unambiguous. Do not draw an E-R Diagram on a grid. Avoid abbreviations and jargon. Put relationship names at the ends of the line and on opposite sides of the line. which are difficult to follow. Add adjectives to improve understanding. Neat and Tidy • • • • • Line entity boxes up. Avoid the use of many closely parallel lines. 62 .

63 . For further information on the subject see: CASE*Method Entity Relationship Modelling. 5456-V1. 3-16 and 3-17. Position lower volume. Position higher volume. pp.Lay Out the E-R Diagram . at least one end of the relationship will point down or to (he right.0. less volatile entities toward the bottom and right of the diagram. Quick Note • Until an M:M relationship is resolved. more volatile entities toward the top and left of the diagram. Layout Rules • • • Try to position a crowsfoot on the left end or the top end of the relationships line.cont'd Draw crowsfeet pointing up or to the left.

The entity's name is always a qualifier of the attribute name . Example What are some attributes of the entity EMPLOYEE? • • • • • Badge number or payroll number identify an EMPLOYEE. date ordered.ATTRIBUTES Attributes are information about an entity that needs to be known or held. identifying.. Age quantifies an EMPLOYEE. date of contact.e. quantifying or expressing the state of the entity. Therefore.. an attribute's name should not include its entity's name. First name and last name qualify an EMPLOYEE. is it quantity. Example 77506 and 763111 are values of the attribute badge number. Attributes represent a type of description or detail.g. Quick Notes • • • • • Attribute names should be clear to the user. on leave. e. active. terminated) expresses the status of an EMPLOYEE. 64 . Employment status (e.g. or quantity purchased? Always clarify a date attribute with a descriptor or verb phrase.e.g. Payroll category (e.g.g. John is a value of the attribute first name of EMPLOYEE. weekly or salary) classifies an EMPLOYEE. classifying. Attributes describe an entity by qualifying. not an instance. Attribute names should be specific . code of COURSE. quantity returned. not codified for the developer. An attribute should only be assigned to a single entity.

List attribute names in their entity's soft box.Attributes . Example 65 .cont'd Diagramming Conventions • • Attribute names are singular and shown in lower case.

Quick Notes • • Attributes containing dates. social security numbers. street address. The number of an ITEM consists of type. Break down aggregate attributes and embedded code fields into simple attributes. and zip codes are generally not decomposed further. vendor. and item number. city.cont'd Always break attributes down into their lowest meaningful components. 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.Attributes . 66 . times. state. and zip code. Examples The name of a PERSON can be broken down into last name and first name. • The level of attribute decomposition will depend upon the business requirements.

a CLIENT may be contacted multiple times.Attributes . The entity CONTACT is missing. 67 . A multi-valued attribute or repeating group is not a valid attribute. Example Are the attributes of CLIENT single -valued? No. Quick Note • A repeated attribute indicates a missing entity. and the business needs to keep all dates of contact.cont'd Verify that each attribute has a single value for each entity instance.

the total number of each salesman's monthly sales) Max/Min/Average (e. Common Derived Data • • • • Counts (e. Quick Notes • • Derived attributes are redundant. the number of salesman in a region) Totals (e. statistics on the sales of a group of salesmen) Other calculations (e. 68 .g.g. a salesman's commission calculated at 10% of sales) Do not include derived attributes in an E-R Model. The derived data must be revised whenever the attributes upon which it is based are revised.cont'd Verify that an attribute is not derived or calculated from the existing values of other attributes.Attributes .g. • Address the option of storing derived data during Database Design.g. Redundant data can lead to inconsistent data values.

Example Determine if all the attributes of EMPLOYEE are attributes. and trim color for each color scheme. Example Determine if all of the attributes of VEHICLE are really attributes. Color scheme then had attributes of its own. but if it is necessary to keep each dependent's name and age. the user defined the requirement to track the paint color. paint type. Quick Notes • • Entities have attributes. then it is really an entity. Attributes have no attributes on their own. then DEPENDENT becomes an entity. and became an entity with a relationship to VEHICLE. Later. 69 . Number of dependents can now be derived. Initially the user identified color scheme as an attribute of VEHICLE.DISTINGUISH ATTRIBUTES AND ENTITIES If an attribute has attributes of its own. Number of dependents is an attribute of EMPLOYEE.

70 . Instances of entities and attributes are also nouns.cont'd All entities are nouns. Entity Characteristics Anything about which information must be held Possesses one or more attributes Does not possess attribute (s) of its own Attribute Characteristics Qualifies an entity If an entity has no attributes.Distinguish Attributes and Entities . Attributes for that entity may appear later. it may be only an attribute May have multiple occurrences associated with another entity via a relationship If an attribute has an attribute. but not all nouns are entities. then it is an entity or have no signific ance Has a single value for each entity occurrence (no repeating groups) Quick Notes • • Do not disqualify a candidate entity too quickly.

The remaining attributes are mandatory. Example Identify the attributes for the PERSON entity.ATTRIBUTE OPTIONALITY Identify each attribute's optionality using an attribute tag. Optional Attributes • • A value may be known for each entity occurrence. Determine their optionality. 71 . Tagged with *. The title and weight attributes are optional. Tagged with o. Mandatory Attributes • • A value must be known for each entity occurrence.

Attribute Optionality . Entity Name: PERSON Attribute Name Tags Sample Data code * 110 301 134 340 589 name * Jones Smith Gonzales Johnson Brown title o President Treasurer Secretary sex * F M F M M weight o 210 110 195 Quick Note • An Entity Instance Chart is useful for logging sample attribute data. 72 . 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.cont'd Use sample attribute instance data to validate attribute Optionality.

Employee's name).IDENTIFY ATTRIBUTES Identify attributes by examining interview notes and by asking the user questions. Salary amount for each employee).g. Possessive nouns and pronouns (e.g. Prepositional phrases (e. Nouns. Questions to Ask the User • • What information do you need to know or hold about entity x? What information would you like displayed or printed about entity x? 73 . Attributes may appear in interview notes as: • • • • Descriptive words and phrases.

0.cont'd Examine documentation on existing manual procedures or automated systems to discover additional attributes and omissions. 74 . For further information on the subject see: CASE*Method Entity Relationship Modelling. Beware of derived data. pp. 5-6 and 5-7. 5456-V1.Identify Attributes . Paper Forms Headings Prompts Computer Reports Fields Headings Sort Orders Computer Files Record layouts File Dumps Questions to Ask the User • Is this attribute really needed? Quick Notes • • Beware of obsolete requirements left over from previous systems.

We collect dues on a yearly basis. came and spoke. and Storage Tech. we held a special CASE day last May. We need an information system to help us keep track of all our affairs. Some of our annual events include the September Meeting. Our members come from many different companie s including Coors. Redrocks Community College. and type of business. and our records are a mess.K. For each company. mailing address. and others attend very infrequently or just enjoy receiving our newsletter. We only try to track a single current employer for each member. Develop an E-R Diagram for the following situation. For example. We number each set of comments. We're an all volunteer organization. we need to keep the member's name. office phone number. number of attendees. We only keep the main company address for each company. We have a standard set of type of business codes. we keep the company name. the November Meeting. and everyone's dues are due in January. We'd like to track each event's date.EXERCISE 3-7 Develop an E-R Diagram. and any comments on the event. but keeping this information current is a real chore because our members are always changing companies. an optional description of the event. EG&G. how much money we spent on it. and Richard Barker from ORACLE U. We also hold specia l events each year. For each member. 1. A set of comments is just a free form text statement of any length. and D. We also like to know which company a member works for. and our April Meeting. type of membership (individual or corporate). address. the annual Training Day in January.U. We hold various events during the year. and we frequently get multiple sets of comments for an event. "Our regional Oracle User's Group has grown to include over 200 members. and whether or not the member is current on dues. A few of our members are unemployed. Some of our members are really active. Be sure to tag each attribute with its optionality. We hold our events at several different locations around town including AT&T. and we'd like to track information about each event. We also track which members attended which events. where it was held. (continued) 75 . We treat all comments as if they came from an anonymous submitter. We definitely need to automate our membership records. title.

001 is for IBM/MVS. We have a unique.Exercise 3-7 . For example. and health systems. For example. human resources. 002 is for IBM/VM." 76 . so we don't need to know which platforms they run on. 020 is for OS/2. The applications should be portable. oil and gas. 030 is for PC/DOS: 050 is for Sun Unix. We also like to track which application areas each member is interested in. 003 is for VAX/VMS. and 080 is for other Unix platforms. three-digit system identification tag for each type of platform. pharmaceuticals. accounting.cont'd "We also need to track what type of computer platforms our members are using.

Each entity occurrence must be uniquely identifiable. each ticket is uniquely identified by its date of performance and its seat number. Quick Notes • • All components of a UID must be mandatory *. Tag each UID attribute with #*. Example In a business. The UID for the entity DEPARTMENT is the attribute number. each occurrence of DEPARTMENT is uniquely identified by its department number.ASSIGN UNIQUE IDENTIFIERS A Unique Identifier (UID) is any combination of attributes and/or relationships that serve to uniquely identify an occurrence of an entity. An entity must have a UID. Example For a small theatre. The UID for the entity THEATRE TICKET is the combination of the two attributes date of performance and seat number. or it is not an entity. 77 .

Use a UID bar to indicate that a relationship is part of the entity's UID. Quick Note • A relationship included in a UID must be mandatory and one and only one in the direction that participates in the UID.cont'd An entity can be uniquely identified through a relationship. Example The UID bar indicates that the relationship with BANK is part of the UID of ACCOUNT. Within a bank. 78 . each account has a unique account number. each bank is assigned a unique bank 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.Assign Unique Identifiers . Example In the banking industry.

79 . An employee may be given multiple assignments to a single project.Assign Unique Identifiers . What is the UID of the entity WORK ASSIGNMENT? A WORK ASSIGNMENT is uniquely identified by the EMPLOYEE the WORK ASSIGNMENT is for.cont'd An entity may be uniquely identified through multiple relationships. Example A business needs to track the work assignments of its employees. Employees are given work assignments to projects. and the date assigned. the PROJECT the WORK ASSIGNMENT is to. each with a different date of assignment. Quick Note • Both relationships are mandatory and one and only one in the direction included in the UID.

Assign Unique Identifiers . or do not tag them. Example What uniquely identifies an EMPLOYEE? Candidate UIDs include: 1. Quick Notes • • Either tag Secondary UIDs as (#). and the others to be secondary UIDs.cont'd An entity may have more than one UID. 80 . payroll number 3. first name/last name Are they all unique? The first name/last name combination is probably not unique. CASE*Dictionary can document multiple secondary UIDs. badge number 2. Select one candidate UID to be the primary UID.

Quick Notes • • Artificial attributes are used often for UIDs. artificial attributes to help identify each entity. Example What uniquely identifies a CUSTOMER entity? Possibly the CUSTOMER'S first and last name could be a UID.Assign Unique Identifiers . However. Create an artificial attribute called CUSTOMER code which will be unique for each instance of CUSTOMER. Define an artificial code when the business does not have a natural attribute which uniquely identifies an entity.cont'd Consider creating unique. 81 . there could be two CUSTOMERS with the same name.

Assign Unique Identifiers . Evaluate the Attributes • What mandatory attributes identify the entity? Seek out additional attributes that help identify the entity. • • Does an attribute uniquely identify the entity? What combinations of attributes uniquely identify the entity? Consider the Relationships • • • • Which of the relationships help identify the entity? Are there missing relationships that help identify the entity? Does the relationship help uniquely identify the entity? Is the relationship mandatory and one and only one in the direction from the entity? Validate the UID • Examine sample data. Consider creating artificial attributes for identification. 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 .cont'd Search for attributes and relationships to identify each entity.

The students can take several courses over time. a name. Jamie Brown from AT&T took every course we offer! We track each student's name and phone number. Introduction to UNIX and C Programming are two of our more popular courses. An instructor can teach several courses. and identify a UID for each entity. and many of them do this. Some of our students and instructors do not give us their phone numbers. Each course is taught by only one instructor. "I'm the manager of a training company that provides instructor-led courses in management techniques. 1. We track each instructor's name and phone number. and a fee. We teach many courses. We create a course and then line up an instructor. Add these attribute tags and UID's to the E-R model. Courses vary in length from one day to four days. Paul Rogers and Maria Gonzales are two of our best teachers.EXERCISE 3-8 Identify UIDs." E-R Model from Exercise 3-5 83 . supply attribute tags for each attribute. each of which has a code. For the Training Company situation and E-R model from Exercise 3-5.

We have over 3. and we don't have any movies. Not all of our movies have star actors. Each of our video tapes has a tape number. we do have multiple copies of many of our movies. We track only actors who appear in the movies in our inventory. And.EXERCISE 3-9 Identify UIDs. For the Video Store situation and E-R Model from Exercise 3-6. and each tape is always a copy of a single. We are frequently asked for movies starring specific actors. Our tapes are very long.000 video tapes that we need to keep track of. they must have good credit. A customer may check out multiple video tapes at any given time." To belong to our club. current phone number. Yes. identify a UID for each entity and add these UIDs to the E-R model. we’d like to keep his or her first and last name. supply attribute tags for each attribute. drama. So we'd like to keep track of the star actors appearing in each movie. or sci-fi). A tape may be either Beta or VHS format. comedy. We have lots of customers. action. We just track current rentals. We don't keep track of any rental histories. specific movie. Then we need to keep track of what video tapes each customer currently has checked out. we need to know its title and category (e. For each movie. We give each movie a specific id. and current address. 1. John Wayne and Katherine Hepburn are always popular. Also. We only rent videos to people who have joined our "video club. For each club member." 84 .g. We always have at least one tape for each movie we track. suspense. war. "I'm the owner of a small video store. Customers like to know each actor's "real" birth name and date of birth. and then track which movie a tape contains. which require multiple tapes. of course each club member has a membership number.

cont'd E-R Model from Exercise 3-6 85 .Exercise 3-9 .

We treat all comments as if they came from an anonymous submitter. we keep the company name. and we frequently get multiple sets of comments for an event. We also track which members attended which events. how much money we spent on it. For each company. and our records are a mess. where it was held. A few of our members are unemployed. We hold various events during the year.company address for each company. office phone number. address. and our April Meeting. Some of our annual events include the September Meeting. came and spoke. an optional description of the event. and we'd like to track information about each event. We definitely need to automate our membership records. We'd like to track each event's date. "Our regional Oracle User's Group has grown to include over 200 members. identify a UID for each entity and add these UIDs to the E-R Model. We need an information system to help us keep track of all our affairs. We hold our events at several different locations around town including AT&T. mailing address. A set of comments is just a free form text statement of any length.K. We only try to track a single current employer for each member. and Storage Tech. We also like to know which company a member works for. and type of business. we need to keep the member's name. title. we held a special CASE day last May. the annual Training Day in January. and D. We have a standard set of type of business codes. We only keep the main . number of attendees.EXERCISE 3-10 Identify UIDs. For example. EG&G. Our members come from many different companies including Coors. We also hold special events each year. For each member. and others attend very infrequently or just enjoy receiving our newsletter. Some of our members are really active. We collect dues on a yearly basis and everyone's dues are due in January. type of membership (individual or corporate). and any comments on the event. For the Oracle User's Group situation and E-R Model from Exercise 3-7.U. and Richard Barker from ORACLE U. (continued) 86 . the November Meeting. 1. and whether or not the member is current on dues. but keeping this information current is a real chore because our members are always changing companies. Redrocks Community College. We're an allvolunteer organization. We number each set of comments.

human resources. For example. accounting. The applications should be portable. "We also like to track which application areas each member is interested in. 050 is for Sun Unix. so we don't need to know which platforms they run on. and 080 is for other Unix platforms. three-digit system identification tag for each type of platform. 001 is for IBM/MVS.cont'd We also need to track what type of computer platforms our members are using." E-R Model from Exercise 3-7 87 . 003 is for VAX/VMS. and health systems. pharmaceuticals.. 030 is for PC/DOS. 002 is for IBM/VM. We have a unique. oil and gas. 020 is for OS/2.Exercise 3-10 . For example.

Diagramming Conventions • • • • • Soft box Singular. Write a description of it. Name each entity. 88 . 3. Is each instance of the entity uniquely identifiable? Which attribute or attributes could serve as its UID? 5. John Brown and Mary Smith are EMPLOYEES. Examine the nouns. For example. "An EMPLOYEE has significance as a paid worker at the company. Is there information of interest about the entity that the business needs to hold? 4.REVIEW: BASIC CONCEPTUAL DATA MODELLING An entity is a thing of significance about which information needs to be known or held. unique name Name in upper case Optional synonym name (in parentheses) Any dimensions Identify and Model Entities 1." 6. Are they things of significance? 2. Diagram each entity and a few of its attributes.

3. Determine the optionality of each direction of the relationship. Name each direction of the relationship. Determine the degree of each direction of the relationship.cont'd A relationship is a two-directional. 89 . 2. significant association between two entities. or between an entity and itself. 5. Determine the existence of a relationship. Model the relationship. 4. Relationship Syntax Diagramming Conventions Crows always fly east or south! Analyze and Model the Relationships Between Entities 1.Review: Basic Conceptual Data Modelling .

Determine the optionality of the attribute.Review: Basic Conceptual Data Modelling . 8. 7. Verify that an attribute is not derived. Identify a candidate attribute. 3. 2. 4. Analyze and Model Attributes 1. 6. Break down aggregate attributes. lower case. Associate the attribute with an entity. 90 . 5. Validate that the attribute is really an attribute and not an entity. Diagramming Conventions • • Attribute names are singular. Attribute tags: * for mandatory and o for optional.cont'd Attributes are information about an entity that needs to be known or held. Name the attribute. Verify that an attribute is single valued. and do not include the entity's name.

Diagramming Conventions • # indicates an attribute is part of an entity's UID. Define the UID for the entity.Review: Basic Conceptual Data Modelling . • The UID bar indicates a relationship is part of the UID. A Unique Identifier (UID) is any combination of attributes and/or relationships that serve to uniquely identify an occurrence of an entity. 91 . Determine the entity's dependence upon other related entities. Identify UIDs for Each Entity 1. 2. 3.cont'd Each entity must be uniquely identifiable. Seek out candidate attributes that help identify an entity.

4 ADVANCED CONCEPTUAL DATA MODELLING 92 .

Validate that an attribute is properly placed based upon its dependence on its entity's UID. you will be able to: 1. subtypes.SECTION OBJECTIVES At the end of this section. Identify and model advanced data constructs including recursive relationships. 2. 93 . and exclusive relationships. 3. Resolve many-to-many relationships with intersection entities.

but its principles apply to Conceptual Data Modelling. Validate each attribute's placement using the rules of normalization. Normal Form Rule First Normal Form (1NF) Second Normal Form (2NF) Third Normal Form (3NF) Description All attributes must be single -valued An attribute must be dependent upon its entity's entire unique identifier. Quick Notes • Third normal form is the generally accepted goal for a database design that eliminates redundancy. A normalized entity-relationship data model automatically translates into a normalized relational database design. 94 . • Higher normal forms are not widely used. No non-UID attribute can be dependent on another non-UID attribute.NORMALIZE THE DATA MODEL Normalization is a relational database concept.

therefore the entity CLIENT is not in 1NF Create an additional entity CONTACT with a M:1 relationship to CLIENT. No attribute should have repeating values. how could it be converted to 1NF? The attribute date contacted has multiple values. Validation Check: • Validate that each attribute has a single value for each occurrence of the entity.cont'd First Normal Form Rule: All attributes must be single-valued. If an attribute has multiple values.Normalize the Data Model . create an additional entity and relate it to the original entity with a M:1 relationship. Example Does the entity CLIENT comply with 1NF? If not. 95 .

Example Validate the placement of the COURSE entity's attributes.cont'd Second Normal Form Rule: An attribute must be dependent upon it entity's entire unique identifier. Each instance of a BANK and account number determine specific values of balance and date opened for each account. 96 . It is dependent on BANK. Example Validate the placement of the attributes for the ACCOUNT and BANK entities. The attributes are properly placed. Each instance of a course code determines a specific value for name duration and fee. Each specific instance of the UID must determine a single in stance of each attribute. It should not be an attribute of ACCOUNT. • Validate that an attribute is not dependent upon only part of it's entity's UID. it is misplaced and must be moved.Normalize the Data Model . Validation Check: • Validate that each attribute is dependent upon its entity's entire unique identifier. but not on account number. If an attribute is not dependent on its entity's entire UID. The attribute bank location is misplaced.

Normalize the Data Model . move both the dependent attribute and the attribute it is dependent upon to a new.cont'd Third Normal Form Rule: No non-UID attribute can be dependent on another non-UID attribute. 97 . and place the attributes accordingly. Create another entity called CUSTOMER with a UID of customer id. 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. 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. related entity. Quick Note • If an attribute is dependent upon a non-UID attribute.

Optionally. re-draw the E-R diagrams in third normal form. 98 . and explain what rule of normalization each misplaced attribute violates. For the following E-R Model. 2.EXERCISE 4-1 Normalize an E-R Model 1. evaluate each entity against the rules of normalization. identify the misplaced attribute.

RESOLVE M:M RELATIONSHIPS Attributes may seem to be associated with a M:M Relationship. Attributes only describe entities. the relationship must be resolved. If attributes describe a relationship. Resolve that M:M relationship by adding an intersection entity with those attributes. 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 . Example Consider the M:M relationship between PRODUCT and VENDOR.

Quick Notes • An Intersection Entity is frequently identified by its two originating relationships . Intersection entities frequently represent real-world business entities. Current price is really an attribute of the entity CATALOG ITEM. They tend to be high volume and volatile entities. the requirement for additional attributes of CATALOG ITEM surfaced: package quantity and unit of measure are also attributes of CATALOG ITEM. 100 . • • • The relationships from the intersection entity are always mandatory. Once the entity CATALOG ITEM is defined.Resolve M:M Relationships . Example The M:M relationship between PRODUCT and VENDOR can be resolved by adding the intersection entity CATALOG ITEM. The UID for CATALOG ITEM is composed of its two relationships. Intersection entit ies usually contain consumables like quantity used and dates.note the two UID bars.cont'd Replace or resolve a M:M Relationship with a new Intersection Entity and two M:1 relationships.

101 .Resolve M:M Relationships . M:M Relationship Layout Intersection Entity Layout 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.cont'd Position Intersection Entities to allow the crowsfeet to point up or to the left.

Example Resolve the following M:M relationship to accommodate these additional requirements: "Track the date each student enrolled in a course." Solution Add the intersection entity ENROLLMENT and two M:1 relationships. include the attribute date enrolled as part of the UID. the date the student completed the course. Quick Note • This model only tracks the last date the student enrolled in a specific course.cont'd The UID of an intersection entity is frequently composed of its relationships to the two originating entities. 102 . date completed. and grade. ENROLLMENT has attributes of date enrolled. and the student's grade.Resolve M:M Relationships . The UID of ENROLLMENT is made up of its relationships to STUDENT and COURSE. If multiple enrollments need to be kept.

and the duration of that assignment.Resolve M:M Relationships ." Add an intersection entity called WORK ASSIGNMENT with attributes date assigned and duration. and the attribute date assigned. 103 . the related PROJECT. WORK ASSIGNMENT is partially identified by its relationships to EMPLOYEE and PROJECT. An employee may have multiple assignments to a project. Example Resolve the following M:M relationship to accommodate these additional requirements: "Track the date each employee is assigned to a project. but those two relationships are not enough to uniquely identify a WORK ASSIGNMENT.cont'd An intersection entity's relationships to the two originating entities may not be adequate to uniquely define each occurrence of the intersection entity. with different assignment dates. Therefore. the UID of WORK ASSIGNMENT must include the related EMPLOYEE.

Add the intersection entity VENDOR ITEM with an attribute of current price. What other information needs to be known about a VENDOR ITEM? "We also need to know the package quantity and unit of measure of each VENDOR ITEM. 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." 104 .Resolve M:M Relationships .cont'd Once an intersection entity is identified. search for additional attributes which describe the intersection entity. Resolve the following M:M relationship to accommodate this additional requirement.

or help to identify an intersection entity.Resolve M:M Relationships . So the attribute catalog number should be the UID of VENDOR ITEM.cont'd Search for attributes which identify. and each VENDOR ITEM has a unique catalog number. Example How do you identify each VENDOR ITEM? Do you use the combination of the related VENDOR code and the PRODUCT id? "No." According to the rules of the business. each VENDOR ITEM has a unique catalog number. we have a catalog of all orderable VENDOR ITEMs. 105 .

the user has not identified any attributes that are associated with the M:M relationship. An Intersection Entity with no attributes is the exception to the rule that an entity must have attributes to be an entity. 106 . Resolve the M:M relationship with an Intersection Entity with no attributes. Example In the Video Store situation.cont'd Resolve all M:M relationships by the end of the Analysis phase.Resolve M:M Relationships . The UID for an empty Intersection Entity is always composed of the relationships of the two entities from which it or iginated. This forced resolution may result in an Intersection Entity with no attributes. the following M:M relationship was defined. At the end of the Analysis Stage. Quick Notes • • • An Intersection Entity with no attributes is just a two-way cross-reference list between occurrences of the entities.

1. Additional Requirements "We would also like to keep a brief description of each member's interest in each specific application area. Another member might be interested in an application area without describing that interest. one member might already have a large accounting application system that they developed in house. a M:M relationship was initially modelled between the MEMBER entity and the APPLICATION AREA entity." 107 .EXERCISE 4-2 Resolve a M:M relationship. Resolve that M:M relationship based upon the following additional requirements. In the E-R Model for the Oracle User's Group from Exercise 3-10. For example.

and price.EXERCISE 4-3 Resolve a M:M relationship. 1. Add the attributes date ordered. quantity ordered. 108 . Resolve the following M:M Relationship between CUSTOMER and PRODUCT.

MODEL HIERARCHICAL DATA Represent hierarchical data as a set of many to one relationships. Example Model a company's hierarchical organization structure as a set of M:1 relationships. Quick Note • Oracle's E-R Diagram layout rule Crows fly east or south causes hierarchies to be drawn upside-down or sideways! 109 .

110 . The UID of FLOOR is the floor number and the BUILDING it is contained in. Example What are the UIDs of the entities FLOOR.Model Hierarchical Data . and ROOM? The UID of ROOM is the room id and the SUITE it is located within.cont'd The UID's for a set of hierarchical entities may be propagated through multiple relationships. SUITE. The UID of SUITE is the suite number and the FLOOR it is located on.

DIVISION. and COMPANY.cont'd Consider creating artificial attributes to help identify entities in a hierarchical relationship. independent. independent. artificial identification codes tend to be shorter in length. and TEAM? Each TEAM could be identified based upon its DEPARTMENT. use independent artificial identifiers. Or each entity could have a unique. DEPARTMENT. Example In a typical organization structure. If the hierarchical structure changes often. 111 . Quick Notes • • Unique. what could uniquely identify instances of the entities DIVISION. artificial identification code.Model Hierarchical Data .

but remember that crows always fly east or south. Each EMPLOYEE may be managed by one and only one EMPLOYEE. Example Read the recursive relationship in the following E-R Diagram. 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.MODEL RECURSIVE RELATIONSHIPS A Recursive Relationship is a relationship between an entity and itself. 112 . The loop can appear on any side of the entity's box.

cont'd Consider representing a hierarchy as a recursive relationship. A recursive relationship must be optional in both directions. If each ORGANIZATION ELEMENT must be within another ORGANIZATION ELEMENT.Model Recursive Relationships . the entities at each level of the hierarchy would have the same attributes. Example A business hierarchy can be drawn as a recursive relationship. A recursive organization model can readily accommodate the addition or subtraction of organization layers. • 113 . A recursive organization model cannot handle a mandatory relationship. Quick Notes • • • The single recursive entity must include all of the attributes of each individual entity. Ideally. the organization hierarchy would have to be infinite.

114 . and products. Example An automobile manufacturing organization needs to track elementary parts.Model Recursive Relationships . subassemblies.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. assemblies. The following E-R diagram models this data by considering each of these part categories as an entity.

Example For the automobile manufacturing organization. consider all elementary parts.cont'd Model Bill of Materials data as a many to many recursive relationship.Model Recursive Relationships . Each COMPONENT may be a part of one or more COMPONENTS. Then the previous complex E-R Model can be remodelled as a simple recursive relationship. assemblies. subassemblies. Each COMPONENT may be made up of one or more COMPONENTS. and products as instances of an entity called COMPONENT. 115 .

ASSEMBLY RULE will have an attribute of quantity. Resolve this M:M recursive relationship by adding the intersection entity ASSEMBLY RULE and two M:1 relationships back to the COMPONENT entity. which are a part of a single fan.Model Recursive Relationships . This model will track information about which components are part of a fan. 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.cont'd Resolve a recursive M:M relationship with an intersection entity and two M:1 relationships to different instances of the original entity. The two M:1 relationships from an instance of ASSEMBLY RULE will be associated with different instances of the COMPONENT entity. will it also track how many washers are parts of a fan? The attribute quantity seems to be associated with the recursive relationship. 116 . Example Consider the recursive model of a Bill of Materials structure. For example. But if a washer is part of a fan. The ASSEMBLY RULE entity will record the quantity of washers.

Colorado. and Pacific Districts. The Pacific Coast District is composed of two territories: the California and Nevada territories. We don't overlap our employees' responsibilities .a sales area is always the responsibility of a single salesperson. Each salesperson is responsible for one or more sales areas. the Western Region is divided into the Rocky Mountain. into four major sales regions: the Northern. Each territory has a unique territory code. Pacific Coast. and Western Regions. We also have sales managers who are responsible for one or more sales districts. Sometimes our salespersons. Each district has a unique district code. and Utah-New Mexico. and directors will be on leave or special assignments arid will not have sales turf responsibilities. and one as a recursive structure. 1. Each sales region is then divided into sales districts." 117 . Each sales region has a unique region code. managers. For example. The northwest District is made up of two territories: The Washington and Oregon-Idaho territories.S. Northwest. "Our company sells products throughout the United States. We identify all our sales personnel by their employee ids. Develop one as a hierarchical structure. Colorado is made up of two sales areas: the Front Range and the Western Slope sales areas. Eastern. Develop two E-R diagrams to represent the following situation. Southern. For example. Each district is made up of sales territories. The Rocky Mountain District is composed of three territories: Wyoming-Montana.EXERCISE 4-4 Model hierarchical and recursive relationships. So we've divided the U. and our managers and director's responsibilities don't overlap. Each sales manager is responsible for the territories within his districts. Then each sales territory is broken down into sales areas. Each sales area has a unique sales area code. and sales directors who are responsible for one or more sales regions. and has a specific sales quota. The Pacific District includes the Hawaii territory and the Alaska territory.

But what if an INSTRUCTOR is also a STUDENT? Entities. we defined an INSTRUCTOR entity and a STUDENT entity.MODEL ROLES WITH RELATIONSHIPS Beware of entities that represent roles. Example In the E-R Model for the Training Company. may share overlapping instances. 118 . and a STUDENT is never an INSTRUCTOR. which represent roles. This model works fine if an INSTRUCTOR is never a STUDENT.

which may take on the roles of instructor and/or student.cont'd Use relationships to model roles. define a PERSON entity. Relationships allow a single entity instance to assume multiple roles.Model Roles with Relationships . Example For the Training Company. 119 .

last name. Quick Note • Beware of instances that could be both subtypes . Each EMPLOYEE is either an EXEMPT EMPLOYEE or a NON-EXEMPT EMPLOYEE. overtime rate." Create an EMPLOYEE supertype with two subtypes.MODEL SUBTYPES Use subtypes to model exclusive entity types which have common attributes and common relationships. first name. track the employee's hourly rate.the subtype/supertype construct is incorrect in those instances. 120 . and membership in a union. track each employee's badge number. For all employees. For the exempt employees. also track employee salary. and assigned department. For the non-exempt employees. Example "A business has defined two types of employees: exempt and non-exempt.

A supertype may be split into two or more mutually exclusive subtypes.cont'd A supertype is an entity that has subtypes. first name. Example The EXEMPT EMPLOYEE subtype has an attribute of salary. The NON-EXEMPT EMPLOYEE subtype has attributes of hourly rate and overtime rate. 121 . EMPLOYEES Each subtype may have its own attributes and relationships. All must be assigned to one and only one DEPARTMENT.Model Subtypes . Quick Note • A subtype with no attributes or relationships of its own may be a synonym for the supertype entity and not a subtype. Example An EMPLOYEE is either an EXEMPT EMPLOYEE or a NON-EXEMPT EMPLOYEE. and last name. A supertype may have attributes and relationships shared by its subtypes. but not both. Example All EMPLOYEES must have the attributes badge number. and a relationship with the entity UNION.

. or OTHER JOB.." Subtype Reading Rules ".subtype. which is a type of JOB.. a CLERICAL JOB.CLERICAL JOB. Subtypes must form a complete set with no overlaps.. a job is either a MANUAL JOB or a CLERICAL JOB. which is a type of supertype." Example "..Model Subtypes ." Always use the subtype OTHER when unsure about the set's completeness. but there might be a few exceptions.. Supertype Reading Rules "Each supertype entity must be either a subtype 1 or a subtype2" Example "Each JOB must be either a MANUAL JOB... 122 . Example In general.cont'd All instances of the supertype entity must belong to one and only one of the subtype entities...

Model Subtypes . AIRPLANE.cont'd Subtypes can be further subtyped. Example Define further subtypes for the subtype entity AIRPLANE. JET PLANE inherits the attributes and relationships of POWERED AIRPLANE. 123 . and AIRCRAFT. Normally two or three levels of nesting are adequate. AIRPLANE is a subtype of AIRCRAFT and a supertype of POWERED AIRPLANE and GLIDER.

and must only include relationships originating from that entity. but a specific relationship can only participate in a single arc. 124 . Example A BANK ACCOUNT either must be owned by an INDIVIDUAL or must be owned by a COMPANY.MODEL EXCLUSIVE RELATIONSHIPS Model two or more mutually exclusive relationships from the same entity using an arc. Exclusive Relationship Reading Rules "Each entityA either relationship1 entity1 or relationship2 entity2. The relationships in an arc must be either all mandatory. An arc belongs to a single entity. An entity may have multiple arcs." Example Each BANK ACCOUNT either must be owned by one and only one INDIVIDUAL or must be owned by one and only one COMPANY. or all optional. Arc Modelling Conventions • • • • The relationships in an arc frequently have the same relationship name. Use an arc to model this relationship.

Model Exclusive Relationships . which is not included in the arc.An Arc with Optional Dots A dot on the arc is used to signify that a relationship belongs to the arc.cont'd Choose between two conventions for drawing arcs. 125 . Drawing Convention 1 .An Arc without Dots Any relationship crossed by the arc belongs to the arc. Drawing Convention 2 . A break in the arc indicates a relationship.

We assign each company an identifying company number and track the company's name and address. 1. and 6' open trailers. Develop an E-R Model for the following information requirements. Our corporate sales group handles all that information separately. Most of our rental agreements are for individual customers. but a rental agreement can either be for an individual or for a company. or speculate on when the customer will return rented vehicles. we need to know the current odometer reading.EXERCISE 4-5 Develop an E-R Model. We log the current mileage just before we rent a truck. Each rental office has an office name like "Littleton Right-Way. we don't need to worry about any additional infor mation about a company. We have five different types of vehicles: 36' trucks. the gas tank capacity. For long moves. and directs transfers of vehicles from one rental office to another.780 vehicles including various types of trucks and trailers. 24' trucks. For all our vehicles. Each office is a home office for some of our vehicles. Each vehicle has a vehicle id. We don't take reservations. (Continued) 126 . For our trucks. "The Right-Way Rental Truck Company rents small moving trucks and trailers for local and one-way usage. and whether or not it has a working radio. and expiration date of its registration. 10' trucks. We have 34 7 rental offices across the western United States. We do rent a small percentage of our trucks to companies. We also keep each office's address." Each office also has a unique three-digit office number. customers really prefer a radio. we do have a vehicle type code. Yes. and each vehicle is based out of a single home office. and a license plate registration number. Each rental e office rents vehicles that they have in stock to customers ready to take possession of the vehicle. 8' covered trailers. and then again when it is returned. No. we need to track the last maintenance date. Our rental stock includes a total of 5. The central office oversees the vehicle distribution. We need to implement a system to track our rental agreements and our vehicl assignments. state of registration.

the anticipated duration of the rental. abandoned it. or didn't fully pay the bill. there isn't a mileage charge. Yes. We only allow a single individual or company for a given rental agreement. home phone.Exercise 4-5 . Of course for the trailers. the amount of the deposit paid. and expiration date. the drop-off rental office. address.cont'd "For each individual customer. number. just our rental agreement tracking and vehicle assignment functions. and we write a separate rental agreement for each vehicle. We like to keep track of all our customers. We also need to track the rental date. No. then we tag the customer as a poor risk. and won't rent to that customer again. and the quoted rate per mile. If a customer damaged a vehicle." 127 . the originating rental office. and driver's license state. we don't need to automate the financial side of our business. we do have customers rent two or more vehicles at the same time. we record the customer's name. the quoted daily rental rate. Each rental agreement is identified by the originating rental office number and a rental agreement number.

128 .MODEL DATA OVER TIME Add additional entities and relationships to the E-R model to accommodate historical data. Ask the User: • • • • • Is an audit trail required? Can attribute values change over time? Can relationships change over time? Do you need to query older data? Do you need to keep previous versions? Quick Note • Validate any requirements for storing historical data with the user. Storing unnecessary historical data can be costly.

closed. To model status values over time add a STATUS entity. or suspended. The law Firm wants to track the dates each contract was opened. was closed. The above CONTRACT entity supports a single current status value for CONTRACT. The UID of the STATUS entity is the related CONTRACT and the effective date.g. the contract's status (e. and they need to keep a description of the contract. Example A consulting firm needs to keep information about its contracts. and was suspended.cont'd Create an additional entity to track an attribute's values over time.) Initially the following CONTRACT entity was modelled. Quick Note • Use a single entity to record the values over time of multiple attributes associated with an entity (such as CONTRACT).Model Data Over Time . 129 . open. Each contract has a unique contract id.

cont'd Add a new entity to accommodate a relationship that may change over time.Model Data Over Time .) The following E-R Model will only track the current renter of an APARTMENT. Example An apartment owner wants to track the tenants in each of his apartments. Add the entity RENTAL HISTORY ENTRY to capture the values of the rental relationship over time. (The apartment only writes rental contracts with a single person. 130 . not multiple people.

EMPLOYMENT HISTORY ENTRY.cont'd An intersection entity is frequently used to track information about a relationship. Add an intersection entity. from date and to date). 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. By including the attribute from date in the UID of EMPLOYMENT HISTORY ENTRY. There is an M:M rela tionship between each member and each company. this model will track any multiple terms of employment at a single company by a single employee. to track each employee's employments over time and the dates of those employments. which changes over time. 131 .g.Model Data Over Time .

so we don't need to keep a due date. We will also be able to analyze our customers' movie preferences.EXERCISE 4-6 Model data over time. we really need to keep a history of all 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. 1." 132 . we would like to keep the rental date/time and the return date/time. Each time a customer rents a tape. We will also know how many times a particular tape has been used. All our tapes are due back the next day. Modify the Video Store E-R Model to accommodate the following additional requirements. and will then know when to retire each tape. "You know. Keeping this rental history will allow us to analyze the pattern of our rentals.

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 company worked for. So resolve each of the M:M relationships. The dates of the position seem to be an attribute of a relationship. For each person. and the dates the posit ion was held.MODEL COMPLEX RELATIONSHIPS Beware of a ring of M:M relationships. Which intersection entity are the dates of the position attributes of? All of them? None of them? 133 . Example Develop an E-R model for employment history. track the position held.

• Consider its mandatory relationships as candidates for inclusion in its UID.Model Complex Relationships . follow the rules of basic E-R Modelling to name the entity. and its UID.cont'd Model a relationship between three or more entities as an Intersection Entity with mandatory relationships with those entities. • For an intersection entity representing a complex relationship. and POSITION entities. its attributes. Use a single intersection entity called EMPLOYMENT HISTORY to model this relationship. Example A person's employment history is really a 3-way relationship between the PERSON. A complex relationship is a relationship between three or more entities. 134 . COMPANY. and to analyze and model its relationships. Quick Notes • An intersection entity for a complex relationship always has mandatory relationships back to the entities to which it relates.

Instead. SQL*TextRetrieval. Financials. a M:M relationship was initially modelled between the MEMBER entity and the COMPUTER PLATFORM entity. 1. we don't need to keep the specific version of each product. just the general product name. what we really need to know is which Oracle products (RDBMS. In the E-R Model for the Oracle User's Group from Exercise 3-10.EXERCISE 4-7 Model a complex relationship.) each member is using on which computer platforms. Revise that relationship based upon the following revised requirements. we really don't need to know what computer platform each member is using. Pro*C. CASE. Revised Requirements "No. etc. No." 135 . SQL*Forms.

Cases have to be identifiable by a unique number which appears on a list with every event date and event description.EXERCISE 4-8 Optional Exercise Develop a complex E-R Model. 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. domestic disputes." Our firm is made up of departments such as litigation. Develop an E-R Model for the following business. Jones). and homicide cases. and each case is assigned to a particular department for administrative purposes. (continued) 136 . 1. Attorneys are also assigned to a particular department. After a case has been closed. 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. T for Trial. and there must always be an event status for every case. My firm Bailey and Associates. "I am the senior partner in a large. it may be reopened at some future date. Events have special codes like O for Open. but we need to tie the new case number to the previous case number. civil suits. handles a wide variety of cases including traffic violations. but this is only for billing/payroll purposes since an attorney can work on cases in other departments. 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. diversified law firm. etcetera. L for Lost. We assign reopened cases new case numbers. homicide.

To elaborate on the varying roles that people can play. eyewitnesses (EW)." 137 . defendants (DE) and of course attorneys (AT).cont'd Attorneys can be party to multiple cases the same way a number of people can be party to multiple cases.The kinds of people that may be involved in cases include judges (JG). we have a murder case. there are four people who are parties to this case. and we're working for the defendant. In this context. and we'd like to know about all four. we are not tracking the attorney in terms of billing.Exercise 4-8 . but simply as party to a case. Jones may be a judge on one case and an eyewitness on another. assume that a given party can serve in different roles in different cases. We are only interested in keeping track of parties and the roles that they play in the context of a particular case. and there is. Thus.One attorney is assigned to the case. but a party can only serve in one role on a given case. and some kind of unique numbering system. a judge presiding over the case. For example. There is also an eyewitness. of course. For example. Parties should be identified by their name and date of birth.

A three day cruise will have only one stop. seven. for each cruise we also have different ports that we stop at. always on the second day of the cruise. No. Each year we put out a brochure with the information on each cruise that we offer. CA. Huh? Whenever we book a cabin under the manual system we remove the cabin from the availability board. FL. "I'm Phil Sales with Shipmore Cruises. Yes. What? The ports of Los Angeles. I guess we would need the age of each ship. Once passengers are booked. AK. each cruise will make port calls on different days out. then we can pay the travel agent who made the reservation their commission. as well as Anchorage. and we'll probably expand to 5 or 6 by 1995." 138 . Every cruise has a name. We vary ports depending on where the cruise originates. we can then price them. some people want to go on only the newer ships. no not boats. which has a certain length and number of ports. the Miami cruises go to the Bahamas and the Virgin Islands: and the Anchorage cruises make stops all through Alaska. 1. and they are travelling alone. a seven day cruise will stop at three ports. three. boats can fit onto ships. See. we don't need to worry about tonnage or draft or anything else about the ship. "Goodsky." and the new one. Yes. Registry is the country that it is registered with. then it's gonna cost 'em more. Each cruise also has a specific ship assigned to it. and so on. and Miami. and which cruise they pick will tell us which cabins are available. and we get a deposit from them. We've decided that our manual system of booking passengers onto our ships won't hold up when we get our new ship. unless it's not full and that passenger wants to share with someone else. So. Each one has the name "Goodsea. Develop an E-R Model for the following business. Depending upon the length of each cruise. eleven and fourteen day cruises. Once they choose from what is available." "Goodwind. so I guess that's why you're here. Passengers who sail with us will pick a given cruise. we'll have two ships. That depends on the number of people in the cabin and the "class" of the cabin." and each one has a specific passenger capacity and registry.huh? Oh. length in number of days .EXERCISE 4-9 Optional Exercise Develop a complex E-R Model. the LA cruises go down to Mexico ports like Cabo San Lucas and Mexico City. If the cabin can hold four people.

5 RELATIONAL DATABASE CONCEPTS 139 .

you will be able to: • • • Understand what a relational database is. Define what primary keys and foreign keys are. Understand the concept of data integrity. 140 .SECTION OBJECTIVES At the end of this section.

.e. A relational database must possess data integrity. 141 . Quick Notes • • Relational database tables are simple but disciplined. i. its data must be accurate and consistent. Example The relational table below contains employee data.RELATIONAL DATABASE OVERVIEW A relational database is a database that is perceived by the user as a collection of relations or two-dimensional tables.

Relational operations manipulate sets of data values. • A relational database can support a full set of relational operations. Quick Notes • The American National Standards Institute (ANSI) has established SQL as the standard language for operating upon relational databases. dept_no FROM employee WHERE dept_no = 10. SQL> 2 3 SELECT emp_no. Rela tional operations can be nested. EMP_NO -----100 210 LNAME ----SMITH BROWN FNAME ----JOHN JIM DEPT_NO ------10 10 The Structured Query Language (SQL) is used to manipulate relational databases. fname. use the following SQL statement.cont'd Relational databases are manipulated a set at a time rather than a record at a time.Relational Database Overview . 142 . lname. Tables can be operated on to create other tables. Example To select all employees who work in Department 10.

An entity's UID will map to a Primary Key in its corresponding table. Quick Notes • • • No duplicates are allowed in a Primary Key. and a primary key must be unique. Each row in the table is uniquely identified by its EMP_NO value. The primary key must be unique. Each table must have a primary key. 143 .PRIMARY KEYS A Primary Key (PK) is a column or set of columns that uniquely identifies each row in a table. Primary keys generally cannot be changed. Example The primary key for the EMPLOYEE table consists of the EMP_NO column.

Example The composite primary key for the ACCOUNT table consists of the combination of the BANK_NO and ACCOUNT_NO columns. Quick Note • The columns of a composite primary key must be unique in combination. Each row in the table is uniquely identified by its BANK NO and ACCOUNT NO values.cont'd A Primary Key consisting of multiple columns is called a Composite Primary Key or a Compound Primary Key. 144 . no duplicates are allowed. but in combination. The individual columns can have duplicates.Primary Keys .

Therefore EMP_NO must be defined as NOT NULL. Both BANK_NO and ACCOUNT_NO must be defined as NOT NULL. 145 .cont'd No part of a primary key may be NULL.Primary Keys . 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. Example EMP_NO is the primary key of the EMPLOYEE table.

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. the combination LNAME/ FNAME would probably not be a candidate key. 146 . Person names are not normally candidate keys because their uniqueness cannot be guaranteed. For example. in the EMPLOYEE Table. The other candidates become Alternate Keys (or Unique Keys). Secondary UIDs map to Alternate Keys. Example What are the candidate keys for the EMPLOYEE table? EMP_NO and PAYROLL_ID are candidate keys. Select one candidate key to be the Primary Key for the table. Example Quick Notes • • • All Candidate Keys must be Unique and NOT NULL.Primary Keys .

and refers to values in the DEPT_NO column of the DEPARTMENT Table. Example DEPT_NO is a FK in the EMPLOYEE Table. Quick Notes • • Foreign keys are used to join tables. Foreign keys are based on data values and are purely logical.FOREIGN KEYS A Foreign Key (FK) is a column or combination of columns in one table that refers to a primary key in the same or another table. .

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

If a Foreign Key is part of a Primary Key, that FK cannot be NULL. Example
In the ACCOUNT table, the FK BANK_NO must be NOT NULL because it is part of the PK.

DATA INTEGRITY
Data Integrity refers to the accuracy and consistency of the data. Data Integrity Constraints
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. Constraint Type Entity Integrity Referential Integrity Explanation No part of a primary key can be NULL. A foreign key must match an existing primary key value (or else be NULL). 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.

All data integrity constraints should be enforced by the DBMS or the application software. 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
A business has the following user-defined data integrity constraints.
An exempt employee is not paid for the tirst 5 hours of overtime worked. An employee in the Finance Department cannot have a title of: "Programmer". A Salesman's commission cannot exceed 50% of salary.

Quick Notes
• User-defined data integrity constraints can be set by management policy or be required by government laws. • • 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

Document a database design using Table Instance Charts. Translate an entity-relationship data model into a relational database design. Explain how Database Design fits into the Database Development Process. you will be able to: 1. . 2.SECTION OBJECTIVES At the end of this section. 3.

DATABASE DESIGN
Database Design is performed during the Design Stage of the System Development Cycle and is performed concurrently with Application Design.

Database Design - cont'd
Database Design is performed in two distinct activities. Database Design Activities
1. Map the E-R Model to relational tables to produce an initial design. 2. Refine the initial design to produce a complete database design.

Database Design Deliverable
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
Document each relational table on a Table Instance Chart. Table Instance Chart
Table Name: EMPLOYEE Column EMPNO Name Key Type Nulls/ Unique Sample 7369 Data 7902 7521 7698 7839 MARY SMITH CLERK ANALYST 17- DEC-80 800 03- DEC-81 3000 7902 7566 7698 20 50 30 30 10 NN, U NN NN NN NN PK FK1 FK2 FNAME LNAME JOB HIREDATE SAL COMM MGR DEPTNO

HENRY FORD SUE BOB BOB WARD BLAKE KING

SALESMAN 22- FEB-81 1250 6000 MANAGER

01- MAY-81 2850 10000 7839

PRESIDENT 17- NOV- 81 5000 5000

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. • • • • • Use NN for a column that must be defined NOT NULL. Use U for a column that must be unique. If multiple columns must be unique in combination, label them with a suffix, for example U1. Label a single column PK as NN, U. Label a multiple column PK as NN, U1 or possibly as NN, U1 and U.

Initial Database Design Overview - cont'd
This familiar Training Company E-R Model will be used to illustrate the activities of Initial Database Design. Training Company E-R Model

Map unique identifiers to primary keys. . Choose arc options.Initial Database Design Overview . 6. Map relationships to foreign keys. 4. Map attributes to columns and document sample data. Steps in Initial Database Design 1. 5.cont'd Follow a set of steps to map an E-R Model to a set of relational tables producing an initial database design. Choose subtype options. 2. 3. Map the simple entities to tables.

MAP SIMPLE ENTITIES Map each simple entity to a table. Record only the name of the table. the designer must decide how to map a supertype/subtype construct to tables. Name the table INSTRUCTOR. . Create a Table Instance Chart for the new table. The plural of the entity name is sometimes used because the table will contain a set of rows. In Step 6. Table Name: INSTRUCTOR Column Name Key Type Nulls/ Unique Sample Data Quick Notes • The table name should be easy to trace back to the entity name. Example Create a Table Instance Chart for the INSTRUCTOR entity. • A simple entity is not a subtype or supertype.

will Number be abbreviated as NO or NUM.MAP ATTRIBUTES TO COLUMNS Map each attribute to a column in its entity's table. and last name are mandatory attributes. Since id. NUMBER. Table Name: INSTRUCTOR Column Name Key Type Nulls/ Unique Sample Data NN NN NN INST_ID FNAME LNAME PHONENO For each attribute. first name. select a short but meaningful column name. For example. Use consistent abbreviations to avoid programmer and user confusion. Is it DEPTNO or DEPTNUM? • Short column names will reduce the time required for SQL command parsing. Quick Notes • • • Column names should be easily traced o the E-R model. Example Map the attributes of the entity INSTRUCTOR to columns in the INSTRUCTOR table. Avoid the use of SQL reserved words as column names . Map mandatory attributes to NOT NULL (NN) columns. . designate their columns as NOT NULL.for example.

Map Attributes to Columns . Example Document sample data for the columns of the INSTRUCTOR table.cont'd Document sample rows of data in each table's Table Instance Chart. Table Name: INSTRUCTOR Column Name Key Type Nulls/ Unique Sample Data 10 81 73 95 301 NANCY MARIA PETE KATHY ERIC HALL GONZALES CASSIDY ANDRONICA CAMPLIN 798-2251 756-4891 301-2291 483-9221 535-3166 NN NN NN INST_ID FNAME LNAME PHONENO Sources for Sample Data • • • • • User interview notes Entity Instance Charts Current computer systems Other analysis stage documentation Additional conversations with the user .

U 10 81 73 95 301 NN NANCY MARIA PETE KATHY ERIC NN HALL GONZALES CASSIDY ANDRONICA CAMPLIN 798-2251 756-4891 301-2291 483-9221 535-3166 LNAME PHONENO A key type of PK indicates a primary key column. Label the columns PK. so make the corresponding column INST_ID the PK of the INSTRUCTOR table. which includes multiple attributes to a composite PK. which are part of the entity's UID to PK column(s). Table Name: INSTRUCTOR Column Name INST_ID FNAME Key Type Nulls/ Unique Sample Data PK NN. Quick Notes • • All columns labeled PK must also be labeled NN and U. Label those columns NN and U1 . Map a UID.MAP UID'S TO PRIMARY KEYS Map any attribute(s). Example The attribute id is the UID of the entity INSTRUCTOR.

cont'd If an entity's UID includes a relationship. FK1 and FK2. Add sample data for the FK columns.Map UID's to Primary Keys . for example. and label the column(s) PK. • • Composite PK's must be unique in combination and should be labeled VI. Quick Notes • • Choose a unique name for each FK column. Label multiple column keys with the same suffix. Add two FK columns to the ENROLLMENT table for the PK of the COURSE table and the PK of the STUDENT table. add foreign key columns to the table and mark them as part of the primary key. and FK. Example The UID of the ENROLLMENT entity is composed of its relationship to COURSE and its relationship to STUDENT. If multiple FK columns exist in a table. use suffixes to distinguish between them. NN. .

Supply sample data. label the column NN. U 344 974 401 717 659 NN SQL*FORMS SQL*RW DB DESIGN DBA SOL*PLUS 1000 400 400 900 400 5 2 2 3 2 81 73 95 73 301 NAME FEE DUR INST_ID FK Go with the many! Quick Notes • • • Choose a unique name for the FK column.MAP RELATIONSHIPS TO FOREIGN KEYS For M:1 relationships. take the PK at the one end and put it in the table at the many end. . For must be relationships. Table Name: COURSE Column Name Key Type Nulls/ Unique Sample Data COURSE_ CODE PK NN. Example Take the PK INST_ID at the one end. and put it in the table COURSE at the many end. and label the column (s) FK.

these two columns already exist. Therefore.cont'd If the table's PK includes a foreign key.Map Relationships to Foreign Keys . Example The PK for the ENROLLMENT table included both the foreign key COURSE_CODE and the foreign key ST_ID. the FK columns to support the relationship may have been added in Step 3. and do not need to be added to support the relationships. .

cont'd For a mandatory 1:1 relationship. Table Name: PERSONAL COMPUTER Column INV_NUM CASE_TYPE Name Key Type Nulls/ Unique Sample 1045 Data 0437 1458 1223 1088 BABY AT BABY AT TOWER TOWER 150 200 220 220 4579 8731 4773 9978 4517 NN. MB_ID is the FK column added. U NN NN NN PK CHIP SPEED CHIP 386SX 25 386 33 MINITOWER 200 . The FK is labeled U to enforce the 1:1 relationship. Example Since the relationship from PERSONAL COMPUTER is mandatory. place the FK for the relationship in the PERSONAL_COMPUTER table and label it NOT NULL. U NN NN NN. U PK POWER_ MB_ID SUPPLY FK Table Name: MOTHERBOARD Column MB_ID PROC_ PROC_ COPROC_ Name Key Type Nulls/ Unique Sample 9978 Data 4517 4773 4579 8731 486 386 486 33 40 25 N Y N N Y NN. place the unique FK in the table at the mandatory end and use the NOT NULL constraint to enforce the mandatory condition.Map Relationships to Foreign Keys .

the FK column could also be placed either in the BERTH or SHIP table. The B_NUM column is added to the SHIP table. Example For the optional 1:1 relationship between BERTH and SHIP. place the FK in the table at either end of the relationship. . and labeled Unique to enforce the 1:1 relationship.Map Relationships to Foreign Keys .cont'd If a 1:1 relationship is optional in both directions.

A recursive FK will never be NOT NULL. Name the column MGR_ID to reflect the relationship.1. Name the FK column name to reflect the relationship. add an FK column to the EMPLOYEE table for each employee's manager. Example For this 1:M recursive relationship.cont'd For a 1:M recursive relationship. add a FK column to the single table. 1. This FK column will refer to values of the PK column.Map Relationships to Foreign Keys . . U 7450 5579 6714 9451 3040 NN MARY LESLIE JANET BILL JUAN NN SMITH STERNE GENTRY ABLE GOMEZ 7450 5579 7450 9451 FNAME LNAME MGR_ID FK Quick Notes • • • The FK column refers to a row in the same table.1. Table Name: EMPLOYEE Column Name Key Type Nulls/ Unique Sample Data EMP_ID PK NN.

This FK column will refer to values of the PK column.Map Relationships to Foreign Keys . add a unique column to the PERSON table. Table Name: PERSON Column Name Key Type Nulls/ Unique Sample Data 7450 5379 6714 9451 3040 MARY SMITH 9451 3040 5579 6714 PK NN. U1 NN NN FK U1 PERS_ID FNAME LNAME SPOUSE_ID SUSAN JONES JANET BILL JERRY GENTRY JONES JOHNSON Quick Notes • The combination of the PK and FK columns must always be unique in order to ensure the 1:1 relationship. . add a unique FK to the table.cont'd For a 1:1 recursive relationship. • • A recursive FK will never be NOT NULL 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. Example For this 1:1 recursive relationship.

REVIEW: MAPPING SIMPLE E-R MODELS TO TABLES Map a simple Entity-Relationship model to an initial database design using the following four steps: Steps 1. Document each table design on a Table Instance Chart. 3. 5. Map simple entities to tables. 2. Map relationships to Foreign Keys. Map attributes to columns and document sample data. 4. . Map UID's to Primary Keys.

Follow the first four steps of Initia l Database Design to map this E-R Model to a set of initial table designs. 1. .EXERCISE 6-1 Create an initial database design. Create sample data as required. Document your table designs on the supplied set of Table Instance Charts.

cont'd Table Name: Column Name Key Type Nulls/ Unique Sample Data Table Name: Column Name Key Type Nulls/ Unique Sample Data .Exercise 6-1 .

EXERCISE 6-2
Create an initial database design.
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
Create an initial database design.
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 Create an initial database design.
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 Follow the following additional steps to map a complex Entity-Relationship Model to an initial database design. Additional Steps 5 6 Choose Arc Options Choose Subtype Options .

CHOOSE ARC OPTIONS Arcs represent a kind of multiple alternative foreign key. 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. . Choose between two alternative designs for mapping arcs to foreign keys. Use either an Explicit Arc Design or a Generic Arc Design to add these multiple alternative foreign keys. and corresponding FK columns must be added to the OFFICE_SUITE table. The OFFICE SUITE entity has an arc across the many ends of three relationships. • Arcs can only span relationship ends that are either all mandatory or all optional. Alternative Designs • • Explicit Arc Design Generic Arc Design Example This E-R Model will map to four tables.

• Application software must enforce relationship exclusivity between the foreign keys. Example The following E-R Model contains four simple entities. INDIV_ID. PARTNER_CODE. The arc spans the many end of three relationships. and will be mapped to four separate tables. Using an Explicit Arc Design. and COMPANY_ID could all have a different column format. Therefore. Table Name: OFFICE_SUITE Column Name BLDG_ ID SUITE_NUM INDIV_I PARTNER_ CODE D Key Type PK PK NN. create a FK column for each rela tionship. . U1 Sample Data 1024 512 977 3041 2371 Quick Notes • The Explicit Arc Design will support multiple Foreign keys with different formats. U1 101 210 144 510 430 54532 10844 54101 30045 A4431 FK1 FK2 FK3 COMPANY_ NUMBER Nulls/ Unique NN.Choose Arc Options . FKs must be added to the OFFICE_SUITE table.cont'd The Explicit Arc Design creates a foreign key column for each relationship included in the arc. For example.

J for INDIVIDUAL. U1 1111 2111 14 510 430 FK NN 30045 A4431 54532 10844 541111 NN 1 P 1 C C Quick Notes • • If the relationships under the arc are mandatory.Choose Arc Options . add the to the OFFICE_SUITE table. create a single foreign key column.cont'd The Generic Arc Design creates a single foreign key column and one relationship flag column for the arc. The foreign keys must share the same format for all referenced tables. U1 11124 512 977 MM 2371 PK NN. and C for COMPANY. Table Name: OFFICE_SUITE Column Name Key Type Nulls/ Unique Sample Data BLDG_ID SUITE_NUM RENTER _ID RENTER_ TYPE PK NN. P for PARTNERSHIP. Using the Generic Arc Design. make both added columns NOT NULL. Example Again. For example.one for each entity. and add a type column to indicate which of the three tables is referenced by the FK column in each row. Since the relationships are exclusive. create four separate tables for this E-R Model . Since the arc spans the many end of the relationships. only one FK value will exist for each row in the table. .

1 Using an Explicit Arc Design. Document your design on the provided Table Instance Charts. develop a table design for this Entity-Relationship Model. Table Name: STUDENT Column Name Key Type Nulls/ Unique Sample Data .EXERCISE 6-5 Map arc structures to tables.

Exercise 6-5 .cont'd Table Name: COUNTY Column Name Key Type Nulls/ Unique Sample Data Table Name: OTHER STATE Column Name Key Type Nulls/ Unique Sample Data Table Name: FOREIGN COUNTRY Column Name Key Type Nulls/ Unique Sample Data .

Document your design on the provided Table Instance Charts.cont'd 2 Using a Generic Arc design.Exercise 6-5 . develop a table design for this Entity-Relationship Model. Table Name: STUDENT Column Name Key Type Nulls/ Unique Sample Data .

cont'd Table Name: COUNTY Column Name Key Type Nulls/ Unique Sample Data Table Name: OTHER STATE Column Name Key Type Nulls/ Unique Sample Data Table Name: FOREIGN COUNTRY Column Name Key Type Nulls/ Unique Sample Data .Exercise 6-5 .

EXEMPT EMPLOYEE. E-4) Example In the following supertype/subtype construct. p. Subtype Table Mapping Options • • • Single Table Design Separate Tables Design Arc Implementation (see Appendix E. . the EMPLOYEE. and NON-EXEMPT EMPLOYEE entities may be mapped to one. depending upon the subtype table mapping option selected.CHOOSE SUBTYPE OPTIONS Choose from three options for mapping subtypes to tables. two. or three tables.

cont'd Option 1 . Use a single table design when the subtypes have few subtype-specific attributes and relationships. FK columns for each of the subtype's relationships. The single table will contain instances of all sub types. a TYPE column to identify which subtype each row belongs to. a column for each of the supertype's attributes. FK columns for each of the supertype's relationships.Choose Subtype Options . Create • • • • • • single table for the supertype.Single Table Subtype Design Map the subtypes onto a single table for the supertype. . a column for each of the subtype's attributes.

50 6.50 10.75 12.15 15.Single Table Subtype Design Example Map the EMPLOYEE supertype and its subtypes onto a single EMPLOYEE table. Table Name: EMPLOYEE Column Name BADGE_ NUM Key Type Sample Data PK NN JAMES KAREN MICHAEL MARIA TERRY JOE JULIA HARRY JOSE CLYDE NN JOYCE NN E 29000 25000 42700 44050 38450 8.00 16. U DIDONATO E WEINTER PENA SMITH SMITH WALKER KAPLIN GOMEZ JONES E E E NF NE NE NE NE .75 201 150 201 201 180 4579 6631 1190 370 800 7147 6794 941 1020 3500 FNAME LNAME EMP_ TYPE EE_ SALARY NE_ HOURLY_ RATE NE_ _ RATE NE_ _NUM FK1 FK2 NN 40 35 40 30 35 35 30 45 30 45 DEPT_ CODE OVERTIME UNION Nulls/ Unique NN.50 12.75 11.Choose Subtype Options .00 9.50 18.cont'd Option 1 .

Single Table Subtype Design The columns of the EMPLOYEE table are derived from the attributes and relationships of the supertype and all its subtypes. .cont'd Option 1 . Entity Type Supertype Subtype Columns for Attribtues BADGE_NUM FNAME LNAME EE_SALARY.Choose Subtype Options . NE_HOURLY_RATE. The EMP_TYPE column was added to the EMPLOYEE table for this purpose. NE_OVERTIME_RATE FK Columns for Relationships DEPT_CODE NE_UNION_NUM Quick Note • The single table subtype design requires that a new type column be created to identify each row's subtype.

The subtypes can be accessed and modified using views. Design Advantages • • Access to the supertype is straightforward.Single Table Subtype Design Use the Single Table Subtype Design when there are few subtype-specific attributes and relationships. Design Disadvantages • • Subtype NOT NULL requirements cannot be enforced at the database level.cont'd Option 1 . Application logic will have to cater to different sets of attributes. depending on TYPE. .Choose Subtype Options .

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. Create • • • • • a table for each subtype.cont'd Option 2 .Separate Tables Subtype Design Map the subtypes onto separate tables . a column for each attribute of a subtype in that subtype's table.one for each subtype. Each table will contain only instances of that subtype.Choose Subtype Options . an FK column for each relationship to a subtype in that subtype's table.

one for each subtype. Table Name: EXEMPT_EMPLOYEE Column Name BADGE_NUM FNAME Key Type Nulls/ Unique Sample Data PK NN.Choose Subtype Options .Separate Tables Subtype Design Example Map the EMPLOYEE supertype onto two tables . U 4579 6631 1190 370 800 NN JAMES KAREN MICHAEL MARIA TERRY NN JOYCE NN 29000 LNAME SALARY DEPT_CODE FK NN 40 35 40 30 35 DIDONATO 25000 WEINER PENA SMITH 42700 44050 38450 .cont'd Option 2 . First create a separate table for the EXEMPT EMPLOYEE subtype.

Separate Tables Subtype Design Example . U 201 150 201 201 180 35 30 45 30 45 .15 15.75 NN.cont'd Option 2 . Table Name: NON_EXEMPT_EMPLOYEE Column Name BADGE_ NUM FNAME LNAME HOURLY_ RATE OT_RATE UNION_ NUM FK1 NN NN NN NN NN FK2 NN DEPT_ CODE Key Type PK Nulls/ Unique Sample Data 7147 6794 941 1020 3500 JOE JULIA HARRY JOSE CLYDE SMITH WALKER KAPLIN GOMEZ JONES 8.50 18.Choose Subtype Options .75 12.50 12.50 10.50 6.75 11.cont'd Then create a separate table for the NON-EXEMPT EMPLOYEE subtype.00 9.00 16.

Application program code must be specific to the individual subtype tables.Separate Tables Subtype Design Use a Separate Tables Subtype Design when there are many subtype-specific attributes or relationships. Application logic does not require checks for subtypes. . Maintenance of UID's across subtypes is difficult to imple ment.Choose Subtype Options . Views that join the two tables are display only. Design Advantages • • The subtype's attribute optionality is enforced at the database level. Design Disadvantages • • • • Access to the supertype requires the UNION operator or a view with the UNION operator.cont'd Option 2 .

EXERCISE 6-6 Map subtypes to tables. develop a table design for this Entity-Relationship Model. Sample data is not required. Table Name : PRODUCT Table Name: ORDER . Document your design on the supplied Table Instance Charts. 1 Using a Single Table Subtype Design.

cont'd Table Name: ORDER_LINE Column Name Key Type Nulls/ Unique Sample Data .Exercise 6-6 .

Table Name: PRODUCT Table Name: ORDER .Exercise 6-6 . Document your design on the supplied Table Instance Charts.cont'd 2 Using a Separate Tables Subtype Design. Sample data is not required. develop a table design for this Entity-Relationship Model.

cont'd Table Name: PRODUCT_ORDER_LINE Column Name Key Type Nulls/ Unique Sample Data Table Name: SERVICE_ORDER_LINE Column Name Key Type Nulls/ Unique Sample Data .Exercise 6-6 .

Choose arc options. Steps for Mapping Entity-Relationship Models 1 2 3 4 5 6 Map simple entities to tables. Map attributes to columns and document sample data. Map relationships to Foreign Keys. Choose subtype options. . Document an initial database design on Table Instance Charts.REVIEW: INITIAL DATABASE DESIGN Map an Entity-Relationship Model to an initial database design using the following interrelated steps. Map UID's to Primary Keys.

7 TABLE NORMALIZATION .

SECTION OBJECTIVES At the end of this section. you will be able to: 1 2 3 Define normalization and explain its benefits. Place tables in Third Normal Form. Explain how conceptual data modelling rules ensure normalized tables. .

Data redundancy causes integrity problems. the whole key. No non-key column may be functionally dependent on another non-key column. and nothing but the key. twodimensional tables. Update and delete transactions may not be consistently applied to all copies of the data causing inconsistencies in the data. Third Normal Form (3NF) The table must be 2NF. relationships." Why normalize tables? • • Normalization minimizes data redundancy. Normal Form Rule Description First Normal Form (1NF) The table must be expressed as a set of unordered. "Each non-primary key value MUST be dependent on the key. . • Higher normal forms are not widely used. The table cannot contain repeating groups. Quick Notes • Third normal form is the generally accepted goal for a database design that eliminates redundancy. Every non-key column must be dependent on all parts of the primary key. • Normalization helps identify missing entities. and tables. Second Normal Form (2NF) The table must be in INF.NORMALIZE TABLES Categorize tables according to their degree of normalization. Unnormalized data is redundant.

one for each ORDER_ID. Three variable length records are shown .00 10. ITEM DESCRIPTION.00 65. QUANTITY.75 5. First Normal Form prohibits repeating groups. and PRICE.00 65. Example Consider the following set of data. Why is this data unnormalized? ORDER ID 2301 6/23 DATE CUSTOMER ID 101 CUSTOMER NAME Volleyrite IL STATE ITEM NUM 3786 4011 9132 2302 2303 6/25 6/26 107 110 Herman's We-R-Sports WI MI 5794 4011 3141 ITEM DESCRIP net racket 3-pack 6-pack racket cover 3 6 8 4 2 2 QUANTITY PRIC E 35.00 It contains a repeating group of ITEM NUM.00 4.RECOGNIZE UNNORMALIZED DATA Unnormalized data does not comply with any of the rules of normalization. .

00 Remove the repeating group of ITEM NUM. Create a new ORDERJTEM table with ORDER ID and the repeating group.00 65. Example Convert the following set of unnormalized data to First Normal Form. Create a new table with the PK of the base table and the repeating group. and PRICE. QUA NTITY.75 5.00 10.00 10.00 65. ORDER ID 2301 DATE CUSTOMER ID 101 CUSTOMER NAME Volleyrite STATE ITEM NUM 3786 4011 9132 5794 ITEM DESCRIP net racket 3-pack 6-pack QUANTITY PRICE 6/23 1L 2302 6/25 107 Herman's Wl 3 6 8 4 35.75 5.00 2303 6/26 110 We-R-Sports MI 4011 3141 racket cover 2 2 65.00 4. Steps 1 2 Remove the repeating group from the base table. ORDER ORDER ID PK 2301 2302 2303 ORDER ID PK.FK 2301 2301 2301 2302 2303 2303 DATE 6/23 6/25 6/26 CUSTOMER ID 101 107 110 CUSTOMER NAME Volleyrite Herman's We-R-Sports ITEM DESCRIP Net racket 3-pack 6-pack racket cover QUANTITY 3 6 8 4 2 2 STATE IL WI MI PRICE 35.00 ORDER ITEM ITEM NUM PK 3786 4011 9132 5794 4011 3141 .00 4.CONVERT TO FIRST NORMAL FORM Remove any repeating groups.00 65. The PK of the remaining table is ORDER ID. ITEM DESCRIPTION.

Therefore.CONVERT TO SECOND NORMAL FORM Remove any non-key columns that are not dependent upon the table's entire primary key. . Create a second table with those columns and the column(s) from the PK that they are dependent upon. Steps 1 2 3 Determine which non-key columns are not dependent upon the table's entire primary key. Any value of ORDERJD uniquely determines a single value of each column. all columns are dependent on the PK ORDERJD. the table is not in 2NF. Any table with a single column primary key is automatically in 2NF. Quick Notes • • If each column is not dependent upon the entire primary key. Example Put the following table in2NF. ORDER ORDER ID PK 2301 2302 2303 6/23 6/25 6/26 101 107 110 Volleyrite Herman's We-R-Sports IL WI MI DATE CUSTOMER ID CUSTOMER NAME STATE The ORDER table is already in 2NF. Remove those columns from the base table.

00 65.00 4.75 5. but not dependent upon ORDER ID. Create an ITEM table with those columns and the column from the PK that they are dependent upon.00 10.00 10.FK 3786 4011 9132 5794 4011 3141 3 6 8 4 2 2 QUANTITY ITEM ITEM NUM PK 3786 4011 9132 5794 3141 DESCRIPTION PRICE net racket 3-pack 6-pack cover 35. To convert the table to 2NF. ORDER ITEM ORDER ID ITEM NUM PK. Example Put the following table in 2NF.Convert to Second Normal Form .00 ITEM DESCRIP QUANTITY PRICE The ORDERJTEM table is not in 2NF since PRICE and DESCRIPTION are dependent upon ITEM NUM.00 4. ORDER ITEM ORDER ID PK. remove any partially dependent columns.FK 2301 2301 2301 2302 2303 2303 ITEM NUM PK.75 5.00 65.cont'd Remove any non-key columns that are not dependent upon the table's entire primary key.FK 2301 2301 2301 2302 2303 2303 PK 3786 4011 9132 5794 4011 3141 Net racket 3-pack 6-pack racket cover 3 6 8 4 2 2 35.00 65.00 .

2 Remove those columns from the base table. Move the dependent non-key columns with the non-key column they depend upon Into a new CUSTOMER table. Steps 1 2 3 Determine which columns are dependent upon another non-key column. Therefore. CUSTOMER ID is not the PK.CONVERT TO THIRD NORMAL FORM Remove any columns that are dependent upon another non-key column. the ORDER table is not in 3NF. Example Put the ORDER table in Third Normal Form. ORDER ORDER ID PK 2301 2302 2303 6/23 6/25 6/26 101 107 110 Volleyrite Herman's We-R-Sports IL WI MI DATE CUSTOMER ID CUSTOMER NAME STATE CUSTOMER NAME and STATE are dependent upon CUSTOMER ID. Create a second table with those columns and the non-key column that they are dependent upon. . ORDER ORDER ID PK 2301 2302 2303 6/23 6/25 6/26 DATE CUSTOMER ID FK 101 107 110 PK 101 107 110 Volleyrite Herman's We-R-Sports IL WI MI CUSTOMER CUSTOMER ID CUSTOMER NAME STATE Quick Note • A table is in Third Normal Form if no non-key column is functionally dependent upon another non-key column.

.00 10. and nothing but the key. Example Consider the ITEM table. The ORDERJTEM table is in 3NF. Is it in 3NF? Why or why not? ORDER ITEM ORDER ID PK.cont'd No non-key column can be functionally dependent upon another non-key column. Is it in 3NF? Why or why not? ITEM ITEM NUM PK 3786 4011 9132 5794 3141 net racket 3-pack 6-pack cover 35. and nothing but the key.00 65. The ITEM table is in 3NF.00 DESCRIPTION PRICE All non-key attributes are dependent on the key.Convert to Third Normal Form .75 5.00 4.FK 3786 4011 9132 5794 4011 3141 3 6 8 4 2 2 QUANTITY All non-key attributes are dependent on the key. Example Consider the ORDER JTEM table. the whole key. the whole key.FK 2301 2301 2301 2302 2303 2303 ITEM NUM PK.

Three variable length records are shown-one for each EMP_NUM. Put the following data into First. EMPLOYEE First Normal Form Table Name: Column Name Key Type Nulls/ Unique Sample Data Table Name: Column Name Key Type Nulls/ Unique Sample Data . and Third Normal Form on the supplied Table Instance Charts.EXERCISE 7-1 Normalize a set of data. 1. Second.

Exercise 7-1 .cont'd Second Normal Form 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 Third Normal Form 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 .

cont'd Table Name: Column Name Key Type Nulls/ Unique Sample Data .Exercise 7-1 .cont'd Third Normal Form .

Example Is the entity CLIENT in 1NF? If not.NORMALIZE DURING DATA MODELLING Ensure a 3NF table design by following the rules of data modelling. therefore the entity CLIENT is not in 1NF. Corresponding Data Modelling Rule • All attributes must be single -valued. Create an additional entity CONTACT with a M:1 relationship to CLIENT. . Create an additional entity and 1 :M relationship to ensure 1 NF. First Normal Form Rule • A table must contain no repeating groups. how could it be converted to 1NF? The attribute date contacted has multiple values.

cont'd Validate each attribute's dependence upon its entity's entire UID. . 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. Move the attribute and place it where it depends upon the UID of it's entity.Normalize During Data Modelling . Second Normal Form Rule • Every non-key column must be dependent upon all parts of the primary key. Corresponding Data Modelling Rule • An attribute must be dependent upon its entity's entire unique identifier. It is dependent upon the UID of BANK.

Normalize During Data Modelling . 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.cont'd Verify attribute placement to ensure a normalized table design. Third Normal Form Rule • No non-key column can be functionally dependent upon another non-key column. Corresponding Data Modelling Rule • No non-UID attribute can be dependent upon another non-UID attribute. Create another entity called CUSTOMER with a UID of customer id. . and place the attributes accordingly.

8 FURTHER DATABASE DESIGN .

you will be able to: 1. 5. Evaluate table denormalization. 2. 4. Specify referential integrity constraints. Understand database views.SECTION OBJECTIVES At the end of this section. 3. . Design indexes. Work with your DBA to plan physical storage usage.

FURTHER DATABASE DESIGN Review the default table design against the application module's requirements. Denormalize the database design. Plan physical storage usage. Design indexes. Activities • • • • • Define referential integrity constraints. Establish views. . and refine and extend the initial design to produce a complete database design.

Delete Constraint • What happens if a row containing a referenced primary key is deleted? Update Constraint • What happens if a referenced primary'key is updated? * * Only an issue if the PK is updateable in the first place. Use referential integrity constraints to specify how referential integrity is to be maintained. .SPECIFY REFERENTIAL INTEGRITY A foreign key column value must match an existing primary key column value (or else be NULL).

Specify Referential Integrity .NO for which employees work is deleted from the DEPARTMENT table? Table Name: EMPLOYEE Table Name: DEPARTMENT Option CASCADE RESTRICTED NULLIFY Explanation of Constraint The deletion should cascade to the matching employees. The foreign key should be nullified (valid only for FK's allowing NULLs) when the referenced PK is deleted. The deletion should be restricted to only DEPARTMENTS without employees. or NULLIFY (only if NULLs are allowed) Example Consider the EMPLOYEE and DEPARTMENT tables.cont'd Specify a Delete Constraint to define what should happen if a row containing a referenced primary key is deleted. RESTRICTED. The matching EMPLOYEE rows should also be deleted. Options: CASCADE. What should happen if a DEPT. .

) Options: CASCADE. RESTRICTED.Specify Referential Integrity . or NULLIFY (only ifNULLs are allowed) Example What should happen if a DEPT_NO for which employees work is changed to another DEPT_NO? Table Name: EMPLOYEE Table Name: DEPARTMENT Option CASCADE Explanation of Constraint The update should cascade to the matching employees. 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 .cont'd Specify an Update Constraint to define what should happen when a referenced primary key is updated. (The Update Rule is only meaningful if the PK is updateable. The matching EMPLOYEE rows should also be updated to reflect the new PK value. RESTRICTED NULLIFY The update should be restricted to only DEPARTMENTS without employees.

Table Instance Chart Table Name: COURSE Physical Representations COURSE Table I_COURSES_PRIME Index (Unique) I_COURSES_2 Index (Not Unique) Design Indexes .cont'd .one or more columns from that table. Database Design .

778-V6.0 ORACLE RDBMS Database Administrator's Guide Version 6. referenced in the WHERE clause of a SQL statement if the column is not modified For further information on the subject see: SQL Language Reference Manual.Use indexes to significantly improve data access time.0. Indexes • • • • Provide quick access to rows of data and avoid full table scans Facilitate table joins Ensure uniqueness of a value if defined as unique Are used automatically when.0 .3601-V6.

MAY-9 28-JUL-91 05. Create a composite key called I_ENROLL_PRIME on both columns.91 28-JUL-91 28-JUL-91 21.U1 STJD PK.MAY-91 5014 05.91 Data 05-SEP-91 14-JUN.MAY-91 DATE_ COMPLETED 19-AUG.cont'd A concatenated index is an index created on a group of columns in a single table.91 5013 08.MAY-91 GRADE A B A COURSE_ CODE 344 401 717 717 401 ST_ID 47592 15402 51394 94572 51394 I_ENROLL_PRIME Index (Unique) COURSE_ CODE 344 401 401 717 717 ST_ID ROW ID 47592 15402 51394 51394 5011 5012 5014 5015 94572 5013 .MAY-91 GRADE COURSE_ CODE PK.U1 47592 15402 51394 94572 51394 --A B A 344 401 717 717 401 Physical Tables ENROLLMENT Table ROW ENROLL_ ID DATE 5011 20-JUL-91 5012 05-SEP-91 5015 14-J UN.FK1 NN.91 28-JUL-91 08. Example The ENROLLMENT table has a composite PK of COURSE_CODE and ST_ID. Table Design Table Name: ENROLLMENT Column ENROLL_ DATE_ Name DATE COMPLETEC Key Type Nulls/ NN Unique Sample 20-JUL-91 19-AUG.MAY-9 21. Map a composite key to a concatenated index.Design Indexes .FK2 NN.

3601-V6. Build Indexes for • • Primary keys (unique indexes) Foreign keys (generally non-unique indexes) Consider indexing • • • Alternate keys (unique indexes) Any critical non-key columns used in WHERE clauses Any search keys Indexes add storage and update overhead. 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. indexes are not used by the RDBMS.0 ORACLE RDBMS Performance Tuning Manual 5317-V6.0 .0.Design Indexes . Be aware that under certain conditions. For further information on the subject see: ORACLE RDBMS Database Administrator's Guide Version 6.cont'd Use indexes to implement keys and to support application access requirements.

cont'd A View can restrict what the user. . designer. presenting tables to users in any form. pre-packaging complex queries. A view can be thought of as a predefined window onto the database. A view is defined by a SELECT statement that is named and stored in the ORACLE Data Dictionary. providing referential integrity. pre-joined base tables in SQL*Forms. Quick Notes • • A view has no data of its own and merely relays informa tion from underlying tables. producing rapid prototypes. Examples A View of the EMP table could be used to restrict users from seeing the employees' salaries. • A view is queried as if it were a table.ESTABLISH VIEWS Establish database views to meet application access requirements Views can be used for: • • • • • • • restricting access. Establish Views . or tool sees. checking data input.

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. .A view can be used to present normalized data in a denormalized form. Example Following the rules of normalization.

Establish Views . INSERT. UPDATE. and may cause query optimization to be slower. and DELETE are restricted. it is possible to add rows not visible through the view unless the WITH CHECK OPTION is specified. and DELETE commands have no limitations. • • For multi-table views with virtual columns.cont'd Use views with caution. View Limitations • For a view based upon a single table. . When accessing tables through a view. Access through a view is slower because it requires an extra access to the data dictionary. the SQL INSERT. UPDATE.

quick response time. . Denormalization can cause data inconsistency problems. Denormalization may be a solution for transactions with performance requirements such as: • • • high throughput. especially adding or changing the index structure. Beware of Denormalization! • • Be extremely reluctant to denormalize the default table design.DENORMALIZE THE DATABASE DESIGN Always start with tables in Third Normal Form. Consider all other options prior to denormalization. high frequency.

The ACCOUNT table and the BANK table are combined on BANK_NUM.Denormalize the Database Design . Example Consider the ACCOUNT and BANK tables. .cont'd Combining tables is the most common form of denormalization. If high-volume account queries always access the bank name. a combined table might be worth the data redundancy.

Create a view for each CODE_TYPE. Combine all the tables into a single table with an additional column.cont'd Individual codes tables may be combined into a reference table for validating and decoding coded values for an entire application system. CODE_TYPE.Denormalize the Database Design . that defines which set of values the code belongs to. 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.

cont'd Establish a companion CODE_TYPE table for validating code description lengths. . CODE_TYPE and LENGTH. 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. The table contains two columns. Set up a CODE_TYPE table for validating the length of the descriptions. LENGTH is the maximum description length for each CODE_TYPE.Denormalize the Database Design .

a repeating group of definite size. Represent vector data as either a set of rows or a set of columns.cont'd A vector is a one-dimensional array with a fixed number of values . Column-Wise Table Design (3NF) Row -Wise Table Design .Denormalize the Database Design .

SUM.cont'd Choose the table design for vector data based upon the functional access requirements. e. The storage space requirement is lower. Output reports showing all values horizontally are easy to produce.Denormalize the Database Design .g. .. Advantages of a Column-Wise Design • • SQL group functions act on columns. Changes in the vector length can be easily accommodated. All values can be inserted with a single INSERT statement. Advantages of a Row -Wise Design • • • • On the input form. all data values can appear on a single line. AVG.

Sales data is updated weekly. Maintaining sales quota data by region would be desirable. . He frequently queries the total sales quota and sales-to-date for his region.cont'd Reconsider storing derived data in light of the functional access requirements and the capabilities of the software development tools. and maintaining sales-to-date might also be desirable.Denormalize the Database Design . Example A regional sales manager has 200 salespersons working for him. The sales quotas are established quarterly.

estimate the amount of disk space required. • Define storage allocation parameters based upon the expected patterns of data update and growth. For further information on the subject see: ORACLE RDBMS Database Administrator's Guide Version 6.3601-V6. Considerations • • For each table and index.PLAN PHYSICAL STORAGE USAGE Work with the Database Administrator to plan the physical placement of the database tables and indexes.0 . Decide on the placement of tables and indexes on logically separate tablespaces and physically separate disks.0.

Choose arc options. Denormalize the database design. . Plan physical storage usage. Map unique identifiers to primary keys. Add system support tables. Choose subtype options. Establish views. Activity 2: Further Database Design • • • • • • Define referential integrity constraints. Activity 1: Initial Database Design • • • • • • Map the simple entities to tables.SUMMARY: DATABASE DESIGN Database Design is the process of mapping the information requirements reflected in an Entity-Relationship Model into a relational database. Design indexes. Map attributes to columns and document sample data. Map relationships to foreign keys.

SUMMARY: DATABASE DEVELOPMENT This course has covered the first two steps of the top-down database development process. . The last step is Database Build.

create physical relational database tables to implement the database design. SAL NUMBER(7. CHAR(20) NOT NULL. COMM NUMBER(7. For further information on the subject attend: Introduction to ORACLE for Developers . SQL> 2 3 4 CREATE TABLE DEPARTMENT DEPTNO DNAME LOC NUMBER (2) NOT NULL PRIMARY KEY. LNAME CHAR(15) NOT NULL.DATABASE BUILD OVERVIEW In Database Build. DEPTNO NUMBER(2) NOT NULL REFERENCES DEPARTMENT (DEPTNO) ). FNAME CHAR (15) NOT NULL.2).2). Example The following Structured Query Language (SQL) statements will create the DEPARTMENT and EMPLOYEE tables. MGR CHAR(4) REFERENCES EMPLOYEE(EMPNO). JOB CHAR(9). SQL> 2 3 4 5 6 7 8 9 10 CREATE TABLE EMPLOYEE EMPNO NUMBER (5) NOT NULL PRIMARY KEY. HIREDATE DATE NOT NULL. CHAR (15) NOT NULL ) .

Sign up to vote on this title
UsefulNot useful