DE112007001196T5

DE112007001196T5 - System zur adaptiven Abfrage eines Datenspeicherlagers

Info

Publication number: DE112007001196T5
Application number: DE112007001196T
Authority: DE
Inventors: Wolfgang Wiessler; Debarshi Datta; Steven Owens
Original assignee: Siemens Medical Solutions USA Inc
Current assignee: Siemens Medical Solutions USA Inc
Priority date: 2006-06-02
Filing date: 2007-06-04
Publication date: 2009-07-02
Also published as: WO2007143198A2; WO2007143198A3; US20080222121A1

Abstract

System zum adaptiven Abfragen eines Datenspeicherlagers, mit
einem Eingabeprozessor zum Empfangen einer Mehrzahl von unterschiedlichen ersten Abfragenachrichten in einer entsprechenden Mehrzahl von unterschiedlichen Formaten;
einem Lager von gespeicherten Datenelementen in einer ersten Speicherdatenstruktur; und
einem Vermittlerprozessor zum automatischen Durchführen der Aktivitäten von:
Parsen der Mehrzahl von ersten Abfragenachrichten, zum Identifizieren von angeforderten Datenelementen,
Abbilden der identifizierten angeforderten Datenelemente auf gespeicherten Datenelementen in der ersten Speicherdatenstruktur des Lagers,
Erzeugen einer Mehrzahl von zweiten Abfragenachrichten in einem Format, das kompatibel ist zu dem Lager zur Erfassung der gespeicherten Datenelemente,
Erfassen der gespeicherten Datenelemente aus dem Lager unter Verwendung der erzeugten Mehrzahl von zweiten Abfragenachrichten, und
Verarbeiten der gespeicherten Datenelemente, die in Antwort auf die Mehrzahl von zweiten Abfragenachrichten erfasst werden, zur Ausgabe in einem Format, das kompatibel ist zu der entsprechenden Mehrzahl von unterschiedlichen Formaten der ersten Abfragenachrichten.

Description

