Re: Pizza Example
Date: Tue, 20 Apr 2004 13:45:43 GMT
Message-ID: <bQ9hc.10110$R66.4848_at_newssvr31.news.prodigy.com>
"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
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.
> 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 :-)
- erk