relationalen auf ein objektorientiertes Technische Universitat Munchen

Transkript

1 Published in: Mayr H. (Ed.): Beherrschung von Informationssystemen, Proc. Jahrestagung der Gesellschaft fur Informatik (GI), in Klagenfurt, Oldenbourg-Verlag 1996, pp (best paper award). Ausgezeichnet mit dem Software-Engineering-Preis 1996 der Ernst-Denert-Stiftung. Auswertung der Migration eines Multimedia-Informationssystems von einem relationalen auf ein objektorientiertes Datenbanksystem Gunther Specht, Michael Hofmann Institut fur Informatik, Technische Universitat Munchen Orleansstr. 34, D Munchen Zusammenfassung Bei vielen Informationssystemen stellt sich heute die Frage der Migration von relationalen auf objektorientierte Systeme. Wir haben ein Multimedia-Informationssystem, basierend auf einem relationalen Datenbanksystem als Medien-Server, auf ein objektorientiertes Datenbanksystem migriert. Dabei war nicht nur eine Modellmigration und eine Schemamigration notwendig, sondern auch eine Programm- und Benutzeroberachen- Migration sowie eine Datenmigration, da auf diesem Informationssystem bereits eine Fulle an Anwendungen, vom medizinischen Bereich bis zu Stadtinformationssystemen, entwickelt worden waren. Wir wollen in diesem Artikel kurz die gewahlte Migrationstechnik vorstellen, entstandene Schwierigkeiten aufzeigen, das Altsystem mit dem neuen, objektorientierten System ausfuhrlich vergleichen und insbesondere durch eine Performanzuntersuchung eine Entscheidungshilfe fur die Rentabilitat ahnlicher Migrationen multimedialer Informationssysteme geben. 1 Motivation Bei vielen Informationssystemen stellt sich heute die Frage der Migration von relationalen auf objektorientierte Systeme. Wir hatten ein Multimedia-Informationssystem, das vor drei 233

2 Jahren auf einem darunterliegenden kommerziellen relationalen Datenbanksystem entwickelt wurde. Dieses datenbankgestutzte Informationssystem ist in vielen verschiedenen Anwendungen von der Medizin bis zu Stadtinformationssystemen im Einsatz. Von einer Migration auf ein objektorientiertes Datenbanksystem als Medien-Server versprachen wir uns in erster Linie Vorteile bei der Wartung und Weiterentwicklung der bestehenden Anwendungen. Die Migration ist inzwischen seit einem halben Jahr fertiggestellt. Dabei traten zum Teil uberraschende Ergebnisse hinsichtlich der Speicherung der Multimedia-Objekte und der Links, der Programmcodelangen, der Performanz, der Eignung bezuglich Linkverfolgung im Hypermedia-Netz und der Eignung bezuglich komplexer Suchanfragen, einschlielich Volltextqueries, auf. In diesem Papier wollen wir die Erfahrungen und Ergebnisse dieser Migration auswerten. Dazu zahlt sowohl eine kurze Beschreibung des gewahlten Migrationsverfahrens und seines Aufwands als auch eine ausfuhrliche Gegenuberstellung des relationalen Altsystems gegenuber dem neuen objektorientierten System, um schlielich herauszunden ob und wann sich dieser Aufwand fur datenbankbasierte Hypermedia-Informationssystemelohnt: ist die Migration Mode oder Notwendigkeit? Wir unterscheiden dabei sorgfaltig zwischen allgemeingultigen Ergebnissen und systemspezischen Ergebnissen. Konkret handelte es sich umdasmultimediale Informationssystem MultiMAP, das vom kommerziellen relationalen Datenbanksystem TransBase (TransAction AG, Munchen) auf das kommerzielle objektorientierte Datenbanksystem O 2 (O 2 -Technology, Versailles) einschlielich der Medizin-Anwendung migriert wurde. Die wesentlichen Ergebnisse sind aber systemunabhangig, da sowohl die Zugrisschnittstellen jeweils den aktuellen Standards folgen (SQL-2, bzw. OQL von O 2 dem ODMG-93 Vorschlag [3]) als auch diesysteme selbst sich bezuglich Verhalten und Performanz als gute Reprasentanten der jeweiligen DB-Modelle eignen. Die Verwendung einer Datenbank fur ein Multimedia-Informationssystem bietet gegenuber rein le-basierten Techniken (wie z.b. WWW) eine Reihe von Vorteilen wie z.b. Konsistenz, eziente Zugrispfade, transaktionsgeschutzer Mehrbenutzerbetrieb, Recovery, Versionsverwaltung und eziente und einfache Verwaltung auch sehr groer Datenmengen, wie sie in unseren Multimedia-Anwendungen haug auftreten. Auf dem zu migrierenden Multimedia-Informationssystem wurden bereits eine Vielzahl von Anwendungen erstellt: 234

