7M840

Chapter 5

Chapter 5: Decision Tables

5.1 Introduction The representation of expert knowledge in formal systems for developing knowledge models or expert systems require a number of subtasks. These include: The acquisition of models from knowledge sources (human experts, written material) The formal representation of the knowledge using some formalism (e.g., ifthen rules, frames, objects, belief networks) The implementation of the knowledge in a computer program (e.g., using a dedicated expert system shell or a basic programming language) Verifying and validating the knowledge system

None of these steps is trivial and in particular the acquisition of knowledge and verification and validation of a knowledge model has often been a bottleneck in the successful application of knowledge modeling techniques. The Decision Table is a technique that has specific advantages in particular with regard to acquisition, verification and validation phases. It can be seen as a method to arrange a set of ifthen rules related to some decisions in a table format. The table offers a very legible way of representing the knowledge that greatly facilitates the mentioned tasks. At the same time, it allows one to model very complex knowledge systems, as decision tables can be linked to each other in an hierarchical structure. In this chapter, we introduce the decision table formalism and describe how it can be used to model decision problems and develop knowledge models. The text of this chapter is taken from the following sources: Sections 5.2 5.4: F. Witlox (1998) Modelling Site Selection: A relational Approach Based on Fuzzy Decision Tables, Eindhoven University of Technology, Ph.D. thesis). Sections 5.5 5.6 Arentze, T.A. (2003) The decision table as a design knowledge modeling technique, lecture notes, Eindhoven University of Technology.) 5.2 What are Decision Tables? A decision table (DT) - also termed an inference or logical tree - provides a schematic view of the inference process of a decision-making process. Each decision rule of a DT is composed of a premise (condition) and a conclusion (action). In its tree-like representation, the premises and conclusions are shown as nodes, and the branches of the tree connect the premises and the conclusions. The logical operators AND and OR are used to reflect the structure of the if-then rules. As such, decision tables (DTs) do not seem to differ much from a decision tree. Instead of specifying a table, the choice maker constructs a graph of the decision alternatives emanating as branches from a root node over a number leafs. There are, however, some important

7M840

Chapter 5

differences between both approaches. The advantage of the DT is that it provides a more compact visual presentation and, thus, contributes to a better comprehension of the choice problem. But probably the most important advantage is that using a DT the completeness, correctness and consistency of the information input is easier to check. Thus, in a way, a DT may be regarded as a special case of a decision tree because it fulfils certain logical constraints. Decision tables were initially introduced over three decades ago, primarily as a method in software engineering for structuring computer programmes. It was found that, as a formalism, DTs were very well-suited to describe and analyze problems that contain procedural decision situations which are characterized by a set of influential conditions, the state of which determines the execution of a set of actions (CODASYL, 1982, p. 2-1). Later on, several other important application domains such as manual decision-making, system analysis and design, representation of complex texts, verification of knowledge bases, and knowledge acquisition emerged. In recent years, the potentials of DTs as a conceptual modelling language for representing qualitative and complex knowledge have been investigated (Lucardie, 1994). In respect to this latter point, both Vanthienen (1986) and Lucardie (1994) have developed specific software (e.g. PROLOGA95 and AKTS) for constructing decision table based knowledge-based systems. These DT engineering workbenches have created a significant added value to the use of the DT technique. In this chapter, our goal is twofold. First, the concept of a DT is defined and some new terminology introduced (Section 5.3). Second, the actual construction of a DT is analyzed and explained in a step-by-step manner (section 5.4). 5.3 Definition of a decision table A decision table (DT) is a table that represents the exhaustive set of mutually exclusive conditional statements within a pre-specified problem area (Verhelst, 1980, p. 9). It displays the possible actions that a decision-maker can follow according to the outcome of a number of relevant conditions. The general structure of a DT is shown in Figure 5.1. An example of a specific DT is represented in Figure 5.2. This DT considers the question whether a given neighbourhood shopping centres meet minimum requirements regarding the available stores in the centre. The actions of the table correspond to possible measures aimed at improving the store composition of the shopping centre. The rules are based on a definition of what is generally considered a basic package of daily good supply in the Dutch context.

Problem area CONDITION SET ACTION SET CONDITION SPACE ACTION SPACE

Figure 5.1: The general structure of a decision table

7M840
Choose centre-supply action Number of supermarket C1 outlets m2 gross floor space of the C2 supermarket All fresh products are C3 available Expand floor space of A1 supermarkets A2 Open large supermarket Open complementary A3 specialty stores

