Bachelorarbeit zur Erlangung des akademischen Grades Bachelor of Science

Größe: px
Ab Seite anzeigen:

Download "Bachelorarbeit zur Erlangung des akademischen Grades Bachelor of Science"

Transkript

1 Fachbereich Elektrotechnik und Informatik Studiengang Angewandte Informatik Bachelorarbeit zur Erlangung des akademischen Grades Bachelor of Science Software zur automatischen Zuordnung von ähnlichen Datenbank-Schemata inklusive Datenmigration und Testdatenerzeugung Karl Glatz 13. März 2009 Betreuer Prof. Dr. Martin Hulin Hochschule Ravensburg-Weingarten Dr. Michael Keckeisen TWT GmbH - Neuhausen

2 Karl Glatz: Software zur automatischen Zuordnung von ähnlichen Datenbank-Schemata inklusive Datenmigration und Testdatenerzeugung Bachelorarbeit Hochschule Ravensburg-Weingarten Bearbeitungszeitraum: 15. Dezember März 2009

3 Eidesstattliche Versicherung Ich versichere an Eides statt durch meine Unterschrift, dass ich die vorliegende Bachelorarbeit mit dem Thema Software zur automatischen Zuordnung von ähnlichen Datenbank-Schemata inklusive Datenmigration und Testdatenerzeugung ohne fremde Hilfe verfasst und nur die angegebenen Quellen und Hilfsmittel benutzt habe. Wörtlich oder dem Sinn nach anderen Werken entnommene Stellen sind unter Angabe der Quellen kenntlich gemacht. Diese Arbeit hat in gleicher oder ähnlicher Form noch keiner Prüfungsbehörde vorgelegen. Neuhausen auf den Fildern, Karl Glatz I

4

5 Inhaltsverzeichnis Abbildungsverzeichnis Tabellenverzeichnis Abkürzungsverzeichnis VII IX X 1 Einleitung Problemstellung und Motivation Zieldenition und Vorgehensweise Projektmanagement Anforderungen Grundlagen und Begrie Datenbanksysteme Elemente eines relationalen Datenbanksystems Beziehungen und Normalformen Schema Anforderungen an die Datenmigration Änderung am Datenbankmodell Heterogenität Strukturelle und semantische Heterogenität Zuordnung von Tabellen und Spalten Ernden von Werten Komplexe Zuordnungen Datentypen Anforderungen an Testdaten Analyse bestehender Lösungsansätze Theoretische Ansätze Dynamische Schemaevolution Schemaintegration Schema Mapping Schema Matching SchemaSQL Produkte Oracle SQL Developer (Version 1.5.1) IBM Clio Altova MapForce (Enterprise 2009) Zusammenfassung III

6 4 Ansatz Voraussetzungen für eine Datenmigration Schema Zuordnung im Detail Konstante Werte SQL Erkennen von Ähnlichkeiten zwischen Schemaelementen Vergleich von Namen Vergleich der Struktureigenschaften Optimierungsmöglichkeiten Erzeugen von Testdaten Software-Entwurf Technologie Die Datenbank Abstraktion JDBC JDBC und ODBC Generelle Aspekte Sprache Metadaten Allgemeine Architektur Datenbankzugri Datenmodell (Meta Modell) Modellerweiterung für die Datenmigration Modellerweiterung für die Testdatenerzeugung Logik Oberäche Implementierung Allgemeiner Ablauf Migration: Zuordnung von Tabellen und Spalten Denition alternativer Inhalte Editierabstand Bewertungskriterien und Gewichtung Realisierung der automatischen Zuordnung Datenbankoperationen Abhängigkeiten zwischen Tabellen durch Beziehungen Oracle: Sequenzen und Trigger Migrationsvorgang Testdaten Speichern und Laden von Projekten Einschränkungen Test Test der Datenmigration Schema A (MS Access XP) Schema B (Oracle 10g) Konguration Testdaten erzeugen IV

7 8 Schlussbetrachtung Zusammenfassung Ergebnisse dieser Arbeit Ausblick Danksagungen Literaturverzeichnis Anhang A C V

8

9 Abbildungsverzeichnis 1.1 Typischer Entwicklungsablauf (stark vereinfacht) Begrie einer relationalen Datenbank; Quelle: [Wik09b] Entity-Relationship-Diagramm in Chen-Notation Darstellung einer Datentransformation; Quelle: [Nau06b] Beispiel: Zuordnung von Tabellen und Spalten Gegenüberstellung zweier ähnlicher Schemata mit unterschiedlichen Beziehungen Beispielhafte Darstellung einer nicht trivialen Zuordnung (Datensicht) Mehrwertige Korrespondenzen (1:1, N:1, 1:N) Höherstuge Korrespondenzen (gestrichelt); Quelle: [LN07a] Schema Matching Klassikation nach [RB01] SQL Developer MS Access Export Oracle SQL Developer Startbildschirm Altova MapForce Screenshot; Quelle: Altova Webseite IBM Clio; Quelle: [IBM] Ansatz der Zuordnung von Schemaelementen SQL Befehl Beispiel Beziehungen zwischen Testdaten (Beispiel) JDBC: Vereinfachter Aufbau Schichtenmodell der Komponenten Datenbank und Plugin Interfaces (UML) Basis Datenmodell der Anwendung Erweiterung des Datenmodells (Migration) Kompletter Entwurf des Datenmodells Klassen der Logik Komponente Simpler Oberächen Entwurf Allgemeiner Ablauf als Aktivitätsdiagramm Beziehungen zwischen Tabellen als Graph Trigger und Sequenz im Verbindungsdialog Migrationsvorgang Sequenzdiagramm Arbeitsweise von buildnextrow() Ermittlung der Voreinstellungen für Testdaten Quellschema (Schema A) [MS Access] Zielschema (Schema B) [Oracle Designer] VII

10 VIII 7.3 Screenshot der Konguration des Migrationsprojektes Migration: Tabelle XY_FZG_TYPEN Konguration Testdaten Einstellungen Testdaten: Ausschnitt der generierten Daten

11 Tabellenverzeichnis 1.1 Zeitplan Kardinalitäten, Beispiele und deren Abbildung in der DB Quellen für Testdatenerzeugung Vergleich der Technologien Bewertungstabelle für Ähnlichkeiten zwischen Schemaelementen Beispiel: Bewertung der Ähnlichkeit von Spalten IX

12 X

13 Abkürzungsverzeichnis DB gängige Abkürzung für Datenbank DBMS.... Database Management System Datenbankverwaltungssystem DDL GUI Data Denition Language - Teil der Datenbanksprache, der zur Verwaltung der Elemente der Datenbank dient Graphical User Interface Eine grasche Benutzeroberäche JDBC.... Java Database Connectivity Datenbank Abstraktion von Java JDK MFC MS Java Development Kit Java Paket zur Entwicklung von Java Programmen Microsoft Foundation Classes Bibliothek um Oberächen für Windows zu erstellen gängige Abkürzung für Microsoft ODBC.... Open Database Connectivity Eine standardisierte Datenbankschnittstelle ORM..... Object-Relational Mapping -Objektrelationale Abbildung RDBMS.. Relational Database Management System Relationales Datenbanksystem SQL UML..... Structured Query Language Datenbanksprache zur Denition, Abfrage und Manipulation von Daten in relationalen Datenbanken Unied Modeling Language eine von der Object Management Group (OMG) entwickelte und standardisierte Sprache für die Modellierung von Software und anderen Systemen XI

14

15 1 Einleitung 1.1 Problemstellung und Motivation Zu den Aufgabenbereichen vieler IT-Unternehmen zählt die Entwicklung datenbankgestützter Software. Dabei ist die Datenbank ein Bestandteil des gesamten Software- Systems. Sie dient zur Speicherung und Verwaltung der Daten. Es besteht die Anforderung, das Software-System stetig weiterzuentwickeln sowie mit erweiterter Funktionalität zu versehen. Dies kann zur Folge haben, dass eine komplette Umstellung des Systems erfolgen muss. Soll diese Umstellung bei einem System erfolgen, das sich im produktiven Einsatz bendet, muss gewährleistet werden, dass die bestehenden Daten problemlos in das neue System migriert werden können. Zur optimalen Anbindung des neuen Systems kann der Einsatz eines anderen Datenbankprodukts nötig sein. Abbildung 1.1 verdeutlicht den zeitlichen Zusammenhang. Dateneingabe Dateneingabe Benutzer (altes) Produktivsystem Entwicklung des neuen System Umstellungsphase neues System Zeit Abbildung 1.1: Typischer Entwicklungsablauf (stark vereinfacht) Viele, der auf dem Markt verfügbaren Produkte zur Migration von Datenbanken erlauben nur eine komplette Übertragung der Datenbank. Dies schlieÿt das Schema 1 der Datenbank mit ein. Die Neuentwicklung des Systems erfordert eine Anpassung des Schemas. Um alle Daten aus dem alten in das neue System zu übernehmen muss die Übertragung während der Umstellungsphase erfolgen. Die Unterschiede der Schemata, die zu diesem Zeitpunkt gegeben sind, müssen bei der Umstellung besonderes beachtet werden. Ein weiteres Problem stellt die Geheimhaltung der Daten dar. Externe Unternehmen erlauben nur eingeschränkten Zugri auf sensible Daten aus dem Produktivsystem. 1 Struktur der Daten; Begri wird in Abschnitt erläutert. 1

16 1 Einleitung Aus diesem Grund dürfen Daten von externen Unternehmen nicht für alle beteiligten Entwickler sichtbar sein. Auf Testläufe während der Entwicklung kann jedoch in keinem Fall verzichtet werden. Das manuelle Eintragen von Testdaten verursacht enormen Aufwand und erhöht somit die Kosten. Deswegen ist es notwendig diesen Prozess zu vereinfachen. 1.2 Zieldenition und Vorgehensweise Ziel dieser Bachelorarbeit ist eine prototypische Softwarelösung, mit der sich folgende Aufgaben möglichst einfach lösen lassen: Migration von Daten zwischen zwei heterogenen Datenbanken am Beispiel von Microsoft Access und Oracle Teilautomatische Erzeugung von Testdaten am Beispiel einer Oracle Datenbank Neben diesen primären Zielen soll eine Basis für zukünftige Datenmigrationen geschaffen werden. Daher spielt die Modularität des Programms eine wichtige Rolle. Da die Migration von Daten ein komplexer Prozess ist und nicht jeder beliebige Fall abgedeckt werden kann, wird in Kapitel 2 genau dargelegt, welche Anforderungen erfüllt werden müssen. In diesem Zusammenhang werden theoretische und begriiche Grundlagen erläutert. Anschlieÿend wird eine Analyse bestehender Ansätze durchgeführt (3). Neben theoretischen Ansätzen wird auch überprüft, welche Möglichkeiten aktuelle Produkte bieten um diesen Anforderungen gerecht zu werden. Der Ansatz zur Lösung der bestehenden Probleme unter Beachtung der gegebenen Anforderungen wird in Kapitel 4 beschrieben. Das Kapitel 5 zeigt einen grundlegenden Entwurf für die angestrebten Lösung. Basierend auf diesem Entwurf wird die Implementierung der Anwendung im Detail beschrieben (6). Um eine Verikation für die korrekte Funktionalität der entworfenen Anwendung zu bekommen wurde ein praxisnaher Test entworfen (7). Zum Abschluss wird eine Zusammenfassung der Ergebnisse dieser Bachelorarbeit erstellt sowie ein Ausblick auf künftige Weiterentwicklungen gegeben (8). 1.3 Projektmanagement Die Projektplanung ist ein wichtiger Baustein für den Erfolg eines Projektes. Da dieses Projekt Teil einer Bachelorarbeit ist, wird mit einer 7 Tage Woche gerechnet. Die genaue Dauer einer Aufgabe kann im Voraus nicht bestimmt werden, deshalb ist es notwendig zusätzlich einen Puer festzulegen. Der Zeitplan ist vor allem wichtig, weil er es ermöglicht, zeitliche Probleme während des Projektes früh zu erkennen. 2

