14.2.2 Process Rules A system will also be constrained by process rules, such as “A minimum of 4% of each employee’s salary up to $80,000 must be credited to the company pension fund” and “If salary deductions result in an employee’s net pay being negative, include details in an exception report.” Rules of this kind determine what processing the system is to do in particular circumstances. The first of the preceding examples includes two numbers (4% and $80,000), which may or may not be recorded as data in the database itself. We discuss data that supports process rules in Section 14.5.7. Another example of a process rule that requires some data somewhere is “For each grade of employee, a standard set of base benefits applies.” To support this rule, we need to record the base benefits for each grade of employee. “Employee number 4787 has annual salary $82,000” is, as already indi- cated, a process rule. It is reasonable to expect that the data to support this process rule is going to be held in the database. 14.2.3 What Rules Are Relevant to the Data Modeler? The data modeler should be concerned with both data and process rules and the data that supports them with one exception: other than in making a decision where and how the data supporting a process rule is to be recorded, it is not in the data modeler’s brief to either model or decide on the implementation of any process rules. References to “business rules” in the rest of this chapter therefore include only the various data rule types listed above, whereas references to “data that supports rules” covers both data that supports process rules and data that supports data rules. 14.3 Discovery and Verification of Business Rules While the business people consulted will volunteer many of the business rules that a system must support, it is important to ensure that all bases have been covered. Once we have a draft data model, the following activ- ities should be undertaken to check in a systematic way that the rules it embodies correctly reflect the business requirements. 14.3.1 Cardinality Rules We can assemble a candidate set of cardinality rules by constructing asser- tions about each relationship as described in Sections 3.5.1 and 10.18.2.2. 420 ■ Chapter 14 Modeling Business Rules Simsion-Witt_14 10/11/04 8:53 PM Page 420 We should also check the cardinality of each attribute (how many values it can have for one entity instance). This should be part of the process of nor- malization, as described in Chapter 2. However, if you have worked top- down to develop an Entity-Relationship model, you need to check whether each attribute can have more than one value for each instance of the entity class in which it has been placed. For example, if there is a Nickname attrib- ute in the Employee entity class and the business needs to record all nick- names for those employees that have more than one, the data model needs to be modified, either by replacing Nickname by the multivalued attribute Nicknames (in a conceptual data model or in a logical data model in which these are allowablesee Section 11.4.6) or by creating a separate entity for nicknames (related to the Employee entity class). To establish attribute car- dinalities, we can ask questions in the following form for each attribute: “Can an employee have more than one nickname?” “If so, is it necessary to record more than one in the database?” 14.3.2 Other Data Validation Rules Other data validation rules can be discovered by asking, for each entity class: “What restrictions are there on adding an instance of this entity class?” “What restrictions are there on the values that may be assigned to each attribute of a new instance of this entity class?” “What restrictions are there on the values that may be assigned to each attribute when changing an existing instance of this entity class?” (The answer to this question is often the same as the answer to the pre- vious question but on occasion they may differ; in particular, some attributes once assigned a value must retain that value without change.) “What restrictions are there on removing an instance of this entity class?” 14.3.3 Data Derivation Rules Data derivation rules are best discovered by analyzing each screen and each report that has been specified and by listing each value therein that does not correspond directly to an attribute in the data model. For each value, it is nec- essary to establish with the business exactly how that value is to be derived from the data that is in the database. In the case of a data warehouse (Chapter 16), or any other database in which we decide to hold summary data, we will need to ask similar questions and document the answers. 14.3 Discovery and Verification of Business Rules ■ 421 Simsion-Witt_14 10/11/04 8:53 PM Page 421 14.4 Documentation of Business Rules 14.4.1 Documentation in an E-R Diagram Only a few types of business rules can be documented in an E-R diagram: 1. The referential integrity rules implicit in each relationship (see Section 14.5.4) 2. The cardinalities of each relationship (as discussed in Section 3.2.3): these are (of course) cardinality rules 3. Whether each relationship is mandatory or optional (as also discussed in Section 3.2.4): these are data validation rules, since they determine restrictions on the addition, changing, and/or removal of entity instances 4. Various limitations on which entity instances can be associated with each other (by specifying that a relationship is with a subtype of an entity class rather than the entity class itself; this is discussed further in Section 14.4.3): these are also data validation rules 5. The fact that an attribute is restricted to a discrete set of values (a data val- idation rule) can be documented by adding an entity class to represent the relevant set of categories and a relationship from that entity class to one containing a category attributethe familiar “reference table” struc- ture (see Section 14.5.5)although, as discussed in Section 7.2.2.1, we do not recommend this in a conceptual data model. Further business rules can conveniently be documented in the attribute lists supporting an E-R diagram. Most documentation tools will allow you to record: 6. Whether each attribute is optional (nullable) (a data validation rule) 7. The DBMS datatype of each attribute (e.g., if the attribute is given a numeric datatype, this specifies a data validation rule that nonnumerics cannot be entered; if a date datatype, that the value entered must be a valid date). If the transferability notation (see Section 3.5.6) is available, an additional type of business rule can be documented: 8. Whether each relationship is transferable (a data validation rule). 14.4.2 Documenting Other Rules Unfortunately, there are many other types of rules, including all data deri- vation rules and the following types of data validation rules, which are not 422 ■ Chapter 14 Modeling Business Rules Simsion-Witt_14 10/11/04 8:53 PM Page 422 so readily represented in an E-R diagram or associated attribute list, or at least not in a manner amenable to direct translation into relational database constraints (we can always record them as text in definitions): 1. Nondiscrete constraints on attribute values (e.g., “The Unit Price of a Product must be positive”) 2. Attribute constraints dependent on values of other attributes in the same entity instance (e.g., “The End Date must be later than the Start Date”) 3. Most attribute constraints that are dependent on values of attributes in different entity instances, including instances of different entity classes (e.g., “The amount of this allowance for this employee cannot exceed the maximum for this employee grade”) exceptions that can be modeled in an E-R diagram are referential integrity (see Section 14.5.4) and those involving allowable combinations of values of different attributes (see Section 14.5.6) 4. Cardinality/optionality constraints such as “There can be no more than four subjects recorded for a teacher” or “There must be at least two subjects recorded for each teacher” (actually the first of these could be documented using a repeating group with four items but, as discussed in Section 2.6, repeating groups generally have serious drawbacks) 5. Restrictions on updatability (other than transferability) such as “No existing transaction can be updated,” “This date can only be altered to a date later than previously recorded,” and “This attribute can only be updated by the Finance Manager.” E-R diagrams do not provide any means of documenting these other rule types, yet such rules tell us important information about the data, its meaning, and how it is to be correctly used. They logically belong with the data model, so some supplementary documentation technique is required. Some other modeling approaches recognize this need. ORM (Object Role Modeling, discussed briefly in Section 7.4.2) provides a well-developed and much richer language than the E-R Model for documenting constraints, and the resulting models can be converted to relational database designs fairly mechanically. UML also provides some constraint notations, although in general the ability of UML CASE tools to automatically implement con- straints in the resulting database is less developed than for ORM. We can also choose to take advantage of one or more of the techniques available to specify process logic: decision tables, decision trees, data flow diagrams, function decompositions, pseudo-code, and so on. These are particularly relevant for rules we would like to hold as data in order to facilitate change, but which would more naturally be represented within program logic. The important thing is that whichever techniques are adopted, they be readily understood by all participants in the system development process. It is also important that rules not be ignored as “too hard.” The rules are an integral part of the system being developed, and it is essential to be able to refer back to an agreed specification. 14.4 Documentation of Business Rules ■ 423 Simsion-Witt_14 10/11/04 8:53 PM Page 423 Plain language is still one of the most convenient and best understood ways to specify rules. One problem with plain language is that it provides plenty of scope for ambiguity. To address this deficiency, Ross 2 has devel- oped a very sophisticated diagrammatic notation for documenting rules of all types. While he has developed a very thorough taxonomy of rules and a wide range of symbols to represent them, the complexity of the diagrams produced using this technique may make them unsuitable as a medium for discussion with business people. Ross’ technique may be most useful in documenting rules for the bene- fit of those building a system and in gaining an appreciation of the types of rules we need to look for. The great advantage of using plain language for documentation is that the rules remain understandable to all participants in the system development process. The downside is the possibility of making ambiguous statements, but careful choice of wording can add rigor without loss of understanding. Data validation rules that cannot be represented directly in the data model proper should be documented in text form against the relevant entity classes, attributes, and relationships (illustrated in Figure 14.1). Data derivation rules should be documented separately only if the derived data items have not been included in the data model as we recommended in Section 7.2.2.2. Where there is any doubt about the accuracy of a rule recorded against the model, you should obtain and list examples. These serve not only to clarify and test the accuracy of the specified requirements and verify that the rules are real and important, but provide ammunition to fire at pro- posed solutions. On occasions, we have seen requirements dropped or sig- nificantly modified after the search for examples failed to turn up any, or confirmed that the few cases from which the rules had been inferred were in fact the only cases! 14.4.3 Use of Subtypes to Document Rules Subtypes can be used in a conceptual data model to document limitations on which entity instances can be associated with each other (outlined in Chapter 4). Figure 14.2 on page 426 illustrates the simplest use of subtypes to document a rule. The initial model relates workers and annual leave applications, but we are advised that only certain types of workers employeescan submit annual leave applications. A straightforward sub- typing captures the rule. Nonemployee Worker is not an elegant classification or name, and we should be prompted to ask what other sorts of workers the user is 424 ■ Chapter 14 Modeling Business Rules 2 Ross, R.G., The Business Rule Book: Classifying, Defining & Modeling Rules, Business Rule Solutions (1997). Simsion-Witt_14 10/11/04 8:53 PM Page 424 interested in. Perhaps we might be able to change the entity class name to Contractor. Note that, as described in Chapter 11, we have a variety of options for implementing a supertype/subtype structure; inclusion of subtypes in the model does not necessarily imply that each will be implemented in a sep- arate table. We may well decide not to, perhaps because we can envision other worker types in the future, or due to a relaxation of the rule as to who can submit leave applications. We would then implement the rule either within program logic, or through a table listing the types of workers able to submit annual leave applications. This simple example provides a template for solving more complex prob- lems. For example, we might want to add the rule that “Only noncitizens require work permits.” This could be achieved by using the partitioning convention introduced in Chapter 4 to show alternative subtypings (see Figure 14.3, page 427). Note that the relationship from Noncitizen to Work Permit is optional, even though the original rule could have been interpreted as requiring it to be mandatory. We would have checked this by asking the user: “Could we ever want to record details of a noncitizen who did not have a work permit (perhaps prior to their obtaining one)?” 14.4 Documentation of Business Rules ■ 425 Entity Class/Data Item Constraints Student Absence No date/time overlaps between records for the same Student be for Student Mandatory; Student must already exist Start Date Mandatory; must be valid date; must be within reasonable range End Date If entered: must be valid date; must be not be before Start Date; must be within reasonable range First Timetable Period No Mandatory; integer; must be between 1 and maximum timetable period no inclusive Last Timetable Period No If entered: integer; must be between 1 and maximum timetable period no inclusive; must not be less than First Timetable Period No be classified by Student Absence Reason Mandatory; Student Absence Reason must already exist Notification Date If entered: must be valid date; must be within reasonable range Absence Approved Flag If entered: must be Yes or No Student Absence Reason Absence Reason Code Mandatory; must be unique Description Mandatory; must be unique Figure 14.1 Some data validation rules. Simsion-Witt_14 10/11/04 8:53 PM Page 425 Suppose we wanted to model the organizational structure of a company so as to enforce the rule that an employee could be assigned only to a lowest level organizational unit. This kind of structure also occurs in hier- archical charts of accounts, in which transactions can be posted only to the lowest level. Figure 14.4 on page 428 shows the use of subtypes to capture the rule. Note that the structure itself defines a Lowest Level Organization Unit as an Organizational Unit that cannot control other Organizational Units (since it lacks the “control” relationship). Once again, we might not imple- ment the subtypes, perhaps because a given lowest level organizational unit could later control other organization units, thus changing its subtype. (Section 4.13.5 discusses why we want to avoid instances changing from one subtype to another.) Wherever subtyping allows you to capture a business rule easily in a conceptual data model, we recommend that you do so, even if you have little intention of actually implementing the subtypes as separate tables in the final database design. Even if you plan to have a single table in the database holding many different types of real-world objects, documenting those real-world objects as a single entity class is likely to make the model incomprehensible to users. Do not omit important rules that can be readily documented using subtypes simply because those subtypes are potentially 426 ■ Chapter 14 Modeling Business Rules Worker Annual Leave Application Annual Leave Application Employee Nonemployee Worker submit be submitted by submit be submitted by Worker “only employees can submit annual leave applications” Figure 14.2 Using subtypes to model rules. Simsion-Witt_14 10/11/04 8:53 PM Page 426 volatile. This is an abdication of the data modeler’s responsibility for doing detailed and rigorous analysis and the process modelers will not thank you for having to ask the same questions again! 14.5 Implementing Business Rules Deciding how and where each rule is to be implemented is one of the most important aspects of information system design. Depending on the type of rule, it can be implemented in one or more of the following: ■ The structure of the database (its tables and columns) ■ Various properties of columns (datatype, nullability, uniqueness, refer- ential integrity) ■ Declared constraints, enforced by the DBMS ■ Data values held in the database ■ Program logic (stored procedures, screen event handling, application code) 14.5 Implementing Business Rules ■ 427 Employee Nonemployee Worker Citizen Noncitizen Work Permit Annual Leave Application be held by hold be submitted by submit Worker Figure 14.3 Using alternative subtypings to model rules. Simsion-Witt_14 10/11/04 8:53 PM Page 427 ■ Inside specialized “rules engine” software ■ Outside the computerized component of the system (manual rules, pro- cedures). 14.5.1 Where to Implement Particular Rules Some rules by their nature suggest one of the above techniques in particu- lar. For example, the rule “Each employee can belong to at most one union at one time” is most obviously supported by data structure (a foreign key in the Employee table representing a one-to-many relationship between the Union and Employee entity classes). Similarly, the rule “If salary deductions result in an employee’s net pay being negative, include details in an exception report” is clearly a candidate for implementation in program logic. Other rules suggest alternative treatments; for example, the values 4% and $80,000 supporting the rule “A minimum of 4% of each employee’s salary up to $80,000 must be credited to the company pension fund” could be held as data in the database or constants in program logic. 428 ■ Chapter 14 Modeling Business Rules Figure 14.4 Using unstable subtypes to capture rules. Higher Level Organization Unit Lowest Level Organization Unit Employee work for be worked for by Organization Unit be controlled by control Simsion-Witt_14 10/11/04 8:53 PM Page 428 14.5.1.1 Choosing from Alternatives Where there are alternatives, the selection of an implementation technique should start with the following questions: 1. How readily does this implementation method support the rule? 2. How volatile is the rule (how likely is it to change during the lifetime of the system)? 3. How flexible is this implementation method (how easily does it lend itself to changing a rule)? For example, changing the database structure after a system has been built is a very complex task whereas changing a data value is usually very easy. Changes to program logic involve more work than changing a data value but less than changing the database structure (which will involve program logic changes in at least one programand possibly many). Changes to column properties can generally be made quite quickly but not as quickly as changing a data value. Note that rules implemented primarily using one technique may also affect the design of other components of the system. For example, if we implement a rule in data structure, that rule will also be reflected in program structure; if we implement a rule using data values, we will need to design the data structure to support the necessary data, and design the programs to allow their processing logic to be driven by the data values. This is an area in which it is crucial that data modelers and process modelers work together. Many a data model has been rejected or inappro- priately compromised because it placed demands upon process modelers that they did not understand or were unprepared to meet. If a rule is volatile then we may need to consider a more flexible imple- mentation method than the most obvious one. For example, if the rule “Each employee can belong to at most one union at one time” might change during the life of the system, then rather than using an inflexible data struc- ture to implement it, the alternative of a separate Employee Union Membership table (which would allow an unlimited number of member- ships per employee) could be adopted. The current rule can then be enforced by adding a unique index to the Employee No column in that table. Removal of that index is quick and easy, but we would then have no limit on the number of unions to which a particular employee could belong. If a limit other than one were required, it would be necessary to enforce that limit using program logic, (e.g., a stored procedure triggered by insertion to, or update of, the Employee Union Membership table). Here, once again, there are alternatives. The maximum number of union memberships per employee could be included as a constant in the program logic or held as a value in the database somewhere, to be referred to by the program logic. However, given the very localized effect of stored procedures, 14.5 Implementing Business Rules ■ 429 Simsion-Witt_14 10/11/04 8:53 PM Page 429 [...]... Closure Branch No Date 18 63 Maintenance Local Holiday 1 2 12/25 /93 12/25 /93 12/21 /93 12/23 /93 3 4 5 12/25 /93 12/25 /93 12/25 /93 Figure 14.12 12/25 /93 National Closure Date Reason 6 12/25 /93 Christmas Post office closuresnormalized after subtyping 14.5 .9 Enforcement of Rules Through Primary Key Selection The structures available to us in data modeling were not designed as a comprehensive “tool kit” for... 14 Modeling Business Rules Post Office Closure Individual Branch Closure National Branch Closure INDIVIDUAL BRANCH CLOSURE (Branch No, Date, Reason) NATIONAL BRANCH CLOSURE (Branch No, Date, Reason) Individual Branch Closure Branch No Date Reason National Branch Closure Branch No Date Reason 18 63 Maintenance Local Holiday 1 2 12/25 /93 12/25 /93 Christmas Christmas 3 4 5 6 12/25 /93 12/25 /93 12/25 /93 ... are no longer so One solution is to hold the rules as data If such rules are central to the system, we often refer to the resulting system as being “table-driven.” Note, however, that no rule can be implemented by data values in the database alone Where the data supporting a rule is held in the database, program logic must be written to use that data While the cost of changing the rule during the life... relational data models can capture a variety of business rules in their structures, definitions, and supporting documentation The data in the resulting database will also serve to enforce business rules There are various techniques for discovery, verification, and documentation of business rules A conventional information system may implement rules in the data structure, declared constraints, data in the database,... plays havoc with our generalizations, breaks all our rules; history is baroque.” – Will Durrant, The Lessons of History, 196 8 15.1 The Problem Few areas of data modeling are the subject of as much confusion as the handling of time-related and time-dependent data Perhaps we are modeling data for an insurance company It is certainly important for us to know the current status of a client’s insurance policy... modeler, but they are the result of data administration policies applicable to all databases developed in the organization Business interest in such data is usually peripheral; stakeholders will have an interest in the overall improvement in (for example) auditability, but not in the mechanism used to achieve it If the changes to data structures are largely mechanical, and the data is not of direct interest... need to involve the data modeler and database administrator at all The amount of programming work will depend on how well the original programmers succeeded in localizing the checking logic It may include developing a program to run periodic checks on the data to ensure that the rule has not been violated by a rogue program 14.5 Implementing Business Rules ■ 435 14.5.2.3 Rules in Data Holding the rules... constraint that the customer who placed the 446 ■ Chapter 14 Modeling Business Rules National Closure Individual Branch Closure INDIVIDUAL BRANCH CLOSURE (Branch No, Date, Reason) NATIONAL CLOSURE (Date, Reason) Individual Branch Closure Branch Date Reason 18 12/21 /93 Maintenance 12/25 /93 63 Figure 14.13 National Closure Date Reason 12/23 /93 Local Holiday Christmas Final post office closure model order... recorded Once again the DBMS may allow such constraints to be specified in the database definition As always, the best approach is to document the constraints as you model and defer the decision as to exactly how they are to be enforced until you finalize the logical database design 14.5.7 Recording Data That Supports Rules Data that supports rules often provides challenges to the modeler For example,... Class B members to claim for paramedical services We now need to change the database design to include a foreign key for Class B members in Paramedical Claim We will also need to change the corresponding program logic In general, changes to rules contained within the data structure require the participation of data modelers and database administrators, analysts, programmers, and, of course, the users . expect that the data to support this process rule is going to be held in the database. 14.2.3 What Rules Are Relevant to the Data Modeler? The data modeler should be concerned with both data and process. include only the various data rule types listed above, whereas references to data that supports rules” covers both data that supports process rules and data that supports data rules. 14.3 Discovery. may not be recorded as data in the database itself. We discuss data that supports process rules in Section 14.5.7. Another example of a process rule that requires some data somewhere is “For