Chapter 5

None X
R1

One < 700 X

R2

More than one > 800

R5

700 800 no X
R3

R6

yes
R4

(Source: Arentze, 1999)

Figure 5.2: Decision table for Centre-supply actions

Each DT is identified by the problem area it investigates (e.g. select a suitable location). The table is split by a double line, both horizontally and vertically. The horizontal line divides the table in a condition part (above) and an action part (below). The vertical line divides the sets or stubs or subjects (left) from the spaces or entries or states (right). The result is four quadrants: condition set [Ci], action set [Aj], condition space [SPACE (Ci)] and action space [SPACE (Aj)]. The condition set consists of all the relevant conditions or attributes (inputs, premises or causes) that have an influence on the decision-making process. For instance, in respect to the choice of a business location, the set of relevant conditions consists of all attributes that influence the process of selecting a location site. The example DT (Figure 5.2) contains three conditions. More formally, Ci denotes a condition with domain CDi (i = 1, ..., Cnum) with i, the numerical index indicating the condition, and Cnum, the number of conditions. The condition space specifies all possible combinations of condition states of the conditions. The number of possible condition states is unlimited, at least in theory. The condition space i.e. the set of condition states of a condition i could range from two to any desired number. However, the more condition states used, the more complex the decision table structure will be. Binary condition states (e.g. yes/no) are termed "limited-entry" conditions. Condition states that can account for more than two possible outcomes are termed "extended-entry" conditions. A DT that combines both limited and extended entries is termed a "mixed-entry" DT. The example DT has both limited and extended entry conditions and therefore is of the mixed type. Condition states that are irrelevant for a certain decision rule are marked with the socalled "don' t care" entry (denoted: "-"). This "don't care" entry is equal to stating that all condition states are allowed in a disjunction. The action set contains all the possible actions (outputs, conclusions or consequences) a decision-maker is able to take. This is to say that the action set points to the possible choice outcomes if, for instance, an existing location with a number of specific characteristics is processed through the DT. DTs can account for as many actions as the decision-maker feels it necessary to introduce. The example DT has three actions each of which can take on two values. The formal notation of an action set is as follows. Aj (j = 1, ..., Anum) denotes an action set with j, the numerical index indicating the action, and Anum, the number of actions.

7M840

Chapter 5

The action space of an action j contains all the possible action states of that action. The number of possible action states is also unlimited. However, frequently, DTs confine the number of action states (not number of actions) to three. These are "-", "X" and ".". The narrow line ("-") indicates that the particular action may not be executed, the cross-sign ("X") implies that the particular action must be followed, and a dot (".") signifies an undefined action state. This method is also used in the example DT. The strict separation between conditions and actions may not always be as simple as it might look. Some actions are bound to a condition, implying that they have to be executed before testing the condition, while others may already be executed after testing one or more conditions. Also, condition sets and action sets may themselves refer to other decision tables. For example, an action may involve a call to a procedure to perform some task, or a condition may be defined by another decision table. A decision table called in that way by another decision table is termed an action- or a condition-subtable. These subtables play an important role in structuring the decision problem and permit a more thorough and detailed analysis (see below). Finally, any vertical linking of an element out of the condition space with an element of the action space produces a so-called logical rule [R]. This logical rule is in fact a simple conditional statement or an "if...then" decision rule. For example, rule R2 of the example DT states: if (C1 = one AND C2 < 700) then do A1. Apparently, in order to account for exhaustiveness and exclusiveness, two logical constraints must be fulfilled for each condition state of a DT. The first constraint states that the union of all condition states of a condition (CSi) should be equivalent to the domain of that condition (CDi). The second constraint states that the intersection between different condition states of a condition should yield the empty set. 5.4 Construction of a decision table Verhelst (1980, p. 23) distinguishes three methods to construct a decision table or decision table system: (i) a direct method on the basis of singular (simple) decision rules; (ii) a direct method on the basis of composite (complex) decision rules; and (iii) a search method. Although, these three methods are different on a number of factors (see below), they deal with comparable stages or steps when converting a decision problem into a DT. The main difference between them is the order in which these stages are treated and the way they are worked out. In sum, five stages may be distinguished (Vanthienen, 1986; Vanthienen and Wets, 1994, p. 269): (i) Definition of conditions, condition states, actions and action states for the specific choice problem; (ii) Specification of the problem in terms of decision rules; (iii) Construction of the DT on the basis of the decision rules; (iv) Check for completeness, contradictions and correctness; (v) Simplification, optimization and depiction of the DT. In reality, the construction of decision tables is often not a linear process, as the above procedure seems to suggest because of the complexity of the task. The different stages

