Date/Place: 16 October 1995/Austin, TX
Database was started in middle 1950s. The Korean War had just ended, the French were fighting in Indochina, and Vietnam was one country! Don, Phil and I were still in primary school! Amelia's parents had just been born! (Don Deutsch is X3H2 Chair, Phil and Amelia are members of X3H2.)
Database from the very beginning has always been a vehicle for representing complex data structures. By complex I mean hierarchies and networks. By the early 1960s, the first DMS (data management system), Adam, was running in DoD think tanks (MITRE, Lincoln Labs, and the System Development Division of the Rand Corporation). These DMS had three characteristics in common: English query language, hierarchical data structures, and full-inversion access. In some DMSs the only data that really existed outside the indexes and relationships were the non-indexed fields. Data was directly access through disk drives and drums.
Politics aside, by the middle 1960s, DMS were fully operational, supporting command and control databases for the Strategic Air Command, the Defense Early Warning System (DEWS), and Air Battle control in the U.S. and other Far East locations.
The word database arose by the late 1960s. A database was an organized set of data structures and operations on those structures that matched a clearly defined set of corporate policies. The operations that existed THEN included, in today's terminology, column and table constraints, stored procedures, assertions, triggers, and a full complement of referential integrity
rules and actions. One DBMS, TRW's GIM included fully definable abstract data types, a form of distributed database and two phase commit. All these DMS had schema manipulation languages and full security and privacy. The final component common to these DMSs was NO access through 3GLs.
By the end of the late 1960s, another class of DMSs, started. These were created to preserve the millions of lines of COBOL code. These DMS started with IBM's FFS, formatted file systems, and ended up with two systems, IMS from IBM, and the set of CODASYL (committee on data systems and languages) systems, headed by IDMS, a project of the B.F. Goodrich company. Included also were IDS from Honeywell and DMS-1100 from Univac. Common to those systems were data structures (hierarchical and network), COBOL language access through a subschema facility, and record processing access strategies (that is, almost no indexes). CINCOM's Total was a simplified network data model DBMS designed to compete with IBM's IMS, and which was the first DBMS to run on almost every brand of hardware, a sort of de facto DBMS standard.
The CODASYL DBMS have column and table constraints, a full complement of referential integrity actions and rules, and stored procedures that are activated as triggers.
In those days, databases were still considered to be large complex sets of data structures that matched some coherent set of corporate policy. Database design was laborious and time consuming, not just because of the physical database reorganization requirements from computers that were not even capable of 1 transaction per second, but because the databases were to reflect corporate policy. Policy analysis is, and always has been difficult, time consuming, and something not done by the masses.
Database design was firmly and squarely based on business policy. While at that time, we did not think of database designs as being database objects, in hindsight, they were. There were databases for EMPLOYEEs, PROJECTs, TEACHERs, COURSEs, STUDENTs, FACILITIES, FINANCEs, etc. Each database was founded on a well known, coherent business concept. As each object, that is, the employee, project, teacher, course, and student moved through well known states, certain data structures were valued, modified, and/or deleted. To accomplish these state transformations, whole information systems were created. These information systems either employed their own database transformation logic or used the DBMS self-contained database processes to accomplish the state transformations.
A third set of DBMSs also arose by the late 1960s. These DBMSs were all about making traditional file access easier through the standard 3GL. Adabas from Germany certainly exemplified these systems. If you have files, then after a quick and easy data loading operation you have a database. The common expression was "Database in a Day!" These DBMSs, typified by Adabas, Model 204, Focus, RAMIS, Nomad, and Inquire allow several levels of data structure nesting; the operations of select, project, divide, join, etc. RAMIS, FOCUS, and Nomad have a full complement of Joins and Unions.
These systems, I call Independent Logical File systems.
(ILF) all existed and were running production databases before 1970. These ILF systems were characterized by shallow data structures and index based or sequential l "file" access through 3GLs. These DBMSs however did not completely model business data objects as completely as the other two DBMS classes did.
By the time relational was discovered in 1970, every viable DBMS concept was already in some production class DBMS of one type or another. What relational did however, was to cause two very valuable concepts/activities: database design, and business policy based database objects to be forgotten.
During the 1970s and through the end of the 1980s, databases just plain grew. The awards seemed to go to the one who could build the largest, most number of tables and rows database; who could push through the most number of rows/transactions in a second; who could have the most number of columns in a table, and the like. All the while, the concept of business policy analysis, coherent database design, etc, fell by the wayside. All this is understandable as we've always believed technology to be the source of all answers.
X3H2 was charted in 1978 to standardize the CODASYL network data model. The DDL work was completed two years later. The subschema (copied from COBOL's subschema language) and the DML work (a complete new invention, compliments of Len Gallagher) was completed by 1983. The standard, Network Data Language was delayed a year so that the SQL standard (started as the Relational Data Language (RDL)) could catch up. Both became standards in 1986. The NDL is characterized by flat records with contained vectors and groups that are able to form structures through single, and multiple member sets, a subschema language, and access through 3GLs. Some vendors today, for example, Oracle and Computer Associates implement both the Relational and the Network data models on the same underlying physical data management engine.
SQL/86 included some integrity constraints, views, flat table structures, and access through 3GLS. SQL/89 added referential integrity. SQL/92 added full referential integrity and a whole bunch more integrity constraints. Now SQL/3 has added abstract data types, and if we work real fast, stored procedures, a common call level interface and some form of nested data structures. I know there's more than that to SQL, such as transaction management, two phase commit, multiple language support, but at the fundamental data management level, that's how I see it. I think we need to add more at this fundamental level. I think we need to provide direct assistance at the business data object level.
Much has been written about objects these days. Our committee has gnashed a few teeth on this subject too. As usual, however, we data-bigots see the world inside-out from the process-bigots. To the process-bigot, an object is a combination of process with a data structure component. To tte data-bigot, an object is a data structure with a process component. Can't they be reconciled? Aren't they just inside-out's of each other? I think not. It's the same kind of difference as exists between data flow diagrams and entity-relationship diagrams. They are NOT inside-out's of each other. There is a fundamental orientation difference. Must one survive and the other fail? No, Viva La Difference. After all, isn't object both a noun and a verb. Similar but different?
I object is not the same as I'm an object.
We don't have to come together. When ever I read articles about object-oriented, I seem to be reliving my days of highly structured Fortran programming, where we put together complex systems out of commonly used pieces (and subroutines) of code from libraries. While those code objects are important, and useful they are not database! Nor are they ever what database was EVER intended to be.
Database was always intended to be representations of coherent structures of data that matched well defined areas of policy and which exhibited behavior that matched well known business states.
If we want to contribute to database (note, I did not state DBMS!), then we must rejoin the roadway that was started in the middle 1950s and that had this "1982 to 1995 relational-DBMS development detour." If we want to make a contribution to objects, then first, let us state that we're about business data objects and get on with it. If some other committees want to pursue other types of objects, I don't object!
Let's start with a definition:
A business data object is an instantion of a data structure that proceeds through predefined states according to embedded process transformations.
An object class is the definition language representation of the object. The object class definition language should contain three language subclasses: data, process, and state. I suspect that we already have enough of both data and process. I feel that the view definition language is a good start at the state definition language. I do not feel that adding object classes involves any real change in direction. Rather, a continuation of the right direction.
Business Object Design and Implementation
Page hits since 8/26/95