DE69709918T2

DE69709918T2 - Relationelle datenbank die in einer speicherstruktur compiliert und gespeichert ist

Info

Publication number: DE69709918T2
Application number: DE69709918T
Authority: DE
Inventors: Bart Van Den Bosch
Original assignee: Universitaire Ziekenhuizen Leuven
Current assignee: Universitaire Ziekenhuizen Leuven
Priority date: 1996-05-22
Filing date: 1997-05-21
Publication date: 2009-09-24
Anticipated expiration: 2017-05-22
Also published as: CA2253345C; ATE211839T1; DE69709918D1; EP0898753A1; CA2253345A1; AU723011B2; EP0898753B1; AU2881997A; WO1997044745A1

Description

Gebiet der Erfindung
Die vorliegende Erfindung bezieht sich auf eine relationelle Datenbank, die in einer Speicherstruktur kompiliert/gespeichert ist und die durch den Zugang durch Anwendungsprogramme angepasst wird, die eine Abfrage innerhalb der besagten Datenbank ausführen.
Die vorliegende Erfindung bezieht sich spezifischer gesehen auf ein System für die Entwicklung von Software, die in dem besagten Computer kompiliert werden soll.
Hintergrund der Erfindung
Eine Datenbank nimmt einen großen Teil der Last der Speicherung und der Verwaltung der Daten aus der Anwendung heraus.
Die Vorteile des Gebrauchs einer Datenbank sind vielfältig. Die bedeutendsten Vorteile sind: zentralisierte Kontrolle der Speicherung der Daten; gemeinsame Nutzung der Daten (zwischen den Anwendungen und den Benutzern), zentralisierte Sicherheit, Steuerung gleichzeitiger Zugriffe, Reduktion von Redundanz, ....
Systeme zur Verwaltung von Datenbanken sind im Handel verfügbar für praktisch jede Computerplattform. Die Technologie hat sich selbst bewährt und es ist kostengünstig eine Datenbank zu benutzen. Die Alternative zu dem Gebrauch einer Datenbank besteht in der Verwendung von Computerdateien, um Daten zu speichern. Die Anwendung ist verantwortlich für jede der oben erwähnten Datenbankaufgaben. Gewöhnlich wählt man diese Option nur, wenn keine Notwendigkeit besteht für die Steuerung gleichzeitiger Zugriffe, für eine Teilung der Daten, für die Sicherheit, Dies ist fast nur der Fall bei Systemen für Einzelbenutzer (PC).
Es gibt mehrere mögliche Ansätze bei dem Aufbau eines Managementsystems für eine Datenbank, aber der bedeutendste ist der relationelle Ansatz. Relationelle Datenbankmanagementsysteme wurden im Handel verfügbar gegen Ende der 70er Jahre. Ihr Hauptvorteil gegenüber der damals existierenden Datenbanktechnologie bestand darin, dass sie die Sicht vereinfachte, die der Benutzer von den Daten hatte. Eine sehr lockere Definition eines relationellen Managementsystems einer Datenbank wird nachstehend wie folgt gegeben: ein relationelles System ist ein System, in dem die Daten von dem Benutzer als Tabellen (und als nichts anderes als Tabellen) wahrgenommen werden; und die Operatoren, die dem Benutzer zur Verfügung stehen (zum Beispiel für die Suche von Daten), sind Operatoren, die neue Tabellen aus den alten Tabellen erzeugen. Diese Definition betrachtet ein relationelles Datenbankmanagementsystem aus der Sicht des Benutzers. Das tatsächliche Speicherformat der Daten ist natürlich weit aus komplizierter. Aber dies zeigt den Hauptvorteil der relationellen Systeme: der Benutzer hat nur mit der vereinfachten Sichtweise zu tun und ist vollkommen abgeschirmt gegen die untere Ebene der Implementierungsstrukturen.
Die Verkäufer von relationellen Systemen haben den Weg des Zugriffes auf eine relationelle Datenbank standardisiert. Praktischerweise unterstützen alle Datenbanken SQL (Structured Query Language = strukturierte Abfragesprache). SQL ist die Sprache, mit welcher der Benutzer neue Tabellen aus den existierenden Tabellen schaffen kann. SQL ist eine deklarative Sprache: die Benutzer spezifizieren welche Daten gesucht werden sollen und aus welchen Tabellen, aber nicht, wie sie gesucht werden müssen. Da der Benutzer über kein Wissen bezüglich der zugrunde liegenden physikalischen Datenstrukturen verfügt, ist es für ihn unmöglich zu entscheiden, wie die Daten gesucht werden sollten. Daher muss das System jede SQL Anweisung in einen Abfragepfad übersetzen. Dieser spezifiziert, wie auf die physikalischen Strukturen zugegriffen wird, um die Daten herauszufinden.
Gewöhnlich sind viele Abfragepfade möglich für eine SQL Abfrage. Fast alle relationellen Systeme haben jetzt eine Komponente, die man Optimierer für Abfragen nennt bzw. query optimizer. Der Optimierer für Abfragen wählt den Pfad aus, der wahrscheinlich das gewünschte Ergebnis in der kürzesten Zeit liefern wird. Um das Auffinden von Daten zu beschleunigen, kann der Verwalter der Datenbank Indices definieren. Ein Index ist eine Datenstruktur, die alle Werte für eine besondere Kolonne in irgendeiner Tabelle speichert und eine Referenz zu den Zeilen behält, welche diesen Wert enthalten. Die Werte werden in einer Struktur gespeichert, die ein schnelles Auffinden eines besonderen Wertes ermöglichen. Wenn ein Benutzer wünscht, alle Zeilen, die einen besonderen Wert enthalten, ausfindig zu machen, dann kann das System nach dem Wert in dem Index Nachschau halten, die Referenzen zu den Zeilen, die diesen Wert enthalten, ausfindig machen und diese Referenzen dann verwenden, um direkt die Zeilen zu finden. Dies wird schneller sein als ein Scannen bzw. ein Durchforsten der gesamten Tabelle und ein Nachprüfen einer jeden Zeile nach dem spezifischen Wert, weil der Index kleiner ist, der Index ist so strukturiert, dass der relevante Wert herausgefunden werden kann ohne das Durchforsten bzw. Durchscannen des gesamten Indexes. Der wesentliche Anstieg der Leistung kommt von der Verringerung der Anzahl der Plattenzugriffe. Die Platte ist ein mechanisches Gerät und ist langsam im Vergleich zu dem Zugriff zum internen Speicher. Indices sind verborgen für den Benutzer und die Ergebnisse der Abfrage sind die gleichen, egal ob die Indices verwendet werden oder nicht.
Der Optimierer für Abfragen entscheidet, welche Indices verwendet werden und in welcher Reihenfolge. Um diese Entscheidung zu treffen zieht der Optimierer für Abfragen in seine Überlegungen mit ein, die Länge der Tabellen, die Verfügbarkeit der Indices, die Selektivität des Index, .... Er wird immer versuchen die Anzahl der Zeilen, die durchsucht werden müssen, so früh wie möglich in der Abfrage zu verringern. Die Auswahl eines Abfragepfades erfolgt mit Hilfe heuristischer Methoden, so dass nicht garantiert werden kann, dass der Optimierer den optimalen Abfragepfad herstellen wird. Wie man später sehen wird, verfügt der Optimierer oft nicht über ausreichend Information, um den optimalen Abfragepfad zu erzeugen. Dies ist oft der Fall für komplexe Abfragen und dann kann man dem Optimierer helfen, indem man die Abfrage in kleinere Teile aufteilt, welche leichter zu optimieren sind.
Problemdefinition
Wenn ein Datenmodell „bei jemanden die Sicht formt und bei jemanden die Wahrnehmung begrenzt", dann muss die Anzahl dieser Begrenzungen so gering wie möglich sein und das Formen sollte nicht verzerrend sein. Diese Gestaltung und Begrenzung der Sicht von der Welt bzw. der Umgebung ist teilweise ein bevorzugter Effekt: sie strukturiert die Sicht, die jemand von der Umgebung hat, und sie richtet den Brennpunkt auf denjenigen Teil der Daten, die unter Einsatz eines Computers bearbeitet und verändert werden sollen. Daher ist ein Datenmodell Gegenstand von drei größeren Kräften, nämlich:

• dem Wunsch, eine definierte Umgebung von Interesse so vollständig wie nur möglich zu modellieren,
• der Struktur, die diesem Modell der Umgebung auferlegt werden soll, und
• den Begrenzungen des Komplexitätsgrades im Zusammenhang mit der Hardware und der Software.

Mit der Zeit ändert sich die Realität genauso wie sich die Sichten ändert, die jemand von der Realität hat. Aus diesen Gründen kann es sein, dass Datenmodelle geändert werden müssen im Verlauf der Lebensdauer einer Anwendung. Die Aktualisierungen eines Datenmodells sind kostspielig, betrachtet man den Aufwand an menschlichen Ressourcen. Daher sollte ein Datenmodell gegenüber der Zeit resistent sein.
Das Modell sollte es auch ermöglichen, dass irgendwelche Datenstruktur eingeführt werden kann, denn eine Begrenzung dessen was eingeführt werden kann, würde auch eine Eingrenzung der Sicht der Umgebung darstellen, die jemand durch das Modell bekommt. Auf diese Weise kann jede Information ohne Verzerrung eingeholt werden und verschiedene Modelle können aus diesen Rohdaten abgeleitet werden. Das Modell wird nur von den Rohdaten abgeleitet. Kein Teil des Modells wird impliziert oder durch die internen Datenstrukturen verstärkt, da jeglicher Typ von Struktur eingegeben werden kann. Wenn das Modell nur auf der Deduktion beruht, dann macht auch dies das Modell gegenüber der Zeit resistent. Um das Modell zu ändern, braucht man „nur" die Deduktionen zu ändern, nicht die Darstellung der Daten. Ein anderer Vorteil besteht darin, dass mehrere Modelle zur gleichen Zeit auf der Grundlage der gleichen Rohdaten abgeleitet (und verwendet) werden können. Da die Daten wirklich „roh" sind, das heißt dass sie nicht verzerrt sind, um sich an die Struktur der internen Darstellung der Daten anzupassen, können diese Daten als Wahrheiten oder Gesamtdaten angesehen werden: irgend jemand hat zu einem bestimmten Zeitpunkt festgestellt, dass X wahr war. Die Eingabe von Daten bedeutet das Hinzufügen einer Nachricht zu einem gigantischen Pool von Nachrichten. Die Welt ist chaotisch und die Struktur des zu modellierenden Chaos liegt in dem Auge des Beobachters. Das Problem besteht darin; je weniger Information in der Darstellung der Daten liegt, desto mehr Information muss abgeleitet werden. Wenn es keine inhärente Struktur in der internen Darstellung der Daten gibt, dann wird dies zu einer gigantischen Aufgabe. Man handelt Freiheit der Speicherung gegen Komplexität der Deduktion. Die gegenwärtige Technologie der Datenbanken ermöglicht diese Freiheit der Speicherung nicht.
Relationelle Datenbanken gehören zum Stand der Technik, aber sie haben ein viel starreres Speicherformat als oben beschrieben worden ist. In einer relationellen Datenbank werden die Daten in der Form von Tabellen dargestellt. Eine Tabelle besitzt Kolonnen und Zeilen, die Sätze bzw. Datensätze oder Tupeln genannt werden. So wird für einen jeden Typ einer Nachricht eine Tabelle definiert, um alle Nachrichten von diesem Typ zu speichern. Eine Nachricht wird zu einer Zeile in dieser Tabelle. Tabellen müssen definiert werden, bevor Daten in denselben gespeichert werden können. Dies begrenzt die Freiheit: vorauszusehen welche Typen von Nachrichten benötigt werden. Weil die Strukturen vorher geschaffen werden müssen, können die Benutzer keine Nachrichten hinzufügen, die nicht angenommen waren. Durch die Verwendung einer Suchsprache kann der Programmierer neue virtuelle Tabellen („Sichtweisen” genannt) aus anderen Tabellen deduzieren, d. h. ableiten. Eine Abfrage ist eine Deduktion oder Herleitung aus einem Satz von Tupeln (Sichtweisen) aus verschiedenen anderen Sätzen von Tupeln (Tabellen und Sichtweisen). Eine typische Datenbank kann mit Abfragen umgehen, die bis zu 16 Tabellen verwenden, aber eine Abfrage mit 16 Tabellen ist bei weitem zu langsam, um dieselbe in einem interaktiven online-System anzuwenden. Dies begrenzt in erheblichem Maße den Grad der Komplexität der Deduktionen, die für Abfragen möglich sind, welche schnelle Antwortzeiten erfordern.
Es ist eine Option, eine Strategie für die Datenmodellierung zu wählen, die alle Rohdaten erfasst. Dies wird in der Form von Nachrichten bewerkstelligt. Eine Nachricht ist der Inhalt einer elektronischen Form. Die Nachrichten sind in ihrem Wesen Befehle/Anweisungen oder wesentliche Inhalte und sie besitzen die implizite generische Form von „Benutzer X zur Zeit Y legt fest, dass Z wahr ist". Dies impliziert, dass das Datenmodell additiv ist: neue Information wird als eine neue Nachricht hinzugefügt. Nachrichten werden niemals aktualisiert: eine Nachricht, die zu einem bestimmten Zeitpunkt wahr ist, wird später immer zu diesem Zeitpunkt wahr gewesen sein. Eine neue Nachricht kann einer alten Nachricht widersprechen oder sie ersetzen, aber die Feststellung für welche die alte Nachricht steht bleibt wahr. So ist vom Konzept her eine Aktualisierung (ein Updating) in dieser Strategie der Datenmodellierung nicht erlaubt. Es gibt einen Grund, warum Updates hier erlaubt sind: der Benutzer kann sich täuschen und könnte einen (Eingabe)Irrtum begangen haben, als er eine Nachricht zu dem System hinzugefügte. Diese Irrtümer müssen korrigiert werden. Die Lösung besteht darin, eine andere Nachricht des gleichen Typs an die Datenbank zu senden und festzulegen, dass die neue Nachricht eine Korrektur zu der vorangegangenen Nachricht darstellt. Die alte Nachricht wird nur logisch weggelassen, d. h. in der Deduktion des vorliegenden Modells wird eine Nachricht in den meisten Fällen ignoriert, immer dann wenn eine andere Nachricht existiert, welche dieselbe korrigiert. An der Schnittstelle kann der Benutzer den Inhalt der elektronischen Form korrigieren und mit einem Mausklick die neue Nachricht senden. Von der Logik her überschreibt das System automatisch die alte Version und verbindet die neue Version mit der alten.
Gemäß dieser Option wird die Datenbank anwachsen, während die Leistung bei der Durchführung der Abfragen abnimmt. Dies ist ein Flaschenhals der mit dem unbegrenzten Wachstum der Datenbank verbunden ist. Der nächste Flaschenhals der auftritt besteht in der Zeit für die Wiederherstellung. Je umfangreicher die Datenbank, desto länger dauert es, von derselben eine Sicherung (Backup) oder ein Neuladen (Reload) von einem Band durchzuführen in dem Falle wo ein Fehler des Speichermediums auftritt.
Zusammenfassung der Erfindung
Um eine klare Vorstellung von den wesentlichen Merkmalen der vorliegenden Erfindung zu haben, werden nachstehend einige Definitionen gegeben.
Konzepttabellen sind Tabellen aus einem ersten Satz von Tabellen, die verändert werden können durch Hinzufügen eines anderen Tupels mit Daten zu der Tabelle.
Nicht-Konzepttabellen sind Tabellen aus einem zweiten Satz von Tabellen, die durch eine Aktion, welcher Art auch immer, verändert werden können, z. B.:

• Aktualisieren (update) einer Kolonne eines Tupels
• Hinzufügen eines anderen Tupels
• Aktualisieren/Ändern von einem Tupel
• Löschung von Tupeln
• usw.

In der vorliegenden Erfindung können Daten definiert werden als:

• ein Tupel,
• eine Kolonne,
• ein Element aus dem Kreuz einer Kolonne und eines Tupels, oder
• Teile derselben.

Systeme für das Datenbankmanagement speichern Meta-Daten; dies sind Daten über Daten. Diese Daten werden in dem Datenwörterbuch gehalten. Typische Meta-Daten sind die Typen [Zeichen (character), ganze Zahl (integer), reelle Zahl (real number), ...] für eine jede der Kolonnen in einer Tabelle. Meta-Daten werden von dem System verwendet, um das System auf Fehler zu überprüfen.
Redundanz sollte verstanden werden als:

• eine Kopie von Daten,
• eine „Ableitung" von irgendwelchen Daten, wie: – eine Operation (Multiplikation, Division, Prozent, Kombination, Verifizierung der Vorliegens von, ...) an irgendwelchen Daten, wobei nur ein Datenpunkt verwendet wird, – eine Operation (Multiplikation, Division, Prozent, Kombination, Verifizierung der Vorliegens von, ...) an irgendwelchen Daten, wobei mehrere Datenpunkte (Tupels, Kolonnen in der gleichen Tabelle oder in mehreren Tabellen) verwendet werden

Eine Anwendung kann definiert werden als ein Satz von Programmen, die eine spezifische Funktionalität integrieren.
Ein Dienst kann definiert werden als eine Handlung, die angefordert wird für einen Patienten oder die von einem Patienten ausgeführt wird. Zum Beispiel kann eine Typ einer Dienstleistung irgendeine Handlung seitens der Radiologie oder der Pflegeabteilung sein.
Schließlich ist eine Einheit (oder eine Arbeitseinheit) eine Einheit von Handlungen bzw. Aktionen, die in einer bestimmten Reihenfolge ausgeführt werden (die Einheit wird erbracht durch die Einheit eines Patienten, durch die Einheit der Behandlung, durch die Einheit der Dienstleistung, ...).
Die vorliegende Erfindung wird in den Ansprüchen 1 und 37 definiert. Weitere Ausführungsformen werden in den abhängigen Ansprüchen beschrieben.
Spezifischer gesehen wird die vorliegende Erfindung beschrieben im Zusammenhang mit einem Arbeitsplatz (workstation) innerhalb einer Klinik und die Integration desselben in ein bestehendes Verwaltungssystem, um ein Informationssystem für ein Krankenhaus zu gestalten.
Es wurde der Entschluss gefasst, nicht jede Anwendung getrennt zu bauen, sondern eine Basisschicht einer Software (den Generator) zu erstellen und oben auf dieser Basis wurden Anwendungen aufgebaut. Der Generator besteht aus drei Hauptmodulen, einer für den Umgang mit der grafischen Benutzerschnittstelle, einer für den Umgang mit dem Zugriff zu der Datenbank und einer für die Einbindung des Paradigmas der grundlegenden Benutzerschnittstelle. Dieses letzte Modul bindet die beiden anderen Module funktionell zusammen.
Gemäss einer bevorzugten Ausführung der vorliegenden Erfindung verwendet der Generator Sybase als die Datenbasis, Prolog als die Anwendungssprache, MacArbeitsplatz und spätere X-Windows für die grafische Benutzerschnittstelle.
Die Bestimmung des Generators besteht darin:

• die Anwendungen von den darunterliegenden Softwarekomponenten abzuschirmen. Dies verringert die Abhängigkeit von denselben;
• einen höheren Grad an Funktionalität der Schnittstelle für diese Komponenten zur Verfügung zu stellen. Dieser erlaubt eine schnellere Anwendungsentwicklung, denn er ermöglicht es größere Baublöcke zu verwenden;
• eine Unterstützung für ein Paradigma zu ergeben bezüglich einer grundlegenden Benutzerschnittstelle und eines Datenmodells. Wenn man dies in den Generator mit einbezieht, dann führt dies dazu, dass sich alle Anwendungen diese gemeinsamen Merkmale teilen. Dies gestaltet das System benutzerfreundlicher und leichter zu beherrschen.

Eine neue Strategie der Datenmodellierung wird hierin offenbart. Diese Strategie unterscheidet zwei Typen von Datentabellen:

• Konzepttabellen sind bei der Anwendung und ihren Benutzern bekannt. Sie bilden die Umgebung des Interesses.
• Nicht-Konzepttabellen existieren nicht vom Standpunkt der Ansicht aus gesehen. Sie enthalten redundante Daten und verkörpern ein alternatives Datenmodell.

Beide, sowohl die Leistung als auch der Entwurf, ziehen Vorteile aus der Trennung der Tabellen in zwei Klassen:

• die Leistung wird vergrößert, indem man den Nicht-Konzepttabellen ein Datenmodell verleiht, das jene Abfragen erleichtert, die keine gute Leistung aufweisen, wenn sie auf den Konzepttabellen bearbeitet werden. Gewöhnlich wird nur die minimale Information gespeichert, die notwendig ist, um die Behandlung dieser Abfragen zu beschleunigen;
• der Entwurf wird erleichtert, weil weniger Kompromisse hinsichtlich der Leistung bei dem Aufbau von konzeptuellen Datenmodellen eingegangen werden müssen. Bei der Verwendung dieser Technik ist der Entwurf für die Ausdrucksfähigkeit getrennt von dem Entwurf für die Leistung.

Für eine bevorzugte Ausführung der vorliegenden Systemanwendung gemäss der vorliegenden Erfindung (Konzeptmodell nach dem System 9 genannt) wurden mehrere Spezifikationen entwickelt:

• das Datenmodell verfügt über keine Löschung; das bedeutet, dass Daten niemals physikalisch gelöscht werden können, nur logisch;
• das Datenmodell ist additiv. Das bedeutet, dass Updates vom Konzept her in diesem Modell nicht erlaubt sind. Der Dateneintrag wird angesehen als Eingabe von wahren Aussagen (Nachrichten) von dem Benutzer. Das Datenmodell ist ein Satz mit Tabellen für strukturierte Nachrichten. Normalerweise braucht eine Nachricht nicht korrigiert zu werden, es sei denn, es wurde ein Irrtum gegangen. Da das Modell über keine Löschung verfügt, werden beide Versionen der Nachricht beibehalten, wenn dieselbe korrigiert wird.

Das vorliegende System des Konzeptmodells gemäss der vorliegenden Erfindung besteht aus drei verschiedenen Ebenen:

• die physikalische Ebene beherbergt alle Daten, ob logisch gelöscht oder nicht;
• die konzeptuelle Ebene ist auf der Spitze der physikalischen Ebene definiert und zeigt die laufende Version der Nachrichten. Dies ist die Ebene, auf welcher der Generator operiert;
• die Anwendungsebene definiert die Beziehungen zwischen den Nachrichten.

Diese vier Datenmodelle (die drei konzeptuellen Ebenen und die Nicht-Konzepttabellen) bilden ein Meta-Modell. Die Verwendung des Meta-Modells ermöglicht eine Beurteilung über das globale Datenmodell: der Generator und die Anwendung operieren auf verschiedenen Ebenen des Konzeptmodells und Leistungsprobleme werden in den Nicht-Konzepttabellen gelöst. Jedes Modell besitzt eine spezifische Funktion in der Gesamtheit der Anwendung.
Während der Entwicklung des Systems wurde die elektronische Form als das grundlegende Schnittstellenobjekt gewählt.
Der Benutzer interagiert mit dem System durch das Senden und das Sichten von elektronischen Formen. Diese einer elektronischen Post ähnliche Metapher stimmt gut überein mit einem Datenmodell, das über keine Löschung verfügt und das additiv ist. Die grundlegenden Formoperationen werden in den Generator implementiert und brauchen nicht in jeder Anwendung implementiert zu werden.
Als ein wesentliches Element in der Benutzerschnittstelle wurde die Instrumententafel (dashboard) entwickelt. Die Instrumententafel ist das wesentliche Instrument, um zwischen verschiedenen Funktionen der elektronischen medizinischen Eintragungen bezüglich eines Patienten zu navigieren. Es wurde für die erste Anwendung des vorliegenden Systems entwickelt, und es wurde in allen nachfolgenden Anwendungen wiederholt. In einer gewissen Art bündelt die Instrumententafel die Daten für einen Patienten und schafft eine virtuelle elektronische medizinische Datei.
Um das Problem der Implementierung der Vielfalt zu lösen, die mit der Befehlseintragung inhärent verbunden ist, wurde ein generisches Werkzeug entwickelt, das die Grundlage für eine jede Befehlseintragung bildet. Mehrere Teilprobleme wurden gelöst, nämlich:

• ein Paradigma einer Schnittstelle, bestehend aus einem Selektor, aus einem Editor und aus einem Kollektor, wurde entwickelt. Diese drei Elemente interagieren in einer standardisierten Weise bei allen Anwendungen einer Befehlseintragung. Regelgrundlagen werden verwendet, um das Verhalten für eine spezifische Funktionalität zu steuern;
• die logischen Datenstrukturen, die verwendet werden, um Anweisungen/Befehle in diesem System darzustellen, mussten in das starrere relationelle Format übersetzt werden. Alle Strukturen werden in einem Satz von vier Tabellen gespeichert, indem dieselben in ein kanonisches Format übersetzt werden, wobei ein Regelwerk als Basis verwendet wird. Dadurch kann mit der Vielfalt der Befehlseintragungen umgegangen werden, ohne dass eine nicht aufrechtzuerhaltende Anzahl von Datenbankobjekten geschaffen wird.