3 MultiMAP: Eine System fur multimedial aufbereitete Landkarten und Stadtplane fur Stadtinformationssysteme, Biotopkartierungen oder auch im administrativen Bereich fur Raumordnungsverfahren. MultiMED: Ein System im medizinischen Bereich fur multimedial aufbereite Rontgenbilder einschlielich Detailbilder und verbaler oder textlicher Befunde. Ein Anschlu an die Stationsdatenbank ist integriert ([27]). MultiBHT: Ein System fur Linguisten zur Speicherung und Aufbereitung von Ergebnissen der Sprachanalyse mit dem Ziel der Erstellung korrekter Grammatiken und textkritischer Editionen semitischer Sprachen ([26]). MultiLIB: Ein multimedialer Fuhrer durch die Universitatsbibliothek und ihre Auenstellen und Zweigbibliotheken der LMU Munchen. Zwei weitere Systeme, MultiSTUD und MultiVO fur interaktiv, multimedial abrufbare Vorlesungen an der TU Munchen, sind bereits geplant. Eine Migration eines komplexen Informationssystems mit so unterschiedlichen Anwendungsgebieten, einschlielich der Migration der bestehenden Programme und Daten ist keine triviale Aufgabe. Sie kann nicht nebenbei erledigt werden sondern stellt eine wohluberlegte Investition dar. Dieses Papier gliedert sich wie folgt: In Kapitel 2 wird das gewahlte Migrationsverfahren vorgestellt. Die Migration teilt sich auf in eine Modellmigration mit anschlieender Schemaerzeugung, eine Programm- und Benutzeroberachen-Migration und in eine Datenmigration. In Kapitel 3 vergleichen wir das relationale Altsystem mit dem migrierten, objektorientierten System und gehen dabei insbesondere auf die unterschiedliche Eignung bezuglich Hypermedia-Anforderungen ein. Eine Zusammenfassung in Kapitel 5 soll schlielichdiefra- ge beantworten, ob wir ein zweites Mal migrieren wurden oder nicht. 235

4 2 Migrationstechnik 2.1 Uberblick und Auswahl der Migrationstechnik Bei der Migration von einem relationalen zu einem objektorientierten Informationssystem sind verschiedene Ansatze je nach Tiefe der Migration moglich: 1. Die darunterliegende relationale Datenbank wird beibehalten und um eine objektorientierte Programmierschicht aufgestockt, so da nur die oberen Schichten des Informationssystems migriert werden. Dieser Ansatz beinhaltet dann zwar noch einen internen Modellwechsel, meist verbunden mit einer Prozegrenze, erfordert aber keine teure Schema- und Datenmigration. (vgl. z.b. [12]). 2. Das Datenbanksystem und das darauf aufsetzende Informationssystem werden migriert, jedoch nur oberachlich, indem stur aus allen Relationen Klassen gemacht werden und nur die automatisch erkennbaren funktionalen Abhangigkeiten in oo-konstrukte (komplexe Attribute, Hierarchien etc.) umgesetzt werden. Dieser Ansatz wird in [11] als \oberachliche Migration" bezeichnet, im Gegensatz zur sogenannten Tiefenmigration. Er ist schneller und gunstiger zu erstellen, nutzt aber nicht die eigentliche Machtigkeit objektorientierter Systeme sondern simuliert im Grunde ein relationales System auf einer Objektbank. 3. Bei der Tiefenmigration werden sowohl Datenbanksystem (und damit auch die Daten) als auch das darauf aufsetzende Informationssystem migriert, wobei eine vollstandige Modellmigration durchgefuhrt wird. Ziel ist, ein so gutes OO-System zu erzeugen, wie wenn das Sytemem gleich objektorientiert speziziert worden ware. Die Tiefenmigration ist die aufwendigste Migration und kommt oft einem Neuentwurf vieler Teile gleich. Innerhalb der Tiefenmigration gibt es im wesentlichen zwei verschiedene Ansatze, die Modellmigration und die Schemamigration. (a) Modellmigration: Ausgangspunkt der Migration ist das ER-Modell, das in ein entsprechendes Objektmodell (z.b. OMT) uberfuhrt wird. Aus dem Objektmodell kann dann Tool-unterstutzt das oo-schema generiert werden (vgl. z.b. [22]). Das ER-Modell liegt entweder als Dokumentation bereits vor oder kann durch \rever- 236

5 se engineering" ([4, 14]) aus dem relationalen Datenbankschema wiedergewonnen werden. (b) Schemamigration: Ausgangspunkt ist das relationale Datenbankschema und die Umsetzung wird mit Hilfe von Zusatzinformationen aufgrund der im Schema enthalten Angaben zu Fremdschlusseln, funktionalen Abhangigkeiten, Typaquivalenzen, etc. direkt in ein oo-schema umgesetzt, ohne uber das ER-Modell und Objektmodell zu gehen. (vgl. z.b. [9]). Wir haben die Technik der vollstandigen Tiefenmigration uber die Modellmigration gewahlt, wobei uns das ER-Modell bereits aus der Dokumentation des Altsystems vorlag. Als Zielmodell bieten sich alle gangigen oo-modellierungsformalismen an. Das Ergebnis sollte davon unabhangig sein. Zur Auswahl stehen: Object-oriented Desgin von Grady Booch [2], Object-oriented Software Engineering von Ivar Jacobson [16], Object-oriented Analysis and Design von Peter Coad und Edward Yourdan [5, 6] Object Modeling Technique (OMT) von James Rumbaugh [23] und die Fusion Method von Derek Coleman, Patrick Arnold u.a. [7]. Da sich das OMT von Rumbaugh sehr stark am ER-Modell orientiert, und entsprechende Schemagenerierungstools vorlagen, haben wir diesen Formalismus gewahlt (vgl. Abb. 1). E/R Modell OMT Dokumentation oder reverse eng. relationales Schema CASE-Tools objektorientiertes Schema Abbildung 1: Migrationsvorgang 2.2 Modellmigration und Schemaerzeugung Das Zielmodell: OMT Das OMT besteht aus drei Einzelmodellen: einem Objektmodell, einem dynamischen Modell und einem funktionalem Modell. Das Objektmodell beschreibt die Klassen- und Datenstruk- 237