7M840

Chapter 5

indicate a way to structure this task. In what follows, we elaborate on each of these five stages. When building a DT, an essential and rather straightforward first step is the identification of the conditions and actions and their associated states that have an influence on the decision problem. In this respect, the three above-mentioned DT construction methods strongly resemble conventional quantitative or other qualitative approaches. Usually, the expert is asked to list or name all conditions that are deemed important in evaluating a choice alternative. These verbal records or protocols can be completed with conditions derived from other sources (e.g. literature survey). As such, a combination of condition-determining approaches is used that define the influential conditions both a priori and a posteriori to the expert's answers. Next, the condition states are defined. It is important to note that the expert is not limited to only two states. The expert is able to express as many states as he or she feels necessary in order to logically evaluate a certain condition. All attributes are evaluated in terms of their logical condition states; whether they are limited or extended entries is not important. This offers a greater flexibility to the researcher. Also, the use of (different) multiple response categories implies that conditions are allowed to interact (so-called conceptual interaction). Linked with the aspect of condition categorization is that also dependencies between conditions are taken into account (so-called conditional relevance). As such, a condition like "distance" can be categorized into three, five, or, for that matter, any other number of different categories. Comparable to the condition and condition state specification, the possible actions and action states need to be determined. Again, this can be accomplished by asking the expert what possible actions he or she anticipates in considering the choice alternatives. The number of actions will depend on the nature of the choice problem, and is therefore not limited. As a rule, conditions and actions have to be unambiguous, relevant and realistic to the expert. All condition recurrences, as well as all complementary conditions, should be avoided. Conditions that depend upon other conditions should separately be treated, and ranked in such a way that dependent conditions follow independent conditions. In respect to the categorization of the conditions, two important logical requirements must be fulfilled: exhaustiveness and exclusiveness. Exhaustiveness means that the DT must account for all possible states that a condition is able to take. The exclusivity requirement refers to the fact that each combination of condition states has to be included in one and only one column of the DT. A brief example will perhaps further clarify both logical requirements. Suppose, for an arbitrary chosen condition "distance" (d), the condition states are specified as follows: d < 100, 100 d 150, d > 150. It is c1ear that this condition categorization is exclusive because no single distance can at the same time fall in more than one category. In addition, the categorization is also exhaustive because all possible distances are captured in either one of the three condition states. Therefore, an important property of using decision tables is that the condition states are mutually exclusive but jointly form an exhaustive set. The second stage in the construction process concerns the specification of the decision rules. A decision rule is a logical vertical link between elements of the condition space (antecedent or premise) and action space (consequent or conclusion). It can be compared with a simple "if...then" decision rule. By this is meant: if faced with a

7M840

Chapter 5

number of conditions, then execute a certain action. This kind of decision rule corresponds to the form of a disjunct set of conjoint conditional statements. With respect to the three above DT construction methods, different decision rules or techniques are applied. In the first direct method, singular (or simple) "if...then" decision rules are advanced. This implies that each possible combination of condition states will lead to exactly one and only one action state or column of the table. The result is a totally unambiguous, but rather complex DT. To illustrate, if a location site is characterized by nine conditions, all defined in terms of only two condition states, this will result in 29 (or 512) singular decision rules. Clearly, such a table is too complex to be interpreted. The second direct method deals with composite (or complex) "if...then" decision rules and is somewhat more difficult to understand. Composite rules are based on the combination of singular rules in such a way that in a column for a particular condition, its associated states are being contracted. Thus, singular rules are joined to form a composite rule. A brief example may clarify this somewhat further. Suppose that a DT consists of only two conditions (Cl and C2) with associated condition states (CS11, CS12) and (CS21, CS22, CS23). In a singular DT, this would result in six columns or six singular decision rules. Assume further that for CS12, the condition states of C2 become irrelevant. Thus, in the CS12-column, CS21, CS22 and CS23 may be combined in a single state, namely the so-called "don't care" entry (denoted: "-"). The result is a composite DT that has only four columns (three singular rules and one composite rule). Such grouping or contraction of condition states may cause a loss of overview, and with it, a loss of the simplicity needed to control the exclusivity and exhaustivity requirements of the DT. Therefore, composite rules are only used for problems that are relatively simple and easy to understand. In the third approach, the search method, yet another technique is applied, which is called equivalence class or rule class. The idea was advanced by the Decision Table Task Group of CODASYL (1982). Equivalence class ruling denotes all simple decision rules that have identical or equivalent action states, regardless of the combination of the condition states. Therefore, decision rules are assumed functionally equivalent if they point to identical action states although they are based on different combinations of condition states. For example, translated to the choice of business location, two location sites are assumed functionally equivalent if both locations, although having very different characteristics, can perform an equivalent function (i.e. site suitability) for an economic activity. To further illustrate the search method and the technique of functional equivalence in DTs, we refer to the abstract DT presented in Table 5.1 (Verhelst, 1980, pp. 72-73; CODASYL, 1982, pp. 5.95.11).
Table 5.1: Construction of an abstract multiple-hit DT using the search method
Condition C1 Condition C2 Condition C3 Action A1 Action A2 Action A3 Action A4 c Y X X X N X X Y X X a d N X X Y X e N Y f N Y b g N Y h N

