CH712619B1 - Verfahren für einen bio-molekularen Retrieval-Engine. - Google Patents

Abstract

Vorgeschlagen wird ein Verfahren für einen bio-molekularen Retrieval-Engine zum Suchen, Selektieren und interaktiven Analysieren komplexer Strukturen in heterogenen Speichersystemen und/oder Datenbanken mit dem bio-molekularen Retrieval-Engine mittels entsprechenden Drill-down und Roll-up Operationen, wobei die Speichersysteme und Datenbanken der heterogenen Speichersysteme und/oder Datenbanken nach bio-molekularen 3D-Strukturen und Verbindungen mit bestimmten Eigenschaften gefiltert werden. Beim Ladeprozess (2) von Daten-Files verschiedener selektierter Datenbank (1) in den bio-molekularen Retrieval-Engine werden die einzelnen Zeilen der Daten-Files indexiert (4). Der Inhalt der Daten-Files aller selektierten Datenbanken (1) wird parallel in eine Staging-Tabelle eines Daten Warenhauses (5) mittels des bio-molekularen Retrieval-Engines geladen. Mittels des bio-molekularen Retrieval-Engines werden durch Benutzer auf die in der Staging-Tabelle gespeicherten Daten Such- Operationen ausgeführt, wobei für jede Such-Operation der Such-Operation entsprechende Daten neu gefiltert werden und die jeweiligen erhaltenen Subsets von Daten in zusätzliche, dynamisch erstellte Tabellen gespeichert werden. Die Daten aus der Staging-Tabelle und den zusätzlichen Tabellen werden abfragespezifisch in dimensionale Modelle abgebildet, welche in Datamarts gespeichert werden. Die Datamarts werden innerhalb des Daten Warenhauses (5) als spezifische, individuell gesicherte Workspaces mit definierten, eigenen Zugriffsrechten erstellt. Mittels eines interaktiven Front-End-Tools (6) werden die entsprechenden Drill-down-Operationen und/oder Roll-up-Operationen auf die Datamarts des Daten Warenhauses (5) generiert werden.

Description

Technisches Gebiet

[0001] Die vorliegende Anmeldung betrifft ein Verfahren zum Auffinden und Vergleichen komplexer Strukturen in digitalen Datensätzen in heterogenen Speichersystemen, wie relationale/nicht-relationale Datenbanken oder Graphendatenbanken, mit heterogenen Informationsverwaltungsstrategien, insbesondere ein Verfahren und ein Verfahren für ein System zur Bereitstellung von Lösungen für die Handhabung von räumlichen, biologischen Strukturen zugreifbar in heterogenen, relationalen und/oder skalierbarer Datensammlung, ihrer Modulierung und ihres Zugriffes. Insbesondere betrifft die Erfindung die Bereitstellung eines Verfahrens für ein bio-molekularer Retrieval-Engine und eines intelligenten, interaktiven, dynamischen (REI<2>VA) Visualisierungsverfahren, und entsprechenden Human Maschine Interfaces für Strukturen gespeichert in umfangreichen Datensätze heterogener Speichersysteme, relationale/nicht-relationale Datenbanken, und/oder Graphendatenbanken, beispielsweise in einer Cloud.

Stand der Technik

[0002] Beim Abrufen, Verwalten, Vergleichen und dem automatischen Analysieren von Informationen in Zusammenhang mit komplexen Strukturen, insbesondere in Zusammenhang mit komplexen, räumlichen Strukturen wie räumliche, biologische Strukturen, zeigen sich in der Regel zahlreiche technische Probleme in Verbindung mit Datenintegration und -interpretation, insbesondere wenn die Daten aus mehreren heterogenen Quellen stammen. Zum Beispiel entstehen häufig Schwierigkeiten beim Versuch, große Datenmengen heterogener Datenbanken und Datenverwaltungsstrukturen z.B. zur Benutzervisualisierung in Bezug auf komplexe Strukturen gemeinsam zu analysieren. Zusätzlich zeigen sich bei der Integration von komplexen Informationen von einer oder mehreren Quellen, die insbesondere so konfiguriert sein können, dass sie Echtzeitdaten mit anderen gewünschten Informationen bereitstellen, Probleme mit Zugänglichkeit, Bandbreite und Latenz, wodurch die Flexibilität, Skalierbarkeit und Zugreifbarkeit dieser Systeme als Ganzes oder auf Teile davon beschränkt in Frage gestellt wird.

[0003] Von herkömmlichen Systemen, die mit der Überwachung und Steuerung verschiedener Betriebsparameter für die Abfrage komplexer Komponenten und Subkomponenten von gespeicherten Strukturen, insbesondere räumlichen Strukturen, assoziiert sind, kann gefordert werden, grosse Mengen an Daten in Echtzeit und/oder Nahezu-Echtzeit zu verarbeiten und/oder zu analysieren, wie es z. B. der Fall ist bei kontinuierlichem Monitoring von chronisch kranken Patienten und/oder solche mit seltenen Krankheiten. Werden die Daten selbst in Echtzeit erfasst, werden sie auch als Punktdaten bezeichnet. Die Daten können aus unabhängigen, heterogenen Quellen stammen, wobei jede Quelle so konfiguriert ist, dass sie in spezifischen Strukturen bereits verarbeitete oder auch rohe oder native Informationen bereitstellt, wie zum Beispiel numerische Werte, die verschiedenen Mess-/Überwachungsvorrichtungsmesswerten zugeordnet sind. Alleine genommen liefern diese Daten möglicherweise keinen einheitlichen Kontext für ihre Interpretation und es müssen ihnen zusätzliche Informationen zugeordnet werden, um eine sinnvolle Verarbeitung und Analyse zu gestatten. Ausserdem kann es wünschenswert sein, die Daten dieser heterogenen Datenquellen zu erfassen, zu speichern und zu anderen Verarbeitungskomponenten zu verteilen, so dass diesen Daten komplexer Strukturen ein gewisses Mass an Kontext zugeschrieben werden muss.

[0004] Eine bei vielen herkömmlichen Systemen gefundene Beschränkung besteht darin, dass sie nur beschränkte Fähigkeiten für den Zugriff, die Interpretation und/oder Manipulation von auf der Erfassung komplexer räumlicher Strukturen basierenden Daten kollektiv oder in Verbindung mit anderen derartigen Daten bereitstellen. Diese Fähigkeiten betreffen insbesondere die Kategorie von mit den Daten assoziierten Kontextbereitstellungsinformationen, die in einer Hinsicht die Funktionalität und Bedeutung der Daten für komplexe Strukturen erweitern können. Zu Kontextbereitstellungsinformationen können zum Beispiel deskriptive und/oder Attributinformationen gehören, die die Daten charakterisieren, sowie andere Informationen. Bei herkömmlichen Systemen ist die integrale und flexible Manipulation von auf der Erfassung von räumlichen komplexen Strukturen basierenden aufgrund der naturgemässen Unterschiede und Eigenschaften der Datenquellen eingeschränkt. So können aktuelle Lösungen im Bereich der Molekularbiologie insbesondere auch keine interaktiven, dynamischen Drill-Down und Roll-Up im Bereich von sehr grossen Datenmengen und komplexen Abfragen bieten. Insbesondere auch die Erfassung und direkte Verknüpfung von in Vivo erfassten präklinischen oder klinischen Labordaten mit biomolekularen Daten und Strukturen der verschiedensten „-omics“ Welten und/oder Biopsyen ist im Stand der Technik unmöglich.

[0005] Systeme, welchen einen einheitlichen Zugriff auf gespeicherte, komplexe räumliche Strukturen erlauben, sind insbesondere bei der Entwicklung von neuen Medikamenten entscheidend, da dort nach aktiven Bindungsstellen gesucht werden muss. Herkömmliche Werkzeuge sind jedoch nur für statische Oberflächen geeignet. Notwendig sind Abfrage- und Retrieval Engines gekoppelt mit interaktive, explorative Interfaces, um räumliche biologische Strukturen nach verschiedensten Kriterien zu finden und zu analysieren. Im Stand der Technik ist die Research Collaboratory for Structural Bioinformatics (RCSB) Protein Data Bank (PDB) eine derartige Datenbank zur Erfassung komplexer, biologischer, makromolekularer, räumlicher Strukturen (vgl. www.rcsb.org/pdb/home/home.do), welche sämtliche aufgelöste, bekannte Strukturen als Text-Files sammelt, archiviert und zugreifbar bereitstellt. D.h. die pdb-Text-Files enthalten Informationen über die 3D-Struktur von grossen biologischen Molekülen, einschliesslich Proteinen und Nukleinsäuren. Dies sind die Moleküle, die in allen lebenden Organismen einschliesslich Bakterien, Hefen, Pflanzen, Insekten, oder anderen Tieren, insbesondere dem Menschen, gefunden werden. Basierend auf dem Verständnis der Struktur und Form dieser Moleküle, lässt sich ihre strukturelle Rolle bei der menschlichen Gesundheit und Krankheit herleiten, und zur Medikamentenentwicklung und/oder verschreiben von Therapien nutzen. Die Daten und gespeicherten Strukturen in der pdb-Datenbank von winzigen Proteinen und Teilen von DNA (Desoxyribonukleinsäure) bis zu grossen, komplexen, räumlichen Strukturen wie Ribosomen als makromolekulare Komplexe aus Proteinen und Ribonukleinsäuren (RNA), die im Cytoplasma, in den Mitochondrien und in den Chloroplasten vorkommen. Zugriff, Vergleich und Analyse dieser Strukturen sind deshalb in vielen Bereichen der Technik grundlegend, insbesondere in der Biomedizin und Agrotechnik und -Entwicklung von der Proteinsynthese bis zur Entwicklung von Medikamenten und Functional Food (funktionale Lebensmittel).

