Von MS Access nach Oracle schnell, einfach und dezentral

Transkript

1 17.Deutsche ORACLE-Anwenderkonferenz Database Donnerstag, 11. November h00, Variohalle 5 Von MS Access nach Oracle schnell, einfach und dezentral Stephan La Rocca Team GmbH, Paderborn Schlüsselworte: Oracle Migration Workbench, Microsoft Access 97, Consulting Zusammenfassung Dieser Vortrag gibt die Erfahrungen wider, die in einem Migrationsprojekt bei der Firma SieMatic gemacht wurden. Der Oracle Partner TEAM hat dem Kunden Hilfe zur Selbsthilfe geleistet, wodurch dieser Kunde seine ca. 80 MS Access Datenbanken selbst nach Oracle migrieren konnte und weiter kann. Dabei wurde ein Verfahren benutzt, bei dem die einzelnen Fachabteilungen selbst eine silent Migration, also ohne Interaktion, durchgeführt haben bzw. noch durchführen. Einleitung In dem Unternehmen waren historisch eine Vielzahl von kleineren Applikationen auf Basis von Microsoft Access entstanden. Die Fachabteilungen hatten selbstständig, ohne Unterstützung oder Koordination der EDV-Abteilung eigene Anforderungen im Rahmen der zur Verfügung stehenden Office-Produktpalette realisiert. Im Rahmen der Konsolidierung der im Unternehmen eingesetzten Software, und unter Berücksichtigung von Datenvolumen, Datensicherung und Benutzerberechtigung wurde der Entschluss gefasst, diese Datenbestände in eine Oracle Datenbank zu migrieren. Betroffen waren ca. 80 Access-97-Datenbanken, mit unterschiedlichstem Volumen von knapp 10 MB bis zu mehreren 100 MB. Da einige Anwendungen teilweise mit lokalen Komponenten implementiert war, sollte die Migration der Datenbanken nicht von der EDV-Abteilung zentral, sondern dezentral von den Fachabteilungen durchgeführt werden. Diese konnten die zu migrierenden Tabellen und den Zeitpunkt der Umstellung selbst bestimmen. Nach der Migration wurden die Tabellen via ODBC in die Access-Applikationen eingebunden. An den vorhandenen Formularen, Berichten, Makros und dem Visual Basic Code innerhalb der Access-Datenbanken sollten keine Änderungen

2 KONFERENZ notwendig werden. Die Access-Datenbanken sollten weiterhin als Front-End mit den vorhandenen Komponenten zum Einsatz kommen. Die Fachabteilungen kannten die Strukturen ihrer Applikationen, waren aber nicht vertraut mit Aufgaben der Oracle Datenbank Administration. Begriffe wie Schemata, Tablespace, etc. sollten nicht vermittelt werden müssen, nur damit die Anwender die Tabellen in die Oracle Datenbank ablegen konnten. Migrationsweg Bei der Migration einer Access-Applikation in eine Oracle Datenbank sind eine Reihe von Hürden zu nehmen, die durch die unterschiedliche Umsetzung in der Oracle und Microsoft-Technologie begründet liegt. Es galt folgende Aufgabenstellungen zu lösen: Namenskonventionen Bei einer Access-Datenbank gibt es keine Beschränkung, was die Länge oder die verwendeten Zeichen bei der Benennung von Tabellen, Spalten oder Indizes angeht. Bei der Migration muss berücksichtigt werden, dass diese Namen umgeschrieben werden. Damit aber im Anschluss der restliche Quellcode der Access-Applikation nicht geändert werden muss, empfiehlt es sich, die Tabellen einzubinden und dann ein Abfrage mit Aliasen für die Spalten und Tabellenbezeichnungen zu erstellen. Diese wird dann an den vorhandenen Stellen anstatt der ursprünglichen Tabelle genutzt. Migration der Datentypen Es existiert keine 1:1 Zuordnung der unter Access möglichen Datentypen zu den Datentypen der Oracle Datenbank. Bei einer Migration sind folgende Umsetzungen einzuhalten: Microsoft Access Datentyp Boolean Byte Currency Date Double Integer Long LongBinary Memo Single Text Oracle Datentyp NUMBER(1,0) NUMBER(3,0) NUMBER(15,4) DATE FLOAT(126) NUMBER(5,0) NUMBER(11,0) BLOB CLOB FLOAT(126) VARCHAR2