6 tur auf der das dynamische und das funktionale Modell arbeiten. Es beschreibt die statische Struktur der Objekte und ihre Beziehungen zueinander. Das dynamische Modell beschreibt die Kontrollstruktur der Objekte und damit die Aspekte, die zeitlichen Veranderungen unterliegen. Das funktionale Modell beschreibt den Datenu innerhalb des Systems. Alle drei Modelle zusammen bilden die orthogonalen Teile der Beschreibung der kompletten Anwendung, wobei das Objektmodell das wichtigste ist Umsetzung von Entities auf Klassen Da das ER-Modell nur statische Beziehungen darstellt und keine dynamischen Elemente enthalt, ist nur ein direkter Ubergang vom ER-Modell auf das Objektmodell moglich. Die restlichen zwei Modelle sind nicht aus dem ER-Modell ableitbar (aber auch nicht so essentiell). Eine automatische Umsetzung des ER-Modells auf das Objektmodell, in der u.a. alle Entities auf Klassen umgesetzt werden, ist nur bedingt moglich, da das ER-Modell keine vollstandige Vererbungsinformation beinhaltet. Aus diesem Grund mu nach einer automatischen Transformation das Objektmodell noch nachbearbeitet werden. Um den Vorteil der Vererbung und die naturliche Beziehung der Klassen untereinander wieder zu erhalten mu die Struktur, die bei der Modellierung des ER-Modells zerschlagen worden ist, wieder hergestellt werden. Dazu werden achgedruckte Attribute (1. NF), funktionale Abhangigkeiten, Existenz-abhangigkeiten, 1:n und isa-beziehungen und Gemeinsamkeiten in der Attributnamenswahl und der Attributtypisierung ausgewertet. Auch hierkonnen Techniken des reverse engineering unterstutzend eingesetzt werden Umsetzung der Relationships in Assoziationen Entscheidend fur die Ezienz des Systems ist die jeweils gewahlte Art der Umsetzung der Objektbeziehungen, wir wollen sie daher hier etwas ausfuhrlicher diskutieren. Beziehungen werden durch Assoziationen ausgedruckt. Diese haben eine Richtung und eine Funktionalitat. Richtungen der Assoziationen a) one-way Assoziationen Komplexe Strukturen konnen auf zwei Arten in OO-Systemen dargestellt werden: Man kann die komplexe Struktur selbst eintragen (Adresse: tupel(strae: string, Wohnort: 238

7 string)) oder man tragt eine eigene Klasse, die dieser Struktur entspricht (Adresse: Klasse Adresse) ein. Durch die erste Variante wird der Verweis zu einem Teilwert des Objekts und ist ohne das Objekt nicht existenzfahig. Wird das Objekt geloscht, so geht auch der Teilwert verloren. In der zweiten Variante wird ein Objekt referenziert, dessen Existenz nicht vom Vorhandensein des referenzierenden Objekts abhangt. Auf diese Weise wird ein Objekt, auf das mehrfach verwiesen wird, nicht redundant gespeichert. Wegen dieser Vorteile haben wir bei one-way Assoziationen nur mit Referenzen auf Objekte gearbeitet. b) two-way Assoziationen Assoziationen, die in beide Richtungen verlaufen, konnen auf drei Arten modelliert werden: 1. als Attribut in nur einer Klasse: Das referenzierte Objekt wird als Attribut in einer Klasse aufgenommen. Diese Vorgehensweise ist dann sinnvoll, wenn der Verweis besonders oft in der angegebenen Richtung verfolgt wird. Fur die entgegengesetzte Richtung mu eine entsprechende sequentielle Suche stattnden. 2. als Attribut in beiden Klassen: Die sich gegenseitig referenzierenden Objekte werden in der jeweils anderen Klasse als Attribut aufgefuhrt. Auf diese Weise kann der Verweis in beiden Richtungen sehr schnell verfolgt werden. Der Nachteil dieser Methode liegt darin, da der Programmierer selbst die Verweise konsistent halten mu. 3. als Referenz-Objekt in einer eigenen Relationship-Klasse: In einem Referenz-Objekt werden analog einer Relationship-Relation die Verweispaare gespeichert. Diese Art der Modellierung ist nur in Ausnahmefallen empfehlenswert z.b. bei Verweisen auf Systemklassen, die ja nicht verandert werden konnen oder bei Verweisen, die nur von ganz wenig Objekten einer Klasse benutzt werden. Dann spart man Speicherplatz, da nur fur die Verweise, die auch benotigt werden, Platz bereitgehalten wird. 239

