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

Fachbericht zum Thema: Anforderungen an ein Datenbanksystem

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

Mehr

Handbuch ECDL 2003 Basic Modul 5: Datenbank Grundlagen von relationalen Datenbanken

Handbuch ECDL 2003 Basic Modul 5: Datenbank Grundlagen von relationalen Datenbanken Handbuch ECDL 2003 Basic Modul 5: Datenbank Grundlagen von relationalen Datenbanken Dateiname: ecdl5_01_00_documentation_standard.doc Speicherdatum: 14.02.2005 ECDL 2003 Basic Modul 5 Datenbank - Grundlagen

Mehr

Abamsoft Finos im Zusammenspiel mit shop to date von DATA BECKER

Abamsoft Finos im Zusammenspiel mit shop to date von DATA BECKER Abamsoft Finos im Zusammenspiel mit shop to date von DATA BECKER Abamsoft Finos in Verbindung mit der Webshopanbindung wurde speziell auf die Shop-Software shop to date von DATA BECKER abgestimmt. Mit

Mehr

Fragenkatalog zum Kurs 1666 (Datenbanken in Rechnernetzen) Kurstext von SS 96

Fragenkatalog zum Kurs 1666 (Datenbanken in Rechnernetzen) Kurstext von SS 96 Fragenkatalog zum Kurs 1666 (Datenbanken in Rechnernetzen) Kurstext von SS 96 Dieser Fragenkatalog wurde aufgrund das Basistextes und zum Teil aus den Prüfungsprotokollen erstellt, um sich auf mögliche

Mehr

SharePoint Demonstration

SharePoint Demonstration SharePoint Demonstration Was zeigt die Demonstration? Diese Demonstration soll den modernen Zugriff auf Daten und Informationen veranschaulichen und zeigen welche Vorteile sich dadurch in der Zusammenarbeit

Mehr

4. Jeder Knoten hat höchstens zwei Kinder, ein linkes und ein rechtes.

4. Jeder Knoten hat höchstens zwei Kinder, ein linkes und ein rechtes. Binäre Bäume Definition: Ein binärer Baum T besteht aus einer Menge von Knoten, die durch eine Vater-Kind-Beziehung wie folgt strukturiert ist: 1. Es gibt genau einen hervorgehobenen Knoten r T, die Wurzel

Mehr

Suche schlecht beschriftete Bilder mit Eigenen Abfragen

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

Mehr

SQL: statische Integrität

SQL: statische Integrität SQL: statische Integrität.1 SQL: statische Integrität Im allgemeinen sind nur solche Instanzen einer Datenbank erlaubt, deren Relationen die der Datenbank bekannten Integritätsbedingungen erfüllen. Integritätsbedingungen

Mehr

Konfiguration VLAN's. Konfiguration VLAN's IACBOX.COM. Version 2.0.1 Deutsch 01.07.2014

Konfiguration VLAN's. Konfiguration VLAN's IACBOX.COM. Version 2.0.1 Deutsch 01.07.2014 Konfiguration VLAN's Version 2.0.1 Deutsch 01.07.2014 In diesem HOWTO wird die Konfiguration der VLAN's für das Surf-LAN der IAC-BOX beschrieben. Konfiguration VLAN's TITEL Inhaltsverzeichnis Inhaltsverzeichnis...

Mehr

EasyWk DAS Schwimmwettkampfprogramm

EasyWk DAS Schwimmwettkampfprogramm EasyWk DAS Schwimmwettkampfprogramm Arbeiten mit OMEGA ARES 21 EasyWk - DAS Schwimmwettkampfprogramm 1 Einleitung Diese Präsentation dient zur Darstellung der Zusammenarbeit zwischen EasyWk und der Zeitmessanlage

Mehr

How to do? Projekte - Zeiterfassung

How to do? Projekte - Zeiterfassung How to do? Projekte - Zeiterfassung Stand: Version 4.0.1, 18.03.2009 1. EINLEITUNG...3 2. PROJEKTE UND STAMMDATEN...4 2.1 Projekte... 4 2.2 Projektmitarbeiter... 5 2.3 Tätigkeiten... 6 2.4 Unterprojekte...

Mehr

IT-Governance und Social, Mobile und Cloud Computing: Ein Management Framework... Bachelorarbeit

IT-Governance und Social, Mobile und Cloud Computing: Ein Management Framework... Bachelorarbeit IT-Governance und Social, Mobile und Cloud Computing: Ein Management Framework... Bachelorarbeit zur Erlangung des akademischen Grades Bachelor of Science (B.Sc.) im Studiengang Wirtschaftswissenschaft

Mehr

Web Services stellen eine Integrationsarchitektur dar, die die Kommunikation zwischen verschiedenen Anwendungen