7M840
Decision rule Frame of functional equivalence
R1 R2 R3 R4 R5

Chapter 5

Suppose that an analyst, when constructing a DT, has come to a situation as depicted in Table 5.1. So far, five decision rules have been identified, and in this early stage of the construction process, it is clear that the decision rules R2 and R4 fall within the same frame of functional equivalence. This is because the two particular decision rules exhibit the same configuration of action states, although their associated condition states (acN and adN) are different. When such a frame of functional equivalence is detected, the analyst is interested in whether a statement like "a no for condition C3, always implies that both actions A2 and A4 must be executed?" is true. There are two possible outcomes: either this statement is not true, in which case the analyst continues in further defining decision rules R6, R7, etc., until a new frame of functional equivalence is observed for which the same procedure is then followed; or, the statement is presumed true, in which case the analyst confronts the expert with other combinations of conditions states of Cl and C2 (C3 still being equal to "no"), and examines whether action A2 and A4 still have to be executed. To reduce the complexity of the analyst's task, one is able to work statistically. For instance, the expert is confronted with only 50% or 75% of all possible combinations of condition states of Cl and C2. If in all cases the result stays unchanged, one may take for granted that a "no" for C3 automatically results in executing A2 and A4. The remainder of the analysis can then be concentrated on what the expert will do if C3 takes the condition state "yes". A consequence of functional equivalence is that the DT will not lead to a unique choice, but represents a number of functionally equal choices. It is important to note here that DT's satisfy the necessary conditions for reconstructing decision rules defining functional equivalence. With respect to the definition of decision rules, it is also useful to refer to the existence of what is termed the ELSE rule (Verhelst, 1980, p. 90; CODASYL, 1982, p. 3.41). The ELSE rule is a rule that is executed when none of the other decision rules in a DT are satisfied. It may be viewed as a kind of "catch-all" when all other rules fail. Usually, the ELSE rule is placed as the last decision rule in a DT. The application of the ELSE rule brings with it two important drawbacks: (i) the control for completeness is lost, and (ii) the DT becomes less manageable and interpretable as several decisions are put together in one single column. Consequently, the use of the ELSE rule should be avoided. The third stage deals with the actual construction of the DT on the basis of the defined decision rules. The ranking of conditions and actions in the table is not subject to a strict hierarchy. However, certain logic in the condition order should help in the task of interpreting and optimizing the DT (see also stage 5). Usually, dominant or socalled veto conditions are put at the top of the table because of their noncompensatory character. Also, in view of optimization, it is better to list conditions which have fewer condition states before conditions with relatively more condition states. Similar, conditions which are deemed more important to the choice problem need to be followed by the more impractical (or theoretical) conditions. After all, it is less plausible or likely that a decision-maker will disregard an attribute which seems to have a greater hearing upon the choice problem than that he or she will ignore a more impractical but theoretically possible influential attribute. Usually, conditions appear only once in the DT. By being able to organize and rearrange conditions and

7M840

Chapter 5

