Re: Lucid statement of the MV vs RM position?

Jon Heggland wrote:
> dawn wrote:
> > Jon Heggland wrote:
> >> Other writers claim they *do* know of such applications, however, and
> >> have proposed (semi-)formal guidelines for identifying cases where RVAs
> >> may be appropriate.
> >
> > Yes, but what about the use of RVAs even when the application could be
> > implemented with simple domains?
>
> "Simple" meaning "not relation-valued"?

Yes.

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

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

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

> > Are there best practices for that?
>
> You tell me.

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

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

Output on one side, input on the other. 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.

> 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), and what I think is simple is not backed by the simplest mathematical model.

> > Would any of those best
> > practices be applicable to modeling persisted data as well? If data
> > for exchange is persisted (perhaps in a database such as IBM Viper when
> > that comes out), it would make sense that the best practices for
> > modeling data for exchange and persistence would overlap, right?
>
> I don't know, but I'm skeptical. 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 Received on Wed May 03 2006 - 10:32:22 CEST