relationalen auf ein objektorientiertes Technische Universitat Munchen

Größe: px
Ab Seite anzeigen:

Download "relationalen auf ein objektorientiertes Technische Universitat Munchen email: fspecht,hofmannmg@informatik.tu-muenchen.de"

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

3. Das Relationale Datenmodell

3. Das Relationale Datenmodell 3. Das Relationale Datenmodell Das Relationale Datenmodell geht zurück auf Codd (1970): E. F. Codd: A Relational Model of Data for Large Shared Data Banks. Comm. of the ACM 13(6): 377-387(1970) DBMS wie

Mehr

Objektorientierte Datenmodelle und - verwaltung

Objektorientierte Datenmodelle und - verwaltung Schlagworte der 90er: Objektorientiertes GIS OpenGIS Case-Tool Geoökologe Legt Problemstellung fest (Art, Anzahl, Dimension, Skalierung) Wählt Koordinatensystem Wählt Fachattribute OOUI (object-oriented

Mehr

6. Modellierung von Informationssystemen. 6.1 Einleitung 6.2 Konzeptuelles Modell 6.3 OASIS Spezifikation 6.4 Execution Model 6.

6. Modellierung von Informationssystemen. 6.1 Einleitung 6.2 Konzeptuelles Modell 6.3 OASIS Spezifikation 6.4 Execution Model 6. 6. Modellierung von Informationssystemen Spezialseminar Matr. FS 2000 1/10 Volker Dobrowolny FIN- ITI Quellen: Oscar Pastor, Jaime Gomez, Emilio Insfran, Vicente Pelechano The OO-Method approach for information

Mehr

Drei-Schichten-Architektur. Informatik B - Objektorientierte Programmierung in Java. Vorlesung 16: 3-Schichten-Architektur 1 Fachkonzept - GUI

Drei-Schichten-Architektur. Informatik B - Objektorientierte Programmierung in Java. Vorlesung 16: 3-Schichten-Architektur 1 Fachkonzept - GUI Universität Osnabrück Drei-Schichten-Architektur 3 - Objektorientierte Programmierung in Java Vorlesung 6: 3-Schichten-Architektur Fachkonzept - GUI SS 2005 Prof. Dr. F.M. Thiesing, FH Dortmund Ein großer

Mehr

mywms Vorlage Seite 1/5 mywms Datenhaltung von Haug Bürger

mywms Vorlage Seite 1/5 mywms Datenhaltung von Haug Bürger mywms Vorlage Seite 1/5 mywms Datenhaltung von Haug Bürger Grundlegendes Oracle9i PostgreSQL Prevayler Memory mywms bietet umfangreiche Konfigurationsmöglichkeiten um die Daten dauerhaft zu speichern.

Mehr

DATENBANKEN SQL UND SQLITE VON MELANIE SCHLIEBENER

DATENBANKEN SQL UND SQLITE VON MELANIE SCHLIEBENER DATENBANKEN SQL UND SQLITE VON MELANIE SCHLIEBENER INHALTSVERZEICHNIS 1. Datenbanken 2. SQL 1.1 Sinn und Zweck 1.2 Definition 1.3 Modelle 1.4 Relationales Datenbankmodell 2.1 Definition 2.2 Befehle 3.

Mehr

Objektbasierte und objektorientierte Datenbanken

Objektbasierte und objektorientierte Datenbanken Objektbasierte und objektorientierte Datenbanken in Vorlesung DB2 von Rainer Handel, Christoph Hautzinger Volker Schropp, Robert Westhäuser 15.04.2005 Inhalt (1) Von Volker Schropp Konzepte Grundkonzepte

Mehr

Semantische Integrität (auch: Konsistenz) der in einer Datenbank gespeicherten Daten als wichtige Anforderung

Semantische Integrität (auch: Konsistenz) der in einer Datenbank gespeicherten Daten als wichtige Anforderung 6. Datenintegrität Motivation Semantische Integrität (auch: Konsistenz) der in einer Datenbank gespeicherten Daten als wichtige Anforderung nur sinnvolle Attributwerte (z.b. keine negativen Semester) Abhängigkeiten

Mehr

Code-Erzeugung aus UML-Klassendiagrammen

Code-Erzeugung aus UML-Klassendiagrammen Dominik 09.03.2009 Universität Ulm Gessenharter Inst. f. Programmiermethodik und Compilerbau Code-Erzeugung aus UML-Klassendiagrammen Theorie und Praxis Seite 2 REConf 2009 München Dominik Gessenharter

Mehr

Modellgetriebene Entwicklungsprozesse in der Praxis - eine Bestandsaufnahme. Tillmann Schall, anaptecs GmbH

Modellgetriebene Entwicklungsprozesse in der Praxis - eine Bestandsaufnahme. Tillmann Schall, anaptecs GmbH Modellgetriebene Entwicklungsprozesse in der Praxis - eine Bestandsaufnahme Tillmann Schall, anaptecs GmbH : Agenda Grundlagen modellgetriebener Entwicklungsprozesse Schritte zur Einführung Erfahrungen

Mehr

Datenbanken I - Einführung

Datenbanken I - Einführung - Einführung April, 2011 1 von 30 Outline 1 Organisatorisches 2 Vorlesungsinhalt 3 Begrisklärung 4 Motivation 5 Abstraktion 6 Datenmodelle 7 Literaturangabe 2 von 30 Scheinkriterien Belegübung Regelmäÿige

Mehr

Die Bedeutung abstrakter Datentypen in der objektorientierten Programmierung. Klaus Kusche, September 2014

Die Bedeutung abstrakter Datentypen in der objektorientierten Programmierung. Klaus Kusche, September 2014 Die Bedeutung abstrakter Datentypen in der objektorientierten Programmierung Klaus Kusche, September 2014 Inhalt Ziel & Voraussetzungen Was sind abstrakte Datentypen? Was kann man damit grundsätzlich?

Mehr

Fakultät Angewandte Informatik Programmierung verteilter Systeme 28.11.2011. Übungen zur Vorlesung Informatik II, Blatt 6

Fakultät Angewandte Informatik Programmierung verteilter Systeme 28.11.2011. Übungen zur Vorlesung Informatik II, Blatt 6 WS 2011/12 Fakultät Angewandte Informatik Programmierung verteilter Systeme 28.11.2011 Prof. Dr. Bernhard Bauer Übungen zur Vorlesung Informatik II, Blatt 6 Abgabe: Montag, 05.12.2011, 12.00 Uhr, Informatik

Mehr

Ministerium für Kultus, Jugend und Sport Baden-Württemberg

Ministerium für Kultus, Jugend und Sport Baden-Württemberg Anlage zu 45-6512-2420/31 Ministerium für Kultus, Jugend und Sport Baden-Württemberg Schulversuch 51-6624.20/100 (früher: /84) vom 26. August 2003 Lehrpläne für das berufliche Gymnasium der sechs- und

Mehr

Profilbezogene informatische Bildung in den Klassenstufen 9 und 10. Schwerpunktthema Daten und Datenbanken

Profilbezogene informatische Bildung in den Klassenstufen 9 und 10. Schwerpunktthema Daten und Datenbanken Profilbezogene informatische Bildung in den Klassenstufen 9 und 10 Schwerpunktthema Robby Buttke Fachberater für Informatik RSA Chemnitz Fachliche Einordnung Phasen relationaler Modellierung Fachlichkeit

Mehr

Einführung in Generatives Programmieren. Bastian Molkenthin

Einführung in Generatives Programmieren. Bastian Molkenthin Einführung in Generatives Programmieren Bastian Molkenthin Motivation Industrielle Entwicklung *!!*,(% % - #$% #!" + '( & )!* Softwareentwicklung Rückblick auf Objektorientierung Objektorientierte Softwareentwicklung

Mehr

Vorlesung 30.03.2009 1) Einführung

Vorlesung 30.03.2009 1) Einführung Vorlesung 30.03.2009 1) Einführung Was versteht man unter dem Begriff Datenbank? - Eine Datenbank ist eine Struktur zur Speicherung von Daten mit lesendem und schreibendem Zugriff - Allgemein meint man

