Re: In an RDBMS, what does "Data" mean?

From: Dawn M. Wolthuis <dwolt_at_tincat-group.com>
Date: Sun, 13 Jun 2004 18:02:33 -0500
Message-ID: <caimee$rnh$1_at_news.netins.net>


"mAsterdam" <mAsterdam_at_vrijdag.org> wrote in message news:40ccc506$0$48920$e4fe514c_at_news.xs4all.nl...
> Dawn M. Wolthuis wrote:
> > mAsterdam wrote:
> >>Dawn M. Wolthuis wrote:
> >>"x" wrote:
> >>>>>So if I put my data into an MV database I can access
> >>>>>it as if it were in
> >>>>>an RDBMS. However, the converse is not true.
> >>>>
> >>>>So all data in a MV database can be represented in relational model,
> >>>>but not all data in a RDBMS can be represented in MV model :-)
> >>>>
> >>>>Which one is more expressive ? :-)
> >>>
> >>>Easy question --
> >>>
> >>>if each model can provide a solution for a particular
> >>>area so that we have
> >>>both an MV and a SQL-DBMS solution and
> >>>
> >>>if we can look at the MV model as relational
> >>>when we choose to do so (which
> >>>is usually for the purpose of using SQL against it)
> >>>but we cannot take the relational model and view
> >>>the MV model from it
> >>>
> >>>Then clearly the more expressive language is ...
> >>>NOT the one that loses the
> >>>ability to view the data in some other way, right? --dawn
> >>
> >>So now we have language R and language M.
> >
> > A business problem is brought to people who encode a solution in R and
in M.
> > They make the usual design tradeoffs based on whichever implementation
they
> > are doing. The M solution can toggle to show you an R view
> > of the solution,
>
> ... and have the R view show *all* data present in the M solution ...

No data would be lost by viewing it as relational, but metadata would be.

> Ergo language R is capable of expressing all possible M expressions.

Nope, but it can show the raw data.

> > but the R solution does not have the ability to show an alternate
> > solution, but the R solution does not have the ability to show an
alternate
> > M view of the solution.

>

> Ergo language M is not capable of expressing all possible R expressions.
> It does not matter which product does the translation.

No, it is the R model that does not store all of the (meta)information and because it does not store such information, it cannot come back to us with it.

> > Now, you could design an R solution that does
> > permit you to view it as this M solution, but you would have to have
decided
> > in advance to do that, otherwise it is likely you will make design
decisions
> > that rule out getting back to the original M solution.
> >
> >>R 'loses the ability to view the data' from within M and that
> >>would somehow mean M is *more* expressive?
> >>The only way I could make sense out of that is
> >>if the (appearant) excess expressions in R could
> >>*not* be relevant to a solution.
> >>
> >>Do you have an indication as to what those excess expressions are?
> >
> > they tend to be data that were collected and stored in the M solution
and
> > designed out (deemed unimportant to retain) for the R solution.

>

> Just to get it straight: These 'designed out' data *can*
> be represented in R (inferred from the R translation of the M solution),
> but they are *not* represented in R because of the different design
> process (ispired by the nature of M cq. R)?

Time for an example?

The nature of design using M causes the designer to identify primary entities, such as Invoice (to use one we have discussed). In the "vocabulary of Invoice" are both stored and derived attributes across what would be considered multiple base relations. The builders of the R implementation could decide to also think about such big picture concepts to match real-world objects and could create views that would correspond, sort-of, but not exactly, to the Invoice in M. However, they are not likely to do that up front and are likely to suggest that what we want in an Invoice can really only be retrieved from R by way of a reporting tool -- that SQL can only provide the row/column perspective that is not quite what we need in this case.

So, M can ignore the fact that it knows about an Invoice and can take that invoice and normalize the snot out of it and spit back the data in that fashion in an effort to look R. But R simply lacks the information it needs to give us an M picture.

> >>Which statements can you make in R but not in M - IOW
> >>of which data does R lose 'the abitlity to view the
> >>data in some other way'?
> >
> > It is not what cannot be done, but what will not be
> > done with R that is the problem.
> >
> >>x's question may be easy, your answer sure isn't.
> >
> > Sorry 'bout that. --dawn
>
> It seems to me this is a doubly edged sword.

Or simply not yet stated clearly -- keep asking questions and I'll try to get better at describing.

> The product using the M language is capable of
> showing all of its data in the R language.

I think calling it a Language might be confusing. We are talking about a complete implementation of a single application, for example, within database modeled the R way or the M way.

> The R products are not capable of showing all data
> in the M language.

>

> Factor out the products, and you get:
> Language R is capable of expressing all possible M expressions.
> Language M is not capable of expressing all possible R expressions.

No, it IS the other way around. The M implementation can be viewed as M or as an R implementation, but R is not a rich enough environment to take an arbitrary R implementation and show it as M.

> It is still interesting to see what kind of expressions
> fail to translate.

Combination of metadata and data that is designed out of the relational model, such as orderings, and attributes with cardinality > 1 that are trimmed back to 1 for the relational model.

Did that help or am I digging a deeper hole? --dawn Received on Mon Jun 14 2004 - 01:02:33 CEST

Original text of this message