Re: Lucid statement of the MV vs RM position?

From: Jon Heggland <jon.heggland_at_idi.ntnu.no>
Date: Wed, 03 May 2006 15:41:27 +0200
Message-ID: <e3abu6$j84$1@orkan.itea.ntnu.no>

dawn wrote:
> Jon Heggland wrote:

>> dawn wrote:
>>> For example, we model data for XML
>>> documents for data exchange using multivalues even if we could do
>>> otherwise.
>>
>> You do? Why?

>
> For the same reason I use a multvalued database, perhaps.

Brillant [sic].

>> I don't see the relationship between XML, RVAs and normalisation.
>> Normalisation by definition applies to relations/relvars only.

>
> You can model an XML document with a relation, you just need
> list-valued attributes and RVAs to do so.

A *relation*? Or do you mean a tuple in a relation?
No, you don't (need LVAs/RVAs). An XMLVA might be nice, though...
So what?

>> (I must
>> confess I haven't seen the light with regard to using XML for exchange
>> of data to/from relational systems either.)

>
> But it is the relational systems that are going to change to accomodate
> and there is a reason for that.

Indeed? What changes are needed, and what is the reason?

> Yes, there are, but I don't see them written up anywhere. Ever since
> the RM busted onto the scene, business data processing types who use
> NF2 approaches seem to have gone into hiding, just going about their
> business but talking only amongst themselves so as not to ruffle the RM
> feathers (or something).

That's an... interesting hypothesis.

> I honestly don't know why I can't find much
> related the practice of data modeling in an NF2 world. That is gonna
> have to change, I would think.

Good luck with that.

>> Isn't "modelling" "data for exchange" just producing
>> reports?

>
> Output on one side, input on the other.

So? Call me old-fashioned, but if I wanted to exchange data between two relational systems, I'd choose relations as the exchange data model.

> You can think of it as
> decidedly different from database data modeling until you decide you
> want to persist and report on the exchange data.

Until I decide to introduce duplication, redundancy and query bias, and report on (the contents of) my reports? Then I may be stuck in my fossilised ways for quite some time, I fear.

>> In which case you do what is most convenient for the task at
>> hand. Which is very different from designing the database, where you (or
>> at least I) want it (i.e. the logical model) to be as orthogonal,
>> unbiased and simple as possible.

>
> In order to model as much meaning as feasible, I want my data modeled
> in a biased way (a way biased toward meaning where color and paper are
> different, see chat with JOG on this topic),

"Biased towards meaning"---as opposed to what? Meaninglessness? I'm talking about biased towards query as opposed to update, or towards certain queries at the expense of others. Twisting reasonably accepted terms like that does not help your argument.

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.

>> Why do you want to "persist" "data for
>> exchange"? (I'm not really comfortable with either of those terms.)

>
> OK, I want to store all of the transactions coming in from web
> services. Is that any better? --dawn

Like a log? I still don't see where you're going, or why you think "multivalues" are needed.

-- 
Jon

Received on Wed May 03 2006 - 08:41:27 CDT