Datenbank-Einsatz im Labor

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", "Microsoft SQL Server" oder "Sybase SQL Anywhere"; die auf Personal Computern häufiger eingesetzten Programme wie Microsoft Acess 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:

  1. Date, C.J., "An Introduction to Database Systems", Vol. 1 und 2, Addison-Wesley, Reading/MA 1986.
  2. Fischer, J., "Datenmanagement - Datenbanken und betriebliche Datenmodellierung", Oldenbourg-Verlag, München 1992.
  3. Schlageter, G. und Stucky, W., "Datenbanksysteme: Konzepte und Modelle", Verlag Teubner, Stuttgart 1983.