condition states in a DT, it is clear that the DT formalism supports the systematic account of conditional relevance of attributes and conceptual interactions between attributes. Both mechanisms underlie the concept of functional equivalence. The fourth stage examines the DT with regard to the requirements of completeness, contradiction and correctness. Here, an automatic check is presented to detect certain specification errors. First, the check for completeness verifies whether the table contains decision rules, which have empty action states. In other words, an incomplete DT is a table in which decision rules are missing. If this is observed, it can be rectified. Second, the DT is controlled for contradictions. A contradiction occurs if, leaving aside the ELSE rule, two action states which exclude one another must be executed at the same time. Such a contradiction usually follows from a bad specification of the condition states. Third, if a DT is complete and no decision rules are contradictory, this still does not mean that the decision rules are correct. The correctness of a decision rule depends on the expert's interpretation. As a result to the exclusive and exhaustive character of DTs, all potential condition states are combined to generate action states, including those combinations of condition states that result in unwanted, unrealistic and overlooked action states. In this stage of DT construction, these action states may be spotted and defined so that the DT will produce only valid decision rules. In practice, this comes down to investigating whether every individual decision rule is correct (Verhelst, 1980, p. 18). The fifth and final stage deals with the simplification, optimization and depiction of the DT. Optimization in this context refers to the minimization of the number of decision rules in a DT. In other words, redundancy in the decision rules should be avoided. There are several ways to optimize the lay-out and execution time of a DT. Table contraction is one possibility, row order optirnization another (Vanthienen and Dries, 1994, p. 227)

7M840

Chapter 5

Table contraction (or rule collapsing) refers to the minimization of the number of columns for a given condition order by combining (groups of) columns which lead to the same action configuration. In other words, the number of columns is reduced by contracting singular to composite decision rules. Table contraction should always be preceded by the check for completeness, contradictions and correctness. The reason is that once the table has been contracted, it is difficult to uncover decision rule errors. Row order optimization opens the possibility of decreasing the number of (contracted) columns by changing the order in which the conditions are noted in the table. For a table with n conditions, this implies a choice between n! alternative condition orders. Some rankings, however, might not be feasible due to previous constraints (e.g. condition dependencies). A third way to optimize and structure a DT is by using subtables. A subtable may be defined as a decision table wherein actions function as conditions in an upper-level decision table. Subtables may themselves be subject to other subtables. Figure 5.3 shows a simple abstract example of a three-level decision table system with subtables. Figure 5.4 shows an example of how a decision table can be optimized using both the techniques of table contraction and row order optimisation. (a) Full table
C1 C2 C3 A1 A2 A3

Y Y Y X Level3 X
R1

N N Y N X
R4

N N X
R6

CR 7 C8 C3 C9 C10 C
4

N X
R2

Y X
R3

Y Level X
R5

Y X
R7

N X
R8

Level 1

C3 C4 C1

C1 C2 A C5 C6 C2
1

C11 C12 C5 C13 C14 C

6

(source: Lucardie, 1988, p.74)

Figure 5.3. The structure of a three-level DT with subtables

7M840 (b) Table contraction

C1 C2 C3 A1 A2 A3

Chapter 5

Y Y Y X X
R1

N N X
R2

Y X
R3

N X
R4

Y X
R5

N X
R6

(c) Row order optimization

C3
C1 C2 A1 A2 A3

Y Y Y X X
R1

N X
R2

N X
R3

N X
R4

(Source: Vanthienen and Wets, 1994, pp. 270 272)

Figure 5.4: Optimization of a DT using two different transformations

In Figure 5.3 on the highest level (level 1) only two conditions (Cl and C2) explain the action state of A1. It can, however, be noted that both Cl and C2 are subject to the outcome of the subtables defined on the second level, and also subject to the results of the subtables specified on the third level. Therefore, defining C7, C8, C9 and C10 results in the specification of both C3 and C4, which in turn defines the condition state of Cl, Thus, Cl is defined as a combination of four other condition states (CS7, CS8, CS9 and CS10). In a similar way, C2 is also defined as a combination of four condition states (CS11, CS12, CS13 and CS14). Note that, in this simple example, the conditions C3, C4, C5 and C6 do not have to be specified because they are determined by the outcome of the two subtables on the third level. This property of generating knowledge from lower level condition state information is an important advantage of using a DT system. An additional characteristic of using subtables is that the concepts defining the conditions on higher levels may be more abstract than those on lower levels. Or, the higher (lower) the level in a DT, the more abstract (concrete) the concepts may be defined. Usually, this property entails that a condition relating to an abstract concept may be further specified through the use a condition subtable. Conditions in a condition-subtable may in turn be further worked out in a subtable at lower level and so on. In many applications, DTs are connected through such condition-subtable links giving rise to an entire hierarchical system of decision tables. The highest level table specifies in abstract terms the decision rules in a problem domain. Subsequently, a system of subtables elaborates in more concrete terms these abstract concepts. The conditions used at the end points of the hierarchy should be defined in such a way that they can be matched with the observable attributes (Arentze et al., 1996, p. 8). 5.5 Examples of decision tables in planning and design