8 Funktionalitaten der Assoziationen 1:1 Beziehungen: Sie konnen wie im Relationenschema auf zwei Varianten transformiert werden, entweder als zwei Klassen mit gegenseitigen Objektreferenzen oder als eine komplexe Klasse. 1:n Beziehungen: Oft entsprechen 1:n Beziehungen is-a oder has-a Hierarchien und sollten entsprechend umgesetzt werden. Ansonsten gilt: Wahrend bei der relationalen Umsetzung auf der n-seite der Beziehung eine Spalte fur den Fremdschlussel eingefugt wird, sollte im Objektmodell die Beziehung in der Klasse gespeichert werden, von der die meisten Zugrie ausgehen. Ist dies die n-seite, so bleibt alles wie gehabt, ist dies aber die 1-Seite, so wird ein mengen- oder listenwertiges Attribut mit den referenzierten Objekt-Identikatoren (OID) eingefugt. m:n Beziehungen: Sie sollten nicht in eigene Relationship-Klassen umgesetzt werden, sondern aufgelost, uber mengenwertige OID-Referenzen, bei den entsprechenden Objekten abgelegt werden (Ausnahmen siehe oben) CASE-Tools zur Generierung des OO-Schemas aus dem OMT Zur Unterstutzung der Modellentwicklung gibt es verschiedenste Tools mehrerer Software- rmen und Universitaten. Einige bieten nur einen grascher Editor mit dem man Objektdiagramme erstellen kann an, andere setzen halbautomatisch ER-Modelle in Objektmodelle um. Diese unterscheidet man in Transformatoren, wenn sie auf der graphischen Darstellung arbeiten, und in Generatoren, wenn sie auf einer formalisierten Reprasentation aufsetzen. Schlielich gibt es noch eine Reihe an Tools die aus dem Objektmodell Code-Schablonen fur die Klassendenitionen in C++, CLOS oder Smalltalk erzeugen. Letztere haben sich bei unserer Migration am nutzlichsten und brauchbarsten erwiesen. 2.3 Programm- und Benutzeroberachen-Migration Inharent haben wir bei der Modellmigration nicht nur das Datenbankschema migriert, sondern den gesamten Kernel des Multimedia-Informationssystems, der darauf aufsetzt. Modellmigration und Programm-Migration liefen also in einem Schritt verzahnt ab. Anders verhielt es sich bei der Benutzeroberachen-Migration. Zwar hatten wir es nach wievor mit einer 240

9 X-Oberache und Motif zu tun, jedoch kam die Einbindung der vom verwendeten objektorientierten Datenbanksystem O 2 zur Verfugung stehenden Klassen des O 2 -Look-Widgets einer Neuimplementation gleich. Verstandlicherweise greifen hier die diskutierten Transformationsformalismen am wenigsten. 2.4 Datenmigration Die aus der Modellumsetzung gewonnene Schema-Transformation lat sich leicht in ein Konvertierungsprogramm fur die Daten umsetzen. Als praktische Erfahrung hat sich gezeigt, da die Datenumsetzung bei einer typischen Datenbankgroe von ca. 2 GigaByte nicht lokal moglich ist. Auf einer typischen Workstationdatenbank konnen uber 2000 Bilder, die eine durchschnittliche Groe von etwa 0.77 MByte haben, gespeichert werden. Zur Umsetzung wird dann ein 2 GigaByte groer Spoolbereich und ein 2 GigaByte groer Bereichfur die objektorientierte Datenbank benotigt. Diese Konvertierung kann durch ein NFS-System sehr stark vereinfachtwerden, wobei jedoch eine sehr hohe Netzlast wahrend der Umsetzung auftritt. 3 Vergleich von Altsystem und Neusystem 3.1 Anforderungen von Multimedia-Systemen an den Medien- Server Hypermedia-Anwendungen sind von Natur aus sehr speicherintensiv. Dabei werden nicht nur sehr viele, sondern auch sehr groe Datenobjekte gespeichert (Bilder, Audiodateien, Videosequenzen, Volltexte, etc.). Das stellt hohe Anforderungen bezuglich Flexibilitat, Ezienz, Indexunterstutzung, Optimierungen, intelligentes Caching und eektive Speicherausnutzung an das Datenhaltungssystem. Insbesondere mussen sowohl eine schnelle Suche uber komplexe Suchpradikate als auch eine schnelle Navigation durch Linkverfolgung moglich sein. Objektorientierte Datenbanken wurden entwickelt um komplex strukturierte Objekte einschlielich ihrer Methoden zu speichern. Dieser Ansatz ist machtiger als die rein BLOBorientierte Speicherung von Multimedia Objekten in relationalen Systemen. Fur den Entwickler ist es bedeutsam, inwiefern eine moglichst naturliche Formulierung im Datenmodell 241

10 unterstutzt wird und wie leicht es erweiterbar und modizierbar ist. Das verringert die Fehlerwahrscheinlichkeitundfuhrt zu niedrigeren Entwicklungskosten. Auf der anderen Seite ist es fur den Endbenutzer von besonderer Bedeutung wie schnell im System auf Bilder und Texte zugegrien werden kann. Wahrend die objektorientierten Datenbanksysteme von sich behaupten die Anforderungen der Entwickler gut zu erfullen, haben wir bei der Endbenutzeranforderung nach Ezienz schlechtere Erfahrungen gesammelt. Wir wollen in diesem Kapitel diese Kriterien genauer auf relationale und objektorientierte Multimedia-Informationssystemeanwenden um die Vor- und Nachteile, die man sich mit einer Migration erkauft, genauer herauszustellen. Zuerst werden wir kurz die fur alle Anwendungen relevanten Punkte zusammenstellen und dann in 3.3. OODBS und RDBS bezuglich der spezischen Punkte fur Hypermedia-Systeme vergleichen. 3.2 Allgemeiner Vergleich von OODBS und RDBS Vorteile der OODBS gegenuber RDBS: Die Vorteile objektorientierter Modellierung und Programmierung sind oft genug herausgestellt worden. Sie werden hier nur der Vollstandigkeit halber kurz aufgelistet, sofern sie fur unsere Migration entscheidend waren. Naturlichere Codierung durch Klassenhierarchien (man denke nur an die verschiedenen Bildtypen), Vererbung und Methoden Abstrakte Datentypen Speicherung des Source-Code und damit Concurrency, Recovery und Versionskontrolle auch uber Methoden Moglichkeit der Speicherung von aktivierbaren Objekten Deutlich weniger Objektkopien in temporare Speicher Aufgrund der Transparenz von Anwendungsprogrammierung und Datenbankprogrammierung besteht keine Notwendigkeit Daten zur Bearbeitung in den temporaren Speicher der Anwendung zu kopieren, um sie dann in der Hostsprache zu bearbeiten. 242

