DE69131336T2

DE69131336T2 - Verfahren und Gerät um eine inhaltsaddressierbare Abfragemöglichkeit einer Programmiersprache hinzuzufügen

Info

Publication number: DE69131336T2
Application number: DE69131336T
Authority: DE
Inventors: Jose A Blakely; Craig W Thompson
Original assignee: Texas Instruments Inc
Current assignee: Texas Instruments Inc
Priority date: 1990-04-30
Filing date: 1991-04-29
Publication date: 1999-12-16
Anticipated expiration: 2011-04-30
Also published as: DE69131336D1; US5761493A; US5826077A; EP0455447A3; EP0455447A2; EP0455447B1; JPH06110767A

Description

Hintergrund der Erfindung

Gebiet der Erfindung

Diese Erfindung bezieht sich auf objektorientierte Programmiersprachen und auf objektorientierte Datenbank-Managementsysteme und genauer auf eine Sprache zum Abfragen von Sammlungen von unter Verwendung einer Host-Programmiersprache modellierten Objekten, die ihrerseits in einem objektorientierten Datenbanksystem gespeichert sein können.

Beschreibung des Standes der Technik

Die Berichte der 15. Internationalen Konferenz über sehr große Datenbanken, 22.-25. August 1989, S. 433-442, offenbaren eine objektorientiert strukturierte Programmiersprache mit Anweisungen zum Abfragen einer Datenbank. Das Ergebnis des Abfragens der Datenbank ist eine ebenfalls objektorientiert strukturierte Unterdatenbank. Die von diesem Artikel vorgeschlagene Sprache ist eine vollständig neue und in sich abgeschlossene Sprache, d. h. keine Erweiterung einer existierenden Sprache. Zusätzlich zu den Abfrageanweisungen ermöglicht die Sprache, an die Objekte, aus denen die Ergebnisse einer Abfrage bestehen, Meldungen zu schicken oder Operationen an ihnen auszuführen; diese Meldungen oder Operationen können, wie z. B. "print" und "display", computersystemorientiert oder, wie z. B. "hire-employee", anwenderdefiniert sein. Das verwendete Objektmodell ermöglicht sowohl die Verallgemeinerung als auch die Aggregation von Hierarchien. Die verwendeten Abfrageanweisungen besitzen die folgende Struktur:
context association pattern expression
where conditions
select object classes and/or attributes
operations object classes
Klassen von Objekten, die miteinander verwandt sein können, d. h. gemäß dem besonderen verwendeten Realitätsmodell miteinander verwandt sein können, werden in der Kontextzeile spezifiziert, wobei die besonderen Objekte jener Klassen, die über tatsächlich existierende Bezugnahmen miteinander verwandt sind, zurückgegeben werden. Diese Objekte werden dann gemäß den in der Where-Klausel spezifizierten Bedingungen gefiltert. Die Auswahlzeile gibt von der gefilterten Gruppe der Objekte die Objekte besonderer Klassen oder besonderer Attribute zurück. Die folgende Zeile kann zum Ausführen von Operationen auf dem Ergebnis der Abfrage verwendet werden, wobei im Fall einer Gruppe von Objekten Meldungen an sie gesendet werden können. Die durch eine Abfrage erzeugten Unterdatenbanken können zur weiteren Verarbeitung benannt und dauerhaft gesichert werden. Mengenoperationen wie die Vereinigung und der Durchschnitt werden ebenfalls offenbart. Angewandte Informatik 4/87 offenbart auf den S. 149-156 eine MEMOPASCAL genannte Einbettung einer existierenden Abfragesprache MEMODAX in eine Host-Sprache PASCAL. MEMODAX ist ein relationales Datenbanksystem. Es werden Erweiterungsanweisungen bereitgestellt, die Erklärungen von Variablen eines Datenbanktyps und eines Relationstyps ermöglichen. (Eine Relation ist eine Tabelle von Daten in einer relationalen Datenbank und enthält Datensätze oder Tupel, die jeweils die gleiche Feldstruktur besitzen.) Die Erweiterungsanweisungen umfassen außerdem eine Auswahloperation, in der der Satz der zurückgegebenen Tupel einer Relation zugewiesen wird. Zum Umsetzen der Erweiterungsanweisungen in Laufzeitaufrufe für das MEMODAX-System wird ein Vorkompilierer verwendet. Der Artikel legt dar, daß es ein Vorteil ist, z. B. über eine universelle Relationsschnittstelle einen von dem über das MEMOPASCAL- Programm verschiedenen alternativen Zugriff auf die MEMODAX- Datenbank zu besitzen.
Das relationale Modell stellt die Daten in einer Datenbank als eine Sammlung von Relationen dar. Formlos ähnelt jede Relation einer Tabelle. Jede Zeile in einer Tabelle stellt eine Sammlung verwandter Datenwerte dar, die als eine Tatsache interpretiert werden können, die ein Subjekt in der Realität beschreibt. Jede Tabelle und jede Spalte in einer relationalen Datenbank besitzt einen Namen. Die Namen werden zur Hilfe zum Interpretieren der Bedeutung der in jeder Zeile einer Tabelle enthaltenen Werte verwendet. Zum Beispiel wird die Tabelle 20 in Fig. 1 Person genannt, da jede ihrer Zeilen Tatsachen über eine besondere Person darstellt. Die Spaltennamen Name 22, SSN 24, Alter 26 und Adresse 28 spezifizieren, wie die Datenwerte in jeder Zeile auf der Grundlage der Spalte, der jeder Wert angehört, zu interpretieren sind. Alle Werte in einer Spalte haben den gleichen Typ.
In der Terminologie der relationalen Datenbanken wird eine Tabelle eine Relation, ein Spaltenname ein Attribut und eine Zeile ein Tupel genannt. Relationen werden mittels eines durch R(A&sub1;, A&sub2;, ..., An) bezeichneten Relationsschemas, wobei R der Relationsname und A&sub1;, A&sub2;, ..., An die Attribute sind, beschrieben. Zum Beispiel ist das Schema der Relation Person nach Fig. 1 Person(Name, SSN, Alter, Adresse).
In einer relationalen Datenbank werden die Daten unter Verwendung einer Datenbanksprache definiert, abgefragt und aktualisiert. Der Datendefinitionsteil der Sprache wird als die Datendefinitionssprache (DDL) bezeichnet, während der Abfrage- und der Aktualisierungsteil der Sprache als die Datenmanipulationssprache (DML) bezeichnet werden.
Jedes kommerzielle relationale Datenbank-Managementsystem (DBMS) ist mit einer Datenbanksprache ausgestattet. Am besten bekannt ist die als die Datenbanksprache für den relationalen DBMS-Prototyp des Systems R der International Business Machines (IBM) erzeugte Strukturierte Abfragesprache (SQL), die nun einen ANSI-Datenbank-Sprachenstandard für relationale DBMSs dar stellt. Obgleich das (für den an der Universität von Kalifornien in Berkeley für den relationalen DBMS-Prototyp INGRES konstruierte) QUEL eine weitere wohlbekannte Datenbanksprache ist, findet SQL als eine relationale Abfragesprache breitere Verwendung.
Die SQL-Befehle für die Datendefinition in der Datenbank sind CREATE TABLE (spezifiziert ein Relationsschema), ALTER TABLE (fügt zu einem Schema ein Attribut hinzu) und DROP TABLE (löscht ein Schema). Beispiele dieser SQL-Datendefinitionsanweisungen für die Relation Person nach Fig. 1 wären:
Sobald die Datenbank definiert wurde, wird die SELECT-Anweisung in SQL zum Wiedergewinnen von Informationen aus der Datenbank verwendet. Die Grundform der SELECT-Anweisung ist wie folgt aus drei Klauseln - SELECT, FROM und WHERE - aufgebaut:
SELECT < attributes>
FROM < tables>
WHERE < predicate> ;
wobei < attributes> eine Liste von Attributnamen, deren Werte durch die Abfrage wiedergewonnen werden sollen, < tables> eine Liste von Relationsnamen, die die wiederzugewinnenden Daten enthält, und < predicate> ein Boolesches Prädikat, das eine durch die wiederzugewinnenden Tupel zu erfüllende Nebenbedingung spezifiziert, ist.
Zum Beispiel lautet die zum Wiedergewinnen des Namens und der Adresse aller weniger als 30 Jahre alten Personen erforderliche SQL-Abfrage:
SELECT Name, Address
FROM Person
WHERE Age < 30;
Leider besitzt SQL, insbesondere bei der Verwendung zum Abfragen objektorientierter Daten, wie andere momentane Abfragesprachen mehrere Nachteile. Diese Nachteile stammen von der Tatsache her, daß sie als eine Schnittstelle für ein relationales Modell konstruiert wurde, die nur einfache Objekte (Tupel) und nicht zusammengesetzte Objekte behandelt. Im Ergebnis behandelt sie keine Vererbung oder Datenabstraktion, ist nicht eng an eine Programmiersprache gekoppelt und unterstützt keine starke Typisierung. Tabelle 1: Ein Beispiel von SQL, eingebettet in C.
SQL kann in Verbindung mit einer allgemeinen Programmiersprache wie etwa C, FORTRAN oder COBOL verwendet werden. Eine solche Programmiersprache wird die Host-Sprache genannt. Eine SQL- Anweisung kann in eine Host-Sprache eingebettet werden. Eine eingebettete SQL-Anweisung unterscheidet sich von den Host- Sprachenanweisungen dadurch, daß ihr ein spezielles Schlüsselwort vorangestellt ist, so daß ein Vorkompilierer die eingebetteten SQL-Anweisungen von der Host-Sprachenanweisung unterscheiden kann. Zum Beispiel gehen irgendeiner eingebetteten SQL-Anweisung in der Host-Sprache C die Schlüsselwörter EXEC SQL voraus. Das in Tabelle 1 gezeigte Programmstück zeigt die Art, in der SQL in ein C-Programm zum Wiedergewinnen des Namens und der Adresse aller weniger als 30 Jahre alten Personen eingebettet ist.
Der Unterschied zwischen den Typsystemen der Host-Sprache und der eingebetteten Abfragesprache ist normalerweise für den Anwendungsprogrammierer sehr offensichtlich, was zu ernsthaften Problemen führt. Zunächst geht die starke Typisierung in der Datenbankschnittstelle verloren. Die starke Typisierung stellt in einer Programmiersprache sicher, daß die Argumente der Funktionen den richtigen Typ haben; eine Programmiersprache mit einer starken Typisierung gilt als sicherer und effizienter als eine, die kein Erzwingen von Typen unterstützt. In den momentanen SQL-Einbettungen ist die Darstellungen der Host-Sprache und der Datenbank-Abfragesprache verschieden, wobei der Programmierer zum Kopieren seiner Daten in die Datenbank die starke Typisierung durchbrechen muß. Experimentelle dauerhafte Programmiersprachen korrigieren dieses Problem, weisen aber keine Abfrageerweiterungen auf. Zweitens können Abfragesprachen einschließlich der eingebetteten SQL nur Abfragen zum Wiedergewinnen dauerhafter Datenbankobjekte (d. h. in der relationalen Datenbank gespeicherter Daten) im Speicherraum des Programms formulieren. Das Abfragen von Übergangsdaten, die nur während einer einzelnen Ausführung eines Programms im Hauptspeicher des Computers existieren, oder dauerhafter Objekte nach deren Eintritt in den Speicherraum des Programms ist nicht möglich. Drittens können Host-Sprachen-Anweisungungen (z. B. in der Host- Sprache geschriebene anwenderdefinierte Funktionen) nicht in Abfragen verwendet werden, können Abfragen nicht (z. B. als Parameter für Funktionen) frei mit Host-Sprachen-Anweisungen gemischt werden und müssen spezifischen Protokollen genügen. Viertens stellen Programmiersprachen typischerweise keinen SET- Typ als einen ihrer Grundtypen bereit. Folglich kann die vollständige Gruppe der durch eine Abfrage zurückgegebenen Objekte nicht für ein Programm verfügbar gemacht werden. Es kann nur jeweils ein Tupel für ein Programm verfügbar gemacht werden. Das in allen Einbettungen von SQL verwendete Konzept eines Cur sors (Anweisung 9 aus Tabelle 1) erzwingt diese tupelweise Verarbeitung (Anweisungen 12-16 aus Tabelle 1). Schließlich sind die Syntax und die Semantik der Abfrage- und der Host-Sprache vollständig verschieden, wobei der Programmierer diese Unterschiede erlernen und sich ihrer bewußt sein muß.
Wie oben erwähnt wurde, stellt das relationale Modell die Daten in Tabellenform dar. Ein Tupel in einer Relation kann nur aus atomaren Werten gebildet werden. Somit können die Informationen über eine Person und über alle ihre Kinder (wie in Tabelle 30 von Fig. 2 zu sehen) nicht in einer einzelnen Relation dargestellt werden. Außerdem kann das relationale Modell keine Vererbung und keine durch die Host-Sprache definierten, anwenderdefinierten abstrakten Datentypen behandeln. Das liegt daran, daß die Typsysteme der Host- und der Abfragesprache verschieden sind.
Der objektorientierte Zugang zur Modellierung von Daten liefert eine bessere Übereinstimmung zwischen realen Subjekten und der Art, in der sie in einer Datenbank dargestellt werden. Ein zentrales Konzept in diesem Ansatz ist das Konzept eines Objekts, das eine Abstraktion eines für die Anwendung relevanten Dings in der Realität ist. Ein Objekt wird von zwei Hauptkomponenten gebildet: von seinem Zustand und von seinem Verhalten.
Der Zustand besteht aus einer Sammlung von (auch Instanzvariable, Datenelemente oder Schlitze genannten) Attributen. Die Attribute können genau als die Attribute eines Tupels betrachtet werden, das ein reales Subjekt in dem relationalen Modell darstellt. Das Verhalten besteht aus einer Sammlung von (auch Operationen, Verfahren oder Elementfunktion genannten) Funktionen, die das Verhalten des Objekts kapseln. Die Sammlung der Funktionen, die das Verhalten eines Objekts modellieren, wird auch als die Schnittstelle des Objekts bezeichnet und ist die einzige Möglichkeit, mit einem Objekt zu wechselwirken. Eine wichtige Eigenschaft eines Objekts besteht darin, daß sein Privatzustand nur durch seine eigenen Operationen manipuliert werden kann. Diese Eigenschaft stellt sicher, daß die Realisierung ei nes Objekts nicht von den internen Einzelheiten anderer Objekte, sondern nur von ihren Operationen abhängen kann, was, da sie spezifizieren, welche Operation erwünscht ist, nicht aber, wie die Operation ausgeführt werden sollte, die Modularität und die Datenunabhängigkeit der Anwendungen sicherstellt.

