FREE DM Review Site Registration!
Sign-up today and access DM Review on the Web!

Your FREE registration entitles you to:
FREE email newsletters

FREE access to all DM Review content

FREE access to web seminars, resource portals, our white paper library and more!

   

Rules on Rules

Design Challenge

A logical data model represents a business solution independent of technology, including the business rules. For example, the rule an order is identified by an order number and must have a valid ID from a customer and salesperson is enforced in Figure 1.



Figure 1: Enforcement of a Business Rule on a Logical Data Model

Yet there are other business rules that appear impossible to enforce on a logical data model such as the following: A high-risk property is one that has had three or more claims filed in the last four years with a total value of more than $50,000 in losses.

The Challenge

What guideline do you apply in deciding which rules to enforce on the logical data model?

The Response

The two most popular factors in deciding which rules to enforce on the logical data model are whether the rule is stable and whether the rule is data driven. There are also a few other important factors to consider.

Enforce stable rules on the logical data model. With our goal of building a flexible model, we need to ensure changes to business rules minimally impact the model's structure. Norman Daoust, modeler, would model "rules that both the modeler and domain expert agree are unlikely to change in the near future." Karen Lopez, project manager, applies similar logic. "I find that numbers are the items in a business rule most likely to change, so I don't put them in a logical or physical data model as a data model constraint." Amanda Schoenauer, data architect, prefers not to store calculated values in the database. "Storing the high-risk property rule results in the database would cause data integrity issues if the rules ever changed. Instead, I would opt to store the rule criteria. Then as the rules change, so would your results."

Avoid enforcing data-driven rules on the logical data model. I like to use the if-then test in deciding whether to include the rule on the logical data model. All rules that can be put into an if-then format should not be represented on the logical data model. We can rephrase this high-risk property rule into: If a property has had three or more claims filed in the last four years with a total value of more than $50,000 in losses, then it is considered high risk. Due to its modeling complexity and instability, this is a business rule I would not represent on a logical data model. However, on the physical side, I could implement such a rule using database views.

Joanne Alexander, senior analyst, believes the presence or absence of a piece of information can be enforced by the model, yet, "Business rules based on the value contained in a data item (other than null) can't be enforced unless you are dealing with subtypes based on that data item or are using a lookup table to validate a value. Complex sets of value relationships are best left to the application." Melanie Mecca, enterprise architecture consultant, has a similar viewpoint. "Rules that are dependent on the semantic value of the column should not be enforced within the database. Fundamental data requirements, such as not null columns, identifiers and entity type to entity type data relationships should definitely be represented in the data model."

Although this high-risk property rule is not feasible to capture on the model, you could capture the data required to apply the rule or the results of applying this rule. Forrest Carter, data architect, for example, would create a Boolean indicator that identifies high-risk properties.

Additional guidelines. There are a number of other guidelines to consider, as well. At times, there are limitations to what our modeling tools and notation can capture. Ann Poindexter, senior data modeler, mentioned these limitations as well as the limitations on the human brain to actually document the complexity of some of the business rules on a data model. Emma Fortnum, application architect, takes into account the audience for the model in determining the rules that get shown. Steve Heichelheim, data analyst, asks this very practical question, "What is the potential negative impact to the business from not enforcing the rule in the logical model?"

Submit a Design Challenge

If you would like to become a design challenger and have the opportunity to submit modeling solutions, please add your email address at www.stevehoberman.com/designchallenge.htm. If you have a challenge you would like our group to tackle, please email me a description of the scenario at me@stevehoberman.com.


Steve Hoberman has worked as a business intelligence and data management practitioner and trainer since 1990. He is a Certified Business Intelligence Professional (CBIP), having achieved mastery level certification in data analysis and design. He is a popular and frequent presenter at industry conferences, both nationally and internationally.  Hoberman is a columnist and frequent contributor to industry publications, as well as the author of  Data Modeler's Workbench and Data Modeling Made Simple (available for purchase through the DM Review bookstore). He is the founder of the Design Challenges group, inventor of the Data Model Scorecard and a recognized innovator and thought leader in the field of data modeling. He can be reached at me@stevehoberman.com.

Graeme Simsion's latest book is out! Data Modeling Theory and Practice. Here's a link where you can read more about the book and purchase it at a discounted price.

For more information on related topics, visit the following channels:



Industry Vendors