
Kurzfassung: Steigende Probezahlen und die
konsequente Anwendung der Guten Laborpraxis (GLP) führen zu
immer größeren Datenmengen im Labor, die mit einfachen PC-Datensystemen
kaum mehr zu handhaben sind. Zur Lösung dieser Problematik und
damit zur Steigerung der Laborproduktivität bieten sich
Softwareprodukte an, die als Datenbanksysteme bekannt sind. Die
wichtigsten Vorteile sind effizientes Suchen früherer Daten,
Datensicherheit, Datenkompatibilität sowie die Abwicklung
gleichzeitiger Zugriffe mehrerer Benutzer.

EDV im Labor: Der aktuelle Stand
In den letzten Jahren ist die Elektronische Datenverarbeitung
(EDV) auch im Labor nahezu unverzichtbar geworden. Mit dem
Aufkommen preiswerter, aber sehr leistungsfähiger Personal
Computer (PCs) gehen immer mehr Hersteller von Laborgeräten dazu
über, diese als Datenstationen für ihre Geräte einzusetzen.
Was für den Hersteller vor allem aus Kostengründen interessant
ist (da damit die aufwendige Entwicklung von Ein- und
Ausgabeeinheiten wegfällt), führt aber auch zu bisher nicht
gekannter Leistungsfähigkeit und Bedienungsfreundlichkeit für
den Anwender - zumindest wenn die mitgelieferte Software diesem
Anspruch gerecht wird.
Neben den zuvor genannten Aufgaben, die vor allem
Datenerfassung, Steuerung sowie Auswertung umfassen, nehmen in
der täglichen Laborroutine aber auch diverse Verwaltungstätigkeiten
erhebliche Zeit in Anspruch. Hier wären insbesondere die
Abwicklung von Analysenaufträgen einschließlich der
Probenverwaltung, diverse Lagerhaltungserfordernisse (z.B.
Chemikalien) oder Maßnahmen zur Optimierung von Personal- oder
Geräteeinsatz zu erwähnen. Diese Aufgaben werden in vielen
Laboratorien bereits mit Computerunterstützung bewältigt;
derartige Systeme sind als "LIMS" (Laborinformationssysteme)
bekannt.
Gesetzliche und allgemeine gesellschaftliche Änderungen der
letzten Jahre führen einerseits dazu, dass immer mehr Proben
analysiert werden müssen (insb. in den Sektoren Umweltschutz und
Lebensmittel) und andererseits, dass auch an die Analysendaten im
Zuge der Guten Laborpraxis (GLP) immer höhere Ansprüche
gestellt werden. Aus diesen Gründen nimmt der Umfang der im
Labor anfallenden Daten stetig zu. Dieser Beitrag soll einen Überblick
bieten, wie diese Datenmengen mit Hilfe der als Datenbanksysteme
bekannten Technologie bewältigt werden können.
Potenzielle Problemquellen
Vor der Erläuterung, was unter einem Datenbanksystem zu
verstehen ist, wird ein praxisnahes Beispiel aus der Labor-EDV
die Probleme aufzeigen, die mit "herkömmlicher"
Software ohne Datenbank-Einsatz auftreten können:
Ein auf Personal Computer basierendes Chromatographie-Datensystem
wird in einem Routinelabor zur Aufzeichnung, Auswertung und
Speicherung der anfallenden Chromatogramme eingesetzt. Bei nur
einigen hundert Chromatogrammen pro Tag wird die Zahl 100.000
bereits in etwa einem Jahr erreicht. Wenn man noch die langjährige
Aufzeichnungspflicht nach GLP berücksichtigt, gelangt man zu
Datenmengen, die für einen Menschen nicht mehr zu überblicken
sind.
Bei ausreichend großer Festplatte ist die Speicherung einer
derartigen Anzahl von Chromatogrammen auf einem Rechner zwar noch
möglich, allerdings gleicht die Suche nach einem bestimmten
Chromatogramm, von dem lediglich die Analysenmethode, Details der
Rohdaten oder Resultate, der Auftraggeber oder der Ausführende
bekannt sind, der sprichwörtlichen Nadel im Heuhaufen.
Weitere Schwierigkeiten der Speicherung der Chromatogramme als
einzelne Dateien sind darin zu sehen, dass das Löschen oder
Umbenennen von Dateien zumindest auf Betriebssystem-Ebene ohne Rücksicht
darauf möglich ist, ob diese Dateien noch benötigt werden oder
nicht. Auch die Protokollierung aller Anwenderaktionen (Audit
Trail), die von GLP-kompatiblen Datensystemen meist unterstützt
wird, findet bei Löschoperationen aus dem Betriebssystem heraus
nicht statt. Irrtümlich gelöschte Dateien können außerdem nur
mehr wiederhergestellt werden, wenn der Fehler sofort bemerkt
wurde.
Darüber hinaus sind die Möglichkeiten, auf die
Chromatogrammdaten über externe Programme (kommerziell oder im
Haus entwickelt) zuzugreifen, je nach Datensystem mehr oder
weniger eingeschränkt. Beim Mehrbenutzerbetrieb (mehrere
Anwender arbeiten mit demselben Datenbestand zur gleichen Zeit, z.B.
in einem Netzwerk) kommen noch weitere Probleme wie
Sperrmechanismen oder Transaktionskontrolle hinzu, auf die aber
an dieser Stelle nicht näher eingegangen werden kann.
Die genannten Schwierigkeiten sind jedoch keineswegs auf
Chromatographie-Datensysteme beschränkt - mit Spektren,
Analysenaufträgen etc. verhält es sich kaum anders. Da diese
Probleme in ähnlicher Form bereits seit langem bekannt sind, z.B.
bei Banktransaktionen, Flugreservierungen oder im betrieblichen
Rechnungswesen, werden bereits seit einigen Jahrzehnten Systeme
zur Lösung dieser Situation entwickelt. Diese Systeme, die unabhängig
von einer konkreten Anwendung arbeiten ( also genauso für
Flugreservierungen wie zur Verwaltung von Analysenaufträgen
geeignet sind), sind allgemein als Datenbanksysteme bekannt.
Was ist eine Datenbank ?
Zunächst ist es erforderlich, auf einige Begriffe im Detail
einzugehen, die für das Verständnis der folgenden Erläuterungen
erforderlich sind:
Objekt: bezeichnet eine Person, einen Gegenstand oder ein
anderes reales Faktum, das für sich abgeschlossen existiert.
Beispiele hierfür wären ein bestimmter Kunde, eine
Analysenmethode oder eine Probe.
Objekttyp: Gesamtheit aller gleichartigen Objekte, also z.B.
die Liste aller Kunden.
Attribute: Zur Beschreibung jedes Objekts sind bestimmte
Angaben notwendig, die als Attribute bezeichnet werden. Für
jeden Kunden wären beispielsweise Name, Adresse, Telefonnummer
und Kundennummer anzugeben. Alle Objekte, die einem bestimmten
Objekttyp angehören, sind hinsichtlich ihrer Attribute
gleichartig strukturiert.
Um dies besser verständlich zu machen, soll ein Ausschnitt
aus der Probenverwaltung eines Weinlabors diskutiert werden.
In der Liste der Auftraggeber der Weinproben (= Objekttyp
"Kunden") scheinen die einzelnen Firmen (= Objekte)
Bauer GmbH, Müller AG sowie Novak & Co auf. Für jedes
Unternehmen werden Kunden-Nummer, Firmenname, Adresse,
Telefonnummer etc. (= Attribute) gespeichert. In der
weitverbreiteten Tabellendarstellung würde das wie in Abb. 1
aussehen.

