Re: In an RDBMS, what does "Data" mean?

Sir:

This is a good question.

"Laconic2" <laconic2_at_comcast.net> wrote in message news:t6adncXPEMhfsVfdRVn-sw_at_comcast.com...
>
> There's a second question, along the same lines.
>
> In the recent Pick example, showing an invoice, there's a list of
account
> numbers, and a correlated list of amounts.
> That is, the second amount "goes with" the second account number. But, in
> the earlier pizza pick example we had a list
> of three toppings and an uncorrelated list of three cheeses. Now my
> question is this: how the heck do you know that in one case the two lists
> are correlated and in the other example they are uncorrelated?
>
> Are you "just expected to know" the logical structure of invoices and
> pizzas enough to draw this inference?
> Not that there aren't things you "just have to know" in a schema of
tables,
> but the Pick people treat it as though it's "intuitively obvious". Maybe
to
> an SME, but maybe not to everybody else.

The database side doesn't normally enforce this relationship (it could be enforced with a trigger). However, considering the number of business rules associated with such a module, and the fact that the data is usually managed from a single application, these rules are best kept in the application code. This is because the business person is much closer to the application and database, and its tools. The database nomenclature is not unique and words mean what they've always meant (i.e. noone refers to a "row" or a "column" when referencing a customer or a list of their outstanding invoices).

The field definitions are where the descriptions of the field are kept. Any such relationships that exist (such as field#s 9 & 10 below) are also kept in the field definition. Again, it is not the database that enforces these rules, it's the application. You might see the following:

009 1010]1020]1050]1090
010 2500]32500]17525]15
011 9]12]33]34]35]36]37]38]39

in a customer record where:

009 - The G/L acct#s of recurring monthly billings (such as support fees).
010 - The amount of each G/L acct#s recurring billing amount.
010 - The unpaid invoices still associated with this customer.

This is very usual and a single disk read gets the salient properties of the customer record. The dictionary for the G/L acct#s may be defined as being the controlling field with a relationship to field# 10 while field# 10 is dependent on field# 9.

As you can tell, a well defined mvDbms application uses the field definitions to describe the data (as it should be) and relationships with other data (or other tables for that matter). Naturally, the field definitions are nothing more than data maintained in the database since they're just data too. :-)

Bill Received on Sat Jun 12 2004 - 03:36:08 CEST