1. View Design and Integration
Chapter 12
View Design and Integration
This chapter describes the practice of designing user views and combining user views into a complete conceptual design.
Objectives:
-     Understand the motivation for view design and integration
-     Analyze a form and construct an ERD to represent it
-     Determine an integration strategy for a database development effort
-     Perform both incremental and parallel integration approaches
-    Recognize and resolve synonyms and homonyms in the view integration process

2. Outline Motivation for view design and integration
View design with forms
View integration
Motivation:
- View design and integration as way to manage complexity
- Nature of large-scale database development efforts
View design with forms
- Hierarchical representation of forms
- Analysis steps
- Analysis of M-way relationships
View integration:
- Incremental vs. Parallel integration
- Determining an integration strategy
- Practice on a small example

3. Why View Design and Integration?
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
The company size is an important determinant of complexity.
Large organizations have many databases with individual databases supporting groups of functions such as payroll, personnel, accounting, material requirements, and so on.
These individual databases can be very complex, as measured by the size of the ERDs. When converted to a relational database, the database can have hundreds to perhaps thousands of tables.
Other measures of complexity involve the use of the database through forms, reports, computer programs, and validation rules. A large database can have hundreds to thousands of forms, reports, computer programs, and validation rules.
The design effort often involves collecting requirements from many different groups of users. Requirements can be notoriously difficult to capture. Because of the volume of requirements and the difficulty of capturing requirements, a large database design effort can involve a team of designers. Coordination among designers is an important part of the database design effort.

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.

5. Overview of View Design and Integration
In view design, an ERD is constructed for each group of users. The requirements can come in many formats such as interviews, documentation of an existing system, and proposed forms and reports. A view is typically small enough for a single person to design.
Multiple designers can work on views covering different parts of the database. The view integration process merges the views into a complete, conceptual schema. Integration involves recognizing and resolving conflicts. To resolve conflicts, it is sometimes necessary to revise the conflicting views.

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
Source of requirements:
- Users can effectively communicate requirements through anticipated forms and reports
- Easy to visualize and prototype
Goal: derive a consistent ERD
In Chapter 10, you were given a database and then you defined forms to meet certain information processing needs. In using forms for database design, you reverse the process described in the first part of the book.

7. Sample Customer Order Form
Forms often may exist in paper format or as part of an existing system.
you may need several sample instances of a form.
The use of forms in view design does not preclude requirements in other formats such as interviews and documentation of an existing system

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
In form analysis, you create an Entity Relationship diagram to represent a form. The resulting ERD is a view of the database. The ERD should be general enough to support the form and perhaps other anticipated processing

9. Form Analysis Steps
The backtracking in Form Analysis Process shows that the form analysis process can return to previous steps. It is not necessary to perform the steps sequentially. In particular, if any problems are found in the last step, other steps must be repeated to correct the problems.

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.
Complex forms are not common: too difficult for users to understand
Analysis steps for hierarchical forms with two levels
Analysis steps can be extended for more complex forms: see references

11. Hierarchical Form Structure
Hierarchical Structure for the Customer Order Form
This figure depicts the structure of the customer order form. A rectangle (parent or child) in the hierarchy diagram is called a node.
As part of making the form structure, you should identify keys within each node in the hierarchy. In this figure, node keys are underlined.
Parent node: Order No is the node key
Child node: Product No is the node key
-In the parent node, the node key value is unique among all form instances. In the child node, the node key value is unique within the parent node. For example, a product number is unique on an order but not unique across orders.

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.
Typically, each node in the hierarchical structure represents more than one entity type. You should look for form fields that can be primary keys of an entity type in the database.