17 1.3 Projektmanagement Aufgabe Zeit (Tage) Analyse der Anforderungen, Machbarkeitsstudie 2 Erarbeiten der theoretischen Grundlagen 4 Recherche bestehender Lösungen 2 Projektplanung 2 Erarbeiten des Lösungsansatzes 3 Entwurf der Software-Architektur 5 Entwicklungs- und Testumgebung einrichten 1 Programmierung grundlegender Funktionen 11 Programmierung der Migration 14 Programmierung der Testdatenerzeugung 8 Dokumentation (Quellcode, Bachelorarbeit) 24 Projektabschluss 2 Benötigte Zeit 78 Verfügbare Zeit (12 Wochen) 84 Puer 6 Tabelle 1.1: Zeitplan Das Testen des Quellcodes erfolgt kontinuierlich während der Programmierung und ist deshalb in den Zeitangaben der Programmieraufgaben enthalten. 3

18 2 Anforderungen In diesem Kapitel werden zunächst die Grundlagen und Begriichkeiten (2.1) vorgestellt. Weiterhin werden die Anforderungen an das System (2.2, 2.3) deniert und durch entsprechende Beispiele erläutert. 2.1 Grundlagen und Begrie Datenbanksysteme Implizit wird bei Datenbanken meist von den weit verbreiteten relationalen Datenbanksystemen (RDBMS) ausgegangen. Diese Arbeit beschränkt sich in diesem Zusammenhang auf relationale Datenbanksysteme, die SQL 1 unterstützen. Ein Datenbanksystem hat die Aufgabe, Daten möglichst ezient dauerhaft zu speichern. Ebenso soll es die Verwaltung der Daten vereinfachen. Relationale Datenbanksysteme nutzen das relationale Datenmodell. Es besteht aus den nachfolgend erläuterten Elementen und bietet dem Nutzer eine logische, mengenorientierte Abfrage der Daten. Alle Betrachtungen werden so allgemein wie möglich gehalten. Spezische Beispiele und Implementierungen erfolgen mit Microsoft Access XP und Oracle 10g Elemente eines relationalen Datenbanksystems Aus Benutzersicht besteht ein relationales Datenbanksystem aus Tabellen und Spalten. Jedoch unterscheidet sich ein Datenbanksystem im Detail enorm von einer Tabellenkalkulations- Software. In Tabellen sind die Spalten (auch als Attribute oder Felder bekannt) deniert. Eine Datenbank beinhaltet in der Regel mehrere Tabellen. Eine Spalte besitzt neben einem Namen immer auch einen Datentyp. Sie kann also nur bestimmte Daten aufnehmen. Beispiele hierfür sind die Datentypen Number (Zahlen) und Varchar (Text). Datentypen sind sowohl für die interne Speicherung der Daten durch das Datenbanksystem, als auch für die Datenbank-Benutzer wichtig. Die physikalische Datenspeicherung auf dem Datenträger kann je nach Datentyp durch das Datenbanksystem optimiert werden. Dem Anwender nutzen sie bei der Eingabe 1 Abfragespache für Datenbanken 4

19 2.1 Grundlagen und Begrie Relationsname/ Tabellenname Attribute/Felder/Spalten Relationenschema R A1 Wert... An Relation/ Tabelle Tupel/Zeilen Abbildung 2.1: Begrie einer relationalen Datenbank; Quelle: [Wik09b] von Daten. Bei einem fehlerhaften Eintrag aufgrund eines falschen Datentyps wird ein Fehler angezeigt. Als Zeilen (oder auch Tupel) bezeichnet man die eigentlichen Datensätze. Eine Zeile enthält für jede Spalte einen Wert. Soll eine Spalte mit keinem Wert belegt werden, so ist der Inhalt NULL 2. Abbildung 2.1 zeigt beispielhaft eine Tabelle mit Beschriftung der Begrie. Für die Elemente einer Datenbank gibt es verschiedene Begrie, welche nahezu gleichbedeutend sind. Diese Arbeit beschränkt sich auf folgende deutsche Begrie: Datenbank, Tabelle, Spalte und Zeile. Relationale Datenbanksysteme bieten dem Nutzer viele weitere Vorteile gegenüber der Speicherung als Datei auf einem Datenträger. Dazu zählen neben Mehrbenutzerfähigkeit und Transaktionen auch Datensicherheit und Datenintegrität. Zur Datensicherheit zählt sowohl der Schutz vor Datenverlust, als auch vor unerlaubtem Zugri durch Dritte. Die Datenintegrität wird durch Regeln (Constraints) erreicht. Diese geben vor, welche Daten wie geändert werden dürfen. Wichtigste Regel für die Datenintegrität ist der Fremdschlüssel (Foreign Key Constraint) Beziehungen und Normalformen Beziehungen zwischen Daten werden in einem relationalen Datenbanksystem mit Hilfe von Schlüsselspalten realisiert. Primärschlüssel sind Schlüssel, die einen Datensatz (Zeile) eindeutig identizieren. Fremdschlüssel sind Schlüssel, die in eine Tabelle eingetragen werden, um eine Verbindung des Datensatzes zu einem anderen Datensatz herzustellen. Die Werte dieser Spalte identizieren den verknüpften Datensatz eindeutig. Modelliert werden Beziehungen oft in so genannten Entity-Relationship (ER) Diagrammen (siehe Abbildung 2.2). Diese Notation ermöglicht eine abstrahierte Sicht: Tabellen 2 Besonderer Wert der für kein Inhalt steht. 5

20 2 Anforderungen Kunde vergibt Auftrag Mitarbeiter arbeitet an Abbildung 2.2: Entity-Relationship-Diagramm in Chen-Notation werden als Entitäten, Spalten als Attribute einer Entität dargestellt. Eine Entität kann, anders als Tabellen, direkte Beziehungen zu anderen Entitäten besitzen. Die Art der Beziehung wird mit einer Kardinalität festgelegt. Die Kardinalität gibt den Grad der Beziehung an. Sie bestimmt, wie viele Elemente mit einem Element dieser Entität verknüpft sein können. Diese Darstellung kann, wie in Tabelle 2.1 erklärt, in Tabellen mit Primär 3 - und Fremdschlüsseln umgewandelt werden. Normalformen Unter Normalisierung versteht man eine schrittweise Zerlegung von einer Tabelle in mehrere Tabellen auf der Grundlage funktionaler Abhängigkeiten. Das Ziel ist die Vermeidung von Redundanzen und Anomalien. Auch die Steigerung der Konsistenz kann eine Motivation zur Normalisierung sein. Daten in relationalen Datenbanksystemen liegen üblicherweise in der dritten Normalform (3NF) vor. Diese Normalform bietet für die Praxis den gröÿten Nutzen. Für eine detailliertere Erklärung der Normalformen muss auf [Kel98] verwiesen werden. Daten in der dritten Normalform müssen bei einer Abfrage aus mehreren Tabellen zusammengesetzt werden. Weil dies zu Geschwindigkeitseinbuÿen führt, wird zur Optimierung für bestimmte Anwendungen teilweise auf Normalisierung verzichtet. 3 Statt eines Primärschlüssels kann auch ein eindeutiger Schlüssel (unique key) genutzt werden. 1 Kardinalität 2 Theoretisch ist es möglich, dass so eine Person mehrere Personalausweise besitzt. Dies lässt sich jedoch über eine Einschränkung der Fremdschlüsselspalte verhindern (Unique Constraint). 6

21 2.2 Anforderungen an die Datenmigration K 1 Beschreibung Beispiel Abbildung in der DB 1:1 Eine Entität wird hierbei höchstens genau einer anderen Entität zugeordnet Ein Personalausweis gehört genau zu einer Person Die Personalausweis Tabelle erhält einen Fremdschlüssel der auf den Primärschlüssel von 1:N Einer Entität können keine oder mehrere Entitäten zugeordnet werden M:N Beliebig viele Entitäten können zugeordnet werden Schema Ein Kind hat genau eine Mutter, eine Mutter kann mehrere Kinder haben Ein Student hört mehrere Vorlesungen, eine Vorlesung wird von mehreren Studenten gehört Person verweist 2 In der Tabelle Kind wird ebenfalls ein Fremdschlüssel erstellt, der auf den Primärschlüssel von Mutter zeigt Es wird eine Hilfstabelle erstellt, welche beide Primärschlüssel der Tabellen Student und Vorlesungen enthält Tabelle 2.1: Kardinalitäten, Beispiele und deren Abbildung in der DB Ein Schema (...) ist eine formale Beschreibung der Struktur von Daten. [Wik09c] Im Schema der Datenbank ndet eine genaue Denition aller bisher erläuterten Elemente statt. Neben diesen werden, je nach Datenbankhersteller, viele weitere Struktureigenschaften (z. B. Constraints) unterstützt. Folglich legt ein Datenbankschema fest, welche Tabellen mit welchen Spalten in einer Datenbank existieren. Durch die Struktureigenschaften können die Beziehungen zwischen diesen Tabellen bestimmt werden. Die formale Denition ndet bei relationalen Datenbanksystemen meist mit Hilfe des DDL-Teils 4 von SQL statt. 2.2 Anforderungen an die Datenmigration Das in Abschnitt 1.1 beschriebene Szenario erfordert, dass die Daten von einem Datenbanksystem in ein anderes migriert werden. Die Schemata beider Datenbanken bleiben dabei unberührt. Die Datenbankprodukte können von unterschiedlichen Herstellern stammen. Die Daten müssen von einer Repräsentation in eine andere überführt werden. Dieser Vorgang wird auch als Datentransformation bezeichnet (Abbildung 2.3). Eine Übertra- 4 Data Denition Language; Teil der Datenbanksprache, der zur Verwaltung der Elemente der Datenbank dient. 7

