abbildung relationaler datenbanken auf das unix
Werbung
Jens Albrecht / Wolfgang Lehner DBFS ABBILDUNG RELATIONALER DATENBANKEN AUF DAS UNIX-DATEISYSTEM 1 Motivation In den letzten Jahren hat der Bereich der statistischen Auswertung betriebswirtschaftlich relevanter Massendatenbestände (“OLAP”) immer mehr Beachtung gefunden. Data Warehouses bilden die Datenbasis für derartige Analysen. Es müssen regelmäßig Daten aus heterogenen Quellen, unter anderem aus verschiedenen Datenbanksystemen, extrahiert und in bereinigter, aufbereiteter Form in das Data Warehouse eingebracht werden. Für diese Aufgabe gibt es spezielle Ladewerkzeuge (z.B. Extract von Evolutionary Technologies International’s Extract oder den Warehouse Manager von Prism Solutions Inc., für einen Überblick siehe [Will97]). Dennoch erfolgt der Datenaustausch zwischen verschiedenen Datenbanksystemen bei kleineren Warehouse-Szenarien sowie bei unzähligen ähnlichen Anwendungen über einfache Textdateien, die eine festgelegte Struktur haben. Jedes kommerzielle Datenbanksystem bietet die Möglichkeit, Textdateien zu importieren und zu exportieren. Einige Hersteller haben für diesen Zweck spezielle Werkzeuge (z.B. der SQL*Loader von Oracle [Orac95]), die mit Hilfe von Skripten den Datenaustausch halbautomatisch durchführen können. Dennoch muß oft sehr viel Zeit investiert werden, um Informationen aus einem Datenbanksystem in ein anderes zu übertragen. Die Metainformationen zu den Relationen, wie Datentypen und Constraints, gehen bei der Übertragung in der Regel verloren und müssen von Hand nachgetragen werden, sofern nicht durch das exportierende Datenbanksystem Skripten für die Schemagenerierung erzeugt werden können. Der in diesem Beitrag skizzierte Ansatz besteht darin, einen generischen Dienst anzubieten, der den transparenten Zugang zu verschiedenen Datenbanksystemen über das Unix-Dateisystem ermöglicht. Es soll also möglich sein, mehrere Datenbanken als Datenbankdateisysteme (DBFS) zu “mounten”. Die Idee ist, ähnlich wie beim Proc-Filesystem, bei dem Prozeßstrukturen auf Dateien abgebildet werden, Relationen als Dateien im Unix-Dateisystem erscheinen zu lassen. Innerhalb des DBFS sind die Relationen samt Metainformationen als Textdateien zugänglich. Dadurch wird zum einen die komfortable Navigation durch den Datenbestand ermöglicht, da auf fast allen Plattformen graphische Benutzeroberflächen existieren, um Verzeichnis- und Dateiinhalte zu betrachten. Zum anderen eröffnen sich ganz neue Möglichkeiten zur Datenmanipulation. Man denke hierbei nur an die mächtigen Textverarbeitungswerkzeuge, die unter Unix zur Verfügung stehen (z.B. perl, awk, sed). Die Struktur der Dateien und Verzeichnisse ist für alle Relationen gleich. Dadurch erscheint der Datenbestand in einem homogenen Format. Um das zu erreichen, muß eine geeignete Abbildung der Relationen auf Verzeichnisse und Dateien definiert werden. Der Export einer Relation aus einem Datenbanksystem in ein anderes wird dann auf einen einfachen Kopiervorgang im DBFS reduziert. Das DBFS muß dafür allerdings intelligent genug sein, um die komplexe Semantik, die durch die Metainformationen an die Relationen und damit auch an die Dateien geknüpft wird, zu interpretieren. 2 Vorarbeiten In der Literatur finden sich verschiedene Arbeiten, die sich mit der datenbanktechnischen Verarbeitung von Textdateien beschäftigen. In [AbCM93], [CACS94] und [CoMi94] werden Verfahren beschrieben, die komplexe Anfragen auf teilstrukturierten Textdateien ermöglichen. Unser Ansatz geht in die andere Richtung - die Abbildung von Relationen, die sich bereits in einer Datenbank befinden, auf strukturierte Dateien. Die Implementierung eines Dateisystems für eine objektorierentierte Datenbank wird in [GeJR94] beschrieben. 3 Ziele Die Data-Warehouse-Problematik sollte als eine mögliche Anwendung nur eine Motivation für diesen Artikel sein; uns ist klar, daß durch das DBFS nicht die gesamte Ladeproblematik eines großen Warehouses gelöst werden kann. Aus unserer Sicht ist das DBFS als eine Erweiterung des Komforts beim alltäglichen Umgang mit dem Datenbanksystem zu verstehen, die auch komplexere Einsatzmöglichkeiten eröffnet. In diesem Beitrag wird der erste Schritt bei der Realisierung des DBFS erläutert: die Definition der Abbildung einer Relation auf strukturierte Dateien. Dabei soll einerseits die Navigation durch den Datenbestand möglichst einfach und intuitiv gestaltet werden. Andererseits sollen auch komplexe Anfragen an die Datenbank möglich sein, damit die Flexibilität nicht allzu stark eingeschränkt wird. Man erhält dadurch beispielsweise die Möglichkeit, das Ergebnis einer select-Anweisung direkt an die Unix-Werkzeuge weiterleiten zu können. 4 Table-Dateien und Meta-Dateien Für jede Relation und jede View der Datenbank existiert ein eigenes Verzeichnis gleichen Namens. In diesem Verzeichnis befinden sich mehrere Dateien, welche Daten (Table-Dateien) und Metainformationen (Meta-Dateien) der entsprechenden Relation enthalten. Table- und MetaDateien sind nicht physisch vorhanden, sondern werden durch das DBFS in Datenbankanfragen übersetzt. Nach außen sind sie jedoch von “echten” Dateien nicht unterscheidbar. Um sofort die Möglichkeit zu haben, die Daten der Relation zu betrachten, gibt es eine Datei mit dem ausgezeichneten Namen @ (all), welche die gesamte Tabelle in ASCII-Form enthält. Das Layout dieser Datei wird durch spezielle Einträge in der Meta-Datei .@metadata (s.u.) bestimmt. Zusätzlich dazu existiert für jedes Attribut eine eigene Datei gleichen Namens. So gibt es beispielsweise für die Relation PERSONAL (siehe Abbildung 1) ein Verzeichnis PERSONAL/ mit den Dateien PNr, Name, Telefon und ANr. Diese Dateien enthalten nur die Wertepaare bestehend aus dem Primärschlüssel und dem jeweiligen Attribut. Falls kein Primärschlüssel auf der Relation definiert ist, wird stattdessen der Row-Identifier herangezogen. Durch diese Dateien wird ein elementarer Zugriff auf die einzelnen Attribute ermöglicht. Existenzanfragen können sehr schnell mit grep ausgeführt werden, Wertebereiche können mit uniq ermittelt werden. Anfragen die zwei Attribute betreffen, können einfach mit Hilfe des Unix-Befehls join auf Dateiebene gestellt werden. Der Datentyp jedes Attributes steht in einer eigenen Meta-Datei, deren Name mit einem Punkt beginnt (z.B. .Telefon für Telefon), um sie bei der “normalen” Anzeige des Verzeichnisinhaltes zu verbergen. Ist allerdings eine referentielle Integritätsbedingung auf dem Attribut definiert, so existiert nur ein symbolischer Link auf die korrespondierende Meta-Datei der referenzierten Relation. Somit sind durch ein einfaches ls -l sofort alle referentiellen Integritätsbedingungen sichtbar. Bei einer View sind alle diese Dateien bis auf die, welche Aggregate beschreiben, symbolische Links. Die eigentlichen Metadaten der Relation sind in einer Datei namens .@metadata abgelegt. Im wesentlichen stehen dort die Parameter, die bei Erzeugung der Tabellen- oder View-Definition (create table/view) angegeben wurden. Weitere Informationen wie die Anzahl der Tupel, die gesetzten Locks usw. können hier eingetragen sein. Letztere Daten dienen ausschließlich zur Information für den Benutzer, da nicht davon ausgegangen werden kann, daß sie sich systemübergreifend verwenden lassen. In dieser Datei finden sich auch Informationen darüber, wie die Tabelle als Textdatei dargestellt sein soll, also welches Zeichen als Separator verwendet wird oder auf welchen Zeilenpositionen welche Attribute zu finden sind. Relation PERSONAL PNr Name Telefon ANr 4711 4712 4713 Wedekind,Hartmut Lehner,Wolfgang Albrecht,Jens 85-7893 85-7800 85-7884 IMMD6 IMMD6 IMMD6 Relation ABTEILUNG ANr Bezeichnung Leiter IMMD6 Datenbanksysteme 4711 / Informix Oracle albrecht PERSONAL lehner ABTEILUNG PNr Name Telefon ANr @ .PNr .Name .Telefon .ANr .@metadata Abb. 1: Beispielrelationen und der resultierende Dateibaum Anhand der Beispielrelationen aus Abbildung 1 wird die bisher beschriebene Abbildung illustriert. Man beachte, das albrecht hier nicht das Unix-Home, sondern den Oracle-Login-Namen bezeichnet: % cd Oracle/albrecht % ls PERSONAL ABTEILUNG % cd PERSONAL % ls -a .@metadata .PNr PNr Name .Name Telefon .Telefon ANr .ANr @ % cat .@metadata PNr integer primary key, Name char(20) not null, Telefon char(7), ANr foreign key references Abteilung(ANr) @Separator ; % ls -l .ANr .ANr -> ../ABTEILUNG/.ANr % cat .ANr char(5) % cat Name 4711;Wedekind,Hartmut 4712;Lehner,Wolfgang 4713;Albrecht,Jens 5 Pseudo-Dateien In [GeJR94] wird vorgeschlagen, für komplexere Anfragen Pseudo-Dateien zu verwenden. Auf Pseudo-Dateien kann explizit über den Namen zugegriffen werden, dennoch erscheinen sie nicht als Einträge im Verzeichnis und können auch nicht sichtbar gemacht werden. Pseudo-Dateien bieten die Möglichkeit, über Dateinamen komplexe Anfragen zu verpacken. Dadurch kann die select-Anweisung in ihrer gesamten Flexibilität im Dateisystem zur Verfügung gestellt werden ohne ein unüberschaubares Durcheinander von Dateinamen zu erzeugen. Da die Ausgaben immer Textdateien von festgelegter Struktur sind, lassen sie sich Unix-seitig sehr komfortabel über Pipes oder Filter weiterverarbeiten. Häufige Anfragen können durch das Anlegen von symbolischen Links auf Pseudo-Dateien erleichtert werden. Diese symbolischen Links entsprechen der Definition von Views auf Dateiebene. Alle Dateien, die mit dem Zeichen @ beginnen, sind Pseudo-Dateien (einzige Ausnahme bildet die Datei @, die im Verzeichnis sichtbar ist). Der Pseudo-Dateiname übersetzt sich direkt in eine SQLAnweisung und hat deshalb im wesentlichen dieselbe Syntax. Eine from-Klausel ist nicht notwendig, da sich der Tabellenname aus dem Directorynamen der Pseudo-Datei ermitteln läßt. Die Vorgehensweise wird am besten an folgendem Beispiel verdeutlicht. Die Anfrage select Name from PERSONAL where Telefon=‘85-7884’ kann auf Dateiebene folgendermaßen gestellt werden: % cat PERSONAL/“@Name where Telefon=‘85-7884’” Allgemein läßt sich eine Anfrage der Gestalt select string1 from table where string2 auf Dateiebene darstellen als % cat table/”@string1 where string2” string1 kann dabei nicht nur die Attribute, sondern auch alle in SQL möglichen Aggregierungsfunktionen enthalten. Ebenso können in string2 alle Klauseln, die nach einem where stehen können, wie z.B. group by oder order by, vorkommen. Diese Zeichenketten werden direkt in die select-Anweisung übernommen. Die Angabe string1 where ist optional, wenn alle Attribute (select *) angegeben werden: % cd PERSONAL % cat “@Name like ‘Lehner%’” 4712;Lehner,Wolfgang;Erlangen;IMMD6 Joins sind nur zwischen Tabellen, die im selben Verzeichnis liegen (wie PERSONAL und ABTEILUNG) möglich. Die Pseudodateien für die Joins sind in diesem Verzeichnis (albrecht) zugänglich. Das Ergebnis einer Anfrage der Gestalt select t1.a, t2.b from t1, t2 where string kann man sich durch % cat “@t1/a, t2/b where string” ausgeben lassen. string kann natürlich auch ein Prädikat der Form t1/c=t2/c enthalten. Man beachte, daß auch hier die from-Klausel nicht angeben werden muß - die beteiligten Relationen werden wie in QUEL durch die explizit anzugebenden Tabellennamen bei den Attributen ermittelt. Die Anfrage select P.Name, A.Name from PERSONAL P, ABTEILUNG A where PERSONAL.PNr=ABTEILUNG.Leiter hat dann auf Dateiebene die Darstellung % cat “@PERSONAL/Name, ABTEILUNG/Name where\ PERSONAL/PNr = ABTEILUNG/Leiter” und liefert als Ergebnis Wedekind,Hartmut;Datenbanksysteme Diese Anfrage läßt sich auf Dateiebene genauso mit Hilfe des Unix-Kommandos join formulieren: % join -t ‘;’ -1 1 -2 3 -o 1.2,2.2 PERSONAL/@ ABTEILUNG/@ 6 Technische Realisierung Die Implementierung des DBFS wird durch den Einsatz des Network File Systems (NFS [Sun95]) ermöglicht (Abbildung 2). Dabei kommt serverseitig anstelle des NFS-Servers ein intelligenter DBFS-Server zum Einsatz, der die eigentliche Abbildung von Relationen auf Dateien durchführt. Dafür braucht er für jedes Datenbanksystem, das mit einbezogen werden soll, eine systemabhängige Komponente, die den Zugriff auf die Metainformationen dieses Systems ermöglicht. Rechner A Oracle Dateiorientierte Anwendung NFS Client Ethernet read/write open/close DBFS Server DBFS Daemon Sybase Rechner B Oracle DBFS Server DBFS Daemon Adabas Abb. 2: Kommunikation zwischen dateiorientierter Anwendung und Datenbanksystem Ein weiterer Grund für den Einsatz des NFS-Protokolls ist die Unterscheidung zwischen readdir und lookup, welche die Implementierung der im vorigen Abschnitt erwähnten Pseudo-Dateien gestattet. 7 Zusammenfassung und Ausblick Durch das DBFS wird ein einheitlicher Zugang auf verschiedenste Datenbanksysteme über das Unix-Dateisystem ermöglicht. Dadurch eröffnen sich komfortable Möglichkeiten für die Navigation im Datenbestand, den Datentransfer und die Manipulation der Daten. Bisher wurde nur ein Read-Only-Dateisystem beschrieben. An einem Mechanismus, der die Datenmanipulation und damit die eingangs beschriebenen Import- und Export-Funktionen zuläßt, wird noch gearbeitet. Das DBFS soll am Lehrstuhl für Datenbanksysteme an der Universität Erlangen-Nürnberg implementiert werden. Literatur AbCM93 Abiteboul, S.; Cluet, S.; Milo, T.: Querying and Updating the File, in: Proceedings of the 19th Internatial Conference on Very Large Data Bases (VLDB’93, Dublin, Ireland, Aug. 24-27 1993), S. 73-84 CACS94 Christophides, V.; Abiteboul, S.; Cluet, S.; Scholl, M.: From Structured Documents to Novel Query Facilities, in: Proceedings of the ACM-SIGMOD 1994 International Conference on the Management of Data (SIGMOD’94, Minneapolis, MN, May 1994), S. 313-324 CoMi94 Consens, M.P.; Milo, T.: Optimizing Queries on Files, in: Proceedings of the ACMSIGMOD 1994 International Conference on the Management of Data (SIGMOD’94, Minneapolis, MN, May 1994), S. 301-312 GeJR94 Gehani, N.H.;Jagadisch, H.V.; Roome, W.D.: OdeFS: A File System Interface to an Object-Oriented Database, in: Proceedings of the 20th VLDB Conference, (Santiago, Chile, 1994), S. 249-260 Orac95 SQL*Loader: Oracle7 Server Utilities, Oracle Corporation, 1995 Sun95 Network File System: The NFS Distributed File Service, Sun Microsystems, Inc., 1995 (http://www.sun.com/sunsoft/solaris/desktop/nfs.html) Will97 Williams, John: Tools for Traveling Data, DBMS Online (http://www.dbmsmag.com/ 9706d16.html) Autorenangaben Dipl.-Inf. Jens Albrecht Friedrich-Alexander-Universität Erlangen-Nürnberg Lehrstuhl für Datenbanksysteme (IMMD VI) Martensstr. 3 D-91058 Erlangen Tel.: 09131/85-7884 Fax.: 09131/32090 EMail: [email protected] Dipl.-Inf. Wolfgang Lehner Friedrich-Alexander-Universität Erlangen-Nürnberg Lehrstuhl für Datenbanksysteme (IMMD VI) Martensstr. 3 D-91058 Erlangen Tel.: 09131/85-7800 Fax.: 09131/32090 EMail: [email protected]
