EP2208154A1 - Verbindungsschicht für datenbanken - Google Patents

Verbindungsschicht für datenbanken

Info

Publication number
EP2208154A1
EP2208154A1 EP08773457A EP08773457A EP2208154A1 EP 2208154 A1 EP2208154 A1 EP 2208154A1 EP 08773457 A EP08773457 A EP 08773457A EP 08773457 A EP08773457 A EP 08773457A EP 2208154 A1 EP2208154 A1 EP 2208154A1
Authority
EP
European Patent Office
Prior art keywords
data
application
alias
applications
instance
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP08773457A
Other languages
English (en)
French (fr)
Inventor
Stefan Deutzmann
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Deutsche Telekom AG
Original Assignee
Deutsche Telekom AG
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Deutsche Telekom AG filed Critical Deutsche Telekom AG
Publication of EP2208154A1 publication Critical patent/EP2208154A1/de
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/25—Integrating or interfacing systems involving database management systems
    • G06F16/252—Integrating or interfacing systems involving database management systems between a Database Management System and a front-end application

Definitions

  • the invention relates to a method for carrying out access to databases and / or data fields and / or applications in a data processing system and / or in a network of data processing systems, the databases and / or data fields and / or applications being assigned a unique address, in particular one IP address, a server name, a pathname and / or a file name or the like and a data processing system with an application for performing the method.
  • Application means the actual program as well as the data stored by this program.
  • the data can be stored within the application or outside. It is assumed that the application is accessed.
  • These applications are linked together for specific functions in order to use data from another application.
  • the calling application must therefore know where to find the application to be called and how the data can be queried. Since a multiplicity of applications with a multiplicity of mutual entanglements results in the course of time, maintenance of each individual entanglement is not possible. If it is necessary to change the application to be called (eg other server, other database name, other field structure, etc.), changes to the calling applications must be avoided become. In addition, access to applications should be as efficient as possible in order to keep the number of accesses and thus the server load as low as possible.
  • server and database names of applications to be called are permanently stored in the program code of the calling application. Solutions are known to replace these server and database names. The fundamental problem of fixed access paths is still not resolved. Solutions are also known for storing configurations in each application and then specifying server and database names or a platform-specific address for other applications to be queried in this application. If an application to be called is changed (for example, relocation to another server), the configuration must be changed with great effort in each calling application. There is a risk of not knowing all calling applications.
  • the object of the invention is to provide a method and a data processing system which overcomes the mentioned disadvantages and in particular prevents the fact that it can be overlooked to adapt a specific application in complex systems to a changed data structure or server structure.
  • each database and / or each data field and / or each application is assigned a unique address, in particular an IP address, a server name, a pathname and / or a file name or the like, each database and / or each data field and / or each application an alias is uniquely assigned and at least one assignment instance is provided, in which the assignment from alias to address is stored and retrievable therefrom, and that a connection entity is provided, which in an attempted access to databases and / or data fields and / or applications under Using the alias retrieving the address from the mapping instance and then accessing the databases and / or data fields and / or applications using the address obtained from the mapping instance.
  • the inventive method is not dedicated to the translation problem of different systems, although a coupling of the method with a translation method is conceivable.
  • applications within a system are identified only by their alias.
  • system it is meant here that the applications use the same platform, e.g. store their data in different databases of the same manufacturer.
  • the databases can run on the same or different hardware.
  • a tie layer i. a connection instance, puts the alias in a physical application, i. the actual address around.
  • the link layer provides applications with specific interfaces to query other applications. In a central configuration, i. in an assignment instance, it is deposited which physical application hides behind an alias.
  • the method underlying the invention extends and enhances the principle of simple physical localization of the resource, such as the known DNS system, by describing, in addition to finding the database, a universal method for independently and efficiently accessing data of a destination resource from its memory structure can.
  • the structure independence even goes so far that additional data can be offered at the access interface without changing existing access have to. This flexibility does not allow WebServices, for example.
  • the access technology is identical for all applications which use the method. This results in advantages with regard to simplified programming of the interfaces, their maintenance, expandability and changeability as well as performance during runtime.
  • the allocation instance is preferably a centrally stored instance, in particular in the form of a database.
  • the allocation instance may be formed by synchronized replicas on a plurality of data processing systems.
  • each accessing application as well as each application to be accessed is assigned an alias.
  • the assignment of alias to application or address is stored in the assignment instance as a central configuration and can be queried there.
  • individual data fields and / or data field contents of a database are indexed.
  • data contents of a database are returned to the requesting application via the connection instance.
  • connection entity can have a data processing entity which is suitable for processing the received data before handing over to the requesting application.
  • the connection instance may comprise a data buffer which is suitable for at least temporarily storing the data obtained. The procedure in a particularly preferred embodiment is described below.
  • Indexes are used for tapping individual data so that performance-optimized access to the index can be used instead of at the field level.
  • the data can already be made available in preprocessed form via the index in order to reduce access times.
  • the index is also accessed via the connection layer.
  • the data is masked with an alias in order to decouple the queriable data names from the underlying field names. In a central configuration, it is deposited which indexes with which data aliases are available.
  • Alias - adapt physical application to immediately route all calls of this application to the new physical application. This advantage increases as more applications communicate with each other.
  • the method works with double masking, ie the one-to-one assignment of alias to application or address and alias to data element: application masking and data masking.
  • Application masking and data masking Access to applications and Data takes place via a connection layer, ie via a connection instance. All information about the masking is stored in a central configuration, ie in an assignment instance. This configuration is stored so that it can be accessed by all applications to read data from.
  • Conceivable variants for this central configuration are:
  • the central configuration data have only a small amount and are subject to few changes. Therefore, the access to this configuration data can be done very quickly, so that no noticeable performance losses are recorded.
  • the entire implementation of the masks is hidden in the intermediate layer and is used by each application. Depending on whether the application itself or the data is to be accessed, the masking must be implemented and configured accordingly.
  • the intermediate layer provides powerful interfaces via which the respective access to the data or the application takes place.
  • Fig. 1 is a schematic representation of the access of a calling
  • connection layer Application via the connection layer to a data-holding application
  • Fig. 2 is a schematic representation of the access of a calling
  • connection layer Application via the connection layer to specific data contents of a data-holding application
  • Fig. 3 is a schematic representation of the access of a calling
  • connection layer to complete data records of a data-holding application.
  • the application masking takes place as shown in FIG.
  • Each application has a mask entry of two elements in the central configuration:
  • the application determines its own alias by querying the alias associated with its physical location (actual address).
  • the application is able to determine its own “identity” and e.g. in messages to other applications or to read other configurations that affect themselves from the central configuration.
  • an application wants to contact another application, it uses the alias of the target application to query the physical application in the intermediate layer.
  • the intermediate layer then returns an appropriate accessibility.
  • These functionalities are built into the intermediate layer so that they no longer communicate directly with each other for the applications involved.
  • the intermediate layer accepts all requests and responses of the applications involved and forwards them to the respective addressees. If an application calls another application, the call is made as shown in Figure 1 according to the following scheme:
  • the calling application A asks the connection layer V a query in which it passes the alias of the application C to be called.
  • connection layer V makes a request to the central configuration B, in which it passes on the alias of the application C to be called.
  • connection layer V From the central configuration B, the physical application C belonging to the alias is returned to the connection layer V.
  • connection layer V calls the physical application C belonging to the alias.
  • connection layer V returns the called application C as an object, for example, to the calling application A.
  • the calling application A therefore, no physical data of the application C to be called up must be stored.
  • the communication takes place exclusively via the connection layer V and can be completely masked behind the alias. Only in the central configuration B is it necessary to pay attention to the correct assignment of alias and physical application. If the called application C 1 changes, this change is mapped in the central configuration. According to this illustration, all calling applications immediately use the new physical application without the need for additional changes to the calling applications.
  • the data masking is shown schematically in FIG.
  • the masking of the data is an extension of the application masking.
  • at least one index will be created containing a suitable search key and additional data.
  • An index is thus not only an access path for the identification of specific data, but serves the intermediate layer to actually read the data from the called application.
  • An application may have multiple indexes, e.g. improve the performance of each index or represent different types of data.
  • a query configuration is stored for each index from the following elements:
  • the search key and the alias of the desired data element must be specified in the query. If an application retrieves data from another application, the call is made as shown in FIG. 2: 1.
  • the application A calls the connection layer V to obtain data from application C.
  • connection layer directs a query to the Central Configuration B with the name of the query configuration.
  • the central configuration B returns the alias of the application C to be queried.
  • connection layer V directs a query to the central configuration B with the alias of the application C to be queried.
  • a list with aliases of the data available in the index is returned from the central configuration B.
  • connection layer V accesses the physical application C (5).
  • the bonding layer V accesses the index (6).
  • connection layer V searches for the record matching the search key in the index.
  • the application C supplies the entire index data of the data set from (10) to the connection layer V. These data are stored in the data buffer P.
  • the link layer V extracts from the entire index data in the buffer P out (11) the data with the desired data element alias.
  • connection layer V delivers the desired data to the calling application A.
  • connection layer V retrieves the data for the calling applications A from the source application C and thereby reads the entire index data (see step 11), the retrieved data can be buffered in the data buffer P of the connection layer V. If data is fetched again for the same data record, the connection layer V can make the data available directly, ie without renewed access to the central configuration B or the source application C. The more data that is queried for a data record, the clearer the performance gain over access without the one shown here Technology. In addition, robust mechanisms are stored in the connection layer V, which intercept data errors and thus prevent aborts in the calling application A.
  • connection layer can provide a method which automatically supplies the desired data completely.
  • a definition is stored in the central configuration, which has a data masking and a data element alias list.
  • the calling application must make a request to the connection layer, passing the configuration name and the search key. If this method is used, even extensive data queries can be realized with minimal effort in the calling application. In addition, the benefits of application masking and the benefits of data masking can be fully exploited. If an application retrieves data in this way, the call is made as shown in FIG. 3:
  • the application A calls the connection layer V and passes configuration name and search key.
  • the link layer V requests the configuration from the central configuration to B.
  • connection layer V iterates over the data element alias list. For each pass, it retrieves the data via the data masking method described above (represented by dashed lines) using the data buffer of link layer V.
  • connection layer V returns the entire determined data to the calling application A. Building on this, further extensions are possible. Thus, the connection layer can not only return the data to the calling application, but can process it and return the result first. As a result, the network layer can centrally provide tools that can be used by several applications, are centrally maintainable, and make use of the advantages of application and data masking.