11 Viele Methoden konnen in der Datenbank direkt ausgefuhrt werden. Anderungen im Adressraum, in dem sich auch die Daten benden, sind um den Faktor schneller als Anderungen, die uber Prozegrenzen hinweg erfolgen. Sofortige Typuberprufung Wahrend bei OODBS aufgrund der Identitat von Host- und Retrievalsprache eine sofortige Typuberprufung stattnden kann, kann bei relationalen Sprachen erst innerhalb der Transaktion die Typuberprufung der SQL-Query stattnden, die von der Hostsprache als "SQL-String" ubergeben wurde. Entsprechend sind umstandliche Fehlerabfangroutinen notwendig. Diesen Vorteilen stehen aber auch einige Nachteile gegenuber. Nachteile der OODBS gegenuber RDBS: Fehlende Algebra Mit OQL ist eine SQL-Variante als Query Sprache fur OODBS deniert worden, jedoch fehlt eine Algebra fur diese Query-Sprache. Algebren mit ihren Gesetzen sind eine gute mathematische Grundlage fur eektive und eziente Optimierer. Das fuhrt dazu, da objektorientierte Datenbanken bei nicht navigierenden Anfragen den relationalen Datenbanken weit unterlegen sind. Eingeschrankte Schema-Evolution Fast alle objektorientierten Datenbanksysteme reagieren auf Schema- Anderungen sehr empndlich. So ist zum Beispiel das nachtragliche Einfugen einer Klasse in die Vererbungshierarchie meist nur nach vorherigem ausspoolen und loschen aller Subklassen moglich. Keine Unterscheidung zwischen persistenten und temporaren Attributen In objektorientierten Datenbanken gibt es nur die Moglichkeit Klassen bzw. Objekte als Ganzes persistent oder temporar zu deklarieren, nicht jedoch einzelne Attribute. Werden Attribute nur fur temporare Zwischenergebnisse oder nur wahrend der Darstellung des Multimedia-Objekts am Bildschirm benotigt,sowerden sie bei der Speicherung des Objekts auch mit abgespeichert. Dies spielt insbesondere bei Dialog-Objekten eine Rolle, die oft eine lange Parameterleiste fuhren (siehe spater). 243

12 Hoher Arbeitsspeicherbedarf Ein O 2 -Clientbenotigt zum Beispiel ca. 10 MByte Arbeitsspeicher, ohne da eine einzige O 2 -Anwendung gestartet worden ist. Diese enorme System-Speicherbedarf fuhrt zu verstarktem Swapping und beeintrachtigt die Performanz der Datenbank stark. Es gilt allgemein, da objektorientierte Datenbanken gegenuber relationalen einen viel groeren Verwaltungsoverhead besitzen. Lange Compilezeiten Durch den hohen Arbeitsspeicherbedarf bei den objektorientierten Datenbanken werden auch die Compilezeiten bei der Anwendungsprogrammierung sehr stark erhoht. Workstations mit geringem Arbeitsspeicher werden somit zum standigen Swapping gezwungen. Hier wirkt sich die Trennung von Host- und Query-Sprache bei den RDBS positiv aus. Wahrend diese Vor- und Nachteile fur alle zu migrierenden Datenbankanwendungen gelten, wollen wir im folgenden ausfuhrlicher auf die speziellen Punkte bezuglich Hypermedia- Informationssystemen eingehen: 3.3 OODBS gegenuber RDBS im Bezug auf Hypermedia Naturlichere Umsetzung des Hypermedia-Modells Gerade Multimedia-Informationssysteme besitzten aufgrund der Topologie der verschiedenen Medienformate ausgepragte Vererbungshierarchien und eine Vielzahl von Verweisen. Beides lat sich in OODBS adaquater ausdrucken als in achen Relationen, die zudem durch die Normalisierung oftmals noch weiter aufgespalten werden Schnellerer Zugri bei der Linkverfolgung In relationalen Datenbanksystemen konnen aufgrund der rein symbolischen Darstellung der Daten keine Pointer gespeichert werden. So mu die Verfolgung eines Links uber Fremdschlusseljoins realisiert werden, die, indexunterstutzt, in den meisten Systemen eine Komplexitat der Ordnung m* log(n) besitzen. Demgegenuber erreicht die Ablage eines Links als (indirekter) Pointer in OODBS eine Komplexitat von O(1). Direkte Navigation uber Linkverfolgung ist also in OODBS sehr viel schneller als in relationalen. 244

