Re: Entity vs. Table

From: Alan <alan_at_erols.com>
Date: Mon, 14 Jun 2004 13:14:56 -0400
Message-ID: <2j64o9Fuen2nU1_at_uni-berlin.de>


"ben brugman" <ben_at_niethier.nl> wrote in message news:40cdcac8$0$4925$4d4ebb8e_at_read.news.nl.uu.net...
>
>
> >
> > I've been nice up till now, but I'm sorry- you clearly do not know what
> you
> > are talking about. 3NF has nothing to do with RAID, error checking bits,
> or
> > anything else that is not data. Indexes are not redundant information.
> They
> > are references. Indexes are analagous to looking in the index of a book.
> You
> > look there to get a specific place to look in the book. If indexes were
> > redundant, they would serve no purpose. Indexes are part of the physical
> > implelmetation, and have zero to do with the logical model, which is
where
> > you establish 3NF.
> >
>
> I've been nice up till now and shall stay nice.
> 3NF has nothing to do with RAID, error checking bits or ..... (Yes I think
> so).
> All my implementations of databases have redundancy in the
> implementation (we use raids error checking and indexes in the
> implementation).
> They are still implementations of logical models (which are 3NF).
> But the implementation is not 3NF.
> (The implemented 3NF design (your term) might be)
> (The fysical model (as you use it) might be)
> (My model of the implementation does have redundancy. I do not know how
you
> would
> call this model).

Okay, now we can clear this up. Your _implementation_ has redundancy at the physical level. You could even argue that it is one step beyond that, and say it is in the hardware level (if you choose to further decompose the model and add a hardware level.) But, this has nothing to do with 3NF, as 3NF refers strictly to relationships among the data. RAID has to do with how the data is physically arranged on disks and has nothing at all to do with the logical model.

>
> ben
>
>
Received on Mon Jun 14 2004 - 19:14:56 CEST

Original text of this message