Tabelle 2: Einige Beziehungen zwischen relationalen und objektorientierten Konzepten.

relationales Konzept objektorientiertes Konzept
Relationsschema Klasse oder Typ
Attribut Attribut, Datenelement, Schlitz
Funktion, Verfahren, Operation, Elementfunktion
Tupel Objekt
Relation Gruppe der Objekte
Eine Klasse (oder ein Typ) beschreibt die Realisierung einer Gruppe von gleichartigen Objekten. Jedes Objekt, gelegentlich Instanz genannt, muß zu einer Klasse gehören. Tabelle 2 zeigt die Korrelation zwischen relationalen und objektorientierten Konzepten.

Tabelle 3: Komponenten einer Klassendefinition.

Klassenname Employee
Superklasse Person
Attribute Hire_date, Job_grade, Salary, Project
Funktionen Hire employee, Increase_salary, Assign_project, Promote_employee
Tabelle 3 zeigt die Hauptkomponenten einer Beispielklassendefinition.
Im Gegensatz zu Relationen sind Klassen in einer Vererbungshierarchie organisiert. Eine Klasse kann in einer Unterklasse verfeinert oder spezialisiert werden, die ihr Verhalten erbt.
Die Klasse Employee aus Tabelle 3 erklärt, daß die Objekte der Klasse das Verhalten der Klasse Person erben, die in der Hierarchie der Vorgänger von Employee ist. Das relationale Modell besitzt diese Ideen des Verhaltens und der Vererbung nicht.
In dem objektorientierten Modell kann ein Objekt aus anderen, beliebig komplexen Objekten zusammengesetzt sein. Zum Beispiel besteht ein Objekt Auto aus einem Objekt Fahrgestell und einem Objekt Karosserie. Ein Fahrgestell besteht seinerseits aus den Objekten Rahmen, Räder und Motor.
Jedes Objekt besitzt eine Objektidentität, die das Objekt eindeutig identifiziert und unabhängig vom Zustand des Objekts ist. Dies ermöglicht die Bezugnahme auf ein Objekt durch andere Objekte, so daß es gemeinsam genutzt werden kann. Im Gegensatz dazu können in dem relationalen Modell Tupel (das Objekt des Modells) nicht gemeinsam genutzt werden. Ein Tupel ist vollständig durch die Werte seiner Attribute identifiziert, wobei in einer Relation keine zwei Tupel existieren können, die in bezug auf alle ihre Attribute die gleichen Werte haben.
Es wird nun die Programmiersprache C&spplus;&spplus; als ein Beispiel eines objektorientierten Datenmodells betrachtet. Das Datenmodell von C&spplus;&spplus; umfaßt eine Gruppe vordefinierter (eingebauter oder primitiver) Datentypen einschließlich: Zeichen, Ganzzahl, Langzahl, Kurzzahl, Gleitkommazahl und doppelt genaue Zahl. Diese primitiven Typen können zum Definieren komplexerer Typen verwendet werden.
Eine Klasse ist der Mechanismus zum Definieren eines solchen komplexen Typs, der den Zustand und das Verhalten einer Sammlung von Objekten bestimmt. Die Definition einer Klasse umfaßt das Spezifizieren einer Gruppe von Datenelementen (Attributen oder Instanzvariablen) und einer Gruppe von Elementfunktionen (Operationen oder Verfahren). Ein Klassenelement (eine Elementfunktion oder ein Datenelement) kann als öffentlich, privat oder geschützt erklärt werden. Auf ein öffentliches Element kann von einer beliebigen Stelle in einem Programm aus zuge griffen werden. Auf ein privates Element können nur die Elementfunktionen seiner Klasse zugreifen. Auf ein geschütztes Element können die Elementfunktionen seiner Klasse sowie die Elementfunktionen der von ihr abgeleiteten Klassen zugreifen. Ein abstrakter Datentyp ist eine Klasse, die eine öffentliche Gruppe von Elementfunktionen und keine öffentlichen Datenelemente besitzt (alle ihre Datenelemente sind als privat oder geschützt erklärt).
Beim Definieren einer Klasse wird der Typ jedes ihrer Datenelemente spezifiziert. Der Typ eines Datenelements kann einer der vordefinierten Datentypen (Ganzzahl, Gleitkommazahl usw.) oder ein anderer, anwenderdefinierter Typ sein. Diese Fähigkeit in C&spplus;&spplus; ermöglicht das Aufbauen von Aggregationshierarchien (gelegentlich als Kompositionshierarchien bezeichnet) oder Graphen zur Darstellung komplexer Objekte, die rekursiv bezüglich anderer Objekte definiert sind. Rekursive Definitionen, in denen ein Datenelement einer Klasse zurück auf die gleiche Klasse zeigt, sind ebenfalls möglich.
Ein Klasse kann ebenfalls von einer oder von mehreren Basisklassen abgeleitet werden, wobei somit die einzelne und die mehrfache Vererbung unterstützt wird. Eine abgeleitete Klasse kann selbst als die Basisklasse für weitere Ableitungen dienen, wobei dies den Aufbau von Verallgemeinerungshierarchien oder Gittern ermöglicht. Eine abgeleitete Klasse erbt alle öffentlichen und geschützten Elemente ihrer Basisklasse und wird als eine Unterklasse (ein Untertyp) ihrer Basisklasse bezeichnet. Auf private Elemente einer Basisklasse kann nicht von irgendwelchen anderen Klassen einschließlich von irgendwelchen abgeleiteten Klassen aus zugegriffen werden.
Da die Programmiersprache C&spplus;&spplus; viele der zuvor diskutierten Beschränkungen des relationalen Datenmodells einschließlich der Darstellung beliebig komplexer Elemente, der Vererbung und anwenderdefinierter abstrakter Datentypen überwindet, ist sie eine gute Grundlage für ein Datenmodell. Da C&spplus;&spplus; keine dauerhaften Daten, keine Gleichzeitigkeitssteuerung und keine Wiedergewin nung behandeln kann, unterliegt es als ein Datenbanksystem jedoch noch einigen Beschränkungen; außerdem fehlt C&spplus;&spplus; die Unterstützung für einen SET-Typ und für einen assoziativen Abfragemechanismus. Eine Überwindung dieser letzteren Beschränkungen ist wünschenswert.
Frühere objektorientierte Abfragesprachen können in zwei Gruppen eingeteilt werden. Dies sind die Erweiterungen zu SQL und jene, die versuchen, zu C&spplus;&spplus; eine Abfragefähigkeit hinzuzufügen. Bis zur vorliegenden Erfindung hat kein früherer Ansatz eine Kombination der beiden geschaffen.
Beispiele solcher objektorientierten Abfragesprachen sind OSQL, RELOOP und O+&spplus;. OSQL ist die Abfragesprache des bei Hewlett- Packard entwickelten objektorientierten Datenbank-Managementsystem-Prototyps IRIS. RELOOP ist eine der Abfragesprachen des bei Altair entwickelten objektorientierten Datenbank-Managementsystem-Prototyps O&sub2;. Sowohl OSQL als auch RELOOP beruhen auf SQL, wobei sie aber keine Host-Sprachausdrücke in Abfragen ermöglichen und somit nicht eng mit einer Programmiersprache integriert sind.
O++, eine von C&spplus;&spplus; abgeleitete Datenbankprogrammiersprache, ist die Sprache des bei AT&T entwickelten Datenbanksystem-Prototyps ODE. O&spplus;&spplus; enthält in seiner Syntax Iteratorausdrücke (z. B. for each), die das Manipulieren von Gruppen von Objekten fast so erklärend wie relationale Abfragesprachen ermöglichen. O&spplus;&spplus; beruht auf C&spplus;&spplus;, wobei die Grundstruktur der Abfrageanweisungen aber nicht die SELECT-FROM-WHERE-Form (SFW-Form) von SQL verwendet. O&spplus;&spplus; ist eine Sondersprache, die einen besonderen und teuren Kompilierer erfordert und wie OSQL und RELOOP nur dauerhafte Objekte und keine Übergangsobjekte abfragen kann.
Außerdem werden in herkömmlichen Datenbanken Daten durch den Anwendungsprogrammcode jedesmal aus dem und in das Datenmodell des Programms in das Datenmodell der Datenbank übersetzt, wenn Daten zwischen den beiden verschoben werden. Das MACH-Projekt von Carnegie-Mellon berichtet, daß 90% der Anwendungen, die Daten gemeinsam nutzen, dies auf dem gleichen Maschinentyp und in der gleichen Programmiersprache tun. Durch Übersetzen des Datenmodells der Sprache in ein anderes (z. B. relationales) Datenmodell zahlt die Datenbank-Programmiersprachen-Gesellschaft 100% der Zeit für eine Abbildung (die Übersetzungskosten von dem Datenmodell der Sprache in das neutrale Datenmodell), wenn sie nur 10% der Zeit benötigt wird. Es ist wünschenswert, daß dies nur geschieht, wenn es zur gemeinsamen Nutzung von Daten unter verschiedenen Programmiersprachen, die verschiedene Datenmodelle nutzen, erforderlich ist. Da die Übersetzung den Programmierern überlassen ist, führt dies ferner eine Wahrscheinlichkeit von Fehlern und Ineffizienzen ein. Sogar 30% der Anwendungen, die auf Datenbanken zugreifen, werden im Programmierercode zum Ausführen solcher Abbildungen verbracht, was die Produktivität der Programmierer wesentlich erschöpft. Außerdem wird dadurch, daß diese Übersetzung den Anwendungsprogrammierern überlassen wird, die typsichere starke Typisierung potentiell genau an der Programm-Datenbank-Schnittstelle gebrochen (nicht durch das System sichergestellt). Da das typsichere Verhalten in den Programmen als ein wesentliches Merkmal betrachtet und die in der Datenbank gespeicherten Daten als ein Hauptbetriebsmittel eines Unternehmens angesehen werden, ist dieser Verlust der starken Typisierung an der Datenbank- Programm-Schnittstelle ein großes Problem. Die heutigen Datenbanksysteme erhalten die Typsicherheit an dieser Schnittstelle nicht; die Datenbanken von morgen werden dies tun müssen.
Schließlich unterstützt kein OODBMS eine nahtlose Integration zwischen der Abfrage- und der Host-Sprache. Allgemein werden Abfragesprachen in die Host-Sprache in einer Ad hoc-Weise, nicht durch nahtlose Erweiterung der Host-Sprache mit Gruppen und Abfragen, eingebettet.

