Re: The IDS, the EDS and the DBMS

"Marshall Spight" <mspight_at_dnai.com> wrote in message news:2CO_c.112104$9d6.6707_at_attbi_s54... Marshall,

I need to preface these remarks with a general comment about your previous posts. There are literally dozens of times that I have not responded in a thread where you have posted a response before me. My reaction on reading what you wrote was that you said roughly what I was going to say, only you said it better.

So my view of you is that you generally have at least as much insight as I do. If I'm sometimes sharply critical of what follows, it's NOT a comment on what I think of your level of understanding.

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

Agreed. (Well, I'm not critical of everything).

I might prefer "semi encapsulated data structure". But that's a lot of syllables. And it combines "encapsulated", which belongs to the OO crowd with "data structure" which belongs to the database crowd. Synthesis, again.

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

It seems to be that the whole idea behind the DBMS, from the 1950s to the 1990s was that the data has more structure than the user or provider of the data is forced to see. That structure provides useful functionality, but that functionality is somebody else's business.

More than half of the databases built since 1990 were built for pursposes that are largely at cross purposes with the purpose envisioned by the earlier builders of the DBMS products. In other words, a lot of professionals learned how DBMS products work or, more, precisely how to work DBMS products. But they never learned, or disregarded, what DBMS products are for.

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

I'm with Lauri on this: if views aren't for modularity, then what the heck ARE they for? Of course database people don't call it "modularity". They call it "data independence."

I think of the terms "modularity", "encapsulation", and "data independence" as all addressing the same underlying issue.

Here's the issue: If any part of a system could be intimately linked to any other part of a system, in ways that are not obvious in a schematic view of the "system", then that system is about as maintainable as a bowl of spaghetti.

The folks who developed the three concepts above were all addressing that issue, even though their way of addressing it seems very different.

Again, in expressing what I think is obvious, I don't mean to slam you. I value your opinions. Received on Mon Sep 06 2004 - 15:35:41 CEST