13. Entity Types for the Customer Order Form
As an example of step 2, there are three entity types in the parent node of Hierarchical Structure for the Customer Order Form.
Customer identified by Customer No, Order identified by Order No, and Salesperson identified by Salesperson No. The parent node key (Order No) usually designates an entity type. Customer No and Salesperson No are good choices because there are other associated fields (Customer Name and Salesperson Name). In the child node, there is one entity type: Product designated by Product No because Product No can be a primary key with other associated fields.

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
In the third step, you attach attributes to the entity types identified in the previous step. It is usually easy to associate form fields with the entity types. You should group together fields that are associated with the primary keys found in Step 2. Sometimes the proximity of fields can provide clues to their grouping: form fields close together often belong in the same entity type.

15. Attributes Added to the Entity Types
In this example, group the fields as shown in Entity Types for the Customer Order Form. Order with Order No and Order Date, Customer with Customer No, Customer Name, Address, City, State, and Zip, Salesperson with Salesperson No and Salesperson Name, and Product with Product No, Description, and Unit Price.
You might notice that Quantity does not seem to belong to Product because the combination of Order No and Product No determine Quantity. You can create a new entity type (OrderLine) with Quantity as an attribute. If you miss this entity type, Quantity can be made an attribute of a relationship in the next step. In addition, the Unit Price attribute can be considered an attribute of the OrderLine entity type if the historical price rather than the current price of a product is tracked.

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
In this fourth step, you connect entity types with relationships and specify cardinalities.
You should begin with the entity type containing the primary key of the form. Let us call this the form entity type. Make the form entity type the center of the ERD. Typically, many relationships are between the form entity type and other entity types derived from the parent and the child nodes.

17. Entity Relationship Diagram
Entity Relationship Diagram for the Customer Order Form
In this figure, Order is the form entity type. After identifying the form entity type, add 1-M relationships with other entity types derived from fields in the main form. This leaves us with Order connected to Customer and SalesPerson through 1-M relationship. The same customer can make many orders and the same salesperson can take many orders.
Next connect the entity types derived from fields in the subform. Product and OrderLine can be connected by a 1-M relationship. An order line contains one product, but the same product may appear in order lines of different forms.
To finish the relationships, you need to connect an entity type derived from main form fields with an entity type derived from subform fields. Typically the relationship will connect the form entity type (Order) with an entity type derived from the child node. This relationship can be 1-M or M-N.
you can assume that an order can be associated with many products. If you examine other order form instances, you could see the same product associated with different orders. Therefore, a product can be associated with many orders. Here, it is important to note that Quantity is not associated with either Product or Order but with their combination. The combination can be considered a relationship or entity type.

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.

19. Consistency Rules for Relationship Cardinalities
In at least one direction, the maximum cardinality should be one for relationships connecting entity types derived from the same node (parent or child).
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.
For consistency, the form structure provides several constraints on the relationship cardinalities as summarized in Rules for Relationship Cardinalities.
The first rule is necessary because only one value is displayed on the form. For example, there is only one value displayed for the customer number, name, and so on. As an example of the first rule, the maximum cardinality is one in the relationship from Order to Customer and from Order to Salesperson.
The second rule ensures that there is a 1-M relationship from the parent to the child node. A given record in the parent node can be related to many records in the child node. As an example of the second rule, the relationship from Order to OrderLine has a maximum cardinality of M. In the alternative ERD (Figure 8), the maximum cardinality is M from Order to Product.

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.
Chapter 7 described the concept of relationship independence as a way to reason about the need for M-way relationships. This section describes a more application-oriented way to reason about M-way relationships. You can use data entry forms to help determine if an associative entity type representing an M-way relationship is needed in an ERD.
M-way relationships can be difficult to understand because they involve three or more entity types. 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. Typically, one entity type resides on the main form and the other two entity types reside on the subform.

21. Sample Project Purchasing Form
This figure shows a form with a project in the main form and part-supplier combinations (two entity types) in the subform. This form can be used to purchase parts for a particular project (localized purchasing).
Notice: Because purchasing decisions are made by projects, both Part No and Supplier No can be updated in the subform.

