Download 2010SprDmaProceduresv3 - MIS315-05

Database Applications GIT 150
Overview
Methodology and Documentation
Modeling Procedures
Model Translation
Object Orientation
Product Data Exchange Standard
Enterprise Model Utilization & Summary
Database Applications GIT 150
Information Modeling
• Definition:
– A structured (primarily graphical) set of rules for
representing the file and database information and business
process requirements.
• Purpose:
– To provide a “template” for managing and integrating the
information used and/or produced in support of a business
and/or personal need(s).
• Benefit:
– The information model provides the design foundation for
implementing a physical database(s). This “template” is
essential to avoid constant redesign of a physical
database(s) as the scope is extended.
Database Applications GIT 150
Sample Information Model
Database Applications GIT 150
Why Information Modeling Is Needed for
Designing Database Applications
• Traditional information system development
approaches contain inherent weaknesses.
• Increasingly complex information systems are being
developed.
• Complexity of modern systems increases
development risks.
Database Applications GIT 150
The Problem: Timely Access to Critical
Information
Is this the
current version
of the Design?
Who is
responsible?
Who can I
call?
What is the
failure rate of
this Part?
Database Applications GIT 150
How Is An Information Model Built?
• Starts with good business process or workflow activity information needs analysis.
Database and
Application Design
User Requirements Analysis
USED AT :
AUTHOR :
PROJECT, IDS
DATE :
REV:
NOTES : 1 2 3 4 5 6 7 8 9 10
WORKING
DRAFT
X RECOMMENDED
PUBLICATON
READER
DATE
CONTEXT :
Physical_Unit_Occurrence
CONTRACT AND MISSION REQMTS
NONCONFORMANCE
DOCUMENTATION
Usage
26,6 Function_Domain
Port
Functional_Domain_Port
Allocation
ANALYZE FOR
REPAIR
DISPOSITIONING
DISCREPANT PART W / DOC. REFERING PART BACK TO MFG FOR REWORK
source
element
L[1:?]
NONREWORKABLE DISCREPANT PART
DISCREPANT
PART
A1421
ANALYZE FOR
STANDARD
DISPOSITIONING
DISCREPANT PART
descendent
Physical_Connectivity
Defintion
DISCREPANT PART W / DOC REFERING PART
FOR STANDARD REPAIR
Path_Element
NON STANDARD REPAIRABLE PART
ENGR DWGS AND ANALYSIS
A1422
DISCREPANT PART
ENGR DWGS AND ANALYSIS
ANALYZE FOR
DISPOSITION
BY UNIQUE
REPAIR
PROCEDURES
A1423
NODE :
A142
TITLE :
DETERMINE REPAIR DISPOSITION REQUIRED
DISCREPANT PART
W / DOC REFERING
DISPOSITION
TO MR ACTION
DISCREPANT
PART NOT
DISPOSITIONED
BY MR ACTION
Functional_Connectivity
implementation
Defintion
BOOLEAN
requirement
restricted
Connectivity_Allocation
NUMBER
Business Process Requirements
Analysis
Application Specific
Information Model
Local to Enterprise
Mapping
Information
Standards
- Hardware
- Software
- Database
- Network
- Platforms
- Budget
- Schedule
Corporate Constraints
(Standards)
Enterprise
Information
Model
Integrate-able
Database Applications
Application Interpreted
Information Model
(Design Specification)
Database Applications GIT 150
How Is An Information Model Built?
(continued)
• From document, report and database decomposition.
CHANGE
ORDERS
GEOMETRIC
CONFIGURATION
CHANGE
REVISION
NOTES
PART
SHAPE
PART
PART
LIST
(BOM)
PART
INSTRUCTIONS
PART
APPROVAL
TASK
PART
RELEASE
PART
EFFECTIVITY
Database Applications GIT 150
Overview
Methodology and Documentation
Modeling Procedures
Model Translation
Object Orientation
Product Data Exchange Standard
Enterprise Model Utilization & Summary
Database Applications GIT 150
What Is an Information Model?
• A structured, primarily graphical, set of rules for
representing information of interest to a community.
– Specifies information needed to support the activities of a
business.
• Depicts real or abstract objects, their characteristics
and relationships to one another.
• Two types:
– Logical models/schemas
– Physical models/schemas.
Database Applications GIT 150
Logical and Physical Information Models
• Logical
– Defines information requirements in the form of a set of
non-redundant technical and management data declarations,
but does not include the design considerations and physical
storage parameters.
– A logical schema contains entities made up of attributes,
and connected by relations.
• Physical
– Contains all the needed logical and physical design choices
and physical storage parameters needed to generate a
design in a data definition language, which can then be
used to create a database.
Database Applications GIT 150
The Modeling Languages
• Several techniques/languages have been developed for the
design of information models. While these methodologies
guide modelers in their work, two different people using
the same methodology will often come up with different
results.
• Some are based upon a Relational paradigm, others on
Object-Oriented paradigm, and some are hybrids.
Examples include:
– Entity-relationship diagrams (R)
– IDEF-1x (R), IDEF-4 (O)
– Object Role Modeling (ORM) or Nijssen's Information Analysis
Method (NIAM) (H)
– EXPRESS, EXPRESS-G (O)
– RM/T (R)
– UML (O)
Database Applications GIT 150
Sample Information Model
(Relational - IDEF 1X)
(SET TYPE)
Database Applications GIT 150
Sample Information Model
(Object Oriented - EXPRESS G)
hair
children S[0:?]
(INV) parents
S[0:2]
person
(DER) age
hair_type
birth_date
date
A[1:3]
INTEGER
first_name
last_name
INTEGER
STRING
nickname
1
*husband
male
female
wife
*maiden_name
Database Applications GIT 150
How Is an Information Model Documented?
• With a modeling language/methodology in conjunction with a data
dictionary repository.
– A data dictionary is a set of metadata that contains definitions and
representations of data elements.
– A data dictionary holds the following information:
•
•
•
•
•
•
Precise definition of the information elements
Usernames, roles and privileges
Integrity constraints
Stored procedures and triggers
General database structure
Space allocations
• One benefit of a well-prepared data dictionary is a consistency
between data items across different tables. For example, several
tables may hold telephone numbers; using a data dictionary the
format of this telephone number field will be consistent.
• Both the methodology (e.g., IDEF1x) and data dictionary are
required to fully understand the content of the information models.
Database Applications GIT 150
Information Models Contain
• Entities/Objects:
– A generalization of a real or abstract thing.
– Example : part, system, or person
– MS Access  Table
• Attributes/Characteristics:
– A fact or property about an object.
– Example : part name, or system number
– MS Access  Field
• Relationships/Relations:
– The association between two entities/objects.
– Example : a system contains many parts
– MS Access  Relationship
Database Applications GIT 150
Entity
• A class of objects about which one wishes to retain
data
• Identifies places, things or events that have common
characteristics
• Uniquely identifiable
• Named with a noun or noun phrase
• Represented by a box on the IDEF1x diagram
Database Applications GIT 150
Entity Rules
• Each entity must have a unique name and same
meaning must always apply to same name
• An entity must have one or more characteristics
which uniquely identify every instance of the entity
• Every entity must have one or more characteristics
which are either owned by the entity or inherited
through a relationship
Database Applications GIT 150
Entity Instance
• An occurrence of an entity
• Entity instances are the information that goes into a
database
• They are not represented in an information model
• An information model captures the structure of the
instance meanings
– - Characteristics
– - Characteristics Values
= Information Model
= Data Base
Database Applications GIT 150
Entity Example
Entity
Characteristics
MOVIE
Movie Number
Instances
Name
Rating
Rental Rate
12345345
Die Hard
PG13
$3
23456781
Wings
PG
$2
65656565
Black Beauty
G
$2
CUSTOMER
Cust Number
Name
Address
12 Oak St
Status
Code
123-345
Tom Jones
789-789
Mary Sullivan 456 Hill Ave
Pend
567-342
Bob Waters
OK
7676 Scutter Rd
OK
Database Applications GIT 150
Attributes
• The characteristics of entities
• A common property for all entity instances
• Identified by a noun phrase that describes the
characteristics being depicted
• Represented as text inside the entity box on the
IDEF1x diagram
• May be either identifying (key) or non-identifying
(non-key)
Database Applications GIT 150
Attribute Rules
• Each attribute must have a unique name and same
meaning must always apply to the same name
• Every attribute is owned by exactly one entity but can
be related to many others
• Every instance of an entity must have a value for
every attribute (no-null rule)
• No instance of an entity can have more than one
value for an attribute (no-repeat rule)
Database Applications GIT 150
Key Attributes
• An attribute or set of attributes whose values uniquely
identify instances of an entity
• Placed at the top of the attribute list within an entity
box
ENTITY
KEY ATTRIBUTE
MOVIE
Movie Number
Database Applications GIT 150
Non-Key Attributes
• A property or characteristic of an entity that is not
part of the key
• Placed after the key attributes and separated by a
horizontal line crossing the entity box
ENTITY
KEY ATTRIBUTE
NON-KEY ATTRIBUTE
MOVIE
Movie Number
Name
Rating
Rental Rate
Database Applications GIT 150
Relationships
• Identify associations between pairs of entities
• Two types of relationships
– Category
– Connection
• Represented by lines drawn between entity boxes
Database Applications GIT 150
Category Relationships
• Used to identify 'subtype relationships' when some
instances of a generic entity have an attribute that
others do not have
• Composed of one generic entity and one or more
category entities
•
•
•
•
Both entities describe the same object
Generic entity contains attributes that are common to all subtypes
Category entities contain attributes that apply only to subtypes
Category entities are mutually exclusive
• Example:
– Movie= generic entity
– Western, Suspense, Comedy = category entities
Database Applications GIT 150
Category Syntax
Generic Entity
Double Line for
Complete Set of
Category Entities
(Discriminator)
Category
Category
Category
Single Line for
Incomplete
Set of Category
Entities
Database Applications GIT 150
Category Rules
• A category entity in one categorization relationship
may be a generic entity in another categorization
relationship
• A generic entity can have multiple categorization
relationships
• The key attributes of a category entity must be the
same as the generic entity
• All instances of a category entity have the same
discriminator value
Database Applications GIT 150
Categorization Example
WESTERN
SUSPENSE
COMEDY
(MOVIETYPE)
MOVIE
INCOMPLETE CATEGORIZATION
(there are other movie types such as Documentary)
MALE
FEMALE
(SEX)
PERSON
COMPLETE CATEGORIZATION
Database Applications GIT 150
Connection Relationships
• Represent an association that exists between two
different entities
• Captures that one entity instance may be related to
zero, one, or many ( 0,1,M ) instances of another
entity
e.g., Customer rents ( 0,1,M ) Movies
• Can be either a Specific or Non-Specific instance
identification
Database Applications GIT 150
Connection Syntax
• Line with solid circle at end point
• Relationship is described with a verb phrase placed
next to connection line
- Circle : represents zero, one or many (0,1,M)
- Circle with Letter P: represents one or more (1,M)
P
- Circle with Letter Z: represents zero or one (0,1)
Z
- Circle with Number: represents an exact number (n)
n
Database Applications GIT 150
Non-Specific Connection
Relationships
• A relationship where one instance of an entity may
relate to 0, 1, M instances of a second entity; and
one instance of the second entity may relate to 0, 1,
M instances of the first entity
• For Example:
– A Customer Rents at 0,1,M Movies, and Each Movie is
Rented by 0, 1, M Customers
MOVIE
CUSTOMER
Cust Number
Name
Address
Status Code
Movie Number
rents/is rented by
Name
Rating
Rental Rate
Database Applications GIT 150
Specific Connection Relationships
• A Parent - Child relationship that resolves a nonspecific relationship to capture additional detail
• A relationship where one instance of an entity
(Parent) may relate to 0, 1, M instances of the second
entity (Child), and the Child entity is related to one
and only one instance of the Parent entity
• For Example:
- A CUSTOMER Rents a specific copy of a MOVIE
Movie Rental Record
Customer
Cust Number
Name
Address
Status Code
rents according to
Movie Number
Movie Copy Id
Rental Date
Cust Number (FK)
Database Applications GIT 150
Attribute Migration
• In all Specific relationships the key attributes of the
parent (first) entity migrate to the child (second)
entity
e.g., Become attributes of the child entity
• These attributes are known as Foreign Key attributes
• The non-key attributes of the parent entity never
migrate
• A migrated key may migrate to either a key or nonkey position in the child entity
Database Applications GIT 150
Attribute Migration Syntax
• A solid line is used to depict a parent-child
relationship where, foreign key migrates to key
position in child entity
– An identifying relationship
– Child entity box has rounded corners
• A dashed line is used to depict a parent-child
relationship where foreign key migrates to non-key
position in child entity
– An non-identifying relationship
– Child entity box has square corners
Database Applications GIT 150
Identifying Relationships
{
Key
"Migrates"
to Key
Position
AIRLINE
Airline-Name
issues
AIRLINE-TICKET
Airline-Ticket-No
Airline-Name (FK)
Database Applications GIT 150
Non-Identifying Relationships
{
Key
"Migrates"
to Non-Key
Position
TRAVEL-AGENCY-BRANCH
Travel-Agency-Br-ID-No
employs
EMPLOYEE
Social Security Number
Travel-Agency-Br-ID-No (FK)
Database Applications GIT 150
Entity Dependency
ZZ
PARENT - EXISTENCE INDEPENDENT, IDENTIFIER INDEPENDENT ENTITY
YY
XX (FK1)
CHILD - EXISTENCE DEPENDENT, IDENTIFIER INDEPENDENT ENTITY
XX (FK1)
CHILD - EXISTENCE DEPENDENT, IDENTIFIER DEPENDENT ENTITY
YY
XX
ZZ
YY (FK1)
XX (FK1)
CHILD - EXISTENCE DEPENDENT, IDENTIFIER DEPENDENT ENTITY
Database Applications GIT 150
Attribute Role Names
• Role names are noun phrases assigned to attributes to
help convey a characteristic's (attribute's) meaning
• Required when a single attribute is inherited more
than once, distinguishes multiple attributes
occurrences
• May be used (optional) for single attribute occurrence
migrations
Database Applications GIT 150
Attribute Role Name
PERSON
PERSON
Name
is Parent in
Name
is Child in
is
Z
FAMILY TREE
Parent.Name
Child.Name
REQUIRED ROLE NAMES
MINOR
MinorPerson.Name
OPTIONAL ROLE NAME
Database Applications GIT 150
Levels of Modeling Detail
• DATA PLANNING MODEL
(ENTITY RELATIONSHIP MODEL)
– The Highest or Most Generalized Level of Abstraction Cannot Make Precise Business Rule Statements
R
E
F
I
N
E
M
E
N
T
DATA PLANNING
MODEL
KEY - BASED MODEL
FULLY ATTRIBUTED MODEL
NUMBER OF ENTITIES
G
E
N
E
R
A
L
I
Z
A
T
I
O
N
Database Applications GIT 150
Planning Model Example
MOVIE
CUSTOMER
Is Rented By
/ Rents
Is Produced In/
Produces
(TYPE)
WESTERN
STUDIO
Database Applications GIT 150
Levels of Modeling Detail
• Key - Based Model
– Adds Unique Identifiers or Key Attributes To the Entities
of the Planning Model
R
E
F
I
N
E
M
E
N
T
DATA PLANNING
MODEL
KEY - BASED MODEL
FULLY ATTRIBUTED MODEL
NUMBER OF ENTITIES
G
E
N
E
R
A
L
I
Z
A
T
I
O
N
Database Applications GIT 150
Key-Based Model Example
MOVIE
RENTAL
MOVIE
MOVIE #
Is Rented By
MOVIE # (FK1)
CUSTOMER # (FK2)
DATE
CUSTOMER
CUSTOMER #
Rents
Is Produced by
(TYPE)
WESTERN
MOVIE #
MOVIE
PRODUCTION
STUDIO ID (FK2)
MOVIE # (FK1)
STUDIO
Funds
STUDIO ID
Database Applications GIT 150
Levels of Modeling Detail
• FULLY ATTRIBUTED MODEL
(FULLY REFINED MODEL)
– Completely Defines Characteristics And
– Relationships of All the Entities Within A
– Given Scope - Greatest Level of Refinement
R
E
F
I
N
E
M
E
N
T
DATA PLANNING
MODEL
KEY - BASED MODEL
FULLY ATTRIBUTED MODEL
NUMBER OF ENTITIES
G
E
N
E
R
A
L
I
Z
A
T
I
O
N
Database Applications GIT 150
Fully Attributed/Refined Model Example
MOVIE
RENTAL
MOVIE
MOVIE #
Is Rented By
TITLE
LENGTH
MOVIE # (FK1)
CUSTOMER # (FK2)
DATE
CUSTOMER
CUSTOMER #
Rents
NAME
ADDRESS
LATE STATUS
Is Produced by
(TYPE)
WESTERN
MOVIE #
LOCATION
ASPCA RATING
MOVIE
PRODUCTION
STUDIO ID (FK2)
MOVIE # (FK1)
BUDGET
STUDIO
Funds
STUDIO ID
STUDIO NAME
ADDRESS
Database Applications GIT 150
• Overview
• Methodology and Documentation
• Modeling Procedures
• Model Translation
• Object Orientation
• Product Data Exchange Standard
• Enterprise Model Utilization & Summary
Database Applications GIT 150
Model Building Procedures
DATA
PLANNING
MODEL
1. SCOPE PROJECT
2. ENTITY DEFINITION
3. RELATIONSHIP DEFINITION
4. KEY ATTRIBUTE DEFINITION
5. NON-KEY ATTRIBUTE DEFINITION
KEY
BASED
MODEL
FULLY
ATTRIBUTED
MODEL
Database Applications GIT 150
Step 1 : Scope Project
• Organize Team
– Manager
– Subject Experts
– Modeling Expert
• Build, Analyze, and Optimize Process Model *
• Identify Functional Requirements and Data Objects
• Collect Source Material
–
–
–
–
Data Object Examples
Interview Results
Policy / Procedure Manual
Data Base / File Specifications for Existing Systems
*Not a trivial exercise
Database Applications GIT 150
Reasons for Process Evaluation and
Measurement
• Process Measurement And Evaluation
Helps To:
1)Focus attention on the real drivers behind achieving the
organization's mission
2)Determine how to use the organization's resources effectively
3)Set goals and monitor trends
4)Analyze root causes and sources of errors
5)Identify opportunities for improvement
6)Give employees a sense of accomplishment
7)Provide a means of knowing whether you're "Winning Or Losing"
• Process Re-Design
Database Applications GIT 150
End Customer = Key to Process Re-Design
• Start workflow evaluation by understanding the
process’s end customer(s).
• An end customer is one who pays for the results of
the process.
– Product
– Service
• Determine "What" is being paid for.
• Intermediate or internal customers (quality circle) are
typically an expense rather than a revenue generator.
Database Applications GIT 150
AS-IS Process to TO-BE Process
• Identify the activities and objects within the AS-IS
process that the end customer pays for.
• Question all others.
• Start at the end of the process and work backward
adding only those activities and objects that are on the
critical path.
Database Applications GIT 150
Process Defined:
• A process or workflow is any activity or group of
activities that takes an input, adds value to it, and
provides an output to an internal or external
customer.
Database Applications GIT 150
Definition of a Process Flow Model
• A graphical workflow model and glossary that
describes what an organization or system actually
does.
• Depicts the time phased actions that are performed by
a person, object, or system component in the
performance of a given action or scenario.
• Views an environment from a process centered view many objects at various points within their life cycle.
Database Applications GIT 150
Purpose of a Process Flow Model
• Drive out the requirements for automation by
capturing the objects, access reasons, approvers,
notifications, organizations, and decision points for
an event.
• Defines the process rulebase for the PDM process
flow engine (i.e., enables the PDM to automate the
environment’s policies and procedures).
• Define configuration management and control
requirements.
• Can help optimize the entire process cycle time by
exposing nonessential or ill-timed tasks.
Graphical process model depicting activities
to be supported by a Student Registration
Database Application
Database Applications GIT 150
Manage 1.1
Student
Data
Manage 1.2
Instructor
Data
Student Information
Identify 1.6
Textbook
Requirements
Instructor Information
Capture 1.8
Student
Registration
Data
Class Details
Manage 1.3
Course
Data
Manage 1.4
Facility
Data
Course
Information
Identify 1.5
Class
Offerings
Facility Information
Textbook Details
Develop 1.7
Class
Catalog
Catalog of Classes
Reg Report
Database Applications GIT 150
Manage Airline Meal Catering Process
Model Example
Airline Information including Ticket Sales
Track
Special Meal
Requests 1.1
Special Requests
1.2.1
Manage
Customers
(Airlines) 1.3
Ticket
Sales
Airline
Information
Understand
Flight
Schedules
Manage
Airline Meal
Delivery 1.2
Schedules
Determine
Flight
Passenger
Counts
1.2.2
Passenge
r
Flight
Details
Identify
Departure
Gate
Location
and Plan
Delivery
Meal
Delivery
Plan
Manage
Flight Delays
and
Cancellations
1.2.4
1.2.3
Schedules
Flight Changes
Database Applications GIT 150
Process Flow Diagram Example
Commercial Loan Process
approved*
application
procedures
new*loan
evaluation worksheet
received*loan
application
O
unapproved*
loan application
approved*
qualification
procedures
completed*
loan
evaluation
worksheet
reviewed* loan
application
CONDUCT
CREDIT CHECK
1
A11
approved*
loan booking
procedures
approved loan*
application
X
MAKE LOAN
DETERMINATION
in-work*
loan
application
2
A12
BOOK
LOAN
O
generated*
internal order
3
A13
qualified*
loan officer
qualified*
loan officer
qualified*
branch
manager
rejected* loan application
with information request
trained*note
department
approved*
loan file
approved*
loan dollars
Database Applications GIT 150
Process Flow Model Elements
• A process flow model is composed of the following
elements:
–
–
–
–
–
–
Activities and Events (Units Of Behavior)
Inputs and Outputs (Object & State Links)
Constraints and Rules (Controls)
Resources (Mechanisms)
Decision Points (Junctions)
Notifications and Messages
Database Applications GIT 150
Process Model Information Interview
Form
MODELER PROFILE
NAME:
JOB TITLE:
LOCATION:
ORG/DEPT/SECTION/GROUP:
ADDRESS:
MAIL STOP:
PHONE#:
SKILLS (optional)
SKILL NAME CODE
EXPERIENCE (optional)
a) PROGRAM/PRODUCT:
JOB DESCRIPTION PFROM TO
b) PROGRAM/PRODUCT:
JOB DESCRIPTION PFROM TO
ACTIVITY INFORMATION
ACTIVITY NAME:
PAGE (2)
NODE#
ACTIVITY DESCRIPTION:
PERFORMING ORG/DEPT/SECTION/GROUP:
AUTHORIZING ORG/DEPT/SECTION/GROUP:
APPROVING ORG/DEPT/SECTION/GROUP:
EQUIPMENT REQUIRED TO PERFORM ACTIVITY
(INCLUDING HW/SW):
ACTIVITY SUCCESS CRITERIA:
c) PROGRAM/PRODUCT:
JOB DESCRIPTION PFROM TO
MAJOR GOALS/OBJECTIVES (optional):
PROBLEMS ASSOCIATED WITH ACTIVITY:
NEEDS FOR PROBLEM SOLUTIONS:
Database Applications GIT 150
Process Model Information Interview
Form
ACTIVITY INFORMATION
ACTIVITY NAME:
PAGE (3)
NODE#
TYPE OF QUESTIONS ASKED IN PERFORMING THE
ACTIVITY:
1)
INPUT & CONTROL INFORMATION FLOW PAGE (4)
ACTIVITY NAME:
NODE#
a) INPUT/CONTROL NAME:
MEDIA:
SIZE:
LIFECYCLE STATE:
NODE#(s) RECEIVED PFROM:
(INPUT) HOW MODIFIED:
(CONTROL) HOW USED:
2)
3)
b) INPUT/CONTROL NAME:
MEDIA:
SIZE:
LIFECYCLE STATE:
NODE#(s) RECEIVED PFROM:
(INPUT) HOW MODIFIED:
4)
(CONTROL) HOW USED:
5)
6)
7)
8)
9)
c) INPUT/CONTROL NAME:
MEDIA:
SIZE:
LIFECYCLE STATE:
NODE#(s) RECEIVED PFROM:
(INPUT) HOW MODIFIED:
(CONTROL) HOW USED:
d) INPUT/CONTROL NAME:
MEDIA:
SIZE:
LIFECYCLE STATE:
NODE#(s) RECEIVED PFROM:
(INPUT) HOW MODIFIED:
(CONTROL) HOW USED:
Database Applications GIT 150
Process Model Information Interview
Form
OUTPUT INFORMATION FLOW
ACTIVITY NAME: NODE#
PAGE (5)
NOTIFICATION INFORMATION FLOWS PAGE (6)
ACTIVITY NAME:
a) OUTPUT NAME:
MEDIA:
SIZE:
LIFECYCLE STATE:
NODE#(s) GOING TO:
b) OUTPUT NAME:
MEDIA:
SIZE:
LIFECYCLE STATE:
NODE#(s) GOING TO:
c) OUTPUT NAME:
MEDIA:
SIZE:
LIFECYCLE STATE:
NODE#(s) GOING TO:
d) OUTPUT NAME:
MEDIA:
SIZE:
LIFECYCLE STATE:
NODE#(s) GOING TO:
e) OUTPUT NAME:
MEDIA:
SIZE:
LIFECYCLE STATE:
NODE#(s) GOING TO:
f) OUTPUT NAME:
MEDIA:
SIZE:
LIFECYCLE STATE:
NODE#(s) GOING TO:
NODE#
a) NOTIFICATION NAME:
PURPOSE:
MEDIA:
SIZE:
ORG/DEPT/SEC/GROUP/PERSON(s) SENDING MESSAGE:
ORG/DEPT/SEC/GROUP/PERSON(s) RECEIVING MESSAGE:
NODE#(s) GOING TO:
b) NOTIFICATION NAME:
PURPOSE:
MEDIA:
SIZE:
ORG/DEPT/SEC/GROUP/PERSON(s) SENDING MESSAGE:
ORG/DEPT/SEC/GROUP/PERSON(s) RECEIVING MESSAGE:
NODE#(s) GOING TO:
c) NOTIFICATION NAME:
PURPOSE:
MEDIA:
SIZE:
ORG/DEPT/SEC/GROUP/PERSON(s) SENDING MESSAGE:
ORG/DEPT/SEC/GROUP/PERSON(s) RECEIVING MESSAGE:
NODE#(s) GOING TO:
Database Applications GIT 150
Project Functional Requirements (PFR)
• A mechanism for translating a process vision (i.e.,
Should Maps, To-Be Process Models) into
information system and database application
requirements.
• Used to organize and summarize one or more
application concepts into reusable capabilities.
• Provides a technique for maintaining traceability
between user requirements and the application system
design specifications.
• The set of PFRs bound the scope of the information
model vision.
Database Applications GIT 150
Each PFR Contains
• A Capability Statement
– A description of “What” function or concept of operation the PFR is providing.
This is extracted from user process analysis.
• A Rationale Statement
– A description of “Why” the PFR is needed. Describes what process(s) is being
supported.
• A Presentation Statement
– A description of “How” the capability(s) defined by the PFR is to be provided or
accomplished. Identifies the implementation approach (i.e., query on-line, report).
• A Data Assertion Statement
– A description of the information needs of the PFR. Identifies the entity/object
classes and their attributes needed to initiate the capability and the entity/object
classes and associated attributes provided by the completion of the capability.
• A Players Statement
– A description of “Who” desires and “Who” utilizes the capability identified in the
PFR.
Database Applications GIT 150
Example PFR for Responsible Personnel for a
Part
• Capability Statement:
– Be able to retrieve responsible personnel or part ownership information
for a given part and optionally include most current system
requirements information as well.
• Rationale Statement:
– To facilitate and make team communication more efficient.
– To support issue resolution by providing the immediate association of
parts that are the subject of or that are affected by an issue and the
people who need to be contacted to achieve team resolution (during
both informal change control and formal issue management).
• Presentation Statement:
– Multi-level screens, using Part, System, Requirement, Responsible
Person as selection to get to secondary screens. Reports not required
but limited printing based upon screen context. Most critical
requirements always shown first based upon area (part) criticality.
Database Applications GIT 150
Part Responsibility PFR Example (Con’t)
• Data Assertion Statement:
– The Part Prefix, Base, with Suffix is the input information
for returning Personnel information that includes Person’s
Name, Title, Phone Number, Department Name, Alternate
Extension, FAX Phone Number. There is a single set of
the Personnel information for each Part Number input.
– Optional Requirements information would include
Requirements text, Product Line, Series Name, Unit Cost,
Total Program Invest, Weight, Quality Assessment, . . .
• Players Statement
– Desired by: Designer, Program Office
– Utilized by: Program Office, CAE Personnel
Database Applications GIT 150
Step 2 : Entity/Object Definition
• Use the Process Flow Model Links and the
Functional Requirement’s Data Assertion Statements
to create an Entity/Object Pool
– list of "things" that have data associated with them
• Test Pool for validity
– Can each entity be described?
– Are there several instances?
– Can one instance be separated from another?
• Define entities in Pool and identify synonyms
Database Applications GIT 150
Step 3 : Relationship Definition
• Build entity relationship matrix
– Identify related entities
– Define connection relationships
– Define category relationships
• Identify dependencies
• Capture narrative statements about the relationship business rules
• Build data planning model
Database Applications GIT 150
Entity Relationship Matrix
MOVIE
X
WESTERN
X
STUDIO
X
CUSTOMER
X
X
X
Database Applications GIT 150
Entity Relationship Matrix
Could Is Prod- Is
Be A uced By Rented
By
MOVIE
WESTERN Is A
Type Of
STUDIO
Produces
CUSTOMER Rents
Database Applications GIT 150
Planning Model Example
MOVIE
CUSTOMER
Is Rented By
/ Rents
Is Produced In/
Produces
(TYPE)
WESTERN
STUDIO
Database Applications GIT 150
Step 4 : Key Attribute Definition
• Resolve non-specific relationships
• Determine primary and alternate keys
• Define key attributes
• Migrate key attributes
• Determine identifying (solid line) and non-identifying
(dashed line) relationships
• Perform no-null, no-repeat, and smallest-key testing
Database Applications GIT 150
Attribute Testing
• No-null rule: for each instance of an entity, all
attributes must have a value
• No-repeat rule: no entity instance can have more than
one value for a given entity key
• Smallest key test: entities with compound keys must
require whole key set for unique identification
Database Applications GIT 150
Key-Based Model Example
MOVIE
RENTAL
MOVIE
MOVIE #
Is Rented By
MOVIE # (FK1)
CUSTOMER # (FK2)
DATE
CUSTOMER
CUSTOMER #
Rents
Is Produced by
(TYPE)
WESTERN
MOVIE #
MOVIE
PRODUCTION
STUDIO ID (FK2)
MOVIE # (FK1)
STUDIO
Funds
STUDIO ID
Database Applications GIT 150
Step 5 : Non-Key Attribute Definition
• Determine non-key attributes
• Define non-key attributes
• Specify precise cardinalities and other information
constraints
• Validate single entity ownership
• Apply no null, no repeat, and smallest key set rules
Database Applications GIT 150
Attribute Ownership
• Each and every attribute must be "owned" by one and
only one entity
• A non-key attribute can only be found within a single
entity unless the attribute is a foreign key (migrated
as a non-key attribute)
PERSON
SSN
PASSPORT
PASSPORT #
has
Z
SSN (FK1)
Database Applications GIT 150
Fully Attributed/Refined Model Example
MOVIE
RENTAL
MOVIE
MOVIE #
Is Rented By
TITLE
LENGTH
MOVIE # (FK1)
CUSTOMER # (FK2)
DATE
CUSTOMER
CUSTOMER #
Rents
NAME
ADDRESS
LATE STATUS
Is Produced by
(TYPE)
WESTERN
MOVIE #
LOCATION
ASPCA RATING
MOVIE
PRODUCTION
STUDIO ID (FK2)
MOVIE # (FK1)
BUDGET
STUDIO
Funds
STUDIO ID
STUDIO NAME
ADDRESS
Database Applications GIT 150
Normalization
• A set of rules for analyzing the attributes of an
information model
–
–
–
–
Eliminate model redundancy
Ensure model consistency
Verify structural correctness
Maximize stability
• However, normalization cannot validate a model's
accuracy in reflecting the business meaning of the
information
Database Applications GIT 150
Normal Forms
• Sequential steps for achieving an optimized and
logically desirable information model
• Provides a common foundation from which an
efficient physical database design can be created
• There are six degrees of normal form - the first three
are usually sufficient for most modeling applications
•
•
•
•
•
•
First normal form
Second normal form
Third normal form
Boyce/Codd normal form
Fourth normal form
Fifth normal form
Database Applications GIT 150
First Normal Form - (1NF)
• Every key and non-key attribute of an entity must be
single valued
• No entity instance can have multiple values for a
given attribute
• i.e., The No Repeat Rule
• A violating entity is corrected by removing repeating
or multivalued attributes to another, dependent (child)
entity
Database Applications GIT 150
First Normal Form - Example
RESTAURANT
REST NAME
ADDRESS
PHONE #
EMPLOYEE NAME
REST NAME
ADDRESS
PHONE #
BURGER KING 123 NORTH ST
123-2345
TACO HOUSE
345 126TH PLACE 765-8907
FISH COMPANY 77 SUNSET AVE
395-5682
RESTAURANT
REST NAME
ADDRESS
PHONE #
EMPLOYEE NAME
JOHN, SUE, LISA
MARY, BILL
ED, SAM, JOSE, RICK
EMPLOYEE
employs
EMPLOYEE NAME
REST NAME
POSITION
Database Applications GIT 150
Second Normal Form - (2NF)
• An entity that is in first normal form and each nonkey attribute is dependent on the entire primary key
• No non-key attribute instance can be determined by
knowing just part of an entity instances key
• A violating entity is corrected by removing to a
parent entity any attributes that depend on only a
subset of the primary key
Database Applications GIT 150
Second Normal Form - Example
RESTAURANT ORDER
REST NAME
SUPPLIER NAME
ORDER ITEM
SUPPLIER PHONE #
REST NAME
SUPPLIER NAME ORDER ITEM
BURGER KING SAM'S PRODUCE
TACO HOUSE
SALSA INC.
FISH COMPANY SAM'S PRODUCE
SUPPLIER
SUPPLIER NAME
PHONE #
fills
BEEF
PEPPERS
SNAPPER
SUPPLIER PHONE #
123-2345
765-8907
123-2345
RESTAURANT ORDER
REST NAME
ORDER ITEM
SUPPLIER NAME (FK1)
Database Applications GIT 150
Third Normal Form - (3NF)
• An entity that is in second normal form and each nonkey attribute is only dependent on the entire primary
key and nothing other than the key
• No non-key attribute instance can be determined by
knowing the value of another non-key attribute for
the same instance
• A violating entity is corrected by removing to a
parent entity any attributes exhibiting transitive
dependencies (non-key attributes that not only depend
on the whole key but also on other non-key attributes)
Database Applications GIT 150
Third Normal Form - Example
RESTAURANT RESERVATION
REST NAME
RESERVATION #
CUSTOMER NAME
CUSTOMER PHONE #
TIME
# IN PARTY
REST NAME
RES # CUST NAME
F. JONES
BURGER KING 12
R. SMITH
TACO HOUSE
234
F. JONES
FISH COMPANY 88
CUSTOMER
CUSTOMER NAME
PHONE #
makes
CUST PH #
123-2345
765-8907
123-2345
TIME
11:00 AM
2:30 PM
8:15 PM
# IN PARTY
4
4
6
RESTAURANT RESERVATION
REST NAME
RESERVATION #
CUSTOMER NAME (FK1)
TIME
# IN PARTY
Database Applications GIT 150
Boyce/Codd Normal Form - (BCNF)
• An entity that is in third normal form and all
attributes depend on only the entire primary or
alternate keys (candidate keys) and do not depend on
any subset of the candidate keys.
• No non-key attribute instance can be determined by
knowing the value of another non-key or partial key
attribute for an alternate key entity instance
• A violating alternate key instance entity is corrected
by removing to a parent entity any attributes that
depend on only a subset of the primary key or those
exhibiting transitive dependencies
Database Applications GIT 150
Fourth Normal Form - (4NF)
(APPLIES ONLY TO COMPOUND/COMPOSITE KEYS)
• An entity that is in boyce/codd normal form and the
primary and alternate keys do not contain any
independently multivalued attributes
• No entity instance should contain two or more
independent facts about an entity unless inherited
through relationships
• Don't mix apples and oranges
• A violating entity is corrected by removing any
independently multivalued components of the
primary key to two or more new (possibly) parent
entities
Database Applications GIT 150
Fifth Normal Form - (5NF)
(APPLIES ONLY TO COMPOUND/COMPOSITE KEYS)
• An entity that is in fourth normal form and the
primary key does not contain any pairwise cyclic
redundancies
• No entity instance should contain information which
can be reconstructed from smaller pieces of
information which can be maintained with less
redundancy
• A violating entity is corrected by simultaneous
decomposition into three or more new parent entities
Database Applications GIT 150
• Overview
• Methodology and Documentation
• Modeling Procedures
• Model Translation
• Object Orientation
• Product Data Exchange Standard
• Enterprise Model Utilization & Summary
Database Applications GIT 150
Model Translation
• Logical to Physical, Relational Database
• Converting IDEF-1X (ER Models) to EXPRESS (OO
Models)
Database Applications GIT 150
Translation of a Logical Model into a
Physical, Relational Database
• Identify Tables
• Identify Columns
• Adapt Data Structure To Product Environment
• Design Databases For Business Rules About Entities
• Design For Business Rules About Relationships
• Design For Business Rules About Attributes
Database Applications GIT 150
STEP 1 : Identify Tables
• In general, identify one table for each AIM entity.
• Define each bottom level Subtype entity as a table
rolling all Supertype attributes down into the
Subtypes. Or, define top level Supertype entity as a
table rolling all Subtype attributes into Supertype as
optional class dependent attributes. Write triggers to
enforce inheritance rules (ONEOF etc.).
• Document tables in a data dictionary.
Database Applications GIT 150
STEP 2 : Identify Columns
• In general, identify one column for each attribute of
an AIM entity.
• In general, don't define composite columns (multiple
AIM attributes per column).
• Define triggers to enforce integrity and cardinality
rules.
• Document table columns in data dictionary.
• Create ER diagram of global internal schema by
depicting tables as ER entities and columns as ER
entity attributes.
Database Applications GIT 150
STEP 3 : Adapt Data Structure To
Product Environment
• Define optimum sequencing of columns for physical
device storage and performance
• If feasible, for each table allocate enough primary
storage space to contain the entire table - try to
minimize use of secondary space
• If feasible, for each table allocate enough free storage
space to accommodate all anticipated row inserts and
updates that may occur after initial table load or after
table reorganization
Database Applications GIT 150
STEP 3 : Adapt Data Structure To
Product Environment (con't)
• Define database(s) to facilitate greater concurrency/data
availability and to avoid physical size limitations.
• Group common business meaning entity/tables together
into separate databases.
• Group commonly accessed entity/tables together into
separate databases.
• Evaluate and design databases to utilize locking
parameters which optimize data record locking for
minimal size and time.
• Document database meta data in data dictionary.
• Create ER subset diagrams of global internal schema for
each database.
Database Applications GIT 150
STEP 4 : Design Databases For
Business Rules About Entities
i.e., Uniqueness, Minimality, And Key Null Value Disallowance
• Enforce entity uniqueness key (and alternate key)
concepts through DBMS data definition language
(DDL) and/or DBMS domain definitions.
• Document database table key and alternate key
concepts and enforcement methods in data dictionary.
Database Applications GIT 150
STEP 5 : Design For Business Rules
About Relationships
i.e.,
Key Attribute Insert, Delete, And Update Constraints
• Enforce entity referential integrity concepts through
DBMS data definition language (DDL) foreign key
designation and/or DBMS triggering techniques.
• Document database table foreign key concepts and
enforcement methods in data dictionary.
Database Applications GIT 150
STEP 6 : Design For Business Rules About
Attributes (Domain Constraints & Events)
• Enforce entity attribute domain and action event
concepts through DBMS data definition language
(DDL), indexes, and/or standard maintenance
routines.
– Domain constraints = data type, length, format/mask,
allowable value definition, uniqueness, null support, and/or
default value specification.
– Action events = triggering mechanisms to enforce object
methods and algorithms specified in aim.
• Document database domain and action event concepts
and enforcement techniques in data dictionary.