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

"Anthony W. Youngman" <wol_at_thewolery.demon.co.uk> wrote in message news:oCcd7SN$x6xAFw31_at_thewolery.demon.co.uk...
> What I'm saying is that maths is great at building a model. But without
> science you can't say that any model is useful. Without science, a model
> is just an intellectual exercise of no value to the real world.

You've probably said it before, and it makes sense. But most sciences verify their theorems using prediction and comparisons with real-world phenonema. We don't have that luxury, since we can build working systems with various data models and languages and frameworks, and any experiments designed to measure overall productivity in system creation and maintenance have to take colossal human factors into account... is there some way of testing the models - or actually the meta-models?

> >> Let's take the evolution of that theory I keep on throwing out as an
> >> example.
> >>
> >> Copernicus : orbit == circle
> >> Kepler : obit == ellipse
> >> Newton : F=ma; E=1/2mv^2 where m is constant
> >> Einstein : e=mc^2
> >>
> >> Each change may only subtly modify the previous axioms, but the result
> >> is theory/model that is a closer fit to reality.
> >
> >I don't think the above are axioms in the mathematical sense, though I
could
> >be wrong.
>
> Yes they are. Copernicus ASSUMED that the planets went in circles, and
> then he used logic on top or that. Therefore, "orbit == circle" is an
> axiom.
>
> Kepler realised that "orbit == ellipse", and that explained why
> Copernicus' logic was so screwy.
>
> Newton ASSUMED that m and E could neither be created nor destroyed,
> therefore they are axioms.
>
> Einstein realised that m and E were interchangeable, and that explained
> why Newton couldn't predict the orbit of Mercury.
>
> Basically, any assumption that underlies mathematical logic is an axiom.
> Copernican orbital theory is a mathematical model. Newtonian Mechanics
> is a mathematical model. Therefore the assumptions that underlie them
> must be axioms.

OK, my mistake - I thought you meant the formulae themselves were axioms. You're referring to underlying assumptions, which of course are.

> >Cascading deletes are useful for implementations, not part of the
theory - a
> >cascading delete is simply nice shorthand for an implicit multi-update
(as
> >advocated by Date in recent writings), and roughly corresponds to the
> >usefulness of the "foreign key" concept in place of a longer-winded
> >constraint definition.
>
> In other words, the theory has no way of coping with what I call "the
> adjectival clause" - a table whose contents are meaningless without the
> existence of another table to point to. An invoice line item cannot
> exist without an invoice for it to belong to!

Right, but cascading delete is different than that. Constraints encode what you just said ("A cannot exist without B"); cascades are useful shorthands for updates, designed to make sets of operations easier while obeying the constraints.

> >"Meaningful in their own right" is rhetorical - every relation has a
meaning
> >(the external predicate). To turn the question on its ear, surely a Pick
> >file which requires applications to enforce the correspondence between
> >values in several distinct attributes MUST be different from a file whose
> >attributes refer to the IDs of other files?
> >
> I don't get that. But I think you're making the logical blunder of
> expecting your logic to PREscribe the world's behaviour, rather than
> DEscribe it.

That's not what I'm trying to do, but describing the world's behavior isn't all software development is. My requirements have always included demands for information which isn't directly manifest in the real world - in other words, beyond just being able to reproduce an invoice (thus showing that my database describes invoices), my data is also the basis for

> Please explain to me how, in the real world, an invoice line item can
> have an existence in the absence of the invoice to which it belongs ...
> because as I read you you are saying that relational theory says it can

I may have expressed myself badly. What relational theory says is that statements about line items on an invoice state truths about values which are unrelated to the invoice as a whole, though each line item of course depends on the invoice (header). That statement, while "related to" the invoice header (in that it can't exist without it), has logical meaning on its own - I can formulate useful queries over line items which don't involve the header.

If cascading delete is your guide, then would deleting a customer cause all of that customer's invoices (and their line items) to be deleted as well? Danger aside, does that imply that invoices are an attribute of customers? I understand there's a difference between customer:invoice and invoice:line item relationships, but I'm trying to boil it down to something more than "they're part of the same thing". When it comes to general ledger entries, invoices, payments, shipments, contacts, etc., the line between what is and isn't part of a customers gets a little murkier. Or does it?

• Eric