Diese ist eine nicht vorläufige Anmeldung der vorläufigen Anmeldung mit der Seriennummer 60/803,750 von S. F. Owens und anderen, eingereicht am 2 Juni 2006.
Gebiet der Erfindung
Die vorliegende Erfindung betrifft Datenspeicherlagersysteme, und insbesondere Systeme zum Abfragen eines Datenspeicherlagers.
Hintergrund der Erfindung
Die Anzahl von Quellen oder Lager von Daten nimmt zu. Diese Quellen können elektronische Instrumente sein, die Echtzeitdaten erzeugen, Computersysteme, die Daten sammeln und speichern, oder Fernsysteme, die Daten in Antwort auf Anfragen von einem Benutzer zurückgeben. Es ist oft erforderlich Daten, die von verschiedenen Datenquellen geholt werden, zu integrieren und/oder zu kombinieren. Typischerweise wird jede Datenquelle unabhängig von den anderen entwickelt und/oder gewartet, möglicherweise durch unterschiedliche Anbieter. Dies hat unterschiedliche Verfahren zur Abfrage der Datenquelle und verschiedene Formate für die Abfrage der Datenquelle sowie für die Daten, die von der Datenquelle geholt werden, zur Folge. Ferner werden oft neue Datenquellen verfügbar, und ein Zugriff auf diese Datenquellen wird von einem Benutzer gewünscht.
In medizinischen Kontent-Management-Systemen sind diverse Quellen von medizinischen Daten verfügbar, und neue werden verfügbar. Daten von diversen Quellen werden kombiniert, um hilfreiche Information herzuleiten. Beispielsweise wird in der Diagnose und Behandlung von Krebs metabolische Information, die von PET- oder von SPECT-Studien hergeleitet wird, mit anatomischer Information, die von CT-Studien mit hoher Auflösung hergeleitet wird, korreliert. Weitere Daten können von einer molekularen Bildgebung verfügbar sein, die ebenfalls mit den oben beschriebenen Daten kombiniert werden. Jede zusätzliche Quelle von Daten erfordert, dass das Abfragsystem zum Zugriff auf diese Daten und die Formate zur Übertragung von Anfragen und Daten an die neuen Datenquellen angepasst werden.
Die verschiedenen medizinischen Datensysteme, wie Bildarchivierungs- und Kommunikationssysteme (PACs), Radiologieinformationssysteme (RIS), Laborinformationssysteme (LISs) und andere Fachbereichsinformationssysteme sind nicht individuell konfiguriert, um der Vielfältigkeit von Daten, die jetzt verfügbar sind und die in Zukunft verfügbar werden, Rechnung zu tragen. Dies liegt daran, dass gegenwärtige Datenspeicherlagerabfragesysteme ein festes Datenschema verwenden, und unterschiedliche Datenspeicherorte unterschiedliche feste Abfragesysteme verwenden. Ferner verwenden unterschiedliche Anwendungen unterschiedliche Abfragschemen und Datenformate zur Abfrage von Datenspeicherlagern. Ein System zum Abfragen eines Datenspeicherorts, das flexibel und dynamisch ist, ist wünschenswert.
Kurze Zusammenfassung der Erfindung
Gemäß Prinzipien der vorliegenden Erfindung frägt ein System adaptiv ein Datenspeicherlager ab. Ein Eingabeprozessor empfängt eine Mehrzahl von unterschiedlichen ersten Abfragenachrichten in einer entsprechenden Mehrzahl von unterschiedlichen Formaten. Ein Speicher enthält gespeicherte Datenelemente in einer ersten Speicherdatenstruktur. Ein Vermittlerprozessor parst automatisch die Mehrzahl von ersten Abfragenachrichten, um angeforderte Datenelemente zu identifizieren; bildet automatisch die identifizierten angefragten Datenelemente auf gespeicherte Datenelemente in der ersten Speicherdatenstruktur des Speicherorts ab; erzeugt automatisch eine Mehrzahl von zweiten Abfragenachrichten in einem Format, das mit dem Speicherort kompatibel ist, zur Erfassung der gespeicherten Datenelemente; erfasst automatisch die gespeicherten Datenelemente aus dem Speicherlager unter Verwendung der erzeugten Mehrzahl von zweiten Abfragenachrichten; und verarbeitet automatisch die erfassten gespeicherten Datenelemente in der Mehrzahl von zweiten Abfragenachrichten zur Ausgabe in einem Format, das kompatibel ist mit einer entsprechenden Mehrzahl von unterschiedlichen Formaten der ersten Abfragenachrichten.
Ein derartiges System erlaubt unterschiedlichen Anwendungen, die jeweils ein anderes Datenmodell implementieren, um auf die gleichen Daten zuzugreifen, die in dem gleichen Speicherlager gespeichert sind. In einem speziellen Fall dieser Situation kann die gleiche Anwendung unterschiedliche Datenmodelle implementieren, um auf die gleichen Daten zuzugreifen. Darüber hinaus erlaubt ein derartiges System ein Hinzufügen eines neuen Datentyps oder ein Er setzen eines Datenelements durch ein neues Datenelement, das möglicherweise an einem anderen Ort oder einem anderen Speicherlager gespeichert wurde. Ein derartiges System erlaubt ein dynamisches Ändern des Speicherdatenmodels, also des Models der Daten innerhalb des Speicherlagers, ohne die Anwendungen zu beeinflussen. Die Anwendungen müssen also nicht wissen, wie die Daten in dem Speicherlager gespeichert werden. Ähnlich erlaubt ein derartiges System ein dynamisches Ändern des Datenspeicherlagers selbst. Eine Änderung kann also in den Datenspeichervorrichtungen erfolgen, die die Speicherdatenstruktur halten. Diese Änderungen können erfolgen ohne, dass eine Änderung in der ausführbaren Anwendung oder in ausführbaren Prozeduren, die die Anwendungen oder den Client implementieren, oder eine Änderung des Datenspeicherlagers erforderlich ist. Dies bedeutet, dass kein erneutes Codieren und kein Neutesten des ausführbaren Anwendungscodes notwendig ist, um die oben beschriebenen verschiedenen Änderungen bereitzustellen.
Kurzbeschreibung der Zeichnungen
In den Zeichnungen zeigen:
1 ein Blockdiagramm eines Systems zum adaptiven Abfragen eines Datenspeicherlagers gemäß Prinzipien der vorliegenden Erfindung;
2 ein detaillierteres Blockdiagramm, das einem Bereich des Systems in 1 gemäß der vorliegenden Erfindung verdeutlicht.
3 ein Datenbeziehungsdiagramm, das die Komponenten eines Informationsmodellabbilders verdeutlicht, der Teil des Systems in 1 ist, gemäß Prinzipien der vorliegenden Erfindung;
4 ein Flussdiagramm, das den Betrieb eines Systems zum adaptiven Abfragen eines Datenspeicherlagers gemäß Prinzipien der vorliegenden Erfindung verdeutlicht; und
5 ein Beispiel eines Kernschemas, 6 ein Beispiel eines Ausgabeschemas, 7 ein Beispiel einer Abbildungsdatei, 8 ein Beispiel einer Abfragedatei, und 9 ein Bei spiel einer Ausgabedatei, die in Kombination hilfreich sind für das Verständnis des Betriebs des Systems gemäß 1 in Übereinstimmung mit Prinzipien der vorliegenden Erfindung.
Detaillierte Beschreibung der Erfindung
Ein Prozessor, wie er hier verwendet wird, arbeitet unter der Steuerung einer ausführbaren Anwendung, um (a) Information von einer Eingabeinformationsvorrichtung zu empfangen, (b) die Information zu verarbeiten durch manipulieren, analysieren, modifizieren, konvertieren und/oder übertragen der Information, und/oder (c) die Information an eine Ausgabeinformationsvorrichtung weiterzuleiten. Ein Prozessor kann die Fähigkeiten von beispielsweise einer Steuerung oder von einem Mikroprozessor verwenden oder enthalten. Der Prozessor kann mit einem Anzeigeprozessor oder Generator arbeiten. Ein Anzeigeprozessor oder Generator ist ein bekanntes Element zum Erzeugen von Signalen, die Anzeigebilder oder Bereiche davon darstellen. Ein Prozessor und ein Anzeigprozessor enthalten irgendeine Kombination von Hardware, Firmware und/oder Software.
Eine ausführbare Anwendung, wie sie hier verwendet wird, enthält code- oder maschinenlesbare Anweisungen zum Konditionieren des Prozessors, um vorbestimmte Funktionen zu implementieren, beispielsweise diejenigen eines Betriebssystems, eines Systems zum adaptiven Abfragen eines Datenspeicherorts, oder eines anderen Informationsverarbeitungssystems, beispielsweise in Antwort auf einen Benutzerbefehl oder eine Eingabe. Eine ausführbare Prozedur ist ein Codesegment oder eine maschinenlesbare Anweisung, Subroutine oder ein anderer eindeutiger Codeabschnitt oder Bereich einer ausführbaren Anwendung zum Durchführen von einem oder von mehreren bestimmten Prozessen. Diese Prozesse können ein Empfangen von Eingabedaten und/oder Parametern, ein Durchführen von Operationen für die empfangenen Eingabedaten und/oder ein Durchführen von Funktionen in Antwort auf empfangene Eingabeparameter und ein Bereitstellen resultierender Ausgabedaten und/oder Parameter enthalten.
Ein Datenlager, wie er hier verwendet wird, enthält eine Quelle von Datensätzen. Ein Datenlager kann eine oder kann mehrere Speichervorrichtungen aufweisen, die die Datensätze beinhalten, es kann lokal zu dem Prozessor oder von dem Prozessor entfernt angeordnet sein. Wenn er von dem Prozessor entfernt ist, können die Daten zwischen dem Prozessor und dem Datenlager über einen Kommunikationskanal übertragen werden, beispielsweise über eine bestimmte Da tenverbindung, ein Computernetzwerk, also ein lokales Netzwerk (LAN) und/oder ein WAN, wie beispielsweise das Internet, oder über irgendwelche Kombinationen derartiger Kommunikationskanäle. Ein Datenlager kann auch Quellen von Datensätzen aufweisen, die keine Speichervorrichtungen enthalten, beispielsweise Live Feeds, Nachrichtenfeeds, Aktienticker oder andere derartige Echtzeitdatenquellen. Ein Datensatz, wie er verwendet wird, kann ein oder kann mehrere Dokumente enthalten und der Begriff „Datensatz" kann austauschbar verwendet werden mit dem Begriff „Dokument".
Das World Wide Web Konsortium (W3C) hat einen Standard definiert, der als XML-Schema bezeichnet wird. Ein XML-Schema stellt ein Mittel bereit zum Definieren der Struktur, des Inhalts und der Semantik von XML-Dokumenten. Ein XML-Schema wird verwendet zum Definieren einer Metadatenstruktur. Beispielsweise können die Metadaten die Struktur einer Sammlung von verschachtelten Tabellen definieren oder spiegeln. Die jeweiligen Tabellen enthalten eine Sammlung von Feldern (die nicht verschachtelt werden können). Die jeweiligen Felder enthalten eine Sammlung von Datenelementen.
Der Begriff Abstraktion bezieht sich auf die Praxis des Reduzierens oder Herausfakorisierens von Details, so dass man sich auf breitere, wichtigere Konzepte konzentrieren kann. Der Begriff Datenabstraktion betrifft die Abstraktion der Struktur und des Inhalts von Daten, beispielsweise Daten, die in Datenlagern gespeichert sind, gegenüber der Bedeutung der Daten selbst. Ein Benutzer kann beispielsweise an einem Röntgenbild interessiert sein, aber nicht daran wo die Daten, die dieses Bild darstellen, gespeichert sind, wie sie gespeichert sind oder wie der Mechanismus aussieht, der erforderlich ist zum Zugreifen auf diese Daten und zum Holen dieser Daten. Eine Datenabstraktionsschicht betrifft eine ausführbare Anwendung, oder ausführbare Prozedur, die eine Datenabstraktion zwischen einem Benutzer und der Speicherung der Daten, die für den Benutzer wichtig sind, aufrechterhält. Insbesondere, wie hier verwendet, ist eine Datenabstraktionsschicht ein System zur Gewinnung von Daten aus einem Lager ohne vorherige Kenntnis der Speicherstruktur, unter Verwendung vordefinierter Information, die das Parsen, Analysieren und Abfragen des Lagers unterstützt.
Der Begriff „Schema" wird hier in verschiedenem Kontext verwendet. Wenn er im Bezug auf XML (beispielsweise „XML-Schema") verwendet wird, ist eine normale XML-Schemadatei gemäß der W3C-Definition gemeint. Wenn er im Bezug auf eine Datenbank verwendet wird, ist das Datenbankschema (beispielsweise Tabellen, Reihen, Felder oder Hierarchie, etc.) als Teil der realen Datenbank gemeint. Wenn er verwendet wird in Bezug auf einen Begriff der Datenabstraktionsschicht (beispielsweise „Ausgabeschema"), ist die XML-Schemadatei, die die Information enthält, gemeint (wie später genauer beschrieben wird). Eine XML-Datei, die Information beschreibt, die von der Datenabstraktionsschicht verwendet wird und zu einem der Datenabstraktionsschichtschemen gehört, wird bezeichnet als „<Datenabstraktionsschichtterm>" plus „Datei", beispielsweise „Abbildungsdatei" (wie ebenfalls später im Einzelnen beschrieben wird).
1 zeigt ein Blockdiagramm eines Systems zum adaptiven Abfragen eines Datenspeicherlagers gemäß Prinzipien der vorliegenden Erfindung. In 1 empfängt ein Eingabeprozessor (10) eine Mehrzahl von Anfragenachrichten an einem Eingabeterminal. Ein Ausgabeterminal in dem Eingabeprozessor 10 ist an einen ersten Eingabeterminal eines Vermittlerprozessors 30 gekoppelt. Ein erster Ausgabeterminal des Vermittlerprozessors 30 ist an einem Eingabeterminal eines Lagers 20 gekoppelt. Ein Ausgabeterminal des Lagers 20 ist an einem zweiten Eingabeterminal des Vermittlerprozessors 30 gekoppelt. Ein zweiter Ausgabeterminal des Vermittlerprozessors 30 erzeugt Ausgabedaten in Antwort auf die empfangenen Anfragenachrichten.
Im Betrieb empfängt der Eingabeprozessor 10 eine Mehrzahl von unterschiedlichen ersten Anfragenachrichten in einer entsprechenden Mehrzahl von unterschiedlichen Formaten. Das Lager 20 enthält gespeicherte Datenelemente in einer ersten Speicherdatenstruktur. Der Eingabeprozessor 10 sendet die Mehrzahl von ersten Anfragenachrichten an den Vermittlerprozessor 30, der automatisch die folgenden Aktivitäten durchführt. Er parst die Mehrzahl von ersten Anfragenachrichten, um angeforderte Datenelemente zu identifizieren. Er bildet die identifizierten angeforderten Datenelemente auf gespeicherte Datenelemente in der ersten Speicherdatenstruktur in dem Speicher 20 ab. Er erzeugt eine Mehrzahl von zweiten Anfragenachrichten in einem Format, das kompatibel ist mit dem Lager 20 zum Erfassen der gespeicherten Datenelemente. Die Mehrzahl von zweiten Abfragnachrichten wird an das Lager 20 gesendet. Der Vermittlerprozessor 30 erfasst die gespeicherten Datenelemente von dem Lager 20 unter Verwendung der erzeugten Mehrzahl von zweiten Abfragenachrichten. Ferner, verarbeitet er die gespeicherten Datenelemente, die er in Antwort auf die Mehrzahl von zweiten Abfragenach richten erfasst hat, zur Ausgabe in einem Format, das kompatibel ist mit der entsprechenden Mehrzahl von unterschiedlichen Formaten der ersten Abfragenachrichten.
Spezieller empfängt der Eingabeprozessor 10 mindestens eine erste Abfragenachricht, die eine Abfrage für Information enthält, und eine Anweisung, die ein Datenformat zur Bereitstellung der Information bestimmt. Die Anweisung ist änderbar für ein adaptives Ändern der Information und des Datenformats zur Bereitstellung der Information. Die Anweisung, die das Datenformat zur Bereitstellung der Information bestimmt, kann in einem Auszeichnungssprach-Ausgabeschema sein. Beispielsweise kann das Auszeichnungssprach-Ausgabeschema ein erweiterbares Auszeichnungssprach(XML)-Schema sein. Diese Abfragenachricht wird an den Vermittlerprozessor 30 gesendet. Der Vermittlerprozessor 30 parst die mindestens eine erste Abfragenachricht, um angeforderte Datenelemente zu identifizieren. Er bildet die identifizierten angefragten Datenelemente auf gespeicherte Datenelemente in der ersten Speicherdatenstruktur des Lagers 20 ab. Er erzeugt dann mindestens eine zweite Abfragenachricht in einem Format, das kompatibel ist zu dem Speicher 20 zur Erfassung der gespeicherten Datenelemente, die an den Speicher 20 gesendet worden ist. Er erfasst die gespeicherten Datenelemente aus dem Speicher 20 unter Verwendung der erzeugten mindestens einen zweiten Abfragenachricht. Ferner, verarbeitet er die gespeicherten Datenelemente, die in Antwort auf mindestens eine zweite Abfragenachricht erfasst worden sind, zur Ausgabe in einem Format, das kompatibel ist zu dem Datenformat, das durch die Anweisung in der mindestens eine erste Abfragnachricht bestimmt worden ist.
In dem System gemäß 1 führt der Vermittlerprozessor 30 vorteilhafterweise automatisch die oben beschriebenen Aktivitäten durch, ohne Neuübersetzen oder Neutesten eines ausführbaren Codes, der zur Durchführung dieser Aktivitäten verwendet wird. Diese Flexibilität wird erreicht durch Verkörpern von Information, die die Aktivitäten in Dateien betrifft, die Daten enthalten, die Einzelheiten bezüglich der Durchführung dieser Aktivitäten beschreiben. Spezieller verkörpert das System die abfragespezifische Information in deskriptiven Dateien (beispielsweise Kernschema, Erweiterungsschema, Abbildungsdatei, Ausgabeschema, Abfragedatei, etc., wie im Folgenden beschrieben), anstatt in dem ausführbaren Code. Die Daten in den deskriptiven Dateien kann geändert werden, ohne ein Ändern des ausführbaren Codes, um Aspekte des Datenholens zu ändern.
Die ersten Abfragenachrichten enthalten Dateien, die zu einem Abfrageschema konform sind, und die zweite Abfragenachrichten enthalten Abfragen, die von dem Lager 20 ausführbar sind. Die ersten Abfragenachrichten sind in einem Format, das durch das Abfrageschema bestimmt wird. Das Abfrageschema bestimmt: (a) die Abfragesuchtiefe der hierarchischen Datenelemente in dem Speicher 20, und/oder (b) Einschränkungen auf das Absuchen des Speichers 20. Das Abfrageschema kann (a) ein SQL-kompatibles Abfragformat und/oder (b) ein Xquery-kompatibles Format haben.
Wie oben beschrieben verarbeitet der Vermittlerprozessor 30 gespeicherte Datenelemente, die aus dem Speicher 20 geholt werden, zur Ausgabe in einem Format, das kompatibel ist mit der entsprechenden Mehrzahl von unterschiedlichen Formaten der ersten Abfragenachrichten. Das Format, das mit der entsprechenden Mehrzahl von unterschiedlichen Formaten der ersten Abfragenachrichten kompatibel ist, wird bestimmt durch ein Ausgabeschema. Das System von 1 enthält Daten, die das Ausgabeschema bestimmen. Das System von 1 enthält ferner Daten, die ein Kernschema bestimmen, das Datenfelder angibt, die in der ersten Speicherdatenstruktur in dem Speicher 20 von gespeicherten Datenelementen zugreifbar sind. Es enthält ferner ein Abbildungsschema, das das Abbilden der identifizierten angefragten Datenelemente auf die gespeicherten Datenelemente in der ersten Speicherdatenstruktur in dem Speicher 20 bestimmt.
2 zeigt ein detaillierteres Blockdiagramm des Vermittlerprozessors 30 von dem System von 1 gemäß der vorliegenden Erfindung. In 2 senden ausführbare Anwendungen oder Komponenten von ausführbaren Anwendungen, manchmal als Clients bezeichnet, Daten, die die ersten Abfragenachrichten 202 in einem XML-Format darstellen, an den Vermittlerprozessor 30 über den Eingabeprozessor 10 (1). Die Abfragen 202 werden einer Datenabstraktionskomponenten 204 bereitgestellt. Die Datenabstraktionsschicht 204 enthält in ihrer Programmierung keine Kenntnisse von der Struktur oder von der Operation von weder den ausführbaren Anwendungen oder den Komponenten, noch von dem Lager 20. Stattdessen ist die Information, die die Struktur und die Operation dieser Elemente betrifft, in Daten enthalten, die in dem Informationsmodellabbilder 206 gespeichert sind. Die Datenabstraktionskomponente 204 greift auf Information in dem Informationsmodellabbilder 206 zu, um die ersten Abfragenachrichten zu parsen und die Datenelemente, die in den ersten Abfragenachrichten identifiziert werden, auf gespeicherte Datenelemente in der ersten Speicherdatenstruktur abzubilden.
Die Datenabstraktionskomponente greift ferner auf Information in dem Informationsmodellabbilder 206 zu, um zweite Abfragenachrichten in einem Format zu erzeugen, das kompatibel ist mit dem Lager 20, um die identifizierten gespeicherten Datenelemente abzurufen. Die zweiten Abfragenachrichten sind in einem Format, das von dem Lager 20 ausgeführt werden kann. Beispielsweise, im Fall einer Datencomputerbank, können die zweiten Abfragenachrichten in einem SQL-kompatiblen Abfrageformat oder einem Xquery-kompatiblen Abfrageformat sein. Die zweiten Abfragenachrichten werden an das Lager 20 geliefert. In Antwort darauf, gibt das Lager 20 die angefragten gespeicherten Datenelemente zurück. Die Datenabstraktionskomponente 204 erfasst die gespeicherten Datenelemente von dem Speicher 20 in Antwort auf die zweiten Abfragenachrichten. Die Datenabstraktionskomponente 204 greift erneut auf Information in dem Informationsmodell 206 zu, um die erfassten gespeicherten Datenelemente zu verarbeiten, um sie in einem Format zu platzieren, das kompatibel ist mit der entsprechenden ersten Abfrage, die von dem Eingabeprozessor 10 empfangen wird (1). Die reformatierten Daten werden an die ausführbare Anwendung, den Client oder die Komponente, die angefragt hat, zurückgegeben.
3 zeigt ein Datenbeziehungsdiagramm, das die Komponenten eines Informationsmodellabbilders 206 verdeutlicht, der Teil des Systems von 1 ist, gemäß Prinzipien der vorliegenden Erfindung. In dem Ausführungsbeispiel, das in 3 gezeigt ist, wird das Schema als XML-Schema implementiert, und Daten werden erwartet in der Form von XML-Dateien. Diese Datendateien können validiert werden, indem sie gegenüber dem XML-Schema geprüft werden, das Inhalt und Struktur definiert.
In 3 enthält der Informationsmodellabbilder 206 ein Kernschema 304 und ein oder mehrere Erweiterungsschemen 306. Das Kernschema 304 und die Erweiterungsschemen 306 (die später genauer beschrieben werden) definieren den Bereich 303 einer Anwendung. Der Bereich 303 einer Anwendung stellt angefragte Datenelemente dar, die verwendet und von anderen Schemen referenziert werden können, um das Datenmodell zu bilden. Spezieller definieren das Kernschema 304 die Erweiterungsschemen 306 die Datenelemente, die für eine Abfrage verfügbar sind, jedoch definieren sie nicht irgendeine Hierarchie. Die Elemente, die in dem Bereich 303 definiert sind, sind atomar (sie haben also keine Kind-Elemente) und können verwendet werden, um Levels zu definieren, können jedoch nicht selbst als Level dienen.
Der Informationsmodellabbilder 206 enthält ferner ein oder mehrere Ausgabeschemen 302 (die im Folgenden genauer beschrieben werden). Ein Ausgabeschema 302 spezifiziert die Beziehung unter verfügbaren angefragten Datenelementen, die in dem Bereich 303 einer Anwendung definiert sind (beispielsweise Kernschema 304 und Erweiterungsschemen 306). Spezieller definiert das Ausgabeschema 302 eine Ausgabehierarchie durch Spezifizieren von Leveln in dem Informationsmodell. Die Kombination des Bereichs 303 einer Anwendung und eines Ausgabeschemas 302 definiert das Informationsmodell 305 für entweder eine gesamte Anwendung oder einen Teil davon (beispielsweise ein Client).
Ein Abbildungsschema 308 (das im Folgenden genau beschrieben wird) definiert die Inhalte und die Struktur einer Abbildungsdatei 309. Eine Abbildungsdatei 309 spezifiziert die Korrespondenz unter Datenelementen, die in dem Informationsmodell 305 definiert sind, und die Speicherdatenstruktur des Speichers 20 (2). Eine Abbildungsdatei 309, die gemäß dem Abbildungsschema 308 aufgebaut ist, definiert also wo Datenelementen, die in dem Informationsmodell definiert sind, in dem Lager 20 lokalisiert sind, und wie sie aus dem Lager 20 geholt werden können.
Der Informationsmodellabbilder 206 enthält ferner ein Abfrageschema 310 (das im Folgenden genau beschrieben wird). Um Daten aus dem Lager 20 zu holen verarbeitet die Datenabstraktionsschicht 206 Abfragedaten 202, die von dem Eingabeprozessor 10 (1) in der Form einer XML-Formatabfragedatei 311 empfangen werden. Das Abfrageschema 310 definiert die jeweiligen Inhalte und die Struktur der Abfragdateien 311, die von der Datenabstraktionskomponente 204 empfangen werden. Die Mehrzahl von ersten Abfragen, die durch eine ausführbare Anwendung oder eine Komponente oder einen Client abgegeben werden, sind jeweilige Abfragedateien 311, die konform sind mit dem Abfrageschema 310.
Die Datenabstraktionskomponente 204 enthält ferner ein Ressource-Schema 312 (das im Folgenden genauer beschrieben wird). Das Ressource-Schema 312 definiert den Inhalt und die Struktur einer Ressource-Datei 313. Die Ressource-Datei 313 dient als Lager von Daten, die externe Datenquellen in dem Speicher 20 spezifizieren. Diese Datenquellen können von der Datenabstraktionsschicht 204 abgefragt werden, oder Daten können an den Abfrager zurückgegeben werden, so dass die externen Datenquellen von dem Abfrager außerhalb der Datenabs traktionsschicht 204 abgefragt werden können. Beispiele der Schemen und Dateien, die in 3 verdeutlicht sind, sind in dem Folgenden Anhang gegeben.
Im Einzelnen beschreibt ein Kernschema 304 die Grundelemente, die ein Ausgabeschema 302 in dem gleichen Bereich 303 verwenden kann, um ein Ausgabemodell zu bilden. Die mehreren Ausgabeschemen 302 enthalten die Schemendaten, die in dem Kernschema 304 enthalten sind, um auf dessen Elemente Zugriff zu haben. In dem vorliegenden Ausführungsbeispiel, in dem das Kernschema und Ausgabeschema XML-Schemen sind, meint der Begriff „enthält" ein Textkopieren der Inhalte des Kernschemas 304 in die mehreren Ausgabeschemen 302. Dies kann erfolgen durch Plazieren einer Textreferenz zu dem Kernschema 304 in den mehreren Ausgabeschemen 302. Das Kernschema 304 definiert nicht irgendeine Beziehung zwischen den bereitgestellten Elementen und wird nicht verwendet als Schema für tatsächliche XML-Dateien. Gemeinsame Datentypen und Elementgruppen für eine bequeme Referenz können in einem Kernschema 304 definiert werden. Seine Hauptverwendung liegt in der Vereinheitlichung der Deklaration gemeinsam verwendeter Elemente in einem Bereich. Die Basisstruktur ist:

– Einbeziehung des allgemeinen Schemas
– Typdefinitionen
– Elementdefinitionen
– Definition zusätzlicher Hilfselemente, um die gemeinsame Ver

Ein Kernschema 304 definiert auch welche Elemente zusätzliche externe Verbindungen bereitstellen können. Eine externe Verbindung ist eine Referenz auf eine Ressource, die definiert ist in der Ressourcendatei 313 kombiniert mit einem Identifizierer, der die angefragte Information spezifiziert. Ein Anfrager kann diese Information verwenden, um auf diese Datenquelle direkt zuzugreifen, um darin gespeicherte Objekte zu holen.
Im Einzelnen stellte das Erweiterungsschema 306 die Fähigkeit bereit, das Kernschema 304 mit einer Anwendung oder einer Implementierung spezifischer gemeinsamer Elemente zu erweitern. Ein oder mehrere Erweiterungsschemen 306 können definiert werden, die im Wesentlichen die gleiche Struktur wie das Kernschema 304 aufweisen, jedoch nicht von jedem Aus gabeschema 302 verwendet werden müssen. Das Erweiterungsschema 306 zusammen mit dem Kernschema 304 definiert den Bereich 303 einer Anwendung. Der Bereich 303 repräsentiert das Grundrahmenwerk innerhalb dem unterschiedliche Informationsmodelle implementiert werden können.
Genauer beschreibt ein Ausgabeschema 302 das Datenmodell auf dem eine abfragende Anwendung ihre Abfragen basiert (beispielsweise ein Ausgabemodell). Es enthält ein Kernschema 304 und optional ein oder mehrere Erweiterungsschemen 306, um auf die Grundelemente, die den Bereich 303 bilden, zuzugreifen. Ein Ausgabeschema 302 spezifiziert eine Hierarchie, die den Kontext definiert, in dem die Datenelemente dargestellt werden. Die abgefragten Ergebnisse von dem Lager 20 werden formatiert basierend auf der spezifizierten Hierarchie, bevor sie an den Abfrager zurückgegeben werden. Neben der Verwendung der gemeinsamen Elemente kann auch ein Ausgabeschema 302 neue Elemente einführen, die nur spezifisch sind für dieses einzelne Ausgabemodell. Derartige Elemente sind typischerweise Level, die verschachtelte Elemente enthalten, beispielsweise Level, die reale Datenbanklevel oder Hilfslevel reflektieren, die nicht in dem realen Datenbankdatenmodell existieren. Andere Elemente können entweder in dem Kernschema oder den Erweiterungsschemen 304, 306 definiert werden. Ein Ausgabeschema 302 zusammen mit den Kern- und Erweiterungsschemen 304, 306 bildet ein Informationsmodell 305, das die Semantik des gegenwärtigen Datenmodells beschreibt, ohne Bezugnahme auf irgendetwas in der realen Datenbank. Die Verbindung zwischen dem gegenwärtig verwendeten Informationsmodell, das durch das Ausgabeschema 302 definiert wird, und der tatsächlichen Darstellung in der Datenbank wird definiert in einem Abbildungsschema 308. Ein Ausgabeschema 302 beschreibt eine komplette Hierarchie. Eine Abfrage kann eine erforderliche Tiefe begrenzen oder nur bestimmte Bereiche des Ausgabemodells abfragen. Das Folgende ist das allgemeine Layout eines Ausgabeschemas 302:

– Referenzieren des Kernschemas 304 und der Erweiterungsschemen 306 (wenn notwendig)
– Definieren von Leveln, beginnend mit der untersten Level. Ein höheres Level bezieht sich auf die niedrigere Schicht und beschreibt dessen Multiplizität.
– Definieren des Ausgabemodells, das entweder die gesamte Hierarchie (Referenzieren des höchsten Levels) oder eine Sammlung von niedrigeren Leveln aufweist, wenn eine Abfrage die Daten, die angezeigt werden, abfragt beginnend bei einem niedrigeren Level.

Genauer beschreibt ein Abbildungsschema 308 die Struktur einer XML-Datei, die definiert, wie Elemente, die in dem Ausgabeschema 302 verwendet werden, Tabellen, Feldern oder anderen Einheiten in dem Lager 20 entsprechen. Eine tatsächliche XML-Abbildungsdatei 309 bildet die Daten, die in dem einen Ausgabeschema 302 spezifiziert sind, ab. Eine andere Abbildungsdatei 309 ist erforderlich, wenn ein anderes Ausgabeschema 302 in dem gleichen Bereich 303 verwendet wird, und dieses Ausgabeschema 302 führt neue Level ein. Im Übrigen kann die gleiche Abbildungsdatei 309 verwendet werden. Eine Abbildungsdatei 309 besteht aus den folgenden primären Elementen:

– Einheit – Eine Einheit repräsentiert ein Element, das auf eine gesamte Lager 20 – Speicherressource abgebildet ist, beispielsweise eine Datenbanktabelle. Eine Einheit hat „Namen"- und „Abbildungstabelle" – Kindknoten.
– Feld – Ein Feld repräsentiert ein atomares Element in der Lager 20 – Speicherressource, beispielsweise ein Feld in einer Tabelle. Jeweilige Felder haben den „Name"-, „Abbildungstabelle"-, „Abbildungsfeld", „ist Erweiterungsfeld"-, „ist suchbar" – Kindknoten
– Hilfslevel – Ein Hilfslevel spiegelt ein künstliches Level wieder, die in das Ausgabeschema 302 eingeführt ist, um ein neues Hierarchielevel hinzuzufügen, das aus einem oder mehreren Feldern besteht. Es dient als Gruppierungsmechanismus. Ein Beispiel ist ein Level, das als „Geschlecht und Krankheit" bezeichnet wird, das verwendet wird als ein erstes Level in einem Ausgabemodell. Wenn ein Abfrager Datensätze von Patienten mit der Krankheit „HIV" abfrägt, werden durch dieses Hilfslevel die Ergebnisse in zwei Gruppen formatiert, eine mit dem Attribut „männlich" und „HIV", die andere mit den Attributen „weiblich" und „HIV". Ein Hilfslevel hat einen „Namen", und mindestens eine „Beziehung", die beschreibt welche Felder in diesem Hilfslevel involviert sind. Ein Level selbst kann nicht Teil einer Abfrage sein, sondern die Felder, die zu diesem Hilfslevel gehören, können dies sein.

Die Kinder, die in den Primärelementen verwendet werden, sind:

– Name – ist der Name, der für dieses Element in dem Ausgabeschema 302 verwendet wird.
– Abbildungstabelle – ist der Name der Tabelle, auf welche diese Einheit abbildet, oder wo dieses Feld lokalisiert ist.
– Abbildungsfeld – ist das Feld in der „Abbildungstabelle", auf die dieses Feld abbildet.
– IstErweiterungsfeld – gibt an, ob dieses Feld Teil der „Abbildungstabelle" selbst ist oder ihre Erweiterungstabelle.
– IstSuchbar – gibt an, ob dieses Feld in die reguläre Ausdruckssuche (RegExp) integriert werden soll oder nicht.
– Beziehung – wird verwendet in einem Hilfslevel und beschreibt ein Feld als Teil des Hilfslevels. Die Beziehung enthält einen „Namen", „Abbildungstabelle", „Abbildungsfeld", „IstErweiterungsfeld".

Genauer Bezug nehmend auf ein Abfrageschema 310 kann eine Anwendung mehrere Abfragen starten, um Daten von der Datenabstraktionsschicht 204 abzufragen. Die jeweiligen Abfragen werden in einer XML-Datei ausgedrückt, die konform ist zu dem Abfrageschema 310. Eine Abfrage XML-Datei kann eine Abfrage zu einem Zeitpunkt enthalten. Das Ergebnis jeder Abfrage wird gemäß dem Ausgabemodell formatiert, wie durch ein Ausgabeschema 302 definiert, betreffend die Abfragetiefe und Einschränkungen. Die Abfrage kann in einer Standardabfragesprache definiert sein, wie beispielsweise SQL oder XQuery. In dieser Weise wird eine weit verbreitete Sprache verwendet, und ein Abfrager muss nicht eine neue Abfragesprache lernen. Es ist möglich, dass nicht alle möglichen Operatoren und Abfragelemente einer bestimmten Abfragesprache durch die Datenabstraktionsschicht 204 unterstützt werden. In einem derartigen Fall kann ein eingeschränkter Nebensatz von anwendbaren Abfrageoperationen und Beziehungen definiert werden. Die Abfragesprache selbst ist die Datenbank unabhängige Art und Weise zum Beschreiben einer Abfrage. Jede Abfrage wird von der Datenabstraktionsschicht 204 geparst gemäß der gegenwärtig verwendeten Datenbank in dem Lager 20.
Genauer Bezug nehmend auf ein Ressource-Schema 312, sind mögliche Datenquellen, auf die die Datenabstraktionsschicht 204 oder der Abfrager zugreifen kann, um Daten zu holen, in dem Ressource-Schema 312 definiert. Eine bestimmte Ressource wird spezifiziert durch ihren Typ und ihre aktuelle Verbindungsinformation. Der Typ beschreibt die Art und Weise der Datenquelle, beispielsweise „PACS". Es kann eine oder mehrere Instanzen eines Typs geben. Jede Instanz beschreibt eine tatsächliche Verbindung zu einer Datenquelle von diesem Typ. In dem Ressource-Schema 312 werden die möglichen Typen definiert. Eine Ressource-XML-Datei 313, die zu dem Ressource-Schema 312 gehört, ist wie folgt:
4 zeigt ein Flussdiagramm, das die Operation eines Systems verdeutlicht zur adaptiven Abfrage eines Datenspeicherlagers gemäß Prinzipien der vorliegenden Erfindung. Gleichzeitig Bezug nehmend auf die 2 und 3 und 4 werden XML-Formatabfragedaten 202 von der Datenabstraktionskomponente 204 empfangen. Vor dem Betrieb des Systems, wie in 4 gezeigt, müssen das Schema und die Dateien, wie in 3 gezeigt, bestückt und verifiziert werden.
5 zeigt ein Beispiel eines Kernschemas, 6 zeigt ein Beispiel eines Ausgabeschemas, 7 zeigt ein Beispiel einer Abbildungsdatei, 8 zeigt ein Beispiel einer Abfragedatei, und 9 zeigt ein Beispiel einer Ausgabedatei. Diese Dateien sind hilfreich für das Verständnis des Betriebs des Systems, wie in 4 gezeigt. Eine detailliertere Beschreibung dieser Schemen und Dateien, und detailliertere Beispiele davon sind im Anhang gegeben.
Wie in 5 gezeigt, definiert ein Kernschema 304 eine Mehrzahl von Datenelementen, die für Abfrager verfügbar gemacht werden. Die Datenelemente sind definiert durch Namen und Datentyp. Beispielsweise hat ein erstes Datenelement 502 den Namen „PatientID" und einen Typ von „String"; ein zweites Datenelement 504 hat einen Namen „Patientname" und einen Typ von „String"; usw.
Wie in 6 gezeigt definiert das Ausgabeschema 302 eine Mehrzahl von Leveln des Berichtens, in denen Datenelemente, die in dem Kernschema 304 definiert sind, angeordnet werden können. Wie oben beschrieben enthält das Ausgabeschema 302 das Kernschema 304 (5), um Zugriff auf die Datenelemente zu haben, die in dem Kernschema 304 definiert sind. Ein Einfügungselement 601 liefert die Referenz zu dem Kernschema 304, spezifiziert durch den Dateinamen „CoreSchema1.xsd".
In 6 hat ein erster Level den Namen „Study" 602, und enthält Datenelemente „StudyName" 604 und „StudyModality" 606. Ein zweiter Level hat den Namen „Experiment" 608 und enthält die Datenelemente „ExperimentID" 610 und „ExperimentDescription" 612, und enthält ferner Null oder mehrere Ergebnisse des „Study"-Levels 614. Ein dritter Level hat den Namen „Patient" 616 und enthält die Datenelemente „PatientID" 618, „Patientname" 620, „PatientGender" 622 und „PatientDisease" 624, und enthält ferner Null oder mehrere Ergebnisse des „Experiment"-Levels 626. Die tatsächliche Ausgabedatei, die definiert wird durch das Ausgabeschema 302 von 6, hat den Namen „Output" 628 und enthält Null oder mehrere Ergebnisse des „Patient"-Levels 630.
7 zeigt ein Beispiel einer Abbildungsdatei 309. Die Abbildungsdatei enthält [Entity] Einträge 702 und [Field Entries] 704. Wie genauer im Anhang beschrieben, definieren die [Entity] Einträge 702 eine Tabelle, die für den Abfrager verfügbar ist, und die Feldeinträge 704 definieren Felder in der Tabelle. Die Einträge in der Abbildungsdatei 309 liefern eine Korrespondenz zwischen den Namen der Tabellen und der Felder, die von dem Abfrager verwendet werden, und denjenigen, die durch das Lager 20 (1) verwendet werden. In 7 hat ein erster [Entity] Eintrag 706 den Namen „Patient", was der Name ist, der verwendet wird von dem Abfrager. Zu diesem Namen gehört eine Abbildungstabelle „Projekt" 708, was der Name ist, der von dem Lager 20 verwendet wird. Weitere Einträge definieren Felder. Ein erstes Feld hat einen Namen „PatientID" 710, was der gleiche Name ist, der von dem Abfrager verwendet wird. Das „PatientID"-Feld ist in der Abbildungstabelle mit dem Namen „Projekt" 712 und das Feld in der „Projekt"-Tabelle, das dem „PatientID"-Feld entspricht, hat den Namen „Id" 714. Andere Einheiten und Felder sind in der Abbildungsdatei 309 in ähnlicher Art und Weise definiert.
Mit dem Kernschema 304, dem Ausgabeschema 302 und der definierten Abbildungsdatei 309 arbeitet das adaptive Abfragesystem wie in 4 gezeigt. Abfragedaten werden in Schritt 402 empfangen. Die Abfragedaten sind in der Form einer XML-Datei, die gemäß dem Abfrageschema 310 (3) gebildet wird. Das Abfrageschema 310 ist im Anhang verdeutlicht und definiert die Struktur der Abfragedatei. Wie eine derartige Abfragedatei gemäß einem Abfrageschema zu konstruieren ist, ist dem Fachmann bekannt, und ist für die vorliegende Erfindung nicht relevant, und wird hier nicht im Einzelnen beschrieben.
8 verdeutlicht eine derartige Abfragedatei. In 8 sind Sortierkriterien 802 und Suchparameter 804 definiert. In 8 sind die Sortierkriterien 802 derart, dass zuerst nach dem Datenfeld „Patientname" in absteigender Reihenfolge 806 sortiert wird, und dann das Datenfeld „PatientID" in aufsteigender Reihenfolge 808 sortiert wird. Ein erstes Suchkriterium ist das Auswählen derjenigen Datensätzen, für die das „Patientname"-Datenfeld mit dem Buchstaben „B" beginnt, und weiterhin (810) und (812) für die das „PatientDisease"-Datenfeld „HIV" ist.
In Schritt 402 wird Ausgabeschema 302 (6) ausgewählt, das der Abfragedatei (8) entspricht, die von der Datenabstraktionskomponente 204 empfangen wird, und liefert Daten in einem Format, das von dem Abfrager gewünscht ist. Dieses Ausgabeschema 302 wird verwendet zum Steuern des Formatierens der Daten, die an den Abfrager zurückgegeben werden. In Schritt 404 werden die Inhalte der Abfragedatei gegenüber dem Abfrage-XML-Schema 310 (siehe Anhang) validiert, um zu verifizieren, dass sie in dem geeigneten Format, das korrekt verarbeitet wird, sind. Die Inhalte der Abfragedatei werden weiter gegenüber dem Kernschema 304 (5) validiert, gegenüber den Erweiterungsschemen 306 (in diesem Beispiel nicht verwendet) und dem Ausgabeschema 302 (6), um zu verifizieren, dass es Datenelemente abfrägt, die für einen Zugriff verfügbar sind. Wenn sie korrekt validiert wird, kann die Abfragedatei geparst werden, um Datenelemente zu extrahieren, die als verfügbar angesehen werden durch das Kernschema 304 und Erweiterungsschema 306 in dem Bereich 303 der Anwendung. In Schritt 406, wenn die empfangene XML-Abfragedatendatei korrekt verifiziert worden ist, dann geht die Verarbeitung weiter in Schritt 410, ansonsten wird der Fehler dem Abfrager 408 mitgeteilt.
In Schritt 410 wird auf die Daten in der Abbildungsdatei 309 (7), die gemäß dem Abbildungsschema 308 (3) konstruiert worden ist, zugegriffen, um eine zweite Abfrage zu erzeugen, um Datenelemente aus einer ersten Speicherdatenstruktur in dem Lager 20 zu holen. Wie oben beschrieben bestimmt diese Abbildungsdatei 309 die Namen und die Orte der gespeicherten Datenelemente in dem Speicher 20 (1), entsprechend den Datenelementen, die in dem Informationsmodell 305 definiert und von der Abfrage 202 angefordert werden (2). Die Tabellen und Feldnamen, die den Datenelementen entsprechen, die von dem Abfrager angefordert werden, werden also aus der Abbildungsdatei 309 hergeleitet. Eine zweite Abfrage wird erzeugt, um die angeforderten Daten aus dem Datenspeicher 20 zu holen. Wie ebenfalls oben bereits beschrieben, ist die zweite Abfrage in einem Format, das zu dem Lager 20 kompatibel ist, beispielsweise SQL oder Xquery.
Obwohl nicht in dem vorliegendem Beispiel gezeigt, greift die Datenabstraktionskomponente 204 (2) weiter auf Daten in der Ressourcedatei 313 (3) zu, um zu bestimmen, ob angeforderte Daten in einer externen Datenquelle (nicht gezeigt) existieren. Wenn dem so ist, dann können die Daten von der Ressourcedatei 313 von der Datenabstraktionskomponente 204 verwendet werden, um eine Abfrage der externen Datenquelle in einem Format zu erzeugen, das kompatibel ist mit der Datenquellen, um die angeforderten Daten aus der externen Datenquelle zu holen. Alternativ können die Daten an den Abfrager zurückgegeben werden, wodurch es dem Abfrager ermöglicht wird auf die externe Datenquelle zuzugreifen, um die angeforderten Daten zu holen.
Die Datenelemente, die aus dem Speicher 20 geholt werden, sind typischerweise in einem anderen Format als die von der ersten Abfrage angeforderten. In Schritt 412, wenn die angeforderten Daten aus dem Speicher 20 geholt worden sind (also von einer Datenbank und/oder externen Datenquelle), greift die Datenabstraktionskomponente 204 (2) auf Daten in dem Ausgabeschema zu und verwendet diese Daten, um die Daten, die aus dem Lager 20 (1) erfasst worden sind in ein Format zu formatieren, das kompatibel ist mit der entsprechenden ersten Abfragenachricht. In dem vorliegenden Beispiel wird das Ausgabeschema 302 (6) verwendet, um die aus dem Lager 20 geholten Daten zu formatieren.
In 9 enthält eine Ausgabedatei, die gemäß dem Ausgabeschema 302 (6) formatiert ist, Ergebnisse für drei Patienten 902, 904 und 906. Die Daten für die Patienten enthalten „PatientID" 908, „Patientname" 910, „PatientGender" 912 und „PatientDisease" 914 Datenfelder, wie durch die Patientenschicht 616 definiert. Für den ersten Patienten 902 enthalten diese Daten „123", „Bright", „Male" und „HIV". Wie in der Abfragedatei (8) spezifiziert werden die Patienten mit Namen beginnend mit „B" oder größer (810) und (812) mit der Krankheit „HIV" 814 aufgelistet. Die Patientendaten 902, 904, 906 enthalten ferner Experimentdaten. Für den Patienten 902 werden Daten über zwei Experimente 916 und 918 zurückgegeben. Beispielsweise enthält das Experiment 916 die „ExperimentID" 920 und „ExperimentDescription" 922 Datenfelder, wie definiert wird durch die Experimentschicht 608 (6). Keine Studien wurde diesen Experimenten zugeordnet. Wenn dies erfolgt wäre, dann wären die Datenfelder, die zu diesen Studien gehören, wie durch die Studienschicht 602 definiert, in die Ausgabedatei eingefügt worden, innerhalb der zugehörigen Experimentauflistung.
In Schritt 414 werden die geholten Daten (9) in dem Ausgabeformat, das von der ersten Abfrage angefordert worden ist, an den Abfrager zurückgeben.
In einem System, wie in 1 gezeigt, können Änderungen in das adaptive Abfragesystem eingebracht werden durch Ändern der Schemen (302–312 von 3) und der entsprechenden Dateien (309, 313), ohne ein Neuübersetzen und/oder Neutesten des ausführbaren Codes von entweder der anfragenden ausführbaren Anwendung oder der Datenabstraktionskomponente 214, die verwendet wird, um die Aktivitäten durchzuführen. Derartige Änderungen umfassen: (a) Hinzufügen oder Ändern von Datenelementen, die an den Abfrager zurückgegeben werden; (b) Ändern der Beziehung zwischen den Datenelementen, die an den Abfrager zurückgegeben werden, (c) Ändern der Datenelemente und/oder der Beziehung von Datenelementen in dem Lager 20; (d) Ändern des Lagers 20; und/oder (e) irgendwelche anderen Änderungen, die das Speichern und das Holen von Daten in Antwort auf Abfragen von ausführbaren Anwendungen und Komponenten oder Clients betreffen.
Anhang
Beispiele für XML und XML-Schemadateien
Das folgende Beispiel beschreibt mögliche Szenarien und beispielhafte XML-Dateien und XML-Schemadateien. Die Datenbank, auf der die Beispiele basieren, ist durch die folgenden drei Tabellen in der gegebenen Hierarchie gebildet:
Gemeinsame Schemen für die Beispiele
Die folgenden XML-Schemen beschreiben die Syntax für die Abbildungsdatei, die Abfragedatei und Ressourcen-Datei. Diese Schemen sind unabhängig von irgendwelchen bestimmten Implementierung und existieren in.
Abbildungsschema
Diese Datei beschreibt eine Abbildungsdatei, die die Datenelemente, wie sie von einer Client ausführbaren Anwendung verwendet werden, auf die Datenelemente abbildet, wie sie tatsächlich in einer Speicherdatenbank implementiert sind.
Abfrageschema
Dieses Schema beschreibt eine Abfragedatei (die tatsächliche Abfrage).
Beispiel 1
In diesem Verwendungsbeispiel wird die Hierarchie, die durch die Datenbank gegeben wird, aufrechterhalten. Die Datenfelder und eine Tabelle werden umbenannt. Das Clientdatenmodell ist:
Kernschema

Ausgabeschema:

Abbildungsdatei

Abfragedatei

Beispielausgabe für eine Abfrage
Beispiel 2
Dieses Beispiel basiert auf den Dateien, die in dem obigen Beispiel 1 beschrieben worden sind. In diesem Fall wird die Ausgabehierarchie geändert. Um dies zu machen, wird das Ausgabeschema geändert. Der Rest bleibt der gleiche. Die neue Hierarchie ist: Experiment
Ausgabeschema

Beispielergebnis
Ressource-Schema, Ressource-Datei und Erweiterungsschema
Erweiterungsschema
Ein Erweiterungsschema ist ähnlich zu einem Kernschema. Es wird verwendet, um existierende Kernschemen zu erweitern, um spezifische Bedürfnisse einer ausführbaren Clientanwen dung oder von Komponenten zu erfüllen, wenn das gleiche Kernschema von mehreren Clients gemeinsam verwendet wird. Die Erweiterungsschemen sind optional.
Ressource-Schema
Ein anderes Ressource-Schema wird für jeweilige Implementierungen definiert. Das Ressource-Schema definiert den Inhalt und die Struktur einer Ressourcen-Datei, welche Typen von Ressourcen verfügbar sind. Das folgende Ressource-Schema ist Beispiel für einen Client, der PACS und Biochip-Ressourcen verwendet.
Ressource-Datei
Eine Ressource-Datei ist eine konkrete Instanz, die Ressourcen beschreibt, die in einem System verwendet werden. Sie gehört zu dem Ressource-Schema, wie oben beispielhaft gezeigt.
Beispiel:
Zusammenfassung
Ein Eingabeprozessor empfängt eine Mehrzahl von unterschiedlichen ersten Abfragenachrichten in einer entsprechenden Mehrzahl von unterschiedlichen Formaten. Ein Lager enthält gespeicherte Datenelemente in einer ersten Speicherdatenstruktur. Ein Vermittlerprozessor parst automatisch die Mehrzahl von ersten Abfragenachrichten zum Identifizieren von angeforderten Datenelementen; bildet automatisch die identifizierten angeforderten Datenelemente auf gespeicherte Datenelemente in der ersten Speicherdatenstruktur des Lagers ab; erzeugt automatisch eine Mehrzahl von zweiten Abfolgenachrichten in einem Format, das kompatibel ist zu dem Lager zur Erfassung der gespeicherten Datenelemente; erfasst automatisch die gespeicherten Datenelemente aus dem Lager unter Verwendung der erzeugten Mehrzahl von zweiten Abfragenachrichten; und verarbeitet automatisch die gespeicherten Datenelemente, die in Antwort auf die Mehrzahl von zweiten Abfragenachrichten erfasst werden, zur Ausgabe in einem Format, das kompatibel ist zu der entsprechenden Mehrzahl von unterschiedlichen Formaten der ersten Abfragenachrichten.

Claims

System zum adaptiven Abfragen eines Datenspeicherlagers, mit einem Eingabeprozessor zum Empfangen einer Mehrzahl von unterschiedlichen ersten Abfragenachrichten in einer entsprechenden Mehrzahl von unterschiedlichen Formaten; einem Lager von gespeicherten Datenelementen in einer ersten Speicherdatenstruktur; und einem Vermittlerprozessor zum automatischen Durchführen der Aktivitäten von: Parsen der Mehrzahl von ersten Abfragenachrichten, zum Identifizieren von angeforderten Datenelementen, Abbilden der identifizierten angeforderten Datenelemente auf gespeicherten Datenelementen in der ersten Speicherdatenstruktur des Lagers, Erzeugen einer Mehrzahl von zweiten Abfragenachrichten in einem Format, das kompatibel ist zu dem Lager zur Erfassung der gespeicherten Datenelemente, Erfassen der gespeicherten Datenelemente aus dem Lager unter Verwendung der erzeugten Mehrzahl von zweiten Abfragenachrichten, und Verarbeiten der gespeicherten Datenelemente, die in Antwort auf die Mehrzahl von zweiten Abfragenachrichten erfasst werden, zur Ausgabe in einem Format, das kompatibel ist zu der entsprechenden Mehrzahl von unterschiedlichen Formaten der ersten Abfragenachrichten.
System nach Anspruch 1, wobei der Vermittlerprozessor automatisch die Aktivitäten durchführt, indem Information, die die Aktivitäten in mindestens einer Datei betrifft, die die Daten aufweist, die Einzelheiten betreffend der Durchführung der Aktivitäten betreffen, ausgedrückt wird.
System nach Anspruch 2, wobei die mindestens eine Datei eine Kernschemadatei aufweist, die Daten enthält, die die angeforderten Datenelemente definieren.
System nach Anspruch 3, wobei die Kernschemadatei Daten aufweist, die jeweilige Namen von den angeforderten Datenelementen definieren.
System nach Anspruch 3, wobei die mindestens eine Datei eine Erweiterungsschemadatei aufweist, die Daten enthält, die weitere angeforderte Datenelemente definieren.
System nach Anspruch 5, wobei die Erweiterungsschemadatei Daten aufweist, die jeweilige Namen der angeforderten Datenelemente definieren.
System nach Anspruch 2, wobei die mindestens eine Datei eine Ausgabeschemadatei aufweist, die Daten enthält, die jeweilige Beziehungen unter den angeforderten Datenelementen spezifizieren.
System nach Anspruch 2, wobei die Ausgabeschemadatei Daten aufweist, die eine Ausgabehierarchie definieren.
System nach Anspruch 8, wobei die Ausgabeschemadatei Daten aufweist, die angeforderte Datenelemente definieren.
System nach Anspruch 9, wobei die Ausgabeschemadatei Daten aufweist, die Level definieren, wobei die Level definierenden Daten, Daten enthalten, die angeforderte Datenelemente definieren, und Daten, die angeforderte Daten definieren, die in anderen Leveln definiert sind.
System nach Anspruch 2, wobei die mindestens eine Datei eine Abbildungsdatei aufweist, die Daten enthält, die die Korrespondenz unter angeforderten Datenelementen und Datenelementen in der Speicherdatenstruktur in dem Lager spezifizieren.
System nach Anspruch 11, wobei die Abbildungsdatei Daten aufweist, die ein angefordertes Datenelement in Bezug setzen zu einer Tabelle in der Speicherdatenstruktur in dem Speicher, und Daten, die das angeforderte Datenelement zu einem Feld in der Tabelle in der Speicherdatenstruktur in dem Lager in Bezug setzen.
System nach Anspruch 2, wobei die mindestens eine Datei eine Ressource-Datei aufweist, die Daten enthält, die externe Datenquellen in dem Lager spezifizieren.
System nach Anspruch 13, wobei die Ressource-Datei Daten aufweist für einen Zugriff auf die externe Quelle.
System nach Anspruch 14, wobei die Daten zum Zugreifen auf die externe Quelle in einem Format ausgegeben werden, das kompatibel ist zu der entsprechenden Mehrzahl von unterschiedlichen Formaten der ersten Abfragenachrichten.
System nach Anspruch 2, wobei die mindestens eine Datei eine Abfrageschemadatei aufweist, die Daten enthält, die den jeweiligen Inhalt und die Struktur der ersten Abfragenachrichten definieren.
System nach Anspruch 16, wobei die mindestens eine Datei eine Abfragedatei aufweist, die Daten enthält, die die ersten Abfragenachrichten definieren.
System nach Anspruch 1, wobei der Vermittlerprozessor automatisch die Aktivitäten durchführt ohne Neuübersetzen von ausführbarem Code, der bei der Durchführung der Aktivitäten verwendet wird.
System nach Anspruch 1, wobei der Vermittlerprozessor automatisch die Aktivitäten durchführt ohne Neutesten von ausführbarem Code, der verwendet wird zur Durchführung der Aktivitäten.
System nach Anspruch 1, wobei die ersten Abfragenachrichten Abfragedateien aufweisen, die konform sind zu einem Abfrageschema; und die zweiten Abfragenachrichten Abfragen enthalten, die von einem Lager ausführbar sind.
System nach Anspruch 1, wobei die ersten Abfragenachrichten in einem Format sind, das durch ein Abfrageschema bestimmt ist und mindestens ein Format von a), einen SQL kompatiblen Abfrageformat oder b), einen XQuery kompatiblen Abfrageformat aufweist.
System nach Anspruch 7, wobei das Abfrageschema mindestens a) eine Abfragesuchtiefe von hierarchischen Datenelementen in dem Lager und/oder b) Einschränkungen beim Absuchen des Lagers aufweist.
System nach Anspruch 1, wobei das Format, das kompatibel ist mit der entsprechenden Mehrzahl von unterschiedlichen Formaten der ersten Abfragenachrichten durch ein Ausgabeschema bestimmt wird.
System nach Anspruch 1, ferner mit Daten, die ein Kernschema bestimmen, das Datenfelder angibt, die in der ersten Speicherdatenstruktur in dem Speicher von gespeicherten Datenelementen zugreifbar sind.
System nach Anspruch 1, ferner mit einem Abbildungsschema, das das Abbilden der identifizierten angeforderten Datenelemente auf gespeicherte Datenelemente in der ersten Speicherdatenstruktur des Lagers bestimmt.
System zum adaptiven Abfragen eines Datenspeicherlagers mit einem Eingabeprozessor zum Empfangen von mindestens einer ersten Abfragenachricht, die eine Anfrage nach Information und eine Anweisung, die ein Datenformat zur Bereitstellung der Information enthält, aufweist, wobei die Anweisung änderbar ist, um die Information und das Datenformat zur Bereitstellung der Information adaptiv zu ändern; einem Lager von gespeicherten Datenelementen in einer ersten Speicherdatenstruktur; und einem Vermittlerprozessor zur automatischen Durchführung der Aktivitäten von: Parsen der mindestens einen ersten Abfragenachricht, um angeforderte Datenelemente zu identifizieren, Abbilden der identifizierten angeforderten Datenelemente auf gespeicherte Datenelemente in der ersten Speicherdatenstruktur des Lagers, Erzeugen von mindestens einer zweiten Abfragenachricht in einem Format, das kompatibel ist zu dem Lager zur Erfassung der gespeicherten Datenelemente, Erfassen der gespeicherten Datenelemente aus dem Lager unter Verwendung der erzeugten mindestens zweiten Abfragenachrichten, und Verarbeiten der gespeicherten Datenelemente, die in Antwort auf die mindestens eine zweite Abfragenachricht erfasst worden sind, zur Ausgabe in einem Format, das kompatibel ist mit dem Datenformat, das durch die Anweisung in der mindestens einen ersten Abfragenachricht bestimmt ist.
System nach Anspruch 10, wobei die Anweisung, die das Datenformat zur Bereitstellung der Information bestimmt, ein Markup-Sprachausgabeschema enthält.
System nach Anspruch 10, wobei das Markup-Sprachausgabeschema ein XML-Schema ist.