Zusammenfassung der Erfindung

Angesichts der obigen mit dem Stand der Technik verknüpften Probleme besteht eine Aufgabe der vorliegenden Erfindung in der Schaffung einer Vorrichtung und eines Verfahrens zum Erzielen einer besseren Integration (auch als Nahtlosigkeit bekannt) zwischen einer Abfragesprache und einer objektorientierten Host-Programmiersprache.
Eine weitere Aufgabe der vorliegenden Erfindung ist die Schaffung einer Vorrichtung und eines Verfahrens, die die Datenbankprogrammierung für Programmierer unter Verwendung einer spezifischen Host-Sprache zugänglicher machen.
Gemäß der vorliegenden Erfindung wird ein Verfahren zum Ausführen von Abfragen von Objektengruppen in einem Computer geschaffen, wobei die Abfragen in Abfrageanweisungen eines Programms explizit spezifiziert sind,
dadurch gekennzeichnet, daß
das Programm Anweisungen einer objektorientierten Host- Programmiersprache und Erweiterungssprachen-Anweisungen, die wenigstens die Abfrageanweisungen enthalten, umfaßt und daß die Abfrageanweisungen der Abfrage von Mengen von Objekten der Hast-Programmiersprache dienen,
daß das Verfahren die Vorverarbeitung des Programms enthält und daß die Vorverarbeitung das Umsetzen wenigstens der Erweiterungssprachen-Abfrageanweisungen in Anweisungen der objektorientierten Host-Programmiersprache enthält, und daß das Verfahren ferner enthält:
Kompilieren des resultierenden Programms in der Host- Sprache in ausführbaren Code und
Ausführen des resultierenden ausführbaren Codes, wobei der Code ausgeführt wird, um das Ergebnis der Abfrageanweisungen zurückzugeben.
Gemäß der vorliegenden Erfindung wird außerdem eine Vorrichtung zum Ausführen von Abfragen von Mengen von Objektgruppen ge schaffen, wobei die Abfragen in Abfrageanweisungen eines Programms explizit spezifiziert sind,
dadurch gekennzeichnet, daß
das Programm Anweisungen einer objektorientierten Host- Programmiersprache und Anweisungen einer Erweiterungssprache, die wenigstens die Abfrageanweisungen enthalten, umfaßt und daß die Abfrageanweisungen der Abfrage von Mengen von Objekten der Hast-Programmiersprache dienen,
daß die Vorrichtung ein Mittel zum Vorverarbeiten des Programms enthält und daß die Vorverarbeitung das Umsetzen wenigstens der Erweiterungssprachen-Abfrageanweisungen in Anweisungen der objektorientierten Host-Programmiersprache enthält,
und daß die Vorrichtung ferner enthält:
ein Mittel zum Kompilieren des resultierenden Programms in der Host-Sprache in ausführbaren Code und
ein Mittel zum Ausführen des resultierenden ausführbaren Codes, wobei der Code ausgeführt wird, um das Ergebnis der Abfrageanweisungen zurückzugeben.
In einer bevorzugten Ausführungsform wird eine starke Typisierung an der Abfrageschnittstelle beibehalten, wobei auf diese Weise die Datenbankprogrammierung wesentlich erleichtert und zuverlässiger als herkömmliche SQL-Einbettungen gemacht wird.
In einer bevorzugten Ausführungsform können Abfragen nicht nur an dauerhafte, sondern auch an Übergangssammlungen von Objekten formuliert werden, können anwenderdefinierte Funktionen in der Rost-Sprache zur Verwendung bei der Formulierung von Abfragen geschrieben werden, können Abfragen frei mit Host-Sprachen- Anweisungen, die ein Gruppenobjekt erwarten, gemischt werden, wird ein SET-Typ unterstützt, so daß vollständige Sammlungen von durch die Abfragen zurückgegebenen Objekten in der Host- Sprache verfügbar sind, wird eine Datenabstraktion unterstützt, werden die Vererbung und zusammengesetzte Objekte bei der Formulierung von Abfragen unterstützt und werden eine gleichförmigere Syntax und Semantik der Abfrage- und der Host-Sprache geschaffen.
Diese Aufgaben werden in einer bevorzugten Ausführungsform dadurch erreicht, daß eine Vorrichtung und ein Verfahren geschaffen werden, die als Objektabfragesprache (OQL) bekannt sind. Der Begriff "OQL" bezieht sich auf das spezifische Verfahren zum Erweitern irgendeiner objektorientierten Host-Sprache mit zugeordneten Abfrageanweisungen, während sich "OQL[C&spplus;&spplus;]" auf die besondere Verbindung von OQL mit C&spplus;&spplus; bezieht, die die Verwendung bestimmter C&spplus;&spplus;-Ausdrücke bei der Formulierung von Abfragen ermöglicht. Wo die spezifische Host-Sprache nicht wichtig ist, wird der Begriff "OQL[X]" zum Bezeichnen einer Verbindung von OQL mit einer Host-Sprache X verwendet, wobei X z. B. C&spplus;&spplus;, CLOS, Smalltalk, Objective-C usw. ist.
Grundsätzlich wendet OQL die SELECT-FROM-WHERE-Struktur (SFW- Struktur) der SQL-SELECT-Anweisung an und ermöglicht, geeignete Anweisungen der Host-Sprache in Abfragen zu verbinden. Die SFW- Struktur von SQL wird angewendet, da sie ein Standardmodell für die Formulierung von Abfragen in objektorientierten Host- Sprachen liefert, das sich in Datenbankanwendungen momentan eines breiten Gebrauchs erfreut.
Die bevorzugte Ausführungsform OQL[C&spplus;&spplus;] erweitert das Typsystem von C&spplus;&spplus; durch eine Unterstützung eines Typs einer parametrisierten Gruppe, wobei sie auf diese Weise ermöglicht, daß C&spplus;&spplus; Gruppen behandelt. Somit ist die Erfindung dadurch, daß sie eine nahtlose Integration zwischen der Abfrage- und der Host- Sprache dadurch schafft, daß sie die Verwendung der von einer OQL[C&spplus;&spplus;]-Abfrage zurückgegebenen Gruppen an irgendeiner Stelle innerhalb eines C&spplus;&spplus;-Programms ermöglicht, bei der zu erwarten ist, daß eine Gruppe zu behandeln ist (z. B. ein Parameter für eine C&spplus;&spplus;-Funktion), daß sie die Verwendung mengenwertiger C&spplus;&spplus;- Funktionen in der FROM-Klausel einer OQL[C&spplus;&spplus;]-Anweisung ermöglicht und daß sie die freie Kombination von Booleschen C&spplus;&spplus;- Funktionen als Teil eines Prädikats in der WHERE-Klausel einer OQL[C&spplus;&spplus;]-Anweisung ermöglicht, mehr als eine Einbettung einer Abfragesprache in C&spplus;&spplus;. Diese Nahtlosigkeit in bezug auf die Sprache tritt auf, da C&spplus;&spplus; mit Gruppen von Datensätzen und Operationen auf Gruppen erweitert wird.
Im Gegensatz zu vielen existierenden objektorientierten Abfragesprachen schafft die bevorzugte Ausführungsform der vorliegenden Erfindung eine bessere Integration mit der objektorientierten Programmiersprache C&spplus;&spplus;. Die durch die bevorzugte Ausführungsform der vorliegenden Erfindung gelösten Entwurfsaufgaben sind: minimale Datenmodellabhängigkeit durch Verwendung des Typsystems der Programmiersprache als ein nacktes Datenmodell, Datenabstraktion durch Beschränkung der Abfragen auf die Verwendung der öffentlichen Schnittstelle des Objekts, orthogonale Behandlung von Klassen als Typen und von Klassen als Typerweiterungen durch Unterstützen vom Anwender unterhaltener Klassenerweiterungen, Dauerhaftigkeit orthogonal zur Abfrageverarbeitung durch das Ermöglichen von Abfragen sowohl an Übergangsgruppen als auch an dauerhaften Gruppen und eine verringerte Leistungsfehlanpassung zwischen der Programmiersprache und der Abfragesprache durch Verwendung des gleichen Typsystems für beide Sprachen.
OQL[C&spplus;&spplus;] ist minimal datenmodellabhängig. Dies wird dadurch erreicht, daß, anstatt ein neues proprietäres Datenmodell ganz von vorn zu definieren, nur die Kenntnis des Typsystems der Host-Sprache (in diesem Fall C&spplus;&spplus;) als ein "nacktes" Datenmodell vorausgesetzt wird. Die C&spplus;&spplus;-Konzepte des Objekts, der Klasse, des Datenelements, der Elementfunktion, der Vererbung und der Definitionen von Klassenzusammensetzungen schafft den Kern der meisten objektorientierten Datenmodelle.
OQL[C&spplus;&spplus;] unterstützt die Datenabstraktion dadurch, daß es erzwingt, daß alle Abfragen über die öffentliche Schnittstelle (Elementfunktionen) des Objekts formuliert werden, wobei somit die interne Darstellung des Objekts verborgen wird. Dies wird durch das Analysiermodul 102 (siehe Fig. 4) von OQL[C&spplus;&spplus;] erreicht, das in dem Laufzeit-Datenwörterbuch 112, das alle Klasseninformationen enthält und irgendwelche Abfrageanweisungen, die auf irgend etwas anderem als auf der öffentlichen Schnittstelle der Klasse definiert sind, nicht zuläßt, nachschlägt. Eine bezüglich der privaten Datenelemente oder Elementfunktionen des Objekts falsch formulierte Abfrage führt zu einem in Fig. 4 gezeigten Syntaxfehler 122. Dies erzeugt das Prinzip der Datenunabhängigkeit, (d. h. der Immunität der Anwendungen gegenüber Änderungen an den zum Organisieren der Daten verwendeten Datenstrukturen), die eine der durch das relationale Modell eingeführten, in objektorientierten Datenbankabfragen zu bewahrenden Hauptvorteile ist.
OQL[C&spplus;&spplus;] unterstützt explizite, durch den Anwender unterhaltene Gruppen dadurch, daß es erfordert, daß Programmierer in ihren Programmen Variablen vom Typ OQL_SET definieren. Dies bewirkt, daß die Konzepte der Klassendefinition und der Klassenerweiterung (der Gruppe der Instanzen einer Klasse) orthogonal sind. Wie es in allen Datenbanksystemen, die implizite Gruppen unterstützen, der Fall ist, sind im Ergebnis dessen möglicherweise nicht allen Klassen Gruppen zugeordnet, während einigen Klassen möglicherweise nicht eine, sondern viele Gruppen zugeordnet sind. Dies wird dadurch erreicht, daß ein Programmierer, anstatt implizite Gruppen von der Klassendefinition zugeordneten Objekten vorauszusetzen, explizit Variablen vom Typ OQL_SET definieren und diese Gruppen unter Verwendung der Elementfunktionen vom Typ OQL_SET (siehe Block 44 aus Tabelle 5 unten) bevölkern kann.
OQL[C&spplus;&spplus;] ermöglicht Abfragen in Übergangsgruppen und dauerhaften Gruppen. In relationalen DBMSs und in allen momentanen OODBMSs werden Abfragen ausschließlich an dauerhaften Daten ausgeführt. In OQL ist es möglich, Übergangsgruppen, d. h. Gruppen, deren Lebensdauer ein einzelner Programmaufruf ist, zu definieren und abzufragen. Nun zurückkehrend zu Fig. 4 wird eine Abfrage von Übergangsgruppen durch Unterhalten eines "Laufzeit"-Datenwörterbuchs 112 erreicht, das alle durch die Anwendung definierten Übergangsklassen und dauerhaften Klassen und mengenwertigen Variablen verfolgt. Diese Datenwörterbuch- Informationen sind für den OQL-Abfrageprozessor 100 verfügbar, so daß ein geeigneter C&spplus;&spplus;- oder dauerhafter C&spplus;&spplus;-Code erzeugt wird. Dies macht den OQL-Zugang zur Abfrage unabhängig davon, ob die Daten dauerhaft in einem DBMS oder vorübergehend im Speicher eines Computers unterhalten werden. Als eine direkte Folge dieser Unabhängigkeit kann OQL als ein Werkzeug zum Unterstützen von Abfrageanweisungen in einer Host-Sprache verwendet werden.
Dadurch, daß OQL[C&spplus;&spplus;] die Verwendung bestimmter Host-Sprachkonzepte bei der Formulierung von Abfragen ermöglicht, schafft es eine bessere Integration mit der Host-Sprache. Dies wird dadurch erreicht, daß, zusätzlich zu den OQL_SETs in der FROM- Klausel einer Abfrage eingegebene Bereichsvariable und anwenderdefinierte mengenwertige Funktionen, in der WHERE-Klausel anwenderdefinierte Boolesche Funktionen und vererbte Elementfunktionen und in der SELECT-Klausel Typobjekte und Ersetzbarkeit gefordert werden. Da alle Informationen über die Vererbungsklassenhierarchie in dem Datenwörterbuch 112, auf das der Analysierer 102, die Abfrageneuschreibung 104 und die Abfrageübersetzungsmodule 106 zugreifen, verfügbar sind, können der Analysierer und die Abfrageneuschreibmodule gültige Bezugnahmen auf vererbte Elementfunktionen erkennen und kann der Abfrageübersetzer den richtigen, der verarbeiteten Abfrage entsprechenden C&spplus;&spplus;- oder dauerhaften C&spplus;&spplus;-Code erzeugen. Dies ermöglicht eine viel besser Programmierbarkeit der Erfindung als SQL, ohne die speziellen, nochmals weiteren Spracherweiterungen zu SQL zum Erweitern seiner DML-Funktionalität zu benötigen.
Außerdem schafft OQL[C&spplus;&spplus;] geschickte Schleifen-Konstrukte für C&spplus;&spplus;. Der Programmierer kann die relationale Berechnung von SQL ausnutzen, um zu spezifizieren, welche Daten wiederzugewinnen sind, wobei er die vorliegende Erfindung die höhere Spezifizierung in Schleifen abbilden läßt, die bestimmen, wie die Daten effizient wiederzugewinnen sind. Das "Was" wird durch das in den Abfrageprozessor 100 eingegebene erklärende OQL[C&spplus;&spplus;] 124 dargestellt, während das "Wie" durch den von dem Abfrageprozessor ausgegebenen C&spplus;&spplus;- oder dauerhaften C&spplus;&spplus;-Code 126 dargestellt wird. Dies erhöht die Produktivität des Programmierers, indem es ihm die Last des Bestimmens effizienter Zugriffswege abnimmt und ihm das Schreiben und Lesen des Codes erleichtert.
In der vorliegenden Erfindung werden die Daten zwischen dem Programm- und dem Datenbank-Datenmodell durch den Anwendungsprogrammcode nur übersetzt, wenn Daten zwischen verschiedenen, auf verschiedenen Datenmodellen beruhenden Programmiersprachen gemeinsam genutzt werden müssen. Da die Datenbank-Programmiersprachen-Gemeinschaft nicht mehr für die Kosten von 100% der Zeit zu zahlen hat, wenn nur 10% der Zeit erforderlich sind, erzeugt dies große Einsparungen. In den relationalen und in anderen existierenden Systemen wird diese Übersetzung zwischen der Host-Sprache und der Datenbank durch Anwendungscode erreicht. In dauerhaften Programmiersprachen wird es durch eine von dem System unterhaltene Abbildung erreicht, die Datenstrukturen im Laufzeit-Host-Sprachen-Speicher in die/aus den externen Speicherdarstellungen übersetzt. OQL soll mit diesen letzteren dauerhaften Programmiersprachen arbeiten. In diesem Fall wird die dauerhafte oder vorübergehende Existenz der Gruppen in einer zur dauerhaften oder vorübergehenden Existenz irgendeiner anderen Host-Sprachen-Datenstruktur genau analogen Weise erreicht.
Diese und weitere Merkmale und Vorteile der Erfindung werden für den Fachmann auf dem Gebiet aus der folgenden ausführlichen Beschreibung einer bevorzugten Ausführungsform offensichtlich, die zusammen mit der beigefügten Zeichnung zu nehmen ist, in der:

