Re: Lucid statement of the MV vs RM position?
Date: 4 May 2006 20:38:42 -0700
Message-ID: <1146800322.728030.23180_at_v46g2000cwv.googlegroups.com>
JOG wrote:
> 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.
>> >
> >
> > > 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
>
> 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
No, it was not. My apologies.
> and a result of the reactionary debate you have with others,
No, not that either -- I'm just moving too fast to be coherent and on point right now. I should have refrained.
> 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.
I understand. I'll ponder it more and try to clarify once I have tme to write fewer words, but the right ones. Do think about the difference between entities and properties of entities. These are not clearly-defined where everyone will make the same choices any more than every developer making the same choices about which becomes a separate class while doing OOP.
The youngest is graduating in a week and I have tons of work and a business trip between now and then, so please forgive my rapid response here when I shouldn't be taking the time to respond at all. My name is dawn and I'm a cdt addict ;-)
Cheers! --dawn Received on Fri May 05 2006 - 05:38:42 CEST