This chapter is a continuation of the last chapter. This one deals with data rules that require a set of business objects to test over instead of looking inside just one business object at a time. Most of the information of the previous chapter applies equally to this chapter.
This is just another part of the process of trying to find as many data rules as possible that can be used to find evidence of inaccurate data. Data can look correct completely within all business objects, satisfying value, structure, and data rule tests but incompatible in the context of data in other business objects. Because these data rules involve multiple objects, finding incompatibilities does not identify the offending data, it simply narrows the amount of data within which the wrong data exists.
The terms business object and data rule were defined in the previous chapter. What remains is a definition of a set of business objects.
This is a collection of business object instances that can be isolated in terms of columns of the objects. Each object instance remains a discrete entity within the set. The set can include multiple instances of the same business object type; for example, all inventory rows for each discrete part type. They can also include rows from multiple different business object types; for example, supplier information combined with orders sent to each supplier. A business object set may include all of the data in a table. The set is everything.
A business object set requires a definition of how to select multiple instances or how to join rows between tables. These definitions divide the rows of tables in groups of business object instances data rules can be applied to. Examples of selection criteria are each REGION, each DIVISION, each TYPE_CODE, and LAST_MONTH.
The set may consist of all of the data in one database combined with the data in another database. This would be considered when data is partitioned across multiple databases or when data is being profiled in anticipation of consolidation.
Data rules are the same for sets as for individual objects. However, they have at least one component that is new. They must define the set.
Another structure you see in data rules concerning sets of objects you do not see with data rules for individual objects is aggregation functions. The rule may involve a test against a COUNT, SUM, AVERAGE, or STANDARD DEVIATION.
Data rules for sets of objects can be hard rules or soft rules, just as in the case of single-object data rules.
Most of the rules in this category are the result of process rules. They can be very complex. You probably will not find them in business procedures because they do not represent transactional activity. You will probably not find them documented at all.