Re: Pizza Example

"Anthony W. Youngman" <wol_at_thewolery.demon.co.uk> wrote in message news:+N$oICIHz0cAFw8o_at_thewolery.demon.co.uk...
> In message <DIidncafbowjK-_dRVn-uA_at_comcast.com>, Laconic2
> <laconic2_at_comcast.net> writes
> >> More to the point, it's structured in a manner the database can
> >> understand, which isn't the case if the information is scattered across
> >> multiple tables :-)
> >
> >This gets to the heart of the matter. If I can expand on this, I have
two
> >questions:
> >
> >First, does the relational data model scatter information across
multiple
> >relations?
>
> What do you mean? If you have a repeating attribute, the relational
> model demands that you spread data about a single object across multiple
> tables.
> >
> >Second, if so, does the database fail to understand what the relational
> >model has done?
>
> Let's assume we have several types of object. All have repeating
> attributes. And all are related, some by a many-2-many relation. Can a
> relational database group the tables according to the object they
> describe?
> >
> >And here's a third question: can a relational model be reconstructed
from
> >the database schema? If not, why not?
> >
> Why not? If you're talking about a Pick schema, then the only reason you
> can't get a relational model is if the Pick designer didn't do his job
> properly.
>
> As a Pick database designer, I would have one FILE (our equivalent of
> "table") per real-world object type. The data in this file *is*
> *normalised*. It's just that it's NFNF (non first normal form).

Good point, Anthony.
In fact, I think one of the primary issues I have with the relational model is with the statement that in order for data to be in any normal form, it must first be in first normal form. PICK developers normalize in what would be 2nd, 3rd, etc regularly without putting the data in 1NF. I would expect an "XML data modeler" to do the same.

Some relational theorists have backed off from 1NF as traditionally understood by allowing for relations as a possible type of attribute, but they still reserve use of such a type for special occasions. 1NF is one of the disfavors that the relational model has done for our profession. 2nd and 3rd, on the other hand, are wonderful clear descriptions of what good designers did even before these rules were recorded and are very helpful in teaching the discipline to the next generation.

That 1NF is just such a shame. It is not supported by the mathematics of relations nor, I suspect, would it be supported by emperical data related to implementations of various models were we able or inclined to collect such. smiles. --dawn

> So. Imagine you've defined a view, in your relational database, that
> joins all tables representing an object. You then "list" (sorry I don't
> know the relational term) one object in your view. In your
> two-dimensional view, imagine that all duplicated values just "don't
> exist". You now have the equivalent of a Pick RECORD (a bit like your
> row). We don't duplicate a simple attribute because it doesn't make
> sense to do so - why list it repeatedly when it only exists once per
> object?
>
> Cheers,
> Wol
Received on Wed Apr 07 2004 - 03:05:35 CEST