Beschreibung der Zeichnung

Fig. 1 ein Blockdiagramm ist, das ein Beispiel einer Tabelle in dem relationalen Modell der Daten im Stand der Technik zeigt;
Fig. 2 ein Blockdiagramm ist, das ein Beispiel von Daten zeigt, die mit dem Stand der Technik in dem relationalen Modell nicht dargestellt werden können;
Fig. 3 eine schematische Darstellung einer Beispielklassenhierarchie ist, die ein Krankenhaus-Datenbanksystem beschreibt;
Fig. 4 ein Blockschaltplan der Abfrageprozessorarchitektur gemäß einer bevorzugten Ausführungsform der vorliegenden Erfindung ist;
Fig. 5 ein Diagramm der zum Kompilieren eines gemäß der vorliegenden Erfindung geschriebenen Programms erforderlichen Vorverarbeitungsphasen ist; und
Fig. 6 ein Blockschaltplan ist, der die Lage einer Anwendung der vorliegenden Erfindung, von C&spplus;&spplus;-Anweisungen, von dauerhaften C&spplus;&spplus;-Anweisungen, von Übergangsdaten und von dauerhaften Daten im Hauptspeicher eines Computers zeigt.

Ausführliche Beschreibung einer bevorzugten Ausführungsform

Obgleich die bevorzugte Ausführungsform der Objektabfragesprache (OQL) der vorliegenden Erfindung unten bezüglich ihrer besonderen Syntax und Semantik in bezug auf ihre Realisierung mit der Programmiersprache C&spplus;&spplus; weiter beschrieben wird, ist einiger zusätzlicher Hintergrund erforderlich.
Es sollte erkannt werden, daß OQL, obgleich die unten ausführlich zu beschreibende bevorzugte Ausführungsform OQL[C&spplus;&spplus;] eine spezifische Bindung mit C&spplus;&spplus; als einer Host-Sprache zur Datenmodellierung und für Programmoperationen schafft, auf andere Sprachen wie etwa auf OQL[Cobol], auf OQL[CLOS], auf OQL[Smalltalk] usw. erweitert werden kann, wodurch Abfragefähigkeiten ebenso zu anderen Programmiersprachen hinzugefügt werden. OQL kann auf OQL[X] erweitert werden, wobei X ein Datenmodell einschließlich eines allgemeinen sprachneutralen Datenmodells; und einschließlich domänenspezifischer Datenmodelle für die computerunterstützte Entwicklung (z. B. das erweiterte Datenaustauschformat oder EDIF), für die computerunterstützte Software-Entwicklung (z. B. das Informationsentwicklungsmittel von TI), für die Wissensdarstellung (z. B. für ROCK der Carnegie-Group-Initiative), für Büroinformationssysteme (z. B. für die Bürodatenarchitektur SGML) usw. ist. OQL[X] definiert eine Familie von Bindungen zwischen einer Abfragesprache und entweder einer Host-Sprache oder einer Datenmodellierungsumgebung. Somit sollte die vorliegende Erfindung in keiner Weise nur auf eine C&spplus;&spplus;-Verbindung beschränkt werden.
Die Syntax von OQL[C&spplus;&spplus;] beruht auf dem SFW-Paradigma von SQL, wird aber mit C&spplus;&spplus;-Ausdrücken erweitert. Da das SFW-Paradigma von SQL zum Abfragen nicht nur von relationalen Daten, sondern, wie aus der großen Anzahl der SQL-Erweiterungen ersichtlich ist, auch von durch andere Modelle dargestellten Daten verwendet werden kann, gilt es als datenmodellunabhängig. Die bevorzugte Ausführungsform der vorliegenden Erfindung verbindet genau das SFW-Paradigma von SQL mit dem Datenmodell von C&spplus;&spplus;.
OQL[C&spplus;&spplus;] ist keine Einbettung in C&spplus;&spplus;, da die von OQL[C&spplus;&spplus;]- Abfragen herrührenden Gruppen an irgendeiner Stelle in einer C&spplus;&spplus;-Anweisung, die eine Gruppe (z. B. einen Parameter für eine C&spplus;&spplus;-Funktion) erwartet, verwendet werden können, da durch anwenderdefinierte Funktionen zurückgegebene Gruppen weiter abgefragt werden können und da anwenderdefinierte Funktionen als Teil der Prädikate von Abfragen verbunden werden können.
OQL[C&spplus;&spplus;] ist eine erklärende und nichtprozedurale Sprache, d. h., daß der Programmierer OQL[C&spplus;&spplus;] nutzen kann, um zu spezifizieren, welche Daten wiedergewonnen werden müssen, und daß er OQL die höhere Spezifikation in Schleifen abbilden lassen kann, die bestimmen, wie die Daten effizient auszulesen sind. Dies erhöht die Produktivität des Programmierers dadurch, daß ihm die Last des Bestimmens effizienter Zugriffswege abgenommen und das Schreiben und das Lesen des Codes erleichtert wird.
OQL[C&spplus;&spplus;] ist minimal datenmodellabhängig. Dies wird dadurch erreicht, daß, anstatt ein neues proprietäres Datenmodell ganz von vorn zu definieren, nur die Kenntnis des Typsystems der gegebenen Host-Sprache (in diesem Fall C&spplus;&spplus;) als ein Datenmodell vorausgesetzt wird. OQL[C&spplus;&spplus;] wendet die objektorientierten Datenmodellierungskonzepte und die Semantik von C&spplus;&spplus; einschließlich der Konzepte des Objekts, der Klasse, des Datenelements, der Elementfunktion, der Vererbung, der Zusammensetzung von Klassendefinitionen und der Nachrichtenabfertigung an, die zusammen einen Kern von in den meisten objektorientierten Datenmodellen zu findenden Konzepten bereitstellen. OQL[C&spplus;&spplus;] erweitert C&spplus;&spplus; durch Abfragen und Gruppen. Die in OQL[C&spplus;&spplus;] erreichte Gleichförmigkeit der Typsysteme der Host- und der Abfragesprache behält die strenge Typisierung an der Abfrageschnittstelle bei, was die Datenbankprogrammierung wesentlich erleichtert und zuverlässiger als herkömmliche Datenbanken macht.
OQL[C&spplus;&spplus;] ist besonders nützlich für CA*-Werkzeuge und -Anwendungsentwickler (z. B. für CAD-, CAM-, CASE-Werkzeuge und -Anwendungsentwickler). Eine Hauptanforderung dieser Anwendungen ist die Bereitstellung von Datenbankvorzügen (d. h. Dauerhaftigkeit, Wiedergewinnung, Gleichzeitigkeitssteuerung und Abfragen) in einer transparenten (nahtlosen) Weise in den Programmierumgebungen. Die vorliegende Erfindung erreicht diese verringerte Leistungsfehlanpassung zwischen der Abfrage- und der Host-Sprache dadurch, daß sie von der Programmiersprache C&spplus;&spplus; ausgeht. Die Dauerhaftigkeit, Wiedergewinnung und Gleichzeitigkeitssteuerung wurden zu C&spplus;&spplus; hinzugefügt, ohne einen neuen Kompilierer zu erfordern. Hierauf wurde eine Abfragefähigkeit hinzugefügt, die eine Sprache enthält, die Merkmale von SQL und von einigen seiner vorgeschlagenen Abwandlungen mit der Syntax der Host-Sprache (C&spplus;&spplus;) vermischt.
Die vorliegende Erfindung erzielt eine Datenabstraktion. Eines der wichtigsten Konzepte des objektorientierten Zugangs zur Softwareentwicklung ist die Datenabstraktion, bei der die Da tendarstellung eines Objekts gegenüber der Anwendung verborgen wird und alle Wechselwirkungen mit den Objekten über die öffentliche Schnittstelle des Objekts ausgeführt werden. Die vorliegende Erfindung erzielt auf diese Weise eine Datenabstraktion, wobei sie die Anwendungen datenunabhängig (d. h. invariant gegenüber Änderungen in der Darstellung der Objekte) macht. Somit wird die Datenunabhängigkeit, einer der Hauptvorteile relationaler Datenbanksysteme, in OQL[C&spplus;&spplus;] beibehalten. Die Datenabstraktion wird in der vorliegenden Erfindung dadurch erzwungen, daß gefordert wird, daß alle Abfrageprädikate bezüglich der öffentlichen Schnittstelle des Objekts formuliert werden. Es wird angemerkt, daß das Prinzip der Datenabstraktion streng nur vom Standpunkt des Anwenders oder der Anwendung erzwungen wird, wobei auf diese Weise die Option, daß interne Module von OQL[C&spplus;&spplus;] (z. B. Abfrageoptimierer) Zugriff auf die Darstellung des Objekts haben, offengelassen wird.
Die Unterstützung von Gruppen in einem OODB-System kann implizit oder explizit sein. Die implizite Unterstützung bedeutet, daß die Gruppen der Objekte implizit als Teil eines Programmiersprachenkonstrukts (z. B. einer Klasse) gesammelt werden. Wenn z. B. in einem relationalen System Tupel (die Objekte des Systems) erzeugt werden, werden sie implizit zu einer entsprechenden Gruppe hinzugefügt (d. h. eine Relation). Andererseits werden explizite Gruppen durch einen Anwender erklärt und unterhalten. Die vorliegende Erfindung unterstützt explizite, durch Anwender unterhaltene Gruppen, ist aber nicht auf die Behandlung allein expliziter Gruppen beschränkt.
Es soll eine Beispielklasse Patient betrachtet werden, die Informationen über Patienten in einem Krankenhaus definiert. Zusätzlich zur Gruppe aller Patienten in dem Krankenhaus kann es zweckmäßig sein, die Erklärung spezieller Gruppen von Patienten wie etwa der Laborpatienten oder der Kinderpatienten zu ermöglichen. Da nicht erwünscht ist, daß Anwendungen gezwungen werden, den Aufwand zum Unterhalten impliziter Gruppen für Klassen aufzubringen, die möglicherweise nicht abgefragt werden, werden Gruppen von Objekten in OQL[C&spplus;&spplus;] explizit durch den Anwender erklärt und unterhalten.
In herkömmlichen (z. B. relationalen) Datenbank-Managementsystemen und in allen momentanen objektorientierten Datenbank- Managementsystemen werden Abfragen ausschließlich an dauerhaften Gruppen ausgeführt. In CA*-Umgebungen und -Anwendungen wird eine große Gruppe von Übergangsdaten erzeugt, für die ein gruppenorientierter Abfragezugriff wesentlich ist. OQL[C&spplus;&spplus;] bietet ebenfalls die Vorteile eines assoziativen Zugriffs auf Übergangsgruppen von Objekten. Da die vorliegende Erfindung eine Erweiterung von C&spplus;&spplus; ist, können Übergangsgruppen, d. h. Gruppen, deren Lebensdauer ein einzelner Programmaufruf ist, definiert und abgefragt werden. Tabelle 4: Grammatik der Gruppenerklärungsanweisungen.
Gruppen werden unter Verwendung der DECLARE- bzw. der IMPLEMENT-Anweisung erklärt und definiert. Gemäß der bevorzugten Ausführungsform sind OQL[C&spplus;&spplus;]-Gruppen unter Verwendung der Anweisung DECLARE OQL_SET < class-name> , wobei DECLARE ein Schlüsselwort ist, das der Vorkompilierer versteht, und wobei class-name der Name einer zuvor erklärten Klasse ist, erklärte parametrisierte Gruppen. Die Syntax der Gruppenerklärung ist in Tabelle 4 gezeigt. In der derzeitigen Ausführung kann eine solche (Übergangs- oder dauerhafte) Gruppe nur auf Klassen, nicht auf Grundtypen (Ganzzahl oder Zeichenstring) erklärt werden.
Die DECLARE-Anweisung bewirkt, daß der Vorkompilierer den zum Erklären einer OQL[C&spplus;&spplus;]-Gruppenklasse erforderlichen C&spplus;&spplus;-Code erzeugt. Der im Ergebnis der DECLARE-Anweisung erzeugte Code wird durch das Codefragment 40 aus Tabelle 5 erläutert. Die öffentliche Schnittstelle der Gruppenklasse umfaßt Elementfunktionen zum Bevölkern der Gruppe (Block 44), zum Iterieren über die Elemente der Gruppe (Block 46), zum Ausführen von Mengenoperationen (Block 48) sowie Elementfunktionen zum Unterhalten von Indizes in der Gruppe (Block 50). Das Iteratordatenelement der OQL[C&spplus;&spplus;]-Gruppe wird verwendet, um getrennte gleichzeitige Iterationsanforderungen an eine Gruppe zu verfolgen. Ein solcher Iterator wird gewöhnlich durch eine Iterator-Id identifiziert. Tabelle 5
Die Anweisung IMPLEMENT OQL_SET < class-name> erweitert die Definition der Elementfunktionen einer Gruppe auf geeigneten C&spplus;&spplus;- Code, der die beabsichtigten Funktionen ausführt.
Während der OQL-Vorverarbeitungsphase 144 (Fig. 5) werden DECLARE- und IMPLEMENT-Anweisungen erkannt und in C&spplus;&spplus;- oder dauerhaften C&spplus;&spplus;-Code, der die Erklärung und Realisierung der OQL-Gruppen beschreibt, umgewandelt. Außerdem werden während dieser Vorverarbeitungsphase OQL-Abfrageanweisungen identifiziert, analysiert, optimiert und in effizienten C&spplus;&spplus;- oder (in Abhängigkeit davon, ob die Gruppe eine dauerhafte Gruppe ist) in dauerhaften C&spplus;&spplus;-Code, der die Abfrage berechnet, übersetzt (Block 100, Fig. 4). Das resultierende Programm wird dann durch den C&spplus;&spplus;-Kompilierer 152 kompiliert (Fig. 5).
Die folgenden Beispiele beruhen auf dem in Fig. 3 gezeigten Schema, das klinische Beispielinformationen über Patienten in einem Krankenhaus darstellt. Die Namen in dem Graphen stellen Klassen dar. Die durch eine durchgezogene Linie verbundenen Klassen stellen eine Zusammensetzung dar. Die Vererbung zwischen Klassen wird durch Strichlinien dargestellt.
Die Struktur einer OQL-Abfrage ist:
SELECT < objects>
FROM < range variable> IN < set>
WHERE < predicate> ;
Die Syntax der vorliegenden Erfindung entleiht das SFW-Paradigma von SQL in einer aufwärtskompatiblen Weise und verbessert es auf mehrfache Weise. Die SELECT-Klausel identifiziert die Objekte, die die Antwortgruppe (d. h. das Ergebnis der Abfrage) bevölkern. Weiteres über die Art der Objekte, die in der SELECT-Klausel spezifiziert werden können, wird unten diskutiert. Die FROM-Klausel spezifiziert mittels einer Bereichsva riablen die Art der Objekte in der Zielgruppe, der Gruppe, die abgefragt wird. Schließlich spezifiziert die WHERE-Klausel das Prädikat, das die durch die Objekte im Ergebnis zu erfüllenden Eigenschaften definiert.