[0006] Die Daten-Textfiles, kurz pdb-Files oder pdb-Strukturen, sind jedoch für End-Benutzer von sehr kleinem Nutzen, wenn es um Data Mining (intelligente Datenanalyse) oder Data Analyse oder Vorhersage im erweiterten Sinn geht. Ebenfalls ist das Verbinden der Daten aus den pdb-Daten-Files mit anderen Datenbanken, wie z.B. den Swissprot-Datenfiles, insbesondere relationalen Datenbanken, Graphendatenbanken, heterogene Speichersysteme und Speicherformate der Daten und/oder der dazugehörigen Applikationen/Programme, Ontologien und Taxomien, schwierig bis unmöglich, um aus den komplexen Daten vergleichbare, räumliche Informationen zu extrahieren. Im Stand der Technik müssen für dieses Vorhaben Benutzer auf jedes File, unabhängig von der Datenquelle, endlose, langwierige, kostspielige, repetitive und zeitintensive Operationen ausführen und selber ein Aufzeichnungssystem entwickeln, um die jeweiligen Zwischenergebnisse festzuhalten. Selbst wenn eine mögliche pdb-Organisation Möglichkeiten anbietet, das Suchfeld nach gewissen Kriterien einzuschränken, bleibt dem Benutzer die File-pro-File Suche (mehr als 113'000 Textfiles und über 1,2 Milliarden Zeilen, Stand Mai 2016 und mehr als 530'000 Proteine aus Swissprot, Tendenz stetig steigend) nicht erspart. Dass damit (i) eine jegliche Anbindung an anderen heterogene Datenquellen, wie eben z.B. Swissprot, (ii) ein Vergleich der Daten im grossen Umfang oder hoher Komplexität, (iii) ein Ausführen von komplexen Queries auf die umfangreichen Datensätze, oder (iv) eine kontrollierte, homogene Anreicherung der Daten faktisch unmöglich ist, ist für den Fachmann bei dieser Ausganglage offensichtlich.

Technische Aufgabe

[0007] Es ist Aufgabe der Erfindung, eine technische Lösung bereit zu stellen, die die oben diskutierten Nachteile nicht aufweist. Insbesondere besteht die zu lösenden Aufgabe darin, für biologische Struktur- oder Sequenzdaten ein Verfahren und ein Verfahren für ein System und Such- und Analysevorrichtung bereitzustellen, welches eine datenbankübergreifende Analyse von grossen verteilten Datenbeständen, schnellere Ausführung, bessere Skalierbarkeit oder Replikation ermöglicht. Die Lösung soll dabei nicht nur unter Labortest funktionieren, sondern auch in der Praxis derartiger heterogener relationaler Datenbanken und Systeme anwendbar sein, wie z.B. auf Oracle Exadata entwickelten Systeme. (Oracle Exadata bzw. die Oracle Exadata Database Machine ist eine gegenseitig optimierte und gemeinsam entwickelte Software und Hardware, um hohe Performance und Verfügbarkeit bei der Ausführung von Oracle Databases zu erreichen. Zur Oracle Exadata Architektur gehören horizontal skalierte Server, typischerweise gemäss dem üblichen Industriestandard, und intelligente Storage Server mit moderner Flash-Technologie und internen InfiniBand-Hochgeschwindigkeitsleitungen. Oracle Exadata ermöglicht mittels elastischen Konfigurationen auf bestimmte Datenbank-Arbeitslasten zugeschnittene Systeme.) Die Lösung soll erlauben in einem sehr kurzen Zeitraum (real-time oder fast real-time), d.h. im Bereich von Sekunden bis wenigen Minuten, eine grosse Vielfalt von Hypothesen bei den gespeicherten räumlichen Strukturen zu überprüfen, und durch eine einfache Handhabung den Fokus auf das Wesentliche zu richten. Die Lösung soll zudem einfach übertragbar sein auf andere grosse verteilte Datenbestände, z.B. auf verteilte, günstige NoSQL-Datenbanken, sofern kein Anspruch auf absolute Sicherheit, absoluter Datenschutz erhoben wird, wobei die Operationen auf disjunkte Datensätze erfolgen, um zu verhindern, dass parallele oder sogar massiv parallele Prozesse von einigen wenigen Einzelausführungen blockiert werden und die gesamte Systemperformance in Frage stellen.

Zusammenfassung der Erfindung

[0008] Gemäss der vorliegenden Erfindung werden die obgenannten Aufgaben insbesondere durch die Anspruchsmerkmale der unabhängigen Ansprüche erreicht. Weitere vorteilhafte Ausführungsformen können durch die abhängigen Ansprüche und die Beschreibung erhalten werden.

