McGraw-Hill/Irwin Copyright © 2007 by The McGraw-Hill Companies, Inc. All rights reserved. Chapter...

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



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

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

Order NoOrder Date

OrderQuantity

OrderLine


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

Order No

OrderQty ShipQty OrdQty Back

ShipLine


Product

Invoice NoDateTotal AmountDiscountAmount Due

Invoice

UsesProd

ShipFor ShipsIn

SentTo

12-42

Integrated ERD (Parallel)


Customer

Order NoOrder Date

OrderQuantity

OrderLine


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

McGraw-Hill/Irwin Copyright © 2007 by The McGraw-Hill Companies, Inc. All rights reserved. Chapter...

Documents

Transcript of McGraw-Hill/Irwin Copyright © 2007 by The McGraw-Hill Companies, Inc. All rights reserved. Chapter...