Grob gesprochen, stellen die Spalten der Tabelle die Attribute
dar (oft auch als Felder bezeichnet), während die Zeilen den
einzelnen Objekten (häufig auch Datensätze genannt) entsprechen.
Nun ist mit den Daten der Auftraggeber alleine noch nicht
allzu viel anzufangen; zumindest sollten Informationen über die
einlangenden Proben sowie deren Zugehörigkeit zu den bekannten
Auftraggebern vorliegen. Diese Zugehörigkeit wird in der
Darstellung (Abb. 2) durch Pfeile zwischen den einzelnen Objekten
symbolisiert.

Man sieht, dass die Bauer GmbH 3 Proben in Auftrag gegeben hat,
die Müller AG keine und Novak & Co 2. Umgekehrt ist jedoch
jeder Probe genau ein Auftraggeber zugeordnet. Die durch die
Pfeile symbolisierte Objektbeziehung zwischen den Objekttypen
"Kunden" und "Proben" wird als 1:N-Beziehung
bezeichnet, da von jedem Kunden-Objekt mehrere Pfeile ausgehen können,
von jeder Probe aber nur eine. Neben der 1:N-Beziehung sind aber
genauso 1:1 oder M:N-Beziehungen denkbar. Ein weiteres Kriterium
stellt die Tatsache dar, dass einem Auftraggeber nicht unbedingt
eine Probe zugeordnet sein muss (z.B. Müller AG), umgekehrt aber
für jede Probe ein Auftraggeber zu existieren hat.
In einer realen Anwendung würden jedoch noch einige
Objekttypen hinzukommen, z.B. "Auftrag", "Analysenmethode",
"Rohdaten", "Resultate" etc. Um die bereits
recht komplexen Beziehungen korrekt wiederzugeben, hat sich als
Planungshilfe die sogenannte "Entity-Relationship"-Darstellungsmethode
sehr bewährt. Bei unserem einfachen Beispiel würde dies wie in
Abb. 3 aussehen.

