Bachelorarbeit. Database Live Migration. Stückler Karl. Wirtschafts- und Sozialwissenschaften. Dipl.-Ing. Mag. Dr. Albert Weichselbraun

Größe: px
Ab Seite anzeigen:

Download "Bachelorarbeit. Database Live Migration. Stückler Karl. Wirtschafts- und Sozialwissenschaften. Dipl.-Ing. Mag. Dr. Albert Weichselbraun"

Transkript

1 WIRTSCHAFTSUNIVERSITÄT WIEN Vienna University of Economics and Business Bachelorarbeit Titel der Bachelorarbeit: Database Live Migration Verfasser/in (Nachname, Vorname): Matrikelnummer: Stückler Karl Studium: Wirtschafts- und Sozialwissenschaften Beurteiler/in (Titel, Vorname, Nachname): Dipl.-Ing. Mag. Dr. Albert Weichselbraun Hiermit versichere ich, dass 1. ich die vorliegende Bachelorarbeit selbständig und ohne Verwendung unerlaubter Hilfsmittel verfasst habe. Alle Inhalte, die direkt oder indirekt aus fremden Quellen entnommen sind, sind durch entsprechende Quellenangaben gekennzeichnet. 2. die vorliegende Arbeit bisher weder im In- noch im Ausland zur Beurteilung vorgelegt bzw. veröffentlicht worden ist. 3. diese Arbeit mit der beurteilten bzw. in elektronischer Form eingereichten Bachelorarbeit übereinstimmt. 4. (nur bei Gruppenarbeiten): die vorliegende Arbeit gemeinsam mit (Vorname, Nachname) entstanden ist. Die Teilleistungen der einzelnen Personen sind kenntlich gemacht, ebenso wie jene Passagen, die gemeinsam erarbeitet wurden. Datum Unterschrift

2 Abstrakt Unter Migration versteht man die Übertragung, unter Umständen Transformation, von Daten und Schemata auf eine bestimmte Zielplattform. Dabei sind die traditionellen Ansätze nicht immer anwendbar. Insbesondere treten Schwierigkeiten bei der Migration von großen Datenmengen und komplexen Schemata auf, da einerseits die Durchlaufzeit möglichst kurz, andererseits das Gesamtsystem währenddessen nicht wesentlich beeinträchtigt werden soll. Eine Herausforderung ist insbesondere das Informationswachstum im Web, welches aufgrund seiner heterogenen Eigenschaft neue Ansätze für einen effizienten Datenaustausch benötigt. Im Rahmen dieser Arbeit werden zunächst unterschiedliche theoretische Ansätze der Migration und deren Umsetzung in der Praxis erörtert. Weiteres wurde ein eigenes Framework und eine Referenzimplementierung entwickelt, welches eine effiziente Migration zwischen beliebigen Datenquellen ermöglicht. Während des Migrationsprozesses wird zunächst das Quellschemata in ein standardisiertes Format gebracht, auf Grundlage dessen eine Transformation in eine beliebige Zielschemata erfolgen kann. Abstract Migration is the transmission, in certain circumstances transformation, of data und schema to a defined target platform. Sometimes a manual migration approach is not applicable. Particularly with regard to migration of a good deal of data and complex schema, difficulties occur as on the one hand processing time should be minimized, on the other hand the total system should not be influenced essentially. Another big challenge is the growth of information in the web, which, due to its heterogeneous attributes, needs new efficient solutions for data exchange. In context of this thesis different theoretic solutions of migration and its implementation in practice are discussed. Further an own framework and a reference implementation were developed which enables an efficient migration between any data sources. First of all, the source schema is transformed in a standardized format. Based on this format a transformation to any target schema may happen.

3 Inhaltsverzeichnis I. Inhaltsverzeichnis I. INHALTSVERZEICHNIS EINLEITUNG MOTIVATION ALLGEMEINES DATENBANKEN CLUSTERING Shared Storage Shared Nothing Partitionierung REPLIKATION Master/Slave-Replikation Multimaster-Replikation Read One Write All Voting MIGRATION SCHEMA MAPPING Strukturkonflikte Datenkonflikte Mapping Algorithmus SCHEMA MATCHING Schema based Mapping Instance based Mapping ANBIETER VON LÖSUNGEN SLONY-I Architektur Konfiguration Auswahl der Slony-I Version IBM CLIO Architektur Beispiel REFERENZIMPLEMENTIERUNG PROJEKT DESIGN IMPLEMENTIERUNG Migration des Schemas Migration der Daten TESTUMGEBUNG VERWENDUNG AUSBLICK Seite 3

4 Inhaltsverzeichnis II. ANHANG ABBILDUNGSVERZEICHNIS LISTINGVERZEICHNIS TABELLENVERZEICHNIS LITERATUR Seite 4

5 Einleitung 1. Einleitung Viele modern Anwendungen im Bereich data warehousing und electronic commerce erfordern das Zusammenführen und die Transformierung von Daten aus unterschiedlichen Datenquellen (Miller, et al., 2001). Bei großen Datenmengen und komplexen Schemata kann der Transformationsprozess ohne entsprechende Werkzeuge zeit- und kostenintensiv sein. Das Ziel dieser Bachelorarbeit ist die Analyse theoretischer und praktischer Lösungsansätze sowie die Implementierung eines Frameworks zur Transformation von Schemata und Daten zwischen beliebigen relationalen Datenbanken. 1.1 Motivation Der Media Watch on Climate Change aggregiert, kommentiert und visualisiert Artikel von 150 angloamerikanischen Nachrichtenseiten. In wöchentlichen Intervallen werden von insgesamt Medienartikeln je mit Umweltbezug kommentiert und indiziert. Im Anschluss erfolgt die Speicherung in einer Datenbank, in der die Informationen anhand unterschiedlicher Dimensionen, wie beispielsweise Zeit, Thema, Schlüsselwörter oder geografische Nähe, wieder aufgefunden werden können. Die Plattform basiert auf weblyzard, das eine automatisierte und integrierte Analyse von Webseitenstrukturen und Inhalten ermöglicht. Die weblyzard Datenbank besteht aus Millionen von Dokumenten und Bildern, die in einer PostgreSQL Datenbank gespeichert werden. Derzeit fordern Datenbankaktualisierungen sowie die Migration von Daten einen erheblichen Aufwand. Aufgrund der sich daraus ableitenden Anforderungen soll ein Werkzeug für die Migration von Datenbanken entwickelt werden. Das Framework soll eine Echtzeitmigration zwischen beliebigen Datenbanksystemen ermöglichen, also Schemata und Daten ohne Einschränkung während des laufenden Betriebs migrieren. So müssen alle Datenänderungen auf der Quelldatenbank während der Migration protokolliert und im Anschluss auf die Zieldatenbank übertragen werden. Ein weiteres Ziel ist die genaue Spezifikation von Schnittstellen, um eine einfache Integration von beliebigen Datenbanksystemen zu ermöglichen. 1.2 Allgemeines Neben dem konkreten Anwendungsbereich von Migration- und Transformationstechnologien bei Media Watch on Climate Change gibt es vielfältige Einsatzmöglichkeiten derartiger Anwendungen: Data Mining Unter data mining versteht man die Gewinnung von interessanten Daten aus einer großen Menge von Daten (Petersohn, 2005). Zunächst werden Daten selektiert und mit bestimmten Mustern verglichen. Das Ergebnis dieses Prozesses ist die Informationsgewinnung. Beispiele für den Einsatz von data mining Anwendungen sind Seite 5

6 Einleitung Kundensegmentierungen im Marketingbereich (zum Beispiel Erforschung von Kaufverhalten und Kundeninteressen), Warenkorbanalysen (zum Beispiel Preisoptimierung, Produktplatzierungen im Supermarkt) oder Text Mining (zum Beispiel Gewinnung von relevante Informationen aus Textdaten) (Oberholzer, 2003). Weiteres wird das automatische Auswerten solcher Datenbestände mit Hilfe statistischer Verfahren, künstlicher neuronaler Netze, Fuzzy-Clustering-Verfahren oder genetischer Algorithmen ermöglicht (Petersohn, 2005). Eine spezielle Form des data mining ist das web mining, in dessen Kontext das Web die Datenquelle darstellt (Stoffel, 2009). Bestimmte spezifische Eigenschaften des Webs erschweren die Informationsgewinnung. Insbesondere die Größe, die fehlende Datenkonsistenz sowie die unterschiedlichen Datenformate (zum Beispiel HTML, XML, RSS, et cet era) erhöhen die Komplexität eines web data mining Systems (Stoffel, 2009). Jedoch haben alle Bereiche des data mining die Gemeinsamkeit, dass Informationen aus verschiedenen Datenquellen (häufig Datenbanken) gewonnen werden. E-Marketing Unter dem E-Marketing (Internet Marketing) versteht man die systematische Nutzung von Online Dienste für die Zwecke des Marketings (Fritz, 2004). Durch den Einsatz von Datenbanken können Kundendaten gespeichert und systematisch für Werbezwecke verwendet werden. Das Internet Marketing ist in den meisten Fällen kein Ersatz für traditionelle Marketingansätze, sondern stellt lediglich eine Ergänzung dar (Alpar, et al., 2008). Dies ergibt sich aus der Einschränkung, dass mit Internet Marketing (noch) nicht die ganze Bevölkerung erreichbar ist. Für die Informationsbeschaffung werden data mining Techniken eingesetzt, um die Werbung speziell nach den Interessen des Kunden auszurichten. 1 Information Retrieval Ein Information Retrieval (IR) System ist ein Werkzeug zur Selektion von Informationen. Dabei muss einerseits dem System die erforderlichen Informationen in geeigneter Form übermittelt, zum anderen den Nutzenden in geeigneter Darstellung präsentiert werden (Fühles-Ubach, 1997). Dabei liegt das Hauptproblem, neben der eigentlichen Suche, bei der Umsetzung des menschlichen Informationsbedarfs in eine für die Maschine verständliche Sprache und die Darstellung der maschinengerecht vorliegenden Informationen in einer für den Mensch verständliche Form (Fühles-Ubach, 1997). 1 Amazon protokolliert Interaktionen, um die Interessen eines Benutzers auszuforschen, um Werbung zielgerichteter und effektiver zu gestalten. Seite 6

7 Datenbanken Alle zuvor beschriebenen Einsatzgebiete haben die Gemeinsamkeit, dass Daten aus unterschiedlichsten Quellen verarbeitet werden. Durch den Einsatz von Migrations- und Transformationstechniken können diese Daten je nach Anwendungsbereich in die verschiedene Darstellungsformen umgewandelt werden. 2. Datenbanken Nach Howe ist eine Datenbank wie folgt definiert: Eine Datenbank ist eine Sammlung von nicht-redundanten Daten, die von mehreren Applikationen benutzt werden. (Howe, 2001) Aufgrund der weiten Verbreitung von Datenbanken als Speichermedium in der Praxis werden in diesem Kapitel Clustering- und Replikationsstrategien behandelt. Dabei wird auf grundlegende Konzepte eingegangen, die unter anderem von Migrationswerkzeuge eingesetzt werden (siehe Kapitel 4). Die in diesem Kapitel vorgestellten Ansätze werden vor allem bei der Migration zwischen homogenen Datenbankmanagementsystemen eingesetzt. Die Algorithmen für die Transformation zwischen beliebigen Datenquellen werden in Kapitel 3 behandelt. 2.1 Clustering Clustering ist ein vielfältiger Begriff und wird in der Literatur in unterschiedlichsten Bereichen verwendet. Ein Cluster ist eine Ansammlung von Knoten, die bei der Ausführung einer Anwendung zusammenwirken, nach außen jedoch als gemeinsame Einheit auftreten (Yousif, 1999). Durch Clustering kann die Performance, Skalierbarkeit, Verfügbarkeit und Wartbarkeit des Gesamtsystems erhöht werden (Derks, et al., 2000). Im Kontext von Datenbanken beschreibt Clustering die Verteilung von Daten auf mehrere Knoten. Dadurch kann die Performance und die Ausfallsicherheit des Systems durch (horizontale) Skalierung erhöht werden. Unter anderem versteht man unter Clustering auch die Verwendung mehrerer Datenbankinstanzen, idealerweise auf mehreren Maschinenknoten, die auf unterschiedliche Weise Daten speichern und verwalten (Eisentraut, et al., 2009) Shared Storage In Shared Storage Architekturen besitzt jeder Knoten innerhalb eines Clusters eine eigene CPU und einen privaten Speicher. Die Daten liegen auf einem gemeinsamen Speichermedium, worauf die Knoten über ein Netzwerk zugreifen (Derks, et al., 2000). In einer solchen Umgebung können gleichzeitig mehrere Transaktionen ausgeführt werden. Um Datenkonsistenz zu gewährleisten, ist jedoch ein globales Nebenläufigkeitsprotokoll erforderlich, das Zugriffskonflikte zwischen den Transaktionen auflöst. Üblicherweise erfolgt die Umsetzung durch zentrale oder verteilte Sperrmechanismen. Beim zentralen Sperren übernimmt ein spezieller Knoten die Verwaltung der Transaktionen. Jeder Knoten muss Zugriffe Seite 7

8 Datenbanken auf das Speichermedium bei diesem registrieren. Beim dezentralen Transaktionsmanagement erfolgt das Sperren direkt auf dem gemeinsamen Speichermedium (zum Beispiel beim Row- Level Locking). Danach werden die Daten vom gemeinsamen Speichermedium in die lokalen Puffer des Knoten geladen (Yousif, 1999). Um Datenintegrität zu gewährleisten, verhindert das globale Kohärenzprotokoll den Zugriff auf nicht aktuelle Daten, die sich in den lokalen Puffern der Knoten befinden (Yousif, 1999). Der Nachteil solcher Architekturen kommt bei einem Ausfall des Gesamtsystems zum Vorschein. Da nur ein gemeinsames Speichermedium existiert und bei dessen Ausfall das gesamte System betroffen ist, stellt diese Komponente einen Single Point of Failure dar. Deshalb ist eine gesonderte Absicherung des gemeinsamen Speichermediums erforderlich, damit bei Ausfall nicht der gesamte Cluster in seiner Funktionsfähigkeit beeinträchtigt wird (Eisentraut, et al., 2009). P P Global Controller Node 1 M Node 2 Node N Interconnection Network D D D D Abbildung 1 Shared Storage Architektur (Yousif, 1999) Beispiele von Shared Storage Architekturen sind DEC VAXcluster und IBM Sysplex. Der Anwendungsbereich solcher Architekturen liegt insbesondere im Hochverfügbarkeitsbereich. Beispielsweise nutzen Failover Cluster diese Architektur, in der ein ausgefallener Knoten sofort durch einen anderen ersetzt wird und dessen Funktion ausübt. Eine Migration von Daten und Schemata in Shared Storage Architekturen ist verhältnismäßig einfach umzusetzen, da sich der gesamte Datenbestand auf einem zentralen Speichermedium befindet. Seite 8

9 Datenbanken Shared Nothing Die Knoten innerhalb eines Clusters sind unabhängig von einander und sind im Unterschied zu Shared Storage Architektur mit eigenen Speichermedien ausgestattet (Stonebraker, 1986). Ein gemeinsames Speichermedium existiert nicht. Über ein Netzwerk sind die einzelnen Knoten miteinander verbunden (Derks, et al., 2000). Eine Migration von Daten und Schemata kann sich als Komplex erweisen, weil die Daten über die verschiedenen Knoten hinweg verteilt sind. Da kein gemeinsames Speichermedium existiert, wird die Datenbank auf die Knoten innerhalb des Clusters partitioniert. Es ist kein globales, sondern nur ein lokales Nebenläufigkeitsprotokoll erforderlich, weil jeder Knoten nur auf sein lokales Speichermedium zugreift (Yousif, 1999). Daraus ergeben sich positive Effekte auf die Performance und Skalierung des Gesamtsystems (Derks, et al., 2000). Desweiteren ist kein globales Kohärenzprotokoll erforderlich, weil sich Daten nur im Puffer desjenigen Knoten befinden können, auf dem sich das zugehörige Speichermedium befindet (Yousif, 1999). Um Daten zwischen den Knoten auszutauschen, unterscheidet man zwischen Function-Shipping und I/O-Shipping. Beim Function-Shipping erfolgt der Datenaustausch zwischen den Knoten über Remote Procedure Calls. Dabei ruft ein Knoten eine Funktion auf einem anderen Knoten auf, welcher die Anfrage verarbeitet und als Ergebnis die gewünschten Daten zurückgibt (Yousif, 1999). Der I/O-Shipping Ansatz gibt hingegen nicht das Ergebnis der Anfrage, sondern einen bestimmter Block des Speichermediums zurück. Der aufrufende Knoten muss die Daten zum gewünschten Resultat weiterverarbeiten (Yousif, 1999). Beide Modelle werden in der Praxis von unterschiedlichen Herstellern eingesetzt. Ein Beispiel für IO-Shipping ist die Oracle Implementierung für IBM SP2 Highly Parallel Systems. Datenbanken wie IBM DB2 Parallel Edition oder Sybase MPP und Informix XPS sind Beispiele für Function-Shipping, wo typischerweise SQL Anfragen an Knoten gerichtet werden, welche die entsprechenden Daten beinhalten (Teuffel, et al., 2004). Seite 9