22 2 Anforderungen Quellschema Mapping Zielschema Quelldaten Transformationsanfrage Zieldaten Abbildung 2.3: Darstellung einer Datentransformation; Quelle: [Nau06b] gung zwischen zwei ähnlichen Schemata hat den Vorteil, dass sich die Repräsentation der Daten nicht fundamental unterscheidet. Änderungen am Schema werden nur dann gemacht, wenn dies absolut erforderlich ist. Der gesamte Vorgang wird in dieser Arbeit als Datenmigration bezeichnet. Der weitere Verlauf des Abschnitts führt von den Gründen zur Änderung eines Schemas über die daraus resultierende Heterogenität hin zur konkreten Anforderung. Die Anforderungen werden zum besseren Verständnis anhand von Beispielen erklärt Änderung am Datenbankmodell Bei der Modellierung der Datenbank wird ein Teil der Realität in einem Modell abgebildet. Aus diesem Modell ergibt sich das Schema der Datenbank. Im professionellen Umfeld erfolgt dabei zunächst eine Analyse des Prozesses. Dabei handelt es sich um ein Beobachten und Dokumentieren der Wirklichkeit. Aus dieser Analyse werden Schlüsse gezogen, welche wiederum zu einer Annahme führen. Beispiel: Beobachtung Annahme Schlussfolgerung Es ist kein Semester bekannt, in dem ein Student an der HS-Weingarten eine Vorlesung gehalten hat. Studenten halten keine Vorlesungen. Das Modell muss keine hält Beziehung zwischen Student und Vorlesung vorsehen. Ist ein bestimmter Fall in der Vergangenheit nie eingetreten, so kann nicht automatisch davon ausgegangen werden, dass dies in Zukunft nicht doch geschehen wird. Um ein Modell jedoch möglichst ezient und simpel zu gestalten, müssen solche Annahmen und Schlussfolgerungen gemacht werden. Ändern sich die Gegebenheiten, muss das Modell angepasst werden. Im beschriebenen Beispiel wird hierzu eine hält Beziehung zwischen Student und Vorlesung hergestellt. 8

23 2.2 Anforderungen an die Datenmigration Dieses simple Beispiel zeigt, warum sich in einem Modell die Beziehungen verändern können. Durch komplexe Anforderungen an eine Softwarelösung können die Änderungen des Schemas wesentlich stärker ausfallen. Technische Gründe Ein weiterer Grund zur Änderung eines Schemas ist die Optimierung auf eine Anwendung. Beispiel: Moderne Softwaresysteme setzen immer häuger Objektorientierung ein. Um Daten aus einer relationalen Datenbank möglichst einfach in die Objektorientierung einzubinden, wird oft eine objektrelationale Abbildung (ORM) eingesetzt. Um den Prozess der Abbildung von relationalen Daten auf Objekte zu vereinfachen, gibt es unterschiedliche Software, die den Entwickler unterstützt. Je nach Konzept und Art dieser Software kann es nötig sein, das Schema entsprechend anzupassen. Grobe Entwurfsfehler im Schema der Quelldatenbank können ebenfalls eine Motivation zur Änderung sein Heterogenität Aus den Änderungen am Datenbankmodell entstehen Unterschiede zwischen den Schemata der Datenbanken. Diese Unterschiede werden im Buch Informationsintegration von Ulf Lesser und Felix Naumann [LN07b] als Heterogenität wie folgt deniert: Zwei Informationssysteme, die nicht exakt die gleichen Methoden, Modelle und Strukturen zum Zugri auf Ihre Daten anbieten, werden als heterogen bezeichnet. Da die Heterogenität zwischen Informationssystemen auf vielen verschiedenen Ebenen bestehen kann, wird im Folgenden nur auf die für die Datenmigration wichtigen Aspekte eingegangen. Für die Betrachtung wird die Denition der Arten von Heterogenität aus [LN07b] verwendet. Da diese Arbeit nur relationale Datenbanksysteme betrachtet, ist eine gewisse technische Homogenität gewährleistet. Dennoch gilt es, die technischen Unterschiede zwischen einzelnen Datenbankprodukten zu beseitigen. Des Weiteren ist auch keine Datenmodellheterogenität gegeben. Das liegt daran, dass alle relationalen Datenbanksysteme das relationale Datenmodell nutzen. Syntaktische Heterogenität liegt vor, wenn die Darstellung derselben Daten in den Datenbanksystemen unterschiedlich ist. Das ist bei verschiedenen Datenbankprodukten von unterschiedlichen Herstellern oft der Fall (Stichwort: Datentypen). Die syntaktische Heterogenität lässt sich jedoch durch Konvertierung der Daten relativ leicht überwinden. Das Verändern eines Schemas der Datenbank kann zu struktureller und semantischer Heterogenität führen. 9

24 2 Anforderungen Strukturelle und semantische Heterogenität Unter diesen zwei Begrien werden alle Unterschiede, die das Schema und die darin verwendeten Namen und Konzepte betreen, zusammengefasst. Im Folgenden wird kurz erklärt, wie sich diese Unterschiede klassizieren lassen. Strukturelle Heterogenität liegt vor, wenn zwei Schemata unterschiedlich sind, obwohl sie den gleichen Ausschnitt aus der realen Welt erfassen. [LN07b] Durch Veränderungen am Schema kann eine strukturelle Heterogenität zwischen dem veränderten Schema und dessen Ursprungsschema entstehen. Einige Gründe zur Änderung wurden bereits in den vorhergehenden Abschnitten aufgezeigt. Dazu gehört neben der Umsetzung eines konzeptionellen Modells in ein Schema auch die Optimierung auf eine bestimmte Anwendung. Die schematische Heterogenität ist ein Spezialfall der strukturellen Heterogenität. Sie liegt vor, wenn verschiedene Elemente des Datenmodells (also Tabellen, Spalten oder Werte) zur Modellierung genutzt werden. Abbildung 2.4 zeigt ein solches Beispiel: In der Quelldatenbank ist das Auto als Tabelle modelliert, die Art des Fahrzeuges ist durch den Namen der Tabelle klar deniert. In der Zieldatenbank hingegen ist die Art des Fahrzeuges erst durch den Wert der Spalte FZG_TYP deniert. Ebenso wäre eine Modellierung als Spalte denkbar, je eine Spalte pro Fahrzeugtyp. Als Datentyp könnte man hierfür Boolean (wahr/falsch) nutzen. Die Schemaelemente besitzen Namen, welche zunächst lediglich Zeichenketten sind. Ein Mensch kann jedoch deuten, welche Information sich hinter einem Element bendet. Dies ist möglich, da der Mensch neben dem vorhandenen Wissen über das Schema zusätzliches Weltwissen besitzt. Semantische Heterogenität liegt vor, wenn die Elemente verschiedener Schemata sich intensional überlappen [LN07b] Um die Denition besser zu verstehen, werden die Begrie Intension und Extension deniert. Die Intension eines Elements beschreibt deren Konzept. Als Extension versteht man alle Objekte dieses Konzepts in der realen Welt. Beispiel: Die Intension des Tabellennamens Produkt ist alle Erzeugnisse die verkauft werden. Die Extension hingegen ist die Menge aller jemals hergestellten Produkte. Die konkrete Extension der Tabelle Produkt sind alle zu einem Zeitpunkt darin enthaltenen Zeilen. Semantische Konikte treten auf, wenn der Zusammenhang zwischen Namen und Konzepten in den Systemen verschieden ist. Es gibt drei Arten von semantischen Konikten. Ein Synonym liegt vor, wenn zwei Namen die unterschiedlich sind, die gleiche Intension haben. Homonyme sind hingegen zwei gleiche Namen mit unterschiedlicher Intension. Beispiel hierfür ist das Wort Kiwi - es beschreibt sowohl eine Frucht als auch einen Vogel. Die dritte Art ist das Hyperonym. Es beschreibt einen Konikt, bei dem ein Name ein Oberbegri des zweiten Namens ist. Ein Beispiel ist in Abbildung 2.4 zu sehen. Der Tabellenname Fahrzeuge 5 schlieÿt die Intension und Extension des Tabellennamens Autos mit ein. In der Realität treten auch Mischungen dieser Arten auf. 5 Eigentlich: XY_FAHRZEUGE 10

25 2.2 Anforderungen an die Datenmigration Quelldatenbank Personen Auftraege Zieldatenbank XY_PERSONEN XY_AUFTRAEGE Tabellen Zu geringe Ähnlichkeit manuelle Zuordnung Autos AutoId Name PS Kaufdatum Tueren XY_FAHRZEUGE FZG_ID FZG_NAME FZG_PS FZG_DATUM FZG_TUEREN FZG_TYP Fremdschlüssel Spalten Konstante: 1 XY_FZG_TYPEN FZT_ID FZT_NAME 1 Auto 2 LKW Abbildung 2.4: Beispiel: Zuordnung von Tabellen und Spalten Die häugsten semantischen Konikte bei einer Datenmigration sind Synonyme. Namen von Tabellen werden oft aus technischen Gründen oder wegen einer Namenskonvention anders benannt. Die Reihenfolge der Spalten unterscheidet sich ebenfalls häug. Die Übergänge zwischen struktureller und semantischer Heterogenität sind ieÿend. Daher kann nicht immer genau unterschieden werden, ob die vorliegende Dierenz von semantischer oder struktureller Natur ist. Um ein sinnvolles Ergebnis bei der Übertragung von Daten zu erreichen, ist es nötig, dass die Unterschiede zwischen den Schemata der Datenbanken nicht zu groÿ sind Zuordnung von Tabellen und Spalten Der intuitive Ansatz zur Überwindung der entstandenen Heterogenität ist eine Zuordnung der Schemaelemente. Im Folgenden soll anhand von Beispielen gezeigt werden, warum diese Zuordnungen nötig sind. Die Zuordnung von Tabellen- und Spalten aus Quell- und Zieldatenbank ist deshalb eine zentrale Aufgabe der Datenmigration. Hierbei muss der Anwender der Software jederzeit die volle Kontrolle über die Zuordnung haben. Ähnlichkeiten zwischen den 11