3 17.Deutsche ORACLE-Anwenderkonferenz Database Indizes und Constraints Indizes und Constraints müssen aus der Access-Tabellendefinition ausgelesen werden und unter Oracle angelegt werden. Die Namenskonvention der Oracle Datenbank können ohne weitere Aufwände umgesetzt werden, da innerhalb der Access-Applikation die Indizes und Constraints nicht über den Namen angesprochen werden. Notwendige Primary Keys durch ODBC-Zugriff Da im Anschluss an die Migration die erstellten Tabellen in der Oracle Datenbank via ODBC in das Access-Front-End eingebunden werden sollen, ist es notwendig, dass jede Tabelle einen Primary-Key aufweist. Sollte das nicht der Fall sein, so ist es nicht möglich, DML-Befehle auf diese Tabelle abzusetzen. Default-Werte In einer Access-Datenbanktabelle definierte Default-Werte für eine Spalte sind in Oracle in einem Datenbanktrigger (BEFORE INSERT OR UPDATE) zu realisieren. Dieser Trigger muss bei der Konvertierung der Tabelle angelegt werden. Konvertierung boolscher Feldinhalte Bei der Migration der Daten ist zu beachten, dass die Oracle Datenbank keinen eigenen Datentyp für die Access-Ja/Nein-Felddatentypen bereitstellt, sondern diese Inhalte in ein Number-Feld importiert. Dabei ist darauf zu achten, dass unter Visual Basic der boolsche Wert TRUE durch die Zahl 1, der boolsche Wert FALSE durch die Zahl 0 interpretiert wird. Oracle Migration Workbench Im Hinblick auf diese Aufgabenstellung wurden in einem ersten Schritt die Möglichkeiten der Oracle Migration Workbench beleuchtet. Die umfangreichen Möglichkeiten der Oracle Migration Workbench und erste Testmigrationen zeigten, dass die zuvor gestellten Anforderungen mit diesem Tool durchaus gelöst werden konnten. Allerdings stellte sich recht schnell heraus, dass der Overhead und die Vielfältigen Möglichkeiten für die Migration viel zu groß waren und die Fachabteilungen sicherlich nicht in der Lage gewesen wären, die Migration ohne die EDV-Abteilung durchzuführen. Bei der Angabe der zu nutzenden Datenbank, den zu erstellenden Schematas, der benutzten Tablespaces, etc verlangte die Oracle Migration Workbench DBA- Know-How und DBA-Berechtigungen ab, die den Fachabteilungen nicht zugestanden werden sollten. Eine Trennung der Migrationsaufgaben war durch das Tool nicht vorgesehen. Die Möglichkeiten, die Migration in eine Übernahme des Datenmodells in das Repository, die Bearbeitung dieses Datenmodells, das Erstellen des Zieldatenmodells und die Migration der Daten zu trennen, war keine Option, die der Kunde hätte nutzen können.

4 KONFERENZ Die Alternative Nach diesen ersten Migrationsschritten entschloss sich das Projektteam, die Migration ausschließlich eigenständig zu implementieren. Das Know-how um die Aufgabenstellung und die Umsetzung aus den, in der Oracle Migration Workbench enthaltenen Access-Komponenten waren Grundlage für die Umsetzung. Die Migration wurde in folgende Aufgaben geteilt. 1.) Vorbereitung der Oracle Datenbank Von der EDV-Abteilung wurde die Oracle Datenbank für die Migration vorbereitet. Dazu wurden für Gruppen von Fachabteilungen eigene Schematas angelegt, Tablespaces reserviert und Benutzerberechtigungen eingerichtet. Ziel sollte es sein, dass für Gruppen von Access-Applikationen die Tabellen in eigene Schematas gepackt werden sollten. Die Gruppen wurden durch die Organisationsform der Abteilungen gebildet. 2.) Erstellen eines Access-Migration-Front-Ends Von der EDV-Abteilung wurde ein Access-Programm entwickelt, mit dem die Fachabteilungen die Migration durchführen sollten. Dieses Access-Programm übernahm folgende Aufgaben: a. Auswahl der zu migrierenden Access-Datenbank. Der Anwender konnte sich über das Filesystem die Access-Datenbank auswählen, die er migrieren wollte. b. Auswahl der Tabellen in der zu migrierenden Datenbank. Nachdem der Anwender die Datenbank ausgewählt hat, die er migrieren möchte, bekommt er eine Auswahl der zu migrierenden Tabellen. Es werden alle Tabellen angeboten, die in der ausgewählten Datenbank enthalten sind. c. Anlegen der Tabellen in der Oracle Datenbank Mit der Anmeldung des Anwenders entscheidet das Programm, unter welchen Datenbankschemata die Tabelle angelegt werden soll. Aus der Tabellendefinition der Access Tabelle wird ein CREATE-Skript für die Oracle Tabelle erstellt. Dabei werden die Typkonvertierungen und die Behandlung der boolschen Felder berücksicht. Weiterhin wird aus der Tabellendefinition die Information über Pflichtfelder, Constraints und Indizes entnommen und diese erstellt. d. Namenskonventionen Zur Einhaltung der Namenskonventionen werden die Oracle Namenskonventionen umgesetzt. In einer Mappingtabelle wird festgehalten, wie die Spalten und Tabellennamen umbenannt wurden. e. Erstellen eines eindeutigen Schlüssels Sollte bei der Analyse der Tabellendefinition festgestellt werden, dass die Tabelle keinen eindeutigen Schlüssel besitzt, wird der Anwender aufgefordert, einen eindeutigen Schlüssel zu erstellen.

