Re: Principle of Orthogonal Design
From: Bob Badour <bbadour_at_pei.sympatico.ca>
Date: Sun, 20 Jan 2008 19:23:01 -0400
Message-ID: <4793d7db$0$4052$9a566e8b_at_news.aliant.net>
>
>
> Well this is an interesting question, because I am yet to see any
> reason as to why it be beneficial, but can see how it makes life
> harder given that it prevents a union without a preceding rename.
>
> I find the example of phone numbers useful (a scenario also discussed
> on TTM lists a while back): for a selection of propositions
> discussing people's work, home and mobile numbers is it possible to
> state a consistent preference for a schema from:
>
> 1) Contacts = {phone_type, name, number}
> 2) Home = {name, number}
> Work = {name, number}
> Mobile = {name, number}
>
> I find it interesting that the PoOD recommends 1, the option that I
> believe most designers would intuitively go for, but that in its
> 'strong form' also suggests that 2 is perfectly satisfactory if roles
> are simply renamed as:
>
> Home = {name, home_number}
> Work = {name, work_number}
> Mobile = {name, mobile_number}
Date: Sun, 20 Jan 2008 19:23:01 -0400
Message-ID: <4793d7db$0$4052$9a566e8b_at_news.aliant.net>
JOG wrote:
> On Jan 20, 12:40 pm, Jan Hidders <hidd..._at_gmail.com> wrote:
>
>>On 19 jan, 16:55, mAsterdam <mAster..._at_vrijdag.org> wrote: >> >> >> >> >>>Jan Hidders wrote: >>> >>>>mAsterdam wrote: >>>> >>>>>Jan Hidders wrote: >>>>> >>>>>>mAsterdam wrote: >>>>>> >>>>>>>Jan Hidders wrote: >>>>> >>>>>... >>>>> >>>>>>>>Anyway, the stronger POOD that requires that headers are distinct >>>>>>>>sounds like nonsense to me. Why would R(A, B) be a worse design than >>>>>>>>R(R_A, R_B)? >>>>>>>>The weaker POOD looks more interesting to me. I even found a published >>>>>>>>paper about it: >>>>>>>>http://www.wseas.us/e-library/conferences/2006madrid/papers/512-451.pdf >>>>>>> >>>>>>>Unfortunately the link times out. >>>>>> >>>>>>Hmm, not for me. But to help you out: >>>>>>http://www.adrem.ua.ac.be/bibrem/pubs/pood.pdf >>>>> >>>>>Thank you for helping me out by providing the document. >> >>>>>I started reading "Extended Principle of Orthogonal Design" >>>>>by Erki Eessaar >> >>>below: EE >> >>>>>User defined datatypes (UDT) give the designer of a database >>>>>more decisions, more room for wrong decisions. >>>>>Row-, array-, reference-, multiset collection types >>>>>- choices, choices, choices. >>>>>How to deal with that freedom? >>>>>Enter the Principle of Orthogonal Design (POD): >>>>>If you have a tuple-type, make sure to have only one base >>>>>relvar for recording that tuple-type. >> >>>>Hmm, I would call that the strong POOD (or strong POD), and that, I >>>>would agree, seems to make no sense. >> >>>We agree on that, that is clear. >>>So ok, but - from the huge category of easily asked but >>>hard to answer questions: - why? >> >>>Why doesn't the (strong) PoOD make sense to you? >> >>It is at the same time too strong and too weak. It is too strong >>because it forbids cases where there is in fact no redundancy, and at >>the same time allows cases where there is redundancy. Moreover, you >>can always trivially satisfy it by renaming R(a,b) to R(r_a,r_b). How >>exactly does that improve the design?
>
>
> Well this is an interesting question, because I am yet to see any
> reason as to why it be beneficial, but can see how it makes life
> harder given that it prevents a union without a preceding rename.
>
> I find the example of phone numbers useful (a scenario also discussed
> on TTM lists a while back): for a selection of propositions
> discussing people's work, home and mobile numbers is it possible to
> state a consistent preference for a schema from:
>
> 1) Contacts = {phone_type, name, number}
> 2) Home = {name, number}
> Work = {name, number}
> Mobile = {name, number}
>
> I find it interesting that the PoOD recommends 1, the option that I
> believe most designers would intuitively go for, but that in its
> 'strong form' also suggests that 2 is perfectly satisfactory if roles
> are simply renamed as:
>
> Home = {name, home_number}
> Work = {name, work_number}
> Mobile = {name, mobile_number}
The RM proponents I have read are all strongly opposed to encoding meaning in attribute names, relation names etc., and were all opposed at the time folks were discussing POOD a lot.
I do not believe POOD ever suggests 2 is perfectly satisfactory.
[snip] Received on Mon Jan 21 2008 - 00:23:01 CET