Beispiel 1. Gewinne die bei Aetna versicherten Patienten wieder.

SELECT p
FROM Patient *p IN Patient_Set
WHERE p-> get_insurance()-> company = = "Aetna"
In diesem Beispiel ist p eine Bereichsvariable eines Typzeigers auf einen Patienten in der Klasse Patient 62, die in der FROM- Klausel erklärt wird. Die Verwendung von p in der SELECT- Klausel zeigt, daß die Antwortgruppe aus einer Gruppe von Zeigern auf Patienten 62 besteht. Die Verwendung eingegebener Bereichsvariablen erleichtert die Typprüfung zur Kompilierungszeit und die Fähigkeit zum Formulieren von Prädikaten in einer C&spplus;&spplus;-ähnlichen Syntax.
Wie das Krankenhausschema nach Fig. 3 zeigt, ist Patient Set 62 eine OQL-(Ziel-)Gruppe, die Objekte vom Typ Patient 90 enthält. Es ist möglich, irgendeinen mengenwertigen Ausdruck (z. B. eine Variable oder eine Anwenderfunktion) als eine Zielgruppe in der FROM-Klausel zu spezifizieren. Weitere in Fig. 3 (und in Tabelle 6) definierte Klassen sind Name 80, Birthdate 82, Insurance 84, Person 86, Physician 88 und Patient 90. Tabelle 6
Der String p-> get_insurance()-> company heißt ein Wegausdruck und ermöglicht die Formulierung von Prädikaten auf tief in der Struktur eines Objekts verschachtelten Werten. Falls t eine Bereichsvariable vom Typ T(T *) ist, gilt: (a)t und t.m()(t-> m()) sind Wegausdrücke, wobei m eine Elementfunktion der Klasse T ist; und (b) falls p ein Wegausdruck ist, ist p.m()(p-> m()) ein Wegausdruck. Die Funktion m ist ein Element der Klasse T oder ihrer Vorgänger. Es kann einwertige oder mehrwertige Wegausdrücke geben. Die Wichtigkeit dieser Unterscheidung wird unten beschrieben.
Die Verwendung von Wegausdrücken und die Erklärung eingegebener Bereichsvariablen sind zwei in SQL nicht verfügbare Merkmale der vorliegenden Erfindung.
Alle Prädikate in der WHERE-Klausel werden bezüglich der öffentlichen Schnittstelle des Objekts ausgedrückt, d. h., daß in privaten Datenelementen oder Funktionen keine Prädikate zulässig sind. Momentan liegt es in der Verantwortung des Anwenders sicherzustellen, daß die Elementfunktionen in Prädikaten nebenwirkungsfrei sind, d. h., daß ihr Aufruf den Zustand irgendeines Objekts in der Datenbank nicht ändert.
Alternativ hätte die Bereichsvariable vom Typ Patient 90 erklärt werden können, wobei die Abfrage in diesem Fall als:
SELECT p
FROM Patient p IN Patient_Set
WHERE p.Insurance()-> company = = "Aetna";
geschrieben würde.
In beiden Formen dieser Abfrage geben die Ausdrücke p.Insurance() und p-> Insurance() einen Zeiger an eine Versicherungsstruktur 84 zurück. Somit muß in beiden Fällen unter Verwendung der Pfeilschreibweise auf den Namen der Gesellschaft Bezug genommen werden. Es wird angemerkt, daß die Pfeilschreibweise direkt von C&spplus;&spplus; her kommt und nicht Bestandteil von OQL ist; OQL[CLOS] würde zur Bezugnahme auf Instanzvariablen und - verfahren die Lisp-Syntax und die CLOS-Semantik verwenden.
Der Zweck der SELECT-Klausel besteht im Erklären des Typs der einzelnen Objekte, die die Antwortgruppe bilden. Beispiel 2 zeigt eine andere Verwendung der SELECT-Klausel.

