Re: Pizza Example

"Anthony W. Youngman" <wol_at_thewolery.demon.co.uk> wrote in message news:Y7ZBlTBoBwhAFwS2_at_thewolery.demon.co.uk...
> In message <bQ9hc.10110$R66.4848_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: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.

>

Yes, the data represents things about the "real world" (which is often an abstraction, one that's agreed upon in the course of requirements/systems analysis). But a data model models data, not the real world. A "business model" models a business, using a "data model". The wording is bad (and not agreed-upon), but the short version is: just because the "real world" appears to look like X doesn't mean that the underlying data model has to "look like" X. Nothing "looks like" a relation, but it's useful - toss aside 1NF if you like. Meanwhile, I contend that even for those things that are "real world" hierarchies, that XML's data model isn't necessarily a good one for modeling it.

> >Attributes are nouns.

>

So you'd phrase a family example as "John is the father of 3 children" rather than "John has 3 children"? Sticking to language momentarily, is the "is" verb the signifier of an attribute?

> >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.
>
> In practice, it actually seems to work extremely well...

Could be. I don't think the attribute-to-table-with-foreign-key work is that hard either, and for "attributes" where that happens, if there's no corresponding change in business logic (e.g. it's display only), perhaps relational vs. MV doesn't matter.

But then again, let's stick to theory. :-)

• erk