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

Dawn M. Wolthuis wrote:

> mAsterdam wrote:

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

Why not provide the metadata?

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

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

Here is how you get me confused. You introduce the 'language' metaphore - ok that looks promising - and suddenly we are back to 'storing'. Now - before we step out of the metaphore, the question should not be wether some DBMS can store things or not - just wether it is possible to express what's relevant, no?

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

Yep.

> 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, the difference is in the software development process and the tooling of the developers. If the 'R' people were to prototype - including using a reporting tool to produce realistic invoices - there would be no difference in the output.

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

Because in your example, this needed information was never expressed in R to start with.

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

I like the 'language' metaphore. It goes beyond this example. In a way, every database definition constitutes a language, capable of expressing statements about truths, relevant to the business using that database.

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

The gap is there.
I think we already established that SQL is not a complete tool in this respect. It gets (and updates) data, but it does a lousy job at showing data nicely. Most RDBMS come with reporting/form tools to fill in this gap.

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

Because R can't show the data it did not get, and there is a differance in tools when comparing the tools surrounding M and those surrounding R?

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

Both ;-) Received on Mon Jun 14 2004 - 09:04:57 CEST