Re: The IDS, the EDS and the DBMS

"Laconic2" <laconic2_at_comcast.net> wrote in message news:8aSdnXPiIYWz46bcRVn-ug_at_comcast.com...
> > As I said, we need not
> > a mapping but a unification.
>
> On second thought, this is an excellent point.
>
> I think that the OO people may reach this crossroads completely
> independently of the DBMS, when they come to
> using an app as an integrating device between two otherwise disjoint apps.

Yes, I think they will.

> But if you look at the discussion of dataphor in another thread, it seems
> to me that the whole drive behind that discussion comes from dataphor's role
> in intgreating data, not from its role in storing and retrieving data.

Yes.

> There is a paradox in this: you can hide information, and you can share
> information, but you can't do both with the same information at the same
> time.

Right. In many ways, encapsulation (a la OO) actually *prevents* declarative data management. But you still need *something* for modularization. I think the dbms crowd just doesn't think about modularity enough. Do you really need the entire schema exposed to all applications at all times? Also note that much of the criticisms of dataphor were really about modularity.

I think your last paragraph gets at something interesting, and that something is sometimes called "semistructured data." (That's a really terrible term for it, alas.)

I was one of the crowd that thought "semistructured" was bogus, until I started to hear some usage of the term that made sense. Namely, data is semistructured when the current context's view of it doesn't expose all its structure. (Which emphatically is *not* saying it doesn't have structure; it's just that not all of the structure is visible at once.) While I've not heard it put in these terms, the idea of being able to do data management and manipulation on data without having to see all of the details is a great tool for modularity.

Rough idea: views as a mechanism for modularity, by allowing one to do operations on data where not all structure is exposed. For example, one could have a view that was a projection of a base table, and delete a row from the view, which would trigger a deletion from the base table. One would thus be manipulating data without having all of its structure exposed.

This example is boringly easy, but I have yet to consider all the details. The idea of views as a tool for *modularity* specifically is not one I've heard expressed before.

Marshall Received on Mon Sep 06 2004 - 02:57:34 CEST