10 Datenbanken P P M Node 2 Node N D D Node 1 Interconnection Network Abbildung 2 Shared Nothing Architektur (Yousif, 1999) Der Nachteil dieser Architektur liegt bei der Lastenverteilung, da nur schwer vorhersehbar ist, auf welche Daten besonders häufig zugegriffen wird (Yousif, 1999). Bei Knotenfehlern können Zeitverluste beim Zugriff und darüberhinaus eine erhöhte Netzwerkbelastung entstehen (Teuffel, et al., 2004). Die Suchmaschine Google verwendet diese Architektur um schnelle Antwortzeiten bei Suchabfragen zu erreichen (Duthel, 2009) Partitionierung Horizontale und vertikale Partitionierung sind wichtige Aspekte des physischen Datenbankdesigns und haben insbesondere starke Auswirkungen auf die Performance und Wartbarkeit eines Systems. Durch horizontale Partitionierung werden Daten in disjunkte Mengen zerlegt und auf verschiedenen physikalischen getrennten Knoten verteilt (Agrawal, et al., 2004). Bei der vertikalen Partitionierung hingegen werden disjunkte Mengen von Spalten auf unterschiedliche Knoten aufgeteilt (Agrawal, et al., 2004). 2.2 Replikation Grundsätzlich versteht man unter Replikation die Synchronisation von Datenbeständen zwischen verschiedenen Datenbankinstanzen. Dabei werden die Daten redundant auf autonome Knoten verteilt. Die Schlüsselfaktoren bei der Replikation sind Konsistenz, Verfügbarkeit und Performanz, die zueinander jedoch im Zielkonflikt stehen, weil üblicherweise die Verbesserung eines dieser Kriterien zu einer Reduktion der anderen Kriterien führt (Niemann, 2002). Ein in der Praxis häufig verwendeter Indikator zur Messung dieser Schlüsselfaktoren ist die Stillstandzeit des Gesamtsystems innerhalb eines bestimmten Zeitraumes. Grundsätzlich wird zwischen planmäßigen, beispielsweise Zeiträume für die Wartung eines Systems, und außerplanmäßigen Stillstandzeiten, wie Systemabstürze oder Stromausfälle, unterschieden. Die Verfügbarkeit ergibt sich aus dem Verhältnis der Stillstandzeiten zur Gesamtlaufzeit (Cecchet, et al., 2008). Seite 10

11 Datenbanken Bestimmte Replikationsstrategien können auch zum Zwecke der Migration von Datenbeständen eingesetzt werden (siehe Kapitel 4.1). Gray nimmt folgende Klassifizierung der Replikationsstrategien vor (siehe Table 1): Eager Replication Bei dieser Replikationsmethode werden Daten innerhalb einer atomaren Transaktion synchron repliziert. Es treten keine Nebenläufigkeitskonflikte auf. Der Nachteil liegt bei Einbußen in der Performance, weil zu jeder Transaktion zusätzliche Operationen für die Replikation der Daten synchron ausgeführt werden müssen (Gray, et al., 1996). Desweiteren sind synchrone Replikationsstrategien besonders in großen Umgebungen mit vielen Knoten schwierig zu skalieren. Je mehr Knoten sich im Gesamtsystem befinden, desto geringer ist der Durchsatz und die Verfügbarkeit des Gesamtsystems (Yasushi, et al., 2005). Lazy Replication Bei Lazy Replication werden Daten nach Abschluss der Transaktion asynchron zu den anderen Knoten repliziert, das heißt, Änderungen werden im Hintergrund übertragen und dabei entstandene Konflikte durch inkrementelle Algorithmen aufgelöst (Gray, et al., 1996). Aufgrund der asynchronen Replikation ist eine Nebenläufigkeitskontrolle erforderlich. Durch den Vergleich von Zeitstempel, die bei jeder Aktualisierung eines Knoten automatisch gesetzt werden, können Konflikte erkannt und behoben werden (Gray, et al., 1996). Der Vorteil ist die bessere Skalierbarkeit des Gesamtsystems, weil die Replikation der Daten in einer neuen, separaten Transaktion erfolgt (Yasushi, et al., 2005). Group Jeder Knoten darf seine Datenkopie verändern. Dieser Ansatz wird in der Literatur oft als Update Anywhere bezeichnet (Gray, et al., 1996). Jedoch können Nebenläufigkeitskonflikte auftreten, wenn zwei oder mehrere Knoten ihre Kopie der Daten zur selben Zeit ändern. Daher können inkonsistente Datenbestände bei Einsatz dieser Methode nicht verhindert, sondern nur im Nachhinein aufgelöst werden (Esther, et al., 2000). Master Jede Datenkopie ist einem Master Knoten zugeordnet, der Änderungen an diesen vornehmen darf. Nach jeder Aktualisierung werden die geänderten Daten an die anderen Knoten repliziert, die als Slave Knoten bezeichnet werden (Gray, et al., 1996). Seite 11

12 Datenbanken Propagation / Ownership Lazy Eager Group Master N Transaction N Object Owners N Transactions 1 Object Owner Table 1 Klassifizierung der Replikationsstrategien nach Gray (Gray, et al., 1996) 1 Transaction N Object Owners 1 Transaction 1 Object Owner Master/Slave-Replikation Die Replikationskopie am Master Knoten wird als primary copy bezeichnet (Pacitti, et al., 2001). Datenänderungen erfolgen nur an der primary copy und werden anschließend auf die Slave Knoten repliziert, die als secondary copys bezeichnet werden (Pacitti, et al., 2001). Master/Slave Architekturen können asynchron oder synchron implementiert werden, wobei in dieser Arbeit verstärkt auf asynchrone Ansätze eingegangen wird. Im Allgemeinen setzt sich die Replikationsstrategie aus vier Parametern zusammen: Ownership Es wird zwischen drei Arten von Knoten unterschieden: Master, Slave und MasterSlave. Ein Knoten wird als Master bezeichnet, wenn er nur primary copies, als Slave, wenn er ausschließlich secondary copies verwaltet (Pacitti, et al., 2000). Ein Knoten ist zugleich Master und Slave (MasterSlave), wenn er sowohl primary- als auch secondary copies speichert (Pacitti, et al., 2000). Propagation Durch diesen Parameter erfolgt die Steuerung, wann Änderungen einer primary copy auf anderen Knoten, welche die secondary copies speichern, repliziert werden müssen. Grundsätzlich wird zwischen der deferred und der immediate Strategie unterschieden. Bei ersteren werden die auf der primary copy geänderten Daten nach Abschluss der Änderungstransaktion auf die anderen Knoten repliziert. Bei der immediate propagation Strategie hingegen erfolgt die Replikation sofort nach jeder Schreiboperation (Pacitti, et al., 2000). Refreshment Der trigger Parameter gibt an, wann am Slave Knoten die Refreshment Transaktion gestartet werden soll. Es wird zwischen den trigger Modi deferred, immediate und wait unterschieden. Der Propagation- und der Refreshment Parameter ergeben zusammen die Update Propagation Strategie: (Pacitti, et al., 2000) Seite 12

13 Datenbanken Propagation Trigger Mode Update Propergation Deferred Immediate Immediate Immediate Immediate Wait Deferred-Immdeiate Immediate-Immediate Immediate-Wait Table 2 Update Propagation Strategien Bei einer Deferred-Immediate Strategie werden Änderungen nach Abschluss der Transaktion zu den Slave Knoten repliziert, wobei am Slave Knoten die Änderungen sofort nach Erhalt der Daten durchgeführt werden. Bei der Immediate-Immediate Strategie erfolgt die Replikation zu den Slave Knoten sofort nach jedem Schreibvorgang, noch bevor die eigentliche Transaktion beendet wurde. Nach Erhalt der Daten wird am Slave Knoten eine Refreshment Transaktion gestartet. Der Immediate-Wait Modus ist ähnlich der Immediate-Immediate Strategie, mit dem Unterschied, dass die Refreshment Transaktion am Slave Knoten erst gestartet wird, nachdem alle Schreibvorgänge repliziert wurden (Pacitti, et al., 2000). Configuration Es existieren unterschiedliche Ansätze für mögliche Konfigurationen. One Master per Slave ist eine azyklische Konfiguration. Jeder Slave Knoten ist einem Master Knoten zugeordnet. Bei Änderung der primary copy repliziert der Master Knoten (R) die Änderungen an die Slave Knoten (r1, r2, r2) (Pacitti, et al., 2001). Bei One Slave per Master handelt es sich ebenfalls um eine azyklische Konfiguration, bei der Daten von unterschiedlichen primary copies (R, S, U) auf einen Slave Knoten (r, s, u) repliziert werden (Pacitti, et al., 2001). Folgende Abbildung zeigt die beiden Konfigurationsmöglichkeiten: Abbildung 3 One-Master-per Slave (Pacitti, et al., 2001) Abbildung 4 One Slave-per Master (Pacitti, et al., 2001) Seite 13

14 Datenbanken Multimaster-Replikation Bei der Multimaster-Replikation sind gleichberechtigte Knoten innerhalb eines Clusters miteinander verbunden, wobei alle beteiligten Knoten Schreib- und Leseoperationen ausführen können (Eisentraut, et al., 2009). Für die Koordination dieser Operationen sind umfangreiche Kommunikations- und Sperrmechanismen erforderlich, sowie aufwendige Nebenläufigkeitssysteme (Eisentraut, et al., 2009). Aufgrund der Ähnlichkeit zu Master/Slave Systemen wird bezüglich weiterer Ausführungen auf das vorherige Kapitel verwiesen Read One Write All Read One Write All (ROWA) ist ein synchrones Replikationsverfahren. Es müssen alle Replikate vor Abschluss einer Änderungstransaktion aktualisiert werden. Dadurch wird sichergestellt, dass zu jedem Zeitpunkt immer alle Replikate auf den aktuellsten Stand sind. Deshalb kann für eine Leseoperation ein beliebiger Knoten ausgewählt werden. Die Vorteile des Verfahrens sind eine hohe Verfügbarkeit bei Lesezugriffen, geringer Kommunikationsaufwand und einfache Skalierung (Rahm, 1994). Der Nachteil des Verfahrens zeigt sich bei Änderungsoperationen. Einerseits ist der Einsatz eines verteilten Sperrverfahrens notwendig, um vor jeder Änderung alle Replikate mit einer Schreibsperre zu belegen (bei einer großen Anzahl von Knoten führt dies zu einem hohen Kommunikationsaufwand), andererseits kann keine Änderung mehr vorgenommen werden, sobald ein Replikat nicht mehr verfügbar ist (Abdelsalam, et al., 1996). Im Ergebnis ist meines Erachtens ROWA für Umgebungen mit einer großen Anzahl von Knoten und vielen Änderungsoperationen nicht geeignet. Eine Erweiterung von ROWA ist das Read One Write All Available (ROWA-A) Verfahren. Der wesentliche Unterschied liegt darin, dass nicht alle Replikate innerhalb einer Änderungstransaktion aktualisiert werden müssen, sondern nur die im Zeitpunkt der Änderung verfügbaren Replikate (Rahm, 1994). Dadurch werden Verzögerungen vermieden, wenn Knoten im System nicht verfügbar sind. Bevor ein ausgefallener Knoten wieder verfügbar sein kann, müssen die in der Zwischenzeit erfolgten Änderungen an diesem Knoten nachgezogen werden. Der Nachteil dieser Variante liegt beim erhöhten Validierungsaufwand, da vor Beendigung der Transaktion überprüft werden muss, ob alle nicht verfügbaren Knoten weiterhin nicht verfügbar sind und ob alle verfügbaren Knoten weiterhin verfügbar sind (Abdelsalam, et al., 1996). Trifft eine Bedingung nicht zu, muss die Transaktion abgebrochen werden Voting Beim Majority-Consensus-Verfahren muss eine Änderungstransaktion zunächst eine Mehrheit der Replikate mit einer Schreibsperre (Stimme) belegen und kann danach die Änderung durchführen (Rahm, 1994). Zu einem Zeitpunkt kann immer nur eine Transaktion die Mehrheit der Stimmen haben, sodass Nebenläufigkeitsprobleme ausgeschlossen sind. Dabei greifen die Knoten nicht direkt auf die Replikate zu, sondern über einen Database Management Process Seite 14

15 Datenbanken (DBMP), der den Algorithmus zur Konsensfindung implementiert (siehe Abbildung 5) (Thomas, 1979). Der Vorteil liegt darin, dass selbst nach einem Rechnerausfall oder Netzwerkverbindungsfehlern ein konsistenter Datenbestand erhalten bleibt, solange die Mehrheit der Stimmen gehalten wird (Rahm, 1994). Der Nachteil liegt im sehr hohen Kommunikationsaufwand zwischen den Knoten zur Konsensfindung (Thomas, 1979). DB Copy 1 DB Copy 2 DB Copy N DBMP 1 DBMP 2 DBMP N Update Query Query AP 1 AP 2 AP N Abbildung 5 Architektur des Majority-Consensus Verfahren (Thomas, 1979) Bei einer Änderungsoperation werden folgende Schritte durchlaufen (Thomas, 1979): 1. Query Database Die Anwendung, welche ein Replikat ändern möchte, sendet eine Anfrage an den DBMP, um Objekte (base variables) für das Konsensverfahren zu selektieren. Für die Nebenläufigkeitskontrolle wird jedes Objekt mit einem Zeitstempel assoziiert, der ebenfalls zurückgegeben wird. 2. Compute Update Die Anwendung führt die Änderungen auf den zuvor selektierten Daten durch. Diese neue Menge wird als update variables bezeichnet, die eine Untermenge der base variables sind. 3. Submit Request Im nächsten Schritt erzeugt die Anwendung eine Änderungsanfrage mit den update variables und den base variables und sendet sie zu einem DBMP. Seite 15

16 Datenbanken 4. Synchronize Update Jeder DBMP muss entscheiden, ob er die Änderungsanfrage akzeptiert oder verwirft. Zu diesem Zweck wird auf jeden teilnehmenden Knoten dieselbe Votingprozedur ausgeführt. Dabei werden im Wesentlichen bei der Entscheidungsfindung die Zeitstempel verglichen (Die Prozedur stimmt für die Änderung, wenn die Daten des Replikats in der Zwischenzeit nicht geändert wurden). 5. Apply Update Die Änderungen an allen Replikaten werden durch die jeweiligen DBMPs durchgeführt, wenn die Änderungsanfrage akzeptiert wurde. 6. Notify Der DBMP informiert die Anwendung, welche die Anfrage erzeugt hat, über den Status. Wurde die Änderungsanfrage nicht akzeptiert, so wird dieser Vorgang wiederholt. Der Algorithmus setzt sich aus fünf Regeln zusammen: (Thomas, 1979): Communication Rule Es wird zwischen zwei unterschiedlichen Arten, wie DBMPs untereinander kommunizieren, unterschieden. Im broadcast Modus sendet der DBMP gleichzeitig einen Submit Request an alle anderen DBMPs. Beim daisy chain Modus erfolgt die Kommunikation in einer Kette und endet, wenn alle DBMPs ihre Stimme abgegeben haben. Folgende Abbildungen zeigen die beiden Ansätze: Abbildung 6 Boradcast Modus (Thomas, 1979) Seite 16

17 Datenbanken Abbildung 7 Daisy Chain Modus (Thomas, 1979) Der Vorteil beim boradcast Modus liegt in der kurzen Zeitspanne zwischen Senden und Empfangen, da alle Knoten gleichzeitig verständigt werden. Hingegen erhöht sich der Netzwerkverkehr. Beim daisy chain Modus werden die Nachrichten von Knoten zu Knoten übertragen, somit die Anzahl der Nachrichten reduziert. Die Antwortzeiten einer Anfrage sind dagegen höher als beim broadcast Modus. Voting Rule Auf dieser Regel baut die Nebenläufigkeitskontrolle auf. Dabei werden die Zeitstempel der Anfrage (base variables) mit jenen in der lokalen Datenbank verglichen. Stimmen die Werte nicht überein, dann gibt die Prozedur NEIN zurück, ansonsten JA. Request Resolution Rule Haben mehr als die Hälfte mit JA gestimmt, dann wird die Änderungsanfrage des Senders akzeptiert. Update Application Rule Diese Regel legt fest, wie Änderungen in die lokale Datenbankkopie eines Knoten übernommen werden. Eine Aktualisierung wird nur durchgeführt, wenn der Zeitstempel in der lokalen Datenbank älter als in der Änderungsanfrage (base variables) ist. Timestamp Generation Rule Wie zuvor bereits erwähnt, wird die Nebenläufigkeitskontrolle durch das Setzen von Zeitstempel implementiert. Dabei wird bei der Erstellung einer Änderungsanfrage ein Zeitstempel generiert, der bei Akzeptanz (Mehrheit der Stimmen) in den Datenbestand übernommen wird. Auf die Spezifikation der Anforderungen an Zeitstempel wird auf weiterführende Literatur verwiesen. Seite 17