7M840

Chapter 5

Example 1 An existing situation, no matter whether it concerns a building or an urban area, needs to be continuously monitored to see whether, as a consequence of changes over time, it still comes up to given objectives and constraints. If not, then there is a problem that needs an intervention of some kind. Thus, the task here is to 1) analyze the performance of an existing building or urban system and 2) compare the performance with planning/design standards. Several variants of the task exist that we may wish to represent in a DT. In order of increasing complexity, these include: 1. The DT just checks whether or not there is a problem; 2. In addition to 1, the DT also gives a diagnosis of the problem; 3. In addition to 2, the DT also suggests an intervention. Consider the following example: Example 1 A shopping centre attracts too few customers and the risk exists that one or more stores in the centre will be forced to close. An analysis reveals that the poor performance is not caused by a decline of the catchment-area population or by increased competition from neighbouring centres. Rather, the centre has become less attractive over the years due to a declining attractiveness of shopping streets. So, in this case, we can conclude: 1. 2. 3. There is a problem (if we do not intervene the centre will loose The cause of the problem is a decline of attractiveness of shopping It is wise to intervene and refurbish the centre.

quality); streets;

A DT that performs detection of the problem, diagnosis and intervention suggestion all in one step may look like the following:
Performance of shopping centre C1 Number of visitors C2 Demand shortage C3 Maintenance A1 Problem A2 Suggested intervention < Norm Yes Viability Close R1 No < Norm Maintenance Refurbish R2 >= Norm Unknown Unknown R3 >= Norm None None R4

Demand shortage of shopping centre C1 Population base C4 Competition A1 Demand shortage

< Norm Yes R1

< Norm Yes R2

>= Norm >= Norm No R3

Examples 2 and 3

7M840

Chapter 5

Before making a plan/design, experts are asked to establish the (functional or technical) requirements the design must meet, considering the needs and constraints imposed by users, policies, the environment, etc. Example 2 The number and size of meeting rooms needed in an office building depends on the activities of the organization to be accommodated. The critical factors include the frequency formal meetings take place, the number of persons involved in meetings and the frequency of central meetings involving all employees of the organization. The decision table in such a case may look as follows.
Required number and size of meeting rooms C1 Formal meetings take place Number of persons involved in a C2 formal meeting Frequency (/week) formal C3 meetings Frequency (/week) formal C4 central meetings Required number of meeting A1 rooms Required size of meeting rooms A1 (m2)

No 0 0 R1 <2 0 0 R2 <5 [2,5) 0 0 R3

Yes [5,10) >= 5 <2 1 >= 2 2 <2 3 [2,5) 0 0 R7

15-30 15-30 15-30 R4 R5 R6

7M840

Chapter 5

Example 3 There are different levels of protecting an office building against burglary possible and the appropriate level for an organization will depend on characteristics of the organization. The following decision table could represent the decision rules.
Required level of burglary protection C1 Protection of persons required Protection of vital processes C2 required C3 Burglary sensitive items present Loss of burglary sensitive items C4 is fatal Storage of burglary sensitive C5 items in safe is possible Required level of burglary A1 protection Yes High R1 Yes High R2 Yes No R3 No No Medium R4 Yes No R5 Yes Yes No High R6 No No No No R7

Example 4 and 5 This task of analyzing and evaluating solutions is relevant in different problem contexts, including: 1. Eliminating infeasible solutions; 2. Making a choice between alternative solutions; 3. Making a decision on whether or not to accept a plan/design proposal, for example, from a developer. Analysis and evaluation refers to different problems. Analysis involves an assessment of the performance on some criterion and evaluation refers to a comparison of the actual performance with objectives/constraints. Therefore, variables such as suitability, feasibility and utility would typically be used in an evaluation context, whereas more value neutral terms are used to express analysis results. Even though analysis and evaluation are different, from a knowledge modelling perspective they are equivalent in the sense that both involve some classification of solutions. The following examples illustrate an analysis and evaluation step respectively. Example 4 The extent to which a (office) building facilitates internal transport of goods is a performance aspect that is relevant for at least some types of organizations. The following decision table describes a method to assess this performance aspect based on attributes of the building.
Capacity of internal goods transport C1 Goods are deliverable at the entrance C2 Intermediate storage of goods can be implemented C3 Width of alleys to intermediate storage place A1 Capacity of internal goods transport

