Re: Lucid statement of the MV vs RM position?

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

> and I did not want to get stuck on
> the digression. As such I changed my example to reflect this in an
> attempt to get back on track, so I can only hope this tangential line
> 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 Received on Thu May 04 2006 - 22:53:55 CEST