<Desc/Clms Page number 1>
Verfahren zur Speicherung persistenter Objekte von objektorientierten Anwenderprogrammen in einer relationalen Datenbank.
Die Erfindung betrifft ein Verfahren zur Speicherung persistenter Objekte von objektorientierten Anwenderprogrammen in einer relationalen Datenbank.
Objektorientierte Programme stützen sich auf Objekte bzw. Objektgeflechte, das sind komplexe vernetzte Datenstrukturen. Der Inhalt mancher dieser Objekte oder Objektgeflechte muss über die Ablaufdauer eines Programms hinaus erhalten bleiben, das zugehörige Objekt oder Objektgeflecht wird dann als "persistent" bezeichnet. Für die Speicherung persistenter Objekte kommen grundsätzlich Dateien-sogenannte flat files-, objektorientierte Datenbanken oder relationale Datenbanken in Frage.
Dateien sind für die Speicherung allerdings nicht in jedem Fall geeignet.
Objektorientierte Datenbanken sind erst seit kurzem auf dem Markt verfügbar und genügen daher den hohen Zuverlässigkeitsvorschriften industrieller Anwendungen nicht. Man verwendet daher üblicherweise relationale Datenbanken, die den Vorteil haben, dass erprobte und zuverlässige Standardprodukte mit für den Betrieb ausreichenden Zugriffseiten vorhanden sind.
Die Zuordnung persistenter Objektstrukturen zu den einfachen Tabellen einer relationalen Datenbank ist jedoch eine komplexe Aufgabe, die aufwendige und kostenintensive Entwicklungen erfordert
<Desc/Clms Page number 2>
Der Erfindung liegt daher die Aufgabe zugrunde, ein Verfahren anzugeben, mit dem auf einfache Weise die Verbindung zwischen beliebigen objektorientierten Anwenderprogrammen und relationalen Datenbanken hergestellt werden kann Dies geschieht erfindungsgemäss mit dem Verfahren nach Anspruch 1.
Mit der erfindungsgemässen Programmlogik werden Zugriffs- und Speichermethoden für die persistenten Objekte der Anwendung bereitgestellt, sodass eine einfache Handhabung durch die Anwenderprogramme gewahrleistet ist.
So werden sämtliche objektmodellabhängigen Methoden für den Zugriff auf die Datenbank automatisch generiert. Durch die Ausnutzung spezieller Eigenschaften von relationalen Datenbanksystemen können auch kurze Datenbankzugriffszeiten gewährleistet werden. Es liegt ein beliebig granulares Sperrkonzept vor ; es können sowohl Einzelobjekte als auch Objektmengen zum Zeitpunkt des Auslesen aus der relationalen Datenbank gesperrt werden.
Sowohl Datenbank-Sessions als auch Datenbank-Transaktionen können logisch geschachtelt werden. Objektmengen können in Blöcken schrittweise aus der Datenbank gelesen werden. Die Blockgrösse kann vorrAnwender definiert werden. Innerhalb von Objektmengen kann beliebig (vorwärts, rückwärts, absolut, first, last) positioniert werden. Die Positionierung kann blockweise oder Objekt für Objekt erfolgen. Das Anwendungsprogramm kann durch Nutzung der vorhandenen Tuningfeatures die Zugriffszeiten auf seine persistenten Objekte beeinflussen.
Die Erfindung wird anhand einer Figur näher erläutert, welche beispielhaft ein Struktogramm der erfindungsgemässen Programmlogik zeigt.
Das dargestellte Ausführungsbeispiel betrifft ein objektonentiertes Computerprogramm zur Verwaltung einer Bibliothek.
Basis eines objektonentlerten Programmes sind Objekte Diesen Objekten konnen sowohl Daten (= Attribute) als auch Operationen (= Methoden)
<Desc/Clms Page number 3>
zugeordnet werden. Weiters können zwischen den Objekten verschiedene Arten von Beziehungen (Vererbung, Points-to-Beziehung, ContainmentBeziehung) bestehen. Die Beschreibung der Objekte inkl. aller ihrer Eigenschaften erfolgt in Form von Klassendefinitionen, eine Klasse ist also die allgemeine Beschreibung eines Objekts.
Im vorliegenden Beispiel können von den Bibliotheksmitgliedern Bücher und CD's ausgeliehen werden. Die Bibliotheksmitglieder werden daher mit ihren für die vorliegende Aufgabe relevanten Eigenschaften In der Objektklasse "Mitglied" erfasst, Bücher und CD's werden hinsichtlich ihrer gemeinsamen Eigenschaften in der abstrakten Superklasse "entlehnbarer Gegenstand"und in den konkreten Blattklassen "Buch"und"CD"erfasst. Die Eigenschaften der Superklasse werden über Vererbung an die Blattklassen weitergegeben.
Die einfachen Attribute der genannten Klassen, welche den Eigenschaften der erfassten Objekte entsprechen, werden in der folgenden Tabelle dargestellt.
EMI3.1
<tb>
<tb>
Mitglied <SEP> Entlehnbarer <SEP> Gegenstand
<tb> Mitgliedsnummer <SEP> Kennung
<tb> Nachname <SEP> Titel
<tb> Vorname <SEP> Herausgeber
<tb> Geburtsjahr <SEP> Regalnummer
<tb> CD <SEP> Buch <SEP>
<tb> Komponist <SEP> Autor
<tb> Interpret
<tb>
Entlehnungen werden als 1 : n Beziehungen zwischen Mitgliedern und entlehnbaren Gegenständen abgebildet.
Erfindungsgemäss werden nun die Objektklassen mittels vorgegebener Schlusseiwörter hinsichtlich ihrer persistenten und translenten Eigenschaften und Beziehungen beschrieben Im folgenden eine Beschreibung der Klassen des Ausfuhrungsbelsplels
<Desc/Clms Page number 4>
#MODULE¯SECTION #VERSION@(#) Mitglied M, /main/1, NO¯LABELS; Mon, 03. 07. 95, 14 : 15 :
51 #DATUM 03. 07. 95 #KOMPONENTE BIB #KENNUNG M #AUTOR1 Schallhart #AUTOR2 #HISTORIE #END¯MODULE¯SECTION #INCLUDE¯SECTION #include < DbRoot.H > #END¯INCLUDE¯SECTION #CLASS¯SECTION #CLASS Mitglied #LEVEL Conceptual #SUPER DbRoot #OBJECTNAME ein #DESCRIPTION #USES #FLAGS concrete #STATES #ATTRIBUTES #ATTRIBUTE mitgliedsNr #DOMAIN Int #ATTRIBUTE¯DESCRIPTION #ATTRIBUTE¯FLAGS protected persistent #ATTRIBUTE nachname #DOMAIN Stnng25
EMI4.1
#ATTRIBUTE¯DESCRIPTION#ATTRIBUTE¯FLAGS protected persistent #ATTRIBUTE vomame #DOMAIN String25 #ATTRIBUTE¯DESCRIPTION #
ATTRIBUTE¯FLAGS protected persistent #ATTRIBUTE geburtsjahr #DOMAIN Short #ATTRIBUTE¯DESCRIPTION
EMI4.2
entlehnungen #MULTIVALUED#ATTRIBUTE¯DESCRIPTION #ATTRIBUTE¯FLAGS protected persistent #METHODS #METHOD #END¯CLASS¯SECTION
<Desc/Clms Page number 5>
#MODULE¯SECTION #VERSION @(#) EntlehnbarerGegenstand.M., /main/1; NO¯LABELS, Mon, 03. 07. 95, 14 : 16 : 40 #DATUM 03. 07. 95 #KOMPONENTE BIB #KENNUNG E #AUTOR1 Schallhart #AUTOR2 #HISTORIE #END¯MODULE¯SECTION #INCLUDE¯SECTION #include < DbRoot.
H > #END¯INCLUDE¯SECTION #CLASS¯SECTION #CLASS EntlehnbarerGegenstand #LEVEL Conceptual #SUPER DbRoot #OBJECTNAME ein #DESCRIPTION #USES #FLAGS abstract #STATES #ATTRIBUTES #ATTRIBUTE id #DOMAIN Int #ATTRIBUTE¯DESCRIPTION #ATTRIBUTE¯FLAGS protected persistent #ATTRIBUTE titel #DOMAIN String100 #ATTRIBUTE¯DESCRIPTION #ATTRIBUTE¯FLAGS protected persistent #ATTRIBUTE herausgeber #DOMAIN String60 #ATTRIBUTE¯DESCRIPTION #ATTRIBUTE¯FLAGS protected persistent #ATTRIBUTE regalNr #DOMAIN Short #
ATTRIBUTE¯DESCRIPTION #ATTRIBUTE¯FLAGS protected persistent #METHODS #METHOD.
#END¯CLASS¯SECTION
EMI5.1
@(#) Buch. M,/main/l, NO-LABELS ; Mon, 03. 07. 95, 14 16 57#DATUM 030795 #KOMPONENTE BIB #KENNUNG B
<Desc/Clms Page number 6>
#AUTOR1 Schallhart #AUTOR2 #HISTORIE #END¯MODULE¯SECTION #INCLUDE¯SECTION #include < EntlehnbarerGegenstand.
H > #END¯INCLUDE¯SECTION
EMI6.1
##CLASS Buch #LEVEL Conceptual #SUPER EntlehnbarerGegenstand #OBJECTNAME ein #DESCRIPTION #USES #FLAGS concrete #STATES #ATTRIBUTES #ATTRIBUTE autor
EMI6.2
Strin#ATTRIBUTE¯DESCRIPTION #ATTRIBUTE¯FLAGS protected persistent #METHODS #METHOD...
#END¯CLASS¯SECTION
EMI6.3
SECTION#DATUM 03. 07. 95 #KOMPONENTE BIB #KENNUNG C #AUTOR1 Schailhart #AUTOR2 #HISTORIE #END¯MODULE¯SECTION #INCLUDE¯SECTION #include < EntlehnbarerGegenstand.
H > #END¯INCLUDE¯SECTION #CLASS¯SECTION #CLASS CD #LEVEL Conceptual #SUPER EntlehnbarerGegenstand #OBJECTNAME eine #DESCRIPTION #USES #FLAGS concrete #STATES
<Desc/Clms Page number 7>
#ATTRIBUTES #ATTRIBUTE komponist #DOMAIN Stnng40 #ATTRIBUTE¯DESCRIPTION #ATTRIBUTE¯FLAGS protected persistent #ATTRIBUTE interpret #DOMAIN String40 #ATTRIBUTE¯DESCRIPTION #ATTRIBUTE¯FLAGS protected persistent #METHODS #METHOD...
#END¯CLASS¯SECTION Aus dieser Beschreibung 1 (Klassen-Template) werden durch Aufruf eines Template-Umsetzer-Modules 2 einerseits Datenfiles 3 mit Persistenzinformation entsprechend den im folgenden angeführten
EMI7.1
CLASS Mitglied
ATTRIBUTE Int mitgliedsNr
ATTRIBUTE String25 nachname
ATTRIBUTE String25 vomame
ATTRIBUTE Short geburtsjahr
REFERS EntlehnbarerGegenstand entlehnungen MULTIVALUED
ENDCLASS EntlehnbarerGegenstand. dat :
EMI7.2
CLASS EntlehnbarerGegenstandATTRIBUTE String100 titel
ATTRIBUTE String60 herausgeber
ATTRIBUTE Short regalNr
ENDCLASS
Buch dat.
CLASS Buch : EntlehnbarerGegenstand
ATTRIBUTE String40 autor
ENDCLASS
CD. dat :
CLASS CD : EntlehnbarerGegenstand
ATTRIBUTE String40 komponist
ATTRIBUTE String40 interpret
ENDCLASS und Zusatzfiles 4 mit programmiersprachenspezifischer Information genenert
<Desc/Clms Page number 8>
Die programmiersprachenspezifische Klassendeklaration im ZusatzFile 4 enthält sämtliche Attribute und Methoden It. Klassen-Template 1 und zusätzlich die Deklaration (= Schnittstellenbeschreibung) aller klassenspezifischen Persistenz-Methoden.
Im folgenden ein Auszug aus dem C++-Zusatzfe 4 für die Klasse "Mitglied" : #ifndef¯Mitglied¯h #define¯Mitglied¯h //------------------------------------------- //Dateiname :Mitglied.H //.....
1/Includes #include < DbRoot. H >
1/Ende Includes
1/Import class Mitglied ;
EMI8.1
class DbContainer (Mitglied) ; 1/Ende Import //Deklarationen class Mitglied : public DbRoot { public :
CREATE (Mitglied) static Db : : ErrorCode lesenObjekte ( DbZeigerListe (Mitglied) & , const char* se) Stat = 0,
Db::LockType lockMode = Db : : OBJUNLOCK, const char* dbTabName = 0,
ListLaenge contGroesse = AKTCONTGROESSE, int anzKeyCont = 0
EMI8.2
;Db : : ErrorCode zaehlenObjekte ( int & treffer, const char* = 0,
Db::LevelType levelMode = Db : : SHALLOW
EMI8.3
(
DbContainer(Mitglied) & , const char* Stat = 0,
Db : LockType lockMode = Db : : OBJUNLOCK,
ListLaenge contGroesse = AKTCONTGROESSE, int anzKeyCont = 0
EMI8.4
<Desc/Clms Page number 9>
;virtual Db : : ErrorCode lesenObjekt ( const char* = 0,
Db::LockType lockMode = Db : : OBJUNLOCK
EMI9.1
;Db : : ErrorCode passivieren (
Db : : LevelType levelMode = Db : : SHALLOW,
Db ::TransTypetransMode=Db::TRANS
EMI9.2
void setStoreRequestAll ( Db : : StoreType storeMode = Db : : NOREQUEST
EMI9.3
( const char* = 0,
DB::LockType lockMode = Db : :
OBJUNLOCK
EMI9.4
;protected : Int mitgliedsNr,
String nachname ;
String vomame ;
Short geburtsjahr,
EMI9.5
(EntlDB::ErrorCodeaendemDb();
DB ::ErrorCodeloeschenDb(); private :
EMI9.6
;INSERT (Mitgiied, DbRoot) //EndeDeklarationen //Inlines #include "mitglied. iC" //EndeInlines #endif
<Desc/Clms Page number 10>
Die Generierung des Datenbankschemas mittels Datenbankgenerator 5 erfolgt nach den folgenden Grundsätzen : * Für jede Klasse, die persistente Objekte (=Instanzen) ausbilden kann, wird eine Datenbanktabelle erzeugt. Für abstrakte Klassen (wie z. B.
"Entlehnbarer Gegenstand") gibt es keine Entsprechung als Tabelle.
Jede Datenbanktabelle erhäít zusÅatzíich zu den über das Template 1 definierten persistenten Attributen eine erste Spalte zur eindeutigen
Objektidentifikation und eine zweite Spalte zur Prüfung der Objektaktualität bei konkurrierenden Zugriffen.
* Die Vererbung zwischen den Klassen wird im relationalen Datenbanksystem
14 dadurch berücksichtigt, dass geerbte Attribute in der Datenbanktabelle der jeweiligen Blattklasse aufgenommen werden. Die Tabelle "Buch" enthält die daher neben der Spalte "Autor" auch die Spalten "Kennung",'Titel", "Herausgeber" und"Regalnummer", welche den von der abstrakten
Superklasse "EntlehnbarerGegenstand" geerbten persistenten Attributen entsprechen.
Einfache Attribute werden im Datenbanksystem 14 durch genau eine
Datenbankspalte repräsentiert. Dem Attribut "Mitgliedsnummer" entspricht die Datenbankspalte"Mitgliedsnummer".
Bei Objekt-Objekt-Beziehungen (Containment- und Points-to-Bezlehungen) handelt es sich um komplexe Attribute. Eingebettete (Containment) und referenzierte (Points-to-Beziehung) Objekte werden in einer eigenen Tabelle der jeweiligen Klasse abgelegt. Die Beziehung als solche wird dann im Datenbanksystem 14 durch Fremdschlüssel abgebildet.
So wird für das komplexe Attribut "Entlehnungen" in den Datenbanktabellen "Buch" und "CD" eine Spalte "Entlehnungen"gebildet. Wenn ein Buch oder eine CD ausgeliehen wird, wird in diese Spalte der Klasse "Buch"oder nCD"der Wert der ersten Spalte zur Objektidentifikation des jeweiligen Objektes der Klasse Mitglied eingetragen Bel Rückgabe wird der Fremdschlüssel wieder geloscht.
<Desc/Clms Page number 11>
Die folgende Tabelle zeigt das Schema der Datenbanktabellen des vorliegenden Ausführungsbeispiels
EMI11.1
<tb>
<tb> Tabellenname <SEP> Mitglied <SEP> Buch <SEP> CD
<tb> erste <SEP> Spalte <SEP> zur <SEP> sysKey <SEP> sysKey <SEP> sysKey
<tb> Objektidentifikat.
<tb> zweite <SEP> Spalte <SEP> zur <SEP> IfNr <SEP> IfNr <SEP> IfNr <SEP>
<tb> Objektaktualität
<tb> DB-Spafte <SEP> (n)
<SEP> f.-Kennung <SEP> Kennung
<tb> geerbte <SEP> Attribute <SEP> Titel <SEP> Titel
<tb> Herausgeber <SEP> Herausgeber
<tb> Regalnummer <SEP> Regalnummer
<tb> DB-Spalte <SEP> (n) <SEP> f. <SEP> Mitgliedsnummer <SEP> Autor <SEP> Komponist
<tb> eigene <SEP> Attribute <SEP> Nachname <SEP> Interpret
<tb> Vorname
<tb> Geburtsjahr
<tb> DB-Spalte <SEP> (n) <SEP> für <SEP> - <SEP> Entlehnungen <SEP> Entlehnungen
<tb> Fremdschlüssel
<tb>
Über key-files 6 können für persistente Attribute und Attributkombinationen Anwenderschlüssel und-indizes definiert werden, die beim Generierungslauf in das Datenbankschema übernommen werden.
Als Beispiel eines key-files 6 : Mitglied. key-.
CLASS Mitglied
KEY mitgliedsNr
ENDCLASS Ausgehend von den Datenfiles 3 und den key-files 6 erzeugt der Datenbankgenerator 5 eine Beschreibung des Datenbankschemas 9 in der Datenbankabfragesprache SQL (SQL-Script). Dieses SQL-Script dient als
<Desc/Clms Page number 12>
Eingangsinformation für das SQL-Werkzeug 11 des jeweiligen StandardDatenbanksystems, über das die Datenbank 14 erzeugt wird Die Anwenderschnittstelle 12 der erfindungsgemässen Programmlogik stellt sämtliche Methoden für das Persistenz-Handling zur Verfügung. Diese lassen sich in drei Gruppen teilen : Controler-, Klassenspezifische-, und Container-Methoden.
Controler-Klassen 10 bieten Methoden für das Öffnen und Schliessen der Datenbank (geschachteltes Sessionhandling), für das Transaktionshandling (Offnen, Commit, Rollback, geschachtelte Transaktionen) und für die Fehlerbehandlung an.
Klassenspezifische Methoden 8 werden durch den Datenbankgenerator 5 für jede - über Templates 1 definierte - persistente Klasse von Objekten erzeugt.
Dabei werden folgende Funktionsgruppen unterschieden : Aktivieren (Auslesen aus der Datenbank) Dazu werden Lese- und Dereferenzier-Methoden generiert. Dabei wird das Prinzip der lazy evaluation verfolgt, d. h. Objektgeflechte werden Schritt für Schritt aktiviert.
Bel Aktivierung eines Objektes werden alle einfachen persistenten Attribute aus der DB ausgelesen. Für die Aktivierung komplexer Attribute werden
EMI12.1
Durch spezielle Schlùsselwörte in der Template-Definition kann die Generierung von Tuningfeatures angefordert werden wie z. B. die Zusammenfassung von Datenbankzugriffen, wodurch verminderte Client-ServerKommunikation und Zugriffsoptimierung bel Points-to-Bezlehungen erreicht wird
<Desc/Clms Page number 13>
Bei Aktivierung eines Objektes bzw. eines Objektgeflechtes kann über die Aufrufschnittstelle der Lese- bzw. Dereferenzier-Methode auch eine Sperrmöglichkeit mitgeliefert werden.
. Passivieren (Insert, Update und Delete) Für den Schreibvorgang werden Marier- un Passivier-Methoden angeboten.
Soll ein Objekt bzw. ein Objektgeflecht passiviert, d. h in die Datenbank geschrieben werden, so muss es entsprechend markiert werden. Dabei wird über eine Markier-Methode die Art der Passivierungwünsche bekanntgegeben ; es wird mitgeteilt, ob das Objekt eingefügt, aktualisiert oder gelöscht werden soll.
Innerhalb eines Objektgeflechts können dabei verschiedene Passivierungswünsche beliebig gemischt werden. o Zählen von Objekten Mittels Methodenaufruf kann die Anzahl der Objekte ermittelt werden, die einem bestimmten Kriterium genügen.
Für das Handling der Objektmengen, werden weiterhin verschiedene Container-Methoden 10 bzw. Listen-Klassen angeboten : A) Homogene Listen, in die nur Objekte einer Klasse eingehängt werden, und B) Heterogene Listen, In die Objekte verschiedener Klassen, die zueinander in einer Vererbungshierarchie stehen, eingehängt werden. Die Objekte können einer Superklasse oder einer ihrer Subklassen angehoren.
Alle Container- bzw. Listen-Klassen bieten Methoden für folgende Funktionsgruppen : . Aktivieren (Auslesen aus der Datenbank) Uber Methodenaufruf werden Objekte aktiviert, die einem übergebenen Kriterium entsprechen Das Aktivieren kann geblokt werden, wobei die gewünschte Blockgrösse über die Aufrufschnittstelle mitgeteilt werden kann
<Desc/Clms Page number 14>
Über die Aufrufschnittstelle der Aktivierungmethode können diezu aktivierenden Objekte auch gesperrt werden.
* ! terieren/Positionieren Über die Objektmenge von Listen kann Objekt für Objekt und blockweise vorwärts und rückwärts positioniert werden.
Passivieren (Insert, Update und Delete) Nachdem die - beliebig mischbaren - Passivierungswünsche für die Objekte einer Liste bekanntgegeben wurden, kann die gesamte Liste durch Methodenaufruf passiviert werden.
. Zählen von Objekten Mittels Methodenaufruf kann die Anzahl der Objekte einer Liste ermittelt werden.
Alle beschriebenen Methoden werden als Anwenderschnittstelle von der erfindungsgemässen Programmlogik in Library-Form angeboten.
Der Datenbankgenerator 5 erzeugt ausgehend von den Datenfiles 3, die sämtliche klassenspezifische Informationen enthalten, und klassenneutralen Prototypen 7, die eine klassenunabhängige Ablaufbeschreibung für Methoden darstellen, den Programm-Code für alle klassenspezifischen PersistenzMethoden.
Zusammen mit dem Programm-Code 10 für Controler- und Container-Klassen werden die generierten klassenspezifischen Methoden 8 unter Einbindung der Zusatzfiles durch entsprechende Mittel 12 in Maschinen-Code übersetzt und als Bibliothek 13 bereitgestellt.
<Desc / Clms Page number 1>
Method for storing persistent objects from object-oriented user programs in a relational database.
The invention relates to a method for storing persistent objects of object-oriented user programs in a relational database.
Object-oriented programs are based on objects or object networks, which are complex networked data structures. The content of some of these objects or network of objects must be retained beyond the duration of a program; the associated object or network of objects is then referred to as "persistent". Basically, files - so-called flat files -, object-oriented databases or relational databases can be used to store persistent objects.
However, files are not always suitable for storage.
Object-oriented databases have only recently become available on the market and therefore do not meet the high reliability requirements of industrial applications. Relational databases are therefore usually used, which have the advantage that tried-and-tested and reliable standard products with access pages sufficient for operation are available.
The assignment of persistent object structures to the simple tables of a relational database is, however, a complex task that requires complex and costly developments
<Desc / Clms Page number 2>
The invention is therefore based on the object of specifying a method with which the connection between any object-oriented user programs and relational databases can be established in a simple manner.
The program logic according to the invention provides access and storage methods for the persistent objects of the application, so that simple handling by the user programs is ensured.
In this way, all object model-dependent methods for accessing the database are generated automatically. By using special properties of relational database systems, short database access times can also be guaranteed. There is an arbitrarily granular locking concept; Both individual objects and object sets can be locked at the time of reading from the relational database.
Both database sessions and database transactions can be logically nested. Object sets can be read in blocks from the database step by step. The block size can be defined in advance. Any number of objects can be positioned (forward, backward, absolute, first, last). The positioning can be done in blocks or object by object. The application program can influence the access times to its persistent objects by using the existing tuning features.
The invention is explained in more detail with reference to a figure, which shows an example of a structure diagram of the program logic according to the invention.
The exemplary embodiment shown relates to an object-based computer program for managing a library.
The basis of an object-developed program are objects. These objects can contain both data (= attributes) and operations (= methods).
<Desc / Clms Page number 3>
be assigned. Furthermore, different types of relationships (inheritance, points-to-relationship, containment relationship) can exist between the objects. The description of the objects including all of their properties is in the form of class definitions, so a class is the general description of an object.
In this example, library members can borrow books and CDs. The library members are therefore recorded with their properties relevant to the present task in the object class "member", books and CDs are recorded with regard to their common properties in the abstract super class "borrowable object" and in the specific sheet classes "book" and "CD". The properties of the super class are passed on to the leaf classes via inheritance.
The simple attributes of the classes mentioned, which correspond to the properties of the detected objects, are shown in the following table.
EMI3.1
<tb>
<tb>
Member <SEP> Borrowable <SEP> item
<tb> Member number <SEP> identifier
<tb> Surname <SEP> title
<tb> first name <SEP> publisher
<tb> Year of birth <SEP> shelf number
<tb> CD <SEP> book <SEP>
<tb> Composer <SEP> author
<tb> interpreter
<tb>
Loans are mapped as 1: n relationships between members and borrowable items.
According to the invention, the object classes are now described by means of predetermined key words with regard to their persistent and translucent properties and relationships. The following is a description of the classes of the exemplary embodiment
<Desc / Clms Page number 4>
# MODULE¯SECTION # VERSION comm (#) member M, / main / 1, NO¯LABELS; Mon, 07/07/95, 14:15:
51 # DATE 07/03/95 # COMPONENT BIB # ID M # AUTHOR1 Schallhart # AUTHOR2 # HISTORY # END¯MODULE¯SECTION # INCLUDE¯SECTION #include <DbRoot.H> # END¯INCLUDE¯ SECTION # CLASS¯SECTION # CLASS Member # LEVEL Conceptual # SUPER DbRoot # OBJECTNAME a # DESCRIPTION # USES # FLAGS concrete # STATES # ATTRIBUTES #ATTRIBUTE member # # DOMAIN Int # ATTRIBUTE¯DESCRIPTION # ATTRIBUTE¯FLAGS protected persistent # ATTRIBUTE last name #DOMAIN Stnng25
EMI4.1
# ATTRIBUTE¯DESCRIPTION # ATTRIBUTE¯FLAGS protected persistent #ATTRIBUTE vomame # DOMAIN String25 # ATTRIBUTE¯DESCRIPTION #
ATTRIBUTE¯FLAGS protected persistent AT ATTRIBUTE year of birth A DOMAIN Short num ATTRIBUTE¯DESCRIPTION
EMI4.2
borrowings # MULTIVALUED # ATTRIBUTE¯DESCRIPTION # ATTRIBUTE¯FLAGS protected persistent # METHODS # METHOD # END¯CLASS¯SECTION
<Desc / Clms Page number 5>
# MODULE¯SECTION #VERSION® (#) Borrowable item.M., / Main / 1; NO¯LABELS, Mon, 07/03/95, 14:16:40 # DATE 07/03/95 # COMPONENT BIB # ID E # AUTHOR1 Schallhart # AUTOR2 # HISTORY # END¯MODULE¯SECTION # INCLUDE¯SECTION #include <DbRoot.
H> EN END¯INCLUDE¯SECTION num CLASS¯SECTION #CLASS Lentable item num LEVEL Conceptual SUP SUPER DbRoot OB OBJECTNAME a DESCRIPTION DESCRIPTION num USES FL FLAGS abstract ST STATES num ATTRIBUTES num ATTRIBUTE id # DOMAIN Int # ATTRIBUTE¯DESCRIPTION # ATTRIBUTE¯FLAGS protected persistent # ATTRIBUTE title #DOMAIN String100 # ATTRIBUTE¯DESCRIPTION # ATTRIBUTE¯FLAGS protected persistent # ATTRIBUTE publisher # DOMAIN String60 # ATTRIBUTE ATTRIBUTESIBES protected persistent #ATTRIBUTE regalNr # DOMAIN Short #
ATTRIBUTE¯DESCRIPTION # ATTRIBUTE¯FLAGS protected persistent # METHODS # METHOD.
# END¯CLASS¯SECTION
EMI5.1
comm (num) book. M, / main / l, NO-LABELS; Mon, 07/03/95, 14 16 57 DATE 030795 COMPONENT BIB ID B
<Desc / Clms Page number 6>
# AUTHOR1 Schallhart # AUTHOR2 # HISTORY # END¯MODULE¯SECTION # INCLUDE¯SECTION # include <Borrowable item.
H> # END¯INCLUDE¯SECTION
EMI6.1
# #CLASS Book # LEVEL Conceptual # SUPER Loanable Object # OBJECTNAME a # DESCRIPTION # USES # FLAGS concrete # STATES # ATTRIBUTES # ATTRIBUTE author
EMI6.2
Strin # ATTRIBUTE¯DESCRIPTION & ATTRIBUTE¯FLAGS protected persistent & METHODS & METHOD ...
# END¯CLASS¯SECTION
EMI6.3
SECTION # DATE 07/03/95 # COMPONENT BIB ID # C # AUTHOR1 Schailhart # AUTHOR2 # HISTORY # END¯MODULE¯SECTION # INCLUDE¯SECTION # include <Borrowable item.
H> EN END IN INCLUDE S SECTION # CLASS S SECTION CLASS CLASS CD LE LEVEL Conceptual #SUPER Borrowable item DESCRIPTION OBJECTNAME a DESCRIPTION DESCRIPTION num USES FL FLAGS concrete ST STATES
<Desc / Clms Page number 7>
# ATTRIBUTES # ATTRIBUTE composer # DOMAIN Stnng40 # ATTRIBUTE¯DESCRIPTION # ATTRIBUTE¯FLAGS protected persistent # ATTRIBUTE interpret #DOMAIN String40 # ATTRIBUTE¯DESCRIPTION # ATTRIBUTE¯FLAGS protected persistent # METHOD ...
# END¯CLASS¯SECTION From this description 1 (class template), by calling up a template converter module 2, data files 3 with persistence information corresponding to those listed below are made
EMI7.1
CLASS member
ATTRIBUTE Int member no
ATTRIBUTE String25 last name
ATTRIBUTE String25 vomame
ATTRIBUTE Short year of birth
REFERS Borrowable Item Borrowings MULTIVALUED
ENDCLASS Borrowable item. dat:
EMI7.2
CLASS Borrowable Item ATTRIBUTE String100 title
ATTRIBUTE String60 publisher
ATTRIBUTE Short shelf no
ENDCLASS
Book dat.
CLASS book: borrowable item
ATTRIBUTE String40 author
ENDCLASS
CD. dat:
CLASS CD: Borrowable item
ATTRIBUTE String40 composer
ATTRIBUTE String40 interpret
ENDCLASS and additional files 4 with programming language-specific information
<Desc / Clms Page number 8>
The programming language-specific class declaration in the additional file 4 contains all attributes and methods It. Class template 1 and additionally the declaration (= interface description) of all class-specific persistence methods.
The following is an excerpt from the C ++ additional Fe 4 for the class "member": # ifndef¯Mitglied¯h # define¯Mitglied¯h // ------------------- ------------------------ // Filename: Member.H // .....
1 / Includes # include <DbRoot. H>
1 / end includes
1 / Import class member;
EMI8.1
class DbContainer (member); 1 / end of import // declarations class member: public DbRoot {public:
CREATE (member) static Db:: Read ErrorCodeObjects (DbZeigerListe (member) &, const char * se) Stat = 0,
Db :: LockType lockMode = Db:: OBJUNLOCK, const char * dbTabName = 0,
ListLaenge contGroesse = AKTCONTGROESSE, int anzKeyCont = 0
EMI8.2
; Db:: ErrorCode count objects (int & hit, const char * = 0,
Db :: LevelType levelMode = Db:: SHALLOW
EMI8.3
(
DbContainer (member) &, const char * Stat = 0,
Db: LockType lockMode = Db:: OBJUNLOCK,
ListLaenge contGroesse = AKTCONTGROESSE, int anzKeyCont = 0
EMI8.4
<Desc / Clms Page number 9>
; virtual Db:: Read error code Object (const char * = 0,
Db :: LockType lockMode = Db:: OBJUNLOCK
EMI9.1
; Db:: passivate error code (
Db:: LevelType levelMode = Db:: SHALLOW,
Db :: TransTypetransMode = Db :: TRANS
EMI9.2
void setStoreRequestAll (Db:: StoreType storeMode = Db:: NOREQUEST
EMI9.3
(const char * = 0,
DB :: LockType lockMode = Db::
OBJUNLOCK
EMI9.4
; protected: Int member number,
String last name;
String vomame;
Short birth year,
EMI9.5
(EntlDB :: ErrorCodeaendemDb ();
DB :: ErrorCodeloeschenDb (); private:
EMI9.6
; INSERT (Member, DbRoot) // EndDeclarations // Inlines #include "member. IC" // EndInlines # endif
<Desc / Clms Page number 10>
The database schema is generated using the database generator 5 according to the following principles: * A database table is generated for each class that can form persistent objects (= instances). For abstract classes (such as
"Borrowable item") there is no equivalent as a table.
In addition to the persistent attributes defined via template 1, each database table is given a first column for clear identification
Object identification and a second column to check the object's current status for competing accesses.
* Inheritance between classes is in the relational database system
14 takes into account that inherited attributes are included in the database table of the respective leaf class. In addition to the "Author" column, the "Book" table also contains the "Identification", "Title", "Publisher" and "Shelf number" columns, which correspond to those of the abstract
Superclass Borrowable Item match inherited persistent attributes.
Simple attributes are identified in database system 14 by exactly one
Represents database column. The "Member number" database column corresponds to the "Member number" attribute.
Object-object relationships (containment and points-to-relationships) are complex attributes. Embedded (containment) and referenced (points-to-relationship) objects are stored in a separate table for each class. The relationship as such is then mapped in the database system 14 using foreign keys.
For example, a column "Loans" is created for the complex attribute "Loans" in the database tables "Book" and "CD". If a book or CD is borrowed, the value of the first column for object identification of the respective object of the member class is entered in this column of the "Book" or nCD class. The foreign key is deleted again on return.
<Desc / Clms Page number 11>
The following table shows the diagram of the database tables of the present exemplary embodiment
EMI11.1
<tb>
<tb> table name <SEP> member <SEP> book <SEP> CD
<tb> first <SEP> column <SEP> to <SEP> sysKey <SEP> sysKey <SEP> sysKey
<tb> object identifier.
<tb> second <SEP> column <SEP> to <SEP> IfNr <SEP> IfNr <SEP> IfNr <SEP>
<tb> Object topicality
<tb> DB-Spafte <SEP> (n)
<SEP> f. Identifier <SEP> identifier
<tb> inherited <SEP> attributes <SEP> title <SEP> title
<tb> editor <SEP> editor
<tb> shelf number <SEP> shelf number
<tb> DB column <SEP> (n) <SEP> f. <SEP> member number <SEP> author <SEP> composer
<tb> own <SEP> attributes <SEP> last name <SEP> interpreter
<tb> first name
<tb> year of birth
<tb> DB column <SEP> (n) <SEP> for <SEP> - <SEP> borrowings <SEP> borrowings
<tb> Foreign key
<tb>
Key-files 6 can be used to define user keys and indices for persistent attributes and attribute combinations, which are transferred to the database schema during the generation run.
As an example of a key file 6: member. key-.
CLASS member
KEY member no
ENDCLASS Based on the data files 3 and the key files 6, the database generator 5 generates a description of the database scheme 9 in the database query language SQL (SQL script). This SQL script serves as
<Desc / Clms Page number 12>
Input information for the SQL tool 11 of the respective standard database system, via which the database 14 is generated. The user interface 12 of the program logic according to the invention provides all methods for persistence handling. These can be divided into three groups: controller, class-specific, and container methods.
Controler classes 10 offer methods for opening and closing the database (nested session handling), for transaction handling (open, commit, rollback, nested transactions) and for error handling.
Class-specific methods 8 are generated by the database generator 5 for each persistent class of objects - defined via templates 1.
A distinction is made between the following function groups: Activate (reading from the database) For this purpose, reading and dereferencing methods are generated. The principle of lazy evaluation is followed, i. H. Object meshes are activated step by step.
When an object is activated, all simple persistent attributes are read from the DB. For the activation of complex attributes
EMI12.1
Using special keywords in the template definition, the generation of tuning features can be requested, such as: B. the combination of database accesses, whereby reduced client-server communication and access optimization is achieved at points-to-lendings
<Desc / Clms Page number 13>
When activating an object or a network of objects, a blocking option can also be provided via the call interface of the reading or dereferencing method.
. Passivation (insert, update and delete) Marier and passivation methods are offered for the write process.
If an object or an object network is to be passivated, i. h are written to the database, it must be marked accordingly. The type of passivation requests is announced using a marking method; it is informed whether the object should be inserted, updated or deleted.
Different passivation requests can be mixed as desired within a network of objects. o Counting objects The method can be used to determine the number of objects that meet a certain criterion.
Various container methods 10 and list classes are still offered for the handling of object sets: A) Homogeneous lists, in which only objects of one class are inserted, and B) Heterogeneous lists, In the objects of different classes, which are in one another Inheritance hierarchy are available, can be mounted. The objects can belong to a superclass or one of its subclasses.
All container and list classes offer methods for the following function groups:. Activate (read out from the database) Objects that correspond to a passed criterion are activated via method call. Activation can be blocked, whereby the desired block size can be communicated via the call interface
<Desc / Clms Page number 14>
The objects to be activated can also be blocked via the call interface of the activation method.
*! terieren / Positionieren Via the object set of lists, object by object and blocks can be positioned forward and backward.
Passivation (insert, update and delete) After the passivation requests for the objects in a list, which can be mixed as required, have been announced, the entire list can be passivated by calling the method.
. Counting objects The number of objects in a list can be determined by calling the method.
All the methods described are offered as a user interface by the program logic according to the invention in library form.
Starting from the data files 3, which contain all class-specific information, and class-neutral prototypes 7, which represent a class-independent process description for methods, the database generator 5 generates the program code for all class-specific persistence methods.
Together with the program code 10 for controller and container classes, the generated class-specific methods 8 are translated into machine code by means of appropriate means 12 with the inclusion of the additional files and made available as library 13.