22. ERD for the Project Purchase Form
An associative entity type involving purchase, part, and supplier is necessary because a purchase can involve many combinations of parts and suppliers.
The subform supports updates to both partno and suppno.

23. Sample Purchasing Form
As an alternative to localized purchasing for each project, some organizations may prefer centralized purchasing. This slide shows a form to support centralized purchasing with the supplier in the main form and related parts in the subform. There is another form for assigning parts to projects.

24. ERD for the Purchasing Form
There is a binary relationship between Purchase and Part.
To allocate parts to projects, there is another form with the project in the main form and the parts used by the project in the subform. The ERD for the other form would need a binary relationship between project and part.

25. View Integration
Combine individual views into a complete database design
Incremental and parallel integration approaches
Two approaches for view integration are presented along with approaches for determining an integration strategy.

26. Incremental Approach
In the Incremental Approaches, a view and partially integrated ERD are merged in each integration step.
Initially, the designer chooses a view and constructs an ERD for it. For subsequent views, the designer performs integration while analyzing the next view. The view design and integration processes are performed jointly for each view after the first one. This approach is incremental as a partially integrated ERD is produced after each step.
This approach is also binary as the current view is analyzed along with the partially integrated ERD.

27. Parallel Approach
In the parallel approach, ERDs are produced for each view and then the view ERDs are merged. The integration occurs in one large step after all views are analyzed. This approach is parallel because different designers can perform view designs at the same time.
Integration can be more complex in the parallel approach because integration is postponed until the end when all views are integrated to produce the final ERD.

28. Integration Strategy
An integration strategy specifies a mix of incremental and parallel approaches to integrate a set of views.
To choose an integration strategy, you divide the views into subsets (say n subsets). For each subset of views, the incremental approach is followed. You should choose subsets of views so that views in a subset are closely related. Views in different subsets should not be closely related.
Incremental integration across subsets of views can proceed in parallel. After an integrated ERD is produced for each subset of views, a parallel integration produces the final, integrated ERD.
If the ERDs from each subset of views do not overlap much, the final integration should not be difficult. If there is significant overlap among the subset of views, incremental integration can be used to combine the ERDs from the view subsets.

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
To help determine an integration strategy, you can identify precedence relationships among forms. Form A precedes form B if form A must be completed before form B is used. Form A typically provides data used in form B.

30. Precedence Example
The precedence relationships indicate that instances of the customer and product forms must be complete before an order is taken. Likewise, the product and product Design forms must be complete before a manufacturing form is completed.
Using these precedence relationships, the forms can be divided into two groups: (i) an ordering process consisting of the customer, product, order, and invoice forms and (ii) a manufacturing process consisting of the product, product design, and product manufacturing forms.

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
In any integration approach, resolution of synonyms and homonyms is a very important issue. A synonym is a group of words that are spelled differently but have the same meaning. For example, OrdNo, Order Number, and ONO are likely synonyms. Synonyms often occur because different parts of an organization may use different vocabulary to describe the same things. This situation is especially likely if a common database did not exist before.
A homonym is a group of words that have the same sound and often the same spelling but have different meanings. In database design, homonyms arise because of context of usage. For example, two forms may show an address field. In one form, the address may only represent the street address while in the other form, it represents the street, city, state, and zip. Even when both address fields represent the street address, they may not be the same. One form might contain the billing address while the other form contains the shipping address.
Resolving synonyms and homonyms is a major part of standardizing a vocabulary that is a large part of database development. The use of naming standards and a corporate data dictionary can aid in the identification and resolution of synonyms and homonyms. A corporate data dictionary can be created and maintained with a CASE tool.

32. View Integration Examples
This section depicts the incremental and parallel approaches to view integration using the customer order (slide 7) and invoice forms (next slide). The final result is identical with both approaches, but the path to this result is different.

33. Sample Invoice Form

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
To demonstrate the incremental integration approach, let us integrate the customer invoice form (slide 33) with the ERD from slide 17.
The following 5 slides will demonstrate the Incremental Integration process.

