The IDS, the EDS and the DBMS
Date: Thu, 2 Sep 2004 13:03:13 -0400
Message-ID: <rsqdncziiclazKrcRVn-tA_at_comcast.com>
In this discussion, I'm trying to compare two very different reasons for using a DBMS. I'm calling them the "integrated data store" (IDS) and the
"encapsulated data store" (EDS). What I think I've seen is that people who
build an IDS and people who build an EDS use the same tools and methods, but they use them for purposes that are not merely orthogonal to each other, but are nearly antithetical.
I'm borrowing the term IDS from a project of the same name that was carried
out in General Electric in about 1952. I think of that project as the dawn
of what became the DBMS industry. I prefer the term "integrated" to the
term "centralized". "Centralized" suggests physical proximity, while
"integrated" suggests logical coherence. Each is worth discussing, but I'm
more interested in integration than in centralization.
The IDS is the classic DBMS of the 1970s or 1980s to me. It costs more to get data into the database than to get data into a file, but you get more value out of the data by using it to support more processes.
I'm calling a certain kind of database an "encapsulated data store". I'm using the term "encapsulated" hoping that I can do so without starting yet another tirade between the relational devotees and the OO devotees. Encapsulation is an important concept. Used appropriately, it can contain the collateral damage done when a very large system is revised and extended. I call this collateral damage "the ripple effect". In my structured programming years, I might have used modularity to contain collateral damage, but I think encapsulation clarifies and expands the concept beyond my own concept of modularity.
What do I mean by an EDS? Roughly, it's this: a database is built to
provide persistence to some data in an object oriented environment.
However, the data is seen as being somehow encapsulated within a class of
objects in the larger system.
That is, there is a certain class of objects that "knows" how to interpret
all the data in the database, knows how to operate meaningfully on it, and
knows how and when to write data to the database. Further publication of
the description and prescription of the data would be at best redundant,
and at worst undermine the encapsulation of the class that knows how to use
the database.
How to you spread the value of the data across the entire system? two ways.
First, you can define new classes that inherit from the class that knows the
database.
Second, you can use messaging to communicate between any class and the
class that knows the database.
That is, the OO system uses inheritance and messaging to enable
integration.
In the IDS, the data itself enables integration. The data definitions, descriptions, and prescriptions (or maybe proscriptions) are included in the database, and expressed as data (well, metadata). Thus, from a data centric perspective, the database contains everything needed for the data's orderly use and orderly sharing.
It seems to me that many discussions in this forum have degenerated into tirades because some of us have the IDS so deep under our skins that the EDS strikes us as chaos, and the result of ignorance. Others have the EDS so deep under our skins that the mere concept of the IDS seems at best quaint, and at worst counterproductive.
I'll admit that my own background leads me more towards the IDS than the EDS. But my purpose in this discussion is to move the IDS and the EDS from the realm of unconscious reaction to the realm of conscious thought. That way, the discussion between "IDS types" and "EDS types" can be rational and analytic, instead of visceral and parochial. Received on Thu Sep 02 2004 - 19:03:13 CEST