Re: Modeling question...

On Nov 14, 12:25 am, paul c <toledobythe..._at_oohay.ac> wrote:
> 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>).

I'm not sure what you mean when you say that pointers imply alternatives. For example, given

    age(bill,n).
    value(n,10).

we can deduce that bill is 10. Assuming N is a key in value(N,V), we know that a variable named n only holds one value at a given time (as it should, by definition of a variable).

> 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).

Yes the RA has no indirection operator. However an indirection can be expressed with a join.

> 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.

Agreed.

> 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.

I'm not sure if it's helpful to think of data models in terms of anything procedural. An "axiomatic" definition of variables and pointers in the context of data models would I think simply express the idea that 1) a namespace (or "address space") of variables is associated with a function that maps each identifier to a value, 2) a pointer type defined on that address space is associated with the domain of that function - ie the set of identifier values, and 3) given a pointer value, the dereference operator is simply the application of that function.

All the above is a rather verbose description for the simple idea that the data model makes use of a function that maps identifiers to values.

In the context of data models I see the practical application of variables as a means to express the concept of shared values and this can sometimes make it easier to express integrity constraints.

In the case of a Triangulated Irregular Network (TIN), a vertex often participates in 6 triangles. Here is one way for a TIN to be represented:

    triangle(T,V1,V2,V3,T1,T2,T3) :- Triangle T has vertices V1,V2,V3 and adjacent triangles T1,T2,T3.

    vertex(V,X,Y,Z) :- vertex V has coordinates (X,Y,Z).

[Aside: For a closed surface every triangle has three adjacent triangles. However for an open surface that is no longer the case, and one could be tempted to use NULLs (and interpret as NULL pointers!)]

A lot of the time the vertices of a TIN aren't associated with "features" like corners - for example consider any TIN approximation of a sphere. In such a case a vertex taken out of context is meaningless. I think this is what characterises an abstract identifier. Received on Fri Nov 14 2008 - 02:58:39 CET