Re: Lucid statement of the MV vs RM position?

dawn wrote:
> 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.

There are no such things as entities or properties in relational theory. (And I consider that one of its strengths. :)

> 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.

Maybe, maybe not. That depends on a lot of assumptions that you don't mention.

> 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.

This is a very misleading way of stating it. If you're talking relational theory, it's better to say "If it might have cardinality > 1, they model the relationship between characters and colours using a separate relvar". You don't necessarily need a "Colour" relvar, if that's what you mean by "a separate entity"; that decision is based on whether or not you need to know additional facts about colours, and the nature of those facts.

> 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?

This "just about as easy" again presupposes several important assumptions---the disregard for integrity constraints being one of them.

Anyway, since cost seems to be the prime deciding factor for you, I doubt any of us will benefit from further discussion. "Cost" is too dependent on a host of concrete factors that an abstract system like relational theory is just plain silent on. It's also very vague (at least until you specify exactly how you measure it), and it's hard to isolate the factors that determine it.

-- 
Jon