Beispiel 2. Wiedergewinnen der bei Aetna versicherten Patienten als eine Gruppe von Personen.

SELECT Person *x = p
FROM Patient *p IN Patient_Set
WHERE p-> Insurance()-> company = = "Aetna";
Dieses Beispiel zeigt, wie das Prinzip der Ersetzbarkeit (d. h. einer Programmvariablen eines Typs kann irgendein Objekt von einem abgeleiteten Typ zugewiesen werden) gemäß der vorliegenden Erfindung in einer OQL-Abfrage angewendet werden kann. In einer OQL-Abfrage kann die Antwortgruppe Elemente enthalten, deren Typ der gleiche wie der Typ der Elemente in der Zielgruppe sowie der irgendeiner ihrer Vorgänger ist. In diesem Beispiel ist Person 60 (Fig. 3)/86 (Tabelle 7) ein Vorgänger von Patient 62 (Fig. 3)/90 (Tabelle 7). Der Variablen x vom Typ Zeiger auf Person 60/86 wird ein Zeiger auf Patient 62/90 zugewiesen. Es wird angemerkt, daß die Objektidentität der Elemente in der Zielgruppe in der Antwortgruppe bewahrt wird. Jedoch hat das Objekt der Antwortgruppe bei jeder Ausführung der Abfrage eine neue Identität. Tabelle 7
Eine Abfrage gemäß der vorliegenden Erfindung kann außerdem Objekte eines nicht mit der Klassenhierarchie des Typs der Objekte in der Zielgruppe verwandten Typs zurückgeben. Dies ist in Beispiel 3 gezeigt. Beispiel 3. Gewinne die Namen und das Alter der höchstens 10 Jahre alten Patienten wieder.
Diese Abfrage zeigt eine Verwendung des C&spplus;&spplus;-Konstrukteurs zum Erzeugen einer Gruppe von Objekten eines neuen Typs unter der Voraussetzung, daß der neue Typ zuvor definiert wurde. Die durch diese Abfrage zurückgegebenen Objekte besitzen eine neue Identität. Die Abfrage zeigt außerdem die Verwendung der Vererbung. Die in dem Konstrukteur und in dem Prädikat der WHERE- Klausel verwendeten Wegausdrücke p-> get_name() und p-> get_age() beziehen sich auf Elementfunktionen, die durch die Objekte der Klasse Patient von der Vorgängerklasse Person vererbt wurden.
Es wird angemerkt, daß die Vererbung der Elementfunktionen in der OQL[C&spplus;&spplus;] ohne Aufwand angeboten wird, da sie das C&spplus;&spplus;- Typsystem enthält.
Obgleich sie in C&spplus;&spplus; nicht unterstützt werden, sind in OQL weitere Formen der Vererbung (z. B. die Mengeninklusion) möglich. Vorausgesetzt, daß Patient 62 und Employee 64 von der Klasse Person 60 abgeleitete Klassen sind, wäre z. B. in Fig. 3 zu erwarten, daß in diesen Klassen definierte Gruppen die Semantik Mengeninklusion tragen. Die Semantik Mengeninklusion bedeutet, daß irgendeine Instanz des Typs Patient oder Employee, die ein Element der Gruppe der Patienten 62 bzw. der Gruppe der Angestellten 64 ist, automatisch eine Instanz der Gruppe der Personen 60 wird. Dies ermöglicht das Ausführen von Abfragen auf der Gruppe der Personen 60 nicht nur in den ursprünglich als Personen erzeugten Instanzen, sondern auch auf Instanzen von Patienten und von Angestellten.
Bisher waren alle in den Abfragen der Beispiele 1-3 verwendeten Wegausdrücke einwertig. Beispiel 4 zeigt einen Fall, in dem ein Wegausdruck mehrwertig ist. Beispiel 4. Gewinne die Patienten von Dr. Smith, bei denen vor dem 10. Oktober 1989 Grippe diagnostiziert wurde, wieder.
Da der Wegausdruck p-> get_med_record() mehrwertig ist (d. h., da die Funktion get_med_rec() der Patienten eine Gruppe von medizinischen Datensatzobjekten 68 zurückgibt) muß eine Variable r definiert werden, die über die Elemente dieser Gruppe reicht. Dies führt zur Verwendung verschachtelter Unterabfragen in einer OQL-Anweisung. Die Forderung, für Abfragen mit mengenwertigen Wegausdrücken eine explizite Bereichsvariable zu verwenden, anstatt OQL diese implizit definieren zu lassen, liefert eine klarere Semantik und eine einfachere Realisierung der vorliegenden Erfindung.
Die Berechnung des Prädikats EXISTS < set> ergibt jedesmal wahr, wenn < set> nicht leer ist. Dies ist kompatibel mit dem entspre chenden Prädikat in SQL. Die Prädikate in der WHERE-Klausel können die Vergleichsoperatoren θ {= = , < , < =, > , > = ! =} und die logischen Operatoren && (AND), (OR) und NOT verwenden. Für den Vergleich und für logische Operationen wird die C&spplus;&spplus;- Syntax verwendet. Gültige atomare Ausdrücke sind: t&sub1; θ t&sub2;, t&sub1; θ c, t&sub1; IN s&sub1;, s&sub1; CONTAINS s&sub2;, v θ ALL s&sub1;, v θ ANY s&sub1; und EXISTS s&sub1;; wobei t&sub1; und t&sub2; einwertige Wegausdrücke, s&sub1; und s&sub2; Gruppen, v ein einwertiger Wegausdruck oder eine Konstante, c eine Konstante (Ganzzahl oder String) und θ ein Vergleichsoperator sind. Die atomaren Terme, die ANY und ALL umfassen, werden zur existentiellen bzw. universellen Quantisierung verwendet. Ein Prädikat ist eine Boolesche Kombination atomarer Terme.
Vom Standpunkt des Anwenders wird in der vorliegenden Erfindung offensichtlich sowohl auf vererbte Elementfunktionen als auch auf zusammengesetzte Objekte einheitlich durch einen einzigen Syntaxmechanismus (d. h. durch den Wegausdruck) Bezug genommen. Beispiel 5. Gewinne alle Kinderärzte und ihre bei Aetna versicherten Patienten wieder.
Diese Abfrage zeigt das Prinzip der Orthogonalität in OQL selbst. Eine SELECT-Anweisung kann überall, wo eine Gruppe erwartet wird, in diesem Fall in dem Konstrukteur eines Objekts New_Patient, verwendet werden.
Der Gültigkeitsbereich einer Bereichsvariable ist die gesamte mit der FROM-Klausel, die sie definiert, verknüpfte Auswahlanweisung. Dies ermöglicht, die in der äußeren SELECT-Anweisung erklärte Variable p in der inneren SELECT-Anweisung zu verwenden. Im Gegensatz dazu kann die in der inneren Auswahl erklärte Variable pat in der äußeren Auswahl nicht verwendet werden. Dies ist genau mit den ANSI-SQL-Gültigkeitsbereichs-Vorschriften konsistent. Beispiel 6. Gewinne die Patienten mit einer Röntgenstrahluntersuchung wieder, deren Röntgenbild zu einer Lungentuberkulose paßt.
Die Abfrage nach Beispiel 6 zeigt die Verwendung von mengenwertigen, anwenderdefinierten Funktionen in einer OQL-Anweisung. Es wird angenommen, daß jeder medizinische Datensatz eines Patienten eine heterogene Liste von Laboruntersuchungen (z. B. Röntgenstrahluntersuchungen 74, Ultraschalluntersuchungen 78, Blutproben 76 nach Fig. 3) enthält. Um eine Abfrage in einer Gruppe von Röntgenstrahluntersuchungen 74 auszuführen, müssen zunächst die Röntgenstrahluntersuchungs-Objekte aus der Liste der Laboruntersuchungsberichte 74 entnommen werden (was oben durch f ausgeführt wird) und muß dann aus der Liste eine Gruppe erzeugt werden (was durch die obige Funktion Make_set ausgeführt wird). Dies ist erforderlich, da OQL nur Gruppen homogener Objekte abfragen kann. Die anwenderdefinierte (Boolesche) Funktion x_ray_match vergleicht das Bitmuster r- > picture() einer Röntgenstrahluntersuchung mit einer Programmvariablen vom Typ Bitmap, die ein typisches Tuberkulose-Röntgenbild hält.
Die Datenabstraktion ermöglicht das Formulieren von OQL[C&spplus;&spplus;]- Abfragen an zusammengesetzten Objekten unter Verwendung eines einheitlichen Mechanismus (d. h. von Wegausdrücken) ohne Rücksicht auf die realisierte Wegzusammensetzung. Dies ist in Beispiel 7 gezeigt. Beispiel 7. Gewinne die Patienten wieder, die weniger als 19 Jahre alt sind und durch Ärzte behandelt werden, die für in Dallas liegende Krankenhäuser arbeiten.
In Abhängigkeit von dar Art, in der die zusammengesetzten Beziehungen realisiert sind, erfordern andere Abfragesprachen, die keine Datenabstraktion unterstützen, für die Abfragen an zusammengesetzten Objekten andere Formulierungen. Wie unten gezeigt wird, ist in diesen Sprachen zum Ausdrücken der obigen Abfrage eine explizite Verbindung mit durch eine verschachtelte Abfrage zurückgegebenen Objekten erforderlich.
Die Anweisungen 2 und 3 aus Tabelle 8 zeigen, wie gemäß der vorliegenden Erfindung eine Gruppe von Patienten zu erklären und zu definieren ist. Die Anweisung 6 erklärt zwei Programmvariable mypatients und result des Typs OQL-Gruppe der Patienten. Die Anweisung 8 zeigt, wie die Gruppen unter Verwendung der add-Elementfunktion bevölkert werden. Die Anweisungen 10-12 zeigen, wie über alle einzelnen Elemente einer Gruppe zu iterieren ist. Die Anweisung 14 zeigt die Abfrage nach Beispiel 6 in der Gruppe mypatients. Es wird die Verwendung der anwenderdefinierten Funktionen als Teil des Programms vermerkt. Die Anweisungen 16-19 stellen Code dar, der die Funktionen f und Make_set definiert. Tabelle 8
Als Hilfe bei der Realisierung der bevorzugten Ausführungsform der vorliegenden Erfindung folgt die Grammatik von OQL[C&spplus;&spplus;].
Der in OQL verwendete Ansatz zur Schaffung einer besseren Integration mit den Host-Sprachen kann auch durch die momentanen SQL-Systeme verwendet werden, um eine bessere Integration mit objektorientierten Programmiersprachen zu schaffen.
Die Erfindung schafft eine geschickte Art der Kombination der am meisten verwendeten industriell wirksamen objektorientierten Programmiersprache der Computerindustrie, C&spplus;&spplus;, mit der Industriestandard-Datenbankabfragesprache SQL. Die Erfindung ergänzt die existierenden Programmierwerkzeuge eines C&spplus;&spplus;- Programmierers durch Hinzufügen einer Abfragefähigkeit. Dies kann zu einem besseren, zuverlässigeren C&spplus;&spplus;-Code führen und die Datenbankprogrammierung für die große Anzahl der C&spplus;&spplus; Programmierer zugänglicher machen.
Die Abfrageprozessorarchitektur der OQL 100 ist in Fig. 4 gezeigt. Sie besteht aus vier Hauptmodulen: dem Analysierer 102, dem Abfrageneuschreiber 104, dem vorschriftsbasierten Abfrageübersetzer und Optimierer 106 und dem Codeoptimierer 108. Alle diese Module verwenden das Laufzeit-Datenwörterbuch 112, das alle Typinformationen der Anwendung einschließlich der in den Anwendungen verwendeten Klasseninformationen (Klassennamen, Datenelementnamen und -typen und Elementfunktionsnamentypen und -parameter), Klassenhierarchieinformationen und der mengenwertigen und Booleschen Variablen und Funktionen enthält. Der Abfrageprozessor verwendet die SELECT-Anweisungen 124 von OQL[C&spplus;&spplus;] als Eingangsgröße und erzeugt als Ausgangsgröße optimierten C&spplus;&spplus;- oder dauerhaften C&spplus;&spplus;-Code 126. In Fig. 4 stellen die hell schraffierten Kästen Laufzeit-Datenstrukturen, die dunkleren Kästen Vorschriftsgrundlagen, die die Module verbindenden Pfeile die Übertragung der Steuerung und die durchgezogenen Linien den Zugriff auf Datenstrukturen von den entsprechenden Modulen dar. Der Analysierer 102 verwendet die OQL[C&spplus;&spplus;]-SELECT-Anweisung als Eingangsgröße und prüft mit Hilfe des Datenwörterbuchs die Syntax der Anweisung und ob die Bezugnahmen auf Klasseninformationen und anwenderdefinierte Funktionen gültig sind. An syntaktisch falsche Anweisungen werden Syntaxfehler 122 ausgegeben, während syntaktisch richtige Anweisungen auf einen Abfragegraphen 116 abgebildet werden. Nach dem Analysieren wird die Steuerung an das Abfrageneuschreibmodul 104 übergeben, das den Abfragegraphen 116 liest und ihn nach dem Ausführen der semantischen und algebraischen Abfrageopti mierung mit Hilfe des Datenwörterbuchs 112 bzw. der algebraischen Vorschriftsgrundlage 110 an seiner Stelle transformiert. Nach dem Neuschreiben der Abfrage wird die Steuerung an den vorschriftsbasierten Abfrageübersetzer 106 übergeben, der den Abfragegraphen mit Hilfe der Ablageschnittstellen-Vorschriftsgrundlage 118 und des Datenwörterbuchs 112 in eine in C&spplus;&spplus; oder in dauerhaftem C&spplus;&spplus; geschriebene erste Version eines Ausführungsplans 114 übersetzt. Schließlich erzeugt der Codeoptimierer 108 eine verbesserte Folge von der ursprünglichen Abfrage 124 entsprechenden C&spplus;&spplus;- und dauerhaften C&spplus;&spplus;-Code-126- Anweisungen.
In Fig. 5 ist das vollständige Kompilierungsverfahren 140 eines Programms, das OQL[C&spplus;&spplus;]-Anweisungen (d. h. DECLARE-, IMPLEMENT- und SELECT-Anweisungen) enthält, gezeigt. Die Eingangsgröße zu dem Kompilierungsverfahren ist ein Programm, das die OQL[C&spplus;&spplus;]- Anweisungen 142 enthält. Diese Eingangsgröße wird durch den OQL-Vorkompilierer verarbeitet, der für die SELECT-Anweisungen alle in dem Abfrageprozessor 100 (Fig. 4) beschriebenen Funktionen ausführt. Wegen der Möglichkeit, daß ein Programm Übergangsdaten und dauerhafte Daten abfragen kann, erzeugt der OQL- Vorkompilierer eine Kombination aus C&spplus;&spplus;- und dauerhaftem C&spplus;&spplus;- Code 146. Ein Vorkompilierer 148 für dauerhaftes C&spplus;&spplus; transformiert den dauerhaften C&spplus;&spplus;-Code in reinen C&spplus;&spplus;-Code 150, während der C&spplus;&spplus;-Code diesen Prozeß unverändert durchläuft. Der C&spplus;&spplus;-Code 150 wird dann durch einen Standard-C&spplus;&spplus;-Kompilierer 152 verarbeitet, der den ausführbaren Code 154 erzeugt.
Fig. 6 zeigt eine mögliche Anordnung eines Anwendungscodes 164 gemäß einer bevorzugten Ausführungsform der Erfindung, der OQL[C&spplus;&spplus;]-Abfrageanweisungen 166 enthält, im Hauptspeicher 162 eines Computers 160. Während der Entwicklung der Anwendung gibt ein Computerprogrammierer ein Programm über ein Computerterminal 180 in den Computer 160 ein. Die Anwendung wird gemäß dem in Fig. 5 beschriebenen Verfahren kompiliert, wobei die OQL[C&spplus;&spplus;]-Anweisungen 142 (Fig. 5)/166 (Fig. 6) in Abhängigkeit davon, ob die Abfragen auf Übergangsdaten 170 oder auf dauerhafte Daten 172 zugreifen, in reinen C&spplus;&spplus;-Code 168 oder in dauerhaften C&spplus;&spplus;-Code 178 übersetzt werden. Die dauerhaften Daten 172 werden in einer dauerhaften Datenbank 176 auf der Platte 174 gespeichert. Abfragen an Übergangsdaten werden unter Verwendung des C&spplus;&spplus;-Codes 168 im Hauptspeicher 170 ausgeführt. Abfragen an dauerhaften Daten werden unter Verwendung des dauerhaften C&spplus;&spplus;-Codes 178 ausgeführt, der die Übertragung der dauerhaften Daten von der Datenbank 176 auf der Platte 174 in einen Spezialbereich 172 des Hauptspeichers 162, wo die Abfrage ausgeführt wird, sicherstellt. Es wird angemerkt, daß, obgleich der Anwendungscode 164, der OQL[C&spplus;&spplus;]-Code 166, der C&spplus;&spplus;-Code 168 und der dauerhafte C&spplus;&spplus;-Code 178 vor der Kompilierung unterscheidbar sind, nach der Kompilierung ein einzelnes, ununterscheidbares Stück Ausführungscode bilden.
Die Beschreibung des durch einen C&spplus;&spplus;-Vorkompilierer realisierten OQL[C&spplus;&spplus;] ist spezifisch für die realisierte Ausführung. Falls natürliche (nicht durch Vorkompilierer realisierte) C&spplus;&spplus;- Kompilierer für die Verwendung von OQL erweitert würden, würden durch diese Kompilierer ähnliche Operationen realisiert. Falls inkrementelle C&spplus;&spplus;-Kompilierer verfügbar werden, kann OQL[C&spplus;&spplus;] in der Tat ähnlich inkrementell werden, wobei es dennoch die interaktive "ad hoc"-Fähigkeit zum Formulieren von Abfragen erbt. Da CLOS ein inkrementelles Kompilieren ermöglicht, würde dieses Merkmal bei der Anwendung gemäß der vorliegenden Erfindung sofort in OQL[CLOS] geerbt.