Mehr

O/R Mapper. O/R Mapper anhand von NHibernate & Entity Framework Thomas Mentzel März 2010

O/R Mapper. O/R Mapper anhand von NHibernate & Entity Framework Thomas Mentzel März 2010 O/R Mapper O/R Mapper anhand von NHibernate & Entity Framework Thomas Mentzel März 2010 Agenda Object-relational impedance mismatch Mapping Session Abfragen No. 2 Object-relational impedance mismatch Object-relational

Mehr

Datenbanken (WS 2015/2016)

Datenbanken (WS 2015/2016) Datenbanken (WS 2015/2016) Klaus Berberich (klaus.berberich@htwsaar.de) Wolfgang Braun (wolfgang.braun@htwsaar.de) 0. Organisatorisches Dozenten Klaus Berberich (klaus.berberich@htwsaar.de) Sprechstunde

Mehr

Fachbericht zum Thema: Anforderungen an ein Datenbanksystem

Fachbericht zum Thema: Anforderungen an ein Datenbanksystem Fachbericht zum Thema: Anforderungen an ein Datenbanksystem von André Franken 1 Inhaltsverzeichnis 1 Inhaltsverzeichnis 1 2 Einführung 2 2.1 Gründe für den Einsatz von DB-Systemen 2 2.2 Definition: Datenbank

Mehr

Java Persistence API 2.x. crud + relationships + jp-ql

Java Persistence API 2.x. crud + relationships + jp-ql Java Persistence API 2.x crud + relationships + jp-ql Grundprinzip 10.02.10 2 Problematik Man muss bei der Persistierung immer das Klassenmodell und dessen Umsetzung im Datenmodell (in der DB) berücksichtigen.

Mehr

Software-Engineering Einführung

Software-Engineering Einführung Software-Engineering Einführung 7. Übung (04.12.2014) Dr. Gergely Varró, gergely.varro@es.tu-darmstadt.de Erhan Leblebici, erhan.leblebici@es.tu-darmstadt.de Tel.+49 6151 16 4388 ES Real-Time Systems Lab

Mehr

Objektrelationale und erweiterbare Datenbanksysteme

Objektrelationale und erweiterbare Datenbanksysteme Objektrelationale und erweiterbare Datenbanksysteme Erweiterbarkeit SQL:1999 (Objekt-relationale Modellierung) In der Vorlesung werden nur die Folien 1-12 behandelt. Kapitel 14 1 Konzepte objekt-relationaler

Mehr

Persistenz. Workplace Solutions. Persistenz. ÿ RDBMS und OO ÿ Strukturkonflikt ÿ Object-RDBMS-Mapping. Abbildung Objekte auf RDBMS

