Re: Principle of Orthogonal Design

Jan Hidders schreef:
> mAsterdam wrote:

>> Jan Hidders wrote:
>>> ..., you can always trivially satisfy
>>> it by renaming R(a,b) to R(r_a,r_b).
>>> How exactly does that improve the design?
>> Not. But just renaming the attributes does not change the
>> tuple-type (which I earlier referred to as signature of
>> the relation), so, while it indeed does not improve the
>> design, it also has no bearing on satisfying PoOD as
>> I understand it from EE.

Yes, depending on 'it matters', because , as you said, compliance by renaming becomes trivial.

>> I could not find your definition, BTW.

>>>>> What they probably should have said is: R and S are said to have
>>>>> overlapping meaning if it does not follow from the constraints /
>>>>> dependencies that the intersection of R and S is always empty.

Thank you.

> For the record. I think this definition is better than Erki Eesaar's,
> but as I will argue later on I also think that it is still too crude
> and that there is a better definition possible.
>

>> It is clear from JOG's OP that renaming the attribute doesn't
>> PoOdify the design - which made Darwen reject it.
>>
>>  From JOG's OP:
>>
>> OP> Darwen rejected the original POOD paper outright given that
>> OP> McGovern posits that:
>> OP>
>> OP> R1 { X INTEGER, Y INTEGER }
>> OP> R2 { A INTEGER, B INTEGER }
>> OP>
>> OP> violates the principle, whatever the relations' attribute names.

>>>>> What they probably should have said is: R and S are said to have
>>>>> overlapping meaning if it does not follow from the constraints /
>>>>> dependencies that the intersection of R and S is always empty.
>>>> Maybe, but it would not take away my objection.
>>>> As long as R\S and S\R are allowed to be non-empty,
>>>> R and S are independent, regardless of their heading.
>>> In that case you still might have redundancy.
>> Redundancy in what sense?

The constraint only applies to a subset of R I.o.w. R is a mix of constrained and unconstrained data. We are talking a /design/ principle here, so my question would be: how did these different sets end up disguised as one in the first place?

But indeed, redundancy.

> In general a qualified inclusion dependency is of the form "if Q1 then
> Q2" where Q1 is a conjunction of atoms and simple equations, Q2 is a
> single atom, and there is at least one atom in Q1 with the same free
> variables as Q2. Such an inclusion dependency is said to hold between
> R and S if at least one atom in Q1 that has the same free variables as
> Q2 concerns R and the atom in Q2 concerns S.

> Our new definition of "overlapping meaning" might then be as follows:
> R and S are said to have overlapping meaning if there is a qualified
> dependency between R and S or between S and R that does not follow
> from the dependencies at relation level.

An inclusion dependency on a proper subset would be a tell, right?

> As you can see it also deals with the case where R and S have
> differently named attributes, and at the same time arguably does not
> see overlapping meaning where there actually is none, so it is more
> refined then my preceding definition. Darwen and McGovern could
> perhaps both be happy with this. :-)
>
> What would really establish its correctness is a theorem that says
> that it characterizes exactly if there is a certain type of redundancy
> (defined for example a la Libkin) at schema level or not. Much like we
> also know is the case for 5NF. I think that's possible, although we
> should probably take all full, single-head dependencies into account
> for that and redefine the normal form accordingly, but unfortunately I
> don't have time right now.
>

>>> If you decompose in to the following three,
>>> R' = R/S,
>>> RS' = R intersect S,
>> RS' =  R ⋂ S     (long live Unicode!)

Last time I checked, with レ (re) and ル (ru), there were no complaints.

ID: R(a) レ S(b) japanese re, for 'references'

                   (mnemonic: check)
FK: R(a) ル S(b)  japanese ru, for 'references unique'
                   (mnemonic: check one)

>>> S'  = S/R,
>>> then you have removed that redundancy.
>> I can see that it is a lossless decomposition.
>> What I don't see is which update anomaly is prevented by it.
>> If I apply it to less abstract relations (say Brians example),
>> I find myself having much more difficulty to come up with
>> sensible predicates for R' , S' and especially for RS'.
>> This makes me suspicious.

I tried to pick nit, but I could not find objections. Received on Mon Jan 21 2008 - 23:10:11 CET