Merkmale der bevorzugten Ausführungsform

Unten werden verschiedene wichtige Merkmale einer bevorzugten Ausführungsform zusammengefaßt.
Eine Vorrichtung zum Verarbeiten von Abfragen in einer objektorientierten Datenbank mit Vorkompiliereranalyse-, Optimierungs- und Übersetzungs-Objektabfrage-Sprachen-Anweisungen in effiziente Host-Sprachen-Anweisungen und ein an den Vorkompilierer angeschlossener Kompilierer zum Kompilieren der effizienten Host-Sprachen-Anweisungen zu ausführbarem Code. Für eine solche Vorrichtung kann die Host-Sprache C&spplus;&spplus; oder Gemeinsames- Lisp-Objektsystem (CLOS) sein. Außerdem kann der Kompilierer ein C&spplus;&spplus;-Kompilierer sein.
Eine Vorrichtung zum Verarbeiten von Abfragen in einer objektorientierten Datenbank mit einem Vorkompilierer zum Analysieren, Optimieren und Übersetzen durch den Anwender erzeugter OQL[C&spplus;&spplus;]-Anweisungen in effiziente C&spplus;&spplus;-Anweisungen und ein an den Vorkompilierer angeschlossener Kompilierer zum Kompilieren der effizienten C&spplus;&spplus;-Anweisungen in ausführbaren Code.
Ein Verfahren zum Ausführen einer Abfrage in einer Objektabfragesprache, das die folgenden Schritte enthält: Definieren der Objektabfragesprache mit Gruppenerklärungen, Formulieren der Abfrageanweisungen durch Kombinieren des Typsystems der Host-Sprache als ein Datenmodell mit ausgewählten Aspekten einer relationalen Abfragesprache als eine Grundstruktur für die Abfrageanweisungen, Vorverarbeiten der Abfrageanweisungen, Kompilieren der Abfrageanweisungen und Ausführen der Abfrageanweisungen, um eine Antwort an die formulierte Abfrageanweisung zurückzugeben. Die Gruppenerklärungen dieses Verfahrens können wenigstens eine Elementfunktion, wenigstens eine Mengenoperation, wenigstens einen Iterationsoperator und wenigstens eine Indexierungsfunktion enthalten. Der Schritt des Formulierens der Abfrageanweisungen kann ferner das Kombinieren von Booleschen Host-Sprache-Funktionen mit wenigstens einem Prädikat oder das Verwenden mengenwertiger Funktionen der Host- Sprache als Ziele für die Abfragen umfassen. Dieser Schritt kann außerdem den Schritt des Verwendens der Ausdrücke und der Objektzusammensetzung der Host-Sprache bei der Formulierung der Abfrageanweisungen umfassen. Die relationale Abfragesprache ist SQL, während die im voraus gewählten Aspekte der Wahl-von-wo- Stil (Select-From-Where-Stil) von SQL sind. Der Schritt des Vorverarbeitens umfaßt ferner die folgenden Schritte: Analysieren der Abfrageanweisungen, Optimieren der Abfrageanweisungen und Übersetzen der Abfrageanweisungen in Anweisungen, die durch einen Host-Sprache-Kompilierer kompiliert werden können.
Obwohl oben in der Patentanmeldung eine bestimmte Ausführungsform der Erfindung gezeigt und beschrieben wurde, sind für den Fachmann auf dem Gebiet verschiedene Modifikationen und alternative Ausführungen ersichtlich. Die Erfindung soll dementsprechend nur bezüglich der beigefügten Ansprüche beschränkt sein.

