Re: Principle of Orthogonal Design

On 3 feb, 23:43, mAsterdam <mAster..._at_vrijdag.org> wrote:
> Jan Hidders schreef:
>
> > mAsterdam wrote:
> >> Jan Hidders wrote:
> >>> mAsterdam wrote:
> >>>> Jan Hidders wrote:
> >>>>> mAsterdam wrote something very much like:
> >>>>>> Pragmatical redefinitions must be temporary and tracked.
> [snip]
> >> D&M draft: "...type-compatibility as we define it
> >> requires the two tables to have identical column names."
> ...
> >> 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.
>
> 'usual' depends on what you are used to.
> "In theory the difference between practice and theory is
> due to practical considerations that theorists find it
> impractical to fit into their theories."
> (http://www.kettering.edu/~jhuggins/humor/theory.html)
> With this piece of folklore from the village of theory
> practitioners in effect we exclude 'type' from the topic,
> and in the end - if something useful comes up we check
> what (if anything) is needed for generalization.
> I have seen it before somewhere, but during this thread
> I was not aware of it until this post.
>
> Your mentioning this simplification puts (for me - not for
> someone who indeed considers this step usual) a light on the
> original PoOD. A little rephrasing here and there makes me
> understand the whole discussion much better. It looks valid,
> and with it, I think I can overcome the problems induced by
> my not being able to "grasp all the consequences of making
> attributes and types indiscriminate". E.g. if there is only
> one attribute-type, it is immediately clear that the
> number of attributes determines the tuple-type; at
> some point I did put a question mark when you
> made a remark to that effect.
>
> Thank you.

You're very welcome.

> >>>> 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.
>
> So far, so good.

Ok.

> > For type-compatibility as a prerequisite for taking
> > the union of two relations I am not.
>
> Just when I thought I was starting to understand ..

How can we take the union of a relation with header {A,B} and a relation with header {C,D}? (Since we're assuming only one type, I'm omitting the types from the header.) What would be the header of the result?

Of course, if you generalize the notion of "taking the union" such that you also allow the renaming of attributes, then an equal number of attributes in the header would indeed be a necessary and sufficient condition for being able to take the union. On the other hand, the result would then not be uniquely defined unless you specify the renaming you want to apply.

• Jan Hidders