Re: Stored fields ordered left to right

"Adrian Kubala" <adrian_at_sixfingeredman.net> wrote in message news:slrnc06823.vjp.adrian_at_sixfingeredman.net...
> Dawn M. Wolthuis <dwolt_at_tincat-group.com> schrieb:
> > You can see the function outright in the above design. Or the designer
> > could add it without such a key, by making the entire tuple a
> > "candidate key" by implementing it as
> >
> > ID:<1,1>
> > ID:<1,2>
> > ID:<2,1>
> >
> > In this design, the function maps each of these IDs to the null set.
>
> In that case, I will grant you that this approach is equally expressive,
> but I think that calling this a "function" is an abuse of the term.

Au contraire; it fits the definition of function perfectly: a mapping from a set of values to another set of values. In this case, the second set of values happens to be the empty set.

> The
> range of this function, and therefore the function itself, in it's
> function-ness, is logically meaningless -- you're actually using the
> domain as a way to encode a list of tuples, a relation, in an obscure
> way.

But Dawn didn't pick the example; you did. If the example is wonky, why not pick a real example, and Dawn can show you how that, too, is a function, provided you limit yourself to a single key?

Nothing in the definition of function prevents the range of a function from being the empty set. (Nothing prevents the domain from being the empty set, either. Neat, eh? Nullology is the most fun part of relational theory.)

> A modelling tool should deliver a straightforward mapping between the
> parts of the model and the parts of the system we're modeling. With
> relations it is easy to make such a mapping by treating relations as
> logical predicates: "so-and-so LIVES AT such-and-such-a-place". I don't
> see how such a mapping would work in general for functions.

It's the *exact* *same* *mapping.* The only difference is that you are limited to a single key.

> In our above
> example, you can see that the null range of the function corresponds to
> nothing in our actual system, it is just there to satisfy the formalism.
> That's a bad sign.

Again, you picked the example. You happened to pick an example in which every attribute was included in the key. Is this a "bad sign?" No; that's a totally fine situation to have. Consider: your example could be a many-to-many table for some other table, and each of the two columns could be foreign keys. The key would be a composite key over the two columns. Bad sign? Not at all. It's actually not even that uncommon.

Marshall Received on Tue Jan 13 2004 - 06:30:07 CET