Als Datenbanksystem wird ein Programm bezeichnet, das die
Verwaltung von Daten in der gezeigten Form übernimmt, ohne auf
eine bestimmte Aufgabe gebunden zu sein. Letztere wird erst im
Rahmen der Datendefinition festgelegt; die meisten Systeme
erlauben es überdies, dass mehrere unabhängige Anwendungen mit
unterschiedlichen Objekttypen zum selben Zeitpunkt vom
Datenbanksystem unterstützt werden.
Die Datendefinition (z.B. die Bekanntgabe an das System,
welche Objekttypen mit welchen Attributen und Beziehungen
existieren) wurde bereits erwähnt; weitere Kernbereiche des
Datenbanksystems sind Datenmanipulation (Eingabe, Änderung, Löschen)
sowie Datenabfrage. Die zuletzt genannte Funktion erlaubt es auch,
aus einer Vielzahl von Datensätzen einen oder mehrere
herauszufinden, die ganz bestimmten Kriterien genügen, z.B.
einen Kunden, dessen Nachname mit "M" beginnt, der in
Salzburg wohnhaft ist und der zwischen September und November
1993 zwei Aufträge erteilt hat. Alle drei Kernfunktionen werden
von der weitverbreiteten Datenbanksprache "SQL" (structured
query language) unterstützt. Wichtig ist vor allem, dass diese
Funktionen sowohl manuell als auch über spezielle Programme
offenstehen, um volle Flexibilität zu erzielen.
Neben den Funktionen Datendefinition, Datenmanipulation und
Datenabfrage bieten die meisten Systeme auch Unterstützung bei
der Datensicherung (Backups), Export/Import-Fähigkeiten (Datenaustausch
mit verschiedenen Programmen wie Textverarbeitung,
Tabellenkalkulation etc.) sowie die sogenannte
Transaktionskontrolle. Unter dem zuletzt genannten Schlagwort
sind Verfahren zu verstehen, die Änderungen des Datenbestandes
nur dann zulassen, wenn sie formell abgeschlossen werden. Ein
negatives Beispiel hierfür wäre eine Banküberweisung, bei der
der Betrag von einem Konto abgebucht wird, aber wegen eines
Rechnerabsturzes beim anderen Konto nicht gutgeschrieben wird.
Die Transaktionskontrolle würde in diesem Fall die Überweisung
nicht durchführen, sondern den letzten sinnvollen Zustand vor
dem Absturz beibehalten.
Im Mehrbenutzerbetrieb sind darüber hinaus noch
Sperrmechanismen erforderlich, die ebenfalls vom Datenbanksystem
geboten werden. Diese verhindern, dass durch gleichzeitiges
Bearbeiten eines Datensatzes durch mehrere Anwender unsinnige
oder unvollständige Daten entstehen.
Datenbankmodelle
Die heute am Markt befindlichen Datenbanksysteme lassen sich
im wesentlichen in drei Gruppen ("Datenbankmodelle")
einordnen: hierarchische, Netzwerk- sowie relationale Datenbanken.
Systeme, die dem hierarchischen Modell angehören, kommen
wegen ihrer geringen Flexibilität heute für Neuinstallationen
kaum mehr in Frage. Netzwerk-Datenbanken stellen gewissenermaßen
eine Erweiterung des Konzepts an die realen Erfordernisse dar, während
relationale Datenbanken unabhängig davon nach der sogenannten
Relationentheorie entwickelt wurden.
Netzwerk-Datenbanken zeichnen sich vor allem durch sehr hohe
Arbeitsgeschwindigkeit aus, während ihre relationalen Gegenstücke
bei der Entwicklung und Anpassung der gewünschten Anwendungen
besonders komfortabel zu handhaben sind. Aus diesem Grund werden
kleine und mittlere Anwendungen, bei denen maximale
Arbeitsgeschwindigkeit nicht das wichtigste Kriterium ist, zum
Großteil mit relationalen Datenbanken realisiert. Durch die
bereits erwähnte Sprache "SQL", die bei diesen
Datenbanken sich als quasi-Standard etabliert hat, sind auch
bestimmte Anwendungen relativ leicht auf andere Rechner und
Datenbanksysteme zu übertragen.
Bekannte Vertreter relationaler Systeme sind die Produkte
"ORACLE", "INFORMIX" oder "INGRES";
die auf Personal Computern wesentlich häufiger eingesetzten
Programme "DBASE", "Access" oder "Paradox"
etc. können in nicht allzu komplexen Anwendungen gut eingesetzt
werden, sind aber bei umfangreicheren Anforderungen und
Mehrbenutzerbetrieb meist überfordert. Allerdings holen die
zuletzt genannten Systeme in den letzten Jahren deutlich auf.
Anwendungsbeispiele im Labor
Die "klassische" Anwendung von Datenbanksystemen im
Labor sind wohl
Laborinformationssysteme (LIMS),
die in größeren Betrieben bereits seit geraumer Zeit im Einsatz
sind. Kernbereich dieser Programme ist die Verwaltung der
Analysenaufträge, also die Verfolgung der Proben von
Probeziehung bis zum Ausdruck des Analysenzertifikats. In den
letzten Jahren existiert aber ein starker Trend, auch andere
laborrelevante Verwaltungstätigkeiten in diese Systeme zu
integrieren. In diesem Sinn wären diverse Lagerhaltungsaufgaben
(z.B. Chemikalien) oder die Verwaltung von
Standardarbeitsanweisungen (SOPs), Normen, Grenzwerten oder
Literaturstellen erwähnenswert. Darüber hinaus liefern LIMS oft
auch diverse Auslastungsstatistiken, die zur Verbesserung der
Laboreffizienz genützt werden können. Da der Zugriff auf die
Daten durch mehrere Personen zum selben Zeitpunkt erforderlich
sein kann, sind die Systeme nahezu immer für Mehrbenutzerbetrieb
vorgesehen.
Als Beispiel, wie die Datenbankstruktur eines
Laborinformationssystems aussehen könnte, soll im folgenden ein
entsprechender Teil des Labor-EDV-Systems "LIME" (Laboratory
Integration Multiuser Environment) erläutert werden. Dabei
findet die weiter oben beschriebene Entity-Relationship-Darstellung
Verwendung, da sie auch komplexere Strukturen, wie sie im
vorliegenden Fall auftreten, gut überschaubar macht (Abb. 4).