Der Generator, der hier offenbart wird, unterstützt die Metapher der Benutzerschnittstelle und die Strategie der Datenmodellierung. Es ist die Basis für alle drei implementierten klinischen Anwendungen. Dies demonstriert die allgemeine Anwendbarkeit der verwendeten Werkzeuge und Metaphern.
Für den klinischen Arbeitsplatz identifiziert man die generische Funktionalität, die in den klinischen Abteilungen notwendig ist. Diese wurde in den Basismodulen implementiert. Der Umgang mit der Spezifizität einer jeden Abteilung wurde gehandhabt indem ein Regelwerk an Befehlen verwendet wurde. Mehrere Softwarebibliotheken wurden entwickelt, um mit diesen Regeln umzugehen. Das System wurde z. B. angewandt in der Pädiatrie und danach in der Onkologie, Gynäkologie/Geburtshilfe und in den Hals-Nasen-Ohren Abteilungen. Keine größeren Änderungen der Basismodule waren notwendig, um die Unterschiede zwischen diesen Abteilungen zu befriedigen. Alle Unterschiede konnten behandelt werden durch Anpassung der Regelbasis.
Um eine Fragmentierung bzw. eine Zergliederung der klinischen Daten zu vermeiden, ist ein globaler Plan für ein Krankenhaus-Informations-System erforderlich. Dieses System sollte in der Lage sein, beides zu bewerkstelligen, sowohl mit die Verwaltungs- als auch die klinischen Daten, dies in einer integrierten Art und Weise. Es würde notwendig sein, einen klinischen Arbeitsplatz zu bauen oder zu kaufen als eine Ergänzung zu dem Verwaltungssystem. Der klinische Arbeitsplatz war dazu bestimmt die klinische Schnittstelle zu dem System der Krankenhausinformationen zu bilden. Er sollte in der Lage sein, klinische Daten an der Quelle zu erfassen. Diese Daten sollten die Basis für eine elektronische medizinische Aufzeichnung bilden. Das System sollte die Verwendung von Daten für die Zwecke der Verwaltung auf der Hierarchieebene der Abteilung und auf der Ebene des gesamten Krankenhauses erlauben.
Genaue Beschreibung der Erfindung
Die weitere textliche Spezifikation nimmt für die Lehrzwecke nur die Implementierung einer Systementwicklungsoftware an, die auf einem Satz von Computer übersetzt bzw. kompiliert werden soll und ganz besonders für ein Krankenhaus-Informations-System auf einem Netzwerk von Computer und einem Arbeitsplatz gespeichert werden soll.
Sybase war dasjenige unter den ersten relationellen Systemen für das Datenbankmanagement, das sich selbst in Richtung OLTP (On-line Transaction Processing) schaltete. Bei den OLTP Anwendungen werden viele Transaktionen pro Sekunde angefordert und die Anzahl der gleichzeitigen Benutzer ist hoch. Sybase bahnte mit einigen Merkmalen den Weg, welche die Auswahl des Sybase Systems als die vorherrschende Datenbank im klinischen Bereich garantierten.
Der Sybase Server besteht aus einem einzelnen UNIX Prozess. Dies bedeutet, dass alle gleichzeitigen Benutzer von diesem einzigen Prozess befriedigt werden. Der Vorteil besteht darin, dass dieser Prozess eine allgemeine Optimierung des Speichermanagements und des Speicherzugriffs für alle Benutzerprozesse bewerkstelligen kann. Ursprünglich vertraute der größte Teil des Wettbewerbs auf verschiedene Prozesse, die den Server implementieren sollten. Dies überließ viel von der Ablaufplanung für das Betriebssystem übrig, welches leichter zu implementieren ist, welches aber weniger effizient ist, weil das Betriebssystem weniger Information hat, um darauf seine Ablaufplanung zu gründen. Das Betriebssystem „weiß" nicht, was die Prozesse, deren Ablauf es plant, tun und welche ihre Wechselwirkung ist. Indem man alle Benutzerprozesse in einen Serverprozess einbringt, kann dieser Serverprozess Vorteil aus den gegenseitigen Wechselwirkungen der Benutzerprozesse ziehen, um deren Ablauf zu planen.
Mit Sybase ist die Client-software nur eine C Bibliothek. Diese C Bibliothek kann in das Anwendungsprogramm eingebunden werden. Alle Zugriffe auf den Datenbankserver werden durchgeführt durch Aufrufe zu Programmen in dieser Bibliothek. Die Client-software verarbeitet keine Daten. Sie sendet nur die Befehle zu dem Server und findet die daraus entstehenden Ergebniszeilen wieder. Die gesamte andere Verarbeitung wird auf dem Server durchgeführt. Diese Architektur erlaubt es, die Anwendung und die Datenbank auf verschiedenen Servern laufen zu lassen. Die besten Ergebnisse werden erzielt, wenn Sybase seinen eigenen, ihm gewidmeten Server hat, und wenn alle Klienten auf einer anderen Maschine sitzen.
In Sybase können SQL Abfragen als eine Prozedur geschrieben werden. Solch eine Prozedur kann über Parameter verfügen, um Attributwerte an die Abfrage zu übergeben. Prozeduren können auf dem Server kompiliert und gespeichert werden. Um die Ausdrucksfähigkeit zu vergrößern, fügte Sybase zu der SQL-Sprache prozedurale Kontrollanweisungen hinzu (if ... then ... else; while Schleifen). Dies erlaubt es bis zu einem gewissen Umfang, kleinere Programme als auf dem Server gespeicherte Prozeduren zu schreiben. Es gibt mehrere Vorteile für diesen Ansatz:

• die Kompilierung und der größte Teil der Optimierung sind getan, wenn die Prozedur geschaffen ist. Dies beschleunigt das Wiederauffinden, wenn die Prozedur aufgerufen wird. Für Prozeduren, die pro Tag etliche tausend Male aufgerufen werden, vermindert dies auch die allgemeine Belastung des Datenbankservers;
• der Netzwerkverkehr wird vermindert, weil nur der Prozedurname und die Parameter von dem Klienten zu dem Server gesandt werden;
• eine größere Zugangskontrolle. Den Benutzern kann es erlaubt werden, gespeicherte Prozeduren auszuführen, ohne ihnen Zugang zu den darunter liegenden Tabellen zu geben. Dies gibt eine vollständige Kontrolle darüber, über welche Abfragen dem Benutzer die Durchführung erlaubt ist. Wenn notwendig kann die Prozedur (komplizierte) Autorisationsprüfungen durchführen, bevor die aktuelle Abfrage ausgeführt wird;
• wenn die Abfrage neu formuliert wird, dann braucht die Anwendung nicht rekompiliert zu werden, im Gegensatz zu (einigen Implementierungen bei dem) eingebetteten SQL.

Trigger sind eine spezielle Form von gespeicherten Prozeduren, die ausgeführt werden, wenn auf einer Tabelle eine Einfügung, ein Update oder eine Löschung vollzogen wird. Triggers werden innerhalb der gleichen Transaktion ausgeführt wie die Operation, welche dieselben aktiviert hat. Triggers können Prüfungen von Geschäftsregeln durchführen und wenn die Prüfung nachweist, dass die Operation ungültig ist, dann kann der Trigger die Transaktion zum Neuladen zwingen (das heißt, alle Änderungen seit dem Start der Transaktion auflösen). Triggers werden ausgiebig verwendet, um Konsistenzprüfungen durchzuführen und um spezifische Felder und Tabellen des vorliegenden Systemdatenmodells zu unterstützen.
Als Sprache für die Anwendungsentwicklung und für bloße Lehrzwecke wird in der Folge gewählt: Prolog.
Ein Computer wird programmiert, indem man eine Computersprache verwendet. Auf der untersten Ebene führt der Prozessor die Instruktionen aus. Der Satz von Instruktionen, den der Prozessor ausführen kann, wird von dem Hersteller definiert, wenn der Prozessor entworfen wird. Der Hersteller liefert auch eine Sprache, die diese Instruktionen verwendet, um den Prozessor zu programmieren. Solch eine Sprache wird gewöhnlich als Assemblersprache bezeichnet. Eine Assemblersprache ist schwierig zu lesen und zu programmieren, weil sie eine niedrige Programmiersprache ist. Ihre Ausdrucksfähigkeit ist niedrig; das heißt, sogar einfache Programme erfordern viele Instruktionen. Anwendungen werden selten in einer Assemblersprache geschrieben. Gewöhnlich werden Sprachen der so genannten dritten Generation verwendet, um Anwendungen zu programmieren. Ein Programm in diesen Sprachen wird übertragen (kompiliert oder interpretiert) in Instruktionen der Assemblersprache, die dann von dem Prozessor ausgeführt werden. Beispiele von Sprachen der dritten Generation sind Pascal, C, COBOL, PL/1 und FORTRAN. Diese Sprachen sind ausdrucksfähiger als die Sprachen der niedrigeren Niveaus. Alle außer nicht-trivialen Programmen sind viel kürzer in C oder in Pascal als sie in der Assemblersprache sein würden. Dies bedeutet, dass die Last als Teil der Komplexität der Programmierung von dem Programmierer weg zu dem Compiler (oder Interpreter) hin verlagert worden ist. Je mächtiger bzw. ausdrucksfähiger eine Sprache ist, desto komplexer muss der Compiler oder Interpreter für solch eine Sprache sein. Der Compiler oder Interpreter muss „intelligenter" sein, um in der Lage zu sein, ein Programm, das in dieser Sprache geschrieben ist, in ein Programm der Assemblersprache zu übersetzen.
Vor dem Beginn des Projektes verwendete das U. Z. Leuven die Sprache COBOL der dritten Generation in ihren Verwaltungssystemen. Zu dieser Zeit tauchten die Sprachen der vierten Generation auf. Diese waren ausdrucksfähiger und kompensierten die gestiegene Komplexität der Implementierung, dadurch dass sie spezifischer ausgerichtet waren. Sie sind gewöhnlich sehr gut integriert mit Systemen von relationellen Datenbanken und sehr geeignet für das Wiederauffinden und die Bearbeitung von Daten aus diesen Datenbanken, und sie werden geliefert mit einer eingebauten grafischen Benutzerschnittstelle. Der Hauptnachteil dieser Sprachen besteht darin, dass sie Eigentum derjenigen Gesellschaft sind, die sie entwickelt hat, was diese Sprachen abhängig macht von dem finanziellen Schicksal und den wirtschaftlichen Unwägbarkeiten der Muttergesellschaft. Ein anderer Nachteil ist ihre Spezifizität. Die Komplexität der Implementierung wird vermindert, indem man die Sprachen spezifischer gestaltet. Die meisten Sprachen der vierten Generation sind in Richtung Datenbankzugriff abgestimmt. Dies macht Nicht-Datenbankberechnungen oft schwierig zu programmieren (und das resultierende Programm ist gewöhnlich nicht sehr effizient).
Eine Alternative zu den Sprachen der vierten Generation ist Prolog. Seine Hauptvorteile gegenüber den Sprachen der vierten Generation sind:

• es ist nicht Eigentum einer einzelnen Gesellschaft, und
• es ist eine allgemeine Programmiersprache mit einer hohen Ausdrucksfähigkeit.

Prolog nennt man oft eine Sprache der fünften Generation, aber dieser Ausdruck ist irreführend. Prolog entwickelte sich nicht aus den Sprachen der vierten Generation, sondern hat die Wurzeln seiner Entstehung in der Logik. Die Sprache ist eine Implementierung einer Untermenge einer Logik der ersten Ordnung, genannt Horn Klauseln. Viele Implementierungen von Prolog sind verfügbar und seit Juni 95 ist eine ISO Norm definiert.
Prolog ist eine leistungsfähige Sprache geworden, weil der größte Teil der Forschung für die Optimierung von Prolog von vielen Universitäten geleistet wird und weil die Ideen, die aus dieser Forschung resultierten, dann in die spezifischen Prolog Compiler eingebaut werden. Wie bei relationellen Datenbanken so besteht ein Wettbewerb zwischen den Verkäufern von Prolog bezüglich des schnellsten Prolog. Mit einer Sprache der vierten Generation kann nur eine Gesellschaft die gesamte Arbeit machen.
Es wird Prolog von BIM eingesetzt, welches sowohl schnell als auch robust ist. Am Beginn des Projektes hat man beschlossen, alle Entwicklungen in Prolog durchzuführen und die zeitkritischen Teile in C zu übersetzen, wenn es notwendig ist. Dies war nie notwendig: die Prolog Programme sind ausreichend schnell.
Prolog ist nicht die „silberne Kugel", um die so genannte chronische Softwarekrise zu lösen, aber es hat einige einzigartige Merkmale, was es leichter macht, Programme mit weniger Fehlern zu schreiben.
Speichermanagement
Ein Programm bearbeitet Datenstrukturen. Gewöhnlich besteht die Programmiersprache aus spezifischen Instruktionen, um den Datenstrukturen, welche die Sprache zu erzeugen wünscht, Speicherplatz zuzuordnen. Wenn die Datenstrukturen nicht länger notwendig sind, dann löst das Programm den zugeordneten Speicherplatz wieder auf. Eine häufige Art eines Fehlers ist eine Lücke im Speicher. Wenn ein Programm den gesamten zugeordneten Speicher nicht wieder deaktiviert bzw. wieder auflöst, wenn es denselben nicht länger gebraucht, dann kann das Programm aufhören zu funktionieren wenn der gesamte Speicherplatz aufgebraucht ist. In großen Programmen können diese Fehler schwer zu finden sein, da der Irrtum (der nicht erfolgten Wiederfreigabe des Speicherplatzes) nicht sofort ein Versagen/Ausfallen des Programms verursacht. Wenn das Programm nicht kontinuierlich läuft, dann kann es passieren, dass der Fehler niemals aufgedeckt wird, da das Programm nie den verfügbaren Speicherplatz erschöpft. Auf einem klinischen Arbeitsplatz, der Tag und Nacht im Betrieb ist, kann möglicherweise sogar eine Speicherlücke von einem Byte ein Versagen/Ausfallen des Systems verursachen. In Prolog wird der Speicherplatz automatisch zugeordnet und wenn praktisch der gesamte Speicherplatz, der dem Programm zugeordnet worden ist, ausgenutzt ist, dann wird ein Müllsammler aufgerufen. Der Müllsammler spürt Speicherplatz auf, der zu Datenstrukturen gehört, die nicht länger gebraucht werden, und er löst die Zuordnung dieses Speicherplatzes wieder auf. Dies eliminiert eine bedeutende Quelle von Fehlern.
Keine lose Referenzen
Die meisten Programmiersprachen verwenden Zeiger (pointer). Ein Zeiger ist eine elektronische Referenz auf eine Datenstruktur. Wenn die Struktur gelöscht worden ist (infolge einer Auflösung des zugeordneten Speicherplatzes) oder wenn das Programm die Referenz fälschlicherweise geändert hat, dann zeigt der Zeiger auf Zufallsbits oder auf eine andere Struktur, wenn der Speicherplatz wieder neu verwendet würde. Dies nennt man eine lose Referenz. Dieses Problem kann nicht in Prolog auftreten, weil Prolog explizite Referenzen nicht verwendet. Alle Referenzen sind implizit und werden von der Prolog Sprache intern behandelt. Der Programmierer kann die Datenstrukturen über variable Namen bearbeiten und er weiß nicht bzw. braucht nicht zu wissen, wo die Struktur in dem Speicher liegt.
Die logische Variable
Logische Variablen sind Variablen, die frei sein können (d. h. sie erhielten noch keinen Wert) oder die konkretisiert werden (d. h. ein Wert wurde der Variablen zugewiesen). Eine zerstörerische Zuweisung (d. h. eine Wiederzuweisung eines Wertes zu einer schon augenblicklich aktivierten Variablen) ist nicht möglich. In den meisten anderen Sprachen ist eine zerstörerische Zuweisung eher die Regel als die Ausnahme.
Die Unterlassung einer zerstörerischen Zuweisung erleichtert das Aufsuchen und Korrigieren von Programmfehlern (debugging). In einem großen Team verwenden Menschen dauernd Teile von Software, die von anderen Mitgliedern des Teams geschrieben worden sind. Um es einfach zu machen, gibt eine Person ihre Datenstrukturen an das Programm irgendeines anderen, das dieselben liest (möglicherweise die Datenstrukturen ändert) und das einige neue Strukturen für die betreffende Person erzeugt. Wenn die Funktion fehlerhaft ist, dann kann sie die Datenstrukturen der Person zerstören, deren Programm dies wahrscheinlich nicht sofort bemerkt, aber später Problemen begegnet, wenn es versucht irgend etwas mit diesen Strukturen zu tun. Abhängig von der Veränderung kann das Programm falsche Ergebnisse berechnen oder vollständig anhalten. In den meisten Sprachen werden Parameter als Referenzen übergeben.
Weil Prolog eine zerstörerische Zuweisung nicht erlaubt, kann irgendeine fehlerhafte Datenstruktur nur fehlerhaft erzeugt werden und nicht versehentlich beschädigt werden. Dies erleichtert das Aufsuchen und Korrigieren von Fehlern, da ein Programmierer den Funktionen eines anderen Programmierers nicht zu vertrauen braucht: er kann seine Datenstrukturen nicht ändern.
Formale Spezifikationen
Eines der Verfahren, um zuverlässige Software zu schreiben, besteht darin, Wahrheitsbeweise für jedes Programm aufzubauen. Dies ist nur für sehr kleine Programme durchführbar und die Prüfung der Korrektheit des Beweises kann genau so umständlich sein wie die Prüfung der Korrektheit des Programms selbst. Einige Sprachen versuchen, dies dadurch zu überwinden, indem sie die Aufstellung von Vor- und Nachbedingungen bzw. von Bedingungen vor und Bedingungen nach der Programmausführung in einer formal logischen Art zulassen. Da Prolog eine deklarative logische Sprache ist, stellt das Programm eine formale Spezifikation dar. Es ist eine ausführbare Spezifikation. Obwohl dies ein Übervereinfachung ist – Prolog erlaubt einige nicht-logische Operationen – können weite Teile des Programms vollständig deklarativ gelesen werden. Insbesondere das Regelwerk an Befehlen, das verwendet wird, um die Module für die verschiedenen Abteilungen anzupassen.
Einsatz von Techniken der Künstlichen Intelligenz (KI)
Prolog erlaubt auch Technologien der Künstlichen Intelligenz einzusetzen, sowohl um die Umgebung des vorliegenden Systems zu bauen als auch dasselbe ebenso nahtlos mit der allgemeinen klinischen Anwendung des Arbeitsplatzes zu integrieren. Viele Techniken, die in und für die Künstliche Intelligenz entwickelt worden sind, wurden zum Einsatz bebracht. Diese Techniken ergeben auch zuverlässige, flexible und wartungsfähige Programme mit kürzeren Entwicklungszeiten als mit den herkömmlichen Sprachen. Einige dieser Techniken werden hier diskutiert, aber ihre spezifische Anwendbarkeit wird herausgearbeitet werden, wenn die Softwaremodule beschrieben werden, in denen sie auftreten.
Auf Regeln beruhende Systeme
Eine allgemeine Technik bei Expertensystemen besteht in der Aufteilung der Software in eine Interferenzmaschine und in eine Regelbasis bzw. ein Regelwerk. Das Regelwerk enthält das Wissen über das Gebiet, in dem das Programm betrieben werden soll. Die Interferenzmaschine ist ein Art von Treiber, der weiß, wie und wann diese Regeln aufzurufen sind. Die Hauptvorteile dieser Technik sind:

• sie hält den Code klein, weil der generische Teil nur einmal geschrieben wird, statt dass er mehrere Male in den für die Anwendungen spezifischen Teilen eingebettet wird. Von Erweiterungen zu dem generischen Teil profitieren automatisch alle spezifischen Teile;
• das Wissen wird isoliert von den die Lösung erzeugenden Prozeduren. Wenn sich irgend etwas in den Spezifikationen des Problems ändert, dann brauchen nur einige Regeln hinzugefügt, gelöscht oder aktualisiert zu werden. Der Code des Anwendungsprogramms wird nicht getrübt durch den allgemeinen Programmcode und umgekehrt. Gewöhnlich können die Regeln (oder Gruppen von Regeln) unabhängig voneinander überprüft werden. Dies macht es leichter, die Beständigkeit des Programms zu bewahren, weil die Programmzeilen, die geändert werden müssen, um eine Anpassung zu erfüllen, einfacher identifiziert und isoliert werden können. Infolge dieser Isolation neigen Irrtümer, die in den Regeln gemacht worden sind, nur dazu lokale Wirkungen zu haben: gewöhnlich können die anderen Regeln noch korrekt verwendet werden und ein unberechenbares Verhalten ist auf einen kleinen Teil des Programms beschränkt;
• es gibt eine implizite Standardisierung, da der generische Teil („die Interferenzmaschine") die Struktur der Regeln bestimmt. Dies standardisiert die Struktur von allen spezifischen Teilen der Anwendung, die durch die Anwendung dieser Regeln definiert werden.

Da ein Prolog-Programm selbst eine Regelbasis bzw. ein Regelwerk ist, läuft diese Technik ganz natürlich in Prolog ab. Diese Entwicklung wird einen Schritt weiter geführt. Wenn das Wissen in mehrere Ebenen aufgeteilt werden kann, dann kann man diese Ebenen in die Auslegung des Programms einbeziehen. Die Interferenzmaschine treibt den Einsatz eines Satzes von Regeln einer hohen Ebene an und einige dieser Regeln triggern den Einsatz von Regeln einer tieferen Ebene. Dies erlaubt es, kleinere Änderungen auf der untersten Ebene der Regeln durchzuführen, ohne dass die Zwischenebene der Regeln geändert zu werden braucht. Der Vorteil ist wieder eine weitere Aufteilung (Partitionierung) des Programmcode und damit eine Vereinfachung der Wartung des Programms.
Diese Technik ist analog zu dem, was man „von Daten angetriebene Programmierung" („data driven programming") in den sequentiellen Programmiersprachen nennt. In Prolog hat ein Programm die gleiche Struktur wie die Daten. Daher können die „Daten", die das Programm antreiben, selbst Programme sein. Dies gibt im Bereich Software Engineering die Hebelwirkung, die für große Systeme benötigt wird.
Bau von Kunden-Interpretern
Ein anderer Vorteil der Ähnlichkeit zwischen den Daten und den Programmen besteht darin, dass man Prolog-Programme in der gleichen Weise wie Prolog Daten behandeln und bearbeiten kann. Dieses Merkmal von Prolog setzt man vorteilhaft ein, um die eigenen begrenzten Interpreter d. h. Interpretierprogramme zu bauen.
Oft muss der gleiche Typ von Programmcode während eines Projektes mehrere Male geschrieben werden. Es wurde gefunden, dass wenn man die Unterschiede zwischen diesen Programmen genau bestimmen kann, es dann kostengünstiger ist, eine Art von „Sprache" für einen besonderen Zweck zu schaffen, welche spezifisch für dieses Problem ist, und einen Interpreter für dieselbe zu schreiben. Der Interpreter liest die Programm-Instruktionen in der neuen Sprache und übersetzt sie.
Diese Technik wird in einer einfachen Form eingesetzt. Die geschaffenen „Sprachen" halten die Syntax von Prolog ein und sie können daher durch Datenstrukturen von Prolog dargestellt werden. Dies macht die Bearbeitung dieser Strukturen durch den Interpreter trivial. Oft enthält diese Struktur eine Liste von Befehlen der hohen Hierarchieebenen, die ausgeführt werden müssen. Der Interpreter liest diese Struktur und wählt die Prolog-Regeln aus, um auf der Basis der in der Struktur liegenden Informationen zu triggern.
Der Vorteil dabei ist, dass nur relevante Teile des Code geschrieben werden müssen (der Rest wird generiert). Das Programm ist kürzer und leichter zu warten. Der Nachteil ist der, dass ein Interpreter geschrieben werden muss, aber in Prolog ist dies weit einfacher als in anderen Sprachen. Der Punkt, an dem die Kosten für das Schreiben des Interpreters ausgeglichen werden durch den Gewinn der automatischen Erzeugung des Programmcode, wird schneller erreicht, wenn Prolog verwendet wird, als wenn man mit den mehr gewöhnlichen Sprachen arbeitet.
Die Architektur des Datenmodells gemäss der Erfindung besitzt mehrere Ebenen von Datenmodellen, die zu einem Meta-Modell (s. 1) gruppiert werden können. Es gibt vier verschiedene Teile des gesamten Datenmodells. Drei davon werden eins auf dem anderen aufgebaut und das vierte (die nicht konzeptuellen Tabellen) ist ein paralleles Modell, das auf allen drei Ebenen verwendet wird. Die Strukturierung der Beziehung zwischen diesen Ebenen des Datenmodells erleichtert die vernünftige Prüfung und Beurteilung der Daten während der Entwicklung. Wie später beschrieben wird, bearbeiten die meisten der Programme die Daten auf nur einer Ebene des Datenmodells. Jedes dieser Datenmodelle und ihre gegenseitige Beziehung zueinander wird diskutiert werden, und schließlich wird der Gebrauch der nicht-konzeptuellen Tabellen bei der Optimierung der Leistung demonstriert.
Physisches Datenmodell
Wie oben erwähnt ist der Inhalt einer Form eine Nachricht. Das physikalische Modell handelt von der Speicherung dieser Nachrichten. Abgesehen von den für die Anwendung definierten Feldern wird für jede Nachricht ein Satz von Standardfeldern (irgend jemand, der die Nachricht einfügte und wann) hinzugefügt. Diese Felder werden auch verwendet, um die Unterstützung für den löschungsfreien Aspekt dieser Ebene zu implementieren. Diese Ebene ist löschungsfrei, da keine Information jemals zerstört wird.
Wenn immer ein Benutzer eine Nachricht löscht, so wird sie nicht physisch gelöscht, sondern nur als gelöscht markiert. Das System speichert auch, wer die Nachricht gelöscht hat und warm. Wenn immer eine Nachricht aktualisiert (korrigiert) wird, dann wird diese Aktualisierung übersetzt in eine Einfügung der neuen Nachricht und in eine Löschung der alten Version. Das System speichert, wer die neue Version einfügte und wann, und es verbindet die neue Version mit der alten. 2 zeigt die Standardfelder, die benötigt werden, um dieses Datenmodell zu implementieren. In einem jeden System konzeptueller Tabellen gehen diese Felder den für Anwendungen spezifischen Feldern voraus. Die Funktion eines jeden dieser Felder wird kurz beschrieben werden, und dann wird gezeigt werden, wie sie verwendet werden.
Eine einzige Zahl für eine jede (Version einer) Nachricht in einer Tabelle. Der dkey und der Tabellenname definieren eine Nachricht auf eine einzigartige Weise. Der dkey wird von dem System zum Zeitpunkt der Einfügung zugewiesen. Der dkey und der Sender werden in der rechten Ecke der Form angezeigt, um die Akzeptanz der Nachricht durch die Datenbank zu bestätigen.
omit ist ein Zeichen mit drei möglichen Werten:

i:: eingefügt (inserted): dies ist immer der erste Wert für dieses Feld
o:: die Nachricht wurde weggelassen (logisch gelöscht)
c:: die Nachricht wurde von einer anderen Nachricht korrigiert.

Diese stehen anfänglich auf Null und sie werden nur dann mit einem Wert versehen, wann auch immer die Nachricht gelöscht wird. In diesem Fall werden sie den Benutzernamen derjenigen Person enthalten, welche die Nachricht gelöscht hat, und die Zeit der Löschung. Zu diesem Zeitpunkt wird sich das omit Feld von „i" auf „c" ändern.
cdkey
Dies wird nur benutzt, wenn eine Nachricht eine Korrektur für eine vorangegangene Nachricht darstellt. In diesem Fall wird dieses Feld den dkey der korrigierten Nachricht halten. Dieses Feld «verbindet» die neue Nachricht mit der alten Nachricht.
Beispiel
Angenommen wir haben eine Tabelle, die Nachrichten enthält mit nur einem von der Anwendung definierten Feld, genannt X. Es gibt schon zwei Datensätze in der Tabelle. Einen mit dem Anwendungsinhalt AAA und einen anderen mit dem Anwendungsinhalt BBB.

dkey omit sender sendTime omitter omitTime cdkey X

1 i Jeff 21.7.95 15:03:04 AAA

2 i Ann 22.7.95 09:33:12 BBB
Wenn Jeff jetzt die Nachricht, die von Ann gesandt wurde, löscht, dann wird die Tabelle folgendermaßen:

dkey omit sender sendTime omitter omitTime cdkey X

