Re: Lucid statement of the MV vs RM position?
Date: 4 May 2006 18:51:05 -0700
Message-ID: <1146793865.848237.259180_at_v46g2000cwv.googlegroups.com>
dawn wrote:
> JOG wrote:
> > Jon Heggland wrote:
> > > JOG wrote:
> > > > Jon Heggland wrote:
> > > >> FWIW, I don't endorse the entity-attribute thinking you (and JOG)
> > > >> indulge in. It confuses the issue, and does not contribute anything. For
> > > >> example, I consider treating colour and paper differently a flaw, not an
> > > >> advantage.
> > > >
> > > > Exactly Jon - there is no difference between them and treating them so
> > > > is flawed . Dawn has assumed a colour is a 'weak entity', but there is
> > > > no justification for this assumption from the propositions that were
> > > > inititally supplied.
> > >
> > > Actually, as far as I can tell it was you that introduced the term "weak
> > > entity" in this context, and it is incorrect. Neither colour nor shoe
> > > size is a weak entity, unless my shoe size (44) is something different
> > > from my brother's shoe size (also 44); ditto for colours. Likewise, the
> > > shoe size 44 does not cease to exist just because the tuple describing
> > > its relationship to me is deleted. That discussion shows signs of less
> > > than clear thinking on more than one part.
> > > --
> > > Jon
> >
> > You are right of course.
> >
> > However Dawn originally stated that a Character was a "strong entity"
> > while a Colour was not.
>
> I was making a distinction between classifying something as an entity
> and a property of an entity. I understand that this is seen as an
> arbitrary distinction. There is a cost to making such distinctions and
> a cost to not making them. How risky would it be to model color as a
> property of Character in the problem domain you have in mind? I
> suspect it is more costly for the long haul to model it as an entity.
> Entities cost more than properties of entities. You are trying to
> avoid the big cost of switching from a property to an entity, however,
> but there should be a risk assessment before assuming the additional
> cost, IMO.
>
> > While I did not agree, this was broadly
> > irrelevant to the point I was making
>
> but very relevant to mine
I see, and that prevails does it.
>> > attempt to get back on track, so I can only hope this tangential line
> > and I did not want to get stuck on
> > the digression. As such I changed my example to reflect this in an
> > ends swiftly.
>
> If I understand the antecedent, then this is not a tangent, this is at
> the heart of my beef with the RM and the democracy of data, the
> unbiased design for whatever queries might come down the pike when
> there are real requirements here and now that could be implemented at a
> fraction of the cost if we didn't decide to model all of reality at
> once. When new requirements come, make the changes for the new
> requirements. This would be a good agile development approach,
> provided we are assessing risk as we go.
>
> > I should have used symbols in my example, that had no semantic loading.
> > You live and learn.
>
> I care a lot about the semantics/meaning of the propositions being
> modeled. We make decisions all the time about whether something is an
> entity or an attribute and that is a good thing. Not all attributes
> are properties of the entity. It might make a lot of sense for one
> inventory system to have "quantity" as an attribute, where obviously it
> is not a property of a Product while another system should have one
> quantity be aggregated from the individual units, each with a unique
> identifier.
>
> Deciding to be impartial about your nouns is not the way anyone
> approaches it. We make decisions about what should be properties.
> Most developers/modelers use "cardinality" as one of the factors in
> making this decision. If each character has only one color, they might
> model it as a property. Why? Because a property of an entity is less
> expensive than an entity. If it might have cardinality > 1, they model
> color as a separate entity. Why? Because SQL and what was formerly
> known as 1NF suggest that is right or make it easier for them to do so
> with the given tools. If you use tools that make it just about as easy
> to make an attribute multi-valued as single-valued, then you can keep
> modeling it as a property. Why bear the cost of an additional entity?
> If you want to have the unbiased reporting aspect of the data, then you
> can make a logical view that gives you that at any point you want --
> either up front so you don't have to do it later, or with JIT schema.
>
> If I'm not making sense, nevermind. smiles. --dawn
This post makes me very sad dawn. I had hoped you were aware that I initiated this line of conversation because I was gradually trying to get to a point, and you have successfully drowned it in your own agenda knowing I had not got there yet. I am sure this is not intentional on your part and a result of the reactionary debate you have with others, but with limited time to post, I am unfortunately at the point of giving up trying to separate the wood from the trees on it. all best, J. Received on Fri May 05 2006 - 03:51:05 CEST