Web Services stellen eine Integrationsarchitektur dar, die die Kommunikation zwischen verschiedenen Anwendungen 9 3 Web Services 3.1 Überblick Web Services stellen eine Integrationsarchitektur dar, die die Kommunikation zwischen verschiedenen Anwendungen mit Hilfe von XML über das Internet ermöglicht (siehe Abb.

Mehr

BüroWARE Exchange Synchronisation Grundlagen und Voraussetzungen

BüroWARE Exchange Synchronisation Grundlagen und Voraussetzungen BüroWARE Exchange Synchronisation Grundlagen und Voraussetzungen Stand: 13.12.2010 Die BüroWARE SoftENGINE ist ab Version 5.42.000-060 in der Lage mit einem Microsoft Exchange Server ab Version 2007 SP1

Mehr

Installation SQL- Server 2012 Single Node

Installation SQL- Server 2012 Single Node Installation SQL- Server 2012 Single Node Dies ist eine Installationsanleitung für den neuen SQL Server 2012. Es beschreibt eine Single Node Installation auf einem virtuellen Windows Server 2008 R2 mit

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

Grundlagen verteilter Systeme

Grundlagen verteilter Systeme Universität Augsburg Insitut für Informatik Prof. Dr. Bernhard Bauer Wolf Fischer Christian Saad Wintersemester 08/09 Übungsblatt 3 12.11.08 Grundlagen verteilter Systeme Lösungsvorschlag Aufgabe 1: a)

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

Albert HAYR Linux, IT and Open Source Expert and Solution Architect. Open Source professionell einsetzen

Albert HAYR Linux, IT and Open Source Expert and Solution Architect. Open Source professionell einsetzen Open Source professionell einsetzen 1 Mein Background Ich bin überzeugt von Open Source. Ich verwende fast nur Open Source privat und beruflich. Ich arbeite seit mehr als 10 Jahren mit Linux und Open Source.

Mehr

Ein Beispiel. Ein Unternehmen will Internettechnologien im Rahmen des E- Business nutzen Welche Geschäftsprozesse?

Ein Beispiel. Ein Unternehmen will Internettechnologien im Rahmen des E- Business nutzen Welche Geschäftsprozesse? Ein Beispiel Ein Unternehmen will Internettechnologien im Rahmen des E- Business nutzen Welche Geschäftsprozesse? Dipl.-Kfm. Claus Häberle WS 2015 /16 # 42 XML (vereinfacht) visa

Mehr

Speicher in der Cloud

Speicher in der Cloud Speicher in der Cloud Kostenbremse, Sicherheitsrisiko oder Basis für die unternehmensweite Kollaboration? von Cornelius Höchel-Winter 2013 ComConsult Research GmbH, Aachen 3 SYNCHRONISATION TEUFELSZEUG

Mehr

Beschreibung und Bedienungsanleitung. Inhaltsverzeichnis: Abbildungsverzeichnis: Werkzeug für verschlüsselte bpks. Dipl.-Ing.

Beschreibung und Bedienungsanleitung. Inhaltsverzeichnis: Abbildungsverzeichnis: Werkzeug für verschlüsselte bpks. Dipl.-Ing. www.egiz.gv.at E-Mail: post@egiz.gv.at Telefon: ++43 (316) 873 5514 Fax: ++43 (316) 873 5520 Inffeldgasse 16a / 8010 Graz / Austria Beschreibung und Bedienungsanleitung Werkzeug für verschlüsselte bpks

Mehr

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

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

Mehr

Eigenen WSUS Server mit dem UNI WSUS Server Synchronisieren

Eigenen WSUS Server mit dem UNI WSUS Server Synchronisieren Verwaltungsdirektion Informatikdienste Eigenen WSUS Server mit dem UNI WSUS Server Synchronisieren Inhaltsverzeichnis Einleitung... 3 Installation WSUS Server... 4 Dokumente... 4 Step by Step Installation...

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

White Paper. Konfiguration und Verwendung des Auditlogs. 2012 Winter Release

White Paper. Konfiguration und Verwendung des Auditlogs. 2012 Winter Release White Paper Konfiguration und Verwendung des Auditlogs 2012 Winter Release Copyright Fabasoft R&D GmbH, A-4020 Linz, 2011. Alle Rechte vorbehalten. Alle verwendeten Hard- und Softwarenamen sind Handelsnamen

Mehr

Übungen zur Softwaretechnik

Übungen zur Softwaretechnik Technische Universität München Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering Markus Pister, Dr. Bernhard Rumpe WS 2002/2003 Lösungsblatt 9 17. Dezember 2002 www4.in.tum.de/~rumpe/se

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

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

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