18 Migration 3. Migration Das Problem der gemeinsamen Nutzung von Daten aus unterschiedlichsten Quellen innerhalb oder zwischen Unternehmen hat in letzter Zeit große Aufmerksamkeit in der Forschung erhalten (Madhavan, et al., 2003). In den letzten Jahren wurden eine Reihe von Strategien für den Austausch von Daten entwickelt, beginnend mit federated databases, gefolgt von data integration systems, peer data management systems und data exchange systems. Ein feederated database system ist eine Ansammlung von kooperierender, aber autonomen Datenbanksysteme die als component database systems bezeichnet werden (Sheth, et al., 1990). Jene Software, welche steuernde und koordinierende Bedienung aller component database systeme ermöglicht wird als federated database managment system bezeichnet (Sheth, et al., 1990). Bei data integration systems wird dem Anwender eine einheitliche Sicht auf Daten ermöglicht, die aus den unterschiedlichsten Quellen stammen können. Das System ist formal definiert durch <G, S, M>, wobei S für das globale Schema, G für eine heterogene Menge von Quellschemata und M für das Mapping zwischen den Quellschemata und dem globalen Schema steht (Lenzerini, 2002). Bei peer database management systems (PDMS) handelt es sich um eine dezentrale und leicht erweiterbare Datenbankmanagementarchitektur, in der Benutzer neue Daten, Schemainformationen oder sogar Zuordnungen zwischen Schemata den anderen peers bereitstellen können (Halevy, et al., 2003). PDMS repräsentiert den nächsten Schritt in der Entwicklung und ist wesentlich mächtiger als data integration systems, da das globale Schema von data integration systems durch eine Ansammlung von miteinander verknüpften semantischen Mappings zwischen den einzelnen peers ersetzt wird (Halevy, et al., 2003). Insbesondere im Web ist ein breites Spektrum an Daten in unterschiedlichen heterogenen Quellen und Formaten verfügbar. Eine Vielzahl von Systemen nützen diese Daten, sodass in den letzten Jahren die Wichtigkeit von data translation und data convention Mechanismen deutlich anstieg (Milo, et al., 1998). Systeme, die eine solche Funktionalität bereitstellen, werden als data exchange systems bezeichnet. Zentrales Element aller dieser Architekturen ist die Spezifikation von semantischen Mappings zwischen Datenquellen. Diese semantischen Zuordnungen beschreiben die Beziehung zu einem oder mehreren Schemata und werden für die Migration- und Transformation von Daten zwischen diesen verwendet (Madhavan, et al., 2003). Seite 18

19 Migration 3.1 Schema Mapping Viele moderne Anwendungen (Data Warehouse, E-Commerce, et cet era) haben die Anforderung, bereits vorhandene Daten, die eine bestimmte Struktur aufweisen, in eine andere Darstellungsform zu transformieren (Renée, et al., 2000). Bei diesem Vorgang wird zunächst das Zielschema erstellt und im Anschluss die Mappings zwischen den Schemata. Anhand der im Mapping definierten semantischen Regeln können die Daten vom Quell- in das Zielschema übertragen werden. Bei diesem Transformationsprozess können Konflikte auftreten, weil die vollständige Abbildung der semantischen Bedingungen sehr schwierig ist. Nach Kim und Seo wird zwischen Struktur- und Datenkonflikten unterschieden (Kim, et al., 1991) Strukturkonflikte Bei Strukturkonflikten wird zwischen table versus table, attribute versus attribute und table versus attribute Konflikten unterschieden. Folgende Aufzählung zeigt einen Überblick: (Kim, et al., 1991) 1) Table versus table Konflikte a) One to one table Konflikte i) Tabellennamenkonflikte (1) Unterschiedliche Namen für gleiche Tabellen (2) Gleicher Name für unterschiedliche Tabellen ii) Tabellenstruktur Konflikte (1) Fehlende Attribute (2) Fehlende, aber implizite Attribute iii) Tabellenconstraint Konflikte b) Many to many Konflikte 2) Attribute versus attribute Konflikte a) One to one Attribute Konflikte i) Attributnamenskonflikte (1) Unterschiedliche Namen für gleiche Attribute (2) Gleicher Name für unterschiedliche Attribute (3) Default Values Konflikte (4) Attributeconstraint Konflikte (a) Datentypkonflikte (b) Attributintegrität Konflikte ii) Many to many Attribute Konflikte b) Table versus Attribute Konflikte Sind Quell- und Zielschema unterschiedlich definiert, so können table versus table Konflikte auftreten. Eine Subkategorie stellen die one to one Konflikte dar. Sie treten auf, wenn für dieselbe Information in den Schemata, unterschiedliche Namen, Strukturen oder Constraints Seite 19

20 Migration verwendet werden. Hingegen treten many to many Konflikte auf, wenn Quell- und Zielschemata eine unterschiedliche Anzahl von Tabellen verwenden, um dieselbe Information darzustellen. Es ist zu beachten, wenn im Mapping nicht alle Attribute des Quellschemas abgebildet werden, dieses nicht mehr vom Zielschema rekonstruiert werden können. Weiteres werden durch fehlende Attribute im Zielschema Constraints verletzt (Legler, et al., 2007). Attribute versus attribute Konflikte treten auf, wenn für semantisch äquivalente Attribute unterschiedliche Definitionen in Tabellen existieren. Bei den Attribut Constraints wird zwischen Datentyp- und Integritätskonflikte unterschieden. Erstere treten auf, wenn für semantisch idente Attribute unterschiedliche Datentypen verwendet werden, bei Zweiteren werden in Quell- und Zielschema unterschiedliche Integritätsbedingungen verwendet. Many to many Konflikte treten auf, wenn Quell- und Zielschema eine unterschiedliche Anzahl von Attributen verwenden, um dieselbe Information zu beschreiben (zum Beispiel: Quellschema: Attribute: Vorname, Nachname; Zielschema: Attribut: Name). Bei Datentypen wird zwischen kompatiblen, partiell kompatiblen und nicht kompatiblen differenziert. Bei nicht kompatiblen tritt ein Datenverlust ein, bei partiell kompatiblen können je nach übertragenem Wert Verluste auftreten (zum Beispiel: Abschneiden von Kommazahlen) (Legler, et al., 2007). Table versus attribute Konflikte treten auf, wenn beispielsweise das Quellschema eine Tabelle, das Zielschema Attribute verwendet, um dieselbe Information darzustellen. (zum Beispiel: Quellschema: Tabelle Adresse; Zielschema: Attribut Adresse in der Tabelle Person) (Kim, et al., 1991) Datenkonflikte Folgende Aufzählung zeigt einen Überblick über mögliche Datenkonflikte: (Kim, et al., 1991) 1) Falsche Daten a) Ungültige Eingangsdaten b) Obsolete Daten 2) Unterschiedliche Darstellung der gleichen Daten oder gleiche Darstellung für unterschiedliche Daten a) Unterschiedliche Ausdrücke b) Unterschiedliche Einheiten Ungültige Eingangsdaten liegen vor, wenn die Attribute in den Schemata übereinstimmen, jedoch die konkreten Wertausprägungen unterschiedlich sind (zum Beispiel: Quellschema: Alter = 25; Zielschema: Alter = 28). Dieser Konflikt ist meist die Folge von Nichteinhaltung von Integritätsbedingungen. Werden Daten redundant gespeichert und nicht miteinander abgeglichen, so kann ein Datenbestand seine Aktualität verlieren. Solche veralteten Daten werden auch als obsolete Daten bezeichnet. Seite 20

21 Migration Unterschiedliche Ausdrücke liegen vor, wenn für semantisch gleiche Attribute die Darstellung der Daten unterschiedlich ist (zum Beispiel: Schulnoten können unterschiedlich dargestellt werden: A, Sehr Gut, 1, Excellent). Ein numerischer Wert erhält durch die Zuordnung von Einheiten eine andere semantische Bedeutung. (zum Beispiel: 10 km, 10 m, 10 kg, 10 g) (Kim, et al., 1991) Mapping Algorithmus Die Beziehungen zwischen den Schemata werden anhand semantischer Ähnlichkeiten gebildet und werden als Korrespondenzen bezeichnet, die als Pfeile zwischen Quell- und Zielschema modelliert werden. Ein Schema Mapping ist demnach eine Menge von Korrespondenzen, das als Grundlage für die Transformation zwischen den Schemata dient (Legler, et al., 2007). Das linke Schema in Abbildung 8 zeigt das relationale Quellschema mit den Relationen firma und spende. Jede Spende gehört zu einer Firma, was durch den Fremdschlüssel firmaid in der Relation spende abgebildet wird. Auf der rechten Seite befindet sich das Ziel XML Schema. Der semantische Kontext im Zielschema entspricht im Wesentlichen dem des Quellschemas, jedoch unterscheiden sich die Strukturen signifikant. Die Elemente organisationen und buchungen werden nach Städten gruppiert. Die Einnahmen der Organisation werden als Subelemente abgebildet, wobei durch den Fremdschlüssel buchungid im Element einnahme eine Verbindung zur entsprechenden Buchung hergestellt wird. Dieses Beispiel dient als Basis für die Erklärung des Algorithmus. Abbildung 8 Quellschema spendendb und Zielschema haushaltdb (Lehner, 2007) Die Ausganssituation stellen zwei unabhängig voneinander modellierte Schemata und eine Menge von Korrespondenzen zwischen den Schemata dar. Gesucht ist eine Anfrage, die Daten vom Quell- in das Zielschema transformiert. Dabei soll die Semantik und allenfalls Integritätsbedingungen des Quellschemas, im Zielschema abgebildet, sowie möglichst alle Korrespondenzen erfasst werden (Lehner, 2007). Der Algorithmus setzt sich aus drei Schritten zusammen: (Popa, et al., 2002) Seite 21

22 Migration 1. Intra-Schema Assoziationen Im ersten Schritt muss herausgefunden werden, wie Elemente innerhalb der Schemata semantisch zueinander in Beziehung stehen. In relationalen Schemata werden semantische Verbindungen zwischen zwei atomaren Elementen in zweifacherweise dargestellt. Befinden sich zwei Attribute innerhalb derselben Relation oder sind Attribute über mehrere Relationen verteilt, jedoch über Fremdschlüssel miteinander in Beziehung, so indiziert dies eine semantische Zusammengehörigkeit. Das bedeutet, dass sowohl die Struktur von Relationen als auch Constraints für die semantische Interpretation bedeutsam sind. Bei isolierter Betrachtung der Struktur ergeben sich aus der Menge der semantisch zusammenhängenden Attribute primary paths, wobei bei relationalen Schemata per Definition immer ein primary path existiert. Bei verschachtelten Strukturen stellen sämtliche Elemente, die denselben Vaterknoten beziehungsweise gleiche Vorfahren haben, einen primary path dar. In Bezug auf Listing 1 werden diese Pfade wie folgt berechnet: (Popa, et al., 2002) (a) (b) S 1: SELECT * FROM f IN spendendb.firmen; S 1: SELECT * FROM s IN spendendb.spenden; H 1: SELECT * FROM h IN haushaltdb; H 1: SELECT * FROM h IN haushaltdb, o IN h.stadthaushalt.organisationen; H 1: SELECT * FROM h IN haushaltdb, o IN h.stadthaushalt.oranisationen, e IN o.org.einnahmen; H 1: SELECT * FROM h IN haushaltdb, b IN h.stadthaushalt.buchungen; Listing 1 Primary paths, (a) spendendb, (b) haushaltdb Im nächsten Schritt werden alle Verbindungen betrachtet, die der Semantik der referenziellen Integritätsbedingungen der Schemata entsprechen. Dabei stellen die referenzielle Integritätsbedingungen die Gleichheit eines Elements (oder eine Menge von Elementen) in zwei primary paths, sicher. Dadurch können mehrere primary paths zu einer größeren Menge von logisch zusammenhängenden Elementen zusammengefasst werden (Popa, et al., 2002). r 1: FOR s IN spendendb.spenden EXISTS f IN spendendb.firmen WHERE f.firma.firmaid = s.spende.firmaid r 2: FOR h IN haushaltdb, o IN h.stadthaushalt.oranisationen, e IN o.org.einnahmen EXISTS b IN h.stadthaushalt.buchungen WHERE b.buchung.buchungid = e.einnahme.buchungid Listing 2 Verbindung durch (r1) Fremdschlüssel und (r2) verschachtelte Constraints Seite 22

23 Migration Im nächsten Schritt werden logisch zusammenhängende Verbindungen gesucht, welche eine maximale Menge von Elementen zurückgeben. Zur Veranschaulichung wird im relationalen Schema der Abbildung 8 das Attribut projekt der Relation spende in eine eigene Relation ausgelagert und mit der Relation spende über einen Fremdschlüssel verknüpft (Popa, et al., 2002). S 1 : SELECT * FROM f IN spendendb.firmen, s IN spendendb.spenden WHERE f.firma.firmaid = s.spende.firmaid; S 2 : SELECT * FROM f IN spendendb.firmen, s IN spendendb.spenden, p IN spendendb.projekte WHERE f.firma.firmaid = s.spende.firmaid AND s.spende.projektid = f.projekte.projektid Listing 3 Zusammenhänge Verbindungen geben eine maximale Menge von Elementen zurück S 1 und S 2 sind nicht ident, da S 2 eine größere Menge von Elementen zurückgibt. Durch Verfolgung alle referenziellen Integritätsbedingungen der Relation spenden werden in S 2 alle logisch zusammenhängenden Tupel zurückgegeben (Popa, et al., 2002). 2. Inter-Schema Assoziationen Logische Relationen sind die Grundlage für das Verständnis von Korrespondenzen. Beispielsweise werden die Korrespondenzen v 1 und v 2 aufgrund der logischen Relation S 1 zusammen interpretiert. v 1: FOR f IN spendendb.firmen EXISTS h IN haushaltdb, o IN h.stadthaushalt.organisationen WHERE f.firma.name = o.org.orgname v 2: FOR s IN spendendb.spenden EXISTS h IN haushaltdb, o IN h.stadthaushalt.organisationen e IN o.org.einnahmen WHERE s.buchung.spendeid = e.einnahme.spendeid Listing 4 Die Korrespondenzen v1 und v2 werden durch alle primary paths interpretiert Bei der Interpretation nach Listing 4 werden die Semantik der Quell- und Zielschemata ignoriert. Einnahmen werden zwar von spenden erzeugt, aber die Aussage, dass sich einnahmen innerhalb eines org Elementes befinden, welches von einer firma erzeugt wird, findet keine Berücksichtigung. Deshalb werden für die Interpretation der Korrespondenzen nicht primary paths, sondern die logische Relationen herangezogen. Seite 23

24 Migration v 12: FOR s IN spendendb.spenden, IN spendendb.firmen p IN spendendb.projekte WHERE f.firma.firmaid = s.spende.spendeid AND p.projekte.projektid = s.spende.projektid LET w1 = f.firma.name, w2 = s.spende.spendeid EXISTS h IN haushaltdb, o IN h.stadthaushalt.organisationen e IN o.org.einnahmen, b IN h.buchunge WHERE e.buchungid = b.buchungid AND o.org.orgname = f.firma = w1 AND e.spende.spendeid = w2 Listing 5 Die Korrespondenzen v1 und v2 werden durch logische Relationen interpretiert 3. Erstellung der Anfrage Für die Durchführung der Transformation muss für jede Korrespondenz eine Anfrage erstellt werden. Im ersten Schritt werden die Daten aus dem Quellschema selektiert und daraus die Anfrage anhand der Informationen im Mapping für das Zielschema generiert. Dabei ergeben sich zwei Hauptproblembereiche, einerseits die Erzeugung neuer Werte, andererseits die Gruppierung von verschachtelten Elementen (Lehner, 2007). Wie Abbildung 9 zeigt, ist das Attribut buchungid nicht im Mapping enthalten und wird deshalb nicht in das Zielschema übertragen. Um dieses Problem zu lösen, sind mehrere Lösungswege denkbar. Für das Attribut buchungid wird entweder ein NULL oder Default Wert vergeben, eine eindeutige ID generiert oder eine Skolemfunktion ermittelt die buchungid anhand aller Werte innerhalb der entsprechenden Korrespondenz (Lehner, 2007). Wie in Abbildung 9 ersichtlich, ist nur das Attribut betrag im Mapping enthalten, sodass die Skolemfunktion, SK(betrag) lautet. Abbildung 9 Konflikt: buchungid nicht im Mapping enthalten In der nächsten Abbildung wird eine Integritätsbedingung im Zielschema verletzt, da die Beziehung zwischen buchung und einnahme nicht berücksichtigt wird. Der Verlust von Assoziationen erfordert das Erfinden neuer Schlüssel durch eine Skolemfunktion, wobei dieselbe Funktion sowohl für die Vergabe der Primär- und Fremdschlüssel angewendet werden muss. Dadurch wird gewährleistet, dass idente Werte für die Schlüssel generiert werden. Die nächste Abbildung zeigt die Lösung des Problems: Seite 24

