Re: Pizza Example

"Anthony W. Youngman" <wol_at_thewolery.demon.co.uk> wrote in message news:0IV6pcCYeDhAFwEv_at_thewolery.demon.co.uk...
> In message <2HQgc.9747$gG5.9105_at_newssvr31.news.prodigy.com>, Eric Kaun
> <ekaun_at_yahoo.com> writes
> >"Anthony W. Youngman" <wol_at_thewolery.demon.co.uk> wrote in message
> >news:ym$bCWJIqvfAFw3f_at_thewolery.demon.co.uk...
> >Good question; in this case I meant simple as advocated by Occam's Razor.
> >Fewer concepts, and more consistent notation.
>
> Occam's razor - as phrased by ?Einstein - "Things should be as simple as
> possible - but no simpler".

Agreed.

> To me, relational has simplified too far - "The car is blue and green",
> "John is Mike's dad". If I model both these situations in relational, I
> need a relation to link the colours to the car. I need a relation to
> link John and Mike. In the first situation I'm linking an entity with
> its attributes. In the second I'm linking two entities. Relational makes
> no distinction between the two types of link ...

Does it have to? Remember, we're modeling data, not "the real world" (unless you want to build a small model of a car and paint it blue and green, which is up to you). It's not a model in the same sense as you discuss elsewhere with physical models.

Unless, of course, you claim to have seen DATA in the "real world" with your own eyes. I don't mean Brent Spiner in Star Trek: The Next Generation.

And in any event, the case you cite is very simple (colors, which are in most models scalars, make the argument for 1NF less persuasive than in other cases). Other cases like children, line items, and any business data I can think of are another matter. The line between entity and relationship, while there, is fuzzy. Basing your statements of fact on normalized predicates is much less ambiguous, and this clarity of design guidance is another benefit of relational. There will always be an appeal to the business domain you're modeling, but given that, normalization rules are much better guides than anything else I've seen.

> >Define "complex." It usually depends on the "object" - oh, can you define
> >that as well?
>
> Well, I'd define a real world object as something described by a noun -
> an invoice, a car, a person ...

Attributes are nouns.

I'm not just being argumentative. I think it's a credit to relational that it (tries to) base itself on predicates, as opposed to entities, relationships, and attributes, is stronger for many reasons covered in books already mentioned...

> > "the data" is
> >what the entire disagreement is about. Is it a set of attribute values?
Is
> >it an object graph? Is it both, meaning we've decided in advance the view
of
> >"the object" everyone must have because it's "real world" (can you define
> >that?).
>
> Typically, it's a set of attribute values. And yes, I see what you mean
> - given the primary key, a relational view will return (after a lot of
> work if it's scattered across many tables) all the attributes associated
> with an entity. With Pick, it is a single "row" in a single "table".

And the decision of what "it" you're talking about is likely to be premature and limited in usefulness. The up-front simplicity of modeling based on entities is undercut by its application focus.

> Well, yes, the fact that in relational N is only ever 2 makes life
> simple.

HA! So you admit it? :-)

> But that's a "cosmological constant" which upsets purist
> physicists. If I can solve a problem for N where N is any number, it's a
> far better solution than if it only works for "N=2" :-) (and actually,
> both the values you've quoted for N I've met in practice :-)

Uh... I suspect there's another model / meta-model confusion here, but the margin of this message is too narrow to contain the marvelous proof I've concocted.

• erk