Re: Modeling question...

David BL wrote:
...
> I did mean something else, but I think it needs some rewording because
> I wasn't very clear. Let there be a relation
>
> father(X,Y) :- X is the father of Y.
>
> Let there be a UoD in which bill,jane are identifiers for two
> particular humans. Then the tuple
>
> father(bill,jane)
>
> is an independently verifiable statement of fact on the UoD.
>
> Alternatively let there be relations
>
> age(X,N) :- X has age recorded by variable named N.
> value(N,V) :- Variable named N has value V
>
> where the scope of the variables in value(N,V) is regarded as local to
> the DB. Then the following tuple
>
> age(bill,n)
>
> is not independently verifiable by a domain expert (who will ask "what
> is n?" - because n is an abstract identifier).
>
> With this last example I'm curious to know whether anyone would
> disagree with the idea that it's sometimes possible to interpret an
> identifier as a name for a variable. I know when I've suggested the
> idea that relations can represent variables and pointers to variables
> I've met with plenty of opposition - the argument I presume being that
> relation (values) only record tuple values, which in turn only record
> attribute values - so it's argued there can't be variables or
> pointers.
>
> An interesting question: is there a practical example of the use of
> abstract identifiers (i.e. identifiers that fall outside the UoD)
> where they never appear as a candidate key in some relation? If so
> that would seem to defeat my argument that abstract identifiers can
> always be interpreted as names of variables defined in a scope within
> the DB.
>
>

This is probably over my head, but I'll chip in anyway. By convention, all tuples in a relation are true. Pointers require resolution because they imply alternatives. In the RM (as we know it today), the only way to express alternatives in an extension is with a predicate that involves logical OR (ala D&D's definition of <OR>). The fundamental algebra doesn't have a resolution (nor indirection) operator that allows a variable to point to another variable (I presume the same goes for the calculus given that it has been shown to logically equivalent). I'm guessing that the question around "age(bill,n)" is basically the same as trying to express a BNF grammar in relations and then using it to compile from a source program. It would be tedious, every "right-hand-side" would need a different relation and the BNF terminals would need some pretty big "look-up tables". It would be tedious to merely decide if some source text was legal for a particular language without "stepping out" of the RM algebra as we know it.

This doesn't bother me, rather to me it underlines how focussed on the db problem Codd was.

The possibly simplistic way I look at pointers is that they are instructions, not data. In a procedural program (which all programs on today's consumer cpu's are when seen at the assembly level), they have the effect of changing the path the program takes, in one breath they are data, in another they are instructions. The pointer n in age(Bill,n) could be resolved with a relation that includes "n" as a key value but the instruction to resolve must lie outside the operators (you have said you don't want that). From the point of view of the RM, it seems that instructions of this ilk are kept in the user's head. Received on Thu Nov 13 2008 - 16:25:01 CET