Multiple Accessors Multiple Semantic Interpretations


Multiple Accessors = Multiple Semantic Interpretations

Database programs have an additional problem to resolve: Typically there are many programs accessing the data, each of which is relying on the fact that all the other programs are imparting an equivalent semantic on the data.

This turns out to be one of the central problems of large systems: The consistency of interpretation has historically been in the head of the analyst/designer. Methodologies and design approaches attempt to make as much of this as explicit as possible, but inevitably a large portion remains in the analyst's head.

Imagine a scenario where one program is updating an accounting file. Accounting systems typically have debits and credits, which often confuse programmers because they are arbitrary distinctions. So let's say a programmer was writing a program to process inventory adjustments. Because most of the adjustments decreased the inventory, the programmer made a local variable called "increase," which was mapped to the debit entry. (Inventory is an asset in which debits are increases.)

Another programmer comes along later, clones the program for use in accounts payable, and uses "increase," which to the second programmer means "increase the liability." However, because it is mapped to the debit field in the database, the opposite occurs.

This is just one possible scenario of the hundreds that come up in typical projects. Over the course of a project this tacit understanding evolves, and programs designed later in a project have the benefit of additional semantic richness or clarity.

There have been two responses to the problem of determining whether all the programmers (and therefore all the programs) are interpreting the model equivalently:

  • System testing—Since we can't ensure that all the programs treat the data consistently, we test as many combinations as possible of access to the data by different programs, in different sequences with different types, in hopes of uncovering a high percentage of the semantic mismatches.

  • Shifting semantic evaluation into the database—Another approach (and the two are often used in concert) is to take as much of the semantic interpretation as possible out of the code and put it where all programs must access it (e.g., database constraints or stored procedures).

Consistency

Assuming we can come up with a semantic description of the rules that we wish to apply to the data, how can we assure ourselves that the rules are consistent and complete?

For example, it is easy to define a rule that says that no time card can have negative hours on it, and another rule that says if time is charged to the wrong account it must be corrected by charging a credit to the incorrectly charged account. However, these rules can be implemented in many ways that would be inconsistent. If we are to have any hope of shifting the evaluation of semantics out of the individual application programs and into a shared part of the system (DMBS, middleware, etc.), we must have some way of determining whether we have a complete set of semantic constraints. We discuss this topic in more detail in Chapter 8.




Semantics in Business Systems(c) The Savvy Manager's Guide
Semantics in Business Systems: The Savvy Managers Guide (The Savvy Managers Guides)
ISBN: 1558609172
EAN: 2147483647
Year: 2005
Pages: 184
Authors: Dave McComb

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net