Persistenz. Workplace Solutions. Persistenz. ÿ RDBMS und OO ÿ Strukturkonflikt ÿ Object-RDBMS-Mapping. Abbildung Objekte auf RDBMS Persistenz ÿ RDBMS und OO ÿ Strukturkonflikt ÿ Object-RDBMS-Mapping APCON Abbildung Objekte auf RDBMS Der Strukturkonflikt Basisklassen und Domänen Klassen zur Kapselung der relationalen Datenbank Abbildung

Mehr

LINQ to SQL. Proseminar Objektorientiertes Programmieren mit.net und C# Christoph Knüttel. Institut für Informatik Software & Systems Engineering

LINQ to SQL. Proseminar Objektorientiertes Programmieren mit.net und C# Christoph Knüttel. Institut für Informatik Software & Systems Engineering LINQ to SQL Proseminar Objektorientiertes Programmieren mit.net und C# Christoph Knüttel Institut für Informatik Software & Systems Engineering Agenda 1. LINQ allgemein Vorteile Bausteine und Varianten

Mehr

Software Engineering Analyse und Analysemuster

Software Engineering Analyse und Analysemuster Software Engineering Analyse und Analysemuster Prof. Adrian A. Müller, PMP, PSM 1, CSM Fachbereich Informatik und Mikrosystemtechnik 1 Klassendiagramme in der Analyse Im Rahmen der Anforderungsanalyse

Mehr

Vgl. Oestereich Kap 2.7 Seiten 134-147

Vgl. Oestereich Kap 2.7 Seiten 134-147 Vgl. Oestereich Kap 2.7 Seiten 134-147 1 Sequenzdiagramme beschreiben die Kommunikation/Interaktion zwischen den Objekten (bzw. verschiedenen Rollen) eines Szenarios. Es wird beschrieben, welche Objekte

Mehr

Einführung in Datenbanken

Einführung in Datenbanken Grundlagen der Programmierung 2 Einführung in Datenbanken Grundlagen der Programmierung 2 I-1 Inhalt Einführung Entity-Relationship-Diagramm Relationales Modell Entity-Relationship-Diagramm ins Relationales

Mehr

Datenbanken. Prof. Dr. Bernhard Schiefer. bernhard.schiefer@fh-kl.de http://www.fh-kl.de/~schiefer

Datenbanken. Prof. Dr. Bernhard Schiefer. bernhard.schiefer@fh-kl.de http://www.fh-kl.de/~schiefer Datenbanken Prof. Dr. Bernhard Schiefer bernhard.schiefer@fh-kl.de http://www.fh-kl.de/~schiefer Wesentliche Inhalte Begriff DBS Datenbankmodelle Datenbankentwurf konzeptionell, logisch und relational

Mehr

Drei-Schichten-Architektur. Informatik B - Objektorientierte Programmierung in Java. Vorlesung 17: 3-Schichten-Architektur 2

Drei-Schichten-Architektur. Informatik B - Objektorientierte Programmierung in Java. Vorlesung 17: 3-Schichten-Architektur 2 Universität Osnabrück 1 3 - Objektorientierte Programmierung in Java Zur Erinnerung: Aufteilung der Schichten GUI Vorlesung 17: 3-Schichten-Architektur 2 Fachkonzept Fachkonzept - Datenhaltung Datenhaltung

Mehr

Technische Beschreibung: EPOD Server

Technische Beschreibung: EPOD Server EPOD Encrypted Private Online Disc Technische Beschreibung: EPOD Server Fördergeber Förderprogramm Fördernehmer Projektleitung Projekt Metadaten Internet Foundation Austria netidee JKU Linz Institut für

Mehr

Gliederung und Einordnung