1 i Jeff 21.7.95 15:03:04 AAA

2 o Ann 22.7.95 09:33:12 Jeff 22.7.95 09:35:14 BBB

Wenn Ann die Nachricht korrigiert, die von Jeff gesandt wurde (und den Inhalt von AAA nach CCC verändert), dann wird diese Aktualisierung übersetzt in ein omit (Weglassen) der ursprünglichen Nachricht und in eine insert (Einfügung) der neuen Nachricht.

dkey	omit	sender	sendTime	omitter	omitTime	cdkey	X
1	c	Jeff	21.7.95 15:03:04	Ann	23.7.95 11:12:13		AAA
2	o	Ann	22.7.95 09:33:12	Jeff	22.7.95 09:35:14		BBB
3	i	Ann	23.7.95 11:12:13			1	CCC

Die aktuelle Einfügung des Benutzernamens (username), der Zeitprägung (timestamp) usw. in die Kopffelder des Systems wird nicht unmittelbar von den Anwendungsprogrammen vollzogen sondern durch die Verwendung von „Triggern" ausgeführt. Die drei Basisoperationen (einfügen, weglassen und korrigieren) können leicht auf eine standardisierte Weise von einer jeden elektronischen Form aus initiiert werden. Die elektronischen Formen in dem vorliegenden System teilen sich alle einen Standardkopf von ikonischen Zeichen. Eine jede der Funktionen ist mit einem ikonischen Zeichen in dem Kopf verbunden. Das Modul der Formwerkzeuge (formTools) des vorliegenden Systemgenerators bewerkstelligt die Verarbeitung dieser Funktionen für alle Formen in einer generischen Art.
Infolge der Löschlosigkeit enthält die physikalische Ebene auch eine Aufzeichnung von allen Versionen von allen Nachrichten. Dies hat mehrere Vorteile. Der erste besteht darin, dass, warm auch immer ein Parameter vorliegt darüber welche Information zu einem bestimmten Zeitpunkt verrfügbar war, der Zustand einer Nachricht oder einer Gruppe von Nachrichten zu diesem Zeitpunkt leicht rekonstruiert werden kann.
Obwohl nur die Programmierer Suchfragen an die physikalische Ebene stellen können, um die vorangegangenen Versionen einer Nachricht wiederzufinden, so können einige privilegierte Benutzer (die Administratoren) eine Geschichte der Versionen einer Nachricht wiederfinden. Diese Geschichte enthält die Liste darüber wer eine Nachricht veränderte hat und wann. Wenn ein Benutzer Fragen über die Versionsgeschichte einer Nachricht hat, dann kam ihm der Administrator demselben die Namen der daran beteiligten Personen geben. Wenn notwendig, können auch die aktuellen Versionen wiedergefunden und verglichen werden.
Der zweite und bedeutendste Vorteil besteht darin, das jeder Benutzer für jedes Informationsbit, das er in die Datenbank eingibt, verantwortlich ist. Dies ist auch der Grund dafür, warum der dkey und des Sendername gezeigt werden, wenn eine Form verschickt wird: dies erinnert den Benutzer an die Tatsache, dass die Datenbank die Nachricht angenommen und mit seinem Namen versehen hat. Die einzige Zahl identifiziert diese Version und irgendwelche nachfolgenden Aktualisierungen können diese Version niemals auslöschen. Wenn in einer geschriebenen medizinischen Datei Information geändert oder überschrieben wird, dann kann fast immer gesehen werden, dass einige Information überschrieben worden sind. In einem Computer ist dies nicht der Fall. Die neue Version eines medizinischen Berichtes sieht genauso ursprünglich aus wie die vorangegangene Version. Dies verringert den Widerstand, Information in einem elektronischen medizinischen Datensatz zu verändern. Das Ziel der Aufzeichnung von allen Veränderungen und das ständige Erinnern der Benutzer an diese Aufzeichnungen besteht darin, den Mangel an sichtbaren Spuren des Überschreibens zu kompensieren.
Konzeptuelles Datenmodell des Generators
Die Basisschichten des vorliegenden Softwaresystems nennt man den Generator. In dem konzeptuellen Datenmodell des Generators werden die gelöschten Nachrichten und ältere Versionen logisch aus den Tabellen weggelassen. Eine Tabelle auf dieser Ebene enthält nur die letzte Version einer jeden Nachricht. Diese Ebene wird in allen Abfragen der Anwendung verwendet und die physikalische Ebene bleibt vollkommen verborgen (außer für die Anfrage nach der Versionsgeschichte für die Administratoren).
Diese Ebene kann leicht erzeugt werden, indem man Sichtweisen der relationellen Datenbank ganz oben auf den x# Tabellen definiert. Nach Vereinbarung ist der Name dieser Sichtweise der gleiche wie derjenige der darunter liegenden Tabelle, aber ohne den x# Prefix. Die Definition der Sichtweise foo oben an der Spitze von x#foo wird in 3 gezeigt. Die Strukturen von diesen Ansichten sind einfach, deshalb behindern sie die Leistung nicht. In jeder praktischen Hinsicht verhält sich diese Sichtweise wie eine konzeptuelle Basistabelle für alle Datenmodelle einer höheren Ebene. Daher werden diese Tabellen genannt ,Tabellen-Sichtweisen'.
Aktualisierungen und Löschungen von Nachrichten sollten nur im Falle von Irrtümern verwendet werden. Dies ist nur möglich, wenn das Datenmodell der Anwendung ein additives Modell ist. Dies impliziert, dass eine Nachricht alle Information von dem enthalten sollte, was zu dem erwarteten Zeitpunkt des Dateneintrages durch den einzelnen Benutzer bekannt ist. Der Benutzer muss in der Lage sein, all die Information als ein Ganzes zu der Datenbank zu schicken. Wenn aber zum Beispiel zwei Informationseinheiten A und B nicht zur gleichen Zeit bekannt sind, wenn aber operationale Prozeduren den Dateneintrag von Einheit A in das System erfordern, dann kann Einheit B nicht einen Teil der gleichen Nachricht (und Teil der gleichen elektronischen Form) sein wie Einheit A. Wenn es das sein würde, dann würde die Prozedur den Benutzer zwingen, den Wert der Einheit B zu raten (oder den Wert leer bzw. blank zu lassen), wenn er die Nachricht abschickt. Wenn die Informationseinheit B bekannt wird, dann müsste der Benutzer die Nachricht korrigieren. Solch eine Situation betrachtet man als einen Irrtum des Datenmodellierens für ein additives Datenmodell. Wieder müssen Kompromisse gemacht werden, um das System ergonomisch zu halten. Betrachtet man das Extrem, dann könnte jede Dateneinheit eine unterschiedliche Nachricht sein. Dies würde das obige Problem vermeiden, da man niemals zwei oder mehr Einheiten in einer Form verschicken muss. In einem idealen Umfeld mit unfehlbaren und allwissenden Benutzern sollte der Inhalt dieser Ebene exakt der gleiche sein wie der Inhalt der physikalischen Ebene.
Konzeptuelles Datenmodell der Anwendung
Diese Ebene basiert auf dem konzeptuellen Datenmodell des Generators. Diese Ebene definiert die Felder, die den Inhalt der Nachrichten halten. Ein Datenmodell der Anwendung definiert einen Informationsfluss. Jeder Benutzer (oder eine eine Funktion erzeugende Information) wird irgendwo in diesem Fluss lokalisiert. Ein Benutzer erhält die Nachrichten von den vorgeschalteten Personen und er fügt seine Information durch Verwendung der elektronischer Formen hinzu für die Benutzung durch die nachgeschalteten Personen. Dies ist exakt das gleiche wie mit Papierformen. Eine Papierform wird vervollständigt und dann zu der nächsten Person in dem Informationsfluss geschickt. Diese Person wird wahrscheinlich neue Information erzeugen und dieselbe an (zurück an) die nächste Person in dem Fluss senden.
Diese Strategie der Datenmodellierung erlaubt den Benutzern, eine aktivere Rolle bei der Definition des Datenmodells zu spielen. Gewöhnlich wird von den Benutzern erwartet, dass sie nachdenken sollten als ob sie ihre Prozeduren bei der Benutzung der Papierformen wieder neu entwickeln sollten. Wegen der elektronischen Natur der Formen gibt es nur wenige Extra-Annahmen die der Benutzer zu machen ermächtigt ist:

• die Formen kommen an ihrem Bestimmungsort virtuell sofort an;
• eine Form kann von mehreren Personen zur gleichen Zeit eingesehen werden (eine serielle Vorgehensweise hintereinander ist nicht notwendig, wenn zwei Personen die gleiche Information benötigen);
• Teile der Formen können für einige (Typen der) Benutzer verborgen werden.

Die Benutzer können ihr Datenmodell zusammen mit den Analytikern bauen, so dass sie verstehen, was das Datenmodell darstellt. Diese Transparenz erlaubt ihnen abzuleiten, welche Informationsfunktionen möglich sind und welche bei dem Datenmodell ausgeschlossen bleiben. Dies steht im Gegensatz zu dem klassischeren Ansatz, bei dem der Analytiker die Spezifikationen für die verschiedenen Funktionen, die von dem System zur Verarbeitung von Informationen durchgeführt werden müssen, heraus arbeitet und nachfolgend ein Datenmodell baut, um diese Funktionen zu tragen. Wenn der Benutzer die Spezifikationen ändert oder wenn neue Funktionen hinzugefügt werden müssen, dann ist es möglich, dass diese sich nicht gut in das Datenmodell hinein passen. Das Datenmodell muss dann angepasst werden, was kostspielig ist. Indem man einen etwas transparenteren Ansatz in Richtung Datenmodellierung wählt, kann der Benutzer überwachen, wie gut das Datenmodell mit seiner Sicht des Umfeldes abgestimmt ist.
Benyon stellt fest, dass ein Modell der Datenverarbeitung aufgebaut ist aus einem Datenmodell und aus einem Verarbeitungsmodell. Das Datenmodell stellt die Struktur des Unternehmens dar, indem es dasselbe modelliert in Begriffen von Objekten und Beziehungen zwischen diesen Objekten. Das Verarbeitungsmodell stellt die Transformationen in den Vordergrund, die in dem System stattfinden. Diese Prozesse transformieren die Daten durch einige Manipulationen, restrukturieren dieselben in eine nützlichere Form oder beziehen dieselben auf andere Daten. Das Datenmodell und das Verarbeitungsmodell stellen jeweils die statischen und dynamischen Merkmale des Informationsmodells dar.
Wenn man die Technik der Datenmodellierung einer Person auf diesen Typ von Datenmodellierung abbildet, dann könnte man sagen, dass das Verarbeitungsmodell in hohem Grad vereinfacht ist. Prozesse in der realen Welt führen nur zu einem Typ von Veränderung in der Datenbank: die Hinzufügung einer Nachricht. Keine Daten werden bearbeitet oder restrukturiert durch irgendeine von einem Benutzer erzeugte Funktion. Diese Vereinfachung addiert sich zu der Transparenz des Datenmodells. Wie vorher festgestellt, führt diese Vereinfachung in dem Dateneintrag und bei der Bedienung zu komplexeren Deduktionen. So ist der dafür zu zahlende Preis die Leistung. Dies wird gelöst durch ein Handeln zwischen Leistung an Deduktion und Speicherplatz und Leistung der Einfügung, so wie dies in dem nächsten Abschnitt erklärt wird.
Nicht konzeptuelle Tabellen (Anwendungsebene) optimieren die Leistung
Die die Nachricht modellierende Technik behandelt einen Geschäftsprozess als ein Fluss von Nachrichten. Der Zustand eines Geschäftsprozesses kann aus dem Vorhandensein oder dem Nicht-Vorhandensein von Nachrichten abgeleitet werden. Als ein Beispiel seien fünf der Nachrichten überprüft, die sich auf einen Besuch bei einem ambulanten Patienten beziehen. Ein Aufnahmeformular wird ausgefüllt, wenn der Patient ankommt (1). Dann wird der Patient einem Assistenten und einem Überwacher zugewiesen (2). Der Assistent wird nach der Visite einen Bericht schreiben (3) und der Überwacher wird diesen Bericht auf Richtigkeit überprüfen (4). Das Sekretariat schickt den Bericht zu dem (externen) Arzt, der die Untersuchung erbeten hatte (5).
Jede dieser Nachrichten kann von einer verschiedenen Person geschickt werden. Die Nachrichten müssen in dieser Reihenfolge geschickt werden. Es ist offensichtlich, dass man einen Bericht, der nicht besteht, nicht auf seine Richtigkeit überprüfen kann, aber das System wird auch prüfen, dass ein Report nicht geschrieben werden kann, wenn der Patient nicht an einen Assistenten und an einen Überwacher überwiesen worden ist. Für jeden Besuch des ambulanten Patienten müssen alle vier Formblätter ausgefüllt werden (wobei eine Anzahl von Ausnahmen gestattet sind). Die fünf Phasen beschreiben eine Arbeitseinheit.
Der Zustand dieser Arbeitseinheit, die „ambulanter Betreuungsbesuch" genannt wird, besteht in dem Fortschreiten durch diese fünf Phasen. Die Phase, in welcher der Patient sich befindet, und der nächste Schritt, der zu vollziehen ist, können aus dem Vorliegen und dem Nicht-Vorliegen von Nachrichten abgeleitet werden. Auf diese Art und Weise wird das System Arbeitslisten erstellen, um den Benutzern die spezifische Information zu zeigen, die notwendig ist, um die Arbeit derselben durchzuführen. Zum Beispiel möchten die Assistenten eine Liste von allen Patienten haben, die aufgenommen worden sind, die aber bis jetzt noch nicht zugewiesen sind. Sie werden von dieser Liste ausgehen, um die Arbeit unter sich aufzuteilen. Nach der Zuweisung der Patienten (durch das Abschicken der elektronischen Zuweisungsform) werden sie den Patienten besuchen und behandeln. Später verwendet der Assistent eine Liste von allen ihm zugewiesenen Patienten, aber für welche bis jetzt noch kein Bericht geschrieben worden ist, um mit dem Schreiben der medizinischen Berichte zu beginnen. Der Überwacher wird eine Liste haben wollen mit allen nicht validierten Berichten für die ihm zugewiesenen Patienten.
Jede dieser Arbeitslisten wird definiert als eine Sicht in die relationelle Datenbank. Die Strukturen dieser Sichtweisen sind ähnlich: sie wählen Patienten aus, für die eine besondere Nachricht existiert und für die eine andere Nachricht nicht vorhanden ist. Nur ein kleiner Teil von den Tupeln in jeder der Tabellen wird an diesen Abfragen teilnehmen, nämlich die Tupeln, die zu den Arbeitseinheiten gehören, für die nicht alle fünf Phasen vervollständigt worden sind. Von diesen Arbeitseinheiten sagt man, sie seien in der Produktion. Die meisten der Daten werden sch in Arbeitseinheiten befinden, die nicht in Produktion sind: Daten über Besuche, für die validierte Berichte bestehen.
Für die oben erwähnten Arbeitslisten besteht der meiste Teil der Computerarbeit in dem Typ von Arbeit „finde Tupeln aus der Tabelle A, für welche kein Tupel in der Tabelle B vorhanden ist". Für Abfragen aus dem realen Leben werden offensichtlich mehr als zwei Tabellen an der Abfrage beteiligt sein. Die Leistung der Abfrage verschlechtert sich in dem Masse wie die Größe der Tabellen wächst. In einem medizinischen Datensatz sind die historischen Daten so bedeutend, dass die Benutzer die Information so lange wie möglich online halten wollen. Dies bedeutet, dass die Leistung in dem Maße abnimmt wie die Datenbank wachst. Man kann zwischen zwei Typen von Tabellen unterscheiden: statische und dynamische Tabellen. Dynamische Tabellen wachsen in der Größe annähernd mit der gleichen Geschwindigkeit wie Arbeitseinheiten in die Datenbank hinzugefügt werden. Zum Beispiel ist die Berichtstabelle eine dynamische Tabelle: für jeden Besuch des Patienten in dem Krankenhaus werden ein oder mehrere Berichte geschrieben. Statische Tabellen wachsen mit einer weit niedrigeren Geschwindigkeit, die normalerweise nicht an den Umfang der Arbeitseinheiten gebunden ist. Es wird z. B. eine Tabelle mit Definitionen von radiologischen Prüfungen wachsen, je mehr Techniken für bildgebende medizinische Verfahren oder neue Geräte verfügbar werden. Andere Beispiele sind die Tabellen, welche die Identifikationen von Ärzten enthalten, sowie Stationsnummern und Beschreibungen, medizinische Listen, .... Diese Tabellen wachsen auch, aber um einige Größenordnungen langsamer als die dynamischen Tabellen. Sie umfassen gewöhnlich einige Hunderte oder einige Tausende von Datensätzen.
Suchfragen (wie Arbeitslisten), die verwendet werden, um den normalen Arbeitsfluss zu unterstützen, nennt man Produktionsanfragen, um sie von den Abfragen des Managements zu unterscheiden. Produktionsanfragen benötigen eine schnelle Antwortzeit, um einen glatten bzw. kontinuierlichen Arbeitsfluss zu gewährleisten. Produktionsanfragen können in Punktanfragen und in einen Satz von Anfragen unterteilt werden.
Punktanfragen sind Abfragen, die alle Tupeln geben, die zu einer bekannten Einheit gehören, und die einen identifizierten Bezeichner oder Identifier aufweisen. Zum Beispiel sind dies alle Berichte für einen einzelnen Patienten; oder alle Zuweisungsformen für einen einzelnen Überwacher. Abfragesätze reichen über mehrere Einheiten und sie sind gewöhnlich von dem Typ einer Arbeitslisten, wie sie oben beschrieben worden sind. Punktfragen können beschleunigt werden, indem man Indices verwendet, die in einem jeden System einer kommerziell verfügbaren Datenbank zur Verfügung stehen. Abfragesätze profitieren auch von Indices, aber diese sind nicht ausreichend, um den erforderlichen Grad an Leistung zu erreichen. Die für dieses Problem gefundene Lösung benutzte extra Tabellen, um die Information zu speichern, die benötigt wurde, um diese Abfragen zu beschleunigen. Diese Tabellen enthalten nur redundante Information und sie existieren nicht von einem konzeptuellen Standpunkt her. Daher der Name nicht-konzeptuelle Tabellen. Zustandstabellen sind nicht-konzeptuelle Tabellen, die Information über den Zustand einer Arbeitseinheit enthalten. Die nicht-konzeptuellen Tabellen bilden ein alternatives redundantes Datenmodell. Dasselbe ist ein komprimiertes Datenmodell, da nur redundante Information gespeichert wird, die benötigt wird, um die Auswahl der bedeutenden Arbeitseinheiten, die in den Abfragen benötigt werden, zu beschleunigen. In einer Art wirken die nicht-konzeptuellen Tabellen als semantische Indices zu den Daten in den konzeptuellen Tabellen. Wenn die relevanten Arbeitseinheiten erst einmal identifiziert sind, werden die aktuellen Daten aus den konzeptuellen Tabellen wiedergefunden.
Um das ambulante Betreuungsbeispiel zu optimieren, sollte eine Zustandstabelle notwendig sein mit vier Attributen zusätzlich zu den vier Tabellen, welche die Nachrichten für die Aufnahme, für die Zuweisung, für den Bericht und für die Validitätsform enthalten. In dieser Zustandstabelle enthält das Feld visitID die Identifikationsnummer des Besuches, das Feld assigned enthält 0 oder 1, was auf das Vorhandensein eines Zuweisungsformulars für diesen Besuch hinweist. Das Feld Report enthält auch 0 oder 1, was auf die Existenz eines medizinischen Berichtes hinweist. Wann auch immer eine neue Arbeitseinheit startet, wird ein Datensatz in der Zustandstabelle erzeugt (siehe 4a).
Das obige Tupel weist darauf hin, dass ein Besuch mit der Identifikationsnummer 7 sich in der Produktion befindet und dass nur die Aufnahmephase abgeschlossen worden ist. Wenn der Besuch einem Assistenten und einem Überwacher zugewiesen wird, springt das zugewiesene Bit von 0 auf 1 (siehe 4b).
Wenn der medizinische Bericht an die Datenbank geschickt wird, springt das Reportbit um. Wenn der Bericht validiert wird, springt das nächste Bit um. Wenn die „gesandte" Nachricht zu der Datenbank hinzugefügt wird, dann wird der Datensatz für diesen Besuch aus der Zustandstabelle gelöscht. Das Versenden ist die letzte Phase, so dass die Arbeitseinheit nicht länger in Produktion ist. Die Zustandstabelle enthält Informationen über alle Besuche:

• alle Besuche, die nicht in der Tabelle dargestellt sind, befinden sich außerhalb der Produktion;
• die Besuche, die sich in der Produktion befinden, können in einem jeden der vier Zustande befinden: – nur aufgenommen – aufgenommen und zugewiesen – aufgenommen, zugewiesen und darüber berichtet – aufgenommen, zugewiesen, darüber berichtet und validiert (d. h. es liegt kein Zustandsdatensatz vor).

