P. 1
Data Modeling

Data Modeling

|Views: 2,805|Likes:

More info:

Published by: Manikandan Suriyanarayanan on May 24, 2011
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less

03/02/2013

pdf

text

original

Sections

  • COURSE OBJECTIVES
  • ORACLE OVERVIEW
  • ORACLE'S CASE APPROACH
  • CASE*METHOD DEVELOPMENT CYCLE
  • SECTION OBJECTIVES
  • DATABASE DEVELOPMENT PROCESS
  • BUSINESS INFORMATION REQUIREMENTS
  • CONCEPTUAL DATA MODELLING OVERVIEW
  • DATABASE DESIGN OVERVIEW
  • DATABASE BUILD OVERVIEW
  • DATABASE AND APPLICATION DEVELOPMENT
  • CONCEPTUAL DATA MODELLING
  • ENTITIES
  • IDENTIFY AND MODEL ENTITIES
  • EXERCISE 3-1
  • RELATIONSHIPS
  • EXERCISE 3-2
  • EXERCISE 3-3
  • EXERCISE 3-4
  • RELATIONSHIP TYPES
  • Relationship Types
  • USING A RELATIONSHIP MATRIX
  • ANALYZE AND MODEL RELATIONSHIPS
  • DETERMINE A RELATIONSHIP'S EXISTENCE
  • NAME THE RELATIONSHIP
  • DETERMINE RELATIONSHIP'S OPTIONALITY
  • DETERMINE RELATIONSHIP'S DEGREE
  • VALIDATE THE RELATIONSHIP
  • EXERCISE 3-5
  • EXERCISE 3-6
  • LAY OUT THE E-R DIAGRAM
  • ATTRIBUTES
  • DISTINGUISH ATTRIBUTES AND ENTITIES
  • ATTRIBUTE OPTIONALITY
  • IDENTIFY ATTRIBUTES
  • EXERCISE 3-7
  • ASSIGN UNIQUE IDENTIFIERS
  • EXERCISE 3-8
  • EXERCISE 3-9
  • EXERCISE 3-10
  • REVIEW: BASIC CONCEPTUAL DATA MODELLING
  • NORMALIZE THE DATA MODEL
  • EXERCISE 4-1
  • RESOLVE M:M RELATIONSHIPS
  • EXERCISE 4-2
  • EXERCISE 4-3
  • MODEL HIERARCHICAL DATA
  • MODEL RECURSIVE RELATIONSHIPS
  • EXERCISE 4-4
  • MODEL ROLES WITH RELATIONSHIPS
  • MODEL SUBTYPES
  • MODEL EXCLUSIVE RELATIONSHIPS
  • EXERCISE 4-5
  • MODEL DATA OVER TIME
  • EXERCISE 4-6
  • MODEL COMPLEX RELATIONSHIPS
  • EXERCISE 4-7
  • EXERCISE 4-8
  • EXERCISE 4-9
  • RELATIONAL DATABASE OVERVIEW
  • PRIMARY KEYS
  • FOREIGN KEYS
  • DATA INTEGRITY
  • INITIAL DATABASE DESIGN
  • DATABASE DESIGN
  • INITIAL DATABASE DESIGN OVERVIEW
  • MAP SIMPLE ENTITIES
  • MAP ATTRIBUTES TO COLUMNS
  • MAP UID'S TO PRIMARY KEYS
  • MAP RELATIONSHIPS TO FOREIGN KEYS
  • REVIEW: MAPPING SIMPLE E-R MODELS TO TABLES
  • EXERCISE 6-1
  • EXERCISE 6-2
  • EXERCISE 6-3
  • EXERCISE 6-4
  • MAP COMPLEX E-R MODELS TO TABLES
  • EXERCISE 6-5
  • CHOOSE SUBTYPE OPTIONS
  • EXERCISE 6-6
  • REVIEW: INITIAL DATABASE DESIGN
  • TABLE NORMALIZATION
  • NORMALIZE TABLES
  • Why normalize tables?
  • RECOGNIZE UNNORMALIZED DATA
  • CONVERT TO FIRST NORMAL FORM
  • CONVERT TO SECOND NORMAL FORM
  • CONVERT TO THIRD NORMAL FORM
  • EXERCISE 7-1
  • NORMALIZE DURING DATA MODELLING
  • FURTHER DATABASE DESIGN
  • SPECIFY REFERENTIAL INTEGRITY
  • DESIGN INDEXES
  • ESTABLISH VIEWS
  • DENORMALIZE THE DATABASE DESIGN
  • PLAN PHYSICAL STORAGE USAGE
  • SUMMARY: DATABASE DESIGN
  • SUMMARY: DATABASE DEVELOPMENT

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

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

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

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

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

