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

From: thirdrock (iktaccounts)
Date: 05/22/04 

Date: Sat, 22 May 2004 12:12:34 +1000

On Fri, 21 May 2004 23:50:42 +0200, Hugo Kornelis
<hugo@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/

Relevant Pages

  • Re: Filter Sort Annoyance
    ... I read the info that Van sent about normalizing a database. ... why you lose your filter/sort criteria. ... In a well-normalized data design, ...
    (microsoft.public.access.tablesdbdesign)
  • Re: Placing Query By Design Grid On Form
    ... Have you never heard of normalizing and normal form 1? ... If your schema is "dynamically" changing, this is an indication of a pretty ... what you still need is some kind of "Query by Form." ... design of the database first. ...
    (microsoft.public.access.formscoding)
  • Re: Logical data design, Pick style
    ... To normalize a database to what we call 1st normal form, ... NOT break 1st normal form of normalizing. ... Since MV does not require that first step, how do we design our data ...
    (comp.databases.pick)
  • Re: Normalization insanity
    ... > I'm wrestling with a new system design and am looking for opinions on where ... > to draw the line with normalizing the database. ... I'm in early design and ... code will have to maintain attributes in multiple spots. ...
    (microsoft.public.sqlserver.programming)