Mehr

OPERATIONEN AUF EINER DATENBANK

OPERATIONEN AUF EINER DATENBANK Einführung 1 OPERATIONEN AUF EINER DATENBANK Ein Benutzer stellt eine Anfrage: Die Benutzer einer Datenbank können meist sowohl interaktiv als auch über Anwendungen Anfragen an eine Datenbank stellen:

Mehr

FTP-Leitfaden RZ. Benutzerleitfaden

FTP-Leitfaden RZ. Benutzerleitfaden FTP-Leitfaden RZ Benutzerleitfaden Version 1.4 Stand 08.03.2012 Inhaltsverzeichnis 1 Einleitung... 3 1.1 Zeitaufwand... 3 2 Beschaffung der Software... 3 3 Installation... 3 4 Auswahl des Verbindungstyps...

Mehr

Software-Validierung im Testsystem

Software-Validierung im Testsystem Software-Validierung im Testsystem Version 1.3 Einleitung Produktionsabläufe sind in einem Fertigungsbetrieb ohne IT unvorstellbar geworden. Um eine hundertprozentige Verfügbarkeit des Systems zu gewährleisten

Mehr

Gesicherte Prozeduren

Gesicherte Prozeduren Gesicherte Prozeduren Wenn eine Anwendung auf einer Client-Maschine läuft, wird normalerweise jede SQL-Anweisung einzeln vom Client an den Server gesandt, und jedes Ergebnistupel wird einzeln zurückgeliefert.

Mehr

SDD System Design Document

SDD System Design Document SDD Software Konstruktion WS01/02 Gruppe 4 1. Einleitung Das vorliegende Dokument richtet sich vor allem an die Entwickler, aber auch an den Kunden, der das enstehende System verwenden wird. Es soll einen

Mehr

Typisierung des Replikationsplan Wirries, Denis Datenbankspezialist

Typisierung des Replikationsplan Wirries, Denis Datenbankspezialist Typisierung des Replikationsplan Wirries, Denis Datenbankspezialist Feintypisierung - Überblick Ergebnisse Ergebnisse aus aus anderen anderen Arbeitsergebnissen Arbeitsergebnissen Replikationsplan Replikationsplan

Mehr

MailUtilities: Remote Deployment - Einführung

MailUtilities: Remote Deployment - Einführung MailUtilities: Remote Deployment - Einführung Zielsetzung Die Aufgabe von Remote Deployment adressiert zwei Szenarien: 1. Konfiguration der MailUtilities von einer Workstation aus, damit man das Control

Mehr

mobilepoi 0.91 Demo Version Anleitung Das Software Studio Christian Efinger Erstellt am 21. Oktober 2005

mobilepoi 0.91 Demo Version Anleitung Das Software Studio Christian Efinger Erstellt am 21. Oktober 2005 Das Software Studio Christian Efinger mobilepoi 0.91 Demo Version Anleitung Erstellt am 21. Oktober 2005 Kontakt: Das Software Studio Christian Efinger ce@efinger-online.de Inhalt 1. Einführung... 3 2.

Mehr

IRF2000 Application Note Lösung von IP-Adresskonflikten bei zwei identischen Netzwerken

IRF2000 Application Note Lösung von IP-Adresskonflikten bei zwei identischen Netzwerken Version 2.0 1 Original-Application Note ads-tec GmbH IRF2000 Application Note Lösung von IP-Adresskonflikten bei zwei identischen Netzwerken Stand: 27.10.2014 ads-tec GmbH 2014 IRF2000 2 Inhaltsverzeichnis

Mehr

Prozessbewertung und -verbesserung nach ITIL im Kontext des betrieblichen Informationsmanagements. von Stephanie Wilke am 14.08.08

Prozessbewertung und -verbesserung nach ITIL im Kontext des betrieblichen Informationsmanagements. von Stephanie Wilke am 14.08.08 Prozessbewertung und -verbesserung nach ITIL im Kontext des betrieblichen Informationsmanagements von Stephanie Wilke am 14.08.08 Überblick Einleitung Was ist ITIL? Gegenüberstellung der Prozesse Neuer

Mehr

In diesem Thema lernen wir die Grundlagen der Datenbanken kennen und werden diese lernen einzusetzen. Access. Die Grundlagen der Datenbanken.

In diesem Thema lernen wir die Grundlagen der Datenbanken kennen und werden diese lernen einzusetzen. Access. Die Grundlagen der Datenbanken. In diesem Thema lernen wir die Grundlagen der Datenbanken kennen und werden diese lernen einzusetzen. Access Die Grundlagen der Datenbanken kurspc15 Inhaltsverzeichnis Access... Fehler! Textmarke nicht

