The data model scorecard contains more than 400 rules to apply when reviewing a data model. One of these rules requires justifying optionality on a relationship. For example, on the model in Figure 1 we have these two business rules:
- Each Customer can place many Orders.
- Each Order must be placed by one Customer.
The circle on the relationship line implies zero. That is, a Customer can exist without ever placing an Order. In this example, we would ask the modeler the question, "When can a Customer exist without having placed an Order?"
During a recent class on the Scorecard, someone asked why it is important to justify optionality, such as in this example. Why do you think it is important?
Data modeling offers a precise view of our information landscape, and optionality can detract from this precision. Data Architect Mark Taylor says, "Optionality implies a degree of 'fuzziness' in a relationship, which is why it should be justified. Routinely challenging optionality enables you to be confident that where it remains, it is appropriate for the model concerned."
There are several positive outcomes of justifying optionality:
Uncover new states. Complex concepts such as Customer go through a lifecycle. For example, a customer might start off as a prospect, which is a potential customer. Applications Manager Marc Bratman, Business Analyst Larry Blankenship and Mark Taylor all caution us on the hidden states behind optionality. Mark summarizes: "It could turn out that the definition of Customer is being used to include Lead or Prospect ... and we might accept this, or we might modify the model to account for the differences between Leads and Customers."
Increase model flexibility. Having both a Prospect and a Customer could introduce abstraction in the form of the Party and Role concept. That is, a party can play many roles. Bob the party can start off as the role Prospect and then become the role Customer. Project Manager Earl Dawson and Data Architect Patrick McMullen mention this positive outcome of challenging optionality. Patrick adds, "The term Customer suggests a role that an individual plays when he acquires goods or consumes services. The optionality of the order relationship could indicate that it may be more appropriate to name this customer entity as the more abstract term, 'Party.'"
Refine existing concepts. Justifying optionality can lead to a more accurate and complete definition for Customer. Data Architect Mark Lotz gives this example of a refined definition: "Customer is a person or organization that has purchased goods or services from the ABC Corporation or has registered on our Web site." Information Architect Rakesh Nandish suggests the optionality that could indicate Customer also includes customers of competitors and, therefore, we have no records of their orders. BI Lead Programmer Lakshmi Mangipudi says perhaps this organization is a membership club, and Customer could be someone who signed up for membership and has not yet purchased any products.
Identify timing issues. By questioning the optional cardinality, we can learn more about the sequence of creating customers and orders and identify archival requirements for the application. Project Manager Bob Mosscrop III suggests this organization may need to enter all of the customer information before we allow them to create an order. Data Architect Ryan Abella adds in the case of an online shopper, "The Customer exists without having placed an Order right before the Customer clicked the order button." Senior Data Warehouse Developer Rob Steward says, "If you wanted to keep all Customers forever but roll off Orders to an archival system, you would want the optional relationship."
Drive implementation. Questioning optionality could lead to smarter implementation decisions. Data Architect John Schley says, "If an Order were required for a Customer, the database administrator may choose to put both inserts into one database transaction." Mark Taylor mentions, "Another possibility is that the optionality has been specified in order to support technical processes such as to minimize the relational integrity issues of a data load." If this is the reason for optionality, periodically monitor the data to ensure good data quality. As Data Architect Kristina H. Vogel notes - and cautions, "Application developers can inadvertently allow errors to creep in that create records without legitimate relationships in place, resulting in a mess no one wants to clean up."
Raise data quality concerns. Speaking of data quality, Database Engineer Steve Turnock says, "If the business rules are not explored, then the definition of Customer is incorrect, and you risk that the maintenance routines for Customer may be coded as dependent on Order." Lori Russell, DA, adds, "The optionality also suggests additional questions to understand the business rules, such as did the salesperson forget to submit the order?"
So if it's your data model, make sure you can justify those innocent circles that translate into zero cardinality. If you are reviewing someone's data model, question everywhere zero appears. In both situations, the end product will be higher quality data model and design. Zero really is our hero!
Register or login for access to this item and much more
All Information Management content is archived after seven days.
Community members receive:
- All recent and archived articles
- Conference offers and updates
- A full menu of enewsletter options
- Web seminars, white papers, ebooks
Already have an account? Log In
Don't have an account? Register for Free Unlimited Access