Eins, zwei ... viele
Und diese "Objekte" (wie wir sie vereinfachend nennen möchten) stehen natürlich fast immer auch untereinander in einer bestimmten Beziehung. Eine Probe gehört also zu einem Untersuchungsauftrag und die zu bestimmenden Parameter sind wiederum mit der Probe verbunden.
Dabei gibt es aber grundlegende Unterschiede, nämlich ob einem Exemplar aus einer Objektart immer genau mit einem zugehörigen aus der anderen Objektart verbunden ist, zum Beispiel wenn es für jeden Auftrag genau einen Untersuchungsbericht gibt - im Fachjargon kurz als "1:1-Beziehung" bezeichnet. In der Praxis viel häufiger sind aber die sogenannten "1:N" oder "M:N"-Beziehungen.
"1:N" bedeutet, dass ein Objekt aus einer Objektart (z.B. ein konkreter Auftrag) mit einem (evtl. auch gar keinem), aber möglicherweise auch mehreren Objekten der anderen Objektart (z.B. Probe) verbunden sein kann. Ein Auftrag wird also eine, in den allermeisten Fällen aber mehrere Proben enthalten, während umgekehrt die Probe genau einem Auftrag zugeordnet ist.
"M:N" hingegen zeigt an, dass ein Objekt einer Objektart (z.B. eine Probe) mehreren Objekten einer anderen Art (z.B. zu messender Parameter) zugeordnet sein kann, dasselbe aber auch für die andere Richtung gilt. In einer Probe werden also meist mehrere Parameter bestimmt, jeder Parameter kann aber natürlich in vielen Proben gemessen werden.
Wie soll man das nun in der Praxis umsetzen? Auf den ersten Blick klingt es vernünftig, alle Beziehungen zwischen Objektarten immer mit der "M:N"-Variante zu realisieren, da man damit einfach maximale Flexibilität hat. Wenn eine Probe normalerweise immer genau einem Auftrag zugeordnet ist, gibt es bestimmt von Zeit zu Zeit "Spezialfälle", wo die Probe in mehreren Aufträge benötigt wird.
Leider ist es in der Praxis aber doch nicht so einfach, denn die M:N-Beziehung braucht im Vergleich zu 1:N (oder 1:1) eine zusätzliche Zwischentabelle in der Datenbank und verkompliziert und verlangsamt die entsprechende Abfrage. Je nach Datenmenge, Leistungsfähigkeit der Hardware und anderen Faktoren vielleicht nur geringfügig, vielleicht aber auch massiv. Dazu ergeben sich auch weitere Unklarheiten und Probleme.
Wenn man einen Analysenbericht für eine Probe erstellen möchte, braucht man vielleicht auch Daten des zugehörigen Auftrags, z.B. die Adresse des Auftraggebers. Falls es nun aber gleich mehrere gibt, muss man dem entsprechend Rechnung tragen - sollen alle Adressen ausgegeben werden? Oder gibt es einen "primären" Auftrag. Oder soll das LIMS den Anwender konkret fragen, welchen Auftrag man hier möchte - alles das wäre bei der 1:N-Variante gar nicht aufgetreten.
Kurz gesagt, maximale Flexibilität wird auch mit gewissen "Nebenwirkungen" oder Erschwernissen erkauft und man tut gut daran, ganz seltene "Sonderfälle" hier außer Betracht zu lassen.
