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
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
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 Steps
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 Structure
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
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
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
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 Cardinalities 1.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
12-22 ERD for the Project Purchase Form
12-23 Sample Purchasing Form
12-24 ERD for the Purchasing Form
12-25 View Integration Combine individual views into a complete database design Incremental and parallel integration approaches
12-26 Incremental Approach
12-27 Parallel Approach
12-28 Integration Strategy
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
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-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
12-36 Identify entity types and attach attributes
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)
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
12-42 Integrated ERD (Parallel)
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