Für jede einlangende Probe wird mit Hilfe des "Probentyps"
definiert, welche Analysenverfahren anzuwenden sind. Nach
Feststehen aller geforderten Resultate und deren Freigabe durch
einen autorisierten Anwender kann ein Analysenzertifikat gedruckt
werden, dessen Format durch das definierte Report-Formular
festgelegt wird. Soweit erforderlich, können auch der zugehörige
Auftrag sowie der Auftraggeber jeder Probe, wie auch SOPs,
Grenzwerte, Normen, Literatur etc. verwaltet werden. In Abb. 4
aus Gründen der Übersichtlichkeit nicht aufgeführt, aber in
der Praxis nicht selten ebenfalls relevant sind schließlich
Lagerhaltung, Personaldaten etc.
Weniger verbreitet, aber kaum weniger sinnvoll, ist der
Datenbankeinsatz auch für Datenaufnahme und Auswertung, also die
Entstehung der Rohdaten sowie deren Interpretation zu
Analysenresultaten. Abb. 5 zeigt, wie dieser Sektor in LIME
realisiert ist: Die Datenerfassungs-Methode definiert, auf welche
Weise die Rohdaten (z.B. ein Chromatogramm) zustandekommen; die
Auswertungs-Methode hingegen enthält die Informationen, die die
Interpretation der Rohdaten ermöglichen, also z.B.
Integrationsparameter, Retentionszeiten, Eichkurven etc. Ergebnis
der Auswertung sind schließlich die "Resultate", die
als Liste von Parameter-Wert-Einheit zu verstehen sind (z.B.
"Glucose: 10.5 g/l; Saccharose: 28.4 g/l"). Vor allem
durch den Objekttyp "Proben" wird der Zusammenhang mit
dem LIMS-Teil hergestellt.

