# Re: Principle of Orthogonal Design

Date: Sun, 13 Jan 2008 06:14:06 -0800 (PST)

Message-ID: <a9d463eb-2d44-4946-ac76-7b5d8a2a2b04_at_v4g2000hsf.googlegroups.com>

On Jan 13, 1:54 pm, "Brian Selzer" <br..._at_selzer-software.com> wrote:

> "JOG" <j..._at_cs.nott.ac.uk> wrote in message

*>
**> news:30ef4f38-4b2b-4e15-9ed1-f96ab5efd545_at_1g2000hsl.googlegroups.com...
**>
**>
**>
**> > 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.
**>
**> I think that the requirement that we inspect table names comes from the
**> correlation between RM and predicate logic. In predicate logic, there are
**> predicate symbols and there are individual symbols, and under an
**> interpretation, both the predicate symbols and the individual symbols are
**> assigned meaning. The two relations,
**>
**> sine {x, y}
**>
**> and
**>
**> cosine {x, y}.
**>
**> have the same heading, but have totally different meanings
*

operation{ input:x, output, y, type:t }

t E {sin, cos}

sin {sin_input:x, sin_output:y}

cos {cos_input:x, cos_output:y}

> --even though the

*> same individuals are exemplified in both whenever (x - pi / 4) modulus pi is
**> zero. The tuple, {pi / 4, sqrt(2) / 2}, appears in both relations yet has a
**> different meaning assigned to it from each predicate. Interestingly,
**> though, there is still only one individual represented by that tuple even
**> though it appears in both relations.
**>
**> >> 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.
*

Received on Sun Jan 13 2008 - 15:14:06 CET