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

"mAsterdam" <mAsterdam_at_vrijdag.org> wrote in message news:40cd4e12$0$35145$e4fe514c_at_news.xs4all.nl...
> 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 -

I might have been the one to introduce that, but it doesn't seem like I would have -- I tried to work with M and R being "languages" and figured that in someone's mind they could be by putting all data, metadata, contraints, etc and putting them in this language. I don't actually like calling them languages myself, so sorry if i introduced that inadvertantly.

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

I'm using the term "store" logically, not physically -- it has to do with what predicates (metadata) and propositions (data) have been instantiated. How would you want to state that?

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

Perhaps the combination of a reporting tool, the reporting tool's metadata and specification for things like Invoice plus R would be able to give us an M view.

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

DING DING DING DING DING -- that's the problem -- there is too much left out when R is being used in order to get around the most severe constraint in the model -- 1NF as SQL understands it.

> >>>>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 can roll with that, but I don't seem to speak that way naturally. You are referring to the predicates, the constraints, the type defs including operators, and the propositions as constituting the language, right?

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

Perhaps TRDBMS's will cover this gap, but that would not be my guess. I still don't see anything that designates one view as more of an entry point for a user than another, for example. It isn't easy for a user to figure out what each row in a view stands for. As soon as we join two tables, we might end up dropping information from one if we used an inner join. Users know when they go to get Invoices that they then need to narrow it down to the invoices they want. They don't think in terms of having to toss more invoices in because this view only shows those where the customer is not deceased and the user didn't know that. The user somehow "feels" more in control when they are looking through a portal they understand and grabbing what they need from there (loosely stated objection, of course).

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

R didn't get the data because it encouraged a lesser implementation to keep pain at a minimum.

> >>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
>
> Both ;-)

Yes, I felt that while falling down into it. smiles. --dawn Received on Mon Jun 14 2004 - 23:04:35 CEST