blakeley@osage.csc.ti.com (Jose' A. Blakeley) (01/25/91)
The purpose of this posting is to probe the programming languages
and database communities about the expected need for an associative
query capability in a programming environment.
As a background note, I am part of a research team at Texas Instruments
responsible for building an object-oriented database management system.
Due to a lack of a formal, universally accepted object data model,
we adopted the type system of an object-oriented programming language
X, where X=C++,CLOS,... as a basic data model for the system. Our approach
is similar to other efforts currently underway at several OODB companies.
We denote the basic API of the programming language X augmented with
database amenities like persistence, transaction management (concurrency
control and recovery), and type management (data dictionary) as Persistent[X].
To complement Persistent[X] we have built a prototype of an associative
object query capability denoted OQL[X]. One of the primary design goals of
OQL[X] is to provide a smooth integration of query statements with the normal
programming language statements of X. OQL[X] can be seen as a hybrid of
SQL and statements from X. The structure of an OQL[X] query statement is:
<result> = SELECT <object>
FROM <range variable> IN <collection>
WHERE <predicate>;
where <result> is a collection-valued variable in a program; <object> describes
the type of the objects in the response collection; <range variable> is a
variable declared using syntax of a variable declaration in X which ranges
over the objects of <collection>; <collection> is a collection-valued program
variable or function, or object stored in the database; and <predicate>
is a Boolean expression describing the condition to be satisfied by the
objects in the response collection.
The following example illustrates the use of an OQL[C++] statement
within a C++ program. People familiar with embeddings of SQL in programs
may wish to compare this code with the amount of code required to
formulate a similar query in a relational system using embedded SQL.
Note that the use of set-valued variables eliminates the need for cursors.
class Person{public: char* name(); ...};
class Medical_Record{public: Date date(); char* diagnosis();...};
class Patient: Public Person{public: Set<Medical_Record> medical_records();
Physician *physician();...};
...
main()
{
Set<Patient> mypatients, result;
Patient p1, p2;
... // code that creates instances of
// of patients not shown
mypatients.Insert_Member( p1 ); // insert a member to the set
...
Query{
Date *d = new Date( 12, 11, 90 );
result = SELECT p
FROM Patient *p IN Patient_Set
WHERE p->physician()->name()->last() == ``Smith''
&& EXISTS ( SELECT r
FROM Medical_Record *r IN p->medical_records()
WHERE r->date() < d
&& r->diagnosis() == ``flu'' ) ;
}
};
I would appreciate any information, feedback, or comments from the
programming languages and database communities about the degree of
interest, desirability, and usability of such an associative
query capability to complement a programming language X.
Please send your comments to blakeley@csc.ti.com.
If there is enough interest and responses to this inquiry I promise
to summarize them and post them in this news group.
There is also a technical report that provides a full description of
OQL[C++]. I will be happy to send copies to interested people.
Thank you in advance for your help.
// Jose' A. Blakeley
// Information Technologies Laboratory
// Texas Instruments
// P.O. Box 655474, MS 238
// Dallas, Texas 75265 (214) 995-0362.blakeley@osage.csc.ti.com (Jose' A. Blakeley) (02/13/91)
To date I have received about 70 responses to my inquiry. I am not sure if I should regard this as a low or high level of interest considering the large number of programmers writing object oriented applications. I cannot stop thinking about the approximately 175,000 C++ programmers plus the increasing number of Lisp, Smalltalk, and Objective-C programmers out there. Surely, many of these programmers should require associative access to data stored in a database management system (DBMS). Many of the replies that I got were requests for a copy of the OQL[C++] report. In this summary, I am including only responses that expressed some opinion about the need for a query capability from a programming language. The majority of the responses are favorable about the idea of providing a tight integration of a query facility with a general purpose programming language (GPPL). In fact, there are products already in the market that followed this approach although not in the context of object oriented programming languages. A few people preferred a database query language neutral with respect to the GPPL. They expressed the need for the query language to support object oriented concepts. Other people believe a query capability is unnecessary in the object paradigm, claiming that associative access can be encapsulated as part of the objects' interfaces. There are many projects currently underway requiring the services of an object DBMS which so far have poor support for associative access. Providing a query tool to an object database which is tightly integrated with GPPLs continues to be a challenge. I wish to thank all people who took time to reply to my inquiry. People who have not replied are encouraged to do so. I still have a few copies of the OQL[C++] report available, and continue to welcome comments to our approach and opinions about this problem in general. Regards, Jose' Blakeley // Texas Instruments // P.O. Box 655474, MS 238 // Dallas, Texas 75265 (214) 995 0362 >++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >From: jguy@EBay.Sun.COM (Jeff Bone) >Date: Fri, 25 Jan 91 17:51:55 PST >... >We work on a large, data distributed MIS app. We deal with pieces of >data that are actually composed of several records residing within >several geographically distributed databases. >... >We have a set of interfaces to these databases and "meta records"... >these tools handle UI objects in a psuedo-OOP way, but the data is >still handled in a record-oriented fashion and managed via >embedded SQL. This dissimilarity of models used in the various >layers of the application is rather perturbing and complicates >things. An integrated, associative query capability that lets >you extend the object paradigm to interacting with the database >would be extremely desirable. > >In short, I think you're headed very much in the right direction. >++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >From: ghm@ccadfa.cc.adfa.oz.au (Geoff Miller) >Date: Mon, 28 Jan 91 14:03:51 +1100 > >I have long preferred working with what I call "three-and-a-half-GLs" >because they combine a programming language with precisely the kind >of database functions you mention. To me, this gives me the tools that >I need while providing a reasonably efficient end product. > >At the moment I am working a lot with Prime "Information", but most of >what I do could equally be done in generic Pick. I have a Basic-like >(rather than C-like) programming language, with access to the database >functionality either through statements like > > EXECUTE "database query generating a select list" > READLIST ... > >or through more direct access to the DBMS functions. As with your example, >my "result" is a set of item IDs which I can then manipulate as required. > >++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >From: "Lindsay F. Marshall" <Lindsay.Marshall@newcastle.ac.uk> >Date: Mon, 28 Jan 91 9:40:37 GMT > >Yes! I want it *NOW* if not yesterday. This facility is absolutely >vital for anyone doing anything with databases who hasn't got access >to a proper OO database system. >... >The project I am working on is involved with constructing a Object >Based System Management environment. There are huges amounts of data >that need to be stored for such a system, and it would be very nice if >it we could store it all in a nice OODB. Sadly we don't have such a >thing and there are other constraints which say that the system ought >to work on top of whatever database a given installation actually has, >rather than forcing people to install yet another dbm. We finesse the >problem a little by restricting the amount of information that has to >be stored in the actual System Management DB but what is in there >really does need associative searches. For example we have a notion >of Contract and we want to be able to search the DB to find all >Contracts with particular contractors for carrying out specific >tasks. Currently we are cobbling together a load of stuff using ESQL >which is nearly working, but a proper Persistent store with relational >searches would be ideal. A team of people have actually built a >persistent object store as part of their efforts to build a system for >reliable distributed programming - >... >++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >From: nhg@allegra.att.com (Narain Gehani) >Date: Mon, 28 Jan 91 10:50:35 EST > >we are working on the Ode object oriented database. We have provided >an associative query capability. > >We hope to release a prototype in a couple of weeks. > >++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >From: jss@kpc.com (Jerry Schwarz (Compiler)) >Date: Mon, 28 Jan 91 11:18:31 PST > >... > There is certainly a large >demand for this kind of facility, but if it is necessary to add >new kinds of statements to the language in order to gain access >to them it suggests to me that there is a deficiency in the >language design. This is particularly true in C++ where a major >selling point of the language is it's ability to define interfaces. >... > >++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >From: Marc H. Scholl <scholl@inf.ethz.ch> >Date: Tue, 29 Jan 91 14:51:17 +0100 > >As for your inquiry: sure, I think OQL[X] is a good idea. In fact, >we're investigating a similar approach, even though we're not talking >about several X's. The object model and query language we're working on >contains the concept of set-valued variables for interfacing with the >programming environment, instead of cursors. > >++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >From: JOELR@IBM.COM >Date: Tue, 29 Jan 91 09:09:59 PST > >I believe there is a wide (and widening) interest in seeing >facilities such as you described in your usenet post. There >have certainly been many attempts to combine languages and >databases over the years, and there are several project here >along these lines. OQL[X] sounds like an interesting >approach to the problem. >... > >++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >From: desikan@gupta.com (Desikan Jagannathan) >Date: Tue, 29 Jan 91 14:05:11 PST > >At Unisys, we built programming language (Pascal,ALGOL and COBOL) >interfaces to SIM, a DBMS based on the semantic data model. We had a >standard, English-like query language that had support for associative >access, inheritance etc.. However, when embedded in a host language, the >query language was "tuned" to the flavor of the host language -- the >syntax and construction of the DBMS statements in Pascal, for example, >look like an extension of Pascal. > >Two papers that describe SIM are: > SIM: A database system based on the Semantic Data model > ACM SIGMOD 1988 >and > Design and Implementation of SIM in > Research foundations in object oriented and semantic data systems > McLeod and Cardenas editors. > >My personal preference is to define a high level, object oriented database >access language independent of other consideraions. It can then be tightly >integrated into languages like C++, loosely integrated into non-object >oriented languages like C and Pascal and serve as the database language for >front end tools like spreadsheets and 4GLs. > >++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >From: Francois EXERTIER <exertier@paques.imag.fr> >Date: Wed, 30 Jan 91 11:20:54 +0100 >... > I'm part of the Bull-Imag research team >in Grenoble. I've already had a small experience about >integrating set manipulation in a OO programming language (GUIDE), as in your >approach, I've integrated a "set" querying facility by the way of a special >method 'select' defined on the SET generic type (I think the difference is a >matter of syntax). I'm also working in extending a >relational DBMS with objects (in the European Project 2025 EDS). And >recently we began to work on a low level database programming language which >should include set manipulation facilities. > >++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >From: @sunic.sunet.se:henri@tsoft (Henri L~bke) >Date: Wed, 30 Jan 91 10:35:17 +0100 >... >For the last three years very many of the application programmers within >our company have been using C++ as programming language. Very often C++ >is used together with an RDBMS. Because of that we have developed a >programming technique for separating the database access methods >from the rest of the code. This works, but we have experienced that what >we really need is an OODBMS with query capabilities. My personal opinion >is that the SQL language is being more and more accepted. This implies >that many applications are being created using this language. In >that perspective (many programmers using different programming languages >and all of them are using SQL) together with the fact that there are at >least 100 vendors of SQL based systems today I believe on the paradigm >that the database query language need not be an extension of each >programming language. I am fully aware of all orthogonality problems >that exist in the current versions of SQL, but It must be possible >to fix that and (as You suggest) implement OO extensions to SQL. > >In one of the projects I mentioned above we also developed a navigational >query language. This worked even in an interactive mode. One of the problems >with that approach was that all DB programmers had to navigate themself >within the schema. In many environments this is OK (eg in the CAD area), >but I strongly believe that this is NOT a winning approach in the end. >So, I like Your SQL approach very much. The set oriented approach >is interesting. > >++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >From: Kim Chung Chan <daniel@cs.glasgow.ac.uk> >Date: Wed, 30 Jan 91 09:41:52 GMT > >The query language I am working is part of an ESPRIT project called COMANDOS. >In Glasgow we are working on the data management facilities of the system. >... > We strongly believe that an >associative query language is important for programming even though we have >not done any survey on user requirements. > >++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >From: cimshop!cimshop4!davidm@uunet.UU.NET (David Masterson) >Date: Sun, 3 Feb 91 17:37:46 PST > >... > Is there a real need for an "associative query capability" within an >object oriented database system? Wouldn't methods against objects provide >all that is needed? Wouldn't this stay within the bounds of C++ and, >therefore, reduce programmer training costs? I've never agreed with >embedded SQL for this reason and I hope not to see it in OODBs. > > Perhaps the only complement to Persistent that is needed is a Transaction >object to manage the states of multi-object transactions? Many people seem >to ignore Transaction as an object in its own right thinking instead that it >is a description of a method on some other object. >... >++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >From: jvdgoor@mswe1.dnet.ms.philips.nl >Date: Mon, 4 Feb 91 15:03:28 +0100 >... > We are building >reasonably large medical equipment (eg. Magnetic Resonance Scanners, >Diagnostic Systems for Cardiac and Vascular Imaging, and so on). Besides >image processing and all the special goodies that are developed at our site >we also have to deal with large sets of patients, images, examinations and >physicians. All of this information must be presented to any operator >(radiologist, doctor, nurse, ..) in any form that he/she prefers. >Structuring and accessing this information can become a pain. Therefore it >would be useful when we had a special language, maybe like OQL, that would >enable us to define data(base) access within our development language. >... >Do you also consider OQL[Objective-C]??? >++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++