Re: In an RDBMS, what does "Data" mean?
Date: Mon, 14 Jun 2004 16:19:40 GMT
"Bill H" <wphaskett_at_THISISMUNGEDatt.net> wrote in message
> This is a good question.
> "Laconic2" <laconic2_at_comcast.net> wrote in message
> > There's a second question, along the same lines.
> > In the recent Pick example, showing an invoice, there's a list of
> > numbers, and a correlated list of amounts.
> > That is, the second amount "goes with" the second account number. But,
> > 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
> > 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
> > but the Pick people treat it as though it's "intuitively obvious".
> > 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
> associated with such a module, and the fact that the data is usually
> from a single application, these rules are best kept in the application
This is, more than anything, the philosophical divide between relational and Pick folks. The more rules, the more they should be kept OUT of the application code. "Application" means just that: a judicious application. Of what? Rules. Application != definition, just as implementation != specification.
> This is because the business person is much closer to the application
> and database, and its tools.
Their closeness is irrelevant; they should of course be given tools that let them do their job. But encoding the rules in those tools, as opposed to having those tools generated from and respectful of the rules, is a big difference.
Granted that some rules should be configurable; that doesn't imply that all should be. The business, after all, has (or needs!) some structure.
> The field definitions are where the descriptions of the field are kept.
> 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
> 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
> customer record. The dictionary for the G/L acct#s may be defined as
> 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. :-)
While I see many examples like the above, can you give us an example of how the dictionary defines those? What language do you use to define the dictionary? Is it user-accessible?