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. 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.
>
> 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. 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.
>
> > Whether one chooses to reflect that it is actually a function that
> > gets implemented in a database or opts to leave out that information
> > and treat the function logically as a relation (which it also is) by
> > removing any unique identifier or candidate keys from the
> > implementation (can you really implement this in an RDBMS without any
> > candidate keys?), another model could just as accurately reflect the
> > fact that this is a function within the model.
>
> So my complaint is that calling relations functions is a bad idea. I
> think that if you tried to translate relational formalisms into terms of
> equivalent "functions from tuples to the null set" the result would be
> more complicated, harder to understand and apply. Which is why
> mathematicians created the concept of relations to begin with, so I'm
> surprised you disagree.

I understand your point that a mapping from a bunch of "keys" to empty sets sounds like a tacky component of a model. However, NULLS in this environment can be modeled as null sets and play prominently in the model.

More importantly, I would argue that calling functions relations removes some of the specificity, making the model more abstract than is necessary. If you got back to my list of "input, output, processing, and storage" your basic components are objects and functions -- subjects and predicates -- input to a function, the processing of the function, and the output of the function, which may or may not be stored. That's the simple version for modeling a computer.

We have object languages and function languages, as well as languages that walk you through operations.

Functions are one type of object and objects are the input of and output from functions. What needs to be stored for the purpose of retrieval are objects and functions (handled as objects). From these functions & objects, one can perceive various types of functions as graphs, including trees & di-graphs. We can also apply predicate logic to the functions, which are also predicates where instances are propositions.

Introducing the mathematical concept of a relation really adds nothing to the mix that cannot be done more simply by viewing everything as an object or a function. The model I'm working with includes functions on functions that are not present in the relational operators. These include at least a) navigation by way of a link -- analogous to what is done when one navigates from a web page clicking on a link and getting to another web page (by the way, notice that web pages are all functions -- they have a URL mapping to a page) and b) unnesting and nesting of data, which TTM refers to as GROUP and UNGROUP, IIRC. I'm still working this through, so I don't claim to have all of the answers for what is the right way to do things -- I'm working on describing one way that has been in production for more than 30 years, with many systems that are 20 years old still hanging around and moving forward. This model accounts for an exceedingly quiet multi-billion dollar industry of players who have not (yet?) succumbed to the relational model. The more I learn, the more convinced I am that they are right not to move to 1NF, at the very least, and that is only one of the advantages they currently enjoy.

Thanks for helping me make sure that I'm not illogical in the details, even if my conclusions seem off the mark given the details presented to ate. --dawn Received on Tue Jan 13 2004 - 04:34:11 CET