abbildung relationaler datenbanken auf das unix

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]