5 17.Deutsche ORACLE-Anwenderkonferenz Database Der Benutzer kann die Spalte auswählen, die aus seiner Sicht den eindeutigen Schlüssel in der Tabelle definiert. Sollte kein solcher Schlüssel existieren, wird ein neuer Schlüssel vom System generiert. Dazu wird die Spalte, der Constraint, eine Sequence und ein passender Trigger in der Datenbank angelegt. f. Einbinden der Tabelle via ODBC Nachdem die Tabelle in der Oracle Datenbank erstellt wurde, wird sie via ODBC wieder in die Access-Datenbank eingebunden. g. Datenübernahme In der Access-Applikation, die die Migration durchführt, stehen nun beide Tabellen zur Verfügung und es kann die Migration der Daten von der Access-Tabelle in die Oracle Datenbank durchgeführt werden. Sollte eine zusätzliche Spalte notwendig werden, wird diese bei der Migration der Daten aus der erstellten Sequence gefüllt. h. Ersetzen der Quelltabelle In der Access Datenbank wird die Quelltabelle entfernt und eine neue Abfrage erstellt, die die Namen der Tabelle und Spalten aus der ursrpünglichen Tabelle übernimmt. So ist sichergestellt, dass keine Änderungen an den Formularen, Berichten, Makros und dem Visual Basic Code durchgeführt werden muss. 3.) Duchführung der Migration Den Fachabteilungen wurde die so implementierte Anwendung zur Verfügung gestellt und sie konnen dezentral und zeitunabhängig die Migration durchführen. Mittlerweile sind mehr als 90% der Applikationen migriert und so ca 300 Tabellen in die Oracle Datenbank überführt worden. Der Blick nach vorne Durch die eigene Implementierung dieser Access-Migrations-Applikation war die Firma in der Lage die Aufgaben der Migration sehr genau zwischen den Oracle-Datenbank-Administrativen Aufgaben und den Aufgaben der Anwender zu trennen. Es galt ausschließlich die Daten zu migrieren und die Access-Applikationsentwicklung weiter in den Händen der Fachabteilungen zu belassen. Da auch weiterhin an den Applikationen Änderungen durchgeführt werden, kommt es auch zukünftig dazu, dass die Fachabteilungen in den mittlerweile umgestellten Applikationen implementieren. Nach der Umstellung finden sie zu einer ursprünglichen Access-Tabelle zwei Objekte in der Access-Datenbank. Zum Einen die eingebundene ODBC-Datenquelle mit den Alias-Bezeichnungen und zum anderen das View-Objekt, welches der Benennung der ursprünglichen Tabelle entspricht. Das führt teilweise zur Verwirrung, obwohl es irrelevant ist, welche Tabelle zum Einsatz kommt. Diese Verwirrung hätte vermieden werden können, wenn die Tabellen zunächst in einer eigenen, neu erstellten Access-

6 KONFERENZ Datenbank eingebunden und in dieser die View-Objekte erstellt worden wären. Aus dieser Tabelle hätten dann die Views in die ursprüngliche Applikation übernommen werden können. Weitaus wichtiger für die Weiterentwicklung der Migrationsapplikation ist die Anforderung auch zukünftig DDL-Befehle an die ODBC-Datenquellen (und somit auch an die erstellten View-Objekte senden zu können. Vor der Migration waren die Fachabteilungen selbstständig in der Lage, Spalten hinzufügen oder ändern zu können. Dazu bräuchten Sie nun die Unterstützung der Datenbank-Administratoren. Geplant ist die Erweiterung der Access-Migrations- Applikation um die Möglichkeit, bereits migrierte Tabellen zu verändern. So könnte sichergestellt werden, dass auch gleichzeitig das View-Objekt angepasst wird. Kontaktadresse: Stephan La Rocca Dipl.-Informatiker Business Development Team GmbH Hermann-Löns-Straße 88 D Paderborn Telefon: +49(0) Fax: +49(0) Internet: