Re: Principle of Orthogonal Design

From: Jan Hidders <hidders_at_gmail.com>
Date: Sun, 3 Feb 2008 05:02:39 -0800 (PST)
Message-ID: <de0ae583-6afa-47f3-af93-81e3e2e0aea5_at_n20g2000hsh.googlegroups.com>


On 2 feb, 13:50, mAsterdam <mAster..._at_vrijdag.org> wrote:
> Jan Hidders wrote:
> > mAsterdam wrote:
> >> Jan Hidders wrote:
> >>> mAsterdam wrote something very much like:
> >>>> Pragmatical redefinitions must be temporary and tracked.
> >>> Sure, we agree on that.
> >> <unsnip>
>
> >> Wether the relation between heading and tuples goes
> >> via names or ordering is relevant or not.
>
> >> If it is not I want it out of scope.
>
> >> </unsnip>
>
> > I don't think that it is possible to get it out of scope. If you think
> > it is, then by all means provide an equivalent and complete definition
> > where it is. I'm also not sure what your problem exactly is.
>
> My problem here is that I can't grasp all the consequences of
> making attributes and types indiscriminate.
> D&M draft: "...type-compatibility as we define it
> requires the two tables to have identical column names."
> The BOM, MOD, WIRES example you snipped without comment
> may illustrate why I have this problem. Please read until the end of
> this post before replying to this (it may not be necessary, and no, I
> did not mind the snip at all, I am just referring to the example).

Ok. In that case I'm going to aggressively snip again and concentrate on replying to that point.

[... SNIP ...]
> Aside:
>         Shame on me that I don't have the Alice book.
>
>         I think 'named perspective' was just an unfamiliar
>         label to a familiar concept.

Yes. The named perspective is the usual perspective where tuples are defined as functions from attribute names to domain values, and the unnamed perspective is where they are defined as sequences. The latter is sometimes preferred in theoretical work because it is closer to how logicians formalize things (in P(x,y,z) there are no attribute names, just the 1st, 2nd and 3rd place in the predicate) and it simplifies notation sometimes.

>         Googling for '"named pespective" database' gave me
>         "Relational Scaling and Databases" by Joachim Hereth,http://wwwbib.mathematik.tu-darmstadt.de/Math-Net/Preprints/Listen/fi...
>         . He talks about 'Conceptual Information Systems'.
>         He does pay some lipservice to updates and
>         normalization, but his intrests are in analyzing and
>         presenting; datawarehouses (fancy report generators using
>         technology and data from databases), not databases.
>
>         He quotes S. Abiteboul ea. in saying that "the differences
>         (between named and unnamed perspective, mA) are mainly
>         syntactical, while the expressivity is the same."
>         (Foundations of databases 1995).
>
> Joachim Hereth also uses examples where there is no
> distinction between attribute and type.

That's one way of describing it. You might also say that he makes the usual simplification where there is only one type / domain. Technically there's not much difference between those two points of view.

> >>>> DEFINITION: Two relations R and S are said to have dependency-induced
> >>>> overlap if there is a dependency that requires that sometimes some
> >>>> tuples(1) of R are also in S.
> >>>> (1) for some definition of tuples that allows restricted
> >>>> reshuffling of its values. To do.
> >>> The only way to achieve (1) so that it also takes all normal inclusion
> >>> dependencies into account is to define tuples as something equivalent
> >>> to bags of values.
> >> Nice, a third alternative way to state the same relation.
> >> How can this be relevant?
>
> > It shows to what unacceptable consequences your demand is leading.
> > It destroys the relational model as we know it.
>
> My demand to get irrelevant stuff out of scope?

Yes, or to be more precise, the way in which you proposed to do it. You might for example also do the following:

DEFINITION: Two relations R and S are said to have dependency-induced overlap if there is a qualified full inclusion dependency from R to S.

where "qualified" means it only pertains to a selection of the tuples and "full" that it is an inclusion dependency that goes from the full header of R to the full header of S. Note that inclusion dependencies allow renaming, so all we have done now is delegate the relabeling to sub-definitions, but in some sense it's out of scope in this definition.

> >> Do you have a suggestion for
> >> s/type/$some_name_dependent_notion_similar_to_but_not_the_same_as_type/
> >> in PoOD related discussions ?
>
> > Yes, don't. :-) IMNSHO that part of the POOD discussion clearly
> > doesn't make sense and at best leads only to a crippled version of the
> > relational model.
>
> Ah... (<=== sigh of relief), now that is a lot
> stronger than my reservation.
>
> > But if you insist and want a name for that kind of thing
>
> I don't. I prefer to completely throw
> "...type-compatibility as we define it
> requires the two tables to have identical column names."
> out - which is what you seem to be doing. Are you?

That depends on what you exactly mean by that. For type-compatibility as a prerequisite for meaning overlap I am, yes. For typecompatibility  as a prerequisite for taking the union of two relations I am not.

  • Jan Hidders
Received on Sun Feb 03 2008 - 14:02:39 CET

Original text of this message