Durch die Verwendung einer Datenbank auch in diesem Bereich
lassen sich die meisten der weiter oben erwähnten Probleme gängiger
Datensysteme effizient lösen: Das Auffinden einzelner Rohdaten,
Resultate, Aufträge etc. ist durch die flexiblen Suchmöglichkeiten
(Queries) keine Schwierigkeit. Auch in puncto Datensicherheit
bieten Datenbanksysteme erhebliche Vorteile in der Abwehr von
unberechtigten, vor allem aber von unbeabsichtigten Lösch- oder
Änderungsvorgängen, die ein späteres Nachvollziehen der Labortätigkeit
unmöglich machen würden. Durch ihre offene Architektur ist
weiters ein Zugriff auf alle relevanten Daten auch über Fremd-
und Individualsoftware leicht möglich; außerdem stellen
Datenbanksysteme von sich aus die zusätzlichen Mechanismen für
einen korrekten Mehrbenutzerbetrieb zur Verfügung.
Für diejenigen Leser, die etwas tiefer in diese Materie
eindringen möchten, empfehlen sich die folgenden Lehrbücher,
die keine besonderen EDV-Kenntnisse voraussetzen:
- Date, C.J., "An Introduction to Database Systems",
Vol. 1 und 2, Addison-Wesley, Reading/MA 1986.
- Fischer, J., "Datenmanagement - Datenbanken und
betriebliche Datenmodellierung", Oldenbourg-Verlag, München
1992.
- Schlageter, G. und Stucky, W., "Datenbanksysteme:
Konzepte und Modelle", Verlag Teubner, Stuttgart 1983.