Re: In an RDBMS, what does "Data" mean?
Date: Mon, 14 Jun 2004 09:04:57 +0200
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 ...
> No data would be lost by viewing it as relational,
> but metadata would be.
Why not provide the metadata?
>>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.
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)?
> 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, 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.
>>>>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.
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.
> 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 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.
> 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.
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?
> 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
Both ;-) Received on Mon Jun 14 2004 - 09:04:57 CEST