Re: Nearest Common Ancestor Report (XDb1's $1000 Challenge)

On Fri, 21 May 2004 23:50:42 +0200, Hugo Kornelis <hugo_at_pe_NO_rFact.in_SPAM_fo> wrote:

>
> I meant to write: "It's about storing relationships", but somehow I
> forgot
> to type the hips. Apologies for causing confusion.

No problemo!
>
>
>>> There would have been redundancy if each object's class was stored
>>> along
>>> with it's reference, like this:
>>>
>>> thing class otherThing otherClass hierarchy
>>> --------- --------- ---------- ---------- ---------
>>> (snip some rows)
>>> 'fido' 'dog' 'john' 'person' 'leader'
>>> 'fido' 'dog' 'mary' 'person' 'leader'
>>> 'fido' 'dog' 'luke' 'person' 'leader'
>>
>> The above table does not meet the 1N rule, correct?
>
> When you write "the 1N rule", do you mean "1NF" (first normal form), or
> are you refering to something else?

I've seen it written both ways in the texts, but I am aware of the importance of having a common set of terms, otherwise we end up like the queen of hearts in Through the Looking Glass.

>
> AFAIS, this table does not violate 1NF (no repeating groups). It does
> violate 2NF (class and otherClass are not fully dependent on the primary
> key).

Yes, you are correct.
>
>
>>> This example of a bad design has redundant storage of the same
>>> relation.
>>
>> Er.. actually it's an example of non-normalised data. I don't think
>> design
>> has anything to do with it.
>
> Huh? Normalizing *IS* one of the steps you take when you design the
> schema
> of a relational database. And the aim of normalizing is to remove
> redundant relationships (not relations) from the design.

True. However, sometimes your design will include data that is not normalised for reasons of avoiding unneccessary overhead or to produce certain types of behaviour (which I won't go into in this post). Therefore, non-normalised data *can* be poor design, but it not neccessarily so. It really depends on the context. My point is (and I do have one) that the generalisation that non-normalised data is bad design is not always true, and in fact is probably the wrong way around. Good relational design will, as a general rule, produce normalised data, but the inverse is probably not generally true.

>
>
>>> You seem to be thinking that storing the character strings 'fido' and
>>> 'leader' several times is bad.
>>
>> Bad, or just not normalised?
>
> If I understand Neo correctly, he thinks it is not fully normalised, AND
> he thinks that anything that is not fully normalised is bad.

Which you don't, I assume, so we are in agreement.

> Hmmm, you're right. I did indeed forget to add "on update cascade" and
> "on
> delete cascade" to the "references" clauses in my original message (the
> first one I posted in this discussion, four days ago).

Better add that to collect the 1000 bucks :)

>
>
>>> I don't know what definition of "redundant" you've been taught. I think
>>> that "Exceeding what is necessary or natural; superfluous." (*) does
>>> quite
>>> accurately describe the schema with both thingID and thingName, not my
>>> original schema!
>>
>> Well, writing a trigger to cascade out fido's name change to 'fifi' is
>> redundant if your model was such that it was un-neccessary.
>
> Why write a trigger if you can use DRI?

Exactly! Therefore my statement about it being redundant holds true, yes?

>
> Best, Hugo

Have fun,

Ian

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/