No No Low < 180 Low Yes >= 180 Average No Low

Yes Yes < 180 Average >= 180 High

7M840
R1 R2 R3 R4 R5

Chapter 5
R6

Example 5 A location is feasible for a shopping centre if there is sufficient market potential for a shopping centre at the location, the location is well accessible and a new centre would not distract too much turn over from existing centres. This rule can be represented in a DT as follows:
Feasibility of candidate location for shopping centre C1 Market potential for a shopping centre C2 Accessibility of the location C3 Impact on existing shopping centres A1 Location is feasible for shopping centre

< Norm No R1 < Norm No R2

>= Norm >= Norm < Norm No R3 >= Norm Yes R4

Example 6 and 7 In making a choice, a number of alternative solutions are given and a decision is to be made which alternative to select as the solution. We distinguish two possible subtypes of this problem. First, the alternative solutions have not been evaluated on relevant criteria. Then, the decision table should define under which conditions which alternative is to be chosen. Example 6 If it is feasible to develop a shopping centre at a given location, the question becomes what class of shopping centre should be developed. Planners generally distinguish three or four orders depending on the size and store mix. For example, a low-order centre includes only stores for daily-goods and typically serves a neighbourhood, whereas a large-order centre also includes stores for non-daily goods and typically serves a whole city. The simple rule stating that the highest possible order is to be preferred could be represented in a DT as follows:
Choice of shopping centre size C1 Market potential A1 Shopping centre size <X1 Low order R1 [X1, X2) Medium order R2 >= X2 High order R3

where X1 and X2 is the minimum market potential needed for a medium-order and large-order respectively. Second, the alternatives have been evaluated on a number of relevant criteria. If there is a solution that outperforms all other solutions on each criterion, then making a choice is easy. However, in general this is not the case and making a choice requires trading-off criteria. We argue that the decision table is not a suitable technique for this task. In many cases it is more natural to express the relative importance of criteria by using quantitative weights and calculate an overall score for each alternative based on these weights. To represent this method by a decision table, the condition space should be fully split up to express all

7M840

Chapter 5

possible combinations of weights in separate columns. In contrast, a simple quantitative model would represent the method in a much more efficient way. Example 7 The suitability of a solution is given by the following weighting scheme (numbers between brackets are weights):
Criterion Economic impact (0.6) Environmental impact (0.3) Social impact (0.1) Performance High (0.7) Average (0.2) Low (0.1) High (0.5) Average (0.3) Low (0.2) High (0.8) Average (0.15) Low (0.05) Combined weight 0.420 0.120 0.060 0.150 0.090 0.060 0.080 0.015 0.005

Following this weighting scheme, a decision table representation would give:

Suitability of candidate location for shopping centre C1 Economic impact C2 Environmental impact C3 Social impact A1 Suitability

High High 0.65 R1 High Av 0.585 R2 Low 0.575 R3 High 0.59 R4 Av Av 0.525 R5 Low 0.515 R6 Low High 0.56 R7

which is needlessly cumbersome. 5.6 Combining decision tables and quantitative methods In many cases, a solution to a decision problem requires the application of a combination of quantitative and qualitative knowledge. In DTs, it is relatively straightforward to integrate quantitative models that perform some calculation for example to determine the value of a condition variable or to execute an action. How this can be done can best be shown by some examples. Example 1 Electric power supply in office buildings is usually expressed in Watt per nett-m2 floor space. The demand of electric power by an organization can be calculated as a function of the amount of lighting and electric devices needed. The following DT evaluates the extent to which available supply in a building matches the electric energy consumption rate of a given organization.
Availability electric power supply C1 Electric power demand (W /netto-m2) < 0.95 * {Electric power supply (W /netto-m2)} [0.95 *{Electric power supply (W /netto-m2)}, 1.05 *{Electric power supply (W /netto-m2)}] Sufficient R2 > 1.05 *{Electric power supply (W /netto-m2)}

A1

Availability electric power supply

Undersupply R1

Oversupply R3

7M840

Chapter 5