[0009] Gemäss der vorliegenden Erfindung werden die obgenannten Aufgaben für ein Verfahren für einen bio-molekularer Retrieval-Engine zum Suchen, Selektieren und interaktiven Analysieren komplexer Strukturen in heterogenen Speichersystemen und Datenbanken insbesondere dadurch gelöst, dass mittels der vorliegenden Erfindung mit dem bio-molekularen Retrieval-Engine mittels entsprechenden Drill-down und Roll-up Operationen die heterogenen Speichersysteme und Datenbanken nach bio-molekularen 3D-Strukturen und Verbindungen mit bestimmten Eigenschaften gefiltert werden, dass beim Ladeprozess von Daten-Files einer selektierten Datenbank und/oder Datenquelle in den bio-molekularen Retrieval-Engine die einzelnen Zeilen der Daten-Files der Datenbank und/oder Datenquelle mittels einer eineindeutigen Nomenklatur indexiert werden, wobei mindestens Ladedatum und Ladezeit automatisch vergeben werden, dass dieselbe Indexierung auf die Daten-Files jeder weiteren selektierten und zu ladenden Datenbank und/oder Datenquelle angewendet wird, wobei alle selektierten Datenbanken und/oder Datenquellen die heterogenen Speichersysteme und/oder Datenbanken umfassen und die Indexierung als Primärschlüssel verwendet wird, auf welchem der bio-molekulare Retrieval-Engine und dessen Operationen basieren, dass mittels eines automatisierten Resync-Moduls die selektierten Datenbanken und/oder Datenquellen und der Retrieval-Engine asynchron gekoppelt werden, wobei die Daten im bio-molekularen Retrieval Engine automatisch auf neue oder veränderte Daten aller selektierten Datenbanken und/oder Datenquellen aktualisiert werden zur Gewährleistung der Konsistenz des Primärschlüssels und/oder des Ladedatums-, und der Ladezeit und/oder Daten-Inhalt Terminierung und/oder Versionierung und Historisierung der Daten über den gesamten Lebenszyklus der Daten für einen Retrieve-Prozess, dass der Inhalt der Daten-Files aller selektierten Datenbanken und/oder Datenquellen parallel in eine Staging-Tabelle eines Daten Warenhauses (Data Warehouses DW) als für den bio-molekularen Retrieval-Engine zugreifbare, zentrale Datenbank mittels des bio-molekularen Retrieval-Engines geladen wird, wobei zum Ladezeitpunkt jede Zeile eines jeweilig geladenen Daten-Files mit der eineindeutigen Nomenklatur des Primärschlüssels indexiert ist und jede Zeile eines Daten-Files mit dem Ladedatum und Ladezeitpunkt zugeordnet in der Staging-Tabelle gespeichert ist und jeweils der Inhalt der gesamten Zeile des Daten-Files zum Ladezeitpunkt in die Tabellenzeile kopiert ist, dass mittels des bio-molekularen Retrieval-Engines durch Benutzer auf die in der Staging-Tabelle gespeicherten Daten Such-Operationen ausgeführt werden, wobei für jede Such-Operation der Such-Operation entsprechende Daten neu gefiltert, sortiert und/oder angereichert und/oder neu kombiniert werden und die jeweiligen erhaltenen Subsets von Daten in zusätzliche, dynamisch erstellte Tabellen gespeichert werden, dass die Daten aus der Staging-Tabelle und den zusätzlichen, dynamisch erstellten Tabellen abfragespezifisch und dynamisch in dimensionale Modelle und/oder in Codd-Datenmodelle und/oder objektorientiert zu entsprechenden Objekten von Applikationen und/oder in evolutive Datenmodelle abgebildet werden, wobei die entsprechenden dimensionalen Modelle und/oder Codd-Datenmodelle und/oder Objekte von Applikationen und/oder evolutiven Datenmodelle in Datamarts als individuell gesicherte Workspaces gespeichert werden, dass die Datamarts als Kopie eines Teildatenbestandes des Daten Warenhauses innerhalb des Daten Warenhauses als spezifische, der individuell gesicherten Workspaces mit definierten, eigenen Zugriffsrechten erstellt werden, und dass mittels eines interaktiven Front-End-Tools des bio-molekularen Retrieval-Engines die entsprechenden Drill-down-Operationen und/oder Roll-up-Operationen auf die Datamarts des Daten Warenhauses generiert werden. Mittels eines intelligenten, interaktiven Front-End-Tools des bio-molekularer Retrieval-Engines der Benutzer können z.B. die entsprechenden strukturellen end-to-end Drill-down-Operationen und/oder Roll-up-Operationen zur visuellen Navigation in den bio-molekularen, 3D-Strukturen benutzt und mit prä-, klinischen-, und Labordaten angereichert werden, wobei die generierten Drill-down-Operationen und/oder Roll-up-Operationen dynamisch mittels des bio-molekularer Retrieval-Engines aktualisiert werden. Mittels des bio-molekularer Retrieval-Engine kann z.B. dem Benutzer die Güte des Resultates mittels Visualisierungsmittel der Daten zur eigenständigen Beurteilung visualisiert werden. Retrieval-Resultate des bio-molekularen Retrieval-Engine können z.B. in pdb-Format und/oder einem gängigen Kommunikationsformat für den Benutzer zugreifbar generiert werden. Die gängigen Kommunikationsformate können mindestens XML (Extensible Markup Language) des World Wide Web Consortium (W3C) und/oder Text und/oder pdf (Portable Document Format) der Adobe Systems und/oder HTML (Hypertext Markup Language) des World Wide Web Consortium (W3C) und der Web Hypertext Application Technology Working Group (WHATWG) oder HL7 oder DICOM. XML, pdf und HTML sind Auszeichnungssprachen zur Darstellung hierarchisch strukturierter Daten in Form von Textdateien. XML, pdf und HTML sind vorliegend insbesondere geeignet für einen plattform- und implementationsunabhängigen Austausch von Daten zwischen dem bio-molekularer Retrieval-Engine und anderen elektronischen Systemen, insbesondere über das Internet. Weiter können die Retrieval-Resultate mittels des bio-molekularen Retrieval-Engine für den Transfer von Maschine zu Maschine und/oder deep learning und/oder Artificial Intelligence z.B. encrypted, insbesondere symmetrisch oder asymmetrisch verschlüsselt werden. Dabei können z.B. die interaktiven Retrieval-, Einfüge-, Selektions-, Roll-up- und/oder Drill-down-Prozesse basierend auf und/oder mittels Metadaten und Ontogien erfolgen, um heterogene SQL und/oder NoSQL Systeme irgendwelcher Art zu verbinden. Dadurch wird der Informationsaustausch ermöglicht, vereinfacht, beschleunigt und die Datenqualität gesichert. Die evolutiven Datenmodelle können z.B. Datenmodelle nach JSON (JavaScript Object Notation) umfassen. Allgemein können die heterogenen Datenbanken und/oder Datenquellen auch dokumentenorientierte Datenbanken umfassen, bei welchen Dokumente die Grundeinheit zur Speicherung der Daten bilden. Während relationale Datenbanken aus Datenbanktabellen bestehen, die einem festen Datenbankschema unterliegen, enthalten die dokumentenorientierten Datenbanken einzelne Dokumente. Diese Dokumente können strukturierte Dateien mit einem Standard-Dateiformat sein (wie eine Textverarbeitungsprogrammdatei), aber auch z.B. Binary Large Objects, die im Sinne eines Datenbankzugriffs nicht weiter strukturiert sind (z.B. mpeg-Dateien). Strukturierte Dateien mit einem frei festlegbaren Schema bestehen aus einer Reihe von Datenfeldern, die aus je einem Schlüssel-Wert-Paar bestehen können. Weitere mögliche Datenformate sind beispielsweise JSON-Objekte, YAML-Dokumente (YAML Ain't Markup Language) oder XML-Dokumente (Extensible Markup Language). NoSQL-Datenbanken stellen, wie die dokumentenorientierte Datenbanken, ebenfalls Datenbanken dar, welche Daten in nicht-tabellarischer Form und ohne die Einschränkungen der relationalen Datenbank zu speichern vermögen, wie Graphendatenbanken. Schliesslich können die Daten oder die Datamarts oder heterogene Systeme in der Cloud z.B. entsprechend einer zugeordneten Sensitivität transparent end-to-end verschlüsselt werden. Mindestens eine der heterogenen Datenbanken könne z.B. als Oracle RDBMS 12c realisiert sein, wobei die Eigenschaften der Container Database (CDB) genutzt werden, indem jedem Benutzer eine eigene Pluggable Datenbank (PDB) zugewiesen wird.

[0010] Am konkreten Beispiel wird im Folgenden sowohl die Stärke der Lösung als auch der Erweiterung und Verbesserung der Lösung gezeigt, wie das Einbinden von heterogenen Ressourcen an den bio-molekularen Retrieval-Engine und intelligente, interaktive, dynamische (REI<2>VA) Visualisierungsplattform als eine horizontale Schicht über alle möglichen Arten von Informations-Silos gebaut, betrieben und in jeder Hinsicht als Service, wie z.B. heterogene Datenbanken und/oder Datenquellen und/oder Applikationen und/oder Taxonomien und/oder Ontologien und/oder andere Gebiete wie Genomics, Metabolomics, allgemein „-omics“ aber auch für Biopsyen-Daten-Silos skaliert für die direkte Einbindung von präklinischen, klinischen und Labordaten. Die Vorteile dieser Erfindung liegen insbesondere darin, dass die bereits beschriebenen Verfahren und Methoden, um die Daten für den Retrieval und Darstellungs-Prozess vorzubereiten, solid sind, wie es für das Verfahren am konkreten Fall der Myelin-bindende Proteine gezeigt werden kann. Ein weiterer Vorteil entsteht dadurch, dass die Plattform REI<2>VA eine horizontale Schicht über alle möglichen Daten- , Programme-, Applikationen-, Taxonomien-, Ontologiensilos bildet, welche orts-, und zeitunabhängig asynchron gebaut, geändert, erweitert und betrieben werden können. Im konkreten Fall des Zink-Finger-Musters (siehe Fig. 5) geht es darum, Proteine oder Enzyme die 2 (oder mehr freie) Cysteine enthalten und deren SH Gruppen grob in die gleiche Richtung zeigen, deren Position in der Polypeptidkette jedoch schwierig zu finden ist. Die Schwefelatome sollen zwischen 3.5 Å und 5.0 Å auseinanderliegen und von der Oberfläche her zugänglich sein. Das Front-End I<2>VA des intelligenten, interaktiven Visualisierungsverfahrens der Plattform, siehe Beispiel der Front-Seite, ermöglicht sämtliche logisch zusammenhängende Ressourcen als Metadaten zu speichern, verwalten, betreiben, erweitern oder sogar löschen ohne die Funktionsweise der Plattform als Ganzes in Frage zu stellen. Im Stand der Technik findet sich kein System und Verfahren, welche mittels eines Front-Ends, wie dasjenige der I<2>VA, direkt bio-medizinische Fragestellungen aus präklinischen und klinischen, Labordaten, bio-molekularen Daten der „-omics“ und/oder Biopysien mit bio-molekularen Methoden, Strukturen und Verfahren zu beantworten und/oder Zusammenhänge eruieren kann. Ausserdem stellt der Retrieval Engine das erste Mal technisch Mittel bereit, aus allen Proteinen innerhalb der PDB-Datenbank, z.B. mit mehr als 113'000 Textfiles, welche zusammengenommen mehr als 1,2 Milliarden Zeilen ergeben, das Zink-Finger-Muster innert wenigen Sekunden, z.B. weniger als 60 Sekunden, Fig. 9 und Fig. 10 zu finden, ausgeschlossen sind diejenigen Strukturfiles, welche explizit im Header und/oder Remark die Kennzeichnung „ZINC PATTERN“ aufweisen. Diese Art und Sorte von Proteine sind bekannt als Myelin-bindende Proteine, welche insbesondere für medizinische Behandlung von Multiple Sclerose (MS) sehr wichtig sein können. Die pdb-File-Namen dieser speziellen 4286 myelin-bindenden Proteine deren Verfahren und Methoden, um sie zu finden - skalierbar für beliebige Grundmengen an PDB-Files, sind in dieser Erweiterung explizit enthalten.

Kurze Beschreibung der Zeichnungen

[0011] Die vorliegende Erfindung wird detaillierter erklärt durch die folgenden Beispiele mit Referenzierung zu den Zeichnungen, wobei: Fig. 1 zeigt schematisch den Datenfluss am Beispiel der PDB-Daten illustriert von der Datenbank und/oder Datenquelle (1,2) bis zu spezifischen Data-Mart (3,4,5), und Verknüpfung RE mit I<2>VA (6) und propagieren der Ergebnisse als Output (7) (vgl. Fig. 2). Als Erweiterung kann (mit entsprechenden Anpassungen) das Datawarehouse zu einer Cloud (private und/oder public) und die Datamarts, die in der Cloud verteilten heterogenen Speichersysteme darstellen. Fig. 2 illustriert schematisch den bio-molekularen Retrieval-Engine, der mit der intelligenten, interaktiven Visualisierungs-Applikation und mit den Daten sowohl in SQL-Datenbanken als auch NoSQL-verteilten Datenbanken und in der Cloud interagiert. Fig. 3 zeigt beispielshaft in pdb-Files gespeicherte fehlerbehaftete Daten. Figuren 4a-c zeigen beispielshaft eine parallel zugegriffene Staging-Tabelle eines Data Warehouses (DW) als für die Analysezwecke optimierte zentrale Datenbank, wobei mittels des bio-molekularen Retrieval-Engines der Inhalt der Daten der heterogenen Datenbanken und/oder Datenquellen parallel in die Staging-Tabelle des Data Warehouses (DW) geladen wird. Die Zeilen 1-12 der Tabelle wurde der besseren Erkennung wegen auf die Figuren 4a-c verteilt. Fig. 5 zeigt ein Beispiel für ein Zink-Finger-Motiv. Fig. 6 zeigt eine theoretische Lösung, um alle möglichen Distanzen zwischen den zu Atomen Cαund Residue CYS, Cβund Residue CYS und SG und Residue CYS zu ermitteln. Die Distanz-Kombination Matrix von Fig. 6 zeigt eine symmetrische Matrix der Distanzen zwischen den Atomen. Die Diagonalwerte müssen Null sein, weil dies die Distanzen zum gleichen Atom sind. Das bedeutet, dass wir eine Matrix haben müssen mit dkp= dpk. Deshalb müssen n(n-1)/2 Distanzen für jedes Paar dkpgerechnet werden, mit 1 ≤ k ≤ n-1. Das Muster, das gesucht ist, ist gegeben als jene Werte mit den Distanzen 2.5Å ≤ dkp≤ 5.0Å. Fig. 7 zeigt die Überprüfung der theoretischen Lösung mit dem Protein pdb2wut, auffinden der Koordinaten für das Zink-Finger-Muster, Spalten ATOM_NAME und RESIDUE_NAME auf die Zeile genau, Spalte ATMKVL_ID und ATOM_SERIAL_NMBR. Fig. 8 zeigt den Abfrage-Code um die 4286 pdb-Filenamen zu gewinnen mit einer Resolution im Bereich zwischen 0.5 Å und 3.5 Å und eine next-to-next Distanz zwischen 2.2 Å und 5.0 Å. Fig. 9a-d illustriert das Verfahren und die Methode, um das Zink-Finger-Muster innerhalb von über 1.2 Milliarden Zeilen aller pdb-Datenfiles, zu finden. Fig. 10a-b zeigt das Verfahren und die Methode, um die Distanz zwischen den Ca-Cys und SG-CYS-Atomen zu bestimmen für das Zink-Finger Muster. Fig. 11 zeigt die Plattform Architektur für den bio-molekularen Search Engine (Such-Maschine) und die intelligente, interaktive Visualisations-Applikation. Die Plattform REI<2>VA besteht aus skalier-, erweiterbare, locker zusammenhängende Komponenten, welche für sich genommen in einer private und/oder public Cloud installiert, betrieben und verwaltet werden können. Fig. 12 zeigt, wie in einem Front-End End-Nutzer den Schwierigkeitsgrad der Retrieval Engine aufgrund der jeweiligen Expertise einstellen können. Damit erhalten End-Nutzer die Möglichkeiten Komplexität, Anzahl der Datensätze und/oder Ressourcen eigenständig zu steuern. Fig. 13 illustriert die zugrundeliegende Funktionsweise der Interaktionen Plattform, Visualisierung, End-Nutzer. Die zugrundeliegende Funktionsweise beinhaltet: (a) Funktionalität, um verschiedene Nomenklaturen in Datenbanken über Metastruktur zu verbinden; (b) Programm, um Molekülstrukturen auf funktionelle Bedeutung zu untersuchen -> Retrieval Engine; (c) Interaktive Visualisierung von Dateneigenschaften/Zusammenhängen/Korrelationen.

Detaillierte Beschreibung einer bevorzugten Ausführungsvariante

[0012] Figur 1 illustriert schematisch eine Architektur für eine mögliche Realisierung einer Ausführungsvariante des bio-molekularer Retrieval-Engine zum Suchen, Selektieren und interaktiven Analysieren komplexer Strukturen in grossen, heterogenen Datensätzen mittels entsprechenden Drilldown und Roll-up Operationen. Mittels des bio-molekularer Retrieval-Engine werden die heterogenen Datensätze und/oder Datenquellen und/oder Datenbanken nach bio-molekulare, 3D-Strukturen und Verbindungen mit bestimmten Eigenschaften gefiltert werden, wobei es sich bei dem bio-molekularer Retrieval-Engine um ein automatisiertes, real-time oder beinahe real-time System zum interaktiven Durchsuchen, Vergleichen und Zusammenfassen heterogener, verschiedenartiger Datenbanken handelt. Ein Benutzer kann dabei mittels eines einzigen standardisierten Anfragen-Tool und -Interface zugreifen. Die heterogenen, verteilten Datenbanksysteme können insbesondere nicht nur technische Unterschiede wie z.B. verschiedenartige Dateiformate und/oder Zugriffs Protokolle und/oder Anfragesprachen umfassen, sondern auch auf unterschiedlichen Datenmodellen beruhen, wie z.B. verschiedene Wege, die gleichen Daten zu speichern, z.B. die Encodierung der Spaltennamen. Dabei kann der bio-molekulare Retrieval-Engine auch gleichzeitig ein gemeinsames Abfragesystem für objektorientierte und relationale Datenbanken sein, da sich auch derartige Unterschiede der Datensätze mit dem bio-molekularen Retrieval-Engine verbinden lassen. Für das Dateiformat gilt, dass es die Syntax und Semantik von Daten innerhalb einer Datei definiert. Es stellt damit die bidirektionale Abbildung der zugreifbar gespeicherten Informationen auf einen eindimensionalen binären Speicher dar. Die Kenntnis des Dateiformats ist essentiell für die Interpretation der in einer Datei abgelegten Information. Üblicherweise müssen Dateien über das Dateiformat Anwendungen zugeordnet werden, die die Dateien dann interpretieren können. Protokolle in der Datenbanktechnologie sind Regeln, welche das Format, den Inhalt, die Bedeutung und/oder die Reihenfolge zugreifbarer Informationen zwischen verschiedenen technischen Einheiten festlegen. Schliesslich bildet die Abfragesprache oder Retrievalsprache typischerweise die Datenbanksprache zur Suche nach Informationen. Das Ergebnis einer Abfrage (Query) bildet dabei meinst eine Teilmenge des zugrundeliegenden Informationsbestandes. Dies wird auch als Filtern von Daten bezeichnet. Man unterscheidet im Stand der Technik Abfragesprachen nach ihrer Mächtigkeit. Eine Abfragesprache ist mächtiger als andere Abfragesprache, wenn sie den Datenbestand schärfer trennt als die andere, d.h. wenn also die Menge der in ihr bildbaren Suchergebnismengen die Menge der in der anderen Abfragesprache bildbaren Suchergebnismengen umfasst. Ein Beispiel einer Abfragesprache ist für XML-Informationssysteme die XML-Abfragesprache XQuery. Die Datenbanksprache SQL beinhaltet bereits eine Abfragesprache für entsprechende Datenbanksysteme.

[0013] Der bio-molekularer Retrieval-Engine ermöglicht es damit einem Benutzer eine sehr grosse Datenmenge an bio-molekularen oder anderen 3D-Strukturen zu durchsuchen und in Verbindungen mit vorgebbaren Eigenschaften zu finden. Dabei ist es auch möglich Ähnlichkeiten in den Strukturen in die Suche durch den biomolekularen Retrieval-Engine einzubeziehen. Als Ausführungsbeispiel kann der bio-molekulare Retrieval-Engine z.B. auf der relationalen Oracle Datenbank Release 12c basieren. Der Retrieval-Engine wirkt z.B. bei der pdb-Datenquelle auf mehr als eine Milliarde Zeilen und auf über 520'000 im Swissprot-Datenfile aufgeführten Proteine. Die Indexierung des Bio-Molekularer Retrieval-Engine mittels der eineindeutigen Nomenklatur des Primärschlüssel erfolgt dabei z.B. beim Ladeprozess eines pdb-Datenfiles durch automatische Übersetzung des pdb-three-letter-codes der Aminosäuren aus der pdb-Datenbank in den one-letter-code der Aminosäuren der Swissprot Datenbank, womit über die Protein-ID von SwissProt einen direkten Zusammenhang zu Krankheitsbilder aus SwissProt hergestellt werden kann, der umgekehrte Weg ist auch möglich, wobei der Inhalt der Daten der heterogenen Datenbanken und/oder Datenquellen automatisch parallel in eine Spalte der Staging-Tabelle des Data Warehouses (DW) mittels des bio-molekularen Retrieval-Engines geladen wird. Das heisst, dass beim Ladeprozess der pdb-Datenfiles automatisch die Übersetzung des three-letter-codes der Aminosäuren aus der pdb-Datenbank in one-letter-code der Aminosäuren der Swissprot Datenbank und umgekehrt erfolgt und automatisch in eine Spalte der Staging-Tabelle des Data Warehouses (DW) geladen wird. Die automatische Datenanalyse zwischen den pdb-, und Swissprot Datenquellen (Proteine und mittels der Protein-ID der zugeordneten Krankheitsbilder) ist mittels des Retrieval-Engine dadurch ermöglicht, dass beim Ladeprozess der pdb-Datenfiles ein Mechanismus automatisch alle drei-Zeichen-Code (three-letter-code) der Aminosäuren aus allen pdb-Files in ein-letter-Code (one-letter-code) übersetzt und das Ergebnis in eine dafür bestimmte Spalte persistiert. Mittels des Retrieval-Engine können beide Nomenklaturen (ein-, und drei-letter-Code der Aminosäuren) für jedes Protein aus der pdb-Datenfiles mit dem one-letter-code der Swissprot Datenfile verglichen werden. Umgekehrt, ermöglicht der Retrieval-Engine den one-letter-code der Swissprot Proteine in die three-letter-code der pdb-Sprache automatisch zu assoziieren und zu übersetzen. Analog und insbesondere, falls Sicherheits-, Datenschutz-, und Aspekte des Produktenschutzes nicht zwingend oder regulatorisch zu berücksichtigen sind, lässt sich der bio-molekulare Retrieval-Engine auch auf NoSQL verteilte Systeme erweitern, anbinden und übertragen. Durch den bio-molekularen Retrieval-Engine könne in jedem Fall SQL-, und NoSQL Datenbanken unter Berücksichtigung der Sicherheitsmassnahmen, direkt und/oder mittels Ontologien, Taxonomien und Metadaten verbunden und system-übergreifend abgefragt werden (siehe Fig. 3). Es ist wichtig darauf hinzuweisen, dass NoSQL-Datenbanken nicht zwingend auf die Structured Query Language (SQL) verzichten. Zwar setzen manche NoSQL-Systeme komplett auf nicht-relationale Funktionen, andere dagegen verzichten nur auf bestimmte Elemente, beispielsweise auf feste Tabellenschemata. Anstatt Tabellen kann eine NoSQL-Datenbank Daten beispielsweise als Objekte, Wertpaare oder geordnete Listen und Reihen organisieren.

[0014] Eine der vielen Kernfunktionen des Retrieval-Engines hat die Aufgabe beim Ladeprozess der Daten in die Datenbank, die einzelnen Zeilen der Datenbanken und/oder Datenquellen, z.B. aus der aus pdb Datenquelle, eineindeutig zu indexieren, Ladedatum und Ladezeit automatisch zu vergeben (vgl. Prozessschritt 2 in Fig. 1). Diese Indexierungs- und Markierungsart gelten als Primärschlüssel und sind für das gesamte Datenmodell, für alle Retrieval-Operationen des Retrieval-Engines fundamental. Sie werden durch den Retrieval-Engine eins-zu-eins für alle weiteren, heterogenen Datenbanken und/oder Datenquellen angewendet.

[0015] Die Bedienung des bio-molekularen Retrieval Engine ist über ein einheitliches, intelligentes, interaktives Visualisierungstool und -interface (I<2>VA) realisiert, so dass für Benutzer, auch ohne weiterreichendes Wissen in SQL oder PL/SQL oder Java Programmierung, den Drilldown respektive Roll-up Prozess stark vereinfacht wird, und gleichzeitig um Grössenordnungen beschleunigt ist. Benutzer können aufgrund der aktuellen Ergebnisse, selbständig die Güte des Resultates beurteilen und entscheiden. Die sehr stark verkürzte Entscheidungszeit ermöglicht einem Benutzer zudem iterativ verschiedene und mehrere Hypothesen auszuwerten, was bis anhin mit den Systemen des Standes der Technik technisch nicht möglich war. Das Front-End überträgt Parameter an die Datenbankmodelle, die für höchste Performance implementiert sind und dynamisch oder ad hoc dem Anwendungsfall entsprechend erstellt werden.

[0016] Die erweiterte Daten-Analyse auf pdb-, und Swissprot-Datenquelle ist, nebst anderen wichtigen Möglichkeiten durch den interaktiven, bio-molekularen Retrieval Engine ebenfalls realisierbar. Insbesondere liefert der Retrieval Engine auch auf die zwei konkreten real-world Fragen (i) „wo in der gesamten Menge aller pdb files und Swissprot-Proteine findet sich das DFG-Motif“ und (ii) „wo in der gesamten Menge aller pdb files kann das Zinc-Finger-Muster lokalisiert werden“ verlässliche Antworten. Die Antwort auf die erste Frage betrifft Kinasen. Die zweite Antwort steht im Zusammenhang mit Myelin-bindende-Proteine. Die Retrieval Engine ermöglicht es den Suchbereich beliebig einzugrenzen, z.B. Organismus, Auflösungsintervall eines Proteins, Berechnung der interatomaren Distanzen oder berücksichtigen des Distanz-Intervalls zwischen den relevanten Atomen u.v.n.m. Auch dies ist mit den Systemen des Standes der Technik so nicht möglich oder mindestens nicht in real-time oder nahezu real-time.

[0017] Der erfinderische Retrieval-Engine erlaubt es zudem, dass mit ihm die Datenqualität der in der relationalen Datenbank(en) gespeicherten Daten überprüft werden kann. Entsprechende Mechanismen erlauben es dem Benutzer u.a. aus dem gesamten Datenset der heterogenen Datenbanken und/oder Datenquellen von über einer Milliarde Zeilen innerhalb von wenigen Sekunden das original pdb-File mit mehr als 12'000 Zeilen in der korrekten, logischen und identischen Reihenfolge wie das originale pdb-File zu rekonstruieren. Damit ist es möglich einen Benutzer auf die Zeile und Spalte genau hinzuweisen, wo und welche Art von Fehler in den Daten vorkommt. Danach sind nur die korrigierten Zeilen des neuen pdb-Files in den RE (Retrieval-Engine) zu speichern. Die vorgängigen, fehlerhaften Zeilen können z.B. mit einem Zeitstempel versehen, terminiert, historisiert und/oder versioniert werden. Die korrigierten Zeilen erhalten die eineindeutige Indexierung, als Primärschlüssel, und den Zeitstempel ab dem Moment, ab dem die korrigierten Datenzeilen in die RE gespeichert werden.

[0018] Die Datenanalyse zwischen den pdb-, und Swissprot Datenquellen ist beim Retrieval-Engine dadurch ermöglicht, dass beim Ladeprozess der pdb-Datenfiles ein Mechanismus automatisch alle drei-Zeichen-Code (three-letter-code) der Aminosäuren aus allen pdb-Files in ein-letter-Code (one-letter-code) übersetzt und das Ergebnis in eine dafür bestimmte Spalte persistiert. Benutzer können beide Nomenklaturen (ein-, und drei-letter-Code der Aminosäuren) mittels des Retrieval-Engine für jedes Protein aus der pdb-Datenfiles mit dem one-letter-code der Swissprot Datenfile vergleichen. Umgekehrt, ein Mechanismus ermöglicht den one-letter-code der Swissprot Proteine in die three-letter-code der pdb-Sprache zu übersetzen.

[0019] Die Retrieval-Engine ist z.B. sowohl für Einrechnersysteme mit älteren Datenbankversionen, wie z.B. der Oracle Version 11gR1 geeignet, wobei der Kapazität des Rechners entsprechend reduzierte Datensätze verwendet werden können, als auch für modernere Datenbanksysteme, wie z.B. dem Engineered Systems von Oracle, Exadata quarter und full rack mit Oracle RDBMS-Release 12c. Damit lassen sich problemlos grosse Datensätze wie die vollständigen Datensätzen der pdb-Datenfiles, welche über 113'500 pdb-Textfiles bei mehr als 1,2 Milliarden Zeilen (Stand Mai 2016) umfassen und gleichzeitig den ebenso vollständigen Swissprot Datensatz verwenden. Alle Prozesse sind in der Retrieval-Engine automatisierbar und können insbesondere parallel ausführbar realisiert sein. Zusätzlich ist der Retrieval Engine skalierbar, robust, sicher, von hoher Performance im Vergleich zu Stand der Technik Systemen und erweiterbar, um sehr spezifische Anfragen auf sehr umfangreichen Datensätze und komplexe Queries zu lösen. Ausserdem kann der Retrieval Engine web-basiert realisiert sein, so dass er von verschiedensten End-Geräte oder Netzwerk-Nodes aus nutzbar und für einen grossen Nutzerkreis zugreifbar verwendbar ist. Retrieval Engine und die interaktive Visualisierungsapplikation können einzeln oder gemeinsam durch eine entsprechenden Service Provider angeboten und von verschiedensten „Browser-Based“ Endgeräte genutzt werden.

[0020] Die Prozesseschritte 1-7 aus Fig. 1 umfassen, dass (1) ein automatisierten „resync“ Mechanismus asynchron die verschiedensten, heterogenen Datenbanken und/oder Datenquellen koppelt oder mit Metadaten eindeutig gekennzeichneten Ressourcen jeglicher Art und Weise, also nicht nur die pdb-Datenbank, wobei der Retrieval-Engine dynamisch auf den neuesten Daten-Stand aktualisiert wird. Der Nomenklatur des Primärschlüssels besteht aus <pdb-filename_keyword_linenumber>. Das Prinzip ist auf SQL oder nicht relationale NoSQL übertragbar, um aus Datensätze aus SQL respektive NoSQL Datenbanken eineindeutig, logisch identifizierbarem Inhalt der Originalquellen zu rekonstruieren; (2) mittels parallelen Prozesse der Inhalt der Daten aus Text-Files oder heterogene Datenbanken und/oder Datenquellen in eine Staging-Tabelle der SQL oder NoSQL-Datenbank geladen wird. Zum Ladezeitpunkt ist jede Zeile des jeweilig geladenen Daten-Text-Files mit dem eineindeutig, in Prozessschritt 1 erklärten Nomenklatur des Primärschlüssels indexiert. Zusätzlich ist jede Zeile aus der pdb-, oder heterogenen Datenquelle mit dem Ladedatum-, und Ladezeitpunkt versehen. Der Inhalt der gesamten pdb-Zeile ist zum Ladezeitpunkt tel-quel in die Tabellenzeile kopiert. Dieses Verfahren ist auf jede andere heterogene Datenbank und/oder Datenquelle analog anwendbar; (3) auf die, in der Stagingtabelle gespeicherten Daten (vgl. Fig.1 und Fig3.) Benutzer Operationen dem Anwendungsfall entsprechend ausführen können, um von Fall zu Fall relevante Daten zu filtern, sortieren oder Daten anzureichern oder neu kombinieren und die jeweiligen erhaltenen Subsets von Daten in zusätzlichen, sogar ad hoc erstellten Tabellen und/oder Views zu speichern oder ad hoc Programme zu generieren. Die Nomenklatur für die erstellten Tabellen und/oder Views folgt dem Muster <organism_keyword-pdb-file_T>, wobei das „keyword-pdb-file“ ist das erste nach pdb-Regeln festgelegten Keyword und kennzeichnet jede Zeile im pdb-File; (4) Daten aus der Staging-Tabelle fallabhängig oder auch dynamisch und/oder ad hoc in Dimensional Models, Datenmodelle nach den Regeln von Codd oder objektorientiert Applikationen-Objekte oder in evolutive Datenmodelle, z.B. JSON, abgebildet werden; (5) Daten, Ergebnisse, weitere individuelle Sub-Retrieval-Engines und Verfahren in den individuell gesicherten Workspaces, sog. Datamart oder in der Cloud, gespeichert sind. Nur explizit erteilte Berechtigungen erlauben den Zugriff von Dritten auf andere Datamarts oder Teile von anderen, individuellen Workspaces oder Systeme in der Cloud. Die Datamarts innerhalb des Data-Warehouse sind spezifische, individuelle Workspaces mit eigen dafür definierten Zugriffsrechte und Sicherheitsmassnahmen. Im Fall von Oracle RDBMS 12c mit den Eigenschaften der Container Database (CDB) ist es sinnvoll jedem End-Benutzer eine eigene Pluggable Datenbank (PDB) zuzuweisen. Mechanismen erlauben Track and Trace, Korrektur, Historisierung und Versionierung von „malformed“ Datensätze (vgl. Fig.3); (6) das intelligente, interaktive Front-End (vgl. Prozessschritt 6 in Fig. 1) es einem grossen Nutzerkreis erlaubt die gesamte Infrastruktur aus verschiedensten Endgeräten aus zu nutzen; (7) es die intelligente, interaktive Visualisierungsapplikation einem Benutzer es ermöglicht eigenständig die Güte der Resultate zu beurteilen. Resultate, Informationen oder Wissen gelangen schliesslich im Prozessschritt 7 im pdb-Format aber auch in allen gängigen Kommunikationsformate (XML, Text, pdf, HTML, verschlüsselt für den Transfer von Maschine zu Maschine, deep learning, Artificial Intelligence ...) aus der Retrieval-Engine in die Aussenwelt.

[0021] Anzumerken ist, dass der bio-molekularer Retrieval-Engine zum Suchen, Selektieren und interaktiven Analysieren komplexer Strukturen die beiden Prozess-Schritte 4 und 5 der bekannten Oracle-Prozesse (siehe docs.oracle.com/cd/B19306_01/datamine.102/b14340/blast.htm) technisch vereinfacht und den Ladeprozess aus dem Swissprot-Datenfile in die relationale Datenbank beschleunigt. Damit sind die Schritte vier und fünf des Standes der Technik durch den bio-molekularer Retrieval-Engine obsolet. Konkret, im Schritt vier des von Oracle bekannten Ladeprozess geht es darum, dass „4. Create a control file named sprot.ctl with the following contents:“, um im folgenden Schritt „5. Finally, load the data: sqlldr userid=<user_name>/<passwd> control=sprot.ctl log=sprot.log direct=TRUE data=sprot40_formatted.txt“ die Swissprot-Daten in die relationale Datenbanktabelle zu speichern. Der im Retrieval-Engine integriere Prozess, führt „malformed“ Zeilen aus dem ursprünglichen Swissprot-Datenfile in einem separaten File auf. Nach Korrektur speichert der gleiche Mechanismus die korrigierten Daten in die Tabelle, Dieser Vorgang wird iteriert, bis alle „malformed“ Swissprot-Datensätze in die Tabelle geschrieben werden.

[0022] Am expliziten Beispiel für das Finden des Zink-Finger-Musters innerhalb der pdb-Daten-Text-files (mehr als 113'000) werden exemplarisch die Kernfunktionalitäten dieser generischen, evolutiven Lösung vorgeführt, um ad hoc und schnell beliebige andere Strukturen zu ermitteln. Die Prinzipien dieser Lösung lassen sich zusammenfassen in: eineindeutige, konsistente Partitionierung der gesamten Datenmenge, parametrisieren der gesuchten Muster und dessen logischen Zusammenhang, massiv parallele Ausführung der eindeutigen Operationen auf eindeutig disjunkte, logisch und im Kontext, konsistente Datenmengen. Somit lassen sich, wie im Beispiel gezeigt wird, jeglichen Arten und Sorten von Atomen und Residues u.v.n.m. innerhalb auf der gesamten Menge aller stetig wachsenden Anzahl der Datenmenge angewendet werden.

[0023] Die Parametrisierung besteht darin, dass (a) die Kernrestriktionen in der „where-clause“ beliebig erweitert werden können. (b) die booleschen Bedingungen sowohl zwischen den Mustern als auch zwischen den Restriktionen situativ adaptiert werden können. „On the fly“ generiert das Verfahren dieser Lösung automatisch das auszuführende Programm (a) für die Plattform, wo es ausgeführt werden muss und (b) genau dort, wo die analysierten Daten physisch gespeichert sind. Damit ist die Maxime erreicht „bring the programs to the data and not vice versa“. Damit werden viele Vorteile erreicht, wie z.B. kurze Latenz-Zeiten, optimale Nutzung der Bandbreite von Kommunikationsnetz (nur die Lösung, ein Subset der gesamten Datenmenge wird transportiert), optimale Nutzung der Rechenleistung und Speicherplatz, kein unnötiger Datentransport, Hochverfügbarkeit gegen Ausfälle von Ressourcen, weil die locker Verbunden und im Netz eingebunden Ressourcen sicherer sind gegen Hacker-Angriffe wie z.B. DdoS (distribute denail of service) u.v.n.m.

[0024] Als Beispiel seien als Parameter p_Muster_1, p_Muster_2, ... p_Muster_n, die boolesche Operation zwischen den Mustern und/oder Restriktionen genannt und mit der I<2>VA im Front-End der RE (Retrieval Engine) ad hoc festgelegt und weitergeleitet.

[0025] Beispiel für ein generisches Muster: Damit kann die Plattform aus generischen Prozeduren eine ad hoc bestimmte Prozedur konstruieren, um andere Muster mit anderen Bedingungen in der gesamten Datenmenge zu finden

[0026] Ebenso lässt sich die Berechnung der Distanzen zwischen den gewünschten Atomen, Atome und Residuen, Residuen und ... ad hoc mittels parametrisieren der generischen Lösung mittels des Front-End I2VA für grosse Datenmengen lösen, wie in Fig. 10. Verfahren und Methoden, um Distanzen zwischen Atome in grossen Datenmengen bestimmen.

[0027] Am Beispiel des Zink-Finger-Musters ist exemplarisch vorgeführt, dass im Fall von relationalen, nichtrelationalen heterogene Systeme, wo also die anfänglich gegebene, strenge, sequentielle Ordnungs-Struktur zwischen aufeinanderfolgenden Atome derselben Struktur/Protein, wie diese eindeutig in entsprechenden Struktur-Text-Files gegeben ist, zu jedem Zeitpunkt und für alle vorkommenden Proteine, immer sicher gestellt wird, dass die Distanzen logischerweise nur zwischen Atome oder Atome/Residuen usw. derselben Struktur, also der Struktur, welche ursprünglich in einem bestimmten Text-File enthalten war und mit der Speicherung in einer relationalen Datenbank oder wo auch immer als „Set“ (=Menge) stattfindet, somit jegliche Ordnungsstruktur verloren gegangen ist, ad hoc bestimmt und rekonstruiert wird.

[0028] Diese Aufgabe ist im Beispiel mit folgender generischer Bedingung gelöst:

[0029] Damit wird immer festgestellt, Fig. 10, dass nur die Distanzen zwischen Atome berechnet werden, welche im Kontext und im Zusammenhang mit dem gesuchten Muster, die Atome auf jeden Fall und immer aus dem ursprünglichen Daten-Textfile stammen und zusammengehören. Aus Fig. 10.:

[0030] Eine Ausführungsvariante liegt auch darin, anhand von expliziten Beispiele, wie das Auffinden des Zing-Finger-Musters in Proteine, welche nicht im Header/Remarks der pdb-Textfiles explizit gekennzeichnet, jedoch sehr wichtig für die medizinische Behandlung wie z.B. Multiple Sclerose (MS) sind, eine generische Lösung liefert, um mittels Parametrisierung ad hoc Muster, logische Zusammenhänge zwischen den Mustern mittels unscharfe Suche der gegeben Muster danach die Distanz zwischen den Atomen und Residuen für zusammengehörenden Atom-Gruppen und die dazugehörenden Residuen, gezeigt zu haben. Darüber hinaus zeigt diese Lösung wie mit einfachen Mittel, wie Ressourcen die Plattform REI<2>VA auch auf Ressourcen in der Cloud erweitert werden kann.

[0031] Mit dem Front-End I<2>VA intelligenten, interaktiven Visualisierungsapplikation der Plattform, ist es für End-Nutzer mit verschiedenen Kompetenz-Level möglich, von einer gesamten Übersicht aus sämtliche logisch und im Kontext zusammenhängende Ressourcen als Metadaten zu speichern, verwalten, betreiben, erweitern oder sogar löschen, ohne den Rest der Plattform in Frage zu stellen.

[0032] Jede Aktion eines beliebigen End-Nutzer kann, falls ein End-Nutzer es will, kann mitgezeichnet und lokal in einem privaten, beliebigen Speicherort eines End-Nutzers gespeichert werden. Somit kann ein beliebiger End-Nutzer, aufgrund der jeweils mitgespeicherten und/oder adressierbaren URIs (unique resource identifiers) irgendwo in einem beliebigen, jedoch zugreifbarer Cloud-Server Daten und/oder Dienste und/oder Applikationen und/oder Programme und/oder Rechenleistung benutzen, Fig. 18.Die automatische Mitschrift wird von der Plattform durchgeführt, gewährt, dass sogar mehrere explorativen Untersuchungen und deren Abhängigkeiten aufgezeichnet werden können, um aufgrund eines substantiell qualitativ hohem Subset auf die angestrebten Ergebnisse zu fokussieren. Selbst wenn die Verbindung mit der Plattform unterbrochen wird, sorgt die Applikation dafür, dass alle bestätigten Aktionen festgehalten werden. Bei einer erneuerten Anmeldung rekonstruiert die Plattform die eingefrorenen Zustände vor dem Abbruch der Kommunikation.

[0033] Am Beispiel des pdb-Filenamen z.B. pdb4yzf wird die Stärke der Lösung gezeigt und mit Hilfe der Ressourcen erläutert so, dass Verfahren und Methoden mutatis mutandi auf alle weiteren Ressourcen anwendbar ist, und die Plattform REI2VA als horizontaler Schicht über alle möglichen Arten von Informations-Silos gebaut, betrieben und in jeder Hinsicht, wie z.B. heterogene Datenbank und/oder Datenquellen und/oder Applikationen und/oder Taxonomien und/oder andere Gebiete wie Genomics, Metabolomics, allgemein „-omics“ aber auch für Biopsyen-Daten-Silos skaliert.

[0034] Damit lässt sich jede weitere Quelle der Plattform REI<2>VA als Service präsentieren, anbinden und verwenden. Nur wenn die angepeilte Quelle es erlaubt, darf ein End-Nutzer der Plattform REI2VA in den erlaubten Ressourcen Änderungen durchführen. Umgekehrt, lässt sich damit die Plattform REI2VA als Service für andere Services anbinden.

[0035] Im konkreten Beispiel des pdb-files pdb4yzf lassen sich Verfahren und Methoden dieser Lösung einerseits für alle weiteren pdb-Files, anderseits aber auch für alle anderen Arten und Sorten von Ressourcen anwenden. Die Verkettung, der im Kontext geltenden Teil-Strings für die Ansteuerung der Ressourcen, unter Berücksichtigung der grammatischen Definitionen respektive Syntaxen lassen sich zusammenbauen und als solche einer eineindeutigen Ressource zuweisen.

[0036] Beispiel:

[0037] https://pdbj.org/emnavi/quick.php?id =pdb-4yzf ist somit der komplette Ressourcen-Namen der als Metadata in der Plattform gespeichert wird, um damit alle in der pdb Datenbank zur Verfügung stehenden Ressourcen ohne ein jegliches Dazutun, zu nutzen und gleichzeitig ad hoc Informationen aus der angewählten Ressource für die Anreicherung der Plattform zu nutzen.

[0038] Die Assoziation der URL oder allgemeiner der URI (uniform resource identifier) ist im Sinne von RFC 3986 („A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource...“) zu verstehen. In gleicher Art und Weise, wie im Beispiel, lassen sich den Bedürfnissen eine End-Nutzers entsprechend alle weiteren, bereits existierenden, definierten und entwickelten Arten und Sorten von Ressourcen in die REI2VA verwenden, anbinden, erweitern, integrieren, bearbeiten und/oder sogar löschen, siehe Beispiel https://pdbj.org/emnavi/quick.php?id =pdb-4yzf , ohne den Rest der Plattform REI2VA zu zerstören oder Konsistenz, Qualität, Quantität oder Sicherheit der gesamten Plattform in Frage zu stellen.

[0039] Sämtliche durch eine URI, wie im Beispiel gezeigt, zur Verfügung stehenden Ressourcen können von einem End-Nutzer verwendet werden, die Plattform REI2VA, sofern es ein End-Nutzer es will, registriert, wie bereits beschrieben alle Aktivitäten. Dadurch entsteht mittels „lockere“ Verbindung der Komponenten (loosly coupled components) eine skalierbare Plattform, welche Ressourcen-Namen als Metadata in der REI2VA speichert und verwaltet und die tatsächlichen Ressourcen, wie z.B. Daten, Programme, Applikationen, Taxonomien, u.v.n.m. ist die Gesamtheit und Funktionsweise der Plattform REI2VA immer gewährleistet, siehe Fig. 11 und Fig. 13, denn die zu einem beliebigen aber bestimmten Fall gehörenden Ressourcen können beliebig geändert, ergänzt, skaliert oder sogar gelöscht werden ohne die REI2VA-Plattform zu zerstören.

[0040] Damit ist es z.B. möglich computational Tools und/oder Daten entweder in einer private und/oder public Cloud zu verteilen oder aus derselben zu integrieren so, dass die Plattform REI<2>VA schlank und flexibel gehalten werden kann, um z. B. End-Nutzer zu ermöglichen Evidenz-basierte, medizinische Entscheide („medical decision making and patient outcomes“) präzise ad hoc zu fällen, z.B. mit dem Einbinden von prä-, und/oder klinischen und/oder Labordaten zu einem bestimmten Krankheitsbild eines bestimmten Individuums, derer respektive dessen Identität mit persönlichen pseudo Fingerprints als Verschlüsselung maskiert ist, um direkt und unkompliziert mit unzähligen, weit-weit verteilten Labors, Research and Development Unternehmen und/oder Pharma Informationen zu teilen und/oder auszutauschen, unter Wahrung der Privacy, Secrecy und Anonymity eines betroffenen Individuums und/oder direkter und/oder vom Patient/Patientin beauftragter Gesundheitsversorger und Leistungserbringer.

[0041] Entsprechende Beispiele können einen Eindruck geben, wie die benutzerfreundliche I<2>VA einen End-Nutzer explorative Tests ermöglicht, um aus grossen Datenmengen auf wesentliche Details zu fokussieren. Somit lässt sich jede Ressource ausserhalb aber auch innerhalb der Plattform REI<2>VA als Service anbinden. Dafür braucht es lediglich eine Verbindung, wie Internet oder sonst eine erlaubte und beglaubigte Verbindung zwischen einer Ressource und die REI<2>VA Plattform. Die Zugriffsrechte auf die angeschlossenen Ressourcen, können den Bedürfnissen entsprechend angepasst, umgesetzt werden. End-Nutzer können im Front-End der REI<2>VA Plattform, aufgrund der jeweiligen Expertise, die Komplexität der Abfragen eigenständig steuern Fig. 11 und Fig. 12.

Claims (9)

1. Verfahren zum Suchen, Selektieren und interaktiven Analysieren komplexer Strukturen in heterogenen Speichersystemen und/oder Datenbanken mit einem bio-molekularen Retrieval-Engine mittels entsprechenden Drill-down und Roll-up Operationen, wobei die heterogenen Speichersysteme und/oder Datenbanken nach bio-molekularen 3D-Strukturen und Verbindungen mit bestimmten Eigenschaften gefiltert werden, dadurch gekennzeichnet, dass beim Ladeprozess (2) von Daten-Files einer selektierten Datenbank und/oder Datenquelle (1) in den bio-molekularen Retrieval-Engine die einzelnen Zeilen der Daten-Files der Datenbank und/oder Datenquelle (1) mittels einer eineindeutigen Nomenklatur indexiert (4) werden, wobei mindestens Ladedatum und Ladezeit automatisch vergeben werden, dass dieselbe Indexierung (4) auf die Daten-Files jeder weiteren selektierten und zu ladenden Datenbank und/oder Datenquelle (1) angewendet wird, wobei alle selektierten Datenbanken und/oder Datenquellen (1) die heterogenen Speichersysteme und/oder Datenbanken umfassen und die Indexierung (4) als Primärschlüssel verwendet wird, auf welchem der bio-molekulare Retrieval-Engine und dessen Operationen basieren, dass mittels eines automatisierten Resync-Moduls die selektierten Datenbanken und/oder Datenquellen (1) und der Retrieval-Engine asynchron gekoppelt werden, wobei die Daten im bio-molekularen Retrieval Engine automatisch auf neue oder veränderte Daten aller selektierten Datenbanken und/oder Datenquellen (1) aktualisiert werden zur Gewährleistung der Konsistenz des Primärschlüssels und/oder des Ladedatums-, und der Ladezeit und/oder Daten-Inhalt Terminierung und/oder Versionierung und Historisierung der Daten über den gesamten Lebenszyklus der Daten für einen Retrieve-Prozess, dass der Inhalt der Daten-Files aller selektierten Datenbanken und/oder Datenquellen (1) parallel in eine Staging-Tabelle eines Daten Warenhauses (5) als für den bio-molekularen Retrieval-Engine zugreifbare, zentrale Datenbank mittels des bio-molekularen Retrieval-Engines geladen wird, wobei zum Ladezeitpunkt jede Zeile eines jeweilig geladenen Daten-Files mit der eineindeutigen Nomenklatur des Primärschlüssel indexiert (4) ist und jede Zeile eines Daten-Files mit dem Ladedatum und Ladezeitpunkt zugeordnet in der Staging-Tabelle gespeichert ist und jeweils der Inhalt der gesamten Zeile des Daten-Files zum Ladezeitpunkt in die Tabellenzeile kopiert ist, dass mittels des bio-molekularen Retrieval-Engines durch Benutzer auf die in der Staging-Tabelle gespeicherten Daten Such- Operationen ausgeführt werden, wobei für jede Such-Operation der Such-Operation entsprechende Daten neu gefiltert, sortiert und/oder angereichert und/oder neu kombiniert werden und die jeweiligen erhaltenen Subsets von Daten in zusätzliche, dynamisch erstellte Tabellen gespeichert werden, dass die Daten aus der Staging-Tabelle und den zusätzlichen, dynamisch erstellten Tabellen abfragespezifisch und dynamisch in dimensionale Modelle und/oder in Codd-Datenmodelle und/oder objektorientiert zu entsprechenden Objekten von Applikationen und/oder in evolutive Datenmodelle abgebildet werden, wobei die entsprechenden dimensionalen Modelle und/oder Codd-Datenmodelle und/oder Objekte von Applikationen und/oder evolutiven Datenmodelle in Datamarts als individuell gesicherte Workspaces gespeichert werden, dass die Datamarts als Kopie eines Teildatenbestandes des Daten Warenhauses (5) innerhalb des Daten Warenhauses (5) als spezifische, der individuell gesicherten Workspaces mit definierten, eigenen Zugriffsrechten erstellt werden, und dass mittels eines interaktiven Front-End-Tools (6) des bio-molekularen Retrieval-Engines die entsprechenden Drill-down-Operationen und/oder Roll-up-Operationen auf die Datamarts des Warenhauses (5) generiert werden.

2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass Retrieval-Resultate des bio-molekularen Retrieval-Engine in pdb-Format (7) und/oder einem Kommunikationsformat für den Benutzer zugreifbar generiert werden.

3. Verfahren nach Anspruch 2, dadurch gekennzeichnet, dass die Kommunikationsformate mindestens Extensible Markup Language und/oder Text und/oder Portable Document Format und/oder Hypertext Markup Language umfassen.

4. Verfahren nach einem der Ansprüche 2 oder 3, dadurch gekennzeichnet, dass die Retrieval-Resultate mittels des bio-molekularen Retrieval-Engine für den Transfer von Maschine zu Maschine verschlüsselt sind.

5. Verfahren nach Anspruch 4, dadurch gekennzeichnet, dass die Retrieval-Resultate mittels des bio-molekularen Retrieval-Engine für den Transfer von Maschine zu Maschine verschlüsselt sind, und die interaktiven Retrieval-, Einfüge-, Selektions-, Roll-up- und/oder Drill-down-Prozesse basierend auf und/oder mittels Metadaten und Ontogien erfolgen, wobei heterogene SQL und/oder NoSQL Systeme irgendwelcher Art verbindbar sind und wobei der Informationsaustausch ermöglicht und/oder vereinfacht und/oder beschleunigt und/oder die Datenqualität gesichert wird.

6. Verfahren nach einem der Ansprüche 1 bis 5, dadurch gekennzeichnet, dass die evolutiven Datenmodelle nach JavaScript Object Notation umfassen.

7. Verfahren nach einem der Ansprüche 1 bis 6, dadurch gekennzeichnet, dass die Datamarts entsprechend einer zugeordneten Sensitivität transparent end-to-end verschlüsselt werden.

8. Verfahren nach einem der Ansprüche 1 bis 7, dadurch gekennzeichnet, dass mittels des interaktiven Front-End-Tools des bio-molekularen Retrieval-Engines der Benutzer die entsprechenden strukturellen end-to-end Drill-down-Operationen und/oder Roll-up-Operationen zur visuellen Navigation in den bio-molekularen, 3D-Strukturen benutzt, wobei die generierten Drill-down-Operationen und/oder Roll-up-Operationen dynamisch mittels des bio-molekularen Retrieval-Engines aktualisiert werden.

9. Verfahren nach einem der Ansprüche 1 bis 7, dadurch gekennzeichnet, dass die Indexierung (4) mittels der eineindeutigen Nomenklatur des Primärschlüssels beim Ladeprozess eines pdb-Datenfiles (7) durch automatische Übersetzung des pdb-three-letter-codes der Aminosäuren aus der pdb-Datenbank in den one-letter-code der Aminosäuren der Swiss-Prot Datenbank und umgekehrt erfolgt, wobei der Inhalt der Daten der heterogenen Datenbanken und/oder Datenquellen (1) automatisch parallel in eine Spalte der Staging-Tabelle des Daten Warenhauses (5) mittels des bio-molekularen Retrieval-Engines geladen wird.