1 INTRODUCTION 9 .

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

ORACLE OVERVIEW 11 .

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

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

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

2 OVERVIEW OF DATABASE DEVELOPMENT 15 .

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

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

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

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

DEC-81 22. primary key.DEC-80 03.DATABASE DESIGN OVERVIEW In Database Design. 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.81 50 50 Table Name: DEPARTMENT Column Name Key Type Nulls/ Unique Sample Data DEPTNO PK NN. and any foreign keys and provides a visual view of sample data. 20 . Table Name: EMPLOYEE Column Name Key Type Nulls/ Unique Sample Data EMPN O PK NN.NOV.MAY-81 51 28 PRESIDEN 17.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. map the information requirements reflected in an Entity-Relationship Model into a relational database design. 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.

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

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. Analyze and model the relationships between entities. Identify and model entities. Identify unique identifiers for each entity. Analyze and model attributes. 24 . 5. 4. Develop a basic entity-relationship model from a statement of information requirements and user interviews.SECTION OBJECTIVES At the end of this section. 2. 3.

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

Relationships-how the things of significance are related. Example The following entity-relationship model represents the information requirements of the Human Resources Department.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. Entity-Relationship Model Components • • • Entities . 26 . which needs to be held.the things of significance about which information needs to be held. Attributes-the specific information.

precise format. and/or purchased application packages. development projects. 27 . • Use views or subsets of an E-R Model as a communication aide. Robust Syntax • An E-R Model documents an organization's information requirements in a clear. 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. Definition of Scope • An E-R Model provides a clear picture of the scope of an organization's information requirements. User Communication • Users can easily understand the pictorial form of an E-R Model. Quick Notes • Be sure to fully establish an organization's information requirements during the conceptual data modelling stage.Conceptual Data Modelling-cont'd An entity-relationship model is an effective means for collecting and documenting an organization's information requirements.

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

An entity is a class or category of thing. Examples Possible attributes for the entity EMPLOYEE are: badge number. and salary Possible attributes for the entity DEPARTMENT are: Name. 29 . date of birth. An entity is a named 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. name. which need to be known. number. 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. 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.

cont'd Entity Diagramming Conventions • • • • • Soft box with any dimensions Singular. 30 .Entities . 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. Synonyms are useful when two groups of users have different names for the same thing of significance.

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

Badge number is a candidate for the entity UID. 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. Example What attributes might uniquely identify the following entities? Quick Notes • • If an entity cannot be uniquely identified. which uniquely identify an entity and are part of the entity's UID are tagged with #*. Example Each employee has a unique badge number.cont'd Each instance must be uniquely identifiable from other instances of the same entity. it may not be an entity. 32 . Attributes.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. Quick Note • Do not disqualify a candidate entity too soon. Additional attributes of interest to the business may be uncovered later. Are they things of significance? Name each entity. For example. 33 ." • Diagram each entity and a few of its attributes. "An EMPLOYEE has significance as a paid worker at the company. John Brown and Mary Smith are EMPLOYEES.IDENTIFY AND MODEL ENTITIES Follow the steps below to identify and model entities from a set of interview notes. • • • • Examine the nouns.

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

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

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

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

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

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

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

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

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

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

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