25 Migration Abbildung 10 Skolemfunktion erzeugt einen Schlüssel für buchungid (Lehner, 2007) Abbildung 11 Grupierung von Elementen (Lehner, 2007) Obwohl alle Attribute im Mapping vorhanden sind, kann es dennoch zum Verlust von Assoziationen kommen. Wie in Abbildung 11 zeigt, muss für jedes Element haushaltdb ein Schlüssel anhand der Skolemfunktion, SK(land, stadt), vergeben werden, damit für jedes weitere Element aus firmen derselbe Wert errechnet werden kann. Aufgrund dieses Wertes kann das neue Element unter dem gleichen Element geschachtelt werden. Die Übersetzung der Anfrage in eine schemaspezifische Sprache (zum Beispiel SQL, XQuery, et cet era) wird im Kapitel 4.2 behandelt. 3.2 Schema Matching Eine grundlegende Operation für die Manipulation von Schemainformationen ist Match. Die Funktion Match hat zwei Schemata als Eingabeparameter und liefert als Ergebnis ein Mapping zwischen diesen zurück, ohne den Verlust von semantische Informationen (Li, et al., 1994). Das manuelle durchführen von Schema Matching ist ein langwieriger, zeitaufwendiger, fehleranfälliger und kostspieliger Prozess (Rahm, et al., 2001). Durch die erhöhte Komplexität der Schemata, beschleunigt durch die stetige Weiterentwicklung von Datenbanken und Anwendungen, ist eine manuelle Erzeugung der Mappings zwischen den Datenquellen aus betriebswirtschaftlicher Sicht nicht sinnvoll. Semantik kann in vielen heterogenen Datenquellen enthalten sein, wie beispielsweise in Datenbankenmodellen, konzeptuellen Schemata, Anwendungsprogrammen oder in den Köpfen der Benutzer. Das Extrahieren von semantischen Informationen aus den Köpfen der Benutzer ist ein nicht automatisierbarer Prozess, es können nur individuelle Befragungen durchgeführt werden (Li, et al., 1994). Die semantischen Informationen aus Schemata oder Daten können Seite 25

26 Migration zumeist automatisiert ermittelt werden, jedoch besteht immer ein Restrisiko (abhängig von der Datenqualität) für das Auftreten von falschen oder fehlenden Matching Bedingungen (Hong Hai, 2007). Deshalb sind Techniken erforderlich, um erworbenes Wissen bei der Auflösung von semantisch unterschiedlichen Beziehungen wiederzuverwenden, in anderen Worten, der Algorithmus muss lernfähig sein. Jede Implementierung einer Match Prozedur verwendet einen oder mehrere Algorithmen für die Erzeugung von Match Bedingungen. Greift eine Matchprozedur auf mehrere Ansätze zurück, so werden sie als Combinding Matchers bezeichnet Ein Hybrid Matcher integriert verschiedene Ansätze fix in seine Struktur, während die Composite Matchers die Ergebnisse von unabhängig voneinander ausgeführten Matcher miteinander verbindet. Element versus Structure Mapping Matching kann für individuelle Schemaelemente (Element), wie beispielsweise für Attribute oder zusammengesetzte Elemente (Structure), durchgeführt werden. Linguistic versus Constraint Bei einem linguistischen Ansatz erfolgt das Matching anhand von Namen oder Beschreibungen von Schemaelementen, bei einem Contraint Ansatz hingegen auf Schlüssel und Beziehungen. Unterschiedliche Kardinalitäten In einem Match Ergebnis können ein oder mehrere Elemente des ersten Schemas in Verbindung mit einem oder mehreren Elemente des anderen Schemas sein, woraus unterschiedliche Kardinalitäten folgen. Die wichtigsten Differenzierungen veranschaulicht folgende Klassifizierung: (Rahm, et al., 2001): Seite 26

27 Migration Schema Matching Individual matcher approaches Combining matchers Schema-only based Instance/contents-based Hybrid matchers Composite matchers Element-level Structure-level Element-level Manual composition Automatic composition Linguistic Constraintbased Constraintbased Linguistic Constraintbased Further criteria: Match cardinality Auxiliary information used Name similarity Description similarity Global namespaces Type similarity Key properties Graph matching IR techniques Value pattern and ranges Sample approaches Abbildung 12 Klassifikation von Schema Matching Ansätzen (Rahm, et al., 2001) Seite 27

28 Migration Schema based Mapping Diese Art von Mapping berücksichtigt keine Daten, sondern nur Schemainformationen. Die zur Verfügung stehenden Informationen inkludiert die Eigenschaften der Schemaelemente, wie beispielsweise Namen, Beschreibungen, Datentypen, Beziehungstypen (zum Beispiel: 1:1, 1:n), Constraints und die Schemastruktur (Rahm, et al., 2001) Instance based Mapping Diese Art von Schema Matching liefert wichtige Informationen bezüglich der Inhalte und der Bedeutung von Schemaelementen (Rahm, et al., 2001). Wenn daher nützliche Schemainformationen nur begrenzt vorhanden sind, dass bei semi-strukturierten Daten häufig der Fall ist, sollte meines Erachtens Instance based Mapping eingesetzt werden. Ist kein Schema vorhanden, so kann dieses entweder manuell oder automatisch aus den Daten konstruiert werden. Der Einsatz von Instance based Mapping Strategien kann auf zweifacherweise erfolgen. Einerseits kann bei Kombination mit einem Schema based Matcher die Effizienz erhöht werden (zum Beispiel ein Constraint based Schema Matcher kann aufgrund der Datenwerte Rückschlüsse auf verwendete Datentypen ziehen) (Lehner, 2007). Andererseits kann dieser Ansatz für sich isoliert eingesetzt werden. Dabei werden aus der Attributmenge der beiden Schemata die wesentlichen Eigenschaften extrahiert, daraus das Kreuzprodukt gebildet und eine Überprüfung der Ähnlichkeit dieser Paare durchgeführt (Rahm, et al., 2001). Seite 28

29 Anbieter von Lösungen 4. Anbieter von Lösungen Die in den vorherigen Kapiteln diskutierten Ansätze finden sich in einer Vielzahl von Produkten wieder. Zunächst wird Slony-I für PostgreSQL Datenbanken vorgestellt, welches auf einer Master/Slave Architektur basiert. Als Schematransformationswerkzeug wird IBM Clio behandelt. Der Schwerpunkt liegt bei der Transformation von Daten in eine andere Darstellungsform, die sich vom Quellschema unterscheidet. 4.1 Slony-I Slony-I ist ein weit verbreitetes Replikationssysteme für PostgreSQL Datenbanken (Parveen, et al., 2010), welches nach dem asynchronen Master/Slave-Verfahren arbeitet und frei unter der Berkeley Software Distribution (BSD) Lizenz verfügbar ist (Browne). Es unterstützt mehrere Slave-Knoten, wobei Änderungen nur über einen Master Knoten repliziert werden. Die Software ist sehr flexibel und insbesondere für Load-Balancing Systeme ausgelegt. Die Stärke von Slony-I ist seine Konfigurierbarkeit. So ist das Hinzufügen oder Entfernen von Knoten während des laufenden Betriebes möglich, ohne den gesamten Clusterbetrieb zu blockieren. Darüberhinaus bietet Slony-I eine mächtige Kommandosprache, wodurch das System über die Kommandozeile oder über andere Administrationswerkzeuge einfach konfiguriert werden kann. Slony-I kann auch als Migrationstool herangezogen werden, insbesondere wenn für produktive Systeme nur eine minimale Ausfallzeit akzeptiert werden kann (Eisentraut, et al., 2009). Auf diese Weise kann die Ausfallzeit beim Umschalten der Produktivsysteme reduziert werden, die Datenübernahme vom Alt- auf das Neusystem erfolgt im laufenden Betrieb Architektur Der einzige Knoten eines Slony-I Clusters, der Änderungen an Objekten einer Datenbank durchführen kann, ist der Master-Knoten, der auch als orgin bezeichnet wird (Browne). Das Werkzeug unterstützt die Replikation von Tabellen und Sequenzen, die zu einem Set zusammengefasst werden. Die Slave-Knoten, die auch Subscriber genannt werden, abonnieren beim orgin ein oder mehrere Set(s) und geben damit bekannt, dass Daten auf diese Knoten repliziert werden sollen (Marcotte, 2005). Die zentrale Komponente von Slony-I sind die sogenannten slon Prozesse, welche die Replikation durchführen und das Ergebnis kontrollieren. Für einen orgin und subscriber muss innerhalb eines Clusters ein slon Prozess angelegt werden (Browne). Die Ausführung der Replikation erfolgt durch Trigger, die Datenänderungen in den von Slony-I eingerichteten Log- Tabellen protokollieren. Im Vergleich zu andere Replikationslösungen werden SQL-Statements direkt an andere Knoten weitergegeben, weshalb problematische, nicht deterministische Operationen nur sehr aufwändig und nicht konsistent repliziert werden können (Eisentraut, et al., 2009). Der Nachteil der von Slony-I gewählten Lösung liegt jedoch auf der Verdoppelung der Seite 29

30 Anbieter von Lösungen Abbildung 13 Slony-I Architektur (Marcotte, 2005) Schreiblast am orgin und teilweise an den subscribern. Dies muss bereits beim Design des Slony- I Clusters berücksichtigt werden (Eisentraut, et al., 2009). Folgende Abbildung zeigt die Architektur von Slony-I: Der slon Prozess wiederum besteht aus mehren Threads. Der Synchronisation Thread überprüft in regelmäßigen Intervallen, ob eine Replikation durchzuführen ist und generiert für diesen Fall ein SYNC Event (Marcotte, 2005). Der local listen thread übernimmt Konfigurationsänderungen in die aktuelle Clusterkonfiguration des slon Prozesses. Der cleanup thread,, wie der Name impliziert, führt Wartungsarbeiten im slon Prozess durch, wie beispielsweise das Entfernen von temporären Tabellen. Der remote listen thread erhält Events vom orgin und schreibt diese in die interne Warteschlange des remote worker thread. Der remote worker thread führt die eigentliche Replikation durch (Browne). Ab der Version 1.2 von Slony-I ist ein dateibasiertes Logshipping enthalten. In diesem Betriebsmodus werden die replizierten Daten in Form von SQL Statements in eine Datei geschrieben (Eisentraut, et al., 2009). Seite 30

31 Anbieter von Lösungen Zusammenfassend ergeben sie vielfältige Einsatzmöglichkeiten für Slony-I, wobei hier insbesondere auf die Nutzung als Migrationstool hingewiesen wird. Da die Replikation vom Quell- auf das Zielsystem während dem laufenden Betrieb durchgeführt werden kann, eignet sich das Werkzeug für Szenarien, in der eine Echtzeitmigration erforderlich ist Konfiguration Für die Administration des Slony-I Replikationscluster kommt der Kommandoprozessor slonik zum Einsatz, der eine eigene Kommandosprache besitzt, die in Form von Skripten vom Kommandoprozessor ausgeführt wird (Browne). Jedes slonik Skript beginnt mit einer Präambel, in der die teilnehmenden Knoten und der Name des Clusters definiert sind. Das Kommando CLUSTER NAME legt den Namen des Clusters fest und entspricht dem Namensraum, indem alle erzeugen Slony-I Datenbankobjekte verwaltet werden. Der NODE ADMIN CONNINFO Befehl hinterlegt für jeden Knoten die Datenbankverbindungsinformationen, damit der entsprechende slon Prozess eine Verbindung zu diesem aufbauen kann. CLUSTER NAME = 'video'; NODE 1 ADMIN CONNINFO = 'dbname=videostore;host=master' NODE 2 ADMIN CONNINFO = 'dbname=videostore;host=slave1' NODE 3 ADMIN CONNINFO = 'dbname=videostore;host=slave2' Listing 6 Slony-I Präambel Im nächsten Schritt wird der Cluster durch den Befehl INIT CLUSTER initialisiert. Dabei werden alle für den Betrieb von Slony-I erforderlichen Datenbankobjekte auf allen, in der Präambel referenzierten Knoten, innerhalb des Namensraumes ( video ) angelegt. INIT CLUSTER (id = 1, comment = 'Video Cluster'); Listing 7 Initialisierung des Clusters Mit dem Befehl CREATE SET wird ein neues Set erzeugt (Browne). Es ist die kleinste Einheit einer Slony-Replikationslösung und enthält alle zu replizierenden Tabellen und Sequenzen. Beim erzeugen des Sets werden Tabellen und Sequenzen hinzugefügt, ein nachträgliches hinzufügen ist nicht mehr möglich (Eisentraut, et al., 2009). Der Befehl SET ADD TABLE fügt eine Tabelle einem SET hinzu, wobei der Parameter set id angibt, welchem SET sie hinzugefügt werden soll (Browne). Der orgin muss beim Hinzufügen der Tabelle nochmal gesetzt werden. Der fully qualified name gibt den schemaspezifischen Namen der Tabelle an. Es müssen folgende Bedingungen eingehalten werden: (Eisentraut, et al., 2009) Die Tabelle muss entweder einen Primärschlüssel oder einen eindeutigen Index definieren. Bei letzteren muss der Index über den optionalen Parameter key spezifiziert werden. Seite 31

32 Anbieter von Lösungen Wenn kein eindeutiger Schlüssel vorhanden ist, kann das Kommando TABLE ADD KEY verwendet werden. Davon ist jedoch abzuraten, da in neueren Slony-I Versionen dieses Kommando nicht mehr unterstützt wird. Das Hinzufügen von Sequenzen erfolgt analog zu Tabellen: SET ADD TABLE (set id = 1, origin = 1, id = 2, fully qualified name = 'public.kunde'); SET ADD TABLE (set id = 1, origin = 1, id = 3, fully qualified name = 'public.bestellung'); SET ADD SEQUENCE (set id = 1, origin = 1, id = 1, fully qualified name = 'public.sequence_benutzerid', comment = 'BenutzerID Sequenz'); Listing 8 Tabellen und Sequenzen dem Set hinzufügen Das Kommando STORE NODE initialisiert einen neuen Knoten und fügt diesen der Clusterkonfiguration hinzu (Browne). Dabei werden in der Knotendatenbank alle erforderlichen Datenbankobjekte erzeugt. STORE NODE ist nicht mit dem Befehl INIT CLUSTER zu verwechseln. Während INIT CLUSTER nur einmal ausgeführt werden kann und den orgin eines Clusters initialisiert, kann STORE NODE mehrmals ausgeführt werden, um beispielsweise einen neuen Knoten dem bestehenden Cluster hinzuzufügen (Eisentraut, et al., 2009). Die Kommunikation zwischen Datenbanken erfolgt über definierbare Pfade. Mit dem Kommando STORE PATH können diese Pfade festgelegt werden: (Browne) server definiert den Zielknoten. client ist jener Knoten, welcher die Kommunikation zum Server initiiert. conninfo enthält die Verbindungsinformation zum Zielknoten. connretry gibt die Anzahl der Verbindungsversuche an, falls der Zielknoten nicht erreichbar ist. STORE NODE (id = 2, comment = 'Slave 1'); STORE NODE (id = 3, comment = 'Slave 2'); STORE PATH(server = 1, client = 2, conninfo='dbname=videostore;host=slave1'); STORE PATH(server = 1, client = 3, conninfo='dbname=videostore;host=slave2'); Listing 9 Speichern von Knoten und Pfaden Seite 32

33 Anbieter von Lösungen Die Replikation wird durch Subscriptions durchgeführt. Dabei abonniert ein Slave Knoten durch das SUBSCRIBE SET Kommando ein Set. Davor müssen am jeweiligen Knoten die Definitionen von den Tabellen und Sequenzen angelegt werden. Wichtig ist, dass die Tabellendefinitionen und Sequenzen exakt mit den Definitionen am orgin übereinstimmen. Dabei müssen folgende Parameter angegeben werden: (Eisentraut, et al., 2009) Id verweist auf das zu replizierende SET Provider ist üblicherweise der orgin des Sets. Eine Replikation von einem anderen Knoten ist auch möglich, dadurch lassen sich kaskadierende Cluster realisieren Receiver definiert die ID des neuen Subscriber Die Ausführung von SUBSCRIBE SET kann Zeit in Anspruch nehmen, weil alle Daten innerhalb des angegebenen SETs vom orgin kopiert werden (Eisentraut, et al., 2009). Wenn mehre SUBSCRIBE SET Kommandos in einem Skript kombiniert werden, dann muss jeder Befehl durch ein WAIT FOR EVENT Kommando abgeschlossen werden (Browne). Ansonsten gibt es keine Garantie für die korrekte Abarbeitung der Ereignisse. SUBSCRIBE SET (id = 1, provider = 1 receiver = 2); WAIT FOR EVENT (origin = 1; confirmed = 1) Listing 10 Registrierung eines Subscribers Im Betrieb kann es notwendig sein, zwei bestehende SETs zu einem Set zusammenzulegen. Dies ist insbesondere hilfereich, wenn ein bestehendes SET geändert werden soll. Dabei wird ein temporäres SET erzeugt und Tabellen und Sequenzen hinzugefügt. Danach wird das temporäre SET mit dem bestehenden SET zusammengeführt. Anschließend müssen die beteiligten Subscriber das neue SET abonnieren. SUBSCRIBE SET (ID = 999, PROVIDER = 1, RECEIVER = 2); SYNC (ID=1); WAIT FOR EVENT (ORIGIN = 1, CONFIRMED = 2, WAIT FOR=1); SUBSCRIBE SET (ID = 999, PROVIDER = 1, RECEIVER = 3); SYNC (ID=1); WAIT FOR EVENT (ORIGIN = 1, CONFIRMED = 3, WAIT FOR=1); MERGE SET ( ID = 1, ADD ID = 999, ORIGIN = 1 ); Listing 11 Zusammenführen von zwei SETs Mit dem WAIT FOR EVENT und dem SYNC Kommando wird die Datenübernahme auf allen Subscribern abgewartet. Mit dem MERGE SET Befehl wird das SET mit der ID 1 und das temporäre SET mit der ID 999 am orgin 1 zusammengeführt. Seite 33

