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.
What guideline do you apply in deciding which rules to enforce on the logical data model?
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 firstname.lastname@example.org.
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