Re: Principle of Orthogonal Design

On Jan 10, 5:32 am, DM Unseen <dm.uns..._at_gmail.com> wrote:
> On 10 jan, 03:23, JOG <j..._at_cs.nott.ac.uk> wrote:
>
>
>
>
>
> > On Jan 9, 9:01 pm, TroyK <cs_tr..._at_juno.com> wrote:
>
> > > On Jan 8, 6:51 pm, JOG <j..._at_cs.nott.ac.uk> wrote:
>
> > > > I was wondering what your current stances towards the principle of
> > > > current design is cdt - info about the POOD is actually pretty sparse
> > > > on google, which has not helped my own understanding. I gather that
> > > > Date has realigned his opinion - although what to I know not - and
> > > > that Darwen rejected the original POOD paper outright given that
> > > > McGovern posits that:
>
> > > > R1 { X INTEGER, Y INTEGER }
> > > > R2 { A INTEGER, B INTEGER }
>
> > > > violates the principle, whatever the relations' attribute names.
> > > > Instinctively it does seem rather odd that a predicates such as:
>
> > > > * on Day:X the shop had noCustomers:Y
> > > > * on Roll:A, the dice showed the Number:B
>
> > > > cannot share the same database. Have I interpreted the debate
> > > > correctly? Any insights or corrections are, as ever, appreciated -
> > > > POOD is certainly thought provoking, and the concept that an update
> > > > need not require specifcation of a table name is an interesting one.
>
> > > I thought I'd work up an example that illustrates part of McGovern's
> > > argument (as I understand it). Comments and corrections are most
> > > welcome:
>
> > > Assuming we want to represent employees and their status as either
> > > salaried, commissioned, or both, we might come up with the following
> > > design (assuming the most obvious interpretations):
>
> > > Table: Emp
> > > Emp#  IsSalaried  IsCommissioned
> > > ====  ----------  --------------
> > > 1     Y           N
> > > 2     N           Y
> > > 3     Y           Y
>
> > > Another possible design could be:
> > > Table: Emp
> > > Emp#
> > > ====
> > > 1
> > > 2
> > > 3
>
> > > Table: SalariedEmp (FK, Emp# references Emp.Emp#)
> > > Emp#
> > > ====
> > > 1
> > > 3
>
> > > Table: CommissionedEmp (FK, Emp# references Emp.Emp#)
> > > Emp#
> > > ====
> > > 2
> > > 3
>
> > > Although we can derive the same information from each design, the
> > > former is to be prefered because the latter violates POOD (two tables
> > > with identical headers, even semantically speaking). Additionally, it
> > > requires that we inspect the tables' names in order to gather the full
> > > meaning of the propositions.
>
> > > TroyK
>
> > I like this example Troy - It is both concise and clear. I was just
> > mulling and came up with a possible schema for a "kennel club", that
> > might help clarify some of the issues I'm seeing.
>
> > owners = {name, age, joined} PK(name)
> > dogs = {name, age, joined}  PK(name)
> > ownership = {owner, dog}  FK(owner, owners.name) FK(dog, dogs.name)
>
> > As it stand this is clearly not in POOD, and a proposition such as
> > <Bess, 18, 01/08/08> is ambiguous. So it got me thinking about how we
> > know in real life what a proposition refers to.
>
> > 1) I know the context implicitly of <Bess, 18, 01/08/08> (from
> > previous conversation, who i'm talking to, etc)
> > 2) Surrounding text: <Bess, 18, 01/08/08> = "The dog called Bess is 18
> > years old and joined the kennel club on 01/08/08"
>
> > I don't think we can deign to rely on a computer ever being able to
> > cope with implict context (leave that to the CYC people to bang there
> > heads against ad infintum), so that appears to leave me with option 2.
> > In turn, I see two ways of integrating this explicit surrounding
> > context.
>
> > 1) Via role names so, the proposition becomes:
> > There is a dog with (dogsName:Bess) of (age:18) and who (joined:
> > 01/08/08)
>
> > 2) Via another attribute:
> > There (is_a:dog) with (name:Bess) of (age:18) and who (joined:
> > 01/08/08)
>
> > Which is preferable, and why that would be so I am uncertain. It would
> > be easy to say "this is all just a design decision", but I'm starting
> > to think there might be some sort of salient lesson in there.
> > Somewhere. Maybe.- Tekst uit oorspronkelijk bericht niet weergeven -
>
> > - Tekst uit oorspronkelijk bericht weergeven -
>
> Could be something like
>
> joiners= {name, age, joined, type} PK(name,type)
> where type in {'Owner','Dog'}
>
> ownership = {owner, dog}  FK(owner, joiners.name AND
> joiners.type='Owner') FK(dog, joiners.name AND joiners.type='Dog')
>
> This could still be generalised further bit I think this would be in
> POOD.
>
> And yes POOD implies "semantical" types and not syntactical.
> This could also imply that we are dropping too much information in the
> conversion from semantical (conceptual) models like NIAM/ORM to
> logical models like the relational models.
>
> DM Unseen- Hide quoted text -
>
> - Show quoted text -

You make a good point about the possible lossy conversion from conceptual to logical (inasmuch as "encoding" information in the relations' names implies this loss).

I'm wondering if we should consider this type of POOD violation a nonissue,  though. In SQL, we always need to specify which table we're talking about (both for updates and data retrieval), so that forces one to be specific about the propositions they're interested in. Even in a more pure RM implementation, we would need to reference which relvar in particular we're updating (or deriving from).

In practice, I use POOD more to inform my design decisions around constraint-based table/view partitioning.

TroyK Received on Thu Jan 10 2008 - 21:13:30 CET