Mehr

Root-Server für anspruchsvolle Lösungen

Root-Server für anspruchsvolle Lösungen Root-Server für anspruchsvolle Lösungen I Produktbeschreibung serverloft Internes Netzwerk / VPN Internes Netzwerk Mit dem Produkt Internes Netzwerk bietet serverloft seinen Kunden eine Möglichkeit, beliebig

Mehr

Sehr geehrte Faktor-IPS Anwender,

Sehr geehrte Faktor-IPS Anwender, März 2014 Faktor-IPS 3.11 Das neue Release Faktor-IPS 3.11 steht Ihnen zum Download zur Verfügung. Wir informieren Sie über die neusten Feautres. Lesen Sie mehr Sehr geehrte Faktor-IPS Anwender, Auf faktorzehn.org

Mehr

dpa-infocom - Datenlieferung

dpa-infocom - Datenlieferung dpa-infocom - Datenlieferung Copyright 2006 von dpa-infocom GmbH Status des Dokuments: FINAL Inhaltsverzeichnis Inhaltsverzeichnis...1 1. Verzeichnisstrukturen...2 2. Nachrichtenmanagement...2 3. Datenübertragung...3

Mehr

OP-LOG www.op-log.de

OP-LOG www.op-log.de Verwendung von Microsoft SQL Server, Seite 1/18 OP-LOG www.op-log.de Anleitung: Verwendung von Microsoft SQL Server 2005 Stand Mai 2010 1 Ich-lese-keine-Anleitungen 'Verwendung von Microsoft SQL Server

Mehr

Folgende Einstellungen sind notwendig, damit die Kommunikation zwischen Server und Client funktioniert:

Folgende Einstellungen sind notwendig, damit die Kommunikation zwischen Server und Client funktioniert: Firewall für Lexware professional konfigurieren Inhaltsverzeichnis: 1. Allgemein... 1 2. Einstellungen... 1 3. Windows XP SP2 und Windows 2003 Server SP1 Firewall...1 4. Bitdefender 9... 5 5. Norton Personal

Mehr

Upgrade-Leitfaden. Apparo Fast Edit 1 / 7

Upgrade-Leitfaden. Apparo Fast Edit 1 / 7 Upgrade-Leitfaden Apparo Fast Edit 1 / 7 Inhaltsverzeichnis 1 Download der neuen Version... 4 2 Sicherung des Apparo Datenbank-Repository... 4 3 De-Installation der installierten Apparo Fast Edit Version...

Mehr

Kurzanleitung. Zuordnung eines Moodle-Kurses in TUMonline

Kurzanleitung. Zuordnung eines Moodle-Kurses in TUMonline Kurzanleitung Zuordnung eines Moodle-Kurses in TUMonline Inhalt 1 Allgemeine Informationen... 2 2 Kategorie elearning zuordnen... 2 3 Wo ist die Kategorie nach der Zuteilung zu finden?... 4 4 Wann wird

Mehr

Was ist PDF? Portable Document Format, von Adobe Systems entwickelt Multiplattformfähigkeit,

