mcgraw-hill/irwin copyright © 2007 by the mcgraw-hill companies, inc. all rights reserved. chapter...
TRANSCRIPT
McGraw-Hill/Irwin Copyright © 2007 by The McGraw-Hill Companies, Inc. All rights reserved.
Chapter 12
View Design and Integration
12-2
Outline
Motivation for view design and integration View design with forms View integration
12-3
Motivation
Database complexity reflects organizational complexity.
Time-consuming and labor-intensive process
Collect requirements from different user groups
Coordination among designer team members
Manage complexity of large designs
12-4
Managing Complexity
As the “divide and conquer” strategy is used to manage complexity, view design and integration is an approach to managing complexity of the database design effort.
12-5
Overview of View Design and Integration
Viewdesign
Viewintegration
Views
Conceptual schema
InterviewsDocumentation
Proposedforms/reports
Conflictidentification
Conflictresolution
12-6
View Design with Forms Important source of database
requirements Reverse the process described in the
Chapter 10 Derive an ERD that is consistent with the
form Five step procedure
12-7
Sample Customer Order Form
Order No.: 1234 Order Date: 3/19/2006
Customer No.: 1001 Customer Name: Jon Smith
Address: 123 Any Street
City: Seattle State: WA Zip: 98115
Salesperson No.: 1001 Salesperson Name: Jane Doe
$5001
$1503
$1204
Unit PriceQuantity
R210
B138
M128
Table
Cabinet
Bookcase
DescriptionProduct No.
Customer Order Form
Parent (main form)
Child (subform)
12-8
Form Analysis Create an ERD to represent a form ERD supports form and other
anticipated processing ERD should be consistent with the form ERD is a view of the database
12-9
Form Analysis StepsStep 1: Defineform structure
Step 2: Identifyentity types
Step 3: Attachattributes
Step 4: Addrelationships
Step 5: Checkcompleteness and
consistency
12-10
Step 1: Define Form Structure Construct a hierarchy that depicts the form
structure Most forms consist of a simple hierarchy
where the main form is the parent and the subform is the child.
Complex forms can have parallel subforms and more levels in the hierarchy.
12-11
Hierarchical Form StructureParent Node
Order NoOrder Date
Customer No., Customer NameAddress, City
State, ZipSalesperson No
Salesperson Name
Child NodeProduct NoDescription
QuantityUnit Price
12-12
Step 2: Identify Entity Types
Split each node in the hierarchical structure into one or more entity types.
Make an entity type if a form field is a potential primary key and there are other associated fields in the form.
12-13
Entity Types for the Customer Order Form
OrderOrder No
CustomerCustomer No
ProductProduct No
SalesPersonSalesPerson No
12-14
Step 3: Attach Attributes Attach attributes to the entity types
identified in the previous step Group together fields that are associated
with the primary keys found in Step 2 Form fields close together may belong in
the same entity type
12-15
Add Attributes
OrderOrder No
Order Date
CustomerCustomer No
Customer NameAddress
CityStateZip
ProductProduct NoDescriptionUnit Price
OrderLineQuantity
SalesPersonSalesPerson No
SalesPerson Name
12-16
Step 4: Add Relationships Relationships involving the form entity type
Form entity type contains the form's primary key Relationships between the form entity type and
other entity types derived from the parent node: usually 1-M.
Add a relationship to connect the form entity type to an entity type in the child node
Add relationships to connect entity types derived from the child node if not already connected
12-17
Entity Relationship Diagram
Customer NoCustomer NameAddressCityStateZip
Customer
Order NoOrder Date
Order
Product NoDescriptionUnit Price
Product
SalesPerson NoSalesPersonName
Salesperson
Makes
Takes
Contains
Quantity
12-18
Step 5: Check Completeness and Consistency The ERD should adhere to the diagram
rules specified in Chapter 5. In addition, the ERD should be consistent
and complete with respect to the form structure.
Explore diagram transformations as suggested in Chapter 6.
12-19
Consistency Rules for Relationship Cardinalities1. In at least one direction, the maximum
cardinality should be one for relationships connecting entity types derived from the same node (parent or child).
2. In at least one direction, the maximum cardinality should be greater than one for relationships connecting entity types derived from nodes on different levels of the form hierarchy.
12-20
Analysis of M-Way Relationships using Forms Choice between M-way and binary
relationships can be difficult. Data entry forms provide a context to
understand M-way relationships. An M-way relationship may be needed if a
form shows a data entry pattern involving three entity types.
12-21
Sample Project Purchasing Form
Project Purchasing Form
Purchase No.: P1234 Purchase Date: 3/19/2006
Project No.: PR1 Project Manager: Jon Smith
Part No. Supplier No. Quantity Unit Price
M128 S100 4 $120
M128 S101 3 $150
R210 S102 1 $500
12-22
ERD for the Project Purchase Form
PartNoPartName
PartSuppNoSuppName
SupplierProjNoProjName
Project
QtyPrice
IncludesPartUses
SuppUses
PurchaseNoPurchaseDate
Purchase
PurchUses
Makes
12-23
Sample Purchasing Form
Purchasing Form
Purchase No.: P1234 Purchase Date: 3/19/2006
Supplier No.: S101 Supplier Name: Anytime Supply
Part No. Quantity Unit Price
M128 4 $120
M129 3 $150
R210 1 $500
12-24
ERD for the Purchasing Form
PartNoPartName
Part
SupplierNoSupplierName
Supplier
QtyPrice
Includes
PartUses
PurchaseNoPurchaseDate
Purchase
PurchUse
From
12-25
View Integration Combine individual views into a complete
database design Incremental and parallel integration
approaches
12-26
Incremental Approach
Incremental viewintegration
Integrated ERD(Views 1 to n)
View nPartially Integrated ERD
12-27
Parallel Approach
Parallel viewintegration
Integrated ERD(Views 1 to n)
View nERD
View 1ERD
...
12-28
Integration Strategy
Parallel viewintegration
Integrated ERD
Partially integratedERD for subset 1 ...
Incremental viewintegration
Incremental viewintegration
Partially integratedERD for subset n
View subset 1 View subset n...
12-29
Precedence Relationships Form A precedes form B if form A must be
completed before form B. Preceding forms typically provide data for
subsequent forms. Place forms with precedence relationships
in the same view subset
12-30
Precedence Example
Customerform
Productform
Orderform
Invoiceform
Product Designform
Product Mftg.form
12-31
Resolving Synonyms and Homonyms
Synonym: spelled differently but have the same meaning
Homonym: same sound and often the same spelling but different meaning
Forms provide a context to resolve Major part of standardizing a vocabulary
McGraw-Hill/Irwin Copyright © 2007 by The McGraw-Hill Companies, Inc. All rights reserved.
View Integration Examples
12-33
Sample Invoice FormINVOICE FORM
Customer No.: 1273 Invoice No.: 06389 Name: Contemporary Designs Date: 3/28/2006
Address: 123 Any Street Order No.: 61384
City: Seattle State: WA Zip: 98105
Product No Description Qty Ord
Qty Ship
Qty Back
Unit Price
Total Price
B381 Cabinet 2 2 150.00 300.00
R210 Table 1 1 500.00 500.00
M128 Bookcase 4 2 2 200.00 400.00
Total Amount $1200.00
Discount 60.00
Amount Due $1140.00
12-34
Incremental Integration Example The following 5 slides demonstrate
the Incremental Integration process by integrating the Invoice Form with the ERD for Customer Order Form
12-35
Form Hierarchy
Parent NodeInvoice No
DateCustomer No.
Name, AddressCity, State, Zip
Order No., Discount
Child NodeProduct NoDescription
Qty Ord, Qty ShipQty Back
Unit Price, Total Price
12-36
Identify entity types and attach attributes
OrderOrder No
CustomerCustomer No
NameAddress
City, State, Zip
ProductProduct NoDescriptionUnit Price
ShipLineQty Ord.Qty Ship
Qty Back *Total Price *
InvoiceInvoice No.
DateTotal Amount *
Discount *Amount Due *
12-37
Match Form Fields
Match to existing entity types Order No matches the Order entity
type. Customer No, Customer Name,
Address, City, State, and Zip match the Customer entity type.
Product No, Description, and Unit Price match the Product entity type.
12-38
Analyze Homonyms Revise the Customer entity type with
two sets of address fields: billing address fields and shipping address fields.
Add shipping address fields to the Invoice entity type.
Create a new entity type (ShipAddress) with the shipping address fields.
12-39
Integrated ERD (incremental)
Customer NoCustomer NameAddressCityStateZip
Customer
Order NoOrder Date
OrderQuantity
OrderLine
Product NoDescriptionUnit Price
Product
SalesPerson NoSalesPerson Name
SalesPerson
Makes
Takes
Contains
UsedIn
Invoice NoDateShipAddrShipCityShipStateShipZipTotal AmountDiscountAmount Due
Invoice
Qty ShipQty OrdQty Back
ShipLine
ShipFor
ShipsIn
UsesProd
12-40
Parallel Integration Example
The difference between the parallel and incremental approaches is that integration occurs later in the parallel approach.
For the parallel approach, ERDs for forms must be constructed before merging.
12-41
ERD for the Invoice Form
Customer NoCustomer NameAddressCityStateZip
Customer
Order No
OrderQty ShipQty OrdQty Back
ShipLine
Product NoDescriptionUnit Price
Product
Invoice NoDateTotal AmountDiscountAmount Due
Invoice
UsesProd
ShipFor ShipsIn
SentTo
12-42
Integrated ERD (Parallel)
Customer NoCustomer NameAddressCityStateZip
Customer
Order NoOrder Date
OrderQuantity
OrderLine
Product NoDescriptionUnit Price
Product
SalesPerson NoSalesPerson Name
SalesPerson
Makes
Takes
Contains
UsedIn
Invoice NoDateShipAddrShipCityShipStateShipZipTotal AmountDiscountAmount Due
Invoice
Qty ShipQty OrdQty Back
ShipLine
ShipFor
ShipsIn
UsesProd
12-43
Summary View design and integration is an
important skill for designing large databases.
Manage complexity of large development efforts
The result of form analysis is an ERD that is a view of the database.
Two approaches for View Integration, incremental and parallel