In the table, the condition variable Electric power demand (W/netto-m2) is defined by a quantitative function, whereas the value of Electric power supply (W/netto-m2) can be retrieved from a database. If the DT is executed and the value of the condition variable is unknown, the DT calls the function and, after having received the value from the function, proceeds to evaluate the condition statements on the right hand side of the table. Example 2 In general, planners consider the opening of a facility (e.g., a shopping centre) in an area (e.g., neighbourhood) if there is enough market potential and there are currently no facilities (of that type) present in the area. This simple decision rule is expressed in the following DT:
Reconsider facility provision There are facilities in the C1 zone Market potential for a C2 facility unit Close facility unit A1 A2 A3 Open facility unit Determine facility unit size No Insufficient No No No R1 Dubious OR Sufficient No Yes Yes R2 Insufficient Yes No No R3 Yes Dubious OR Sufficient No No Yes R4

The table illustrates the use of a procedure call in the action section of the table. A1 and A2 are conventional action variables that are assigned a value in execution of the table. However, A3 is special in that it refers to a procedure for, in this case, determining the (optimal) size of a new facility unit given the characteristics of the area and the facility. In columns R2 and R4 the procedure is activated. Furthermore, it is worth nothing that C2 also involves a call to a quantitative method, namely a function computing the market potential of the area for a facility. Thus, the table illustrates a case where procedure or function calls are included in both the condition and action section. 5.7 Executing decision tables Executing a DT involves evaluating the condition statements from top to bottom until a unique column is selected and, next, executing the action specified in that column. Since the execution procedure is fully structured it is possible and in fact straightforward to automate this procedure and let the computer execute DTs, for example, in the context of a larger design or decision support system or some other information system. To write a program that can execute DTs a few notes are in order. Most importantly, the program should be able to find the values of relevant condition variables for identifying the appropriate column. An if-needed procedure can be written in such a way that it can be used for any condition variable and any decision table. The method should be based on the following rule.

7M840

Chapter 5

If the value of the condition variable is unknown than try to find it by consulting the following sources: 1. If the condition variable is a call to a function than execute the function; 2. If the condition variable is defined in a subtable than execute the subtable; 3. If the value of the condition variable is stored in the database than retrieve the value from the data base; 4. Ask the user to enter the value. The method should try the sources in this order and stop the moment the value of the condition variable is found. Asking the user is the last resort in this procedure. With respect to the choice of a dialog form, the variable type is important. If the condition variable is a categorical variable, the dialog used should include a list box (or some other closed form) from which the user can select the right category. If, on the other hand, the condition variable is a continuous variable (e.g., quantitative) an edit box in which the user can enter input in a free format is more adequate. In the last case, it is important to check whether the answer given falls in the allowed range of the variable and return an error message if the value is outside the range. 5.8 References Arentze, T.A. (1999) A Spatial Decision Support System for the Planning of Retail and Service Facilities. Ph.D. Thesis. Eindhoven University of Technology. Arentze, T.A., G.L. Lucardie, H. Oppewal, H.J.P. Timmermans (1996) A Functional Decision Table Based Approach to Multi-Attribute Decision Making. Paper presented at the 3rd International Conference on Retailing and Consumer Services Science held in Telfs/Buchen, Austria, 22-25 June, 1996. CODASYL (1982) A modern appraisal of decision tables. Report of the decision table task group of the conference on data systems languages (CODASYL). New York, Association for Computing Machinery (ACM). Lucardie, G.L. (1994) Functional object-types as a foundation of complex knowledgebased systems. Rijswijk, TNO Bouw, Ph.D. thesis. Vanthienen, J. (1986) Automatiseringsaspecten van de specificatie, constructie en manipulatie van beslissingstabellen. Leuven, Katholieke Universiteit Leuven, Departement Toegeapste Economische Wetenschappen, Ph.D. thesis, Nr. 60. Vanthienen, J. and E. Dries (1994) Illustration of a decision table tool for specifying and implementing knowledge based systems, International Journal on Artificial Intelligence Tools, 3, 267-288. Vanthienen, J., G. Wets (1994) From decision tables to expert system shells, Data & Knowledge Engineering, 13, 265-282. Verhelst, M. (1980) De praktijk van beslissingstabellen. Deventer and Antwerp, Kluwer. Witlox, F. (1998) Modelling Site Selection: A relational Approach Based on Fuzzy Decision Tables, Eindhoven University of Technology, Ph.D. thesis.