Each SALES REPRESENTATIVE may be assigned to visit one or more CUSTOMERS. Quick Notes • • M:1 relationships are very common. Each CUSTOMER must be visited by one and only one SALES REPRESENTATIVE. Example There is a M:1 relationship between CUSTOMER and SALES REPRESENTATIVE. 45 . M:1 relationships that are mandatory in both directions are rare.Relationship Types .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.

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

47 . which seem to have a 1:1 relationship. Entities. A 1:1 Relationship that is mandatory in both directions is very rare. may really be the same entity. Quick Notes • • • 1:1 Relationships are rare. 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 MOTHERBOARD may be incorporated into one and only one MICROCOMPUTER.Relationship Types . Each MICROCOMPUTER must be the host for one and only one MOTHERBOARD.

• Recursive relationships (between an entity and itself) are represented by the boxes on the diagonal. Example The following relationship matrix shows a set of relationships between four entities. • • All the entities are listed along both the left-hand side of the matrix and the top of the matrix. CUSTOMER is related to ORDER and the name of the relationship is the originator of. 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.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. • If a row entity is not related to a column entity. then the name of that relationship is shown in the intersection box. 48 . If a row entity is related to a column entity. ORDER is related to CUSTOMER and the name of the relationship is originated by. • Each relationship above the diagonal line is the inverse or mirror image of a relationship below the line. then a long dash is shown in the intersection box.

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

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

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

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

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

0. 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.cont'd Use a list of relationship name pairs to assist in naming relationships. For further information on the subject see: CASE*Method Entity Relationship Modelling.Name the Relationship . page C-10 54 . 5456-V1.

Example 55 . 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. 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.DETERMINE RELATIONSHIP'S OPTIONALITY Determine the optionality of each direction of the relationship. an EMPLOYEE must always be assigned to a DEPARTMENT. with the relationship names. Draw the relationship lines. Must a DEPARTMENT be responsible for an EMPLOYEE? No. a DEPARTMENT does not have to be responsible for an EMPLOYEE.

Example 56 . an EMPLOYEE must be assigned to only one DEPARTMENT.DETERMINE RELATIONSHIP'S DEGREE Determine the degree of the relationship in both directions. Add the relationship degrees to the E-R Diagram. a DEPARTMENT may be responsible for one or more EMPLOYEES. May a DEPARTMENT be responsible for more than one EMPLOYEE? Yes. 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. May an EMPLOYEE be assigned to more than one DEPARTMENT? No.

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

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

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

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

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

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

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

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

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

The number of an ITEM consists of type. vendor. and item number. Examples The name of a PERSON can be broken down into last name and first name. An attribute of address is frequently left as an aggregate and then decomposed during Design.Attributes .cont'd Always break attributes down into their lowest meaningful components. times. • The level of attribute decomposition will depend upon the business requirements. and zip code. Break down aggregate attributes and embedded code fields into simple attributes. city. and zip codes are generally not decomposed further. social security numbers. Alternative ly it can be decomposed into multiple attributes: apartment/suite. street address. Quick Notes • • Attributes containing dates. state. 66 .

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

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

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

Attributes for that entity may appear later.Distinguish Attributes and 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. it may be only an attribute May have multiple occurrences associated with another entity via a relationship If an attribute has an attribute. Instances of entities and attributes are also 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.cont'd All entities are nouns. 70 . but not all nouns are entities.

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

cont'd Use sample attribute instance data to validate attribute Optionality. 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. 72 . 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.Attribute Optionality .

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 . Employee's name).g.g. Salary amount for each employee).IDENTIFY ATTRIBUTES Identify attributes by examining interview notes and by asking the user questions. Prepositional phrases (e. Possessive nouns and pronouns (e. Nouns. Attributes may appear in interview notes as: • • • • Descriptive words and phrases.

cont'd Examine documentation on existing manual procedures or automated systems to discover additional attributes and omissions. 5456-V1. 5-6 and 5-7. For further information on the subject see: CASE*Method Entity Relationship Modelling. 74 .0. 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. Beware of derived data. pp.Identify Attributes .

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

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