Landscapes

  • Engineering & Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Data Mining & Analysis (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

Verfahren zur Durchführung eines Zugriffs auf Datenbanken und/oder Datenfelder und/oder Applikationen (C) in einer Datenverarbeitungsanlage und/oder in einem Netzwerk von Datenverarbeitungsanlagen, wobei den Datenbanken und/oder Datenfeldern und/oder Applikationen (C) eine eindeutige Adresse zugeordnet ist, insbesondere eine IP-Adresse, ein Servername, ein Pfadname und/oder ein Dateiname oder dergleichen, wobei jeder Datenbank und/oder jedem Datenfeld und/oder jeder Applikation (C) ein Alias eineindeutig zugeordnet ist und zumindest eine Zuordnungsinstanz (B) vorgesehen ist, in der die Zuordnung von Alias zu Adresse gespeichert und von dieser abrufbar ist, und dass eine Verbindungsinstanz (V) vorgesehen ist, die bei einem versuchten Zugriff auf Datenbanken und/oder Datenfelder und/oder Applikationen (C) unter Verwendung des Alias die Adresse aus der Zuordnungsinstanz (B) abruft und sodann unter Verwendung der von der Zuordnungsinstanz erhaltenen Adresse auf die Datenbanken und/oder Datenfelder und/oder Applikationen (C) zugreift.

Description

Verbindungsschicht für Datenbanken
Die Erfindung betrifft ein Verfahren zur Durchführung eines Zugriffs auf Datenbanken und/oder Datenfelder und/oder Applikationen in einer Datenverarbeitungsanlage und/oder in einem Netzwerk von Datenverarbeitungsanlagen, wobei den Datenbanken und/oder Datenfeldern und/oder Applikationen eine eindeutige Adresse zugeordnet ist, insbesondere eine IP-Adresse, ein Servername, ein Pfadname und/oder ein Dateiname oder dergleichen und eine Datenverarbeitungsanlage mit einer Applikation zur Durchführung des Verfahrens.
Auf Basis einer Plattform für Datenbanken existieren mehrere Applikationen. Unter "Applikation" wird das tatsächliche Programm sowie die von diesem Programm gespeicherten Daten verstanden. Die Daten können innerhalb der Applikation oder außerhalb gespeichert sein. Es wird unterstellt, dass über die Applikation der Zugriff erfolgt. Diese Applikationen sind für bestimmte Funktionen miteinander verbunden, um so Daten einer anderen Applikation zu verwenden. Die aufrufende Applikation muss also wissen, wo die aufzurufende Applikation zu finden ist und wie die Daten abgefragt werden können. Da sich im Zeitablauf eine Vielzahl an Applikationen mit einer Vielzahl an gegenseitigen Verschränkungen ergibt, ist eine Wartung jeder einzelnen Verschränkung nicht möglich. Ist es erforderlich, die aufzurufende Applikation zu ändern (z.B. anderer Server, anderer Datenbankname, andere Feldstruktur, etc.), müssen Änderungen an den aufrufenden Applikationen vermieden werden. Zudem sollen die Zugriffe auf Applikationen möglichst effizient geschehen, um die Anzahl der Zugriffe und damit die Serverbelastung möglichst gering zu halten.
In vielen Fällen werden Server- und Datenbanknamen aufzurufender Applikationen fest im Programmcode der aufrufenden Applikation hinterlegt. Es sind Lösungen bekannt, um diese Server- und Datenbanknamen zu ersetzen. Das grundsätzliche Problem der fixierten Zugriffswege ist damit dennoch nicht behoben. Auch sind Lösungen bekannt, in jeder Applikation Konfigurationen zu hinterlegen und in dieser dann Server- und Datenbanknamen bzw. eine plattformeigene Adresse für abzufragende andere Applikationen anzugeben. Wird eine aufzurufende Applikation geändert (z.B. Übersiedelung auf einen anderen Server), muss mit hohem Aufwand in jeder aufrufenden Applikation die Konfiguration geändert werden. Dabei besteht das Risiko, nicht alle aufrufenden Applikationen zu kennen.
Der Abruf der Daten selbst erfolgt mittels Zugriff auf Feldebene. Dazu muss der gewünschte Datensatz gefunden, geöffnet und dann im Datensatz das Feld abgerufen werden. Dieses Vorgehen ist - abhängig von der verwendeten Plattform - hinsichtlich der Performance nicht optimal. Bekannte Lösungen widmen sich dem Problem, unterschiedliche Systeme und Datenbanken zu koppeln. Dabei steht also eine "Übersetzung" jeweils spezifischer Eigenheiten in eine allgemeinere Form bzw. in spezifische Eigenheiten eines anderen Systems im Vordergrund.
Die Aufgabe der Erfindung ist es, ein Verfahren und eine Datenverarbeitungsanlage zur Verfügung zu stellen, durch die die genannten Nachteile überwunden werden und es insbesondere verhindert wird, dass es übersehen werden kann, eine bestimmte Applikation in komplexen Systemen an eine geänderte Datenstruktur oder Serverstruktur anzupassen.
Diese Aufgabe wird erfindungsgemäß durch ein Verfahren gemäß Anspruch 1 und durch eine Datenverarbeitungsanlage nach Anspruch 10 gelöst.
Besonders vorteilhaft ist dabei, dass bei dem Verfahren zur Durchführung eines Zugriffs auf Datenbanken und/oder Datenfelder und/oder Applikationen in einer Datenverarbeitungsanlage und/oder in einem Netzwerk von Datenverarbeitungsanlagen, wobei den Datenbanken und/oder Datenfeldern und/oder Applikationen eine eindeutige Adresse zugeordnet ist, insbesondere eine IP-Adresse, ein Servername, ein Pfadname und/oder ein Dateiname oder dergleichen, jeder Datenbank und/oder jedem Datenfeld und/oder jeder Applikation ein Alias eineindeutig zugeordnet ist und zumindest eine Zuordnungsinstanz vorgesehen ist, in der die Zuordnung von Alias zu Adresse gespeichert und von dieser abrufbar ist, und dass eine Verbindungsinstanz vorgesehen ist, die bei einem versuchten Zugriff auf Datenbanken und/oder Datenfelder und/oder Applikationen unter Verwendung des Alias die Adresse aus der Zuordnungsinstanz abruft und sodann unter Verwendung der von der Zuordnungsinstanz erhaltenen Adresse auf die Datenbanken und/oder Datenfelder und/oder Applikationen zugreift.
Das erfindungsgemäße Verfahren widmet sich nicht der Übersetzungsproblematik unterschiedlicher Systeme, wenngleich eine Koppelung des Verfahrens mit einem Übersetzungsverfahren denkbar ist. Bei dem geschilderten Verfahren werden Applikationen innerhalb eines Systems lediglich über ihren Alias identifiziert. Unter "System" wird hierbei verstanden, dass die Applikationen die gleiche Plattform benutzen, z.B. ihre Daten in unterschiedlichen Datenbanken desselben Herstellers ablegen. Die Datenbanken können auf derselben oder auf einer anderen Hardware laufen. Je mehr Datenbanken und/oder Server betroffen sind, desto größer wird der Vorteil des Verfahrens. Eine Verbindungsschicht, d.h. eine Verbindungsinstanz, setzt den Alias in eine physikalische Applikation, d.h. die tatsächliche Adresse um. Die Verbindungsschicht bietet den Applikationen bestimmte Schnittstellen, um andere Applikationen abzufragen. In einer zentralen Konfiguration, d.h. in einer Zuordnungsinstanz, ist hinterlegt, welche physikalische Applikation sich hinter einem Alias verbirgt.
Das der Erfindung zugrundeliegende Verfahren erweitert und verbessert das Prinzip der einfachen physischen Lokalisierung der Ressource, wie beispielsweise des bekannten DNS-Systems, indem zusätzlich zum Auffinden der Datenbank ein universelles Verfahren beschreiben wird, um auf Daten einer Zielressource von deren Speicherstruktur unabhängig und effizient zugreifen zu können. Die Strukturunabhängigkeit geht sogar soweit, dass an der Zugriffsschnittstelle zusätzliche Daten angeboten werden können, ohne bestehende Zugriffe ändern zu müssen. Diese Flexibilität erlauben z.B. WebServices nicht. Ferner ist die Zugriffstechnik für alle Applikationen, die das Verfahren einsetzen, identisch. Somit ergeben sich Vorteile im Hinblick auf vereinfachte Programmierung der Schnittstellen, deren Wart-, Erweiter- und Änderbarkeit sowie Performance während der Laufzeit.
Weitere vorteilhafte Ausgestaltungen der Erfindung sind in den Unteransprüchen angegeben.
Vorzugsweise ist die Zuordnungsinstanz eine zentral abgelegte Instanz, insbesondere in Form einer Datenbank. Alternativ kann die Zuordnungsinstanz durch synchronisierte Vervielfältigungen auf einer Mehrzahl von Datenverarbeitungsanlagen gebildet sein.
In einer bevorzugten Ausführungsform des erfindungsgemäßen Verfahrens ist sowohl jeder zugreifenden Applikation als auch jeder Applikation, auf die zugegriffen werden soll, jeweils ein Alias zugeordnet ist. Die Zuordnung von Alias zu Applikation bzw. Adresse ist in der Zuordnungsinstanz als zentrale Konfiguration hinterlegt und dort abfragbar.
Vorzugsweise werden einzelne Datenfelder und/oder Datenfeldinhalte einer Datenbank indiziert.
Es ist möglich, dass jede Applikation bei einem Start zunächst ihren eigenen Alias durch Abfrage bei der Zuordnungsinstanz abfragt.
Bevorzugt werden Dateninhalte einer Datenbank über die Verbindungsinstanz an die anfragende Applikation zurückgegeben.
Die Verbindungsinstanz kann eine Datenverarbeitungsinstanz aufweisen, die geeignet ist, die erhaltenen Daten vor einer Übergabe an die anfragende Applikation zu verarbeiten. Alternativ oder kumulativ kann die Verbindungsinstanz einen Datenpuffer aufweisen, der geeignet ist, die erhaltenen Daten zumindest zeitweise zu speichern. Der Verfahrensablauf in einer besonders bevorzugten Ausführungsform ist nachfolgend beschrieben.
Für den Abgriff einzelner Daten werden Indizes benutzt, so dass ein performanceoptimierter Zugriff auf den Index genutzt werden kann und nicht auf Feldebene erfolgt. Über den Index können die Daten zudem bereits in einer vorverarbeiteten Form zur Verfügung gestellt werden, um so die Zugriffszeiten zu reduzieren. Der Zugriff auf den Index erfolgt ebenfalls über die Verbindungsschicht. Dabei werden die Daten mit einem Alias maskiert, um eine Entkopplung der abfragbaren Datennamen von den zugrunde liegenden Feldnamen zu erreichen. In einer zentralen Konfiguration ist hinterlegt, welche Indizes mit welchen Datenaliasen zur Verfügung stehen.
Bei dem geschilderten Verfahren rufen sich Applikationen gegenseitig über den jeweiligen Alias auf. Bei Änderungen z.B. am Server oder/und Namen einer Applikation ist lediglich an einer Stelle (der zentralen Konfiguration) die Zuordnung
Alias - physikalische Applikation (Adresse) anzupassen, um sofort alle Aufrufe dieser Applikation an die neue physikalische Applikation zu leiten. Dieser Vorteil wird größer, je mehr Applikationen miteinander kommunizieren.
Über den Index und dessen Maskierung mittels Aliasen wird eine Entkoppelung von den tatsächlichen Feldnamen erreicht. Ändern sich Feldnamen der aufzurufenden Applikation muss lediglich der Indexaufbau angepasst werden. Der Alias, mit dem das Datenelement nach außen aufscheint, bleibt unverändert. Somit sind an aufrufenden Applikationen keine Änderungen notwendig. Zudem können zum Index an beliebiger Stelle weitere Datenelemente hinzugefügt werden, ohne bestehende Abfragen gegen den Index zu gefährden (die Aliasdefinition muss natürlich den Indexaufbau korrekt wiedergeben).
Das Verfahren arbeitet mit doppelter Maskierung, d.h. der eineindeutigen Zuordnung von Alias zu Applikation bzw. Adresse und Alias zu Datenelement: Applikationsmaskierung und Datenmaskierung. Der Zugriff auf Applikationen und Daten erfolgt über eine Verbindungsschicht, d.h. über eine Verbindungsinstanz. Sämtliche Angaben zur Maskierung sind in einer zentralen Konfiguration, d.h. in einer Zuordnungsinstanz hinterlegt. Diese Konfiguration ist so gespeichert, dass sie von allen Applikationen erreicht werden kann, um daraus Daten zu lesen. Denkbare Ausführungsvarianten für diese zentrale Konfiguration sind:
■ eine zentral abgelegte Instanz
■ eine synchronisierte Kopie auf allen Servern
■ algorithmisch bestimmbare Instanzen
Da es sich hierbei nur um eine Hintergrundapplikation handelt, ist die einzige Einschränkung die, dass alle Applikationen Zugriff haben müssen. Die zentralen Konfigurationsdaten haben in nur geringen Umfang und sind wenigen Änderungen unterworfen. Deshalb kann der Zugriff auf diese Konfigurationsdaten sehr schnell erfolgen, so dass keine merkbaren Leistungseinbußen zu verzeichnen sind. Die gesamte Implementierung der Maskierungen ist in der Zwischenschicht verborgen und wird von jeder Applikation benutzt. Je nach dem, ob auf die Applikation selbst oder auf die Daten zugegriffen werden soll, ist die Maskierung entsprechend umzusetzen und zu konfigurieren. Die Zwischenschicht bietet leistungsfähige Schnittstellen, über die der jeweilige Zugriff auf die Daten bzw. die Applikation erfolgt.
Drei Ausführungsbeispiele des erfindungsgemäßen Verfahrens oder Systems sind in den Figuren dargestellt und werden nachfolgend erläutert. Es zeigen:
Fig. 1 Eine schematische Darstellung des Zugriffs von einer aufrufenden
Applikation über die Verbindungsschicht auf eine datenhaltende Applikation;
Fig. 2 eine schematische Darstellung des Zugriffs von einer aufrufenden
Applikation über die Verbindungsschicht auf bestimmte Dateninhalte einer datenhaltenden Applikation;
Fig. 3 eine schematische Darstellung des Zugriffs von einer aufrufenden
Applikation über die Verbindungsschicht auf vollständige Datensätze einer datenhaltenden Applikation. Die Applikationsmaskierung erfolgt wie in Figur 1 dargestellt.
Jede Applikation verfügt in der zentralen Konfiguration einen Maskierungseintrag aus zwei Elementen:
■ Alias der Applikation
■ Physikalische Applikation (z.B. Server- und Dateiname oder andere geeignete Parameter, die für den Aufruf der Applikation notwendig sind)
Beim Start einer Applikation ermittelt sie ihren eigenen Alias, indem sie den zu ihrer physikalischen Lokation (tatsächliche Adresse) gehörenden Alias abfragt. Damit ist es der Applikation möglich, ihre eigene "Identität" zu ermitteln und z.B. in Nachrichten an andere Applikationen mitzugeben bzw. weitere Konfigurationen, die sie selbst betreffen, aus der zentralen Konfiguration zu lesen.
Möchte eine Applikation eine andere Applikation kontaktieren, fragt sie anhand des Alias der Zielapplikation die physikalische Applikation bei der Zwischenschicht nach. Die Zwischenschicht liefert daraufhin eine entsprechende Zugriffsmöglichkeit zurück. Diese Funktionalitäten sind derart in der Zwischenschicht eingebaut, dass für die beteiligten Applikationen nicht mehr direkt miteinander kommunizieren. Die Zwischenschicht nimmt alle Anfragen und Antworten der beteiligten Applikationen an und reicht sie an den jeweiligen Adressaten weiter. Ruft eine Applikation eine andere Applikation auf, erfolgt der Aufruf wie in Figur 1 dargestellt nach folgendem Schema:
1. Die aufrufende Applikation A stellt an die Verbindungsschicht V eine Abfrage, in der sie den Alias der aufzurufenden Applikation C übergibt.
2. Die Verbindungsschicht V stellt eine Anfrage an die Zentrale Konfiguration B, in der sie den Alias der aufzurufenden Applikation C weitergibt.
3. Aus der Zentrale Konfiguration B wird die zum Alias gehörende physikalische Applikation C zurückgeliefert an die Verbindungsschicht V.
4. Die Verbindungsschicht V ruft die zum Alias gehörende physikalische Applikation C auf.
5. Die Verbindungsschicht V liefert die aufgerufene Applikation C z.B. als Objekt an die aufrufende Applikation A zurück. In der aufrufenden Applikation A müssen somit keinerlei physikalische Daten der aufzurufenden Applikation C hinterlegt werden. Die Kommunikation erfolgt ausschließlich über die Verbindungsschicht V und kann vollständig hinter dem Alias maskiert werden. Lediglich in der zentralen Konfiguration B ist auf die korrekte Zuordnung von Alias und physikalischer Applikation zu achten. Ändert sich die aufgerufene Applikation C1 wird diese Änderung in der zentralen Konfiguration abgebildet. Nach dieser Abbildung verwenden sofort alle aufrufenden Applikationen die neue physikalische Applikation, ohne dass zusätzliche Änderungen bei den aufrufenden Applikationen notwendig sind.
Die Datenmaskierung ist schematisch in Figur 2 dargestellt.
Die Maskierung der Daten ist eine Erweiterung der Applikationsmaskierung. Für jede Applikation, die Daten für andere Applikationen zur Verfügung stellt, wird mindestens ein Index errichtet, der einen geeigneten Suchschlüssel sowie zusätzlich Daten enthält. Ein Index ist somit nicht nur ein Zugriffsweg zur Identifikation bestimmter Daten, sondern dient der Zwischenschicht dazu, die Daten tatsächlich aus der aufgerufenen Applikation zu lesen. Eine Applikation kann über mehrere Indizes verfügen, um z.B. die Performance der einzelnen Indizes zu verbessern oder unterschiedliche Arten von Daten darstellen zu können.
In der zentralen Konfiguration wird für jeden Index eine Abfragekonfiguration hinterlegt aus folgenden Elementen:
■ Name der Abfragekonfiguration zur Identifikation
■ Alias der Applikation, aus der die Daten gelesen werden sollen
■ Name des Index in der Applikation
■ Liste mit Aliasnamen für die einzelnen Datenelemente, die der Index darstellt
Um Daten aus einer anderen Applikation abzufragen, muss bei der Abfrage lediglich die zu verwendende Abfragekonfiguration, der Suchschlüssel sowie der Alias des gewünschten Datenelements angegeben werden. Ruft eine Applikation Daten aus einer anderen Applikation ab, erfolgt der Aufruf wie in Figur 2 dargestellt: 1. Die Applikation A ruft die Verbindungsschicht V auf, um Daten aus Applikation C zu erhalten.
2. Die Verbindungsschicht richtet eine Abfrage an die Zentrale Konfiguration B mit dem Namen der Abfragekonfiguration.
3. Die Zentrale Konfiguration B meldet den Alias der abzufragenden Applikation C zurück.
4. Die Verbindungsschicht V richtet eine Abfrage an die Zentrale Konfiguration B mit dem Alias der abzufragenden Applikation C.
5. Aus der Zentralen Konfiguration B wird die zum Alias gehörende physikalische Applikation C zurückgemeldet.
6. Aus der Zentralen Konfiguration B wird der Name des Index in der physikalischen Applikation C zurückgemeldet, der die gewünschten Daten enthält.
7. Aus der Zentralen Konfiguration B wird eine Liste mit Aliasen der im Index verfügbaren Daten zurückgemeldet.
8. Die Verbindungsschicht V greift auf die physikalische Applikation C aus (5) zu.
9. Die Verbindungsschicht V greift auf den Index aus (6) zu.
10. Die Verbindungsschicht V sucht den zum Suchschlüssel passenden Datensatz im Index.
11. Die Applikation C liefert die gesamten Indexdaten des Datensatzes aus (10) an die Verbindungsschicht V. Diese Daten werden im Datenpuffer P abgelegt.
12. Die Verbindungsschicht V extrahiert aus den gesamten Indexdaten im Puffer P aus (11) die Daten mit dem gewünschten Datenelementalias.
13. Die Verbindungsschicht V liefert die gewünschten Daten an die aufrufende Applikation A.
Da die Verbindungsschicht V die Daten für die aufrufenden Applikationen A aus der Quellapplikation C abruft und dabei die gesamten Indexdaten liest (vgl. Schritt 11), können die abgerufenen Daten im Datenpuffer P der Verbindungsschicht V zwischengespeichert werden. Erfolgt ein erneuter Abruf von Daten für denselben Datensatz, kann die Verbindungsschicht V die Daten unmittelbar, d.h. ohne erneuten Zugriff auf die Zentrale Konfiguration B oder die Quellapplikation C, zur Verfügung stellen. Je mehr Daten also für einen Datensatz abgefragt werden, desto deutlicher der Performancegewinn gegenüber eines Zugriffs ohne die hier dargestellte Technologie. Zudem sind in der Verbindungsschicht V robuste Mechanismen hinterlegt, die Datenfehler abfangen und so Abbruche in der aufrufenden Applikation A verhindern.
Auf Basis dieses Verfahrens sind weitere Technologien möglich. Dabei werden - aus Sicht der aufrufenden Applikation - vor der Datenabfrage weitere Schritte in der Verbindungsschicht angeboten. Werden z.B. für verschiedene Applikationen immer wieder dieselben Daten benötigt (z.B. für eine Kundenapplikation Kundenname, - adresse etc.), kann die Verbindungsschicht ein Verfahren zur Verfügung stellen, das automatisch die gewünschten Daten vollständig liefert. Hierfür wird in der zentralen Konfiguration eine Definition abgelegt, die eine Datenmaskierung und eine Datenelementaliasliste aufweist.
Um alle Daten der Liste zu erhalten, muss die aufrufende Applikation eine Anfrage an die Verbindungsschicht stellen und dabei den Konfigurationsnamen sowie den Suchschlüssel übergeben. Wird dieses Verfahren eingesetzt, sind selbst umfangreiche Datenabfragen mit minimalem Aufwand in der auf rufenden Applikation realisierbar. Zudem lassen sich die Vorteile der Applikationsmaskierung sowie die Vorteile der Datenmaskierung in vollem Umfang nutzen. Ruft eine Applikation auf diese Weise Daten ab, erfolgt der Aufruf wie in Figur 3 dargestellt:
1. Die Applikation A ruft die Verbindungsschicht V auf und übergibt Konfigurationsname sowie Suchschlüssel.
2. Die Verbindungsschicht V fordert die Konfiguration von der zentralen Konfiguration an B.
3. Aus der zentralen Konfiguration B wird die entsprechende Datenmaskierung zurückgeliefert.
4. Aus der zentralen Konfiguration B wird die entsprechende Datenelementaliasliste zurückgeliefert.
5. Die Verbindungsschicht V iteriert über die Datenelementaliasliste. Für jeden Durchlauf ruft sie die Daten über das oben beschriebene Verfahren zur Datenmaskierung ab (dargestellt durch die gestrichelten Linien), wobei der Datenpuffer der Verbindungsschicht V benutzt wird.
6. Die Verbindungsschicht V gibt die gesamten ermittelten Daten an die aufrufende Applikation A zurück. Darauf aufbauend sind weitere Erweiterungen möglich. So kann die Verbindungsschicht die Daten nicht nur an die aufrufende Applikation zurückliefern, sondern bearbeiten und erst das Ergebnis retournieren. Dadurch kann die Vermittlungsschicht zentral Werkzeuge zur Verfügung stellen, die von mehreren Applikationen genutzt werden können, zentral wartbar sind und die Vorteile der Applikations- und Datenmaskierung nutzen.

Claims

Ansprüche
1. Verfahren zur Durchführung eines Zugriffs auf Datenbanken und/oder Datenfelder und/oder Applikationen (C) in einer Datenverarbeitungsanlage und/oder in einem Netzwerk von Datenverarbeitungsanlagen, wobei den Datenbanken und/oder Datenfeldern und/oder Applikationen (C) eine eindeutige Adresse zugeordnet ist, insbesondere eine IP-Adresse, ein Servername, ein Pfadname und/oder ein Dateiname oder dergleichen, dadurch gekennzeichnet, dass jeder Datenbank und/oder jedem Datenfeld und/oder jeder Applikation (C) ein Alias eineindeutig zugeordnet ist und zumindest eine Zuordnungsinstanz (B) vorgesehen ist, in der die Zuordnung von Alias zu Adresse gespeichert und von dieser abrufbar ist, und dass eine Verbindungsinstanz (V) vorgesehen ist, die bei einem versuchten Zugriff auf Datenbanken und/oder Datenfelder und/oder Applikationen (C) unter Verwendung des Alias die Adresse aus der Zuordnungsinstanz (B) abruft und sodann unter Verwendung der von der Zuordnungsinstanz erhaltenen Adresse auf die Datenbanken und/oder Datenfelder und/oder Applikationen (C) zugreift.
2. Verfahren nach Anspruch 1 , dadurch gekennzeichnet, dass die Zuordnungsinstanz (B) eine zentral abgelegte Instanz ist, insbesondere in Form einer Datenbank.
3. Verfahren nach Anspruch 1 , dadurch gekennzeichnet, dass die Zuordnungsinstanz (B) durch synchronisierte Vervielfältigungen auf einer Mehrzahl von Datenverarbeitungsanlagen gebildet ist.
4. Verfahren nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, dass sowohl jeder zugreifenden Applikation (A) als auch jeder Applikation (C), auf die zugegriffen werden soll, jeweils ein Alias zugeordnet ist.
5. Verfahren nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, dass einzelne Datenfelder und/oder Datenfeldinhalte einer Datenbank indiziert werden.
6. Verfahren nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, dass jede Applikation (A) bei einem Start zunächst ihren eigenen Alias durch Abfrage bei der Zuordnungsinstanz (B) abfragt.
7. Verfahren nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, dass Dateninhalte einer Datenbank über die Verbindungsinstanz (V) an die anfragende Applikation (A) zurückgegeben werden.
8. Verfahren nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, dass die Verbindungsinstanz (V) eine Datenverarbeitungsinstanz aufweist, die geeignet ist, die erhaltenen Daten vor einer Übergabe an die anfragende Applikation (A) zu verarbeiten.
9. Verfahren nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, dass die Verbindungsinstanz (V) einen Datenpuffer aufweist, der geeignet ist, die erhaltenen Daten zumindest zeitweise zu speichern.
10. Datenverarbeitungsanlage mit einer Applikation zur Durchführung des Verfahrens nach einem der vorherigen Ansprüche.
EP08773457A 2007-11-16 2008-06-16 Verbindungsschicht für datenbanken Withdrawn EP2208154A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102007057248A DE102007057248A1 (de) 2007-11-16 2007-11-16 Verbindungsschicht für Datenbanken
PCT/EP2008/004822 WO2009062556A1 (de) 2007-11-16 2008-06-16 Verbindungsschicht für datenbanken

Publications (1)

Publication Number Publication Date
EP2208154A1 true EP2208154A1 (de) 2010-07-21

Family

ID=39773182

Family Applications (1)

Application Number Title Priority Date Filing Date
EP08773457A Withdrawn EP2208154A1 (de) 2007-11-16 2008-06-16 Verbindungsschicht für datenbanken

Country Status (4)

Country Link
US (1) US20100274757A1 (de)
EP (1) EP2208154A1 (de)
DE (1) DE102007057248A1 (de)
WO (1) WO2009062556A1 (de)

Family Cites Families (54)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0777883B1 (de) * 1994-09-01 2003-05-02 Computer Associates Think, Inc. System und verfahren für die x.500-datenbanknorm
US5893107A (en) * 1996-07-01 1999-04-06 Microsoft Corporation Method and system for uniformly accessing multiple directory services
US6098108A (en) * 1997-07-02 2000-08-01 Sitara Networks, Inc. Distributed directory for enhanced network communication
US7165152B2 (en) * 1998-06-30 2007-01-16 Emc Corporation Method and apparatus for managing access to storage devices in a storage system with access control
GB2371901B (en) * 1999-09-21 2004-06-23 Andrew E Borthwick A probabilistic record linkage model derived from training data
US7039656B1 (en) * 1999-10-20 2006-05-02 Yodlee.Com, Inc. Method and apparatus for synchronizing data records between a remote device and a data server over a data-packet-network
US7003571B1 (en) * 2000-01-31 2006-02-21 Telecommunication Systems Corporation Of Maryland System and method for re-directing requests from browsers for communication over non-IP based networks
AU2001243597A1 (en) * 2000-03-03 2001-09-17 Radiant Logic, Inc. System and method for providing access to databases via directories and other hierarchical structures and interfaces
US20020013810A1 (en) * 2000-04-17 2002-01-31 Hwa Pang Hwee Electronic document mapping
US7032031B2 (en) * 2000-06-23 2006-04-18 Cloudshield Technologies, Inc. Edge adapter apparatus and method
AU2002230745A1 (en) * 2000-12-12 2002-06-24 Time Warner Entertainment Company, L.P. Digital asset data type definitions
US20040111530A1 (en) * 2002-01-25 2004-06-10 David Sidman Apparatus method and system for multiple resolution affecting information access
US6606690B2 (en) * 2001-02-20 2003-08-12 Hewlett-Packard Development Company, L.P. System and method for accessing a storage area network as network attached storage
US20020174236A1 (en) * 2001-03-26 2002-11-21 Sanjay Mathur Methods and apparatus for processing data in a content network
US20020198994A1 (en) * 2001-05-15 2002-12-26 Charles Patton Method and system for enabling and controlling communication topology, access to resources, and document flow in a distributed networking environment
US20030114206A1 (en) * 2001-08-24 2003-06-19 United Parcel Service Of America, Inc. Portable data acquisition and management system and associated device and method
AUPR907001A0 (en) * 2001-11-23 2001-12-20 Law Of The Jungle Pty Ltd Decision tree software application
US7257597B1 (en) * 2001-12-18 2007-08-14 Siebel Systems, Inc. Table substitution
BR0215411A (pt) * 2001-12-28 2005-09-06 Jeffrey James Jonas Métodos para processar dados e para separar registros previamente conjugados, e, meio legìvel por computador
US20030212654A1 (en) * 2002-01-25 2003-11-13 Harper Jonathan E. Data integration system and method for presenting 360° customer views
DE60336946D1 (de) * 2002-02-25 2011-06-16 Broadcom Corp System, Verfahren und Computerprogram zur Cachespeicherung von Domain-Name-System-Information in einem Netzwerkgateway
US7107285B2 (en) * 2002-03-16 2006-09-12 Questerra Corporation Method, system, and program for an improved enterprise spatial system
US7200619B2 (en) * 2002-05-31 2007-04-03 International Business Machines Corporation Method and process to optimize correlation of replicated with extracted data from disparate data sources
US20030227487A1 (en) * 2002-06-01 2003-12-11 Hugh Harlan M. Method and apparatus for creating and accessing associative data structures under a shared model of categories, rules, triggers and data relationship permissions
US20040083199A1 (en) * 2002-08-07 2004-04-29 Govindugari Diwakar R. Method and architecture for data transformation, normalization, profiling, cleansing and validation
US7433891B2 (en) * 2002-10-11 2008-10-07 Chrome Systems Corporation Data management interface capable of providing enhanced representation of imported electronic content
US7970795B2 (en) * 2002-12-10 2011-06-28 Accenture Global Services Limited Data model development tool
FI120755B (fi) * 2003-06-06 2010-02-15 Tieto Oyj Tietueiden käsittely vastinparien löytämiseksi vertailutietojoukosta
US7231396B2 (en) * 2003-07-24 2007-06-12 International Business Machines Corporation Data abstraction layer for a database
US20050240592A1 (en) * 2003-08-27 2005-10-27 Ascential Software Corporation Real time data integration for supply chain management
US20050234894A1 (en) * 2004-04-05 2005-10-20 Rene Tenazas Techniques for maintaining collections of generated web forms that are hyperlinked by subject
WO2006017362A2 (en) * 2004-07-13 2006-02-16 Freedom Software, Inc. Storing and distributing encrypted digital content
US20060230039A1 (en) * 2005-01-25 2006-10-12 Markmonitor, Inc. Online identity tracking
WO2006108069A2 (en) * 2005-04-06 2006-10-12 Google, Inc. Searching through content which is accessible through web-based forms
US20060253423A1 (en) * 2005-05-07 2006-11-09 Mclane Mark Information retrieval system and method
US20060253476A1 (en) * 2005-05-09 2006-11-09 Roth Mary A Technique for relationship discovery in schemas using semantic name indexing
US20070038674A1 (en) * 2005-08-12 2007-02-15 Arturo Bejar System and method for securely analyzing data and controlling its release
US7784038B2 (en) * 2005-10-13 2010-08-24 International Business Machines Corporation Pattern matching and transformation of intermediate language expression trees
US7836065B2 (en) * 2005-11-01 2010-11-16 Sap Ag Searching multiple repositories in a digital information system
US8121028B1 (en) * 2006-01-03 2012-02-21 Sprint Communications Company L.P. Quality of service provisioning for packet service sessions in communication networks
US7644066B2 (en) * 2006-03-31 2010-01-05 Oracle International Corporation Techniques of efficient XML meta-data query using XML table index
US8151323B2 (en) * 2006-04-12 2012-04-03 Citrix Systems, Inc. Systems and methods for providing levels of access and action control via an SSL VPN appliance
US7940735B2 (en) * 2006-08-22 2011-05-10 Embarq Holdings Company, Llc System and method for selecting an access point
US20080049629A1 (en) * 2006-08-22 2008-02-28 Morrill Robert J System and method for monitoring data link layer devices and optimizing interlayer network performance
NO325487B1 (no) * 2006-09-14 2008-05-13 Tandberg Telecom As Fremgangsmate og anordning for dynamisk streaming-/arkiveringskonfigurasjon
WO2008092147A2 (en) * 2007-01-26 2008-07-31 Information Resources, Inc. Analytic platform
US20080319983A1 (en) * 2007-04-20 2008-12-25 Robert Meadows Method and apparatus for identifying and resolving conflicting data records
US8131759B2 (en) * 2007-10-18 2012-03-06 Asurion Corporation Method and apparatus for identifying and resolving conflicting data records
CN101918961B (zh) * 2007-11-14 2015-05-06 潘吉瓦公司 评估供应交易的公共记录
US7962486B2 (en) * 2008-01-10 2011-06-14 International Business Machines Corporation Method and system for discovery and modification of data cluster and synonyms
US8380692B2 (en) * 2008-01-25 2013-02-19 Nuance Communications, Inc. Fast index with supplemental store
US7908252B1 (en) * 2008-03-19 2011-03-15 Crossroads Systems, Inc. System and method for verifying paths to a database
US8495005B2 (en) * 2009-01-14 2013-07-23 International Business Machines Corporation Methods for matching metadata from disparate data sources
US20110320433A1 (en) * 2010-06-25 2011-12-29 Microsoft Corporation Automated Joining of Disparate Data for Database Queries

Non-Patent Citations (4)

* Cited by examiner, † Cited by third party
Title
"DNS and BIND", 30 September 1998, O'REILLY, ISBN: 978-1-56592-512-0, article CRICKET LIU ET AL: "Chapter 1, Background", pages: 78 - 88, XP055346494 *
"DNS and BIND", 30 September 1998, O'REILLY, ISBN: 978-1-56592-512-0, article CRICKET LIU ET AL: "Chapter 2, How Does DNS Work?", pages: 89 - 112, XP055346497 *
CHATEL M: "Classical versus Transparent IP Proxies", NETWORK WORKING GROUP RFC 1717, INTERNET SOCIETY (ISOC) 4, RUE DES FALAISES CH- 1205 GENEVA, SWITZERLAND, CH, 31 March 1996 (1996-03-31), XP015007703 *
See also references of WO2009062556A1 *

Also Published As

Publication number Publication date
US20100274757A1 (en) 2010-10-28
DE102007057248A1 (de) 2009-05-20
WO2009062556A1 (de) 2009-05-22

Similar Documents

Publication Publication Date Title
DE3689664T2 (de) Verfahren und Gerät zur Verwaltung von veralteten Datenobjekten.
DE3852324T2 (de) Verfahren und System zur Netzwerkverwaltung.
DE69533786T2 (de) Vorrichtung zum Erzeugen von objektorientierten Schnittstellen für relationale Datenbanken und von dieser Vorrichtung durchgeführtes Verfahren
DE69832786T2 (de) Vorrichtung und verfahren zur identifizierung von klienten die an netzwer-sites zugreifen
DE69938077T2 (de) Verfahren, Vorrichtung und Programmspeichereinrichtung für einen Klienten und ein adaptiver Synchronisierungs- und Transformierungsserver
DE19747583B4 (de) Kommunikationssystem und Verfahren
DE69031164T2 (de) Zeitlich begrenztes zentrumsystem für dezentralisiertes datenbanksystem
DE602004001010T2 (de) Verfahren und System um auf peer to peer Netzen zuzugreifen
EP0829046B1 (de) Setup-verfahren und setup-system für benutzerprogramme, sowie benutzerrechner in einem rechnernetz
DE69634650T2 (de) Telekommunikationsdienstwechselwirkungen
DE4218025A1 (de) Datenspeicherverwaltungssystem und verfahren mit speicherzuordnung auf der basis nachgefragter dienstklassen
DE69127399T2 (de) Verfahren zur automatischen Löschung vorübergehender Dokumentverbindungen in einem Datenverarbeitungssystem
DE10311074A1 (de) Verfahren und Anordnungen in einem Telekommunikationsnetz
DE102007037646A1 (de) System und Verfahren zum Indizieren, Durchsuchen und zur Datenwiedergewinnung von Datenbanken
EP2250588B1 (de) Verfahren und programm zum bereitstellen von datenkohärenz in netzwerken
DE69704304T2 (de) Flexibles Einhängen und Abhängen von benutzerauswechselbaren Medien
DE20020773U1 (de) Servereinrichtung zum Übertragen elektronischer Datenmengen
EP2208154A1 (de) Verbindungsschicht für datenbanken
DE20119114U1 (de) Kommunikationssystem, sowie zentraler Computer
EP1239377A1 (de) Datenorganisationssystem und Verfahren zur Gliederungsstrukturverwaltung und -synchronisation
DE10310415A1 (de) Verfahren zur An- und Abmeldung von Produkten und deren gefärbten Einstellungen
EP1332461A2 (de) Verfahren zur verknüpfung von unterschiedlichen zielgruppen sowie ein geeignetes system hierfür
EP1249991A2 (de) Verfahren zum Betrieb eines automatischen Fernsprech-Auskunftssystems
DE10017608B4 (de) Verfahren zur Durchführung von Operationen in einem Datenbanksystem
EP1308860A2 (de) Verfahren zum Auffinden und Anbieten von Informationen und Diensten in einem Kommunikationsnetzwerk sowie entsprechendes Kommunikationssystem

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20100406

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MT NL NO PL PT RO SE SI SK TR

AX Request for extension of the european patent

Extension state: AL BA MK RS

DAX Request for extension of the european patent (deleted)
17Q First examination report despatched

Effective date: 20170308

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20170719