Claims

1. Verfahren zum Ausführen von Abfragen von Objektengruppen in einem Computer, wobei die Abfragen in Abfrageanweisungen eines Programms explizit spezifiziert sind, dadurch gekennzeichnet, daß

das Programm Anweisungen einer objektorientierten Host- Programmiersprache und Erweiterungssprachen-Anweisungen, die wenigstens die Abfrageanweisungen enthalten, umfaßt und daß die Abfrageanweisungen der Abfrage von Mengen von Objekten der Host-Programmiersprache dienen,

daß das Verfahren die Vorverarbeitung des Programms enthält und daß die Vorverarbeitung das Umsetzen wenigstens der Erweiterungssprachen-Abfrageanweisungen in Anweisungen der objektorientierten Host-Programmiersprache enthält,

und daß das Verfahren ferner enthält:

Kompilieren (152) des resultierenden Programms in der Host-Sprache in ausführbaren Code (154) und

Ausführen des resultierenden ausführbaren Codes (154), wobei der Code ausgeführt wird, um das Ergebnis der Abfrageanweisungen zurückzugeben.

2. Verfahren nach Anspruch 1, bei dem die Abfragen, die in den Abfrageanweisungen der Erweiterungssprache spezifiziert sind, Objekte der Host-Programmiersprache zurückgeben.

3. Verfahren nach Anspruch 2, bei dem die Erweiterungssprache-Abfrageanweisungen wenigstens ein Objekt eines Typs zurückgeben, das ein Vorgänger des Typs abgefragter Objekte ist.

4. Verfahren nach irgendeinem der vorangehenden Ansprüche, bei dem die Objekte, die von der Abfrage abgefragt werden, dauerhafte Objekte enthalten.

5. Verfahren nach irgendeinem der vorangehenden Ansprüche, bei dem die Objekte, die von der Abfrage abgefragt werden, Übergangsobjekte enthalten.

6. Verfahren nach irgendeinem der vorangehenden Ansprüche, bei dem die Gruppen von Objekten selbst erklärte Objekte sind.

7. Verfahren nach Anspruch 6, bei dem die Erklärung der erklärten Objekte wenigstens eine Mitgliedsfunktion umfaßt.

8. Verfahren nach Anspruch 6 oder Anspruch 7, bei dem die Erklärung wenigstens eine Mengenoperation enthält.

9. Verfahren nach irgendeinem der Ansprüche 6 bis 8, bei dem die Erklärung wenigstens eine Iterationsoperation enthält.

10. Verfahren nach irgendeinem der Ansprüche 6 bis 9, bei dem die Erklärung wenigstens eine Indexierungsfunktion enthält.

11. Verfahren nach irgendeinem vorangehenden Anspruch, bei dem die Abfrage eine Booleschen Funktion der Host-Sprache als ihr Prädikat enthält.

12. Verfahren nach irgendeinem vorangehenden Anspruch, bei dem die abgefragten Gruppen jene sind, die durch gruppenwertige Funktionen der Host-Sprache zurückgegeben werden.

13. Verfahren nach irgendeinem vorangehenden Anspruch, bei dem die Abfrageanweisungen den Stil von SQL (structured query language) besitzen.

14. Verfahren nach Anspruch 13, bei dem die Abfragen den Wahlvon-wo-Stil von SQL (structured query language) besitzen.

15. Verfahren nach irgendeinem vorangehenden Anspruch, bei dem die Abfrageanweisungen Ausdrücke der Host-Sprache und die Objektzusammensetzung verwenden.

16. Verfahren nach irgendeinem vorangehenden Anspruch, bei dem der Schritt der Vorverarbeitung ferner die folgenden Schritte enthält:

Analysieren der Abfrageanweisungen;

Optimieren der Abfrageanweisungen; und

Übersetzen der Abfrageanweisungen in Anweisungen, die durch den Kompilierer für die Host-Sprache kompilierbar sind.

17. Verfahren nach irgendeinem vorangehenden Anspruch, bei dem die Host-Sprache C&spplus;&spplus; ist.

18. Verfahren nach irgendeinem vorangehenden Anspruch, bei dem das vorverarbeitete Programm durch ein Hypermedien/Text-System erzeugt worden ist.

19. Verfahren nach irgendeinem der Ansprüche 1 bis 17, bei dem das vorverarbeitete Programm durch eine graphische Abfrageschnittstelle erzeugt worden ist.

20. Verfahren nach irgendeinem vorangehenden Anspruch, bei dem die Abfrage eingegebene Bereichsvariablen zuläßt.

21. Verfahren nach irgendeinem vorangehenden Anspruch, bei dem verschachtelte Abfrageanweisungen zugelassen sind.

22. Verfahren nach irgendeinem vorangehenden Anspruch, bei dem die Vorverarbeitung über ein Zwischenprogramm (146) erfolgt, wobei Anweisungen des Zwischenprogramms, die mit dauerhaften Objekten in Beziehung stehen, in Anweisungen der Host-Sprache umgesetzt (148) werden.

23. Vorrichtung zum Ausführen von Abfragen von Mengen von Objekten, wobei die Abfragen in Abfrageanweisungen eines Programms explizit spezifiziert sind, dadurch gekennzeichnet, daß

das Programm Anweisungen einer objektorientierten Host- Programmiersprache und Anweisungen einer Erweiterungssprache, die wenigstens die Abfrageanweisungen enthalten, umfaßt und daß die Abfrageanweisungen der Abfrage von Mengen von Objekten der Host-Programmiersprache dienen,

daß die Vorrichtung ein Mittel (144) zum Vorverarbeiten des Programms enthält und daß die Vorverarbeitung das Umsetzen wenigstens der Erweiterungssprachen-Abfrageanweisungen in Anweisungen der objektorientierten Host-Programmiersprache enthält,

und daß die Vorrichtung ferner enthält:

ein Mittel (142) zum Kompilieren des resultierenden Programms in der Host-Sprache in ausführbaren Code (154) und

ein Mittel zum Ausführen des resultierenden ausführbaren Codes, wobei der Code ausgeführt wird, um das Ergebnis der Abfrageanweisungen zurückzugeben.

24. Vorrichtung nach Anspruch 23, ferner mit Mitteln zum Ausführen des Verfahrens, das in einem der Ansprüche 2 bis 22 definiert ist.