JASMINE: Die objektorientierte Datenbank Computer Associates, ein Unternehmen mit langer Erfahrung in der Datenbankwelt, stellt JASMINE, ein objektorientiertes Datenbanksystem (ODBMS) vor. Im Gegensatz zu den heute meist verwendeten RDBMS, bieten ODBMS wie Jasmine neue Möglichkeiten. Sie sind deutlich enger an objektorientierte Programmiersprachen wie C++ oder Java gebunden und verkürzen dadurch den Designprozeß in der Softwareentwicklung bis hin zu 30 % und mehr. Aber auch die Behandlung erweiterter Datentypen wie Bilder, Töne, oder auch Person, Kunde, usw. wird wesentlich vereinfacht. Die Idee des ODBMS ist mit dem Entstehen neuer Anforderungen an Datenbanksysteme gewachsen und daher nicht ganz neu, aber bislang hatte sich noch kaum ein renommierter Hersteller dieser Thematik angenommen. Das ist deshalb wichtig, weil die darunterliegende Datenbank für das Gelingen von Projekten wichtig ist. Wäre die Datenbank zum Beispiel instabil, so wird die ganze Applikation instabil - und damit unbrauchbar. Bei ODBMS ist die Datenbank bedeutender als bei traditionellen RDBMS - denn auch die ausführbaren Programmteile sind Bestandteil der Datenbank. Gerade hier tut es gut, sich auf einen renommierten Hersteller verlassen zu können. Jasmine ist für professionelle Anforderungen designed worden. Als "gutes" ODBMS entspricht es den CORBA - Definitionen der OMG, und orientiert sich auch in Abfragesprache und anderen Details sehr nahe an den derzeitigen Standardisierungsbestrebungen. Gleichzeitig kann Jasmine auch auf bestehende SQL-Datenbanken zugreifen, so daß auch in der OO-Applikation existierende Daten aus anderen Systemen zur Verfügung stehen. Das kann bislang keine andere OO-Datenbank zufriedenstellend. Jasmine verläßt sich dabei auf Komponenten, die auch im bewährten IngresNet enthalten sind. Mit dieser Connectivity Software greift Jasmine problemlos auf Daten aus VSAM, DB/2 oder IMS ebenso zu wie auf RDBMS unter Unix. Allerdings kann Jasmine diese Daten nur mit SQL-Klassen bearbeiten, für objektorientierte Systeme muß schon Jasmine selbst bemüht werden. Jasmine selbst speichert seine Daten grundsätzlich nicht in Tabellenform, und unterscheidet sich damit ganz wesentlich von RDBMS mit "aufgesetztem"Objektinterface. Jasmine als Objektspeicher Wird die Applikation allerdings objektorientiert entwickelt, bringt Jasmine als ODBMS viel. Speichert eine objektorientierte Applikation mangels ODBMS Daten in einem RDBMS ab, kostet das Enwicklungszeit und Geld. Das mutet nicht nur umständlich an, sondern ist es auch. Verglichen mit einem Auto wird das Auto jedesmal in die Einzelteile zerlegt, wenn es in die Garage gestellt wird. Da die Objekte zerlegt und oft in verschiedene, nicht zusammen gehörende Tabellen gespeichert werden müssen, drängt sich dieser Vergleich geradezu auf. Hat man jedoch eine OO-Datenbank zur Verfügung, kann diese Behelfslösung durch eine professionelle ersetzt werden. Die Objekte können in einem Stück in der DB gespeichert werden. Jasmine wird dann zu einem "Persistent Object Storage", einem beständigen Objektspeicher. Auch in Bereichen, die mit einem RDBMS nicht viel anfangen, kann Jasmine nützlich sein. Viele dieser Entwickler arbeiten objektorientiert, und suchen nach Möglichkeiten, einfach ganze Objekte abspeichern zu können. GIS (Geographische Informationssysteme), Neuronale Netze oder Optimierungssysteme haben nämlich - für RDBMS - zu komplexe Strukturen. Ein ODBMS wie Jasmine kann aber sehr wohl die Datenhaltung übernehmen. Prinzipiell entspricht ein ODBMS den heutigen OOP Programmiersprachen weit mehr als RDBMS. Jasmine als ODBMS Weil Jasmine als ODBMS in Objekten Methoden und Attribute vereint, wird das Anwendungssystem (fast) komplett in Jasmine modelliert. Große Teile des ausführbaren Codes werden als Methoden in die Datenbank gelegt, wodurch die Clients noch schlanker werden. Der Client muß nur mehr die "richtige" Aktion im Server anstoßen und das Ergebnis am Schirm darstellen. Verarbeitet wird die Anwendungslogik komplett im Server. So wird auch die Erstellung des Clients einfacher und leichter, und die Netzwerkbelastung wird gesenkt. Dadurch ergeben sich neuartige Locking-Strukturen, die ebenfalls implementiert wurden. Besondern bei persistenten Objekten, die lang im Speicher verbleiben, scheint ein effektives Locking wichtig zu sein. Anders als bei OO-Programmen mit RDBMS "darunter" wird hier ständig in der Datenbank gearbeitet. Locking ist auf Objektebene möglich, und zwar sowohl zum Lesen als auch zum Schreiben. Auf Wunsch kann das Locking in einem bestehenden Objekt geändert werden, ohne daß das Objekt zerstört und neu aus der DB "geholt" werden müßte. Der Jasmine Server läuft unter NT, und für leistungshungrige Anwendungen auch unter Solaris. Andere Umgebungen sind als Zielplattformen ebenfalls geplant. Unter NT benötigt man 32-64 MByte (besser wie üblich MEHR) RAM, und ca. 200 Mbyte Plattenplatz. Da die Methoden mit Microsoft Visual C++ übersetzt werden, müssen Entwickler, die JASMINE ausnützen möchten, VC++ besitzen. Die Überwachung mit CA Unicenter TNG ist - wie bei jeder Datenbank - möglich. Interessanter dürfte die Einbindung von JASMINE in TNG sein - dann verwendet TNG JASMINE als Object Repository. JADS Wer Jasmine nicht "nur" als Speichersystem für persistente Objekte einsetzen möchte, der wird sich über JADS freuen. Das Jasmine Application Developement Studio dient sowohl der Datenbankwartung als auch der Applikationsentwicklung. In die objektorientierte "Datenbankwartung" fällt mehr als die Datendefinition; hier werden bei einem ODBMS auch Methoden definiert, die die Grundlage für spätere Benutzeraktionen legen. Diese Definitionen sind daher applikationsspezifischer und weitaus wichtiger als bei einem RDBMS. Während bei der DB-Definition nun auch applikationsspezifische Skills notwendig werden, benötigt man im zweiten Anwendungsfall, der Client-Programmierung, immer weniger Fachwissen. Da der Client - mit JADS im Nu entwickelt - extrem wenig "Intelligenz" besitzt und eigentlich nur Serverobjekte und -methoden anstoßen sollte, können hier auch Mitarbeiter aus Fachabteilungen eingesetzt werden. Das eigentliche Know-how der Applikation liegt ja im Server. Für Windows-spezifische Medientypen erweitert JADS das Repertoire von Jasmine um neue Klassen mit passenden Methoden. So sind etwa Widgets (Knöpfe, Felder, Dialogelemente) ebenso als Objektklassen enthalten, wie Töne, Bilder und Videos. Daß die passenden Abspielmethoden - auch für Streaming-Datentypen passend zur Verfügung stehen, versteht sich fast von selbst. Die Entwicklung wird zum Kinderspiel - gut so, solange man nicht vergißt, daß dafür in der Datendefinition bei weitem mehr Skills als bei einem RDBMS notwendig sind. Ereignisse und Reaktionen der Anwendung werden einfach mit der Maus festgelegt - sofern die notwendigen Methoden in der Datenbank vorhanden sind. Ist die Datenbank richtig und vollständig definiert, wird die Programmierung des Clients weitaus einfacher als etwa mit Delphi oder Visual Basic - zwischen PowerBuilder und JADS liegen Welten. JADS scheint "trotteleinfach", flexibel und effektiv zu sein - solange die Datenbank perfekt definiert wurde. JADS erstellt danach vollautomatisch aus einer Anwendungsdefinition einen Client. Oder aber, man möchte die Anwendung im Webbrowser verwenden. Dann verwendet Jasmine ein Plug-In für den Browser (MS IE und Netscape unter Windows), das die Web-Anwendung "in den Browser bringt". Am interessantesten dürfte aber die letzte Variante sein - CGI/HTML. JADS generiert automatisch ein ausführbares Modul für einen Windows-NT Webserver, der die Datenbankapplikation mit Hilfe normaler HTML-Anweisungen darstellt. Jeder Browser kann auf diese Applikation zugreifen, ohne JAVA, JAVAScript, VBScript und ohne PlugIn. Alternativ zu JADS kann die Datenbank auch direkt in JAVA - als persistenter Objektspeicher - auch vom Client aus angesprochen werden. Gerade dieser Anwendungsfall kann die Erstellung geplanter JAVA-Projekte deutlich erleichtern. Allerdings verliert der Entwickler fast alle beworbenen Multimedia-Fähigkeiten von Jasmine - diese liegen nämlich in JADS. Entwicklung - mit RDBMS Nach Projektbeginn wird das Zielsystem mit geeigneten Methoden modelliert. Heutzutage sind dies meist objektorientierte Techniken, etwa OOA/OOD nach Coad und Yourdan. Diese Techniken kommen heute oft auch dann zum Einsatz, wenn nicht alle Tools, Programmiersprachen, DBMS usw. objektorientiert sind. Dann aber müssen die objektorientierten Designs auf die "konventionellen" Tools abgebildet werden. Zum Beispiel werden RDBMS meist mit einem EER modelliert, das nicht ohne weiteres aus einem OOA erstellt werden kann. Das ist deshalb schwierig, weil nicht alle Verbindungstypen des OOA im EER und nachher im RDBMS möglich ist. Ein Beispiel dafür ist die "whole-part" oder "ganzes-teil" Beziehung, die darstellt, daß ein Objekt Teil eines anderen sein kann (eine Schraube ist Teil eines Autos). Diese Beziehung kann in einem RDBMS nicht dargestellt werden, sondern wird zu einer "normalen" Relation. Beim Realisieren in einem OO-Tool (Delphi, C++, PowerBuilder,...) werden dann sehr wohl OOA-Objekte direkt modelliert. Ihnen fehlt aber die direkte Entsprechung in der DB. Ein Objekt ist oft über viele Entitäten/Tabellen verteilt. Daten eines Objekts müssen über mehrere Zugriffe beschafft werden, und beim Rückspeichern in ebenso viele verschiedene Tabellen zurückgeschrieben werden. Dabei benötigt man für jede Tabelle einen eigenen DB-Zugriff, was die Logik für den Objektabbau extrem aufbläht. Diese Notlösungen verbrauchen oft bis zu 30% der Realisierungszeit! - mit Jasmine/ODBMS Hier kann gleich nach dem OOA/OOD die Datenbank modelliert werden. Die Methoden werden in der DB modelliert, nur wenig ragt aus der Datenbank heraus. Das Holen und Rückspeichern der Daten in die Applikationsobjekte des Clients ist mit jeweils einer einzigen Zeile erledigt. Alle Beziehungen des OOA können in der Datenbank modelliert werden! Durch diese positiven Eigenschaften verkürzt sich die Realisierung UND die Designphase jeweils um ca. 30%. Ein EER wird ja nicht mehr erstellt. Als Nachteil sei nur die langsamere Performance genannt. Beim mengenorientierten Zugriff kann die Performance gegenüber einem RDBMS nachhinken, beim navigierenden Zugriff auf komplexe Objekte ist Jasmine dem RDBMS klar überlegen. - mit ORDBMS Die ORDBMS sind meist RDBMS mit "Objekt-Emulation". In diesem Bericht kommen sie nicht vor, weil sie mir ODBMS nicht vergleichbar sind - Werbestrategen sehen das naturgemäß anders. Mit ORDBMS können nicht alle möglichen Relationen und Objekttypen eines OOA in der DB abgebildet werden. Dafür kann der Programmierer mit geeigneten Zugriffsmethoden leichter zugreifen als mit RDBMS. Die Eleganz der ODBMS-Entwicklung fehlt jedoch. Dafür ist die Performance beim mengenorientierten Zugriff eher RDBMS-ähnlich. RDBMS Traditionell werden heute, sobald man von "Datenbank" spricht, relationale Datenbanksysteme, sogenannte RDBMS, gemeint. Diese "Relational DataBase Management Systems" arbeiten mit einer mengenorientierten Datensichtweise. Daten werden nach gemeinsamen Kriterien (Eigenschaften) in Tabellen geordnet, ähnlich einem Spreadsheet. Dabei ist eine Zeile eine zusammengehörende Einheit, ein Datensatz (row/record). Oft ist diese Zeile auch gleichbedeutend mit einer Entität, aber nicht immer. Diese Zeile hat Spalten, in der die jeweiligen Eigenschaften stehen. Verarbeitet werden immer Datenmengen anhand von gleichen Kriterien, etwa alle Zeilen mit einem bestimmten Wert in einer bestimmten Spalte. Beispielsweise alle Personen, die im Jahr 1950 geboren worden sind. Eine solche Abfrage hat als Ergebnis wieder eine Datenmenge, die weiter eingeschränkt werden kann. Prinzipiell ist ein solches Ergebnis wieder wie eine Tabelle in Zeilen und Spalten strukturiert, wobei nicht alle Spalten übernommen werden (Abstraktion), und nur die dem Selektionskriterium entsprechenden Zeilen eingeschlossen werden. Im Beispiel könnte man eine einspaltige Tabelle, die nur Namen enthält als Ergebnis anfordern. Die Anwendungslogik der Applikation ("Intelligenz") liegt nicht in der Datenbank, sondern in der Applikation. Ein RDBMS ist eigentlich "nur" ein Datenspeicher, der alles aufnimmt, was ihm serviert wird - sofern es bestimmten festgelegten Kriterien genügt. ODBMS wie Jasmine Beim ODBMS hingegen ist vieles anders. Gemäß den Forderungen der Objektorientierung enthält die Datenbank Objekte, die aus Klassen abgeleitet werden. Diese Klassen enthalten - ähnlich wie die Tabellendefinitionen eines RDBMS - Eigenschaften. Intuitiv richtig ordnet man einer Klasse aus dem OOA/OOD nach Coad/Yourdan eine DB-Klasse zu, die die gemeinsamen Eigenschaften strukturiert. Gleichzeitig kann man aber für einen eingeschränkten Kreis, etwa den Kunden unter den Personen, eine eigene Klasse ableiten. Diese "Kunden" haben dann alle Eigenschaften einer Person, aber zuzüglich noch einige weitere Attribute, z.B. die Kundennummer. Diese spezielle Ableitung benötigt keinerlei Referenzen oder Fremdschlüssel, sie ist eine Vererbung. In einem RDBMS müßte man eine neue Tabelle definieren, und alle Programme vorbereiten, um Kunden wie Personen zu behandeln. Im ODBMS hingegen werden automatisch Kunden von allen Softwarekomponenten verarbeitet, die auch Personen verarbeiten - ohne jedoch Rücksicht auf die speziellen Eigenschaften von Kunden zu nehmen. Selbstverständlich unterstützt Jasmine Operator-Overloading. Die Definition der Klassenstruktur ("Klassenhierarchie") ist daher auch die aufwendigste beim ODBMS-Datendesign. Oft kann man aber schon auf ein OOA/OOD zurückgreifen, das bereits vorliegt. Implementiert man dieses direkt, fällt die ganze Datenbankdefinition weg. Aber ein Objekt besteht nicht nur aus Daten. Objekte enthalten - per definitionem - auch Methoden, sprich ausführbaren Code. Diese Methoden ermöglichen es, Programmteile in die Datenbank zu integrieren. Zum Beispiel kann das Abfragen der Lieferungen mit einem bestimmten Preislimit als Methode der Klasse "Lieferung" modelliert werden. Diese Methode ist Bestandteil der Datenbank; sie wird im Server ausgeführt, und nur das Ergebnis wird zum Client übertragen. Weitaus wichtiger ist dabei jedoch, daß die Skills zur komplexen Funktionsmodellierung nur bei der Server-Entwicklung angewandt werden. Der Systemkern einer Applikation kann somit von OO-Gurus am Server entwickelt werden, die hochbezahlt ihre professionellen Skills einbringen. Die Client-Komponenten hingegen verarbeiten kaum noch Daten, sondern stoßen lediglich die richtigen Methoden im Server an. Für den Client-Bereich können eventuell sogar Mitarbeiter aus Fachabteilungen eingesetzt werden, die kaum spezialisierte EDV-Kenntnisse benötigen. Eine weitere Anwendung für ODBMS ist die Rolle als "persistenter Objektspeicher". Das ODBMS dient als Zustandsspeicher für Programmier-Objekte der Applikation. Technisch wird jedes Objekt der Applikation aus einer Persistenz-Klasse abgeleitet, die vordefinierte Methoden wie "Create from Key" oder "Store away" enthält. Diese Methoden erlauben es entweder, ein Programm-Objekt als Abbild eines DB-Objektes zu kreieren, beziehungsweise eine Programm-Objekt in das ODBMS zu speichern. Eigentlich wird nur der Zustand gespeichert, so daß nachher wieder ein Programm-Objekt als Abbild des ODBMS-Objekts generiert werden kann.