26 2 Anforderungen Namen der Tabellen und Spalten sollte die Software jedoch automatisch erkennen. Die Abbildung 2.4 zeigt eine direkte Zuordnung von Tabellen und den enthaltenen Spalten. Ähnlichkeiten zwischen den Namen der Elemente sind hervorgehoben dargestellt (fett gedruckte Buchstaben) Ernden von Werten Aufgrund einer unterschiedlichen Struktur der Schemata ist eine direkte Zuordnung der Spalten nicht immer möglich. Kann eine Spalte aus der Zieldatenbank keiner Spalte in der Quelldatenbank zugeordnet werden, ist es notwendig, den Inhalt für diese Spalte festzulegen. Dies gilt vor allem für Spalten, die nicht leer gelassen werden dürfen (not nullable 6 ). Die einfachste Möglichkeit ist das Einfügen eines konstanten Werts wie in Abbildung 2.4 dargestellt. Der Typ des Fahrzeuges wird statisch angegeben. In diesem Beispiel wird ein weiteres Problem sichtbar: Angenommen, es gibt eine weitere Tabelle in der Quelldatenbank, die Fahrzeuge enthält, z. B. LKWs. Diese soll ebenfalls in die XY_FAHRZEUGE-Tabelle der Zieldatenbank übertragen werden. Dazu wird die LkwId (Primärschlüssel von LKWs) der Spalte FZG_ID zugeordnet. Beim Übertragen der Daten kann es vorkommen, dass die Werte der Spalte FZG_ID nicht mehr eindeutig sind. Dies liegt daran, dass die Menge der Werte aus Auto- Id und LkwId überlappen können. Weil FZG_ID der Primärschlüssel der Tabelle XY_FAHRZEUGE ist, führt dies zu einem Fehler. Dieses Problem lässt sich jedoch bedingt lösen. Vorausgesetzt, FZG_ID wird nicht als Fremdschlüssel in einer anderen Tabelle genutzt, können neue, eindeutige Werte erzeugt werden. Hierbei handelt es sich um eine Generalisierung 7 der Tabelle: Mehrere Tabellen der Quelldatenbank werden zu einer Tabelle in der Zieldatenbank zusammengefasst Komplexe Zuordnungen Wenn sich zwei Schemata unterscheiden, ist es möglich, dass eine Zuordnung von Tabellen zwischen den Datenbanken nicht direkt angegeben werden kann. Abbildung 2.5 zeigt zwei Schemata, die sich strukturell unterscheiden. Anders als im vorherigen Beispiel lässt sich diese Zuordnung nicht mit einem konstanten Wert lösen. Das liegt daran, dass die Daten der Quelldatenbank übernommen werden müssen. Das folgende Beispiel soll diese Problematik verdeutlichen. Beispiel: Angenommen eine Firma produziert Reinigungs- und Kosmetikartikel. Bei der Modellierung der Datenbank wurde festgelegt, dass ein Produkt immer genau von einem Typ sein kann. Die Typen sind in Klassen unterteilt (Abbildung 2.5 linker Teil). 6 Als not nullable bezeichnet man Spalten, die ausgefüllt werden müssen, daher keinen NULL-Wert enthalten dürfen. 7 Verallgemeinerung 12

27 2.3 Anforderungen an Testdaten Quelldatenbank Zieldatenbank Klassen KlasseId Name Beschreibung XY_TYPEN (DBMT_TEST) TYP_ID TYP_NAME TYP_BESCHREIBUNG XY_KLASSEN (DBMT_TEST) KLA_ID KLA_NAME KLA_BESCHREIBUNG Typen TypId Name Beschreibung KlasseId Produkte ProduktId Name ErstellDatum TypId PROD_XTN_FK XY_PRODUKTE (DBMT_TEST) PRO_TYP_ID PROD_XKN_FK PRO_ID PRO_NAME PRO_BESCHREIBUNG PRO_DATUM PRO_KLA_ID Abbildung 2.5: Gegenüberstellung zweier ähnlicher Schemata mit unterschiedlichen Beziehungen Diese Einteilung hat sich in der Praxis aufgrund der Inexibilität nicht bewährt. Die Firma produziert auch Produkte, deren Typ zwar gleich ist, die jedoch in einer anderen Klasse geführt werden sollen. Ein Beispiel hierfür ist Shampoo. Neben Produkten für die Reinigung (z. B. Teppichshampoo) gibt es auch Produkte für die Körperpege (Haarshampoo). Aus diesem Grund wurde das Schema der neuen Datenbank geändert (Abbildung 2.5 rechter Teil). In Abbildung 2.6 ist diese Situation in der Datenansicht dargestellt Datentypen Verschiedene Datenbanksysteme nutzen unterschiedliche Datentypen. Datenbanken für Endbenutzer, wie Microsoft Access, haben viele, sehr spezielle Datentypen, wie beispielsweise Hyperlink. Beim Übertragen solcher Daten kann es zum Verlust von Informationen kommen. Da bei der Migration möglichst wenige Informationen verloren gehen sollten, ist es notwendig, diese Daten zu konvertieren. Unterschiedliche Datentypen in den Datenbankprodukten sind ein Beispiel für syntaktische Heterogenität. 2.3 Anforderungen an Testdaten Das Testen von Anwendungen ist eine der wichtigsten Maÿnahmen, um qualitativ hochwertige Software zu schreiben. Um datenbankgestützte Anwendungen testen zu können, ist es notwendig, dass die Datenbank Daten enthält. 13

28 2 Anforderungen Quelldatenbank Klassen KlasseId Name... 1 Reinigung 2 Körperpflege 3 Kosmetik Typen TypId Name KlassseId 101 Waschmittel Shampoo Haargel 3 1:1 Zieldatenbank XY_KLASSEN KLA_ID KLA_NAME 1 Reinigung 2 Körperpflege 3 Kosmetik XY_TYPEN TYP_ID TYP_NAME 101 Waschmittel 102 Shampoo 103 Haargel Neuer Datensatz, nach der Übertragung eingefügt Produkte PId 1 Name TypId 1002 Shockwave Ultra XL Weisser XY_PRODUKTE 2 ID NAME TYP_ID KLASSE_ID 1002 Sho Ult Weis K ProduktId 2 Tabellen Präfix PRO_ aus Platzgründen entfernt Beziehungen innerhalb des Schema Abbildung 2.6: Beispielhafte Darstellung einer nicht trivialen Zuordnung (Datensicht) Stehen einem Entwickler nur sehr wenige oder gar keine nutzbaren Daten zur Verfügung, müssen diese erzeugt werden. Der einfachste Ansatz ist das manuelle Eintragen der Daten mit Hilfe eines allgemeinen Datenbankwerkzeugs. Eine Schwierigkeit beim manuellen Eintragen von Daten sind Beziehungen. Damit die Testdaten einer gewissen Integrität entsprechen, müssen die Beziehungen eingehalten werden. Deshalb muss der Entwickler Werte aus der verknüpften Tabelle auslesen und in die aktuelle Tabelle eintragen. Dieser Prozess lässt sich mit normalem SQL nicht zufriedenstellend automatisieren. Ebenso wichtig, wie die Beziehungen, sind fortlaufende, eindeutige Nummerierungen von Elementen. Viele Datenbanken bieten zwar eine Generierung solcher Werte an, dies muss jedoch im Schema der Datenbank deniert werden. Die Funktion kann daher nur genutzt werden, wenn die Generierung auch im produktiven Betrieb erwünscht ist. Soll die Geschwindigkeit einer Anwendung beim Umgang mit vielen Datensätzen getestet werden, so ist es faktisch unmöglich, all diese Datensätze von Hand einzutragen. Bei 14

29 2.3 Anforderungen an Testdaten solchen Tests ist der Inhalt einzelner Spalten, wie z. B. Namen, weniger von Bedeutung. Wichtig sind vor allem korrekte Beziehungen zwischen den Daten. Um Testdaten zu erzeugen, müssen Datenquellen existieren. Diese können beispielsweise über einen Generator erzeugt werden oder in einer Datei hinterlegt sein. 15

30 3 Analyse bestehender Lösungsansätze In diesem Kapitel werden relevante theoretische Ansätze und Produkte, die zur Problemlösung beitragen könnten, betrachtet. 3.1 Theoretische Ansätze In diesem Abschnitt werden Techniken aus Wissenschaft und Forschung vorgestellt. Hierbei wird untersucht, welche Ansätze sich für die Datenmigration eignen. Viele dieser Techniken stammen aus dem Gebiet der Informationsintegration Dynamische Schemaevolution Schemaevolution ist die wissenschaftliche Bezeichnung eines Gebietes, das sich mit Voraussetzungen, Auswirkungen und Durchführbarkeit bei Änderungen an bestehenden Datenbank-Schemata beschäftigt. Datenbankhersteller wie IBM und Oracle haben inzwischen diesen Bedarf erkannt und bieten dem Kunden bedienbare Werkzeuge an [Geb05]. Obwohl die dynamische Schemaevolution ein interessanter Ansatz ist, kann sie das Problem, welches durch die Neuentwicklung eines bereits im produktiven Einsatz be- ndlichen Systems entsteht, nicht lösen. Vor allem deshalb nicht, weil bei der Neuentwicklung selten das gleiche Datenbankprodukt zum Einsatz kommt (bspw. Oracle statt Microsoft Access). Des Weiteren sind die Änderungen am Schema durch das bisherige Softwaresystem beschränkt. Bestimmte Änderungen können zum Verlust der Funktionsfähigkeit des Systems führen. Das in Abschnitt 1.1 beschriebene Szenario kann durchaus als eine Art Schemaevolution betrachtet werden. Jedoch nicht als dynamische Schemaevolution Schemaintegration Die Schemaintegration beschreibt das Zusammenfügen von Informationen aus mehreren Schemata. Meist wird von verschiedenen Quellschemata in ein globales Schema integriert. 16

31 3.1 Theoretische Ansätze Man unterscheidet generell zwei Arten der Schemaintegration. Werden die Daten tatsächlich in eine Datenbank übertragen, spricht man von der materialisierten Integration. Sind die Daten hingegen nur bei Abruf kombiniert, handelt es sich um eine virtuelle Integration. Die materialisierte Integration bildet die Grundlage für sogenannte Data Warehouses 1. Die Datenmigration kann nicht als Schemaintegration betrachtet werden. Trotzdem gibt es einige Überschneidungen mit diesem Thema. Die Schemaintegration nutzt beispielsweise ebenfalls Techniken wie Schema Mapping und Schema Matching Schema Mapping Einige der Eigenschaften und Probleme von Schema Mapping wurden schon in den Anforderungen dargestellt (Abschnitt 2.2.4). Die folgende Betrachtung ist jedoch formaler und stützt sich auf die Arbeiten in [LN07a]. Das Schema Mapping beschränkt sich nicht auf ein bestimmtes Datenmodell. Diese Beschreibung geht jedoch von relationalen Datenbanken als Quelle und Ziel der Daten aus. Der Begri Schema Mapping (oder Schema-Abbildung) beschreibt im Prinzip zwei Dinge. Zunächst versteht man unter Schema Mapping eine Menge von Korrespondenzen zwischen Schemaelementen. Auÿerdem wird damit auch ein komplexer Prozess beschrieben. Dieser Prozess erzeugt, ausgehend von den Korrespondenzen, Vorschriften zur Datentransformation. Wertkorrespondenzen Wertkorrespondenzen sind die wesentlichen Elemente des Schema Mapping. Eine Wertkorrespondenz gibt an, wie Werte einer oder mehrer Zielspalten aus einer oder mehreren Quellspalten erzeugt werden. Als einfache Korrespondenzen bezeichnet man solche, die eine Spalte genau einer anderen Spalte zuweisen. Somit werden die Daten aus der einen Spalte in die andere übertragen (1:1). Bei mehrwertigen Korrespondenzen werden mehrere Spalten genau einer Spalte zugeordnet (N:1). Oder in umgekehrter Reihenfolge: Eine Spalte wird mehreren anderen Spalten zugeordnet (1:N). Die Aufteilung bzw. Vereinigung übernimmt eine Funktion. Bei Nachname Vorname Nachname Name concat() extract() Name Name Vorname Nachname Abbildung 3.1: Mehrwertige Korrespondenzen (1:1, N:1, 1:N) 1:N Korrespondenzen bildet diese Funktion die Werte der einen Spalte auf mehrere Werte der zugeordneten Spalten ab. Abbildung 3.1 zeigt ein simples Beispiel mit dem Namen einer Person. In Abbildung 3.2 (links) wird das Geschlecht einer Person durch die Tabellennamen Frauen und Männer angegeben. Die Tabelle Personen hingegen gibt das Ge- 1 Zentrale Sammlung von Daten die meist aus unterschiedlichen Quellen zusammengesetzt sind. 17

32 3 Analyse bestehender Lösungsansätze Frauen 'w' name adresse 'm' Männer name adresse Personen name adresse geschlecht Personen name adresse geschlecht = 'w' = 'm' Frauen name adresse Männer name adresse Abbildung 3.2: Höherstuge Korrespondenzen (gestrichelt); Quelle: [LN07a] schlecht über die Spalte geschlecht an. Derselbe Sachverhalt wird hier mit verschiedenen Elementen des Datenmodells dargestellt (Tabellenname vs. Wert einer Spalte). Die gestrichelten Pfeile symbolisieren eine höherstuge Wertkorrespondenz. Der rechte Teil der Abbildung zeigt genau das Gegenteil. Hier werden aus der Information der Spalte geschlecht die Daten jeweils in Frauen und Männer aufgeteilt. Die höherstugen Wertkorrespondenzen können zur Überwindung der hier beschriebenen, schematischen Heterogenität eingesetzt werden (siehe Abschnitt 2.2.3). Logisches Mapping Im Schema Mapping Prozess wird durch Interpretation aus den Wertkorrespondenzen ein logisches Mapping erzeugt. Aus diesem können die Datenbankanfragen generiert werden. Die Interpretation der Korrespondenzen ist dabei nicht immer eindeutig. Je nach Algorithmus unterscheidet sich diese. Wie in den Anforderungen (Abschnitt 2.2) bereits angedeutet, ist eine Form des Schema Mapping für die entstehende Softwarelösung nötig Schema Matching Das Schema Matching beschäftigt sich mit der automatischen Zuordnung von Elementen verschiedener Schemata. Dabei geht es um das Erkennen von Ähnlichkeiten zwischen Schemata. Diese Erkenntnisse werden herangezogen um eine (vorläuge) Zuordnung zu erzeugen. Das Aunden von Ähnlichkeiten zwischen zwei Schemata kann basieren auf: Namen der Schemaelemente (label-based) In der Datenbank eingetragene Daten (instance-based) Struktur des Schemas (structure-based) Mischformen 18

33 3.1 Theoretische Ansätze Allgemeiner Algorithmus ([Nau06a]) Gegeben sind zwei Schemata (oder Tabellen) mit den Mengen der Tabellen (bzw. Spalten) A und B Kernidee: Bilde Kreuzprodukt aller Attribute a aus A und B Für jedes Paar berechne Ähnlichkeit z. B. bzgl. Attributnamen z. B. bzgl. gespeicherter Daten Wähle ein Matching aus Ähnlichste Paare bis Schwellwert Nebenbedingungen a Hierbei sind sowohl Tabellen, als auch Spalten gemeint. Je nachdem ob zwei Schemata oder zwei Tabellen verglichen werden. Schema Matching Ansätze Individuelle Ansätze Kombinierte Ansätze Schema-basiert Instanz-basiert Hybrid Zusammengesetzt Namen (Linguistisch) Inhalt (Linguistisch) Strukturbasiert Duplikatbasiert Manuell Automatisch Struktur-basiert Abbildung 3.3: Schema Matching Klassikation nach [RB01] In Abbildung 3.3 ist eine allgemeine Klassikation dargestellt. Die gelb hervorgehobenen Elemente sind relevant für die Datenmigration. Neben dem Vergleich von Namen der Schemaelemente (wie Tabelle- und Spalte) ist es ebenso sinnvoll, die Struktur des Schemas mit zu berücksichtigen. Hierzu zählen auÿer Datentypen auch weitere Eigenschaften (Constraints) der Spalten, wie Fremd- und Primärschlüssel. Da das Zielschema in der Regel keine Daten enthält, ist ein instanzbasierter Vergleich schlicht unmöglich SchemaSQL Bei SchemaSQL handelt es sich um eine Erweiterung von SQL. Während SQL nur die Abfrage von Daten erlaubt, ist mit SchemaSQL auch der Zugri auf Metadaten 19

34 3 Analyse bestehender Lösungsansätze möglich. Des Weiteren kann die Sprache auf mehreren Datenbanken agieren, daher gehört sie zur Gattung der Multidatenbanksprachen. Es wird nur der lesende Zugri unterstützt. Aufgrund der Eigenschaften von SchemaSQL kann es zur Überwindung schematischer Heterogenität genutzt werden. Laut [Mau05] existiert keine fertig gestellte Implementierung von SchemaSQL. In diesem Dokument nden sich auch Beispiele, die die Verwendung von SchemaSQL erklären. 3.2 Produkte Das Prüfen der am Markt bendlichen Produkte ist notwendig, um zu verhindern, dass eine Anwendung entsteht, die es in dieser Form bereits gibt. Die Analyse soll ebenso zeigen, welche Ansätze zur Datenmigration und Testdatenerzeugung bereits umgesetzt wurden. Aufgrund der Fülle von Anwendungen werden hier nur einige Produkte vorgestellt. Im Folgenden wird analysiert, in wie weit sich diese Lösungen für die Datenmigration, wie in Kapitel 2 (Abschnitt 2.2) beschrieben, eignen Oracle SQL Developer (Version 1.5.1) Beim Oracle SQL Developer handelt es sich um ein universelles Werkzeug zur Abfrage und Verwaltung von Datenbanken. Neben Oracles eigenen Datenbanksystemen werden auch andere Produkte wie Microsoft Access oder MySQL unterstützt. Die Hauptfunktionen sind jedoch für Oracle und deren Technologien (z. B. PL/SQL) ausgelegt. Abbildung 3.4: SQL Developer MS Access Export Der SQL Developer enthält eine Migrationsunterstützung, welche die Aufgaben des inzwischen nicht mehr weiterentwickelten Oracle Migration Workbench ersetzt. Diese Migration bietet eine vollständige Übertragung von Schema und Daten. Da MS Access per JDBC-ODBC nur begrenzt Zugri auf Metadaten liefert (der SQL Developer nutzt JDBC), wird der Export aus Access mit Hilfe eines VBA 2 -Makros realisiert. Dieses erzeugt eine XML Datei, die Schema und Daten enthält. Der SQL Developer kann diese Datei in eine Oracle Datenbank umwandeln. Dieser Ansatz zur Migration ist nur für eine initiale Migration sinnvoll. Eine Datenmigration im Sinne der Anforderungen lässt sich mit dem SQL Developer nicht durchführen. 2 Visual Basic for Applications; Skriptsprache von Microsoft für Anwendungen 20

35 3.2 Produkte Abbildung 3.5: Oracle SQL Developer Startbildschirm IBM Clio Clio ist ein Forschungsprojekt des IBM Almaden Research Center und der University of Toronto - Department of Computer Science. Leider lässt sich die Software nicht einfach herunterladen und testen. Verfügbare Informationen ([IBM, LN07a, Nau06b]) zeigen jedoch, dass dieses Projekt über die im Rahmen dieser Bachelorarbeit beschriebene Problematik hinausgeht. Es werden beispielsweise auch XML Schemata unterstützt. Clio stellt ein universelles Zuordnungs- und Transformationswerkzeug dar. Über die Unterstützung von Datenbankprodukten ist wenig bekannt, sicher ist jedoch, dass DB2 von IBM unterstützt wird. Regeln für die Zuordnung werden in einem proprietären Format angegeben und später in eines der Ausgabeformate XSL, XQuery oder SQL umgewandelt. Die Schema Matching Fähigkeiten von Clio setzen primär einen instanzbasierten Vergleich ein. Dieser ist jedoch für die Datenmigration völlig ungeeignet. 21

36 3 Analyse bestehender Lösungsansätze Altova MapForce (Enterprise 2009) Altova MapForce Enterprise 2009 ist ein kommerzielles Produkt der Firma Altova. MapForce bietet eine sehr übersichtliche und leicht verständliche Oberäche. Der Zugri auf Datenbanken erfolgt über ODBC. Die Software eignet sich besonders gut, um Zuordnungen zwischen zwei oder mehreren Datenbanken (oder XML Daten) herzustellen. Eine Zuordnung der Elemente (Schema Matching) anhand ihres Namens ist möglich, jedoch nur auf Spaltenebene. Ebenso beschränkt sich diese Zuordnung auf identische Namen; eine Ähnlichkeitsanalyse ndet nicht statt. Abbildung 3.7: Altova MapForce Screenshot; Quelle: Altova Webseite Zusammenfassung Diese Produkte zeigen interessante Ansätze. Neben den ausgefeilten Oberächen sind auch weitere Datenquellen wie XML oder Microsoft Excel möglich. Trotzdem wird keines der untersuchten Produkte den Anforderungen aus Kapitel 2 gerecht. Einige der genannten Aufgaben können mit dem ein oder anderen Programm erfüllt werden. Dennoch kann, gerade im Bezug auf die automatische Zuordnung von Schemaelementen, keines der Produkte überzeugen. Auch das Erzeugen von Testdaten wird nicht unterstützt. 22

37 3.2 Produkte Abbildung 3.6: IBM Clio; Quelle: [IBM] 23

