Data Modeling in context

Download Report

Transcript Data Modeling in context

Entity-Relationship Design
Information Level Design
Information Access Mgt
09/12/97
1
The Data Life Cycle
Stage
Tool
Initial
Report
Investigation
Feasibility
Function-Entity
Decomposition
General
E-R Diagram
Analysis
Detailed
Schema
Design
Coding
SQL
Objective
General Scope
Installation
Initialize Tables
Information Access Mgt
Population Plan
09/12/97
Business Entities
Logical Entities
Physical Design
Specify DBMS
3
Data Modeling Stages
Stage
Goal
Outcome
Business
Scope
Business
Model
IT Model
Business justification
for system
Data requirements in
business terms
High level technical
description
Database specific
design
Data Definition
specifications
Functional Database
Data Plan
Priority list
Project Organization
CRUD Matrices
Conceptual Design
E-R Diagrams
Physical Design
Normalized Tables
Table Schema
SQL requirements
Populated Database
Management plan
Technology
Model
Technology
Definition
Database
System
Information Access Mgt
09/12/97
4
Babysitter Service
The AITP Service Club wants to run a
babysitting service. Customers call to
request a sitter and the Club
Coordinator assigns an employee to sit
for the customer from a list of
employees available for the particular
day requested.
Information Access Mgt
09/12/97
5
The Data Life Cycle
Stage
Tool
Initial
Report
Investigation
Feasibility
Function-Entity
Decomposition
General
E-R Diagram
Analysis
Detailed
Schema
Design
Coding
SQL
Objective
General Scope
Installation
Initialize Tables
Information Access Mgt
Population Plan
09/12/97
Business Entities
Logical Entities
Physical Design
Specify DBMS
6
The Data Life Cycle
Stage
Tool
Initial
Report
Investigation
Feasibility
Function-Entity
Decomposition
General
E-R Diagram
Analysis
Detailed
Schema
Design
Coding
SQL
Objective
General Scope
Installation
Initialize Tables
Information Access Mgt
Population Plan
09/12/97
Business Entities
Logical Entities
Physical Design
Specify DBMS
7
Functional Decomposition

Assign Employee
•
•
•
•
•

Take Call
Check Availability
Assign to Job
Contact Employee
Confirm Appointment
Determine Availability
Information Access Mgt
09/12/97
8
Functional-Entity
Decomposition
Employee
Assign Employee
Take Call
Check Availability
R
Assign to Job
R
Contact Employee
Confirm Appointment
Determine
Availability
R
Information Access Mgt
Customer
Job
U
R
U
R
R
U
U
09/12/97
9
The Data Life Cycle
Stage
Tool
Initial
Report
Investigation
Feasibility
Function-Entity
Decomposition
General
E-R Diagram
Analysis
Detailed
Schema
Design
Coding
SQL
Objective
General Scope
Installation
Initialize Tables
Information Access Mgt
Population Plan
09/12/97
Business Entities
Logical Entities
Physical Design
Specify DBMS
10
E-R Diagram
Employee
Customer
Job
Information Access Mgt
09/12/97
12
Data Flow Diagram
Context Diagram
Request
Customer
Confirmation
Babysitter
Information
System
Availability
Assignment
Employee
Information Access Mgt
09/12/97
14
Data Flow Diagram
Level 1
Request
Assignment
Confirmation
New
1.
Assign
Employee
Current
D1 | Customer
Availability
Avail
Times
Job
Assign
2.
Record
Availability
Avail
Times
D2 | Employee
D3 | Jobs
Information Access Mgt
09/12/97
15
Entity Relationship Models

A good E-R model has
•
•
•
One table for every entity in the business
system
Correctly drawn relationships indicating 1-1
or 1-m cardinalities
Optionality indicators to support needed
referential integrity
Information Access Mgt
09/12/97
17
ATTRIBUTE:
A description or property of a given entity
type.
• Must depend on the entity key alone
• Must contain information that we
explicitly need
• Must have the same data type for all
entity occurrences
Information Access Mgt
09/12/97
20
Discovering Entities
•
•
•
•
Entities are normally described by NOUNS
and ADJECTIVES
Entities do not change anything.
Entity occurrences are records, entity types
are files.
Reports are derived output and not entities.
Information Access Mgt
09/12/97
23
Keys
Names are normally poor primary keys. They
have multiple valid representations. Primary
keys:
1. Should not change values over the life of the
instance.
2. Should not have null values.
3. Should not be "intelligent keys". These are
keys that also describe properties of the
entity.
4. Should not be large composite keys.
Information Access Mgt
09/12/97
28
Not null vs nulls allowed
•
•
Null values represent inapplicable,
applicable but not known, and
applicable but not present values.
Primary keys cannot have null values.
Null values are different from zeros or
blanks
Information Access Mgt
09/12/97
29
Diagrams: Attributes
Entity
Key
Information Access Mgt
Attribute
09/12/97
......
Attribute
31
Diagrams:
Repeating Groups
Course
SectionNum
Information Access Mgt
09/12/97
32
PREMIERE PRODUCTS
EXAMPLE
The Premier Products Company is a
wholesale hardware company that provides
products to customers. Each customer is
served by a salesman who processes orders.
The salesmen is paid from commissions
earned on each customer order. A customer
places an order by calling the company and
contacting the salesman. The salesman
records the ordering person, products and
quantity ordered.
Information Access Mgt
09/12/97
34
PREMIERE PRODUCTS:
REPEATING GROUPS
In the Premier Products Company each
salesmen is paid from commissions earned
on each customer order. A customer places
an order by calling the company and
contacting the salesman. The salesman
records the ordering person, products and
quantity ordered. The order consists of
Customer data, Salesman data and a list of
products, price, and quantity for the products
that the customer wants delivered. The
attributes {PRODUCT, PRICE, QUANTITY}
constitute a repeating group.
Information Access Mgt
09/12/97
35
Example: Order
ORDER
5103
PRODUCT
IRON
SKILLET
PRICE
17.95
19.95
QUANTITY
11
6
5110
TOASTER
IRON
57.95
17.95
4
3
Each instance of an order has several order lines. Order lines
{Description, Price, Quantity} are examples of repeating
groups.
Information Access Mgt
09/12/97
36
RELATIONSHIP.
•
•
Does not describe processing or change any
data. Relationship names should be passive
(ordered by).
CARDINALITY Refers to the number of
records that a relationship connects to a
given child record in a relationship.
PARTICIPATION (Optionality) Refers to
whether a record must exist in one table
before a related one is inserted into another.
Information Access Mgt
09/12/97
38
Diagrams:
1:m Relationships
InstructorID
Section
CourseSection
Instructor
InstructorID
Information Access Mgt
09/12/97
39
Diagrams:
m:n Relationships
CourseSection
StudentID
Section
Student-Section
CourseSection
Student
StudentID
Information Access Mgt
09/12/97
40
Optionality
(Referential Integrity)
Records in a table that have a relationship
with another table may be restricted by
optionality requirements.
 Relationship Optional
 Relationship Mandatory (referential
integrity enforced)
Information Access Mgt
09/12/97
41
Optionality
Optional (0 allowed)
0
Mandatory (1 or more required)
1
Information Access Mgt
09/12/97
42
Data
Information Access Mgt
09/12/97
45