Gliederung und Einordnung Gliederung und Einordnung 1. Objektorientierte Programmierung mit Object Pascal (5. Studienbrief, Kapitel 5) 9.4. + 16.4. 2. Software-Bausteine am Beispiel der Delphi-Komponenten (5. Studienbrief, Kapitel

Mehr

Suche schlecht beschriftete Bilder mit Eigenen Abfragen

Suche schlecht beschriftete Bilder mit Eigenen Abfragen Suche schlecht beschriftete Bilder mit Eigenen Abfragen Ist die Bilderdatenbank über einen längeren Zeitraum in Benutzung, so steigt die Wahrscheinlichkeit für schlecht beschriftete Bilder 1. Insbesondere

Mehr

Bedienung von BlueJ. Klassenanzeige

Bedienung von BlueJ. Klassenanzeige Im Folgenden werden wichtige Funktionen für den Einsatz von BlueJ im Unterricht beschrieben. Hierbei wird auf den Umgang mit Projekten, Klassen und Objekten eingegangen. Abgeschlossen wird dieses Dokument

Mehr

Verschiedene Arten des Datenbankeinsatzes

Verschiedene Arten des Datenbankeinsatzes 1 Beispiele kommerzieller DBMS: Kapitelinhalt Was charakterisiert und unterscheidet verschiedene Einsatzbereiche für. Welche prinzipiell unterschiedlichen Anforderungen ergeben sich für das DBMS bei Ein-

Mehr

Datenbanken: Relationales Datenbankmodell RDM

Datenbanken: Relationales Datenbankmodell RDM Das RDM wurde in den 70'er Jahren von Codd entwickelt und ist seit Mitte der 80'er Jahre definierter Standard für Datenbanksysteme! Der Name kommt vom mathematischen Konzept einer Relation: (Sind A, B

Mehr

Analyse und praktischer Vergleich von neuen Access- Layer-Technologien in modernen Webanwendungen unter Java. Oliver Kalz

Analyse und praktischer Vergleich von neuen Access- Layer-Technologien in modernen Webanwendungen unter Java. Oliver Kalz Analyse und praktischer Vergleich von neuen Access- Layer-Technologien in modernen Webanwendungen unter Java Oliver Kalz Agenda Grundlagen Objektpersistenz Objektrelationales Mapping Performance Fazit

Mehr

TRAINING. Transbase Training. Transbase Training - Die Kurse in der Übersicht

TRAINING. Transbase Training. Transbase Training - Die Kurse in der Übersicht Transbase Training Der Bereich Schulung und Training von Transaction Software umfasst ein breites Angebot rund um das Thema Datenbanken. Angeboten werden spezielle Transbase Trainings. Transbase Training

Mehr

Objektorientierter Software-Entwurf Die Unified Modeling Language 4 1

Objektorientierter Software-Entwurf Die Unified Modeling Language 4 1 Objektorientierter Software-Entwurf Die Unified Modeling Language 4 1 Die Unified Modeling Language Die UML (hier in der Version 0.9) ist ein Satz von Notationen zur Beschreibung objektorientierter Softwaresysteme.

Mehr

Der Website-Generator

Der Website-Generator Der Website-Generator Der Website-Generator im Privatbereich gibt Ihnen die Möglichkeit, schnell eine eigene Website in einheitlichem Layout zu erstellen. In Klassen, Gruppen und Institutionen können auch

Mehr

Integration Services - Dienstarchitektur

Integration Services - Dienstarchitektur Integration Services - Dienstarchitektur Integration Services - Dienstarchitektur Dieser Artikel solle dabei unterstützen, Integration Services in Microsoft SQL Server be sser zu verstehen und damit die

Mehr

Data Lineage goes Traceability - oder was Requirements Engineering von Business Intelligence lernen kann

Data Lineage goes Traceability - oder was Requirements Engineering von Business Intelligence lernen kann Data Lineage goes Traceability - oder was Requirements Engineering von Business Intelligence lernen kann Andreas Ditze MID GmbH Kressengartenstraße 10 90402 Nürnberg a.ditze@mid.de Abstract: Data Lineage

Mehr

1 Einleitung. 1.1 Caching von Webanwendungen. 1.1.1 Clientseites Caching

1 Einleitung. 1.1 Caching von Webanwendungen. 1.1.1 Clientseites Caching 1.1 Caching von Webanwendungen In den vergangenen Jahren hat sich das Webumfeld sehr verändert. Nicht nur eine zunehmend größere Zahl an Benutzern sondern auch die Anforderungen in Bezug auf dynamischere

Mehr

Kapitel 6. Vererbung

Kapitel 6. Vererbung Kapitel 6 Vererbung Vererbung 1 Ziele Das Vererbungsprinzip der objektorientierten Programmierung verstehen Und in Java umsetzen können Insbesondere folgende Begriffe verstehen und anwenden können: Ober/Unterklassen

Mehr

FlowFact Alle Versionen

FlowFact Alle Versionen Training FlowFact Alle Versionen Stand: 29.09.2005 Brief schreiben, ablegen, ändern Die FlowFact Word-Einbindung macht es möglich, direkt von FlowFact heraus Dokumente zu erzeugen, die automatisch über

Mehr

Von der UML nach C++

Von der UML nach C++ 22 Von der UML nach C++ Dieses Kapitel behandelt die folgenden Themen: Vererbung Interfaces Assoziationen Multiplizität Aggregation Komposition Die Unified Modeling Language (UML) ist eine weit verbreitete

Mehr

Einführung. Kapitel 1 2 / 508

Einführung. Kapitel 1 2 / 508 Kapitel 1 Einführung 2 / 508 Einführung Was ist ein Datenbanksystem (DBS)? Ein System zum Speichern und Verwalten von Daten. Warum kein herkömmliches Dateisystem verwenden? Ausfallsicherheit und Skalierbarkeit

Mehr

8.4 Überblick und Vergleich weiterer ERP-Systeme. G Oracle Applications 11 G PeopleSoft 7 G J.D. Edwards One World G BaanERP

8.4 Überblick und Vergleich weiterer ERP-Systeme. G Oracle Applications 11 G PeopleSoft 7 G J.D. Edwards One World G BaanERP 8.4 Überblick und Vergleich weiterer ERP-Systeme G Oracle Applications 11 G PeopleSoft 7 G J.D. Edwards One World G BaanERP Kapitel 8: ERP-Einführung 32 Architektur von Oracle Applications 11 G Logische

Mehr

Musterlösung zur Vorlesung Modellbasierte Softwareentwicklung Wintersemester 2014/2015 Übungsblatt 9

Musterlösung zur Vorlesung Modellbasierte Softwareentwicklung Wintersemester 2014/2015 Übungsblatt 9 Prof. Dr. Wilhelm Schäfer Paderborn, 15. Dezember 2014 Christian Brenner Tristan Wittgen Musterlösung zur Vorlesung Modellbasierte Softwareentwicklung Wintersemester 2014/2015 Übungsblatt 9 Aufgabe 1 Codegenerierung

Mehr

4. Objektrelationales Mapping Grundlagen der Programmierung II (Java)

4. Objektrelationales Mapping Grundlagen der Programmierung II (Java) 4. Objektrelationales Mapping Grundlagen der Programmierung II (Java) Prof. Dr. Bernhard Humm Hochschule Darmstadt University of Applied Sciences Sommersemester 2006 Übersicht Grundlagen der Programmierung

Mehr

Jens Kupferschmidt Universitätsrechenzentrum

Jens Kupferschmidt Universitätsrechenzentrum Einordnung der Metadaten im MyCoRe Projekt Connection to other databases Data presentations MyCoResearch over instances Classifications Metadate and search Derivate User and access rights GUI Workflow

Mehr

Datenbanken. Ein DBS besteht aus zwei Teilen:

Datenbanken. Ein DBS besteht aus zwei Teilen: Datenbanken Wikipedia gibt unter http://de.wikipedia.org/wiki/datenbank einen kompakten Einblick in die Welt der Datenbanken, Datenbanksysteme, Datenbankmanagementsysteme & Co: Ein Datenbanksystem (DBS)

Mehr

OM Datenbanken. OM Datenbanken. 8.1 Was ist ein Datenbanksystem? Motivation

OM Datenbanken. OM Datenbanken. 8.1 Was ist ein Datenbanksystem? Motivation 1 Inhalt: Relationale Datenbanken 8.1 Was ist ein Datenbanksystem? 8.2 Relationale Datenbanksysteme 8.3 Abbildung des objektorientierten Modells auf Tabellen 2 8.1 Was ist ein Datenbanksystem? Motivation

Mehr

Workstations. Server. Recovery Log. Database. SQL Queries. Query Processing Object Mgmt. Transaction Mgmt. Buffer Mgmt. I/O Layer

Workstations. Server. Recovery Log. Database. SQL Queries. Query Processing Object Mgmt. Transaction Mgmt. Buffer Mgmt. I/O Layer Client-Server Architekturen: Query Shipping Grundprinzip 1. Client schickt Anfrage zum Server 2. Server schickt Ergebnisse der Anfrage zuruck Workstations Application Interface Layer SQL Queries Query

Mehr

Fachhochschule Wiesbaden, FB Design Informatik Medien Studiengang Allgemeine Informatik Vorlesung im SS 2007

Fachhochschule Wiesbaden, FB Design Informatik Medien Studiengang Allgemeine Informatik Vorlesung im SS 2007 Softwaretechnik Fachhochschule Wiesbaden, FB Design Informatik Medien Studiengang Allgemeine Informatik Vorlesung im SS 2007 1 Ziele Die Analyse einer softwaretechnischen Problemstellung nach objektorientierten

Mehr

jetzt lerne ich PHP 5 & MySQL 4.1 Der schnelle Einstieg in die objektorientierte

jetzt lerne ich PHP 5 & MySQL 4.1 Der schnelle Einstieg in die objektorientierte jetzt lerne ich PHP 5 & MySQL 4.1 Der schnelle Einstieg in die objektorientierte Webprogrammierung SVEN LETZEL FRIEDHELM BETZ Inhaltsverzeichnis jetzt lerne ich Hallo! 15 1 Grundlagen 17 1.1 Das Internet

Mehr

2. Datenbank-Programmierung

2. Datenbank-Programmierung 2. Datenbank-Programmierung SQL ist eingeschränkt bezüglich der algorithmischen Mächtigkeit, z.b. Berechnung einer transitiven Hülle ist in Standard-SQL nicht möglich. Die Einschränkung ist von Bedeutung

Mehr

In die Zeilen würden die Daten einer Adresse geschrieben werden. Das Ganze könnte in etwa folgendermaßen aussehen:

In die Zeilen würden die Daten einer Adresse geschrieben werden. Das Ganze könnte in etwa folgendermaßen aussehen: 1 Einführung in Datenbanksysteme Fast jeder kennt Excel und hat damit in seinem Leben schon einmal gearbeitet. In Excel gibt es Arbeitsblätter, die aus vielen Zellen bestehen, in die man verschiedene Werte

Mehr

Die Grundbegriffe Die Daten Die Informationen

Die Grundbegriffe Die Daten Die Informationen Die Grundbegriffe Die Daten sind diejenigen Elemente, die vom Computer verarbeitet werden. Die Informationen sind Wissenselemente, welche durch die Analyse von Daten erhalten werden können. Die Daten haben

Mehr

Modellbasierte Softwareentwicklung mit EMF

Modellbasierte Softwareentwicklung mit EMF Softwaretechnik I, WS 2009/10 Modellbasierte Softwareentwicklung mit EMF Übungsblatt 5 13. November 2009 Organisatorisches Zur Bearbeitung der Übungsaufgabe stehen Ihnen die folgenden 3 Wochen (Kalenderwochen

Mehr

Kapitel 6. Vererbung

Kapitel 6. Vererbung 1 Kapitel 6 2 Ziele Das sprinzip der objektorientierten Programmierung verstehen Und in Java umsetzen können Insbesondere folgende Begriffe verstehen und anwenden können: Ober/Unterklassen Subtyping Überschreiben

Mehr

Kapitel 33. Der xml-datentyp. In diesem Kapitel: Der xml-datentyp 996 Abfragen aus xml-datentypen 1001 XML-Indizierung 1017 Zusammenfassung 1023

Kapitel 33. Der xml-datentyp. In diesem Kapitel: Der xml-datentyp 996 Abfragen aus xml-datentypen 1001 XML-Indizierung 1017 Zusammenfassung 1023 Kapitel 33 Der xml-datentyp In diesem Kapitel: Der xml-datentyp 996 Abfragen aus xml-datentypen 1001 XML-Indizierung 1017 Zusammenfassung 1023 995 996 Kapitel 33: Der xml-datentyp Eine der wichtigsten

Mehr

Vortrag von: Ilias Agorakis & Robert Roginer

Vortrag von: Ilias Agorakis & Robert Roginer MDA Model Driven Architecture Vortrag von: Ilias Agorakis & Robert Roginer Anwendungen der SWT - WS 08/09 Inhalt Was ist MDA? Object Management Group (OMG) Ziele Konzepte der MDA Werkzeuge Vor- und Nachteile

Mehr

Business Intelligence Praktikum 1

Business Intelligence Praktikum 1 Hochschule Darmstadt Business Intelligence WS 2013-14 Fachbereich Informatik Praktikumsversuch 1 Prof. Dr. C. Wentzel Dipl. Inf. Dipl. Math. Y. Orkunoglu Datum: 14.10.2013 Business Intelligence Praktikum

Mehr

Kapitel 6. Vererbung

Kapitel 6. Vererbung 1 Kapitel 6 2 Ziele Das sprinzip der objektorientierten Programmierung verstehen Und in Java umsetzen können Insbesondere folgende Begriffe verstehen und anwenden können: Ober/Unterklassen Subtyping Überschreiben

Mehr

Client/Server-Systeme

Client/Server-Systeme Fachbereich Informatik Projektgruppe KOSI Kooperative Spiele im Internet Client/Server-Systeme Vortragender Jan-Ole Janssen 26. November 2000 Übersicht Teil 1 Das Client/Server-Konzept Teil 2 Client/Server-Architekturen

Mehr

TU München, Fakultät für Informatik Lehrstuhl III: Datenbanksysteme Prof. Dr. Thomas Neumann

TU München, Fakultät für Informatik Lehrstuhl III: Datenbanksysteme Prof. Dr. Thomas Neumann TU München, Fakultät für Informatik Lehrstuhl III: Datenbanksysteme Prof. Dr. Thomas Neumann Blatt Nr. 11 Übung zur Vorlesung Einsatz und Realisierung von Datenbanksystemen im SoSe15 Moritz Kaufmann (moritz.kaufmann@tum.de)

Mehr

Business Intelligence Praktikum 1

Business Intelligence Praktikum 1 Hochschule Darmstadt Business Intelligence SS 2014 Fachbereich Informatik Praktikumsversuch 1 Prof. Dr. C. Wentzel Dipl. Inf. Dipl. Math. Y. Orkunoglu Datum: 07.05.2014 Business Intelligence Praktikum

Mehr

Knasmüller.book Seite vii Mittwoch, 28. März 2001 11:11 11. vii. Inhaltsverzeichnis

Knasmüller.book Seite vii Mittwoch, 28. März 2001 11:11 11. vii. Inhaltsverzeichnis Knasmüller.book Seite vii Mittwoch, 28. März 2001 11:11 11 vii 1 Einführung 1 1.1 Motivation.................................... 1 1.2 Vorteile der neuen Techniken...................... 3 1.3 Aufbau des

Mehr

Datenbankmodelle 1. Das Entity-Relationship-Modell. Prof. Dr. Bernhard Schiefer 2-1

Datenbankmodelle 1. Das Entity-Relationship-Modell. Prof. Dr. Bernhard Schiefer 2-1 Datenbankmodelle 1 Das Entity-Relationship-Modell Prof. Dr. Bernhard Schiefer 2-1 Datenbankmodelle ER-Modell hierarchisches Modell Netzwerkmodell relationales Modell objektorientierte Modelle Prof. Dr.

Mehr

Teil VI. Datenbanken

Teil VI. Datenbanken Teil VI Datenbanken Überblick 1 Grundlegende Begriffe Motivation 2 Relationale Datenbanksysteme Das Relationale Datenmodell SQL 3 Entwurf von Datenbanken Das Enity Relationship (ER) Modell Abbildung von

Mehr

JDO Java Data Objects

JDO Java Data Objects JDO Java Data Objects Ralf Degner, Chief Consultant Ralf.Degner@poet.de Agenda POET Motivation Geschichte Einführung Architekturen FastObjects POET Gegründet 1993 Zwei Produktlinien esupplier Solutions:

Mehr

VBA-Programmierung: Zusammenfassung

VBA-Programmierung: Zusammenfassung VBA-Programmierung: Zusammenfassung Programmiersprachen (Definition, Einordnung VBA) Softwareentwicklung-Phasen: 1. Spezifikation 2. Entwurf 3. Implementierung Datentypen (einfach, zusammengesetzt) Programmablaufsteuerung

Mehr

Inhalt der Vorlesung. 1 Datenmodellierung (Entity-Relationship Modell) 2 Das relationale Modell. 3 Relationenalgebra. 4 Datenbanksprache (SQL)

Inhalt der Vorlesung. 1 Datenmodellierung (Entity-Relationship Modell) 2 Das relationale Modell. 3 Relationenalgebra. 4 Datenbanksprache (SQL) Inhalt der Vorlesung 1 Datenmodellierung (Entity-Relationship Modell) 2 Das relationale Modell 3 Relationenalgebra 4 Datenbanksprache (SQL) 5 Normalisierung 6 Vom ERM zum Datenbankschema 7 Routinen und

Mehr

Integritätsbedingungen / Normalformen- Beispiel: Kontoführung

Integritätsbedingungen / Normalformen- Beispiel: Kontoführung Technische Universität München WS 2003/04, Fakultät für Informatik Datenbanksysteme I Prof. R. Bayer, Ph.D. Lösungsblatt 8 Dipl.-Inform. Michael Bauer Dr. Gabi Höfling 12.01. 2004 Integritätsbedingungen

Mehr

Vorlesung Informatik II

Vorlesung Informatik II Vorlesung Informatik II Universität Augsburg Wintersemester 2011/2012 Prof. Dr. Bernhard Bauer Folien von: Prof. Dr. Robert Lorenz Lehrprofessur für Informatik 08. Exkurs: Datenbanken 1 Motivation Datenbanksysteme

Mehr

7. Übung - Datenbanken

7. Übung - Datenbanken 7. Übung - Datenbanken Informatik I für Verkehrsingenieure Aufgaben inkl. Beispiellösungen 1. Aufgabe: DBS a Was ist die Kernaufgabe von Datenbanksystemen? b Beschreiben Sie kurz die Abstraktionsebenen

Mehr

ER-Modell. Entity-Relationship-Model

ER-Modell. Entity-Relationship-Model + ER-Modell Entity-Relationship-Model + Was ist ein Modell? Worte/Zitat aus einem Physikbuch: "Modelle sind also Vorstellungshilfen und Wirklichkeitshilfen, nicht die Wirklichkeit selbst." (Metzler Physik).

Mehr

Kopplung Verteilter Datenbanksysteme. Eric Ndengang

Kopplung Verteilter Datenbanksysteme. Eric Ndengang Kopplung Verteilter Datenbanksysteme Eric Ndengang 21.06.2004 Seminar SS 2004 Universität Karlsruhe Babel 21.06.2004 Seminar SS 2004 2 Übersicht Einleitung Problematik Wrapper / Mediator-basierte Architekturen

Mehr

ObjectBridge Java Edition

ObjectBridge Java Edition ObjectBridge Java Edition Als Bestandteil von SCORE Integration Suite stellt ObjectBridge Java Edition eine Verbindung von einem objektorientierten Java-Client zu einer fast beliebigen Server-Komponente

Mehr

eadmin Manual Universitätsstraße 3 56070 Koblenz Deutschland

eadmin Manual Universitätsstraße 3 56070 Koblenz Deutschland DOKUMENT: TYP: ERSTELLT VON: Manual nova ratio AG Universitätsstraße 3 56070 Koblenz Deutschland VERSION: STAND: 9.x 23. September 2015 Inhaltsverzeichnis 1 2 2.1 2.2 2.3 3 3.1 3.2 3.3 4 4.1 4.2 4.3 4.4

Mehr

Definition Informationssystem

Definition Informationssystem Definition Informationssystem Informationssysteme (IS) sind soziotechnische Systeme, die menschliche und maschinelle Komponenten umfassen. Sie unterstützen die Sammlung, Verarbeitung, Bereitstellung, Kommunikation

Mehr

Ein wesentliches, charakteristisches Merkmal aller Datenbankmanagement

Ein wesentliches, charakteristisches Merkmal aller Datenbankmanagement Anfrageformulierung: Allgemeines Ein wesentliches, charakteristisches Merkmal aller Datenbankmanagement nkmanagement- systeme ist die Unterstützung einer (oder mehrerer) Anfragesprachen. Eine Anfrage ist

Mehr

Relationale Datenbanken Datenbankgrundlagen

Relationale Datenbanken Datenbankgrundlagen Datenbanksystem Ein Datenbanksystem (DBS) 1 ist ein System zur elektronischen Datenverwaltung. Die wesentliche Aufgabe eines DBS ist es, große Datenmengen effizient, widerspruchsfrei und dauerhaft zu speichern

Mehr

Visualisierung paralleler bzw. verteilter Programme

Visualisierung paralleler bzw. verteilter Programme Seminar Visualisierung in Informatik und Naturwissenschaften im SS 1999 Visualisierung paralleler bzw. verteilter Programme Holger Dewes Gliederung Zum Begriff Motivation PARADE Beispiel 1: Thread basierte

Mehr

Informationssystemanalyse Use Cases 11 1

Informationssystemanalyse Use Cases 11 1 Informationssystemanalyse Use Cases 11 1 Use Cases Slide 1 Als ein populäres Mittel um Anforderungen zu erfassen und Systeme zu beschreiben, werden Use Cases benutzt. Sie bilden die Basis für eine umfassendere

Mehr

Ein Schlüssel ist eine Menge von Attributen (also eines oder mehrere), die eine Datenzeile (Tupel) einer Tabelle eindeutig identifiziert

Ein Schlüssel ist eine Menge von Attributen (also eines oder mehrere), die eine Datenzeile (Tupel) einer Tabelle eindeutig identifiziert Maika Büschenfeldt Datenbanken: Skript 1 1. Was ist eine relationale Datenbank? In Datenbanken können umfangreiche Datenbestände strukturiert abgelegt werden. Das Konzept relationaler Datenbanken soll

Mehr

Ein Erfahrungsbericht beim Einsatz von generierenden Ansätzen im Vergleich zu generischen Lösungen

Ein Erfahrungsbericht beim Einsatz von generierenden Ansätzen im Vergleich zu generischen Lösungen Ein Erfahrungsbericht beim Einsatz von generierenden Ansätzen im Vergleich zu generischen Lösungen Tom Krauß Agenda Begriffsdefinition Verfahren Praktische Beispiele Vergleich und Bewertung Begriffsklärung

Mehr

Allgemeines zu Datenbanken

Allgemeines zu Datenbanken Allgemeines zu Datenbanken Was ist eine Datenbank? Datensatz Zusammenfassung von Datenelementen mit fester Struktur Z.B.: Kunde Alois Müller, Hegenheimerstr. 28, Basel Datenbank Sammlung von strukturierten,

Mehr

5.1 Bestehende Projekte bearbeiten 79 5.2 Neue Projekte erstellen 85

5.1 Bestehende Projekte bearbeiten 79 5.2 Neue Projekte erstellen 85 Projekte per DOM bearbeiten KAPITEL 5 5.1 Bestehende Projekte bearbeiten 79 5.2 Neue Projekte erstellen 85 Bisher haben wir uns angesehen, wie List & Label mit Ihren Daten bekannt gemacht werden kann und

Mehr

Themenkatalog der Schulungsinhalte

Themenkatalog der Schulungsinhalte IT-Training Themenkatalog der Schulungsinhalte Seite 1 von 6 Inhalt 1. DATENBANKEN... 3 1.1 Datenbank - Programmierung... 3 1.1.1 SQL - Structured Query Language / Compound Statements...3 1.2 Datenbank

Mehr

Modellierungstechniken im Softwaredesign. Praxisprojekt [ai] Control WS 2011/2012 Lara Baschour und Anne Heiting

Modellierungstechniken im Softwaredesign. Praxisprojekt [ai] Control WS 2011/2012 Lara Baschour und Anne Heiting Modellierungstechniken im Softwaredesign Praxisprojekt [ai] Control WS 2011/2012 Lara Baschour und Anne Heiting Was ist Modellierung? Modell = Ein Modell ist eine Repräsentation eines Systems von Objekten,

Mehr

Datenbankentwurf. 4.2 Logischer Entwurf. Kapitel 4. ER-Modell. Umsetzung. Entwurfsdokumentation. relationales Modell. Verbesserung

Datenbankentwurf. 4.2 Logischer Entwurf. Kapitel 4. ER-Modell. Umsetzung. Entwurfsdokumentation. relationales Modell. Verbesserung 4.2 Logischer Entwurf Datenbankentwurf 4.2 Logischer Entwurf 2002 Prof. Dr. Rainer Manthey Informationssysteme Logischer Entwurf: Einordnung Entwurfsdokumentation logische Strukturen "auf dem Papier" konzeptueller

Mehr

- 133 - SWE. Zwischenbericht zur Migration von UIS-Centura-Anwendungen nach Java

- 133 - SWE. Zwischenbericht zur Migration von UIS-Centura-Anwendungen nach Java - 133 - SWE Zwischenbericht zur Migration von UIS-Centura-Anwendungen nach Java J. Mäkiö Forschungszentrum Informatik Haid-und-Neu-Str. 10-14 76131 Karlsruhe H. Spandl Landesanstalt für Umwelt, Messungen

Mehr

Fundamentals of Software Engineering 1

Fundamentals of Software Engineering 1 Folie a: Name Fundamentals of Software Engineering 1 Grundlagen der Programmentwurfstechnik 1 Sommersemester 2012 Dr.-Ing. Stefan Werner Fakultät für Ingenieurwissenschaften Folie 1 Inhaltsverzeichnis

Mehr

Vorlesungsinhalt. Architektur von Datenbanksystemen. G. Specht: Datenbanksysteme 8-1. Kapitel VIII

Vorlesungsinhalt. Architektur von Datenbanksystemen. G. Specht: Datenbanksysteme 8-1. Kapitel VIII Architektur von Datenbanksystemen Kapitel VIII Vorlesung Datenbanksysteme Univ.-Prof. Dr. Günther Specht Universität Innsbruck Institut für Informatik Datenbanken und Informationssysteme (DBIS) Vorlesungsinhalt

Mehr

Prinzipien Objektorientierter Programmierung

Prinzipien Objektorientierter Programmierung Prinzipien Objektorientierter Programmierung Valerian Wintner Inhaltsverzeichnis 1 Vorwort 1 2 Kapselung 1 3 Polymorphie 2 3.1 Dynamische Polymorphie...................... 2 3.2 Statische Polymorphie........................

Mehr

Modellierung von Geodaten

Modellierung von Geodaten Modellierung von Geodaten Universität Augsburg Fachbereich Informatik Seminar: Datenbankunterstützung für mobile GIS Sommersemester 2011 Zeev Turevsky Betreuer: Dipl.-Informatiker Florian Wenzel Gliederung

Mehr

Software-Schutz Server Aktivierung

Software-Schutz Server Aktivierung Software-Schutz Server Aktivierung Anstelle eines Hardlock-Server-Dongles (parallel, USB) kann Ihre moveit@iss+ Netzwerkinstallation nun auch per Software-Schutz Server lizenziert werden. Dabei wird Ihre

Mehr

1 Transaktionen in SQL. 2 Was ist eine Transaktion. 3 Eigenschaften einer Transaktion. PostgreSQL

1 Transaktionen in SQL. 2 Was ist eine Transaktion. 3 Eigenschaften einer Transaktion. PostgreSQL 1 Transaktionen in SQL Um Daten in einer SQL-Datenbank konsistent zu halten, gibt es einerseits die Möglichkeit der Normalisierung, andererseits sog. Transaktionen. 2 Was ist eine Transaktion Eine Transaktion

Mehr