13 3.3.3 Geringere Anzahl von Queries und Sperren Die notwendige Aufteilung zusammengesetzter Multimedia-Objekte auf mehrere Relationen in RDBS bringt Nachteile bezuglich der Update-Performanz mit sich. Um ein einfaches Multimedia-Objekt (wie zum Beispiel einen Info Block bestehend aus einem TIFF-Bild, einen ASCII-Text und einer Audiodatei) in die Datenbank aufzunehmen oder zu verandern mussen intern mehrere Subqueries gestellt werden, die jeweils Sperren fur alle benutzten Relationen (bzw. Seiten oder Tupel je nach Lock-Granularitat des Systems) anfordern. Dies kann bei mehreren Benutzern, die gleichzeitig mit der Anwendung arbeiten, zu einer erheblichschlechteren Update-Performanz der relationalen Datenbank fuhren (vgl. auch [25]) als bei OODBS, in denen man einen direkteren Zugri auf komplexe Objekte hat und die zudem meist auf eine feinere Sperrgranularitat zuruckgreifen konnen, da hier Locks auf Objektidentikatoren (OIDs) moglich sind Wesentlich kurzerer Programm-Code Die Lange des Programm-Code (gemessen in lines of code) der neuen, objektorientierten Variante der Multimedia-Datenbank erreicht nur 60 % des relationalen Altsystems bei gleicher Funktionalitat. Der enorm kurzere Code hat folgende Ursachen: Methodenvererbung: Weniger die Vererbung von Attributen als vielmehr der Aufbau einer geeigneten Methodenhierarchie und Vererbung trug zur Code-Reduktion erheblich bei. Kurzerer Datenbank-Zugriscode Reichhaltigere vordenierte Datenbank-Datentypen, wielist, set, string, etc. Inharente Verfugbarkeit von Objektidentikatoren: Jede Relation benotigt einen eindeutigen Schlussel. Dazu werden oft kunstliche Identikatornummern eingefuhrt. Die korrekte Vergabe dieser Identikatoren (ID) obliegt dabei dem Programmierer. Entweder wird dazu das Maximimum der bisherigen IDs berechnet und inkrementiert oder, ezienter aber redundanter, eine eigene Relation enthalt die nachste zu vergebende ID je Tabelle. Demgegenuber wird die gesamte Vergabe und Verwaltung von Objektidentitaten von OODBS inharent erledigt. 245

14 Einfachere Dialogerstellung: Informationssysteme sind hochinteraktiv. Unter einem Dialog verstehen wir im folgenden alles, was eine callback-funktion besitzt, also auch jeden Button oder maussensitiven Bereich. Selbst wenn derselbe Dialog (z.b. der Ende-Button eines Fensters) ofter am Bildschirm erscheint, steht dahinter verschiedener Code, da jeder Dialog fenster- und kontextabhangig ist. Darum sollte die Dialogerstellungsprozedur entsprechend parametrisiert sein. Die Anzahl der Parameter kann sehr gro werden, je nachdem wie machtig der Dialog ist. Da eine zu groe Anzahl von Parametern sehr schnell unubersichtlich und fehleranfallig wird, wird oft der Code entsprechend der Anzahl spater gleichzeitig am Bildschirm erscheinenden Dialoge kopiert und verandert. Bei der objektorientierten Programmierung ist dies nicht notig, da jedesmal beim Kreieren eines neuen Dialoges ein neues Objekt erzeugt wird. Die bei der prozeduralen Programmierung notwendigen Parameter entfallen hier, da sie als Klassenattribute schon vorhanden sind. Verwendung speziellerer Widgets: Dieser Punkt ist der einzige systemspezische. O 2 stellt sogenannte Look-Widgets fur die Fensterdarstellungen zur Verfugung. Da ein Look-Widget mit mehreren Eingabefeldern erzeugt werden kann, kann bei umfangreicheren Dialogen weiterer Code gespart werden Programmiererleichterung In objektorientierten Datenbanken sind keine Typkonvertierungen zwischen der Datenbank und der Programmiersprache notig, da die Typen der Datenbank genau denen der Programmiersprache (i.a. C++) entsprechen. Der Programmierer hat somit keinen zusatzlichen Aufwand mit eventuellen Typkonvertierungen. In OODBS besteht kaum ein Unterschied in der Programmierung zwischen persistenten und temporaren Objekten. Die Programmierung eines Updates auf ein persistentes Objekt ist bis auf den Transaktionsaufruf identisch zu dem einer Attributanderung eines temporaren Objekts. In relationalen Systemen mu dazu in zwei verschiedenen Sprachen (SQL und der Hostsprache) programmiert werden. Weiterhin besitzen relationale Datenbanksysteme nur ein paar elementare Datentypen. Dagegen haben objektorientierte Datenbanksysteme unter anderem verschachtelte Datentypen, 246

15 Mengen- und Listentypen. Wahrend bei einem C-Anschlu bei den relationalen Datenbanken zusammen mit embedded SQL diese zusatzlichen Datentypen selbst deniert werden mussen, kommt man bei den objektorientierten Datenbanken mit diesen vorgegebenen Datentypen bei fast allen Anwendungen aus. Es geht alsokeine zusatzlich Entwicklungszeit fur die Implementierung solcher grundsatzlichen Datentypen verloren Performanz-Tests Die Konguration beim Performanztest war in beiden Fallen die gleiche: Die Datenbankserver (genauer: der TransBase-Kernel sowie das zugehorige shared Memory und der O 2 -Server sowie der O 2 -Swapbereich) liefen jeweils auf derselben SUN Sparc SPARC Station 10 mit 32 MByte Hauptspeicher. Die Datenbankclients liefen auf SUN SPARC Classics mit 16 MByte Hauptspeicher. Vernetzt waren die Rechner uber eine lokale Ethernet-Netzbox, so da externe Netzlast ausgeschaltet werden konnte. Getestet wurde die Laufzeit bei folgenden Aktionen: Programmstart Neuanlegen, Laden und Andern eines wohldenierten zusammengesetzten Multimedia- Objektes, dem sogenannten Infoblock, bestehend aus einem TIFF-Bild (512x512 Pixel bei 256 Farben, 524 kbyte), variabel langen Text (hier im Mittel ca. 200 Bytes) und einer Audiodatei (hier im Mittel 30 sec, d.h. komprimiert ca. 100 kbyte) Neuanlegen und Andern eines Links Recherche nach einem Multimedia-Objekt mit Hilfe eines trunkierten Suchausdrucks Suche und Visualisierung aller Polygone auf einem Bild, die gleichzeitig Linkausgange sind. Jede Aktion wurde dreimal hintereinander ausgefuhrt. Bei gleichen Zeiten wird der Wert nur einmal angegeben. Die Spalte mit der Uberschrift rel bezeichnet das alte (relationale) MultiMED, oo steht fur das neue (objektorientierte) MultiMED und die dritte Spalte oo(500) gibt die Laufzeiten fur das neue MultiMED an, nachdem 500 Infoblocke in die Datenbank 247

