2090A - Modeling Business Requirements To Create A Database Using Microsoft Visual Studio .NET Enterprise Architect PDF

Modeling Business Requirements
to Create a Database Using

Microsoft Visual Studio .NET

Enterprise Architect
Delivery Guide
Course Number: 2090A
Part Number: X08-87912

Released: 06/2002
Information in this document, including URL and other Internet Web site references, is subject to
change without notice. Unless otherwise noted, the example companies, organizations, products,
domain names, e-mail addresses, logos, people, places, and events depicted herein are fictitious,
and no association with any real company, organization, product, domain name, e-mail address,
logo, person, place or event is intended or should be inferred. Complying with all applicable
copyright laws is the responsibility of the user. Without limiting the rights under copyright, no
part of this document may be reproduced, stored in or introduced into a retrieval system, or
transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or
otherwise), or for any purpose, without the express written permission of Microsoft Corporation.
Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual
property rights covering subject matter in this document. Except as expressly provided in any
written license agreement from Microsoft, the furnishing of this document does not give you any
license to these patents, trademarks, copyrights, or other intellectual property.
2002 Microsoft Corporation. All rights reserved.
Microsoft, MS-DOS, Windows, Windows NT, Outlook, PowerPoint, Visio, and Visual Studio are
either registered trademarks or trademarks of Microsoft Corporation in the U.S.A. and/or other
countries.
The names of actual companies and products mentioned herein may be the trademarks of their
respective owners.
Portions of this work are used with permission from the book, Information Modeling and
Relational Databases, by Terry Halpin, 2001 by Morgan Kaufmann Publishers. All rights
reserved.
Course Number: 2090A

Part Number: X08-87912
Released: 06/2002
Modeling Business Requirements to Create a Database Using Microsoft Visual Studio .NET Enterprise Architect iii
Contents
Introduction
Course Materials ......................................................................................................2
Prerequisites.............................................................................................................4
Course Outline .........................................................................................................5
Setup ........................................................................................................................7
Initial Logon Procedure ...........................................................................................9
Setting Screen Resolution ......................................................................................11
Microsoft Official Curriculum ...............................................................................12
Microsoft Certified Professional Program .............................................................13
Facilities.................................................................................................................16
Module 1: Introduction to Modeling Business Requirements
Module Overview ....................................................................................................1
Lesson: Overview of Database Modeling Process...................................................2
Lesson: Data Modeling Concepts ..........................................................................17
Lab A: Examining External Information ...............................................................33
Module 2: Analyzing External Information and Creating a Conceptual
ModelCSDP Step 1
Module Overview ....................................................................................................1
Lesson: Verbalizing Data Use Cases .......................................................................2
Lesson: Formalizing Fact Types ............................................................................23
Module Review......................................................................................................36
Lab A: Analyzing External Information and Creating a Conceptual Model
CSDP Step 1 ..........................................................................................................38
Module 3: Drawing a Conceptual Model and Entering Sample Data
CSDP Step 2
Module Overview ....................................................................................................1
Lesson: Drawing Fact Types ...................................................................................2
Lesson: Applying a Population Check...................................................................11
Lesson: Applying CSDP Step 2 .............................................................................17
Module Review......................................................................................................25
Lab A: Drawing Fact Types and Applying Population Checks .............................26
Lab A Discussion: Drawing Fact Types and Applying Population Checks...........32
Module 4: Trimming the Conceptual SchemaCSDP Step 3
Module Overview ....................................................................................................1
Lesson: Implementing Primitive Entity Types ........................................................2
Lesson: Implementing Derived Fact Types ...........................................................14
Lesson: Applying CSDP Step 3 .............................................................................22
Module Review......................................................................................................31
Lab A: Implementing Primitive Entity Types and Derived Fact TypesCSDP
Step 3 .....................................................................................................................32
iv Modeling Business Requirements to Create a Database Using Microsoft Visual Studio .NET Enterprise Architect
Module 5: Adding Uniqueness Constraints and Checking Arity of Fact

TypesCSDP Step 4
Module Overview ................................................................................................... 1
Lesson: Implementing Uniqueness Constraints ...................................................... 2
Lesson: Implementing Nested Object Types ........................................................ 15
Lesson: Checking Fact Arity................................................................................. 22
Lesson: Applying CSDP Step 4 ............................................................................ 31
Module Review..................................................................................................... 40
Lab A: Adding Uniqueness Constraints and Checking Arity of Fact Types ........ 41
Module 6: Adding Mandatory Role Constraints and Checking for Logical
DerivationsCSDP Step 5
Module Overview ................................................................................................... 1
Lesson: Implementing Mandatory Role Constraints............................................... 2
Lesson: Implementing a Primary Reference Scheme ........................................... 18
Lesson: Checking for Logically Derivable Fact Types......................................... 31
Module Review..................................................................................................... 47
Lab A: Adding Mandatory Role Constraints and Checking for Logical
Derivations............................................................................................................ 48
Module 7: Adding Value and Set Constraints, and Creating Entity
SubtypesCSDP Step 6
Module Overview ................................................................................................... 1
Lesson: Implementing Value Constraints ............................................................... 2
Lesson: Implementing Set Constraints.................................................................. 11
Lesson: Implementing Entity Subtypes ................................................................ 21
Module Review..................................................................................................... 46
Lab A: Adding Value Constraints, Set Constraints, and Entity Subtypes............. 47
Module 8: Adding Frequency and Ring ConstraintsCSDP Step 7
Module Overview ................................................................................................... 1
Lesson: Implementing Frequency Constraints........................................................ 2
Lesson: Implementing Ring Constraints............................................................... 12
Module Review..................................................................................................... 42
Lab A: Implementing Frequency and Ring Constraints........................................ 44
Module 9: Generating a Relational Logical Model
Module Overview ................................................................................................... 1
Lesson: Understanding Relational Logical Models ................................................ 2
Lesson: Understanding Normalization.................................................................. 10
Lesson: Generating a Relational Logical Model................................................... 22
Module Review..................................................................................................... 30
Lab A: Generating a Relational Logical Model .................................................... 31
Course Evaluation ................................................................................................. 34
Modeling Business Requirements to Create a Database Using Microsoft Visual Studio .NET Enterprise Architect v
Module 10: Completing the Baseline Model

Module Overview ....................................................................................................1
Lesson: Refining Conceptual and Logical Models ..................................................2
Lesson: Documenting Conceptual and Logical Models ........................................17
Module Review......................................................................................................25
Lab A: Completing the Baseline Model ................................................................26
Module 11: Generating and Reverse Engineering Physical Schema
Module Overview ....................................................................................................1
Lesson: Forward Engineering ..................................................................................2
Module Review......................................................................................................21
Lab A: Forward and Reverse Engineering Physical Schema.................................22
Course Evaluation..................................................................................................28
Modeling Business Requirements to Create a Database Using Microsoft Visual Studio .NET Enterprise Architect vii
About This Course

This section provides you with a brief description of the course, audience,
suggested prerequisites, and course objectives.
Description This intensive, three-day course provides students with the knowledge and
skills to model business requirements to create a baseline database design. It
focuses on the use of Object Role Modeling (ORM) and the ORM modeling
tool in Microsoft Visual Studio .NET Enterprise Architect edition. Students
will also learn the database modeling process and how ORM relates to Entity
Relationship (ER) diagrams.
Audience This course will benefit those who need to understand the principles of database
design in preparation for modeling, designing, developing, or administering
databases. It will also help those who are developing applications that access
data in an online transaction processing (OLTP).
Some of the individuals who may benefit from this course are:
! Database designers.
! Database implementers.
! Database administrators.
! Application developers (client, server, Web).
Student prerequisites This course requires that students meet the following prerequisites:
! Be familiar with databases and their uses.
! Have the ability to:
Describe what databases are and how they are used.
Understand basic programming concepts.
Understand the following relational database terms:
Tables
Columns
Data integrity
Data types
! Have the necessary skills to log on to and navigate in a Microsoft
Windows environment.
Course objectives After completing this course, students will be able to:
! Analyze business requirements.
! Create a conceptual database model by using ORM.
! Create a relational logical model.
! Validate the model against the external information.
! Transfer the model into a Microsoft SQL Server 2000 database.
viii Modeling Business Requirements to Create a Database Using Microsoft Visual Studio .NET Enterprise Architect
Course Timing
The following schedule is an estimate of the course timing. Your timing may
vary.
Day 1
Start End Module
9:00 9:30 Introduction
9:30 10:15 Module 1: Introduction to Modeling Business Requirements
10:15 11:00 Break
10:15 11:00 Lab A: Examining External Information
11:00 12:00 Module 2: Analyzing External Information and Creating a
Conceptual ModelCSDP Step 1
12:00 1:00 Lunch
1:00 1:30 Lab A: Analyzing External Information and Creating a
1:30 2:30 Module 3: Drawing a Conceptual Model and Entering Sample
DataCSDP Step 2
2:30 3:00 Lab A: Drawing Fact Types and Applying Population Checks
3:00 3:15 Break
3:15 4:15 Module 4: Trimming the Conceptual SchemaCSDP Step 3
4:15 4:45 Lab A: Implementing Primitive Entity Types and Derived Fact
TypesCSDP Step 3
Modeling Business Requirements to Create a Database Using Microsoft Visual Studio .NET Enterprise Architect ix
Day 2
Start End Module
9:00 9:15 Day 1 review
9:15 10:15 Module 5: Adding Uniqueness Constraints and Checking Arity of
Fact TypesCSDP Step 4
10:15 10:30 Break
10:30 11:00 Lab A: Adding Uniqueness Constraints and Checking Arity of
Fact Types
11:00 12:00 Module 6: Adding Mandatory Role Constraints and Checking for
Logical DerivationsCSDP Step 5
12:00 1:00 Lunch
1:00 1:45 Lab A: Adding Mandatory Role Constraints, and Checking for
Logical Derivations
1:45 2:45 Module 7: Adding Value and Set Constraints, and Creating Entity
SubtypesCSDP Step 6
2:45 3:00 Break
3:00 3:30 Lab A: Adding Value Constraints, Set Constraints, and Entity
Subtypes
3:30 4:30 Module 8: Adding Frequency and Ring ConstraintsCSDP Step
7
4:30 5:00 Lab A: Implementing Frequency and Ring Constraints
Day 3
Start End Module
9:00 9:15 Day 2 review
9:15 10:00 Module 9: Generating a Relational Logical Model
10:00 10:30 Lab A: Generating a Relational Logical Model
10:30 11:00 Break
11:00 12:00 Module 10: Completing the Baseline Model
12:00 1:00 Lunch
1:00 1:30 Lab A: Completing the Baseline Model
1:30 2:45 Module 11: Generating and Reverse Engineering Physical
Schema
2:45 3:00 Break
3:00 3:30 Lab A: Forward and Reverse Engineering Physical Schema
x Modeling Business Requirements to Create a Database Using Microsoft Visual Studio .NET Enterprise Architect
Trainer Materials Compact Disc Contents

The Trainer Materials compact disc contains the following files and folders:
! Autorun.exe. When the compact disc is inserted into the compact disc drive,
or when you double-click the Autorun.exe file, this file opens the compact
disc and allows you to browse the Student Materials or Trainer Materials
compact disc.
! Autorun.inf. When the compact disc is inserted into the compact disc drive,
this file opens Autorun.exe.
! Default.htm. This file opens the Trainer Materials Web page.
! Readme.txt. This file explains how to install the software for viewing the
Trainer Materials compact disc and its contents and how to open the Trainer
Materials Web page.
! 2090A_ms.doc. This file is the Manual Classroom Setup Guide. It contains
the steps for manually setting up the classroom computers.
! 2090A_sg.doc. This file is the Automated Classroom Setup Guide. It
contains a description of classroom requirements, classroom configuration,
instructions for using the automated classroom setup scripts, and the
Classroom Setup Checklist.
! Powerpnt. This folder contains the Microsoft PowerPoint slides that are
used in this course.
! Pptview. This folder contains the Microsoft PowerPoint Viewer 97, which
can be used to display the PowerPoint slides if Microsoft PowerPoint 2002
is not available. Do not use this version in the classroom.
! Setup. This folder contains the files that install the course and related
software to computers in a classroom setting.
! Studentcd. This folder contains the Web page that provides students with
links to resources pertaining to this course, including additional reading,
review and lab answers, lab files, multimedia presentations, and course-
related Web sites.
! Tools. This folder contains files and utilities used to complete the setup of
the instructor computer.
! Webfiles. This folder contains the files that are required to view the course
Web page. To open the Web page, open Windows Explorer, and in the root
directory of the compact disc, double-click Default.htm or Autorun.exe.
Modeling Business Requirements to Create a Database Using Microsoft Visual Studio .NET Enterprise Architect xi
Student Materials Compact Disc Contents

The Student Materials compact disc contains the following files and folders:
! Autorun.exe. When the compact disc is inserted into the CD-ROM drive, or
when you double-click the Autorun.exe file, this file opens the compact
disc and allows you to browse the Student Materials compact disc.
! Autorun.inf. When the compact disc is inserted into the compact disc drive,
this file opens Autorun.exe.
! Default.htm. This file opens the Student Materials Web page. It provides
you with resources pertaining to this course, including additional reading,
review and lab answers, lab files, multimedia presentations, and course-
related Web sites.
! Readme.txt. This file explains how to install the software for viewing the
Student Materials compact disc and its contents and how to open the
Student Materials Web page.
! Addread. This folder contains additional reading files for this course.
! Flash. This folder contains the installer for the Macromedia Flash 5.0
browser plug-in.
! Fonts. This folder contains fonts that may be required to view Microsoft
Word documents that are included with this course.
! Labfiles. This folder contains files that are used in the hands-on labs. These
files may be used to prepare the student computers for the hands-on labs.
! Media. This folder contains files that are used in multimedia presentations
for this course.
! Mplayer. This folder contains the setup file to install Microsoft Windows
Media Player.
! Practices. This folder contains files that are used in the hands-on practices.
! Visio. This folder contains the Microsoft Visio Viewer Web Component
that is used to view Visio diagrams on computers that do not have Microsoft
Visual Studio .NET Enterprise Architect edition installed.
! Webfiles. This folder contains the files that are required to view the course
Web page. To open the Web page, open Windows Explorer, and in the root
directory of the compact disc, double-click Default.htm or Autorun.exe.
! Wordview. This folder contains the Word Viewer that is used to view any
Word document (.doc) files that are included on the compact disc.
xii Modeling Business Requirements to Create a Database Using Microsoft Visual Studio .NET Enterprise Architect
Document Conventions
The following conventions are used in course materials to distinguish elements
of the text.
Convention Use
Bold Represents commands, command options, and syntax that must

be typed exactly as shown. It also indicates commands on menus
and buttons, dialog box titles and options, and icon and menu
names.
Italic In syntax statements or descriptive text, indicates argument
names or placeholders for variable information. Italic is also
used for introducing new terms, for book titles, and for emphasis
in the text.
Title Capitals Indicate domain names, user names, computer names, directory
names, and folder and file names, except when specifically
referring to case-sensitive names. Unless otherwise indicated,
you can use lowercase letters when you type a directory name or
file name in a dialog box or at a command prompt.
ALL CAPITALS Indicate the names of keys, key sequences, and key
combinations for example, ALT+SPACEBAR.
monospace Represents code samples or examples of screen text.
[] In syntax statements, enclose optional items. For example,
[filename] in command syntax indicates that you can choose to
type a file name with the command. Type only the information
within the brackets, not the brackets themselves.
{} In syntax statements, enclose required items. Type only the
information within the braces, not the braces themselves.
| In syntax statements, separates an either/or choice.
! Indicates a procedure with sequential steps.
... In syntax statements, specifies that the preceding item may be
repeated.
. Represents an omitted portion of a code sample.
.
.
THIS PAGE INTENTIONALLY LEFT BLANK

Introduction
Contents
Introduction 1
Course Materials 2
Prerequisites 4
Course Outline 5
Setup 7
Initial Logon Procedure 9
Setting Screen Resolution 11
Microsoft Official Curriculum 12
Microsoft Certified Professional Program 13
Facilities 16
either registered trademarks or trademarks of Microsoft Corporation in the United States and/or
other countries.
respective owners.
reserved.
Introduction iii
Instructor Notes
Presentation: The Introduction module provides students with an overview of the course
30 minutes content, materials, and logistics for Course 2090, Modeling Business
Requirements to Create a Database Using Microsoft Visual Studio .NET
Enterprise Architect.
Required materials To teach this course, you need the following materials:
! Delivery Guide
! Trainer Materials compact disc
Preparation tasks To prepare for this course, you must:

! Complete the Course Preparation Checklist that is included with the trainer
course materials.
! If possible, review and reference Chapters 1-8, and 10 of Information
Modeling and Relational Databases, by Terry Halpin. 2001 by Morgan
Kaufmann Publishers.
iv Introduction
How to Teach This Module

This section contains information that will help you to teach this module.
Introduction Welcome students to the course and introduce yourself. Provide a brief
overview of your background to establish credibility.
Ask students to introduce themselves and provide their background, product
experience, and expectations of the course.
Record student expectations on a whiteboard or flip chart that you can reference
later in class.
Course materials Tell students that everything they will need for this course is provided at their
desk.
Have students write their names on both sides of the name card.
Describe the contents of the student workbook and the Student Materials
compact disc.
Tell students where they can send comments and feedback on this course.
Point out the additional resources available on Object Role Modeling (ORM).
Demonstrate how to open the Web page that is provided on the Student
Materials compact disc by double-clicking Autorun.exe or Default.htm in the
StudentCD folder on the Trainer Materials compact disc.
Tell students that there are two files they can use for reference which are linked
from the Additional Reading page on the student CD. The files are a glossary
called ORM_Terminology_Guide.doc and a symbol guide called
ORM_Symbol_Guide.doc.
Prerequisites Describe the prerequisites for this course. This is an opportunity for you to
identify students who may not have the appropriate background or experience
to attend this course.
Course outline Briefly describe each module and what students will learn. Be careful not to go
into too much detail because the course is introduced in detail in Module 1.
Explain how this course will meet students expectations by relating the
information that is covered in individual modules to their expectations.
Setup Describe any necessary setup information for the course, including course files
and classroom configuration.
Initial Logon Procedure Describes and provides the procedure for students to follow for their initial
logon in the classroom. Students must follow this procedure to complete the
course.
Microsoft Official Explain the Microsoft Official Curriculum (MOC) program and present the list
Curriculum of additional recommended courses.
Refer students to the Microsoft Official Curriculum Web page at
http://www.microsoft.com/traincert/training/ for information about curriculum
paths.
Introduction v
Microsoft Certified Inform students about the Microsoft Certified Professional (MCP) program, any
Professional program certification exams that are related to this course, and the various certification
options.
Facilities Explain the class hours, extended building hours for labs, parking, restroom
location, meals, phones, message posting, and where smoking is or is not
allowed.
Let students know if your facility has Internet access that is available for them
to use during class breaks.
Also, make sure that the students are aware of the recycling program if one is
available.
Introduction 1
Introduction
! Name
! Company affiliation
! Title/function
! Job responsibility
! Database experience
! SQL Server experience
! Visio experience
! Infomodeler experience
! Expectations for the course
*****************************ILLEGAL FOR NON-TRAINER USE******************************

2 Introduction
Course Materials
! Name card
! Student workbook
! Student Materials compact disc
! Course evaluation
! Additional resources

The following materials are included with your kit:
! Name card. Write your name on both sides of the name card.
! Student workbook. The student workbook contains the material covered in
class, in addition to the hands-on lab exercises.
! Student Materials compact disc. The Student Materials compact disc
contains the Web page that provides you with links to resources pertaining
to this course, including additional readings, review and lab answers, lab
files, multimedia presentations, and course-related Web sites.
Note To open the Web page, insert the Student Materials compact disc into
the CD-ROM drive, and then in the root directory of the compact disc,
double-click Autorun.exe or Default.htm.
! Course evaluation. To provide feedback on the course, training facility, and

instructor, you will have the opportunity to complete an online evaluation
near the end of the course.
To provide additional comments or inquire about the Microsoft Certified
Professional program, send e-mail to mcphelp@microsoft.com.
Introduction 3
! Additional resources. You can find additional information about Object

Role Modeling (ORM) and database modeling on the following Web sites:
http://www.orm.net
http://www.msdn.microsoft.com/library
http://www.inconcept.com
http://www.ormcentral.com
For more details on information modeling, read Information Modeling and

Relational Databases, by Terry Halpin. 2001 by Morgan Kaufmann
Publishers Information Modeling and Relational Databases.
(ISBN 1-55860-672-6)
4 Introduction
Prerequisites
! Familiarity with databases and their uses

! Ability to:
" Describe what databases are and how they are used
" Understand basic programming concepts
" Understand basic relational database terms
! Have the necessary skills to log on to and navigate in a
Microsoft Windows environment

This course requires that you meet the following prerequisites:
! Familiarity with databases and their uses.
! Ability to:
Describe what databases are and how they are used.
Understand basic programming concepts.
Understand the following relational database terms:
Tables
Columns
Data integrity
Data types
! Have the necessary skills to log on to and navigate in a Microsoft
Windows environment.
Introduction 5
Course Outline
! Module 1: Introduction to Modeling Business Requirements
! Module 2: Analyzing External Information and Creating a
! Module 3: Drawing a Conceptual Model and Entering Sample
DataCSDP Step 2
! Module 4: Trimming the Conceptual SchemaCSDP Step 3
! Module 5: Adding Uniqueness Constraints and Checking Arity of
! Module 6: Adding Mandatory Role Constraints and Checking for
Logical DerivationsCSDP Step 5

Module 1, Introduction to Modeling Business Requirements,provides an
overview of the business requirements modeling process. It introduces you to
ORM and the associated terminology. The purpose of this module is to build
the foundation for the rest of the course.
Module 2, Analyzing External Information and Creating a Conceptual
ModelCSDP Step 1, is the first of seven modules that cover the steps of
ORM. This module explains how to transform familiar information examples
into elementary facts and apply quality checks.
Module 3, Drawing a Conceptual Model and Entering Sample DataCSDP
Step 2, explains how to draw fact types and apply population checks by using
ORM.
Module 4, Trimming the Conceptual SchemaCSDP Step 3, covers the
Transact-SQL component of Microsoft SQL Server 2000. This module covers
how to check for entity types that should be combined and note arithmetic
derivations.
Module 5, Adding Uniqueness Constraints and Checking Arity of Fact
TypesCSDP Step 4, provides information on how to add uniqueness
constraints and check the arity of facts.
Module 6, Adding Mandatory Role Constraints and Checking for Logical
DerivationsCSDP Step 5, explains how to add mandatory role constraints,
check for logical derivations, and implement a primary reference scheme.
6 Introduction
Course Outline (continued)
! Module 7: Adding Value and Set Constraints, and

Creating Entity SubtypesCSDP Step 6
! Module 8: Adding Frequency and Ring Constraints
CSDP Step 7
! Module 9: Generating a Relational Logical Model
! Module 10: Completing the Baseline Model
! Module 11: Generating and Reverse Engineering
Physical Schema

Module 7, Adding Value and Set Constraints, and Creating Entity Subtypes
CSDP Step 6, covers how to add value, set comparison, and create subtype
constraints. This module covers how to check for entity types that should be
combined and note arithmetic derivation.
Module 8, Adding Frequency and Ring ConstraintsCSDP Step 7, provides
information on how to add other constraints and perform final checks.
Module 9, Generating a Relational Logical Model, explains what relational
logical models are and describes normalization and denormalization and how to
generate a relational logical model.
Module 10, Completing the Baseline Model, provides the knowledge and
steps for setting physical data types, setting physical names, and documenting
the baseline model.
Module 11, Generating and Reverse Engineering Physical Schema,
summarizes how to forward engineer and reverse engineer physical schema.
Introduction 7
Setup
! Course files
" Lab files are located in the folder C:\Moc\2090\Labfiles\
on the student computers
" Practice files are located in the folder
C:\Moc\2090\Practices\ on the student computers
! Classroom setup
" Classroom is configured in the single domain/workgroup
model

Software The classroom environment is set up with software and a path to course files
that you will use in class. You should also take note of the classroom
configuration in which you will be performing the lab exercises.
The following software will be used in the classroom:
! Microsoft SQL Server 2000, Developer edition
! Microsoft Visual Studio .NET, Enterprise Architect edition
Course Files Files associated with the course labs and practices are available to you. The lab
files are located in the folder C:\Moc\2090\Labfiles\ on the student computers.
The practice files are located in the folder C:\Moc\2090\Practices\ on the
student computers. Both of these folders have subfolders with answers.
Classroom Setup The classroom is configured in the single domain/workgroup model, as shown
in the following graphic.
8 Introduction
All computers in the classroom environment belong to a single domain, on a

single TCP/IP subnet. The instructor computer is the domain controller, and is
running the DHCP service to automatically configure TCP/IP settings on
student workstations. The instructor computer is running Windows 2000
Advanced Server, and the student computers are all running Microsoft
Windows XP Professional. The screen resolution for all computers will be
1024x800.
SQL Server 2000 Developer Edition is installed on all computers, using
Windows Authentication integrated security and running under a dedicated
domain service account. Students will access SQL Server by using a trusted
connection from their domain logons.
This course primarily uses Microsoft Visio Enterprise Architect edition, which
is packaged with Visual Studio .NET Enterprise Architect Edition. A minimal
installation of Visual Studio .NET Enterprise Architect Edition is installed.
Although it is not used in the course, it must be installed before installing Visio
for Enterprise Architects.
Introduction 9
Initial Logon Procedure
Passwords in MOC courses must be complex.

You must:
! Perform your initial logon by using P@ssw0rd
! Create your own password to use for the course

Complex passwords To meet the complexity requirements for the password that you will use in this
course, you must include characters in your password from at least three of the
following four categories:
! Uppercase letters (A to Z)
! Lowercase letters (a to z)
! Numbers (0 to 9)
! Symbols (! @ # $)
To create the password that you will use in this course, you must log on either
as Studentxx, where xx is your student number, or as Student, depending on
the classroom setup.
10 Introduction
Tasks ! Log on to your account

1. Press CTRL+ALT+DEL to open the Log On to Windows dialog box.
2. In the User name box, type Studentxx or Student.
3. In the Password box, type P@ssw0rd.
4. In the Log on to box, select the name of the domain that is used in the
course or the name of your computer, and then click OK.
The Logon Message dialog box appears, stating that your password must be
changed at initial logon.
! Change your password

1. In the Logon Message dialog box, click OK.
2. In the New Password box, type your new password.
3. In the Confirm New Password box, retype your new password, and then
click OK.
4. In the Change Password dialog box, click OK.
Introduction 11
Setting Screen Resolution
! Requirements
! Tasks

Requirements Because Visio requires a large desktop resolution to display graphical models,
you must resize your desktop resolution to 1024 x 768 pixels.
Tasks ! Log off from your account
1. Press CTRL+ALT+DEL to open the Windows Security dialog box.
2. Click Log Off.
3. In the Log Off Windows dialog box, click Log Off.
! Log on to your account

1. Press CTRL+ALT+DEL to open the Log On to Windows dialog box.
2. In the User name box, type Studentxx or Student.
3. In the Password box, type your password.
4. In the Log on to box, select the name of the domain that is used in the
course or the name of your computer, and then click OK.
! Change your screen resolution

1. Right-click a blank area of the desktop.
2. Click Properties.
3. On the Settings tab, drag the Screen Resolution slider to the 1024 x 768
mark, and then click OK.
4. In the Monitor Settings dialog box, click Yes.
12 Introduction
Microsoft Official Curriculum

2071, Querying Microsoft
SQL Server 2000 with
Transact-SQL
2090, Modeling Business
Requirements to Create a 2072, Administering a
Database Using Microsoft Microsoft SQL Server 2000
Visual Studio . NET Database
Enterprise Architect
2073, Programming a
Microsoft SQL Server 2000
Database
http://www.microsoft.com/traincert/

Introduction Microsoft Training and Certification develops Microsoft Official Curriculum
(MOC), including MSDN Training, for computer professionals who design,
develop, support, implement, or manage solutions using Microsoft products and
technologies. These courses provide comprehensive skills-based training in
instructor-led and online formats.
Additional Each course relates in some way to another course. A related course may be a
recommended courses prerequisite, a follow-up course in a recommended series, or a course that offers
additional training.
After taking Course 2090, Modeling Business Requirements to Create a
Database Using Microsoft Visual Studio .NET Enterprise Architect, you can
take the following courses in any order:
! 2071, Querying Microsoft SQL Server 2000 with Transact-SQL
! 2072, Administering a Microsoft SQL Server 2000 Database
! 2073, Programming a Microsoft SQL Server 2000 Database
Other related courses may become available in the future, so for up-to-date
information about recommended courses, visit the Training and Certification
Web site.
Microsoft Training and For more information, visit the Microsoft Training and Certification Web site at
Certification information http://www.microsoft.com/traincert/.
Introduction 13
Microsoft Certified Professional Program
Exam Core
Core exam
examforforthe
the Elective
Electiveexam
exam for
forthe
the
Examnumber
numberand
andtitle
title following
following track
track following
followingtrack
track
70-100:
70-100:Analyzing
AnalyzingRequirements
Requirements
and
andDefining
DefiningSolution
Solution MCSD
MCSD Not
Not Applicable
Applicable
Architectures
Architectures
http://www.microsoft.com/traincert/

Introduction Microsoft Training and Certification offers a variety of certification credentials
for developers and IT professionals. The Microsoft Certified Professional
program is the leading certification program for validating your experience and
skills, keeping you competitive in todays changing business environment.
Related certification This course helps students to prepare for Exam 70-100: Analyzing
exams Requirements and Defining Solution Architectures. The course includes
material to help you prepare for the Developing Data Models skill that is
measured by Exam 70-100.
Exam 70-100 is a core exam for the MCSD certification.
MCP certifications The Microsoft Certified Professional program includes the following
certifications.
! MCSA on Microsoft Windows 2000
The Microsoft Certified Systems Administrator (MCSA) certification is
designed for professionals who implement, manage, and troubleshoot
existing network and system environments based on Microsoft
Windows 2000 platforms, including the Windows .NET Server family.
Implementation responsibilities include installing and configuring parts of
the systems. Management responsibilities include administering and
supporting the systems.
! MCSE on Microsoft Windows 2000
The Microsoft Certified Systems Engineer (MCSE) credential is the premier
certification for professionals who analyze the business requirements and
design and implement the infrastructure for business solutions based on the
Microsoft Windows 2000 platform and Microsoft server software, including
the Windows .NET Server family. Implementation responsibilities include
installing, configuring, and troubleshooting network systems.
14 Introduction
! MCSD
The Microsoft Certified Solution Developer (MCSD) credential is the
premier certification for professionals who design and develop leading-edge
business solutions with Microsoft development tools, technologies,
platforms, and the Microsoft Windows DNA architecture. The types of
applications MCSDs can develop include desktop applications and multi-
user, Web-based, N-tier, and transaction-based applications. The credential
covers job tasks ranging from analyzing business requirements to
maintaining solutions.
! MCDBA on Microsoft SQL Server 2000
The Microsoft Certified Database Administrator (MCDBA) credential is the
premier certification for professionals who implement and administer
Microsoft SQL Server databases. The certification is appropriate for
individuals who derive physical database designs, develop logical data
models, create physical databases, create data services by using Transact-
SQL, manage and maintain databases, configure and manage security,
monitor and optimize databases, and install and configure SQL Server.
! MCP
The Microsoft Certified Professional (MCP) credential is for individuals
who have the skills to successfully implement a Microsoft product or
technology as part of a business solution in an organization. Hands-on
experience with the product is necessary to successfully achieve
certification.
! MCT
Microsoft Certified Trainers (MCTs) demonstrate the instructional and
technical skills that qualify them to deliver Microsoft Official Curriculum
through Microsoft Certified Technical Education Centers (Microsoft
CTECs).
Certification The certification requirements differ for each certification category and are
requirements specific to the products and job functions addressed by the certification. To
become a Microsoft Certified Professional, you must pass rigorous certification
exams that provide a valid and reliable measure of technical proficiency and
expertise.
For More Information See the Microsoft Training and Certification Web site at
http://www.microsoft.com/traincert/.
You can also send e-mail to mcphelp@microsoft.com if you have specific
certification questions.
Introduction 15
Acquiring the skills MOC and MSDN Training Curriculum can help you develop the skills that you
tested by an MCP exam need to do your job. They also complement the experience that you gain while
working with Microsoft products and technologies. However, no one-to-one
correlation exists between MOC and MSDN Training courses and MCP exams.
Microsoft does not expect or intend for the courses to be the sole preparation
method for passing MCP exams. Practical product knowledge and experience is
also necessary to pass the MCP exams.
To help prepare for the MCP exams, use the preparation guides that are
available for each exam. Each Exam Preparation Guide contains exam-specific
information, such as a list of the topics on which you will be tested. These
guides are available on the Microsoft Training and Certification Web site at
http://www.microsoft.com/traincert/.
16 Introduction
Facilities
! Class hours
! Building hours
! Parking
! Restrooms
! Meals
! Phones
! Messages
! Smoking
! Recycling

Module 1: Introduction
to Modeling Business
Requirements
Contents
Module Overview 1
Lesson: Overview of Database Modeling
Process 2
Lesson: Data Modeling Concepts 17
Lab A: Examining External Information 33
other countries.
respective owners.
reserved.
Module 1: Introduction to Modeling Business Requirements iii
Instructor Notes
Presentation: This module is designed to provide students with a basic understanding of the
45 minutes overall database design procedure when using the Object Role Modeling
(ORM) methodology. Students should already be familiar with Entity
Lab: Relationship (ER) diagramming, so this module helps them through the difficult
45 minutes transition of modeling with ORM as opposed to ER.
Important This course is different from many other Microsoft Official

Curriculum (MOC) courses in that it is graphics intensive. You should also be
aware of the other following unique elements:
! Several topic pages include multiple Microsoft PowerPoint slides. These
extra slides are identified with a parenthetical reference to the slide number
that you are currently viewing, such as (1 of 2) or (2 of 2).
! The intent is for you to discuss the contents of each slide. Do not just show
the graphic and move on. Ensure that students are party to all of the nuances
of each example.
! Each of the graphics that appears in the student workbook is reproduced on
a slide and is further identified in the student workbook and slide by a figure
number.
! Also, each Lesson Review slide shows the lesson objectives and is not
simply a repeat of the topic pages. Use these slides to cover each question
listed and also as a place of reference for discussion.
After completing this module, students will be able to:

! Describe the process of modeling business requirements.
Summarize the process of modeling a baseline database model.
Summarize data modeling concepts.
Required materials To teach this module, you need the following materials:
! PowerPoint file 2090A_01.ppt
Preparation tasks To prepare for this module:

! Read all of the materials for this module.
! Complete the practices and lab.
! If possible, review and reference Chapters 1-8 and 10 of Information
iv Module 1: Introduction to Modeling Business Requirements

This module was designed to grab students interest and encourage them to start
thinking in terms of objects and the roles that they play with one another. The
module explains the life cycle of data modeling, emphasizing the need to work
specifically with the business requirements of the enterprise. It provides an
overview of database modeling concepts. You should introduce Microsoft
products used in this course and how they relate to database modeling.
Multiple examples of modeling problems are provided that show sample
information, data, and diagrams. Each example is discussed in terms of how it
semantically expresses the model and is related back to the business record-
keeping activities that it represents.
This module will establish a basis for viewing different levels of information
related to the scope of a modeling solution. Each of these information levels can
be viewed as a phase in the modeling process.
It is the intention of this module to encourage students to release all
assumptions that they may have in regard to modeling and to look at things in a
manner that supports ORM.
Module Overview This page introduces the two lesson topics for this module, covering the
database modeling process and giving students an overview of key data
modeling concepts.
Lesson: Overview of Database Modeling Process

Instructional Methods Students will be given reasons and examples of why databases are modeled.
and Media Students will then be asked to relate these examples to any other business
examples that they may be familiar with and to provide feedback on the use of
modeling in their current environments.
Students will be given a list of the components of a database that are modeled
and will then discuss the reasons for modeling particular components.
Students will be given short examples of ORM, ER, and Unified Modeling
Language (UML) to help them understand how each is best used.
Students will receive a brief overview of set theory and are provided with a
graphical representation to stimulate conversation.
To become familiar with the tools to be used in this course, students will be
given a brief demonstration and practice with Microsoft Visio Enterprise
Architect edition. Students are expected to participate in this lesson by sharing
examples of their own business experiences and discussing modeling
techniques.
Facilitation Instructions After each topic is introduced, provide an opportunity for students to share their
personal experiences with related information. Allow for exploration within the
topic. However, do not allow students to digress. Keep the discussion focused
and relevant.
Positioning The purpose of this lesson is to establish what database modeling is, how it
relates to actual business requirements, and to introduce the Microsoft products
that are used in the course.
Module 1: Introduction to Modeling Business Requirements v
Lesson: Overview of This page gives an overview of the first lesson and introduces the topics
Database Modeling included. Emphasize that a model is a representation of a physical database, not
Process the database itself. The Universe of Discourse (UoD) is defined here, a term
that is used throughout the course. The UoD is a concept that students must
fully understand, or they will have significant difficulty in understanding future
topics.
Practice: Examining a Although students are not expected to be knowledgeable about ORM, this
Scheduling Modeling practice has them start thinking as they would if they were modeling in ORM in
Theme any work environment. Encourage them to go through the exercise without
asking for assistance. The goal is to have them come up with as many diverse
answers as possible. Suggested answers are provided at the end of the practice.
Data Modeling This page provides students with a very brief introduction and comparison of
Methodologies the three predominant database modeling methodologies. Students are expected
to be familiar with ER modeling and may have some basic understanding of
UML. You should emphasize that although ER and UML may be familiar,
ORM is the methodology of choice for modeling business requirements that
will ultimately become a Microsoft SQL Server 2000 database.
Practice: Working with This practice begins with an instructor-led demonstration of the Microsoft Visio
Visio Enterprise Enterprise Architect edition modeling tool that will be used in the course.
Architect Edition Students have a chance to see how basic relationships are represented and to
examine the user interface.
The Baseline Database This page shows students the four steps in the baseline database design
Design Process processExternal, Conceptual, Logical, and Physical. Emphasize the concept
of data collection and modeling, rather than immediately working on
implementation. Note that database performance, manageability, and
implementation details are covered in other courses.
Database Design Roles This page introduces the main roles in database modeling and design and
demonstrates how each relates to the steps in the database design process. You
may want to return to the previous slide to emphasize the linear nature of the
process.
Who Are Domain This page introduces the concept of domain experts, the group of people who
Experts? provide business requirements to the modeler. (Note that some students may
refer to these as subject matter experts.)
Business Context as a This page introduces the concept of how the business area being modeled is
Foundation part of the larger context of business recordkeeping. Emphasize that students
are modeling business requirements, as opposed to a database.
Lesson Review
Review each lesson objective and ensure that students have an opportunity to
ask questions. If possible, limit discussion to modeling of business requirements
and try to resist the temptation to talk about implementation or compare
familiar methods of modeling with ORM.
Most of the information presented in this lesson is factual, so it is difficult to
fully assess what students have learned. After answering the questions, allow
students to discuss openly any of the topics covered.
vi Module 1: Introduction to Modeling Business Requirements
Lesson: Data Modeling Concepts

Lesson: Data Modeling This page is an overview of the lesson, outlining critical terms and concepts that
Concepts will be introduced. Provide examples of real-world projects where each concept
might be familiar to students.
Facilitation Instructions After you introduce each topic, provide an opportunity for students to share
(for the Instructor) their personal experiences with related information. Allow for exploration
within the topic. However, do not allow students to digress. Keep the discussion
focused and relevant.
Positioning The purpose of this lesson is to introduce the modeling information levels that
the rest of the course is structured around on a module level.
What Is the Universe of This page introduces the concept of the Universe of Discourseall aspects of
Discourse? the business enterprise that we will talk about during modeling. Re-emphasize
the concept of domain experts and give examples of real-world dialogue that is
required to collect information.
Note Do not present the UoD simply as the scope of the data model. It is
important that students understand that it also implies an ongoing dialog with
domain experts.
What Are Data Use This page explains the concept of data use cases and their relationship to the
Cases? UoD. Remind students that a data use case is an entire document, not a row in a
table or a given data value.
Instances, Populations, This page presents basic definitions for data modeling terminology and
Sets, and Collections introduces a series of slides on set theory. Note that you should reference these
slides when teaching later modules if necessary, to help students understand
how these key terms relate to data modeling.
Data Relationships This slide explains the concepts of cardinality and how one group of data
instances is related to another.
Set Existence This page reviews basic set theory; this content will be referenced many times
in future modules. You might suggest that students create a shortcut or print a
version for desktop use, if possible.
Set Forming Operations This page reviews basic set forming operations and the concept of forming a
new population from one or more sets.
What Are Functional This page introduces the concept of functional dependencies, where one
Dependencies? attribute in a relationship determines another. Solicit other examples from
students to ensure that they grasp this key concept.
Practice: Examining a This page allows students to repeat the practice from the first lesson, but this
Scheduling Modeling time they are armed with the knowledge of what they are looking for,
Theme specifically. As in the first iteration, allow students to work alone and then open
the class up for discussion so that they can share their discoveries.
Module 1: Introduction to Modeling Business Requirements vii
Lesson Review
ask questions.
Most of the information presented in this lesson is factual, so it is difficult to
students to discuss openly any of the topics covered.
Module Review
Most of the information presented in this module is factual, so it is difficult to
students to openly discuss any of the topics covered. Use the lab as another
assessment and discuss answers aloud. Again, point out that there are no
specific right or wrong answers. Many problems can be solved in several
different ways.
Lab A: Examining External Information

Before beginning this lab, students should have completed Module 1 in its
entirety. Make sure that you have adequately answered any questions from the
module prior to beginning. Encourage students to put their paradigms aside
before doing this lab. Think ORM, not ER. Note: Do this lab as a group
exercise. The goal is to start a dialog about data modeling.
Lab Setup
No lab setup requirements affect replication or customization. Slides for this lab
are available at the end of the module slide deck.
Lab Results
No configuration changes on student computers affect replication or
customization.
Module 1: Introduction to Modeling Business Requirements 1
Module Overview
! Overview of Database Modeling Process

! Data Modeling Concepts

Introduction In business today, organizations must accept ever changing details and
situations as part of everyday work. Modeling can be a valuable asset. By using
a database model, database administrators can test configurations without
changing a working database, modify the model to reflect a recent change in
business requirements and verify this change with subject matter experts in the
business, thereby allowing the language of business to drive the design of a
database. Data modeling lets you reflect the complex structures of a business
environment.
Module purpose In this module, you will learn the fundamental procedures of database
modeling. This module provides a high-level overview of the process, before
teaching you the individual steps.
Objectives After completing this module, you will be able to:
! Describe the process of modeling business requirements.
Summarize the process of modeling a baseline database model.
Summarize data modeling concepts.
2 Module 1: Introduction to Modeling Business Requirements
Lesson: Overview of Database Modeling Process
! Practice: Examining a Scheduling Modeling Theme

! Data Modeling Methodologies
! Practice: Working with Visio Enterprise Architect
Edition
! The Baseline Database Design Process
! Database Design Roles
! Who Are Domain Experts?
! Business Context as a Foundation

Introduction All successful endeavors start with a plan. If you build a school, it is unlikely
that you will be able to undertake every task and responsibility yourself. You
would first undertake research and make decisions about what type of building
you wanted, and then you would have an architect draft a blueprint.
You should create a database in the same manner: Plan first, and then build it.
Lesson purpose The purpose of this lesson is to introduce you to the concept of modeling
business requirements prior to the creation of a database, identify the main
methodologies and roles involved, and gain experience by using the Microsoft
Visio Enterprise Architect edition design tool.
Lesson objectives After completing this lesson, you will be able to:
! Summarize the process of modeling a baseline database model.
Identify the three major database modeling methodologies.
Describe the process of modeling business requirements.
Describe the roles of those involved in data modeling.
Practice: Examining a Scheduling Modeling Theme
! Purpose
! Scenario
! Practice
Mon Tue Wed Thu Fri
8 am
Out of Office:
9 00 Manager Doctors Appt
1:1 All-han
10 00 Team Quaterl
Meeting Meetin Off-sit
11 00 Traini
Brownbag Class
12 pm Lunch: ORM
1 00
Data Data
Modeling Modeling
2 00 Project Project
3 00
4 00
5 00

Introduction In this practice, you will examine a sample of information related to a database
modeling scenario.
Purpose The purpose of this practice is to have you examine information and look for
elements that you think would be modeled in a database.
Scenario You are assigned the task of modeling the information contained in Figures 1.1
and 1.2. You have not been told what the information in the figures represents,
or what the database model will represent.
Mon Tue Wed Thu Fri
8 am
Out of Office:
9 00 Doctors Appt
Manager
1:1 All-ha
10 00 Quart
Team
meeting Meeti
11 00
Off sit
pm Brownbag Traini
12 lunch: ORM Class
1 00
Data Data
00 Modeling Modeling
2 Project Project
3 00
4 00
5 00
Figure 1.1
Appointment
Appointment time
time Location
Location
ID
ID Meeting
Meeting subject
subject Duration
Duration Recurring
Recurring
Weekday
Weekday Hour
Hour Building
Building Room
Room
11 Mon
Mon 10:30
10:30 Team
Team Meeting
Meeting 27
27 Conf
Conf AA 1.0
1.0 Yes
Yes
22 Tue
Tue 9:30
9:30 Manager
Manager 1:11:1 27
27 246
246 1.0
1.0 Yes
Yes
33 Tue
Tue 12:00
12:00 Brownbag
Brownbag Lunch:
Lunch: ORM
ORM 117
117 101
101 1.0
1.0 No
No
44 Tue
Tue 1:30
1:30 Data
Data Modeling
Modeling Project
Project 62
62 151
151 2.5
2.5 Yes
Yes
55 Wed
Wed 1:30
1:30 Data
Data Modeling
Modeling Project
Project 62
62 151
151 2.5
2.5 Yes
Yes
66 Thu
Thu 10:00
10:00 All-hands
All-hands Quarterly Meeting
Quarterly Meeting 117
117 101
101 1.5
1.5 No
No
77 Thu
Thu 11:00
11:00 Offsite
Offsite Training
Training Class
Class NA
NA NA
NA 5.0
5.0 No
No
88 Fri
Fri 9:00
9:00 Out
Out of
of Office:
Office: Doctor
Doctor Apt
Apt NA
NA NA
NA 2.5
2.5 No
No
Figure 1.2
Practice Carefully examine the information and perform the following tasks.
! Determine the scope of the sample

Determine what the database model will represent. Refer to Figures 1.1 and 1.2
to answer the following questions.
1. Describe what the information represents and the aspects of it that you
would discuss and model.
It appears that the information is related to a Microsoft Outlook
calendar, representing meetings or appointments in a variety of
locations.
____________________________________________________________
____________________________________________________________
2. Describe any further information that you would need to fully model the
scenario.
What does reoccurring mean? The calendar is for one week; what
about other weeks? What do different colors mean that are on the left
border of appointments? Who organizes meetings? Who is invited to
meetings?
____________________________________________________________
____________________________________________________________
3. Describe the sources that you would use to gather the needed information.
Check with the owner of the calendar, the organizers of meetings,
invitees to meetings, and the resources mentioned in the meetings.
____________________________________________________________
____________________________________________________________
4. In a class discussion, compare and contrast your individual answers.

! Identify things of interest and relationships

Identify data elements that may be included in the database model. Refer to
Figures 1.1 and 1.2 to answer the following questions.
1. List all of the things of interest.
Meetings, Times, Subjects, Locations, Buildings, and Rooms
____________________________________________________________
____________________________________________________________
2. Consider the things of interest that you noted in the last question. Which
ones of them describe others?
Subjects describe what a meeting is about.
Buildings and rooms describe a location.
____________________________________________________________
____________________________________________________________
3. Describe the relationships between the things of interest.

Meetings take place in a building and a room.
Meetings are about a given subject.
____________________________________________________________
____________________________________________________________

Data Modeling Methodologies
Entity Relationship
diagrams Parent Child
Figure 1.3
Unified modeling language

1 *
Parent Child
Figure 1.4
Object role modeling

Parent Child
Figure 1.5

Introduction Several current modeling methodologies simplify the process of modeling
business requirements for databases. Each has been used effectively in many
types of businesses.
Entity Relationship Entity Relationship (ER) modeling was introduced in 1976 and is still the most
diagrams widely used approach for data modeling. It pictures the world in terms of
entities that have attributes and participate in relationships. ER modeling often
requires that the modeler make decisions about the relative importance of
attributes early in the data modeling process.
For example, Figures 1.6 and 1.7 both represent the same information,
portraying the relationships between rooms, subjects, and time slots. Compare
the two figures and notice that the modeler has made an arbitrary decision on
how to combine the Subject and Room entities to define a time slot.
Figure 1.6
Room
PK RoomNumber
Subject
PK SubjectName
has
RoomTimeSlot
PK,U1 TimeSlot uses

PK,FK1 RoomNumber
FK2,U1 SubjectName
Figure 1.7
Unified Modeling Unified Modeling Language (UML) is an object-oriented approach that

Language encapsulates both data and behavior within objects. Although it is used mainly
for designing code for object-oriented programs, it can also be used for
modeling a database. UML does not always facilitate the modeling of all
business rules or constraints.
Using the same data as the previous example, the diagram in Figure 1.8 also
portrays the relationships between rooms, subjects, and time slots. The UML
diagram, however, does not portray valid unique combinations of rooms,
subjects, and times.
Time
dayHour
Room 0..1 0..1 Subject
roomNumber subjectName
Usage
Figure 1.8
Object Role Modeling Object Role Modeling (ORM) is the only fact-oriented method with significant
support in the industry. ORM began in the early 1970s as a semantic modeling
approach that views the world simply in terms of objects playing roles (parts in
relationships). ORM is a rich modeling methodology that allows for the
modeling of complex fact-driven, data-related business requirements.
For example, the diagram in Figure 1.9 also portrays the relationships between
rooms, subjects, and time slots. In addition, it models constraints that only
allow unique room and time combinations, and unique combinations of time
and subjects.
Time
(Slot)
Room Subject
(Number) (Name)
...at...is used for...
Figure 1.9
Practice: Working with Visio Enterprise Architect Edition
! Purpose
! Scenario
! Practice

Introduction In this practice, you will examine sample data models by using Visio Enterprise
Architect edition, which is included in Microsoft Visual Studio .NET
Enterprise Architect edition.
Purpose The purpose of this practice is to have you examine information and look for
elements that you think would be modeled in a database. Do not worry about
the end results at this time. You will have many different answers.
Scenario You have just been introduced to a new data modeling tool. You will become
familiar with the tool by:
! Examining an ORM diagram and the ORM related functionality of the tool.
! Examining an ER diagram that was generated by the tool and the ER related
functionality.
! Setting the default database driver to SQL Server for the tool.
! Examining a tool-generated Transact-SQL Data Definition Language (DDL)
script and executing the script.
Practice Carefully examine the information and perform the following tasks in Visio.
! Examine an ORM model

1. On the taskbar, click Start, point to All Programs, and then click
Microsoft Visio.
2. In the Visio window, on the File menu, click Open. In the File name box,
type C:\MOC\2090\Practices\Mod01\ExamineORM.vsd and then click
Open.
3. Close the ORM Source window.
4. On the Database menu, point to View, and then click Business Rules.
5. On the View menu, point to Zoom, and then click 150%.
6. Close the ExamineORM.vsd file.
! Examine an ER model
1. In the Visio window, on the File menu, click Open. In the File name box,
type C:\MOC\2090\Practices\Mod01\ExamineER.vsd and then click
Open.
2. On the Database menu, point to View, and then click Code.
3. On the Database menu, point to View, and then click Tables and Views.
4. In the Tables and Views window, double click Meeting.
Notice that on the drawing surface, the shape labeled Meeting is now
selected.
5. On the Database menu, point to Options, and then click Document.
6. In the Database Document Options dialog box, on the Relationship tab,
select Crows feet and then click OK.
! Designate Microsoft SQL Server as the default database driver

1. On the Database menu, point to Options, and then click Drivers.
2. In the Database Drivers dialog box, on the Drivers tab, in the Default
driver for Visio pane, click Microsoft SQL Server, and then click OK.
! Examine a generated Transact-SQL DDL script

1. On the taskbar, click Start, point to All Programs, Microsoft SQL Server,
and then click Query Analyzer.
2. In the Connect to SQL Server dialog box, in the SQL Server box, type
(local) and then click OK.
3. In the SQL Query Analyzer window, on the File menu, click Open. In the
File name box, type C:\MOC\2090\Practices\Mod01\ExamineER.DDL
and then click Open.
4. Review the Transact-SQL DDL script in the Query Analyzer window.
5. On the Query menu, click Execute.
6. Close all open windows.
The Baseline Database Design Process
Modeling
Modelingbusiness
businessrequirements
requirements Modeling
Modelingdatabases
databases
External
External Conceptual
Conceptual Logical
Logical Physical
Physical
Figure 1.10

Introduction In this course, you will follow a methodology to create a baseline database
design. The methodology has two principal stages.
Modeling business The process of collecting, analyzing, and modeling a database begins with an
requirements analysis of the business requirementsin the language of domain experts,
rather than in technical terms. This stage has two phases:
! External modeling phase
When you create a data model, you organize information that exists in the
real worldsuch as forms, reports, and graphsalong with information on
how they are used in a business activity.
! Conceptual modeling phase
Conceptual models describe data requirements from a business point of
view, without implementation details. All later modeling phases are
implementations of a conceptual model.
Modeling databases After you have captured all business requirements in a conceptual model, you
generate a relational database model. This stage also has two phases:
! Logical modeling phase
A relational logical model is the representation of business requirements in
terms of tables, columns, and relationshipsa direct translation from the
conceptual model, without adding any physical characteristics.
! Physical modeling phase
The baseline physical database schema is a refinement of the logical model
that specifies SQL Server physical characteristics such as names, physical
data types, and procedural Transact-SQL code. A baseline physical database
schema is not optimized for performance or manageability.
Database Design Roles
External and Logical Physical

Conceptual
Principal Domain experts Modeler Developer

database
design roles Modeler Developer Modeler
Focus Capture Document Implement

business relational relational
requirements design design
Modeling ORM ER Transact-SQL
methodology DDL
Figure 1.11

Introduction At each of the phases in modeling a database, the focus, roles, and modeling
methodology change. It is important to understand what the objective of each
modeling phase is, and who should be involved.
Focus At the External and Conceptual phases, the focus is on working with domain
experts to capture and validate business requirements accurately.
At the Logical phase, the focus shifts to documenting a relational database
design that represents the conceptual business requirements in a manner that
developers can understand.
At the Physical phase, the focus should be on implementing a platform-specific
schema that facilitates the development of applications.
Principal database As the modeling process progresses, you must involve all members of the
design roles database design team. During each phase, some roles are more actively
involved than others. It is possible that a specific person might function in more
than a single role.
You will work mainly with domain experts who have authoritative knowledge
of the business requirements during the External and Conceptual phases.
During the Logical modeling phase, you should consult with application
developers to ensure that your relational model is understandable and can be
implemented.
The physical schema represents a specific implementation of the logical model.
Work with developers and analysts who will use it to make sure that it meets
their needs.
Modeling methodology You will use ORM to model business requirements during the Conceptual
phase.
You will use a relational form of ER modeling to generate a logical database
model.
You will use Transact-SQL DDL to represent a physical database schema for
SQL Server.
Who Are Domain Experts?
! Definition
Domain experts are the people who provide business
requirements to the modeler
! Examples
" Subject matter experts
" Knowledge workers
" Business analysts
" System architects
" Developers

Introduction A data modeler typically does not know all of the business requirements for a
given situation. Unless the data modeler is actually doing the work that the
database will support, he or she does not have direct experience with the
business requirements. To accurately model the business, the modeler needs to
gather information from individuals who are expert in the business area that the
database will support.
Definition Domain experts are the people who provide business requirements to the
modeler.
Examples These are the experts in particular aspects of the domain of business
requirements:
! Subject matter experts (SMEs). Understand an area of the business and its
data and the data-related business requirements. They know how things are
done in the business.
! Knowledge workers. Have direct knowledge of how and why data is
recorded and used. These front-line workers know how data gets into the
system.
! Business analysts. See the whole picture of the business that includes many
SMEs and knowledge workers.
! System architects. Understand how front-end and back-end IT systems
communicate data. They know the meaning of data passed between systems
and how things are set up.
! Developers. Implement business logic while developing applications. They
know how existing systems are implemented.
Business Context as a Foundation
Business Area Provides Context
Record Keeping
Mon Tue Wed Thu Fri
8 am
9 00 Out of Office: Monetary

MonetaryValue
Valueof
ofInventory
Inventoryby
byPercentage
Percentage
Manager Doctors Appt
1:1 All-han Ex cel Mo nthly Home
HomeMMaga
agazine
10 00 Quaterl
Excel Monthly zine
Team
M eeting Meetin Off-sit
11 00 Traini
8%
8% 17%
Eb ony MMacin
Ebony acintosh
toshApples
Apples
17%
Class
12 pm Brownbag 11%
11%
Lunch: ORM Po rtsmou thhChablis
Portsmout C hablisWine
Wine
1 00
Data D ata Fa st Gold
Fast en Raisins
Golden Raisins
Modeling Modeli ng
11%
11%
2 00
Project Project
Be tter Cr
Better eamed Corn
Creamed Corn
3 00
22%
22% De nny TToilet
Denny oilet Paper
Paper
4 00
15%
15%
00 Bir d Call
Bird CallTartar
Tar tarContro l
Control
5 To othpaste
10%
10% 6%
6% Toothp aste
Mu sial MMint
Musial int Chocolate Bar
C hocolate Bar
Appointment
Appointmenttime
Appointment
Appointment time
time
time Location
Location
Location
Location
ID
ID
ID
ID Meeting
Meeting
Meetingsubject
Meeting subject
subject
subject Duration
Duration Recurring
Duration
Duration Recurring
Recurring
Recurring
Weekday
Weekday Hour
Weekday
Weekday Hour
Hour
Hour Building
Building
Building
Building Room
Room
Room
Room
1111 Mon
Mon
Mon
Mon 10:30
10:30
10:30
10:30 Team
TeamMeeting
Team
Team Meeting
Meeting
Meeting 27
27
27
27 Conf
ConfAAA
Conf
Conf 1.0
1.0
1.0
1.0 Yes
Yes
Yes
Yes
2222 Tue
Tue
Tue
Tue 9:30
9:30
9:30
9:30 Manager
Manager1:1
Manager
Manager 1:1
1:1
1:1 27
27
27
27 246
246
246
246 1.0
1.0
1.0
1.0 Yes
Yes
Yes
Yes
3333 Tue
Tue
Tue
Tue 12:00
12:00
12:00
12:00 Brownbag
BrownbagLunch:
Brownbag
Brownbag Lunch:ORM
Lunch:
Lunch: ORM
ORM
ORM 117
117
117
117 101
101
101
101 1.0
1.0
1.0
1.0 No
No
No
No
4444 Tue
Tue
Tue
Tue 1:30
1:30
1:30
1:30 Data
DataModeling
Data ModelingProject
Modeling
Modeling Project
Project
Project 62
62
62
62 151
151
151
151 2.5
2.5
2.5
2.5 Yes
Yes
Yes
Yes
5555 Wed
Wed
Wed
Wed 1:30
1:30
1:30
1:30 Data
DataModeling
Data ModelingProject
Modeling
Modeling Project
Project
Project 62
62
62
62 151
151
151
151 2.5
2.5
2.5
2.5 Yes
Yes
Yes
Yes
6666 Thu
Thu
Thu
Thu 10:00
10:00
10:00
10:00 All-hands
All-handsQuarterly
All-hands
All-hands QuarterlyMeeting
Quarterly
Quarterly Meeting
Meeting
Meeting 117
117
117
117 101
101
101
101 1.5
1.5
1.5
1.5 No
No
No
No
7777 Thu
Thu
Thu
Thu 11:00
11:00
11:00
11:00 Offsite
OffsiteTraining
Offsite
Offsite TrainingClass
Training
Training Class
Class
Class NA
NA
NA
NA NA
NA
NA
NA 5.0
5.0
5.0
5.0 No
No
No
No
8888 Fri
Fri
Fri
Fri 9:00
9:00
9:00
9:00 Out
Outof
Out
Out ofOffice:
of
of Office:Doctor
Office:
Office: DoctorApt
Doctor
Doctor Apt
Apt
Apt NA
NA
NA
NA NA
NA
NA
NA 2.5
2.5
2.5
2.5 No
No
No
No
SQL
Figure 1.12

Introduction It is critical that the process of modeling business requirements for a database
begins with establishment of a clear understanding of the business area under
consideration.
Business area provides The business area that you are modeling provides the context for the facts that
context will be recorded in the final database. This is the entire area of responsibility for
the business unit, including both things that are in the database and things that
are not. Business analysts assist the modeler by interpreting the business area
and helping to formalize the business requirements in a conceptual model.
Important The primary goal of the modeling process is to properly model

business requirements. Remember that ORM does not model databasesit
models business requirements.
Record keeping Within the business area, record keeping is really about recording data.
Database solutions automate record keeping. For a given data model, the set of
sample documents that the domain experts provide defines the scope of the data
that is modeled and, ultimately, stored in the database.
Lesson Review
Objectives
Objectives
Summarize
Summarizethe
theprocess
process of
ofmodeling
modelingaabaseline
baseline
database
databasemodel
model
Identify
Identifythe
the three
three major
majordatabase
databasemodeling
modeling
methodologies
methodologies
Describe
Describethe
the process
processof
of modeling
modeling business
business
requirements
requirements
Describe
Describethe
the roles
rolesof
of those
thoseinvolved
involvedin
indata
data
modeling
modeling

1. What are the primary uses of each of the three major data modeling
methodologies?
ERModel relational data at the logical level in terms of entities and
attributes and their relationships
UMLDesign code for object-oriented programming
ORMModel complex fact-driven, data-related business requirements
2. Describe the four stages in modeling business requirements.

ExternalOrganize information that exists in the real world
ConceptualDescribe data requirements from a business point of view
LogicalRepresent business requirements in terms of tables and
columns and relationships
PhysicalRefine the logical model that specifies physical
characteristics
3. Describe the process of modeling a baseline database model.

Create a conceptual model of business requirements by using ORM,
create a relational logical model of these business requirements, and
then generate a physical database schema.
Lesson: Data Modeling Concepts
! What Is the Universe of Discourse?

! What Are Data Use Cases?
! Instances, Populations, Sets, and Collections
! Data Relationships
! Set Existence
! Set Forming Operations
! What Are Functional Dependencies?
! Practice: Examining a Scheduling Theme

Introduction Accurately describing the data to be modeled is critical to the creation of a
successful database project. In this lesson, you will learn how to describe what
is (and what is not) being modeled, how set theory and operations are
described, and how to determine relationships between sets of data.
Lesson purpose The purpose of this lesson is to understand the key elements in modeling
business requirements for a database and review basic set theory and
operations.
! Summarize data modeling concepts.
Describe the Universe of Discourse (UoD).
Describe data use cases.
Distinguish between different set characteristics.
Describe functional dependencies.
What Is the Universe of Discourse?
! Definition
The Universe of Discourse is all aspects of the world that
you want to talk about that will be automated
! Characteristics
" Is determined by domain experts
" Represents the scope of data model
" Implies either an open or a closed model

Introduction When you create a database, you are typically doing so to solve a real-world
problem. To understand the problem, you must talk to domain experts.
Definition The Universe of Discourse (UoD) is all aspects of the world that you want to
talk about that will be automated. It is the scope of automated record keeping.
Characteristics Remember the following three key characteristics about the UoD:
! Business managers and domain experts determine the UoD.
Business managers have the responsibility and domain experts have the
authoritative knowledge of the business area. They are the only ones who
can determine what is in (and out) of the UoD (scope of the automated
record keeping system). You must have an ongoing dialog, through the
modeling process, to validate that you properly capture the UoD.
! The UoD represents the scope of the data model.
All business requirements that you could model are either included or
excluded from the UoD. To be successful, you must have a clear
understanding what is in and out of scope.
Important Do not view the UoD as simply a question of what is in or out of

scope. The UoD also implies an ongoing dialog with domain experts and
business decision-makers.
! It is either an open or a closed model.

Through the course of modeling, decisions are made about what to include
in the UoD. If the modeler knows everything there is to know about the
UoD, they are said to be working with a closed model. If it is possible that
the UoD may be expanded during or after the modeling process, they are
said to be working with an open model.
Tip When communicating with domain experts, make sure that all parties
agree whether the model is open or closed.
What Are Data Use Cases?
! Definition
A data use case is a snapshot of data values and their
relationships in the UoD as contained in some existing
or proposed business document
! Characteristics
" Provided by domain experts
" Represent business facts and requirements

Introduction A conceptual data model represents valid states of data within the UoD. The
best way to understand the UoD is to understand familiar examples of data
being used.
Definition A data use case is a snapshot of data values and their relationships in the UoD
as contained in some existing or proposed business document. Examples of data
use cases include reports, forms, graphs, and any other type of document that
contains information within the UoD.
Note An entire document is considered a data use case, not just a given data
value. It shows a case of a group of data values being used together. It provides
the context of meaning for the data values.
Characteristics There are two key characteristics of data use cases:

! Provided by domain experts
To be valid, data use cases must be provided by a domain expert. The
domain expert must be familiar with the data use case and be able to explain
it and answer any questions that the modeler may have.
! Represent business facts and requirements
Data uses cases represent business facts and requirements and imply
constraints on how information in them can be modeled. The data model
must accommodate the aggregate effect of all data uses cases in the UoD.
Instances, Populations, Sets, and Collections
! Instance Population
! Population A C E
! Set B D
Figure 1.13
! Member
! Collection Collection
C E
A D
A D
Figure 1.14

Introduction This topic establishes basic definitions for data modeling terminology, which
will be referenced in the remainder of the course. These will be critical to
success in understanding and modeling business requirements.
Instance An instance is a single example of a thing of interest in the UoD. In database
terms, an instance is a single data value or row in a table.
For example, the individual hexagon shapes in Figures 1.13 and 1.14 each
represent instances.
Population All combined instances of a given type of thing of interest in the UoD are
known as that things population. In database terms, all rows in a table make up
that tables population.
For example, the combination of all of the instances in Figure 1.13 makes up a
population.
Set A set is any group of instances, but it is not necessarily the same as a
population. A set could be part of a population, or a combination of instances
from more than one population. All populations are sets, but not all sets are
populations.
Member Each instance in a set or population is said to be a member of that set or
population.
For example, each instance in Figure 1.13 is considered a member of the larger
population.
Collection A collection of instances is simply another term for a set, with the added
connotation that members of the set are all instances of a single thing of interest
in the UoD.
For example, the collections of instances in Figure 1.14 form a set that was
created from an instance of the population in Figure 1.13. Notice that there are
duplicate instances in the collection.
Data Relationships
1:1
! Cardinality
A B
" One-to-one (1:1)
Figure 1.15
" One-to-many (1:n)
1:n
" Many-to-many (n:m) B
! Mandatory vs. optional A B
cardinality
B
Figure 1.16
n:m
A B
B
A B
Figure 1.17

Introduction The domain expert will provide information on how one group of data instances
is related to another. You need to identify these relationships in terms of basic
ratios.
Cardinality If you consider two correlated populations, cardinality describes the minimum
and maximum number of occurrences of a given instance in each population.
There are three basic types of cardinality phrases to consider:
! One-to-one (1:1)
For each instance in one population, there is exactly one instance in another.
! One-to-many (1:n)
For each instance in one population, there may be more than one duplicate
instance in another.
! Many-to-many (n:m)
Each instance in one population may be a duplicate, and there may be more
than one correlated duplicate instance in another.
Mandatory vs. optional With respect to cardinality, mandatory cardinality implies that at least one
cardinality instance is involved on a given side of a relationship. Optional cardinality
implies that an instance could exist in one population that does not have a
correlated instance in another population. Optional cardinality is expressed by
introducing the word zero in the cardinality phrase, such as one to zero or
one, zero or one to many.
For example, the relationships depicted in Figures 1.15, 1.16, and 1.17 all
portray mandatory cardinality. If you removed all of the B instances from any
of the figures, that figure would then depict a form of optional cardinality.
Set Existence
Mutual exclusion Overlap
A B
A B
Figure 1.18 Figure 1.19
Identity Subset
A B A B

Introduction Nearly every step of the data modeling process relates to how you will model
populations and their relationships with one another. You must understand how
sets exist in relation to one another to model effectively.
Mutual exclusion Two sets are mutually exclusive of one another if and only if no member exists
in both sets. Figure 1.18 indicates that set A does not share any members with
set B.
Table 1.1
Set A Set B
{1,2} {3,4}
{apple, orange} {pear, banana}
Overlap Two sets exhibit overlap if and only if they share at least one member in
common, and they both have at least one other member unique to the set.
Figure 1.19 indicates that set A shares a member with set B, that both sets A
and B each contain at least one other member, and that those other members
each are unique to set A and B, respectively.
Table 1.2
Set A Set B
{1,2,3} {2,3,4}
{apple, orange, pear} {orange, pear, banana}
Identity Two sets are identical if and only if they each contain all of the same members.
Figure 1.20 indicates that set A and set B are identical in all respects.
Table 1.3
Set A Set B
{1,2,3,4} {1,2,3,4}
{apple, orange, pear, banana} {apple, orange, pear, banana}
Subset A set is a subset of another set if and only if all of the first sets members exist
in the second set. Figure 1.21 indicates that all of set As members are also
contained in set B.
Table 1.4
Set A Set B
{1,2} {1,2,3,4}
{apple, orange} {apple, orange, pear, banana}
Set Forming Operations
Union of sets X Y
XUY
Figure 1.22
Intersection of sets X Y
U
X Y
Figure 1.23
Difference of sets X Y
X-Y
Figure 1.24

Introduction You can perform set operations involving one or more sets to form new
populations. The resulting population is a new set in its own right.
Union of sets The unique combination of all of the members in two or more sets is known as
a union of sets. Figure 1.22 illustrates that a new set is formed when the unique
combination of members in set X and set Y are combined, as indicated by the
shaded area.
Table 1.5
Set X Set Y Union of sets
{40, 50} {50, 60, 70} {40, 50, 60, 70}

{car, train, bus} {train, bus, airplane} {car, train, bus, airplane}
Intersection of sets The members that two or more sets have in common are known as an
intersection of sets. Figure 1.23 illustrates that a new set is formed when all
members that are not held in common with set X and set Y are removed, as the
shaded area indicates.
Table 1.6
Set X Set Y Intersection of sets
{40, 50} {50, 60, 70} {50}

{car, train, bus} {train, bus, airplane} {train, bus}
Difference of sets If the common members of one set and another are removed from the first set,
the remaining members of the first set are known as the difference of those sets.
Figure 1.24 illustrates that a new set is formed when all members of set Y,
including those that also exist in set X, are removed from set X, as the shaded
area indicates.
Table 1.7
Set X Set Y Difference of set Y from set X
{40, 50} {50, 60, 70} {40}

{car, train, bus} {train, bus, airplane} {car}
What Are Functional Dependencies?
! Definition
A population is functionally dependent on another if, for
every instance in the latter population, there is exactly
one instance in the former
! Characteristics
" One population is determined by another
" Instances in the parent population are unique

Introduction A functional dependency occurs when one data value in a relationship
determines the other data value or values. Functional dependencies are
important in data modeling, because they allow you to identify fundamental
relationships in the UoD.
Definition A population is functionally dependent on another if, for every instance in the
second population, there is exactly one instance in the first population.
Characteristics Functional dependencies have two key characteristics:
! One population is determined by another.
Functional dependencies represent parent-child relationships between
populations. A child instance cannot exist without a parent instance.
For example, mathematically, the notation y = f(x) indicates that y is a
function of x, or that y is functionally dependent on x.
! Instances in the parent population are unique.
Functional dependencies represent a one-to-many (1:n) relationship between
instances in the parent population and instances in the child population. The
implication is that instances in the parent population are unique.
Practice: Examining a Scheduling Theme
! Purpose
! Scenario
! Practice
Mon Tue Wed Thu Fri
8 am
Out of Office:
9 00 Manager Doctors Appt
1:1 All-han
10 00 Quaterl
Team
11 00 Traini
Brownbag Class
12 pm Lunch: ORM
1 00
Data Data
2 Project Project
3 00
4 00
5 00

Introduction In this practice, you will re-examine a sample of information related to a
database modeling scenario that was presented at the beginning of the module.
Purpose The purpose of this practice is to examine information and look for elements
that would be modeled in a database, by using the terminology and concepts
present in this module.
Scenario You are assigned the task of modeling the information contained in Figures 1.1
and 1.2. You have not been told what the information in the figures represents,
or what the database model will represent.
Mon Tue Wed Thu Fri
8 am
Out of Office:
9 00 Doctors Appt
Manager
1:1 All-ha
10 00 Quart
Team
meeting Meeti
11 00
Off sit
Brownbag Traini
12 pm lunch: ORM Class
1 00
Data Data
2 Project Project
3 00
4 00
5 00
Figure 1.1
Appointment
Appointment time
time Location
Location
ID
ID Meeting
Meeting subject
subject Duration
Duration Recurring
Recurring
Weekday
Weekday Hour
Hour Building
Building Room
Room
11 Mon
Mon 10:30
10:30 Team
Team Meeting
Meeting 27
27 Conf
Conf AA 1.0
1.0 Yes
Yes
22 Tue
Tue 9:30
9:30 Manager
Manager 1:11:1 27
27 246
246 1.0
1.0 Yes
Yes
33 Tue
Tue 12:00
12:00 Brownbag
Brownbag Lunch:
Lunch: ORM
ORM 117
117 101
101 1.0
1.0 No
No
44 Tue
Tue 1:30
1:30 Data
Data Modeling
Modeling Project
Project 62
62 151
151 2.5
2.5 Yes
Yes
55 Wed
Wed 1:30
1:30 Data
Data Modeling
Modeling Project
Project 62
62 151
151 2.5
2.5 Yes
Yes
66 Thu
Thu 10:00
10:00 All-hands
All-hands Quarterly Meeting
Quarterly Meeting 117
117 101
101 1.5
1.5 No
No
77 Thu
Thu 11:00
11:00 Offsite
Offsite Training
Training Class
Class NA
NA NA
NA 5.0
5.0 No
No
88 Fri
Fri 9:00
9:00 Out
Out of
of Office:
Office: Doctor
Doctor Apt
Apt NA
NA NA
NA 2.5
2.5 No
No
Figure 1.2
Practice Carefully examine the information in the scenario and perform the following
tasks.
! Determine the UoD for the modeling scenario

Determine what the database model will represent. Refer to Figures 1.1 and 1.2
to answer the following questions.
would talk about and model.
It appears that the information is related to an Outlook calendar,
representing meetings or appointments.
____________________________________________________________
____________________________________________________________
scenario.
What does reoccurring mean? The calendar is for one week; what
about other weeks? What do different colors mean that are on the left
border of appointments? Who organizes meetings? Who is invited to
meetings?
____________________________________________________________
____________________________________________________________
Check with the owner of the calendar, the organizers of meetings,
invitees to meetings, and the resources mentioned in the meetings.
____________________________________________________________
____________________________________________________________

! Identify populations and relationships

Figures 1.1 and 1.2 to answer the following questions.
1. List all of the sets or populations represented.
Meetings, Times, Subjects, Locations, Buildings, and Rooms
____________________________________________________________
____________________________________________________________
2. Consider the sets or populations that you noted in the last question. Which
of them describes another?
Subjects describe what a meeting is about.
Buildings and rooms describe a location.
____________________________________________________________
____________________________________________________________
3. Describe the relationships between the sets or populations.

Meetings take place in a building and a room.
Meetings are about a given subject.
____________________________________________________________
____________________________________________________________

Lesson Review
Objectives
Objectives
Summarize
Summarizedata
datamodeling
modeling concepts
concepts
Describe
Describethe
the Universe
Universeof
of Discourse
Discourse
Distinguish
Distinguish between
betweendifferent
differentset
set characteristics
characteristics
Describe
Describefunctional
functionaldependencies
dependencies

1. Define the UoD.
The UoD is all aspects of the world that you want to talk about. The
three characteristics of the UoD are: 1) It is determined by the domain
expert, 2) It represents the scope of the data model, and 3) It implies
either an open or closed data model.
2. Identify the set characteristics of each of the following examples.

The set of all dogs and the set of all cats.
The populations are mutually exclusive.
The set of all Dalmatians and the set of all dogs.

The Dalmatian population is a subset of the population of all dogs.
The set of all vaccinated dogs and the set of Dalmatians, including those
that are vaccinated and those that are not.
The population of vaccinated dogs overlaps with the population of all
Dalmatians.
Module Review
! Overview of Database Modeling Concepts

! Data Modeling Concepts

1. In the scheduling theme, are rooms functionally dependent on buildings?
Yes. Because each building has one or more rooms, such as a 1:n
relationship, and a room cannot exist without a building.
2. What is the difference between a row and a column in a table in relation to

instances and sets?
A row is analogous to an instance, and all rows makes up a table's
population.
3. How is modeling business requirements different from modeling a

database?
Modeling business requirements engages domain experts who provide
data use cases and facts that represent the UoD. There is no need to
consider implementation details at this stage.
Database modelers model the relational implementation of business
requirements. The database model is a translation of the business
requirements as tables, columns, and procedural code.
Lab A: Examining External Information
! Exercise 1: Examining an Airline Flights

Theme
! Exercise 2: Examining an Academic
Faculty Theme

Introduction In this lab, you will examine and discuss three modeling themes to evaluate the
external information presented by each.
Objectives After completing this lab, you will be able to:
! Examine samples of external information.
! Identify aspects of the UoD from samples of external information.
! Identify populations, sets, and their relationships from samples of external
information.
Prerequisites Before working on this lab, you must have:

! Knowledge of the phases of data modeling, specifically, what is external
information.
! Knowledge about what the UoD represents.
Scenario A separate database modeling scenario is presented in each lab exercise in the
form of samples of external information.
In each exercise, you will examine the samples of external information related
to the scenario and identify preliminary elements of a data model for future
consideration.
These exercises lay the foundation for future discussions, practices, and
exercises that use these same scenarios throughout this course.
Estimated time to You should complete each exercise in approximately 20 to 25 minutes.
complete this lab:
45 minutes
Exercise 1
Examining an Airline Flights Theme
In this exercise, you will examine samples of external information related to a
scenario, and identify preliminary elements of a database model for future
consideration.
Scenario You are assigned the task of modeling the external information contained in
Figures 1A.1 and 1A.2. You have not been told what the information in the
figure and table represents, or what the database model will represent.
London
UK11 (LHR)
US72
IT37
New York
Madrid Rome
(JFK)
ES23 (MAD) (FCO)
Atlanta US56
VE56
(ATL)
VE59
US68 Dakar
VE56
(DKR)
Caracas
(CCS)
Figure 1A.1
Figure 1A.1 contains sample data values that are correlated to the information
represented by Figure 1A.2.
Flight Origination Destination Departure

Departure info
info
Flight Origination Destination Status
Status
number
number city
city city
city Terminal
Terminal Gate
Gate Time
Time
UK11
UK11 London
London New
New York
York 33 55 14:25
14:25 On
On Time
Time
US72
US72 New
New York
York London
London 4E
4E 19
19 1:55
1:55 Delayed
Delayed
IT37
IT37 Rome
Rome New
New York
York Intl
Intl 12
12 11:12
11:12 Boarding
Boarding
ES23
ES23 Madrid
Madrid Atlanta
Atlanta 33 55 11:12
11:12 On
On Time
Time
US56
US56 Atlanta
Atlanta Rome
Rome TT 99 23:50
23:50 On
On Time
Time
VE59
VE59 Caracas
Caracas New
New York
York Intl
Intl 22 8:03
8:03 Cancelled
Cancelled
VE56
VE56 Caracas
Caracas Rome
Rome Intl
Intl 44 8:48
8:48 On
On Time
Time
US68
US68 Atlanta
Atlanta Caracas
Caracas TT 88 4:54
4:54 Boarding
Boarding
Figure 1A.2
Tasks Carefully examine the information in the scenario and perform the following
tasks.

Determine what the database model will represent. Refer to Figures 1A.1 and
1A.2 to answer the following questions.
It appears that the information is related to the status of airline flights,
including route and departure information.
____________________________________________________________
____________________________________________________________
scenario.
What do the three-letter codes below city names represent? What do
the lines between cities represent? What to the arrow tips on the lines
represent? Is there a relationship between flight numbers and the point
of origin of the flights, or with the direction of travel?
____________________________________________________________
____________________________________________________________
Check with whoever provided the information, the airlines, and the
airports.
____________________________________________________________
____________________________________________________________

! Identifying populations and relationships

Figures 1A.1 and 1A.2 to answer the following questions.
Flights, Flight numbers, Cities, Airports, Airport codes, Countries,
Terminals, Gates, and Status codes.
____________________________________________________________
____________________________________________________________
of them describe others?
Flight numbers identify flights.
Airport codes identify airports.
____________________________________________________________
____________________________________________________________

Airports are in cities.
Cities are in countries.
Flights travel between airports.
____________________________________________________________
____________________________________________________________

Exercise 2
Examining an Academic Faculty Theme
In this exercise, you will examine samples of external information related to a
scenario, and identify preliminary elements of a database model for future
consideration.
Scenario You are assigned the task of modeling the external information contained in
Figures 1A.3 and 1A.4. You have not been told what the information in the
figure and table represents, or what the database model will represent.
Linda
LindaSwift
Swift
Dean
Dean
Tenured
Tenured
Gerri
GerriNorton
Norton John
JohnLane
Lane Amber
AmberBeckman
Beckman
Math
MathDept
DeptHead
Head Literature
LiteratureDept
DeptHead
Head History
HistoryDept
DeptHead
Head
Jun
Jun8,8,2003
2003 Tenured
Tenured Tenured
Tenured
James
JamesCalouri
Calouri Paula
PaulaAbels
Abels Troy
TroyFinch
Finch
Professor
Professor Professor
Professor Professor
Professor
Tenured
Tenured Tenured
Tenured Tenured
Tenured
Jeremy
JeremyAlexander
Alexander Vanessa
VanessaThompson
Thompson Ida
IdaCezar
Cezar
Senior
SeniorLecturer
Lecturer Lecturer
Lecturer Senior
SeniorLecturer
Lecturer
Aug
Aug15,
15,2004
2004 June
June8,8,2003
2003 Sep
Sep9,9,2004
2004
John
JohnLane
Lane
Lecturer
Lecturer
May
May25,
25,2003
2003
Figure 1A.3
Figure 1A.3 contains sample data values that are correlated to the information
represented by Figure 1A.4.
Employee Location
Location Office
Office phone
phone Home
Employee Home
Employee
Employee name
name Dept
Dept
number
number Blg
Blg Room
Room Ext
Ext Access
Access phone
phone
5922
5922 Abels,
Abels, P.
P. Literature
Literature 27
27 78
78 7705
7705 Full
Full NA
NA
7442
7442 Alexander,
Alexander, J. J. Math
Math 27
27 58
58 9497
9497 Local
Local NA
NA
5349
5349 Beckman,
Beckman, A. A. History
History 62
62 151
151 4562
4562 Full
Full 555-3351
555-3351
6961
6961 Calouri,
Calouri, J.J. Math
Math 62
62 39
39 9831
9831 Full
Full NA
NA
4218
4218 Cezar,
Cezar, I.I. History
History 27
27 282
282 4567
4567 Local
Local NA
NA
7947
7947 Finch,
Finch, T.
T. History
History 62
62 53
53 4319
4319 Full
Full NA
NA
5254
5254 Lane,
Lane, J.
J. Literature
Literature 27
27 246
246 2146
2146 Full
Full 555-1967
555-1967
1851
1851 Lane,
Lane, J.
J. Math
Math 62
62 149
149 3991
3991 Local
Local NA
NA
2849
2849 Norton,
Norton, G.G. Math
Math 62
62 151
151 8873
8873 Full
Full 555-6405
555-6405
2350
2350 Swift,
Swift, L.
L. Admin
Admin 27
27 150
150 5041
5041 Full
Full 555-6405
555-6405
1689
1689 Thompson,
Thompson, V. V. Literature
Literature 62
62 311
311 5403
5403 Local
Local NA
NA
Figure 1A.4
Tasks Carefully examine the information in the scenario and perform the following
tasks.

Determine what the database model will represent. Refer to Figures 1A.3 and
1A.4 to answer the following questions.
It appears that the information is related to a university organizational
chart that describes academic employee information.
____________________________________________________________
____________________________________________________________
scenario.
What do the dates on the chart mean? Why do only some employees
have home telephones listed? Why do different employees have
different levels of office telephone access? Are job titles significant? Are
the two employees listed as John Lane the same person?
____________________________________________________________
____________________________________________________________
Check with whoever provided the information, department heads, or
the university administration.
____________________________________________________________
____________________________________________________________

! Identify populations and relationships

Figures 1A.3 and 1A.4 to answer the following questions.
Academics, Departments, Locations, Buildings, Rooms, Offices,
Academic rank, Office phones, Home phones, Telephone numbers,
Telephone access levels, Employee numbers, Employee names, Tenure
status, and Future tenure dates
____________________________________________________________
____________________________________________________________
of them describe others?
Employee names, numbers, academic ranks, and tenure status describe
academic employees.
Offices are located in a building and rooms.
Telephone extensions and access levels describe office phones.
____________________________________________________________
____________________________________________________________

Academics have telephones and offices.
Academics work for departments.
Academics report to department heads.
____________________________________________________________
____________________________________________________________

Module 2: Analyzing
External Information and
Creating a Conceptual
Contents
ModelCSDP Step 1
Module Overview 1
Lesson: Verbalizing Data Use Cases 2
Lesson: Formalizing Fact Types 23
Module Review 36
Lab A: Analyzing External Information
and Creating a Conceptual ModelCSDP
Step 1 38
other countries.
respective owners.
reserved.
Module 2: Analyzing External Information and Creating a Conceptual ModelCSDP Step 1 iii
Instructor Notes
This module teaches students the Conceptual Schema Design Procedure
(CSDP) step 1. This step covers analyzing external information and entering
elementary facts into the Fact Editor, which creates the conceptual model.
Presentation: This module provides students with the necessary knowledge and skills to
60 minutes complete CSDP step 1.
Lab: After completing this module, students will be able to:
30 minutes
! Complete CSDP step 1.
Verbalize data use cases.
Formalize fact types.
Create a conceptual model.
! Microsoft PowerPoint file 2090A_02.ppt
Preparation tasks ! Read all of the materials for this module.

! If possible, review and reference Chapter 3 of Information Modeling and
Publishers.
iv Module 2: Analyzing External Information and Creating a Conceptual ModelCSDP Step 1

In this module, students will learn the items from the external information that
will be used to create the conceptual model. Then, they will enter this into the
Fact Editor, which creates the conceptual model. Finally, students will apply
these steps to create database models for the themes that they are already
familiar with.
Lesson: Verbalizing Data Use Cases

This section describes the instructional methods for teaching each topic in this
lesson.
Fact-Driven Design This topic page covers the basis for which most Object Role Modeling (ORM)
models are best suited: fact-driven design. Make sure that students understand
that they can use ORM to model any database but that fact-driven design
models are best suited for ORM.
What Are Fact This topic page defines and provides the characteristics of fact instances.
Instances?
What Are Object Types? This topic page defines and provides the characteristics of object types. Note
that object means a single instance, while object type refers to all possible
instances.
What Are Predicates? This topic page defines and provides the characteristics of predicates.
What Are Fact Types? This topic page defines and provides the characteristics of fact types.
How to Verbalize Fact This page instructs students on the high-level steps of how to verbalize fact
Types types.
Practice: Verbalizing This page reinforces the elements of the previous page through practice of the
Fact TypesScheduling procedure by using the Scheduling Theme. (This should be an instructor-led
Theme group practice.)
Practice: Verbalizing This page reinforces the elements of the previous page through practice of the
Fact TypesAirline procedure by using the Airline Flights Theme.
Flights Theme
Lesson Review
ask questions. After answering questions, allow students to openly discuss any
of the topics covered.
Module 2: Analyzing External Information and Creating a Conceptual ModelCSDP Step 1 v
Lesson: Formalizing Fact Types

lesson.
Communicating Intent This topic page covers the use of Formal Object Role Modeling Language
(FORML) to communicate with the domain expert. Make sure that students
understand that they will not be required to create FORML expressions, but
they should be able to comprehend them. The Fact Editor in Microsoft Visio
Enterprise Architect edition generates FORML expressions.
Classifying Object This topic page defines and provides the characteristics of object types. Make
Types sure that students understand the differences between entities types and value
types. Also ensure that students know that entity types and value types roughly
map to entities and attributes.
Introduction to CSDP This topic page introduces the Conceptual Schema Design Procedure (CSDP)
Step 1 step 1. Make sure that students understand that this is the beginning of the
conceptual model, even though they do not see a graphical representation at this
time. Do not dwell on this, but clarify any confusion and explain that the CSDP
step 2 covers the creation of the graphical representation.
How to Enter Facts into This topic page covers the high-level steps of how to enter elementary facts into
the Conceptual Model the Fact Editor. Make sure that students understand that as soon as a single fact
is entered they have created the conceptual model. The model exists, regardless
of whether there is a graphical representation. However, they will use the
graphical representation in future lessons.
Practice: Entering Fact This page reinforces the elements of the previous page through practice of the
TypesScheduling procedure by using the Scheduling Theme. Note that the Meeting reoccurs fact
Theme type is a unary fact type, meaning that it has a single object type with a
predicate of reoccurs.
Practice: Entering Fact This page reinforces the elements of the previous page through practice of the
TypesAirline Flights procedure by using the Scheduling Theme.
Theme
Lesson Review
Module Review
After answering the questions, allow students to openly discuss any of the
topics covered.
vi Module 2: Analyzing External Information and Creating a Conceptual ModelCSDP Step 1
Lab A: Analyzing External Information and Creating a Conceptual

ModelCSDP Step 1
module prior to beginning.
Lab Setup
There are no lab setup requirements that affect replication or customization.
Lab Results
There are no configuration changes on student computers that affect replication
or customization.
Module 2: Analyzing External Information and Creating a Conceptual ModelCSDP Step 1 1
Module Overview
! Verbalizing Data Use Cases

! Formalizing Fact Types

Introduction In this module, you will gather external information, analyze it, and extract the
elementary facts from it. You will then enter these elementary facts into a
conceptual model by using the Fact Editor. This comprises the Conceptual
Schema Design Procedure (CSDP) step 1.
Module Purpose The purpose of this module is to start the CSDP process. This will create the
conceptual model.
Important In reality, you would work with a single model throughout the
CSDP process. In this course, however, there is no single unifying model in the
lessons covering CSDP.

Verbalize data use cases.
Formalize fact types.
2 Module 2: Analyzing External Information and Creating a Conceptual ModelCSDP Step 1
Lesson: Verbalizing Data Use Cases
! Fact-Driven Design
! What Are Fact Instances?
! What Are Object Types?
! What Are Predicates?
! What Are Fact Types?
! Howe to Verbalize Fact Types
! Practice: Verbalizing Fact TypesScheduling Theme
! Practice: Verbalizing Fact TypesAirline Flights Theme

Introduction In this lesson, you will study external information and identify several key
components. These components will make the elementary facts that you will
use in the next lesson.
Lesson purpose The purpose of this lesson is to learn how to gather the necessary information
and extract the components used to create a logical model.
! Verbalize fact types.
Describe and identify fact instances.
Describe and identify object types.
Describe and identify predicates.
Fact-Driven Design
! Goals of the modeler

" Represent semantic relationships between objects
" Capture business rules
" Do not capture business processes
! Purpose of the data model
" Represent allowable states of data in the UoD
" Reflect the scope of the UoD

Introduction Object Role Modeling (ORM) lends itself best to databases that are data, or
fact, driven. Use the information on this page to better understand the
application of fact-driven designs.
Goals of the modeler The fact-driven data modeler has three primary goals:
! Represent semantic relationships between objects.
Individual bits of data are usually recognizable in a data use case or from
the description that the domain expert gives of the Universe of Discourse
(UoD). Although it is easy to represent data and store data in a database, it is
often much more difficult to successfully capture the relationships between
data values.
! Capture business rules.
In addition to simple relationships, rules within a business usually qualify
when and how data values in the data use case are related. A successful
ORM model captures the business rules that constrain objects and their
relationships.
! Do not capture business processes.
In a data-driven model, you strive to model how data is represented, not the
process of how it is manipulated. Data relationships are usually much more
stable than processes, which can change from time to time.
Purpose of the data You create a data model to:

model
! Represent allowable states of data in the UoD.
A fact-driven data model represents the allowable data values in a snapshot
of a database at a given point in time.
! Reflect the scope of the UoD.
When you decide which facts are represented in the model and which facts
are not, you limit the scope of the UoD.
What Are Fact Instances?
! Definition
A fact instance is an individual observation of the
relationship between two or more data values
! Characteristics
" Are examples of relationships between specific data
" Are related through an action statement
" May have constraints

Introduction ORM models represent the set of all valid data uses cases in the UoD. When
communicating with the domain expert, you can talk about each data value and
its relationship with other data values.
Definition A fact instance is an individual observation of the relationship between two or
more data values.
Characteristics Fact instances have three important characteristics. They:
! Are examples of relationships between specific data.
An instance of a fact illustrates a specific example of the relationships
between two or more data values.
! Are related through an action statement.
You can express the relationship between objects as an action statement.
For example, in the fact instance
The Author known as Hemingway wrote the Book known by the
Title A Farewell to Arms
the author Hemingway and the book A Farewell to Arms are both data
values, related by the action verb writes.
! May have constraints.
You can qualify the action statement so that it constrains the relationship
between objects in the fact instance.
For example, you can subtly modify the fact instance to read:
The Author known as Hemingway wrote only one Book known
by the Title A Farewell to Arms
What Are Object Types?
! Definition
An object type represents the set of all possible instances
of a given object
! Characteristics
" Generic representations of populations
" Always named singularly
" Always title case
" Object kind

Introduction Within the UoD, many objects can exist. Any given set of all object instances in
the UoD must be defined.
Definition An object type represents the set of all possible instances of a given object.
Characteristics Object types have four important characteristics. They are:
! Generic representations of populations.
All possible object instances are members of the object types population.
You can use an object type to generically refer to the population as a whole.
! Always named singularly.
Object types are always referenced in a singular tense, not plural.
Remember that when working with data in the UoD, you are always
working with a single fact instance at a time and always only a single
instance of the object type in that fact instance.
For example, the proper way to express the collection of all authors in the
UoD is to refer to them by the Author object type, not Authors.
! Always title case.
To delineate an object type from the rest of a fact, the name of the object is
always written with its first letter capitalized.
! Object kind.
An ORM model has three kinds of object types. You can classify all object
types as entities, values, or external. Object types that are designated as
external are defined outside of the current model.
Important Object types in ORM do not directly correlate to tables and

columns in Entity Relationship (ER) diagrams.
What Are Predicates?
! Definition
A predicate is a verb phrase that the domain expert uses
to relate object types
! Characteristics
" Are sentence fragments with holes in them for object
type names
" Describe unqualified relationships
" Have reversible readings

Introduction By combining objects and their relationships, in language, you can create
predicates. ORM uses a natural language to specify its components.
Definition A predicate is a verb phrase that the domain expert uses to relate object types.
Important Only the domain expert can provide the verb phrase that adequately
conveys the meaning of the relationship between object types in the UoD.
Characteristics Predicates have three important characteristics. They:

! Are sentence fragments with holes in them for object type names.
For all similar fact instances, the predicate phrase is the same; what changes
is the object instances that are used in any given fact type.
For example, the following fact instances all share the same predicate but
have differing object instances.
The Author known as Austen wrote the Book known by the

Title Pride and Prejudice
The Author known as Chaucer wrote the Book known by the

Title The Canterbury Tales
! Describe unqualified relationships.

Predicates do not in any way constrain the relationship between object
types; instead, they indicate that they are related.
For example, in the fact instance
The Author known as Hemingway wrote only one Book known
by the Title A Farewell to Arms
the phase only one constrains the fact instance. Without that constraint,
the predicate wrote represents an unqualified description of the
relationship between the author Hemingway and the book A Farewell to
Arms.
! Have reversible readings.
All predicates must convey the same information whether they are read
foreword or backward.
For example, the fact instance
conveys the same information as the fact instance

The book known by the Title A Farewell to Arms was
written by the author known as Hemingway.
What Are Fact Types?
! Definition
A fact type is the set of fact instances that share the same
object types and predicate relationships
! Characteristics
" Syntax: [Object type] predicate [Object type]
" Arity of a fact type
" Generic representation
" Reversible predicate reading

Introduction An ORM object-relationship-object natural language expression can be thought
of as a fact type.
Definition A fact type is the set of fact instances that share the same object types and
predicate relationships.
Characteristics You should recognize four important characteristics of fact types:
! Syntax
A fact types syntax is: [ObjectType] predicate [ObjectType]. Object type
names are always capitalized, and predicates are always lowercase.
! Arity of a fact type
The number of object types in a fact type is known as the fact types arity.
This term is a derivative of the suffixes on the end of binary, ternary,
quaternary, and so on.
! Generic representation
All possible instances are each members of the fact types population. You
can use a fact type to generically refer to the population as a whole.
For example, you can express the group of fact instances
The Author known as Austen wrote the Book known by the

Title Pride and Prejudice
Author known as Chaucer wrote the Book known by the Title

The Canterbury Tales
as the fact type

[Author] writes [Book].
! Reversible predicate reading

You can reverse the order of the object type names in any valid fact type
and re-express the predicate phrase so that the fact type has the same
meaning.
For example, the following fact types represent the same information in the
UoD:
[Author] writes [Book]
[Book] is written by [Author]
How to Verbalize Fact Types
Examine
Examineexternal
externalinformation
information
Identify
Identifyfact
fact instances
instances
Identify
Identifyobject
objecttypes
types
Identify
Identifyunconstrained
unconstrainedpredicates
predicates
Express
Expressfact
fact types
typesin
in terms
termsof
ofobject
object types
types and
and
predicates
predicates

Introduction You verbalize fact types by working with the domain expert to examine the
UoD. Assume that the domain expert has given you all of the external
information that you will need for this project.
Procedure Use the following procedure to catalog fact types:
1. Examine external information.
External information can come in the form of tables, graphs, reports, or
interviews. Work with the domain expert to obtain and understand this data.
2. Identify fact instances.
Consult with the domain expert to identify the appropriate fact instances.
Look for repeating patterns or similar fact instances. You limit the scope of
the UoD by restricting which fact instances you model. You may want to do
this concurrently with the next step in this procedure.
3. Identify object types.
Examine the fact instances for recurring object types. Remember that object
types combine with predicates to form fact types.
4. Identify unconstrained predicates.
Look for common relationships between object types in multiple facts. Fact
instances with occurrences of the same object types and predicates are often
the same fact type.
5. Express fact types in terms of object types and predicates.
Reconstruct generic expressions for groups of fact instances. A single object
type can appear in more than fact type. The arity of a fact type is indicated
by the number of object types in the fact type.
Practice: Verbalizing Fact TypesScheduling Theme

Mon Tue Wed Thu Fri
AA doctors
doctors
8 am appointment
appointmentisis
scheduled
scheduled for for Out of Office:
9 00 2.5
2.5 hours
hours at
at9:00
9:00 Doctors Appt
Manager
1:1 on
on Friday
Friday out
out of
of
All-ha
10 00
AA brownbag
the
theoffice
office
Quart
brownbagTeam
lunch meeting meeting Meeti
lunch
11 00 meeting
on
on ORM
ORM isis Off sit
scheduled
scheduled for
for11 Brownbag AA data
datamodeling
modeling Traini
12 pm noon
hour
hourat at noon lunch: ORM meeting isis Class
meeting
Tuesday
Tuesday in
inroom
room scheduled
scheduled for for
101
101of
1of00building
building Data Data 2.5
2.5 hours
hours at at
117
117
00 Modeling 1:30PM
Modeling1:30PMon on
2 Project Project
Tuesday
Tuesday in in room
room
151
151 of
ofbuilding
building
3 00 62
62
Figure 2.1
4 00
1 22 3 5 00

Introduction All practices in the remainder of this course will use common themes on which
appropriate scenarios are based.
Purpose The purpose of this practice is to introduce you to the procedure of verbalizing
fact types by using the Scheduling Theme.
Scenario For the purposes of this practice, the UoD is limited to the information in this
scenario.
You are meeting with a domain expert to ascertain data modeling requirements
for a scheduling database application. The domain expert has provided you with
the following information:
! The desired functionality of the application is similar to that found in
Microsoft Outlook. Initially, the database will hold a single weeks worth
of meeting appointments.
Appointment
Appointment time
time Location
Location
ID
ID Meeting
Meeting subject
subject Duration
Duration Recurring
Recurring
Weekday
Weekday Hour
Hour Building
Building Room
Room
11 Mon
Mon 10:30
10:30 Team
Team Meeting
Meeting 27
27 Conf
Conf AA 1.0
1.0 Yes
Yes
22 Tue
Tue 9:30
9:30 Manager
Manager 1:11:1 27
27 246
246 1.0
1.0 Yes
Yes
33 Tue
Tue 12:00
12:00 Brownbag
Brownbag Lunch:
Lunch: ORM
ORM 117
117 101
101 1.0
1.0 No
No
44 Tue
Tue 1:30
1:30 Data
Data Modeling
Modeling Project
Project 62
62 151
151 2.5
2.5 Yes
Yes
55 Wed
Wed 1:30
1:30 Data
Data Modeling
Modeling Project
Project 62
62 151
151 2.5
2.5 Yes
Yes
66 Thu
Thu 10:00
10:00 All-hands
All-hands Quarterly
Quarterly Meeting
Meeting 117
117 101
101 1.5
1.5 No
No
77 Thu
Thu 11:00
11:00 Offsite
Offsite Training
Training Class
Class NA
NA NA
NA 5.0
5.0 No
No
88 Fri
Fri 9:00
9:00 Out
Out of
of Office:
Office: Doctor
Doctor Apt
Apt NA
NA NA
NA 2.5
2.5 No
No
Figure 2.2
Practice Use the following procedure and tables to catalog fact types in the scenario.
! Examine external information

1. Review Figure 2.1 for information that is represented graphically. What do
the columns and rows in the figure represent?
The columns represent days of the week. Each row represents one half-
hour block of time throughout the workday.
____________________________________________________________
____________________________________________________________
2. Review the tabular information in Figure 2.2. What information is more

readily indicated in tabular form than is apparent in the graphical
representation in the figure?
The location of each room is called out in the tabular information. The
duration of each appointment is calculated. Recurring meetings are
clearly indicated in tabular form, although they are indicated
graphically as well. Meetings that are tentatively scheduled are only
indicated graphically.
____________________________________________________________
____________________________________________________________
! Identify fact instances

1. A single fact instance is listed below. List all other similar fact instances
presented by the information in Figure 2.1 and Figure 2.2 in plain language
sentences by using a similar verbal pattern.
Meeting 1 has StartTime of Mon, 10:30 A.M.
Meeting 2 has StartTime of Tue, 9:30 A.M.
Meeting 3 has StartTime of Tue, 12:00 P.M.
Meeting 4 has StartTime of Tue, 1:30 P.M.
Meeting 5 has StartTime of Wed, 1:30 P.M.
Meeting 6 has StartTime of Thu, 10:00 A.M.
Meeting 7 has StartTime of Thu, 11:00 A.M.
Meeting 8 has StartTime of Fri, 9:00 A.M.
____________________________________________________________
____________________________________________________________
Meeting 1 has Subject of Team Meeting.
Meeting 2 has Subject of Manager 1:1.
Meeting 3 has Subject of Brownbag Lunch: ORM.
Meeting 4 has Subject of Data Modeling Project.
Meeting 5 has Subject of Data Modeling Project.
Meeting 6 has Subject of All-hands Quarterly Meeting.
Meeting 7 has Subject of Offsite Training Class.
Meeting 8 has StartTime of Out of Office: Doctor's Appointment.
____________________________________________________________
____________________________________________________________
Meeting 1 has Location in Building 27, Conference Room A.
Meeting 2 has Location in Building 27, Conference Room 246.
Meeting 7 has Location in Offsite.
Meeting 8 has Location in Doctor's Office.
____________________________________________________________
____________________________________________________________
Meeting 1 reoccurs.
Meeting 2 reoccurs.
Meeting 4 reoccurs.
Meeting 5 reoccurs.
____________________________________________________________
____________________________________________________________
What are the high-level similarities and differences between the fact
instances?
Each fact instance similarly describes what, where, when information
about each meeting.
Not all meetings are recurring. Not all meetings take place on site.
____________________________________________________________
____________________________________________________________
! Identify object types

Examine each fact instance from the first procedure for recurring use of
object types. What are the singular tense names of the recurring object
instances in all of the fact instances?
Meeting, Subject, Location, and StartTime.
____________________________________________________________
____________________________________________________________
! Identify unconstrained predicates

Examine the relationships between the Meeting object type and each of the
other object types in the fact instances in the first procedure. Complete
Table 2.1 by listing each related pair of object types and an action phrase
that illustrates an unqualified relationship between each pair.
Table 2.1
Object type Predicate phrase Object type
Meeting about Subject
Meeting starts at StartTime
Meeting is hosted in Location
Meeting is recurring
! Express fact types in terms of object types and predicates

1. Re-express the fact instances from the second procedure as generic facts
types by object type names and predicate phrases into sentences that follow
the same pattern as the fact instances from the first procedure. What are the
resulting phrases?
Meeting 1 has StartTime of Mon, 10:30 A.M.
Meeting 2 has StartTime of Tue, 9:30 A.M.
Meeting has StartTime.
____________________________________________________________
____________________________________________________________
2. What is the fact type phrase for the following fact instance?
Meeting 1 has Subject of Team Meeting.
Meeting 2 has Subject of Manager 1:1.
Meeting has Subject.
____________________________________________________________
____________________________________________________________
Meeting 1 has Location in Building 27, Conference Room A.
Meeting has Location.
____________________________________________________________
____________________________________________________________
Meeting 1 is recurring.
Meeting 2 is recurring.
Meeting is recurring.
____________________________________________________________
____________________________________________________________
Practice: Verbalizing Fact TypesAirline Flights Theme
London
UK11
UK11 (LHR)
US72
New York IT37
Madrid Rome
(JFK)
ES23 (MAD) (FCO)
Atlanta US62
US62
US62
US56
VE56
VE56
(ATL)
VE59
US68 Dakar
VE56
VE56 (DKR)
Caracas Flight
FlightUK11
VE56
UK11
VE56 originates
originates inin
Flight
FlightUS62
US62 originates
originates ininAtlanta
Atlanta
(CCS) London
Caracas
London and
Caracas and
and terminates
and terminates
terminates
terminates ininNew
in
New
in
and
andterminates
terminates ininRome.
Rome.
Rome.
York.
Rome.
York.
Figure 2.3
1 22 3

Introduction All practices in the remainder of this course will use common themes on which
appropriate scenarios are based.
Purpose The purpose of this practice is to introduce you to the procedure of verbalizing
fact types by using the Airline Flights Theme as the basis for this exercise.
scenario.
You are meeting with a domain expert to ascertain data modeling requirements
for a database that contains the current status of airline flights. The domain
expert has provided you with the following information:
! You will not model departure information at this time.
! Instead of an airline abbreviation, the two letter code for the originating
country is used to prefix a flight number.
Flight Origination Destination Departure

Departure info
info
Flight Origination Destination Status
Status
number
number city
city city
city Terminal
Terminal Gate
Gate Time
Time
UK11
UK11 London
London New
New York
York 33 55 14:25
14:25 On
On Time
Time
US72
US72 New
New York
York London
London 4E
4E 19
19 1:55
1:55 Delayed
Delayed
IT37
IT37 Rome
Rome New
New York
York Intl
Intl 12
12 11:12
11:12 Boarding
Boarding
ES23
ES23 Madrid
Madrid Atlanta
Atlanta 33 55 11:12
11:12 On
On Time
Time
US56
US56 Atlanta
Atlanta Rome
Rome TT 99 23:50
23:50 On
On Time
Time
VE59
VE59 Caracas
Caracas New
New York
York Intl
Intl 22 8:03
8:03 Cancelled
Cancelled
VE56
VE56 Caracas
Caracas Rome
Rome Intl
Intl 44 8:48
8:48 On
On Time
Time
US68
US68 Atlanta
Atlanta Caracas
Caracas TT 88 4:54
4:54 Boarding
Boarding
Figure 2.4
Practice Use the following procedure and tables to verbalize fact types in the scenario.

1. Review Figure 2.3 for information that is represented graphically. What do
the arrow tipped-lines that flow between cities represent?
The lines represent flight paths between cities, with the direction of
travel indicated by the arrow tip.
____________________________________________________________
____________________________________________________________
What does the text under each city name represent?

The text is the international code that represents a given airport.
____________________________________________________________
____________________________________________________________
2. Review the tabular information in Figure 2.4. What information is more

representation in Figure 2.3?
The current departure terminal, gate, time, and status for each flight is
called out in the tabular information. Origination and destination cities
appear in tabular form, although the international airport codes are
only on the graphical map.
____________________________________________________________
____________________________________________________________

presented by the information in Figures 2.3 and Figure 2.4 in plain language
Flight UK11 originates in London and terminates in New York.
Flight US72 originates in New York and terminates in London.
Flight IT37 originates in Rome and terminates in New York.
Flight ES23 originates in Madrid and terminates in Atlanta.
Flight US56 originates in Atlanta and terminates in Rome.
Flight VE59 originates in Caracas and terminates in New York.
Flight VE56 originates in Caracas and terminates in Rome.
Flight US68 originates in Atlanta and terminates in Caracas.
____________________________________________________________
____________________________________________________________
instances?
Each fact instance similarly describes the cities where the flight
originates and its final destination.
____________________________________________________________
____________________________________________________________
2. Two fact instances are listed below. List all other similar fact instances
presented by the information in Figures 2.3 and Figure 2.4 in plain language
Flight UK11 has status of on time.
Flight IT37 has status of boarding.
Flight US72 has status of delayed.
Flight ES23 has status of on time.
Flight US56 has status of on time.
Flight VE59 has status of canceled.
Flight VE56 has status of on time.
Flight US68 has status of boarding.
____________________________________________________________
____________________________________________________________
instances?
Each fact instance similarly describes current status of a flight; some
are canceled, some are delayed, some are boarding, and some are on
time.
____________________________________________________________
____________________________________________________________

Examine each fact instance from the first procedure for recurring object
types. What are the singular tense names of the recurring objects in all of the
fact instances?
Flight, OriginationCity, DestinationCity, Status.
____________________________________________________________
____________________________________________________________

Examine the relationships between the Flight object type and each of the
other object types in the fact instances in the first procedure. Complete
Table 2.2 by listing each related pair of object types and an action phrase
that illustrates an unqualified relationship between each pair.
Table 2.2
Flight takes off from OriginationCity
Flight lands in TerminationCity
Flight has Status

1. Re-express the following fact instances as generic fact types by using the
object types and predicate phrases from the previous step in such a manner
as to represent all of the similar fact instances that you identified.
Flight UK11 originates in London and terminates in New York.
Flight US72 originates in New York and terminates in London.
Flight IT37 originates in Rome and terminates in New York.
Flight takes off from OriginationCity and lands in TerminationCity.
____________________________________________________________
____________________________________________________________
2. What is the fact type for this instance?

Flight UK11 has status of on time.
Flight US72 has status of delayed.
Flight ES23 has status of on time.
Flight has Status.
____________________________________________________________
____________________________________________________________
Lesson Review
Objectives
Objectives
Verbalize
Verbalize fact
fact types
types
Describe
Describe and
and identify
identify fact
fact instances
instances
Describe
Describe and
and identify
identify object
object types
types
Describe
Describe and
and identify
identify predicates
predicates

1. Define fact instances.
A fact instance is an individual observation of the relationship between
two or more data values.
2. Define object types.

An object type represents the set of all possible instances of a given
object.
3. Define predicates.
A predicate is a verb phrase that the domain expert uses to relate object
types.
4. Define fact types.

A fact type is a set of fact instances that share the same object types and
predicate relationships.
Lesson: Formalizing Fact Types
! Communicating Intent
! Classifying Object Types
! Introduction to CSDP Step 1
! How to Enter Facts into the Conceptual Model
! Practice: Entering Fact TypesScheduling Theme
! Practice: Entering Fact TypesAirline Flights Theme

Introduction In this lesson, you will create the conceptual model. First, however, you must
ensure the accuracy of what you have extracted from the external information.
Lesson purpose The purpose of this lesson is to create a conceptual model by entering fact
types.
! Create a conceptual model.
Classify object types.
Understand Formal Object Role Modeling Language (FORML)
expressions.
Enter fact types into the model by using the Fact Editor.
Communicating Intent
! Formalized Object Role Modeling Language

! Use FORML to communicate intent
" Facilitate communication
" Validate the model

Introduction The natural language of ORM is called Formalized Object Role Modeling
Language (FORML). This is the language that you will use to communicate
with the domain expert. Regardless of the domain experts technical expertise,
FORML can show your models details in a way that the domain expert can
understand.
FORML Remember that object types and predicates have special rules regarding the
language used to express them. These rules combine to form concise FORML
expressions that unambiguously communicate the semantic meaning of a fact
type.
Use FORML to You use FORML to communicate what is captured in the model. Specifically,
communicate intent you use it to:
! Facilitate communication.
The domain expert typically has a variety of methods available to
communicate with the modeler; traditional modeling techniques do little to
communicate the contents of the model back to the domain expert in easily
understandable terms.
! Validate the model.
The chief advantage of ORM over ER diagramming is that an ORM model
expresses information in natural language. Because FORML expressions are
based on natural language, they are readily understood by even a non-
technical domain expert.
Classifying Object Types
! Object kind
" Value type
" Entity type
" External
! Entity type identifier
" Reference mode
" Reference type

Introduction You can further describe object types in the UoD by classifying them by the
kind of object type that they are, and making initial decisions about how you
refer to instances of a given object type.
Object kind Remember the three kinds of object types in an ORM model:
! Value type. Lexical object types that represent a string or a number,
meaning that you can write down a given value type instance on a piece of
paper as characters or a number.
For example, the set of names and ages that are related to a Person object
type are each modeled in ORM as a value type.
! Entity type. Non-lexical object types whose individual instances you cannot
write down on a piece of paper. Entity types must be related to a value type
in order to identify a given entity type instance.
For example, you can represent the set of all people in the UoD with a
Person entity type, implying that instances of Person exist without knowing
anything else about them, such as their name or age.
! External. Defined in one ORM model and referenced in another. You do not
have to define all object types in the UoD in a given ORM model. You can
indicate that you are reusing an object type that exists in another model by
designating it as external.
Entity type identifier You can set the following special characteristics in an ORM model to help you
identify instances of entity types:
! Reference mode
You can uniquely identify any given instance of an entity type by a special
value type known as its reference mode. Object types are commonly
referred to in fact instances by their reference mode.
For example, you can refer to an instance of a Person entity type by that
persons name.
! Reference type
The data values that reference modes hold are grouped into three categories:
identification, measurement, and formatting.
For example, you can use a persons employee number for identifying the
person. You can use the distance covered in a foot race to identify what type
of race it is, such as 100 meters, 10 kilometers, or 26 miles. You can use a
pattern of formatting to identify a date, such as YYYYMMDD.
Introduction to CSDP Step 1
! CSDP step 1
Transform familiar information examples into elementary
facts, and apply quality checks
! Focus of CSDP step 1

" Creates the conceptual model
" Fact-driven design
" Communicates intent

Introduction It is important that you complete all steps in order to create a proper ORM
model. To create a database by using the ORM methodology, you must first
create the conceptual model. You will continue to work with this conceptual
model throughout the CSDP process.
CSDP step 1 Transform familiar information examples into elementary facts, and apply
quality checks.
Important Because each step in the CSDP process builds on the previous steps,
it is important that you continually recheck your work. Mistakes made early in
the process will complicate the model in subsequent steps.
Focus of CSDP step 1 CSDP is the process by which you model databases using the ORM
methodology. It:
! Creates the conceptual model.
As soon as you enter the first component of external information into the
Fact Editor in Microsoft Visio Enterprise Architect edition, you have
created your conceptual model. The model exists, even though you do not
see the graphical representation at this time. (This is covered in CSDP
step 2.)
! Fact-driven design.
Remember that your data modeling methodology is based on a data-driven
design. ORM is structured to capture object types, the fact types that
represent relationships between them, and the constraints placed on the
populations of the fact types that restrict the allowable database states.
! Communicates intent.
The main purpose of CSDP step 1 is to communicate with the domain
expert and create a conceptual model that accurately reflects the domain
experts understanding of the UoD. If you enter object types and fact types
into the ORM model, you can use them to document the UoD as a series of
FORML expressions that both you and the domain expert can understand.
How to Enter Facts into the Conceptual Model
Enter
Enter new
new object
object types
types
Set
Set the
the fact
fact arity
arity
Select
Select existing
existing object
object types
types
Enter
Enter text
text describing
describing relationships
relationships
Validate
Validate your
your intent
intent with
with aa FORML
FORML expression
expression

Introduction Now that you have gathered all the necessary external information, analyzed it
appropriately, and consulted with the domain expert, you can create the
conceptual model.
Procedure Use the following procedure to enter fact types into the conceptual model:
1. Enter new object types.
Always check to determine whether any of the object types in the fact type
already exist in the Business Rules pane. If not, create the new object type,
designate what kind of object type it is, and set the reference mode
information for entity types.
2. Set the fact type arity.
Remember that the number of object types in a fact type is its arity. You
must first set this to create place holders for each object type in the Fact
Editor.
3. Select existing object types.
Remember that you can reuse object types in multiple fact types. Always
use the drop-down menu in the Fact Editor to select an existing fact type.
Tip You actually select an object type in the Fact Editor through a combo
box. If you type an object type name that is not in the combo box, then the
Fact Editor creates a new object type automatically. As a best practice, use
the drop-down menu to select object types.
4. Enter text describing relationships.

Remember that the predicate phrase is a sentence with holes in it for each
object type in the fact type. You need to enter the text describing the
relationship between each object type. For binary fact types, you must also
enter the text that described the inverse of the relationship.
5. Validate your intent with a FORML expression.
As you enter fact type information into the Fact Editor, the Fact Editor
constructs and displays a FORML expression that describes the fact type.
Similarly, when you select an object type, the Fact Editor displays a
FORML expression that describes the object type, as well. Check that the
FORML expressions reflect your intent.
Practice: Entering Fact TypesScheduling Theme
! Purpose
! Scenario
! Practice
Mon Tue Wed Thu Fri
8 am
Out of Office:
9 00 Doctors Appt
Manager
1:1 All-han
10 00 Quaterl
Team
11 00 Traini
Class
Brownbag
12 pm Lunch: ORM
1 00
Data Data
Modeling Modeling
2 00 Project Project
3 00
4 00
5 00

Introduction In this practice, you will enter fact types into the conceptual model from the
Scheduling Theme that you are already familiar with.
Purpose The purpose of this practice is to introduce you to the procedure of entering fact
types into the conceptual model by using the Scheduling Theme as the basis for
this exercise.
scenario.
You have met with a domain expert and have identified fact types in the
Scheduling Theme that you will enter into a conceptual model. Use the
following fact types to complete the procedures in this practice:
Meeting has Subject
Meeting has StartTime
Meeting has Location
Meeting reoccurs
Practice Use the following procedures to enter a single fact type into an ORM source
model, and then repeat for each fact type in the scenario.
! Create a new ORM source model

1. On the Start menu, click Programs, and then click Microsoft Visio.
2. In the Choose Drawing Type window, in the Category pane, click
Database, in the Template pane, and then double-click ORM Source
Model.
! Enter new object types

1. On the Database menu, click View, and then click Business Rules.
2. In the Business Rules pane, click the Object Types tab.
3. What are the object types in the scenario fact type?
Meeting, Subject, Location, and StartTime.
____________________________________________________________
____________________________________________________________
4. For each object type in the scenario fact type that does not exist in the
Object Types pane, press F2, type object type name, and then press ENTER.
! Set the fact type arity

1. Click the Fact Types tab, and then press F2 to open the Fact Editor.
2. On the Fact tab, under Input style, verify that the Guided option is
selected.
3. Under the Input style, in the Guided drop-down menu, select the arity that
is equal to the number of object types in the scenario fact type.
! Select existing object types

1. On the Fact tab, in the left-most Object Name list, select the first object
type in the scenario fact type.
2. On the Fact tab, in the remaining Object Name lists, select the remaining
object types from the scenario fact type.
! Enter text describing relationships

1. On the Fact tab, in the Relationship box between the first and second
Object Name boxes, type the predicate phrase that relates the first object
type to the second object type in the scenario fact type.
2. On the Fact tab, in the Relationship box between subsequent object types,
type the predicate phrase that relates each of those object types together.
! Validate your intent with a FORML expression

On the Fact tab, in the bottom pane, verify that the generated FORML
expression captures the same meaning as the scenario fact type.
! Repeat as necessary
Repeat the previous four procedures for each of the fact types in the
scenario.
Practice: Entering Fact TypesAirline Flights Theme
! Purpose
! Scenario
! Practice
London
UK11 (LHR)
US72
IT37
New York
Madrid Rome
(JFK)
ES2 (MAD) (FCO)
Atlanta 3 US62
VE56
(ATL)
VE59
US68 Dakar
VE56
(DKR)
Caracas
(CCS)

Introduction Enter fact types into the conceptual model from the Airline Flights Theme that
you are already familiar with.
Purpose The purpose of this practice is to introduce you to the procedure of entering fact
types into the conceptual model using the Airline Flights Theme Scenario.
For the purposes of this practice, the UoD is limited to the information in this
scenario.
Scenario You have met with a domain expert and have identified fact types that you will
enter into a conceptual data model. Use the following fact types to complete the
procedures in this practice:
Flight takes off from OriginationCity lands in TerminationCity
Flight has Status
Practice Use the following procedures to enter a fact type into an ORM source model.

1. On the Windows Start menu, click Programs, and then click Microsoft
Visio.
2. In the Choose Drawing Type window, in the Category pane, in the Template
pane, double-click ORM Source Model.

What are the object types in the scenario fact types?
Flight, OriginationCity, TerminationCity, and Status.
____________________________________________________________
____________________________________________________________
3. For each object type in the scenario fact types that does not exist in the
Make sure that you do this for all object types in the scenario.
! Set the fact types arity

2. On the Fact tab, under Input style, verify that the Guided option is
selected.
3. Under the Input style, in the Guided drop-down menu, select the arity that
is equal to the number of object types in the scenario fact type.



scenario.
Lesson Review
Objectives
Objectives
Create
Create aaconceptual
conceptualmodel
model
Classify
Classifyobject
objecttypes
types
Understand
Understand FORML
FORML expressions
expressions
Enter
Enterfact
fact types
typesinto
intothe
the model
modelby
byusing
using the
the
Fact
Fact Editor
Editor

1. Why use FORML to validate intent?
The primary reason to use FORML to validate intent is because any
person involved in the database project can understand it. The domain
expert is not required to be technically savvy in order for the modeler
to demonstrate what the model has captured and what it will eventually
be.
2. In ORM, entities and values will loosely tie into what ER components?
An entity in ORM will become an entity in an ER, or logical, model.
Values in an ORM model will comprise the attributes of an ER model.
Module Review
! Verbalizing Data Use Cases

! Formalizing Fact Types

1. From what sources do you gather external information?
You gather external information from any source that currently
captures the results of your desired outcome. These include reports,
charts, graphs, invoices, and any other documents. Additionally, you
will glean information from the domain expert. You will turn to the
domain expert for both input and clarity of other material.
2. Of the two basic types of databasesfact-driven and transactionalwhich

is ORM best used to model, and why?
ORM lends itself best to databases that are data-, or fact-, driven. An
ORM model captures the state of data at a given point in time.
3. What are the three primary things you are looking to identify when
examining external information, and why?
Identify fact instances, object types, and unconstrained predicates.
Look for repeating patterns or similar fact instances. You limit the
scope of the UoD by restricting which fact instances you model.
Examine the fact instances for recurring object types. Remember that
object types combine with predicates to form fact types. Look for
common relationships between object types in multiple facts. Fact
instances with occurrences of the same object types and predicates are
often the same fact type.
4. How do you validate your intent?

As you enter fact type information into the Fact Editor, the Fact Editor
constructs and displays a FORML expression that describes the fact
type. When you select an object type, the Fact Editor displays a
FORML expression that describes the object type, as well. Make sure
that the FORML expressions reflect your intent and that of the domain
expert.
Lab A: Analyzing External Information and Creating a

! Exercise 1: Verbalizing Fact Types
! Exercise 2: Entering Fact Types into the
Conceptual Model

Objectives This lab will reinforce your skills and knowledge of the CSDP step 1
introduced in the module. In this lab, you will analyze the external information
in the Academic Faculty Theme. This is the theme that will be used in all
remaining labs of this course.
After completing this lab, you will be able to:
Verbalize fact types.

! Completed the practices in Module 2.
! Completely gathered all necessary external information for the given
scenario.
! Interviewed the domain expert for any needed clarification.
Scenario For the purposes of this lab, the UoD is limited to the information in this
scenario.
You have been tasked with modeling a database for an academic faculty of a
university. The database will store personal and professional information about
the staff.
! You will not model home phone number information at this time.
! The Dean and all Department Heads have the Rank of Professor.
! The Dean works for the Administration Department.
Linda
LindaSwift
Swift
Dean
Dean
Tenured
Tenured
Gerri
GerriNorton
Norton John
JohnLane
Lane Amber
AmberBeckman
Beckman
Math
MathDept
DeptHead
Head Literature
LiteratureDept
DeptHead
Head History
HistoryDept
DeptHead
Head
Jun
Jun8,8,2003
2003 Tenured
Tenured Tenured
Tenured
James
JamesCalouri
Calouri Paula
PaulaAbels
Abels Troy
TroyFinch
Finch
Professor
Professor Professor
Professor Professor
Professor
Tenured
Tenured Tenured
Tenured Tenured
Tenured
Jeremy
JeremyAlexander
Alexander Vanessa
VanessaThompson
Thompson Ida
IdaCezar
Cezar
Senior
SeniorLecturer
Lecturer Lecturer
Lecturer Senior
SeniorLecturer
Lecturer
Aug
Aug15,
15,2004
2004 June
June8,8,2003
2003 Sep
Sep9,9,2004
2004
John
JohnLane
Lane
Lecturer
Lecturer
May
May25,
25,2003
2003
Figure 2A.1
Employee Location
Location Office
Office phone
phone Home
Employee Home
Employee
Employee name
name Dept
Dept phone
number
number Blg
Blg Room
Room Ext
Ext Access
Access phone
5922
5922 Abels,
Abels, P.
P. Literature
Literature 27
27 78
78 7705
7705 Full
Full NA
NA
7442
7442 Alexander,
Alexander, J. J. Math
Math 27
27 58
58 9497
9497 Local
Local NA
NA
5349
5349 Beckman,
Beckman, A. A. History
History 62
62 151
151 4562
4562 Full
Full 555-3351
555-3351
6961
6961 Calouri,
Calouri, J.J. Math
Math 62
62 39
39 9831
9831 Full
Full NA
NA
4218
4218 Cezar,
Cezar, I.I. History
History 27
27 282
282 4567
4567 Local
Local NA
NA
7947
7947 Finch,
Finch, T.
T. History
History 62
62 53
53 4319
4319 Full
Full NA
NA
5254
5254 Lane,
Lane, J.
J. Literature
Literature 27
27 246
246 2146
2146 Full
Full 555-1967
555-1967
1851
1851 Lane,
Lane, J.
J. Math
Math 62
62 149
149 3991
3991 Local
Local NA
NA
2849
2849 Norton,
Norton, G.G. Math
Math 62
62 151
151 8873
8873 Full
Full 555-6405
555-6405
2350
2350 Swift, L.
Swift, L. Admin
Admin 27
27 150
150 5041
5041 Full
Full 555-6405
555-6405
1689
1689 Thompson,
Thompson, V. V. Literature
Literature 62
62 311
311 5403
5403 Local
Local NA
NA
Figure 2A.2
Estimated time to You should complete this lab in approximately 30 minutes.

complete this lab:
30 minutes
Exercise 0
Lab Setup
! Log on to Microsoft Windows
1. Press CTRL+ALT+DEL to open the logon screen.
2. Type Studentxx in the User Name box, where Studentxx is the user name
assigned to you at the beginning of the class.
3. Type the password that you established for this account in the Password
box.
4. Ensure that NWTRADERS is listed in the Domain box.
5. Click OK.
Exercise 1
Verbalizing Fact Types
In this exercise, you will catalog the fact types from the Academic Faculty
Theme.
The UoD is limited to the visible contents of Figure 2A.1, the tabular
information in Figure 2A.2, and to the information provided in the scenario.
Use the following procedure and tables to catalog fact types in the scenario.

1. Review Figure 2A.1 for information that is represented graphically. What
do the columns and rows in the figure represent?
The columns represent academic personnel assigned to a department.
The rows are only relevant for the upper two levels. The top row
represents a college dean, and the second row represents department
heads within the college.
____________________________________________________________
____________________________________________________________
2. Review the tabular information in Figure 2A.2. What information is more

representation in Figure 2A.1?
Each Academic on the list has more information than that from Figure
2A.1. This includes: employee number, office location, office phone
number, phone access privileges, and home phone numbers for those
that have one. However, some information from Figure 2A.1 is not
present in Figure 2A.2. This information is: tenured status, or date to
be tenured, and rank.
____________________________________________________________
____________________________________________________________

1. A single fact instance is provided below. List all other similar fact instances
presented by the information in Figures 2A.1 and Figure 2A.2 in plain
language sentences by using a similar verbal pattern.
Gerri Norton is the head of the Math Department.
John Lane is the head of the Literature Department.
Amber Beckman is the head of the History Department.
Linda Swift is the head of the Department of Administration.
____________________________________________________________
____________________________________________________________
James Calouri has Rank of Professor in the Math Department and is
Tenured.
Paula Abels has Rank of Professor in the Literature Department and is
Tenured.
Troy Finch has Rank of Professor in the History Department and is
Tenured.
Linda Swift has Rank of Professor in the Department of Administration
and is Tenured.
Gerri Norton has Rank of Professor in the Math Department and will
be Tenured on June 8th, 2003.
John Lane has Rank of Professor in the Literature Department and is
Tenured.
Amber Beckman has Rank of Professor in the History Department and
is Tenured.
Jeremy Alexander has Rank of Senior Lecturer in the Math
Department and will be Tenured on August, 15th, 2004.
Ida Cezar has Rank of Senior Lecturer in the History Department and
will be Tenured on September 9th, 2004.
John Lane has Rank of Lecturer in the Math Department and will be
Tenured on May 25th, 2003.
Vanessa Thompson has Rank of Lecturer in the Literature Department
and will be Tenured on June 8th, 2003.
____________________________________________________________
____________________________________________________________
What are the high-level similarities and differences in the fact instances?
All Academics have a Rank, regardless of Department.
Rank and job title are not the same thing.
____________________________________________________________
____________________________________________________________
3. A single-fact instance is provided below. List all other similar fact instances
Linda Swift is identified by employee number 2350.
Gerri Norton is identified by employee number 2849.
James Calouri is identified by employee number 6961.
Jeremy Alexander is identified by employee number 7442.
Paula Abels is identified by employee number 5922.
Vanessa Thompson is identified by employee number 1689.
Amber Beckman is identified by employee number 5349.
Troy Finch is identified by employee number 7947.
Ida Cezar is identified by employee number 4218.
John Lane in the Math Department is identified by employee number
1851.
John Lane in the Literature Department is identified by employee
number 5254.
____________________________________________________________
____________________________________________________________
All Academics have an employee number.
John Lane, who is the Literature Department head, is a different
person from John Lane in the Math Department.
____________________________________________________________
____________________________________________________________
Linda Swifts office is room 150 in building 27, her extension is 5041, and
she has full phone access.
Gerri Nortons office is room 151 in building 62, his extension is 8873,
and he has full phone access.
James Calouris office is room 39 in building 62, his extension is 9831,
Jeremy Alexanders office is room 58 in building 27, his extension is
9497, and he has local phone access.
John Lanes office is room 149 in building 62, his extension is 3991, and
he has local phone access.
John Lanes office is room 246 in building 27, his extension is 2146, and
he has full phone access.
Paula Abels office is room 78 in building 27, her extension is 7705, and
she has full phone access.
Vanessa Thompsons office is room 311 in building 62, her extension is
5403, and she has local phone access.
Amber Beckmans office is room 151 in building 62, her extension is
4562, and she has full phone access.
Troy Finchs office is room 53 in building 62, his extension is 4319, and
he has full phone access.
Ida Cezars office is room 282 in building 27, her extension is 4567, and
she has local phone access.
____________________________________________________________
____________________________________________________________
All employees have an office and a phone.
Some have full phone access; others have only local.
____________________________________________________________
____________________________________________________________

Examine each fact instance from the second procedure for recurring object
types. What are the singular tense names of the recurring objects in all of the
fact instances?
Academic, Rank, Tenured status, Employee number, Department,
Office, Phone number, Phone access, Room, and Building.
____________________________________________________________
____________________________________________________________

Examine the relationships between the Academic object type and each of
the other object types in the fact instances in the second procedure.
Complete Table 2A.1 by listing each related pair of object types and an
action phrase that illustrates an unqualified relationship between each pair.
Indicate object type relationships that only occur in all fact instances.
Table 2A.1
Academic has Rank
Academic heads Department
Academic has Tenured status
Academic is identified by Employee number
Academic works for Department
Academic has Office
Academic has Phone number
Academic has Phone access
Office is in Room
Room is in Building

1. Re-express the fact instances from the second procedure as generic fact
types by object type names and predicate phrases into sentences that follow
the same pattern as the fact instances from the first procedure. What are the
resulting phrases?
Gerri Norton is the head of the Math Department.
John Lane is the head of the Literature Department.
Amber Beckman is the head of the History Department.
Academic heads Department.
____________________________________________________________
____________________________________________________________
2. What is the fact type for these instances?

James Calouri has rank of Professor in the Math Department and is
tenured.
Paula Abels has rank of Professor in the Literature Department and is
tenured.
Troy Finch has rank of Professor in the History Department and is
tenured.
Academic has Rank, works for Department, and has Tenured Status.
____________________________________________________________
____________________________________________________________

Linda Swift is identified by employee number 2350.
Gerri Norton is identified by employee number 2849.
James Calouri is identified by employee number 6961.
Academic is identified by Employee number.
____________________________________________________________
____________________________________________________________

Linda Swifts office is room 150 in building 27, her extension is 5041,
and she has full phone access.
Gerri Nortons office is room 151 in building 62, his extension is 8873,
James Calouris office is room 39 in building 62, his extension is 9831,
Academic has Office in Room in Building, has Phone, and has Phone
access.
____________________________________________________________
____________________________________________________________
Exercise 2
Entering Fact Types into the Conceptual Model
In this exercise, you will enter fact types from the Academic Faculty Theme
into the Fact Editor to create a conceptual model. You will use the results of the
previous exercise to complete the exercises below.
The UoD is limited to the visible contents of Figure 2A.1, the tabular
information in Figure 2A.2, and the information provided in the scenario.
Academic heads Department.
Academic has Rank works for Department has Tenured Status.
Academic is identified by Employee number.
Academic has Office in Room in Building has Phone has Phone

access.
Use the following procedures to enter a fact type into an ORM source model.

1. On the Start menu, click Programs, and then click Microsoft Visio.
2. In the Choose Drawing Type window, in the Category pane, click
Database, in the Template pane, and then double-click ORM Source
Model.

What are the object types in the scenario fact type?
Academic, Rank, Tenured status, Employee number, Department,
Office, Phone number, and Phone access.
____________________________________________________________
____________________________________________________________
3. For each object type in the scenario fact type that does not exist in the
Make sure that you do this for all object types in the scenario.
! Set the fact types arity

2. On the Fact tab, under Input style, verify that Guided is selected.
3. Under Input style, in the Guided drop-down menu, select the arity that is
equal to the number of object types in the scenario fact type.



scenario.
Module 3: Drawing a
Conceptual Model and
Entering Sample Data
Contents
CSDP Step 2
Module Overview 1
Lesson: Drawing Fact Types 2
Lesson: Applying a Population Check 11
Lesson: Applying CSDP Step 2 17
Module Review 25
Lab A: Drawing Fact Types and Applying
Population Checks 26
Lab A Discussion: Drawing Fact Types
and Applying Population Checks 32
other countries.
respective owners.
reserved.
Module 3: Drawing a Conceptual Model and Entering Sample DataCSDP Step 2 iii
Instructor Notes
Presentation: This module provides students with the skills and knowledge necessary to
60 minutes complete step 2 of the Conceptual Schema Design Procedure (CSDP).
30 minutes
! Apply CSDP step 2.
Draw fact types.
Apply population checks.

Publishers.
iv Module 3: Drawing a Conceptual Model and Entering Sample DataCSDP Step 2

Lesson: Drawing Fact Types

lesson.
How Object Types Are This topic page outlines the Object Role Modeling (ORM) symbols for object
Symbolized types. Although each symbol is displayed, it is unrealistic to require students to
memorize each shapes nuances in such a short amount of time. Call out the
nuances of each shape and remind students to refer to this page in the future if
they find difficulty in identifying object shapes.
How Predicates Are This topic page explains the ORM symbols for predicates and also calls out the
Symbolized Role Connector shape. Although each symbol is displayed, it is unrealistic to
require students to memorize each shapes nuances in such a short amount of
time. Call out the nuances of each shape and remind students to refer to this
page in the future if they find difficulty in identifying predicates.
How to Draw Fact Types This topic page instructs students on how to draw ORM shapes onto the
drawing surface of Microsoft Visio Enterprise Architect edition. Students
will practice with a variation of the Scheduling Theme. This topic may seem
overly simple, but it is important that you point out that the action of drawing is
not the most important goal of this page. Students are expected to draw the
shapes so that they can work with each individual shape in the future.
Lesson Review
topics covered.
Lesson: Applying a Population Check

lesson.
Meaningful Sample This topic page explains the characteristics that make sample data meaningful
Population and useful to modelers and the domain expert.
How to Implement a This topic page outlines the methods for entering meaningful sample data into a
Population Check fact type. Be sure to reiterate that any sample data entered must be accurate and
reflect all variations of the fact types. Also point out thatalthough students
will analyze the sample data, and Visio will suggest uniqueness constraints
they will not apply these uniqueness constraints until a later step.
Lesson Review
After answering the questions, allow students to discuss openly any of the
topics covered.
Module 3: Drawing a Conceptual Model and Entering Sample DataCSDP Step 2 v
Lesson: Applying CSDP Step 2

lesson.
Focus of CSDP Step 2 This topic page reviews the main points of the CSDP step 2. It is intended as a
brief overview. Do not spend too much time on this page, because each section
will be covered in greater detail on future topic pages.
How to Apply CSDP This topic page is a preview of the CSDP step 2. Guide students through each
Step 2 task. Just like each preceding lesson, this introduction uses the Scheduling
Theme that students should already be familiar with. The terminal objective of
this lesson is how to apply this step.
Practice: Applying CSDP This topic page is for students to practice CSDP step 2 in the Airline Flights
Step 2Airline Flights Theme that they are already familiar with. Allow students the freedom to work
Theme alone but be available to answer questions. This practice includes the detailed
steps for completing this task.
Discussion: Applying This topic page is intended for you to discuss the steps from the previous topic
CSDP Step 2Airline page. Explain why and how each task was completed as it relates to this
Flights Theme scenario.
Lesson Review
topics covered.
Module Review
topics covered.
Lab A: Drawing Fact Types and Applying Population Checks

Lab Setup
Lab Results
or customization.
Module 3: Drawing a Conceptual Model and Entering Sample DataCSDP Step 2 1
Module Overview
! Drawing Fact Types

! Applying a Population Check
! Applying CSDP Step 2

Introduction This module teaches you the concepts and procedures for the Conceptual
Schema Design Procedure (CSDP) step 2. This module deals with information
at the conceptual level.
Module purpose The purpose of this module is to provide you with the necessary knowledge and
skills to successfully complete CSDP step 2, drawing fact types and applying
population checks.
Module objectives After completing this module, you will be able to:
Draw fact types.
2 Module 3: Drawing a Conceptual Model and Entering Sample DataCSDP Step 2
Lesson: Drawing Fact Types
! How Object Types Are Symbolized

! How Predicates Are Symbolized
! How to Draw Fact Types
! Practice: Drawing Fact TypesScheduling Theme

Introduction In this lesson, you will use the Object Role Modeling (ORM) source model
template in Microsoft Visio Enterprise Architect edition to represent facts
graphically in the Universe of Discourse (UoD). This is a continuation of
Conceptual Schema Design Procedure (CSDP).
Lesson purpose The purpose of this lesson is to complete step 2 of the CSDP.
! Draw ORM fact types in Visio.
Describe how fact types are symbolized in ORM.
How Object Types Are Symbolized
Kinds of Object Types
Entity Value
Object Type Names and Reference Mode
Name
Name
(Reference)

Introduction After object types are entered into the model by using the Fact Editor, you can
represent them graphically in a Visio drawing. This topic covers the shapes that
represent object types.
Object type shapes The first of the primary shapes of an ORM model is object type. Oval shapes
represent object types on the models drawing surface.
Table 3.1
ORM modeling element Symbol
Entity object types

Entity object types represent all possible instances in a
population.
Entity type objects are symbolized by an oval shape
with a solid border.
Value object types

Value object types are those object types whose domain
consists of numbers or character strings.
Value type objects are symbolized by an oval shape
with a dashed border.
Table 3.1 (continued)

Entity object type name and reference mode

The name of an object type is symbolized as text in the
center of the object shape. The shape dynamically
resizes to encompass the object types name.
If an entity type has a simple reference scheme, this
may be abbreviated as a reference mode in parentheses
below the entity type name.
Value object type names

The names of entity types and value types are
symbolized in the same manner.
The name of a value type is symbolized as text in the
center of the value type shape. The shape dynamically
resizes to encompass the object types name.
How Predicates Are Symbolized
Role
...
Figure 3.5
Arity
Binary
... ...
Ternary
... ... ...
Quaternary
... ... ... ...
Figure 3.6
Role Connector
Figure 3.7 ...
Predicate Phrase
Figure 3.8 ... has .../... is of ...

Introduction After object types are entered into the model by using the Fact Editor, you can
represent them graphically in a Visio drawing. This topic covers the shapes that
represent predicates.
Predicate shapes The second of the primary shapes of an ORM model is a predicate. Rectangular
shapes represent a fact types predicate on the models drawing surface. A fact
types object types are connected to the roles that they play in the predicate.
Table 3.2
Role shape
A role is a part played by an object type in
a relationship.
Roles are symbolized by a rectangle.
Predicate arity
The number of roles involved in a fact
types predicate indicates arity.
A unary predicate has only one role.
A binary predicate has two roles.
A ternary predicate has three roles.
A quaternary predicate has four roles.
Multiple roles are symbolized side-by-side
to form a predicate shape.

Role connector
The line between a role shape and an object
type shape is a role connector. The role
represents the subset of the object types
population that participates in the
relationship.
A role connector spans a single role and a
single object type.
Predicate phrase
The verb phrase with object holes in it
conveys the relationship between the
predicates object types.
The predicate reading is displayed below
the predicate shape, with object names
replaced by ellipses.
Example The ORM diagram in Figure 3.9 represents a ternary fact.
Figure 3.9
How to Draw Fact Types
Open
Open Business
BusinessRules
Ruleswindow
window
Drag
Drag and
and drop
drop onto
onto the
thedrawing
drawing surface
surface
Examine
Examinedatabase
databaseproperties
propertiesof
ofshapes
shapes

Introduction Visio does not automatically display the components of your data model on the
drawing surface. You must place each element on the drawing surface.
Procedure Use the following procedure to draw fact types:
1. Open the Business Rules window.
Fact types entered into the model through the Fact Editor are accessible in
the Business Rules window, on the Fact Type tab. You can view this
window through the Database menu in an ORM source model template.
2. Drag and drop the fact type or object type onto the drawing surface.
Select one or more of the fact types or object types from the appropriate tab
in the Business Rules window.
Drag and drop the selected element onto the drawing surface. Notice that if
you drag a fact type, the component object type shapes and the fact type
predicate shapes are drawn. This does not occur with object types.
3. Examine database properties of shapes.
You can access the database properties of the model elements represented
by a given shape by double-clicking the shape on the drawing surface.
Practice: Drawing Fact TypesScheduling Theme
! Purpose
! Scenario
! Practice
Mon Tue Wed Thu Fri
8 am
Out of Office:
9 00 Doctors Appt
Manager
1:1 All-han
10 00 Quaterl
Team
11 00 Traini
Brownbag Class
12 pm Lunch: ORM
Starting Solution 1 00
2 00
Data
Modeling
Project
Data
Modeling
Project
Model Model 3 00
4 00
5 00

Introduction On this page, you will complete practice drawing fact types by using the
Scheduling Theme.
Purpose The purpose of this practice is for you to become proficient with drawing fact
types.
Scenario The Scheduling Theme has already been familiarized and verbalized in a Visio
ORM source model. You are to draw different fact types and examine them.
Practice In this practice, you will draw in Visio the ORM diagram for the Scheduling
Theme.
You will use the files in the C:\MOC\2090\Practices\Mod03 folder to complete
this practice. Solution files for this practice are located in the Answer
subdirectory of that folder.
! Open the practice model file in Visio

1. Click Start, point to All Programs, and then click Microsoft Visio.
2. Open the DrawFactType.vsd ORM source model.
! Open the Business Rules window

On the Database menu, point to View, and then click Business Rules to
open the Business Rules window.
! Drag and drop the fact types onto the drawing surface
Drag and drop the Location at Time is used for Subject fact type onto the
drawing surface.
! Examine the fact type shape properties

1. On the drawing surface, double click the Location object type.
This opens the Database Properties window.
2. Click the individual items in the Categories list and examine the
information associated with the Location object type.
3. On the drawing surface, click the atis used for predicate.
4. Click the individual items in the Categories list and examine the
information associated with the atis used for predicate.
Note that it is a ternary fact type.
5. Leave the model open for use in the next practice.
If needed, review the solution files for this practice located in the
C:\MOC\2090\Practices\Mod03\Answer folder.
Lesson Review
Objectives
Objectives
Draw
Draw fact
facttypes
types
Draw
DrawORM
ORM fact
facttypes
typesin
inVisio
Visio
Describe
Describehow
howfact
facttypes
types are
aresymbolized
symbolizedin
in ORM
ORM

1. What is the difference between fact types that are drawn on the drawing
surface and those that are not?
None. They both exist in the model and can be manipulated.
2. How does a fact type become visible on the drawing surface?

You must drag and drop each fact type that you want to represent
graphically on the model.
Lesson: Applying a Population Check
! Meaningful Sample Population

! How to Implement a Population Check
! Practice: Applying a Population CheckScheduling
Theme

Introduction In this lesson, you will use meaningful sample data to populate an ORM source
model and then apply a population check. This is a continuation of CSDP.
Lesson purpose The purpose of this lesson is to learn to implement a population check.
! Implement a population check.
Describe a meaningful sample population.
Meaningful Sample Population
! Representative
! Meaningful variations

Introduction You use meaningful sample data to populate a model for the purpose of
checking both the functionality and the accuracy of the output.
Representative A meaningful sample population must represent instances of information in the
UoD, and it must represent the real-world problem that you are trying to solve.
The sample population can come from any number of sources, such as reports,
charts, graphs, input screens, and forms.
Meaningful variations The sample data is meaningful only if it represents all variations of possible
instances that exist in the UoD.
For example, the set {apple, orange, pear} is not representative of the UoD if
you intend to allow duplicate instances. In that case, {apple, apple, orange,
pear} is more representative.
Important The subject matter expert or the database modeler should never
make up sample data. Always refer back to real data use cases to obtain actual
data. This has a critical effect on whether or not the model actually reflects
actual business requirements.
How to Implement a Population Check
Open
Open the
theExamples
Examplestab
tab in
in the
theFact
Fact Editor
Editor
Enter
Enteraameaningful
meaningfulsample
samplepopulation
population
Analyze
Analyzeexample
exampledata
data

Introduction To apply a population check, you must enter a meaningful sample population
into the model. This topic instructs you on how to enter sample data into a fact
type and then analyze it for implied uniqueness constraints. You will not
implement uniqueness constraints at this time; they are addressed in a later
CSDP step.
Procedure Use the following procedure to implement a population check:
1. Click the Examples tab in the Fact Editor.
You can enter sample data for a given fact type in the Fact Editor, or in the
database properties for the predicate shape.
2. Enter a meaningful sample population.
Meaningful sample data represents all variations of instances of the fact
type. Each row in the data grid represents one fact instance. Each column in
the data grid represents instances of an object types role in the fact type.
The number of columns that you see matches the arity of the predicate that
you are modeling. The minimum number of rows of meaningful sample data
is the arity of the predicate plus 1.
3. Analyze the example data.
Click Analyze to check for implied uniqueness constraints on the fact,
based upon the sample data.
Note You will not apply any constraints identified by the population check in
this lesson. Constraints are applied in later CSDP steps.
Practice: Applying a Population CheckScheduling Theme
! Purpose
! Scenario
! Practice
Mon Tue Wed Thu Fri
8 am
Out of Office:
9 00 Doctors Appt
Manager
1:1 All-han
10 00 Quaterl
Team
11 00 Traini
Brownbag Class
12 pm Lunch: ORM
2 00
Data
Modeling
Project
Data
Modeling
Project
Model Model 3 00
4 00
5 00

Introduction On this page, you will apply a population check to a fact type by using the
Scheduling Theme.
Purpose The purpose of this practice is for you to experience the process of applying a
population check to a fact type.
Scenario You will enter actual sample data from a table provided, and then apply a
population check to the data.
Practice In this practice, you will use the following procedure to apply a population
check to a fact type in the Scheduling Theme. Use the model created in the
previous activity.
! Open the Examples tab in the Fact Editor

1. Open the ImplPopulationCheck.vsd ORM source model.
2. On the drawing surface, right-click the atis used for predicate, and
then click Fact Editor.
3. In the Fact Editor window, click the Examples tab.
! Enter a meaningful sample population

In the grid on the Examples tab, enter the data from Table 3.3, which
represents a meaningful sample population. Press TAB and SHIFT+TAB to
move from one column to another.
Table 3.3
Location Time Subject
69-204 Mon 9 A.M. Math

67-303 Tue 2 P.M. Biology
67-303 Mon 9 A.M. Biology
69-303 Fri 5 P.M. Geometry
! Analyze the example data

1. Click Analyze.
The example data that you entered is analyzed.
Note Ignore the results folder in the Example analysis results window.
Constraints will be covered later in the course.
2. Review the Example analysis results dialog box for messages. If Error or
Warning messages appear, verify that you entered the data exactly as
written, click Close, and then click OK.
Tip If the Analyze report indicates that the population contains blank rows,
most likely more than one numbered blank row appears at the end of the
example data. Click, then right-click the first empty row number, and then
click Delete Rows to remove the extra row. Repeat this action for all but the
last blank row. You must leave one blank numbered row after the last valid
row.
Important Do not click Apply UC Constraints at this time. Doing so will

create the constraints prematurely.
3. Leave the model open for use in the next practice.
Lesson Review
Objectives
Objectives
Apply
Apply aapopulation
populationcheck
check
Implement
Implementaapopulation
populationcheck
check
Describe
Describeaa meaningful
meaningfulsample
samplepopulation
population

1. What constitutes meaningful sample data?
Data that accounts for all meaningful variations of possible data in a
fact type population.
2. Where do you acquire meaningful sample populations?

You can create meaningful sample populations or use existing data as
long as they meet the criteria of being representative and have
meaningful variations.
! Focus of CSDP Step 2

! How to Apply CSDP Step 2
! Practice: Applying CSDP Step 2Airline Flights Theme
! Discussion: Applying CSDP Step 2Airline Flights Theme

Introduction In this lesson, you will combine the procedures of the previous two lessons and
complete CSDP step 2.
Lesson purpose The purpose of this lesson is to synthesize the previous two lessons and apply
that knowledge to scenarios.
Draw fact types.
Focus of CSDP Step 2
CSDP step 2: Draw fact types and apply a population

check
" Conceptual data model vs. the diagram
" Fact types
" Meaningful sample population

Introduction This lesson covers the second step of CSDP. It is important that you follow the
CSDP procedures to generate a well designed ORM model.
CSDP step 2 Draw fact types and apply a population check.
Graphically represent the facts and validate them against meaningful sample
data.
Conceptual data model You create the conceptual data model by entering facts into Visio by using the
vs. the diagram Fact Editor. Although the model exists at this point, you have not yet created
the graphical representation. You cannot visually examine the model until you
place elements of it on the drawing surface.
Warning Just as data exists in a physical database without your querying it,
elements of the database model exist in the Visio document without your
drawing them. Remember that any drawing that you are viewing may not
represent the entire database model.
Fact types ORM uses two primary shapes to graphically represent fact types. These are the
Object shape and the Predicate shape. All other shapes either enhance or
constrain the meaning of the primary shapes.
Meaningful sample To create an accurate model, you must populate a potential model with
population meaningful sample data. Sample data values are entered into each fact type to
validate that you properly modeled the fact. Visio also uses this sample data to
generate reports and FORML statements.
Important The sample population that you use is meaningful only if it portrays
all variations of fact instances, or examples of unique types of data usage, for a
given fact type that occurs in the UoD. If it does not, you cannot definitively
know whether your model is correct.
How to Apply CSDP Step 2
Draw
Draw fact
facttypes
types
Examine
Examinedatabase
databaseproperties
propertiesof
ofshapes
shapes
Implement
Implementpopulation
population check
check
Validate
Validate intent
intentwith
with the
the Verbalizer
Verbalizer

Introduction This topic instructs you on how to apply CSDP step 2 to the Scheduling Theme
that you are already familiar with. Follow the procedure outlined in the
following text. You have already learned the concepts and each of the steps in
this procedure.
Procedure Use the following procedure to apply CSDP step 2:
1. Draw fact types.
Remember that you must place each element on the drawing surface
because Visio does not automatically display the components of your data
model.
2. Examine database properties of shapes.
Review the shapes for your own awareness. You will enhance the model by
altering these database properties in future CSDP steps.
3. Implement a population check.
Validate each fact type with a meaningful sample population. Enter
representative variations of fact instances into the model.
4. Validate intent with the Verbalizer.
Ensure that the model accurately represents the intent of the domain expert.
Validate FORML expressions at each modeling step to prevent the
introduction of errors.
Practice: Applying CSDP Step 2Airline Flights Theme
! Draw fact types

! Examine database properties of shapes
! Implement a population check
! Validate intent with the Verbalizer
London
UK11 (LHR)
US72
IT37
New York
Madrid Rome
(JFK)
ES2 (MAD) (FCO)
Atlanta 3 US62
VE56
(ATL)
VE59
US68 Dakar
Starting VE56
(DKR)
Model Caracas
(CCS)

Introduction On this page, you will apply CSDP step 2 to an exercise with the Airline Flights
Theme.
Purpose The purpose of this practice is to learn how to draw fact types and implement a
population check, and then validate your intent with the Verbalizer.
Scenario The Airline Flights Theme has already been familiarized and verbalized in a
Visio ORM source model. You will draw fact types by using the tables of
information provided, and then implement population checks. You will
complete the exercise by validating intent with the Verbalizer.
Practice In this practice, you apply the steps taught earlier to the Airline Flights Theme
that CSDP step 1 created.
! Draw fact types

1. Open the CSDP2_Airline.vsd ORM source model.
2. Draw the Airline has Flight fact type.
3. Draw the Flight departs from OriginatingCity arrives at
TerminatingCity fact type.

1. Examine the Flight object type.
It is an entity and does not have a reference mode.
2. Examine the ...departs fromarrives atpredicate.
It is a ternary predicate.
! Implement population checks

1. Implement a population check for the Flight departs from
OriginatingCity arrives at TerminatingCity fact type by using the data in
Table 3.4.
Table 3.4
Flight OriginatingCity TerminatingCity
AC-2331 Boston Chicago

ED-987 Seattle Denver
AC-3899 Boston Chicago
AC-3899 Chicago Los Angeles
2. Implement a population check for the Airline has Flight fact type by using
the data in Table 3.5.
Table 3.5
Airline Flight
AC AC-2331
ED ED-987
AC AC-3899

Validate each of the fact types in Table 3.6 to ensure that they match the
intent.
Table 3.6
Fact type
Airline has Flight

Flight departs from OriginatingCity arrives at TerminatingCity
The Verbalizer text for these two fact types should read as follows:
Airline has Flight / Flight is of Airline
Discussion: Applying CSDP Step 2Airline Flights Theme
! Draw fact types

! Implement a population check
London
UK11
(LHR)
US72
IT37
New York
Madrid Rome
(JFK)
ES2 (MAD) (FCO)
Atlanta 3 US62
VE56
(ATL)
VE59
US68 Dakar
Solution VE56
(DKR)
Model Caracas
(CCS)

Discussion You will discuss some of the less obvious or more complex aspects of the
modeling of this scenario.
Draw fact types In this procedure, you drew the two fact types, Airline has Flight and Flight
departs from OriginatingCity arrives at TerminatingCity.
Tip If a model becomes visually complex, you may manually arrange the
shapes on the drawing surface. You can flip or rotate predicates by right-
clicking the predicate, pointing to Shape, and then clicking the appropriate
action.
Examine database Notice that this model, like others, does not indicate a reference mode;
properties of shapes however, you can still enter and view example data for each predicate. In ORM,
the example data is used to validate the relationship that the fact type
represents. A reference mode is not required to do so.
Implement a population In this procedure, you entered example data into the Airline has Flight and
check Flight departs from OriginatingCity arrives at TerminatingCity fact types.
You then clicked Analyze to determine whether the fact type had any errors.
In the case of the first fact type, a minimum of three rows of example data is
necessary to express the domain experts statement that an airline may have
multiple flights, but each flight belongs to only one airline. This conforms to
the rule that the number of example data roles must be one more than the
number of roles in the fact type.
The same population rule applies in the second fact type, Flight departs from
OriginatingCity arrives at TerminatingCity. The three roles in this fact type
require a minimum of four rows of example data.
In addition, the data clearly conforms to the intent. It indicates that a flight
travels between an OriginatingCity and a TerminatingCity. For example, flight
ED-987 has an OriginatingCity of Seattle and a TerminatingCity of Denver.
Note that the same flight number, in this case AC-3899 from Table 3.5, is used
more than once. The first time, the flight originates in Boston and terminates in
Chicago. The next portion of this flight originates in Chicago and terminates in
Los Angeles. This represents a flight that has multiple cities in its route.
You may need to enter more data than is required by the number of arity + 1
rule to ensure that the data that is entered fully describes all possible valid
combinations for the model to be accurate.
Finally, Analyze had no entries in the error or warning category, indicating
that, most likely, you have entered the data correctly. You gain a better
confirmation by visually rechecking the data in Table 3.5 and Table 3.6 against
the data that you entered for each fact type.
Validate intent with the The last step is to verbalize the fact types. In this model, the Verbalizer text for
Verbalizer the predicates should read as follows:
Airline has Flight / Flight is of Airline
These statements also confirm that you have met the intent for the statements
An airline has flights and A flight originates at one city and terminates at
another.
The data supports the intent. The following data is from the Flight departs
from OriginatingCity arrives at TerminatingCity fact type:
Examples:
Flight AC-2331 departs from OriginatingCity Boston arrives
at TerminatingCity Chicago.
Flight ED-987 departs from OriginatingCity Seattle arrives
at TerminatingCity Denver.
Flight AC-3899 departs from OriginatingCity Boston arrives
at TerminatingCity Chicago.
Flight AC-3899 departs from OriginatingCity Chicago arrives
at TerminatingCity Los Angeles.
It supports the intent that flights depart from one city and terminate in another.
Notice that flight AC-3899 has multiple stops. This supports the intent that a
flight may depart from and terminate at more than two cities during its journey.
Lesson Review
Objectives
Objectives
Apply
Apply CSDP
CSDPstep
step22
Draw
DrawORM
ORM fact
facttypes
typesin
inVisio
Visio
Describe
Describehow
howfacts
factstype
type are
aresymbolized
symbolizedin
in ORM
ORM
Check
Check aafact
fact types
typespopulation
populationusing
using
meaningful
meaningfulsample
sample data
data

1. What is the minimum number of sample fact instances that must be entered
into the Fact Editor to validate a model?
Arity + 1. Whatever the arity of the fact, the sample population must
have at least one more.
2. What are the primary shapes of a fact type?

Object shapes (ovals) and predicate shapes (rectangles).
Module Review
! Drawing Fact Types

! Applying a Population Check

1. What shape represents an external entity object type?
An oval with solid borders and slanted hash marks within it.
2. What shape represents a binary predicate?

Two rectangles side by side.
3. Where is the reading of a predicate displayed on the drawing surface?

Directly below the predicate.
Lab A: Drawing Fact Types and Applying Population

Checks
! Exercise 1: Drawing ORM Fact Types in
Visio
! Exercise 2: Implementing a Population
Check
! Exercise 3: Validating the Model

Objectives This lab will reinforce your understanding of CSDP step 2, as well as the skills
taught in the module.
Draw ORM fact types in Visio.
Describe how fact types are symbolized in ORM.
Check a fact types population by using meaningful sample data.
Generate the FORML expression for a fact by using the Verbalizer, and
validate intent.

! Knowledge about how to draw ORM fact types by using Visio.
! Knowledge of how to construct and implement a population check by using
Visio.
Scenario You have been given the ORM source model for the Academic Staff and
Departments Theme. You are to draw the fact types, create a population of
meaningful example data with which to check each fact type, and validate the
intent by using the Verbalizer.
The domain expert has told you the following information:
1. A member of the academic staff works for a department.
2. An academic staff member occupies a room for a semester.
You will use the files in the C:\MOC\2090\Labfiles\Lab03 folder to complete

Estimated time to
complete this lab:
30 minutes
Exercise 0
Lab Setup
box.
5. Click OK.
Exercise 1
Drawing ORM Fact Types in Visio
The goal of this exercise is for you to be able to draw ORM fact types in a Visio
model based upon the Academic ORM source model.
! Draw fact types

1. Open the CSDP2_Academic.vsd ORM source model.
2. Draw each fact type in the ORM source model and arrange them on the
Visio drawing surface.
Table 3A.1
Fact type
Academic occupies Room during Semester


1. Examine the properties of the objects in the ORM model to familiarize
yourself with the model.
2. Leave your model open for the next exercise.
Exercise 2
Implementing a Population Check
The goal of this exercise is for you to be able to implement a valid population
check for the Academic model that you have created and the example data that
you have entered.
! Enter a meaningful sample population

Enter the data from Table 3A.2 into the fact types as roles read from left to
right in the relationship text.
Table 3A.2
Fact type Role 1 Role 2 Role 3
Academic occupies Jones 69-301 Autumn 2000

Room during
Semester
Salmon 69-406 Autumn 2000
Smith 67-320 Autumn 2000
Jones 69-406 Winter 2000
Academic works for Jones Computer Science N/A
Department
Smith Biochemistry N/A
Baker Biochemistry N/A
! Analyze the example data

1. Analyze the example data for each fact type. There should be no errors.
2. If you observe an error, check to ensure that you entered the data correctly.
Do not set UC Constraints at this time.
3. Save your model in your My Documents folder.
Exercise 3
Validating the Model
The goal of this exercise is for you to be able to validate that the Academic
model that you have created meets the original intent.

Compare your Verbalizer output with the following text:
Academic works for Department / Department employs Academic
Lab A Discussion: Drawing Fact Types and Applying

Population Checks
! Exercise 1: Drawing ORM Fact Types in
Visio
! Exercise 2: Implementing a Population
Check
! Exercise 3: Validating the Model

Discussion You will discuss some of the less obvious or more complex aspects of the
modeling of this scenario.
Draw fact types In this procedure, you drew the two fact types, Academic occupies Room
during Semester and Academic works for Department.
Examine database You examined the shape properties in the Database Properties window. Note
properties of shapes that Academic, Room, Semester, and Department are entity object types.
Academic occupies Room during Semester is a ternary fact type, and
Academic works for Department is a binary fact type.
Implement a population In this procedure, you entered example data into the Academic occupies Room
check during Semester and Academic works for Department fact types. You then
clicked Analyze to determine whether the fact types had any errors.
In each case, no errors or warnings indicated that the data conforms to the rule
that the number of example data roles must be one more than the number of
roles in the fact type.
Validate intent with the The last step is to verbalize the fact types. In this model, the Verbalizer text for
Verbalizer the predicates should read as follows, in addition to the example data:
Academic works for Department / Department employs Academic
These statements also confirm that you have met the intent of the statements
that a member of the academic staff works for a department and an academic
staff member occupies a room for a semester.
The data supports the intent. The following data is from the Academic
occupies Room during Semester fact type:
Examples:
Academic Jones occupies Room 69-301 during Semester
Autumn 2000.
Academic Smith occupies Room 69-406 during Semester
Autumn 2000.
Academic Salmon occupies Room 67-320 during Semester
Autumn 2000.
Academic Jones occupies Room 69-406 during Semester
Winter 2001.
This data contains four examples of vendors and the Academic staff members
and the Room that he or she occupies during a Semester. Notice that the
Academic can be listed more than once, with the corresponding room for any
given semester. The Academic Jones is the example of this. This verifies the
intent.
Although the intent was not explicitly stated, the data supports the fact that a
member of the staff may occupy different rooms for different semesters. When
you discover an implied rule in the example data, you should confirm your
observation with the domain expert.
Module 4: Trimming the
Conceptual Schema
CSDP Step 3
Contents
Module Overview 1
Lesson: Implementing Primitive Entity
Types 2
Lesson: Implementing Derived Fact Types 14
Module Review 31
Lab A: Implementing Primitive Entity
Types and Derived Fact TypesCSDP
Step 3 32
other countries.
respective owners.
reserved.
Module 4: Trimming the Conceptual SchemaCSDP Step 3 iii
Instructor Notes
Presentation: This module provides students with the skills and knowledge necessary to
60 minutes complete step 3 of the Conceptual Schema Design Procedure (CSDP).
30 minutes
Implement primitive entities.
Implement derived fact types.

Publishers.
iv Module 4: Trimming the Conceptual SchemaCSDP Step 3

Lesson: Implementing Primitive Entity Types

lesson.
What Is a Conceptual This topic page covers the concepts related to partitioning a conceptual model.
Partitioning Scheme? Make sure that students understand these concepts, because they will use them
in the application of future topic page content. Note that you should refer back
to Figure 1.5 and set existence concepts.
What Are Primitive This topic page covers primitive entity types. It directly relates to the
Entity Types? discussions of set theory in Module 1 and will relate to subtypes in Module 5.
Make sure that students understand this concept before moving on; otherwise,
they will not be prepared for future steps in CSDP.
Guidelines for This topic page combines the theory of the previous two topic pages and
Coalescing Entity Types provides guidelines as to when students should combine object types.
How to Implement This topic page covers the high-level tasks of implementing primitive entity
Primitive Entity Types types. Discuss each task and answer any questions from students. Point out that
this has the effect of trimming the schema.
Practice: Implementing This topic page covers the individual tasks of implementing primitive entity
Primitive Entity Types types by using the Scheduling Theme. Discuss each task and answer any
Scheduling Theme questions from students.
Lesson Review
topics covered.
Lesson: Implementing Derived Fact Types

lesson.
What Are Derived Fact This page covers derived fact types in general. Logically derivable fact types
Types? will be covered in a future lesson.
How to Implement This topic page covers the high-level steps involved in using derived value
Derived Fact Types types. This process is the same for all derived fact types. For arithmetically
derived fact types, all data types are appropriately set; this is not covered in this
step. Discuss each task and answer any questions from students.
Practice: Implementing This topic page covers the individual steps involved in using derived fact types
Derived Fact Types by using the Scheduling Theme. Discuss each task and answer any questions
Scheduling Theme from students.
Module 4: Trimming the Conceptual SchemaCSDP Step 3 v
Lesson Review
topics covered.

lesson.
Focus of CSDP Step 3 This topic page covers the main points of CSDP step 3. It is intended as a brief
overview. Do not spend too much time on this page, because each section will
be covered in greater detail on future topic pages.
How to Apply CSDP This topic page is intended as a preview of CSDP step 3. Guide students
Step 3 through each task. Just like each preceding lesson, this introduction uses the
Scheduling Theme that students should already be familiar with.
Practice: Applying CSDP This topic page is for students to practice CSDP step 3 in the Invoice Theme
Step 3Airline Flights that they are already familiar with. This practice includes detailed steps for
Theme completing the task. Allow students the freedom to work alone, but be available
to answer questions.
Discussion: Applying This topic page is intended for you to discuss the steps just completed from the
CSDP Step 3Airline previous topic page. Explain why each task was completed in this manner. The
Flights Theme ImplPrimitive_Airline.vsd and ImplDerived.vsd answer files are in the answer
folder for students to reference.
Lesson Review
topics covered.
Module Review
topics covered.
vi Module 4: Trimming the Conceptual SchemaCSDP Step 3
Lab A: Implementing Primitive Entity Types and Derived Fact

TypesCSDP Step 3
Lab Setup
No lab setup requirements affect replication or customization.
Lab Results
customization.
Module 4: Trimming the Conceptual SchemaCSDP Step 3 1
Module Overview
! Implementing Primitive Entity Types

! Implementing Derived Fact Types

Introduction This module teaches you the concepts and procedures for the Conceptual
Schema Design Procedure (CSDP) step 3. This module deals with information
at the conceptual level.
Module purpose The purpose of this module is to provide you with the necessary knowledge and
skills to successfully complete CSDP step 3.
! Check for entity types that should be combined, and note any arithmetic
derivations.
Implement primitive entity types.
Apply CSDP step 3.
2 Module 4: Trimming the Conceptual SchemaCSDP Step 3
Lesson: Implementing Primitive Entity Types
! What Is a Conceptual Partitioning Scheme?

! What Are Primitive Entity Types?
! Guidelines for Coalescing Entity Types
! How to Implement Primitive Entity Types
! Practice: Implementing Primitive Entity Types
Scheduling Theme

Introduction In this lesson, you will learn the skills and knowledge necessary to implement a
conceptual schema.
Lesson purpose The purpose of this lesson is to complete the first part of CSDP step 3.
! Implement primitive entity types.
Describe and identify a conceptual partitioning scheme.
Describe and identify partitioning objects.
Describe and identify primitive entity types.
Coalesce entity types.
What Is a Conceptual Partitioning Scheme?
! Definition
A conceptual partitioning scheme is the systematic
separation of the UoDs population into meaningful
object types
! Characteristics
" Group and division of UoD
" Mutually exclusive partitions
" Exhaustive partitions

Introduction The creation of a conceptual Object Role Modeling (ORM) model follows the
process of separating the Universe of Discourse (UoD) into meaningful object
types.
Definition A conceptual partitioning scheme is the systematic separation of the UoDs
population into meaningful object types.
Characteristics When working with a conceptual partitioning scheme, you must consider three
areas when dividing the UoD.
! Group and division of UoD
At its simplest level, a conceptual partitioning scheme is the subdivision of
the UoDs object types into entity types and value types. You can further
partition entity and value types into these three groups:
Strings and numbers
You can group and divided out of the UoD all object types that are
lexical in nature, meaning that you can write them down. All lexical
object types are value types.
Atomic entity types
Atomic entity types are considered as individual object types. They have
no internal structure. Atomic entity types have no meaning until they are
used in a relationship.
Nested entity types
Nested entity types are actually relationships that you consider as an
object type. These are often called objectified relationships. Nested
entity types have internal structures that can be broken down into atomic
entity types. Not all relationships are nested entity types.
! Mutually exclusive partitions

Two sets are mutually exclusive of one another if and only if no member
exists in both sets. This means that any given object instance is found in
only one object type.
! Exhaustive partitions
A partitioning scheme is considered exhaustive if all instances fall into a
single object type, if all object types are in a single partition, and if you have
all of the partitions, even if they are empty. An exhaustive conceptual
partitioning scheme implies a closed model.
Partitioning object types Figure 4.1 represents a generic conceptual partitioning scheme for object types
in the UoD in any given UoD. It shows, moving top to bottom, how all object types are
either entity types or value types, that entity types are either atomic or nested,
and that value types are either strings or numbers. In other words, the
partitioning scheme in Figure 4.1 is exhaustive, in that the entire UoD is
considered, and each subdivision in the partitioning scheme is mutually
exclusive, implying no overlap of object type populations.
Object
Object Types
Types in
in the
the Universe
Universe of
of Discourse
Discourse
Entity
Entity Types
Types Value
Value Types
Types
Atomic
Atomic Nested
Nested
Strings
Strings Numbers
Numbers
Atomic
Atomic Atomic
Atomic Atomic
Atomic
Figure 4.1
What Are Primitive Entity Types?
! Definition
Primitive entity types represent the most basic entity types
in the UoD
! Characteristics
" Atomic
" Mutually exclusive

Introduction To model business requirements, you must precisely identify object types in the
UoD. Often, the initial entity types with which you start modeling are not
atomic, or their populations may overlap. Before proceeding with CSDP, you
must properly identify and model core object types.
Definition Primitive entity types represent the most basic entity types in the UoD. They are
the lowest common denominator of a group of entity types.
Characteristics All primitive entity types share the following characteristics in that they are
atomic and mutually exclusive:
! Atomicity. Primitive entity types are atomic because they cannot be broken
down into other entity types or structures.
! Mutual exclusivity. The populations of two or more primitive entity types
never overlap. A union of the members of two or more primitive entity
types will never produce redundant instances.
Figure 4.2 illustrates a conceptual partitioning scheme that divides object types
in a UoD into primitive entity types. Such a subdivision, by definition, is
exhaustive and mutually exclusive.
Figure 4.2
Primitive entity types are In later CSDP steps, you will see that primitive entity types are the basis for
related to subtypes creating entity subtypes. You may initially recognize primitive entity types in
the UoD as subtypes. At this stage in the CSDP, you should coalesce subtypes
into their primitive forms. Entity subtypes and primitive entity types are related
in the follow manner:
! Subtypes have common primitive entity types.
Subtypes, by definition, share one or more common primitive entity types.
! Subtypes are used differently from one another.
Subtypes are created to allow the placement of differing constraints and
usage of a subset of a given primitive entity types population.
! Subtype populations may overlap.
Unlike a primitive entity type, the populations of its subtypes may overlap.
Guidelines for Coalescing Entity Types

Look
Look for
for commonalities
commonalities
Common
Commoninstances
instances
Common
Commonrelationships
relationships
Common
Common partitioning
partitioning scheme
scheme
Common
Common unit-based
unit-based reference
referencemode
mode
Common
Common primitive
primitiveentity
entitytype
type
Look
Look for
for need
need to
to manipulate
manipulate query
query results
results
Need
Need to
to perform
perform union
unionon
on results
results
Use
Use intersection
intersection of
ofsets
sets to
tocreate
create results
results

Introduction To coalesce entity types into primitive entity types, you must ensure that you
are comparing like objects. As object types, instances of apples and oranges
cannot be meaningfully coalesced. However, fruit might be the primitive entity
type you are looking for.
You should use the following guidelines to assist you in coalescing entity types.
Look for commonalities To combine two or more entity types, the types must share a common primitive
entity type. As such, those entity types may portray the same kind of
information in different ways. The following is a list of things to consider when
comparing objects:
! Common instances
If you find a common instance of an entity type object in two or more object
types member domains, it is a sign that they may share the same primitive
entity type.
! Common relationships
If you find that two or more entity types have the same relationship with
another object type, it is a sign that they may share the same primitive entity
type. These common roles may manifest themselves through a common
partitioning scheme.
! Common partitioning scheme
If the member domain of two or more entity types is partitioned or subtyped
in the same manner, it is a sign that they may share the same primitive entity
type.
! Common unit-based reference mode

If you find that two or more entity types have the same unit-based reference
mode, such as money, distance, or time, it is a sign that they share a
common member domain, and that they may share the same primitive entity
type.
! Common primitive entity type
If it is obvious that two or more entity types share a common primitive
entity type, there is an inherent relationship between those objects.
Queried together Aside from their representation in ORM, another indication that two or more
object types may share a common primitive entity type is if they are queried
together.
! Union of sets
If you find that you need to combine the results of querying multiple fact
types into a single result set, it is a sign that the object types that you are
querying may share a common primitive entity type.
! Intersection of sets
If you can intersect two or more of the result sets on a common object type,
it is an indication that those object types share a common primitive entity
type.
How to Implement Primitive Entity Types
Identify
Identifyentity
entitytypes
typesto
to be
bereplaced
replaced
Create
Create aanew
new primitive
primitive entity
entitytype
type
Consolidate
Consolidateand
andreassign
reassign entity
entitytypes
types
Eliminate
Eliminateredundant
redundantfact
fact types
types
Validate
Validate the
thenew
new fact
facttypes
types

Introduction You can implement primitive types to simplify your model. Use the following
procedure to implement primitive entity types in an ORM model:
Procedure Use the following procedure to implement primitive entity types:
1. Identify entity types to be replaced.
You need to identify entity types to coalesce into new primitive entity types.
Use the guidelines for coalescing entity types to assist you in determining
which entity types to combine.
2. Create a new primitive entity type.
You will create one new primitive entity type for each group of existing
non-primitive entity types that you combine. You will use these entity types
to simplify your model. You must complete this step before reassigning the
non-primitive entity types, or you risk losing information.
3. Consolidate and reassign entity types.
Consolidate the now-redundant fact types, preserving their sample data.
Preserve the information from the original fact types by reassigning the new
primitive entity type to the existing fact type roles.
Tip Do not remove the old entity types from the model at this time. You
may want to use them with entity subtypes in later CSDP steps.
4. Eliminate redundant fact types.

If applicable, delete the redundant fact types that you consolidated
information from, leaving only the fact type that you moved information
into and to which you reassigned the primitive entity type.
Important Fact types are redundant only if they have exactly the same
relationships and constraints, and are based on the same kind of meaningful
sample populations.
5. Validate the new fact types.

Ensure that the new primitive entity type and fact type modifications
represent the same information as the old fact types. The FORML
expressions will be different, but they should convey the same meanings to
the domain expert.
Practice: Implementing Primitive Entity TypesScheduling Theme
! Purpose
! Scenario
! Practice
Mon Tue Wed Thu Fri
8 am
Out of Office:
9 00 Doctors Appt
Manager
1:1 All-han
10 00 Quaterl
Team
11 00 Traini
Brownbag Class
12 pm Lunch: ORM
2 00
Data
Modeling
Project
Data
Modeling
Project
Model Model 3 00
4 00
5 00

Introduction In this practice, you will implement primitive entity types by using the
Purpose The purpose of this practice is to illustrate how you coalesce two entities into a
single primitive entity type, as a result of the entities sharing a common unit-
based reference mode, by using the Scheduling Theme.
Scenario For the purpose of this practice, the UoD is limited to the information in this
scenario.
You have met with the domain expert and are now attempting to trim a portion
of the schema in your initial data model. The domain expert has provided you
with the following information:
! You are to model the starting time and ending time for each meeting.
! All times are recorded in the same unit of measurement.
Practice You will use the files in the C:\MOC\2090\Practices\Mod04 folder to complete
! Identify entity types to be replaced

1. Open and review the ImplPrimitive_Scheduling.vsd ORM source model.
2. Look for two or more entity types that share a common unit-based reference
mode.
Which entity types can you coalesce into the new Time primitive entity
type?
StartTime, StopTime.
____________________________________________________________
____________________________________________________________
! Create a new primitive entity type

2. In the Business Rules window, click the Object Types tab.
3. In the Contents of Entire Contents pane, double-click (Double-click here
to add a new object type.), type Time and then press ENTER.
! Consolidate and reassign entity types

1. On the drawing surface, right-click the predicate shape for the Meeting
begins at StartTime fact type, and then click Fact Editor.
2. On the Fact tab, in the Object Name list that is displaying StartTime,
select Time, and then click OK.
3. Repeat steps 1 and 2, replacing StopTime with the Time object type in the
Meeting ends at StopTime fact type.
4. Delete the StartTime and StopTime shapes from the drawing surface, but
not from the data model.
! Eliminate redundant fact types

In this simplified scenario, no redundant fact types were introduced by the
previous tasks.
Important Had redundant fact types existed, you would have removed them
from the model while preserving any sample data.
! Validate the new fact types

1. On the Database menu, point to View, and then click Verbalizer.
2. On the drawing surface, click the predicate shape for the Meeting begins at
Time fact type. Verify that the following text is displayed in the Verbalizer
window:
Meeting begins at Time
3. On the drawing surface, click the predicate shape for the Meeting ends at
Time fact type. Verify that the following text is displayed in the Verbalizer
window:
Meeting ends at Time
Tip You may select all of the objects and fact types in the model to validate
and open the Verbalizer once. It will contain the statements for all of the
objects and fact types.
Lesson Review
Objectives
Objectives
Implement
Implementprimitive
primitiveentity
entitytypes
types
Describe
Describeand
and identify
identify aaconceptual
conceptualpartitioning
partitioning
scheme
scheme
Describe
Describeand
and identify
identify partitioning
partitioning objects
objects
Describe
Describeand
and identify
identify primitive
primitiveentity
entity types
types
Coalesce
Coalesceentity
entity types
types

1. What is a partition that is both mutually exclusive and exhaustive?
It has no overlapping members in any partitions, and a partition exists
for all possible members.
2. How are primitive entity types different from object types?

Object types are subdivided into entity types and value types. Primitive
entity types represent the most basic entity type in a UoD, and they are
mutually exclusive and exhaustive.
Lesson: Implementing Derived Fact Types
! What Are Derived Fact Types?

! How to Implement Derived Fact Types
! Practice: Implementing Derived Fact Types
Scheduling Theme

Introduction In this lesson, you will learn the skills and knowledge necessary to implement
arithmetically derived fact types.
Lesson purpose During the implementation of a conceptual partitioning scheme, value types
that represent strings and numbers are identified. The purpose of this lesson is
to further trim the schema by decomposing those value types that can be
derived into simpler fact types.
! Implement derived fact types.
Describe and identify role names.
Describe derived fact types and their uses.
What Are Derived Fact Types?
! Definition
A derived fact type is inferred from roles in other fact types
! Characteristics
" Derivation rule
" Derived vs. derived and stored
" Use of role names
! How derived fact types are symbolized

Introduction Derived data often contains hidden or implied information. A common source
of derived data is mathematical calculations. One of the goals of CSDP step 3 is
to convert all arithmetically derived data into derived fact types.
Definition A derived fact type is inferred from roles in other fact types.
Characteristics Derived fact types exhibit three important characteristics:
! Derivation rule
You must document the business rules that allow you to derive the fact
types population. The derivation rule should convey business requirements
in terms that the domain expert can understand.
For example, the extended cost of a line item in an invoice order detail is
derived from calculating the unit price multiplied by the number of units.
! Derived vs. derived and stored
Derived fact types that are designated as derived and stored calculate
instances when writing to the database. Derived fact types that are
designated simply as derived calculate instances during a query.
Note While you can designate whether a derived fact type is stored in an
ORM model, it is really a physical implementation issue.
! Use of role names

Remember that an object type may play a role in more than one fact type.
You can assign a given role a unique name so that a derivation rule can
unambiguously refer to the proper role.
How derived fact types Derived fact types are symbolized just as any other fact type but with the
are symbolized addition of an asterisk next to the fact types predicate shape. Fact types that are
derived are denoted by a single asterisk at the end of their predicate phrases.
Fact types that are derived and stored are denoted by double asterisks at the end
of their predicate phrases.
How to Implement Derived Fact Types
Identify
Identifyexisting
existing object
object types
typesand
and fact
fact types
types
Assign
Assign role
rolenames
names
Create
Create aanew
new fact
facttype
type that
thatincorporates
incorporates aanew
new
object
object type
type
Designate
Designatethethe fact
facttype
type as
asderived
derivedand
andassign
assignaa
derivation
derivation rule
rule
Validate
Validate the
thenew
new fact
facttypes
types

Introduction The procedure to implement derived fact types is the same for all types of
derivation rules.
Procedure Use the following procedure to implement derived fact types:
1. Identify existing object types and fact types.
The object types that you use in your derivation rule must already exist in
the model. Remember that an object type may play a role in more than one
fact type.
2. Assign role names.
You will assign role names to avoid ambiguity in your derivation rule, and
to explicitly identify an object types role in a given fact type.
3. Create a new fact type that incorporates a new object type.
The new object type will represent the instances of derived data. These
instances are related to one or more of the existing object types through the
derivation rule. The new fact models this relationship.
4. Designate the fact type as derived, and assign a derivation rule.
You can now express a derivation rule in terms of role names and a fact
type. Consider how you would like to implement the derived fact type in the
physical schema. You do this in conjunction with modifying the existing
fact types.
5. Validate the new fact types.
Check to make sure that the new fact type appropriately represents a
meaningful sample population, and that you have captured the intent of the
domain expert.
Practice: Implementing Derived Fact TypesScheduling Theme
! Purpose
! Scenario
! Practice
Mon Tue Wed Thu Fri
8 am
Out of Office:
9 00 Doctors Appt
Manager
1:1 All-han
10 00 Quaterl
Team
11 00 Traini
Brownbag Class
12 pm Lunch: ORM
2 00
Data
Modeling
Project
Data
Modeling
Project
Model Model 3 00
4 00
5 00

Introduction In this practice, you will implement derived fact types by using the Scheduling
Theme that you are already familiar with.
Purpose The purpose of this practice is to illustrate how you use an arithmetically
derived fact type to capture a business rule by using the Scheduling Theme.
Scenario For the purpose of this practice, the UoD is limited to the information in this
scenario.
You have met with the domain expert and are now attempting to replace
arithmetically derivable information in your model with derived fact types. The
domain expert has provided you with the following information:
! You are to model the starting time and ending time for each meeting.
! You can calculate the duration of a meeting by subtracting the difference
between the start time and the stop time.
! Identify existing object types

Open and review the ImplDerived_Scheduling.vsd ORM source model.
Which entity type or types can you use to calculate the duration of a
meeting?
Time.
____________________________________________________________
____________________________________________________________
Which fact types have roles that can you use to calculate the duration of a
meeting?
Meeting begins at Time.
Meeting ends at Time.
____________________________________________________________
____________________________________________________________
! Assign role names

1. On the drawing surface, right-click the predicate shape for the Meeting
begins at Time fact type, and then click Database Properties.
2. In the Database Properties window, on the Database Properties tab, in the
Categories list, click Readings.
3. In the Role name (role 2) box, type BeginTime
4. On the drawing surface, click the predicate shape for the Meeting ends at
Time fact type.
Categories list, click Readings.
6. In the Role name (role 2) box, type EndTime
! Create a new fact type that incorporates a new object type

1. Use the Business Rules window and the Fact Editor to create the new
Meeting has Duration fact type.
If needed, refer to the previous topic, How to Enter Facts into the
Conceptual Model, for detailed instructions.
2. Draw the new fact type by dragging and dropping it onto the drawing
surface.
! Designate the fact type as derived and assign a derivation rule

1. On the drawing surface, right-click the predicate shape for the Meeting has
Duration fact type, and then click Database Properties.
Categories list, click Derived.
3. In the Derivation Rule pane, select Derived and Stored.
4. In the Derivation Rule pane, in the Rule box, type:
Meeting.EndTime - Meeting.BeginTime.
! Validate the new fact types

2. On the drawing surface, click the predicate shape for the Meeting has
Duration fact type. Verify that the following text is displayed in the
Verbalizer window:
Derived (and stored) by rule: Meeting.EndTime -
Meeting.BeginTime.
Lesson Review
Objectives
Objectives
Implement
Implementderived
derived fact
facttypes
types
Describe
Describeand
and identify
identify role
rolenames
names
Describe
Describederived
derived fact
fact types
typesand
and their
theiruses
uses

1. Why would you store a derived fact type in a database?
To facilitate efficient querying of derived value instances. Only the
derived value need be retrieved; the constituent parts are not needed
for the query. Additionally, you may want to record the derived value
as a point in time.
2. What is a derived fact type?

A fact type that is inferred from roles in other fact types.

! Discussion: Applying CSDP Step 3Airline Flights
Theme

Introduction In this lesson, you will combine the skills and knowledge of parts 1 and 2 of
CSDP step 3 and implement both on the practice themes that you are already
familiar with.
Implement primitive entity types.
CSDP step 3: Check for entity types that should be

combined, and note any arithmetic derivations
" Trim schema
" Coalesce like sets
" Eliminate use of value types for calculated data

Introduction This lesson covers the use of Microsoft Visio Enterprise Architect edition in
the third step of the CSDP. It is important that you follow the CSDP procedures
to generate a well-designed ORM model.
CSDP step 3 Check for entity types that should be combined, and note any arithmetic
derivations.
Examine facts for opportunities to simplify the model by combining appropriate
object types and defining calculated value types.
Trim schema The primary goal of CSDP step 3 is to coalesce redundant object types into a
simpler conceptual representation. You will analyze and modify the model
based on the concept of object type partitioning.
Coalesce like sets An ORM model represents facts, in the form of set relationships, and
underlying rules. The process of constructing the initial ORM model may not
reduce these set relationships to their lowest common denominators. Coalesce
like sets at this stage in the modeling process to ensure a sound model.
Eliminate use of value Often, the domain of values for a value type is derived from an arithmetic
types for calculated data calculation. Properly modeled ORM diagrams do not represent derived data as
value types. A goal of CSDP step 3 is to model all derived data as derived fact
types.
Identify
Identifythe
theconceptual
conceptualpartitioning
partitioning scheme
scheme
Implement
Implementprimitive
primitiveentity
entitytypes
types
Identify
Identifyderived
derived data
dataand
andimplement
implementderived
derived fact
fact
types
types
Validate
Validate your
yourintent
intentwith
withthe
theVerbalizer
Verbalizer

Introduction This topic instructs you on how to apply CSDP step 3. Follow the procedure
outlined in the text below. You have already learned the concepts and each of
the steps in this procedure.
Procedure Use the following procedure to apply CSDP step 3:
1. Identify the conceptual partitioning scheme.
You will use the conceptual partitioning scheme as the basis for identifying
primitive entity types and derived data. The scheme will evolve as you
apply CSDP step 3. When finished, make sure that your scheme is
exhaustive and that all object types are mutually exclusive.
2. Implement primitive entity types.
You can implement primitive types to simplify your model and reduce
redundancy. The process of identifying primitive entity types will aid you in
discovering derived data.
3. Identify arithmetically derived data and implement derived fact types.
Eliminate all object types from the model that represent arithmetically
derived data. You should model this information as derived fact types.
Tip Remember to transfer existing sample data from the redundant fact
types to the new derived fact types to assist in validating the model.
4. Validate your intent with the Verbalizer.

After each CSDP step, it is important that you verify that you have modeled
what you and the domain expert intended.
! Purpose
! Scenario
! Practice
London
UK11 (LHR)
US72
IT37
New York
Madrid Rome
(JFK)
ES2 (MAD) (FCO)
Atlanta 3 US62
VE56
(ATL)
VE59
US68 Dakar
Starting VE56
(DKR)
Model Caracas
(CCS)

Introduction In this practice, you will apply CSDP step 3 to the Airline Flights Theme that
Purpose The purpose of this practice is to illustrate how to apply CSDP step 3 to a
modeling scenario by using the Airline Flights Theme. You will coalesce
entities that share a common primitive entity type and model an arithmetically
derived fact type.
Scenario You are tasked with modeling elements of the current state of a group of airline
flights. For the purpose of this practice, the UoD is limited to the information in
this scenario.
You have met with the domain expert and are now attempting to trim a portion
of the schema in your initial data model and implement an arithmetically
derived fact type. The domain expert has provided you with the following
information:
! Each city has flights that both take off and land there.
! You do not need to model any differences between eastbound and
westbound flights, aside from their originating and terminating cities.
! All flight departure times are stored in local time.
! The time zone offset for each city is available. You also need to calculate
but not storedeparture times in Greenwich Mean Time (GMT).
Practice In this practice, you will apply the steps that you learned in a previous lesson to
the Airline Flights Theme described in the scenario. Refer to those detailed
procedures if you need assistance.
! Identify the conceptual partitioning scheme

Open and review the ApplyCSDP3_Airline.vsd ORM source model.
Which object types share a common primitive entity type, and what are
those shared primitive types?
EastboundFlight and WestboundFlight are both based on Flight.
OriginationCity and TerminationCity are both based on City.
____________________________________________________________
____________________________________________________________
! Implement primitive entity types

1. Replace EastboundFlight and WestboundFlight in all fact types with a
new entity type called Flight.
2. Replace OriginationCity and TerminationCity in all fact types with a new
entity type called City.
3. Delete EastboundFlight, WestboundFlight, OriginationCity, and
TerminationCity from the drawing surface, but not the model.
4. Remove redundant fact types from the model.
5. For clarity, reorganize the layout of the shapes on the drawing surface.
! Identify arithmetically derived data, and implement derived fact types

1. Review the example data contained in the Flight has local departure Time
and the City local time differs by GMTOffset fact types.
2. Assign the role name of LocalTime to the Time role in the Flight has local
departure Time fact type.
3. Create and draw a new fact type called Flight has GMT departure Time.
4. In the Flight has GMT departure Time fact type, designate the following
derived, but not stored, derivation rule:
dateadd(hh, Flight.GMTOffset, Flight.LocalTime)
! Validate your intent with the Verbalizer

1. Select all predicate shapes on the drawing surface.
2. Use the Verbalizer and verify that the following text is displayed in the
Verbalizer window:
Flight takes off from City lands in City
Flight has local departure Time
City local time differs by GMTOffset
Flight has GMT departure Time

Derived by rule: dateadd(hh, Flight.GMTOffset,
Flight.LocalTime)
! Identify the conceptual partitioning scheme

! Implement primitive entity types
! Identify arithmetically derived data, and
implement derived fact types
London
UK11
(LHR)
US72
IT37
New York
Madrid Rome
(JFK)
ES2 (MAD) (FCO)
Atlanta 3 US62
VE56
(ATL)
VE59
US68 Dakar
Solution VE56
(DKR)
Model Caracas
(CCS)

Discussion The purpose of this practice was to illustrate how to apply CSDP step 3 to a
modeling scenario by using the Airline Flights Theme.
Identify the conceptual You identified two each of different types of flights and cities to coalesce into
partitioning scheme common primitive entity types.
According to the scenario, you do not need to model the distinction between
eastbound and westbound flights; therefore, a single Flights entity type could
represent all flights. OriginationCity and TerminationCity share a common
domain. Also, the populations of these object types are not mutually exclusive.
Primitive entity types are usually discovered by examining fact instances, or
how they are used in a model.
Implement primitive You edited existing fact types that used the EastboundFlight and
entity types WestboundFlight entity types to replace those entity types with Flight. You
then edited existing fact types that used the OriginationCity and
TerminationCity entity types to replace those entity types with City.
By implementing primitive entity types, the EastboundFlight takes off from
OriginationCity lands in TerminationCity and WestboundFlight takes off
from OriginationCity lands in TerminationCity fact types were replaced
with the single Flight takes off from City lands in City fact type.
The changes were implemented, in place, to existing fact types. This preserves
example data and fact types.
Identify arithmetically You created a new arithmetically derived fact type to model GMT flight
derived data and departure times, referencing roles in the Flight has local departure Time and
implement derived fact City local time differs by GMTOffset fact types.
types
Because the Time value type appears in more than one fact type that also
includes the Flight entity type, you had to use role names to clearly refer to the
desired role in the derivation rule. The data types of the Time and GMToffset
value types are appropriate for the derivation rule.
The roles used in the derivation rule are valid because all of those roles are
related through a join path through the Flight object type.
Validate intent You coalesced entities that share a common primitive entity type to form the
Flight takes off from City lands in City fact type, as supported by the
following scenario information:
! Each city has flights that both take off and land there.
! You do not need to model any differences between eastbound and
westbound flights, aside from their originating and terminating cities.
You modeled a new Flight has GMT departure Time derived fact type that
calculates GMT time from a flights local time and a citys GMT time zone
offset value, as supported by the following information:
! All flight departure times are stored in local time.
! The time zone offset for each city is available. You need to also calculate,
but not store departure times in GMT.
You then used the text output from the Verbalizer to validate that the
requirements of the scenario were met. You should also reevaluate any example
data that you entered or possibly deleted while applying CSDP step 3.
Lesson Review
Objectives
Objectives
Apply
Apply CSDP
CSDPstep
step33to
toaamodeling
modelingscenario
scenario
Implement
Implementprimitive
primitiveentity
entitytypes
types
Implement
Implementderived
derived fact
facttypes
types

1. What is the primary goal of CSDP step 3?
To coalesce redundant object types into a simpler conceptual
representation.
2. Why do you eliminate the use of value types for calculated data?
Properly modeled ORM diagrams do not represent derived data as
value types. A goal of CSDP step 3 is to model all derived data as
derived fact types.
Module Review
! Implementing Primitive Entity Types

! Implementing Derived Fact Types

1. What is a conceptual partitioning scheme?
The systematic separation of the UoDs population into meaningful
object types.
2. What are primitive entity types?

The most basic entity types in the UoD. They are the lowest common
denominator of a group of entity types.
3. What are nested entity types?

Relationships that you consider as an object.
4. What characteristics are common to all primitive entity types?

Atomicity and mutual exclusivity.
5. What is the significance of a fact type with an asterisk next to the predicate
shape?
The presence of an asterisk next to a predicates shape indicates that
the fact type is derived.
Lab A: Implementing Primitive Entity Types and Derived

! Exercise 1: Identifying the Conceptual
Partitioning Scheme
! Exercise 2: Implementing Primitive Entity
Types
! Exercise 3: Implementing Arithmetically
Derived Fact Types

Objectives This lab will reinforce your understanding of CSDP step 3, as well as the skills
! Apply Conceptual Schema Design Procedure step 3.
Prerequisites Before working on this lab, you must:

! Have completed CSDP steps 1 and 2.
! Be able to identify a conceptual partitioning scheme.
! Be able to implement primitive entity types.
! Be able to identify arithmetically derived data and implement derived fact
types.
For more information The procedures in this lab are a series of directives. If needed, refer to the
practices in the module for detailed implementation instructions. Additionally,
use the appendixes in this course for a symbol guide and a glossary of terms.
Scenario This lab uses the Academic Theme that you are already familiar with. Refer to
the scenario sections of each exercise for more information. An ORM source
model is provided that represents limited information about the academic
faculty of a college, as well as departmental budget information.
You will use the files in the C:\MOC\2090\Labfiles folder to complete this lab.
Solution files for each exercise are in the Answer subdirectory of that folder.
Estimated time to
complete this lab:
30 minutes
Exercise 0
Lab Setup
box.
5. Click OK.
Exercise 1
Identifying the Conceptual Partitioning Scheme
In this exercise, you will identify a conceptual partitioning scheme by using the
Academic Theme.
Scenario You are tasked with analyzing the information in an ORM source to formulate a
conceptual partitioning scheme.
Tasks
! Look for commonalities among object types and fact types
Open and review the ApplyCSDP3_Academic.vsd ORM source model.
Which object types share a common reference mode?
DepartmentHead, SeniorLecturer, Lecturer, and Professor are all
identified by EmployeeName.
____________________________________________________________
____________________________________________________________
Which fact types share a common predicate phrase?

SeniorLecturer works for Department, Lecturer works for Department,
and Professor works for Department.
Department is allocated a TeachingBudget, and Department is allocated
a ResearchBudget.
____________________________________________________________
____________________________________________________________
Which entity types have a common unit of measurement based on reference

mode?
TeachingBudget and ResearchBudget both are measured as money.
____________________________________________________________
____________________________________________________________
! Look for the need to manipulate query results

Envision how you would query information represented by the data model.
What types of query results could contain information from more than one
object types population in the same column?
All employees that work for a department would be in the same
column, irrespective of their job titles.
Both the teaching budget and the research budget of a department
could be in the same column.
____________________________________________________________
____________________________________________________________
! Identify common primitive entity types

Consider characteristics of the object types and fact types in the ORM
model.
As indicated by their common reference mode and predicate phrase, what
primitive entity types do the DepartmentHead, SeniorLecturer, Lecturer,
and Professor entity types all share?
Employee.
____________________________________________________________
____________________________________________________________
As indicated by the common unit of measurement based on reference mode,

what primitive entity type do the TeachingBudget and ResearchBudget
entity types both share?
Budget.
____________________________________________________________
____________________________________________________________
What other atomic entity type or types exist in the model in primitive form?
Department.
____________________________________________________________
____________________________________________________________
Exercise 2
Implementing Primitive Entity Types
In this exercise, you will implement primitive entity types in an ORM model by
using the Academic Theme.
Scenario You have identified two primitive entity types that you must implement in an
ORM model.
Tasks ! Implement primitive entity types
1. Create an object type named Academic with a reference mode of
EmployeeNumber.
2. Create an object type named Budget with a reference mode of USD.
3. In all of the fact types that include object types with a reference mode of
EmployeeNumber, replace the referenced object type with Academic.
4. Create and draw a new Academic has Rank fact type to preserve the
distinction in the model between different types of academic employees.
5. Identify the fact type that references TeachingBudget. Change the predicate
phrase to include the word teaching, and replace TeachingBudget with a
new entity type called Budget.
6. Identify the fact type that references ResearchBudget. Change the predicate
phrase to include the word research, and replace ResearchBudget with
the new entity type called Budget.
7. Delete the object types replaced in steps 3-5 from the drawing surface, but
not from the model.
8. Remove redundant fact types from the model.
9. For clarity, reorganize the layout of the shapes on the drawing surface.

Verbalizer window:
Academic has Rank
Department is allocated a teaching Budget
Department has research BudgetFactor
Department is allocated a research Budget
If needed, review the solution file for this exercise located in the
C:\MOC\2090\Labfiles\Mod04\Answer folder.
Exercise 3
Implementing Arithmetically Derived Fact Types
In this exercise, you will implement an arithmetically derived fact type in an
ORM model by using the Academic Theme.
Scenario You are tasked with modifying a regular fact type so that its population is
arithmetically derived and stored in a database.
In this scenario, each department is assigned a teaching budget. A given
departments research budget is determined as a percentage of the teaching
budget. This percentage ratio is known as a departments budget factor.
Tasks ! Identify arithmetically derived data and implement derived fact types
1. Review the example data contained in each of the fact types related to a
departments budget.
2. Assign the role name of TeachingBudget to the Budget role in the fact type
that represents a departments teaching budget.
3. In the fact type that represents a departments research budget, designate a
derivation rule that calculates and stores the research budget of a department
as a percentage of its teaching budget.

Verbalizer window:
Department is allocated a research Budget
Derived (and stored) by rule: Department.TeachingBudget
* Department.BudgetFactor.
C:\MOC\2090\Labfiles\Mod04\Answer folder.
Module 5: Adding
Uniqueness Constraints
and Checking Arity of
Fact TypesCSDP
Contents
Step 4
Module Overview 1
Lesson: Implementing Uniqueness
Constraints 2
Lesson: Implementing Nested Object
Types 15
Lesson: Checking Fact Arity 22
Module Review 40
Lab A: Adding Uniqueness Constraints
and Checking Arity of Fact Types 41
other countries.
respective owners.
reserved.
Module 5: Adding Uniqueness Constraints and Checking Arity of Fact TypesCSDP Step 4 iii
Instructor Notes
(CSDP) step 4. This step covers uniqueness and arity of facts. In the step that
this module covers, students will learn about the concepts of uniqueness
constraints and arity of facts.
30 minutes
! Apply CSDP step 4 to an Object Role Modeling (ORM) model.
Implement uniqueness constraints.
Identify fact arity.

Publishers.
iv Module 5: Adding Uniqueness Constraints and Checking Arity of Fact TypesCSDP Step 4

In this module, students will learn about uniqueness constraints and how to
identify and apply them to a database model. Next, they will learn to identify
the arity of a fact and, if necessary, split the fact. Finally, students will apply
both of these to the database models with the themes that they are already
familiar with.
Lesson: Implementing Uniqueness Constraints

lesson.
What Are Uniqueness This page defines uniqueness constraints and lists the characteristics common to
Constraints? all uniqueness constraints in an ORM model.
How Internal This page displays the variations of the shapes of internal uniqueness
Uniqueness Constraints constraints within an ORM model. Each variation is shown with an example of
Are Symbolized how it is used and the specific definition of what it represents on each model.
How External This page displays the variations of the shapes of external uniqueness
Uniqueness Constraints constraints within an ORM model. Each variation is shown with an example of
Are Symbolized how it is used and the specific definition of what it represents on each model.
Note that in Figures 5.10 and 5.11, there should be an internal simple
uniqueness constraint over the A roles, but it was left off to reinforce the
external uniqueness constraint.
How to Implement This page covers the sub-tasks for implementing uniqueness constraints on an
Uniqueness Constraints ORM model.
Practice: Implementing This page reinforces the elements of the previous page through practice of the
Uniqueness procedure by using the Scheduling Theme.
Constraints
Scheduling Theme
Lesson Review
ask questions. After answering the questions, allow students to openly discuss
any of the topics covered.
Lesson: Implementing Nested Object Types

lesson.
What Are Nested Object This page defines nested object types, lists their characteristics and gives
Types? examples of how they are symbolized.
How to Implement This page covers the subtasks to implement nested object types using the ORM
Nested Object Types model.
Nested Object Types procedure by using the Scheduling Theme.
Scheduling Theme
Module 5: Adding Uniqueness Constraints and Checking Arity of Fact TypesCSDP Step 4 v
Lesson Review
ask questions. After answering the questions, allow students to discuss openly
Lesson: Checking Fact Arity

lesson.
What is a Key Length This page defines and describes what a key length check is and how they relate
Check? to internal uniqueness constraints.
When to Split Fact This page lists the criteria used to determine whether a fact type must be split.
Types Make sure that you point out that any one or any combination of these criteria
that proves to be true is sufficient to split the fact type. Also point out that
students must continually reapply these criteria to each split until all facts are
elementary.
Guidelines for Splitting This page covers the guidelines used to preserve data when you must split a fact
Fact Types type. Ensure that students understand the difference between what is on the
preceding When to Split Fact Types topic page and this page. If any of the
criteria on the first page is true, then the fact type must be split; if it must be
split, use these guidelines to preserve the existing data.
How to Split Fact Types This page covers the sub-tasks for splitting fact types in an ORM model.
Practice: Splitting Fact This page reinforces the elements of the previous page through practice of the
TypesScheduling procedure by using the Scheduling Theme.
Theme
Lesson Review

lesson.
Focus of CSDP Step 4 This topic page covers the grand scheme of the CSDP step 4. It is intended as a
will be covered in greater detail on subsequent topic pages.
How to Apply CSDP This topic page is intended as a walk through of CSDP step 4. Guide students
Scheduling Theme that students should already be familiar with. You should
use Microsoft Visio Enterprise Architect edition to conceptually validate the
ORM model after all remaining CSDP steps. During this process, Visio checks
for illegal constructs in ORM, but not whether you have captured business
requirements appropriately.
vi Module 5: Adding Uniqueness Constraints and Checking Arity of Fact TypesCSDP Step 4
Theme alone, but be available to answer questions.
Discussion:Applying This topic page is intended for you to discuss the steps from the previous topic
CSDP Step 4Airline page. Explain why each task was completed in the manner it was done.
Flights Theme
One or more students may notice that flight DR-342 follows contiguous routes,
Boston to Denver, and Denver to Los Angeles. You may acknowledge that fact,
but ring constraints will be discussed later in the course.
Lesson Review
Module Review
After answering questions, allow students to discuss openly any of the topics
covered.
Lab A: Adding Uniqueness Constraints and Checking Arity of Fact

Types
Lab Setup
Lab Results
or customization.
Module 5: Adding Uniqueness Constraints and Checking Arity of Fact TypesCSDP Step 4 1
Module Overview
! Implementing Uniqueness Constraints

! Implementing Nested Object Types
! Checking Fact Arity

Introduction This module teaches you the knowledge and skills necessary to complete the
Conceptual Schema Design Procedure (CSDP) step 4. In this module, you will
primarily be dealing with information at the conceptual level. You will continue
to develop your skills by using the themes that you are already familiar with
from the previous modules.
Module Objectives After completing this module, you will be able to:
! Apply CSDP step 4 to an Object Role Modeling (ORM) model.
Implement uniqueness constraints.
Implement nested object types.
Identify fact arity.
2 Module 5: Adding Uniqueness Constraints and Checking Arity of Fact TypesCSDP Step 4
Lesson: Implementing Uniqueness Constraints
! What Are Uniqueness Constraints?

! How Internal Uniqueness Constraints Are Symbolized
! How External Uniqueness Constraints Are Symbolized
! How to Implement Uniqueness Constraints
! Practice: Implementing Uniqueness Constraints
Scheduling Theme

Introduction In this lesson, you will learn CSDP step 4 and use this to refine models that you
developed in step 3.
! Implement uniqueness constraints.
Define uniqueness constraints.
Identify internal and external uniqueness constraints by their respective
shapes.
What Are Uniqueness Constraints?
! Definition
A uniqueness constraint prevents duplication of role
instances spanned by the constraint
! Characteristics
" Prevent fact redundancy
" Enforce internal uniqueness
" Enforce external uniqueness
" Enforce functional dependency

Introduction You should strive to explicitly test and enforce uniqueness to ensure the strict
use of elementary facts and to eliminate redundancy.
Definition A uniqueness constraint prevents duplication of role instances spanned by the
constraint. Uniqueness constraints can overlap other uniqueness constraints. A
uniqueness constraint placed across all roles in a predicate effectively prevents
the duplication of instances of the fact type.
Characteristics Uniqueness constraints:
! Prevent fact redundancy.
One purpose of a uniqueness constraint is to ensure that no fact instances
may be repeated. Because the combinations of roles make up the fact, this
has the effect of limiting the population of the roles spanned by the
uniqueness constraint.
! Enforce internal uniqueness.
A uniqueness constraint on roles within a single predicate is an internal
uniqueness constraint. An internal uniqueness constraint ensures that fact
table entries for a role, or combination of roles within a single predicate,
occur there only once. All instances of a fact type must be unique for it to be
elementary.
! Enforce external uniqueness.
A uniqueness constraint that spans roles from different predicates is an
external uniqueness constraint. An external uniqueness constraint spans
roles from two or more predicates and ensures that instances of the role
combination occur there only once.
! Enforce functional dependency.
A combination of one or more roles is functionally dependent on another
combination of one or more roles if there is at most one instance of the
former for each instance of the latter.
How Internal Uniqueness Constraints Are Symbolized
! Internal uniqueness
constraint symbol
" Arrow-tipped line
over role shape
" Spans one or more
roles A
Figure 5.1

Introduction This topic page covers the ORM symbol for an internal uniqueness constraint.
The internal uniqueness constraint symbol annotates an existing predicate
shape.
Internal uniqueness The internal uniqueness symbol is basically the same for predicates, regardless
constraint symbol of arity. The following tables provide examples of internal uniqueness
constraints.
Table 5.1
Internal uniqueness constraint

A simple uniqueness constraint spans a single
role.
All internal uniqueness constraints are
symbolized by an arrow-tipped line over the
roles included in the uniqueness constraint. All instances of A are unique.
Examples of internal Table 5.2

uniqueness constraints
on binary facts Uniqueness constraint meaning Symbol
For each instance of A, there exists one

instance of B.
For example:
(apple, car)
(orange, train)
(pear, train)
All instances of AB are unique.
For example:
(apple, car)
(orange, train)
(apple, train)
For each instance of A, there exists one
instance of B,
and
For each instance of B, there exists one
instance of A.
For example:
(apple, car)
(orange, train)
(pear, bus)

on ternary facts Uniqueness constraint meaning Symbol
For each instance of AB, there exists one

instance of C.
For example:
(apple, car, 40)
(orange, train, 40)
(apple, train, 50)
(orange, bus, 40)
For each instance of AC, there exists one
instance of B.
For example:
(apple, car, 40)
(orange, car, 50)
(apple, train, 50)
(orange, bus, 40)
All instances of ABC are unique.
Tip To better understand a given uniqueness constraints meaning, disregard

roles that the uniqueness constraint does not span.

overlapping uniqueness
constraints on a fact Uniqueness constraint meaning Symbol
For each instance of AB, there exists one

instance of C,
and
For each instance of AC, there exists one
instance of B.
For example:
(apple, car, 40)
(orange, train, 40)
(apple, train, 50)
(pear, bus, 60)
How External Uniqueness Constraints Are Symbolized
External uniqueness
constraint symbol
" Dashed line between
roles
Circled U in middle of
U
"
line
" Line connects to roles
in the constraint
Figure 5.9

Introduction This topic page covers the ORM symbol for an external uniqueness constraint.
The external uniqueness constraint symbol annotates existing predicate shapes.
External uniqueness The external uniqueness constraint symbol spans roles in two or more fact
constraint symbol types. Table 5.5 provides an example of external uniqueness constraints.
Table 5.5
External uniqueness constraint

An external uniqueness constraint is
symbolized by a dashed line with a circled
letter U in the middle of the line.
The line end points connect to the roles in
different predicates that participate in the
external uniqueness constraint.
Examples of external The ORM diagram in Figure 5.10 illustrates an external uniqueness constraint
uniqueness constraints that spans roles in two fact types that share a common object type. The
population of both fact types is restricted to allow the unique combinations of
the two designated roles.
The external uniqueness constraint in Figure 5.10 has the meaning of all
instances of BC are unique in the population of the two facts.
Figure 5.10
The ORM diagram in Figure 5.11 illustrates an external uniqueness constraint

that involves three roles in two different fact types. The population of both fact
types is restricted only to allow the unique combinations of the three designated
roles.
The external uniqueness constraint in Figure 5.11 has the meaning of all
instances of BCD are unique in the population of the two facts.
Figure 5.11
How to Implement Uniqueness Constraints
Select
Select fact
fact types
types
Determine
Determine whether
whetherto
to use
use an
an internal
internalor
orexternal
external
uniqueness
uniquenessconstraint
constraint
Create
Create the
theuniqueness
constraint
Validate
Validate the
theuniqueness
constraint

Introduction Create uniqueness constraints to eliminate redundancy and ensure that all fact
types are elementary.
Procedure Use the following high-level procedure to implement uniqueness constraints:
1. Identify the fact type or types.
Uniqueness constraints are the first type of constraint placed on the model
during the CSDP steps.
Tip To help ensure that all fact types in the model are elementary, you
should evaluate placing an explicit uniqueness constraint on every fact type.
2. Determine whether to use an internal or external uniqueness constraint.

If all of the roles in the proposed uniqueness constraint are in one predicate,
you will implement an internal uniqueness constraint. If roles span more
than one predicate, then you must create an external uniqueness constraint.
3. Create the uniqueness constraint.
It is helpful to have sample data entered into the fact type to analyze and to
test the new uniqueness constraint. Select the roles from all of the fact types
that participate in the uniqueness constraint.
4. Validate the uniqueness constraint.
Use the Verbalizer to verify that the new uniqueness constraint captures the
intent of the domain expert. Analyze the uniqueness constraint with the tool
and consider its recommendations. The tool will display errors if your
constraints do not match those indicated by the sample data. If errors occur,
determine whether you need to improve your understanding of the Universe
of Discourse (UoD), correct problems in the sample data, or both.
Practice: Implementing Uniqueness ConstraintsScheduling

Theme
! Purpose
! Scenario
! Practice
Mon Tue Wed Thu Fri
8 am
Out of Office:
9 00 Doctors Appt
Manager
1:1 All-han
10 00 Quaterl
Team
11 00 Traini
Brownbag Class
12 pm Lunch: ORM
2 00
Data
Modeling
Project
Data
Modeling
Project
Model Model 3 00
4 00
5 00

Introduction In this practice, you will implement uniqueness constraints to prevent
redundancy and ensure that all fact types are elementary by using the
Purpose The purpose of this practice is to illustrate how to create an internal and an
external uniqueness constraint, and how to analyze sample data to validate the
constraints.
scenario.
You have met with the domain expert and are now attempting to prevent
instance redundancy in the model through the use of uniqueness constraints.
The domain expert has provided you with the following information:
! The combination of a persons first name and last name is unique.
! Each person can have only one first name and only one last name.
! A person can be invited only once to a specific meeting.
! Any person can invite more than one other person to a meeting.
! Identify the fact type or types

1. Open and review the ImplUnique_Scheduling.vsd ORM source model.
2. Review the example data contained in each of the fact types related to a
person.
Which fact types will be affected by new uniqueness constraints?
Person has FirstName.
Person has Lastname.
Person invites Person to Meeting.
____________________________________________________________
____________________________________________________________
! Determine whether to use an internal or external uniqueness constraint

Identify the roles in each fact type that participate in a uniqueness
constraint, as specified by the scenario.
Which roles form a unique tuple and are located in separate fact types?
The FirstName role of the Person has the FirstName fact type, and the
LastName role of the Person has the LastName fact type will
participate in an external uniqueness constraint because the roles are in
separate fact types.
____________________________________________________________
____________________________________________________________
Which roles form a unique tuple and are located in the same fact types?
The Meeting role and the second Person role of the Person invites
Person to Meeting fact type will participate in an internal uniqueness
constraint because the roles are in the same fact type.
____________________________________________________________
____________________________________________________________
! Create an internal uniqueness constraint

1. On the drawing surface, right-click the predicate shape for the Person
invites Person to Meeting fact type, and then click Add Constraints.
2. In the Add Constraint window, verify that Constraint Type value is set to
Uniqueness.
3. In the Select the role box for each role in the constraint pane, on the
[Person] invites [Person] to [Meeting] predicate shape, click the second
role box, and then click the third role box.
4. In the lower pane, verify that the following text is displayed, and then click
OK:
Given any Person and Meeting
at most one Person invites that Person to that Meeting.
! Create an external uniqueness constraint

1. On the drawing surface, click the predicate shape for the Person has
FirstName fact type, SHIFT+right-click the predicate shape for the Person
has LastName fact type, and then click Add Constraints.
2. In the Add Constraint window, verify that Constraint Type value is set to
Uniqueness.
[Person] has [FirstName] predicate shape, click the second role box.
[Person] has [LastName] predicate shape, click the second role box.
5. In the lower pane, verify that the following text is displayed, and then click
OK:
For each FirstName f and LastName l
there is at most one Person that
has FirstName f and has LastName l.
! Validate the uniqueness constraints

1. On the drawing surface, right-click the predicate shape for the Person has
FirstName fact type, and then click Database Properties.
Categories list, click Examples.
3. On the Database Properties tab, click Analyze
In the Example analysis results window, what message appears in the
Analysis results box?
The examples imply a uniqueness constraint over column 1.
____________________________________________________________
____________________________________________________________
4. Click Apply UC Constraints to create a new uniqueness constraint as

advised.
5. Repeat steps 1-4 by using the Person has LastName fact type.
Lesson Review
Objectives
Objectives
Implement
Implement uniqueness
constraints
Define
Defineuniqueness
uniquenessconstraints
constraints
Identify
Identifyinternal
internaland
and external
externaluniqueness
uniqueness
constraints
constraintsbybytheir
theirrespective
respectiveshapes
shapes

1. Define a uniqueness constraint.
A uniqueness constraint prevents duplication of role instances spanned
by the constraint. Uniqueness constraints can overlap other uniqueness
constraints. A uniqueness constraint placed across all roles in a
predicate effectively prevents the duplication of instances of the fact
type.
2. What are the four main uses of uniqueness constraints?

They prevent fact redundancy and enforce internal uniqueness,
external uniqueness, and functional dependency.
3. What is the difference between an internal and an external uniqueness

constraint?
An internal uniqueness constraint spans the roles of a predicate within
a single fact type. An external uniqueness constraint spans the roles
from two or more fact types.
Lesson: Implementing Nested Object Types
! What Are Nested Object Types?

! How to Implement Nested Object Types
! Practice: Implementing Nested Object Types
Scheduling Theme

Introduction In this lesson, you will learn what a nested object type is. Nested object types
are used to refer to a fact type as if it were an object type.
Lesson purpose The purpose of this lesson is to introduce you to nested object types and how
they are used.
! Implement nested object types.
Define nested object types.
What Are Nested Object Types?
! Definition
" A nested object type is a fact type that is treated as an
object type and has an internal structure that is
composed of the roles in a fact types predicate
! Characteristics
" Play a role in another fact type
" Used with external constraints between fact types
! How nested objects are symbolized

Introduction Sometimes you need to refer to a relationship in the same manner that you refer
to object types. You will use nested object types to refer to relationships in this
and other CSDP steps.
Definition A nested object type is a fact type that is treated as an object type. A nested
object has internal structure that is composed of the roles in a fact types
predicate. A uniqueness constraint must normally span all roles in the
objectified predicate.
Characteristics Nested object types can:
! Play a role in another fact type.
Objectify a relationship by designating it as a nested object type. You can
then use the nested object type just as you would any other object type in the
model. This is particularly helpful for modeling the creation of a fact
instance as an event.
! Be used with external constraints between fact types.
Typically, you place an external constraint between roles in two or more
fact types. By using nested object types, you can place external constraints
that restrict combinations of instances of different fact types.
How nested objects are A nested object type is symbolized by a soft rectangle around the objectified
symbolized predicate shape.
The diagram in Figure 5.12 is an example of a nested entity type in the
Scheduling Scenario. The fact type that represents the relationship between
location, time, and subject has been objectified to create a nested entity type
called class. The student object type participates in a relationship with the
nested entity type called class.
Figure 5.12
Note It is not necessary to use nested object types to model all business
requirements. Alternatively, the diagram in Figure 5.13 is an equivalent
representation of the same business requirements that are represented by the
Class nested object type in Figure 5.12.
Figure 5.13
How to Implement Nested Object Types
Select
Select an
an existing
existingfact
fact type
type
Create
Create aauniqueness
constraintthat
thatspans
spansall
allroles
roles
Designate
Designatepredicate
predicateas
as aanested
nestedobject
objecttype
typeand
and
assign
assign ititaa name
name
Validate
Validate your
yourintent
intentwith
withthe
theVerbalizer
Verbalizer

Introduction You can use nested object types as if they were any ordinary object type.
Procedure Use the following high-level procedure to implement nested object types:
1. Select an existing fact type.
Nested object types refer to an existing relationship. Use them when you
need to reference the relationship as if it were an object or to use it in
another fact type.
2. Create a uniqueness constraint that spans all roles.
Remember that nested object types must have a uniqueness constraint across
all roles in the nested fact type, except for 1:1 associations. If not, create
one, and verify that it is consistent with your sample data.
3. Designate predicate as a nested object type and assign it a name.
Once the proper uniqueness constraints are in place, objectify the predicate,
in effect creating a new object type that you can use in other fact types.
4. Validate your intent with the Verbalizer.
After the nested object type is created, use the Verbalizer to analyze the
Formal Object Role Modeling Language (FORML) expression for the
newly created nested object type. Verify that the new nested object type
captures the intent of the modeler.
Practice: Implementing Nested Object TypesScheduling Theme
! Purpose
! Scenario
! Practice
Mon Tue Wed Thu Fri
8 am
Out of Office:
9 00 Doctors Appt
Manager
1:1 All-han
10 00 Quaterl
Team
11 00 Traini
Brownbag Class
12 pm Lunch: ORM
2 00
Data
Modeling
Project
Data
Modeling
Project
Model Model 3 00
4 00
5 00

Introduction In this practice, you will implement a nested object type by using the
Purpose The purpose of this practice is to illustrate how to objectify a relationship so
that you can reference it as an object in another fact type.
scenario.
You have met with the domain expert and are now attempting to objectify a
relationship in the model through the use of a nested object type. The domain
! A person sends an invitation to another person for a meeting.
! A person can attend several meetings but can be invited only once to a
specific meeting.
! Select an existing fact type

1. Open and review the ImplNested_Scheduling.vsd ORM source model.
2. Review the example data contained in the Person is asked to attend
Meeting fact type.
! Create a uniqueness constraint that spans all roles

Create an internal uniqueness constraint that spans both roles in the Person
is asked to attend Meeting fact type.
! Designate predicate as a nested object type and assign it a name

1. On the drawing surface, right-click the predicate shape for the Person is
asked to attend Meeting fact type, and then click Fact Editor.
2. In the Fact EditorEdit existing Fact window, on the Advanced tab, in the
Objectify / Nest fact as box, type Invitation and then click OK.
3. Create a new fact type called Person sends Invitation, and drag it onto the
drawing surface.
4. Create an internal uniqueness constraint over the Invitation role of the
Person sends Invitation fact type.

2. On the drawing surface, click the predicate shape for the Person is asked to
attend Meeting fact type that is internal to the Invitation nested object
shape. Verify that the following text is displayed somewhere in the
Verbalizer window:
Person is asked to attend Meeting
It is possible that some Person is asked to attend more
than one Meeting and
that more than one Person is asked to attend some
Meeting.
This fact is nested as 'Invitation'.
3. On the drawing surface, click the nested object shape for the Invitation
object type. Verify that the following text is displayed somewhere in the
Verbalizer window:
Invitation is an entity object type.
Invitation is an alias for the nested fact type 'Person
is asked to attend Meeting'
4. On the drawing surface, click the predicate shape for the Person sends
Invitation fact type. Verify that the following text is displayed somewhere
in the Verbalizer window:
Person sends Invitation
For each Invitation i, at most one Person sends
Invitation i.
If needed, review the solution files for this practices located in the
Lesson Review
Objectives
Objectives
Implement
Implement nested
nested object
object types
types
Define
Definenested
nestedobject
objecttypes
types

1. Define nested object types.
A nested object type is a fact type that is treated as an object type. A
nested object has internal structure that is composed of the roles in a
fact types predicate. A uniqueness constraint must span all roles in the
objectified fact types predicate, unless the roles in the predicate have a
1:1 relationship (for example, Marriage).
2. How are nested object types used differently from ordinary object types?
Nested object types are relationships that are treated as an object type.
In all other respects, they are identical to ordinary object types.
Lesson: Checking Fact Arity
! What Is a Key Length Check?

! When to Split Fact Types
! Guidelines for Splitting Fact Types
! How to Split Fact Types
! Practice: Splitting Fact TypesScheduling Theme

Introduction Remember that arity is the number of roles in a fact type. You should strive to
create a model that has elementary facts only. In this lesson you will learn to
check the arity of fact types and split them if necessary.
! Describe fact arity and how it is used.
Define key length check.
Describe how to split fact types.
What Is a Key Length Check?
! Definition
A key length check ensures that a fact type with an arity of
2 or more has an explicit internal uniqueness constraint
that spans at least n-1 roles in the predicate
! Characteristics
" Number of roles is the key length
" Required by elementary fact types
" Split fact type if check fails

Introduction It is easy to include fact types that are too long or too short when creating a
conceptual schema design. A fact type that is too long has an arity higher than
what it should be. A fact type that is too short has an arity shorter than what it
should be.
Definition A key length check ensures that a fact type with an arity of 2 or more has an
explicit internal uniqueness constraint that spans at least n-1 roles in the
predicate.
Characteristics A key length check exhibits the following characteristics:
! Number of roles is the key length.
For a given fact type, a minimal combination of roles spanned by a
uniqueness constraint is called a key.
! Required by elementary fact types.
A fact type is not elementary if the key length rule is violated. Microsoft
Visio Enterprise Architect edition will display an error message in place of
a fact types regular FORML expression, warning the modeler that a fact
type is not elementary.
! Split fact type if check fails.
If a fact type does not satisfy the key length rule, you need to split up and
re-express it as two or more smaller fact types. While there are other reasons
to split fact types, an invalid key length is always sufficient cause.
When to Split Fact Types
Presence
Presence of
of redundant
redundant instances
instances
Invalid
Invalid key
key length
length
Presence
Presence of
of verbal
verbal conjunctions
conjunctions
Fact
Fact type
type is
is not
not elementary
elementary

Introduction Use the criteria on this page to determine what fact types you should split. Any
of these conditions is sufficient to indicate that the fact type is not elementary
and should be split.
Important Continue to check whether you should split each successive fact
type division until all resultant fact types are elementary.
Presence of redundant Check uniqueness constraints against meaningful sample data, and if possible,
instances actual data. Sample fact instances that repeat indicate that the fact type is not
elementary, or that the uniqueness constraints are incorrect or incomplete.
Invalid key length The number of roles in an internal uniqueness constraint indicates the key
length of that fact type. The key length rule states that the minimum valid
length of at least one key on a fact type is one less than the arity of the fact type.
If the key length is not valid, then the fact type is not elementary.
Presence of verbal Verbalize the fact type and look for the use of conjunctions in the FORML
conjunctions expression. If there is a conjunction between two objects with differing
primitive entity types, your fact type is not elementary.
Fact type is not The reason for splitting a fact type is because it is not elementary. Remember
elementary that, although it is not modeled, elementary fact types have an implied
uniqueness constraint spanning all roles in the fact type, meaning that all fact
type instances are unique.
Guidelines for Splitting Fact Types
Break
Break into
into elementary
elementary facts
facts
Preserve
Preserve constraints
constraints
Preserve
Preserve sample
sample data
data
Preserve
Preserve meaningful
meaningful relationships
relationships

Introduction When you split a fact type, it is important to preserve all of the information that
you have gathered so far. Use the guidelines on this topic page to help you
decide how a non-elementary fact type should be broken down.
Break into elementary Non-elementary facts are the result of combining elementary facts into one fact.
facts This is often the result of incomplete evaluation of external data. You should
look for the elementary facts in their combined form and model them
separately, while preserving the information that the original fact type
represented.
Tip You may duplicate a role from the original fact type in two or more new
fact types that were formed during a split. Remember that a role is just a case of
an object type being used in a particular way in a fact type.
Preserve constraints Always preserve the constraints placed on roles in the original fact type. These
constraints are there to represent the UoD accurately and to provide important
clues as to how to break the fact type down properly. You will compare
constraints in the original fact type with the ones in the new fact types that you
create to validate that you have not lost information in your model.
Note You should not break apart the roles spanned by internal uniqueness
constraints in a new fact type. However, you can duplicate them.
Preserve sample data You should have entered a meaningful sample population into the fact type that
you are splitting. Remember that the data in the columns in the sample data
table is associated with the roles in the fact type. If you opt to move a role into
another fact type during the split, you should also transfer the sample data that
goes with that role.
Preserve meaningful Remember that a fact type represents instances of a relationship between object
relationships types. The roles in the fact type were originally grouped together because you
observed them that way in the UoD. Before splitting roles up, ask yourself if
their individual meanings are the same as their joint meaning.
Note You can also view this as the need to preserve functional dependencies of
one role or roles with another role in the same fact type.
How to Split Fact Types
Create
Create new
newfact
facttypes
types by
byusing
usingthe
thesame
sameobject
object
types
types
Apply
Apply old
old constraints
constraints to
tonew
new fact
facttypes
types
Copy
Copy and
andpaste
pastesample
sampledata
datacolumns
columns
Validate
Validate new
new fact
fact types
typesand
andconstraints
constraints
Remove
Removethe
theold
old fact
fact type
typefrom
from the
themodel
model

Introduction Use the following procedure to split fact types into their most basic form,
creating two or more elementary facts.
Procedure 1. Create new fact types by using the same object types.
You are splitting a fact type because it is not elementary. Use the guidelines
from the previous topic page to decide what new fact types you should
create to properly model the same information.
2. Apply old constraints to new fact types.
Remember that constraints are placed on roles in a fact type. If you move
the roles to another fact type, you need to move the constraints associated
with it, as well.
3. Copy and paste sample data columns.
The same sample data associated with a given role stays with it when it is
moved or duplicated. You will need the sample data to validate the new fact
types and constraints.
4. Validate new fact types and constraints.
You need to ensure that the new fact types created from the split capture the
same meaning as the original non-elementary fact type. Use the Verbalizer
to validate the new fact types and sample data instances.
5. Remove the old fact type from the model.
After you have properly split the old fact type and have verified that the
modelers original intent is accurately modeled, it is safe to remove the old
fact type from the drawing surface and the model.
Practice: Splitting Fact TypesScheduling Theme
! Purpose
! Scenario
! Practice
Mon Tue Wed Thu Fri
8 am
Out of Office:
9 00 Doctors Appt
Manager
1:1 All-han
10 00 Quaterl
Team
11 00 Traini
Brownbag Class
12 pm Lunch: ORM
2 00
Data
Modeling
Project
Data
Modeling
Project
Model Model 3 00
4 00
5 00

Introduction In this practice, you will check fact type arity and split a fact type by using the
Purpose The purpose of this practice is to illustrate how to split a fact type based on a
key length check while preserving role functional dependencies.
scenario.
You have met with the domain expert and are now attempting to ensure that all
fact types in the model are elementary. The domain expert has provided you
! Each meeting can be held in one venue, at most.
! A person can receive no more than one invitation to a meeting.
! Create new fact types by using the same object types

1. Open and review the SplitFact_Scheduling.vsd ORM source model.
What is the arity of this fact type, and the largest key length on it?
The arity is 4, and the largest key length is 2.
____________________________________________________________
____________________________________________________________
2. Create a new fact type called Meeting is located at Venue.

3. Create a new fact type called Person invites Person to Meeting.
! Apply old constraints to new fact types

1. Create an internal uniqueness constraint over the Meeting role of the
Meeting is located at Venue fact type.
2. Create an internal uniqueness constraint that spans the second Person role
and the Meeting role of the Person invites Person to Meeting fact type.
! Copy and paste sample data columns

invites Person to Meeting located at Venue fact type, and then click
Database Properties.
Categories list, click Examples.
3. In the examples data grid, click the first Person column heading, drag the
mouse over to the Meeting column heading, right-click the Meeting column
heading, and then click Copy.
4. On the drawing surface, click the predicate shape for the new Person
invites Person to Meeting fact type.
5. In the examples data grid, right-click the cell in the first row of the first
Person column, and then click Paste.
6. In the examples data grid, click the cell in the next to the last row of the first
Person column, right-click the same cell, and then click Delete Rows.
7. Repeat steps 1-6, but instead copy the sample data from the Meeting and
Venue columns of the Person invites Person to Meeting located at Venue
fact type to the new Meeting is located at Venue fact type.
8. In the examples data grid, delete all duplicate rows.
! Validate new fact types and constraints

2. On the drawing surface, select all of the predicate shapes. Verify that the
following text is displayed somewhere in the Verbalizer window:
Person invites Person to Meeting
at most one Person invites that Person to that
Meeting.
Meeting is located at Venue

Each Meeting is located at at most one Venue.
! Remove the old fact type from the drawing surface and the model
Remove the Person invites Person to Meeting located at Venue fact type
from the model.
Lesson Review
Objectives
Objectives
Describe
Describe fact
factarity
arity and
and how
how itit is
is used
used
Define
Definekey
key length
length check
check
Describe
Describehow
howto
to split
split fact
facttypes
types

1. What combination of criteria must be met to cause you to split a fact type?
Any one or more criteria that proves to be true is sufficient reason for
you to split a fact type.

Theme

Introduction In this lesson, you will apply CSDP step 4 to each of the themes that you are
already familiar with.
Lesson purpose The purpose of this lesson is to learn how to apply CSDP step 4.
Lesson objective After completing this lesson, you will be able to:
! Apply CSDP step 4 to an ORM model.
Describe how to add uniqueness constraints.
Describe how to split fact types.
Validate the ORM model.
CSDP step 4Add uniqueness constraints, and check the

arity of fact types
" Constrain population of fact types
" Redundancy is not allowed in a completed conceptual
model
" Re-express non-elementary facts

Introduction This lesson covers the use of Visio in the fourth step of the CSDP. It is
important that you follow the CSDP procedures to generate a well-designed
ORM model.
CSDP step 4 Add uniqueness constraints, and check the arity of fact types.
Enforce unique combinations of roles in predicates, and break apart fact types
that are not already broken down into elementary facts.
Constrain the population Static constraints apply to all possible populations of a fact type. This means
of fact types that static constraints apply to each state of the data in the database, taken one at
a time. You will use uniqueness constraints in this step of the CSDP to start to
restrict allowable instances of a fact type.
Redundancy is not When completed, you eliminate all redundancy in the ORM database model
allowed in a completed through the sequential application of the steps outlined in the CSDP. You will
conceptual model use uniqueness constraints to prevent redundant fact instances. It is imperative
that you apply each step in sequence to properly model the UoD.
Re-express non- Often you will introduce redundancy during the process of modeling external
elementary facts information. When properly modeled, a finished ORM model contains only
elementary facts, with an implied uniqueness constraint that spans all roles in
the fact type.
Implement
Implementuniqueness
constraints
Check
Checkfor
forsufficient
sufficientcause
causeto
to split
split fact
facttypes
types
IfIf indicated,
indicated,split
splitfact
fact types
types
Validate
Validate the
theORM
ORM model
modeland
and your
yourintent
intent

Introduction Use the following procedure to apply CSDP step 4 to an ORM model from the
Procedure Use the following high-level procedure to apply uniqueness constraints:
1. Implement uniqueness constraints.
Elementary facts are defined in terms of UCs and role functional
dependencies. Functional dependencies are also defined in terms of UCs.
UCs prevent redundant role instances and fact instances. You implement
UCs in the model to allow you to check the arity of fact types, and to know
when to split them.
2. Check for sufficient cause to split fact types.
After you implement uniqueness constraints, you split a fact type if any of
the relevant criteria is met. Continue testing and splitting fact types until all
are elementary.
3. If indicated, split fact types.
When splitting fact types, keep all uniqueness constraints intact as you
move roles into new fact types. If necessary, create nested object types to
preserve the relationships.
4. Validate the ORM model and your intent.
what you and the domain expert intended. After you have applied CSDP
step 4, all fact types should be elementary, with the appropriate uniqueness
constraints applied. If you have correctly applied CSDP steps 13, the
ORM model should be error-free at this stage in the process.
Important You should use Visio to conceptually validate the ORM model
after all remaining CSDP steps. During this process, Visio checks for illegal
constructs in ORM; it does not check whether you have captured business
requirements appropriately.
! Purpose
! Scenario
! Practice
London
UK11 (LHR)
US72
IT37
New York
Madrid Rome
(JFK)
ES2 (MAD) (FCO)
Atlanta 3 US62
VE56
(ATL)
Starting
VE59
US68 Dakar
VE56
(DKR)
Model Caracas
(CCS)

modeling scenario. You will split a fact type while preserving uniqueness
constraints and functional dependencies through the use of a nested object.
flights. For the purposes of this practice, the UoD is limited to the information
in this scenario.
You have met with the domain expert and are now attempting to prevent
redundant instances and ensure that all fact types are elementary. The domain
! Multiple airports may have the same terminal codes and gate numbers, but
each is a unique location.
! A flight may be at only one location, and each location may have a single
flight. A flight on the ground is functionally dependent on its location.
! Implement uniqueness constraints

1. Open and review the ApplyCSDP4_Airline.vsd ORM source model.
2. Create a uniqueness constraint over the Airport, Terminal, and Gate roles
of the Flight is grounded at Airport has Terminal has Gate fact type.
3. Create a uniqueness constraint over the Flight role of the Flight is
grounded at Airport has Terminal has Gate fact type.
! Check for sufficient cause to split fact types

1. On the drawing surface, right-click the predicate shape for the Flight is
grounded at Airport has Terminal has Gate fact type, and then click
Database Properties.
Categories list, click Constraints.
What information is displayed about the simple uniqueness constraint over
the Flight role?
*** Invalid uniqueness constraint or Fact Flight is grounded at
Airport has Terminal has Gate is not elementary!
____________________________________________________________
____________________________________________________________
What role or roles is the Flight role functionally dependent on?

The Flight role is functionally dependent on the unique combination of
the Airport, Terminal, and Gate roles.
____________________________________________________________
____________________________________________________________
! If indicated, split fact types

1. Create and draw a new fact type called Airport has Terminal has Gate,
and transfer the relevant sample data into it.
2. Objectify the Airport has Terminal has Gate fact type as a nested object
type called Location.
3. Create and draw a new fact type called Flight is grounded at Location, and
transfer the original Flight role sample data into it. Enter sequential
numbers from 1 to 9 as sample data in the Location role rows.
Note You should always use actual data values for sample data. In this
practice, the actual values should have been string concatenations of the
Location nested object types constituent role values; that is, Airport,
Terminal, Gate combinations.
4. Create a uniqueness constraint over the Flight role of the Flight is

grounded at Location fact type.
5. Create a uniqueness constraint over the Location role of the Flight is
grounded at Location fact type.
6. Remove the Flight is grounded at Airport has Terminal has Gate fact
type from the drawing surface and the model.
! Validate the ORM model and your intent

1. On the Database menu, click Model Error Check. In the Output window,
verify that there are no errors or warnings occur during conceptual
validation.
3. On the drawing surface, select all of the predicate shapes. Verify that the
following text is displayed somewhere in the Verbalizer window:
Airport has Terminal has Gate
It is possible that more than one Airport has more than
one Terminal has more than one Gate.
This fact is nested as 'Location'.
Flight is grounded at Location

Each Flight is grounded at at most one Location.
For each Location l, at most one Flight is grounded at
Location l.
! Implement uniqueness constraints

! Check for sufficient cause to split fact
types
! If indicated, split fact types
London
UK11 (LHR)
US72
IT37
New York
Madrid Rome
(JFK)
ES2 (MAD) (FCO)
Atlanta 3 US62
VE56
(ATL)
Solution
VE59
US68 Dakar
VE56
(DKR)
Model Caracas
(CCS)

modeling scenario. You split a fact type while preserving uniqueness
constraints and functional dependencies through the use of a nested object.
Implement uniqueness You create a uniqueness constraint over the Airport, Terminal, and Gate roles
constraints of the Flight is grounded at Airport has Terminal has Gate fact type, and
another over the Flight role.
You created uniqueness constraints to satisfy the requirements of the scenario,
even though they forced the fact type not to be elementary.
Check for sufficient Because the combination of the prescribed uniqueness constraints forced the
cause to split fact types fact type not to be elementary, the fact type had to be re-expressed.
The decision to split the fact type was indicated by the modeling tool, and
supported by the scenario specifications that a given Flight on the ground is
functionally dependent on its Location. The combination of the functional
dependency and the prescribed uniqueness constraints prevented the fact type
from being elementary.
If indicated, split fact To split the fact type, you created a replacement fact type called Airport has
types Terminal has Gate. To facilitate talking about the unique combination of
Airport, Terminal, and Gate roles, you then objectified the new fact type to as
the Location nested object type. You then created the Flight is grounded at
Location fact type to complete the reformulation of the original fact type.
You preserved uniqueness constraints while forming the Airport has Terminal
has Gate and the Flight is grounded at Location fact types and transferred the
original example data. The new fact types that you created all had valid key
lengths and did not have conflicting uniqueness constraints.
Validate your intent with You prevented redundant instances of the Airport has Terminal has Gate fact
the Verbalizer type by creating a uniqueness constraint across the Airport, Terminal, and
Gate roles to enforce the scenario requirement of:
! Multiple airports may have the same terminal codes and gate numbers, but
each is a unique location.
In addition to preserving the uniqueness constraints while splitting the fact type,
you also preserved the functional dependency through the use of a nested object
type in the Flight is grounded at Location fact type, as indicated by the
scenario requirement:
! A flight may be at only one location, and each location may have a single
flight. A flight on the ground is functionally dependent on its location.
Through a key-length check of the new fact types and proper modeling of
functional dependencies, you ensured that all fact types are elementary. You
then used the text output from the Verbalizer to validate that the model captured
your intent.
Lesson Review
Objectives
Objectives
Apply
Apply CSDP
CSDP step
step 44 to
to an
an ORM
ORM model
model
Describe
Describehow
howto
toadd
add uniqueness
constraints
Describe
Describehow
howto
to split
split fact
facttypes
types
Validate
Validatethe
theORM
ORMmodel
model

1. In CSDP step 4, what do you use to restrict allowable instances of a fact
types population?
You use uniqueness constraints in CSDP step 4 to restrict allowable
instances of a fact types population.
2. What is the significance of CSDP step 4 with respect to elementary facts?

You use uniqueness constraints to check and enforce the arity of fact
types in order to eliminate non-elementary facts.
Module Review
! Implementing Uniqueness Constraints

! Implementing Nested Object Types
! Checking Fact Arity

1. What type of uniqueness constraint would you use if all roles in the
proposed uniqueness constraint are in one predicate, and why?
Internal, because none of the roles spans more than one predicate.
2. Describe how nested object types are symbolized.

Nested object types are symbolized by a soft rectangle around the
predicate shape.
3. When should you use nested object types?

When you first think of a relationship and later want to talk about it.
4. When determining when to split fact types, which of the criterion is an

absolute reason for splitting?
Any one of the criterion that proves true is reason to split a fact type.
None has a higher value than any others.
Lab A: Adding Uniqueness Constraints and Checking

Arity of Fact Types
! Exercise 1: Implementing Uniqueness
Constraints
! Exercise 2: Checking the Arity of Fact
Types
! Exercise 3: Splitting Fact Types

Objectives This lab will reinforce your understanding of CSDP step 4 and the skills taught
in the module.

! Have completed CSDP steps 1 though 3.
! Be able to implement uniqueness constraints.
! Be able to objectify fact types as nested objects.
! Be able to split a fact type as needed.
You will use the files in the C:\MOC\2090\Labfiles\Lab05A folder to complete
this lab. Solution files for each exercise are in the Answer subdirectory of that
folder.
Estimated time to
complete this lab:
30 minutes
Exercise 0
Lab Setup
box.
5. Click OK.
Exercise 1
Implementing Uniqueness Constraints
Academic Theme.
Scenario For the purposes of this exercise, the UoD is limited to the information in this
scenario.
You are given the task of implementing uniqueness constraints in an ORM
source model. In this exercise, do not change any of the fact types beyond
adding uniqueness constraints.
! For each subject that an Academic teaches, the Academic gets at most one
rating. The rating is only given if he or she teaches a subject.
! Each academic has at most one rank code, and if he or she does have a rank
code, they have at most one access level code.
Tasks
! Identify fact types
1. Open and review the ApplyCSDP4_Academic.vsd ORM source model.
2. Review the example data contained in each of the fact types.
Which fact types and roles are related to the uniqueness constraints
prescribed in the scenario?
In the Academic teaches Subject gets Rating fact type, the combination
of Subject and Rating is unique.
In the Academic has Rank and has AccessLevel fact type, the Academic
role is unique, and the Rank role is unique.
____________________________________________________________
____________________________________________________________
! Create uniqueness constraints

1. Create appropriate uniqueness constraints in the Academic teaches Subject
gets Rating fact type.
2. Create appropriate uniqueness constraints in the Academic has Rank and
has AccessLevel fact type.
! Validate the uniqueness constraints

Select all of the predicate shapes on the drawing surface.
What is the text that the Verbalizer displays for the Academic teaches
Subject gets Rating fact type?
Academic teaches Subject gets Rating
Given any Academic and Subject
that Academic teaches that Subject gets at most one
Rating.
____________________________________________________________
____________________________________________________________
What is the text that the Verbalizer displays for the Academic has Rank
and has AccessLevel fact type?
Academic has Rank and has AccessLevel
*** Invalid uniqueness constraint or Fact is not
elementary!
*** Invalid uniqueness constraint or Fact is not
elementary!
____________________________________________________________
____________________________________________________________
C:\MOC\2090\Labfiles\Mod05A\Answer folder.
Exercise 2
Checking the Arity of Fact Types
In this exercise, you will check the arity of each fact type for sufficient cause in
an ORM model to split the fact type into new elementary fact types by using the
Academic Theme.
Scenario All applicable uniqueness constraints have been placed on fact types in an
ORM model.
You will use the model that you modified in the previous exercise to complete
this practice. Alternatively, use the ImplUnique_Academic_Answer.vsd ORM
source model in the C:\MOC\2090\Labfiles\Mod05A\Answer folder.
Tasks
! Perform key length check
1. Examine the Academic teaches Subject gets Rating fact type.
What is the minimum valid key length for the fact type?
It is 2, or the arity of the fact type minus 1.
____________________________________________________________
____________________________________________________________
Is there a uniqueness constraint on the fact type that spans the minimum
number of rows?
Yes, over the Academic and Subject roles.
____________________________________________________________
____________________________________________________________
2. Examine the Academic has Rank and has AccessLevel fact type.
What is the minimum valid key length for the fact type?
It is 2, or the arity of the fact type minus 1.
____________________________________________________________
____________________________________________________________
Is there a uniqueness constraint on the fact type that spans the minimum
number of rows?
No, the uniqueness constraints are each over a single role.
____________________________________________________________
____________________________________________________________
! Look for redundant instances

1. Examine the sample data for the Academic teaches Subject gets Rating
fact type.
Between any two or more columns, are there any redundant tuples?
No.
____________________________________________________________
____________________________________________________________
2. Examine the sample data for the Academic has Rank and has AccessLevel
fact type.
Between any two or more columns, are there any redundant tuples?
Yes, between the Rank and AccessLevel columns, the tuples (P, Full),
(SL, Local), and (L, Local) each have duplicate instances.
____________________________________________________________
____________________________________________________________
Exercise 3
Splitting Fact Types
In this exercise, you will reformulate a fact type that needs to be split in an
ORM model into new elementary fact types by using the Academic Theme.
Scenario You are tasked with implementing fact type splits that were indicated in the
previous exercise.
this practice. Alternatively, use the ImplUnique_Academic_Answer.vsd ORM
Tasks
! Reformulate new fact types
1. Create new fact types as indicated by the previous exercise, and transfer the
relevant sample data into each fact type.
2. Objectify any fact type as needed to preserve functional dependencies
across compound uniqueness constraints in new fact types.
Tip To validate example data when a nested object type does not have a
reference mode of its own, enter text that represents each objectified tuple
into the nested role of a new fact type.
3. Create uniqueness constraints on the new fact types that correspond to those
that exist on the old fact types.
4. Validate the new fact types by examining and analyzing their example data.
Verify that all fact types are elementary and that all new uniqueness
constraints are complete and valid.
5. Remove the old fact types from the model.
Module 6: Adding
Mandatory Role
Constraints and Checking
for Logical Derivations
Contents
CSDP Step 5
Module Overview 1
Lesson: Implementing Mandatory Role
Constraints 2
Lesson: Implementing a Primary
Reference Scheme 18
Lesson: Checking for Logically Derivable
Fact Types 31
Module Review 47
Lab A: Adding Mandatory Role Constraints
and Checking for Logical Derivations 48
other countries.
respective owners.
reserved.
Module 6: Adding Mandatory Role Constraints and Checking for Logical DerivationsCSDP Step 5 iii
Instructor Notes
(CSDP) step 5. This step covers mandatory constraints, primary reference
schemes, and checking for logically derived fact types.
45 minutes
Implement mandatory constraints.
Implement a primary reference scheme.
Avoid modeling logically derivable fact types.

Publishers.
iv Module 6: Adding Mandatory Role Constraints and Checking for Logical DerivationsCSDP Step 5

In this module, students will learn what a mandatory constraint is and how to
identify and apply it to a database model. Next, they will learn to identify a
primary reference scheme. Then they will learn to identify a logically derivable
fact type and discuss why they should avoid it. Lastly, students will apply all
these concepts to the database models with the themes that they are already
familiar with.
Lesson: Implementing Mandatory Role Constraints

lesson.
Populations of Roles This page serves as a review of role populations and object type populations.
and Object Types
Independent Object This page describes modeling object types and their roles, where there is a
Types special classification for object types whose instances can exist outside of any
fact types.
What Are Mandatory This page defines mandatory role constraints and lists the characteristics
Role Constraints? common to all mandatory role constraints in an Object Role Modeling (ORM)
model.
Guidelines for This page covers the guidelines used when implementing mandatory role
Implementing Mandatory constraints.
Role Constraints
How to Implement This page covers the sub-tasks for implementing mandatory role constraints.
Mandatory Role
Constraints
Mandatory Role procedure by using the Scheduling Theme.
Constraints
Scheduling Theme
What Are Disjunctive This page defines disjunctive mandatory role constraints and lists the
Mandatory Role characteristics common to all mandatory role constraints in an ORM model.
Constraints? Make sure that students understand the subtle differences between mandatory
and disjunctive mandatory constraints.
Guidelines for This page covers the guidelines used when implementing disjunctive mandatory
Implementing role constraints.
Disjunctive Mandatory
Role Constraints
How to Implement This page covers the sub-tasks for implementing disjunctive mandatory role
Disjunctive Mandatory constraints.
Role Constraints
Disjunctive Mandatory procedure by using the Scheduling Theme.
Role Constraints
Scheduling Theme
Module 6: Adding Mandatory Role Constraints and Checking for Logical DerivationsCSDP Step 5 v
Lesson Review
Lesson: Implementing a Primary Reference Scheme

lesson.
Identifying Entity Types This page covers the use of reference modes in entity types and how they relate
to modeling. Specifically, it covers how to use reference modes so that both the
modeler and the domain expert can recognize entity types.
What Is a Simple This page defines simple reference scheme and lists the characteristics common
Reference Scheme? to all simple reference schemes in an ORM model.
What Is a Compound This page defines compound reference scheme and lists the characteristics
Reference Scheme? common to all compound reference schemes in an ORM model. Note: that you
should restrict your discussion to reference schemes for an entity type. Do not
discuss reference schemes for predicates.
Guidelines for Selecting This page covers the guidelines used when selecting a primary reference
a Primary Reference scheme.
Scheme
How to Implement a This page covers the sub-tasks for implementing a primary reference scheme.
Primary Reference
Scheme
Practice: Implementing a This page reinforces the elements of the previous page through practice of the
Primary Reference procedure by using the Scheduling Theme. Make sure that you point out that in
SchemeScheduling the Formal Object Role Modeling Language (FORML) expression at the end of
Theme this page, an asterisk by the line indicates the primary reference scheme.
Lesson Review
vi Module 6: Adding Mandatory Role Constraints and Checking for Logical DerivationsCSDP Step 5
Lesson: Checking for Logically Derivable Fact Types

lesson.
What Are Transitively This page defines transitively implied relationships and lists the characteristics
Implied Relationships? common to all transitively implied relationships in an ORM model.
What Are Logically This page defines logically derivable fact types and lists the characteristics
Derivable Fact Types? common to all logically derivable fact types in an ORM model.
Guidelines for Logically This page covers the guidelines used when identifying logically derivable fact
Derivable Fact Types types. You must specifically state that these are not in students best interest to
use. If students find them in their models, then they must find other ways to
model the information in order to keep the model simple.
Lesson Review

lesson.
Focus of CSDP Step 5 This topic page covers the grand scheme of CSDP step 5. It is intended as a
will be covered in greater detail on future topic pages.
How to Apply CSDP This topic page is intended as a walkthrough of CSDP step 5. Guide students
Discussion: Applying This topic page is intended for you to discuss the steps just completed from the
CSDP Step 5Airline previous topic page. Explain why each task was completed in the manner done.
Flights Theme
Lesson Review
Module Review
topics covered.
Module 6: Adding Mandatory Role Constraints and Checking for Logical DerivationsCSDP Step 5 vii
Lab A: Adding Mandatory Role Constraints and Checking for

Logical Derivations
Lab Setup
Lab Results
or customization.
Module 6: Adding Mandatory Role Constraints and Checking for Logical DerivationsCSDP Step 5 1
Module Overview
! Implementing Mandatory Role Constraints

! Implementing a Primary Reference Scheme
! Checking for Logically Derivable Fact Types

to develop your skills by using the themes from the previous modules.
Implement mandatory role constraints.
Implement a primary reference scheme.
Avoid modeling logically derivable fact types.
2 Module 6: Adding Mandatory Role Constraints and Checking for Logical DerivationsCSDP Step 5
Lesson: Implementing Mandatory Role Constraints
! Populations of Roles and Object Types

! Independent Object Types
! What Are Mandatory Role Constraints?
! Guidelines for Implementing Mandatory Role Constraints
! How to Implement Mandatory Role Constraints
! Practice: Implementing Mandatory Role ConstraintsScheduling
Theme
! What Are Disjunctive Mandatory Role Constraints?
! Guidelines for Implementing Disjunctive Mandatory Role
Constraints
! How to Implement Disjunctive Mandatory Role Constraints
! Practice: Implementing Disjunctive Mandatory Role Constraints
Scheduling Theme

Introduction In a relationship, you may have to enforce the fact that every instance of an
object type has information recorded. You accomplish this by placing
constraints on the object types population.
Lesson purpose The purpose of this lesson is to understand mandatory role constraints so that
you can apply them to create a primary reference scheme and identify logically
derivable fact types in later lessons.
! Implement mandatory role constraints.
Identify populations of roles and object types.
Describe mandatory constraints and their uses.
Describe disjunctive mandatory constraints and their uses.
Populations of Roles and Object Types

Instances
Instances ofof
Person
Person Subset of
Subset
Role of
in
in Roles
Roles Role
A, B Person
Person
Population
Population
Population
Population
drives
A, B Subset
Subset of
of
Role
Role
A, C A, C Person
Person
Population
Population
Population
B, C Population
resides in
Person
Subset
Subset of
of
Role
Role
B, C Person
Person
Population
Union
Union of
ofRole
Role Population
Population
Figure 6.1 Population
Instances
Instances
works for
11 2 33

Introduction Remember that each role in a fact type is a placeholder for an object types
participation in the fact type. The role merely indicates that a relationship
exists. You cannot infer the number of instances by the roles existence.
Role population Each role represents the subset of an object types population that participates
in a given fact type.
Object type population You can think of the population of an object type in terms of the roles that it
participates in. Roles illustrate three important things about an object type:
! Union of role instances
The population of an object type is represented by the union of all instances
in all of the fact roles that an object type participates in. In this manner, the
sum of the parts makes up the whole.
For example, Table 1.5 in Module 1, Introduction to Modeling Business
Requirements, in Course 2090: Modeling Business Requirements to Create
a Database Using Microsoft Visual Studio .NET Enterprise Architect,
illustrated the concept of a union of sets. In the same manner, the union of
role populations is the same as the object type population.
Table 1.5
Set X Set Y Union of sets
{40, 50} {50, 60, 70} {40, 50, 60, 70}

{car, train, bus} {train, bus, airplane} {car, train, bus, airplane}
Independent Object Types
! A given instance is not required to participate in any roles

! An object types population is larger than all of its roles
populations, except for its reference mode
Object Type Population Role Population
A A
D D
B Instance
Instance Is
Is
B
E Not
Not In
In Roles
Roles
Population
Population
C C

Introduction When modeling object types and their roles, there is a special classification for
object types whose instances can exists outside of any fact types.
A given instance is not Remember than an instance of an object type is known by its reference mode. If
required to participate in nothing else is known about a given instance, that means that that particular
any roles instance does not have a role in any other relationships; or that an instance of
the object type can exist independently.
For example, if an Employee object type has a reference mode of
EmployeeNumber, and you know of an employees number but do not know
anything else about that employee, then the Employee object type is
independent.
An object types Remember that a roles population is always the same as or a subset of the
population is larger than object types population that it represents. If any role populations exist that are
all of its roles identical to its object types population, then the object type is not independent.
populations, except for
its reference mode For example, consider that the instances in Figure 6.2 represent the population
of an object type, and Figure 6.3 represents the population of the only role that
the object type plays, except for its reference mode. Notice that instance E
exists in the object type population but not in the role population. These
circumstances indicate that the object type is independent.
Tip While it is possible to do so, do not designate object types as independent

at this time. Wait until you have completed the model, and check for
independent object types when generating a relational logical model.
Microsoft Visio Enterprise Architect edition automates much of this check
for you.
What Are Mandatory Role Constraints?
! Definition
A mandatory role constraint forces all instances of an
object type to participate in a given role. Reference
roles are always mandatory
! Characteristics
" Global nature
" Implied with functional dependency
! FORML expression

Introduction Sometimes you want to force participation in a role by the entire object types
population. In this manner, you can guarantee that you know certain
information about an object type.
Definition A mandatory role constraint forces all instances of an object type to participate
in a given role. Reference roles are always mandatory.
Note Mandatory role constraints enforce the relational concept of preventing

null values.
Characteristics Mandatory role constraints have two important characteristics:

! Global nature
Mandatory role constraints are global in nature to the extent that they force
the enumeration of the entire population of an object type. This is important
in that it forces you to consider all instances for inclusion in all other roles
that the object type participates in.
For example, if you model a mandatory constraint on an employees name
and birth date, then you must know both items for all employees, or you
cannot store the employee record in the database.
! Implied with functional dependency
Remember that a role is functionally dependent on another if there is a
many-to-one or a one-to-one relationship between the roles, and if the first
role in that relationship always has a uniqueness constraint on it.
For example, if it is mandatory that each father has a child, and that children
are functionally dependent on their fathers, then it is mandatory that all of
the children have fathers.
Warning Do not explicitly annotate implied mandatory role constraints in

the model unless the domain expert explicitly requests you to do so.
FORML expression Mandatory role constraints are expressed in Formal Object Role Modeling
Language (FORML) notation by the inclusion of the word Each in front of an
object type. In the FORML expression,
Each Person has Name
The word Each indicates that the Person role in the fact type has a mandatory
role constraint on it, and that the name of each instance of the object type
Person is known.
How mandatory role A mandatory role constraint is symbolized by a solid round dot at the end of the
constraints are line that connects a role shape to an object type shape.
symbolized
In Figure 6.4, notice the solid round dot on the object type end of the role
connector for Person, indicating that the entire population of the Person object
type participates in the fact type.
Figure 6.4
Tip The majority of all fact types that you are likely to encounter while
modeling business requirements will have the same structure and constraints as
the fact type in Figure 6.4.
Guidelines for Implementing Mandatory Role Constraints
Rarely
Rarely apply
apply to
to nonfunctional
nonfunctional roles
roles
Make
Make aa role
role mandatory
mandatory ifif and
and only
only ifif needed
needed

Introduction Use the following guidelines when implementing a mandatory uniqueness
constraint.
Rarely apply to In practice, mandatory constraints on non-functional roles are rare.
nonfunctional roles Implementation of them in a relational database is somewhat complex and
involves performance overhead.
Make a role mandatory if Due to the implications of implied constraints and the possible impact on later
and only if needed CSDP steps, make a role mandatory only if it is absolutely indicated by the
domain expert.
How to Implement Mandatory Role Constraints
Identify
Identifythe
theroles
rolesto
to make
makemandatory
mandatory
Add
Add an
an internal
internalmandatory
mandatoryrole
roleconstraint
constraint
Validate
Validate the
theORM
ORM model
modeland
and your
yourintent
intent

Introduction Create mandatory role constraints to declare which roles must be played by the
population of an object type.
Procedure Use the following procedure to implement a mandatory role constraint:
1. Identify the roles to make mandatory.
Mandatory role constraints are created on roles within a fact type.
Remember that the mandatory constraint forces the entire object type's
population to participate in the fact type.
2. Add an internal mandatory role constraint.
Create a mandatory role constraint on the role whose population you want to
make mandatory. Remember that the internal version of a mandatory role
constraint forces the roles population to match the object types population.
3. Validate the Object Role Modeling (ORM) model and your intent.
what you and the domain expert intended. If you have correctly applied
CSDP steps 1-4, the ORM model should be error-free at this stage in the
process. Always use the Verbalizer to generate a FORML expression to
validate the new constraint. Every mandatory role expression should start
with the word Each.
Practice: Implementing Mandatory Role ConstraintsScheduling

Theme
! Purpose
! Scenario
! Practice
Mon Tue Wed Thu Fri
8 am
Out of Office:
9 00 Doctors Appt
Manager
1:1 All-han
10 00 Quaterl
Team
11 00 Traini
Brownbag Class
12 pm Lunch: ORM
2 00
Data
Modeling
Project
Data
Modeling
Project
Model Model 3 00
4 00
5 00

Introduction In this practice, you will implement mandatory role constraints by using the
Purpose The purpose of this practice is to illustrate how to force the entire population of
an object type to participate in a role in a fact type.
Scenario For the purposes of this practice, the Universe of Discourse (UoD) is limited to
the information in this scenario.
You have met with the domain expert and are now attempting to designate
certain roles as mandatory. The domain expert has provided you with the
following information:
! All persons must have a first name and a last name.
! At least one person is invited to every meeting.
! Identify the roles to make mandatory

Open and review the ImplMandatory_Scheduling.vsd ORM source model.
According to the scenario requirements, which object types will have a
mandatory role in a fact type?
Person, Meeting
____________________________________________________________
____________________________________________________________
! Add an internal mandatory role constraint

invites Person to Meeting fact type, and then click Add Constraints.
2. In the Add Constraint window, in the Constraint Type list, select
Mandatory.
3. In the pane entitled Select the role box of each role in the constraint, on the
[Person] invites [Person] to [Meeting] predicate shape, click the Meeting
role box, and then click OK.
4. Repeat steps 1-3, creating a mandatory role constraint on the Person roles
of the Person has FirstName fact type and the Person has LastName fact
type.
Tip You can quickly enter multiple constraints on a group of predicates by

selecting all of the relevant predicate shapes, before you right-click to add
the first constraint.

verify that there are no errors or warnings during conceptual validation.
2. Select all of the predicate shapes on the drawing surface.
Verbalizer window:
Person has FirstName
Each Person has some FirstName.
Each Person has at most one FirstName.
Person has LastName

Each Person has some LastName.
Each Person has at most one LastName.
Person invites Person to Meeting

For each Meeting m,
some Person invites some Person to Meeting m.
at most one Person invites that Person to that
Meeting.
What Are Disjunctive Mandatory Role Constraints?
! Definition
A disjunctive mandatory role constraint is an inclusive-or
constraint that applies to a set of two or more roles
! Characteristics
" Multi-role mandatory role constraint
" Connected to the same object type
" Instance must participate in at least one role
! FORML expression
! How Disjunctive Role Constraints Are Symbolized

Introduction Sometimes when you have two fact types, you need to model that an object
must participate in one or both facts. This represents a disjunction of sets.
Definition A disjunctive mandatory role constraint is an inclusive-or constraint that
applies to a set of two or more roles.
For example, you could constrain the population of an Employee entity type so
that that all employees work in an office, or have a mobile phone, or both.
Characteristics Disjunctive mandatory role constraints have three important characteristics:
! Multi-role mandatory role constraint
When modeling a disjunctive mandatory role constraint, you actually just
create a mandatory role constraint on two or more roles from the same
object type.
! Connected to the same object type
The fact types that contain the spanned roles must all include a common
role. That common role represents the object type population that is
constrained.
! Instance must participate in at least one role
Remember that an object type may play a role in more than one fact type. A
disjunctive mandatory role constraint forces any given instance to be in the
population of at least one of the roles spanned by the constraint.
FORML expression Disjunctive mandatory role constraints are expressed in FORML notation by
noting that each object type participates in one relationship or another.
Each Employee works in some Office or has some MobilePhone.
Note Although the FORML expression only connects the relationships with
the word =or, disjunctive mandatory roles actually mean either-or, or both.
How disjunctive role A disjunctive role constraint is symbolized by a small circle with a smaller solid
constraints are dot in it, and a dashed line connecting each of the roles spanned by the
symbolized constraint to the circle, as shown in Figure 6.5.
Figure 6.5
Guidelines for Implementing Disjunctive Mandatory Role

Constraints
Draw
Draw duplicate
duplicate fact
fact type
type shapes
shapes as
as needed
needed
Explicitly
Explicitly declare
declare ifif itit will
will still
still apply
apply ifif more
more roles
roles are
are added
added

Introduction Use the following guidelines when applying disjunctive mandatory role
constraints. Use disjunctive mandatory role constraints only when absolutely
necessary.
Draw duplicate fact type Remember that even though object types and fact types may be drawn multiple
shapes as needed times, all duplicate shapes actually represent a single object or fact type. It may
help to draw duplicate shapes to clarify symbolization.
Explicitly declare only if It may not be obvious that implied mandatory constraints apply to a fact type.
it will still apply if more Given the global nature of mandatory role constraints, the addition of a new
roles are added to the role may change the population under consideration.
object type
If a role is implied as mandatory, then it cannot participate in a disjunctive
mandatory constraint. For this reason, explicitly declare disjunctive mandatory
role constraints only if you are sure that they will still apply when the model is
completed.
How to Implement Disjunctive Mandatory Role Constraints
Determine
Determine the
the mandatory
mandatory role
roledisjunction
disjunction
Add
Add aa mandatory
mandatoryrole
role constraint
constraint across
acrosstwo
two or
ormore
more
roles
roles
Validate
Validate the
theORM
ORM model
modeland
and your
yourintent
intent

Introduction Create a disjunctive mandatory role constraint to model an inclusive or
requirement.
Procedure Use the following procedure to implement a disjunctive mandatory role
constraint:
1. Determine the mandatory role disjunction.
Select the roles played by the same object type but in different fact types.
Remember that you are indicating that the object type must at least have an
instance in one of the fact types.
2. Add a mandatory role constraint across two or more roles.
Recall that you create a disjunctive mandatory role constraint simply by
creating an external mandatory role constraint in the model. When Visio
refers to the constraint as mandatory, it really is disjunctive.
process. Use the FORML expression to validate the domain experts intent.
Be aware that disjunctive mandatory role constraints can sometimes be hard
to verbalize, especially if a relevant inverse predicate reading is absent.
Practice: Implementing Disjunctive Mandatory Role Constraints

Scheduling Theme
! Purpose
! Scenario
! Practice
Mon Tue Wed Thu Fri
8 am
Out of Office:
9 00 Doctors Appt
Manager
1:1 All-han
10 00 Quaterl
Team
11 00 Traini
Brownbag Class
12 pm Lunch: ORM
2 00
Data
Modeling
Project
Data
Modeling
Project
Model Model 3 00
4 00
5 00

Introduction In this practice, you will implement a disjunctive mandatory role constraint by
using the Scheduling Theme that you are already familiar with.
Purpose The purpose of this practice is to illustrate how to force the population of an
object type to participate in one role, another role, or both.
scenario.
certain roles as disjunctive mandatory. The domain expert has provided you
! Each meeting must be hosted somewhere.
! Meetings can be hosted at a physical location, online, or both.
! Determine the mandatory role disjunction

Open and review the ImplDisjunction_Scheduling.vsd ORM source model.
According to the scenario requirements, which fact types will have a role
with a disjunctive mandatory role constraint?
Meeting is hosted physically at Location.
Meeting is hosted electronically Online.
____________________________________________________________
____________________________________________________________
! Add a mandatory role constraint across two or more roles

1. On the drawing surface, click the predicate shape for the Meeting is hosted
electronically Online fact type, SHIFT+right-click the Meeting is hosted
physically at Location fact type, and then click Add Constraints.
2. In the Add Constraint window, in the Constraint Type list, select
Mandatory.
[Meeting] is hosted electronically [Online] predicate shape, click the
Meeting role box.
[Meeting] is hosted electronically at [Location] predicate shape, click the
Meeting role box, and then click OK.

2. On the drawing surface, select the external disjunctively disjunctive
mandatory role constraint shape that spans the Meeting roles in the Meeting
is hosted electronically Online and Meeting is hosted physically at
Location fact types.
3. Use the Verbalizer and verify that the following text is displayed
somewhere in the Verbalizer window:
Each Meeting is hosted electronically some Online or is
hosted physically at some Location.
Although it is not explicitly stated in the FORML expression, what is the

true meaning of this disjunctive mandatory role constraint?
Each Meeting is hosted electronically some Online and/or is
hosted physically at some Location.
____________________________________________________________
____________________________________________________________
Lesson Review
Objectives
Objectives
Implement
Implement mandatory
mandatory role
role constraints
constraints
Identify
Identifypopulations
populationsof
of roles
rolesand
and object
object types
types
Describe
Describemandatory
mandatoryconstraints
constraintsand
and their
theiruses
uses
Describe
Describedisjunctive
disjunctivemandatory
mandatoryconstraints
constraints
and
and their
theiruses
uses

1. Define a mandatory role constraint.
A mandatory role constraint forces all instances of an object type to
participate in a given role. Reference roles are always mandatory.
2. How is a mandatory role constraint symbolized?

A mandatory role constraint is symbolized by a solid round dot at the
end of the line that connects a role shape to an object type shape.
3. Define a disjunctive mandatory role constraint.

A disjunctive mandatory role constraint enforces an inclusive-or
relationship in the populations of the two or more roles spanned by the
constraint.
4. How is a disjunctive mandatory role constraint symbolized?

A disjunctive mandatory role constraint is symbolized by a small circle
with a smaller solid dot in it and a dashed line connecting each of the
roles spanned by the constraint to the circle.
Lesson: Implementing a Primary Reference Scheme
! Identifying Entity Types

! What Is a Simple Reference Scheme?
! What Is a Compound Reference Scheme?
! Guidelines for Selecting a Primary Reference Scheme
! How to Implement a Primary Reference Scheme
! Practice: Implementing a Primary Reference Scheme
Scheduling Theme

Introduction When modeling, you must be able to unambiguously identify members of an
entity types population.
Lesson purpose To facilitate communication with the domain expert and to validate instances of
data that the model represents, you must implement a primary reference scheme
for all entity types in the model.
! Implement a primary reference scheme.
Describe requirements for identification of entity types.
Describe simple reference schemes and their uses.
Describe compound reference schemes and their uses.
Identifying Entity Types
! Global means
! Candidate identifiers
! Primary reference scheme
Candidate
Candidate Candidate
Candidate Candidate
Candidate Candidate
Candidate
Identifier
Identifier Identifier
Identifier
Emp
Emp Employee
Employee Dept
Dept Location
Location Phone
Phone Tenured/
Tenured/
num
num name
name nontract-
nontract-
Blg
Blg Room
Room Ext
Ext Access
Access expiry
expiry
715
715 Adams A Computer
Computer Science
Science 69
69 301 2345
2345 LOC
LOC 01/31/95
01/31/95
720
720 Brown TT Biochemistry
Biochemistry 62
62 406 9642
9642 LOC
LOC 01/31/95
01/31/95
139
139 Cantor
Cantor G
G Mathematics
Mathematics 67
67 301 1221
1221 INT
INT Tenured
Tenured
430
430 Codd
Codd EF
EF Computer
Computer Science
Science 69
69 507 2911
2911 INT
INT Tenured
Tenured
Figure 6.6
1 22 3

Introduction You need a means of identifying object types in your model that both you and
the domain expert clearly understand.
Global means You should model all entity types so that you can readily identify any instance
of them, no matter where in the model they appear. This is useful to both you
and the domain expert.
Candidate identifiers You must be cognizant of identifiers that could be used to identify an entity.
There is often more than one value type that you can use to identify an entity.
For example, a student may be known by his or her matriculation number, full
name and birth date, or e-mail address.
Primary reference When there are multiple ways of identifying an object type, you must designate
scheme one of them as the primary identifier. Recall that reference mode is the
identification scheme that you select to identify an entity type in your model.
The reason that reference modes are useful is that they are global in nature.
What Is a Simple Reference Scheme?
! Definition
A simple reference scheme uses instances of a single
value type to identify an entity type
! Characteristics
" Implied binary fact type
" Mandatory role
" Simple uniqueness constraint
! FORML expression
! How symbolized P
Person
Person Name
(Name)
is identified by

Introduction Just as a rose by any other name is still a rose, in an ORM model, what you call
an object is irrelevant as long as you call it that same thing all of the time.
Definition A simple reference scheme uses instances of a single value type to identify an
entity type.
Characteristics Simple reference schemes display the following characteristics:
! Implied binary reference type
A binary reference type combining the entity type with a single value type is
used to map instances of the entity type to instances of the value type. The
single role representing the value type identifies the entity type.
! Mandatory role
All instances of the entity type must participate in the reference type. To
enforce this, the entity type role in the reference type is designated as
mandatory.
! Simple uniqueness constraint
To enforce a one-to-one mapping of the entity type population to an
identifying value type population, a unary uniqueness constraint is placed on
each role in the binary association.
FORML expression The syntactical expression of a simple reference scheme notes that every entity
instance is identified by one distinct value instance.
For example, the FORML expression for a Person entity type that has a simple
reference scheme that identifies instances by a persons name is:
Every Person is identified by one distinct Name.
How simple reference Simple reference schemes are visually indicated by an entity type reference
schemes are symbolized mode, or by a fact type that has uniqueness constraints that enforce a one-to-one
or more relationship combined with a mandatory role constraint. If the
reference mode is primary, then the letter P is superimposed over the
uniqueness constraint.
Figures 6.7 and 6.8 both graphically indicate the same simple primary reference
scheme.
Figure 6.7
A cleaner, more compact way of symbolizing a simple reference scheme is to

just designate Name as the reference mode for Person, as shown in Figure 6.8.
Figure 6.8
What Is a Compound Reference Scheme?
! Definition
A compound reference scheme uses the unique
population of a related group of roles to identify an
entity type
! Characteristics
" Tuple based
" Implied mandatory
" Uniqueness constraint spans identifying roles
! FORML expression

Introduction Another way of identifying entities is to use a unique combination of related
roles.
Definition A compound reference scheme uses the unique population of a related group of
roles to identify an entity type.
Characteristics Compound reference schemes display the following characteristics:
! Tuple-based
Multiple roles are associated with an entity type to form a tuple. The
population of the tuple uniquely identifies the entity type.
For example, the unique combination of first name, last name, birthday, and
place of birth may be used to uniquely identify a person.
! Implied mandatory
As with simple reference schemes, all instances of the entity type must
participate in the identifying fact type. To enforce this, the entity type role
that is identified in the fact type is designated as mandatory.
! Uniqueness constraint spans identifying roles
All roles used to identify the entity type are spanned by a uniqueness
constraint, to enforce that the population of the tuple maps one-to-one to
entity type population.
Note The domain expert may have indicated that a given combination of
roles was unique anyway. But the combination of roles needs to have the
preceding characteristics in order to use it for identification purposes.
FORML expression The syntax of a simple reference scheme notes that every entity instance is
identified by at most one distinct tuple instance.
For example, the FORML expression for a Person entity type that has a
compound reference scheme that identifies instances by the unique combination
of first name, last name, birthday, and birthplace is:
External FORML expression:
For each FirstName f, LastName l, Date d and PlaceOfBirth p
there is at most one Person that
has FirstName f and has LastName l and was born on Date d
and was born in PlaceOfBirth p.
Person is primarily identified by this unique combination.
Internal FORML expression:

*Given any FirstName, LastName, Date and PlaceOfBirth
at most one Person has that FirstName and that LastName and
was born that Date and was born in that PlaceOfBirth.
How compound The diagram in Figure 6.9 illustrates the use of an external uniqueness
reference schemes are constraint that is used as a compound primary reference scheme for identifying
symbolized an instance of Person. Notice that the letter U in the external uniqueness
constraint shape is replaced with the letter P to indicate that the uniqueness
constraint is the primary reference scheme.
Figure 6.9
Notice that it is possible to associate more than one instance of any of the other
object types with Person. This diagram allows multiple combinations of the
identifying roles to be captured, but only allows one unique combination of
those to exist.
The diagram in Figure 6.10 illustrates the use of an internal uniqueness

constraint that may be used as a compound primary reference scheme for
identifying an instance of Person.
Figure 6.10
Remember to designate a uniqueness constraint as the primary reference

scheme when you want to identify and discuss instances of an entity type by
using the roles spanned by the uniqueness constraint.
Warning While the diagram in Figure 6.10 is illustrative of a compound

primary reference scheme, the fact type portrayed is not elementary. You would
have split this fact type into four separate binary fact types during CSDP step 4.
This is due to the presence of conjunctions in the predicate reading and results
in the diagram in Figure 6.9.
Guidelines for Selecting a Primary Reference Scheme
Where
Where applicable,
applicable, use
use reference
reference mode
mode
Minimize
Minimize the
the number
number of
of roles
roles
Favor
Favor stable,
stable, rigid
rigid identifiers
identifiers
Be
Be wary
wary of
of information
information bearing
bearing identifiers
identifiers
Decompose
Decompose information
information bearing
bearing identifiers
identifiers
Normalize
Normalize units
units of
of measurement
measurement

Introduction Use the following guidelines to assist in selecting a primary reference scheme
for entity type objects in an ORM model.
Where applicable, use Avoid adding redundant clutter by creating new fact types just to identify an
reference mode entity type. Always use reference mode or pre-existing uniqueness constraints.
Caution Be careful not to contradict the domain expert while trying to

formulate a reference scheme.
Minimize the number of The larger the number of roles needed to identify an entity, the more doubtful it
roles is that they are all accurate or necessary.
Favor stable, rigid When implementing your database, you must have stable identifiers assigned to
identifiers all elements of the model. Select identifiers that are stable and are not subject to
significant change.
For example, a persons phone number is not a good choice for a primary
reference scheme, because the phone number may change from time to time.
Be wary of information Identifiers that convey meaning of what the data represents are usually not
bearing identifiers primitive object types. More often than not, this is a compound reference
scheme where the identifiers are stable.
For example, in a university, all mathematics courses are prefixed with the
letters MAT, and all courses in biology are prefixed with the letters BIO. The
significance of the letters is apparent to a student who is registering for classes.
Note During physical implementation, you may create a surrogate key to

simplify a primary reference scheme. At the conceptual level, it is not always
advantageous to use surrogate keys. Reconsider the use of surrogate keys later
when you are refining the model.
Decompose information Do not use concatenated information bearing identifiers in a single fact type.
bearing identifiers You may need to use the component parts separately in other fact types, or
query them separately.
For example, if a classrooms location is identified by the combination of
building number and room number, you should model these as two fact types,
and create an external uniqueness constraint between the two to use as a
primary reference scheme.
Normalize units of Use a common unit of measurement for like object types. Do not measure one
measurement object type in U.S. dollars and another in euros when they are both sums of
money. Use a derivation rule to normalize the numbers.
How to Implement a Primary Reference Scheme
Determine
Determinecandidate
candidateidentifiers
identifiers
Implement
Implementaa uniqueness
constraint or
orentity
entitytype
type
reference
reference mode
mode
Designate
Designatethe
the UC
UCas
as the
theprimary
primaryreference
referencescheme
scheme
Validate
Validate the
theORM
ORM model
modeland
and your
yourintent
intent

Introduction Create a primary reference scheme to serve as the standard identifier of an
entity type.
Procedure Use the following procedure to implement a primary reference scheme:
1. Determine candidate identifiers.
Remember that you can model more than one identifier for a given object
type. Use the guidelines from the previous topic page to select the most
appropriate.
2. Implement a uniqueness constraint or entity type reference mode.
If you select a binary relationship to act as the primary reference scheme,
then implement it as the entity types reference mode. Otherwise, create or
select an appropriate uniqueness constraint.
3. Designate the uniqueness constraint as the primary reference scheme.
Marking a uniqueness constraint as the primary reference scheme will
impact how the logical and physical models are generated.
Tip This step is unnecessary unless there is an alternative reference

scheme. If there is only one candidate reference scheme, Visio will choose it
as the primary reference scheme automatically during generation of the
relational logical model.

process. Use the Verbalizer to generate a FORML expression for the
identification of the object type. The expression should use the phrase is
known by with respect to the object type.
Practice: Implementing a Primary Reference SchemeScheduling

Theme
! Purpose
! Scenario
! Practice
Mon Tue Wed Thu Fri
8 am
Out of Office:
9 00 Doctors Appt
Manager
1:1 All-han
10 00 Quaterl
Team
11 00 Traini
Brownbag Class
12 pm Lunch: ORM
2 00
Data
Modeling
Project
Data
Modeling
Project
Model Model 3 00
4 00
5 00

Introduction In this practice, you will implement a primary reference scheme by using the
Purpose The purpose of this practice is to illustrate how to designate an external
uniqueness constraint as the primary reference scheme of an object type.
scenario.
You have met with the domain expert and are now attempting to implement a
primary reference scheme for the Location object type. The domain expert has
provided you with the following information:
! The unique combination of a room in a building identifies a location.
! The same room number could exist in different buildings.
! Determine candidate identifiers

Open and review the ImplReference_Scheduling.vsd ORM source model.
Based on the scenario requirements, which role or roles can be used to
identify a given Location?
The combination of the Room roles in the Location has RoomNumber
fact type, and the Location is in Building fact type.
____________________________________________________________
____________________________________________________________
! Implement a uniqueness constraint or entity type reference mode

Create an external uniqueness constraint over the RoomNumber role of the
Location has RoomNumber fact type and the Building role of the
Location is in Building fact type.
! Designate the uniqueness constraint as the primary reference scheme

1. On the drawing surface, right-click the predicate shape for the external
uniqueness constraint between the Location has RoomNumber and
Location is in Building fact types, and then click Database Properties.
2. In the Database Properties window, select Represents the primary
identification scheme.
3. In the Database Properties window, ensure that the Mapping option list
value is set to Primary Key.

2. On the drawing surface, select the predicate shape for the external
uniqueness constraint between the Location has RoomNumber and
Location is in Building fact types.
Verbalizer window:
For each Building b and RoomNumber r
there is at most one Location that
is in Building b and has RoomNumber r.
Location is primarily identified by this unique
combination.
Lesson Review
Objectives
Objectives
Implement
Implement aa primary
primary reference
reference scheme
scheme
Describe
Describerequirements
requirementsfor
foridentification
identification of
of
entity
entity types
types
Describe
Describesimple
simplereference
reference schemes
schemesand
and their
their
uses
uses
Describe
Describecompound
compound reference
referenceschemes
schemesand
and
their
theiruses
uses

1. Define simple reference schemes.
Simple reference schemes use instances of a single value type to identify
an entity type.
2. What is the simplest way of designating a reference scheme?

Designate a reference mode for the object type.
3. Define compound reference schemes.

A compound reference scheme uses the unique population of a related
tuple to identify an entity type.
Lesson: Checking for Logically Derivable Fact Types
! What Are Transitively Implied Relationships?

! What Are Logically Derivable Fact Types?
! Guidelines for Logically Derivable Fact Types

Introduction Modeling logically derivable fact types is a poor practice. Use other techniques
to model the same information and relationships.
Lesson purpose The purpose of this lesson is to help you avoid complicating your model by
introducing the unneeded complexity of logically derivable fact types.
! Avoid modeling logically derivable fact types.
Describe transitively implied relationships.
Describe logically derivable fact types.
What Are Transitively Implied Relationships?
! Definition
Object types exhibit a transitive
implied relationship when an
unbroken chain of comparable
relationships is formed
spanning a series of object
types
! Characteristics
" Use in logic and mathematics
" Conducts characteristics
! Examples
" If X =Y and Y = Z, then X = Z
" If X > Y and Y > Z, then X > Z
" If X is like Y and Y is like Z,
then X is like Z
1 22 3 Figure 6.11

Introduction You can think of transitively implied relationships as a chain in which each link
is related to every other link in the same manner. Link A is like link B, and link
B is like link C, and so on. Each link also translates its strength to every other
link in order to form the chain.
Definition Object types exhibit a transitively implied relationship when an unbroken chain
of comparable relationships is formed spanning a series of object types.
This allows for the creation of a mathematically equivalent relationship
between the first and last object types in the chain. Transitive relationships are
commonly expressed as if-then statements, such as:
If X = Y and Y = Z, then X = Z
Notice that you can rely on X equating to Z because of the relationship of X to
Y, and likewise, of Y to Z.
Characteristics Transitive relationships are important in ORM. They display two important
characteristics:
! Use in logic and mathematics
Transitive relationships are commonly used to build mathematical proofs
and to test hypothesis. In logic, transitive relationships reduce complex
relationships into simpler ones.
! Conducts characteristics
A transitive relationship is usually presented as a conditional statement that
is successively tested in a chain of elements. In an ORM model, object types
in a transitive chain share the characteristics that cause the conditional state
to be evaluated the same for each link in the chain.
Important Transitive relationships are the basis for nearly all implied
constraints in an ORM model. It is critical that you have a thorough
understanding of them.
Examples Each of the following examples illustrates a transitive relationship.

! Example 1:
If a student is in a class, and the class is taught by a professor, then the
student is taught by the professor.
(If X = Y, and Y = Z, then X = Z)
! Example 2:
If Manuels salary is greater than Moes, and Moes salary is greater than
Jacks, then Manuels salary is greater than Jacks.
(If X > Y, and Y > Z, then X > Z)
! Example 3:
If driving a car is like driving a van and driving a van is like driving a
truck, then driving a car is like driving a truck.
(If X is like Y, and Y is like Z, then X is like Z)

What Are Logically Derivable Fact Types?
! Definition
The information in a logically derivable fact type is inferred from other
fact types. Logically derivable fact types are typically based upon
related but separate elementary fact types
! Characteristics
" Usually contain hidden information
" Not normally shown on diagram
" All explicit constraints are normally derivable
" Relationships that are transitively implied from other relationships

Introduction Just as you strive to convert all object types into primitive entity types, you
must also re-express all fact types that are not at their lowest common
denominators.
Definition The information in a logically derivable fact type is inferred from other fact
types. Logically derivable fact types are typically based on related but separate
elementary fact types.
When properly modeled, they are similar to arithmetically derived fact types,
except that they express their derivation rule in terms of conceptual joins, not
numbers.
For example, if you know that a city is in a state, and a state is in a country,
then the country that a city is in is logically derivable from the relationships
with the state.
Characteristics Logically derived fact types display the following characteristics:
! Usually contain hidden information
If a logically derived fact type exists, it is based on other fact types. If they
exist in your model, then it is probable that you have not yet modeled all of
the constituent information. However, you may have already modeled that
information in other fact types but under a different context.
Caution Be careful not to confuse logically derivable fact types with fact
types that are not using primitive entity types. You should have dealt with
primitive entity types in CSDP step 3. The act of breaking object types up
into primitive entity types frequently breaks up logically derived fact types,
as well.
! Not normally shown on diagram

Recall the discussion about derived information versus derived and stored
information. It is not necessary to model logically derivable fact types if you
can gain the same information from other fact types.
! All explicit constraints are normally derivable
If the fact type is logically derivable, then all explicit constraints on it are
normally derivable as well. Remember this as you try to determine the
underlying fact types, because you need also to re-express the constraints.
! Relationships that are transitively implied from other relationships
Remember that object types that are functionally dependent on one another
exhibit characteristics of a transitively implied relationship. Constraints
represent the characteristics that are implied through the chain of different
fact types to other populations.
Note This is the main reason that you can logically derive some fact types.
How logically derivable Aside from the derivation notation, there is no special symbology for logically
fact types are derived fact types. They may appear on the drawing surface just as any other
symbolized fact type, or not at all. Logically derivable fact types are correctly symbolized
when all of their constituent fact types and constraints are themselves
symbolized.
Example Figure 6.12 illustrates a logically derivable fact type. Notice that there is a
circular chain of fact types, creating more than one path to retrieve data.
Figure 6.12
This information would be better modeled by removing the City is in Country

fact type, because it is redundant and is logically derivable through City and
Countrys relationships with State.
Important When properly modeled, you should have a single join path by
which it is possible to retrieve data on a given role.
Guidelines for Logically Derivable Fact Types
Look
Look for
for other
other relationships
relationships of
of interest
interest between
between fact
fact types
types
Look
Look for
for derivable
derivable constraints
constraints
Look
Look for
for circular
circular relationship
relationship chains
chains

Introduction If you can produce the same results in two different paths, then you should
choose to model only one of the two. Use the following guidelines to assist in
identifying logically derived fact types.
Look for other Often, a single bit of external information, as communicated by the domain
relationships of interest expert, may generate multiple facts. Each of those facts may by themselves
between fact types have meaning to the domain expert. Sometimes, interesting observations are
drawn after modeling seemingly unrelated facts.
These observations either represent logically derivable fact types, or they
represent a lower level of granularity from which other fact types are derived.
The subjective observation of other relationships of interest between fact types
frequently leads to the discovery of logically derivable fact types.
Look for derivable If a constraint can be derived (either implied or through a transitive chain of
constraints functional dependencies), then it is a sign that the fact type may be derivable, as
well.
Look for circular Anytime you have a circular set of relationships between fact types, it is a sign
relationship chains that you may be dealing with a logically derivable fact type in that relationship
chain. Use the previous guidelines to help you identify the fact type that you
need to re-express.
Lesson Review
Objectives
Objectives
Avoid
Avoid modeling
modelinglogically
logically derivable
derivable fact
fact types
types
Describe
Describetransitively
transitively implied
implied relationships
relationships
Describe
Describelogically
logicallyderivable
derivable fact
facttypes
types

1. Define transitively implied relationships.
A transitively implied relationship is an unbroken chain of relationships
that share common object types.
2. What are the primary characteristics of logically derived fact types?

They may share multiple join paths, they usually contain hidden
information, they are not normally shown on a diagram, explicit
constraints on them are derivable, and they exhibit characteristics of
transitively imply relationships.
3. Define logically derived fact types.

A logically derivable fact type is a fact type that is inferred from other
fact types. Logically derivable fact types are typically based on related
but separate elementary fact types.

Theme

Introduction In this lesson, you will apply CSDP step 5 to a modeling scenario in order to
assess your understanding of the previous three lessons.
Lesson purpose The purpose of this lesson is to synthesize and apply skills and knowledge
relating to mandatory role constraints, primary reference schemes, and logically
derivable fact types in order to implement CSDP step 5.
! Apply CSDP step 5 to a modeling scenario.
Describe the focus of CSDP step 5.
CSDP step 5: Add mandatory role constraints and check

logical derivations
" Nullability
" Cardinality
" Role functional dependency

Introduction You use the concepts of mandatory role constraints and uniqueness to create
reference schemes and recognize logically derivable fact types. It is important
that you address these issues before proceeding onward with the CSDP.
CSDP step 5 Add mandatory role constraints, and check for logical derivations.
Nullability In an ORM model, all relationships are elementary, so their populations cannot
include null values. In a relational logical model, null values are introduced
through the outer join of two intersecting sets. Mandatory role constraints force
the relational intersection to behave like an inner join, thereby eliminating
NULLs.
In practice, relational models generated from a properly constructed ORM
model are fully normalized. This means, among other things, that nullability is
eliminated from the model.
Cardinality Mandatory role constraints combine with the uniqueness constraints that were
added to the model in CSDP step 5 to enforce the relational concept of
cardinality in the model.
Role functional Mandatory role constraints and uniqueness constraints also combine with
dependency functional dependencies among roles to form elementary facts. The transitive
nature of this combination of characteristics leads to implied constraints and
logically derivable fact types. CSDP step 5 helps to guarantee that all functional
dependencies and elementary facts are properly modeled.
Implement
Implementmandatory
mandatoryrole
roleconstraints
constraints
Implement
Implementprimary
primaryreference
referenceschemes
schemes
Check
Checkfor
forlogically
logically derivable
derivablefact
fact types
types
Validate
Validate the
theORM
ORM model
modeland
and your
yourintent
intent

Introduction Use the following procedure to apply CSDP step 5 to an ORM model from the
Procedure To apply CSDP step 5:
1. Implement mandatory role constraints.
Designate that the entire population of a role or group of roles must
participate in a fact type by implementing a mandatory role constraint. You
can do this for business reasons, or as the first step in creating a reference
scheme.
2. Implement primary reference schemes.
Remember that the roles or tuples for candidate reference schemes must be
mandatory and unique. The creation of mandatory role and uniqueness
constraints will aid in identifying logically derivable fact types.
3. Check for logically derivable fact types.
Logically derivable fact types complicate the model. Ask yourself or the
domain expert if you can derive a fact type from others before adding it to
the model. Try to re-express any fact types that you discover that are
logically derivable.
process. Validate your intent by using the Verbalizer. The application of
explicit mandatory role and uniqueness constraints often transitively implies
constraints on other fact types. Take extra care to validate that the model
still reflects your intent by using the Verbalizer.
! Purpose
! Scenario
! Practice
London
UK11
(LHR)
US72
IT37
New York
Madrid Rome
(JFK)
ES2 (MAD) (FCO
Atlanta 3 US62 )
VE56
(ATL)
Starting US6
8
VE59
VE56
Dakar
(DKR)
Model Caracas
(CCS)

modeling scenario. You will create mandatory role constraints and implement a
primary reference scheme for an entity type.
scenario.
mandatory roles and a primary reference scheme for the Airport object type.
The domain expert has provided you with the following information:
! Each city is in some country and has one or more airports.
! For each airport, you know the city that it is in, the name of the airport, or
both.
! All airports have a unique three letter code.
! When the information is available, you can refer to an airport by the
combination of the city it is in and its name.
! Implement mandatory role constraints

2. Create a mandatory role constraint on the City role of the City has Airport
fact type.
3. Create a mandatory role constraint on the City role of the City is in
Country fact type.
4. Create a disjunctive mandatory role constraint that spans the Airport roles
of the City has Airport and Airport has AirportName fact types.
! Implement primary reference schemes

Designate the reference mode for the Airport entity type to be Code.
Why is the external uniqueness constraint that spans the City has Airport
and Airport has AirportName fact types not a suitable candidate
identifier?
The Airport roles in those fact types are not both mandatory, which is a
requirement for a reference scheme.
____________________________________________________________
____________________________________________________________
! Check for logically derivable fact types

1. Examine the relationships between the Airport, City, and Country object
types.
Which of the guidelines for implementing logically derivable fact types
indicates that the Country has Airport fact type is logically derivable?
Country can be transitively implied through the overlap of the Country
is in City fact type, and the City has Airport fact type.
____________________________________________________________
____________________________________________________________
2. Remove the Country has Airport fact type from the drawing surface and
the model.

2. Select the Airport object types, the City is in Country and City has
Airport predicate shapes and the disjunctive mandatory role constraint
shape on the drawing surface.
Verbalizer window:
Airport(Code) is an entity object type.
Every Airport is identified by one distinct Code.
City has Airport

Each City has some Airport.
City is in Country
Each City is in some Country.
For each Airport a,

some City has Airport a or
Airport a has some AirportName.
Discussion: Applying CSDP Step 5 Airline Flights Theme
! Implement mandatory role constraints

! Implement primary reference schemes
! Check for logically derivable fact types
London
UK11
(LHR)
US72
IT37
New York
Madrid Rome
(JFK)
ES2 (MAD) (FCO
Atlanta 3 US62 )
VE56
(ATL)
Solution US6
8
VE59
VE56
Dakar
(DKR)
Model Caracas
(CCS)

modeling scenario. You created mandatory role constraints and implemented a
primary reference scheme for an entity type.
Implement mandatory You created mandatory role constraints on the City role of the City has
role constraints Airport and City is in Country fact types. You also created a disjunctive
mandatory role constraint across the Airport roles of the City has Airport and
Airport has AirportName fact types.
These constraints force every instance of the City object type to participate in
both fact types. The combination of the mandatory role constraint and the
simple uniqueness constraint over the City role in both fact types forces the
Airport role and the Country role to be functionally dependent on the City
object type. The disjunction between the Airport roles forces you to record
either the city the airport is located it, its name, or both.
Implement primary You designated a reference mode of Code for the Airport entity type. The
reference schemes simple uniqueness constraint over the AirportName role of the Airport has
AirportName fact type as the primary reference scheme for the Airport object
type.
The compound internal uniqueness constraints over the roles in the Airport has
AirportName fact type create a many-to-many mapping between the
populations of the Airport and AirportName object types, so that it cannot be
used as a reference scheme. There could also be more than one airport in a
given city, so that the simple uniqueness constraint over the Airport role of the
City has Airport fact type is not a candidate identifier.
Check for logically Because it was logically derivable through other fact types, you removed the
derivable fact types Country has Airport fact type. The reason that the fact type was logically
derivable was that its information was available through transitively implied
relationships with other fact types. Also, Airport is directly functionally
dependent on City, but it was not directly functionally dependent on Country.
The presence of multiple join paths from the Airport object type to the
Country object type was an indication to examine the involved fact types for
possible logically derivable fact types.
Validate the ORM model The need for the mandatory role constraints were indicated by the scenario
and your intent requirement:
! Each city is in some country and has one or more airports.
The disjunctive mandatory role constraint was indicated by the scenario

requirement:
! For each airport, you know the city that it is in, the name of the airport, or
both.
The use of a reference mode on the Airport entity type as its primary reference
scheme was justified by the requirements:
! All airports have a unique three letter code.
! When the information is available, you can refer to an airport by the
combination of the city it is in and its name.
requirements of the scenario were met. You should also re-evaluate any
example data that you entered or possibly deleted while applying CSDP step 5.
Lesson Review
Objectives
Objectives
Apply
Apply CSDP
CSDP step
step 55
Implement
Implementmandatory
mandatory role
roleconstraints
constraints
Implement
Implementprimary
primaryreference
referenceschemes
schemes
Check
Check for
forlogically
logicallyderivable
derivablefact
fact types
types
Validate
Validateyour
yourintent
intent with
withthe
theVerbalizer
Verbalizer

1. What three aspects of data manipulation are addressed by CSDP step5?
Nullability, cardinality, and role functional dependency.
2. What part of a population participates in a reference role?

The entire population of an object type participates in a reference role.
Module Review
! Implementing Mandatory Role Constraints

! Implementing a Primary Reference Scheme
! Checking for Logically Derivable Fact Types

1. What is the population of an object type equivalent to?
The union of all instances in all of the fact roles that an object type
participates in.
2. What percentage of a roles population participates in a reference role?

The entire population of an object type participates in a reference role.
3. How do you model a disjunctive mandatory role constraint?

When modeling a disjunctive mandatory role constraint, you actually
just create a mandatory role constraint that involves two or more roles
from the same object type.
4. How do you identify an entity type?

By designating a reference mode, or designating an appropriate
uniqueness constraint as the primary reference scheme.
Lab A: Adding Mandatory Role Constraints and Checking

for Logical Derivations
! Exercise 1: Implementing Mandatory Role
Constraints
! Exercise 2: Implementing Primary
Reference Schemes
! Exercise 3: Checking for Logically
Derivable Fact Types

Introduction This lab will reinforce your understanding of CSDP step 5, as well as the skills

! Be able to implement mandatory constraints.
! Be able to implement a primary reference scheme.
! Be able to avoid modeling logically derivable fact types.
faculty of a college and departmental budget information.
folder.
Estimated time to
complete this lab:
45 minutes
Exercise 0
Lab Setup
box.
5. Click OK.
Exercise 1
Implementing Mandatory Role Constraints
In this exercise, you will implement mandatory role constraints by using the
Academic Theme.
scenario.
You are tasked with implementing uniqueness constraints in an ORM source
model. In this exercise, do not change any of the fact types other than adding
mandatory or disjunctive mandatory role constraints.
! You must record a phone number, the first name, the last name, and the
department that every academic works for.
! Every department knows who works for it and who heads the department.
! Every department heads phone number is known.
Tasks
! Identify the roles to make mandatory
Open and review the ApplyCSDP5_Academic.vsd ORM source model.
According to the scenario requirements, which object types will have a
mandatory role in a fact type?
Academic and Department.
____________________________________________________________
____________________________________________________________
Which roles of which fact types should have mandatory role constraints?
The Academic role of the Academic has PhoneNumber, Academic has
FirstName, Academic has LastName, and the Academic works for
Department fact types.
The Department role for the Academic works for Department,
Academic heads Department, and the Department has head with home
PhoneNumber fact types.
____________________________________________________________
____________________________________________________________
! Add internal mandatory role constraints

Create internal mandatory role constraints in the appropriate fact types.
! Validate the mandatory role constraints

2. Select all of the predicate shapes on the drawing surface that now have
internal mandatory role constraints on them.
What is the text that the Verbalizer displays for these fact types that is
related to the new mandatory role constraints?
Academic has PhoneNumber
Each Academic has some PhoneNumber.
Academic has FirstName

Each Academic has some FirstName.
Academic has LastName

Each Academic has some LastName.

Each Academic works for some Department.

For each Department d, some Academic heads Department d.
Department has head with home PhoneNumber

Each Department has head with home some PhoneNumber.
____________________________________________________________
____________________________________________________________
Exercise 2
Implementing Primary Reference Schemes
In this exercise, you will consider primary reference scheme candidates and
implement one for an object type in an ORM model by using the Academic
Theme.
Scenario All applicable uniqueness constraints have been placed on fact types in an
ORM model. Designate the proper uniqueness constraint or constraints as a
primary reference scheme.
this practice. Alternatively, use the ImplMandatory_Academic_Answer.vsd
ORM source model in the C:\MOC\2090\Labfiles\Mod06A\Answer folder.
! The unique combination of an academics first name, last name, and the
department that he or she works for could identify the academic. Academics
typically do not change departments frequently.
! Every academic has a phone number that is not shared with anyone else.
Phone numbers are reused when an academic no longer works for the
university, or when the person changes departments.
Tasks
! Determine candidate identifiers
Examine all 1:1 uniqueness constraints in which the Academic object type
plays a role.
According to the scenario requirements, which object types can you use to
identify an academic?
The combination of FirstName, LastName, and Department.
PhoneNumber.
____________________________________________________________
____________________________________________________________
! Implement uniqueness constraints over candidate roles

Create appropriate uniqueness constraints over the roles in the fact types
that are indicated by the scenario requirements if they do not exist already.
What uniqueness constraints should you have created?
An external uniqueness constraint spanning the FirstName, LastName,
and Department roles of the fact types that involved the Academic
object type.
A simple internal uniqueness constraint already exists on the
PhoneNumber role of the Academic has PhoneNumber fact type.
____________________________________________________________
____________________________________________________________
! Designate the primary reference scheme

1. Evaluate the candidate identifying uniqueness constraints.
Which candidate uniqueness constraint has a shorter key length?
The internal uniqueness constraint over the PhoneNumber role of the
Academic has PhoneNumber fact type is the shortest, with a key length
of one.
____________________________________________________________
____________________________________________________________
Which uniqueness constraint would contain the most stable values?

The external uniqueness constraint that spans the FirstName,
LastName, and Department object types.
____________________________________________________________
____________________________________________________________
2. Designate the best candidate uniqueness constraint as the primary reference

scheme for the Academic object type.
! Validate the primary reference schemes

2. Select all of the uniqueness constraints that you designated as the primary
reference scheme.
What is the text that the Verbalizer displays for this uniqueness constraint?
For each FirstName f, LastName l and Department d
there is at most one Academic that
has FirstName f and has LastName l and works for
Department d.
Academic is primarily identified by this unique
combination.
____________________________________________________________
____________________________________________________________
Exercise 3
Checking for Logically Derivable Fact Types
In this exercise, you will identify and remove a logically derivable fact type
from an ORM model by using the Academic Theme.
Scenario You are tasked with avoiding the use of logically derivable fact types in an
ORM model.
this practice. Alternatively, use the ImplReference_Academic_Answer.vsd
ORM source model in the C:\MOC\2090\Labfiles\Mod06A\Answer folder.
Tasks
! Identify and remove logically derivable fact types
1. Examine the relationships between the object types in the model.
Which object types are involved in a circular relationship?
Academic, PhoneNumber, and Department.
____________________________________________________________
____________________________________________________________
Of those object types, what functional dependencies exist between them?

In the Academic has PhoneNumber fact type, both roles are
functionally dependent upon each other.
In the Academic heads Department fact type, both roles are
functionally dependent upon each other.
In the Academic works for Department fact type, the Department role
is functionally dependent upon the Academic role.
In the Department has head with home PhoneNumber fact type, the
PhoneNumber role is functionally dependent upon the Department role.
____________________________________________________________
____________________________________________________________
2. Remove the fact type from the model that is logically derivable from other
fact types.
Which fact type was removed?
Department has head with home PhoneNumber.
____________________________________________________________
____________________________________________________________
Module 7: Adding Value
and Set Constraints,
and Creating Entity
SubtypesCSDP
Contents
Step 6
Module Overview 1
Lesson: Implementing Value Constraints 2
Lesson: Implementing Set Constraints 11
Lesson: Implementing Entity Subtypes 21
Module Review 46
Lab A: Adding Value Constraints, Set
Constraints, and Entity Subtypes 47
other countries.
respective owners.
reserved.
Module 7: Adding Value and Set Constraints, and Creating Entity SubtypesCSDP Step 6 iii
Instructor Notes
(CSDP) step 6. This step covers adding three types of constraints: value
constraints, set constraints, and subtype constraints.
30 minutes
Implement value constraints.
Implement set constraints.
Implement entity subtypes.

Publishers.
iv Module 7: Adding Value and Set Constraints, and Creating Entity SubtypesCSDP Step 6

In this module, students will learn what value constraints are and how to
identify and apply them to a database model. Next, they will learn what set
constraints are and how to identify and apply them. Then they will learn to
identify and apply subtype constraints. Finally, students will apply each of these
constraints to database models with the themes that they are already familiar
with.
Lesson: Implementing Value Constraints

lesson.
Domain of a Population This page covers the domain of populations. Make sure that students understand
the theory behind this topicthat a domain of a population is a limiting factor
to a population.
What Are Value This page defines and describes what value constraints are. It then covers how
Constraints? they are used by providing several examples.
How Value Constraints This page covers how value constraints are visually indicated on an Object Role
Are Represented Modeling (ORM) diagram. Point out that there is no shape for value constraints,
but rather a textual annotation enclosed in braces that appears next to the object
type shape.
After teaching the content in this topic, point out to students that the equality
constraint connected to the role in Employee is paid Salary extends the
impact of the exclusion constraint connected to the same role, so that no sales
manager is paid an hourly wage.
How to Implement Value This page instructs students on the high-level steps of how to implement value
Constraints constraints.
Value Constraints procedure by using the Scheduling Theme.
Scheduling Theme
Lesson Review
Lesson: Implementing Set Constraints

lesson.
Comparing and This page covers the comparison and contrasting of sets to recognize the
Contrasting Set similarities and differences of populations.
Populations
What Are Set This page defines and describes set constraints and then provides examples of
Constraints? how they are used.
Module 7: Adding Value and Set Constraints, and Creating Entity SubtypesCSDP Step 6 v
How Set Constraints Are This page covers the ORM specific symbology of set constraints.
Represented
How to Implement Set This page teaches students the high-level steps of how to implement a set
Constraints constraint.
Set Constraints procedure by using the Scheduling Theme.
Scheduling Theme
Lesson Review
Lesson: Implementing Entity Subtypes

lesson.
Specialization of Object This page covers the specialization of objects. Think of this as breaking out a
Types group from a supertype to a subtype. Point out the bottom-up process by noting
that, as alphabetically labeled, we start at the top of the node tree and go down
during the specialization process. Note that the letters are there for labeling
purposes only and are not reflective of instances in a population.
Generalization of Object This page covers the generalization of objects. Think of this as combining
Types subtypes into a common supertype. Point out the top-down process by noting
that, as alphabetically labeled, we start at the bottom of the node tree and go up
during the specialization process. Note that the letters are there for labeling
purposes only and are not reflective of instances in a population.
What Are Entity This page defines and describes examples of entity subtypes and provides input
Subtypes? on their use.
How Subtype This page covers the specific ORM symbology of entity subtype relationships.
Relationships Are Point out that the references as to which object is the subtype and which object
Represented is the supertype are relative, based on the object specified.
Guidelines for This page provides a set of guidelines that students should consider when
Implementing Entity applying entity subtypes to an ORM model. Point out that these are only
Subtypes guidelines and should not be treated as rules.
How to Implement Entity This page teaches students the high-level steps of how to implement entity
Subtypes subtypes.
Entity Subtypes procedure by using the Scheduling Theme. This practice may take extra time
Scheduling Theme because students are creating new fact types and constraints on the newly
created subtypes. The creation of the subtypes is not justified without such a
setup.
vi Module 7: Adding Value and Set Constraints, and Creating Entity SubtypesCSDP Step 6
Lesson Review

lesson.
Focus of CSDP Step 6 This topic page covers the grand scheme of the CSDP step 6. It is intended to
tie together the main concepts of the previous lessons. Do not spend too much
time on this page, because you will have covered each section in greater detail
in previous lessons.
How to Apply CSDP This topic page is intended as a preview of the high-level steps of the CSDP
Step 6 step 6. Guide students through each task. Point out that the steps in this overall
procedure are not in the order that they were presented in the module. This is
because set and value constraints must be defined before subtypes, so that
students can understand their use in subtypes.
CSDP Step 6Airline page. Explain why each task was completed in the manner done.
Flights Theme
Lesson Review
Module Review
topics covered.
Module 7: Adding Value and Set Constraints, and Creating Entity SubtypesCSDP Step 6 vii
Lab A: Adding Value Constraints, Set Constraints, and Entity

Subtypes
module prior to beginning. You can save time by showing the Verbalizer text as
a demonstration, so that students wont have to record all the information
themselves.
Lab Setup
Lab Results
customization.
Module 7: Adding Value and Set Constraints, and Creating Entity SubtypesCSDP Step 6 1
Module Overview
! Implementing Value Constraints

! Implementing Set Constraints
! Implementing Entity Subtypes

Implement value constraints.
Implement set constraints.
Implement entity subtypes.
2 Module 7: Adding Value and Set Constraints, and Creating Entity SubtypesCSDP Step 6
Lesson: Implementing Value Constraints
! Domain of a Population
! What Are Value Constraints?
! How Value Constraints Are Represented
! How to Implement Value Constraints
! Practice: Implementing Value ConstraintsScheduling
Theme

Introduction You will use value constraints to limit the populations of objects and control
what data is stored in your final database.
Lesson purpose This lesson serves to teach you how to limit the populations of object types to a
predetermined set of values.
! Implement value constraints.
Describe and identify population domains.
Describe value constraints and their uses.
Domain of a Population
! All allowable values

! Values in domain are unique
! Population is not always unique
Domain Population
A A
B
B C Not in the
Z Domain
C
Figure 7.1 A
Introduction Fact types in an Object Role Modeling (ORM) model represent
relationships between populations. Constraints are used to limit those
populations. In ORM, there are several methods of limiting the domain of
an object type.
All allowable values The domain of a population represents all of the possible values that could
exist in the population. It is not necessary that each member of the domain
be used. It is only important that each member could be used.
For example, an object could be constrained to allow only a number
between 1 and 5, or to allow only the names of the days of the week.
Note In a physical implementation on Microsoft SQL Server 2000, the

domain of a population is enforced by data types, check constraints,
triggers, and foreign key constraints.
Values in domain are The domain of a population represents the unique values that could exist,
unique without duplicates. This list can contain one or many values. If a value is
not on the list, then it cannot appear in the physical database.
For example, a domain that contained the names of days of the week would
not list Wednesday twice.
Population is not always In contrast to the domain of a population, the actual population consists of
unique zero or more instances of each domain value.
For example, a populations domain may be limited only to the days of the
week, but the actual population may include multiple entries for any given
day.
What Are Value Constraints?
! Definition
Value constraints limit the population of an object type to a
specific domain of allowable values
! Characteristics
" Global effect on an object types roles
" Defined by enumerated list of values
" Limit the effect on the Universe of Discourse

Introduction To limit the domain of values in an ORM database model, you must create
value constraints.
Definition Value constraints limit the population of an object type to a specific domain of
allowable values.
Characteristics Value constraints have three important characteristics:
! Global effect on an object types roles
Value constraints apply to the population of any role wherever the object
type is used. In this sense, they are global, because they are related only to
an object type.
For example, a value constraint on the Person object limits the Person
drives Car fact type. It also limits the instances of Person that can
participate in the Person has Address fact type, and all other fact types that
involve the Person object type, as well.
! Defined by enumerated list of values or numeric ranges
A value constraint that limits the domain to string values is defined by an
enumerated list of possible values that can exist in the population of an
object type.
For example, the list of names Jeff, Maria, and Pierre could define a value
constraint on the Person object type, thereby limiting the people that are
allowed to drive a car to the persons in that list.
A value constraint that limits the domain to ranges of numeric values is
defined by an enumerated list, a series of numeric ranges, or both.
For example, the numeric ranges of 1-5, 10-20, and numbers greater than
100 could define a value constraint.
! Limit the effect on the Universe of Discourse

In the same manner that you decide which relationships are included in the
Universe of Discourse (UoD), value constraints limit the relevant population
of object types, and, therefore, fact types in the UoD.
For example, if a value constraint on the Person object type exists that only
allows Jeff, Maria, and Pierre, then it has the effect of limiting the UoD to
discussing person relationships and instances that only involve these three
people.
How Value Constraints Are Represented
! FORML expression
Person(Name) is an entity object type.
Every Person is identified by one
distinct Name.
The possible values of 'Name' are:
'Jeff', 'Maria', 'Pierre'.
! Graphically
{ 'Jeff', Value
'Maria', Constraint
'Pierre' }
Person
Car
(Name)
drives
Figure 7.2

Introduction Unlike most other ORM symbology, no unique symbols represent value
constraints. Rather, they are listed as text in the model and show up on the
drawing surface.
FORML expression The Formal Object Role Modeling Language (FORML) expression of a value
constraint follows the pattern of specifying the object type, then the phrase The
possible values of, followed by the object type and the word are, followed by
an enumerated list of values.
Person(Name) is an entity object type.
Every Person is identified by one distinct Name.
The possible values of 'Name' are: 'Jeff', 'Maria',
'Pierre'.
For example, the preceding FORML expression represents a value constraint on

the Person object type that restricts the domain of the object type to Jeff, Maria,
and Pierre.
Graphically The domain of a value constraint is graphically represented by braces around a
list of allowable values, as seen in Figure 7.2.
How to Implement Value Constraints
Select
Select the
theobject
objecttype
type
Specify
Specifythe
thedomain
domainof
of values
valuesor
ornumeric
numericranges
ranges
Validate
Validate the
theORM
ORM model
modeland
and your
yourintent
intent

Introduction Create value constraints to limit the population of an object type to a specific
domain of allowable values.
Procedure Use the following procedure to implement a value constraint:
1. Select the object type.
Remember that value constraints apply to an individual object type, not fact
types. Select the object type whose domain you want to constrain to a list of
values.
2. Specify the domain of values or numeric ranges.
Limiting the domain of values for an object type has the effect of limiting
the scope of the UoD. You use an object types database properties to
specify a value constraint. String values are entered one at a time. Numeric
values are specified individually like string values, or in ranges of values.
process. Just like any other time you modify the model, validate that the
domain of values is properly captured by using the Verbalizer.
Practice: Implementing Value ConstraintsScheduling Theme
! Purpose
! Scenario
! Practice
Mon Tue Wed Thu Fri
8 am
Out of Office:
9 00 Doctors Appt
Manager
1:1 All-han
10 00 Quaterl
Team
11 00 Traini
Brownbag Class
12 pm Lunch: ORM
2 00
Data
Modeling
Project
Data
Modeling
Project
Model Model 3 00
4 00
5 00

Introduction In this practice, you will implement a value constraint by using the Scheduling
Purpose The purpose of this practice is to illustrate how to limit the domain of the
Status object types population to a specific list of allowable values.
scenario.
You have met with the domain expert and are now attempting to restrict the
domain of allowable values in an object type. The domain expert has provided
you with the following information:
! After a person is invited to a meeting, you need to keep track of their
invitation status.
! A persons invitation status must be either decline, accept, or tentative.
! Select the object type

Open and review the ImplValue_Scheduling.vsd ORM source model.
For which object type should you limit the domain of allowable values?
Status.
____________________________________________________________
____________________________________________________________
! Specify the domain of values or numeric ranges

1. On the drawing surface, right-click the shape for the Status value type, and
then click Database Properties.
2. In the Database Properties window, in the Categories pane, select Value.
3. In the Value box, type Decline and then click Add.
4. In the Value box, type Accept and then click Add.
5. In the Value box, type Tentative and then click Add.

verify that no errors or warnings occur during conceptual validation.
2. Select the Value object type shape on the drawing surface.
3. Use the Verbalizer to verify that the following text is displayed in the
Verbalizer window:
Status is a value object type.
The possible values of 'Status' are: 'Decline',
'Accept', 'Tentative'.
Lesson Review
Objectives
Objectives
Implement
Implement value
value constraints
constraints
Describe
Describeand
and identify
identify population
population domains
domains
Describe
Describevalue
value constraints
constraintsand
andtheir
theiruses
uses

1. Describe the domain of a population.
The domain of a population is narrowed by three things. First, it is
limited by allowable instances. Secondly, the values in the domain are
unique, and finally, all values in the population must exist in the
domain.
2. Define value constraints.

Value constraints limit the population of an object type to a specific
domain of allowable values.
Lesson: Implementing Set Constraints
! Comparing and Contrasting Set Populations

! What Are Set Constraints?
! How Set Constraints Are Represented
! How to Implement Set Constraints
! Practice: Implementing Set ConstraintsScheduling
Theme

Introduction Often, a relationship exists between the populations of two different fact types.
ORM uses set constraints to capture these relationships.
Lesson purpose The purpose of this lesson is to teach you how to control the relationships
between populations in an ORM database model by using set constraints.
! Implement set constraints.
Describe and identify set comparisons.
Describe and identify set equality constraints and their uses.
Describe and identify subset constraints and their uses.
Describe and identify set exclusion constraints and their uses.
Comparing and Contrasting Set Populations
! Set equality
Set 1 Set 2
Figure 7.3
A B C A B C
! Subset
Set 1 Set 3
A B C A B
Figure 7.4
! Set exclusion
Set 3 Set 4
Figure 7.5
A B C

Introduction Remember that a role in a fact type represents a population of an object type.
Often, you need to compare and contrast two populations of the same object
type. Those populations are related to each other in one of three different ways.
Set Equality In Figure 7.3, the population of set 1 is exactly the same as that of set 2.
Table 7.1
Set 1 Set 2
{A,B,C} {A,B,C}
{apple, orange, pear, banana} {apple, orange, pear, banana}
Subset The instances shown in Figure 7.4 illustrate that set 3 is a subset of the
population of set 1. No instance can exist in set 3 if it does not exist in set 1.
Table 7.2
Set 1 Set 3
{A,B,C} {A,B}
{apple, orange, pear, banana} {apple, pear }
Set Exclusion The instances shown in Figure 7.5 illustrate that set 4 contains no instances that
are in set 3. No overlap between the populations occurs.
Table 7.3
Set 3 Set 4
{A,B } {C}
{apple, pear} {orange, banana}
What Are Set Constraints?
! Definition
Set constraints restrict two populations in relation to each
other
! Characteristics
" External
" Constrain two roles or tuples
" Transfer the impact of constraints

Introduction Like all things ORM related, populations must relate to each other to complete
an ORM model. Set constraints limit which instances can participate in a fact
type.
Definition Set constraints restrict two populations in relation to each other.
Characteristics Set constraints have three important characteristics. They:
! Are external.
A set constraint is primarily external, meaning that it spans roles in two
different fact types, just like an external uniqueness constraint. By
constraining the roles in two different fact types, you in effect constrain the
fact instances in each of the fact types, as well.
Caution Although you can create an internal set constraint on the roles in a
single fact type, typically it is not meaningful.
! Constrain two roles or tuples.

Set constraints extend the concept of limiting the allowable domain of
values for a population so that it is quantitatively correlated to another
population. A single role, or tuple, may represent a population. The number
of roles must be the same on both ends of the set constraint. If a tuple is
used, the ordinal sequence of the roles is meaningful.
For example, you can use a set constraint to correlate the combination of a
date and a customer number on a purchase order with the combination of a
date and a customer on an invoice.
! Transfer the impact of constraints.

The population of any given role is limited by the cumulative application of
all of the constraints on that role. In other words, the population of a given
role must satisfy all constraints on that role. In this manner, set constraints
transfer the impact of all other constraints from one role to another.
For example, when you place a mandatory constraint on a given role, and
then create a set equality constraint between that role and another, you
effectively make both roles mandatory.
How Set Constraints Are Represented
! Set exclusion HourlyWage

is paid
No Employee that is paid
some HourlyWage is paid Exclusion
some Salary. Constraint
! Set equality is paid

Salary
Employee e is paid some Equality

Salary if and only if Employee
Constraint
Employee e works as some
SalesManager.
SalesManager
! Set subset works as
Subset
If Employee e works as Constraint
some SalesManager then
Employee e works as some Salesperson
Salesperson. works as
Figure 7.6
1 22 3

Introduction Like most other ORM elements, there are only subtle differences between these
shapes.
Set constraint shapes Use Table 7.4 to identify the set constraint shapes.
Table 7.4
Set exclusion constraint

Prevent instances in one set from appearing in another.
Are symbolized by a dashed line between the roles with a circled X in
the center.
FORML expression:
No Employee that is paid some HourlyWage is paid
some Salary.
Set equality constraint

Force all instances in one set to appear in another.
Are symbolized by a dashed line between the roles with a circled equal
sign in the center.
FORML expression:
Employee e is paid some Salary if and only if
Employee e works as some SalesManager.

Set subset constraint

Limit instances in one set to those that are also in another.
Are symbolized by a dashed arrowed line between the roles with a
circled subset sign in the center. The arrow always points from the
subset to the superset.
FORML expression:
If Employee e works as some SalesManager then
Employee e works as some Salesperson.
How to Implement Set Constraints
Identify
Identifyand
and select
selectthe
thefact
facttypes
types
Select
Selectthe
thetype
typeof
ofset
set constraint
constraint
Designate
Designatethe
the roles
rolesin
inthe
theset
setconstraint
constraint
Validate
Validate the
theORM
ORM model
modeland
and your
yourintent
intent

Introduction Create set constraints to restrict two populations in relation to one another.
Procedure Use the following procedure to implement set constraints:
1. Identify and select the fact types.
You can make meaningful set comparisons only when comparing like
populations. Identify two different facts that each share a common object
type so that you can compare two different populations of the same thing.
2. Select the type of set constraint.
Remember that set constraints work in conjunction with other constraints to
indirectly impact other populations.
3. Designate the roles in the set constraint.
Equality and exclusion set constraints are nondirectional. If you are
implementing a subset constraint, decide which population represents the
whole superset and which represents the subset. Remember that the
connector arrow points to where an instance must exist.
Note The roles designated for the set constraint must represent the same
object type.

process. Use the FORML expressions that the Verbalizer generates to
validate that you captured your intent. Make sure that you have properly
designated the subset and superset populations with subset constraints.
Practice: Implementing Set ConstraintsScheduling Theme
! Purpose
! Scenario
! Practice
Mon Tue Wed Thu Fri
8 am
Out of Office:
9 00 Doctors Appt
Manager
1:1 All-han
10 00 Quaterl
Team
11 00 Traini
Brownbag Class
12 pm Lunch: ORM
2 00
Data
Modeling
Project
Data
Modeling
Project
Model Model 3 00
4 00
5 00

Introduction In this practice, you will implement set constraints by using the Scheduling
Purpose The purpose of this practice is to illustrate how to designate that the population
of one tuple is a subset of the population of another tuple. The combination of
two roles represents the tuples.
scenario.
You have met with the domain expert and are now attempting to restrict the
populations in fact type roles relative to one another. The domain expert has
! A given meetings use of a venue must be approved by a venue owner.
! Venue owners can only approve the use of venues that they actually own.
! Identify and select the fact types

1. Open and review the ImplSet_Scheduling.vsd ORM source model.
Which fact type represents the set of tuples that indicates which person or
persons own a given venue?
Person owns Venue.
____________________________________________________________
____________________________________________________________
Which fact type represents the set of tuples that indicates the set of persons
who approved the use of venues for meetings?
Person approves use of Venue for Meeting.
____________________________________________________________
____________________________________________________________
Based on the mandatory role constraints on the fact types, which fact type
constrains the domain of Person and Venue instances that can participate in
others?
The domain of the Person owns Venue fact type constrains the domain
of the Person approves use of Venue for Meeting fact type.
____________________________________________________________
____________________________________________________________
2. On the drawing surface, click the predicate shape for the Person Owns
Venue fact type, SHIFT+right-click the predicate shape for the Person
approves use of Venue for Meeting fact type, and then click Add
Constraint.
! Select the type of set constraint

In the Add Constraint window, in the Constraint type list, select Subset.
! Designate the roles in the set constraint

1. In the Add Constraint window, in the Number of roles at each end box,
select 2.
2. In the Add Constraint window, in the pane entitled Select the role box of
each role in the constraint, on the predicate shape for the [Person] approves
use of [Venue] for [Meeting] fact type, click the Person role, and then
click the Venue role to designate the subset tuple.
each role in the constraint, on the predicate shape for the [Person] owns
[Venue] fact type, click the Person role, and then click the Venue role to
designate the superset tuple.

2. On the drawing surface, select the subset constraint shape that spans the
Person and Venue roles in the Person owns Venue and Person approves
use of Venue for Meeting fact types.
3. Use the Verbalizer to verify that the following text is displayed somewhere
If Person p approves use of Venue v for some Meeting then
Person p owns Venue v.
Lesson Review
Objectives
Objectives
Implement
Implement set
set constraints
constraints
Describe
Describeand
and identity
identity set
setcomparisons
comparisons
Describe
Describeand
and identify
identify set
setequality
equality constraints
constraints
and
and their
theiruses
uses
Describe
Describeand
and identify
identify subset
subset constraints
constraintsand
and
their
theiruses
uses
Describe
Describeand
and identify
identify set
setexclusion
exclusion constraints
constraints
and
and their
theiruses
uses

1. What is the relationship between sets in the following examples?
Set A: Frank, Marguerite, Jacques, Anita
Set B: Frank, Jacques, Anita
Set B is a subset of set A.
Set A: Frank, Marguerite, Anita

Set B: Jacques, Roland
The population of set A is excluded from set B, and vice versa.
Set A: Frank, Marguerite, Jacques, Anita, Roland

Set B: Frank, Marguerite, Jacques, Anita, Roland
The population of set A is exactly the same as the population of set B.
2. Why would you use a set constraint?

To restrict two populations of the same object type in relation to each
other.
3. Do you model set constraints externally or internally?

Externally.
Lesson: Implementing Entity Subtypes
! Specialization of Object Types

! Generalization of Object Types
! What Are Entity Subtypes?
! How Subtype Relationships Are Represented
! Guidelines for Implementing Entity Subtypes
! How to Implement Entity Subtypes
! Practice: Implementing Entity SubtypesScheduling
Theme

Introduction Sometimes you need to control a subset of an object types population
differently from the entire population. That subset of the population may also
participate in different fact types.
Lesson purpose The purpose of this lesson is to teach you how to implement entity subtypes in
an ORM model.
! Implement entity subtypes.
Describe specialization of object types.
Describe generalization of object types.
Describe and identify subtype relationships and their uses.
Specialization of Object Types
! Subsets of a population
! Subsets have distinctive
A
characteristics
" Specialized relationships B C
" Specialized constraints
" Start from primitive object
types D E
! Top-down process
" Arrows point toward node
that was specialized F G
Figure 7.7

Introduction Often you must classify a subset of a group of objects into more specific groups
to understand them or ascertain more useful information from them.
Subsets of a population Think of specialization of an object type as breaking its population up into
subsets.
For example, the specialization of the population of the Vehicle object type
might result in the GasVehicle and DieselVehicle object types. You could
further specialize each of those as ConsumerVehicle and CommercialVehicle
object types.
Subsets have distinctive You should only specialize an object type into subsets if the subsets will each
characteristics have distinctive characteristics, such as:
! Specialized relationships
Each subset should represent a population that has a relationship with other
object types that are specific to a given subset only.
For example, if the population of Person were broken down into parents
and non-parents, you could model that only parents can have children.
! Specialized constraints
Each subset should represent a population that has constraints on it that do
not apply to other subsets.
For example, if the population of Employee were broken down into
managers and clerks, you could make it mandatory that managers have a
cellular phone number, and you could not require clerks to have one.
! Start from primitive object types

Remember that primitive object types are the lowest common denominator
of several object types. After you have determined the primitive object type
in CSDP step 3, you can deliberately break it back up into supertypes.
For example, instead of Dentist and Surgeon being two different unrelated
object types, it is possible to make them both supertypes of the primitive
entity type Doctor. Any constraints or relationships that the Doctor entity
type participated in would also apply to the entity subtypes Dentist and
Surgeon.
Top-down process The process of specialization of object types is a top-down process. You start
with the population of the most abstract object type, and then you refine it,
drilling down into less and less abstract object types.
Generalization of Object Types
! Supersets of a population
! Supersets have overlapping
G
characteristics
" Shared relationships E F
" Shared constraints
" End up with a shared
primitive object type C D
! Bottom-up process
" Arrows point toward more
generic nodes A B
Figure 7.8

Introduction In contrast to information on the previous topic page, sometimes you must
combine a group, or population of objects, into more generic groups to
understand them or ascertain more useful information from them.
Supersets of a Think of a generalization of object types as the grouping of its population into
population supersets.
For example, the generalization of the GasVehicle and DieselVehicle object
type populations might result in a Vehicle object type.
Supersets have You should only generalize a group of object types into larger supersets if they
overlapping have common, non-competing characteristics, such as:
characteristics
! Shared relationships
Each superset should represent the union of other populations that share
common relationships. Supersets are formed to consolidate relationships.
For example, if regional managers and district managers both supervise
employees, you may be able to generalize them into a supertype Manager
object type who supervises employees.
! Shared constraints
Each superset should represent the union of other populations that share
common constraints. A constraint on a supertype applies to all supertypes,
as well.
For example, if it is mandatory that all undergraduate students are enrolled
in a class, and it is also mandatory that all post-graduate students are
enrolled in a class, then you may be able to create a supertype Student
object type, and constrain that instances of it be enrolled in a class.
! End up with a shared primitive object type
If shared relationships and constraints are indicative of a common primitive
entity type, you may end up with a shared primitive object type.
Warning Do not confuse generalization of object types with conceptual

partitioning to implement primitive object types. While similar, there is an
important distinction in that generalization of object types combines
populations because of how they are used, and primitive object types are
created because of what they are.
Bottom-up process The process of generalizing object types is a bottom-up process. You start with
specialized populations, and then you progress to more and more general-
purpose object types.
What Are Entity Subtypes?
! Definition
An entity subtype is an object type that is contained in another
object type
! Characteristics
" Identified by the primary supertypes reference scheme
" Populations may overlap through implied set constraint
" Reuse through inheritance
" Subtypes are transitively related
" Cumulative relationships and constraints
" Based on primitive entity types

Introduction You must understand the meanings and characteristics of specialization to
properly model subtype constraints.
Definition An entity subtype is an object type that is contained in another object type.
Entity subtypes must be well defined in terms of relationships played by their
supertypes. Entity subtypes with the same supertype may overlap.
Note The application of supertypes is a form of object type specialization.
Characteristics Entity subtypes display six characteristics:

! They are identified by the primary supertypes reference scheme.
By default, the primary reference scheme for an entity subtype is that of its
supertype. If there is more than one supertype, then use the primary
supertypes reference scheme.
! Their populations may overlap through implied set constraint.
The populations of entity subtypes that share a common supertype may
intersect, as restricted by constraints on the various supertypes. The
population of the entity subtype is always equal to or a subset of the
supertype.
For example, a manager could be both an accountant and a salesperson, but
the converse is not necessarily true.
! They allow for reuse through inheritance.

Entity subtypes allow you to reuse complex or standard business rules that
you have captured. Remember that an entity subtype inherits characteristics
from its parent, or supertype.
For example, you can augment standard relationships and constraints for
employees across your whole organization to include those business rules
that are specific to a given job; and you do this by creating a specific
subtype of employee, and then using the subtype in additional roles.
Note Inheritance loops are not allowed in subtyping. Inheritance from

multiple supertypes is allowed, however. If you do have multiple
inheritances, you must designate one supertype as the primary supertype.
! They are transitively related.

Remember that a transitive relationship implies that characteristics are
passed from object to object in a similar fashion. Subtype inheritance, by its
very nature, transitively passes characteristics from parent to child.
! Their relationships and constraints are cumulative.
Because of the transitive nature of inheritance and because entity subtypes
allow multiple inheritance, the relationships and constraints that a given
instance is subject to are the cumulative effects of all relationships and
constraints of all its supertypes.
For example, a value constraint on an entity subtypes parent combines with
a set constraint on the subtype to restrict the subtype population to the
intersection of the two constrained populations.
Note Inheritance in ORM is similar (but not exactly the same) as

inheritance in object-oriented programming. This is because you cannot
override parent relationships or constraints.
! They are based on primitive entity types.

You must be able to trace all entity subtypes back to a primitive entity type
to properly determine the subtypes allowable population.
Note In many ways, the relationship between subtypes and supertypes is

similar to functional dependencies, in the sense that the population of an
entity subtype is functionally dependent on the population of its supertype.
How Subtype Relationships Are Represented
! FORML expression for

Salesperson object type
Employee
Salesperson is primarily
identified by the Subtype
identification scheme of Relationship
Employee.
Salesperson is a subtype of
Employee / Employee is a Accountant Salesperson
supertype of Salesperson.
Employee is the primary Primary

super type of Salesperson. Secondary
Subtype
Subtype
Each Manager is a Relationship
Relationship
Salesperson but not every Manager
Salesperson is necessarily a
Manager.
Figure 7.9
11 2 33

Introduction You must be able to readily identify entity subtypes and tell which object is the
supertype and which is the subtype.
FORML expression An object types FORML expression is annotated to speak of every entity
subtype that it participates in, either as a parent or a child. The following
FORML expression represents the subtype relating to the Salesperson object
type:
Salesperson is an entity object type
Salesperson is primarily identified by the identification

scheme of Employee.
Salesperson is a supertype of Employee / Employee is a

supertype of Salesperson.
Employee is the primary super type of Salesperson.
Each Manager is a Salesperson but not every Salesperson is

necessarily a Manager.
Entity subtype shapes Entity subtypes are indicated by an arrow-tipped line that connects the object
type that is a subtype with the object type that is the supertype. The arrow
always points to the supertype.
A solid line indicates the primary subtype and primary path of inheritance for
identification purposes. A dotted line indicates a secondary subtype in the case
of multiple inheritances, differing only in that it is not used for identification.
Guidelines for Implementing Entity Subtypes
Do
Do not
not create
create aa subtype
subtype unless
unless there
there is
is aa specific
specific role
role for
for itit
Explicitly
Explicitly constrain
constrain subtypes
subtypes to
to enforce
enforce different
different uses
uses
Create
Create aa chain
chain of
of subtypes
subtypes relating
relating back
back to
to aa primitive
primitive entity
entity type
type
Avoid
Avoid assigning
assigning aa subtype
subtype its
its own
own reference
reference scheme
scheme

Guidelines Use the following guidelines whenever you model entity subtypes.
Do not create a subtype Do not complicate the model by creating unused subtypes. Remember that the
unless there is a specific rationale for subtypes is that a subset of the population is used differently from
role for it the bulk of the population, meaning that it participates in fact types or has
constraints on it that do not apply to the rest of the population.
Explicitly constrain Even though direct subtypes of a primitive object type have implied set
subtypes to enforce exclusion constraints between them, you should explicitly place set and value
different uses constraints on subtypes to enforce the rationale for creating them.
Create a chain of To be safe, always start by creating subtypes of a primitive entity type. This
subtypes relating back will keep your model clean and help you determine which constraints implicitly
to a primitive entity type stem from constraints on the primitive type.
Avoid assigning a Although you can assign a subtype its own reference scheme, doing so will
subtype its own obscure the subtype relationships during the physical implementation of the
reference scheme model. Conceptually, all subtypes represent the same supertype anyway, so use
the default supertypes reference scheme to avoid confusion.
How to Implement Entity Subtypes
Identify
Identifyentity
entity supertypes
supertypesand
andcreate
create entity
entitysubtype
subtype
objects
objects
Create
Create subtype
subtype relationships
relationships
Create
Create entity
entitysubtype
subtyperelated
relatedfact
fact types
types
Enforce
Enforcesubtypes
subtypeswith
withvalue
valueand
and set
set constraints
constraints
Validate
Validate the
theORM
ORM model
modeland
and your
yourintent
intent

Introduction Create an entity subtype that is an object type contained in another object type.
You must adequately define entity subtypes in terms of relationships played by
their supertypes. Remember that the populations of entity subtypes with the
same supertype may overlap.
Procedure Use the following procedure to implement subtype constraints:
1. Identify entity supertypes and create entity subtype objects.
Remember that the creation of subtypes is a form of specialization of object
types, specifically, primitive object types. Do not create a subtype and its
supertype at the same time; always use an existing object type as the
supertype.
2. Create subtype relationships.
Subtype relationships are created by dragging the subtype relationship shape
from the ORM source template window onto the drawing surface, and then
appropriately connecting the ends to indicate which entity type is the
subtype and which is the supertype.
3. Create entity subtype related fact types.
Remember that subtypes are created to allow for the application of special
relationships and constraints that apply only to a given subtype.
4. Enforce subtypes with value and set constraints.
Use value constraints to limit the domain of a given subtype to a specific set
of instances. Use set exclusion constraints to make sure that there is no
overlap between subtypes, if so desired.
what you and the domain expert intended, and that the model is error-free. It
is harder to validate subtype constraints, because the FORML expression is
relative to the end of the subtype constraint that you are examining.
Practice: Implementing Entity SubtypesScheduling Theme
! Purpose
! Scenario
! Practice
Mon Tue Wed Thu Fri
8 am
Out of Office:
9 00 Doctors Appt
Manager
1:1 All-han
10 00 Quaterl
Team
11 00 Traini
Brownbag Class
12 pm Lunch: ORM
2 00
Data
Modeling
Project
Data
Modeling
Project
Model Model 3 00
4 00
5 00

Introduction In this practice, you will implement entity subtypes by using the Scheduling
Purpose The purpose of this practice is to illustrate how to implement entity subtypes of
the Venue object type that are all based on a common primitive entity type, but
that exclusively participate in different relationships.
scenario.
You have met with the domain expert and are now attempting to model
subtypes and their relationships. The domain expert has provided you with the
! Meetings must be hosted at a single venue. The type of venue is a physical
location, an online location, or both. You must keep the types of venues
separate. The attendee capacity of every venue is known.
! Physical locations are known by a single building and room number.
! Online locations are known by their URL, and they may have an access
code.
! Identify entity supertypes and create entity subtype objects

1. Open and review the ImplSubtype_Scheduling.vsd ORM source model.
Which object type has population subsets that participate in different
relationships?
Venue.
____________________________________________________________
____________________________________________________________
2. Create the new entity subtypes called Location and Online, and then drag
them onto the drawing surface.
! Create subtype relationships

1. On the File menu, point to Stencils and then Database, and then click
ORM Source.
2. In the ORM Source stencil window, drag the Subtype Relationship shape
onto the drawing surface.
3. On the drawing surface, drag the arrow-tipped end of the new subtype
relationship shape onto the Venue object type shape, and then drag the other
end of the subtype relationship shape onto the Location object type shape.
4. On the drawing surface, right-click the shape for the Location object type,
and then click Database Properties.
5. In the Database Properties window, in the Categories pane, click Subtype,
and then in the Subtype definition box, type The subset of Venues that
are physical resources.
6. Repeat steps 2-5, designating the Online object type as a subtype of the
Venue object type, with a subtype definition of The subset of Venues that
are online resources.
! Create entity subtype related fact types

1. Create the following new object types: Building, RoomNumber, and
AccessCode.
2. On the Database menu, point to View, and then click Fact Editor.
3. On the Fact tab, in the left-most Object Name box, select Location. In the
Relationship box, type is in and in the right-most Object Name box, select
Building.
4. On the Constraints tab, in the Constraint Question #1 box, select Exactly
One. In the Constraint Question #2 box, select Zero or More, and then
click Apply.
5. Repeat steps 3 and 4 by using the information in Table 7.5, and then click
Cancel.
Table 7.5
Constraint Constraint
Object name Relationship Object name question #1 question #2
Location Has RoomNumber Exactly One Zero or More

Online Has AccessCode Zero or One Zero or More
6. Assign a reference mode of URL to the Online object type.

7. Draw the new fact types that were created in steps 3-5.
8. Create a compound primary reference scheme across the Building and
RoomNumber roles of the Location is in Building and Location has
RoomNumber fact types.
9. Use the Fact Editor and the information in Table 7.6 to replace the Venue
role as appropriate in the original fact types, and then draw them.
Table 7.6
Original fact type Replace Venue role with
Meeting is hosted physically at Venue Location

Meeting is hosted electronically at Venue Online
! Enforce subtypes with value and set constraints

1. On the drawing surface, click the predicate shape for Meeting is hosted
physically at Location, SHIFT+right-click the predicate shape for Meeting
is hosted electronically at Online, and then click Add Constraints.
2. In the Add Constraint window, in the Constraint type box, select
Exclusion.
each role in the constraint, click each of the Location and Online roles in
the predicate shapes, and then click OK.

2. On the drawing surface, select the exclusion set constraint shape and the
shapes for the Venue, Location, and Online object types.
Assuming o is an instance of Location or Online then
For each o, at most one of the following holds:
some Meeting is hosted physically at Location o;
some Meeting is hosted electronically at Online o.
Venue(ID) is an entity object type.

Every Venue is identified by one distinct ID.
Every Location and Online is a Venue but not vice-versa.
Location is an entity object type

Location is primarily identified by the constraint:
For each Building b and RoomNumber r
there is at most one Location that
is in Building b and has RoomNumber r.
Location is a subtype of Venue / Venue is a supertype of
Location.
Venue is the primary super type of Location.
Subtype definition: The subset of Venues that are
physical resources.
Online(URL) is an entity object type.

Every Online is identified by one distinct URL.
Online is a subtype of Venue / Venue is a supertype of
Online.
Venue is the primary super type of Online.
Subtype definition: The subset of Venues that are online
resources.
Lesson Review
Objectives
Objectives
Implement
Implement entity
entity subtypes
subtypes
Describe
Describethe
the specialization
specialization of
of object
object types
types
Describe
Describethe
the generalization
generalizationof
ofobject
object types
types
Describe
Describeand
and identify
identify subtype
subtyperelationships
relationshipsand
and
their
theiruses
uses

1. Describe the specialization of object types.
The breaking up of a group or population into subsets of more specific
populations or groups.
2. Describe the generalization of object types.

The combining of like groups or populations into more generic groups
or populations.
3. What is the purpose of using set and value constraints in conjunction with
entity subtypes?
To ensure the purposeful separation of a supertypes population into
one or more subtype populations.

Theme

Introduction In this lesson, you will apply CSDP step 6 to assess your understanding of the
previous three lessons.
relating to value constraints, set constraints, and entity subtypes to implement
CSDP step 6.
CSDP Step 6: Add value, set, and subtype constraints

" Domain of a population
" Comparing and contrasting set populations
" Specialization of object types

Introduction In CSDP step 6, you control populations of the same object type. It is important
that you complete the previous CSDP steps before starting this step.
CSDP step 6 Add value, subset, equality, and exclusion constraints, and create entity
subtypes.
Domain of a population Remember that the domain of a population is the allowable values of an object
type or role. You use value and set constraints to limit the allowable members
of a population.
Comparing and Remember that the instances in a population make up a set. You control which
contrasting set populations are related through the use of fact types, and you can control the
populations domains of roles in those fact types by using set constraints.
Specialization of object Remember that you may need to model specialized relationships or constrain
types specific populations of an object type. You use subset constraints to isolate a
subset of an object types population so that you can create specific
relationships and constraints on that subset.
Implement
Implemententity
entitysubtypes
subtypes
Implement
Implementvalue
value constraints
constraints
Implement
Implementset
set constraints
constraints
Validate
Validate the
theORM
ORM model
modeland
and your
yourintent
intent

Introduction Use the high-level procedures on this page to apply CSDP step 6:
Procedure to apply CSDP step 6:
1. Implement entity subtypes.
Use subtype constraints to specialize your model for subsets of an object
types population. Set and value constraints help to define the population of
each subtype.
2. Implement value constraints.
Apply value constraints to the model to limit the scope of the UoD, and to
limit the population of an object type that will be used in set constraints.
3. Implement set constraints.
Apply set constraints to control the combination of fact types that a given
instance of an object type will participate in. Remember that set constraints
transfer the impact of population constraints between fact types.
process. Check that the cumulative effect of the fact types and constraints
that you have modeled are as intended.
! Purpose
! Scenario
! Practice
London
UK11 (LHR)
US72
IT37
New York
Madrid Rome
(JFK)
ES2 (MAD) (FCO)
Atlanta 3 US62
VE56
(ATL)
VE59
Starting US68
VE56
Dakar
(DKR)
Model Caracas
(CCS)

modeling scenario. You will model subtypes of the Flight object type, create
relationships that are specific to those subtypes, and implement value and set
constraints.
flights. For the purposes of this practice, the UoD is limited to the information
in this scenario.
You have met with the domain expert and are now attempting to specialize
object types and their relationships, and to limit the UoD by restricting
allowable values in object types. The domain expert has provided you with the
! You can categorize all flights as either eastbound or westbound.
! A given flight is identified by concatenating the two-letter code for the
country it originated in with a number from 1 to 99.
! The number is always even for eastbound flights and always odd for
westbound flights.
! All flights have a status, limited to On Time, Delayed, Arriving,
Boarding, Canceled, or Will Board.
! You will only model information for flights that originated in the United
States, United Kingdom, Italy, Spain, Senegal, and Venezuela. The two-
letter codes for those countries are US, UK, IT, ES, SN, and VE,
respectively.
! Implement entity subtypes

2. Create two new object types called EastboundFlight and
WestboundFlight that are subtypes of the Flight object type.
3. Assign a subtype definition of Flights that travel west to the
WestboundFlights object type, and a subtype definition of Flights that
travel east to the EastboundFlights object type.
4. Use the information in Table 7.7 with the Fact Editor to create fact types
that are related to the new entity subtypes.
Table 7.7
Object Constraint Constraint
Object name Relationship name question #1 question #2
WestboundFlight Has odd- Number Exactly One Zero or

More
EastboundFlight Has even- Number Exactly One Zero or
More
5. In the WestboundFlight has odd Number fact type, specify the Number is
always odd derived but not stored derivation rule.
6. In the EastboundFlight has odd Number fact type, specify the Number is
always even derived but not stored derivation rule.
! Implement set constraints

Create an external exclusion constraint between the Flight entity subtype
roles of the EastboundFlight has even Number and the WestboundFlight
has odd Number fact types.
! Implement value constraints

1. Create a value constraint on the Number object type that limits its domain
to a range of numbers between 1 and 99.
2. Create a value constraint on the Country object type that limits its domain
to the two-letter country codes provided in the scenario requirements.
3. Create a value constraint on the Status object type that limits its domain to
the status codes provided in the scenario requirements.

2. On the drawing surface, select the shapes for the WestboundFlight and
EastboundFlight object types.
WestboundFlight is an entity object type
WestboundFlight is primarily identified by the
identification scheme of Flight.
WestboundFlight is a subtype of Flight / Flight is a
supertype of WestboundFlight.
Flight is the primary super type of WestboundFlight.
Subtype definition: Flights that travel west.
EastboundFlight is an entity object type

EastboundFlight is primarily identified by the
identification scheme of Flight.
EastboundFlight is a subtype of Flight / Flight is a
supertype of EastboundFlight.
Flight is the primary super type of EastboundFlight.
Subtype definition: Flights that travel east.
4. On the drawing surface, select the predicate shapes for the

WestboundFlight has odd Number and EastboundFlight has even
Number fact types, and the set exclusion constraint between them.
WestboundFlight has odd Number
Each WestboundFlight has some odd Number.
Each WestboundFlight has at most one odd Number.
EastboundFlight has even Number

Each EastboundFlight has some even Number.
Each EastboundFlight has at most one even Number.
Assuming e is an instance of WestboundFlight or

EastboundFlight then
No e that has some odd Number has some even Number.
6. On the drawing surface, select the shapes for the Status, Number, and
Country object types.
Status is a value object type.
The possible values of 'Status' are: 'On Time',
'Delayed', 'Arriving', 'Boarding', 'Canceled', 'Will
Board'.
Country(Code) is an entity object type.

Every Country is identified by one distinct Code.
The possible values of 'Code' are: 'US', 'UK', 'IT',
'ES', 'SN', 'VE'.
Number is a value object type.

The possible values of 'Number' are: 1 to 99.
! Implement entity subtypes

London
UK11
(LHR)
US72
IT37
New York
Madrid Rome
(JFK)
ES2 (MAD) (FCO)
Atlanta 3 US62
VE56
(ATL)
VE59
US68 Dakar
Solution VE56
(DKR)
Model Caracas
(CCS)

modeling scenario. You modeled subtypes of the Flight object type, created
relationships that are specific to those subtypes, and implemented value and set
constraints.
Implement entity You created two new subtypes of the Flight object type: WestboundFlight and
subtypes EastboundFlight. After that, you added the WestboundFlight has odd
Number and EastboundFlight has even Number fact types.
The scenario requirements told you that all flights were categorized as
eastbound or westbound and that some special relationships that applied only to
westbound or eastbound flights, in that eastbound flights have an even number,
and westbound flights have an odd number.
The mandatory role constraints on each entity subtype force all flights in that
category to participate in the special relationships.
Implement set You created an external set exclusion constraint across the WestboundFlight
constraints and EastboundFlight roles of the WestboundFlight has odd Number and
EastboundFlight has even Number fact types.
The scenario requirements told you that all flights were categorized as
eastbound or westbound. Remember that because both the WestboundFlight
and EastboundFlight object types have the same supertype, set constraints
placed between their roles are really applied to the population of the Flights
object type.
Any one of the mandatory role constraints on the Flight object type will force
every instance in its population to participate in some state of the model.
Coupled with the mandatory roles on WestboundFlight and EastboundFlight,
the set exclusion constraint will force the categorization of all Flight instances
into one of the subtypes, effectively creating a partitioning scheme.
Implement value Value constraints were applied to the Status, Country, and Number object
constraints types that limited the domain of allowable values for each object type to those
noted in the scenario requirements.
The value constraints have the effect of limiting the UoD by restricting the
instances of each fact type that may exist in the data model. All status codes are
standardized. The model tracks only flights that originate in a known set of
countries. The numeric component used to identify a flight is limited to
numbers between 1 and 99. All other instances of Flight that are not related to
domains specified by the value constraints are not in the scope of the UoD.
The mandatory role constraint on the Flight roles of the Flight has Status,
Flight originates in Country, and Flight has Number fact types force all
instances of Flight to be affected by the value constraints.
Validate the ORM model The need for the entity subtypes was indicated in the scenario requirements that
and your intent called for special relationships for each subtype, and a set exclusion constraint
between roles in those special relationships, as indicated by:
! You can categorize all flights as either eastbound or westbound.
! The number is always even for eastbound flights and always odd for
westbound flights.
The scenario requirements that called for value constraints were indicated by
the scenario requirements:
! A given flight is identified by concatenating the two-letter code for the
country it originated in with a number from 1 to 99.
! All flights have a status, limited to On Time, Delayed, Arriving,
Boarding, Canceled, or Will Depart.
! You will only model information for flights that originated in the United
States, United Kingdom, Italy, Spain, Senegal, and Venezuela. The two
letter codes for those countries are US, UK, IT, ES, SN, and VE,
respectively.
requirements of the scenario were met. You should also reevaluate any example
data that you entered or possibly deleted while applying CSDP step 6.
Lesson Review
Objectives
Objectives
Apply
Apply CSDP
CSDP step
step 66
Implement
Implementvalue
valueconstraints
constraints
Implement
Implementset
set constraints
constraints
Implement
Implemententity
entitysubtypes
subtypes

1. Most generally, what is the reason for CSDP step 6?
You use CSDP step 6 to create fact types and constraints that involve
role populations of the same object type.
2. In the procedures for implementing CSDP step 6, why are entity subtypes
implemented before value and set constraints?
Set and value constraints help to define the population of each subtype.
Module Review
! Implementing Value Constraints

! Implementing Set Constraints
! Implementing Entity Subtypes

1. How does a set constraint limit the domain of a role differently than a value
constraint?
A value constraint is placed on an object type to limit the domain of all
of an object types roles to a list of values.
A set constraint is placed on a role to limit the domain of that role in
relation to the population of another role.
2. What us the significance of the arrow on the subtype constraint in an ORM

diagram?
The arrow is the indicator of which object is the supertype and which is
the subtype. The arrow always points to the generalized object type that
the subtype inherits its fact types and constraints from.
3. Where do the allowable values set in a value constraint appear in an ORM

model?
They appear on the ORM diagram as a text list within braces above the
object types shape, and in the database properties for the object type.
4. How do you specialize an object type in an ORM model?

Identify the supertype object, create or identify the subtype object,
create a subtype constraint between them, and create other constraints
to limit the population of the subtype.
Lab A: Adding Value Constraints, Set Constraints, and

Entity Subtypes
! Exercise 1: Implementing Entity Subtypes
! Exercise 2: Implementing Set Constraints
! Exercise 3: Implementing Value
Constraints

Introduction This lab will reinforce your understanding of CSDP step 6 and the skills taught
in the module.
! Apply the Conceptual Schema Design Procedure (CSDP) step 6.

! Be able to implement value constraints.
! Be able to implement set constraints.
! Be able to implement entity subtypes.
folder.
Estimated time to
complete this lab:
30 minutes
Exercise 0
Lab Setup
box.
5. Click OK.
Exercise 1
Implementing Entity Subtypes
Academic Theme.
scenario.
You are tasked with implementing entity subtypes in an ORM source model. In
this exercise, do not change any of the fact types beyond adding entity subtypes
and related fact types.
! Each academic works for at most one department.
! Some academics can be categorized as professors, some as teachers, and
some as both. If a professor also teaches, his or her teaching duties are
secondary to professorial duties.
! Each teacher is audited by at most one other teacher.
! It is possible that some professors who teach serve on more than one
committee.
! For each department, at most one professor heads the department. Each
professor heads at most one department.
Tasks
! Identify entity supertypes and create entity subtype objects
According to the scenario, which primitive entity type has population
subsets that participate in different relationships?
Academic.
____________________________________________________________
____________________________________________________________
What new subtype entities are called for by the scenario, and what are their
supertypes?
Professor and Teacher are subtypes of the Academic supertype.
TeachingProfessor is a subtype with two supertypes, Professor and
Teacher.
____________________________________________________________
____________________________________________________________
2. Create new object types, entity subtype relationships, and subtype

definitions for each of the above identified object subtypes.
3. Use the Fact Editor to create new fact types that are related to the new entity
subtypes, as indicated by the scenario.
! Validate the entity subtype relationships

2. Select all of the new entity subtype shapes on the drawing surface.
What is the text that the Verbalizer displays for the entity subtypes?
Teacher is an entity object type
Teacher is primarily identified by the identification
scheme of Academic.
Teacher is a subtype of Academic / Academic is a
supertype of Teacher.
Academic is the primary super type of Teacher.
Subtype definition: The subset of Academics who are
Teachers.
Each TeachingProfessor is a Teacher but not every
Teacher is necessarily a TeachingProfessor.
Professor is an entity object type

Professor is primarily identified by the identification
scheme of Academic.
Professor is a subtype of Academic / Academic is a
supertype of Professor.
Academic is the primary super type of Professor.
Subtype definition: The subset of Academics who are
Professors.
Each TeachingProfessor is a Professor but not every
Professor is necessarily a TeachingProfessor.
TeachingProfessor is an entity object type

TeachingProfessor is primarily identified by the
identification scheme of Professor.
TeachingProfessor is a subtype of Teacher and
Professor.
Teacher and Professor are supertypes of
TeachingProfessor.
Professor is the primary super type of
TeachingProfessor.
Subtype definition: The superset of Teachers and
Professors.
____________________________________________________________
____________________________________________________________
Exercise 2
Implementing Set Constraints
In this exercise, you will check the arity of each fact type for sufficient cause in
an ORM model to split the fact type into new elementary fact types by using the
Academic Theme.
scenario.
You are tasked with implementing set constraints in the resultant ORM source
model from the previous exercise. Entity subtype relationships have already
been created in the model. Do not change any of the fact types beyond adding
set constraints.
Each department is headed by a professor who works for that same department.
this practice. Alternatively, use the ImplSubtype_Academic_Answer.vsd ORM
Tasks
1. Examine the Academic works for Department and the Professor heads
Department fact types.
Which role combination represents the largest population domain?
The {Academic, Department} role combination has at least as large a
population domain as the {Professor, Department} role combination.
____________________________________________________________
____________________________________________________________
2. What type of set constraint is indicated by the scenario requirements?

An external subset constraint with two roles.
____________________________________________________________
____________________________________________________________
3. Create a set constraint as indicated by the scenario requirements.

! Validate the entity subtype relationships

2. Select the new set constraint shape on the drawing surface.
What is the text that the Verbalizer displays for the set constraint?
Assuming a is an instance of Professor or Academic then
If Professor a heads Department d then
Academic a works for Department d.
____________________________________________________________
____________________________________________________________
Exercise 3
Implementing Value Constraints
In this exercise, you will reformulate a fact type that needs to be split in an
ORM model into new elementary fact types by using the Academic Theme.
scenario.
You are tasked with implementing set constraints in the resultant ORM source
model from the previous exercise. Entity subtype relationships and set
constraints have already been created in the model. Do not change any of the
fact types beyond adding value constraints.
! Each time that an academic teaches a subject, he or she may receive a rating
on the teaching on a scale of 1 to 7.
! The only allowable rank codes are P, SL, and L.
! The only allowable access level codes are Full and Local.
this practice. Alternatively, use the ImplSet_Academic_Answer.vsd ORM
Tasks
1. Examine the model and the scenario requirements.
Which object types have their domains limited to certain values?
Rating, Rank, and AccessLevel.
____________________________________________________________
____________________________________________________________
2. Create value constraints on object types that restrict their domains to a list of
values, as indicated by the scenario requirements.
3. Create value constraints on object types that restrict their domains to a range
of numeric values, as indicated by the scenario requirements.
! Validate the value constraints

2. On the drawing surface, select the shapes for the object types on which you
placed new value constraints.
What is the relevant text that the Verbalizer displays for the value
constraints?
Rating(Number) is an entity object type.
Every Rating is identified by one distinct Number.
The possible values of 'Number' are: 1 to 7.
Rank(Code) is an entity object type.

Every Rank is identified by one distinct Code.
The possible values of 'Code' are: 'P', 'SL', 'L'.
AccessLevel(Code) is an entity object type.

Every AccessLevel is identified by one distinct Code.
The possible values of 'Code' are: 'Full', 'Local'.
____________________________________________________________
____________________________________________________________
Module 8: Adding
Frequency and Ring
ConstraintsCSDP
Contents
Step 7
Module Overview 1
Lesson: Implementing Frequency
Constraints 2
Lesson: Implementing Ring Constraints 12
Module Review 42
Lab A: Implementing Frequency and
Ring Constraints 44
other countries.
respective owners.
reserved.
Module 8: Adding Frequency and Ring ConstraintsCSDP Step 7 iii
Instructor Notes
(CSDP) step 7. This step covers adding frequency and ring constraints.
30 minutes
Implement frequency constraints.
Implement ring constraints.

Publishers.
iv Module 8: Adding Frequency and Ring ConstraintsCSDP Step 7

In this module, students will learn what value constraints are and how to
identify and apply them to a database model. Then, they will learn what set
constraints are and how to identify and apply them. Next, they will learn to
identify and apply subtyping constraints. Finally, students will apply each of
these constraints to database models with the themes that they are already
familiar with.
Lesson: Implementing Frequency Constraints

lesson.
Reoccurring Domain This topic page covers the broad look at domain values and how students can
Values reuse them within a population without violating any uniqueness requirements
of the domain. Make sure that students understand that a value can be unique in
a domain, but that does not mean that it must be unique in a population.
What Are Frequency This topic page defines and provides the characteristics of frequency
Constraints? constraints. There are examples for each of the characteristics using a common
theme of Person drives Car fact type.
How Frequency This topic page covers how frequency constraints are visually indicated on an
Constraints Are Object Role Modeling (ORM) diagram. Point out that the shape for a frequency
Represented constraint is merely a line above the predicates that it spans, and with a number
over the line to indicate the allowable values of the frequency constraint.
How to Implement This page instructs students on the high-level steps of how to implement
Frequency Constraints frequency constraints.
Frequency procedure by using the Scheduling Theme.
Constraints
Scheduling Theme
Lesson Review
Lesson: Implementing Ring Constraints

lesson.
Object Type This topic page covers the relationships that students can model within a
Intra-Population population. Make sure that students understand that these are not relationships
Relationships between two populations, but rather between segments of a single population.
These relationships can be between two instances of the same value, or two
instances of values within the same set.
Module 8: Adding Frequency and Ring ConstraintsCSDP Step 7 v
What Are Ring This topic page defines and provides the characteristics of ring constraints.
Constraints? Make sure that you cover the high-level descriptions and characteristics, but do
not try to focus on each ring constraint, because they are each covered in detail
on the following pages.
How Ring Constraints This topic page covers how ring constraints are visually indicated on an ORM
Are Symbolized diagram. Point out that the shapes for different types of ring constraints differ
only in the annotation above the ring constraint shape, and that the shape for
ring constraints is identical to that of frequency constraints, without the
annotation.
Irreflexive Ring This topic page defines and describes irreflexive ring constraints. Additionally,
Constraints this page illustrates the constraint with a mathematical equation and a non-
example. Note that iff means if and only if, xRx means the set of X is
related to the set of X, and ~ means not.
Symmetric Ring This topic page defines and describes symmetric ring constraints. Additionally,
example. Note that right arrow means implies that.
Asymmetric Ring This topic page defines and describes asymmetric ring constraints.
Constraints Additionally, this page illustrates the constraint with a mathematical equation
and a non-example.
Antisymmetric Ring This topic page defines and describes antisymmetric ring constraints.
Constraints Additionally, this page illustrates the constraint with a mathematical equation
and a non-example.
Intransitive Ring This topic page defines and describes intransitive ring constraints. Additionally,
example.
Acyclic Ring Constraints This topic page defines and describes acyclic ring constraints. Additionally, this
page illustrates the constraint with a mathematical equation and a non-example.
Valid Ring Constraint Be careful not to place too great an emphasis on this topic. Tell students that
Combinations memorization of this diagram is unimportant; instead, they should be familiar
with it as it relates to the user interface (UI) of Microsoft Visio Enterprise
Architect edition. Students should understand that they will implement ring
constraints by choosing the appropriate area of the diagram in the UI.
How to Implement Ring This page instructs students on the high-level steps of how to implement ring
Constraints constraints.
Ring Constraints procedure by using the Scheduling Theme.
Scheduling Theme
Lesson Review
vi Module 8: Adding Frequency and Ring ConstraintsCSDP Step 7

lesson.
Focus of CSDP Step 7 This topic page covers the grand scheme of CSDP step 7. It is intended to tie
together the main concepts of the previous lessons. Do not spend too much time
on this page, because you will have covered each section in greater detail in
previous lessons.
How to Apply CSDP This topic page is intended as a preview of CSDP step 7. Guide students
Step 7 through each task. Just like in each preceding lesson, this introduction uses the
Theme alone but be available to answer questions.
CSDP Step 7Airline page. Explain why each task was completed in the manner done.
Flights Theme
Note It is especially important to become familiar with the Discussion page
before teaching the class, because the discovery involved will be critical to the
students understanding the content
Lesson Review
ask questions. After answering questions, allow students to discuss openly any
Module Review
topics covered.
Lab A: Implementing Frequency and Ring Constraints

Lab Setup
Lab Results
customization.
Module 8: Adding Frequency and Ring ConstraintsCSDP Step 7 1
Module Overview
! Implementing Frequency Constraints

! Implementing Ring Constraints

Implement frequency constraints.
Implement ring constraints.
2 Module 8: Adding Frequency and Ring ConstraintsCSDP Step 7
Lesson: Implementing Frequency Constraints
! Reoccurring Domain Values

! What Are Frequency Constraints?
! How Frequency Constraints Are Represented
! How to Implement Frequency Constraints
! Practice: Implementing Frequency Constraints
Scheduling Theme

Introduction This lesson discusses how to constrain the frequency of occurrences of
instances in a population.
Lesson purpose Frequency constraints complete the constraints needed to fully model
cardinality at the conceptual level. To model more complex aspects of the
Universe of Discourse (UoD), you can also combine frequency constraints with
ring constraints, which the next lesson presents.
! Implement frequency constraints.
Describe and identify reoccurring domain values.
Describe frequency constraints and their uses.
Reoccurring Domain Values
! Each instance must have an allowable value from the

population domain
! Multiple instances could have the same value
Domain Population
A A
A
B C
C
C
Figure 8.1 A
Introduction You can control domain values, as well as how often they appear in your
model, by using frequency constraints.
Each instance must Remember that instances must have a value listed in the domain of a
have an allowable value population. The instances are unique in the domain of allowable values. You set
from the population these values in CSDP step 6 by using value constraints.
domain
Multiple instances could Although the list of allowable values is unique, it is possible that you could
have the same value assign more than one instance the same value in the population domain.
For example, notice in Figure 8.1 that A and C appear only once in the domain
of allowable values. However, three instances in the population have the
domain value of A, and two have the domain value of C. This is perfectly
acceptable because the instances are reusing the same value, not re-creating it.
What Are Frequency Constraints?
! Definition
Frequency constraints restrict the number of instances in a
population that may share the same domain value
! Characteristics
" Specify the cardinality of a role
" Apply to a role or tuple
" Control the size of the population of a fact type
! Special types of frequency constraints
" Mandatory role
" Uniqueness

Introduction Think of frequency constraints as an answer to the question, How many
instances are possible? You will use frequency constraints to limit the answer
to this question in your model.
Definition Frequency constraints restrict the number of instances in a population that may
share the same domain value. They control how many instances of an object
type can exist that share the same domain value.
Characteristics Frequency constraints have three important characteristics. They:
! Specify the cardinality of a role.
Frequency constraints show the relationship between an instance in an
object types population and the number of instances in a roles population.
The number of times that a domain value can be used in a role is expressed
as an integer number greater than zero or an open or closed range of
integers.
For example, by using the Person drives Car fact type, you can create a
frequency constraint on the role of Car that requires you to record no more
than two different cars for every car in the Car object types population.
! Apply to a role or tuple.
The frequency constraint limits the number of instances in the domain of a
role, or when roles are combined, the occurrences of permutations of values
in a tuple.
For example, by using the Person drives Car to Location fact type, you
can create a frequency constraint on the tuple formed by combining the role
of Car and the role of Location, effectively limiting the number of places
that a person could drive any given car.
! Control the size of the population of a fact type.

Although frequency constraints are placed on roles, they also effectively
control the number of recorded fact instances. When combined with other
constraints, they force the existence of fact instances.
For example, by using the Person drives Car fact type, if you modeled it so
that it was mandatory that every person drives a car and you put a frequency
constraint on it that requires two instances of every person, then the number
of fact instances would be equal to twice the number of instances in the
Person object type.
Note Frequency constraints enforce that the number of occurrences

specified of a given instance exist in a roles population, or that instance is
not in the roles population at all.
Special types of Mandatory role and uniqueness constraints are special types of frequency
frequency constraints constraints.
! Mandatory role
Remember that a mandatory role constraint forces every instance in a
population to participate in a role. This effectively creates a frequency
constraint on that role with a range of one or more occurrences.
! Uniqueness
Remember that a uniqueness constraint prevents duplicate instances in a
role. This effectively creates a frequency constraint on that role, limiting
occurrences of any instance to exactly one.
How Frequency Constraints Are Represented
! FORML expression
Each Person occurs exactly 2 times or not at all.
Each Car, Location combination that occurs,

occurs at least 3 and at most 4 times.
! Graphically Frequency Constraint
2 3..4
Person Location
...drives...to...
Figure 8.2 Car

Introduction Frequency constraints have both a graphical and a Formal Object Role
Modeling Language (FORML) representation in an Object Role Modeling
(ORM) model. Like other constraints, they appear near the predicates on the
drawing surface.
FORML expression The FORML expression of a frequency constraint is an annotation of a fact
type, using either the phrase occurs exactly, or some combination of the
phrases occurs at least and occurs at most.
For example, the following FORML expression represents the fact type in
Figure 8.2 where role populations are constrained such that if a given instance
of a person participates in the fact type, then this person must do so twice. Also,
across all instances of the fact type, the combination of car and location occurs
between three and four times.
Person drives Car to Location
Each Person occurs exactly 2 times or not at all.
Each Car, Location combination that occurs, occurs at least
3 and at most 4 times.
Graphically Frequency constraints are graphically represented by textual annotations above

the role or roles that they constrain. The constrained number of occurrences is
associated with the applicable roles.
How to Implement Frequency Constraints
Select
Select the
thefact
fact type
type
Select
Select the
therole
role or
orroles
roles
Designate
Designatethe
thenumber
numberof
ofoccurrences
occurrencesallowed
allowed
Validate
Validate the
theORM
ORM model
modeland
and your
yourintent
intent

Introduction Create frequency constraints to restrict the number of instances in a population
that may share the same domain value. Remember that they control how many
instances of an object type can exist that share the same domain value.
Procedure Use the following procedure to implement a frequency constraint:
1. Select the fact type.
Remember that frequency constraints that are placed on a role or roles in a
fact type can affect the number of instances in the fact type.
2. Select the role or roles.
The frequency constraint will limit the subset of an object types population
that participates in a role. Most of the time, you will select a single role to
constrain.
3. Designate the number of occurrences allowed.
The number of instances with duplicate values is set to be an exact integer,
or an open or closed range of occurrences.
what you and the domain expert intended, and that the model is error-free.
You should also ensure that the resulting FORML expression matches your
intent and that the data in a meaningful sample population does not violate
the frequency constraint.
Practice: Implementing Frequency ConstraintsScheduling Theme
! Purpose
! Scenario
! Practice
Mon Tue Wed Thu Fri
8 am
Out of Office:
9 00 Doctors Appt
Manager
1:1 All-han
10 00 Quaterl
Team
11 00 Traini
Brownbag Class
12 pm Lunch: ORM
2 00
Data
Modeling
Project
Data
Modeling
Project
Model Model 3 00
4 00
5 00

Introduction In this practice, you will implement a frequency constraint by using the
Purpose The purpose of this practice is to illustrate how to restrict the number of
occurrences of Meeting instances in a role.
scenario.
You have met with the domain expert and are now attempting to implement
frequency constraints to model reoccurring meetings. The domain expert has
! A given meeting reoccurs or does not. If a meeting reoccurs, its
reoccurrences are stored.
! Reoccurrences of a given meeting are based on one common meeting.
! The first reoccurrence stored is always the original meeting.
! For meetings that reoccur, there will always be at least two reoccurrences.
! Select the fact type

1. Open and review the ImplFreq_Scheduling.vsd ORM source model.
According to the scenario, on which fact type should you place a frequency
constraint?
Meeting is a reoccurrence of Meeting.
____________________________________________________________
____________________________________________________________
2. On the drawing surface, right-click the predicate shape for the Meeting is a
reoccurrence of Meeting fact type, and then click Add Constraints.
! Select the role or roles

1. Review the scenario requirements relating to the roles that should have
frequency constraints.
What kind of frequency constraint should be on the first Meeting role of the
Meeting is a reoccurrence of Meeting fact type?
The first roles population should be limited to a single occurrence of
each domain value. This is already enforced by a simple uniqueness
constraint over this role.
____________________________________________________________
____________________________________________________________
What kind of frequency constraint should be on the second Meeting role of

the Meeting is a reoccurrence of Meeting fact type?
The second roles population should be constrained to require at least
two occurrences of each domain value.
____________________________________________________________
____________________________________________________________
2. In the Add Constraint window, in the Constraint type box, select

Frequency.
each role in the constraint, on the predicate shape for the [Meeting] is a
reoccurrence of [Meeting] fact type, click the second role box.
! Designate the number of occurrences allowed

In the Add Constraint window, in the Minimum (1 or more) box, type 2
and delete any value in the Maximum (blank=no max) box. Then click
OK.

On the Database menu, click Model Error Check. In the Output window,
! Validate your intent by using the Verbalizer

1. On the drawing surface, select the predicate shape for the Meeting is a
reoccurrence of Meeting fact type.
Meeting is a reocurrence of Meeting
Each Meeting is a reocurrence of at most one Meeting.
Each Meeting m that occurs in
Meeting is a reocurrence of Meeting m
occurs there at least 2 times.
Lesson Review
Objectives
Objectives
Implement
Implement frequency
frequency constraints
constraints
Describe
Describe and
and identify
identify reoccurring
reoccurring domain
domain
values
values
Describe
Describe frequency
constraints and
and their
their uses
uses

1. Describe a reoccurring domain value.
A reoccurring domain value is a value that is defined in a populations
domain and is reused through instances of a given population.
2. Describe frequency constraints and their uses.

Frequency constraints are constraints placed on roles in an ORM
model that control or limit the number of duplicate domain values in
instances of the roles population.
Lesson: Implementing Ring Constraints
! Object Type Intra-Population Relationships

! What Are Ring Constraints?
! How Ring Constraints Are Symbolized
! Irreflexive Ring Constraints
! Symmetric Ring Constraints
! Asymmetric Ring Constraints
! Antisymmetric Ring Constraints
! Intransitive Ring Constraints
! Acyclic Ring Constraints
! Valid Ring Constraint Combinations
! How to Implement Ring Constraints
! Practice: Implementing Ring ConstraintsScheduling Theme

Introduction This lesson covers the use of ring constraints to control relationship instances
within a population.
Lesson purpose This is the last of the constraints used in the CSDP process. Use ring constraints
to model the most complex of all requirements within the UoD.
! Implement ring constraints.
Describe and identify intra-set relationships.
Describe ring constraints and their uses.
Object Type Intra-Population Relationships
! Instances of a single object type

! Related groups of instances
" Circularly related groups
" Hierarchically related groups
" Set relationships between groups

Introduction Until this point, the course has focused on relationships in ORM between two
or more different object types. Relationships in the UoD that are between
populations of the same object type may exist, though, as well.
Instances of a single Remember that all of the instances of an object type that play a role in a fact
object type type represent a subset of the object types population. If the object type plays
more than one role in a fact type, each role has a separate subset population.
Related groups of Remember that a fact type instance is represented by a tuple. Chains of tuples
instances can be related in that an instance in one role of a tuple appears in a different role
in another tuple. Tuples can be grouped together so that they exhibit special
relationships, such as:
! Circularly related groups
Tuples may be related together through shared instances. The relationships
between tuples may form a circular path or loop.
For example, a batting lineup in baseball represents a circular loop of
relationships. After all players have batted in order, the lineup starts over
again at the top of the list.
! Hierarchically related groups
There is a parent-child relationship where an instance in the child role could
also play the role of a parent of other children.
For example, an organization chart represents hierarchical relationships
between departments and employees of a company.
! Set relationships between groups
Remember that set constraints limit the segments of an object types
population that can participate in two different fact types. In the same
manner, two different segments of the same object types population may
have a set-based relationship when participating in the same fact type.
For example, in a family tree, individuals are often grouped in generations.
Each generation has a relationship with the generation before and after it.
What Are Ring Constraints?
! Definition
Ring constraints control the population of an object types
roles when the object type has two roles in a fact type
! Characteristics
" Common object type
" Recursively related role populations
" Strong constraint
" Six different types

Introduction Normally, an object type plays just one role in a fact type. When two roles in a
fact type are played by the same object type, the path from the object type
through the role pair, and back to the object type, forms a ring.
Definition Ring constraints control the population of an object types roles when the object
type has two roles in a single fact type.
Characteristics Ring constraints have three important characteristics:
! Common object type
Remember that the population of the role is equal to or a subset of an object
types population. The roles spanned by a ring constraint all represent a
common object type.
! Recursively related role populations
Fact types are created to capture the relationship between populations of
object types. If an object type is used twice in a single fact type, the objects
roles represent two object type populations that may or may not overlap.
! Strong constraint
Because ring constraints are applied at the end of the CSDP process, they
combine with other types of constraints to have a strong cumulative effect.
Ring constraints will always interact with uniqueness constraints.
! Six different types
There are six types of ring constraints: irreflexive, symmetric, asymmetric,
antisymmetric, intransitive, and acyclic. You can combine some of these six
types in certain ways to form more restrictive constraints.
How Ring Constraints Are Symbolized
Ring
Ring Ring
Ring
Constraint
Constraint Constraint
Constraint
Ring
Ring
Constraint
Constraint
Figure 8.5
11 2 33

Introduction The different types of ring constraints are all symbolized in a similar manner.
How symbolized Ring constraint shapes augment existing predicate shapes in ORM.
Table 8.1
Ring constraint type

A ring constraint is symbolized by a
connecting bar above the two roles that are
constrained.
The connecting bar is annotated with a degree .
sign, followed by a two-letter abbreviation for
the type of ring constraint.
Note that the role shapes in the predicate are
not part of the ring constraint symbol.
The abbreviations used in the annotation are listed in Table 8.2.

Table 8.2
Ring constraint type Abbreviation
Irreflexive ir
Symmetric sym
Asymmetric as
Antisymmetric ans
Intransitive it
Acyclic ac
Examples The diagrams in Figures 8.3, 8.4, and 8.5 are all intentionally generic so that
they do not imply a particular type of ring constraint. Figure 8.3 shows a ring
constraint over a simple binary fact type. Figure 8.4 shows a ring constraint
over two roles in a ternary fact type. Figure 8.5 shows a ring constraint over the
roles in a binary fact type whose objects are both subtypes of common
supertypes.
Caution The shape for a ring constraint is similar to the shape for a frequency
constraint that spans two roles. Graphically, they differ only in how they are
annotated.
Irreflexive Ring Constraints
! Purpose No
Noinstance
instanceisisrelated
relatedto
toitself.
itself.
! Non-example data
xx yy
AA Figure 8.XBB Figure 8.6
BB DD
CC BB ! Mathematical expression
DD EE R is irreflexive iff
Constraint
Constraint
Violation!
Violation! AA AA for all x
Table 8.3 ~ xRx
11 2 33

Introduction Irreflexive ring constraints are the simplest ring constraints.
Purpose The purpose of an irreflexive (ir) ring constraint is to prevent an instance from
being related to itself.
Mathematical If the roles in an irreflexive ring constraint are referenced by the populations X
expression and Y that are subsets of a common object types population, you can represent
an irreflexive ring constraint by using the mathematical expression of:
A relationship is irreflexive if and only if (iff) for all of X, a relationship exists
between X and Y such that no tuple (X,Y) is equal to the tuple (X,X).
Non-example data If an irreflexive ring constraint was in place over the populations of X and Y in
Table 8.3, the fifth row would violate the constraint. The instance A in
population X is the same instance in population Y.
Table 8.3
Population X Population Y
A B
B D
C B
D E
A A
FORML expression The FORML expression for an irreflexive (ir) ring constraint is:
No Object is related to itself.
Symmetric Ring Constraints
! Purpose Musthave
Must
Must havemirror
have mirrorimages
mirror image
images
! Non-example data
xx yy
AA Figure 8.XAA Figure 8.7
AA BB
BB BB ! Mathematical expression
BB AA R is symmetric iff
Constraint
Constraint
Violation!
Violation! AA CC for all x, y
Table 8.4 xRy ! yRx
11 2 33

Introduction Symmetric ring constraints enforce the existence of complementary tuples in a
population. A symmetric ring constraint generally requires that either two
specially related rows are inserted into a database or none at all. Reflexive
relationships are allowed.
Purpose The purpose of a symmetric (sym) ring constraint is to ensure that a mirror
image of every tuple exists in the fact types population.
Mathematical If the roles in a symmetric ring constraint are referenced by the populations X
a symmetric ring constraint by using the mathematical expression of:
A relationship is symmetric if and only if for all of X and Y, a relationship
exists between X and Y that implies a tuple (Y,X) exists for every tuple (X,Y).
Non-example data If a symmetric ring constraint was in place over the populations of X and Y in
Table 8.4, then the fifth row would violate the constraint. The mirror opposite
of the tuple (A,C) in the fifth row does not exist in any other row in the table.
Table 8.4
A A
A B
B B
B A
A C
FORML expression The FORML expression for a symmetric (sym) ring constraint is:
If Object o1 is related to Object o2
then Object o2 is related to Object o1.
Asymmetric Ring Constraints
! Purpose No
Noopposites
opposites
! Non-example data
xx yy
BB CC
AA AA ! Mathematical expression
CC DD R is asymmetric iff
Constraint
Constraint
Violation!
Violation! BB AA for all x, y
Table 8.5 xRy ! ~yRx
11 2 33

Introduction Asymmetric ring constraints prevent the existence of complementary tuples in a
population. An asymmetric ring constraint prevents the insertion of a tuple into
a database if a tuple with the mirror image of that tuple already exists. Reflexive
relationships are allowed.
Purpose The purpose of an asymmetric (as) ring constraint is to ensure that no mirror
images of any tuple exist in the fact types population.
Mathematical If the roles in an asymmetric ring constraint are referenced by the populations X
an asymmetric ring constraint by using the mathematical expression of:
A relationship is asymmetric if and only if for all of X and Y, a relationship
exists between X and Y that implies for every tuple (X,Y), no tuple (Y,X)
exists.
Non-example data If an asymmetric ring constraint was in place over the populations of X and Y,
the fifth row of Table 8.5 would violate the constraint. The tuple (B,A) in the
fifth row is the mirror image of the tuple (A,B) in the first row.
Table 8.5
A B
B C
A A
C D
B A
FORML expression The FORML expression for an asymmetric (as) ring constraint is:
then it cannot be that
Object o2 is related to Object o1.
Antisymmetric Ring Constraints
! Purpose No
Noopposites
oppositesor
ormirror
mirrorimages
images
! Non-example data
xx yy
BB CC
Constraint
Constraint
Violation!
Violation! AA AA ! Mathematical expression
CC DD R is antisymmetric iff
Constraint
Constraint
Violation!
Violation! BB AA for all x, y
Table 8.6 x =/ y & xRy ! ~yRx
11 2 33

Introduction Antisymmetric ring constraints prevent the existence of both complimentary
and reflexive tuples in a population. An antisymmetric ring constraint is the
combination of an asymmetric and an irreflexive ring constraint.
Purpose The purpose of an antisymmetric (ans) ring constraint is to ensure that no
mirror images of any tuple exist in the fact types population, and that no
instance is related to itself.
Mathematical If the roles in an antisymmetric ring constraint are referenced by the
expression populations X and Y that are subsets of a common object types population, you
can represent an antisymmetric ring constraint by using the mathematical
expression of:
A relationship is antisymmetric if and only if for all of X and Y, relationship
exists between X and Y that implies for every tuple (X,Y), no tuple (Y,X)
exists, and no tuple (X,Y) is equal to the tuple (X,X).
Non-example data If an antisymmetric ring constraint was in place over the populations of X and
Y, the fifth row of Table 8.6 would violate the constraint. The tuple (B,A) in
the fifth row is the mirror image of the tuple (A,B) in the first row. The tuple
(A,A) in the third row also violates the constraint because it is reflexive.
Table 8.6
A B
B C
A A
C D
B A
FORML expression The FORML expression for an antisymmetric (ans) ring constraint is:
and o1 is not the same Object as o2, then it cannot be that
Intransitive Ring Constraints
! Purpose You
Youcannot
cannotskip
skipaageneration
generation
! Non-example data
xx yy
BB CC
CC DD ! Mathematical expression
DD EE R is intransitive iff
Constraint
Constraint
Violation!
Violation! AA EE for all x, y, z
Table 8.7 xRy & yRz ! ~xRz
11 2 33

Introduction Intransitive ring constraints prevent an instance from having more than one
parent in a hierarchy.
Purpose The purpose of intransitive (it) ring constraints is to enforce hierarchical
relationships between instances in a population.
Mathematical If the roles in an intransitive ring constraint are referenced by the populations X
an intransitive ring constraint by using the mathematical expression of:
A relationship is intransitive if and only if for every path through the
hierarchical relationship between X, Y, and Z, the existence of tuples (X,Y) and
(Y,Z) implies that no tuple (X,Z) exists.
Non-example data If an intransitive ring constraint was in place over the populations of X and Y,
the fifth row of Table 8.7 would violate the constraint. There is a path from
instance A to instance E through the tuples (A,B), (B,C), (C,D), and (D,E). The
constraint is violated because there is also a path from A to E in the tuple (A,E).
Table 8.7
A B
B C
C D
D E
A E
FORML expression The FORML expression for an intransitive (it) ring constraint is:
and Object o2 is related to Object o3
then it cannot be that
Acyclic Ring Constraints
! Purpose No
Noancestor
ancestorisisaadescendant
descendant
! Non-example data
xx yy
BB DD
CC EE ! Mathematical expression
DD FF R is acyclic iff
Constraint
Constraint
Violation!
Violation! FF AA for all x, y, z
Table 8.8 xRy & yRz ! ~zRx
11 2 33

Introduction Acyclic ring constraints prevent instance recursion.
Purpose The purpose of acyclic (ac) ring constraints is to prevent a path from looping
back on itself through a chain of relationships.
Mathematical If the roles in an acyclic ring constraint are referenced by the populations X and
expression Y that are subsets of a common object types population, you can represent an
intransitive ring constraint by using the mathematical expression of:
A relationship is acyclic if and only if for every path through the hierarchical
relationship between X, Y, and Z, the existence of tuples (X,Y) and (Y, Z)
implies that no tuple (Z,X) exists.
Non-example data If an acyclic ring constraint was in place over the populations of X and Y, the
fifth row of Table 8.8 would violate the constraint. There is a path from
instance A to instance F through the tuples (A,B), (B,D), (D,F). The constraint
is violated because the path continues though tuple (F,A) to form a loop back to
instance A.
Table 8.8
A B
B D
C E
D F
F A
FORML expression The FORML expression for an acyclic (ac) ring constraint is:
A Object cannot cycle back to itself through one or more
applications of the relationship:
Object is related to Object.
Valid Ring Constraint Combinations
o o o
ans ir sym
oas
oit
o
ac
Figure 8.12

Introduction Due to the nature of the different types of ring constraints, you can apply only
certain combinations with validity, as noted in Table 8.9.
Valid ring constraint Figure 8.12 shows an Euler diagram that illustrates the valid combinations of
combinations ring constraints. The intersecting regions of the diagram represent valid
combinations, showing how some ring constraints encompass others, and how
some are in conflict with one another.
Note Ring constraints can sometimes combine with uniqueness constraints to

the same modeling effect. Microsoft Visio Enterprise Architect edition will
issue a warning when this occurs when checking the ORM model for errors.
Table 8.9
Combination Abbreviation Combined effect
Acyclic + ac, it This forces that a hierarchical path is observed and

intransitive that the path does not loop back on itself.
Asymmetric + as, it This forces that a hierarchical path is observed and
intransitive that there are no opposites.
Intransitive + it, sym This forces that a hierarchical path is observed and
symmetric that there must be a mirror image.
Irreflexive + ir, sym This forces that no instance is related to itself and
Symmetric there must be a mirror image.
Tip To better understand Figure 8.12, picture it as a dart board. When a dart is
thrown, the circle or circles that it lands in define its properties. This may be
only one constraint, a combination, or none at all.
How to Implement Ring Constraints
Identify
Identifyaafact
fact type
typewith
withthe
thesame
same object
objecttype
typein
in two
two
roles
roles
Select
Select constraint
constraint role
roleorder
order
Select
Select aavalid
valid combination
combinationof
of ring
ring constraint
constraint types
types
Validate
Validate the
theORM
ORM model
modeland
and your
yourintent
intent

Introduction Create ring constraints to control the population of an object types roles when
the object type has two roles in a single fact type.
Procedure Use the following procedure to implement a ring constraint:
1. Identify a fact type with the same object type in two roles.
Remember that ring constraints restrict a fact type that has the same object
type in two different roles. Because of this, the fact type is often more
complex than others. Ensure that the fact type is appropriate for the UoD
and not incorrectly modeled.
2. Select constraint role order.
Remember that ring constraints restrict how one subset of a population is
related to another subset. The role order designates which role population
constrains the other one.
Warning Although the role order to express a fact type is immaterial, it is

critically important in the application of ring constraints. Varying the role
order in a ring constraint may drastically change the meaning or effect of the
constraint.
3. Select a valid combination of ring constraint types.

After you select the constraint role order, use the Euler diagram illustrated
in Figure 8.12 to select a valid combination of ring constraint types. Visio
uses this diagram in the user interface (UI) to aid selection.
You should always use the Verbalizer to generate a FORML expression to
validate your intent, but the FORML expressions for ring constraints can be
confusing to the domain expert. To compensate, rely on meaningful sample
data to validate that the ring constraints are not violated.
Practice: Implementing Ring ConstraintsScheduling Theme
! Purpose
! Scenario
! Practice
Mon Tue Wed Thu Fri
8 am
Out of Office:
9 00 Doctors Appt
Manager
1:1 All-han
10 00 Quaterl
Team
11 00 Traini
Brownbag Class
12 pm Lunch: ORM
2 00
Data
Modeling
Project
Data
Modeling
Project
Model Model 3 00
4 00
5 00

Introduction In this practice, you will implement a ring constraint by using the Scheduling
Purpose The purpose of this practice is to illustrate how to implement a ring constraint
that prevents reoccurring meetings from looping back on themselves and limits
each reoccurring child meeting to a single parent meeting.
scenario.
You have met with the domain expert and are now attempting to implement
ring constraints. The domain expert has provided you with the following
information:
! Reoccurrences of a given meeting are based on one common meeting.
! The first reoccurrence stored is always the original meeting.
! A reoccurrence cannot have other reoccurrences.
! Identify a fact type with the same object type in two roles
1. Open and review the ImplRing_Scheduling.vsd ORM source model.
According to the scenario, on which fact type should you place a ring
constraint?
____________________________________________________________
____________________________________________________________
2. On the drawing surface, right-click the predicate shape for Meeting is a

reoccurrence of Meeting, and then click Add Constraints.
3. In the Add Constraint window, in the Constraint type box, select Ring.
! Select constraint role order

In the Add Constraint window, in the pane entitled Select the role box of
each role in the constraint, on the predicate shape for the [Meeting] is a
reoccurrence of [Meeting] fact type, select the second role box, and then
the first.
The Ring Constraint dialog box appears.
! Select a valid combination of ring constraint types

1. Review the scenario and the model.
Which type of ring constraint prevents a chain of relationships from looping
back on itself?
Acyclic.
____________________________________________________________
____________________________________________________________
Which type of ring constraint prevents a descendent from having more than
one ancestor?
Intransitive.
____________________________________________________________
____________________________________________________________
2. In the Ring Constraint Properties window, in the Ring Type box, select
Acyclic + Intransitive, and then click OK twice.
3. On the Database menu, click Model Error Check, and then examine the
contents of the Output window.
What ring constraint validation error do you receive?
Error C2042: RC:it,ac (Meeting is a reoccurrence of Meeting) :
Intransitive constraint is implied by a simple uniqueness constraint on
the predicate.
____________________________________________________________
____________________________________________________________
4. On the drawing surface, double-click the abbreviation for the ring constraint
on the Meeting is a reoccurrence of Meeting fact type.
5. In the Database Properties window, in the Ring Type list, select Acylic.

2. On the drawing surface, select the ring constraint shape and the uniqueness
constraint that are on the Meeting is a reoccurrence of Meeting fact type.
in the Verbalizer window.
Each Meeting is a reoccurrence of at most one Meeting.
A Meeting cannot cycle back to itself through one or more
applications of the relationship:
Lesson Review
Objectives
Objectives
Implement
Implement ring
ring constraints
constraints
Describe
Describeand
and identify
identify intra-population
intra-population relationships
relationships
Describe
Describering
ring constraints
constraints and
and their
their uses
uses

1. Describe intra-population relationships.
Relationships in the UoD that are between populations of the same
object type are called intra-population relationships.
2. Define ring constraints.

Ring constraints control the population of an object types roles when
the object type has two roles in a single fact type.

Theme

Introduction In this lesson, you will apply CSDP step 7 to assess your understanding of the
previous lessons.
relating to frequency and ring constraints to implement CSDP step 7.
CSDP step 7: Add other constraints and perform final

checks
" Reoccurring domain values
" Cardinality
" Intra-population relationships
" Other constraints

Introduction CSDP step 7 is the last of step of the Conceptual Schema Design Procedure.
Completion of the CSDP steps in order should provide you with a sound
conceptual model.
CSDP step 7 Add other constraints and perform final checks.
Reoccurring domain Frequency constraints restrict the number of reoccurring values represented by
values the model, and indirectly, the size of a database. Ask the domain expert the
questions necessary to restrict the population of the data.
Cardinality You can now fully model the concept of cardinality in ORM by combining the
use of mandatory role constraints and frequency constraints. Remember that
uniqueness constraints are a special form of frequency constraints that restrict
the population of an object type to contain no more than a single occurrence of
each of its domain values.
Tip You can use functionality on the Constraints tab of the Fact Editor to
simultaneously create mandatory role constraints, uniqueness constraints, and
frequency constraints.
Intra-population Most of the modeling constructs in ORM relate to relationships between

relationships different object types populations. Ring constraints extend the usefulness of set
constraints in restricting intra-population relationships.
Other constraints Other types of constraints exist in the UoD that are not readily modeled in an
ORM diagram by using the Visio data modeling tools. Most of these constraints
are procedurally based, not fact based. From an academic point of view, CSDP
step 7 addresses uncommon constraints other than the ones presented in this
module.
Implement
Implementfrequency
frequencyconstraints
constraints
Implement
Implementring
ring constraints
constraints
Validate
Validate the
theORM
ORM model
modeland
and your
yourintent
intent
Consider
Consideriteratively
iterativelyapplying
applying CSDP
CSDPsteps
steps1-7
1-7

Introduction Use the high-level procedures on this page to apply CSDP step 7.
Procedure To apply CSDP step 7:
1. Implement frequency constraints.
Use a frequency constraint not only to its own end, but also to restrict the
applicability of ring constraints.
2. Implement ring constraints.
Ring constraints allow you to capture complex modeling concepts that are
not otherwise easily captured.
Use the Verbalizer and meaningful sample data to verify that you have
captured the domain experts understanding of the UoD. Complex
frequency constraints and ring constraints are not always readily evident in
the UoD or through conversation with the domain expert.
4. Consider iteratively applying CSDP steps 1-7.
The application of each of the CSDP steps frequently entails changes to the
model as you go. You should always consider revisiting all steps iteratively
to refine and improve the model until you are sure that you have created an
accurate conceptual model of the UoD.
! Purpose
! Scenario
! Practice
London
UK11
(LHR)
US72
IT37
New York
Madrid Rome
(JFK)
ES2 (MAD) (FCO
Atlanta 3 US62 )
VE56
Starting (ATL)
US6
VE59
Dakar
VE56
Model
8 (DKR)
Caracas
(CCS)

Purpose The purpose of this practice is to illustrate how to constrain the Flight travels
between Airport to Airport fact types roles so that the number of occurrences
of a given Flight and a given (Airport, Airport) role tuple are restricted. Also,
it is important to prevent the same Airport object type instance from appearing
in two roles of the same fact instance.
scenario.
You are tasked with modeling elements of the current state of a group of airline
flights. You have met with the domain expert and are now attempting to
implement frequency and ring constraints. The domain expert has provided you
! A segment is the travel path between an origination airport and a destination
airport. A given flight may not have more than three segments.
! Multiple flights may travel the same segments, but for a given airport, a
maximum of five flights that use the same segment are allowed.
! A given flight may not take off from and land at the same airport nor revisit
any airport that it has already visited.
! Implement frequency constraints

Which roles represent a flight segment, as described in the scenario?
The two Airport roles
____________________________________________________________
____________________________________________________________
What are the role names for each of the Airport roles?
Outbound Airport and Inbound Airport
____________________________________________________________
____________________________________________________________
What is the effect of the uniqueness constraint over the first two roles?
If a flight has multiple segments, it can take off from a given airport
only once.
____________________________________________________________
____________________________________________________________
What is the effect of the uniqueness constraint over the first and third roles?
If a flight has multiple segments, it can land at a given airport only
once.
____________________________________________________________
____________________________________________________________
What is the combined effect of the two uniqueness constraints?

A given flight cannot have duplicate segments.
____________________________________________________________
____________________________________________________________
2. Create a frequency constraint over the Flight role, as indicated by the

scenario.
3. Create a frequency constraint over the Airport roles, as indicated by the
scenario.
! Implement ring constraints

Create a ring constraint across the Airport roles, as indicated by the
scenario.

On the Database menu, click Model Error Check. In the Output window,
! Validate your intent by using the Verbalizer

1. On the drawing surface, select the predicate shape for the Flight travels
between Airport to Airport fact type.
Flight travels between Airport to Airport
Given any Flight and Airport
that Flight travels between at most one Airport to
that Airport.
Given any Flight and Airport
that Flight travels between that Airport to at most
one Airport.
Each Flight occurs at most 3 times or not at all.
Each Airport a1, Airport a2 combination that occurs in
Flight travels between Airport a1 to Airport a2
occurs there at most 5 times.
Some Flight travels between no Airport to itself.
! Consider iteratively applying CSDP steps 1-7

Review the scenario requirements and think about the other Airport Flights
Theme scenarios in this course.
What types of things would cause you to consider iteratively applying
CSDP steps 1-7 to the theme?
A better understanding of UoD and the meaningful same data that
represents it.
The formation of new object types and relationships to accommodate
CSDP steps, such as primitive entity types, splitting of fact types, and
the creating of subtypes.
Application of globally impacting constraints, such as mandatory role
constraints and logically derivable fact types.
____________________________________________________________
____________________________________________________________

! Consider iteratively applying CSDP
steps 1-7
London
UK11
(LHR)
US72
IT37
New York
Madrid Rome
(JFK)
ES2 (MAD) (FCO
Atlanta 3 US62 )
VE56
(ATL)
Solution US6
8
VE59
VE56
Dakar
(DKR)
Model Caracas
(CCS)

Discussion The purpose of the practice was to illustrate how to constrain the Flight travels
between Airport to Airport fact types roles so that the number of occurrences
of a given Flight and a given (Airport, Airport) role tuple were restricted.
Also, it was important to prevent the same Airport object type instance from
appearing in two roles of the same fact instance.
Implement frequency You should have created a frequency constraint on the Flight role of the Flight
constraints travels between Airport to Airport fact type that limits the number of Flight
instances to no more than three. You also should have created a frequency
constraint across the (Airport, Airport) role tuple that limits the number of
tuple instances to no more than five.
Remember that each flight could have multiple segments (airports from which
it takes off and at which it lands). Every time that a fact instance is recorded for
a given segment, the Flight instance value will be duplicated. The frequency
constraint on the Flight role effectively limits the number of flight segments by
limiting the number of Flight instances.
The frequency constraint over the combination of these roles limits the number
of times that a segment can be recorded, independent of which Flight is
associated with a given segment. This effectively limits the number of outbound
destinations and inbound originations for a given airport to five each.
The uniqueness constraint that spans the Flight and origination Airport roles
prevents a given flight from taking off from the same airport twice. The
uniqueness constraint that spans the Flight and termination Airport roles
prevents a given flight from landing at the same airport twice.
Implement ring You should have created an irreflexive ring constraint across the Airport roles
constraints in the Flight travels between Airport to Airport fact type that prevents the
same instance of Airport from appearing in both Airport roles at the same
time.
With respect to the scenario, the irreflexive ring constraint prevents a flight
from taking off and landing at the same airport on the same segment.
When combined with the two uniqueness constraints on the fact type, the
irreflexive ring constraint effectively prevents a flight from revisiting an airport
to which it has already been on any segment.
Validate the ORM model The need for the frequency constraints was indicated in the scenario
and your intent requirements that called for limiting the number of times a domain value could
be used, as indicated by:
! A segment is the travel path between an origination airport and a destination
airport. A given flight may not have more than two segments.
! Multiple flights may travel the same segments, but for a given airport, a
maximum of five flights that use the same segment are allowed.
The scenario requirements that called for a ring constraint was indicated by the
scenario requirement:
! A flight may not take off from and land at the same airport.
requirements of the scenario were met.
Consider iteratively The CSDP should be applied iteratively to discover and refine an effective
applying CSDP steps 1-7 ORM model until you are satisfied that the model appropriately captures all
aspects of the UoD.
Important Because this course uses variations on different modeling themes to

illustrate specific concepts and because this particular lesson uses a limited,
focused variation on the Airline Flights Theme, you cannot meaningfully revisit
CSDP steps 1-7 in this lesson.
Lesson Review
Objectives
Objectives
Apply
Apply CSDP
CSDP step
step 77
Implement
Implementfrequency
constraints
Implement
Implementring
ring constraints
constraints

1. What other types of constraints are not covered by the material in this
course?
Most of the other constraints are procedurally based, not fact based.
These are the constraints that should be added in later iterations of the
database model.
2. At what point can you be sure you have an accurate and adequate
conceptual model?
The application of each of the CSDP steps frequently entails changes to
the model as you go. You should always consider revisiting all steps
iteratively to refine and improve the model until you are sure that you
have created an accurate conceptual model of the UoD.
Module Review
! Implementing Frequency Constraints

! Implementing Ring Constraints

1. Can multiple instances of a population domain have the same value?
In a population domain, the list of allowable values is unique; however,
it is possible to assign more than one instance of the same value from
the population domain.
2. Do you apply frequency constraints to a role or a tuple?

Both, sometimes. The frequency constraint limits the number of
instances in the domain of a role, or when roles are combined, the
occurrences of permutations of values in a tuple.
3. What two other constraints are actually special types of frequency

constraints?
Uniqueness and mandatory. A uniqueness constraint prevents duplicate
instances in a role. This effectively creates a frequency constraint on
that role, limiting occurrences of any instance to exactly one. A
mandatory role constraint forces every instance in a population to
participate in a role. This effectively creates a frequency constraint on
that role with a range of one or more occurrences.
4. What three relationships among groups deal primarily with ring constraints?
Circularly related groups, hierarchically related groups, and set
relationships between groups.
5. How are frequency and ring constraints symbolized?

Frequency and ring constraints are symbolized by a connecting bar
above the two roles that are constrained, with the appropriate
annotation designating frequency or ring.
Lab A: Implementing Frequency and Ring Constraints
! Exercise 1: Implementing Frequency

Constraints
! Exercise 2: Implementing Ring Constraints

Introduction This lab will reinforce your understanding of CSDP step 7, as well as the skills

! Have completed the CSDP steps 1 though 6.
! Be able to implement frequency constraints.
! Be able to implement ring constraints.
faculty of a college and departmental budget information.
folder.
Estimated time to
complete this lab:
30 minutes
Exercise 0
Lab Setup
box.
5. Click OK.
Exercise 1
Implementing Frequency Constraints
In this exercise, you will implement frequency constraints by using the
Academic Theme.
scenario.
You are tasked with implementing frequency constraints in an ORM source
model. In this exercise, do not change any of the fact types other than adding
the frequency constraints.
! Every teacher is audited two or three times.
! A given professor that teaches is not allowed to serve on more than four
committees.
Tasks
2. Create a frequency constraint over the appropriate roles, as indicated by the
scenario.
! Validate the frequency constraints

2. Select all of the frequency constraint shapes on the drawing surface.
What is the text that the Verbalizer displays for frequency constraints?
Each Teacher t that occurs in
Teacher t is audited by Teacher
occurs there at least 2 and at most 3 times.
Each TeachingProfessor that occurs in

TeachingProfessor serves on Committee
occurs there at most 4 times.
____________________________________________________________
____________________________________________________________
Exercise 2
Implementing Ring Constraints
In this exercise, you will implement ring constraints in an ORM model by using
the Academic Theme.
scenario.
You are tasked with implementing a ring constraint in the resultant ORM
source model from the previous exercise. Frequency constraints have already
been created in the model. Do not change any of the fact types beyond adding
ring constraints.
! Teachers cannot audit themselves.
! Teachers cannot audit teachers who have already audited them.
this practice. Alternatively, use the ImplFreq_Academic_Answer.vsd ORM
Tasks
1. Examine the Teacher is audited by Teacher fact type.
2. Create a ring constraint over the appropriate roles, as indicated by the
scenario.
What type of ring constraint should you have created?
Antisymmetric, which prevents mirror images and opposites.
____________________________________________________________
____________________________________________________________
! Validate the mandatory role constraints

2. Select all of the frequency constraint shapes on the drawing surface.
What is the text that the Verbalizer displays for frequency constraints?
If Teacher t1 is audited by Teacher t2
and t1 is not the same Teacher as t2, then it cannot be
that
Teacher t2 is audited by Teacher t1.
____________________________________________________________
____________________________________________________________
Module 9: Generating a
Relational Logical
Model
Contents
Module Overview 1
Lesson: Understanding Relational Logical
Models 2
Lesson: Understanding Normalization 10
Lesson: Generating a Relational Logical
Model 22
Module Review 30
Lab A: Generating a Relational Logical
Model 31
Course Evaluation 34
other countries.
respective owners.
reserved.
Module 9: Generating a Relational Logical Model iii
Instructor Notes
45 minutes create relational logical models.
30 minutes
! Generate a relational logical model.
Describe a relational logical model.
Describe normalization.

! If possible, review and reference Chapters 8 and 10 of Information
iv Module 9: Generating a Relational Logical Model

Lesson: Understanding Relational Logical Models
lesson.
What Are Relational This topic page defines and describes relational logical models, their uses, and
Logical Models? where they fit in the baseline database design process. Dont spend time
debating the difference between relational logical model diagrams and ER
diagrams. If students ask, say that one difference is that the relational logical
models that Microsoft Visio Enterprise Architect edition generates during the
build process will create the subtype tables rather than using the ER subtype
notation.
How Tables and This topic page describes how tables and columns are symbolized in a relational
Columns Are logical model. At this level, students are looking at the actual logical model for
Symbolized the database.
What Are Relationships? This topic page defines and describes relationships in a relational logical model.
Make sure that students understand that relationships in a relational logical
model are similar to, but ultimately different from, relationships in Object Role
Modeling (ORM).
How Relationships Are This topic page describes how relationships are symbolized in a relational
Symbolized logical model.
Lesson Review
Lesson: Understanding Normalization

lesson. This lesson covers the definitions and benefits of normalization and
denormalization.
What is Normalization? This content is for familiarization only. Students dont actually have to
understand normalization to complete this course; however, it is good
background material. Dont spend too much time here.
Module 9: Generating a Relational Logical Model v
What Is First Normal This topic page defines and describes First Normal Form. The example consists
Form? of an excerpt for a fictitious order entry system. During the discussion you may
use the following nonexamples to further explain First Normal Form.
If the Customer table contained a column called ContactInformation that
holds the customer's first name, last name, and phone number, this would
violate the one type of information and single value clauses of 1NF.
Additionally, if the Customer table contained a single column called Orders
that contained the order ID number for each order that a customer places,
delineated in some fashion, this would be a multi-valued column and would
violate the single value clause of 1NF.
Finally, if the table contained multiple columns for order ID numbers, such as
Order1, Order2, and Order3, each one containing the OrderID key for each
order placed, that would violate the repeating groups clause of 1NF.
What Is Second Normal This topic page defines and describes Second Normal Form. The order entry
Form? system example now contains an Order and an OrderDetail table, similar to
the tables in Northwind.
What Is Third Normal This topic page defines and describes Third Normal Form. It continues using
Form? the order entry example and adds a Sales table.
Benefits of This topic page describes the major benefits of normalization. Make sure that
Normalization students understand that this is not an all inclusive list, just a few of the more
important benefits.
What Is This is background material only; students will not perform denormalization in
Denormalization? this course.
Lesson Review
vi Module 9: Generating a Relational Logical Model
Lesson: Generating a Relational Logical Model

lesson. This lesson covers the use of Visio in generating a relational logical
model from a conceptual model. Make sure that students understand that this is
the preferred method and that it represents the natural progression of modeling
a database within the baseline database design process.
Important
! When a source file is added to a project, the project remembers the directory
location of that source file. The project will then always verify that the
source file exists in this directory. Because of this, the source files cannot be
moved after they have been added to a project. There is no such restriction
on the project file, however.
! Because Visio requires the .vsd files to be writable in many of the practices
and labs, students will be able to save updated versions of the starting and
answer files back to their original directories of C:\Moc\2090\.... After
students overwrite a course-supplied .vsd file, in order to return it to its
original state, they must copy it from another source, or restore it by running
the Allfiles.exe application found on the Student Materials compact disc.
! Running Allfiles.exe will overwrite all the course-supplied files. For that
reason, you may advise students to make a copy of the C:\Moc\2090\...
directory tree to save the original files to another location on their
computers hard disk.
Multimedia This topic page briefly describes and introduces the multimedia visual aid. This
visual aid covers the way that Visio maps ORM constructs into ER constructs.
Make sure that students understand that there is no one-to-one correlation
between the objects in the ORM model and objects in the relational logical
model.
What Is a Project? This topic page defines and describes projects and their uses in Visio and how
they are used in this course to generate relational logical models. It covers the
components, source models, and external objects. External objects are described
but not demonstrated. If you want, you may demonstrate their use for students
who need help understanding.
How to Generate a This topic page instructs students on how to create a project, how to generate a
Relational Logical Model relational logical model, and, finally, how to draw the logical model diagram.
from a Conceptual Make sure that students understand that, just like an ORM model, a relational
Model logical model exists, regardless of whether it is visible on the drawing surface.
The diagram is only the graphical representation of the model.
Practice: Generating a This page reinforces the elements of the previous page through practice of the
Relational Logical Model procedure by using the Scheduling Theme. There is no link on this slide to the
from a Conceptual solution project file. Open the answer file from the course files folder.
ModelScheduling
Theme The starting file for this practice is the ORM source model. Students will create
the project file and add the ORM source model to it during the practice. The
answer file for this practice is the solution project file. It will link to the starting
ORM source model when opened.
Module 9: Generating a Relational Logical Model vii
Lesson Review
Module Review
topics covered.
Lab A: Generating a Relational Logical Model

Lab Setup
Lab Results
or customization.
Module 9: Generating a Relational Logical Model 1
Module Overview
! Understanding Relational Logical Models

! Understanding Normalization
! Generating a Relational Logical Model

Introduction In this module, you will learn the necessary skills and information that you need
to generate relational logical models. In addition, you will learn to use modeling
projects, which are the shells around the models that you work with. You will
also use modeling projects to reuse models.
Module purpose Now that you have completed the Conceptual Schema Design Procedure
(CSDP), the purpose of this module is to teach you the procedures for
generating the relational logical model.
! Generate a relational logical model.
Describe a relational logical model.
Describe normalization.
2 Module 9: Generating a Relational Logical Model
Lesson: Understanding Relational Logical Models
! What Are Relational Logical Models?

! How Tables and Columns Are Symbolized
! What Are Relationships?
! How Relationships Are Symbolized

Introduction Following the database design method, you generate a relational logical model
from your existing conceptual business requirements model. You must be
familiar with the elements and use of a relational logical model.
Lesson purpose The purpose of this lesson is to teach you a basic understanding of the elements
and use of a relational logical model.
! Define and describe a relational logical model and its use.
Define and describe tables and columns.
Define and describe relationships.
What Are Relational Logical Models?
! Definition
The relational logical model is a representation of the
conceptual business data requirements modeled using
tables, columns, and relationships
! Components
" Tables
" Columns
" Primary keys
" Relationships

Introduction The database design method is segmented into four parts: external, conceptual,
logical, and physical. The ORM models that you have been working with are
the conceptual models of business requirements. The data definition language
(DDL) that creates the database represents the physical schema. Captured in
DDL, the physical model goes beyond the logical model by including such
characteristics as indexes and file placement. The relational logical model is the
bridge between the two.
Definition The relational logical model is a representation of the conceptual business data
requirements modeled by using tables, columns, and relationships.
Microsoft Visio Enterprise Architect edition stores the relational logical
model and displays it as an ER diagram. The relational logical model is the
blueprint that you use to create the physical schema.
Components Some of the components of a relational logical model are:
! Tables. Represent the existence of things of interest. How data is structured
in a relational logical model. Each table must have a unique name. Rows of
data must be unique. Tables in the relational logical model represent what
will become the physical tables in the database.
! Columns. The divisions of data within a table. Column names within a table
must be unique. All values in a column must be the same type of data.
Columns must be non-decomposable. Columns in the relational logical
model represent what will become the physical columns in the database.
! Primary keys. Uniquely identify each row of data in a table. You will
designate one column or one combination of columns as the primary key for
each table.
! Relationships. Represent the links between two tables. They enable you to
retrieve related data from more that one table. Relationships in the relational
logical model are enforced by foreign key constraints in the physical
database.
How Tables and Columns Are Symbolized
Table Primary key

E mploy ee Employee
PK EmployeeID
Column Employee Uniqueness Employee

PK EmployeeID constraint PK EmployeeID
LastName U1 LastName
FirstName U1 FirstName
BirthDate U1 BirthDate
Address Address
Figure 9.2 PhoneNumber Figure 9.4 PhoneNumber

Introduction You must learn to recognize the shapes and what they represent in the relational
logical diagram. Visio labels tables as Entity in the template. However, this
course will continue to refer to them as tables.
Table and column Table 9.1 describes tables, columns, primary keys, and uniqueness constraints
shapes as they appear in a relational logical diagram.
Table 9.1
Relational logical diagram modeling element Symbol
Table
Tables represent the existence of things of interest.
Tables are symbolized by rectangular grid with solid
borders. The table name appears in the shaded heading
region.
Columns
The divisions of data within a table. Columns are either
part of the primary key or describe the real-world object
instances contained in the table.
Non-primary key columns are listed in the second row.

Relational logical diagram modeling element Symbol
Primary key
A primary key identifies a row of data. A primary key is,
by definition, unique.
The columns of a primary key are located in the first row
of a table shape and are identified by the letters PK in the
cell to the left. Also, the primary key is underlined.
Uniqueness constraint
A uniqueness constraint guarantees that each value, or
combination of values, will appear only once in a table.
Uniqueness constraints are symbolized by the letters U(n)
where n is the ordinal of the uniqueness constraint in the
entity. Columns spanned by a uniqueness constraint that
are not part of the primary key are considered alternate
keys.
Required columns are bold.
What Are Relationships?
! Definition
Relationships are associations between tables
! Characteristics
" Shared columns
" Foreign keys
" Relationship cardinality

Introduction A relational logical model uses relationships to identify semantic data
connections between the columns of two tables.
Definition Relationships are associations between tables. The tables involved in a
relationship are called participants.
Characteristics There are three important characteristics of relationships that you should be
aware of:
! Shared columns. The same column existing in two tables. Relationships are
built on shared columns.
! Foreign keys. A formal declaration of the relationship between the shared
columns of two tables. Foreign keys enforce the referential integrity of that
relationship.
! Relationship cardinality. The minimum and maximum number of rows of
each table that may participate in a relationship, for example, 1:1, 1:many.
How Relationships Are Symbolized
Crows Feet Notation

Zero One Many
Figure 9.5 Figure 9.6 Figure 9.7
Examples
One to zero or more One to zero or more
One to zero or one
Figure 9.10

Introduction Visio uses the Crows feet notation to symbolize relationships, including their
cardinality. It is useful because it provides an unambiguous graphical method
for quickly understanding the meaning of each relationship.
Crows feet notation Crows feet notation consists of three individual symbols, each referring to
some portion of the complete relationship cardinality. Crows feet notation
expresses logically valid zero, one, or many cardinality combination.
Note The exception is many-to-many relationships. The relational logical

diagram expresses these as three tables by using two one-to-many relationships
joining the parent tables with a common child table.
Crow's feet notation can symbolize optional parent relationships. However,

Microsoft SQL Server 2000 does not support optional parents in foreign
keys.
Tip You have the choice of displaying the numeric relationship cardinality
with the default relationship arrows, or displaying the Crows feet notation
without the numeric cardinality. Switch between the two notations to see the
numeric cardinality when you have range of value constraints in the ORM
model.
Table 9.2 contains the basic Crows feet symbols.

Table 9.2
Crows feet symbol Interpretation
Zero
It is valid for the side of the relationship on which this symbol
is found to have no participating rows. That side of the
relationship is optional.
One
The side of the relationship on which this is found may have
one participating row. Two vertical lines mean that you must
have exactly one, usually stated as one.
Many
The side of the relationship on which this is found may have
more than one participating row. The many symbol is found
only on the child side of the relationship.
Identifying and non- In addition to the Crows feet notation, the relational logical diagram uses either
identifying relationships dashed or solid lines to indicate whether the foreign key in the child table also
becomes its primary key. A dashed line, the most common type, means that the
foreign key does not become part of the child table's primary key, and,
therefore, is non-identifying. A solid line means that it is identifying.
The relational logical diagram uses the individual symbols, placed at each end
of the dotted or solid line between two tables, to express the full relationship
logical syntax. Table 9.3 contains three examples of relationships.
Table 9.3
Relationship (parent to child) Interpretation
One to zero or more

Each parent may exist with zero or more
children. The foreign key is not part of the child
tables primary key.
One to zero or more
Each parent may exist with zero or more
children. The foreign key is part of the child
tables primary key, making this an identifying
relationship.
One to zero or one
Each parent may exist with zero or one child. The
child is optional.
Lesson Review
Objectives
Objectives
Understand
Understand aa relational
relational logical
logical model
model
Define
Defineand
anddescribe
describerelational
relationallogical
logical models
models
Define
Defineand
anddescribe
describetables
tablesand
andcolumns
columns
Define
Defineand
anddescribe
describerelationships
relationships

1. Describe a relational logical model.
A relational logical model is a representation of the conceptual business
data requirements modeled by using tables, columns, and relationships.
It is generated during the build process and is based on the business
requirements model in the source files.
2. Describe tables.
Tables are how data is perceived in a relational logical model. Each
table must have a unique name. Rows of data must be unique. Tables in
the relational logical model represent what will become the physical
tables in the database.
3. Describe columns.
Columns are the divisions of data within a table. Column names within
a table must be unique. All values in a column must be the same type of
data. Columns must be non-decomposable. Columns in the relational
logical model represent what will become the physical columns in the
database.
4. Describe relationships.
Relationships represent the links between two tables. They enable you
to retrieve related data from more than one table. Relationships in the
relational logical model are enforced by foreign key constraints in the
physical database.
Lesson: Understanding Normalization
! What Is Normalization?
! What Is First Normal Form?
! What Is Second Normal Form?
! What Is Third Normal Form?
! Benefits of Normalization
! What Is Denormalization?

Introduction To fully understand a relational logical model, you must also understand the
requirements of normalization and denormalization.
Lesson purpose The purpose of this lesson is to explain normalization and denormalization to
the extent that you can appreciate what Visio does for you. This lesson is not
meant to show you how to normalize and denormalize.
! Describe normalization.
Define and describe the first three forms of normalization.
Describe the benefits of normalization.
Describe denormalization.
What Is Normalization?
! Definition
Normalization is the formal methods used to separate data
into multiple, related tables
! Tasks accomplished with normalization
" Minimized duplication of information
" Reduced data inconsistencies
" Faster data modification (insertions, updates, and
deletions)

Introduction Normalization is the process of progressively refining a logical model to
eliminate duplicate data from a database. In practice, normalization involves
reorganizing database tables and defining relationships among these tables.
Definition Normalization is the formal method used to separate data into multiple, related
tables in order to eliminate redundancy and inconsistencies when manipulating
data.
Often, normalization is accomplished by manually changing your model. But
by using the CSDP to generate a conceptual model, Visio generates a relational
logical model that is in Fifth Normal Form.
Tasks accomplished Normalized databases typically include more tables with fewer columns.
with normalization Normalizing a database accomplishes the following:
! Minimized duplication of information
A normalized database contains no duplicate information.
! Reduced data inconsistencies
Normalization reduces data inconsistencies by maintaining table
relationships.
! Faster data modification (insertions, updates, and deletions)
Normalization speeds up the data modification process in a database.
What Is First Normal Form?
! Definition
First Normal Form is the state of a database in which each
column contains a single type of information and there
are no repeating groups of data
Table 9.4
Customer-
Customer-Order
CustomerID LastName FirstName OrderID OrderDate Product Quantity
1108 Cary Richard 2667 05/03/2002 P11-3 5
1108 Cary Richard 2667 05/03/2002 L3-4 9
1256 Gambardella Matthew 7401 01/26/2001 P11-3 16
Primary key

Introduction The first step in normalizing a database is to ensure that the tables are in First
Normal Form (1NF).
Definition First Normal Form is the state of a database in which each column contains a
single type of information, a single value, and there are no repeating groups of
data.
Example of First Normal Table 9.4 is an example of a table in First Normal Form.
Form
Table 9.4
Customer-Order
CustomerID LastName FirstName OrderID OrderDate Product Quantity
1108 Cary Richard 2667 05/03/2002 P11-3 5
1108 Cary Richard 2667 05/03/2002 L3-4 9
1256 Gambardella Matthew 7401 01/26/2001 P11-3 16
What Is Second Normal Form?
! Definition
Second Normal Form is the state of a database in which
the database meets the requirements of 1NF and every
non-key column depends on the entire primary key
Table 9.5
Customer
CustomerID LastName FirstName SalesPersonID SalesPersonPhone
1108 Cary Richard 889709 01-99-999-9999
1256 Gambardella Matthew 223546 01-11-111-1111
Table 9.6 Table 9.7

Order OrderDetail
OrderID OrderDate CustomerID OrderID ProductID Quantity
2667 05/03/2002 1108 2667 P11-3 5
7401 11/26/2001 1256 2667 L304 9
Primary key 7401 P11-3 16

Introduction Putting a table into Second Normal Form (2NF) is the next step in
normalization and a further enhancement of the logical model.
Definition Second Normal Form is the state of a database in which the database meets the
requirements of 1NF, and every non-key column depends on the entire primary
key.
Example Table 9.5, Table 9.6, and Table 9.7 are examples of tables in Second Normal
Form.
Table 9.5
Customer
CustomerID LastName FirstName SalesPersonID SalesPersonPhone
1108 Cary Richard 889709 01-99-999-9999
1256 Gambardella Matthew 223546 01-11-111-1111
Table 9.6
Order
OrderID OrderDate CustomerID
2667 05/03/2002 1108
7401 11/26/2001 1256
Table 9.7
OrderDetail
OrderID ProductID Quantity
2667 P11-3 5
2667 L304 9
7401 P11-3 16
What Is Third Normal Form?
! Definition
Third Normal Form is the state of a database in which the
database meets the requirements of 2NF, and every
non-key column depends only on the primary key
Table 9.8 Table 9.9
Customer Sales
CustomerID LastName FirstName SalesPersonID SalesPersonID Phone
1108 Cary Richard 889709 889709 01-99-999-9999
1256 Gambardella Matthew 223546 223546 01-11-111-1111
Table 9.10 Table 9.11
Order OrderDetail
OrderID OrderDate CustomerID OrderID ProductID Quantity
2667 05/02/2002 1108 2667 P11-3 5
7401 11/26/2001 1256 2667 L3-4 9
7401 L3-4 16
Primary key
Introduction Third Normal Form (3NF) builds on 2NF and is generally the highest level of
normalization that you will implement.
Definition Third Normal Form is the state of a database in which the database meets the
requirements of 2NF, and every non-key column depends only on the primary
key.
No column has a functional dependency on any column other than the primary
key.
Third Normal Form helps to avoid update and deletion anomalies, because all
data can be reached through foreign key values, and redundant data within each
table no longer exists. This level of normalization greatly increases database
integrity and generates a more optimized design.
Example Table 9.8, Table 9.9, Table 9.10, and Table 9.11 are examples of tables in
Third Normal Form
Table 9.8
Customer
CustomerID LastName FirstName SalesPersonID
1108 Cary Richard 889709
1256 Gambardella Matthew 223546
Table 9.9
Sales
SalesPersonID Phone
889709 01-99-999-9999
223546 01-11-111-1111
Table 9.10
Order
OrderID OrderDate CustomerID
2667 05/02/2002 1108
7401 11/26/2001 1256
Table 9.11
OrderDetail
OrderID ProductID Quatity
2667 P11-3 5
2667 L3-4 9
7401 L3-4 16
Benefits of Normalization
! Enhanced application efficiency

! Fewer null values
! Update anomalies reduced
! Less application modification

Introduction As described, normalization can eliminate many difficulties that would
otherwise hinder the performance and accuracy of a database. This page
describes some of the specific benefits of normalization.
Enhanced application Modifying the data values in a normalized database is generally quicker
efficiency because it affects fewer tables. Additionally, fewer application contentions
occur when multiple users are making modifications to the datas values.
Fewer null values Reducing the number of columns in a table to only those that are relevant to
that particular table results in fewer null values for a given record, thus reducing
the overall size of the table and the database.
Update anomalies By ensuring that data is not duplicated anywhere in a database, you can
reduced virtually eliminate all insert, update, and deletion anomalies, because the
database will only have to store and change data in one place. This leads to
consistency of data within the database, resulting in the same information
retrieved by each query.
Less application Using smaller and more concisely defined tables reduces the impact on
modification application maintenance, because fewer tables are affected by schema changes.
What Is Denormalization?
! Definition
Denormalization is the process of selectively duplicating
data in multiple tables
! Potential costs
" You must use code to maintain data consistency
" Data modifications will take longer to execute
" Write cost may exceed the read benefit

Introduction Sometimes, performance needs outweigh the requirements of normalization.
You can often enhance the performance of a query through the use of
denormalization.
Definition Denormalization is the process of selectively duplicating data in multiple
tables.
It is important to understand that this is not the opposite of normalization.
Denormalization requires great effort on your part to make sure that the
duplicate data is the correct data to duplicate, and that it is stored in the proper
tables.
The benefits of such duplication can be significant, typically exhibited as a
reduction in table joins within queries. However, given the costs, you should
only denormalize data if you can create a clear performance enhancement.
Potential costs There are costs associated with denormalization that you must consider. The list
is too great to cover here; however, there are a few items that you should be
familiar with.
! You must use code to maintain data consistency.
Because you will have duplicate data in multiple tables, any time that you
change data in one table, you must also change it in the other tables. This
will require the use of application code, stored procedures, orpreferably
triggers to manage this. Without triggers, there is no guarantee that every
application that writes to the database will maintain data consistency. The
cost is that the extra code requires more work to create and maintain.
! Data modifications will take longer to execute.

Regardless of the mechanism used to maintain data consistency, it will take
longer to insert, update, and delete redundant information, because you must
do so in multiple places. This could also lead to disk Input/Output and lock
contention within the database as multiple write-oriented application users
access more tables, and for longer periods of time.
! Write cost may exceed the read benefit.
Denormalization is most appropriate for databases that have a high degree
of read activity when compared to write activity. An example of this is a
reporting database. A reporting database is typically reloaded at periodic
intervals, requiring write-oriented applications to be executed infrequently.
Alternately, a reporting database may receive incremental changes, but these
changes, as well as entire database reloads, usually execute when users are
not using the reporting applications.
Lesson Review
Objectives
Objectives
Describe
Describe normalization
normalization
Define
Defineand
anddescribe
describethe
thefirst
first three
three forms
forms of
of
normalization
normalization
Describe
Describethe
the benefits
benefitsof
ofnormalization
normalization
Describe
Describedenormalization
denormalization

1. Define First Normal Form.
First Normal Form is the state of a database in which each column
contains a single type of information and there are no repeating groups
of data.
2. Define Second Normal Form.

Second Normal Form is the state of a database in which the database
meets the requirements of 1NF, and every non-key column depends on
the entire primary key.
3. Define Third Normal Form.

Third Normal Form is the state of a database in which the database
meets the requirements of 2NF, and every non-key column depends
directly on the primary key.
4. Which of the three normal forms does Table 9.12 violate?

Table 9.12
EmployeeID (PK) LastName FirstName JobCode JobDescription
0239 Larsen Ashley S3 Support Level 3

5906 Zuvela Leonard I2 Instructor Level 2
3006 Chai Sean S3 Support Level 3
0357 Phua Meng A4 Administrator Level 4
Table 9.12 violates 3NF because JobDescription is functionally

dependent on JobCode, not EmployeeID.
5. What are the problems associated with Table 9.12 in the preceding
example?
The job description for each job code is stored multiple times in the
table. This could lead to changes to the description in some rows but not
in others. It also means that the job description for a particular job
code will not exist in the database unless an employee has that job code.
6. What is the primary benefit of using ORM to model normalized

information?
Using ORM, and following the CSDP, Visio will generate a relational
logical model that is in Fifth Normal Form.
Lesson: Generating a Relational Logical Model
! Multimedia: ORM Relational Mapping Process in

Microsoft Visio Enterprise Architect Edition
! What Is a Project?
! How to Generate a Relational Logical Model from a
Conceptual Model
! Practice: Generating a Relational Logical Model from a
Conceptual ModelScheduling Theme

Introduction Visio provides the benefit of automatically generating a relational logical model
from an ORM model. In this lesson, you will learn how to generate a relational
logical model from a conceptual model as part of the baseline database
modeling process. You will use modeling projects to help you manage the files
used in the development of your database.
Lesson purpose The purpose of this lesson is to teach you how to generate a relational logical
model from a conceptual model.
! Generate a relational logical model from a conceptual model.
Create and use a project.
Draw a relational logical model diagram.
Multimedia: ORM Relational Mapping Process in Microsoft Visio

Enterprise Architect Edition
. ..invites. ..to. ..
Venue !
(ID) Att endeeCapacity+
owns has
VenueManager
Building !
(Number)
... approves use of. ..for... is in
Person ! Meeting
Location ! RoomNumber
(I D) (ID)
...has...f or... is hosted physically at has
{ 'Decline',
'Accept',
'Tentative' } Online !
(URL)
Status is hos ted electronically at has
AccessCode
MeetingOrganizer
Teleconferenc e !
proposes reoccurs
is hosted telephonically at has
>=2
Subject
T elephoneNumber
is used by reoccuring has
has
Time
Appointment ! (TimeValue)
(I D)
is used by one-time "Timeslot"
is related
P
Duration+
spans (ac,it) has **
Venue
PK Venu e ID
Location
Atten deeCapacity
Building
P K,FK 1 Build ing
PK B uildin g PK Room Nu mber
F K2,U 1 Venu e ID
T eleconference O nline
PK T elephon eNum ber PK On lin e U RL

PK AccessCo de
Ac cessC ode
F K1,U1 Ven ue ID FK 1,U1 Venu e ID
Meeting
PK Meeting ID
FK 1 Meeting Org aniz er proposesPerson ID

Su bject
FK 2 Hosted phy s ic ally LocationBuilding
VenueManager approves use Venue Meeting V enueM anager owns V enue
FK 2 Hosted phy s ic ally Location Room Number
FK 3 Hosted elec tronic ally Online URL PK,F K2 V en ue ID P K,F K1 P erson ID
FK 4 Hosted telephonic ally T elec onferenc e TelephoneNumber PK,F K1 M eetin g ID P K,F K2 V enue ID
FK 4 Hosted telephonic ally T elec onferenc e Acc ess Code
Reoccu rs FK2 P erson ID
Appointm ent us ed reocc uring Meeting

P ers on
PK ,F K1 App oin tmen t ID
PK Perso n ID
PK ,F K2 Meeting ID
P ers on inv ites Pers on M eeting

Appointment
PK A ppo in tment ID P K,F K1 Perso n invitesP erso n ID

P K,F K2,U1 Invites Person toPerson ID
FK 1 U s ed onetime Meeting ID
F K3,U1 Meetin g ID
Appointment spans Times lot

Tim eslot P ers on Status M eeting
PK ,FK 1 Appo intment ID
PK S tartT imeTime P K,F K1 Perso n ID
PK ,FK 2 StartTimeT ime
PK S to pT imeTime P K,F K1 Meetin g ID
PK ,FK 2 Stop TimeT ime
D uration Statu s

Introduction The multimedia visual aid presented here provides you with a very high-level
view of the processes that take place when you build a relational logical model
from a conceptual model. It is important that you understand what Visio does
for you, not how it works.
The multimedia visual aid will show you how the ORM elements of the
conceptual model map to the ER elements of the relational logical model. Pay
special attention to each grouping of ORM elements, because there is not a one-
to-one relationship between the elements of each model.
You will not see this mapping take place when you build a relational logical
model. Visio performs this action and presents you with the final output of the
relational logical model, while preserving your existing conceptual model.
What Is a Project?
! Definition
A project is a Visio file that groups models and files that
are related to a single relational logical model
! Components
" Source models
" External objects
! Synchronization

Introduction After completing the CSDP, you must create a Visio project to relate your
ORM model to the logical model that you generate.
Definition A project is a Visio file that groups models and files that are related to a single
Projects can include ORM source models, ER source models, and other non-
Visio files that you want to keep together. Building a project consolidates the
source models in the relational logical model and performs a check for errors.
Components ! Source models
A source model is a structured repository of information that captures the
business rules and requirements. A source model is stored in a Visio file.
Each source model can be shared in multiple projects. All of the source
model files in your project are displayed in the Visio Project window, where
you can:
Open a model file by double-clicking its name.
Manage the models in the project by right-clicking the model names and
choosing a command.
! External objects
External objects are object types created in one model that are referenced in
a second model. You fully define the object type properties and reference
scheme in the original (non-referencing) model, but can then use the object
as though it were created in the referencing model. In order to designate an
object types as external, its corresponding object type, having the same
name, must exist in another model within the Visio project.
The benefit of using external objects is the ability to break up large complex
models into manageable sub-models and share those across multiple
projects.
Synchronization When working with projects, you will periodically synchronize the source
models with the collective relational logical model. This ensures that changes to
one model are reflected in the others.
Using Visio, you can manually update the source models with changes made to
the relational logical model. Visio will also automatically prompt you to do so
at specific times, such as when building the project after making changes to the
relational logical model. Visio synchronizes changes made to the source model
with the relational logical model when you build the project.
In general, make changes at the conceptual level and then rebuild the project.
How to Generate a Relational Logical Model from a Conceptual

Model
Create
Create aanew
new database
databasemodel
model diagram
diagram
Add
Addananexisting
existingfile
fileto
tothe
theproject
projectand
andcheck
checkfor
for
errors
errors
Generate
Generatethe
thelogical
logicalmodel
model
Draw
Draw the
theelements
elementson
onthe
thedrawing
drawing surface
surface

Introduction In this practice, you will execute the steps required to create a project and then
generate, or build, a relational logical model from a conceptual model.
Procedure Use the following procedure to create a logical model:
1. Create a new database model diagram.
Create the diagram and save it with a name indicating that it is a project. Set
Crows feet notation for the relational logical model.
2. Add an existing file to the project and check it for errors.
Add the ORM source model or models that you will be working with. The
source models form the basis of the relational logical model, also referred to
as the collective model.
3. Generate the logical model.
Generate the logical model by building the project. This process performs
an automatic ORM model error check, validates the congruence of the ORM
source models, and builds the relational logical model, mapping the
conceptual elements to their corresponding logical elements.
4. Draw the elements on the drawing surface.
This will create the shapes for the tables, columns, and the relationships in
the model.
Practice: Generating a Relational Logical Model from a Conceptual

ModelScheduling Theme
! Purpose
! Scenario
! Practice
Mon Tue Wed Thu Fri
8 am
Out of Office:
9 00 Doctors Appt
Manager
1:1 All-han
10 00 Quaterl
Team
11 00 Traini
Brownbag Class
12 pm Lunch: ORM
2 00
Data
Modeling
Project
Data
Modeling
Project
Model Model 3 00
4 00
5 00

Introduction In this practice, you will execute the steps required to create a project and then
generate a relational logical model from an ORM model.
Purpose The purpose of this practice is to familiarize you with the procedures and tasks
used to create modeling projects and generate relational logical models by using
Visio.
Scenario This practice uses the Room Scheduling Theme to illustrate creating the logical
model.
Practice You will use the files in C:\MOC\2090\Practices\Mod09 to complete this
practice. Solution files for this practice are located in the Answer subdirectory
of that folder.
! Create a new database model diagram

1. On the File menu, point to New, point to Database, and then click
Database Model Diagram.
The Database Document Options window appears.
3. In the Database Document Options dialog box, on the Relationship tab,
under Show, select Crows feet, and then click OK.
4. On the Database menu, point to View, and then click Project to open the
Project window.
5. On the File menu, click Save as. Save the project to your My Documents
folder as GenerateLogical_Scheduling_Project.vsd.
! Add existing files to the project

1. On the Database menu, point to Project, and then click Add existing
document.
2. In the Add Document to Project dialog box, navigate to the practice folder
for this module, click GenerateLogical_Scheduling_ORMSource to select
it, and then click Open.
! Generate a logical model

1. On the Database menu, point to Options, and then click Drivers. On the
Drivers tab, confirm that Microsoft SQL Server is selected.
2. On the Database menu, point to Project, and then click Build.
This will generate the logical model. The Tables and Views tab will be
added to the Project window.
! Draw the elements on the drawing surface

1. In the Project window, on the Tables and Views tab, press CTRL, click the
Building, BuildingRoom which Capacity, and Person tables, and then
drag and drop them onto the drawing surface.
2. On the File menu, click Save to save your project.
If needed, review the solution files for this practice located in

C:\MOC\2090\Practices\Mod09\Answer.
Lesson Review
Objectives
Objectives
Generate
Generate aa relational
relational logical
logical model
model from
from aa
conceptual
conceptual model
model
Create
Createand
and use
useaaproject
project
Draw
Drawaarelational
relationallogical
logicalmodel
modeldiagram
diagram

1. What is a project?
A project is a Visio file that groups models and files that are related to a
single relational logical model.
2. What are source models?

A source model is a structured repository of information that captures
the business rules and requirements.
3. What is an external object?

External objects are object types created in one model that are
referenced in a second model.
Module Review
! Understanding Relational Logical Models

! Understanding Normalization
! Generating a Relational Logical Model

1. What could you change in a relational logical model without migrating
those changes back to the ORM source model?
Column names, physical table names, and the relative position of non-
key columns. These are considered nonstructural changes and are
saved as part of the relational logical model.
2. Why would you use external objects?

The benefit of using external objects is the ability to break up large
complex models into manageable sub-models and share those across
multiple projects.
3. Describe the benefits and costs of denormalization and a circumstance

where it would be beneficial.
A reduction in table joins within queries is the primary benefit. This
may lead to higher performing queries. The costs include the fact that
you must use code to maintain data consistency, data modifications will
take longer to execute, and the write cost may exceed the read benefit.
A useful circumstance would be a reporting environment in which data
changes are made infrequently.
Lab A: Generating a Relational Logical Model
! Exercise 1: Generating a Logical Model

Objectives This lab will reinforce your understanding of generating a relational logical
model, and your knowledge of the tasks required to do so.
! Generate a relational logical model from an ORM conceptual model.

! Be able to create a Visio project.
! Be able to add an ORM source model to a project.
! Be able to build a project to generate a logical model.
model is provided that represents limited information about the campus
buildings and the employees that maintain them.
You will use the files in C:\MOC\2090\Labfiles\Lab09A to complete this
of that folder.
Estimated time to
complete this lab: 30
minutes
Exercise 0
Lab Setup
box.
5. Click OK.
Exercise 1
Generating a Logical Model
In this exercise, you will be given an ORM source model for the Academic
Theme. You are to create a project, add the ORM source model to it, build the
project to generate the logical model, and draw the elements in the logical
model.
! Create a Visio project

Create a new diagram displaying the project window, and save it as
GenerateLogical_Academic_Project.vsd in your My Documents folder.
! Add existing files to the project

Add the GenerateLogical_Academic_ORMSource.vsd ORM source
model to the project.
! Generate a logical model

1. Ensure that Visio is using the SQL Server driver.
2. Select the Crows Feet relationship option in the logical model.
3. Build the project to create the logical model.
You should encounter no errors or warnings.
! Draw the elements on the drawing surface

1. Draw the logical model elements.
2. Save your project.
C:\MOC\2090\Labfiles\Lab09A\Answer folder.
Course Evaluation

Your evaluation of this course will help Microsoft understand the quality of
your learning experience.
At a convenient time before the end of the course, please complete a course
evaluation, which is available at http://www.metricsthatmatter.com/survey/.
Microsoft will keep your evaluation strictly confidential and will use your
responses to improve your future learning experience.

Module 10: Completing
the Baseline Model
Contents
Module Overview 1
Lesson: Refining Conceptual and Logical
Models 2
Lesson: Documenting Conceptual and
Logical Models 17
Module Review 25
Lab A: Completing the Baseline Model 26
other countries.
respective owners.
reserved.
Module 10: Completing the Baseline Model iii
Instructor Notes
60 minutes interpret and refine logical models.
Lab:
30 minutes After completing this module, students will be able to:
! Complete a baseline model.
Refine conceptual and logical models.
Document conceptual and logical models.

iv Module 10: Completing the Baseline Model

Lesson: Refining Conceptual and Logical Models
lesson. This lesson covers the final steps completed to create the baseline
What Are Data Types? This page defines and describes data types as they relate to Object Role
Modeling (ORM) and relational logical modeling. It further says that you set
the data type for every entity object type with a reference mode and every value
object type. Entity object types with no reference mode do not use the data type,
even though it exists. As you may recall, an entity object type that lacks a
reference mode will derive its primary reference scheme from the fact types that
it participates in.
How to Set Physical This page instructs students on the high-level steps of how to set data types in
Data Types the ORM model.
Practice: Setting This page reinforces the elements of the previous page through practice of the
Physical Data Types procedure by using the Scheduling Theme.
Scheduling Theme
What Are Physical This page defines and describes physical names as they relate to ORM and
Names? relational logical modeling. Make sure that students understand that when they
change the physical names in the logical model, they must migrate those
changes back to the conceptual model, or they will be lost the next time the
project is built.
How to Set Physical This page instructs students on the high-level steps of how to set physical
Names names in the ORM model.
Practice: Setting This page reinforces the elements of the previous page through practice of the
Physical Names procedure by using the Scheduling Theme.
Scheduling Theme
In the relational logical model generated by this practice, the primary key for
the Person table is Person, the name of the table. By default, it would be
Employee ID. The Building table would be named Name Alpha by default.
Name is the entity object type identified in the primary reference scheme, and
Alpha is its reference mode.
This model provides an indication of the tradeoff when setting options. In this
case, eliminating the reference mode of Employee ID from the name caused it
not to appear as the primary key name, even though it would have been a good
choice. However, Name is a better starting point than Name Alpha, or Alpha
for the Building primary key. In general, use the reference mode when the
majority of the primary reference schemes in the ORM model are the reference
modes of the object types.
Module 10: Completing the Baseline Model v
Also, use this practice to explore the mapping that occurred based on the
options set prior to rebuilding the project. This will reinforce students
understanding of name mapping.
Important The practice has students attempt to close the relational logical
model to force Microsoft Visio Enterprise Architect edition to prompt them to
save the model and to migrate changes to the source model. Generally, you
would save a file prior to attempting to close it; however, Visio always prompts
to migrate changes when closing the model, even if they have already been
manually migrated or migrated on a save. The steps in the practice eliminate the
redundancy.
Next Steps This topic page serves as a reminder that students are not done with the
database design. After the database has generated the physical schema, there are
several more work items pending. However, these items are out of scope of this
course. You may instruct students to further their studies by attending Course
2072: Administering a Microsoft SQL Server 2000 Database and Course 2073:
Programming a Microsoft SQL Server 2000 Database.
Lesson Review
Lesson: Documenting Conceptual and Logical Models

lesson.
Why Document a This topic page covers the reasons why and when students would want to
Model? generate reports. There are many reports, and each report has many options, so
they will not be covered in detail. Feel free to have students discover the
variations of these reports through exploration.
Types of Visio Reports This topic page lists the titles of each report available from the user interface
(UI). As stated above, though, there are too many variations to cover all
options.
How to Generate This page instructs students on the high-level steps of how to generate reports
Reports in the conceptual and logical models.
Practice: Generating This page reinforces the elements of the previous page through practice of the
ReportsScheduling procedure by using the Scheduling Theme.
Theme
Lesson Review
vi Module 10: Completing the Baseline Model
Module Review
topics covered.
Lab A: Completing the Baseline Model

Lab Setup
Lab Results
or customization.
Module 10: Completing the Baseline Model 1
Module Overview
! Refining Conceptual and Logical Models

! Documenting Conceptual and Logical Models

Introduction After you have created a conceptual model by using the Conceptual Schema
Design Procedure (CSDP), you can use this model to generate a relational
logical model. This logical model requires manipulation in order to prepare it
for implementation in a production environment.
Module purpose The purpose of this module is to guide you through the processes of completing
the baseline model, so that you can generate the initial physical schema.
2 Module 10: Completing the Baseline Model
Lesson: Refining Conceptual and Logical Models
! What Are Data Types?

! How to Set Physical Data Types
! Practice: Setting Physical Data TypesScheduling
Theme
! What Are Physical Names?
! How to Set Physical Names
! Practice: Setting Physical NamesScheduling Theme
! Next Steps

Introduction Refining the baseline model requires setting the physical data types and
creating efficient physical names. This ensures that the database is ready for
initial implementation. This lesson also lists further refinements that you must
consider, but which are out of scope for this course.
Lesson purpose The purpose of this lesson is to teach you the skills and knowledge to set data
types in the conceptual model and to set physical names in the relational logical
model.
! Refine conceptual and logical models.
Set data types.
Set physical names.
What Are Data Types?
! Definition
Data types define the specific kind of data that can be
stored in a column in a database
! Portable
! Physical

Introduction You will use data types to limit the kind of information that is stored in the
columns of a given table. Although this is set in the conceptual model, you will
see the limitations more prevalently in the physical database.
Definition Data types define the specific kind of data that can be stored in a column in a
database.
You must set the data type in each entity object type with a reference mode and
in each value object type in every Object Role Modeling (ORM) source model
in the project. Microsoft Visio Enterprise Architect edition allows you to
specify either portable or physical data types.
Portable Portable data types are generic. Setting portable data types in the conceptual
model allows you to delay the decision of which Database Management System
(DBMS) to use when you generate a physical schema until you actually need to
do so. Visio will automatically map each portable data type to the closest data
type supported by the DBMS that you specify for the selected database driver.
Physical Physical data types are specific to a particular DBMS. Setting physical data
types requires you to make the target database decision while still working with
the conceptual model.
You will be setting Microsoft SQL Server 2000 specific data types in the
conceptual model during refinement. Setting data types in the conceptual model
will propagate them into the relational logical model during the build. One
object type in ORM may map to several elements in the relational logical
model.
How to Set Physical Data Types
Select
Selectthe
theORM
ORMsource
source model
model
Set
Set the
thephysical
physicaldata
data types
typesin
inORM
ORM
Build
Build the
theproject
project
Examine
Examinethe
the column
columndata
datatypes
types

Introduction In this practice, you will execute the steps required to set physical data types in
a conceptual model.
Procedure Use the following procedure to set SQL Server 2000 physical data types in a
conceptual model, and to build the relational logical model:
1. Select the ORM source model.
Because the collective relational logical model reflects the object types in
every source model in a project, you must set the data type in each of these
source models.
2. Set the physical data types in ORM.
Visio defaults to a data type of char(10) for every object type. Setting the
data types consists of selecting the SQL Server 2000 data type from a list,
and typing the number of characters, or digits, for those data types requiring
manual sizing.
3. Build the project.
Building the project propagates the data types set in ORM to the relational
logical model.
Note You must then execute an error check to ensure that the data type
sizing that you have set is within the limits of the database management
system to which the driver is set, in this case SQL Server 2000. For
example, char(30000) is invalid in SQL Server. Performing an ORM model
error check and building the project will not discover this type of error.
4. Examine the column data types.

Prior to building a project to generate a relational logical model, you cannot
predict which object types in the ORM source model will become columns
in the database. After generating the logical model, you can examine the
column data types to verify that they reflect the SQL Server 2000 data types
that are most appropriate. If they do not, you must return to the ORM source
model to make the changes.
Practice: Setting Physical Data TypesScheduling Theme
! Purpose
! Scenario
! Practice
Mon Tue Wed Thu Fri
8 am
Out of Office:
9 00 Doctors Appt
Manager
1:1 All-han
10 00 Quaterl
Team
11 00 Traini
Brownbag Class
12 pm Lunch: ORM
2 00
Data
Modeling
Project
Data
Modeling
Project
Model Model 3 00
4 00
5 00

Introduction Setting physical data types is the final activity that you will perform on the
ORM model.
Purpose The purpose of this practice is to familiarize you with the steps used to change
the default ORM data type of char(10) into the physical data types that support
the implementation of your database in SQL Server 2000.
Scenario This practice uses the Scheduling Theme to illustrate setting the physical data
types. It includes employees who maintain buildings according to maintenance
schedules.
of that folder.
Important This practice requires that the Visio database driver is set to
Microsoft SQL Server. Verify that this is the case by opening the Database
Drivers window from the Database, Options, Drivers menu, and verifying that
Microsoft SQL Server is selected. Close the window when done.
! Select the ORM source model

1. On the File menu click Open. Navigate to the practice folder and open
SetPhysicalDataTypes_Scheduling_Project.vsd.
2. On the Database menu point to View, and then click Project.
3. In the Project window, double-click
SetPhysicalDataTypes_Scheduling_ORMSource.vsd to open and display
the ORM source model for this project.
! Set the physical data types in ORM

2. In the Business Rules window, click the Object Types tab to expose the
object types in the model. Position the window to view all four columns of
information for each object type.
3. For the Person object, in the Physical Data Type column, double-click the
entry char(10) and change the 10 to 8.
This will set the data type of the Person reference mode of Employee ID to
char(8).
4. Repeat step 3 for the remaining object types in the source model by using
the information in Table 10.1.
Table 10.1
Object type Physical data type
Campus Map Location char(4)

Capacity smallint
Room char(4)
Date datetime
Name char(30)
Schedule char(3)
! Build the project

1. On the Window menu, click SetPhysicalDataTypes_Scheduling_Project
to switch to the project file.
The starting project has been built previously, and the tables and
relationships drawn in the starting model. Building the project in this
practice will update the physical data types in the relational logical model.
3. On the Database menu, point to Model, and then click Error Check.
There should be no warnings or errors in the model.
Important If you experience warnings or errors related to data types, make the
corrections in the ORM source model and rebuild the project so the corrections
are propagated throughout the relational logical model.
! Examine the column data types

2. In the Database Document Options window, on the Table tab, under Data
Types, click Show Physical, and then click OK.
The physical data types will not be displayed in each table on the drawing
surface.
3. Examine the data types for each of the columns in the Person table.
Notice that both First Name Alpha1 and Last Name Alpha have a data
type of char(30). This is the same for the Name Alpha column in the
Building and related tables.
What caused this to occur?
During the build, Visio mapped the Name entity object type specified in
the ORM source model with these three columns. In the ORM model,
Name has a data type of char(30).
____________________________________________________________
____________________________________________________________
4. Save the project and source models to their original locations and close
them.
What Are Physical Names?
! Definition
Physical names are the names assigned to elements of a
relational logical model that will generate like elements
in the physical schema with the same name
! Considerations
! Common options

Introduction After you have set the physical data types, you set the relational logical model
physical name generation options and assign physical names to elements of the
relational logical model. You will not change the conceptual names so that they
remain as a visual semantic link back to the object and fact types in the ORM
source model.
Definition Physical names are the names assigned to elements of a relational logical model
that will generate like elements in the physical schema with the same name.
You change the default physical names to names that are more understandable,
less prone to error during use, or that conform to a database development
standard.
Considerations The elements that you consider when changing physical names are tables,
columns, constraints, and indexes. Visio offers a variety of name generation
options. Due to the large number of possible combinations, you should
experiment with the options to determine how to generate names that meet your
needs. This will minimize the magnitude of the changes that you must manually
make as you fine tune the names.
Common options Two options frequently require changing:

! Use of reference mode
By default Visio will add the reference mode to the object type name. You
can control whether Visio uses the reference mode in naming, and if so,
whether it is used in the object type name, or in the primary key column
name.
Depending on what information you want to see when setting the physical
names, there are three options from which you can choose. These are:
Do not use for naming
The reference mode will not appear in either the object type or the
primary key column name.
Add to object type name
The reference mode will be appended to the table and primary key
column name.
Use as column name
The reference mode will be the primary key column name.
! Spacing character
By default, Visio will place a blank space between words in element names.
You can control whether Visio generates a spacing character in element
names, and if so, what character is generated.
Although blank spacing characters may enhance readability, they can also
make it difficult to use the names accurately. For example, spaces and
underscore characters can be confused, and spaces require special treatment
when referencing names from tools and application programs.
How to Set Physical Names
Set
Set the
theVisio
Visio physical
physicalname
namegeneration
generation options
options
Build
Build the
theproject
projectto
togenerate
generatethe
the relational
relationallogical
logical
model
model
Change
Changethe
thephysical
physicalnames
nameswhere
where appropriate
appropriate

Introduction This page describes the steps required to set physical names in a relational
logical model.
Procedure Use the following procedure to set physical names in a relational logical model:
1. Set the Visio physical name generation options.
The Visio naming option default settings ensure that some level of
standardization is applied to the physical names during a build operation.
Changing these defaults allows you to force the physical names to conform
to other naming conventions that correspond to standards that govern your
database implementations.
2. Build the project to generate the relational logical model.
Building the project allows you to examine the names that Visio generated
based on the options that you set.
3. Change the physical names where appropriate.
Some names may still need to be changed after building the model. For
these elements, you will manually change the physical name to correct the
deficiency. You should migrate the changes back to the ORM source model
so that they are not lost.
Tip Displaying both the conceptual and physical names on the relational
logical model will provide additional context for you when determining how to
set physical names.
Practice: Setting Physical NamesScheduling Theme
! Purpose
! Scenario
! Practice
Mon Tue Wed Thu Fri
8 am
Out of Office:
9 00 Doctors Appt
Manager
1:1 All-han
10 00 Quaterl
Team
11 00 Traini
Brownbag Class
12 pm Lunch: ORM
2 00
Data
Modeling
Project
Data
Modeling
Project
Model Model 3 00
4 00
5 00

Introduction You set physical names as the last step in creating the baseline logical model.
Purpose The purpose of this practice is to familiarize you with the steps used to change
the physical names that are generated during the build process. You will do this
by setting Visio name generation options and changing the physical name for
elements in the relational logical model.
Scenario This practice uses the Scheduling Theme to illustrate setting the physical
names. It includes employees who maintain buildings according to maintenance
schedules.
of that folder.
! Set physical name generation options

1. On the File menu, click Open. Navigate to the practice folder and open
SetPhysicalNames_Scheduling_Project.vsd.
2. On the Database menu point to View, and then click Project.
3. In the Project window, double-click
SetPhysicalNames_Scheduling_ORMSource.vsd to open and display the
ORM source model for this project.
5. In the ORM Document Options window, on the Miscellaneous tab, under
Reference Mode, click Use as column name.
6. On the Miscellaneous tab, under Spacing Character, click None, and then
click OK.
! Build the project to generate the relational logical model

1. On the Window menu, click SetPhysicalNames_Scheduling_Project to
switch to the project file.
Note This project has been built previously, and the tables and
relationships drawn in the starting model. Building the project will update
the physical names in the relational logical model based on the options that
you set.

4. In the Database Document Options window, on the General tab, under
Names visible on diagram, click Both, and then click OK.
Note The physical names for each element appear first, followed by the
conceptual names in braces. Notice the lack of spaces in the physical names.
Also notice that the physical name of the key column does not contain the
reference mode as it would by default.
! Change the physical names where appropriate

1. In the relational logical model, on the Visio drawing surface, double-click
the BuildingRoomwhichseatsCapacity table to open the Database
Properties window.
2. Under Categories, click Definition.
3. In the Database Properties window, ensure that Sync names when typing is
not selected, and then select and change the physical name
BuildingRoomwhichseatsCapacity to Room.
4. Under Categories, click Columns.
5. In the Database Properties window, select and change the physical name
Alpha to BuildingName.
6. Select and change the physical name Number to RoomNumber.
7. Select and change the physical name Numeric to Capacity.
8. Change other physical names according to the information in Table 10.2.
Optionally, change the names in the model that are not identified in the
table, as appropriate.
Table 10.2
Table Physical name New physical name
Building Alpha BuildingName

Building Constructiondatemmddyyyy ConstructionDate
Building LocationCoordinates CampusMapCoordinates
Person Person (table name) Employee
Person FirstnameAlpha FirstName
Person LastnameAlpha LastName
9. In the project window, on the File menu, click Close.

10. Click Yes when prompted to save changes to the model.
11. Click Yes when prompted to migrate changes back to the source model.
12. Save the ORM source model back to its original location.
Next Steps
! Establish secure environment

! Evaluate performance
! Implement DDL

Introduction After you have set physical data types and names, you have a baseline model
that would probably meet many of the needs of both the business users and the
IT department. However, there are several more things that will likely need to
be modified for the model to meet them completely.
Three important areas to consider are security, performance, and procedural
code, which this page describes. The actual steps of making these changes are
out of scope for this course.
Establish secure Security controls the access that users, groups of users, or applications may
environment have to the database. Visio does not allow you to define the security aspects of
a database. You will perform this task after you have created the physical
database.
Evaluate performance Performance, consisting of throughput and response time, is affected by a
number of factors, including the size of the database, the use of indexes, the
layout of data on disk, the number of users, transaction semantics, and the
complexity and frequency of read and write activity.
During refinement of the baseline logical model, you will change the
performance characteristics of the physical model by using Visio, and the
database schema by using other tools, such as adding indexes and using file
groups, respectively. Because of the possible complexities of performance
tuning, you will likely repeat this step of refinement numerous times for
different aspects of the database and different queries.
Implement DDL Visio will generate procedural code (such as constraints) to enforce business
rules. Where possible, Visio will generate the actual data definition language
(DDL) required to create the database object. Often, however, Visio will
provide a code snippet that you must implement as a function, trigger, or stored
procedure, depending on the code generated and the eventual use in the
database.
Lesson Review
Objectives
Objectives
Refine
Refine conceptual
conceptual and
and logical
logical models
models
Set
Set data
datatypes
types
Set
Set physical
physicalnames
names
Consider
Considernext
next steps
steps

1. What is the effect of setting data types in the ORM source model versus the
relational logical model?
Setting an object types data type in the ORM source model will cause
this data type to propagate to all elements in the relational logical
model derived from the object type. If you perform this step in the
logical model, you will have to set every data type, and they will not
propagate to the ORM model.
2. Why is it useful to set physical name generation options?

Setting physical name generation options will cause Visio to create the
physical names that conform to the criteria that you selected. This
ensures uniformity across the entire relational logical model. It also
allows you to force the names to conform to a naming standard that you
are adhering to.
Lesson: Documenting Conceptual and Logical Models
! Why Document a Model?

! Types of Visio Reports
! How to Generate Reports
! Practice: Generating ReportsScheduling Theme

Introduction Just like any other business project, you must document your work when
creating a database. The conceptual and logical model diagrams are forms of
documentation that are useful to people in various roles. In addition, Visio
provides reports that cover a large and varied amount of information about
these models. Use these reports to provide specific data to people in specific
roles.
Lesson purpose The purpose of this lesson is to teach you how to generate reports that
document specific aspects of your models.
! Document conceptual and logical models.
Differentiate conceptual and logical reports.
Generate reports.
Why Document a Model?
! Use of reports
" Document your database design
" Summarize file and database statistics or to document
the tables in your model
" List data types in an object-relational model
" Identify problems with the model, such as entity types
without reference modes

Introduction Documenting your models is an important part of your overall design effort.
Providing the right information to individual project team members will allow
them to better understand the models that you create. These persons may
include application developers, database administrators, business analysts, and
technical reviewers. You can generate reports at any time after information has
been entered into Visio.
Use of reports You can create, preview, print, and export reports based on the contents of the
currently opened model. For example, you can create a report to:
! Document your database design.
! Summarize file and database statistics or to document the tables in your
model.
! List data types in an object-relational model.
! Identify problems with the model, such as entity types without reference
modes.
Types of Visio Reports
! Conceptual
" Constraint Type
" Fact Type
" Object Type
" Supertype
! Logical
" Statistical
" Table
" Types

Introduction Visio has several reports that are built into the user interface (UI) for your
convenience. They are electronic or printed, textual, and graphical documents
that identify and describe the elements of both conceptual and logical models.
Conceptual The reports available in the ORM source model are Constraint Type, Fact Type,
Object Type, and Supertype reports. The following section describes each type.
! Constraint Type
Constraint Type reports provide detailed information about the constraints
in an ORM source model or in a project containing an ORM source model.
! Fact Type
Fact Type reports show information about the facts in an ORM source
model or in a project containing an ORM source model.
! Object Type
Object Type reports show information about the objects in an ORM source
model or in a project containing an ORM source model.
! Supertype
Supertype reports provide information about the subtype and supertype
definitions in an ORM source model or in a project containing an ORM
source model.
Logical The reports available in the database model diagram include those available
from ORM, plus Statistical, Table, and Types from the database model diagram
report menu.
! Statistical
Statistical reports provide a high-level summary of the contents of a
database model diagram.
! Table
Table reports show how objects in your model, such as tables and columns,
will appear in the database that you generate or update from the model.
! Types
Types reports show the composite, user-defined, and built-in data types
represented in your database model diagram.
You can also include attribute information such as type names, base types,
and derived types by using the Attributes tab in the Report dialog box.
How to Generate Reports
Run
Run the
theReport
Report Generation
Generation Wizard
Wizard
Select
Select the
thetype
typeof
ofreport
report
Select
Select report
report options
optionsand
andgenerate
generatereport
report

Introduction Reports are generated from the ORM source model and database model
diagram menus.
Procedure Use the following procedure to generate reports from both the ORM source
model and database model diagram report menus:
1. Run the Report Generation Wizard.
The report wizard will walk you through the steps required to select,
preview, and generate each report.
2. Select the type of report.
Select the report based on your current point in developing the model and
the needs of the audience for the report. Selecting the appropriate report will
make you more effective at communicating details about the model with
other individuals.
3. Select report options and generate the report.
Select the filters to reduce the amount of information in the report and to
limit the report to the information that is required to perform your current
task. Set the attributes (types of information) that will appear on the report.
Set report preferences, sort order, and header and pagination information.
You have the option of previewing the report, exporting it to a Rich Text
Format (RTF) file, or printing it immediately.
Practice: Generating ReportsScheduling Theme
! Purpose
! Scenario
! Practice
Mon Tue Wed Thu Fri
8 am
Out of Office:
9 00 Doctors Appt
Manager
1:1 All-han
10 00 Quaterl
Team
11 00 Traini
Brownbag Class
12 pm Lunch: ORM
2 00
Data
Modeling
Project
Data
Modeling
Project
Model Model 3 00
4 00
5 00

Introduction You will generate reports throughout the design process, depending on your
requirements at the time.
Purpose The purpose of this practice is to introduce you to the procedure for generating
Visio reports and to familiarize you with the content of the reports.
Scenario In this practice, you will generate a Fact Type report based on the database
model diagram for the Scheduling Theme.
Practice
! Run the report generation wizard and select the type of report
1. Open the GenerateReport_Scheduling_Project.vsd database model diagram
file.
2. On the Database menu, click Report.
! Select the type of report

In the New Report Wizard dialog box, under Choose the type of report,
click Fact Type Report, click Next, and then click Finish.
! Select report options and generate the report

Select the report options and generate the report based on the information in
Table 10.3. After you have specified the report, preview it, and then export
it to your My Documents folder. Close the models when you are done.
Table 10.3
Report wizard dialogue box/tab/item Selections
Report, Filter All fact types matching filter

Report Filter All fact types in document(s)
Report, Attributes Select All
Report, Sort/Group, Selected sort keys Accept the defaults
Report, Headers, Report subtitle Type a space after &DocTitle, and
then type &Date (or click Insert to
select Current Date)
Report, Pagination Accept the defaults
Export to RTF, File name FactTypeReport.rtf
Lesson Review
Objectives
Objectives
Document
Document conceptual
conceptual and
and logical
logical models
models
Differentiate
Differentiateconceptual
conceptualand
and logical
logical reports
reports
Generate
Generate reports
reports

1. What reports would you run to view the physical data types for the columns
that will be created in the database?
You will run the Table report. It will contain the tables with their
columns and data types that will correspond to the physical database
schema.
2. What report would you run to view subtyping?

Supertype reports provide information about the subtype and
supertype definitions in an ORM source model or in a project
containing an ORM source model.
Module Review
! Refining Conceptual and Logical Models

! Documenting Conceptual and Logical Models

1. What are the two characteristics that you set to complete a baseline model?
Data types and physical names. Additional modifications that describe
a physical implementation are in the realm of the physical model or
schema.
2. At what stages of development would you document your model?

You can generate reports as soon as you have entered information into
the model. You will create ORM reports to check that the model meets
the business requirements at the conceptual level. You will do the same
at the logical level to validate the relational logical model that Visio has
generated. You will use both types of reports to convey the model to
others who are involved in the project.
Lab A: Completing the Baseline Model
! Exercise 1: Setting Physical Data Types

! Exercise 2: Setting Physical Names
! Exercise 3: Generating Reports

Objectives This lab will reinforce your understanding of the steps that you can take to
correct or refine a logical model after you have completed the conceptual
model.
Prerequisites Before working on this lab, you must be able to:

! Modify data types in ORM.
! Modify name generation defaults in ORM.
! Modify element names in the relational logical model.
! Build modeling projects.
! Check models for errors.
model is provided that represents limited information about the academic staff.
Estimated time to
complete this lab:
30 minutes
Exercise 0
Lab Setup
box.
5. Click OK.
Exercise 1
Setting Physical Data Types
Scenario In this exercise, you will be given both an ORM source model based on the
Academic Theme and a project containing a previously generated and drawn
relational logical model. You will set the data types in the ORM source model
and rebuild the project to propagate the data types to a relational logical model.
Finally, you will run an error check on the logical model to ensure that the data
types meet the sizing criteria for SQL Server 2000.
! Select the ORM source model

Open the SetPhysicalDataTypes_Academic_Project.vsd project, and then
open the project source model from there.
! Set the physical data types in ORM

Set the physical data types in the ORM source model according to the
information in Table 10A.1.
Table 10A.1
Object type Physical data type
Academic char(8)
Date datetime
Degree char(3)
Name varchar(30)
UniversityCode char(4)
! Build the project

Build the project and check for, and correct, errors in data types, if any.
There should be no other warnings or errors.
! Examine the column data types

1. Examine the column data types to see how the data types were propagated
into the model.
2. Save the project and source models to their original locations, and then close
them.
What columns and data type in the relational logical model were generated
as a result of setting the Date object type data type to datetime?
Contract date Date mmddyyyy
____________________________________________________________
____________________________________________________________
Exercise 2
Setting Physical Names
Scenario In this exercise, you will set Visio physical name generation options, rebuild the
model, and change specific names in the relational logical model.
! Set physical name generation options

In the ORM source model, set Use reference mode to use as column name,
and Spacing to None.
! Build the project to generate the relational logical model

1. Build the project to generate the new physical names.
2. Display both the conceptual and physical names to see the differences.
! Change the physical names where appropriate

Change the physical names that ORM generated according to the
information in Table 10A.2. Optionally, change the remaining names as
appropriate. When finished, save your models to their original locations, and
then close them.
Table 10A.2
Table Physical name New physical name
Academic Employee EmployeeID

Academic Contractedmmddyyyy ContractEndDate
Academic IsTenured TenuredFlag
University Code UniversityCode
University KnownAlpha Name
Degree Code DegreeCode
Degree DescriptionAlpha Name
Exercise 3
Generating Reports
In this exercise you will generate Visio reports to view their content and gain an
understanding of their utility.
Practice
! Run the report generation wizard and select the type of report
You will be generating the report based on the
GenerateReport_Academic_Project.vsd project and its corresponding ORM
source model.
! Select the type of report

Choose the Object Type report.
! Select report options and generate the report

Select the report options and generate the report based on the information in
Table 10A.3. After you have specified the report, preview it, and then
export it to your My Documents folder. Close the models when you are
done.
Table 10A.3
Report wizard dialogue box/tab/item Selections
Report, Filter All object types matching filter

Select all
Report, Attributes Accept the defaults
Report, Sort/Group, Selected sort keys Accept the defaults
Report, Headers, Report subtitle &DocTitle, &Date (Click Insert to
select these items)
Report, Pagination Accept the defaults
Export to RTF, File name ObjectTypeReport.rtf
Module 11: Generating
and Reverse
Engineering Physical
Contents
Schema
Module Overview 1
Lesson: Forward Engineering 2
Module Review 21
Lab A: Forward and Reverse Engineering
Physical Schema 22
Course Evaluation 28
other countries.
respective owners.
reserved.
Module 11: Generating and Reverse Engineering Physical Schema iii
Instructor Notes
This module teaches students the skills and knowledge necessary to create a
database from a relational logical model, and also how to create a relational
logical model from an existing database.
Presentation: After completing this module, students will be able to:
75 minutes
! Transfer a data model to and from Microsoft SQL Server 2000.
Lab:
Generate a database from a relational logical model.
30 minutes
Update a database with a modified relational logical model.
Reverse engineer a database into a relational logical model.

iv Module 11: Generating and Reverse Engineering Physical Schema

In this module, students will learn the skills and knowledge to empower them to
generate a database from a relational logical model, to update an existing
database, and to reverse engineer a database into a relational logical model.
Lesson: Forward Engineering

lesson. Make sure that students understand that forward engineering includes
both generating a database schema for the first time, and also updating an
existing database from changes made to an existing relational logical model that
was already used to generate the database.
What Is Forward This page defines and describes forward engineering. It further describes what
Engineering? happens and what does not happen to the data and models during the forward
engineering process.
How to Generate a This page covers the high-level procedure of how to generate a database by
Database using the Generate Wizard.
Practice: Generating a This page reinforces the knowledge offered on the previous page and allows
DatabaseScheduling students to practice the minute steps of generating a database by using the
Theme Generate Wizard.
How to Update a This page covers the high-level procedure of how to update an existing database
Database from a by using the Update Wizard.
Modified Database
Model
Practice: Updating a This page reinforces the knowledge offered on the previous page and allows
DatabaseScheduling students to practice the minute steps of updating a database by using the Update
Theme Wizard.
Lesson Review
Module 11: Generating and Reverse Engineering Physical Schema v
Lesson: Reverse Engineering

lesson.
What Is Reverse This page defines and describes reverse engineering. It further covers the choice
Engineering? that a student must make between Object Role Modeling (ORM) and relational
logical modeling as to which is the better option for reverse engineering. After
reviewing the page, you should point out that ER is the better of the two, not
because it is a superior modeling methodology, but rather because its results
will have less pending work. You should emphasize that the best practice is to
start from the beginning with a new ORM model if students want to recreate an
existing database to correct functionality or enhance performance.
How to Reverse This page covers the high-level procedure of how to reverse engineer a model
Engineer a SQL Server from an existing database. Point out that any database could be reverse
Schema engineered, but this course only focuses on SQL Server databases.
Practice: Reverse This page reinforces the knowledge offered on the previous page and allows
Engineering students to practice the minute steps of reverse engineering a database model
Scheduling Theme from an existing database.
Lesson Review
Module Review
topics covered.
Lab A: Forward and Reverse Engineering Physical Schema

Lab Setup
Lab Results
customization.
Module 11: Generating and Reverse Engineering Physical Schema 1
Module Overview
! Forward Engineering
! Reverse Engineering

Introduction This module presents the knowledge and skills necessary to generate a database
from a relational logical model, update it with changes made to the original
model, and also to reverse engineer a database into a relational logical model.
! Transfer a data model to and from Microsoft SQL Server 2000.
Generate a database from a relational logical model.
Update a database from a modified relational logical model.
Reverse engineer a database into a relational logical model.
2 Module 11: Generating and Reverse Engineering Physical Schema
Lesson: Forward Engineering
! What Is Forward Engineering?

! How to Generate a Database
! Practice: Generating a DatabaseScheduling Theme
! How to Update a Database from a Modified Database
Model
! Practice: Updating a DatabaseScheduling Theme

Introduction In this lesson, you will learn how to forward engineer, or generate a database
from a relational logical model. In addition, you will learn how to update a
database with changes made to an existing relational logical model.
! Generate a database from a relational logical model.
! Update a database from a modified relational logical model.
What Is Forward Engineering?
! Definition
Forward engineering is the process of generating a new database or
updating an existing database from a relational logical model
Author Author writes Book Book
PK Author ID PK,FK1 Author ID PK Book TitleID

PK,FK2 Book TitleID
LastName U1 Title
SQL

Introduction Now that you have completed a baseline relational logical model, you can
convert the model into an actual database. To do this, you will forward engineer
your model.
Definition Forward engineering is the process of generating a new database or updating an
existing database from a relational logical model.
The Microsoft Visio Enterprise Architect edition setup application
automatically selects Microsoft Access as the default Visio database driver. To
generate a database model for a different database management system
(DBMS), you must set the default driver to the DBMS that you are targeting, in
this case, SQL Server.
Before you link Visio to a database, you must create a connection to the
database server upon which the new database will reside. That connection is a
data source, also referred to as a data source name (DSN). The DSN resides on
the local computer. It identifies the target database server, the database driver,
and the physical database, as well as security, network connection information,
and other parameters required to make the connection.
How to Generate a Database
Execute
Execute the
theGenerate
Generate Wizard
Wizard
Create
Create the
theinitial
initialDSN
DSN
Generate
Generatethe
thedatabase
database
Review
Review the
thedatabase
database

Introduction After you have created and refined your model, use Visio to generate the actual
database and the Data Definition Language (DDL) associated with creating it.
Visio uses the Generate Wizard to perform this function. You will perform a
model error check as part of this procedure.
Procedure Use the following procedure to generate a database from a Visio modeling
project:
1. Run the Generate Wizard.
The Generate Wizard guides you through all of the steps necessary to
generate a database. In addition, you have the option of generating and
viewing the DDL that corresponds to the database schema that Visio
generates when it creates the database.
2. Create the initial DSN.
The Generate Wizard prompts you to create the DSN and to specify the
database driver options that it uses to communicate with SQL Server when
creating the database. You can then use this DSN to create other databases.
3. Generate the database.
The Generate Wizard continues to prompt you for information used for the
creation process. It then generates the SQL Server database if you choose
that option.
Note You can also create the DDL script and use it to manually create the
database by using a tool such as SQL Query Analyzer. In either case, the
database schema will be the same.
4. Review the database.

Open SQL Server Enterprise Manager to view the database tables, stored
procedures, default values, and other components.
Practice: Generating a DatabaseScheduling Theme
! Purpose
! Scenario
! Practice
Mon Tue Wed Thu Fri
8 am
Out of Office:
9 00 Doctors Appt
Manager
1:1 All-han
10 00 Quaterl
Team
11 00 Traini
Brownbag Class
12 pm Lunch: ORM
Starting 1 00
2 00
Data
Modeling
Project
Data
Modeling
Project
Model 3 00
4 00
5 00

Purpose The purpose of this practice is to familiarize you with the procedure of using
the Visio Generate Wizard to create a DSN and generate a SQL Server
database.
Scenario This practice uses the Scheduling Theme model that you are already familiar
with.
Practice You will generate the Scheduling database, including creating a DSN, by using
the Visio Generate Wizard. You will use the files in the C:\MOC\2090\
Practices\Mod11 folder to complete this practice. Solution files for this practice
are located in the Answer subdirectory of that folder.
Important The practices in this module require that the Visio database driver is
set to Microsoft SQL Server. Verify that this is the case by opening the
Database Drivers window from the Database, Options, Drivers menu, and
then verifying that Microsoft SQL Server is selected. Close the window when
done.
! Run the Generate Wizard

1. Open the Generate_Scheduling_Project.vsd file.
2. On the Database menu, point to Model, and then click Error Check.
Check for errors in the model. There should be none.
3. On the Visio menu bar, click Database, and then click Generate.
The Generate Wizard dialog box appears.
4. In the Generate Wizard dialog box, click Generate a new database, and
then click Next.
5. In the Installed Visio drivers box, select Microsoft SQL Server.
! Create the initial DSN

Click New to create a new data source name.
The Create New Data Source Wizard opens.
Complete the Create a New Data Source Wizard by using the information in
Table 11.1 Test the data source when the option is available.
Important Do not change the wizard defaults unless instructed to do so.
Table 11.1
Item Selection or input
User Data Source Selected

Select a driver for which you want to set SQL Server
up a data source
Name CreateDatabase
Server Your classroom computer name
! Generate the database

1. Continue executing the Generate Wizard by using the information in Table
11.2.
Table 11.2
Data source name CreateDatabase

Database name Scheduling
2. In the Connect Data Source window, click OK.

It is not necessary for you to type your user name and password because you
are connecting to the database using integrated security.
3. In the SQL Server Create Database dialog box, click Close.
Visio will create the database and log files of Scheduling and
Scheduling_log automatically in the SQL Server data folder, which is
C:\Program Files\Microsoft SQL Server\MSSQL\Data\.
Important In this practice, Visio creates the database and log files on the
same drive. In reality, you must place them on separate disk drives to be
able to recover the database in the event of disk failure.
4. In the Microsoft Visio dialog box, click Yes when asked whether you want
to view the generated DDL script.
Visio opens the Code Editor window displaying the DDL script that was
used to create the database.
5. Review the generated DDL and the progress information in the Database
Model Diagram window and in the Visio Output window to become
familiar with their contents.
Important Visio does not generate or reverse engineer security settings.

Because you do not capture these in an ORM or relational logical model,
you must define them on the target database.
! Review the database by using SQL Server Enterprise Manager

1. Click Start, point to All Programs, point to Microsoft SQL Server, and
then click Enterprise Manager.
2. In the SQL Server Enterprise Manager window, under Console Root,
double-click Microsoft SQL Servers to expand it and expose the SQL
Server Group.
3. Expand SQL Server Group.
Your server name will appear.
4. Expand your local server, expand Databases, and then expand the
Scheduling database.
5. Under the Scheduling database, right-click Tables, and then click New
Window from Here.
6. In the Tables window, right-click Building, and then click Design Table.
7. In the Design Table window, right-click one of the rows above the window
divider line, and then click Indexes/Keys.
The Properties window will appear.
8. Explore the tabs on the Properties window to review the contents.
9. Close your models and exit SQL Server Enterprise Manager.
How to Update a Database from a Modified Database Model
Make
Make changes
changesto
to the
theexisting
existingmodel
model
Run
Run the
theUpdate
Updatewizard
wizard

Introduction Over time, you may need to make changes to your database schema to support
evolving business needs. The recommended practice is to make the changes to
the ORM source model, or the relational logical model if appropriate, and then
to update the database with those changes.
Procedure Use the following procedure to update a database from a modified database
model:
1. Make changes to the existing model.
After you make changes, you will perform an error check on the updated
models and on the rebuilt relational logical model, before you update the
schema.
2. Run the Update Wizard.
The Update Wizard examines the existing database schema that was stored
in Visio during the generate process and compares it with the current model.
You may also choose to have Visio compare the physical schema with the
model stored in Visio from the generate or the last update to determine
whether changes have been made to the database that have not been reverse
engineered in the Visio model.
Practice: Updating a DatabaseScheduling Theme
! Purpose
! Scenario
! Practice
Mon Tue Wed Thu Fri
8 am
Out of Office:
9 00 Doctors Appt
Manager
1:1 All-han
10 00 Quaterl
Team
11 00 Traini
Brownbag Class
12 pm Lunch: ORM
2 00
Data
Modeling
Project
Data
Modeling
Project
Model Model 3 00
4 00
5 00

Purpose The purpose of this practice is for you to become familiar with the process of
updating a database from a data model to which you have recently made
changes.
with.
Practice You will update the Scheduling database that you generated in the previous
practice by using the Visio Update Wizard. You will use the files in the
C:\MOC\2090\Practices\Mod11 folder to complete this practice. Solution files
for this practice are located in the Answer subdirectory of that folder.
! Make changes to the existing modeladd a value constraint

In this exercise, you will add an item to an attribute value constraint.
1. Open the Update_Scheduling_Project.vsd file.
2. On the Database menu, point to View, and then click Project.
3. In the Project window, double-click Update_Scheduling_ORMSource.vsd
to open it.
4. On the Visio drawing surface, double-click the Capacity value type.
This will open the Database Properties window for this object.
5. In the Database Properties window, under Categories, click Value.
6. Under Range, in the From box, type 1
7. In the To box, type 500, and then click Add.
! Make changes to the existing modeladd a fact type

1. On the Database menu, point to View, and click Fact Editor.
2. Add the fact type Person has birth date of Date.
3. Add the example data in Table 11.3 to the new fact type.
Table 11.3
Person Date
112039 04/07/1950
231156 04/07/1950
115324 03/04/1953
298843 02/18/1983
4. Add a Uniqueness Constraint over the Person related role.

5. Perform an error check and save the ORM Source model.
6. Switch to the Update_Scheduling_Project window.
7. On the Database menu, point to Project, and click Build.
8. In the Employee table, change the new column physical name from
Birthdatemmddyy to BirthDate.
9. Perform an error check and save the relational logical model.
! Run the Update Wizard

1. On the Visio menu bar, click Database, and then click Update.
The Visio Update Wizard dialog box appears.
2. Run the wizard by using the information in Table 11.4.
Table 11.4
Update the database Selected

Detect changes in the database Cleared
3. In the Update Wizard dialog box, in the Installed Visio drivers box, select
Microsoft SQL Server.
! Create the Scheduling DSN

1. Click New to create a data source name.
2. Complete the Create a New Data Source Wizard by using the information in
Table 11.5 Test the data source when the option is available. Click Test
your data source at the appropriate time to ensure that you have created it
correctly. Click Next, and not Finish when given the choice.
Table 11.5
User Data Source Selected

Select a driver for which you want to set SQL Server
up a data source
Name Scheduling
Server Your classroom computer name
Change the default database to Scheduling
3. In the Connect Data Source window click OK, and then click Finish.
! Update the database

1. Review the changes that will be made by expanding the table names when
this option is available, and then click Finish.
2. In the Microsoft Visio dialog box, click Yes when asked whether you want
to view the generated DDL script.
Visio opens the code window, displaying the DDL script used to create the
database.
3. Review the generated DDL and the progress information in the Database
Model Diagram window and in the Visio Output window to become
familiar with their contents and to see how Visio updated the existing
database to match your model changes.

1. Click Start, point to All Programs, point to Microsoft SQL Server, and
then click Enterprise Manager.
2. In the SQL Server Enterprise Manager window, under Console Root,
double-click Microsoft SQL Servers to expand it and expose the SQL
Server Group.
3. Expand SQL Server Group.
Your_server_name appears.
4. Expand your local server, expand Databases, and then expand the
Scheduling database.
5. Under the Scheduling database, right-click Tables, and then click New
Window from Here.
6. In the Tables window, right-click Room and click Design Table.
7. In the Design Table window, right-click one of the rows above the window
divider line, and click Check Constraints.
The Check Constraints tab in the Properties window appears.
8. Note the check constraint that corresponds to the value constraint you added
to the ORM source model.
([SeatingCapacity] >=1 and [SeatingCapacity] <= 500)
9. Close your models and exit SQL Server Enterprise Manager.

Lesson Review
Objectives
Objectives
Generate
Generateaa database
databasefrom
from aarelational
relationallogical
logicalmodel
model
Update
Updateaadatabase
databasewith
with aamodified
modified relational
relational logical
logical
model
model

1. What is the default database driver for Visio, and why is this relevant?
Visio includes drivers for many of the most common databases in use
today. The Visio setup program automatically selects Microsoft Access
as the default Visio database driver. To create a database model for a
different database management system, such as SQL Server, set the
Visio database driver for the DBMS that you are targeting as the
default driver.
2. Why is it important to make changes to your source and relational logical

models and not directly to the database?
Because this practice ensures that the models always reflect the current
database.
Lesson: Reverse Engineering
! What Is Reverse Engineering?

! How to Reverse Engineer a SQL Server Schema
! Practice: Reverse EngineeringScheduling Theme

Introduction In this lesson, you will learn how to reverse engineer a database into a relational
logical model. You will not learn how to reverse engineer into an ORM, or
conceptual model. Reverse engineering a database into ORM leaves several
areas incomplete.
! Reverse engineer a database into a relational logical model.
What Is Reverse Engineering?
! Definition
Reverse engineering is the process of creating a model from an
existing database schema
! Relational logical model
Author Author writes Book Book
PK Author ID PK,FK1 Author ID PK Book TitleID

PK,FK2 Book TitleID
LastName U1 Title
! ORM Book
Title
(TitleID)
writes / is written by has
Author
(AuthorID)
LastName
has

Introduction Visio supports reverse engineering an existing database into a relational logical
model or into an ORM source model.
Definition Reverse engineering is the process of creating a model from an existing
database schema.
It is the opposite of forward engineering. Reverse engineering an existing
database into a relational logical model is a useful function because it allows
you to document the database schema. However, when reverse engineering into
an ORM model, some of the business semantics are lost. It is recommended that
you reverse engineer into a relational logical model.
Relational logical model When you reverse engineer a database into a relational logical model, you can
immediately use it. Tables and columns, indexes, and procedural code, are
present in recognizable forms. You can document an existing design by using
the relational logical model reports.
ORM It is out of the scope of this course to cover all the details of the limitations of
reverse engineering into ORM. However, the information in Table 11.6 details
a few of the pending work items that could exist.
Table 11.6
Pending work item Cause
Subtyping Visio does not recognize subtyping in a relational

database.
Derivation rules Visio cannot interpret the database code that forms
derivation rules.
Set and ring constraints Visio cannot interpret the database code that enforces set
and ring constraints.
Predicate names The relational database does not contain the notion of
predicate names.
Denormalization Visio will not recognize that a denormalized database is
in violation of ORM rules.
Columns Your ORM model would contain all of the columns from
the database, leaving a large amount of clutter on the
drawing surface.
How to Reverse Engineer a SQL Server Schema
Create
Create aaDatabase
DatabaseModel
ModelDiagram
Diagram
Reverse
Reverseengineer
engineerthe
theexisting
existingdatabase
database

Introduction Reverse engineering an existing SQL Server database is the process whereby
the schema for the database is extracted and stored as a Visio model.
Procedure Use the following procedure to reverse engineer a SQL Server database into a
Visio relational logical model:
1. Create a Database Model Diagram.
The Database Model Diagram contains the reverse engineered relational
logical model and allows you to represent it as a diagram.
2. Reverse engineer the existing database.
The Reverse Engineering Wizard prompts you for information used for the
extraction process. It will then populate the relational logical model from
the SQL Server database schema.
Practice: Reverse EngineeringScheduling Theme
! Purpose
! Scenario
! Practice
Mon Tue Wed Thu Fri
8 am
Out of Office:
9 00 Doctors Appt
Manager
1:1 All-han
10 00 Quaterl
Team
11 00 Traini
Brownbag Class
12 pm Lunch: ORM
Solution 1 00
2 00
Data
Modeling
Project
Data
Modeling
Project
Model 3 00
4 00
5 00

Purpose The purpose of this practice is for you to become familiar with the process of
reverse engineering a database into a data model.
with.
Practice You will reverse engineer the Scheduling database you previously created into a
new Database Model Diagram. You will use the files in the C:\MOC\2090\
Practices\Mod11 folder to complete this practice. Solution files for this practice
are located in the Answer subdirectory of that folder.
! Create a new Database Model Diagram

1. Start Visio.
2. On the File menu, point to New, point to Database, and then click
Database Model Diagram.
3. On the Database menu, point to Options, and click Document.
4. On the Relationship tab, under Show, select Crows feet.
5. On the Table tab, under Data types, select Show Physical.
! Reverse engineer the existing database

1. On the Database menu, click Reverse Engineer.
The Reverse Engineer Wizard window will appear.
2. Run the Reverse Engineer Wizard by using the information in Table 11.7.
In the Connect Data Source window click OK.
Table 11.7
Item Action
Data sources Scheduling

Select tables and/or views to reverse engineer Click Select All.
When you click Finish, Visio will reverse engineer the Scheduling database
and layout the elements on the drawing surface.
3. Review the items on the drawing surface and their properties and compare
them with the database by using SQL Server Enterprise Manager.
4. On the Visio menu bar, click Database, point to View, and then click Code.
Examine the check constraint code that Visio imported from the Room
table. In the Code window, notice that the fully qualified name indicates on
which object the constraint is found.
Note Even though the value check constraint does not appear as a
constraint on the Room table in the Database Properties window, Visio does
associate it with the Capacity column in that table and will generate it on the
Capacity column when forward engineering this model into a new database.
5. On the Visio menu bar, click File, click Save, and close your models.
Lesson Review
Objective
Objective
Reverse
Reverseengineer
engineeraadatabase
databaseinto
into aarelational
relational logical
logical
model
model

1. When reverse engineering an existing database, what is the suggested
modeling type to build?
Relational logical model.
2. Why is this a more appropriate type?

When reverse engineering into an ORM model, much of the business
semantics are lost.
Module Review
! Forward Engineering
! Reverse Engineering

1. Describe the difference between generating and updating a database.
To generate a database is to create a database, which does not presently
exist, from a model. To update a database is to make changes to a
model and then replicate those changes in a database that was already
generated from the same model, before you made these changes.
2. Why would you reverse engineer a database?

To document it by using the relational logical model reports and to
communicate the design to others.
Lab A: Forward and Reverse Engineering Physical

Schema
! Exercise 1: Generating a Database from a
Logical Model
! Exercise 2: Updating an Existing Database
! Exercise 3: Reverse Engineering an
Existing Database

Objectives This lab will reinforce your understanding of the steps that you take to create a
physical database from a logical model, to update that database from a modified
model, and to reverse engineer an existing database.
! Transfer a data model to and from SQL Server.
Generate a database from a database model.
Update a database with a modified database model.
Reverse engineer a database model from a database schema.
Prerequisites Before working on this lab, you must be able to:

! Modify element names in the conceptual model.
! Build modeling projects.
! Create a DSN.
! Perform the steps to generate, update, and reverse engineer a database
schema.
Scenario You will use the Academic Theme that you are already familiar with in this lab.
In the first exercise, you will work with an existing database project to generate
a new physical database.
In the second exercise, you will refine the model, rebuild the project, and
update the physical database with those changes.
In the third exercise, you will reverse engineer the SQL Server database schema
into a relational logical model and review the contents of the logical schema.
Estimated time to
complete this lab:
30 minutes
Exercise 0
Lab Setup
box.
5. Click OK.
Exercise 1
Generating a Database from a Logical Model
The goal of this exercise is for you to generate a database from a logical model.
In this exercise, you will use the Generate Wizard to generate the Academic
database. You will then compare tables in the database schema with the
corresponding entities in the logical model.
Important The exercises in this lab require that the Visio database driver is set
to Microsoft SQL Server. Verify that this is the case by opening the Database
Drivers window from the Database, Options, Drivers menu, and verifying that
Microsoft SQL Server is selected. Close the window when done.
! Run the Generate Wizard

1. Open the GenerateAcademic_Project.vsd modeling project file.
2. Run the Generate Wizard to begin the generate process.
When required to specify the DSN, do not create a new one. Use the
CreateDatabase DSN that you previously created on your computer.
! Generate the Academic database

1. Continue using the Generate Wizard to create the Academic database.
2. Review the DDL used to create the academic database.
Note The DDL used to enforce the exclusive-or constraint across the roles
associated with whether an Academic is either tenured or has a contract
date. He or she must have one or the other.
/* Create table level checks for table Academic.*/

alter table "Academic" add constraint Academic_MR check
( ("ContractEndDate" is not null) or ("TenuredFlag" = 1) )
go
alter table "Academic" add constraint Academic_excl check

( ("ContractEndDate" is null) or ("TenuredFlag" = 0) )
go

Run SQL Enterprise Manager and review the tables and other objects
created by the Generate Wizard. Compare them with the information in the
Exercise 2
Updating an Existing Database
In this exercise, you will use Visio to add two new fact types to the ORM
source model. You will then rebuild the project, and, finally, run the Update
Wizard to make the changes permanent in the database.
! Make changes to the ORM source and logical models

1. In the ORM source model, add the fact types Academic has first name of
Name and Academic has last name of Name, and a uniqueness constraint
over the role associated with Academic on each of the fact types.
You may enter example data if you would like.
2. Build the project to migrate your changes in ORM to the relational logical
model.
Change to new column names to be more meaningful.
! Create the Academic user DSN

While using the Update Wizard, create a user DSN with the name of
Academic, pointing to the Academic database on your server.
! Update the database

1. Continue to run the Update Wizard to make the changes to the SQL Server
database.
2. View the Transact-SQL script generated by the wizard to see the code that is
associated with the changes that you made to the ORM source model.
! Review the changes by using SQL Enterprise Manager

By using SQL Enterprise Manager review the changes in the actual
database.
Exercise 3
Reverse Engineering an Existing Database
In this exercise, you will reverse engineer the Academic database you
previously updated and review its design in a Database Model Diagram. You
will not work with ORM during this exercise.
! Run the Reverse Engineer Wizard

1. Run the Reverse Engineer Wizard from a new Database Model Diagram and
extract the Academic schema from SQL Server.
Select all tables when prompted.
2. Set Crows feet notation and show physical data types in the relational
logical model.
3. Review the extracted items and their properties and compare them with the
database in SQL Server Enterprise Manager.
4. Save and close your relational logical model.
Course Evaluation

Your evaluation of this course will help Microsoft understand the quality of
your learning experience.
To complete a course evaluation, go to http://www.metricsthatmatter.com/
survey/.
Microsoft will keep your evaluation strictly confidential and will use your
responses to improve your future learning experience.

2090A - Modeling Business Requirements To Create A Database Using Microsoft Visual Studio .NET Enterprise Architect PDF

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

2090A - Modeling Business Requirements To Create A Database Using Microsoft Visual Studio .NET Enterprise Architect PDF

Загружено:

Авторское право:

Доступные форматы

Modeling Business Requirements

to Create a Database Using

Part Number: X08-87912

2002 Microsoft Corporation. All rights reserved.

Course Number: 2090A

Module 5: Adding Uniqueness Constraints and Checking Arity of Fact

Module 10: Completing the Baseline Model

About This Course

Trainer Materials Compact Disc Contents

Student Materials Compact Disc Contents

Bold Represents commands, command options, and syntax that must

THIS PAGE INTENTIONALLY LEFT BLANK

2002 Microsoft Corporation. All rights reserved.

Preparation tasks To prepare for this course, you must:

How to Teach This Module

*****************************ILLEGAL FOR NON-TRAINER USE******************************

*****************************ILLEGAL FOR NON-TRAINER USE******************************

! Course evaluation. To provide feedback on the course, training facility, and

! Additional resources. You can find additional information about Object

For more details on information modeling, read Information Modeling and

! Familiarity with databases and their uses

*****************************ILLEGAL FOR NON-TRAINER USE******************************

*****************************ILLEGAL FOR NON-TRAINER USE******************************

Course Outline (continued)

! Module 7: Adding Value and Set Constraints, and

*****************************ILLEGAL FOR NON-TRAINER USE******************************

*****************************ILLEGAL FOR NON-TRAINER USE******************************

All computers in the classroom environment belong to a single domain, on a

Initial Logon Procedure

Passwords in MOC courses must be complex.

*****************************ILLEGAL FOR NON-TRAINER USE******************************

Tasks ! Log on to your account

! Change your password

Setting Screen Resolution

*****************************ILLEGAL FOR NON-TRAINER USE******************************

! Log on to your account

! Change your screen resolution

Microsoft Official Curriculum

*****************************ILLEGAL FOR NON-TRAINER USE******************************

Microsoft Certified Professional Program

*****************************ILLEGAL FOR NON-TRAINER USE******************************

*****************************ILLEGAL FOR NON-TRAINER USE******************************

2002 Microsoft Corporation. All rights reserved.

Important This course is different from many other Microsoft Official

After completing this module, students will be able to:

Preparation tasks To prepare for this module:

How to Teach This Module

Lesson: Overview of Database Modeling Process

Lesson: Data Modeling Concepts

Lab A: Examining External Information

! Overview of Database Modeling Process

*****************************ILLEGAL FOR NON-TRAINER USE******************************

Lesson: Overview of Database Modeling Process

! Practice: Examining a Scheduling Modeling Theme

*****************************ILLEGAL FOR NON-TRAINER USE******************************

Practice: Examining a Scheduling Modeling Theme

Mon Tue Wed Thu Fri

*****************************ILLEGAL FOR NON-TRAINER USE******************************

Mon Tue Wed Thu Fri

! Determine the scope of the sample

4. In a class discussion, compare and contrast your individual answers.

! Identify things of interest and relationships

3. Describe the relationships between the things of interest.

*ILLEGAL FOR NON-TRAINER USE**

*ILLEGAL FOR NON-TRAINER USE**

*ILLEGAL FOR NON-TRAINER USE**

*ILLEGAL FOR NON-TRAINER USE**

*ILLEGAL FOR NON-TRAINER USE**

*ILLEGAL FOR NON-TRAINER USE**

*ILLEGAL FOR NON-TRAINER USE**

*ILLEGAL FOR NON-TRAINER USE**

*ILLEGAL FOR NON-TRAINER USE**

*ILLEGAL FOR NON-TRAINER USE**

*ILLEGAL FOR NON-TRAINER USE**

*ILLEGAL FOR NON-TRAINER USE**

*ILLEGAL FOR NON-TRAINER USE**

*ILLEGAL FOR NON-TRAINER USE**

*ILLEGAL FOR NON-TRAINER USE**

*ILLEGAL FOR NON-TRAINER USE**

*ILLEGAL FOR NON-TRAINER USE**

*ILLEGAL FOR NON-TRAINER USE**

*ILLEGAL FOR NON-TRAINER USE**

*ILLEGAL FOR NON-TRAINER USE**

*ILLEGAL FOR NON-TRAINER USE**

*ILLEGAL FOR NON-TRAINER USE**

*ILLEGAL FOR NON-TRAINER USE**

*ILLEGAL FOR NON-TRAINER USE**

*ILLEGAL FOR NON-TRAINER USE**

*ILLEGAL FOR NON-TRAINER USE**

*ILLEGAL FOR NON-TRAINER USE**

*ILLEGAL FOR NON-TRAINER USE**

*ILLEGAL FOR NON-TRAINER USE**

*ILLEGAL FOR NON-TRAINER USE**

*ILLEGAL FOR NON-TRAINER USE**

*ILLEGAL FOR NON-TRAINER USE**