Example For a small theatre. or it is not an entity.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. Quick Notes • • All components of a UID must be mandatory *. Tag each UID attribute with #*. each occurrence of DEPARTMENT is uniquely identified by its department number. An entity must have a UID. The UID for the entity THEATRE TICKET is the combination of the two attributes date of performance and seat number. The UID for the entity DEPARTMENT is the attribute number. 77 . Example In a business. each ticket is uniquely identified by its date of performance and its seat number. Each entity occurrence must be uniquely identifiable.

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

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

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

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

Evaluate the Attributes • What mandatory attributes identify the entity? Seek out additional attributes that help identify the entity. 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 .Assign Unique Identifiers . • • 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.cont'd Search for attributes and relationships to identify each entity. Consider creating artificial attributes for identification.

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

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

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

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

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

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

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

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

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

4 ADVANCED CONCEPTUAL DATA MODELLING 92 .

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

A normalized entity-relationship data model automatically translates into a normalized relational database design. No non-UID attribute can be dependent on another non-UID attribute. • Higher normal forms are not widely used.NORMALIZE THE DATA MODEL Normalization is a relational database concept. 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. but its principles apply to Conceptual Data Modelling. 94 . Quick Notes • Third normal form is the generally accepted goal for a database design that eliminates redundancy.

cont'd First Normal Form Rule: All attributes must be single-valued. No attribute should have repeating values.Normalize the Data Model . If an attribute has multiple 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. Example Does the entity CLIENT comply with 1NF? If not. create an additional entity and relate it to the original entity with a M:1 relationship. therefore the entity CLIENT is not in 1NF Create an additional entity CONTACT with a M:1 relationship to CLIENT. 95 .

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

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

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

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

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

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. When M:M relationships are resolved.Resolve M:M Relationships . 101 . 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.

Resolve M:M Relationships . 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 . include the attribute date enrolled as part of the UID. and grade. the date the student completed the course. and the student's grade. date completed. Example Resolve the following M:M relationship to accommodate these additional requirements: "Track the date each student enrolled in a course. The UID of ENROLLMENT is made up of its relationships to STUDENT and COURSE. If multiple enrollments need to be kept." Solution Add the intersection entity ENROLLMENT and two M:1 relationships. ENROLLMENT has attributes of date enrolled.

" Add an intersection entity called WORK ASSIGNMENT with attributes date assigned and duration. and the duration of that assignment. WORK ASSIGNMENT is partially identified by its relationships to EMPLOYEE and PROJECT. the UID of WORK ASSIGNMENT must include the related EMPLOYEE. the related PROJECT. 103 .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. and the attribute date assigned. An employee may have multiple assignments to a project.Resolve M:M Relationships . but those two relationships are not enough to uniquely identify a WORK ASSIGNMENT. Example Resolve the following M:M relationship to accommodate these additional requirements: "Track the date each employee is assigned to a project. Therefore.

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

cont'd Search for attributes which identify. each VENDOR ITEM has a unique catalog number. or help to identify an intersection entity. 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.Resolve M:M Relationships ." According to the rules of the business. 105 . we have a catalog of all orderable VENDOR ITEMs. So the attribute catalog number should be the UID of VENDOR ITEM.

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

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

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

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

SUITE. 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. 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. The UID of SUITE is the suite number and the FLOOR it is located on.Model Hierarchical Data .

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

Each EMPLOYEE may be the manager of one or more EMPLOYEES. Example Read the recursive relationship in the following E-R Diagram. The loop can appear on any side of the entity's box. but remember that crows always fly east or south.MODEL RECURSIVE RELATIONSHIPS A Recursive Relationship is a relationship between an entity and itself. 112 . Each EMPLOYEE may be managed by one and only one EMPLOYEE. Quick Notes • • The E-R diagramming convention that shows a recursive relationship is known as a pig's ear.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Storing unnecessary historical data can be costly.MODEL DATA OVER TIME Add additional entities and relationships to the E-R model to accommodate historical data. 128 . 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.

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

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