Was ist PDF? Portable Document Format, von Adobe Systems entwickelt Multiplattformfähigkeit, Was ist PDF? Portable Document Format, von Adobe Systems entwickelt Multiplattformfähigkeit, Wie kann ein PDF File angezeigt werden? kann mit Acrobat-Viewern angezeigt werden auf jeder Plattform!! (Unix,

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

Lizenzierung von System Center 2012

Lizenzierung von System Center 2012 Lizenzierung von System Center 2012 Mit den Microsoft System Center-Produkten lassen sich Endgeräte wie Server, Clients und mobile Geräte mit unterschiedlichen Betriebssystemen verwalten. Verwalten im

Mehr

Um ein solches Dokument zu erzeugen, muss eine Serienbriefvorlage in Word erstellt werden, das auf die von BüroWARE erstellte Datei zugreift.

Um ein solches Dokument zu erzeugen, muss eine Serienbriefvorlage in Word erstellt werden, das auf die von BüroWARE erstellte Datei zugreift. Briefe Schreiben - Arbeiten mit Word-Steuerformaten Ab der Version 5.1 stellt die BüroWARE über die Word-Steuerformate eine einfache Methode dar, Briefe sowie Serienbriefe mit Hilfe der Korrespondenzverwaltung

Mehr

Der beste Plan für Office 365 Archivierung.

Der beste Plan für Office 365 Archivierung. Der beste Plan für Office 365 Archivierung. Der Einsatz einer externen Archivierungslösung wie Retain bietet Office 365 Kunden unabhängig vom Lizenzierungsplan viele Vorteile. Einsatzszenarien von Retain:

Mehr

WINDOWS 8 WINDOWS SERVER 2012

WINDOWS 8 WINDOWS SERVER 2012 WINDOWS 8 WINDOWS SERVER 2012 IT Fachforum 2012 :: 24.09.-27.09.2012 Andreas Götzfried IT Fachforum::Agenda Windows 8 Windows Server 2012 Zertifizierung WINDOWS 8 Schöne neue Welt Andreas Götzfried Windows

Mehr

7. Übung - Datenbanken

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

Mehr

Autorisierung. Sicherheit und Zugriffskontrolle & Erstellen einer Berechtigungskomponente

Autorisierung. Sicherheit und Zugriffskontrolle & Erstellen einer Berechtigungskomponente Autorisierung Sicherheit und Zugriffskontrolle & Erstellen einer Berechtigungskomponente Dokumentation zum Referat von Matthias Warnicke und Joachim Schröder Modul: Komponenten basierte Softwareentwickelung

Mehr

Guide DynDNS und Portforwarding

Guide DynDNS und Portforwarding Guide DynDNS und Portforwarding Allgemein Um Geräte im lokalen Netzwerk von überall aus über das Internet erreichen zu können, kommt man um die Themen Dynamik DNS (kurz DynDNS) und Portweiterleitung(auch

Mehr

Design Pattern - Strukturmuster. CAS SWE - OOAD Marco Hunziker Klaus Imfeld Frédéric Bächler Marcel Lüthi

Design Pattern - Strukturmuster. CAS SWE - OOAD Marco Hunziker Klaus Imfeld Frédéric Bächler Marcel Lüthi Design Pattern - Strukturmuster CAS SWE - OOAD Marco Hunziker Klaus Imfeld Frédéric Bächler Marcel Lüthi Agenda Einleitung Strukturmuster Fassade Model View Controller Vergleich 2 Einleitung Strukturmuster

Mehr

Benutzerverwaltung Business- & Company-Paket

Benutzerverwaltung Business- & Company-Paket Benutzerverwaltung Business- & Company-Paket Gemeinsames Arbeiten mit der easyfeedback Umfragesoftware. Inhaltsübersicht Freischaltung des Business- oder Company-Paketes... 3 Benutzerverwaltung Business-Paket...

Mehr

4. BEZIEHUNGEN ZWISCHEN TABELLEN

4. BEZIEHUNGEN ZWISCHEN TABELLEN 4. BEZIEHUNGEN ZWISCHEN TABELLEN Zwischen Tabellen können in MS Access Beziehungen bestehen. Durch das Verwenden von Tabellen, die zueinander in Beziehung stehen, können Sie Folgendes erreichen: Die Größe

Mehr

Anwenderdokumentation AccountPlus GWUPSTAT.EXE

Anwenderdokumentation AccountPlus GWUPSTAT.EXE AccountPlus Inhaltsverzeichnis Inhaltsverzeichnis Anwenderdokumentation AccountPlus GWUPSTAT.EXE (vorläufig) ab Version 6.01 INHALTSVERZEICHNIS...1 1 ALLGEMEINES...2 2 INSTALLATION UND PROGRAMMAUFRUF...2

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

Ein mobiler Electronic Program Guide

Ein mobiler Electronic Program Guide Whitepaper Telekommunikation Ein mobiler Electronic Program Guide Ein iphone Prototyp auf Basis von Web-Technologien 2011 SYRACOM AG 1 Einleitung Apps Anwendungen für mobile Geräte sind derzeit in aller

Mehr

E-Mail-Inhalte an cobra übergeben

E-Mail-Inhalte an cobra übergeben E-Mail-Inhalte an cobra übergeben Sie bieten ihren potentiellen oder schon bestehenden Kunden über ihre Website die Möglichkeit, per Bestellformular verschiedene Infomaterialien in Papierform abzurufen?

Mehr

VIDA ADMIN KURZANLEITUNG

VIDA ADMIN KURZANLEITUNG INHALT 1 VIDA ADMIN... 3 1.1 Checkliste... 3 1.2 Benutzer hinzufügen... 3 1.3 VIDA All-in-one registrieren... 4 1.4 Abonnement aktivieren und Benutzer und Computer an ein Abonnement knüpfen... 5 1.5 Benutzername

Mehr

Reporting Services und SharePoint 2010 Teil 1

Reporting Services und SharePoint 2010 Teil 1 Reporting Services und SharePoint 2010 Teil 1 Abstract Bei der Verwendung der Reporting Services in Zusammenhang mit SharePoint 2010 stellt sich immer wieder die Frage bei der Installation: Wo und Wie?

Mehr

Technische Dokumentation: wenn Englisch zur Herausforderung wird

Technische Dokumentation: wenn Englisch zur Herausforderung wird Praxis Technische Dokumentation: wenn Englisch zur Herausforderung wird Anforderungsspezifikation, Requirements-Engineering, Requirements-Management, Terminologieverwaltung www.sophist.de Über Englischkenntnisse

Mehr

1 Mathematische Grundlagen

1 Mathematische Grundlagen Mathematische Grundlagen - 1-1 Mathematische Grundlagen Der Begriff der Menge ist einer der grundlegenden Begriffe in der Mathematik. Mengen dienen dazu, Dinge oder Objekte zu einer Einheit zusammenzufassen.

Mehr

3. Stored Procedures und PL/SQL

3. Stored Procedures und PL/SQL 3. Stored Procedures und PL/SQL Wenn eine Anwendung auf einer Client-Maschine läuft, wird normalerweise jede SQL-Anweisung einzeln vom Client an den Server gesandt, und jedes Ergebnistupel wird einzeln

Mehr

Durchführung der Datenübernahme nach Reisekosten 2011

Durchführung der Datenübernahme nach Reisekosten 2011 Durchführung der Datenübernahme nach Reisekosten 2011 1. Starten Sie QuickSteuer Deluxe 2010. Rufen Sie anschließend über den Menüpunkt /Extras/Reisekosten Rechner den QuickSteuer Deluxe 2010 Reisekosten-Rechner,

Mehr

Kapitel 10 Aktive DBMS

Kapitel 10 Aktive DBMS Kapitel 10 Aktive DBMS 10 Aktive DBMS 10 Aktive DBMS...1 10.1 Einführung und Definition...2 10.2 Funktionsprinzip: ADBMS und ECA-Modell...4 10.3 Potentiale und Vorteile ADBMS...5 10.4 Aktive Elemente einer

Mehr

Datenübernahme easyjob 3.0 zu easyjob 4.0

Datenübernahme easyjob 3.0 zu easyjob 4.0 Datenübernahme easyjob 3.0 zu easyjob 4.0 Einführung...3 Systemanforderung easyjob 4.0...3 Vorgehensweise zur Umstellung zu easyjob 4.0...4 Installation easyjob 4.0 auf dem Server und Arbeitsstationen...4

Mehr

Anbindung an easybill.de

Anbindung an easybill.de Anbindung an easybill.de Stand: 14. Dezember 2011 2011 Virthos Systems GmbH www.pixtacy.de Einleitung Pixtacy verfügt ab Version 2.3 über eine Schnittstelle zu dem Online-Fakturierungsprogramm easybill.de.

Mehr

Zur Bestätigung wird je nach Anmeldung (Benutzer oder Administrator) eine Meldung angezeigt:

Zur Bestätigung wird je nach Anmeldung (Benutzer oder Administrator) eine Meldung angezeigt: K U R Z A N L E I T U N G D A S R Z L WE B - P O R T A L D E R R Z L N E W S L E T T E R ( I N F O - M A I L ) RZL Software GmbH Riedauer Straße 15 4910 Ried im Innkreis Version: 11. Juni 2012 / mw Bitte

Mehr

Business Application Framework für SharePoint Der Kern aller PSC-Lösungen

Business Application Framework für SharePoint Der Kern aller PSC-Lösungen Business Application Framework für SharePoint Der Kern aller PSC-Lösungen Überblick pscbaf Dieses Dokument liefert die Antworten auf folgende Fragen: Was ist das Portal Systems Business Application Framework

Mehr

Sie erhalten einen kurzen Überblick über die verschiedenen Domänenkonzepte.

Sie erhalten einen kurzen Überblick über die verschiedenen Domänenkonzepte. 4 Domänenkonzepte Ziele des Kapitels: Sie verstehen den Begriff Domäne. Sie erhalten einen kurzen Überblick über die verschiedenen Domänenkonzepte. Sie verstehen die Besonderheiten der Vertrauensstellungen

Mehr

StuPro-Seminar Dokumentation in der Software-Wartung. StuPro-Seminar Probleme und Schwierigkeiten in der Software-Wartung.

StuPro-Seminar Dokumentation in der Software-Wartung. StuPro-Seminar Probleme und Schwierigkeiten in der Software-Wartung. StuPro-Seminar Dokumentation in der Software-Wartung StuPro-Seminar Probleme und Schwierigkeiten in der Software-Wartung Folie 1/xx Software-Wartung: theoretisch Ausgangslage eigentlich simpel: fertige

Mehr

Data Mining-Projekte

Data Mining-Projekte Data Mining-Projekte Data Mining-Projekte Data Mining stellt normalerweise kein ei nmaliges Projekt dar, welches Erkenntnisse liefert, die dann nur einmal verwendet werden, sondern es soll gewöhnlich ein

Mehr

Dokumentenverwaltung. Copyright 2012 cobra computer s brainware GmbH

Dokumentenverwaltung. Copyright 2012 cobra computer s brainware GmbH Dokumentenverwaltung Copyright 2012 cobra computer s brainware GmbH cobra Adress PLUS ist eingetragenes Warenzeichen der cobra computer s brainware GmbH. Andere Begriffe können Warenzeichen oder anderweitig

Mehr

Freigabemitteilung Nr. 39. Neue Funktionen Emailadresse zurücksetzen / ändern Kennung ändern Anlegen von OCS (elektr. Postfach) Mailbenutzern

Freigabemitteilung Nr. 39. Neue Funktionen Emailadresse zurücksetzen / ändern Kennung ändern Anlegen von OCS (elektr. Postfach) Mailbenutzern Freigabemitteilung Nr. 39 Neue Funktionen Emailadresse zurücksetzen / ändern Kennung ändern Anlegen von OCS (elektr. Postfach) Mailbenutzern DFBnet Benutzerverwaltung Erstellt: Letzte Änderung: Geprüft:

Mehr

Welche Unterschiede gibt es zwischen einem CAPAund einem Audiometrie- Test?

Welche Unterschiede gibt es zwischen einem CAPAund einem Audiometrie- Test? Welche Unterschiede gibt es zwischen einem CAPAund einem Audiometrie- Test? Auch wenn die Messungsmethoden ähnlich sind, ist das Ziel beider Systeme jedoch ein anderes. Gwenolé NEXER g.nexer@hearin gp

Mehr

Agile Vorgehensmodelle in der Softwareentwicklung: Scrum

Agile Vorgehensmodelle in der Softwareentwicklung: Scrum C A R L V O N O S S I E T Z K Y Agile Vorgehensmodelle in der Softwareentwicklung: Scrum Johannes Diemke Vortrag im Rahmen der Projektgruppe Oldenburger Robot Soccer Team im Wintersemester 2009/2010 Was

Mehr

Installation und Inbetriebnahme von SolidWorks

Installation und Inbetriebnahme von SolidWorks Inhaltsverzeichnis FAKULTÄT FÜR INGENIEURWISSENSCHAFTEN I Prof. Dr.-Ing. Frank Lobeck Installation und Inbetriebnahme von SolidWorks Inhaltsverzeichnis Inhaltsverzeichnis... I 1. Einleitung... 1 2. Installation...

Mehr

Database Exchange Manager. Infinqa IT Solutions GmbH, Berlin Stralauer Allee 2 10245 Berlin Tel.:+49(0) 30 2900 8639 Fax.:+49(0) 30 2900 8695

Database Exchange Manager. Infinqa IT Solutions GmbH, Berlin Stralauer Allee 2 10245 Berlin Tel.:+49(0) 30 2900 8639 Fax.:+49(0) 30 2900 8695 Database Exchange Manager Replication Service- schematische Darstellung Replication Service- allgemeines Replikation von Daten von bzw. in ein SAP-System und einer relationalen DMS-Datenbank Kombination

Mehr

Integration mit. Wie AristaFlow Sie in Ihrem Unternehmen unterstützen kann, zeigen wir Ihnen am nachfolgenden Beispiel einer Support-Anfrage.

Integration mit. Wie AristaFlow Sie in Ihrem Unternehmen unterstützen kann, zeigen wir Ihnen am nachfolgenden Beispiel einer Support-Anfrage. Integration mit Die Integration der AristaFlow Business Process Management Suite (BPM) mit dem Enterprise Information Management System FILERO (EIMS) bildet die optimale Basis für flexible Optimierung

Mehr

Stammdaten Auftragserfassung Produktionsbearbeitung Bestellwesen Cloud Computing

Stammdaten Auftragserfassung Produktionsbearbeitung Bestellwesen Cloud Computing Stammdaten Auftragserfassung Produktionsbearbeitung Bestellwesen Cloud Computing Finanzbuchhaltung Wenn Sie Fragen haben, dann rufen Sie uns an, wir helfen Ihnen gerne weiter - mit Ihrem Wartungsvertrag

Mehr

Auto-Provisionierung tiptel 30x0 mit Yeastar MyPBX

Auto-Provisionierung tiptel 30x0 mit Yeastar MyPBX Allgemeines Auto-Provisionierung tiptel 30x0 mit Yeastar MyPBX Stand 21.11.2014 Die Yeastar MyPBX Telefonanlagen unterstützen die automatische Konfiguration der tiptel 3010, tiptel 3020 und tiptel 3030

Mehr

Transparente Hausverwaltung Marketingschmäh oder doch: eine neue Dimension der Dienstleistung?

Transparente Hausverwaltung Marketingschmäh oder doch: eine neue Dimension der Dienstleistung? Transparente Hausverwaltung Marketingschmäh oder doch: eine neue Dimension der Dienstleistung? INTERNET Geschäftsführer Biletti Immobilien GmbH 24/7 WEB Server Frankgasse 2, 1090 Wien E-mail: udo.weinberger@weinberger-biletti.at

Mehr

2.5.2 Primärschlüssel

2.5.2 Primärschlüssel Relationale Datenbanken 0110 01101110 01110 0110 0110 0110 01101 011 01110 0110 010 011011011 0110 01111010 01101 011011 0110 01 01110 011011101 01101 0110 010 010 0110 011011101 0101 0110 010 010 01 01101110

Mehr

Mai 2006. Hauptseminar: Nichtrelationale Datenbanken Historisch-Kulturwissenschaftliche Informationsverarbeitung Universität zu Köln

Mai 2006. Hauptseminar: Nichtrelationale Datenbanken Historisch-Kulturwissenschaftliche Informationsverarbeitung Universität zu Köln Hauptseminar: Nichtrelationale Historisch-Kulturwissenschaftliche Informationsverarbeitung Universität zu Köln Mai 2006 Was ist eine Datenbank? Erweiterung relationaler um eine Deduktionskomponente Diese

Mehr

Registrierung am Elterninformationssysytem: ClaXss Infoline

Registrierung am Elterninformationssysytem: ClaXss Infoline elektronisches ElternInformationsSystem (EIS) Klicken Sie auf das Logo oder geben Sie in Ihrem Browser folgende Adresse ein: https://kommunalersprien.schule-eltern.info/infoline/claxss Diese Anleitung

Mehr

Ist Excel das richtige Tool für FMEA? Steve Murphy, Marc Schaeffers

Ist Excel das richtige Tool für FMEA? Steve Murphy, Marc Schaeffers Ist Excel das richtige Tool für FMEA? Steve Murphy, Marc Schaeffers Ist Excel das richtige Tool für FMEA? Einleitung Wenn in einem Unternehmen FMEA eingeführt wird, fangen die meisten sofort damit an,

Mehr

Fassade. Objektbasiertes Strukturmuster. C. Restorff & M. Rohlfing

Fassade. Objektbasiertes Strukturmuster. C. Restorff & M. Rohlfing Fassade Objektbasiertes Strukturmuster C. Restorff & M. Rohlfing Übersicht Motivation Anwendbarkeit Struktur Teilnehmer Interaktion Konsequenz Implementierung Beispiel Bekannte Verwendung Verwandte Muster

Mehr

1 topologisches Sortieren

1 topologisches Sortieren Wolfgang Hönig / Andreas Ecke WS 09/0 topologisches Sortieren. Überblick. Solange noch Knoten vorhanden: a) Suche Knoten v, zu dem keine Kante führt (Falls nicht vorhanden keine topologische Sortierung

Mehr

Einrichten der Outlook-Synchronisation

Einrichten der Outlook-Synchronisation Das will ich auch wissen! - Kapitel 3 Einrichten der Outlook-Synchronisation Inhaltsverzeichnis Überblick über dieses Dokument... 2 Diese Kenntnisse möchten wir Ihnen vermitteln... 2 Diese Kenntnisse empfehlen

Mehr

euro-bis Import von Bestellungen aus Buch- und Aboauskunft Stand 22.02.2007

euro-bis Import von Bestellungen aus Buch- und Aboauskunft Stand 22.02.2007 euro-bis Import von Bestellungen aus Buch- und Aboauskunft Stand 22.02.2007 INHALTSVERZEICHNIS Konfiguration... 3 Buch- und Aboauskunft... 3 euro-bis... 3 Aufträge einlesen... 5 Kundendaten prüfen... 6

Mehr

Übung: Verwendung von Java-Threads

Übung: Verwendung von Java-Threads Übung: Verwendung von Java-Threads Ziel der Übung: Diese Übung dient dazu, den Umgang mit Threads in der Programmiersprache Java kennenzulernen. Ein einfaches Java-Programm, das Threads nutzt, soll zum

Mehr

3D Visualisierung von UML Umgebungsmodellen

3D Visualisierung von UML Umgebungsmodellen 3D Visualisierung von UML Umgebungsmodellen Vortragender: Helmer Krämer Betreuer: Dr. Holger Giese 3D Visualisierung von UML Umgebungsmodellen Krämer Seite 1 Motivation und Anforderungen Das Umgebungsmodell

Mehr