38 4 Ansatz Dieses Kapitel beschreibt den Lösungsansatz für die in Kapitel 2 dargelegten Probleme und Anforderungen. Die im Rahmen dieser Bachelorarbeit entstandene prototypische Softwarelösung deckt die Bereiche der Datenmigration und Testdatenerzeugung ab. Die Übertragung der Daten wird direkt ausgeführt. Auf eine Ausgabe von Transformationsregeln in Sprachen wie SQL wird verzichtet. Es wird zwischen den zwei Projekttypen Migration und Testdaten unterschieden. Daten in der Datenbank Für beide Projekttypen ist es notwendig, dass die Zieldatenbank völlig leer ist. Deshalb muss die Anwendung alle vorhandenen Inhalte aus der Datenbank löschen. Dieser Vorgang ist nur dann erfolgreich, wenn die Reihenfolge der Löschung den referentiellen Integritätsbedingungen nicht widerspricht. Auch für das Eintragen von Daten muss die Reihenfolge stets beachtet werden. Die genaue Problematik und deren Lösung wird in Kapitel 6 erklärt. 4.1 Voraussetzungen für eine Datenmigration Es wird nur eine Datenmigration mit genau einer Quell- sowie genau einer Zieldatenbank unterstützt. Ebenso müssen die Datentypen von Quell- und Zielspalte kompatibel sein. Vor allem darf der Datentyp der Zielspalte keine stärkeren Einschränkungen hinsichtlich der Länge haben, als die Quellspalte erlaubt. Die Umsetzung der Konvertierung von Datentypen ist in Kapitel 6 (Abschnitt 6.4) erklärt. 4.2 Schema Zuordnung im Detail Das Zuordnen von Elementen der Schemata ist nötig, um strukturelle und semantische Heterogenität zu überwinden. Anders als es im Schema Mapping (Abschnitt 3.1.3) erklärt ist, nutzt dieser Ansatz keine Denition von Korrespondenzen, sondern ermöglicht es, direkt ein logisches Mapping vorzunehmen. Der Vorteil dabei ist, dass die komplexe Interpretation der Korrespondenzen entfällt. Der folgende praktische Ansatz kann nur einen Teil aller denkbarer Unterschiede überbrücken. Im weiteren Verlauf dieser Arbeit wird dargestellt, welche Einschränkungen durch den Ansatz bzw. die Implementierung bestehen. 24

SQL structured query language

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

Mehr

Einführung in SQL Datenbanken bearbeiten

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

Mehr

Relationale Datenbanken Kursziele

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

Mehr

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

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

Mehr

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

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

Mehr

Relationale Datenbanken Datenbankgrundlagen

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

Mehr

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

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

Mehr

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

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

Mehr

2 7 Erweiterungen. 7.1 Prozess-Kommunikation mit Datenbanken

2 7 Erweiterungen. 7.1 Prozess-Kommunikation mit Datenbanken 2 7 Erweiterungen 7 Erweiterungen 7.1 Prozess-Kommunikation mit Datenbanken Im Buch Einstieg in das Programmieren mit MATLAB wird im Abschnitt 4.8 das Thema Prozess-Kommunikation am Beispiel von MS-Excel

Mehr

Relationale Datenbanken in der Praxis

Relationale Datenbanken in der Praxis Seite 1 Relationale Datenbanken in der Praxis Inhaltsverzeichnis 1 Datenbank-Design...2 1.1 Entwurf...2 1.2 Beschreibung der Realität...2 1.3 Enitiy-Relationship-Modell (ERM)...3 1.4 Schlüssel...4 1.5

Mehr

Gliederung und Einordnung

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

Mehr

DATENBANKEN SQL UND SQLITE VON MELANIE SCHLIEBENER

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

Mehr

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

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

Mehr

1 Grundbegriffe...1. 2 Datenbanksysteme...7. 3 Entwicklung von Datenbanksystemen...15. Inhaltsverzeichnis. 1.1 Information und Daten...

1 Grundbegriffe...1. 2 Datenbanksysteme...7. 3 Entwicklung von Datenbanksystemen...15. Inhaltsverzeichnis. 1.1 Information und Daten... Inhaltsverzeichnis 1 Grundbegriffe...1 1.1 Information und Daten...2 1.2 Datenorganisation...3 1.3 Dateikonzept...5 1.4 Kontroll- und Vertiefungsfragen...6 2 Datenbanksysteme...7 2.1 Datenintegration...7

Mehr

Software-Engineering Einführung

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

Mehr

Fundamentals of Software Engineering 1

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

Mehr

ARIS II - Modellierungsmethoden, Metamodelle und Anwendungen

ARIS II - Modellierungsmethoden, Metamodelle und Anwendungen ARIS II - Modellierungsmethoden, Metamodelle und Anwendungen C3: Structured Query Language Lernziele: Nach der Bearbeitung dieser Lektion haben Sie folgende Kenntnisse erworben: Sie können elementaren

Mehr

Technische Beschreibung: EPOD Server

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

Mehr

Vorlesung. Informationssysteme. Prof. Dr. Hans Czap. Lehrstuhl für Wirtschaftsinformatik I. Email: Hans.Czap@uni-trier.de

Vorlesung. Informationssysteme. Prof. Dr. Hans Czap. Lehrstuhl für Wirtschaftsinformatik I. Email: Hans.Czap@uni-trier.de Vorlesung Grundlagen betrieblicher Informationssysteme Prof. Dr. Hans Czap Email: Hans.Czap@uni-trier.de - II - 1 - Inhalt Kap. 1 Ziele der Datenbanktheorie Kap. 2 Datenmodellierung und Datenbankentwurf

Mehr

Carl-Engler-Schule Karlsruhe Datenbank 1 (5)