Add an intersection entity.g. 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.Model Data Over Time . EMPLOYMENT HISTORY ENTRY. 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. There is an M:M rela tionship between each member and each company. which changes over time. By including the attribute from date in the UID of EMPLOYMENT HISTORY ENTRY. from date and to date). 131 .cont'd An intersection entity is frequently used to track information about a relationship.

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

the company worked for. track the position held. and the dates the posit ion was held. For each person. The dates of the position seem to be an attribute of a relationship. Which intersection entity are the dates of the position attributes of? All of them? None of them? 133 . So resolve each of the M:M relationships. A person may hold a specific position within the same company multiple times during their career.MODEL COMPLEX RELATIONSHIPS Beware of a ring of M:M relationships. Initially the following E-R Model was defined. Example Develop an E-R model for employment history.

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

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

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

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

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

5 RELATIONAL DATABASE CONCEPTS 139 .

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

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

Rela tional operations can be nested.Relational Database Overview . SQL> 2 3 SELECT emp_no.cont'd Relational databases are manipulated a set at a time rather than a record at a time. use the following SQL statement. lname. Example To select all employees who work in Department 10. dept_no FROM employee WHERE dept_no = 10. 142 . 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. • 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. Relational operations manipulate sets of data values. Tables can be operated on to create other tables. fname.

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

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

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

Example Quick Notes • • • All Candidate Keys must be Unique and NOT NULL.Primary Keys . Select one candidate key to be the Primary Key for the table. in the EMPLOYEE Table. Each of these is called a Candidate Key. For example. Secondary UIDs map to Alternate Keys. The other candidates become Alternate Keys (or Unique Keys). 146 . Example What are the candidate keys for the EMPLOYEE table? EMP_NO and PAYROLL_ID are candidate keys.cont'd A table can have more than one column or combination of columns that can serve as the table's primary key. the combination LNAME/ FNAME would probably not be a candidate key. Person names are not normally candidate keys because their uniqueness cannot be guaranteed.

. Example DEPT_NO is a FK in the EMPLOYEE Table. and refers to values in the DEPT_NO column of the DEPARTMENT Table.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 are based on data values and are purely logical. Quick Notes • • Foreign keys are used to join tables.

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

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

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

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

• A simple entity is not a subtype or supertype. the designer must decide how to map a supertype/subtype construct to tables. Name the table INSTRUCTOR. Record only the name of the table.MAP SIMPLE ENTITIES Map each simple entity to a table. 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. . The plural of the entity name is sometimes used because the table will contain a set of rows. Create a Table Instance Chart for the new table. In Step 6.

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

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.Map Attributes to Columns . 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 .

