Subtyping Resolution
from Chapter 19. Physical Data Models->Creating a physical data model，作者 Steve Hoberman
One refinement we’ll need to make is to resolve the supertype/subtype relationship for the Customer entity. Since relational databases do not support the concept of subtyping, we need to resolve this in our physical data model. Recall from our earlier discussion that there are three ways of resolving subtyping in the physical model: identity, rolling down, and rolling up. In this case, we’ll choose the rolling down method to preserve two distinct entities: Retail Customer and Wholesale Customer. Since in the original design, the intern neglected to include wholesale customers, two separate applications had been built: one to manage retail customers and one for wholesale customers. Although this is not an ideal situation, we are unable to rewrite the applications themselves, and provide a solution that matches the real world implementation, in this case. These types of ‘work-arounds’ are common in ‘real world’ implementations. Another ‘work-around’ is that since we’re using a combined logical and physical data model, denormalization changes will be applied to both the logical and physical models simultaneously. Ideally, we’ll want to keep our logical models (business) and physical models (technical implementation) distinct, which would require us to use separate logical and physical data models and use the Derive functionality. Refer to Table 18.5 for a summary of the pros and cons of using a combined logical/physical model vs. separate logical and physical models.
Recall our subtype relationship for customer in the logical model, shown in Figure 19.45.
Figure 19.45 Subtype Relationship for Customer
To resolve this subtype, first select the subtype symbol 
on the diagram, as shown in Figure 19.46.
Figure 19.46 Selecting the Subtype Symbol
Next, select Actions|Transformations|Supertype-Subtype RollDown from the Main Menu. The Supertype Subtype Rolldown Wizard appears as shown in Figure 19.47.
Figure 19.47 Supertype Subtype Rolldown Wizard
Select Next to complete the action. A panel summarizing the changes appears, as shown in Figure 19.48, explaining that the Customer entity will roll down into the Retail Customer and Wholesale Customer entities, which is the action we want.
Figure 19.48 Completing the Supertype Subtype Wizard
Select Finish and you will be returned to the diagram, shown in Figure 19.49. Note that you may need to reorganize the diagram slightly, since the entities and relationships have been modified.
Figure 19.49 Relational LDM for Baker Cakes with Subtyping Resolved via Rolling Down
We’ve created some redundancy in our model, with the Loyalty_Code repeated in both the Retail Customer and Wholesale Customer tables, and a redundant relationship between Retail Customer and Order and Wholesale Customer and Order. But we’ve maintained readability of the model and, importantly, matched the implementation requirements of the organization.
One thing that seems strange, however, is that there is only one Customer ID attribute as a foreign key in the Order entity that refers to both Retail Customers and Wholesale Customers. While that’s technically correct, since customer IDs are unique, it makes the model difficult to interpret. Remember our discussion of role names earlier in this chapter? This is a perfect use case for role naming—we’ll create a separate role name for the Customer ID attribute in the Retail Customer and Wholesale Customer entities. To create a role name, open the Relationship Properties Editor for the relationship between Retail Customer and Order, and move to the Role Name tab, as shown in Figure 19.50. For more information on the Relationship Properties Editor, refer to Chapter 6.
Figure 19.50 Invoking the Relationship Properties Editor to Add a Role Name
In the Role Name field, enter our role name for the Customer ID attribute, in this case ‘Retail Customer ID’, as shown in Figure 19.51.
Figure 19.51 Adding a Role Name for a Foreign Key Attribute
Select Close, and your model diagram should now look like Figure 19.52. Notice that the Customer ID attribute remains as-is in the Retail Customer entity, but is role named to Retail Customer ID in the Order table.
Figure 19.52 Role Name Added for Retail Customer ID
Create a role name called ‘Wholesale Customer ID’ for the Customer ID attribute in the Wholesale Customer entity. We won’t walk you through this—use similar steps to those you used for the Retail Customer ID role name. When complete, your model should look similar to Figure 19.53.
Figure 19.53 Subtyping Resolved in LDM with Role Names Added
Switch to the physical data model, and you’ll see a similar design, as shown in Figure 19.54.
Figure 19.54 Subtyping Resolved in PDM
This is close to the design we need, but notice the relationships between Order and Retail_Customer and Order and Wholesale Customer. If you read these relationships, you’ll see that an order must have a retail customer and a wholesale customer, which is not a correct business rule. To change this, select the relationship between Order and Retail Customer and open the Relationship Properties Editor. Then change the Null Option on the General tab to Nulls Allowed, as shown in Figure 19.55.
Figure 19.55 Changing the Null Option for a Relationship
Follow similar steps for the relationship between Wholesale Customer and Order, and your model will look similar to Figure 19.56.
Figure 19.56 Subtyping Resolved in PDM – with Correct Cardinality