35. Form Hierarchy

36. Identify entity types and attach attributes
As steps 2 and 3 are performed , it is useful to see how the entity types should be merged into the existing ERD (or ERD for Customer Order Form).

37. List the form fields that match 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.
As you match form fields to existing entity types, you should check for synonyms and homonyms.

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.
If it is not clear that Address, City, State, and Zip fields have the same meaning in the two forms, or If you determine that the two sets of fields are homonyms (an order may be billed to one address and shipped to another), there are a number of data modeling alternatives as listed.
- Revise the Customer entity type with two sets of address fields: billing address fields and shipping address fields. This solution restricts the customer to having only a single shipping address. If more than one shipping address is possible, this solution is not feasible.
 - Add shipping address fields to the Invoice entity type. This solution supports multiple shipping addresses per customer. However, if an invoice is deleted, the shipping address is lost.
- Create a new entity type (ShipAddress) with the shipping address fields. This solution supports multiple shipping addresses per customer. It may require overhead to gather the shipping addresses. If shipping addresses are maintained separate from invoices, this solution is the best

39. Integrated ERD (incremental)
This integrated ERD uses the second alternative.
In the incremental integration process, the usual process of connecting entity types (Step 4) should be followed. For example, there is an M cardinality relating an entity type derived from the parent node with an entity type derived from the child node. The maximum cardinality in ShipsIn from Invoice to ShipLine satisfies this constraint. Note that ShipLine could be represented as an M-N relationship instead of as an entity type with two 1-M relationships.
As another point of interest from this figure, there is no relationship from Invoice to Customer. At first thought, a relationship may seem necessary because customer data appears on the main form of an invoice. If the invoice customer can be different than the order customer, a relationship between Invoice and Customer is needed. If the customer on an order is the same as the customer on the related invoice, a relationship is not needed. The customer for an invoice can be found by navigating from Invoice to Order and Order to Customer. In this figure, the assumption is that the order customer and the invoice customer are identical

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.
To demonstrate the parallel integration process, let us integrate the customer invoice form with the order form.
The major difference between the parallel and incremental approaches is that integration occurs later in the parallel approach. Thus, the first step is to construct an ERD for each form using the steps of form analysis described earlier.

41. ERD for the Invoice Form
Invoice is directly connected to both Customer and Order. The direct connection follows the practice of making the form entity type (Invoice) the center of the diagram.

42. Integrated ERD (Parallel)
The integration process merges the order form ERD with the invoice form ERD to produce the ERD shown in Figure 24. The final ERD should be the same whether an incremental or parallel approach is used.
Again, a major integration issue is the resolution of homonyms for the address fields.
Another issue is the connections among Invoice, Order, and Customer. In customer order form, Customer is directly connected to Order, but in invoice form, Order and Customer are not directly connected by a relationship. The integration process must resolve this difference. The relationship between Order and Customer is needed because orders precede invoices. A relationship between Invoice and Customer is not needed if the customer shown on an invoice is the same customer shown on the associated order. Assuming that the customer on an order is identical to the customer on the associated invoices, Invoice is not directly connected to Customer in this figure.

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
- View Design and Integration is an important skill for designing large database.
Large databases can involve ERDs with hundreds of entity types and relationships. Also, hundreds of forms, reports, and computer programs are used in the database. View design and integration helps manage the complexity of such large database design efforts.
- Forms are an important source of requirements because they are common and easily communicated for user. A five step procedure was given to analyze a form. Not only the form analysis process results an ERD that captures the data requirements of the form, it also helps detect the need for M-way relationships in an ERD.
- Two approaches for View Integration. . In the incremental approach, a view and the partially integrated ERD are merged in each integration step. In the parallel approach, ERDs are produced for each view and then the individual ERDs are merged. The incremental approach works well for closely related views, while the parallel approach works well for unrelated views. In any integration approach, resolving synonyms and homonyms is critical