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
> >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.

The argument hinges on the word "about". MV and OO folks would claim that any reference to X is "about" X and therefore should be collected together with everything else "about" X. Relational folks realize that's silly, since these represent different assertions, "about" X ALONG WITH OTHER THINGS.

> >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?

The question is too vague to address - why won't foreign keys suffice in this?

> >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).

Then it's not normalized. Please, at least use a different term rather than co-opting one already defined. Wait - you used an S in normaliSed. My mistake. :-)

> 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".

What duplicated values? Presumably the "list" (a report) would include a comma-separated representation of the multiple values or some such.

> 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

In what sense does the relational model duplicate an attribute?

> why list it repeatedly when it only exists once per object?

There are multiple values which may be associated with X, but in what sense is it "listed repeatedly"? Again, I don't see the "duplication."

• erk