Carl-Engler-Schule Karlsruhe Datenbank 1 (5) Carl-Engler-Schule Karlsruhe Datenbank 1 (5) Informationen zur Datenbank 1. Definition 1.1 Datenbank-Basis Eine Datenbank-Basis ist eine Sammlung von Informationen über Objekte (z.b Musikstücke, Einwohner,

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

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

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

Mehr

Informationsintegration

Informationsintegration Informationsintegration Grundlegende Architekturen Ulf Leser Inhalt diese Vorlesung Klassifikation verteilter, autonomer, heterogener Systeme Weitere Klassifikationskriterien Schichtenaufbau integrierter

Mehr

Verschiedene Arten des Datenbankeinsatzes

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

Mehr

Datenmodellierung und Datenbanksysteme. Vorlesung. Informationswissenschaft und Informationssysteme. Hans Uszkoreit & Brigi1e Jörg

Datenmodellierung und Datenbanksysteme. Vorlesung. Informationswissenschaft und Informationssysteme. Hans Uszkoreit & Brigi1e Jörg Vorlesung Informationswissenschaft und Informationssysteme Hans Uszkoreit & Brigi1e Jörg Definitionen Data modeling in software engineering is the process of creating a data model by applying formal data

Mehr

Einführung in die Informatik II

Einführung in die Informatik II Einführung in die Informatik II Die Structured Query Language SQL Prof. Dr. Nikolaus Wulff SQL Das E/R-Modell lässt sich eins zu eins auf ein Tabellenschema abbilden. Benötigt wird eine Syntax, um Tabellen

Mehr

Prüfungsberatungs-Stunde Datenbanksysteme 1 (Dbs1)

Prüfungsberatungs-Stunde Datenbanksysteme 1 (Dbs1) Prüfungsberatungs-Stunde Datenbanksysteme 1 (Dbs1) Herbstsemester 2013/14 Prof. S. Keller Informatik HSR Januar 2014, HS13/14 Dbs1 - Prüfungsvorbereitung 1 Dbs1 Ziele Grundlagenwissen in folgenden Gebieten

Mehr

Architekturen. Von der DB basierten zur Multi-Tier Anwendung. DB/CRM (C) J.M.Joller 2002 131

Architekturen. Von der DB basierten zur Multi-Tier Anwendung. DB/CRM (C) J.M.Joller 2002 131 Architekturen Von der DB basierten zur Multi-Tier Anwendung DB/CRM (C) J.M.Joller 2002 131 Lernziele Sie kennen Design und Architektur Patterns, welche beim Datenbankzugriff in verteilten Systemen verwendet

Mehr

SQL (Structured Query Language) Schemata Datentypen

SQL (Structured Query Language) Schemata Datentypen 2 SQL Sprachelemente Grundlegende Sprachelemente von SQL. 2.1 Übersicht Themen des Kapitels SQL Sprachelemente Themen des Kapitels SQL (Structured Query Language) Schemata Datentypen Im Kapitel SQL Sprachelemente

Mehr

Eine weitere Möglichkeit "die grosse weite Welt" zu erschliessen sind ODBC/JDBC bzw. ESS Verbindungen.

Eine weitere Möglichkeit die grosse weite Welt zu erschliessen sind ODBC/JDBC bzw. ESS Verbindungen. Database Designs Alexis Gehrt / alexis@database-designs.ch - Erster Kontakt mit FileMaker ca. 1991 ( Version 2, 2.1) - Jan 2000 - Database Designs - Seit 2007 bei einem Kunden (Linden-Grafik AG) angestellt

Mehr

Business Intelligence Praktikum 1

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

Mehr

Business Intelligence Praktikum 1

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

Mehr

Entwurf einer einfachen Datenbank zur Wunschzettel- Verwaltung

Entwurf einer einfachen Datenbank zur Wunschzettel- Verwaltung Entwurf einer einfachen Datenbank zur Wunschzettel- Verwaltung Prof. Dr. Alfred Holl, Georg Simon Ohm University of Applied Sciences, Nuremberg, Germany 29.03.2014/1 Entwurf einer einfachen Datenbank zur

Mehr

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

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

Mehr

Integrated Data Management Konzentrieren sie sich auf ihr Business, und nicht auf die Verwaltung ihrer Daten

Integrated Data Management Konzentrieren sie sich auf ihr Business, und nicht auf die Verwaltung ihrer Daten Integrated Data Management Konzentrieren sie sich auf ihr Business, und nicht auf die Verwaltung ihrer Daten Entwurf Data Architect Verwaltung und Umsetzung komplexer Datenmodelle Graphische Darstellung

Mehr

EDV-GESTÜTZTES ENTWERFEN, BERECHNEN UND KONSTRUIEREN IM BAUINGENIEURWESEN Prof. Dr.-Ing. Klaus Wassermann MODULPRÜFUNG

EDV-GESTÜTZTES ENTWERFEN, BERECHNEN UND KONSTRUIEREN IM BAUINGENIEURWESEN Prof. Dr.-Ing. Klaus Wassermann MODULPRÜFUNG EDV-GESTÜTZTES ENTWERFEN, BERECHNEN UND KONSTRUIEREN IM BAUINGENIEURWESEN Prof. Dr.-Ing. Klaus Wassermann MODULPRÜFUNG Bachelorstudiengang Facility Management Informatik am 26. September 2007 Name, Vorname

Mehr

Datenbanken: ER-Modell

Datenbanken: ER-Modell Beispiel: Lastenheft: Für eine Hochschule soll eine Verwaltungssoftware geschrieben werden, die alle relevanten Daten in einem relationalen Datenbanksystem speichert. Zu diesen Daten zählen die Stamm-

Mehr

TECHNISCHE UNIVERSITÄT DRESDEN Fakultät Wirtschaftswissenschaften Prof. Dr. W. Esswein Lehrstuhl Wirtschaftsinformatik, insbesondere Systementwicklung

TECHNISCHE UNIVERSITÄT DRESDEN Fakultät Wirtschaftswissenschaften Prof. Dr. W. Esswein Lehrstuhl Wirtschaftsinformatik, insbesondere Systementwicklung TECHNISCHE UNIVERSITÄT DRESDEN Fakultät Wirtschaftswissenschaften Prof. Dr. W. Esswein Lehrstuhl Wirtschaftsinformatik, insbesondere Systementwicklung Diplomprüfung Wintersemester 2010-2011 im Fach Wirtschaftsinformatik,

Mehr

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

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

Mehr

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

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

Mehr

Datenadminstrator, Datenbankdesigner, Systemanalytiker (für die logische Sicht zuständig)

Datenadminstrator, Datenbankdesigner, Systemanalytiker (für die logische Sicht zuständig) 1 Grundlagen Begriffe Daten bekannte zutreffende Tatsachen über die Domäne/Miniwelt DBS Einsatz eines DBMS für eine Datenbank, DBS besteht aus folgenden Komponenten: 1. DBMS 2. Datenbank DBMS Software

Mehr

Kapitel DB:III. III. Konzeptueller Datenbankentwurf

Kapitel DB:III. III. Konzeptueller Datenbankentwurf Kapitel DB:III III. Konzeptueller Datenbankentwurf Einführung in das Entity-Relationship-Modell ER-Konzepte und ihre Semantik Charakterisierung von Beziehungstypen Existenzabhängige Entity-Typen Abstraktionskonzepte

Mehr

Einführung Datenbank

Einführung Datenbank Einführung Datenbank Einführung Datenbank Seite 2 Einführung in die Arbeit mit einer Datenbank Grundbegriffe: Datenbank - Datenbankmanagementsystem Eine Datenbank ist eine systematische strukturierte Sammlung

Mehr

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

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

Mehr

SQL für Trolle. mag.e. Dienstag, 10.2.2009. Qt-Seminar

SQL für Trolle. mag.e. Dienstag, 10.2.2009. Qt-Seminar Qt-Seminar Dienstag, 10.2.2009 SQL ist......die Abkürzung für Structured Query Language (früher sequel für Structured English Query Language )...ein ISO und ANSI Standard (aktuell SQL:2008)...eine Befehls-

Mehr

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

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

Mehr

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

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

Mehr

SQL- & NoSQL-Datenbanken - Speichern und Analysen von großen Datenmengen

SQL- & NoSQL-Datenbanken - Speichern und Analysen von großen Datenmengen SQL- & NoSQL-Datenbanken - Speichern und Analysen von großen Datenmengen Lennart Leist Inhaltsverzeichnis 1 Einführung 2 1.1 Aufgaben einer Datenbank...................... 2 1.2 Geschichtliche Entwicklung

Mehr

Orientierte Modellierung mit der Unified Modeling Language

Orientierte Modellierung mit der Unified Modeling Language UML-Basics: Einführung in Objekt- Orientierte Modellierung mit der Unified Modeling Language Michael Hahsler Ziel dieses Seminars Verständnis von Objekt-Orientierung Was sind Klassen? Was ist Vererbung?

Mehr

IT-basierte Erstellung von Nachhaltigkeitsberichten. Diplomarbeit

IT-basierte Erstellung von Nachhaltigkeitsberichten. Diplomarbeit IT-basierte Erstellung von Nachhaltigkeitsberichten Diplomarbeit zur Erlangung des Grades eines Diplom-Ökonomen der Wirtschaftswissenschaftlichen Fakultät der Leibniz Universität Hannover vorgelegt von

Mehr

Relationale Datenbanken Kursziele

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

Mehr

Antwortzeitverhalten von Online Storage Services im Vergleich

Antwortzeitverhalten von Online Storage Services im Vergleich EPOD Encrypted Private Online Disc Antwortzeitverhalten von Online Storage Services im Vergleich Fördergeber Förderprogramm Fördernehmer Projektleitung Projekt Metadaten Internet Foundation Austria netidee

Mehr

Fachbereich Informatik Praktikum 1

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

Mehr

Die Analyse großer Datensätze mittels freier Datenbanksysteme Dr Dirk Meusel meusel@iat.uni-leipzig.de

Die Analyse großer Datensätze mittels freier Datenbanksysteme Dr Dirk Meusel meusel@iat.uni-leipzig.de Institut für Angewandte Trainingswissenschaft Leipzig ein Institut des Trägervereins IAT / FES des DOSB e.v. Die Analyse großer Datensätze mittels freier Datenbanksysteme Dr Dirk Meusel meusel@iat.uni-leipzig.de

Mehr

7 Projektarbeit Fahrradverleih

7 Projektarbeit Fahrradverleih Kapitel 7 Projekt Fahrradverleih Seite 1 7 Projektarbeit Fahrradverleih 7.1 Aufgabenstellung In einem Geschäft, das Fahrräder vermietet, sollen die Aktionen, die beim Verleih dieser Fahrräder ablaufen,

Mehr

Dataport IT Bildungs- und Beratungszentrum. HTML- Grundlagen und CSS... 2. XML Programmierung - Grundlagen... 3. PHP Programmierung - Grundlagen...

Dataport IT Bildungs- und Beratungszentrum. HTML- Grundlagen und CSS... 2. XML Programmierung - Grundlagen... 3. PHP Programmierung - Grundlagen... Inhalt HTML- Grundlagen und CSS... 2 XML Programmierung - Grundlagen... 3 PHP Programmierung - Grundlagen... 4 Java - Grundlagen... 5 Java Aufbau... 6 ASP.NET Programmierung - Grundlagen... 7 1 HTML- Grundlagen

Mehr

Softwaretool Data Delivery Designer

Softwaretool Data Delivery Designer Softwaretool Data Delivery Designer 1. Einführung 1.1 Ausgangslage In Unternehmen existieren verschiedene und häufig sehr heterogene Informationssysteme die durch unterschiedliche Softwarelösungen verwaltet

Mehr

Daten-Ex- und Import mit Oracle und PostgreSQL

Daten-Ex- und Import mit Oracle und PostgreSQL Daten-Ex- und Import mit Oracle und PostgreSQL Holger Jakobs bibjah@bg.bib.de 2004-09-07 Inhaltsverzeichnis 1 Grund für Daten-Im- und -Exporte 1 2 Werkzeuge 1 2.1 Export mit pg_dump von PostgreSQL.....................

Mehr

LISE MEITNER GYMNASIUM NEUENHAUS UELSEN

LISE MEITNER GYMNASIUM NEUENHAUS UELSEN Entwurf eines schulinternen Curriculums im Fach Informatik für die Qualifikationsphase (Jahrgang 11 und 12) Für die Gestaltung des Informatikunterrichts in der Qualifikationsphase sind für das schulinterne

Mehr

Integritätsbedingungen / Normalformen- Beispiel: Kontoführung

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

Mehr

DB2 SQL, der Systemkatalog & Aktive Datenbanken

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

Mehr

Einleitung. Literatur. Pierre Fierz. Architektur von Datenbanksystemen. Physische Datenunabhängigkeit. Der Datenbank Administrator (DBA) 1.

Einleitung. Literatur. Pierre Fierz. Architektur von Datenbanksystemen. Physische Datenunabhängigkeit. Der Datenbank Administrator (DBA) 1. Inhalt der Vorlesung Literatur 1 Datenmodellierung (Entity-Relationship Modell) 2 Das relationale Modell 3 Relationenalgebra 4 Datenbanksprache (SQL) 5 Normalisierung 6 Vom ERM zum Datenbankschema 7 Routinen

Mehr

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

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

Mehr

ER-Modellierung am Beispiel der Universitätsdatenbank aus der DBIS-Vorlesung

ER-Modellierung am Beispiel der Universitätsdatenbank aus der DBIS-Vorlesung ER-Modellierung am Beispiel der Universitätsdatenbank aus der DBIS-Vorlesung Datenbank-Praktikum SS 2010 Prof. Dr. Georg Lausen Florian Schmedding ER-Modell: Wiederholung Entitäten E Beziehungen B Attribute

Mehr

Liste der Handbücher. Liste der Benutzerhandbücher von MEGA

Liste der Handbücher. Liste der Benutzerhandbücher von MEGA Liste der Handbücher Liste der Benutzerhandbücher von MEGA MEGA 2009 SP4 1. Ausgabe (Juni 2010) Die in diesem Dokument enthaltenen Informationen können jederzeit ohne vorherige Ankündigung geändert werden

Mehr

Einführung in die Software-Umgebung

Einführung in die Software-Umgebung Ortsbezogene Anwendungen und Dienste WS2011/2012 Einführung in die Software-Umgebung Die Software-Umgebung Zentrale Postgres-Datenbank mit Geodaten von OpenStreetMap: Deutschland: 13 mio. Datensätze Topologie-Informationen

Mehr

PIWIN I. Praktische Informatik für Wirtschaftsmathematiker, Ingenieure und Naturwissenschaftler I. Vorlesung 3 SWS WS 2007/2008

PIWIN I. Praktische Informatik für Wirtschaftsmathematiker, Ingenieure und Naturwissenschaftler I. Vorlesung 3 SWS WS 2007/2008 PIWIN I Kap. 7 Objektorientierte Programmierung - Einführung 1 PIWIN I Praktische Informatik für Wirtschaftsmathematiker, Ingenieure und Naturwissenschaftler I Vorlesung 3 SWS WS 2007/2008 FB Informatik

Mehr

A Generic Database Web Service for the Venice Lightweight Service Grid

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

Mehr

GANTTCHART Generator. stallwanger IT.dev process and controlling controlling development implementation www.stallwanger.net info@stallwanger.

GANTTCHART Generator. stallwanger IT.dev process and controlling controlling development implementation www.stallwanger.net info@stallwanger. stallwanger IT.dev process and controlling controlling development implementation www.stallwanger.net info@stallwanger.net GANTTCHART Generator Copyright 2007 2012,. All rights reserved. Vorwort: Gantt

Mehr

3. Übung. Einführung MS Access. TU Dresden - Institut für Bauinformatik Folie-Nr.: 1

3. Übung. Einführung MS Access. TU Dresden - Institut für Bauinformatik Folie-Nr.: 1 WP3-13 Bauinformatik-Vertiefte Grundlagen 3. Übung Einführung MS Access Folie-Nr.: 1 Allgemeines Microsoft Access ist ein Datenbank-Management-System (DBMS) zur Verwaltung von Daten in Datenbanken und

Mehr

software TECHNISCHE KAUFLEUTE UND HWD

software TECHNISCHE KAUFLEUTE UND HWD software TECHNISCHE KAUFLEUTE UND HWD Was ist Software? Definition. Die Gesamtheit der auf einem Computer laufenden Programme mit den dazu gehörigen Daten nennt man S. Kernstücke von Programmen sind Algorithmen,

Mehr

Projektbericht Gruppe 12. Datenbanksysteme WS 05/ 06. Gruppe 12. Martin Tintel Tatjana Triebl. Seite 1 von 11

Projektbericht Gruppe 12. Datenbanksysteme WS 05/ 06. Gruppe 12. Martin Tintel Tatjana Triebl. Seite 1 von 11 Datenbanksysteme WS 05/ 06 Gruppe 12 Martin Tintel Tatjana Triebl Seite 1 von 11 Inhaltsverzeichnis Inhaltsverzeichnis... 2 1. Einleitung... 3 2. Datenbanken... 4 2.1. Oracle... 4 2.2. MySQL... 5 2.3 MS

Mehr

DBSP. Vorlesung. Prof. Dr. rer. nat. Nane Kratzke. Unit. Praktische Informatik und betriebliche Informationssysteme

DBSP. Vorlesung. Prof. Dr. rer. nat. Nane Kratzke. Unit. Praktische Informatik und betriebliche Informationssysteme Handout zur Vorlesung Vorlesung DBSP Unit Datenmodellierung 1 Prof. Dr. rer. nat. Nane Kratzke Praktische Informatik und betriebliche Informationssysteme Raum: 17-0.10 Tel.: 0451 300 5549 Email: kratzke@fh-luebeck.de

Mehr

Datenbanken und SQL. Kapitel 1. Übersicht über Datenbanken. Edwin Schicker: Datenbanken und SQL (1)

Datenbanken und SQL. Kapitel 1. Übersicht über Datenbanken. Edwin Schicker: Datenbanken und SQL (1) Datenbanken und SQL Kapitel 1 Übersicht über Datenbanken Übersicht über Datenbanken Vergleich: Datenorganisation versus Datenbank Definition einer Datenbank Bierdepot: Eine Mini-Beispiel-Datenbank Anforderungen

Mehr

Klausur Datenbanksysteme

Klausur Datenbanksysteme Prüfung Datenbanksysteme, 31.Jan. 2003 S. 1 Klausur Datenbanksysteme Name: Matrikel-Nr.: Studiengang: Aufgabenblatt nicht vor Beginn der Prüfung umdrehen! Prüfer: Prof. Dr. Martin Hulin Dauer: 90 Minuten

Mehr

Einstieg in relationale Datenbanken mit MySQL. Dr. Kerstin Puschke September 2009

Einstieg in relationale Datenbanken mit MySQL. Dr. Kerstin Puschke September 2009 Einstieg in relationale Datenbanken mit MySQL Dr. Kerstin Puschke September 2009 1 Lizenz Lizenz Dieser Text steht unter einer Creative Commons Attribution-Share Alike 3.0 Germany Lizenz, siehe http://creativecommons.org/licenses/by-sa/3.0/de/

Mehr

Definition Informationssystem

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

Mehr

Berichte aus der Medizinischen Informatik und Bioinformatik. Günther Schadow. Krankenhauskommunikation mit HL7

Berichte aus der Medizinischen Informatik und Bioinformatik. Günther Schadow. Krankenhauskommunikation mit HL7 Berichte aus der Medizinischen Informatik und Bioinformatik Günther Schadow Krankenhauskommunikation mit HL7 Analyse, Implementation und Anwendungeines Protokollstandards für medizinische Datenkommunikation

Mehr

CARL HANSER VERLAG. Christopher Allen. Oracle PL/SQL für Einsteiger Der Einsatz von SQL und PL/SQL in der Oracle-Datenbank 3-446-21801-7

CARL HANSER VERLAG. Christopher Allen. Oracle PL/SQL für Einsteiger Der Einsatz von SQL und PL/SQL in der Oracle-Datenbank 3-446-21801-7 CARL HANSER VERLAG Christopher Allen Oracle PL/SQL für Einsteiger Der Einsatz von SQL und PL/SQL in der Oracle-Datenbank 3-446-21801-7 www.hanser.de Inhaltsverzeichnis Danksagung...XI Einleitung...XIII

Mehr

Manual zur Excel-Oracle Schnittstelle (Version 4.2.2008, Peter Jakob, Peter Waldner)

Manual zur Excel-Oracle Schnittstelle (Version 4.2.2008, Peter Jakob, Peter Waldner) Manual zur Excel-Oracle Schnittstelle (Version 4.2.2008, Peter Jakob, Peter Waldner) 1. Funktion der Schnittstelle Diese Schnittstelle ermöglicht das Transferieren von Daten aus einem Excel-Datenblatt

Mehr

Werkstudent Qualitätssicherung (m/w) (627468)

Werkstudent Qualitätssicherung (m/w) (627468) Werkstudent Qualitätssicherung (m/w) (627468) Kennwort: Aufgabe: Zur Unterstützung der Qualitätssicherung unserer Softwareentwicklung suchen wir längerfristig studentische Unterstützung im Bereich Retail

Mehr

Acrolinx IQ. Verbindung mit einer externen Terminologiedatenbank herstellen 2.7

Acrolinx IQ. Verbindung mit einer externen Terminologiedatenbank herstellen 2.7 Acrolinx IQ Verbindung mit einer externen Terminologiedatenbank herstellen 2.7 2 Inhalt Einleitung 3 Über diesen Leitfaden...3 Verbinden mit externen Terminologiedatenbanken 4 Erstellen von Sicherungen

Mehr

Forms2Net Die neue Migrations-Software

Forms2Net Die neue Migrations-Software Forms2Net Die neue Migrations-Software Forms2Net transportiert Ihre Oracle Forms Anwendungen perfekt nach Microsoft.NET Darauf haben viele gewartet. Vielleicht auch Sie! Forms2Net ist ein Produktpaket,

Mehr

Grundlagen der Informatik

Grundlagen der Informatik Grundlagen der Informatik Speicherung und Verwaltung von Informationen in Datenbanken Prof. Dr.-Ing. Thomas Wiedemann Fachgebiet Informatik / Mathematik Überblick zur Vorlesung Aktueller Stand der Datenverwaltung

Mehr

Hinweise zu A-Plan 2009 SQL

Hinweise zu A-Plan 2009 SQL Hinweise zu A-Plan 2009 SQL Für Microsoft Windows Copyright Copyright 2008 BRainTool Software GmbH Inhalt INHALT 2 EINLEITUNG 3 WAS IST A-PLAN 2009 SQL? 3 WANN SOLLTE A-PLAN 2009 SQL EINGESETZT WERDEN?

Mehr

Sructred Query Language

Sructred Query Language Sructred Query Language Michael Dienert 11. November 2010 Inhaltsverzeichnis 1 Ein kurzer Versionsüberblick 1 2 SQL-1 mit einigen Erweiterungen aus SQL-92 2 3 Eine Sprache zur Beschreibung anderer Sprachen

Mehr

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

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

Mehr

Data Warehouse Grundlagen

Data Warehouse Grundlagen Seminarunterlage Version: 2.10 Version 2.10 vom 24. Juli 2015 Dieses Dokument wird durch die veröffentlicht.. Alle Rechte vorbehalten. Alle Produkt- und Dienstleistungs-Bezeichnungen sind Warenzeichen

Mehr

Enterprise Social Networking: Ein Framework und ein Fachkonzept für ein Industrieunternehmen

Enterprise Social Networking: Ein Framework und ein Fachkonzept für ein Industrieunternehmen Enterprise Social Networking: Ein Framework und ein Fachkonzept für ein Industrieunternehmen Bachelorarbeit zur Erlangung des akademischen Grades Bachelor auf Science (B.Sc.) im Studiengang Wirtschaftswissenschaft

Mehr

Institut für Informatik

Institut für Informatik Aufgaben für die 14. und 15. zur LV "Grundlagen der Informatik" Thema: Datenbanken ( ERM: Entity-Relationship-Modell und SQL: Structured Query Language ) sowie HTML (Hypertext Markup Language) -------------------------------------------------------------------------------------------------------------------------

Mehr

Workflow Systeme mit der Windows Workflow Foundation

Workflow Systeme mit der Windows Workflow Foundation Studiengang Electronic Business (EB) Diplomarbeit (280000) Workflow Systeme mit der Windows Workflow Foundation externe Betreuung durch Christoph Müller vorgelegt bei Prof. Dr. Michael Gröschel von Hans-Martin

Mehr

Datenbanktechnologie mit praktischen Übungen in MySQL und PHP

Datenbanktechnologie mit praktischen Übungen in MySQL und PHP Datenbanktechnologie mit praktischen Übungen in MySQL und PHP Übung, Sommersemester 2013 29. April 2013 - MySQL 2 Sebastian Cuy sebastian.cuy@uni-koeln.de Aufgaben Anmerkungen Best practice: SQL Befehle

Mehr

TimeSafe Leistungserfassung

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

Mehr

Der Mac-Stammtisch Immenstaad informiert: Tabellenkalkulation mit Apple Numbers auf Mac / iphone / ipad

Der Mac-Stammtisch Immenstaad informiert: Tabellenkalkulation mit Apple Numbers auf Mac / iphone / ipad Der Mac-Stammtisch Immenstaad informiert: Tabellenkalkulation mit Apple Numbers auf Mac / iphone / ipad Diese Beschreibung gibt eine Übersicht über Tabellenkalkulations- Programme für Apple-Geräte und

Mehr

IBM Informix SQL. Seminarunterlage. Version 11.04 vom

IBM Informix SQL. Seminarunterlage. Version 11.04 vom Seminarunterlage Version: 11.04 Version 11.04 vom 27. April 2015 Dieses Dokument wird durch die veröffentlicht.. Alle Rechte vorbehalten. Alle Produkt- und Dienstleistungs-Bezeichnungen sind Warenzeichen

Mehr

17.2 MS-Access Projekte

17.2 MS-Access Projekte 964 Von MS-Access 2000 zum SQL-Server 17.2 MS-Access Projekte MS-Access-Projekte, die die Dateiendung adp besitzen, werden als Front-End-Anwendung verwendet. Für die Back-End-Seite gibt es mehrere Möglichkeiten.

Mehr

Kapitel 7: Formaler Datenbankentwurf

Kapitel 7: Formaler Datenbankentwurf 7. Formaler Datenbankentwurf Seite 1 Kapitel 7: Formaler Datenbankentwurf Die Schwierigkeiten der konzeptuellen Modellierung sind zu einem großen Teil dadurch begründet, dass sich die relevanten Strukturen

Mehr

JDBC. Allgemeines ODBC. java.sql. Beispiele

JDBC. Allgemeines ODBC. java.sql. Beispiele JDBC Java Data Base Connectivity Programmierschnittstelle für relationale Datenbanken Sammlung von Klassen, welche zum Aufbau einer Verbindung zwischen einem Java-Programm und einer Datenbank dienen Verwendet

Mehr

Mit dem MySQL Migration Toolkit aus ACCESS Datenbank SQL-Skripte generieren

Mit dem MySQL Migration Toolkit aus ACCESS Datenbank SQL-Skripte generieren Anleitung Problemstellung: Aus ACCESS-Datenbanken (*.mdb) SQL-Skripts erzeugen, die dann mithilfe der MySQL Workbench auf dem MySQL-server eingerichtet werden. Im nachfolgenden Beispiel sollen zu der ACCESS-Datenbank

Mehr