Re: Principle of Orthogonal Design

From: paul c <toledobythesea_at_oohay.ac>
Date: Mon, 21 Jan 2008 18:21:47 GMT
Message-ID: <%o5lj.1094$O07.541_at_pd7urf2no>


TroyK 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 question whether the same information can be derived from both designs. The phrase "either ... or" seems to suggest it is an essential part of a loose predicate. If that is part of the starting point for both designs, I'd think the table predicates for the second design would have the word "or" in them as well as possibly "not". Once we start making inferences, predicates that have disjunctions and negations seem often to lead us into hot water. Whereas the first design seems much more explicit (does it demonstrate the Information Principle?.

The problem of view updating, eg., 'insert through union' seems to turn on the presence of disjunctive predicates (same goes for delete through join if you accept the closed world assumption - if you don't accept the cwa, I doubt the problem exists as it's hard to imagine an algebra that can update in general without it). Maybe some of the confusion is due to the very notion of view updating which taken literally is an absurdity, it might be better to think of updating the base tables of a named expression even if that involved recursion.

Also, I wonder if the goal of eliminating redundancy isn't being confused with the desire for determinate dbms operators. I'd think that views by definition are redundant but we accept that when we find them more convenient or when we prefer to have single-relation closure (seems that most people do prefer that). Received on Mon Jan 21 2008 - 19:21:47 CET

Original text of this message