Re: Principle of Orthogonal Design
Date: Sun, 13 Jan 2008 22:35:33 -0800
Message-ID: <13om0lmp558vq97_at_corp.supernews.com>
JOG wrote:
> On Jan 13, 1:54 pm, "Brian Selzer" wrote:
>[...]
>> 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
>
> Interesting example. So sine and cosine as stated would break POOD
> (which appears intended to assist with view updates). To avoid
> breaking the POOD, we'd have either:
>
> operation{ input:x, output, y, type:t }
> t E {sin, cos}
>
> or,
>
> sin {sin_input:x, sin_output:y}
> cos {cos_input:x, cos_output:y}
In its strongest form, POOD discounts names of attributes as well as names of relations - so the 'or' option would not pass muster. The first option mostly passes POOD - but not the real world test.
The general intention is that presented with a tuple, using just the types, the DBMS should be able to determine which table the row should be inserted in.
The sine and cosine tables are fairly compelling examples.
Another that I find compelling as a counter-example (illustrating that POOD is not the be-all and end-all of DB design) is a Bill of Materials. It is kinda important to know which value is the 'part that is built' and which is the 'part that is used to build'. And both, by definition, have to be from the same domain of part numbers.
[Aside: I think there's a typo in the 'operation' example; the comma separating output and y should probably be a colon. And then I'm not clear but it seems that the x and y in the examples are types, whereas in the original mention of sine and cosine, they were attribute names of a common type.]
> Well, my instinct tells me that the latter is kludgy given x plays
> exactly the same role in both predicates, and as such one would expect
> them to have exactly the same name (and who knows, that might be
> useful information). But then the former would generate enormous
> tables given it would have to incorporate every conceivable operation
> with an input and an output of the same type as used by sin and cos.
> Practically that appears to be undesirable. Theoretically I guess
> there is nothing wrong with it.
As an occasionally useful twist on DB design, I consider POOD worth having at the back of my mind. However, I don't think it is practically of much significance -- even if the DBMS were able to tell where to insert data when presented with a tuple. In my opinion, ignoring attribute names is not healthy.
-- Jonathan Leffler #include <disclaimer.h> Email: jleffler_at_earthlink.net, jleffler_at_us.ibm.com Guardian of DBD::Informix v2007.0914 -- http://dbi.perl.org/ publictimestamp.org/ptb/PTB-2270 haval 2008-01-14 06:00:04 A3E3F8DD3E3BD5472410A4CC430A01CEReceived on Mon Jan 14 2008 - 07:35:33 CET