Die Zeit wird auch unterschiedlich dargestellt. In den nicht-konzeptuellen Tabellen wird das Fortschreiten der Zeit in den Kolonnen dargestellt: in dem Maße wie die Arbeit für eine Arbeitseinheit fortschreitet, werden die Werte in den Kolonnen aktualisiert. In den konzeptuellen Tabellen wird der Zeitfortschritt in den Zeilen dargestellt. Der Abschluss einer Phase in einer Arbeitseinheit bedeutet das Hinzufügen einer Zeile zu einer Tabelle (siehe 5).
Die Zustandstabelle erlaubt es, Suchfragen neu zu schreiben, die das Vorhandensein von Nachrichten testen und die selbige effizienter gestalten. Angenommen, dass alle visitIDs und Patientennamen der Besuche, die noch von dem Überwacher A validiert werden müssen, erbeten sind. Ohne die Zustandstabelle bedeutet dies durch die „zugewiesene" Tabelle gehen zu müssen und für jede visitID, die dem Überwacher A zugewiesen worden ist, durch die Berichttabelle hindurch gehen zu müssen und nach dem Vorhandensein eines Berichtes mit der gleichen visitID zu suchen. Für einen jeden dieser Berichte wird in der Validationstabelle geprüft, ob er schon validiert worden sind oder nicht. Für jene Berichte, für die kein Validationstupel existiert, sucht man den Namen des Patienten aus der Aufnahmetabelle.
Beide, sowohl die „zugewiesene" Tabelle als auch die Berichtstabelle, sind dynamische Tabellen. Die meisten der Datensätze in der zugewiesenen Tabelle haben validierte Berichte, da nur ein begrenzter Satz von allen Daten in der Produktion sein wird. Demnach wird der Nachweistest für einen Datensatz in der Validationstabelle meistens herausfinden, dass der Bericht schon validiert worden ist.
Die gleiche Abfrage kann viel schneller berechnet werden, wenn man die Zustandstabelle verwendet. Da sie sehr viel kleiner ist, erlaubt sie es, die Arbeitseinheiten, die sich noch in der Produktion befinden, sehr viel schneller ausfindig zu machen. Das wird in dem folgenden Experiment gezeigt, das Teil der Abfrage darstellt, welche von den Überwachern verwendet wird, um die Liste der Berichte wiederzufinden, die von ihnen validiert werden müssen.
Experimenteller Beweis des Gewinnes an Leistung
Als ein Beispiel wird (ein Teil) der Abfrage zur Wiederfindung der Validationsliste für einen Überwacher in dem klinischen Arbeitsplatz gezeigt. Die Abfrage findet die Liste der Berichte, die validiert werden müssen durch den Überwacher, der zuständig dafür ist, diese Arbeitseinheit (d. h. einen Patientenkontakt) zu behandeln.
In dem in dem Beispiel verwendeten Fall des Überwachers ergibt das Ergebnis der Abfrage 6 Zeilen (d. h. 6 Berichte müssen validiert werden).
Sechs konzeptuelle Tabellen nehmen an dieser Abfrage teil. Eine kurze Beschreibung dieser Tabellen wird in der Tabelle 1 gegeben. In einem Experiment wurden 3 Versionen der gleichen Abfrage gezeigt und ihre Leistungen wurden verglichen. Die erste Version ist eine gerade deklarative Implementierung der Abfrage. Die zweite Version verwendet nicht-konzeptuelle Tabellen, um die Leistung zu vergrößern. Die dritte Version verwendet die nicht-konzeptuellen Tabellen nicht, aber sie ist etwas prozeduraler geschrieben, um dem Optimierer auszuhelfen.
Um die Leistung zu vergleichen wurde die Zeit gemessen, die für die Berechnung der Abfrage aufgewandt wurde, und die Anzahl der Häufigkeit mit welcher jede Tabelle durchgescannt wurde, um die Lösung zu finden. Der Optimierer der Abfrage kann wählen, mehr als einmal auf eine Tabelle zuzugreifen, weil er es nicht optimal findet, das ganze Auffinden aller Daten in einem Zugriff durchzuführen. Gewöhnlich wird die Tabelle mehrere Male während eines Zugriffes durchgescannt. Sybase erlaubt es, die Reihenfolge der Zugriffe (den Plan der Suchfragen) auszudrucken, aber Sybase sagt nicht, welche Daten in jedem Zugriff wiedergefunden worden sind.
Die Version
Die erster Version verwendet die nicht-konzeptuellen Tabellen nicht. Die Suchfrage wird als eine deklarative Auswahlanweisung geschrieben und die gesamte Optimierung wird dem Abfragenoptimierer überlassen (siehe 6). Der Abfragenoptimierer verfügt nur über syntaktische Information und „weiß" daher nicht, dass die meisten Berichte in der Berichtstabelle validierte Berichte sein werden. Die Reihenfolge der Zugriffe und die Verwendung eines Indexes in dem Zugriff ist in der Tabelle 2 aufgelistet. Die vollständigen Plane der Abfragen für alle drei Abfragen sind in der Tabelle 2 aufgelistet. Aus der Reihenfolge der Zugriffe kann gesehen werden, dass der Server einen Weg wählte, auf dem es notwendig ist mehrere Male auf die Tabellen x#verslag und x#validatie zuzugreifen, bevor er die Arbeitseinheiten identifiziert hat, die bedeutsam sind. Wenn diese erst einmal identifiziert sind, findet der Zugriff auf die anderen Tabellen statt, um die Attribute wiederzufinden, die angezeigt werden müssen.
In der Tabelle 4 sind die Ergebnisse der Leistung aufgeführt. Abfrage 1 nahm 129 Sekunden bis zum Anschluss in Anspruch. Der größte Teil der Zeit wurde mit dem Scannen der Tabelle x#validatie verbraucht, um den „existiert nicht" Test in der Unterabfrage aufzulösen.
Version 2
Die zweite Version der Abfrage verwendet die Zustandstabelle und ist in 7 aufgelistet. Die Zustandstabelle speichert nicht nur Kennzeichen, um anzugeben, welche Phasen abgeschlossen worden sind, sondern auch die Identifikation des Überwachers und des Assistenten, denen die Arbeitseinheit zugewiesen worden ist. Dies bedeutet, dass beide, sowohl die auf dem Überwacher basierende Auswahl als auch die auf dem Nachweis der Validation beruhende Auswahl, gleichzeitig in die Zustandstabelle getan werden können. Der Name des Patienten wird auch in dieser nicht-konzeptuellen Tabelle gespeichert (redundant), da fast alle Abfragen über den Produktionstyp die Namen der Patienten zeigen müssen.
Wie in Abfrage 1 ist diese Version als eine einzelne Auswahlanweisung geschrieben und die gesamte Optimierung wird dem Optimierer überlassen. Ein Optimierer versucht immer die Anzahl der Tupeln, die zu verarbeiten sind, so früh wie möglich in der Abfrage zu vermindern. Der Optimierer hat kein Problem, den optimalen Weg für diese Abfrage zu finden. Er hat drei Selektionskriterien (s.usernameSup = „x163646", s.verslag = 1 und s.validatie = 0) auf der Tabelle statusContact, die auch die kürzeste Tabelle ist. Aus dieser Information vermutet man, dass die größte Verminderung an Tupeln, die zu verarbeiten sind, gewonnen werden kann, wenn man zuerst auf diese Tabelle zugreift.
Dies führt zu einem dramatischen Anstieg der Beschleunigung (verstrichene Zeit weniger als 0,5 sec). Wie aus dem Plan der Abfrage in dem Anhang gesehen werden kann, greift die Abfrage jetzt zuerst auf die Tabelle statusContact, indem der Index auf den Überwacher verwendet wird, identifiziert sofort die 6 Arbeitseinheiten, die bedeutsam sind, und greift auf die Tabellen x#S9User und die x#verslag zu, um zusätzliche Attribute wiederzufinden, die nicht in der Zustandstabelle vorhanden sind. Die Anzahl des Durchscannens von Tabellen wird dadurch sehr vermindert.
Das Problem mit der Abfrage 1 besteht darin, dass der Optimierer einen nicht-optimalen Plan baut. Seine Heuristic kann nur Information aus der Struktur der Abfrage verwenden, aus der Länge der Tabellen und aus dem Vorhandensein oder dem Nicht-Vorhandensein von Indices. Er kann die semantische Information nicht verwenden, die der Programmierer der Anwendung besitzt. Im Fall der Abfrage 1 fällt der Optimierer die falschen Entscheidungen und wird ein „Pessimierer". In solchen Fällen kann ein Anwendungsprogrammierer die Leistung erhöhen, indem er eine stärker optimale Ausführungsanweisung durchsetzt. Dies wird gewöhnlich getan, indem die Abfrage in Teile aufgeteilt wird. Der Abfragenoptimierer wird noch jeden dieser Teile optimieren, aber er kann die Ausführungsanweisung nicht ändern. Einige der Vorteile von SQL gehen auf diese Art und Weise verloren. Die Abfrage ist schwieriger zu lesen, es wird mehr Zeit benötigt sie zu schreiben und wenn die Länge von einigen der Tabellen fundamental ändert, dann muss die Optimierung wieder neu vorgenommen werden. Nichts desto trotz ist diese Technik für sehr komplexe Abfragen oft unvermeidbar.
Version 3
Die dritte Version der Abfrage verwendet die Zustandstabelle nicht, sondern sie wird optimiert durch ihre Aufteilung in drei Teile (siehe 8). Der erste Teil erzeugt eine Tabelle, welche die Identifizierer für die Arbeitseinheiten enthält, die dem Überwacher zugewiesen sind. In dem zweiten Teil werden alle Tupeln, die zu den Arbeitseinheiten gehören, die schon validiert worden sind, aus der Tabelle gelöscht. Mit den resultierenden Identifizierern wird auf die anderen Tabellen zugegriffen, um die Attribute wiederzufinden, die angezeigt werden müssen. Diese Sequenzierung der Berechnung ist auferlegt worden, weil es bekannt ist, dass nur ein kleiner Prozentsatz der Berichte validiert werden muss. Weil semantische Information verwendet wird (die dem Abfragenoptimierer unbekannt ist), nennt man diese Optimierungstechnik semantische Optimierung.
Die Abfrage ist viel schneller als die Abfrage 1, aber noch mehr als 7 mal langsamer als die Abfrage, welche die Zustandstabelle verwendet. Obwohl die Zahl der Scannvorgänge dramatisch abgenommen hat, haben die ersten zwei Teile der Abfrage, welche die relevanten Arbeitseinheiten identifizieren, mehr Verarbeitung zu leisten als bei der Verwendung der Zustandstabelle: die Tabelle x#validatie muss für alle Berichte gescannt werden, die dem Überwacher „x163464" zugewiesen sind.
Abfrage 2 ist bei weitem die schnellste Abfrage, insbesondere wenn man die CPU Zeit betrachtet. In Abfrage 1 ist die CPU Zeit fast die gleiche wie die verstrichene Zeit. Dies bedeutet, dass die Abfrage an die CPU gebunden ist: die CPU stellt den Flaschenhals dar. Abfrage 2 benötigt weniger als 100 ms CPU Zeit (Sybase berichtet von einer CPU Zeit in Einheiten von 100 msec), so dass der größte Teil der 446 msec für den Plattenzugriff verbraucht wird. Die aktuelle Verarbeitung ist sehr leicht. Abfrage 3 ist zwischen den beiden angeordnet. Abgesehen von dem Leistungsvorteil ist Abfrage 2 auch viel lesbarer als Abfrage 3.
Wenn die Anzahl der Arbeitseinheiten in der Datenbank anwächst, wird sich die Leistung der Abfrage 1 und 3 verschlechtern, weil beide von ihnen Tabellen scannen müssen, die mit der Anzahl der Arbeitseinheiten anwachsen. Abfrage 2 scannt die Tabelle stausContact. Diese Tabelle wird in einem stationären Zustand bleiben, wenn die Arbeitsbelastung in der Abteilung sich nicht fundamental ändert. Die Anzahl der Zugriffe auf andere Tabellen hängt nicht von der Gesamtanzahl der Arbeitseinheiten in der Datenbank ab, sondern von der Arbeitslast des Überwachers, die auch in einem stationären Zustand sein wird. Die aktuellen Zugriffe auf diese Tabellen sind indizierte Zugriffe und sie verschlechtern sich daher nur logarithmisch mit der Antwortzeit.
Die Verwendung von nicht-konzeptuellen Tabellen ist ein Handeln mit der Einfügungszeit und dem Plattenspeicherplatz für kürzere Abfragezeiten. Die redundanten Tabellen werden aktuell gehalten und mit den konzeptuellen Tabellen synchronisiert, indem Datenbanktrigger verwendet werden. Einfügungen verlieren ein wenig an Leistung, weil bei der Einfügungszeit redundante Daten aktualisiert werden müssen oder in die nicht-konzeptuellen Tabellen hinzugefügt werden müssen. Dies ist analog zu den Indices. Diese enthalten auch redundante Daten und das Hinzufügen von Indices zu einer Tabelle verlangsamt die Einfügungen, beschleunigt aber die Abfragen. Weil Trigger eingesetzt werden, um die nicht-konzeptuellen Tabellen zu bewahren, wird keine gesonderte Belastung/Organisation (overhead) auf die Anwendung gesetzt oder auf den Netzwerkverkehr zwischen dem Kunden und dem Server. Jedes Overhead liegt auf dem Datenbankserver.
Am Beginn einer Arbeitseinheit (z. B. das Aufnahmeformular in dem obigen Experiment) verursacht die Einfügung in die Aufnahmetabelle auch eine Einfügung in die Zustandstabellen. Alle nachfolgenden Phasen in der Arbeitseinheit verursachen eine Aktualisierung von einem Feld oder von mehreren Feldern auf dem entsprechenden Datensatz in der Zustandstabelle. Gewöhnlich veranlasst eine Einfügung, dass zahlreiche Prüfchecks von dem Datenbankserver durchzuführen sind. Zum Beispiel wenn eine Zuweisung zu einen Assistenten und an einen Überwacher gemacht wird, dann wird das System abchecken, ob die Identifikationen in dem Zuweisungsformular in der Identifikationstabelle für Ärzte existieren. Wenn jemand eine radiologische Untersuchung anfordert, dann wird das System abchecken, ob diese Art von Untersuchung vorhanden ist. Oft werden während des Einfügungsprozesses mehrere dieser Typen von Prüfchecks stattfinden. Gewöhnlich nimmt eine Einfügung ein paar Millisekunden in Anspruch, so dass die zusätzliche Belastung (overhead) zur Wartung der nicht-konzeptuellen Tabellen für die Endbenutzer vernachlässigbar ist.
Der andere zu zahlende Preis ist der Plattenspeicherplatz. Die Belastung hier ist gering (siehe Tabelle 4) und nimmt ab in dem Maße wie die Datenbank wächst, weil das Verhältnis der Arbeitseinheiten in der Produktion gegenüber den historischen Arbeitseinheiten abnimmt. Die Anzahl der Datensätze in der Zustandstabelle bleibt relativ konstant, wenn die Abteilung in einem stabilen/stationären Zustand ist, das heißt, dass sie genau so viele Arbeitseinheiten beenden wie sie deren neu beginnen. Es mag dabei einige Schwankungen in der Zahl der Arbeitseinheiten in der Produktion geben (jahreszeitliche Schwankungen, Personalknappheit, ...), aber eventuell wird ein stabiler Zustand erreicht werden.
Was man gewinnt, ist Antwortzeit auf die Abfrage, wie in dem obigen Beispiel demonstriert wird. Wenn eine Nachricht erst einmal eingefügt worden ist, aber viele Male abgefragt wird, dann überwiegen die Vorteile deutlich die Kosten.
Eine relationelle Datenbank optimiert nicht nur die Abfragepfade, sondern auch das Speichermanagement. Häufig gebrauchte Daten werden in dem Hauptspeicher gehalten, weil der Server antizipiert, dass sie wieder benutzt werden, und weil er die Belastung von Plattenzugriffen, um die Daten aufzufinden, vermeiden möchte. Weil die meisten Abfragen aus der Produktion die Zustandstabellen verwenden und weil die meisten Benutzer (nur) Produktionsabfragen in ihrer täglichen Routine verwenden, wird auf die Zustandstabellen konstant zugegriffen. Weil sie klein sind, können sie vollständig in dem Speicher gehalten werden. Dies hat einen zusätzlichen positiven Effekt auf die Antwortzeiten der Abfragen, weil die meisten Zugriffe auf die Zustandstabelle nur logische Lesevorgänge sein werden (nur in dem internen Speicher) und keine physikalischen Lesevorgänge (Plattenzugriff).
Als Schlussfolgerung daraus gibt es 3 Gründe, die Zustandstabellen klein zu halten:

• je weniger redundante Daten es gibt, desto weniger Synchronisierung muss getan werden bei der Einfügungszeit.
• je kleiner die Zustandstabelle, desto größer ist die Chance, dass sie speicheresident bleiben kann.
• Nutzung des Plattenspeicherplatzes.

Bei den gegenwärtigen Preisen für Speicherplatz spielt der dritte Grund kaum mehr eine Rolle. Die ersten beiden müssen durch Gewinne in der Leistung der Abfrage ausgeglichen werden.
Trennung des Entwurfes für die Leistung von dem Entwurf für die Ausdrucksfähigkeit
Es mag der größte Vorteil bei der Verwendung von nicht-konzeptuellen Tabellen sein, dass weniger Kompromisse eingegangen werden müssen in dem konzeptuellen Datenmodell, um Leistung zu gewährleisten. In der vorliegenden Methodologie ist der Entwurf für die Darstellung und der Entwurf für die Leistung auf verschiedene Datenmodelle aufgeteilt. Dies gibt weit mehr Freiheit in den Darstellungsaspekten des Datenmodells. Die konzeptuellen Tabellen sind äußerlich sichtbar durch die Funktionen in dem System. Die nicht-konzeptuellen Tabellen sind unsichtbar für die Benutzer. Wenn sich im Zeitablauf die Muster der Abfrage ändern und andere Funktionen optimiert werden müssen, dann können nicht-konzeptuelle Tabellen hinzugefügt oder leicht geändert werden und dann können die Abfragen neu geschrieben werden, um sie zu optimieren, um diese Tabellen zu verwenden. Das Datenmodell, so wie es die Benutzer sehen, bleibt unverändert.
Wiederherstellungszeit
Die nicht-konzeptuellen Tabellen erlauben es der Datenbank zu wachsen, während die Leistung der Abfrage nur mit dem Logarithmus der Datenbankgröße abnimmt. Dies beseitigt einen Flaschenhals für unbegrenztes Wachstum der Datenbank. Der nächste Flaschenhals, der auftreten wird, ist die Zeit für die Wiederherstellung. Je größer die Datenbank, desto länger dauert es für eine Sicherung (back up) oder für ein neues Laden von dem Band im Falle eines Mediumfehlers. Obwohl dies eine viel weniger stringente Einschränkung auf das Wachstum der Datenbank ist, kann sie nicht ignoriert werden. Für jede der Datenbanken muss bestimmt werden, was die maximal zulässige Wiederherstellungszeit ist. Dies, in Verbindung mit der maximalen Bandbreite der Sicherung (backup) und der Wiederherstellung (restore), wird die maximale Größe der Datenbank bestimmen.
Wirkung auf die Größe der Datenbank
Das Ausmaß der korrigierten oder unterlassenen Nachrichten variiert stark von Tabelle zu Tabelle. Z. B. das Zuweisungsformular für Patienten auf eine Station wird jedes Mal korrigiert, wenn die Ärzte neuen Stationen zugewiesen werden. Die Berichtstabelle enthält viele logisch gelöschte Berichte, da sogar eine kleinere Korrektur, wie etwa die für einen Tippfehler, bewirkt dass eine Sicherungskopie des Berichtes erstellt wird. Der gesamte Belastungsaufwand (overhead) in den anderen Tabellen verblasst neben dem Belastungsaufwand in der Berichtstabelle: dies ist nicht nur die Tabelle mit der höchsten Anzahl von Korrekturen, es ist auch die Tabelle mit den größten Zeilen. Jedes Feld des Berichtstextes nimmt mindestens 2 kilobytes in Anspruch.
Architektur
Wo der klinische Arbeitsplatz in direkter Unterstützung für die klinische Arbeit eingesetzt wird, werden X-Terminals wegen ihrer Robustheit bevorzugt. An privaten Arbeitsplätzen oder für Sekretariate ist ein Personal Computer eher geeignet. Robustheit ist hier weniger ein Problem. Diese Maschinen sind gewöhnlich weniger kritisch in dem Betrieb einer Abteilung als z. B. der klinische Arbeitsplatz in einem Operationssaal oder auf einer Säuglingsstation.
Hardware Architektur
Konzeptuelle Netzwerkarchitektur
Die konzeptuelle Hardware Architektur des vorliegenden Systems besteht aus drei Ebenen: eine Vorstellung des Arbeitsplatzes, ein Anwendungsserver und ein Datenbankserver. Diese sind mit einem Netzwerk verbunden und wirken als ein einzelnes System (siehe 9). Für jede der drei konzeptuellen Lagen werden verschiedene physikalische Maschinen verwendet. Dies erlaubt es, eine Hardware-Konfiguration für jede Ebene zu wählen, die optimal auf die Funktion dieser Ebene maßgeschneidert ist.
Vorstellung des Arbeitsplatzes
Auf dem Arbeitsplatz für die Vorstellung läuft nur die Software für die Vorstellung und der Rechner trägt keine Anwendungslogik. Keine „Programmierung" wird auf dieser Maschine ausgeführt. Dies ist die Maschine auf dem Arbeitsplatz, mit welcher der Benutzer interagiert. Das System muss in der Lage sein, eine grafische Benutzeroberfläche bzw. Benutzerschnittstelle laufen zu lassen, aber es sollte von Programmen auf dem Anwendungsserver gesteuert werden. Für die ersten beiden Implementierungen des vorliegenden Systems (Chirurgische Pathologie und Radiologie) wurden Macintoshes für die Vorstellung der Arbeitsplatz gewählt. Der Macintosh war zu jener Zeit (1990 und 1992) das kostengünstigste System, das in der Lage war, eine grafische Benutzerschnittstelle laufen zu lassen: es hatte ein grafisches Betriebssystem, ein Netzwerk war eingebaut und es war einfach zu verwalten.
Wie schon erwähnt, wurde X-Windows als die Software für die Benutzerschnittstelle für den klinischen Arbeitsplatz gewählt. Diese Software kann auf PC's, Macintoshes oder auf spezifischer Hardware, genannt X-Terminals, betrieben werden. Diese sind „intelligente" Terminals, die in der Lage sind, eine grafische Benutzeroberfläche laufen zu lassen, aber ohne die Notwendigkeit, lokale Software zu speichern. X-Terminals sehen wie Arbeitsplätze aus. Sie haben einen Prozessor und einen internen Speicher, aber sie verfügen über keine Festplatte. Wenn ein X-Terminal gestartet wird („booted"), dann wird es mit einem Hauptrechner (host computer) verbunden, der das Aufladen der gesamten notwendigen Software besorgt. Dies ist der Grund, warum keine lokale Festplatte gebraucht wird. Sie sind auch einfacher zu verwalten, da nach der Installation kaum irgendwelche lokale Interventionen benötigt werden. Das X-Terminal hat einen lokalen Prozessor und einen Speicher, aber dies wird nur für die Verarbeitung verwendet, und für die Speicherung von Daten, der für die Vorstellungssoftware gebraucht wird. Das Nicht-Vorhandensein einer Festplatte und der Mangel an lokaler Software machen das X-Terminal viel robuster als einen Personal Computer. Diese Maschinen stürzen selten ab, da sie keine bewegenden Teile haben. Wenn sie abstürzen, dann können sie gegen ein ähnliches Modell eingetauscht werden ohne viel Anstrengung, da keine lokalen Dateien benötigt werden, um von der alten Maschine auf die neue herüber transformiert zu werden. Die Kosten für Lösungen Client-Server sind im Vergleich zu denjenigen für X-Terminals viel höher, wenn man mit Personal Computer arbeitet. Um '93 herum waren die Kosten eines X-Terminals höher als diejenigen eines Macintosh, aber die Differenz war so gering, dass sie durch die Kosten der Migration durch die Hälfte des Projektes ausgeglichen wurde.
Während den X-Terminals die Nachteile eines PC fehlen, fehlt es ihnen auch an den Vorteilen eines PC. Keine lokale Verarbeitung ist möglich und die Standard Büro Automationsprogrammpakete, die auf Personal Computer weit verstreut verfügbar sind, haben kein wirkliches Gegenstück auf den UNIX-Maschinen, die gewöhnlich als Hauptrechner (host) für die X-Terminals dienen. Die X-Windows Software, die auf den X-Terminals läuft, kann auch auf den Personal Computer laufen. An solchen Stellen, wo ein Arbeitsplatz für beides verwendet wird, einmal als vorgeschaltete Maschine (front-end) für das Krankenhaus Informations-System und zum anderen für die Büroautomation, wird ein Macintosh mit X-Windows Software aufgestellt. Da der Anwendungsserver sich über das X-Windows Protokoll mit der Vorstellungssoftware unterhält, braucht keine zusätzliche Programmierung auf dem Anwendungsserver durchgeführt zu werden, um diese Konfiguration zu unterstützen.
Anwendungsserver
Der Anwendungsserver betreibt die vorliegende Systemumgebung. Die gesamte Anwendungsprogrammierung (mit der Ausnahme der gespeicherten Prozeduren, Ansichten und Triggern) wird auf diesem System durchgeführt. Der Anwendungsserver steuert den Arbeitsplatz für die Vorstellung über die X-Windows Client Software und er ist ein Klient des Datenbankservers. Nur Übergangsdaten, die nicht von mehreren Benutzern geteilt werden, werden auf diesem System gespeichert. Dies erlaubt es, viele Anwendungsserver zu haben, weil jeder unabhängig von den anderen funktionieren kann: alle Daten, die von anderen Benutzern gesehen werden müssen, werden zu dem Datenbankserver geschickt und alle Anwendungsserver werden mit diesem verbunden.
Der Anwendungsserver führt CPU intensive Aufgaben durch. Ereignisse von dem Windows Server triggern einige Prolog Programme. Dies führt zu der Ausgabe von Befehlen an den Windows Server. Manchmal werden Daten von dem Datenbankserver herausgesucht. Aber keine größeren Mengen von Daten werden auf dem Anwendungsserver verarbeitet. Die Platten auf dieser Maschine werden nur gebraucht, um das Betriebssystem zu speichern (und andere Software, die notwendig ist, um die Maschine auszunutzen), die Programme für den klinischen Arbeitsplatz und den Platz für das Austauschen. Jeder Prolog Prozess erfordert im Durchschnitt 22 Mb virtueller Speicher. Das Verhältnis des physikalischen Speichers gegenüber dem virtuellen Speicher wird beeinflusst von der erwarteten Anzahl gleichzeitig aktiver Benutzer und von der Anzahl der Funktionen in der Anwendung. Je mehr Funktionen in der Anwendung, desto kleiner der prozentuale Teil des Programms, der konstant eingesetzt wird: ein Benutzer kann nur ein paar Dinge gleichzeitig tun. Da jeder Benutzer eine spezifische Aufgabe hat, wird er oder sie nur (wiederholt) eine Untermenge von allen möglichen Funktionen verwenden und halten. Dies nennt man die Lokalität einer Funktion. Ein Angestellter in der Rezeption wird Aufnahmeformulare ausfüllen und in dieser Arbeit für die meiste Zeit fortfahren. Gemäss der Lokalität einer Funktion wird der Teil des Programms, der in dem physikalischen Speicher benötigt wird (der speicherresidente Teil) nicht ändern während des Einsatzes der Anwendung durch den gleichen Benutzer.
Datenbankserver
Der Datenbankserver betreibt nur den Serverteil der Datenbank. Auf dieser Maschine sind alle Daten, die zwischen den Benutzern geteilt werden, gespeichert. Es gibt nur einen Datenbankserver für alle Anwendungsserver. Der Datenbankserver erhält SQL Befehle von den Anwendungen über die Sybase Client Software. Kein Systemprogramm läuft auf dieser Maschine, aber einiges Anwendungswissen liegt speicherresident auf diesem System in der Form von Datenbanktriggern (verwendet für Konsistenz) und von Prozeduren (hauptsächlich für das Berichtswesen verwendet).
Indem man eine getrennte Maschine als Datenbankserver verwendet, kann die Konfiguration optimal auf ihren Einsatz maßgeschneidert werden. Der Datenbankserver behandelt große Mengen an Daten, so dass diese Maschine fähig sein muss, mit großen Volumen von Platten umzugehen. Die meisten Hersteller haben Maschinen in ihren Produktlinien, die spezifisch in Richtung des Betriebs von Datenbanken getrimmt sind.
Beispiel für die Verarbeitung eines Ereignisses in dieser 3 Ebenen Architektur
Angenommen, ein Benutzer drückt einen Druckknopf/-taste (button) auf einer Instrumententafel, um den medizinischen Bericht wiederzufinden, der mit einem besonderen Krankenhausaufenthalt verbunden ist (siehe 10). Wenn der Benutzer den Druckknopf drückt (1), dann erfasst der X-Windows Server dieses Ereignis. (2) Der Windows Server bemerkt – über das Netzwerk – den Windows Klienten auf dem Anwendungsserver des Ereignisses. Der Klient triggert die Ausführung des Programms, das geschrieben worden ist, um mit diesem Ereignis umzugehen. (3) Das Programm wird eine SQL Anweisung vorbereiten, um den Bericht zu finden. (4) Eine Sybase Client Funktion wird verwendet, um die SQL – wieder über das Netzwerk – an den Sybase Datenbankserver zu schicken. (5) Der Datenbankserver führt die SQL Anweisung aus, findet die Daten aus der Datenbank wieder und (6) sendet sie zu dem Klienten. (7) Das vorliegende Systemprogramm auf dem Anwendungsserver verwendet mehrere Sybase Client Funktionen, um die Daten auszulesen. (8) Unter Verwendung von X-Windows Client Funktionen erzeugt das System ein Berichtsfenster auf dem X-Terminal (über das Netzwerk) und (9) zeigt die Daten an, indem dieses Berichtsfenster verwendet wird.
Physikalische Netzwerkarchitektur
In Wirklichkeit sind die drei Typen von Computern nicht seriell miteinander vernetzt. Die physikalische Netzwerkarchitektur verwendet ein Ethernet Hauptnetzwerk (backbone), an das die Anwendungsserver und die Datenbankserver angeschlossen sind. Diese residieren in den Räumen der Hauptausrüstungen (MER = Main Equipment Rooms). Aus den MER sind fiberoptische Verbindungen zu den Räumen der Satellitenausrüstung (SER = Satellite Equipment Rooms) verlegt. Dies nennt man die „vertikale" Verkabelung. Ein SER ist ein kleiner Raum, der ein Schaltfeld enthält. Jeder Netzwerkausgang ist Punkt-zu-Punkt (point-to-point) mit dem Schaltfeld in einem nahe gelegenen SER verbunden. Dies nennt man die „horizontale" Verkabelung. Ein universelles Verkabelungssystem wird für diese Verbindung verwendet. Indem man kleinere Veränderungen an dem Ausgang anbringt und indem man die geeigneten aktiven Komponenten in dem SER aufstellt, könnten diese Kabel verwendet werden, um die am meisten gebräuchlichen Netzwerk- und Terminalprotokolle zu unterstützen (Ethernet, token ring, AppleTalk, RS 232, IBM 3270, ...). Die aktiven Komponenten in dem SER werden über eine vertikale Verkabelung mit den Servern in dem MER verbunden.
Der Hauptvorteil von diesem Kabelsystem besteht darin, dass ein Gebäude verkabelt werden kann, wenn es gebaut wird. Es ist nicht notwendig, den Typ der Netzwerkverbindungen im voraus zu kennen. Auch müssen keine Kabel ersetzt werden, wenn Netzwerkdienste für einen besonderen Raum geändert werden müssen. Zum Beispiel, wenn ein Benutzer von einem Terminal auf einen PC oder auf ein X-Terminal wechselt, dann muss der Ausgang seines Netzwerkes in dem SER an eine andere aktive Komponente neu verbunden werden. Möglicherweise muss der externe Stecker gewechselt werden. Die Verkabelung bedarf keiner Änderungen.
Ein Aufrüsten des Netzwerkes, um mit einem höheren Durchsatz umzugehen (z. B. geschaltetes Ethernet oder ATM), kann in der gleichen Weise bewerkstelligt werden. Der Nachteil ist, dass, um das System universal zu halten, einige Beschränkungen in Rechenschaft gezogen werden müssen. Die Entfernung zwischen dem SER und dem Netzwerkausgang kann 100 Meter nicht überschreiten und es muss eine Punkt-zu-Punkt Verbindung sein. Dies bedeutet, dass genug Netzwerkverbindungen für jeden Raum vorausgesehen werden müssen, da es nicht möglich ist, einen Arbeitsplatz über einen anderen Arbeitsplatz zu verbinden.
Die Skalierung des vorliegenden Systems
Da das vorliegende System ein paar Jahre brauchen wird, um krankenhausweit installiert zu werden, muss das System während dieser Zeit skaliert werden. Die Wirkung der Skalierung auf die drei Ebenen soll untersucht werden. Drei Dimensionen der Skalierung werden betrachtet:

• die Anzahl der Benutzer,
• die Größe der Anwendung (wenn die Zahl der Funktionen wachst, dann wird auch der Umfang des Programmcode wachsen), und
• der Umfang der gespeicherten Daten.

Es wird jetzt untersucht werden, was auf jeder der Ebenen der Hardware getan werden muss, um das Wachstum in jeder dieser Dimensionen anzupassen.
Vorstellung des Arbeitsplatzes
Dies ist die einfachste Ebene der Skalierung: einer wird pro Arbeitsplatz hinzugefügt. Der Umfang der Daten in der Datenbank beeinflusst die Parameter des Arbeitsplatzes nicht, weil der Benutzer immer Listen von einer solchen Länge anfordern wird, welche auf dem Bildschirm gelesen werden können. Es ist nicht üblich, die Berichtslisten anwachsen zu lassen, wenn der Umfang der Daten in der Datenbank anwachst.
Das gleiche gilt für die Größe der Anwendung. Während die Anzahl der Fenster, die geöffnet werden können, wachsen mag, ist die Anzahl der Fenster, die von dem Benutzer gleichzeitig geöffnet werden bzw. geöffnet sind, begrenzt durch das, was ergonomisch akzeptabel ist. Wenn zu viele Fenster den Desktop verwirren, dann wird der Benutzer diese Fenster automatisch schließen.
Für einen gegebenen Typ von Funktionen wird das Hinzufügen weiterer Funktionen einen fortgeschritteneren Arbeitsplatz nicht erfordern, da der Benutzer der limitierende Faktor ist und weil er nur eine kleine Untermenge von diesem größeren Ganzen gleichzeitig benutzen wird.
Anwendungsserver
Der Anwendungsserver skaliert ebenfalls trivial mit der Anzahl der Benutzer: jeder Typ eines Anwendungsservers kann eine bestimmte Menge an Benutzern unterbringen, abhängig von seiner Verarbeitungsleistung und von seinem internen Speicherplatz. Das Hinzufügen von Benutzern bedeutet das Hinzufügen oder die Ausweitung von Anwendungsservern.
Wenn die Größe der Anwendung wächst, wird mehr virtueller Speicherplatz pro Benutzer benötigt, weil mehr Programmcode und mehr Datenstrukturen in dem Speicher gespeichert werden müssen. Entweder wird mehr Speicherplatz hinzugefügt oder mehr Anwendungsserver werden installiert (oder beides wird hinzugefügt, Speicher und CPU Kapazität).
Der Umfang der gespeicherten Daten beeinflusst den Anwendungsserver nicht, da diese nur durch den Anwendungsserver hindurch geleitet werden, der die Daten formatiert, damit sie auf dem Arbeitsplatz für die Vorstellung angezeigt werden können. Da die Daten nicht gespeichert werden und da die Anzahl der Datensätze automatisch begrenzt werden wird durch das was von den Benutzern im Umgang mit diesen Datensätzen noch bewerkstelligt werden kann, wird der Umfang der Daten, der von dem Anwendungsserver verarbeitet werden muss, nicht mit der Länge der Datenbank ansteigen.
Datenbankserver
Der Datenbankserver muss mit der Anzahl der Benutzer skaliert werden: mehr Benutzer bedeuten mehr gleichzeitige Abfragen und Transaktionen. Beides, Speicher und Verarbeitungsleistung, wird hinzugefügt werden müssen. Die Skalierung von Datenbankservern erfolgt nicht linear durch einfache Hinzufügung von Hardware.
Die Größe der Anwendung alleine beeinflusst nicht die Belastung des Datenbankservers: die Benutzer werden mehrere Wege haben, die gleichen Daten anzusehen. Dies mag zu einer größeren Benutzung des Computers führen, aber, da ein Benutzer nur eine Sache gleichzeitig tun kann, wird dieser Anstieg nicht bedeutsam sein.
Wenn der Umfang der Daten wesentlich ansteigt, müssen mehr Speicherplatten und wahrscheinlich mehr Verarbeitungsleistung und Speicher (wenn die Antwortzeiten der Abfragen konstant gehalten werden sollen) hinzugefügt werden. Die Leistung der Abfragen skaliert logarithmisch mit der Größe der Tabellen gemäß der vorliegenden Technik der Datenmodellierung. Die Technik der Datenmodellierung löst nicht das Problem, dass vielfache Benutzer gleichzeitig Aktualisierungen (Updates) in der Datenbank vornehmen. Mehr Benutzer und mehr Daten müssen ausgeglichen werden durch Hinzufügen von Hardware und eleganter Datenbankalgorithmen.
Es wird erwartet, höchstens 1000 gleichzeitige Benutzer in dem vorliegenden System zu haben. Der Umgang damit kann schon von der gegenwärtig zur Verfügung stehenden Technologie bewerkstelligt werden. Datenbankverkäufer sind dabei, die Parallelverarbeitung ihrer Server zu verbessern, und Computer mit 10 und mehr Prozessoren sind Stand der Technik. Daher ist es möglich, die Datenbank auf mehr als 1000 Benutzer zu skalieren.
Als Schlussfolgerung bleibt anzumerken, dass die Skalierung des vorliegenden Systems auf die Skalierung des back-end Datenbankservers herunter geführt wird. Auf allen anderen Ebenen erfolgt die Skalierung linear durch Hinzufügung von Hardware.
Software Architektur
Es würde zu viele Ressourcen erfordern, um Anwendungen für alle Abteilungen in dem Krankenhaus getrennt zu entwickeln. Die Implementierungszeit für die Gesamtheit des Krankenhauses würde unakzeptierbar lang sein. Um die Entwicklung zu beschleunigen, hat man entschieden, zuerst einen Satz von generischen Softwaremodulen zu entwickeln, um als größere Bausteine für nachfolgende Anwendungen zu dienen. Die bei U. Z. Leuven entwickelte Software kann in 4 Gruppen eingeteilt werden: der Systemgenerator, die Systemwerkzeuge, die Erbauer und die klinischen Arbeitsplatzmodule. Die chirurgische Pathologie, die Radiologie und die klinischen Arbeitsplatzmodule teilen alle den Generator und die Systemwerkzeuge als die Basisbausteine.
Die ersten drei Typen von Modulen sind generische Module und werden hier diskutiert werden.
Der Systemgenerator
Der Systemgenerator besteht aus drei Modulen, die eng miteinander interagieren. Er liefert eine Schnittstelle auf höherer Ebene zu Sybase und X-Windows und implementiert das Konzept von Formen auf der Spitze einer löschungsfreien Datenbank auf eine generische Art und Weise. Der Generator ist nicht spezifisch für Krankenhäuser.
In 11 ist der Datenfluss vertreten zwischen der Darstellung und der Datenbank. In einer Anwendung werden Daten konstant zwischen dem Bildschirm (dem vorgeschalteten Ende bzw. front-end, im vorliegenden Fall X-Windows) und der Datenbank (dem nachgeschalteten Ende bzw. back-end, in dem vorliegenden Fall Sybase) transportiert. Zwischendurch wird von der Anwendung eine Formatierung, eine Bearbeitung und ein Prüfcheck der Daten vorgenommen. Prozeduren sind speziell strukturierte Anwendungsteile und einzig und alleine für die Prüfung der Datenintegrität bestimmt. Der Generator liefert Werkzeuge, um einen großen Teil dieses Transportes zwischen der front-end Einrichtung und der back-end Einrichtung zu übernehmen. Wegen der Verwendung der Form Metapher können alle Teile der Anwendung, die sich auf Formen bzw. Formblätter beziehen, in einer generischen Weise behandelt werden.
Die drei Module sind:

• motifShell,
• messageTools und
• formTools.

Ihre Wechselwirkung wird in 12 gezeigt. Module können untergeordnete Module benutzen, aber nicht umgekehrt. Z. B. kann die Anwendung das Modul formTools nutzen, das seinerseits motifShell nutzt, das X-Windows nutzt, um Daten auf dem Bildschirm anzuzeigen, aber motifShell kann niemals Funktionen aus den formTools aufrufen.
MotifShell
MotifShell wird eingesetzt, um den Umgang mit allen Darstellungsaufgaben in den vorliegenden Systemanwendungen zu bewerkstelligen. Grob gesehen dient das Modul zu drei Zwecken:

• eine Prolog Schnittstelle zu Motif/X-Windows,
• eine Implementierung von Schnittstellenobjekten auf hoher Ebene, und
• eine Beschleunigungsoptimierung.

Dadurch dass man ein generisches Modul für den Umgang mit diesen Aufgaben hat, vermeidet man es, dieses für ein jedes Programm oder für eine jede Anwendung neu zu erstellen, und der Zugang zu dem X-Windows Darstellungspaket kann standardisiert werden, was die Wartung und Pflege erleichtert.
Prolog Schnittstelle
Der erste Zweck dieses Moduls besteht darin, den Systemprogrammierer von den Details der unteren Ebene von X-Windows zu schützen. Alle X-Client Funktionen haben ihre Prolog Gegenstücke und diese werden in der Anwendungsprogrammierung eingesetzt. Es ist die Prolog Version der X-Windows Client Software. Abgesehen von dieser Funktionalität der unteren Ebene, stellt motifShell mächtige Prädikate der hohen Ebene zur Verfügung, die einen Teil der Arbeit automatisieren, die darin besteht Fenster in X-Windows zu erzeugen und zu verwalten.
Die Erzeugungsfunktion des Fensters wird erzeugt durch ein Werkzeug, das Builder Xcessory (BX) genannt wird. Dieses Werkzeug wird nur benutzt, um das Fenster zu entwerfen („paint” d. h. „malen"). Nur die Ressourcen, die benötigt werden, um den Typ der Widgets und ihrer positionellen Wechselbeziehungen (Ausrichtung aufeinander, Festlegung welche Widgets welche anderen Widgets verwalten) zu bestimmen, werden festgesetzt unter Verwendung von BX. Dies sind Ressourcen, die in der Zeit relativ fest sind und die wenig Wartung benötigen. Alle Ressourcen, die wahrscheinlich Wartung in der Zukunft benötigen werden, werden in der Prolog Anwendung festgelegt. Dies erlaubt es, die Erzeugungsfunktion mit BX zu generieren, sie mit der Systemanwendung zu verbinden und sie dann fast nie mehr zu berühren. Die gesamte Wartung und Pflege kann dann auf der Prolog Ebene erfolgen.
Um die Anwendungsentwicklung zu beschleunigen, wurde ein kleiner Interpreter gebaut, um das Festsetzen von Ressourcen auf einer höheren konzeptuellen Ebene zu erlauben. Für jede Art von Fenster („shell") muss eine Datenstruktur definiert werden. Diese Datenstruktur enthält Instruktionen der hohen Ebene, um Fensterparameter festzusetzen oder zu modifizieren (siehe 13). Ein kleines Programm liest diese, und für jede Instruktion gibt es eine oder mehrere Regeln, die bestimmen, welche Instruktionen der niedrigen Ebene ausgeführt werden müssen. Eine Instruktion kann zu der Ausführung von einigen X-Windows Client Instruktionen der niedrigen Ebene führen. Prolog ist sehr geeignet, um diese Typen von Programmen zu schreiben. Wenn man solch einen Interpreter hat, dann wird die Anwendungsentwicklung beschleunigt, weil viele komplexe Aufgaben in einer Systeminstruktion gebündelt werden können. Der Interpreter ist einfach in der Wartung, weil das Programm, das die Ausführung der Instruktionen der hohen Ebene antreibt, ein Regelwerk benutzt, um sie zu „dekodieren". Um Instruktionen der hohen Ebene hinzuzufügen, werden nur Regeln für das Hinzufügen benötigt. Diese Regeln können unabhängig voneinander gewartet und gepflegt werden.
Anzeigelemente der hohen Ebene
MotifShell definiert auch „Widgets" der hohen Ebene, wie die logicBox. Die logicBox ist ein Widget, das zwei Darstellungen von Daten, die von ihm gehandhabt werden aufrechterhält: eine Textdarstellung, die verwendet wird, um die Daten zu visualisieren, und eine logische Darstellung, die intern verwendet wird, und die eine reichere Struktur als reiner Text besitzt. Der Anwendungsprogrammierer kann beide Darstellungen verwenden und bearbeiten. Die Synchronisation von beiden Darstellungen und die Abbildung der logicBox Instruktionen der hohen Ebene auf die Widget-Instruktionen der unteren Ebene von X-Windows wird in einer generischen Art bewerkstelligt. Die logicBox definiert einen Satz von Regeln, die der Programmierer liefern soll, um alle anwendungsspezifischen Aufgaben zu bewerkstelligen.
Die logicBox kann dazu benutzt werden, um eine Graphik durchzusehen (browse). Dies wird häufig in dem klinischen Arbeitsplatz eingesetzt. Oft muss das System dem Benutzer einen Satz von Optionen darstellen. Wenn der Benutzer eine Option auswählt, wird ein Satz von Unteroptionen dargestellt. Die Auswahl einer Unteroption könnte wieder neue Optionen auflisten bis die gewünschte Option erreicht ist. Diese Technik wird verwendet, wenn immer die Benutzer aus einer Liste von Optionen auswählen müssen, die zu groß ist, um sie auf einem Bildschirm anzuzeigen. Z. B. gibt es über 700 radiologische Prüfungen, die angefordert werden können. Eine grafische Struktur wird oben auf der Spitze dieses Mengensatzes definiert, was es ermöglicht, auf die gewünschte Prüfung zu „zoomen". Oft müssen solche großen Sätze von Optionen von den Benutzern durchgebrowst bzw. durchgesehen werden. Die logicBox erlaubt es, nur die variablen Teile in der Form der Regeln zu spezifizieren. Die Struktur der Graphik (d. h. die Beziehung zwischen den Optionen: die Ebenen oben übergelagert auf anderen Ebenen von Optionen, und die möglichen Navigationspfade durch diese Struktur) wird spezifiziert, indem Prolog Regeln angewendet werden. Der Programmcode, der durch die Struktur navigiert, die Bildschirme aktualisiert, auf Ereignisse reagiert usw. ist ein ganz generischer Code. Er interpretiert die Regeln, die spezifiziert wurden, um sich für geeignete Handlungen zu entscheiden.
Ein anderes Objekt der hohen Ebene ist eine Tabelle mit der Möglichkeit, Graphen zu erzeugen, die auf Daten in der Tabelle basieren. Das Tabellen-Widget wird verwendet, um alle Arten von Listen in einem Tabellenformat anzuzeigen. MotifShell stellt mehrere optimierte Prädikate zur Verfügung, um auf die Tabelle zuzugreifen, um zu sortieren, um Zeilen und Kolonnen auszulesen, usw. .... GraphTools ist ein Modul, das es für eine gegebene Tabelle dem Benutzer erlaubt, Kreisdiagramme, Kurven, Balkendiagramme, ... zu erstellen, auf der Basis der Daten in der Tabelle. Eine Schnittstelle des Programmierers zu GraphTools existiert, um anwendungsspezifische Diagramme in einem Befehl herzustellen.
Optimierung
MotifShell optimiert auch die Geschwindigkeit der Schnittstelle. Die Erstellung von großen und komplexen Fenstern kann einige Sekunden erfordern. In den vorliegenden Systemanwendungen öffnet der Benutzer oft eine elektronische Form gerade nur, um auf den Dateninhalt zu schauen, und dann schließt er es wieder. Um zu vermeiden, dass das Fenster jedes Mal erstellt wird, wenn es geöffnet wird, zerstört motifShell nicht das Fenster, wenn der Benutzer es schließt, sondern es versteckt dasselbe. Wenn die Benutzer das Fenster wieder öffnen wollen, dann macht motifShell das alte Fenster wieder sichtbar. Der Programmierer kann spezifizieren, welche Teile des Fensters neu initialisiert werden müssen, wenn ein Fenster auf diese Weise wieder geöffnet wird. Dies schraubt die Beschleunigung der Öffnung von Fenstern beträchtlich nach oben. Die Einbuße an Leistung der realen Erstellung wird für jedes Fenster nur einmal auf sich geladen. Wenn der Benutzer eine zweite Version des gleichen Typs von Fenster wünscht, dann erfasst motifShell dieses und erzeugt eine zweite Kopie. Beim Schließen dieser zweiten Kopie wird diese auch nicht zerstört, sondern versteckt.
Der Kompromiss ist Speicherplatz: weil die Fenster nicht zerstört, sondern versteckt sind, erfordert die versteckte Darstellung noch Speicherplatz dafür. MotifShell verwaltet diesen Speicherplatz und kann entscheiden, Speicherplatz frei zu geben (durch Zerstörung des Fensters), wenn es notwendig ist. Dies alles ist vollständig transparent für den Benutzer: es gibt keinen Unterschied zwischen einem neu erzeugten Fenster und einem „wiederhergestellten" Fenster. Die Benutzer werden sich nur die Einbuße an Leistung erleiden, die mit dem erstmaligen Erzeugen der Fenster zusammenhängt, am Beginn einer neu gestarteten Sitzung mit dem klinischen Arbeitsplatz. Nachdem alle Fenster erst einmal erstellt worden sind (oder mehr, falls der Benutzer mehr als eine Kopie eines Fensters gleichzeitig geöffnet haben will) wird das System in der Lage sein, fast nur wiederhergestellte Fenster zu verwenden. Die meisten Benutzer werden nur eine Untermenge von allen in dem klinischen Arbeitsplatz verfügbaren Fenstern öffnen wegen der Lokalität der Funktion. Wegen der Lokalität der Funktion braucht man die verborgene Darstellung von nur einer Untermenge zu speichern, um alle Fenster für einen besonderen Benutzer wiederhergestellt zu haben.
Während es oft komplexer ist, auf einer generischen Ebene zu optimieren, ist die Entlohnung größer: alle Anwendungen profitieren von der Optimierung. Die allgemeine Optimierung ist gewöhnlich besser, da nicht alle Programmierer sich der Mühe unterziehen werden, jedes Programm zu optimieren.
MessageTools
MessageTools ist das niedrigste Modul auf der Datenbankseite des Systems und das einzige Modul, das direkt den Sybase Clienten nutzt. MessageTools hat grob gesehen drei Zwecke:

• eine generische Unterstützung für das konzeptuelle Datenmodell des Generators zu implementieren,
• eine Schnittstelle auf einer höheren Ebene zu Sybase zur Verfügung zu stellen als die Schnittstelle Prolog – Sybase durch BIM, und
• eine Optimierung.

Generische Unterstützung für das konzeptuelle Datenmodell des Generators
Das konzeptuelle Datenmodell des Generators basiert auf dem löschungslosen Modell. Wenn der Benutzer eine Nachricht einfügt („sendet"), kennzeichnet das System diese zeitlich und speichert den Namen des Benutzers mit der Nachricht. Ein Benutzer kann eine Nachricht löschen („weglassen"), aber die Nachricht wird nur aus der Ansicht oben an der Spitze des x#table beseitigt, indem das Kennzeichen des Weglassens (omit flag) auf „o" gesetzt wird. Wenn ein Benutzer den Dateninhalt einer Nachricht ändert und diesen neuen Inhalt als eine Korrektur der alten Nachricht an die Datenbank sendet, dann übersetzt messageTools diese Operation in eine Unterlassung der alten Nachricht, in eine Einfügung der neuen Nachricht und verbindet die neue Nachricht mit der alten Nachricht. Um dies zu bewerkstelligen, verfingt messageTools über einen Programmcode, der mit allen Nachrichten in einer generischen Weise umgeht. Es verwendet auch einen spezifischen SQL Programmcode, der von dem formBuilder erzeugt wurde, um mit solchen Aufgaben umzugehen, die zu spezifisch sind oder bei denen es ineffizient wäre, würde man sie generisch behandeln.
MessageTools arbeitet auf dem konzeptuellen Datenmodell des Generators. Alle Verarbeitungen auf der physikalischen Ebene des Datenmodells werden durchgeführt, indem Trigger oder Prozeduren verwendet werden. Der größte Teil dieses SQL Programmcode wird automatisch von dem formBuilder erzeugt.
Schnittstelle der hohen Ebene zu Sybase
Der Anwendungsprogrammierer ruft nur ein Prolog Prädikat auf, um eine Einfügung, eine Unterlassung oder eine Löschung zu vollziehen. MessageTools wird das Sybase Datenwörterbuch fragen, um die notwendige Information herauszufinden, um SQL Instruktionen zu erzeugen, die erforderlich sind, um die Operation der Datenbank durchzuführen. Ein Aufruf von messageTools führt gewöhnlich zu mehreren Sybase Client-Aufrufen. Weil es selbst das Datenwörterbuch fragen wird, ist es nicht notwendig, ein Patienten messageTools hinzuzufügen, jedes Mal wenn eine neue Tabelle in dem System erstellt wird.
MessageTools ist das einzige Modul, das direkt auf die Sybase Client Software zugreift. Der Vorteil liegt darin, dass alle Module der höheren Ebenen geschützt sind vor den Idiosynkrasien des Sybase Clienten. Abgesehen davon, dass der Zugriff auf Sybase einfacher gemacht wird, ist dies auch ein Vorteil der Wartung. Veränderungen in der Sybase Client Software verursachen nur in einem Modul Veränderungen. Gewöhnlich ändert sich Software graduell, aber manchmal muss man auch totale Veränderungen mit berücksichtigen. Sybase wählte in '93, ihre Client Software zu ändern: die gegenwärtige Client Software (DB-lib) wird noch beibehalten und unterstützt, aber keine neuen Merkmale werden hinzugefügt. Die neue Schnittstellensoftware (CT-lib) wird graduell die alte Software ersetzen und man erwartet, dass die Unterstützung für die alte Schnittstelle irgendwann in der Zukunft eingestellt werden wird. MessageTools wird von DB-lib auf CT-lib transportiert und, wenn die Veränderungen nur auf messageTools beschränkt bleiben können, dann braucht kein Anwendungsprogramm angepasst zu werden.
Optimierung
MessageTools optimiert auch den Sybase Zugriff. Die Lokalität einer Funktion hat als Effekt auf die Datenbank, dass nicht alle Benutzer auf alle Tabellen oder Sichtweisen zugreifen werden. MessageTools erinnert sich an die Meta-Daten, die es lokal wiederfand. Wenn ein Benutzer die Daten später in der Sitzung wieder braucht, dann findet messageTools diese aus seinem internen Datenwörterbuch wieder, ohne auf den Sybase Server zu gehen.
Jeder Benutzer benötigt einen „Prozess" auf den Datenbankserver. Der Client übergibt die SQL-Befehle an diesen Prozess, der sie ausführt und die Ergebnisse zurück an den Clienten sendet. Einen Prozess zu öffnen, jedes Mal wenn ein SQL-Befehl verarbeitet werden muss, ist zu viel allgemeine Belastung, und das Offenhalten nicht benötigter Prozesse ist ineffizient. MessageTools verwaltet die Prozessnutzung. Der Anwendungsprogrammierer spezifiziert, wie viele Prozesse ein Benutzer gleichzeitig geöffnet halten kann. MessageTools wird das Öffnen von extra Prozessen erlauben, aber es wird alle überflüssigen Prozesse schließen, nachdem sie ihre Arbeit abgeschlossen haben. All dies ist transparent für die Anwendung.
Formtools
Formtools implementiert die Basissystem 9 Metapher: das elektronische Verschicken von Formblättern. Es benutzt motifShell für die Benutzerschnittstelle und messageTools für den Zugriff auf die Datenbank. Formtools greift auf diese Module über das gleiche API zu (Application Programmers Interface = Schnittstelle des Anwendungsprogrammierers) wie es die Anwendungen des Systems 9 tun. Mit anderen Worten, formTools ist eine Anwendung für messageTools und motifShell.
Formtools stellt die Verbindung zwischen der visuellen Darstellung der Nachricht (die elektronische Form) und der Datenbanktabelle dar, die verwendet wird, um die Daten der Nachricht zu speichern. Es bewerkstelligt alle Standardoperationen mit den Formblättern in einer generischen Weise, vermindert dabei wieder den Umfang des zu schreibenden Codes. Diese Standardoperationen können von der Schaltsymbolleiste aufgerufen werden, die auf jedem Formblatt des Systems vorhanden ist. Ihre Funktionen werden kurz erklärt:
Send Formtools checkt die Formprozeduren (siehe nächsten Abschnitt), sendet den Inhalt der Form zu messageTools, das es weiter sendet zu der Datenbank. Der Inhalt der Form wird gespeichert in einer Tabelle mit den gleichen Namen wie die Form. Nur der Inhalt der Felder auf der Form mit einem Namen, der auch ein Name einer Kolonne in dieser Tabelle ist, wird gespeichert. Nur das Minimum an Daten, das benötigt wird, um die Form zu rekonstruieren, wird gespeichert. Von diesen minimalen Daten sagt man, sie seien Teil der Nachricht. Der Benutzer braucht nicht zu spezifizieren, welche Widgets Teil der Nachricht sind: Formtools greift auf das Sybase Datenwörterbuch zu, um den Namen der Kolonnen wiederzufinden und es baut automatisch die Nachricht aus dem Inhalt der entsprechenden Felder.
Wenn die Nachricht von der Datenbank angenommen wird (Datenbanktrigger führen Prüfchecks an dem Inhalt durch und können bewirken das ein Einfügen abbricht), dann wird ihr ein eindeutiger Schlüssel (der dkey) zugewiesen. Der dkey und der Name des Benutzers, der das Formblatt sandte, werden in der rechten Seite der Form angezeigt.
Receive Formtools wird den Inhalt aus allen nicht-leeren editierbaren Feldern der Form wiederfinden. Der resultierende „Auswahl-Datensatz" wird verwendet, um eine SQL Anfrage zu erzeugen, um alle Datensätze wiederzufinden, die die gleichen Werte für diese Kolonnen aufweisen. Das Ergebnis wird dargestellt als eine Liste von Datensätzen.
Clear Alle Felder der Form werden frei gemacht, das heißt, Editfelder werden geleert und Checkboxen bzw. Kontrollkästen werden deaktiviert. Popup Menüs werden zurückgesetzt.
Initialize Die Form verschwindet und eine neue Kopie des Originals des Standardformblattes wird auf den Bildschirm gezogen. Wenn eine Initialisierungsfunktion mit der Form verbunden ist, wird diese verwendet, um die Form wiederherzustellen.
Context Zeigt an, wer das Formblatt sandte und wann.
Omit Das Formblatt wird weggelassen (logisch gelöscht: es ist nicht länger sichtbar in der Tabellenansicht, aber es existiert noch auf der physikalischen Ebene).
Correct Nach der Veränderung des Inhaltes des Formblattes kann der Benutzer den Druckknopf (button) drücken, um die alte Nachricht durch die neue zu ersetzen. Was auf der formTools Ebene geschieht, ist sehr ähnlich zu dem Versenden einer Form mit der Ausnahme, dass der dkey der Nachricht, die korrigiert werden soll, mit der Nachricht an messageTools übergeben wird.
Formprozeduren, Initialisierung und Empfangsregeln
Wenn eine Form korrekt definiert worden ist, erlaubt es das System dem Benutzer, Daten hinzuzufügen, wegzulassen und zu korrigieren, ohne dass man ein Anwendungsprogramm hat, das dafür geschrieben worden ist. Manchmal muss die Anwendung die Integrität der Daten prüfen, bevor es die Erlaubnis zum Speichern gibt, oder nach der Speicherung der Daten kann die Anwendung irgendetwas in einer anderen Tabelle oder auf dem Bildschirm des Benutzers ändern. Dies kann nicht generisch behandelt werden. Um der Anwendung zu erlauben einzugreifen, wenn es notwendig ist, können Formprozeduren von der Anwendung definiert werden.
Formprozeduren sind Prolog Regeln, die von formTools vor und nach jedem Befehl des Versendens, Weglassens und Korrigierens aufgerufen werden. Z. B. gibt es vier Typen von dem, was mit dem Versenden einer Form verbunden sein kann: beforeSend, beforeSendOnly, afterSend und afterSendOnly. Da eine Korrektur in ein Weglassen und ein Senden übersetzt wird, werden beforeSend und afterSend auch aufgerufen, wenn eine Nachricht gesandt wird, um eine andere Nachricht zu korrigieren. Indem diese Regeln verwendet werden, kann ein anwendungsspezifischer Code ausgeführt werden zwischen den generischen Teilen. Die before-Regeln werden typischerweise eingesetzt, um Prüfungen der Integrität von Daten durchzuführen, die zu schwierig in SQL auszudrücken sind. Die alter-Regeln führen gewöhnlich Säuberungsaufgaben durch (z. B. automatisches Schließen eines Fensters, wenn die Form erfolgreich versendet wurde). Viele Regeln des gleichen Typs oder von verschiedenen Typs können für die gleiche Form definiert werden.
Die Initialisierungsregeln definieren, was getan werden muss, wenn eine Form geöffnet wird. Gewöhnlich füllen diese Regeln die Form mit vordefinierten Werten aus (diese können variieren in Abhängigkeit von dem Benutzer, von der Abteilung, ...).
Die Empfangsregel kann verwendet werden, um den normalen Weg, einen Empfang auf einer Form zu vermerken, abzuschneiden. Dies wird verwendet, wenn die generische Implementierung des Empfangs zu ineffizient sein würde. Die Empfangsregel kann mehr effiziente Abfragen ableiten, basierend auf dem Anwendungswissen, indem auf die Parameter geschaut wird, die die Suche beschränken.
Nur Speichern was gebraucht wird
Bei der Diskussion um den Versand der Form ist festgestellt worden, dass formTools nur den Inhalt der Felder auf der Form speichert, die einen Namen haben, der auch als Kolonnenname in der entsprechenden Tabelle erscheint. Gewöhnlich gibt es viel mehr Felder auf einer Form als diejenigen, die gespeichert werden. Z. B. viele Formen zeigen des Patienten Namen und Nummer an, aber nur die Nummer ist gespeichert. Dies ist übliche Praxis bei dem Entwurf eines Datenmodells. Die Nummer wird als Referenz zu mehr Daten verwendet (in diesem Fall demographische Daten), so dass, wenn sich irgendwelche davon ändern, die Daten nur an einer Stelle aktualisiert werden müssen (in der Identifikationstabelle des Patienten). Alle anderen Tabellen beziehen sich auf den Patienten, wobei sie die eindeutige Nummer des Patienten verwenden, und sie können die korrekte Information aus dieser Tabelle wiederfinden. Wenn die Daten in jeder Tabelle dupliziert würden, würde die Korrektur eines einfachen Rechtschreibfehlers in des Patienten Namen Aktualisierungen in zahllosen Tabellen erfordern.
Solch eine Situation tritt gewöhnlich viele Male sogar auf einfachen elektronischen Formen auf. Das Zuweisungsformblatt z. B. weist einen Patientenbesuch (z. B. einen Ambulanzbesuch) an einen Assistenten und an einen Überwacher zu. Das Formblatt (siehe 15) listet den Namen (Vor- und Nachname) des Patienten auf, die Nummer und den Typ des Besuches, und die ID, den Vor- und Nachnamen des Assistenten und des Überwachers. Obwohl alle diese Information notwendig ist, um den Benutzern zu ermöglichen, das Formblatt zu verstehen, werden nur die Besuchsnummer, die Identifikationsnummer des Assistenten und die Identifikationsnummer des Überwachers benötigt, um die Beziehung zwischen dem Besuch des Patienten und den zwei Ärzten auszudrücken. Die Besuchsnummer ist mit der Nummer des Patienten über eine Aufnahmetabelle verbunden. Der Name des Patienten kann aus der Identifikationstabelle des Patienten wiedergefunden werden. Daher werden nur die drei Identifikationsnummern benötigt. Wenn das Formblatt von den Benutzern verstanden werden soll, muss die Information, die mit den Nummern verbunden ist, auch angezeigt werden.
Weil dies viele Male auf allen Formblättern passiert, wurde dafür eine generische Lösung gewählt. Geradeso wie formTools die Definition der Tabellenansicht verwendet (die die konzeptuelle Ebene ganz oben auf der physikalischen Ebene definiert), um Daten einzufügen, sucht es nach der Sichtweise der Aufnahme, um das Formblatt anzuzeigen. Die Aufnahmeansicht hat den gleichen Namen wie die Tabellenansicht mit r# ganz am Anfang. Die Aufnahmeansicht bindet die Information aus den verschiedenen darunter liegenden Tabellen zusammen. FormTools verwendet sie, um Daten auf dem Formblatt zu anzuzeigen. Genauso wie mit dem Versenden, entsprechen Kolonnennamen in der Ansichtsdefinition Feldern auf dem Formblatt.
In einer Art wirkt die Ansichtsdefinition der Aufnahme als eine spezifische Anwendungsregel, die von einer generischen Anwendung (formTools) verwendet wird. Es würde möglich sein, die Ansicht der Aufnahme in Prolog zu spezifizieren, aber dies würde weit weniger effizient sein. Weil es als eine Datenbankansicht spezifiziert ist, kann die Ansicht der Aufnahme auch verwandt werden, um neue Sichtweisen zu erzeugen.
Schnittstelle der hohen Ebene
Abgesehen davon, dass es eine generische Anwendung mit eigenem Funktionszweck ist, stellt formTools auch eine Schnittstelle der hohen Ebene an der Spitze von beiden zur Verfügung, sowohl messageTools (Sybase) als auch motifShell (Motif/X-Windows), um damit spezifische Anwendungen zu bauen. Theoretisch könnte man irgendeine Anwendung erstellen, indem man lediglich die Funktionalität von formTools verwendet, aber dies würde ergonomisch nicht akzeptabel sein. Benutzer wünschen und brauchen anwendungsspezifische Kurztastaturen. Dies resultiert in extra Tasten und Menüs auf den Formblättern. FormTools sieht Prädikate vor, um Formblätter zu bearbeiten, was die Implementierung von solchen extra Funktionen erleichtert.
Benutzer betrachten die Inhalte von anderen Formblättern gewöhnlich in der Form von (Arbeits-)Listen. Ein typischer Benutzer schaltet dauernd zwischen dem Abfragen der Datenbank und dem Hinzufügen von Daten hin und her. Das handleQuery Prädikat erlaubt es, eine Abfrage zu spezifizieren sowie die Optionen, die Ergebnisse anzuzeigen; es sendet die Abfrage an die Datenbank, findet die Ergebnisse heraus und zeigt sie an. Da es viele Parameter gibt, die spezifiziert werden können, wurde ein kleiner Interpreter geschrieben, um einen Programmcode auf der niedrigen Ebene zu erzeugen, der jedem dieser Parameter entspricht. Es gibt natürlich eine Belastung bei der Erstellung eines Prädikates von der Komplexität einer handleQuery, aber es zahlt sich aus: fast alle Listen in System 9 Programmen werden erzeugt durch Verwendung dieses Prädikates.
Schlussfolgerung
Das Ziel des vorliegenden Generators des Systems besteht darin, soviel Bearbeitung wie möglich auf einer generischen Ebene zu bewerkstelligen. Dies vermindert den gesamten Umfang des Programmcodes und dadurch steigt die Wartungsfähigkeit nicht nur durch eine Verminderung des Codes, sondern auch durch Standardisierung. Die Reichhaltigkeit der Werkzeuge erlaubt eine schnellere Entwicklung. Der Nachteil besteht darin, dass die Werkzeuge selbst gebaut und gewartet werden müssen. Je größer das System, desto größer ist der Rückfluss solch eines Ansatzes, da mehr Leute und mehr Programmcode von dem gleichen Satz an Werkzeugen profitieren können.
Der vorliegende Generator des Systems wird und ist ständig verbessert worden. Jede sich wiederholende Programmaufgabe wird genau untersucht, um zu sehen, ob sie in einen generischen und in einen anwendungsspezifischen Teil aufgeteilt werden kann. Wenn es der Fall ist und wenn man erwartet, dass der generische Teil in der Zukunft benötigt wird, dann wird die generische Funktionalität zu dem geeigneten Modul hinzugefügt oder ein spezifisches Modul wird erstellt. Dies ist der Weg, wie der Generator konstant verfeinert werden kann. Jean et al. befürwortet die Verwendung einer homogenen Plattform, um alle Module eines klinischen Arbeitsplatzes zu integrieren. Die Autoren unterscheiden 4 Aspekte der Integration: Daten, Darstellung, Kommunikation und Kontrollintegration. Der Generator des Systems löst die ersten beiden durch die Bereitstellung von Entwicklungswerkzeugen. Kontrollintegration wird teilweise abgebildet durch die Strategie der Datenmodellierung (Fortschritt entlang der Zeitachse der Arbeitseinheit; nicht-konzeptuelle Tabellen, um explizit den Zustand dieses Fortschrittes zu speichern), aber keine generischen Softwaremodule stehen zur Verfügung, um dies zu unterstützen. Ein generisches Kommunikationsmodul, das auf der Inhaltsebene des Kommunikationsflusses arbeitet, ist bis jetzt noch nicht entwickelt worden. Solch ein Modul wird wahrscheinlich gebaut werden unter Verwendung des Kommunikationsprotokolls Health Level Seven (HL7) (Gesundheit Ebene Sieben).
Entwicklungswerkzeuge
Um den Entwicklungsprozess zu automatisieren und zu beschleunigen, sind mehrere Entwicklungswerkzeuge entwickelt worden. Eines (BX) wurde gekauft. Ihre Anwendung in dem Entwicklungsprozess ist in 16 gezeigt.
Builder Xcessory (Baustein Xcessory)
Der Builder Xcessory oder BX ist ein Entwurfswerkzeug einer grafischen Benutzeroberfläche von ICS. Mit BX kann der Programmierer ein Fenster „malen". Der Programmierer beginnt damit, dass er das Rechteck des Fensters auf der obersten Ebene zeichnet. Alle verfügbaren Widgets oder Anzeigeelemente können aus einer Palette gewählt und innerhalb des Fensters hineingestellt werden. Die Beziehungen zwischen den Anzeigeelementen (z. B. die Ausrichtung, die Größe, Gestalt, ...) können hier auch festgesetzt werden. Nach Spezifizierung des visuellen Aspektes des Fensters kann BX die Funktion für die Erstellung dieses Fensters in der Programmiersprache C generieren.
Der Anwendungsprogrammierer ändert diese Funktion der Erstellung nicht. Sie ist mit einem Prolog Prädikat so verbunden, dass sie von den Systemanwendungen aufgerufen werden kann.
FormBuilder
FormBuilder wurde entwickelt, um die Erzeugung von Datenbankobjekten, die mit elektronischen Formblättern verbunden sind, zu automatisieren. Nach dem Malen der Form unter Verwendung von BX und nach dem Erzeugen der Erstellungsfunktion verwendet der Programmierer formBuilder, um SQL zu erzeugen. FormBuilder erstellt das Formblatt unter Verwendung der Erstellungsfunktion. Der Benutzer kann dann spezifizieren, welche Felder in der Datenbank gespeichert werden sollen, indem er auf diese Felder klickt. Dann können die Typen (integer, character, real, ...) spezifiziert werden. Eventuell werden erzeugt die SQL, um die Tabelle zu erstellen, die Tabellenansicht und die generischen Teile der Trigger, um die Integrität der physikalischen Ebene des Datenmodells zu unterstützen. FormBuilder erzeugt den SQL Code und stellt ihn in SQL Fenstern des dbDashboard (dbinstrumententafel) dar, wo der Programmierer die anwendungsspezifischen Teile hinzufügen kann. FormBuilder ist ein System, das auf einem Regelwerk basiert und das Regeln für jeden der SQL Teile hat, die erzeugt werden sollen.
DBDASHBOARD
Weil nur der Standardteil von SQL erzeugt werden kann und weil gespeicherte Prozeduren und Trigger gewartet werden müssen, wurde ein Werkzeug entwickelt, das die Erstellung und das Editieren von Datenbankobjekten erleichtert und das in die Systemumgebung integriert ist. DbDashboard stellt ein Fenster zur Verfügung, aus dem SQL direkt an die Datenbank gesandt werden kann. Optionen, um Zeit und Eingabe/Ausgabe-Statistiken zu erzeugen und um den Optimierer den Abfrageplan ausdrucken zu lassen, können von diesem Fenster aus gesetzt werden. DbDashboard stellt (unter anderem) Menüoptionen zur Verfügung, um Tabellen, Ansichten und Prozeduren zu erstellen und aufrechtzuerhalten, Kommentare zu ihnen hinzuzufügen. Es erzeugt SQL Code, um Freigaben festzusetzen und es kann verwendet werden, um Unterschiede zwischen Datenbanken zu prüfen (z. B. Test- und Produktionsdatenbanken können verglichen werden).
DbDashboard steht nur Entwicklern zur Verfügung. Es ist beabsichtigt, Werkzeuge hinzuzufügen, um Tabellen, Ansichten und Prozeduren aus der Test- in die Produktionsdatenbank hinüberzuziehen.
MAURICE
Es ist ein Prüfprogramm entwickelt worden, Maurice genannt, um Teile des Prozesses des Aufsuchens und Korrigierens von Programmfehlern (Debugging Prozess) zu automatisieren. Es ist ein Prolog Programm, das ein anderes Prolog Programm lesen kann und versuchen kann, Programmfehler (bzw. bugs) aufzuspüren. Es besteht aus drei Teilen: die Interferenzmaschine, die Standard Maurice Regeln und die spezifischen Maurice Regeln. Die Interferenzmaschine liest den Code und wendet die Standard Maurice Regeln auf ihn an. Standard Maurice Regeln können spezifischen Maurice Regeln aufrufen.
Standard Maurice Regeln prüfen nach verdächtigem Code. Z. B. das Eintippen von Fehlern bei Variablennamen ist eine gängige Fehlerursache. Maurice prüft nach Variablen, die nur einmal in einem Prädikat erscheinen und listet sie auf. Gewöhnlich wird eine Variable mehr als einmal in einem Prädikat erscheinen: das erste Mal, um sie augenblicklich zu initialisieren (ihr einen Wert geben) und dann weiter, um irgendetwas mit diesem Wert zu tun. Eine Variable, die nur „dasitzt", ist verdächtig und sie wird aufgelistet, z. B. wenn Maurice berichtet, dass es zwei „einsame Variablen" gefunden hat, genannt _myVariable und _myVarable, dann wird der Programmierer sofort wissen, dass er einen Eingabefehler begangen hat. Programmcode, der ein Prädikat aufruft, das nicht existiert, ist auch verdächtig: wahrscheinlich ist es ein (Eingabe-)Fehler, da es keinen Sinn macht zu versuchen, etwas zu verwenden, was nicht existiert.
Maurice loggt sich als ein Benutzer in die Datenbank ein. Wenn er merkt, dass ein Programm versuchen will, ein Objekt der Datenbank zu verwenden (meistens eine Prozedur), wird er prüfen, ob diese Prozedur in der Datenbank existiert. Für jedes der Systemmodule des Generators existiert ein entsprechendes Maurice Regelwerk, um den korrekten Umgang mit der Schnittstelle des Programmierers zu prüfen, die von demselben definiert ist. Z. B. wenn das Programm versucht, den Wert des Feldes A auf das Formblatt B zu setzen, dann wird Maurice prüfen, ob die Formdefinition für Form B vorhanden ist und ob sie eine Felddefinition für Feld A enthält.
Werkzeuge
Die folgenden Module sind Sätze von Werkzeugen, die in ihrer Art sehr allgemein sind. Sie wurden entwickelt, um in mehreren Systemanwendungen eingesetzt zu werden.
S9SERVICES
Dieses Modul wurde entwickelt, um medizinische Bausteine zu halten, die in den meisten Anwendungen benötigt werden, die aber nicht allgemein genug sind, um in dem Generator implementiert zu werden. Beispiele für solche Bausteine sind: Werkzeuge, um Patienteninformation innerhalb einer Anwendung zu speichern, GraphMaker (d. h. ein Werkzeug, um einen Graph von Optionen zu erstellen und durchzublättern), explizite Zugangskontrollprüfungen, SmartAsk (Funktionen, um automatisch und intelligent Fenster zu erzeugen, um Daten von dem Benutzer anzufordern), ....
TEXTHILFE (TEXT ASSISTANCE)
Viele Handlungen in dem Krankenhaus enden damit, dass ein Arzt einen Bericht an einen anderen Arzt schreibt. Einige davon können standardisiert werden. Diese Berichte können erzeugt werden, indem die Kliniker gebeten werden, die relevanten Parameter zu spezifizieren, und dann den Text zu generieren, der auf dem Wert dieser Parameter basiert. Dies hat zwei Vorteile: da man den Computer nach den Parametern hat fragen lassen, werden die Berichte mehr standardisiert und keine Parameter können vergessen werden (es gibt keinen Unterschied zwischen Papierberichten oder mit dem Computer strukturierten Berichten). Der zweite Vorteil besteht darin, dass es viel weniger Zeit in Anspruch nimmt, solch einen Bericht zu erzeugen.
Um die Programmierung von Text erzeugenden Prozeduren zu erleichtern, ist eine spezifische Sprache entwickelt worden. Die Sprache sieht mehr nach einer gewöhnlichen Programmiersprache aus und verfügt über eine Syntax, die völlig verschieden von Prolog ist. Diese Text erzeugenden Programme wurden in Prolog Datenstrukturen kompiliert. Text assistance stellt einen Interpreter zur Verfügung, der, ausgehend von einem gegebenen Satz von Parametern, ihrer Werte und einem kompilierten Text Assistance Programms, einen Bericht erzeugt.
UZ PrologTools (UZ PrologWerkzeuge)
UZPrologTools ist ein Modul, das entwickelt wurde, um auf der niedrigsten Ebene zu funktionieren (d. h. es nutzt nicht irgendein anderes Modul), aber es selbst wird benutzt von fast jedem Modul in dem System. Es enthält einen Satz von kleinen, aber handlichen Prädikaten, um das Programmieren zu erleichtern. Z. B. einen Satz von Prädikaten, um Datensätze einer festen Länge zu lesen und zu schreiben, ein Debugging Werkzeug (Fehlersuche und -korrektur), Listenbearbeitungsprädikate, ....
Verbindung zwischen dem Mainframe (Großrechner) und der Systemumgebung
Eine schnelle bidirektionale Verbindung ist notwendig zwischen dem Mainframe und der Systemumgebung.
VERBINDUNG ZWISCHEN DEM MAINFRAME UND DER SYSTEMDATENBANK
Um Daten in die Sybase Datenbank einzufügen und aus dieser Datenbank anzufordern, wurde die Wahl für eine Schnittstelle getroffen, die es einem (COBOL) Programm erlauben würde, eine willkürlich in Sybase gespeicherte Prozedur auszuführen. Das COBOL Programm, das mit dem Sybase Server kommunizieren möchte, setzt zuerst eine LU 6.2 Verbindung mit einer intermediären UNIX Maschine fest. LU 6.2 ist ein Standard für eine Peer-to-Peer Programmkommunikation. Dies ist eine direkte Kommunikation zwischen zwei Programmen, die auf (möglicherweise verschiedenen) Computer laufen. Sie sendet eine Datenzeichenkette (String) über diese Verbindung zu einem Transferprogramm auf der intermediären Maschine. Das Transferprogramm ist mit einer Sybase Client Software ausgerüstet. Es sendet die Zeichenkette zu dem Sybase Server, der sie ausführt. Wenn die Datenzeichenkette eine Abfrage ist, dann sucht das Transferprogramm die Ergebnisse und überträgt diese zurück an das anfordernde Programm auf dem Mainframe.
LUTools
LUTools erlaubt es, eine LU 6.2 Verbindung von innerhalb der Systemanwendung mit dem Mainframe festzusetzen. LUTools stellt eine Prolog Schnittstelle einer hohen Ebene oben auf den LU 6.2 Bibliotheken zur Verfügung, geliefert von dem Computerhersteller. Mit LUTools kann eine beliebige CICS 18 Transaktion ausgeführt werden. Die Transaktion kann Daten an das Prolog Programm zurückgeben. Es wird verwendet, mit dem System des Mainframes zu kommunizieren, um z. B. Labortestergebnisse wiederzufinden oder um Daten in das Abrechnungssystem einzufügen.
Auftragseinträge in das System: der Service Manager
Der Service Manager verwendet ein generisches Rahmengerüst, um Dienste zu bewerkstelligen. Er definiert die generische Speicherstruktur der Dienste, die Operationen, die an den Diensten getan werden können (Anfrage, Durchführung, Annullieren und Schließen) und das Rahmengerüst für die Benutzerschnittstelle. Das Rahmengerüst wird von Benutzern definierte Regeln vollendet, die es erlauben, die spezifischen Teile zu definieren. Es wird jetzt ein Überblick über das Rahmengerüst des Service Managers gegeben.
SPEICHERSTRUKTUR FÜR DIENSTE
Problem
Die Daten für solche Dienste sind strukturiert, aber da es so viele verschiedene Handlungen gibt, die angefragt werden können, ist die Anzahl von Strukturen, die notwendig sind, sie zu implementieren, gewaltig. Aus diesem Grund ist es nicht machbar, jeden Strukturtyp in einer getrennten Datei oder Datenbanktabelle zu speichern. Die meisten dieser Tabellen oder Dateien würden klein sein und die Reintegration der Daten auf dem Bildschirm aus all diesen Objekten, um eine globale Übersicht eines Patienten zu geben, ist zu ineffizient, um eine annehmbare Antwortzeit zu erzielen.
Die Lösung könnte darin bestehen, entweder die Struktur auf irgendeinen größten Nenner zu beschränken oder eine sehr allgemeine Struktur zu erstellen, die die spezifischen Strukturen subsumiert. Die zweite Option wurde gewählt. Um dies zu tun, mussten einige Beschränkungen bei der Verwendung von relationellen Datenbanken gelöst werden. Eine relationelle Datenbank ist sehr strikt in den Speicherstrukturen, die sie erlaubt: die einzige erlaubte Struktur ist die Tabelle. Die Kolonnen der Tabelle sind in Zahl und Typ festgelegt und müssen vordefiniert werden. Eine Änderung der Struktur einer Tabelle bedeutet gewöhnlich, die Programme zu stoppen, die sie benutzen, die Tabellendefinition zu ändern, Programme zu installieren, die an die neue Struktur angepasst sind, und sie von neuem zu starten. Dies ist sehr mühselig und kann nicht jedes Mal gemacht werden, wenn eine neue Handlung definiert werden soll.
Lösung: eine generalisierte Tabellenstruktur in spezifische logische Terme übersetzen
Um die Handlungen zu speichern werden generalisierte Tabellen verwendet. Diese Tabellen können die Speicherung von irgendeinem Dienst unterbringen. Es gibt vier grundlegende Tabellen, die der Service Manager anwendet: Anfrage, Durchführung, Annullieren, und Schließen. Ein Dienst kann direkt durchgeführt werden, ohne dass er angefordert wird oder er kann angefordert und dann durchgeführt oder annulliert werden (beides schließt die Anforderung). Einige Anfragen sind kontinuierliche Anfragen, dies sind Anfragen, die selbst dann offen bleiben, wenn der Dienst durchgeführt wird (z. B. für Anfragen, die mehrere Male durchgeführt werden müssen). Kontinuierliche Anfragen müssen explizit geschlossen werden. (Zur Vereinfachung werden nur die Anfrage- und Durchführungstabellen verwendet, um die zugrunde liegenden Prinzipien des Service Managers zu diskutieren).
Dienste werden in Typen gruppiert. Ein Diensttyp sammelt alle Dienste, die logisch zusammen gehören. Z. B. gibt es einen getrennten Dienstestyp für das System der Radiologieanfrage/-durchführung und einen anderen für allgemeine medizinische Aktivitäten. Für jeden dieser Typen existiert ein getrennter Satz von diesen vier grundlegenden Tabellen.
Die Tabellen des Service Managers bestehen aus drei Teilen: der Standardteil, der feste und der variable Teil. Der Standardteil definiert die Kolonnen, die die gleichen für alle Diensttypen sind, aber er unterscheidet zwischen Anfrage und Durchführung. Der feste Teil definiert die Kolonnen, die für einen bestimmten Typ von Diensten fest sind. Der variable Teil ist der, wo die Flexibilität des Service Managers liegt. Der variable Teil besteht aus einem Satz von Kolonnen verschiedener Datentypen und verschiedener Längen. Die Kolonnen, die eine ganzzahlige Zahl aufnehmen können, bezeichnet man als int1, int2, ...; die Kolonnen, die verwendet werden können, um einen Bitwert zu speichern, nennt man bit1, bit2, ... usw.
Während die Kolonnen der Standardteile und der festen Teile eine Interpretation für alle Zeilen in der Tabelle haben, verfügen die Kolonnen der variablen Teile über eine Interpretation, die abhängt von dem Dienst, der in der Zeile gespeichert ist. Jeder Dienst kann einige Attribute aufweisen, die gespeichert werden müssen (z. B. eine Zahl, der Name einer medizinischen Behandlung, Typ und Zahl der verwendeten Materialien, ...). Diese Parameter werden auf die physikalischen Kolonnen des variablen Teils abgebildet.
So kann die Kolonne, die int1 heißt, die Zahl der Schnitte aufnehmen, die für einen bestimmten Typ der Chirurgie eingesetzt wurden, aber in einem anderen Dienst kann sie die Zahl der verwendeten Katheter aufnehmen. Die logische Struktur eines Dienstes wird so auf die generische Tabellenstruktur abgebildet.
Der Service Manager arbeitet auf der generischen Ebene der vier grundlegenden Tabellen. Er verwendet vom Benutzer definierte Regeln, um auf die spezifischen Tabellen zuzugreifen, die verwendet werden, um die Anfragen und Durchführungen des Dienstes eines bestimmten Typs zu speichern. Mehrere Typen können den gleichen Satz von Tabellen verwenden, aber ein Typ muss in einem Satz von Tabellen gespeichert werden. Die Übersetzung zwischen der Speicherstruktur und der logischen Struktur des Dienstes wird auch von Regeln bewerkstelligt. Sobald ein Dienst aus der Datenbank gefunden worden ist, wird er in seine logische Struktur übersetzt. Bevor eine Anfrage oder Durchführung eines Dienstes in der Datenbank gespeichert wird, wird die logische Struktur wieder übersetzt in die Struktur der Tabelle. Übersetzungsregeln können für einen gesamten Typ oder für einen spezifischen Dienst definiert werden.
Hilfswerkzeug: Service Typ Macher (service type maker)
Die Strukturen, die benötigt werden, um die Abbildung zwischen den logischen und den physikalischen Darstellungen zu definieren, sind sehr groß und daher fehleranfällig. Um bei dem Aufbau dieser Strukturen zu helfen, wurde ein Programm geschrieben, dass es erlaubt, Parameter für einen Dienst zu definieren und den physikalischen Speichertyp zu spezifizieren. Der Service Typ Macher leitet dann die optimale Abbildungsstruktur für diesen Dienst ab und erzeugt den Prolog Code dafür.
BENUTZERSCHNITTSTELLE
Eine generische Benutzerschnittstelle wurde auch gebaut. Die Basisstruktur der Schnittstelle besteht aus einem Selektor (Auswähler), aus einem Editor und aus einem Kollektor (Sammler). Es sei die Anforderung eines Dienstes betrachtet (die Durchführung von Diensten ist sehr ähnlich). Der Selektor wird verwendet, um eine Dienstanfrage auszuwählen. Wenn eine Dienstanfrage ausgewählt wird, können ihre Parameter in dem Editor editiert werden. Ein voreingestellter Editor wird bereitgestellt, aber für solche Dienste, die extra Parameter aufweisen, wird er Service Manager entweder ein Fenster bauen, um nach Werten für diese Parameter anzufragen, oder die Anwendung kann einen speziellen Editor definieren, der von dem Service Manager verwendet werden wird. Nach der Editierung kann die Serviceanfrage an die Datenbank geschickt werden. Der Kollektor zeigt dann alle Dienste, die für einen Patienten angefordert worden sind. Da es viele verschiedene Typen von Diensten gibt (jeder mit seinem eigenen Satz von Parametern), die alle in einem Kollektor gezeigt werden müssen, kann nur eine Textdarstellung der Dienste angezeigt werden. Ein Regelwerk wird verwendet, um die logische Begriffsdarstellung des Dienstes in eine Textdarstellung zu übertragen, die in dem Kollektor gezeigt wird.
Der Service Manager verknüpft die Funktionalität von vielen anderen Modulen, die schon früher diskutiert worden sind:

• Dienstanfragen und -durchführungen können gesandt, korrigiert oder weggelassen werden. Sie werden als Nachrichten des Systems implementiert;
• der Service Manager ruft Äquivalente der Formprozeduren bevor und nach jeder Datenbankoperation auf. Unter Verwendung von Zugriffsprädikaten, die von dem Service Manager definiert worden sind, kann der Benutzer auf die logische Darstellung der Diensteobjekte zugreifen;
• der Selektor und Kollektor verwenden die logicBox. Der Selektor verwendet oft die logicBox, um durch einen Graphen zu navigieren (siehe 14).

Der Selektor interagiert mit dem Editor und mit dem Kollektor über das Standard Selektor Protokoll. Dies erlaubt es, spezifische Selektoren zu erstellen, wenn es notwendig sein sollte. Der Selektor ist Gegenstand von vielen ergonomischen Beschränkungen. Der ideale Kollektor ist einer, der den nächsten Dienst, der angefordert werden soll, errät. Um eine schnelle Auswahl der am meisten gebräuchlichen Dienste zu ermöglichen, werden spezifische Graphen für jede Abteilung oder Station erstellt. Z. B. startet der Graph der Radiologieanfrage mit den ersten 20 am meisten angeforderten radiologischen Untersuchungen für jede Abteilung.
Von dem Durchblättern der Graphik der Dienste abgesehen, kann der Benutzer auch einen Teil der Beschreibung des Dienstes eingeben und dann die Datenbank danach absuchen, ob damit übereinstimmende Dienste vorhanden sind. Wenn die Benutzer erst einmal mit der Arbeit mit der Tastatur vertraut geworden sind, ist dies häufig die schnellste Methode, eine Option aus einer sehr langen Liste wiederzufinden. Teich et al. gehen hierbei sogar noch einen Schritt weiter. Neben der Auswahl aus einer hierarchischen Liste von Optionen, implementierten sie eine Art von Schnittstelle einer Befehlsleiste, wo Teilbefehle eingegeben werden können. Beim Drücken der «enter»-Taste sucht das System nach Treffern und versucht, den (die) Befehl(e) zu erweitern. Dies erlaubt es nicht nur, in einem Bearbeitungsstapel (batch) mehrere Befehle einzugeben, sondern auch genauso gut, die Parameter direkt einzugeben.
Um die Auswahl der gebräuchlichsten Aktivitäten zu beschleunigen, wurde das Netz hinzugefügt. Das Netz ist eine rechtwinklige Matrix mit 54 Zellen, die Abkürzungen von den 54 gebräuchlichsten Diensten für eine besondere Krankenhausstation enthalten. Wenn das Fenster eines Service Managers geöffnet wird, versucht das System, den wahrscheinlichen Aufenthaltsort des Patienten zu erraten. Diese Stationsnummer wird verwendet, um die geeignete Regel zu linden, das Netz auszufüllen. Die Zellen in dem Netz wirken wie Schaltflächen (buttons): das Klicken einer Zelle bewegt den betreffenden Dienst zum Editor. Das Netz gibt einen zusätzlichen Ein-Maus-Klick-Zugang zu 56 Diensten. Weil das Netz fest an das Standard Selektor Protokoll gebunden ist, brauchten der Editor und der Kollektor nicht angepasst zu werden, als das Netz hinzugefügt wurde.
Eines der Hauptprobleme bei der Erstellung einer Benutzerschnittstelle ist der Unterschied zwischen den Erst- oder Gelegenheitsbenutzern und erfahrenen oder Dauerbenutzern. Die erste Kategorie erfordert eine wortreiche Schnittstelle und ein Navigieren durch einen Graphen oder durch einen hierarchischen Satz von Optionen, der es ihnen erlaubt, jeden Schritt zu überlegen. Der neue oder Gelegenheitsbenutzer ist verwirrt durch zu viele Kurztastaturen und kann sie sich nicht merken, da er das System nicht oft genug nutzt.
Der erfahrene Benutzer weiß genau, was er will und wo es sich in dem System befindet und er wird immer einen größeren Satz an kurztastaturen brauchen, der ihn mit so wenig Mausklicks wie möglich zu der Stelle bringt, wo er hin möchte. In dem Netz befinden sich alle Optionen an einer festen Stelle. Erfahrene Benutzer können eine Option motorisch auswählen, ohne die Inhalte der Zellen zu lesen.
Der klinische Arbeitsplatz
Einführung
Aktive Teilnahme der Kliniker an der Spezifikation:
Eine solide Ausschussgruppe
Die Systeme der Chirurgischen Pathologie und Radiologie wurden entwickelt, indem die Spezifikationen mit den klinischen Schlüsselbenutzern der Abteilungen diskutiert wurden. Nicht nur funktionale Spezifikationen wurden diskutiert, sondern auch das zugrunde liegende Datenmodell. Die Verwendung der die Nachricht modellierenden Konzepte erleichterten diesen Ansatz.
Das Krankenhausmanagement wählte vier klinische Spezialisten aus verschiedenen Disziplinen und eine Krankenschwester aus, um als eine solide Ausschussgruppe den Entwicklern zu dienen. Alle Mitglieder waren von älterem Rang und hatten ausgedehnte Erfahrung in einer klinischen Umgebung. Nach 9 Monaten schlossen sich der Leiter der Verwaltungsabteilung und der Leiter der Pharmazie der Gruppe an.
Die Gruppe traf sich mit dem Entwicklungsteam für fast ein Jahr lang jede Woche während eines zweistündigen Treffens. Alle Entwurfsentscheidungen wurden dieser Gruppe vorgestellt. Später in der Entwicklung wurden Prototypen verwendet, um die Diskussion voranzubringen.
Eine medizinische Datei, ein Satz von Prozeduren
Zentral bei dem Entwurf eines klinischen Arbeitsplatzes ist die Idee einer integrierten medizinischen Datei. Die Daten würden nicht nur in einer Datenbank enthalten sein, die Funktionalität würde auf allen Stationen identisch sein. Da es sich um ein Lehrkrankenhaus handelt, müssen die Ärzte ihre Abteilungen oft wechseln. Wenn sich die Funktionalität zu stark unterscheiden würde, würde dies ein Trainingsproblem darstellen.
Eine der Hauptaufgaben der soliden Ausschussgruppe bestand darin zu garantieren, dass die Funktionalität ausreichend allgemein gehalten wurde, um sie auf allen Stationen zu implementieren. Sie erkannten, wo eine kundenspezifischere Anpassung erforderlich sein würde. Die Automatisierung einer Organisation ändert den Arbeitsfluss und daher müssen die Prozeduren angepasst werden. Die solide Ausschussgruppe definierte auch die Prozeduren, die alle Abteilungen einsetzen müssen, wenn sie mit dem klinischen Arbeitsplatz arbeiten.
Softwaremodule des klinischen Arbeitsplatzes
Der klinische Arbeitsplatz besteht gegenwärtig aus 8 Modulen. Alle außer zwei (Registrierung der vitalen und physischen Parameter und medizinische Verschreibung) sind in der Produktion.
Für den Benutzer sind alle diese Module über das Dashboard (die Instrumententafel) integriert.
Das Dashboard in dem klinischen Arbeitsplatz besteht aus zwei Teilen: ein mit dem Patienten verbundener Teil und ein mit dem Kontakt verbundener Teil. Figur --zeigt das Dashboard und erklärt die Funktionen der Schaltflächen. Das Dashboard ist ein Navigationsinstrument: die Buttons aktivieren ein Modul des klinischen Arbeitsplatzes. Auf den meisten Formen befindet ein Dashboard Schaltsymbol. Ein Klick auf dieses Schaltsymbol findet das relevante Dashboard. Das Dashboard bringt den Benutzer zu den Formen und umgekehrt.
Das Kontaktmodul
Das Kontaktmodul ist das Hauptmodul des klinischen Arbeitsplatzes. Ein Kontakt kann sein ein Ambulanzbesuch, ein Krankenhausaufenthalt, eine Gastroskopie, eine Operation, ein Aufenthalt auf der Intensivstation, eine Behandlung mit Chemotherapie, .... Alle Patientenkontakte werden überwacht und erfasst unter Verwendung dieses Moduls. Ein Kontakt unterscheidet sich von Patientenaufnahmen (oder Übertragungen) in dem Sinne, dass ein Kontakt viele Aufnahmen haben kann (z. B. eine Behandlung einer Nierendialyse wird eine Aufnahme jedes Mal sein, wenn der Patient zur Dialyse kommt). Auf der anderen Seite kann eine Aufnahme mehrere (gleichzeitige) Kontakte aufweisen. Z. B. wird ein Patient der Chirurgie einen offenen Kontakt zu der Chirurgieabteilung haben und kann einen getrennten Kontakt für die Behandlung selbst haben. Ein Aufenthalt in der ICU könnte auch dazu veranlassen, dass ein anderer Kontakt eröffnet wird von den Ärzten der ICU. Ein Kontakt ist eine medizinische, logische Einheit im Gegensatz zu einer Patientenbewegung (Aufnahme, Entlassung oder Transfer), die eine Bewegung in Zeit und Raum ist. Wenn der Patient entlassen ist, wird der Kontakt gewöhnlich nicht beendet sein. Der Kontakt wird beendet, wenn die Arbeitseinheit abgeschlossen ist.
Ein Kontakt hat mehrere Phasen, einige von ihnen sind optional. Die Phasen des Kontaktes machen eine Arbeitseinheit aus. Jede der Phasen wird durch eine elektronische Form dargestellt (als Beispiel die Zuweisungsform). Der Kontakt beginnt mit der Aufnahmeform. Dies verbindet den Kontakt mit dem Patienten und mit der Abteilung (z. B. Pädiatrie, Nephrologie). Der Typ (stationärer Patient im Krankenhaus, ambulanter Patient außerhalb des Krankenhauses, ...) wird hier auch bestimmt. Die zweite Phase, Zuweisung, weist den Kontakt einem Arzt und einem überwachenden Arzt oder einem Überwacher zu. Die Arbeitseinheit muss abgeschlossen werden entweder durch die Validierung des medizinischen Berichtes oder durch eine explizite Feststellung, das kein Bericht für diesen Kontakt notwendig ist.
Die von dem Kontaktmodul erfassten Daten bestimmen den größten Teil des Arbeitsflusses der Ärzte. Insbesondere die ersten beiden Phasen erfassen die Information, die notwendig ist, um den Arbeitsfluss zu steuern. Die Aufnahmeform gibt die Daten, um die Arbeit unter den Ärzten einer (Unter-)Abteilung aufzuteilen, wobei die Zuweisungsform verwendet wird. Diese Daten werden dann verwendet, um Arbeitslisten für die einzelnen Ärzte zu erstellen (wie eine Liste der Berichte, die geschrieben werden müssen, oder, für den Überwacher, die Liste der Berichte, die fertig sind, um validiert zu werden).
Der bedeutendste Teil der Daten, die in dem Kontaktmodul erfasst werden, ist der medizinische Bericht. Eines der Hauptprodukte des Krankenhauses ist Information (für den Patienten, für den behandelnden Arzt, ...) und der größte Teil dieser Information liegt in der Form eines medizinischen Berichtes von einem Arzt and einen anderen vor. In einem Lehrkrankenhaus werden viele Berichte von Ärzten in der Ausbildung geschrieben oder diktiert. Diese Berichte müssen von einem Überwacher validiert werden. Ein nicht validierter Bericht kann ausgedruckt werden, aber „unvalidated" bzw. „nicht validiert" wird schräg über dem Bericht aufgedruckt sein, so dass es leicht erkennbar ist. Nach der Validierung können die Berichte gedruckt werden. Danach werden sie unterschrieben und an den (externen) Arzt geschickt, der den Patienten betreut.
Optionale Phasen oder Formen
Mehrere andere Formen (bzw. Formblätter) sind mit einem Kontakt verbunden, aber sie sind optional. Die Bemerkung erlaubt es, eine kleine Bemerkung an den Kontakt anzuhängen (sehr ähnlich zu Post-it Noten). Zwischenberichte erlauben es, den Fortschritt im Bericht zu erfassen, ohne den Kontakt zu schließen. Dies wird für langfristige Kontakte verwendet: eine Nierendialyse oder eine zwischenzeitliche Behandlung mit einer Chemotherapie wird gewöhnlich als ein Kontakt dargestellt. Die VINO (Verpleegkundige Informatie Nota bij Ontslag – Informationsnotiz der Krankenpflege bei der Entlassung) wird verwendet, um dem Patienten Information zu geben bezüglich der medikamentösen Behandlung, des Betreuungspersonals, ....
Von der Automatisierung verursachtes Organisationsproblem
Vor der Automatisierung wurden Berichte zentral erstellt von Schreibkräften oder von den Sekretariaten der Abteilung. Der zu unterschreibende Brief verblieb zusammen mit der Papierdatei, wurde unterzeichnet und wurde zusammen mit der Papierdatei für den weiteren Umgang in der Bearbeitung zurückgeschickt. Der Bericht und die Papierdatei wanderten gewöhnlich zusammen.
Mit dem klinischen Arbeitsplatz wird die Validierung auf dem Bildschirm ausgeführt und kann auf irgendeinem Terminal in dem Krankenhaus getan werden. Dies veranlasst die Verschiebung von Arbeit von den Sekretariaten auf die Überwacher. Ein Überwacher kann einen Bericht ohne die Papierdatei validieren, da die meisten Daten online verfügbar sind; er braucht nicht auf die Papierkopie zu warten. Sobald ein Bericht geschrieben ist, erscheint er auf der Validationsliste des Überwachers. Wenn der Bericht validiert ist, wird er automatisch in mehreren Kopien gedruckt (eine für den betreuenden Bezugsarzt, eine für die medizinische Datei, eine persönliche Kopie, ...). Das Problem besteht darin, dass der Überwacher den Umgang mit den physischen Kopien des Berichtes beendet und dafür verantwortlich ist, dass diese ihr Bestimmungsziel erreichen.
Dies wurde durch die Verwendung der „elektronischen Unterschrift" gelöst. Die Probleme treten da auf, wo der Fluss des Berichtes von der elektronischen Form auf das Papier wechselt. Dies muss bei der Validationsphase sein, wenn eine geschriebene Signatur notwendig ist. Eine Zugabe zu dem Kontaktmodul wurde erstellt, um die Validation von dem Ausdruck und von der Unterschrift zu trennen. Wenn der Bericht validiert ist, bewegt er sich zu einer Druckliste. Die Sekretariate sind verantwortlich für den Umgang mit der Druckliste. Entweder werden die Berichte unterschrieben in dem Arbeitsstapel in dem Büro des Sekretariats oder, noch besser, die physische Unterschrift wird ersetzt durch eine Notiz am Ende des Berichtes, die besagt „dieser Bericht wurde elektronisch unterzeichnet von Dr. xyz an dem Datum TT.MM.JJ".
Wanderproblem: historische Daten
Ein anderes Problem, dem man begegnete, war eines der Wanderung. Die meisten Abteilungen nutzten schon Computer, um medizinische Berichte zu schreiben. Verschiedene Abteilungen hatten verschiedene Systeme. Eine Möglichkeit, um dieses größere Problem zu überwinden, könnte die Erstellung einer historischen Datenbank sein, alle Daten zu laden und die historische Datenbank mit dem klinischen Arbeitsplatz zu verbinden. Verschiedene Quellensysteme würden zu verschiedenen historischen Datenbanken führen und der Benutzer würde einen Unterschied sehen zwischen den Daten aus dem historischen System und Daten aus dem neuen System.
Stattdessen wurde ein Ladeprogramm entwickelt, um die historischen Daten einzulesen und um die historischen Daten in das Datenmodell zu übersetzen, das in der betreffenden Anwendung verwendet wird. Das Ladeprogramm verwendet ein Regelwerk, um einen auf Training beruhenden Rat für die fehlenden Daten abzugeben. Wenn Information überhaupt nicht abgeleitet oder geraten werden kann, werden vernünftige, aber erkennbare voreingestellte Werte eingegeben. Diese Technik wurde das erste Mal in der Radiologie angewandt. 244.451 radiologische Berichte konnten auf diesem Wege wiedergefunden werden. Es wurde für die Pädiatrie wiederholt (94.866 Berichte), Onkologie (26.727 Berichte), Gynäkologie/Geburtshilfe (96.518 Berichte) und Hämatologie (45.266 Berichte).
Der Hauptvorteil besteht darin, dass es das System mit Daten bevölkert, als ob die Abteilung mit diesen schon die ganze Zeit gearbeitet hat. Es gibt keinen Unterschied in der Struktur zwischen den historischen Daten und den neuen Daten, aber gewisse Datenelemente könnten fehlen oder auf voreingestellte Werte gesetzt sein. Keine extra Software braucht geschrieben zu werden, um die historische Datenbank zu erstellen und mit den Anwendungen des Systems zu integrieren.
Der Nachteil besteht darin, dass Plattenspeicherplatz vergeudet wird durch die Speicherung von Millionen voreingestellter Werte, die von einem Computer erzeugt worden sind und die daher keinen Informationswert tragen. Bei gegenwärtigen Plattenpreisen werden diese Kosten leicht ausgeglichen durch die Kosten für die Entwicklung einer speziellen Software für eine historische Datenbank. Der andere Nachteil besteht darin, dass das Ladeprogramm komplexer ist, da es ein Datenmodell in ein anderes übersetzen muss und Daten generieren oder ableiten muss, wo es nötig ist. Dies muss für jeden Ladetyp wiederholt werden, aber dies ist eine einmalige Anstrengung und einiges der Software kann wiederverwendet werden, indem die Technik der Interferenzmaschine und des Regelwerkes wieder verwendet wird.
Terminsystem: Slot Manager
Das Terminsystem wird als „slot manager" bezeichnet. Die Terminbücher für den Plan der Ambulanzbesuche besteht aus vielen leeren Slots. Die Anzahl der Slots pro Ressource und pro Tag ist begrenzt und vorbestimmt. Der Slot Manager verwaltet die äquivalente elektronische Form von diesen Büchern in Papierform. Er verwendet ein gigantisches Netz von Slots: die X-Achse ist die (Start) Zeit und die Y-Achse die Ressource (ein Arzt, aber es kann auch ein Operationsraum sein, ein Verfahren, ...). Jeder Slot hat auch eine mit ihm verbundene Dauer. Wenn eine Patientennummer an der Schnittstelle von Zeit T und Ressource A gespeichert wird, bedeutet dies, dass Ressource diesem Patienten zugeordnet wird für die Dauer, die mit diesem Slot verbunden ist.
Die Vorteile des Slotkonzeptes bestehen darin, dass wenig Kontrollprüfungen bzw. Checks zum Zeitpunkt der Buchung durchgeführt werden müssen: wenn der Slot existiert und wenn er leer ist, dann kann er gebucht werden. Es ist nicht notwendig, Doppelbuchungen zu prüfen oder ob die Ressource überhaupt verfügbar sein wird. All dies wird einmal verifiziert, wenn die elektronischen Terminbücher erstellt werden. Die Suche nach den freien Slots für eine Ressource (z. B. wenn ein Patient einen besonderen Art wünscht) wird bewerkstelligt durch den Zugriff auf die Matrix der Slots über die Y-Achse. Der Nachteil dieses Ansatzes besteht darin, dass alle Slots lange vorher vordefiniert werden müssen (mindestens ein Jahr; für die Onkologie zwei Jahre), und dies nimmt Platz in Anspruch. Es erfordert von den Ärzten auch, lange vorher zu entscheiden, warm und wie lange sie erlauben, dass Termine gebucht werden.
Ein alternativer Ansatz, ein Terminsystem zu bauen, ist es, über einen großen freien Raum an Zeit und Ressourcen zu verfügen und zu prüfen, zum Zeitpunkt der Buchung, ob die Ressource verfügbar ist. Anstatt explizit festzustellen, welche Slots verfügbar sind, gibt es Regeln, die definieren, was erlaubt ist und was nicht. Slots, die nicht gerade besetzt sind, nehmen keinen Raum in Anspruch, aber die Buchung verbraucht viel mehr Zeit, weil diese Regeln für jede Buchung geprüft werden müssen. Z. B. wenn ein Patient A wünscht, den Arzt B am Dienstag um 10:00 Uhr zu sehen, muss das System prüfen, ob B für Ambulanzpatienten zu diesem Zeitpunkt verfügbar ist und bis jetzt noch nicht für einen anderen Patienten in einem überlappenden Zeitrahmen gebucht ist. Das System muss auch prüfen, ob die maximale Anzahl von Patienten für diesen Tag für Dr. B noch nicht erreicht ist (um Überbuchung zu vermeiden). Die Suche nach einem Arzt aus der Pädiatrieabteilung, der für einen Ambulanzbesuch verfügbar ist, verbraucht viel mehr Zeit.
Weil der Buchungsprozess (Finden eines freien Slots und Zuordnung eines Patienten zu diesem Slot) schnell gehen muss (gewöhnlich wartet jemand auf eine Antwort), wurde der erste Entwurf verwendet. Freie Slots werden gesucht, indem ein Bildschirm für Abfragen verwendet wird, auf dem mehrere Suchkriterien eingegeben werden können (siehe 6–5). Die freien Slots, die die Suchkriterien qualifizieren, werden aufgelistet und die Auswahl eines von diesen ordnet den Patienten einem Slot zu. Das System unterscheidet zwischen Buchungseigentümern und anderen Benutzern. Normalerweise können Benutzer nur freie Slots sehen und niemals eine Liste von allen Patienten, die für einen bestimmten Tag oder Arzt gebucht sind, aus Gründen der Privatheit. Sie können auch nicht überbuchen. Ein Buchungseigentümer kann beides, sowohl überbuchen (d. h. doppelte Slots erzeugen) und die Liste von Patienten sehen, die in den elektronischen Büchern gebucht sind, die ihm gehören. Buchungseigentümer können Information an Slots binden (z. B. „keine neuen Patienten; nur für Nachuntersuchung"). Der Sucher des Slots kann dem Slot Information über den Patienten hinzufügen.
Die Vorteile von elektronischen Terminbüchern sind:

• Patienten werden immer korrekt und lesbar identifiziert;
• die Termindaten werden elektronisch in das medizinische Archiv übertragen, um die Papierdateien wiederzufinden. Sie werden auch in das Verwaltungssystem geladen, so dass, wenn der Patient zugelassen ist, die korrekten Daten voreingegeben werden können und der Zulassungsprozess beschleunigt wird;
• Terminbücher sind zugänglich von jedem Punkt in dem Krankenhaus anstelle eines Zugangs nur von dem Terminarbeitsplatz;
• es ist möglich, einen Überblick über alle Termine für einen Patienten zu geben.

Hilfswerkzeuge: Slot Maker (Slotersteller)
Weil Slots konstant hinzugefügt werden müssen, wurde ein Programm zur Sloterstellung geschrieben. Dieses Programm nimmt ein Muster von Slots für eine Buchung (z. B. jeden Montag, Freitag um 9:00 Uhr, 9:15, 9:30, 10:00, 10:30, ...) und erzeugt die Zeilen in der Tabelle, die die Slots darstellen. Dies ist wieder ein durch eine Regel angetriebenes Programm.
Konflikt mit der Löschungslosigkeit des Systemdatenmodells
Für den Slotmanager ist es notwendig, dass alle Slots fertiggestellt sind, bevor sie gebucht werden können. Die Benutzer aktualisieren sie. Dies ist kein additives Datenmodell und es als ein solches zu implementieren, würde sinnlos sein: der erste Sender von den Slots würde immer ein Programm sein (der slotmaker) und alle realen Operationen würden Korrekturen sein. Weil es nicht erwünscht ist, dass die Eintragung aller Operationen in den Terminbüchern (was ein impliziter Vorteil bei der Verwendung eines löschungslosen Datenmodells ist) verloren gehen, werden alle Änderungen in einer getrennten Tabelle eingetragen, wobei Sybase Trigger verwendet werden.
Service Manager (Dienstmanager)
Ein Großteil der Kommunikation in einem Krankenhaus zwischen den Betreuungsstellen besteht darin, irgendeine Art von Handlung, die an dem Patienten durchgeführt wird/werden soll, anzufordern und zu berichten. Ein Eintrag eines Terminauftrages für einen Radiologie- oder Labortest, Anforderung von Krankenpflege, Gastroskopie, EEG Anforderungen, ... sind alles Beispiele. Dies wird häufig als Handlungsmanagement bezeichnet und einige Projekte beabsichtigen, einen generischen Rahmen dafür zu definieren.
Ein Eintrag eines Terminauftrages ist ein Teil eines Handlungs- oder Dienstemanagements. Schon so früh wie 1970 trat Maurice Collen dafür ein, dass „Ärzte ihren medizinischen Terminauftrag direkt in den Computer eingeben sollten" aus Gründen der Genauigkeit und Vollständigkeit. Viele Eingabesysteme für Terminaufträge misslangen, aber Anfang der 90er Jahre gab es eine erneute Betonung des Eintrages eines Terminauftrages durch den Arzt wegen mehrerer bedeutender Faktoren:

• die Fortschritte in der Computertechnologie erlauben dadurch bessere Benutzerschnittstellen;
• ein Anstieg der Fähigkeit im Ungang mit dem Computer mit der Anzahl der Gesundheitsversorger auf allen Ebenen; und
• das Interesse, einen vollständigen computerbasierten Datensatz des Patienten zu entwickeln, um die Qualität der Pflege zu erhöhen.

Vorteile des Eintrages eines Terminauftrages durch den Arzt sind mannigfaltig:

• alle Terminaufträge sind lesbar und vollständig (die Software kann eine Anfrage blockieren, bis alle Pflichtfelder vollständig ausgefüllt sind, aber dies ist keine Garantie, dass die eingegebenen Daten Sinn machen);
• Terminaufträge erreichen die Dienstabteilung sofort;
• Terminaufträge können nicht verloren gehen und hängende Aufträge können überprüft werden.

Tabellen, die an dem Beispiel der Abfrage teilnehmen
Tabelle	Funktion
Patienten	Demographische Daten für alle bekannten Patienten
x#receptie	Ordnet eine Kontaktnummer zu jeder Arbeitseinheit und verbindet sie mit einem Patienten; alle nachfolgenden Phasen, die zu diesem Kontakt gehören, teilen gemeinsam dieselbe Nummer.
x#artsSup	Beziehung zwischen Kontaktnummer und ID des Assistenten und des Überwachers
x#verslag	Enthält alle Berichte. Ein Kontakt kann mehrere Zwischenberichte haben, aber nur einen Abschlussbericht (gekennzeichnet durch den Berichtstyp „eindverslag"). Jeder Bericht hat eine Berichtsnummer. Die Tabelle verbindet Berichtsnummern mit den Kontakten.
x#validate	Enthält die Berichtsnummer, die Kontaktnummer und die ID des Überwachers, der den Bericht validierte.
x#S9User	Enthält beschreibende Information (Name, Abteilung, Telefon, ...) von allen Benutzern des Systems.

x#verslag	Scannen der Tabelle (um eine Arbeitstabelle zu erstellen)
x#verslag	Scannen der Tabelle (gruppieren nach)
x#validatie	Index: verslagNr (um eine Arbeitstabelle zu erstellen)
Arbeitstabelle	Scannen der Tabelle
x#verslag	Index: verslagNr
x#artsSup	Verwendung eines Clusterindex
x#receptie	Verwendung eines Clusterindex
allePatienten	Verwendung eines Clusterindex
x#S9User	Verwendung eines Clusterindex

Tabelle 3
1 Abfrageplan für Abfrage 1

SCHRITT 1
Der Typ der Abfrage ist SELECT (in eine Arbeitstabelle).
GRUPPIEREN NACH
AUS TABELLE
x#verslag
geschachtelte Iteration
Scannen der Tabelle
ZUR TABELLE
Arbeitstabelle
SCHRITT 2
Der Typ der Abfrage ist SELECT (in eine Arbeitstabelle).
GRUPPIEREN NACH
Vektoraggregation
AUS TABELLE
x#verslag
geschachtelte Iteration
Scannen der Tabelle
AUS TABELLE
x#validatie
geschachtelte Iteration
Index: verslagNr
ZUR TABELLE
Arbeitstabelle
SCHRITT 3
Der Typ der Abfrage ist SELECT.
AUS TABELLE
Arbeitstabelle
geschachtelte Iteration
Scannen der Tabelle
AUS TABELLE
x#verslag
geschachtelte Iteration
Index: verslagNr
AUS TABELLE
x#artsSup
geschachtelte Iteration
Verwendung eines Clusterindex
AUS TABELLE
x#receptie
geschachtelte Iteration
Verwendung eines Clusterindex
AUS TABELLE
AllePatienten
geschachtelte Iteration
Verwendung eines Clusterindex
AUS TABELLE
x#S9User
geschachtelte Iteration
Verwendung eines Clusterindex

11.2 Abfrageplan für Abfrage 2

SCHRITT 1
Der Typ der Abfrage ist SELECT.
AUS TABELLE
Statuskontakt
geschachtelte Iteration
Index: usernameSup
AUS TABELLE
x#S9User
geschachtelte Iteration
Verwendung eines Clusterindex
AUS TABELLE
x#verslag
geschachtelte Iteration
Verwendung eines Clusterindex

11.3 Abfrageplan für Abfrage 3

SCHRITT 1
Der Typ der Abfrage ist TABCREATE.
SCHRITT 2
Der Typ der Abfrage ist INSERT.
Der Aktualisierungsmodus ist direkt.
Arbeitstabelle erstellt für SELECT INTO.
AUS TABELLE
x#artsSup
geschachtelte Iteration
Index: usernameSup
ZUR TABELLE
Arbeitstabelle
SCHRITT 1
Der Typ der Abfrage ist DELETE.
Der Aktualisierungsmodus ist zurückgestellt.
AUS TABELLE
#supervised
geschachtelte Iteration
Scannen der Tabelle
AUS TABELLE
x#verslag
geschachtelte Iteration
Verwendung eines Clusterindex
AUS TABELLE
x#validatie
geschachtelte Iteration
Index: verslagNr
ZUR TABELLE
#supervised
SCHRITT 1
Der Typ der Abfrage ist SELECT.
AUS TABELLE
#supervised
geschachtelte Iteration
Scannen der Tabelle
AUS TABELLE
x#S9User
geschachtelte Iteration
Verwendung eines Clusterindex
AUS TABELLE
x#verslag
geschachtelte Iteration
Verwendung eines Clusterindex
AUS TABELLE
x#receptie
geschachtelte Iteration
Verwendung eines Clusterindex
AUS TABELLE
AllePatienten
geschachtelte Iteration
Verwendung eines Clusterindex

Tabelle 4:
Ergebnisse der Leistung.

Für die drei Abfragen werden die Anzahl der Tabellenscans, die CPU Zeit und die verstrichene Zeit miteinander verglichen

Anzahl der Tabellenscans
	Größe (#Zeilen)	Abfrage 1	Abfrage 2	Abfrage 3
x#receptie	132.043	6		6
x#artsSup	132.374	454	6	1
x#verslag	158.371	456		2.248
x#validatie	114.391	114.040		1.053
x#S9User	1.789	6	6	600
allePatienten	1.055.629	6		6
statusContact	7.772		1
x#validated				2

Zeit
	Abfrage 1	Abfrage 2	Abfrage 3
Server CPU Zeit (msec)	129.000	< 100	1.700
Verstrichene Zeit (msec)	129.746	446	3.055
Verhältnis Verstrichene Zeit	291	1	7

Tabelle 5: Plattenbelastung der nicht-konzeptuellen Tabellen. Die totale Größe der nicht-konzeptuellen Tabellen und jeder Datenbank ist gezeigt. Die belastung der nicht-konzeptuellen Tabellen, ausgedrückt als Prozentsatz der totalen Datenbankgröße, nimmt mit der Zeit ab.

	Chirurgische Pathologie	Radiologie	Klinischer Arbeitsplatz
Monatliche Operationen (Aug. 95)	59	38	8
Nicht-konzeptuelle Tabellen (Mb)	1,2	4,49	15,08
Totale DB Größe (Mb)	1641	4121	844
Belastung (%)	0,07%	0,11%	1,79%

Tabelle 6: Zusammenfassung der Wirkung, wenn man nach oben skaliert: die Anzahl der Benutzer, die Größe der Anwendung oder den Umfang der Daten einer System 9 Anwendung auf der Darstellung eines Arbeitsplatzes, eines Anwendungsservers oder eines Datenbankservers.

Hardware ----------- Anwendung	Darstellung Arbeitsplatz	Anwendungsserver	Datenbankserver
Anzahl von B enutzern	Trivial: Einer pro Benutzer	N Benutzer pro Anwendungsserver, abhängig von der Verarbeitungsleistung und vom verfügbaren Speicher	Mehr Verarbeitungsleistung und mehr Speicher notwendig
Größe der Anwendung	Kein Einfluss	Anstieg des Umfanges des virtuellen Speichers pro Benutzer	Kein Einfluss
Umfang der Daten	Kein Einfluss	Kein Einfluss: nur Übergangsdaten werden hier gehalten	Mehr Plattenspeicher notwendig

Claims

Relationelle Datenbank, die auf einer Komputerumgebung kompiliert/gespeichert ist, für die Speicherung von Daten über Arbeitseinheiten, wobei die besagte relationelle Datenbank wenigstens einen ersten Satz mit Tabellen und einen zweiten Satz mit Tabellen enthält, wobei der besagte erste Satz mit Tabellen, erste Kolonnen und erste Tupeln enthält, die zu den besagten Arbeitseinheiten gehören, sowie einen ersten Datensatz, der die ersten Daten enthält, die in den besagten ersten Kolonnen und ersten Tupeln enthalten sind, und wobei der besagte zweite Satz mit Tabellen zweite Kolonnen und zweite Tupeln sowie einen zweiten Datensatz enthält, der aus zweiten Daten besteht, wobei alle Daten, die in den besagten zweiten Kolonnen und zweiten Tupeln enthalten sind, zweite Daten sind, wobei die besagten zweiten Daten eine redundante Darstellung von einem ausgewählten Teil der besagten ersten Daten sind, wobei jede Arbeitseinheit eine Einheit von Dienstleistungen enthält, die in einer bestimmten Reihenfolge ausgeführt werden, wobei die besagte Arbeitseinheit weiterhin einen Status besitzt, welcher aktiv oder abgeschlossen ist, wobei die besagten ersten Daten alle besagten Dienstleistungen von allen Arbeitseinheiten enthalten, die entweder einen aktiven oder einen abgeschlossenen Status besitzen, und wobei der ausgewählte Teil der besagten ersten Daten aus allen Arbeitseinheiten besteht, die eine Dienstleistung mit einem aktiven Status haben.
Relationelle Datenbank nach Anspruch 1, in der die zweiten Daten mit den ersten Daten identisch sind, wobei die ersten Daten in wenigstens einem ersten Tupel enthalten sind.
Relationelle Datenbank nach Anspruch 1, in der die zweiten Daten von den ersten Daten abgeleitet werden, dies durch eine Anpassung von einem Teil der ersten Daten, die in wenigstens einem ersten Tupel enthalten sind.
Relationelle Datenbank nach Anspruch 1, in der die zweiten Daten von den ersten Daten abgeleitet werden, dies durch eine Operation auf einem Teil der ersten Daten, die in wenigstens einem ersten Tupel enthalten sind.
Relationelle Datenbank nach einem der vorhergehenden Ansprüche, in der die besagten zweiten Daten eine Abfrage innerhalb der besagten ersten Daten unterstützen, wodurch die Leistung der besagten Abfrage innerhalb der besagten ersten Daten erhöht wird.
Relationelle Datenbank nach Anspruch 5, wobei Anwendungsprogramme, welche die Abfrage ausführen, auf der besagten Komputerumgebung kompiliert/gespeichert sind und wobei die besagte relationelle Datenbank für den Zugang durch die besagten Anwendungsprogramme angepasst ist.
Relationelle Datenbank nach Anspruch 6, die weiter Programme enthält, welche ausgeführt werden, während die Daten in einer Tabelle des besagten ersten Satzes mit Tabellen hinzugefügt werden, wobei die besagten Programme die besagten zweiten Daten des besagten zweiten Satzes mit Tabellen erstellen.
Relationelle Datenbank nach einem der vorhergehenden Ansprüche, in welcher der erste Satz mit Tabellen aus einer physikalischen Ebene, einer konzeptuellen Ebene und einer Anwendungsebene besteht.
Relationelle Datenbank nach Anspruch 8, in der alle unter den besagten ersten Daten elektronische Nachrichten sind, die möglicherweise den Inhalt von elektronischen Formen darstellen.
Relationelle Datenbank nach in Anspruch 9, in der die besagten Nachrichten Gesamtdaten darstellen, die aus der Gruppe von Vorgängen, Operationen, Dienstleistungen, Handlungen, Objekten und Personen innerhalb einer definierten Umgebung bestehen.
Relationelle Datenbank nach Anspruch 10, bei der die besagte definierte Umgebung ein Krankenhaus ist.
Relationelle Datenbank nach einem der vorhergehenden Ansprüche, in der ein Teil der Daten sich in einem Tupel befindet, wobei jede erste Data permanent in einem Tupel gespeichert ist, das zu einer Tabelle des besagten ersten Satzes mit Tabellen hinzugefügt wird, wobei der erste Satz mit Tabellen nicht gelöscht werden kann, sondern hinzugefügt werden kann.
Relationelle Datenbank nach Anspruch 12, in der die besagten Tupeln, welche die besagten ersten Daten enthalten, in Einklang mit der Operation gekennzeichnet sind, welche diese besagten ersten Daten erstellt, wobei diese besagten Operationen unter den nachfolgenden Möglichkeiten ausgewählt werden: Einfügung, Unterlassung oder Verbesserung von den besagten ersten Daten.
Relationelle Datenbank nach Anspruch 13, in der die besagten Tupeln, welche die ersten Daten enthalten, in Einklang mit einem Ersteller gekennzeichnet sind, der die besagten ersten Daten erstellt hat, mit dem Datum der Operation, die die besagten ersten Daten erstellt hat und möglicherweise mit der Verbindung zwischen der neuen Fassung der besagten ersten Daten und der alten Fassung der besagten ersten Daten.
Relationelle Datenbank nach Anspruch 9, in der ein Satz mit Nachrichten als eine Arbeitseinheit bezeichnet wird.
Relationelle Datenbank nach Anspruch 15, in der die besagte Einheit durch wenigstens ein Tupel in dem besagten zweiten Satz mit Tabellen dargestellt ist, wobei das besagte Tupel, das die besagte Einheit in dem besagten zweiten Satz mit Tabellen darstellt, gelöscht werden kann.
Zugangssystem zu einer Datenbank, das auf einer Komputerumgebung kompiliert worden ist und das die folgenden Elemente umfasst: – eine relationelle Datenbank nach einem der vorhergehenden Ansprüche 1 bis 16, wobei die besagte Datenbank angepasst ist für den Zugang durch Anwendungsprogramme, die eine Abfrage in der besagten Datenbank ausführen; – Meta-Daten; und – Mittel für die Optimierung der Schritte für den Zugang zu der besagten Datenbank, wobei die besagten Mittel Werkzeuge für den Erhalt eines Satzes mit Meta-Daten enthalten, nachdem die ersten Daten in die besagte Datenbank eingefügt worden sind, wobei der besagte Satz mit Meta-Daten Fehler in der Einfügung von weiteren ersten Daten in die besagte Datenbank überprüft.
System für die Entwicklung von Software für eine Anwendung, die auf einem Satz von Komputern kompiliert worden ist, wobei das besagte System folgende Elemente umfasst: – eine relationelle Datenbank, wie in irgend einem der vorhergehenden Ansprüche 1 bis 16, wobei die ersten Daten elektronische Nachrichten sind, die den Inhalt von elektronischen Formen darstellen; – erste Werkzeuge für die Unterstützung einer Benutzerschnittstelle; – zweite Werkzeuge für den Zugang zu der besagten Datenbank; und – dritte Werkzeuge, welche die besagten elektronischen Nachrichten implementieren und die besagte Datenbank mit der besagten Benutzerschnittstelle verbinden, um auf diese Weise die besagten elektronischen Nachrichten als Daten in der besagten Datenbank zu speichern und wobei die besagten elektronischen Nachrichten über die besagten Benutzerschnittstelle eingegeben werden können oder hierüber zugänglich sind.
System nach Anspruch 18, das Mitteln für die Einfügung, die Unterlassung oder die Verbesserung von den besagten elektronischen Nachrichten weiter enthält.
System nach Anspruch 19, in dem die besagten Mittel in einer Regelbasis eingeschlossen sind, mit ersten Regeln für die Überprüfung der Integrität der Daten bevor die besagten Daten hinzugefügt werden, zweite Regeln für die Ausführung der Schritte bezüglich der Unterlassung und dem Hinzufügen von Daten, nachdem die verbesserten Daten eingegeben worden sind, und dritte Regeln für das Schließen der besagten Benutzerschnittstelle.
System nach Anspruch 20, in dem die besagten Nachrichten Gesamtdaten darstellen, die aus der Gruppe von Vorgängen, Operationen, Dienstleistungen, Handlungen, Objekten und Personen innerhalb einer definierten Umgebung bestehen.
System nach Anspruch 18, in dem die besagten zweiten Werkzeuge, Werkzeuge enthalten für die Eingabe der besagten elektronischen Nachrichten in die besagte Datenbank in der Form von Tupeln mit Kolonnen in einer spezifischen Tabelle.
System nach Anspruch 18, in dem die besagte relationelle Datenbank eine Datenbank vom Sybase Typ ist, die besagte Benutzerschnittstelle eine Arbeitsstation oder ein Terminal ist und die besagten Werkzeuge in Prolog entwickelt werden.
System nach Anspruch 18, das Module weiter enthält, die spezifisch für eine Anwendung in Einklang mit einer der besagten Gesamtdaten innerhalb der besagten definierten Umgebung sind.
System nach Anspruch 18, in dem ein Satz der ersten Daten, der in der besagten Datenbank enthalten ist, auf der besagten Benutzerschnittstelle angezeigt wird.
System nach Anspruch 25, in dem die besagten ersten Werkzeuge die Mittel enthalten für die Wartung eines Untersatzes des besagten Satzes mit ersten Daten auf der besagten Benutzerschnittstelle während der Abspeicherung des besagten Satzes mit ersten Daten.
System nach Anspruch 26, in dem der besagte Satz mit ersten Daten als eine Graphik dargestellt wird, mit Knotenpunkten, die Teile des besagten Satzes mit ersten Daten darstellen und Bögen, welche die Verbindungen zwischen den besagten Teilen darstellen.
System nach Anspruch 27, in dem zusätzlich Mittel enthalten sind, um die besagten Graphiken zu überprüfen.
System nach Anspruch 18, das vierten Werkzeugen für die Entwicklung von einer spezifischen Anwendung weiter enthält, die Mitteln für das Erstellen von Datenbankobjekten umfasst, welche mit den besagten elektronischen Formen in Verbindung stehen.
Klinische Arbeitsstation, die in einer Komputerumgebung eine Darstellung von einer Gruppe von Verfahren, Operationen, Dienstleistungen, Handlungen, Objekten und Personen implementiert, die sich in einem Krankenhaus befinden, wobei dieselbe folgende Elemente umfasst: – eine relationelle Datenbank nach einem der vorhergehenden Ansprüche 1 bis 16, wobei die ersten Daten elektronische Nachrichten sind, die den Inhalt von elektronischen Formen darstellen, worin der besagte erste Satz mit Tabelle als ein Satz mit verallgemeinerten Tabellen in Einklang mit den verschiedenen Operationstypen aufgebaut ist; – Software-Module, die eine medizinische logische Einheit des besagten Krankenhauses umfassen; – eine Benutzerschnittstelle, welche eine Instrumententafel aufweist und die besagten Module umfasst; und – ein Generator, der in der besagten Komputerumgebung gespeichert ist und der folgende Elemente umfasst: – erste Werkzeuge für die Unterstützung einer Benutzerschnittstelle; – zweite Werkzeuge für den Zugang zu der besagten Datenbank; und – dritte Werkzeuge, welche die besagten elektronischen Nachrichten implementieren und die besagte Datenbank mit der besagten Benutzerschnittstelle verbinden, um auf diese Weise die besagten Nachrichten als Daten in der besagten Datenbank zu speichern und auf diese Weise die besagten Nachrichten über die besagte Benutzerschnittstelle eingeben zu können oder hierüber zugänglich zu machen.
Klinische Arbeitsstation nach Anspruch 30, in der die besagte Benutzerschnittstelle eine Instrumententafel auf einem Bildschirm umfasst, wobei die besagte Instrumententafel eine Palette mit Knöpfen enthält, welche die besagten Objekte, Personen, Verfahren, Dienstleistungen, Operationen oder Handlungen in dem besagten Krankenhaus darstellen.
Klinische Arbeitsstation nach Anspruch 30, in welcher der besagte Satz mit verallgemeinerten ersten Tabellen aus einem Standardteil, einem festen Teil und einem variablen Teil besteht.
Klinische Arbeitsstation nach Anspruch 32, in welcher der besagte Standardteil durch den Typ der Operation bestimmt ist, wobei der besagte feste Teil durch eine spezifische Dienstleistung bestimmt ist und wobei der besagte variable Teil durch die besagte Dienstleistung bestimmt ist.
Klinische Arbeitsstation nach Anspruch 30, die ferner Arbeitseinheiten enthält, die mit den besagten dritten Werkzeugen für die Überprüfung der Integrität der besagten Nachrichten verbunden sind.
Informationssystem für ein Krankenhaus, das in einem Netzwerk von Komputern und Arbeitsstationen gespeichert ist und das folgende Elemente umfasst: – eine relationelle Datenbank nach einem der vorhergehenden Ansprüche 1 bis 16, die auf wenigstens einem der Komputer des besagten Netzwerkes gespeichert ist, wobei die ersten Daten elektronische Nachrichten sind, die den Inhalt von elektronischen Formen darstellen; – ein Generator, der auf wenigstens einem der Komputer des besagten Netzwerkes gespeichert ist und der folgende Elemente umfasst: – erste Werkzeuge für die Unterstützung einer Benutzerschnittstelle; – zweite Werkzeuge für den Zugang zu der besagten Datenbank; – dritte Werkzeuge, welche die besagten elektronischen Nachrichten implementieren und die besagte Datenbank mit der besagten Benutzerschnittstelle verbinden, um auf diese Weise die besagten elektronischen Nachrichten als Daten in der besagten Datenbank zu speichern und auf diese Weise die besagten elektronischen Nachrichten über die besagte Benutzerschnittstelle eingeben zu können oder hierüber zugänglich zu machen; und – wenigstens eine klinische Arbeitsstation, welche die besagte Benutzerschnittstelle umfasst, sowie Module, die es ermöglichen die Gesamtdaten einzugeben, die aus einer Gruppe von Verfahren, Operationen, Dienstleistungen, Handlungen und Objekten bestehen, die mit den medizinischen Unterlagen eines Patienten des Krankenhauses in Verbindung stehen.
Informationssystem des Krankenhauses nach Anspruch 35, mit zusätzlichen Daten in Verbindung mit den Verwaltungsunterlagen eines Patienten des Krankenhauses.
Methode für den Aufbau einer relationellen Datenbank für die Beschleunigung der Ausführung einer im voraus definierten Abfrage innerhalb der besagten relationellen Datenbank, wobei die besagte relationelle Datenbank Daten enthält, die Arbeitseinheiten betreffen, wobei jede Arbeitseinheit eine Einheit von Dienstleistungen umfasst, die in einer bestimmten Reihenfolge durchgeführt werden, wobei die besagten Arbeitseinheiten weiterhin einen Status haben und der besagte Status aktiv oder abgeschlossen ist und wobei die besagte im voraus definierte Abfrage eine Abfrage ist, die wenigstens teilweise in Arbeitseinheiten liegt, deren Status aktiv ist, wobei die besagte Methode folgende Schritte umfasst: – das gleichzeitiges Erstellen eines ersten und eines zweiten Satzes mit Tabellen, wobei der besagte erste Satz mit Tabellen, erste Kolonnen und erste Tupeln enthält sowie einen ersten Datensatz mit ersten Daten, die in den besagten ersten Kolonnen und ersten Tupeln enthalten sind, und wobei der besagte zweite Satz mit Tabellen, zweite Kolonnen und zweite Tupeln enthält sowie einen zweiten Datensatz mit zweiten Daten, die in den besagten zweiten Kolonnen und zweiten Tupeln enthalten sind, wobei die besagten zweiten Daten eine redundante Darstellung eines ausgewählten Teils der besagten ersten Daten sind, und – eine Speicherung der besagten ersten und zweiten Datensätze auf einer Komputerumgebung, in der die besagten ersten Daten alle die besagten Dienstleistungen von allen Arbeitseinheiten umfassen, die einen aktiven oder abgeschlossenen Status haben, und der besagte ausgewählte Teil der besagten ersten Daten aus allen Arbeitseinheiten bestehen, die eine Dienstleistung mit einem aktiven Status haben.
Methode für die Ausführung von Abfragen in einer relationellen Datenbank nach einem der vorhergehenden Ansprüche 1 bis 16 oder die durch die Methode nach Anspruch 37 erstellbar ist, wobei dieselbe folgende Schritte umfasst: – die Auswahl der Tupeln in dem besagten zweiten Satz mit Tabellen, und – die Auslese der Tupeln des besagten ersten Satzes mit Tabellen, die den besagten ausgewählten Tupeln der besagten zweiten Tabellen entsprechen.
Methode für die Ausführung von Abfragen in einer relationellen Datenbank nach Anspruch 15, wobei dieselbe folgende Schritte umfasst: – die Auswahl der Tupeln des besagten zweiten Satzes mit Tabellen, die der besagten Einheit entsprechen, und – die Auslese der Attribute, die einer Kolonne und einem Tupel des besagten ersten Satzes mit Tabellen entsprechen, die den besagten ausgewählten Tupeln der besagten zweiten Tabellen entsprechen, die der besagten Einheit entspricht.