16 eingespielt wurden. In beiden Fallen wurden die 500 Elemente mit jeweils 500 Transaktionen in die Datenbank geladen. Jedes dieser Elemente hatte eine Groe von ca. 200kB. Das Einspielen von 500 Bildern in das alte MultiMED, das ca. 8 Minuten benotigte, hat keine mebaren Veranderungen in der Laufzeit der Anwendung ergeben. Aus diesem Grund wird keine zusatzliche Spalte eingefuhrt. Im neuen MultiMED benotigte die Aufnahme der Elemente ca. 47 Minuten. Die folgende Tabelle zeigt die Ergebnisse der Laufzeittests: rel = rel(500) oo oo(500) Programmstart 8s, 4s, 4s 24s, 14s, 14s 23s, 14s, 14s Aufruf Dialog Infoblock neu <1s 5s 7s, 5s, 5s Transaktion Infoblockneu 5s, 2s, 2s 7s, 4s, 4s 16s, 10s, 10s Infoblock laden 3s, 2s, 2s 3s 4s, 3s, 3s Aufruf Dialog Infoblock andern <1s 4s 6s Transaktion Infoblock andern 3s, 2s, 2s 6s, 4s, 4s 9s, 7s, 7s Transaktion Infoblockloschen 3s, 2s, 2s <1s 1s Aufruf Dialog Link neu <1s 3s, 2s, 2s 4s, 2s, 2s Transaktion Link neu 2s, 1s, 1s 2s, 1s, 1s 3s, 1s, 1s Aufruf Dialog Link andern <1s 1s 1s Transaktion Link andern 2s, 1s, 1s 1s 1s trunkierte Suche <1s <1s <1s Zeigen aller Links im Bild <1s <1s <1s Die Aufruf-Dialog-Zeilen geben die Zeiten an, die ein Dialog braucht von der Aktivierung des Menupunktes bis zur Anzeige des Dialogs. Damit ist meist eine Lese-Anfrage an die Datenbank verbunden. Die Transaktions-Zeilen geben die Zeiten fur die Ausfuhrung der Aktionen an. Die lange Zeit, die das oo-system beim Start braucht, kommt durch zwei Faktoren zustande: der Verbindung des O 2 -Clients mit dem O 2 -Server und der Erstellung aller O 2 -Look-Widgets, wobei die Erstellung der Widgets den groeren Anteil ausmacht. Je mehr O 2 -Look-Widgets in einem Dialog verwendet werden, desto langer dauert es bis der Dialog angezeigt wird. Je einfacher ein O 2 -Dialog aufgebaut ist, desto geringer werden die Zeiten zur Anzeige des Dialogs. Erst ein einfacher O 2 -Dialog, wie zum Beispiel der Dialog \Link andern", wird fast so schnell wie ein reiner Motif-Dialog angezeigt. 248

17 Die Transaktionszeiten sind beim neuen MultiMED (leeres System) ein klein wenig geringer als beim alten System (bis auf die Transaktion Infoblock neu, bei der i.a. ein 4-facher Plattenzugri notig ist). Erst durch das Einspielen von 500 Bilder, Texte und Tonen ergibt sich ein gravierender Unterschied. Wahrend die Antwortzeiten beim alten MultiMED nahezu konstant blieben, verschlechterten sich die Zeiten beim neuen MultiMED ganz erheblich. Als Resultat lat sich zusammenfassen, da das objektorientierte MultiMED bereits bei einer kleineren bis mittleren Datenbank sehr viel langsamer als das relationale MultiMED ist. Die Unterschiede in der Dialoganzeige kann noch durch den Verzicht aufdieo 2 -Look-Widgets und einem entsprechenden Programmiermehraufwand ausgeglichen werden, nicht jedochdie unterschiedlichentransaktionszeiten der Datenbanksysteme. Dieses Resultat ist nicht auf O 2 beschrankt, wie ein bei uns erstellter Benchmark fur OODBS [17] und eine durchgefuhrte detaillierte Performanzstudie zu vier weiteren OODB Systemen (Objectstore, Versant, Objectivity und Ontos) zeigt [18]. 4 Zusammenfassung Wir haben fur ein bestehendes Multimedia-Informationssystem, auf dem eine Vielzahl von verschiedenartigen Anwendungen laufen, eine Tiefenmigration zu einem objektorientierten System durchgefuhrt. In diesem Zusammenhang wurde auch das darunterliegende Speichersystem, eine relationale Datenbank durch eine objektorientierte ersetzt. Fur diese Migration benotigten wir 1/2 Personenjahr. In diesem Artikel haben wir das neue, objektorientierte System dem Altsystem gegenubergestellt und ausfuhrlich verglichen. Ziel war es, herauszunden, ob sich die Migration gelohnt hat. Die beiden wesentlichen, uberraschenden Ergebisse sind: Erstens eine Einsparung des Codes auf 60 %. Das bringt enorme Vorteile hinsichtlichwartbarkeit und Weiterentwickelbarkeit des Systems. Diese Code-Einsparung spricht fur die Flexibilitat und die naturlichere Modellierung der Multimedia-Anwendung in einem objektorientierten System. Das zweite erstaunliche Ergebnis war die wesentlich schlechtere Performanz. Gerade Multimedia-Informationssysteme sind hochinteraktive Systeme und benotigen auch bei umfangreicher Bild- und Tonausgabe kurze Antwortzeiten fur eine groe Benutzerakzeptanz. Nur durch einige, nachtragliche Tricks, wie unter anderem der Vorabaufbau von Dialogboxen, die 249