34 Anbieter von Lösungen Auswahl der Slony-I Version Slony-I in der Version 2.0 ist die aktuelle und stabile Version. Die Version 2.0 bringt gegenüber der Version 1.2 einige wesentliche Neuerungen mit. Während die alten Versionen auf alten PostgreSQL Versionen einsetzbar waren, unterstützt die neue Version nur mehr PostgreSQL aber der Version 8.3. Die Versionen 1.0 und 1.1 von Slony-I sollten nicht mehr eingesetzt werden. 4.2 IBM CLIO Clio-Projekt ist ein gemeinsames Projekt zwischen dem IBM Almaden Research Center und der University of Toronto und wurde im Jahr 1999 gestartet (Haas, et al., 2007). Das Ziel von Clio ist die Vereinfachung von Informationsintegration durch die Bereitstellung von Werkzeugen, die bei der Automatisierung und Verwaltung ein schwieriges Problem herausfordern: Die Transformation von Daten zwischen verschiedenen Datenquellen (Fagin, et al., 2009). Die zwei wesentlichen Funktionen von Clio sind data integration (automatische Generierung von Ansichten, um Anfragen des Quellschemas in jene des Zielschemas zu übersetzen) (Lenzerini, 2002) und data exchange (möglichst verlustfreie Transformation der Daten vom Quell- in das Zielschema) (Fagin, et al., 2005). Clio stellt an die Erzeugung und an die Beziehungen zwischen den Schemata keine besonderen Anforderungen, das heißt, jedes Schema kann unabhängig von anderen, Daten beinhalten sowie eigene Integritätsbedingungen definieren (Fagin, et al., 2009). Deshalb ist die Sprache für die Definition von Mappings allgemeiner als bei traditionellen Schemaintegrationsansätzen (Batini, et al., 1986). Weiteres besteht die Möglichkeit, Mappings zwischen relationalen und geschachtelten Schemata (zum Beispiel: XML Schema) zu erstellen. Konkrete Anwendungsbereiche sind data warehousing und data federation Lösungen, welche Daten in unterschiedliche Darstellungsformen transformieren (Fagin, et al., 2009). Auch die weite Verbreitung von XML als allgemeiner Standard für den Datenaustausch ist ein Motivationsfaktor für die Entwicklung solcher Algorithmen. Clio unterstützt die Erstellung von Mappings in unterschiedlichen Detailierungsgraden (Fagin, et al., 2009). Es kann je nach Anwendungsbereich ein Mapping zwischen individuellen Komponenten (zum Beispiel zwischen bestimmten Attributen oder Elemente für die Übersetzung von Euro in Dollar) oder für weitere Bereiche (zum Beispiel Konvertierung der Daten in das Electronic Data Interchange For Administration, Commerce and Transport (EDIFACT) Format) erstellt werden Architektur Den logischen Aufbau von Clio zeigt Abbildung 14. Es besteht aus der Schema-, Mapping- und Correspondence Engine, die gemeinsam ein Datenbankmanagementsystem für die Speicherung von Schemainformationen verwenden. Die Benutzerschnittstelle besteht aus einem Schemaund Dataviewer. Seite 34

35 Anbieter von Lösungen User Schema View GUI Data View Schema Engine Correspondence Engine Integration Knowledge Base Mapping Engine Database Engine Abbildung 14 Clio Architektur (Miller, et al., 2001) 1. Schema Engine Üblicherweise werden zu Beginn ein oder mehrere Schemata von unterschiedlichen Datenquellen in das System geladen. Falls es erforderlich ist, werden diese mit zusätzlichen Constraint Informationen angereichert. Am Ende werden die Schemata vom Benutzer verifiziert, um die Richtigkeit der generierten Informationen zu bestätigen. Um diesen Prozess zu unterstützten, bietet Clio einen Schema- und Dataview Modus an. Während ersteres der Schemata grafisch darstellt, werden bei Zweiteren die Schemata mit Daten gefüllt, damit der Benutzer die Zusammenhänge zwischen den Schemata besser verstehen kann. Folgende Abbildung zeigt den Schema Viewer: (Miller, et al., 2001) Seite 35

36 Anbieter von Lösungen Abbildung 15 Beispiel für die Darstellung eines Schemas in Clio (Haas, et al.) 2. Correspondence Engine Dieser Teil der Architektur ist verantwortlich für die Generierung und Verwaltung einer Menge von möglichen Korrespondenzen zwischen den Schemata (Miller, et al., 2001). Clio bietet für die Bearbeitung von Korrespondenzen zwei unterschiedliche Modi an. Im Schema View Modus werden jene Schemaelemente selektiert, die Teil der Korrespondenz sein sollen. Die Darstellung der Korrespondenzen erfolgt durch Pfeile (siehe Abbildung 15). Der Data View Modus dient der Überprüfung der vom Benutzer eingegebenen Korrespondenzen. 3. Mapping Engine Die Mapping Engine unterstützt die Erzeugung und Wartung von Mappings zwischen zwei Schemata. Ein Mapping besteht aus Schemainformationen und Korrespondenzen, sodass die Engine sowohl auf die Schema- und der Correspondence Engine zurückgereift (Miller, et al., 2001). Der Prozess der Erzeugung von Mappings ist gekennzeichnet durch häufige Iterationen und starke Interaktivität. Unterstützt wird dieser Prozess wiederum durch die grafische Benutzerschnittstelle (siehe Abbildung 15). In data exchange Szenarien kann Clio schemakonformen Code generieren, aufgrund dessen Zielschemata erstellt werden, welche dem Quellschema entsprechen. Beim Einsatz von Clio als data integration Werkzeug werden abhängig vom Quellschema entweder SQL-, XQuery- oder XSLT- Anfragen generiert. Folgende Abbildung zeigt die Implementierung in Clio: Seite 36

37 Anbieter von Lösungen Abbildung 16 Generierung von Anfragen in Clio (Haas, et al.) Beispiel Bei diesem Beispiel wird an das Kapitel 3.1 angeknüpft und die Erzeugung von proprietärer Regeln sowie deren Übersetzung in die entsprechende Abfragesprache behandelt. Dabei werden aus den Mappings SQL- und XQuery Anfragen generiert. Abbildung 17 Erzeugung proprietärer Regeln in Clio (Lehner, 2007) Seite 37

38 Anbieter von Lösungen Im diesem Beispiel wird eine Anfrage auf Basis der Relation spendendb.spenden für das Element einnahmen in haushaltdb erzeugt. Für den Wert buchungid existiert keine Korrespondenz, sodass der Wert NULL gesetzt wird. Bei isolierter Betrachtung des einnahmen Elementes ist die Implementierung einer Skolemfunktion nicht erforderlich. FOR x IN spenden LET s = x.spende.spendeid, p = x.spende.projekt RETURN <einnahme = <spendeid = s, proj = p, buchungid = NULL> > IN einnahmen Listing 12 Übersetzung in eine logische Abfragesprache in Clio I Folgendes Beispiel zeigt die Verwendung einer Skolemfunktion. Damit die Integritätsbedingung in einnahme in haushaltdb erfüllt ist, muss buchungid ein eindeutiger Wert zugewiesen werden. Anderenfalls ist die Assoziation zwischen den Elementen einnahmen und buchungen nicht abbildbar. Abbildung 18 Skolemfunktion für buchungid (Lehner, 2007) FOR x IN spenden LET s = x.spende.spendeid, p = x.spende.projekt b = x.spende.betrag RETURN <einnahme = <spendeid = s, proj = p, buchungid = Sk(s, p, b)> > IN einnahmen <buchung = <buchungid = Sk(s, p, b), datum = NULL, menge = b> > IN buchungen Listing 13 Übersetzung in eine logische Abfragesprache in Clio II Seite 38

39 Anbieter von Lösungen Im nächsten Schritt erfolgt die Übersetzung in die datenquellenspezifische Abfragesprache. Die logische Abfrage in Listing 13 wird wie folgt übersetzt: CREATE VIEW einnahme AS SELECT s.spendeid AS spendeid, s.projekt AS proj, Sk1(s.betrag, s.spendeid, s.projekt) AS buchungid FROM spendendb.spende s CREATE VIEW buchung AS SELECT x.betrag AS menge Sk1(s.betrag, s.spendeid, s.projekt) AS buchungid FROM spendendb.spende s Listing 14 Übersetzung nach SQL LET $doc0 := document("input XML") RETURN <haushaltdb> { distinct-values ( FOR $x0 IN $doc0/spendendb/spende RETURN <einnahme> <spendeid> { $x0/spendeid/text() } </spendeid> <proj> { $x0/projekt/text() } </proj> <buchungid> { "Sk1($x0/betrag/text(), $x0/spendeid/text(), $x0/projekt/text())" } </buchungid> </einnahme> ) }{ distinct-values ( FOR $x0 IN $doc0/spendendb/spende RETURN <buchung> <buchungid> { "Sk1($x0/betrag/text(), $x0/spendeid/text(), $x0/projekt/text())" } </buchungid> <menge> { $x0/betrag/text() } </menge> </buchung> ) } Listing 15 Übersetzung nach XQuery Seite 39

40 Referenzimplementierung 5. Referenzimplementierung Das Ziel der Referenzimplementierung ist die Bereitstellung eines Frameworks für die Migration von Schemata und Daten zwischen beliebigen Datenbanken. Die Referenzimplementierung unterstützt die Migration von PostgreSQL auf MySQL Datenbanken. Anforderungen: Performante Migration von komplexen Schemata und großen Datenmengen zwischen Datenbanken. Keine beziehungsweise minimale Beeinflussung des Produktivsystems während der Migration (Echtzeitmigration). Eine Änderung des Datenbestandes der Quelldatenbank während der Migration muss zulässig sein. Nach Abschluss der Synchronisation sind die Änderungen mit der Zieldatenbank abzugleichen. Bereitstellung von Schnittstellen für die Unterstützung weiterer Datenbankhersteller. Benutzerschnittstelle in der Form eines Kommandozeilenwerkzeuges. Geplante Erweiterungen: Unterstützung weiterer Datenbankhersteller. Unterstützung von geschachtelten Schemata (zum Beispiel: XML Schema). Migration von Datenbankobjekten, die nicht Tabellen sind. Beispielsweise Ansichten oder Funktionen. Implementierung einer grafischen Benutzerschnittstelle. Die Implementierung des Frameworks erfolgte in Java. Dabei wurde weitgehend auf bestehende Open Source Projekte zurückgegriffen. Insbesondere ist ddlutils hervorzuheben, ein Open Source Projekt der Apache Software Foundation (siehe Kapitel 5.3), auf dessen Funktionalität das vorliegende Framework aufsetzt. Obwohl die Referenzimplementierung lediglich zwei Datenbankmanagementsysteme unterstützt, lag die größte Herausforderung bei der Kapselung von datenbankspezifischen Eigenschaften. Die Unterstützung von MySql Datenbanken gestaltete sich aufgrund des eingeschränkten Funktionsumfanges der Plattform als schwierig. Beispielsweise fehlt die Unterstützung für Trigger. Daher konnte die Anforderung, dass sich der Datenbestand der Quelldatenbank während der Migration ändern darf, für MySql Datenbanken nicht umgesetzt werden, da für die Protokollierung von Datenänderung in Log-Tabellen Trigger erforderlich sind. Seite 40

41 Referenzimplementierung 5.1 Projekt Das Projekt gliederte sich in zwei Hauptphasen. In der ersten Phase stand die Evaluierung bereits bestehender Migrationswerkzeugen im Vordergrund. Es wurden neben Open Source Lösungen auch kommerzielle Produkt analysiert, wobei der Schwerpunkt eindeutig bei Open Source lag. Mit dem Wissen aus der Evaluierung startete die zweite Phase, die Entwicklung eines eigenen Migrationsframeworks, wobei der Schwerpunkt bei PostgreSQL Datenbanken lag. Als Entwicklungsumgebung wurde Eclipse, als Programmiersprache Java und für die Verwaltung des Quellcodes, Subversion eingesetzt. Das Ziel war kein fertiges Migrationswerkzeug, sondern ein Framework zu schaffen, um zukünftig mit verhältnismäßig geringem Aufwand Erweiterungen zu implementieren, wie beispielsweise die Unterstützung von weiteren Datenbankherstellern oder SQL Dialekten. Der Zeitplan für das gesamte Projekt betrug drei Monate und konnte auch eingehalten werden. Die Projektmanagementaktivitäten waren sehr gering, da alle Aufgaben in einer Person vereint waren. Folgende Abbildung zeigt den Balkenplan mit der Gliederung der Arbeitspakete: Abbildung 19 Balkenplan Seite 41

42 Referenzimplementierung 5.2 Design Die Hauptziele beim Design des Frameworks war einerseits die Definition einer Schnittstelle zur Kapselung von datenbankspezifischen Eigenschaften, andererseits die einfache Integration von unterschiedlichen Datenbankmanagementsystemen. Die Abbildung 20 zeigt vereinfacht dargestellt die Architektur des Migrationsframeworks. Die Klasse MigrationConnector bildet den Einstiegspunkt und besitzt zwei öffentliche Methoden für die Migration von Schemata und Daten, welche wiederum auf die Batch- und Audit Komponenten zugreifen. Ersteres ermöglicht eine performante Übertragung der Daten von der Quell- auf die Zieldatenbank. Letzteres protokolliert Änderungen an der Quelldatenbank während der Migration und synchronisiert diese Änderungen anschließend mit der Zieldatenbank. In den folgenden Kapiteln werden beide Komponenten ausführlich behandelt. Ausprägungen der Schnittstelle TranslationProfile kapseln datenbankspezifische Funktionalität, sowie beispielsweise die Erzeugung von SQL Statements für ein konkretes Datenbankmanagementsystem (DBMS). Für die Unterstützung weiterer DBMS muss lediglich eine Implementierung dieser Schnittstelle zu Verfügung gestellt werden. Aufgrund des gemeinsamen SQL Standards sind bestimmte Operationen standardisiert und viele Datenbankhersteller unterstützen dieselbe Syntax. Die abstrakte Basisklasse AbstractTranslationProfile stellt eine Standardimplementierung zu Verfügung, die sich an den SQL Standard anlehnt. Dadurch wird die Integration weiterer Datenbankhersteller sehr vereinfacht. Im Hinblick auf zukünftige Änderungen und Erweiterungen werden Instanzen datenbankspezifischer Implementierungen an einer zentralen Stelle durch die Klasse MigrationFacade erzeugt. Seite 42

43 Referenzimplementierung Abbildung 20 Architektur des Migrationsframeworks Seite 43

44 Referenzimplementierung 5.3 Implementierung Die Implementierung erfolgte in der Programmiersprache Java und so konnte auf ein mächtiges Framework zurückgegriffen werden. Die Plattform ist sehr populär und hat eine lebendige Open Source Gemeinde. Im Sinne der Wiederverwendbarkeit und Wartbarkeit der Implementierung wurden für bestimmte Zwecke Open Source Bibliotheken eingesetzt. ddlutils ist ein Framework zur Erzeugung und Verarbeitung von Database Definition Language (DDL) Dateien. Die Dateien weisen ein XML Format auf und dienen zur datenbankunabhängigen Darstellung von Schemainformationen. So werden beispielsweise JDBC statt proprietärer Datentypen verwendet (Apache, 2007). Die Bibliothek wurde folgendermaßen eingesetzt: 1. Abstrahierung des Schemas der Quelldatenbank durch die Database Definition Language. 2. Nachdem die Quelldatenbank in das DDL Format transformiert wurde, können die für die Zieldatenbank spezifischen SQL Kommandos erzeugt und ausgeführt werden. Folgende Abbildung zeigt ein Schema im datenbankunabhängigen DDL Format: <?xml version="1.0"?> <database name="testdb"> <table name="author"> <column name="author_id" type="integer" primarykey="true" required="true"/> <column name="name" type="varchar" size="50" required="true"/> </table> <table name="book"> <column name="book_id" type="integer" required="true" primarykey="true" autoincrement="true"/> <column name="isbn" type="varchar" size="15" required="true"/> <column name="author_id" type="integer" required="true"/> <column name="title" type="varchar" size="255" defaultvalue="n/a" required="true"/> Seite 44