which are part of the entity's UID to PK column(s). 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. which includes multiple attributes to a composite PK. so make the corresponding column INST_ID the PK of the INSTRUCTOR table. Example The attribute id is the UID of the entity INSTRUCTOR.MAP UID'S TO PRIMARY KEYS Map any attribute(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 the columns PK. Map a UID. Label those columns NN and U1 .

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

MAP RELATIONSHIPS TO FOREIGN KEYS For M:1 relationships. Supply sample data. 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. . and label the column (s) FK. Example Take the PK INST_ID at the one end. and put it in the table COURSE at the many end. take the PK at the one end and put it in the table at the many end. label the column NN. For must be relationships. Table Name: COURSE Column Name Key Type Nulls/ Unique Sample Data COURSE_ CODE PK NN.

Example The PK for the ENROLLMENT table included both the foreign key COURSE_CODE and the foreign key ST_ID. Therefore.cont'd If the table's PK includes a foreign key. these two columns already exist.Map Relationships to Foreign Keys . 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. .

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 FK for the relationship in the PERSONAL_COMPUTER table and label it NOT NULL. U NN NN NN PK CHIP SPEED CHIP 386SX 25 386 33 MINITOWER 200 . place the unique FK in the table at the mandatory end and use the NOT NULL constraint to enforce the mandatory condition. Example Since the relationship from PERSONAL COMPUTER is mandatory.cont'd For a mandatory 1:1 relationship. The FK is labeled U to enforce the 1:1 relationship.Map Relationships to Foreign Keys . 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.

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

Map Relationships to Foreign Keys . add a FK column to the single table. This FK column will refer to values of the PK column. Name the FK column name to reflect the relationship. Table Name: EMPLOYEE Column Name Key Type Nulls/ Unique Sample Data EMP_ID PK NN. Example For this 1:M recursive relationship.1. 1.cont'd For a 1:M recursive relationship. . Name the column MGR_ID to reflect the relationship. A recursive FK will never be NOT NULL. 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. add an FK column to the EMPLOYEE table for each employee's manager.1.

add a unique FK to the table. Example For this 1:1 recursive relationship. This FK column will refer to values of the PK column. • • 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. .cont'd For a 1:1 recursive relationship. add a unique column to the PERSON table.Map Relationships to Foreign Keys . 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.

2. Document each table design on a Table Instance Chart. 3. Map attributes to columns and document sample data. 5. Map UID's to Primary Keys.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. 4. Map simple entities to tables. . Map relationships to Foreign Keys.

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

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

EXERCISE 6-2
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 .

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

• Application software must enforce relationship exclusivity between the foreign keys.Choose Arc Options . PARTNER_CODE. and will be mapped to four separate tables. Using an Explicit Arc Design. INDIV_ID. The arc spans the many end of three relationships.cont'd The Explicit Arc Design creates a foreign key column for each relationship included in the arc. For example. Example The following E-R Model contains four simple entities. . FKs must be added to the OFFICE_SUITE table. create a FK column for each rela tionship. and COMPANY_ID could all have a different column format. Table Name: OFFICE_SUITE Column Name BLDG_ ID SUITE_NUM INDIV_I PARTNER_ CODE D Key Type PK PK NN. 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. Therefore.

create four separate tables for this E-R Model . and C for COMPANY. .Choose Arc Options . For example. The foreign keys must share the same format for all referenced tables.cont'd The Generic Arc Design creates a single foreign key column and one relationship flag column for the arc. only one FK value will exist for each row in the table.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. P for PARTNERSHIP. Table Name: OFFICE_SUITE Column Name Key Type Nulls/ Unique Sample Data BLDG_ID SUITE_NUM RENTER _ID RENTER_ TYPE PK NN. Example Again. U1 11124 512 977 MM 2371 PK NN. add the to the OFFICE_SUITE table. create a single foreign key column. J for INDIVIDUAL. Using the Generic Arc Design. make both added columns NOT NULL. 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. Since the arc spans the many end of the relationships.

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

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 .

Exercise 6-5 . develop a table design for this Entity-Relationship Model. Document your design on the provided Table Instance Charts.cont'd 2 Using a Generic Arc design. 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 .

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

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

50 18.75 12.00 16.00 9.50 12. 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.Choose Subtype Options . 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.75 11.cont'd Option 1 .Single Table Subtype Design Example Map the EMPLOYEE supertype and its subtypes onto a single EMPLOYEE table.50 6.15 15.50 10.

Choose Subtype Options .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 . The EMP_TYPE column was added to the EMPLOYEE table for this purpose. Entity Type Supertype Subtype Columns for Attribtues BADGE_NUM FNAME LNAME EE_SALARY. 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. NE_HOURLY_RATE.

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

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

Table Name: EXEMPT_EMPLOYEE Column Name BADGE_NUM FNAME Key Type Nulls/ Unique Sample Data PK NN. First create a separate table for the EXEMPT EMPLOYEE subtype.one for each subtype.cont'd Option 2 .Separate Tables Subtype Design Example Map the EMPLOYEE supertype onto two tables .Choose Subtype Options . 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 .

00 9.cont'd Option 2 .50 18.75 NN. 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.Choose Subtype Options .50 10.75 12.50 12.cont'd Then create a separate table for the NON-EXEMPT EMPLOYEE subtype. U 201 150 201 201 180 35 30 45 30 45 .50 6.Separate Tables Subtype Design Example .00 16.15 15.75 11.

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

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

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

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

Exercise 6-6 .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 .

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

7 TABLE NORMALIZATION .

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

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

one for each ORDER_ID. .00 65. and PRICE. ITEM DESCRIPTION.75 5. First Normal Form prohibits repeating groups. QUANTITY. Three variable length records are shown . 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. Example Consider the following set of data.00 It contains a repeating group of ITEM NUM.00 4.00 10.RECOGNIZE UNNORMALIZED DATA Unnormalized data does not comply with any of the rules of normalization.00 65.

ITEM DESCRIPTION. ORDER ORDER ID PK 2301 2302 2303 ORDER ID PK.00 2303 6/26 110 We-R-Sports MI 4011 3141 racket cover 2 2 65.00 10.00 10. Create a new ORDERJTEM table with ORDER ID and the repeating group.00 65. Steps 1 2 Remove the repeating group from the base table.75 5. Create a new table with the PK of the base table and the repeating group.00 65. QUA NTITY.00 4.00 65.00 ORDER ITEM ITEM NUM PK 3786 4011 9132 5794 4011 3141 .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. The PK of the remaining table is ORDER ID.00 Remove the repeating group of ITEM NUM. Example Convert the following set of unnormalized data to First Normal Form.75 5.00 4. 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.CONVERT TO FIRST NORMAL FORM Remove any repeating groups. and PRICE.

Remove those columns from the base table. Create a second table with those columns and the column(s) from the PK that they are dependent upon.CONVERT TO SECOND NORMAL FORM Remove any non-key columns that are not dependent upon the table's entire primary key. Therefore. the table is not in 2NF. . all columns are dependent on the PK ORDERJD. Example Put the following table in2NF. Steps 1 2 3 Determine which non-key columns are not dependent upon the table's entire primary key. 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. 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. Any value of ORDERJD uniquely determines a single value of each column.

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.cont'd Remove any non-key columns that are not dependent upon the table's entire primary key.75 5.00 4.FK 2301 2301 2301 2302 2303 2303 ITEM NUM PK.00 65.00 .00 ITEM DESCRIP QUANTITY PRICE The ORDERJTEM table is not in 2NF since PRICE and DESCRIPTION are dependent upon ITEM NUM.00 65.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. ORDER ITEM ORDER ID PK. Create an ITEM table with those columns and the column from the PK that they are dependent upon.75 5. remove any partially dependent columns. Example Put the following table in 2NF. To convert the table to 2NF.Convert to Second Normal Form .00 4. ORDER ITEM ORDER ID ITEM NUM PK.00 10. but not dependent upon ORDER ID.

CONVERT TO THIRD NORMAL FORM Remove any columns that are dependent upon another non-key column. Steps 1 2 3 Determine which columns are dependent upon another non-key column.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. the ORDER table is not in 3NF. CUSTOMER ID is not the PK. 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 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. 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. . Therefore. Example Put the ORDER table in Third Normal Form.

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

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

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 .

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 .Exercise 7-1 .

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

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

Example Are all of the attributes in the following E-R diagram dependent upon their entity's UID? The attribute bank location is not dependent upon the UID of ACCOUNT. It is dependent upon the UID of BANK. Move the attribute and place it where it depends upon the UID of it's entity. 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. .Normalize During Data Modelling .cont'd Validate each attribute's dependence upon its entity's entire UID.

Third Normal Form Rule • No non-key column can be functionally dependent upon another non-key column. Example Are any of the non-UID attributes for this entity dependent upon another non-UID attribute? The attributes customer name and state are dependent upon the customer id. Create another entity called CUSTOMER with a UID of customer id.cont'd Verify attribute placement to ensure a normalized table design. and place the attributes accordingly. Corresponding Data Modelling Rule • No non-UID attribute can be dependent upon another non-UID attribute.Normalize During Data Modelling . .

8 FURTHER DATABASE DESIGN .

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

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

Use referential integrity constraints to specify how referential integrity is to be maintained. 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. .SPECIFY REFERENTIAL INTEGRITY A foreign key column value must match an existing primary key column value (or else be NULL).

Specify Referential Integrity . The deletion should be restricted to only DEPARTMENTS without employees. The foreign key should be nullified (valid only for FK's allowing NULLs) when the referenced PK is deleted. What should happen if a DEPT.cont'd Specify a Delete Constraint to define what should happen if a row containing a referenced primary key is deleted. RESTRICTED. . Options: CASCADE. The matching EMPLOYEE rows should also be deleted. or NULLIFY (only if NULLs are allowed) Example Consider the EMPLOYEE and DEPARTMENT tables.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.

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. RESTRICTED NULLIFY The update should be restricted to only DEPARTMENTS without employees.Specify Referential Integrity . DESIGN INDEXES An index is associated with a single physical table and contains the values of . The matching EMPLOYEE rows should also be updated to reflect the new PK value.) Options: CASCADE. (The Update Rule is only meaningful if the PK is updateable.cont'd Specify an Update Constraint to define what should happen when a referenced primary key is updated. RESTRICTED.

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

Use indexes to significantly improve data access time. 778-V6.0.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.3601-V6.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.

MAY-9 21. Create a composite key called I_ENROLL_PRIME on both columns.MAY-9 28-JUL-91 05. Table Design Table Name: ENROLLMENT Column ENROLL_ DATE_ Name DATE COMPLETEC Key Type Nulls/ NN Unique Sample 20-JUL-91 19-AUG.91 28-JUL-91 28-JUL-91 21.cont'd A concatenated index is an index created on a group of columns in a single table.MAY-91 DATE_ COMPLETED 19-AUG.91 Data 05-SEP-91 14-JUN. Example The ENROLLMENT table has a composite PK of COURSE_CODE and ST_ID.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 .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.91 5013 08.FK1 NN.MAY-91 5014 05. Map a composite key to a concatenated index.FK2 NN.U1 STJD PK.MAY-91 GRADE COURSE_ CODE PK.91 28-JUL-91 08.Design Indexes .

Quick Notes • • • A unique index references a column or set of columns that has unique values in the table.cont'd Use indexes to implement keys and to support application access requirements.0.0 ORACLE RDBMS Performance Tuning Manual 5317-V6.3601-V6. For further information on the subject see: ORACLE RDBMS Database Administrator's Guide Version 6.Design Indexes . Be aware that under certain conditions. indexes are not used by the RDBMS.0 . 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. A non-unique index references a column or set of columns that are not unique in a table.

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

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. the ORDER and CUSTOMER tables are separate. Example Following the rules of normalization. .

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

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

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

cont'd Individual codes tables may be combined into a reference table for validating and decoding coded values for an entire application system. . Example The following separate codes tables are required for an application system. that defines which set of values the code belongs to. Combine all the tables into a single table with an additional column. CODE_TYPE. They are used to provide the SQL*Forms list of values feature and to validate table values for INSERT or UP DATE.Denormalize the Database Design . Create a view for each CODE_TYPE.

The table contains two columns. . LENGTH is the maximum description length for each CODE_TYPE. Each of these code types has a different valid length for its code description. CODE_TYPE and LENGTH. Example The CHAR_CODE table on the previous page includes four different types of codes.cont'd Establish a companion CODE_TYPE table for validating code description lengths.Denormalize the Database Design . Set up a CODE_TYPE table for validating the length of the descriptions.

a repeating group of definite size.Denormalize the Database Design . Column-Wise Table Design (3NF) Row -Wise Table Design . 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 .

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

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

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

Design indexes. . Map relationships to foreign keys. Activity 2: Further Database Design • • • • • • Define referential integrity constraints. Map unique identifiers to primary keys. Denormalize the database design. Plan physical storage usage. Choose subtype options. Choose arc options. Add system support tables. 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. Establish views. Map attributes to columns and document sample data.

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

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

You're Reading a Free Preview

Download
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->