Where Are the Semantics in a Database Application?


We've reached the point where database applications have more explicit semantics, their semantics are introduced earlier and more strictly, and these semantics are available for application programmers to use. But this begs an even more interesting question: Where are the semantics? These semantics exist whether the designer of the system studied semantics or not. The database designer and the application programmer must deal with semantics, yet the definition of these semantics is often informally expressed and widely dispersed.

To begin the search for where the semantics currently live, we will start with an extreme case. Figure 5.4 is data, destined for a database, that will be processed by a database application program.

start figure

 ISA*00*          *00*          *ZZ*0          *ZZ*1234567 *020116*1123*U*00401*1107    *0*P*: GS*PT*0*1234567*20020116*1123*1107*X*0040101 ST*867*0001 BPT*00*1107*20020116*C1*****DP123456NoLosses N1*8S*Independent Electricity Market Operator*ZZ*0**41 N1*SJ*PARTICIPANT*ZZ*1234567**40 REF*LU*1234567 PTD*PM***OZ*EL REF*6W*1* REF*LU*1234567* REF*MG*1234567* REF*MT*KH005* QTY*QD*101652*KH MEA**MU*1.0*KH***22 DTM*150****DT*200201140000 DTM*151****DT*200201140005 QTY*QD*10060*KH QTY*QD*10436*KH QTY*QD*10012*KH QTY*QD*10110*KH QTY*QD*10642*KH QTY*QD*10538*KH QTY*QD*10491*KH 

end figure

Figure 5.4: Electronic data interchange (EDI) data.

An application program understands that this is data, and not noise, by reading it into an input area and then applying some rules (known to the program, and by extension to the person who wrote the program) to the data. The rules left over from the old days of punched cards tend to be based on fixed-length fields (e.g., in Figure 5.5 the price might be in columns 31 through 37). However, as we went beyond that we adopted many conventions for rules to help us understand the data, including the following:

  • Field lengths (the first two bytes tell how long the next field is)

  • Delimiters (everything up to the next "special character" is one field)

  • Repeaters (the following field or fields repeat n times)

start figure

          1         2         3         4         5 12345678901234567890123456789012345678901234567890 Perpetual InSmith Trident000100099506012002 

end figure

Figure 5.5: A fixed-field data record.

Once we find the fields in a chunk of data, the next challenge is interpreting them. Is "01-05-02" a date, a part number, a lock combination, or a string? If it's a date, what date is it? Is it May 1 or January 5?

The same sort of issues concern us when we write new data to the database, with the added issue of having to conform to some additional rules that writers of data need to be interested in (e.g., "This number must be not only an integer, but must be less than 25").

In a sense, the semantics of the data are applied by the mind of the programmer, enter the code, and subsequently "manage" the semantics of the data.

So far so good, but we've brushed aside several issues that end up being the crux of the problem:

  • How does a subsequent programmer determine what the first programmer had in mind?

  • How do we deal with these semantic issues in cases where we allow multiple programs to access the same set of data?

  • How do we know that what the programmer intended was implemented consistently and completely?

The Next Programmer

The obvious nonanswer is "documentation." It is a nonanswer because of how rarely useful program documentation is written, and how rarely programmers refer to it.

What programmers do is read the code. And what they do as they read the code is attempt to extract the semantics of the code into a form that they can understand, and then modify it accordingly.

To do this, they rely on a few clues that they hope the previous programmer has left for them. Note that these conventions have become so well established that we sometimes forget that they are there entirely for the subsequent programmer (even if it is the same programmer who comes back to it later).




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