18 nun zwischenzeitlich im Bildschirmhintergrund versteckt sind, konnten wir die Performanz gerade noch benutzerakzeptabel halten. Aus der Sicht der Arbeitserleichterung der Entwickler ist bei Multimedia-Datenbankanwendungen eine Migration auf objektorientierte Datenbanksysteme zu empfehlen. Sobald aber groere Datenmengen vorliegen und eine hohe Performanz als Endbenutzeranforderung unabdingbar ist und sobald ubliche Recherchen nichtnur einfache Linkverfolgung beinhalten, sondern auch komplexere Suchanfragen, Volltextsuche oder Anker als beliebige Polygone in Bildobjekten, ist von einer Migration heute noch abzuraten. Literatur [1] Bancilhon F., Delobel C., Kanellakis P.: Building an Object-Oriented Database System, The Story of O 2, Morgan Kaufmann Publishers, 1992 [2] Booch G.: Object Oriented Design: with Applications, Benjamin/ Cummings, 1991 [3] Catell R. (ed): The Object Database Standard: ODMG-93, Morgan Kaufmann Publishers, 1994 [4] Chiang R.H.L., Barron T.M., Storey V.C.: Reverse engineering of relational databases: extraction of an EER model from a relational database, Data & Knowledge Engineering 12, 1994, pp [5] Coad P., Yourdan E.: Object-Oriented Analysis, Prentice-Hall, 1991 [6] Coad P., Yourdan E.: Object-Oriented Design, Prentice-Hall, 1991 [7] Coleman D., Arnold P. u.a.: Object-Oriented Development: The Fusion Method, Prentice-Hall, 1994 [8] Elmasri R., James S., Kouramajian V.: Automatic class and method generation for objectoriented databases, Proc. 3rd DOOD 1993, Springer, LNCS 760, pp [9] Fahrner C., Vossen G.: Transformation relationaler Datenbankschemas in objektorientierte Schemas gema ODMG-93 Proc. Datenbanksysteme in Buro, Technik und Wissenschaft (BTW '95) Springer, Informatik aktuell, 1995 pp [10] Gogolla M. et al:integrating the ER Approach in an OO Environment, Proc. 12th ERA 1993, pp [11] Dittrich K.: Migration von konventionellen zu objektorientierten Datenbanken: soll man, mu man - oder nicht?, Wirtschaftsinformatik 35 (1993) 4, pp [12] Hahn W., Toenniesen F., Wittkowski A.: Eine objektorientierte Zugrisschicht zu relationalen Datenbanken Informatik Spektrum 18 (1995) pp

19 [13] Halasz F., Mayer Schwartz: The Dexter Hypertext Reference Model, Communications of the ACM37, 2(Feb. 1994), pp [14] Hainault J-L., Tonneau C., Joris M., Chandelon M.:Schema transformation techniques for database reverse engineering, Proc. 12th ERA 1993, pp [15] Heuer A.:Equivalent schemas in semantic, nested relational, and relational database models, Proc. 2nd MFDBS 1989, LNCS 364, pp [16] Jacobson I.: Object-Oriented Software Engineering, Addison-Wesley, 1992 [17] Kempe H., Kowarschick W., Kieling W., Hitzelberger R., Dutkowski F.: The OCAD Benchmark, FORWISS Report FR , Bayerisches Forschungszentrum fur Wissensbasierte Systeme, Munchen, 1995 [18] Kempe H., Kowarschick W., Kieling W., Hitzelberger R., Dutkowski F.: Benchmarking Object- Oriented Database Systems for CAD, Proc. 6th Int. Conf. on Database and Expert Systems Applications (DEXA'95), Springer, LNCS 978, 1995, pp [19] Khoshaan S., Abnous R.: Object Orientation: Concepts, Languages, Databases, User Interfaces, John Wiley & Sons Inc., 1990 [20] Khoshaan S., Baker A.: Multimedia and Imaging Databases, Morgan Kaufmann Publishers, 1996 [21] Markowitz V.M., Makowsky J.A.: Identifying extended Entity-Relationship object-structures in relational schemes, IEEE TSE 16, 1990, pp [22] Narasimhan B., Navathe S.B., Jayaraman S.: On mapping ER ans relational models into OO schemas, Proc. 12th ERA 1993, pp [23] Rumbaugh J.: Object-Oriented Modelling and Design, Prentice Hall, 1991 [24] Schutt, H., Streitz, N.: HyperBase: A Hypermedia Engine Based onarelational Database Management-System, GMD-IPSI, ECHT 1990, pp [25] Smith K., Zdonik S.: Intermedia: A Case Study of the Dierences Beetween Relational and Object-Oriented Database Systems, OOPSLA '87, acm press [26] Specht G.: MultiBHT - ein multimediales Datenbanksystem zur Sprachanalyse, Institut fur Informatik, Technischen Universitat Munchen, 1995 [27] Specht G., Bauer M.: MultiMED - ein Multimedia-Datenbanksystem zur Aus- und Weiterbildung in der Rontgendiagnostik in der Orthopadie in Schoop, Witt, Glowalla.: Hypermedia in der Aus- und Weiterbildung, UVK-Verlag, Konstanz, 1995, pp