45 Referenzimplementierung <foreign-key foreigntable="author"> <reference local="author_id" foreign="author_id"/> </foreign-key> <index name="book_isbn"> <index-column name="isbn"/> </index> </table> </database> Listing 16 Beispiel einer DDL Datei (Apache, 2007) Die Architektur von ddlutils entspricht dem logischen Aufbau einer Datenbank. Dabei erfolgt eine strikte Trennung zwischen datenbankunabhängigen (siehe Abbildung 21) und datenbankspezifischen (zum Beispiel die Erzeugung von SQL Kommandos anhand einer DDL Datei) Komponenten. Abbildung 21 Architektur von DdlUtils (Apache, 2007) Durch den Einsatz von ddlutils ergaben sich mehrere Vorteile. Es musste kein eigenes datenbankunabhängiges Format definiert werden, welches ein relationales Datenbankschema abbildet. Weiteres stellt die Bibliothek eine Java Schnittstelle für die Verarbeitung von DDL Dateien zur Verfügung. Seite 45

46 Referenzimplementierung Migration des Schemas Bei der Migration von Schemata wurde auf die Funktionalität von ddlutils zurückgegriffen. Zunächst werden alle Schemainformationen von der Quelldatenbank ausgelesen (sourceplatform.readmodelformdatabase) und eine Instanz der Klasse Database erzeugt und initialisiert. Danach wird das Schema durch den Methodenaufruf targetplatform.createtables auf der Zieldatenbank erstellt. Dabei werden im Hintergrund zieldatenbankspezifische SQL Kommandos anhand der Informationen in der DDL Datei erzeugt und auf der Zieldatenbank ausgeführt. Folgende Abbildung zeigt die Migration einer Datenbank: public void migratestructure(platform sourceplatform, Platform targetplatform, String catalog) { Database sourcedatabase = null; // Read source schema sourcedatabase = sourceplatform.readmodelfromdatabase(catalogname); // Prepare database for migration (e.g. naming conventions) targetdb.preparedatabase(sourcedatabase); } // Create schema in the target database targetplatform.createtables(sourcedatabase, false, true); Listing 17 Migration des Schemas Es werden von ddlutils eine Vielzahl von Datenbankmanagementsystemen unterstützt (Apache, 2007): Axion DB2 Derby/Cloudscape Firebird HSQLDB Interbase MaxDB/SapDB MyKoi MySQL Oracle PostgreSQL SQL Server Sybase Die Funktionalität von ddlutils im Hinblick auf die Migration von Schemata erfüllte die Anforderungen der Referenzimplementierung zur Gänze. Seite 46

47 Referenzimplementierung Migration der Daten Nachdem das Schema auf der Zieldatenbank erzeugt wurde, kann im nächsten Schritt die Migration der Daten erfolgen. Dabei werden Daten vom Quellschema selektiert und SQL Kommandos für die Übertragung in die Zieldatenbank generiert. Durch das Ausführen der SQL Befehle auf der Zieldatenbank werden die Daten eingefügt. Während der Migration wird die Überprüfung der Integritätsbedingungen auf den jeweiligen Tabellen deaktiviert, um Konflikte zu vermeiden. Die erste Version der Implementierung griff wiederum auf das ddlutils Framework zurück, was im Hinblick der Generierung der SQL Statements eine erhebliche Erleichterung darstellte. Umgesetzt wurde dies durch die Klasse DynaBean, deren Instanz einen Datensatz kapselt. Folgendes Listing zeigt die Migration der Daten mit ddlutils: public void migratedata(platform sourceplatform, Platform targetplatform, String catalog) { Database sourcedb = sourceplatform.readmodelfromdatabase(catalogname); Database targetdb = targetplatform.readmodelfromdatabase(catalogname); for (Table table : sourcedb.gettables()) { String sql = SELECT * FROM table.getname(); Iterator it = sourceplatform.query(sourcedb, sql); // Insert the data in the target database while (it.hasnext()) { DynaBean sourcerow = (DynaBean) it.next(); DynaBean targetrow = targetdb.createdynabeanfor(table.getname()); for (Column column : table.getcolumns()) { targetrow.set(column.getname(), sourcerow.get(column.getname())); } } } } targetplatform.insert(targetconfig.getconnection(), targetdb, targetrow); Listing 18 Migration der Daten mit ddlutils Im weiteren Verlauf der Entwicklung stellte sich heraus, dass dieser Ansatz nicht den Performance Anforderungen entsprach, sodass eine eigene Implementierung für die Migration der Daten entwickelt wurde. Der Kern der neuen Lösung ist die Batchverarbeitung. Dabei werden mehrere SQL Kommandos zu einem Batch zusammengefasst, die Gemeinsam auf der Zieldatenbank ausgeführt werden. Weiteres wurde auf die speicherintensive Klasse DynaBean verzichtet. Seite 47

48 Referenzimplementierung Im ersten Schritt wird eine BatchJob Instanz erzeugt und initialisiert. Beim Methodenaufruf batchjob.prepare(table) wird im Hintergrund ein SQL Kommando für die entsprechende Zielplattform generiert und in einem PreparedStatement Objekt gespeichert. Die Methode batchjob.write( ) fügt einen Datensatz dem Batch hinzu und führt diesen auf der Zieldatenbank aus, sobald das Zuvor gesetzte Limit (batchsize) erreicht wird. batchjob.close() hingegen stellt sicher, dass alle Datensätze auf die Zieldatenbank eingefügt werden. private void migratetable(table table) { String tablename = table.getname(); BatchJob batchjob = targetdb.createbatchjob(databaseoperation.insert); Iterator dataiterator = null; // Initialize Job batchjob.setbatchsize(targetconfig.getbatchsize()); batchjob.prepare(table); dataiterator = sourcedb.query(table); try { while (dataiterator.hasnext()) { batchjob.write((object[]) dataiterator.next()); } } catch (Exception e) { logger.warn("the table '" + tablename + "' is empty."); } batchjob.close(); } Listing 19 Die Daten einer Tabellen werden migriert Es ist möglich, dass sich Daten der Quelldatenbank während der Migration ändern. Um inkonsistente Datenbestände auf der Zieldatenbank zu vermeiden, beispielsweise die Verletzung von referenziellen Integritätsbedingungen, weil ein Fremdschlüssel ohne den referenzierten Primärschlüssel übertragen wird, werden Datenänderungen während der Migration auf der Quelldatenbanken durch Trigger protokolliert und die Änderungen nach Abschluss der Migration mit der Zieldatenbank synchronisiert. Das Erzeugen und Entfernen der temporären Trigger und Tabellen auf der Quelldatenbank erfolgt beim Start, beziehungsweise am Ende jeder Migration. Standardmäßig ist diese Funktion deaktiviert und kann durch entsprechende Konfiguration der Anwendung (siehe Kapitel 5.5) aktiviert werden. Diese Funktion wird bei der Migration von MySql Datenbanken auf eine andere Zielplattform nicht unterstützt. Seite 48

49 Referenzimplementierung Weiteres gibt es zwischen der Migration von MySql auf PostgreSQL folgende Einschränkungen: In MySql Datenbanken sind Namen der Indizes auf Tabellenebene eindeutig. In PostgreSQL müssen derartige Namen hingegen in der gesamten Datenbank eindeutig sein. Nun kommt es bei der Migration von MySql auf PostgreSQL zu Problemen, wenn mehrere Tabellen in einer MySql Datenbank denselben Namen für einen Index verwenden. Um dieses Problem zu lösen, wird bei der Migration von MySQL auf PostgreSQL den Indizes ein eindeutiger Name vergeben. Konkret setzt sich dieser aus den Tabellennamen und dem Indexnamen zusammen. In MySql ist :00:00 ein zulässiger Wert für ein DateTime Feld. Für den entsprechende Timestamp Datentyp in PostgreSQL ist dieser Wert jedoch unzulässig. Falls solche Werte existieren, können diese nicht von MySql auf PostgreSQL migriert werden. In diesem Fall wird von der Referenzimplementierung eine entsprechende Warnung ausgegeben, dass solche Datensätze nicht migriert werden können. Standardmäßig wird bei der Migration, beziehungsweise bei der Generierung der SQL Kommandos keine Quotierung durchgeführt. Nun kann es vorkommen, dass eine Tabellenbezeichnung im Quelldatenbanksystem im Zieldatenbanksystem ein Schlüsselwort darstellt (zum Beispiel: user, role). Damit dennoch eine Migration des Datenbankobjektes möglich ist, kann mittels dem Kommandozeilenparameter (-dim on siehe auch Kapitel 5.5) die Quotierung aktiviert werden. Seite 49

50 Referenzimplementierung 5.4 Testumgebung Bei jedem Testdurchgang wurden Schemata und Daten von PostgreSQL 8.3 nach MySQL 5.1 migriert. Die Testdatenbank besteht aus 3 Tabellen und umfasst in etwa 200 Megabyte an Daten. Grundsätzlich wird zwischen zwei Modi unterschieden. Im Standardmodus erfolgt der Zugriff auf die Quelldatenbank während der Migration ausschließlich lesend. Daher können Änderungen der Daten in der Quelldatenbank während der Migration nicht berücksichtigt werden. So kann sich die Zieldatenbank nach einer Migration in einem inkonsistenten Zustand befinden, wenn währenddessen sich der Datenbestand in der Quelldatenbank ändert. Deshalb eignet sich dieser Modus nur bedingt für eine Echtzeitmigration. Folgende Abbildung zeigt die Struktur der Quelldatenbank: Abbildung 22 Datenbankschema im Standardmodus Die Einschränkungen des Standardmodus werden mit dem Überwachungsmodus beseitigt. Dabei wird vor der Migration auf jede Tabelle in der Quelldatenbank ein Trigger angelegt, der Änderungen während der Migration in Logtabellen mit dem Suffix audit protokolliert. Anhand dieser Informationen kann nach Abschluss der Migration die Synchronisation mit der Zieldatenbank erfolgen. So werden Änderungen der Daten während der Migration in der Quelldatenbank erfasst und mit der Zieldatenbank nach Abschluss der Migration synchronisiert. Daher ist dieser Modus für eine Echtzeitmigration sehr gut geeignet. Abbildung 23 zeigt die Tabellenstruktur im Überwachungsmodus während der Migration. Nach Abschluss der Migration werden Trigger und Logtabellen von der Quelldatenbank wieder entfernt. Wie zuvor schon erwähnt, ist aufgrund technischer Einschränkungen von MySQL Datenbanken der Überwachungsmodus bei der Migration von MySQL auf PostgreSQL nicht verfügbar. Seite 50

51 Referenzimplementierung Abbildung 23 Datenbankschema im Überwachungsmodus Die Testläufe wurden auf einem Intel Core 2 Duo T7300 mit 2 GHZ mit 2 GB Hauptspeicher und Windows XP Service Pack 3 durchgeführt. Dabei befanden sich Quell- und Zieldatenbank auf demselben Rechner. Eine exakte Erfassung von Messwerten gestaltete sich als schwierig, da Datenbank- und Betriebssystemfunktionen aufgrund von Caching unterschiedliche Durchlaufzeiten aufweisen können. Um grobe Verzerrungen zu vermieden, wurden für jedes Szenario fünf Messungen durchgeführt und der Mittelwert errechnet. Table 3 zeigt drei verschiedene Szenarien. Im Standardmodus erfolgt die Migration ohne Logtabellen. Dies bedeutet, dass Datenänderungen in der Quelldatenbank während der Migration nicht berücksichtigt werden. Das Zweite und Dritte Szenario ist jeweils eine Ausprägung des Überwachungsmodus. Beim zweiten Szenario werden keine Datensätze, im dritten Szenario hingegen 1000 Datensätze während der Migration in die Quelldatenbank eingefügt. Daher kommt es beim dritten Szenario zu einem signifikanten Anstieg der Durchlaufzeit in der Kategorie Migration Daten (von 122 auf 257 Sekunden). Die Indikatoren Initialisierung und Migration Schema zeigen hingegen keine nennenswerten Abweichungen. Dagegen besteht ein positiver Zusammenhang zwischen der Kennzahl Synchronisation und der Menge der zu synchronisierenden Daten. Je mehr Daten während der Migration protokolliert werden, desto länger dauert dieser Vorgang. Seite 51

Oracle 10g und SQL Server 2005 ein Vergleich. Thomas Wächtler 39221

Oracle 10g und SQL Server 2005 ein Vergleich. Thomas Wächtler 39221 Oracle 10g und SQL Server 2005 ein Vergleich Thomas Wächtler 39221 Inhalt 1. Einführung 2. Architektur SQL Server 2005 1. SQLOS 2. Relational Engine 3. Protocol Layer 3. Services 1. Replication 2. Reporting

Mehr

PostgreSQL in großen Installationen

PostgreSQL in großen Installationen PostgreSQL in großen Installationen Cybertec Schönig & Schönig GmbH Hans-Jürgen Schönig Wieso PostgreSQL? - Die fortschrittlichste Open Source Database - Lizenzpolitik: wirkliche Freiheit - Stabilität,

Mehr

Abstrakt zum Vortrag im Oberseminar. Graphdatenbanken. Gero Kraus HTWK Leipzig 14. Juli 2015

Abstrakt zum Vortrag im Oberseminar. Graphdatenbanken. Gero Kraus HTWK Leipzig 14. Juli 2015 Abstrakt zum Vortrag im Oberseminar Graphdatenbanken Gero Kraus HTWK Leipzig 14. Juli 2015 1 Motivation Zur Darstellung komplexer Beziehungen bzw. Graphen sind sowohl relationale als auch NoSQL-Datenbanken

Mehr

Einsatz von Replikation. Florian Munz

Einsatz von Replikation. Florian Munz Einsatz von Replikation Florian Munz Agenda Wofür braucht man Replikation? Anwendungsszenarien Wie funktioniert Replikation? Konsistenzbegriff und Strategien Wie implementiert man Replikation? Lösungen

Mehr

PostgreSQL im praktischen Einsatz. Stefan Schumacher

PostgreSQL im praktischen Einsatz. Stefan Schumacher PostgreSQL im praktischen Einsatz 2. Brandenburger Linux Infotag 2005 Stefan Schumacher , PGP Key http:/// $Header: /home/daten/cvs/postgresql/folien.tex,v 1.11 2005/04/25

Mehr

Szenarien zu Hochverfügbarkeit und Skalierung mit und ohne Oracle RAC. Alexander Scholz

Szenarien zu Hochverfügbarkeit und Skalierung mit und ohne Oracle RAC. Alexander Scholz Hochverfügbar und Skalierung mit und ohne RAC Szenarien zu Hochverfügbarkeit und Skalierung mit und ohne Oracle RAC Alexander Scholz Copyright its-people Alexander Scholz 1 Einleitung Hochverfügbarkeit

Mehr

www.raber-maercker.de Herzlich willkommen!

www.raber-maercker.de Herzlich willkommen! www.raber-maercker.de Herzlich willkommen! Raber+Märcker GmbH Hochverfügbarkeit für Dynamics NAV-, Exchange- und SQL-Server Thomas Kuhn Microsoft Certified Solution Developer Teamleiter Server Applications

Mehr

TAV Übung 3. Übung 3: Verteilte Datenhaltung

TAV Übung 3. Übung 3: Verteilte Datenhaltung Übung 3: Verteilte Datenhaltung 1. Serialisierung Konstruieren Sie Historien aus drei Transaktionen T1, T2 und T3, die folgende Merkmale aufweisen: 1. Die serielle Reihenfolge ist T1 vor T2 vor T3. 2.

Mehr

Cassandra Query Language (CQL)

Cassandra Query Language (CQL) Cassandra Query Language (CQL) Seminar: NoSQL Wintersemester 2013/2014 Cassandra Zwischenpräsentation 1 Gliederung Basic facts Datentypen DDL/DML ähnlich zu SQL Besonderheiten Basic facts CQL kurz für

Mehr

Vergleich von Open-Source und kommerziellen Programmen zur Durchführung eines ETL-Prozesses

Vergleich von Open-Source und kommerziellen Programmen zur Durchführung eines ETL-Prozesses Vergleich von Open-Source und kommerziellen Programmen zur Durchführung eines ETL-Prozesses Exposé zur Diplomarbeit Humboldt-Universität zu Berlin Mathematisch-Naturwissenschaftliche Fakultät II Institut

Mehr

TimeSafe Leistungserfassung

TimeSafe Leistungserfassung Keep your time safe. TimeSafe Leistungserfassung Adressimport 1/8 Inhaltsverzeichnis Inhaltsverzeichnis... 2 1 Allgemeines... 3 1.1 Adressen in der TimeSafe Leistungserfassung... 3 1.2 Organisationen und/oder

Mehr

Präsentation zum Thema XML Datenaustausch und Integration

Präsentation zum Thema XML Datenaustausch und Integration Sebastian Land Präsentation zum Thema XML Datenaustausch und Integration oder Warum eigentlich XML? Gliederung der Präsentation 1. Erläuterung des Themas 2. Anwendungsbeispiel 3. Situation 1: Homogene

Mehr

Data Mining-Modelle und -Algorithmen

Data Mining-Modelle und -Algorithmen Data Mining-Modelle und -Algorithmen Data Mining-Modelle und -Algorithmen Data Mining ist ein Prozess, bei dem mehrere Komponenten i n- teragieren. Sie greifen auf Datenquellen, um diese zum Training,

Mehr

Verteiltes Backup. Einleitung Grundlegende Backup Techniken Backup in Netzwerken. Client/Server Peer-to-Peer

Verteiltes Backup. Einleitung Grundlegende Backup Techniken Backup in Netzwerken. Client/Server Peer-to-Peer Verteiltes Backup Einleitung Grundlegende Backup Techniken Backup in Netzwerken Client/Server Peer-to-Peer Einleitung Backup: Das teilweise oder gesamte Kopieren der in einem Computersystem vorhandenen

Mehr

The Unbreakable Database System

The Unbreakable Database System The Unbreakable Database System Real Application Cluster Unterföhring, 04.2005 M. Kühn 1 Comparisson HA - HA Ziele, DataGuard, HA Oracle, RAC RAC Features - Cache Fusion, TAF, Load Balancing RAC on Solaris

Mehr

Integration Services Übersicht

Integration Services Übersicht Integration Services Übersicht Integration Services Übersicht Integration Services stellt umfangreiche integrierte Tasks, Container, Transformationen und Datenadapter für die En t- wicklung von Geschäftsanwendungen

Mehr

Einführung in SQL Datenbanken bearbeiten

Einführung in SQL Datenbanken bearbeiten Einführung in SQL Datenbanken bearbeiten Jürgen Thomas Entstanden als Wiki-Buch Bibliografische Information Diese Publikation ist bei der Deutschen Nationalbibliothek registriert. Detaillierte Angaben

Mehr

sedex-client Varianten für den Betrieb in einer hoch verfügbaren

sedex-client Varianten für den Betrieb in einer hoch verfügbaren Département fédéral de l'intérieur DFI Office fédéral de la statistique OFS Division Registres Team sedex 29.07.2014, version 1.0 sedex-client Varianten für den Betrieb in einer hoch verfügbaren Umgebung

Mehr

Datensicherheit und Hochverfügbarkeit

Datensicherheit und Hochverfügbarkeit Datensicherheit und Hochverfügbarkeit 1. Instanzfehler Aussage: Instanzfehler werden durch Crash Recovery vom DBS automatisch behandelt. Recovery Zeiten? Ausfall von Speichersubsystem, Rechner,...? Ausfall

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

ORACLE Database Migration

ORACLE Database Migration ORACLE Database Migration Hürden und Best Practices in einer hochverfügbaren Umgebung GUUG FFG 2013 Andrea Held 27.2.2013 10:47:05 A. Held: Oracle DB Migration 1 Agenda Oracle Hochverfügbarkeit: Eine Auswahl

Mehr

Uni Duisburg-Essen Fachgebiet Informationssysteme Prof. Dr. N. Fuhr

Uni Duisburg-Essen Fachgebiet Informationssysteme Prof. Dr. N. Fuhr Raum: LF 230 Bearbeitung: 9.-11. Mai 2005 Datum Gruppe Vorbereitung Präsenz Aktuelle Informationen unter: http://www.is.informatik.uni-duisburg.de/courses/dbp_ss03/ Tabellen in IBM DB2 Tabellen Eine relationale

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

Red Hat Cluster Suite

Red Hat Cluster Suite Red Hat Cluster Suite Building high-available Applications Thomas Grazer Linuxtage 2008 Outline 1 Clusterarten 2 3 Architektur Konfiguration 4 Clusterarten Was ist eigentlich ein Cluster? Wozu braucht

Mehr

Datenbankstammtisch. Replikation in heterogenen Datenbankumgebungen am Beispiel des Sybase Replication Servers. 1. Februar 2006

Datenbankstammtisch. Replikation in heterogenen Datenbankumgebungen am Beispiel des Sybase Replication Servers. 1. Februar 2006 Datenbankstammtisch Replikation in heterogenen Datenbankumgebungen am Beispiel des Sybase Replication Servers 1. Februar 2006 Autoren: Andreas Reis, Sebastian Mehl Dipl.-Phys. Thomas Richter Gliederung

Mehr

Datenbanktechnologie für Data-Warehouse-Systeme

Datenbanktechnologie für Data-Warehouse-Systeme Wolfgang Lehner Datenbanktechnologie für Data-Warehouse-Systeme Konzepte und Methoden dpunkt.verlag 1 1.1 1.2 1.3 1.4 1. 5 2 2.1 2.2 2.3 Einleitung 1 Betriebswirtschaftlicher Ursprung des Data Warehousing...

Mehr

Grundlagen der PostgreSQL Administration

Grundlagen der PostgreSQL Administration Jens Wilke Vortrag bei der BELUG 16.03.2011 Der Vortrag behandelt die Installation und Konfiguration von PostgreSQL, dem fortschrittlichsten Open Source Datenbanksystem. Es wird auf die wichtigsten Konfigurationsparameter

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

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

DB2 SQL, der Systemkatalog & Aktive Datenbanken

DB2 SQL, der Systemkatalog & Aktive Datenbanken DB2 SQL, der Systemkatalog & Aktive Datenbanken Lehr- und Forschungseinheit Datenbanken und Informationssysteme 1 Ziele Auf DB2 Datenbanken zugreifen DB2 Datenbanken benutzen Abfragen ausführen Den Systemkatalog

Mehr

Replikation in Datenbanken

Replikation in Datenbanken Replikation in Datenbanken Vortrag: Datenbanken II Yves Adler Hochschule für Technik, Wirtschaft und Kultur Leipzig Fachbereich Informatik, Mathematik und Naturwissenschaften Y. Adler (HTWK Leipzig) Replikation

Mehr

Änderungen erkennen Schneller handeln Stefan Panek. Senior Consultant Christoph Jansen. Consultant 23.10.2008

Änderungen erkennen Schneller handeln Stefan Panek. Senior Consultant Christoph Jansen. Consultant 23.10.2008 Änderungen erkennen Schneller handeln Stefan Panek. Senior Consultant Christoph Jansen. Consultant 23.10.2008 Seit der Datenbankversion 9i bietet Oracle das Feature Change Data Capture an. Aber was genau

Mehr

SQL structured query language

SQL structured query language Umfangreiche Datenmengen werden üblicherweise in relationalen Datenbank-Systemen (RDBMS) gespeichert Logische Struktur der Datenbank wird mittels Entity/Realtionship-Diagrammen dargestellt structured query

Mehr

SQL Tutorial. SQL - Tutorial SS 06. Hubert Baumgartner. INSO - Industrial Software

SQL Tutorial. SQL - Tutorial SS 06. Hubert Baumgartner. INSO - Industrial Software SQL Tutorial SQL - Tutorial SS 06 Hubert Baumgartner INSO - Industrial Software Institut für Rechnergestützte Automation Fakultät für Informatik Technische Universität Wien Inhalt des Tutorials 1 2 3 4

Mehr

Vorlesung Datenbanksysteme Univ.-Prof. Dr. Günther Specht. Universität Innsbruck Institut für Informatik Datenbanken und Informationssysteme (DBIS)

Vorlesung Datenbanksysteme Univ.-Prof. Dr. Günther Specht. Universität Innsbruck Institut für Informatik Datenbanken und Informationssysteme (DBIS) Verteilte DB-Systeme Kapitel XIII Vorlesung Datenbanksysteme Univ.-Prof. Dr. Günther Specht Universität Innsbruck Institut für Informatik Datenbanken und Informationssysteme (DBIS) Vorlesungsinhalt 13.

Mehr

IBM Informix Tuning und Monitoring

IBM Informix Tuning und Monitoring Seminarunterlage Version: 11.01 Copyright Version 11.01 vom 25. Juli 2012 Dieses Dokument wird durch die veröffentlicht. Copyright. Alle Rechte vorbehalten. Alle Produkt- und Dienstleistungs-Bezeichnungen

Mehr

IDS Lizenzierung für IDS und HDR. Primärserver IDS Lizenz HDR Lizenz

IDS Lizenzierung für IDS und HDR. Primärserver IDS Lizenz HDR Lizenz IDS Lizenzierung für IDS und HDR Primärserver IDS Lizenz HDR Lizenz Workgroup V7.3x oder V9.x Required Not Available Primärserver Express V10.0 Workgroup V10.0 Enterprise V7.3x, V9.x or V10.0 IDS Lizenz

Mehr

RAID. Name: Artur Neumann

RAID. Name: Artur Neumann Name: Inhaltsverzeichnis 1 Was ist RAID 3 1.1 RAID-Level... 3 2 Wozu RAID 3 3 Wie werden RAID Gruppen verwaltet 3 3.1 Software RAID... 3 3.2 Hardware RAID... 4 4 Die Verschiedenen RAID-Level 4 4.1 RAID

Mehr

Motivation. Themenblock: Data Preprocessing. Einsatzgebiete für Data Mining I. Modell von Gianotti und Pedreschi

Motivation. Themenblock: Data Preprocessing. Einsatzgebiete für Data Mining I. Modell von Gianotti und Pedreschi Motivation Themenblock: Data Preprocessing We are drowning in information, but starving for knowledge! (John Naisbett) Was genau ist Datenanalyse? Praktikum: Data Warehousing und Data Mining Was ist Data

Mehr

MySQL Replikationstechnologien

MySQL Replikationstechnologien MySQL Replikationstechnologien Lenz Grimmer MySQL Community Relations Specialist $ whoami 1998 2002 2008 2010 Agenda Replikation: Definition und Klassifizierung Anwendungsgebiete

Mehr

Kapitel 7 Datenbank-Tuning

Kapitel 7 Datenbank-Tuning Kapitel 7 Datenbank-Tuning Flien zum Datenbankpraktikum Wintersemester 2012/13 LMU München 2008 Thmas Bernecker, Tbias Emrich 2010 Tbias Emrich, Erich Schubert unter Verwendung der Flien des Datenbankpraktikums

Mehr

Themenblock: Erstellung eines Cube

Themenblock: Erstellung eines Cube Themenblock: Erstellung eines Cube Praktikum: Data Warehousing und Data Mining Einführung relationale Datenbanken Problem Verwaltung großer Mengen von Daten Idee Speicherung der Daten in Form von Tabellen

Mehr

Effizientes Änderungsmanagement in Outsourcing- Projekten

Effizientes Änderungsmanagement in Outsourcing- Projekten Effizientes Änderungsmanagement in Outsourcing- Projekten Dr. Henning Sternkicker Rational Software IBM Deutschland GmbH Sittarder Straße 31 52078 Aachen henning.sternkicker@de.ibm.com Abstract: Es werden

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

Relationale Datenbanken Kursziele

Relationale Datenbanken Kursziele Relationale Datenbanken Kursziele DB Grundlagen Daten-Modellierung Relationales Modell und DB => Praxis: Mit SQL als Anfragesprache Mit MySQL als DB RDB 1-1 Kursinhalt (Tage) 1. DB Einleitung / Entity-Relationship

Mehr

Innovator 11 excellence. DDL importieren. Data-Definition-Language-Dateien in Datenbankschema importieren. HowTo. www.mid.de

Innovator 11 excellence. DDL importieren. Data-Definition-Language-Dateien in Datenbankschema importieren. HowTo. www.mid.de Innovator 11 excellence DDL importieren Data-Definition-Language-Dateien in Datenbankschema importieren HowTo www.mid.de Zweck In Innovator Data excellence können Sie mit dem DDL-Import Ihr physisches

Mehr

Message Oriented Middleware am Beispiel von XMLBlaster

Message Oriented Middleware am Beispiel von XMLBlaster Message Oriented Middleware am Beispiel von XMLBlaster Vortrag im Seminar XML und intelligente Systeme an der Universität Bielefeld WS 2005/2006 Vortragender: Frederic Siepmann fsiepman@techfak.uni bielefeld.de

Mehr

NoSQL mit Postgres 15. Juni 2015

NoSQL mit Postgres 15. Juni 2015 Tag der Datenbanken 15. Juni 2015 Dipl.-Wirt.-Inform. Agenda l Vorstellung l Marktübersicht l Warum PostgreSQL? l Warum NoSQL? l Beispielanwendung Seite: 2 Vorstellung Dipl.-Wirt.-Inform. [1990] Erste

Mehr

RAC auf Sun Cluster 3.0

RAC auf Sun Cluster 3.0 RAC auf Sun Cluster 3.0 Schlüsselworte RAC, OPS, Sun Cluster, Performance, Availability Zusammenfassung Oracle hat mit dem Real Application Cluster (RAC) aus einer Hochverfügbarkeitslösung eine Höchstverfügbarkeitslösung

Mehr

Dipl. Inf. Eric Winter. PostgreSQLals HugeData Storage Ein Erfahrungsbericht

Dipl. Inf. Eric Winter. PostgreSQLals HugeData Storage Ein Erfahrungsbericht Dipl. Inf. Eric Winter Entwicklungsleiter PTC GPS-Services GmbH PostgreSQLals HugeData Storage Ein Erfahrungsbericht Inhalt 1. Problembeschreibung 2. Partielle Indexierung 3. Partitionierung 1. Vererbung

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

56 Maßnahmen zur Sicherung der Verfügbarkeit in Oracle-Umgebungen. Client Client Client Client Client. Public Network. aktiv. Private Network.

56 Maßnahmen zur Sicherung der Verfügbarkeit in Oracle-Umgebungen. Client Client Client Client Client. Public Network. aktiv. Private Network. 56 Maßnahmen zur Sicherung der Verfügbarkeit in Oracle-Umgebungen aktiv inaktiv Node 1 ( Aktiv ) Node 2 ( Passiv ) Private Network aktiv inaktiv (exklusiver Zugriff) Abbildung 3.1: Schematische Darstellung

Mehr

Sichere Daten mit OSL Storage Cluster

Sichere Daten mit OSL Storage Cluster Sichere Daten mit OSL Storage Cluster Alternative Konzepte für die Datensicherung und Katastrophenvorsorge Dipl.-Ing. Torsten Pfundt Gliederung Voraussetzungen für die Konzepte und Lösungen restorefreies

Mehr

25.09.2014. Zeit bedeutet eine Abwägung von Skalierbarkeit und Konsistenz

25.09.2014. Zeit bedeutet eine Abwägung von Skalierbarkeit und Konsistenz 1 2 Dies ist ein Vortrag über Zeit in verteilten Anwendungen Wir betrachten die diskrete "Anwendungszeit" in der nebenläufige Aktivitäten auftreten Aktivitäten in einer hochgradig skalierbaren (verteilten)

Mehr

findet sich im Oplog dazu auch ein entsprechender Eintrag:

findet sich im Oplog dazu auch ein entsprechender Eintrag: 45 In MongoDB wird die Replikation 1 zur Sicherstellung der Ausfallsicherheit (das P aus dem CAP-Theorem) und zur Skalierung von Lesezugriffen eingesetzt. Dabei wird grob zwischen zwei Ansätzen unterschieden:

Mehr

Überblick über Oracle Technologie im Bereich Hochverfügbarkeit. Tage der Datenbanken FH Köln Campus Gummersbach 20. Juni 2013 Dierk Lenz

Überblick über Oracle Technologie im Bereich Hochverfügbarkeit. Tage der Datenbanken FH Köln Campus Gummersbach 20. Juni 2013 Dierk Lenz Überblick über Oracle Technologie im Bereich Hochverfügbarkeit Tage der Datenbanken FH Köln Campus Gummersbach 20. Juni 2013 Dierk Lenz Herrmann & Lenz Services GmbH Erfolgreich seit 1996 am Markt Firmensitz:

Mehr

3 Richtlinienbasierte Verwaltung und Multi-Server- Administration

3 Richtlinienbasierte Verwaltung und Multi-Server- Administration Richtlinienbasierte Verwaltung und Multi-Server-Administration 3 Richtlinienbasierte Verwaltung und Multi-Server- Administration SQL Server Management Studio bietet eine Reihe von Unterstützungsmöglichkeiten,

Mehr

Star-Schema-Modellierung mit ERwin - eine kritische Reflexion der Leistungspotentiale und Anwendungsmöglichkeiten

Star-Schema-Modellierung mit ERwin - eine kritische Reflexion der Leistungspotentiale und Anwendungsmöglichkeiten Star-Schema-Modellierung mit ERwin - eine kritische Reflexion der Leistungspotentiale und Anwendungsmöglichkeiten Michael Hahne T&I GmbH Workshop MSS-2000 Bochum, 24. März 2000 Folie 1 Worum es geht...

Mehr

Fachbereich Informatik Praktikum 1

Fachbereich Informatik Praktikum 1 Hochschule Darmstadt DATA WAREHOUSE SS2015 Fachbereich Informatik Praktikum 1 Prof. Dr. S. Karczewski Dipl. Inf. Dipl. Math. Y. Orkunoglu Datum: 14.April.2015 1. Kurzbeschreibung In diesem Praktikum geht

Mehr

Referenzielle Integrität SQL

Referenzielle Integrität SQL Referenzielle Integrität in SQL aus Referential Integrity Is Important For Databases von Michael Blaha (Modelsoft Consulting Corp) VII-45 Referenzielle Integrität Definition: Referenzielle Integrität bedeutet

Mehr

Musterlösung Übungsblatt 1 Netzprogrammierung WS 05/06

Musterlösung Übungsblatt 1 Netzprogrammierung WS 05/06 Musterlösung Übungsblatt 1 Netzprogrammierung WS 05/06 Block Verteilte Systeme und Middleware 1. Beschreiben Sie die Entwicklung verteilter Systeme von einer Zentralisierung bis zu Peer-to-Peer. Nicht

Mehr

OLAP und Data Warehouses

OLAP und Data Warehouses OLP und Data Warehouses Überblick Monitoring & dministration Externe Quellen Operative Datenbanken Extraktion Transformation Laden Metadaten- Repository Data Warehouse OLP-Server nalyse Query/Reporting

Mehr

Performanceoptimierung mit Exadata Verarbeitung extremer Datenmengen mit PL/SQL basierter Datenbewirtschaftung (Erfahrungsbericht)

Performanceoptimierung mit Exadata Verarbeitung extremer Datenmengen mit PL/SQL basierter Datenbewirtschaftung (Erfahrungsbericht) Performanceoptimierung mit Exadata Verarbeitung extremer Datenmengen mit PL/SQL basierter Datenbewirtschaftung (Erfahrungsbericht) Christian Haag, DATA MART Consulting Consulting Manager Oracle DWH Team

Mehr

Extended Abstract Obserseminar: Datenbanksysteme - Aktuelle Trends. Cloud-Datenbanken. Franz Anders 02.07.2015

Extended Abstract Obserseminar: Datenbanksysteme - Aktuelle Trends. Cloud-Datenbanken. Franz Anders 02.07.2015 Extended Abstract Obserseminar: Datenbanksysteme - Aktuelle Trends Cloud-Datenbanken Franz Anders 02.07.2015 Dies ist das erweiterte Abstract zum Vortrag Cloud-Datenbanken für das Oberseminar Datenbanksysteme

Mehr

Axel Haller, Symposium 25-26 März 2010 Engineering Workflow: Potential und Praxis bei der Integration von Verfahrenstechnik und Automation

Axel Haller, Symposium 25-26 März 2010 Engineering Workflow: Potential und Praxis bei der Integration von Verfahrenstechnik und Automation Axel Haller, Symposium 25-26 März 2010 Engineering Workflow: Potential und Praxis bei der Integration von Verfahrenstechnik und Automation March 25, 2010 Slide 1 Agenda Die Problematik Das Lösungsmittel

Mehr

Hochschule Karlsruhe Technik und Wirtschaft- 10.7.2013. Anhänge: Fakultät für Informatik und Wirtschaftsinformatik SS 2013 Prof. Schmidt.

Hochschule Karlsruhe Technik und Wirtschaft- 10.7.2013. Anhänge: Fakultät für Informatik und Wirtschaftsinformatik SS 2013 Prof. Schmidt. Fakultät für Informatik und Wirtschaftsinformatik SS 2013 Datenbanken und Informationssysteme II Szenario: Projektverwaltung. Es gibt Projekte, Projektleiter, Mitarbeiter und ihre Zuordnung zu Projekten.

Mehr

Die folgenden Features gelten für alle isquare Spider Versionen:

Die folgenden Features gelten für alle isquare Spider Versionen: isquare Spider Die folgenden s gelten für alle isquare Spider Versionen: webbasiertes Management (Administratoren) Monitoring Sichten aller gefundenen Beiträge eines Forums Statusüberprüfung Informationen

Mehr

MySQL Replikation. Erkan Yanar erkan.yanar@linsenraum.de linsenraum.de 19.11.2013. linsenraum.de

MySQL Replikation. Erkan Yanar erkan.yanar@linsenraum.de linsenraum.de 19.11.2013. linsenraum.de MySQL Replikation Erkan Yanar erkan.yanar@linsenraum.de linsenraum.de linsenraum.de 19.11.2013 Erkan Yanar erkan.yanar@linsenraum.de linsenraum.de (linsenraum.de) MySQL Replikation 19.11.2013 1 / 37 Who

Mehr

Orientation in Objects GmbH Weinheimer Str. 68 68309 Mannheim www.oio.de info@oio.de Version: 2014 Orientation 1.0 in Objects GmbH Der Sprecher Erik Bamberg (OIO) 2 1 s Aufgaben des Cachings Datenbank

Mehr

Installation MySQL Replikationsserver 5.6.12

Installation MySQL Replikationsserver 5.6.12 Ergänzen Konfigurationsdatei my.ini auf Master-Server:!!! softgate gmbh!!! Master und Slave binary logging format - mixed recommended binlog_format = ROW Enabling this option causes the master to write

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

Tipps & Tricks. Neues, Nützliches und Praktisches. Christian Dahmen con terra GmbH

Tipps & Tricks. Neues, Nützliches und Praktisches. Christian Dahmen con terra GmbH Tipps & Tricks Neues, Nützliches und Praktisches Christian Dahmen con terra GmbH 1 Qualitätssicherung von Geodaten Qualitätssicherung von Geodaten Mit FME lassen sich einfache und komplexe Prüfroutinen

Mehr

SmarTeam MS Outlook Integration Version 3.1 Beschreibung des Funktionsumfangs

SmarTeam MS Outlook Integration Version 3.1 Beschreibung des Funktionsumfangs SmarTeam MS Outlook Integration Version 3.1 Beschreibung des Funktionsumfangs Der Aufbau der MS Outlook Integration orientiert sich stark an den SmarTeam Integrationen zu den MS Office Produkten, wobei

Mehr

5.3 Datenreplikation. Replikation

5.3 Datenreplikation. Replikation 5.3 Datenreplikation Tresgros Tresgros T Tresgros Filiale Muttenz Filiale Allschwil Filiale Liestal Asynchrone Aktualisierung (Warehouse Update = replica maintenance) Redundante Datenhaltung (data replication)

Mehr

Transaktionen in der Praxis. Dr. Karsten Tolle

Transaktionen in der Praxis. Dr. Karsten Tolle Transaktionen in der Praxis Dr. Karsten Tolle Praxisbeispiel in Java Connection con = null; try { con = DriverManager.getConnection("jdbc:db2:sample"); } catch (Exception e) { e.printstacktrace(); } con.setautocommit(false);

Mehr

Session Storage im Zend Server Cluster Manager

Session Storage im Zend Server Cluster Manager Session Storage im Zend Server Cluster Manager Jan Burkl System Engineer, Zend Technologies Agenda Einführung in Zend Server und ZSCM Überblick über PHP Sessions Zend Session Clustering Session Hochverfügbarkeit

Mehr

Ermittlung von Assoziationsregeln aus großen Datenmengen. Zielsetzung

Ermittlung von Assoziationsregeln aus großen Datenmengen. Zielsetzung Ermittlung von Assoziationsregeln aus großen Datenmengen Zielsetzung Entscheidungsträger verwenden heutzutage immer häufiger moderne Technologien zur Lösung betriebswirtschaftlicher Problemstellungen.

Mehr

Mit Transbase Hypercube Data Warehouse Anwendungen effizient betreiben. Die Hypercube-Technologie

Mit Transbase Hypercube Data Warehouse Anwendungen effizient betreiben. Die Hypercube-Technologie Mit Transbase Hypercube Data Warehouse Anwendungen effizient betreiben Transbase Hypercube ist eine Transbase -Option, die die innovative Hypercube-Technologie für komplexe analytische Anwendungen (OLAP)

Mehr

Einführung in SQL. Sprachumfang: Indizes. Datensätzen. Zugriffsrechten

Einführung in SQL. Sprachumfang: Indizes. Datensätzen. Zugriffsrechten Einführung in SQL Die Sprache SQL (Structured Query Language) ist eine Programmiersprache für relationale Datenbanksysteme, die auf dem ANSI-SQL-Standard beruht. SQL wird heute von fast jedem Datenbanksystem

Mehr

Konzeption eines Master-Data-Management-Systems. Sven Schilling

Konzeption eines Master-Data-Management-Systems. Sven Schilling Konzeption eines Master-Data-Management-Systems Sven Schilling Gliederung Teil I Vorstellung des Unternehmens Thema der Diplomarbeit Teil II Master Data Management Seite 2 Teil I Das Unternehmen Vorstellung

Mehr

Inhalt. Ein Einführung in die Nutzung von SQL-Datenbanken am Beispiel Oracle. Daten und Tabellen - ein Beispiel. Daten und Tabellen - Normalisierung

Inhalt. Ein Einführung in die Nutzung von SQL-Datenbanken am Beispiel Oracle. Daten und Tabellen - ein Beispiel. Daten und Tabellen - Normalisierung Inhalt Ein Einführung in die Nutzung von SQL-Datenbanken am Beispiel Oracle Daten und Tabellen Normalisierung, Beziehungen, Datenmodell SQL - Structured Query Language Anlegen von Tabellen Datentypen (Spalten,

Mehr

3. Spezielle ER-Modelle und Tabellenableitung. Transformation von ER-Diagrammen in Relationen

3. Spezielle ER-Modelle und Tabellenableitung. Transformation von ER-Diagrammen in Relationen 3. Spezielle ER-Modelle und Tabellenableitung Spezialfälle von ER-Modellen Grundlage, was sind Relationen Transformation von ER-Diagrammen in Relationen 56 Lesebeispiel Access (Realisierungmodell!) 57

Mehr

Allgemeines. veröffentlicht unter http://www.profv.de/uni/ lizensiert unter. Creative Commons BY-SA 3.0. XQuery in MS SQL Server 2005

Allgemeines. veröffentlicht unter http://www.profv.de/uni/ lizensiert unter. Creative Commons BY-SA 3.0. XQuery in MS SQL Server 2005 Volker Grabsch 14. Januar 2008 Allgemeines veröffentlicht unter http://www.profv.de/uni/ lizensiert unter Creative Commons BY-SA 3.0 Quelle Dieser Vortrag basiert auf dem Paper XQuery Implementation in

Mehr

Oracle Big Data Technologien Ein Überblick

Oracle Big Data Technologien Ein Überblick Oracle Big Data Technologien Ein Überblick Ralf Lange Global ISV & OEM Sales NoSQL: Eine kurze Geschichte Internet-Boom: Erste Ansätze selbstgebauter "Datenbanken" Google stellt "MapReduce"

Mehr

Seminar Cloud Data Management WS09/10. Tabelle1 Tabelle2

Seminar Cloud Data Management WS09/10. Tabelle1 Tabelle2 Seminar Cloud Data Management WS09/10 Tabelle1 Tabelle2 1 Einführung DBMS in der Cloud Vergleich verschiedener DBMS Beispiele Microsoft Azure Amazon RDS Amazon EC2 Relational Databases AMIs Was gibt es

Mehr

A Generic Database Web Service for the Venice Lightweight Service Grid

A Generic Database Web Service for the Venice Lightweight Service Grid A Generic Database Web Service for the Venice Lightweight Service Grid Michael Koch Bachelorarbeit Michael Koch University of Kaiserslautern, Germany Integrated Communication Systems Lab Email: m_koch2@cs.uni-kl.de

Mehr

IT Storage Cluster Lösung

IT Storage Cluster Lösung @ EDV - Solution IT Storage Cluster Lösung Leistbar, Hochverfügbar, erprobtes System, Hersteller unabhängig @ EDV - Solution Kontakt Tel.: +43 (0)7612 / 62208-0 Fax: +43 (0)7612 / 62208-15 4810 Gmunden

Mehr

UI-Testing mit Microsoft Test Manager (MTM) Philip Gossweiler / 2013-04-18

UI-Testing mit Microsoft Test Manager (MTM) Philip Gossweiler / 2013-04-18 UI-Testing mit Microsoft Test Manager (MTM) Philip Gossweiler / 2013-04-18 Software Testing Automatisiert Manuell 100% 70% 1 Überwiegender Teil der Testing Tools fokusiert auf automatisiertes Testen Microsoft

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

Whitepaper Externe Speicherung von Binary Large Objects (BLOBs) mit SharePoint 2007 sowie SQL Server 2005 / 2008

Whitepaper Externe Speicherung von Binary Large Objects (BLOBs) mit SharePoint 2007 sowie SQL Server 2005 / 2008 Externe Speicherung von Binary Large Objects (BLOBs) mit SharePoint 2007 sowie SQL Andreas Glaser, 23. September 2008 Teufenerstrasse 19 CH 9001 St.Gallen t [+41] 71 228 67 77 f [+41] 71 228 67 88 info@namics.com

Mehr

OWB Referenzarchitektur, Releasemanagement und Deployment. Carsten Herbe metafinanz - Informationssysteme GmbH

OWB Referenzarchitektur, Releasemanagement und Deployment. Carsten Herbe metafinanz - Informationssysteme GmbH OWB Referenzarchitektur, Releasemanagement und Deployment Carsten Herbe metafinanz - Informationssysteme GmbH Wir fokussieren mit unseren Services die Herausforderungen des Marktes und verbinden Mensch

Mehr

Das Knowledge Grid. Eine Architektur für verteiltes Data Mining

Das Knowledge Grid. Eine Architektur für verteiltes Data Mining Das Knowledge Grid Eine Architektur für verteiltes Data Mining 1 Gliederung 1. Motivation 2. KDD und PDKD Systeme 3. Knowledge Grid Services 4. TeraGrid Projekt 5. Das Semantic Web 2 Motivation Rapide

Mehr

Persönlichkeiten bei bluehands

Persönlichkeiten bei bluehands Persönlichkeiten bei Technologien bei Skalierbare Anwendungen mit Windows Azure GmbH & co.mmunication KG am@.de; posts..de/am 1 2 3 4 5 6 7 8 9 Immer mehr Mehr Performance Mehr Menge Mehr Verfügbarkeit

Mehr

5 Schemadefinition in objektrelationalen Datenbanksystemen

5 Schemadefinition in objektrelationalen Datenbanksystemen 75 5 Schemadefinition in objektrelationalen Datenbanksystemen In diesem Kapitel wird die Definition objektrelationaler Schemata am Beispiel von DB2 konkretisiert. Zu diesem Zweck wird zunächst das DBMS

Mehr

Oracle Automatic Storage Management (ASM) Best Practices

Oracle Automatic Storage Management (ASM) Best Practices Oracle Automatic Storage Management (ASM) Best Practices Markus Michalewicz BU Database Technologies ORACLE Deutschland GmbH 2 Page 1 www.decus.de 1 Agenda ASM Funktionalität und Architektur Storage Management

Mehr

Unterabfragen (Subqueries)

Unterabfragen (Subqueries) Unterabfragen (Subqueries) Die kürzeste Formulierung ist folgende: SELECT Felderliste FROM Tabelle1 WHERE Tabelle1.Feldname Operator (SELECT Feldname FROM Tabelle2 WHERE Bedingung); wobei Tabelle1 und

Mehr

Index- und Zugriffsstrukturen für. Holger Brämer, 05IND-P

Index- und Zugriffsstrukturen für. Holger Brämer, 05IND-P Index- und Zugriffsstrukturen für Data Warehousing Holger Brämer, 05IND-P Index- und Zugriffstrukturen für Data Warehousing Materialisierte Sichten Bitmap-Indexe Verbundindexe Materialisierte Sichten gehören

Mehr

Oracle Hot Standby. XE, SEOne, SE. Maximum Performance Mode. WIN, Linux, Unix Einfache Lösung. bis zu 10 Standby DB

Oracle Hot Standby. XE, SEOne, SE. Maximum Performance Mode. WIN, Linux, Unix Einfache Lösung. bis zu 10 Standby DB Network Failure Management Graceful Switchover XE, SEOne, SE WIN, Linux, Unix Einfache Lösung Oracle Hot Standby Maximum Performance Mode 100% Java Kompression bis zu 10 Standby DB Die Oracle Experten

Mehr

Solaris Cluster. Dipl. Inform. Torsten Kasch 8. Januar 2008

Solaris Cluster. Dipl. Inform. Torsten Kasch <tk@cebitec.uni Bielefeld.DE> 8. Januar 2008 Dipl. Inform. Torsten Kasch 8. Januar 2008 Agenda Übersicht Cluster Hardware Cluster Software Konzepte: Data Services, Resources, Quorum Solaris Cluster am CeBiTec: HA Datenbank

Mehr

MySQL Replikation Neue Features in 5.5 und 5.6

MySQL Replikation Neue Features in 5.5 und 5.6 MySQL Replikation Neue Features in 5.5 und 5.6 DOAG SIG-MySQL 2013, München Oli Sennhauser Senior MySQL Consultant, FromDual GmbH oli.sennhauser@fromdual.com 1 / 25 Über FromDual GmbH FromDual bietet neutral

Mehr