DE10031716A1

DE10031716A1 - Abonnement und Benachrichtigung bei Datenbanktechnik

Info

Publication number: DE10031716A1
Application number: DE10031716A
Authority: DE
Inventors: Frank Leymann; Dieter Roller
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 1999-07-06
Filing date: 2000-06-29
Publication date: 2001-01-25
Anticipated expiration: 2020-06-30
Also published as: JP2001043248A; US6826560B1; DE10031716B4; JP3996328B2

Abstract

Die vorliegende Erfindung legt allgemein dar, wie aktive Datenbanktechnik und erweiterungsfähige Datenbanktechnik, d. h. Auslöser und benutzerdefinierte Funktionen, zum Verarbeiten von Abonnements wirksam ausgenutzt werden können. DOLLAR A Nach einem ersten Aspekt der vorliegenden Erfindung wird vorgeschlagen, alle Abonnements zu einer bestimmten Tabelle, oder allgemeiner zu einer Vielzahl von Tabellen, in einem einzigen Auslöser an dieser Tabelle beziehungsweise diesen Tabellen zusammenzufassen. Dies wird die auf Auslösern beruhende Leistungsfähigkeit außerordentlich erhöhen. DOLLAR A Nach einem zweiten Aspekt der vorliegenden Erfindung wird vorgeschlagen, die Informationen, auf die sich ein Abonnent eingetragen hat, über geeignete benutzerdefinierte Funktionen direkt aus dem Adressraum des Datenbanksystems bereitzustellen, was eine weitere Quelle zur Verbesserung der Leistungsfähigkeit Effizienz darstellt.

Description

1. GRUNDLAGEN DER ERFINDUNG 1.1 GEBIET DER ERFINDUNG

Die vorliegende Erfindung gehört zum Bereich von Benachrichtigungssystemen und Nachrichtenvermittlung. Insbesondere bezieht sich die vorliegende Erfindung auf den Bereich der Verarbeitung von Benachrichtigungen und insbesondere auf Veröffentlichungs- und Abonnementanforderungen.

1.2 BESCHREIBUNG UND NACHTEILE DES STANDES DER TECHNIK

Die vorliegende Erfindung hat einen sehr allgemeinen Umfang. Ihre grundlegenden Prinzipien können in jeder Lage gelten, in der ein beliebiger Benachrichtigungsvorgang oder eine Vermittlung und insbesondere Veröffentlichungs- und Abonnementvorgänge stattfinden.

Die vorliegende Erfindung fuhrt die Datenbanktechnik in diese Interessengebiete ein. Es sollte sich verstehen, dass im Sinne dieser Erfindung das Datenmodell des Datenbanksystems nicht von Bedeutung ist. Ebenso konnte das Datenbanksystem auf Platte vorhandene Daten verwalten oder Daten im Hauptspeicher verwalten, d. h. eine Hauptspeicherdatenbank. Nichtsdestotrotz wird die Terminologie der relationalen Datenbanksysteme hier der Einfachheit und der besseren Klarheit halber durchgehend benutzt.

Im Allgemeinen ist ein Nachrichtenvermittler ein Werkzeug, das in einer Lage angewandt wird, in der Nachrichten von einer Vielzahl von Nachrichtenquellen m oft und manchmal periodisch an eine Vielzahl von Nachrichtensenken n in einer Beziehung m/n gesendet werden. Spezielle Fälle von 1 : m und n : 1 treten ebenfalls auf. Nachrichtenvermittler "nutzen gemeinsam" Nachrichten auf eine Weise, dass eine Quelle - oftmals ist dies eine beliebige Art von Programmanwendung - nur eine Nachricht senden muss und der Vermittler eine oder mehrere Versionen davon an einer oder mehreren Senken abliefert, die oftmals auch Anwendungen sind. Weitere Einzelheiten über Nachrichtenvermittlungssysteme sind bei R. Schulte, Message Brokers: A focussed approach to application integration, Gartner Group, Stategic Analysis Report SSA R-401-102 von 1996 zu finden.

Insbesondere ist ein Nachrichtenvermittler so etwas wie ein Mittelpunkt, in den Nachrichten einfließen und aus dem sie herausströmen. Die Nachrichten, die in den Vermittler einfließen, werden hier nachstehend als zum Veröffentlichen bezeichnet. Nachrichten, die aus dem Vermittler herausströmen, werden als abonniert betrachtet. Eine Teilnahmeanforderung gibt die Untermenge aller ankommenden Nachrichten, an denen eine bestimmte Anwendung interessiert ist, und das Format an, in dem sie dem Abonnenten vorgelegt werden soll.

Beispielsweise könnten verschiedene Aktienbörsen periodisch Aktiendaten veröffentlichen, d. h., die Aktiendaten werden an den Nachrichtenvermittler geschickt. Jede Aktienbörse könnte ein unterschiedliches Format benutzen, um ihre Daten zu übertragen. Ein Abonnent könnte auf alle Nachrichten über die Aktiendaten von IBM eingetragen sein, die 103 Dollar überschreiten, und könnte ihre Bereitstellung im XML-Format verlangen.

Bei Nachrichtenvermittlern nach dem Stand der Technik, die Veröffentlichungs-/Abonnementfunktionen bereit stellen, wird großer Aufwand dafür getrieben, die veröffentlichten Nachrichten und die Abonnements zu verwalten. Diese Verwaltung wird üblicherweise unter Verwendung eigener Mechanismen durchgeführt. Die vorliegende Erfindung schlägt vor, objektbezogene Datenbanktechnik zu benutzen, um Veröffentlichungs-/Abonnementfunktionen einzurichten.

Nachrichtenverwalter nach dem Stand der Technik befassen sich üblicherweise mit Nachrichten, die veröffentlicht werden und die Abonnenten wissen möchten. Abonnenten sind jedoch nicht einfach an Nachrichten interessiert, die veröffentlicht werden, sondern auch an Veränderungen, die an Daten vorgenommen worden sind, die in einer oder mehrerer Tabellen in einer oder mehreren Datenbanken gespeichert sind. Die vorliegende Erfindung gestattet es, diese Funktion auf der Grundlage der objektbezogenen Datenbanktechnik zu realisieren.

So würde es wünschenswert sein, diese große Menge an Aufwand für das Programmieren und die Kundenanpassung zu vermindern. Die vorstehend zitierte Quelle für den Stand der Technik hat eine Untersuchung vorgenommen, um die Verwendbarkeit von Datenbanktechnik zu analysieren, um als Grundlage für Nachrichtenvermittlung benutzt zu werden. Die Schlussfolgerung ist jedoch, dass Datenbanksystemen viele Merkmale fehlen, die zur Nachrichtenvermittlung notwendig sind, d. h. die Vermittlungstechnik, die zur Durchführung der Vermittlung entwickelt worden ist, wie etwa Schnittstellenmaschinen und Nachrichtenvermittlungsstellen. Damit wird in der vorstehend zitierten Quelle eine Datenbanktechnik als Grundlage für Nachrichtenvermittlung mehr oder weniger zurückgewiesen, da sie zu schwierig und kompliziert zu realisieren und vom Leistungsvermögen her zu langsam ist.

Wenn das Verhalten der Veröffentlichungs-/Abonnementtechnik unter Verwendung einer datenbankorientierten Sicht analysiert wird, kann die folgende Beobachtung gemacht werden: eine Abonnementanforderung ist einer Abfrage gleich. Beruhend auf dem, was in der Abonnementanforderung vorgegeben worden ist, werden Nachrichten heraus gefiltert und an ihren Empfänger übermittelt. Aber es gibt einen grundlegenden Unterschied der Betriebsweise bei einer Anfrage und einem Abonnement: ein Abonnement arbeitet nicht mit allen Nachrichten, die beispielsweise in einem Nachrichtendepot gespeichert sind, sondern nur an einer einzelnen Nachricht gleichzeitig, nämlich der Nachricht, die gerade an den Nachrichtenvermittler veröffentlicht worden ist. Weiterhin werden üblicherweise viele Abonnements bei einem Nachrichtenvermittler registriert werden, d. h. das Kennzeichnen von Abonnements mit Abfragen wird zu der Lage führen, in der viele Abfragen für eine einzige Nachricht ausgewertet werden müssen: diese Situation kehrt die Lage um, die üblicherweise in Abfragesystemen auftritt, bei denen die Anzahl von Datenposten, die geprüft werden sollen, die Anzahl der Abfragen um viele Größenordnungen übersteigt.

Der Vorschlag der vorliegenden Erfindung, objektbezogene Datenbanktechnik für Veröffentlichungs-/Abonnementtechnik zu benutzen, sieht sich zwei Problembereichen gegenüber, die gelöst werden müssen:
erstens, wie sind Betriebsdaten wirksam effizient zu kennzeichnen, die so bedeutsam sind, dass sie veröffentlicht werden, und
zweitens, wie sind Abonnements auf der Grundlage extern verlagerter Datenbanktechnik wirksam zu realisieren?

Der erste Problembereich rührt von der Tatsache her, dass die meisten Nachrichtenvermittler nicht auf der Grundlage der Datenbanktechnik eingerichtet worden sind, und dass in Geschäftsumgebungen, die einen natürlichen Bedarf an für das Management bedeutsamen Unternehmensdaten haben, bestimmte Veränderungen von beispielsweise Betriebsdaten oftmals als Vorkommnisse angesehen werden, die für äußere Anwendungen von Bedeutung sind. Dies wird in Fig. 1 dargestellt:

Wenn beispielsweise in eine Tabelle ein neues Tupel eingefügt wird, möchte eine Person über eine entsprechende e-Mail über diese Tatsache informiert werden, oder es muss deswegen eine Anwendung aufgerufen werden, oder ein Nachrichtenvermittler hat seinerseits Abonnenten, die diese Daten haben möchten. Damit kann die Datenbank als Quelle für Veröffentlichungen angesehen werden.

Insbesondere wenn ein Nachrichtenvermittler benutzt wird, um die Abonnementanforderungen für Veränderungen an Betriebsdaten zu verwalten und damit die Änderungen der Betriebsdaten an den Nachrichtenvermittler veröffentlicht werden müssen, wird die Bedeutung des Vorfilterns von Veröffentlichungen augenscheinlich. Wenn jede aus einer riesigen Anzahl von Veränderungen von Betriebsdaten an den Nachrichtenvermittler geschoben wird, der dann ermittelt, ob ein Abonnent für die betreffende Veränderung vorhanden ist oder nicht, werden Massen von Daten unnötigerweise verarbeitet. Dies würde einer Verschwendung von Betriebsmitteln gleich kommen. Damit ist das Bereitstellen von Abonnementfunktionen innerhalb eines Datenbanksystems im Allgemeinen von Nutzen.

Andernfalls müssen, wenn innerhalb des Datenbanksystems von Natur aus keine Abonnementmerkmale bereitgestellt werden, die modifizierten Daten in eine Nachricht umgewandelt werden, müssen dann gesendet werden, d. h. an einen getrennten Nachrichtenvermittler veröffentlicht werden, und dieser Nachrichtenvermittler muss alle entsprechenden Abonnenten ermitteln. In dieser Verfahrensweise würde die Datenbank nur als Herausgeber betrachtet werden, die Abonnementmaschine des Nachrichtenvermittlers wird dafür benutzt zu ermitteln, ob irgend ein Abonnent an den modifizierten Daten interessiert ist oder nicht.

Wenn kein Abonnent an dieser Datenübertragung, die zugehörige Datenumwandlungen usw. enthält, zwischen dem Datenbanksystem und dem Nachrichtenvermittler interessiert ist, wird viel Arbeit und Datenverkehr vergebens ausgeführt, wobei auf die Gesamtumgebung eine unnötige Belastung einwirkt. Weiterhin würde die Benutzung einer getrennten Abonnementmaschine die Tatsache vernachlässigen, dass die Abfragefähigkeit des Datenbanksystems unmittelbar benutzt werden kann, um die Abonnements direkt zu verarbeiten, ohne dass eine getrennte Nachrichtenvermittlermaschine benötigt wird - dies wird die Leistungsfähigkeit weiter verbessern.

Das zweite Problem befasst sich mit der Leistungsfähigkeit beim Einrichten von Abonnements, die auf der Datenbanktechnik selbst beruhen. Fast alle relationalen Datenbanksysteme unterstützen heute Auslösemechanismen. Auslöser gestatten es, auf der Grundlage eines registrierten Interesses an bedeutsamen Veränderungen an Daten automatisch eine Aktion durchzuführen. Es scheint so, als ob es ein Anzeichen zum Erkennen einer "natürlichen" Übereinstimmung zwischen Auslösern und Abonnements gäbe: jede Abonnementanforderung ist einfach auf einen entsprechenden Auslöser abzubilden.

Es soll beispielsweise angenommen werden, dass eine AKTIEN-Tabelle Zeilen enthält, die den NAMEN einer Firma, ihren derzeitigen Aktien-PREIS und die gehandelte MENGE aufzeichnen. Dann wird jedes Abonnement für modifizierte Aktiendaten auf einen getrennten Auslöser in dieser Tabelle abgebildet. Hier wird für eine beispielhafte Abbildung eines bestimmten Abonnements auf Fig. 2 Bezug genommen. Wenn eine Anzahl von S(T) Abonnenten, wobei T eine Abkürzung von Tabelle ist, auf Veränderungen an einer gegebenen Tabelle T eingetragen sind und eine Anzahl n(T) Veränderungen pro Sekunde an dieser Tabelle erfolgen, müssen für Tabelle T S(T) × n(T) Auslöser pro Sekunde betrieben werden; in der Praxis ist diese Anzahl sogar noch größer, weil für Abonnements mehr als eine Tabelle von Interesse ist. Wenn es pro Sekunde 10 Veränderungen an der Aktientabelle, wobei angenommen wird, dass dies eine sehr bescheidene Anzahl ist, und 100 Abonnements gibt - was ebenfalls bescheiden ist - müssen an dieser einzigen Tabelle 1000 Auslöser betrieben werden. Dies liegt außerhalb des Umfanges der derzeitigen Datenbanktechnik.

1.3 AUFGABEN DER ERFINDUNG

Es ist daher die Aufgabe der vorliegenden Erfindung, ein Verfahren und System zur wirksamen Nutzung der Datenbanktechnik für Benachrichtigungen und insbesondere für Abonnements bereitzustellen.

2. ZUSAMMENFASSUNG UND VORZÜGE DER ERFINDUNG

Diese Aufgaben der Erfindung werden durch die Merkmale erfüllt, die in den beigefügten unabhängigen Ansprüchen angegeben werden. Weitere vorteilhafte Anordnungen und Ausführungsformen der Erfindung werden in den jeweiligen Unteransprüchen ausgeführt.

Die vorliegende Erfindung behandelt im Allgemeinen, wie aktive Datenbanktechnik und erweiterungsfähige Datenbanktechnik, d. h. Auslöser und benutzerdefinierte Funktionen, zum Verarbeiten von Abonnements wirksam zu nutzen sind.

Nach einem ersten Aspekt der vorliegenden Erfindung wird vorgeschlagen, alle Abonnements auf einer bestimmten Tabelle, oder allgemeiner auf einer Vielzahl von Tabellen, in einem einzigen Auslöser an dieser Tabelle beziehungsweise diesen Tabellen zusammenzufassen. Dies wird die auf Auslösern beruhende Effizienz außerordentlich steigern.

Nach einem zweiten Aspekt der vorliegenden Erfindung wird vorgeschlagen, die Information einem darauf eingetragenen Abonnenten dadurch zur Verfügung zu stellen, dass die vom Datenbanksystem bereitgestellte Fähigkeit benutzerdefinierter Funktionen ausgenutzt wird. Dies gestattet das Erzeugen von Information, die vom Adressraum aus, den die Datenbank betreibt, an die Abonnenten geschickt werden soll, dies ist eine weitere Quelle von Leistungssteigerungen.

Die gesamte Verarbeitung kann damit wie folgt zusammengefasst werden:

Wenn für eine Tabelle T ein erstes Abonnement eingetragen wird, wird an der Tabelle T diese Art von "zusammengefasstem Abonnementauslöser" erzeugt, und eine Sammlung von sogenannten Metadatentabellen wird erzeugt, die für das Festhalten aller Abonnements für die Tabelle T geeignet ist, sie wird als AKTIVIERUNGSTABELLE bezeichnet und in Fig. 3 dargestellt. Es sollte angemerkt werden, dass diese Funktion auch als getrenntes Dienstsprogramm eingerichtet werden kann, das beispielsweise durch einen Administrator ausdrücklich aufgerufen wird.

Bevorzugte Ausführungsformen zum Erzeugen geeigneter Metadatentabellen und zum Erzeugen zusammengefasster Abonnementauslöser werden später ausführlicher beschrieben.

Jedes einzelne Abonnement wird durch "einfaches" EINFÜGEN von geeigneten Tupeln in diese letzteren Metadatentabellen widergespiegelt, d. h., nach der Erfindung wird kein getrennter Auslöser erzeugt, und an dem einzelnen Abonnementauslöser muss keine Veränderung vorgenommen werden.

Eine bevorzugte Ausführungsform zum Widerspiegeln eines Abonnements in Form von Tupeln in der Metadatenbank wird ausführlich beschrieben.

Wenn in Tabelle T ein Tupel manipuliert wird, das einer Veröffentlichung in einem gewöhnlichen Nachrichtenvermittler nach dem Stand der Technik entspricht, springt der entsprechende Auslöser an und ermittelt in einem einzigen Aufruf alle Abonnenten, die an der Veränderung von Tupeln interessiert sind.

Das Benutzen eines einzigen Abonnementauslösers, um den gewünschten wirksamen Gebrauch der Auslösermerkmale des Datenbanksystems zu machen, hat seinen Preis: die Abfrage im Hauptteil des Auslösers muss komplizierter sein als die grundlegende Suche nach allen möglichen Abonnenten in den zugehörigen gesammelten Metadatentabellen. In Abhängigkeit von der Ausführungsform der vorliegenden Erfindung könnte dies mindestens eine Verbindung mit n Wegen betreffen, wobei n die Anzahl der Vergleichsoperatoren ist, die in Abonnementfiltern für die Zieltabelle unterstützt werden. Es ist jedoch ein Tatbestand, dass Abfragesysteme seit Jahrzehnten optimiert worden sind, um sehr wirksam Verbindungen mit n Wegen auszuführen.

Unter Bezugnahme auf die Benachrichtigung, die durch den Datenbankauslöser veranlasst wird, sollte erwähnt werden, dass das Konzept der Erfindung in dieser Hinsicht sehr allgemein ist. Benachrichtigung könnte beispielsweise bedeuten, dass eine Nachricht im Sinne eines Nachrichtensystems gesendet wird, dass an einem durch eine Objektdiensteinheit verwalteten Objekt eine Aktion ausgeführt wird oder dass an den Abonnenten eine e-Mail geschickt wird. Sie könnte sogar in eine für jeden Abonnenten geführte Tabelle eingefügt werden, die es dem Abonnenten gestattet, durch Abfragen der Tabelle die entsprechenden Benachrichtigungen abzurufen.

Im Hinblick auf den zweiten Aspekt der vorliegenden Erfindung, wie er vorstehend erwähnt worden ist, kann der tatsächliche Aufbau der Benachrichtigung, die an jeden vorgegebenen Abonnenten geschickt werden soll, auf der Grundlage einer sogenannten benutzerdefinierten Funktion erfolgen, die nachstehend hier als UDF bezeichnet wird: während das Filter der Abfrage im Hauptteil des Auslösers die vorzugebenden Abonnenten ermittelt, kann die Auswahlklausel der Abfrage auf eine benutzerdefinierte Funktion verweisen, welche die Übermittlung der Benachrichtigung an jeden Abonnenten auslöst. Diese Übermittlungs-UDF wird für jeden vorgegebenen Abonnenten vom Datenbanksystem automatisch aufgerufen. Die Übermittlungsfunktion erhält alle Daten, die erforderlich sind, um die Benachrichtigung zusammenzustellen, z. B. die zutreffenden Werte des veränderten Tupels, welches das Ansprechen des Auslösers veranlasst hat, die Empfängeradresse usw., wodurch zusätzliche Verbindungen erforderlich sein könnten. Auf der Grundlage dieser übermittelten Daten stellt die Übermittlungsfunktion die Benachrichtigung zusammen und schickt sie z. B. über ein Nachrichtenwarteschlangensystem, wie etwa MQSeries, über e-Mail usw. an die Adresse der Empfänger. Eine bevorzugte Ausführungsform der Übermittlungs-UDF wird später ausführlicher beschrieben.

Vorteilhafterweise gestattet es die vorliegende Erfindung, einen leistungsfähigen Abonnementmechanismus auf den vorhandenen Datenbankfunktionen aufzubauen. An dem Datenbanksystem sind keinerlei Veränderungen vorzunehmen. Damit wird ermöglicht, ein objektbezogenes Standarddatenbanksystem so wie es ist zu benutzen, um eine Veröffentlichungs-/Abonnementmaschine einzurichten. Darüber hinaus gestattet es der beschriebene Abonnementmechanismus auch, eine Datenbank in einen Herausgeber von Nachrichten umzuwandeln.

3. KURZE BESCHREIBUNG DER ZEICHNUNGEN

Die vorliegende Erfindung wird mit Hilfe von Beispielen veranschaulicht und wird durch die Form der Figuren der zugehörigen Zeichnungen nicht eingeschränkt, in denen:

Fig. 1 eine schematische Darstellung einer Datenbank in der Rolle eines Herausgebers nach der vorliegenden Erfindung ist,

Fig. 2 ein schematischer Auszug eines SQL-Codes ist, der das Abbilden von Abonnements auf Auslöser nach der vorliegenden Erfindung zeigt,

Fig. 3 eine schematische Skizze ist, die das Einrichten und den Gebrauch eines einzelnen Abonnementauslösers pro Tabelle nach der vorliegenden Erfindung veranschaulicht,

Fig. 4 eine Schema von Metadatentabellen nach der vorliegenden Erfindung ist,

Fig. 5 eine schematische Skizze ist, die das Abbilden von Abonnements auf Tupels in dem Metadatentabellen nach der vorliegenden Erfindung veranschaulicht,

Fig. 6 eine schematische Skizze von Beispieltabellen ist, die das Abbilden von Abonnements auf Tupels in den Metadatentabellen nach der vorliegenden Erfindung veranschaulicht,

Fig. 7 ein schematischer Auszug eins SQL-Codes ist, der einen bevorzugten Musterabonnementauslöser nach der vorliegenden Erfindung zeigt, und

Fig. 8 eine schematische Skizze ist, welche die Rolle der benutzerdefinierten Übermittlungsfunktion UDF in dem zusammengefassten Auslöser nach der vorliegenden Erfindung veranschaulicht.

4. BESCHREIBUNG DER BEVORZUGTEN AUSFÜHRUNGSFORM 4.1 EINFÜHRUNG IN DIE BEVORZUGTE AUSFÜHRUNGSFORM

Ehe die Elemente einer bevorzugten Ausführungsform der vorliegenden Erfindung erörtert werden, sollte angemerkt werden, dass angenommen werden kann, dass im ODER-Normalformat ein Abonnementfilter P vorgegeben ist; dies ist keine Einbuße an Allgemeingültigkeit, da hinreichend bekannt ist, dass jedes Filter in diese Form umgewandelt werden kann und wie dies erfolgt.

Damit kann das Abonnementfilter P dargestellt werden als P = B1 V. . .V Bk, wobei sich jedes Bj im folgenden Format befindet:

B_j = A(_j1 ~ _j1 v_j1 Λ. . .Λ A_jnj ~ _jnj v_jnj)

In einem derartigen Ausdruck ist Aji ein Attribut der Tabelle, für die das Abonnement gilt, ~ij ist ein Vergleichsoperator (z. B. <, ≧, <, ≦, =, ≠, GLEICH, . . .), der für die Domäne von Aji gilt, und vji ist ein Wert aus der Domäne von Aji. Zusammengefasst hat ein Abonnementfilter das folgende Format:

P = (A₁₁ ~ ₁₁ v₁₁ Λ. . .Λ A_1n1 ~ _1n1 v_1n1) V. . .V (A_k1 ~ _k1 v_k1 Λ. . .Λ A_knk ~ _knk v_knk)

In Abhängigkeit von der Ausführungsform der Metadatentabellen, die benutzt werden, um Abonnements festzuhalten, könnten weitere Einschränkungen beim Aufbau der Filter gelten. Beispielsweise nimmt die nachstehend erörterte Ausführungsform an, dass in jeder UND-Verknüpfung B_j = (A_j1 ~ v_j1 Λ. . .Λ A_jnj ~ _jnj v_jnj) ein Attribut höchstens einmal mit einem bestimmten Vergleichsoperator erscheint, d. h.

∍ 1 ≦ j ≦ k ∍ 1 ≦ x, y ≦ nj : A_jx = A_jy Λ ~ _jx = ~_jy ⇒ v_jx = ν_jy

4.2 AUSFÜHRLICHE BESCHREIBUNG

Unter Bezugnahme auf Fig. 4 wird, wenn eine Tabelle T = {A1, . . . Aq} für Abonnements aktiviert ist, eine Sammlung von Metadatentabellen eingerichtet, die alle Abonnements zu dieser Tabelle festhalten wird. Es ist offenkundig, dass für diese Metadatentabellen verschiedene Alternativen vorhanden sind, und die grundlegende Verfahrensweise der Erfindung nimmt keinerlei bestimmten Aufbau an. Zur Erläuterung wird die folgende Verfahrensweise beim Ableiten der erforderlichen Metadatentabellen vorgeschlagen.

Der Mechanismus TABELLE AKTIVIEREN, der beispielsweise als Datenbank-Dienstprogramm oder neues SQL-DDL-Element bereitgestellt werden könnte, nimmt den Namen T der Tabelle, die aktiviert werden soll, genau so an wie die Liste von Vergleichsoperatoren {~1, . . .~m}, die bei Abonnements unterstützt werden sollen; wenn zusätzlich zu neu erzeugten Tupeln auch Aktualisierungen oder Löschungen von Tupeln als Veröffentlichungen behandelt werden sollen, gestattet es ein weiterer Parameter, dies vorzugeben. Auf der Grundlage dieser Eingabe wird die Anforderung TABELLE AKTIVIEREN die Sammlung von Metadatentabellen und auch den zusammengefassten Abonnementauslöser erzeugen. Als Nächstes ist nachstehend eine Mustersyntax für die Anforderung zur Tabellenaktivierung gegeben:

TABELLE AKTIVIEREN Tabellenname, [Vergleichsliste], Liste der Auslösungsveröffentlichungen

Eine aus Muster dienende Ausführungsform der Verarbeitung, die stattfindet, wenn die Anforderung TABELLE AKTIVIEREN durchgeführt wird, wird für jeden Vergleichsoperator ~∈{~1, . . .~m}, der in der Liste von Vergleichsoperatoren angegeben ist, eine Tabelle T-~ = {Abonnent, A1, . . ., Aq, ANDID) erzeugen. Die Tabelle T-~, die dafür benutzt wird, Tupels festzuhalten, welche die verschiedenen einzelnen Ausdrücke einer UND-Verknüpfung des Abonnementfilters widerspiegeln, wird später unter Bezugnahme auf Fig. 5 beschrieben.

Der Auslöser, der für diese Ausführungsform erzeugt wird, soll ausführlicher unter Bezugnahme auf Fig. 6 beschrieben werden.

Unter Bezugnahme auf Fig. 4 wird für Abonnements über die Anforderung TABELLE Aktien AKTIVIEREN, [EQ, NE, GT, LT], [INSERT] das Einfügen von Tupeln in die Tabelle Aktien = {Name, Preis, Menge} aktiviert, wobei EQ "gleich" bezeichnet, NE "nicht gleich" bezeichnet usw. Fig. 4 beschreibt die Metadatentabellen Aktien-EQ, Aktien-NE, Aktien-GT, Aktien-LT, die durch diese Anforderung erzeugt werden.

Unter Bezugnahme auf Fig. 5 werden Abonnements ausführlicher beschrieben, und es wird beschrieben, wie sie auf die vorstehend erwähnten Tupel in den Metadatentabellen abgebildet werden können.

Abonnementfilter für Tabelle T = {A1, . . ., Aq) werden wie folgt als Tupel in den Metadatentabellen T-~1, . . ., T-~m der als Muster dienenden Ausführungsform von Fig. 4 widergespiegelt:

Jede UND-Verknüpfung Bj = (A_jl ~ _jl v_jl Λ. . .Λ A_jnj ~ _jnj v_jnj) eines Filters P = B1 V. . .V Bk einer Abonnementanforderung für Abonnent S entspricht genau einem Tupel in jeder der Tabellen T-~1, . . ., T-~m. Die Spalte ANDID jeder der Tabellen T-~i wird den ganzzahligen Wert j festhalten, und die Spalte Abonnent wird den Wert ,S' festhalten (d. h. einen eindeutigen Bezug auf die erforderliche Information über den Abonnenten).

Für jeden Vergleichsoperator ~i werden alle Einzelausdrücke Ajp ~jp vjp, die in UND-Verknüpfung Bj erscheinen, für ~jp = ~i ermittelt.

Die entsprechende Spalte Ajp von Tabelle T-~i wird auf den Wert vjp gesetzt. Bei einem Attribut A, das mit Vergleichsoperator ~i in Bj nicht in einem Einzelausdruck erscheint, wird der Wert von A in dem Tupel innerhalb von T-~i entsprechend Bj auf NULL gesetzt.

Es sollte angemerkt werden, dass für den Fall, dass eine UND-Verknüpfung Bj eines Abonnementfilters für Abonnent S keinerlei Einzelausdruck mit Vergleichsoperator ~i enthält, die Tabelle T-~i ein Tupel (,S', NULL, . . ., NULL, j) festhalten wird, um diese Tatsache widerzuspiegeln. Jedes Abonnementfilter P = B1 V. . .V Bk wird damit zu genau k Tupeln in jeder der Metadatentabellen T-~1, . . ., T-~m führen.

Unter Bezugnahme auf Fig. 6 wird eine Sammlung von Mustern von Abonnementfiltern dargestellt, und es wird dargestellt, wie jedes von ihnen als Tupel in den als Muster dienenden Tabellen der Muster-Ausführungsform von Fig. 4 dargestellt wird. Nur die Metadatentabellen für Aktien-EQ und Aktien-GT werden in dieser Figur als Beispiele gezeigt.

Es gibt vier beispielhafte Abonnenten Frank, Peter, Don und Janet.

Die vorliegende Erfindung wird ausführlicher beschrieben, namentlich der Gebrauch dessen, dass Abonnent Frank an Aktien-Tupeln mit Namen ,IBM' interessiert ist. Das Abonnementfilter besteht aus einer einzigen UND-Verknüpfung, d. h., ein einziges Tupel in jeder der Metadatenbanken bildet dieses Filter ab. Da innerhalb des Filters kein Ausdruck den GT-Operator betrifft (d. h. "<"), wird das Tupel (,Frank', NULL, NULL, NULL, 1) in Aktien-GT eingefügt. Das einzige Attribut von Aktien, das in der UND-Verknüpfung mit Vergleichsoperator "=" erscheint, ist Name; d. h., das sich ergebende Tupel in Aktien-EQ ist (,Frank', ,IBM', NULL, NULL, 1).

Peter ist auf Aktieninformation über IBM abonniert, aber nur für den Fall, dass der Aktienpreis mehr als 200 beträgt. Wiederum besteht dieses Filter aus einer einzigen UND-Verknüpfung, d. h., ein einziges Tupel in jeder der Metadatentabellen wird dafür ausreichen, das Filter darzustellen. Der einzige Einzelausdruck, der den "="-Vergleich betrifft, ist "Name = ,IBM'", d. h., das entsprechende Tupel in Aktien-EQ ist (,Peter', ,IBM', NULL, NULL, 1). Ein Attribut des Filters ist von einem Vergleich "<" betroffen, nämlich das Attribut "Preis": Preis < 200. Dies führt zu folgendem Tupel in Aktien-GT: (,Peter', NULL, NULL, 200, 1).

Don ist auf Aktieninformation über IBM abonniert, aber nur für den Fall, dass der Aktienpreis größer als 190 ist und die gehandelte Menge mehr als 100 Anteile beträgt. Wiederum besteht dieses Filter aus einer einzigen UND-Verknüpfung, d. h., ein einziges Tupel in jeder der Metadatentabellen reicht dafür aus, das Filter darzustellen. Der einzige Einzelausdruck, der den "="-Vergleich betrifft, ist "Name = ,IBM'", d. h., das entsprechende Tupel in der Aktien-EQ lautet (,Don', ,IBM', NULL, NULL, 1). Zwei Attribute des Filters sind von einem Vergleich "<" betroffen, nämlich die Attribute "Preis" und "Menge": Preis < 190 und ebenso Menge < 200. Dies führt zu dem folgenden Tupel im Aktien-GT: (,Don', NULL, 190, 200, 1)

Das Filter von Janet besteht aus zwei UND-Verknüpfungen, nämlich "Name = ,IBM' UND Preis < 200" ebenso wie "Name ,SAP' UND Preis < 1000 UND Menge < 500". Die erste UND-Verknüpfung führt zu dem Tupel (,Janet', ,IBM', NULL, NULL, 1) in der Tabelle Aktien-EQ und dem Tupel (,Janet', NULL, 200, NULL, 1) in der Tabelle Aktien-GT. Die zweite UND-Verknüpfung wird dadurch widergespiegelt, dass (,Janet', ,SAP', NULL, NULL, 2) und (,Janet', NULL, 1000, 500, 2) in die Tabellen Aktien-EQ beziehungsweise Aktien-GT eingefügt werden.

Unter Bezugnahme auf Fig. 7 wird die Erzeugung von Abonnementauslösern ausführlicher beschrieben.

Fig. 7 zeigt den Auslöser, der durch die Anforderung TABELLE AKTIVIEREN in unserem Aktienbeispiel auf der Grundlage unserer als Muster dienenden Ausführungsform erzeugt wird.

Der Hauptteil des Auslösers besteht aus einer Auswahlanweisung, die der Ausführungsform entspricht, die zum Erzeugen der Metadatentabellen und zum Darstellen von Abonnements in diesen Metadatentabellen erörtert wurde, die unter Bezugnahme auf Fig. 4 beziehungsweise 5 beschrieben worden sind.

Das Verarbeiten dieser Anweisung an sich durch ein relationales Datenbanksystem ist allgemein bekannt und für die vorliegende Erfindung ohne Bedeutung. Damit erfordert es hier keine weitere Erklärung.

Unter Bezugnahme auf Fig. 8 wird der zweite bevorzugte Aspekt der vorliegenden Erfindung ausführlicher beschrieben, nämlich der Gebrauch von benutzerdefinierten Funktionen, UDFs, zur Bereitstellung von Nachrichten.

Unabhängig von einer bestimmten Ausführungsform der Metadatentabellen, die Abonnements auf eine Tabelle T widerspiegeln, hat der Zusammenfassungsauslöser, der von der vorliegenden Erfindung vorgeschlagen wird, den folgenden Aufbau, der in Fig. 8 dargelegt wird:

Für jede Art von Veränderungen, d. h. Einfügen, Löschen, Aktualisieren von Tupeln aus Tabelle T, die als Veröffentlichungen gehandhabt werden sollen, wird ein getrennter Auslöser erzeugt.

Dieser Auslöser wird immer dann zum Ansprechen gebracht, wenn an Tabelle T eine entsprechende Veränderung vorgenommen wird, siehe die Punkte, die in Fig. 8 mit 1 bezeichnet werden.

Wenn der Auslöser anspricht, führt das ihm zugrunde liegende Datenbanksystem den Hauptteil des Auslösers aus, d. h. die in dem Fall in Fig. 7 dargestellte Auswahlanweisung. Die Woher- und Wo-Klausel der Auswahlanweisung veranlasst, alle vorzugebenden Abonnenten aus den Metadatentabellen herauszufiltern, siehe Punkt 2 in Fig. 8. Es sollte angemerkt werden, dass die konkrete Woher- und Wo-Klausel von der bestimmten Struktur der Metadatentabellen abhängt.

Für jeden der vorzugebenden Abonnenten wird die in der Auswahlklausel vorgegebene Übermittlungs-UDF aufgerufen - siehe Punkt 3 in Fig. 8. Hier kann irgendein Spaltenwert aus der berechneten Verbindung als Parameter an die UDF geschickt werden, d. h. insbesondere der Abonnentenkennzeichner.

Die Übermittlungs-UDF wird dann jeden Abonnenten nach seiner Abonnementanforderung verarbeiten, wie es mit Punkt 4 in Fig. 8 beschrieben wird, was in der Praxis oftmals bedeutet, die Abonnementreaktion in einer Zielbenutzer-Warteschlange einzureihen.

Es ist offenkundig, dass eine Vielzahl von Ausführungsformen der Übermittlungs-UDF vorhanden ist. Beispielsweise:

Eine Ausführungsform übermittelt neu erzeugte Tupel als Nachrichten in abonnentenbezogene Zielwarteschlangen. Zu diesem Zwecke können die Metadatentabellen den Namen der Zielwarteschlange für jeden Abonnenten enthalten. Dieser Warteschlangenname wird zusammen mit dem vollständigen neuen Tupel als Parameter an die Übermittlungs-UDF geschickt. Die UDF setzt aus dem Tupel eine Nachricht zusammen und ruft die PUT-Anforderung des zugrunde liegenden Nachrichtensystems (z. B. MQSeries) auf, um die Nachricht an die Warteschlange des Abonnenten zu richten.

Eine weitere Ausführungsform übermittelt einfach den Abonnentenkennzeichner und den Kennzeichner des geänderten Tupels in eine systembezogene interne Warteschlange. Periodisch kann diese Warteschlange durch ein getrenntes Programm verarbeitet werden, das die veränderten Tupel abruft und sie an die Bestimmungswarteschlange des Abonnenten einordnet.

Eine interessierende Anwendung dieser Verfahrensweise ist das periodische Vervielfältigen von veränderten Daten in Datendepotumgebungen: Abonnenten sind die verschiedenen Kopien von ausgewählten Daten in der Umgebung, und die Abonnementfilter stellen die Daten dar, die für die lokale Untermenge von Betriebsdaten von Interesse sind.

Eine weitere Ausführungsform fügt ein Tupel, beispielsweise als XML-Strom, in eine Tabelle ein, die für jeden Abonnenten verwaltet wird. Dies würde es dem Abonnenten gestatten, diese Tabelle abzufragen, um die Abonnementergebnisse zu erhalten.

Der Hauptvorteil der vorliegenden Erfindung besteht darin, dass sie einen wirksamen Weg der Verwendung von Funktionen darlegt, die von Datenbanksystemen nach außen verlagert werden, um Veröffentlichungs-/Abonnementmaschinen zu realisieren. Es sollte betont werden, dass es noch viel leistungsfähigere Wege geben könnte, Veröffentlichungs-/Abonnementmaschinen aus dem Inneren von Datenbanken zu realisieren, d. h. durch Verändern einer gegebenen Datenbankmaschine selbst.

Aber derartige Realisierungen müssten durch den Lieferanten der einzelnen Datenbankmaschine vorgenommen werden. Da viele Lieferanten sich hin zu Veröffentlichungs-/Abonnementlösungen bewegen und viele Lieferanten neuerdings sogar standardisierte Schnittstellen für Veröffentlichung und Abonnement innerhalb der Java-Initiative haben, kann erwartet werden, dass eine wirksame Realisierung oberhalb einer Datenbankmaschine stark an Interesse gewinnen wird.

In der vorstehenden Beschreibung ist die Erfindung unter Bezugnahme auf eine bestimmte beispielhafte Ausführungsform davon dargelegt worden. Es wird jedoch offenkundig sein, dass verschiedene Modifikationen und Veränderungen daran vorgenommen werden können, ohne dass vom weiteren Wesen und Umfang der Erfindung abgewichen wird, wie sie in den anhängenden Ansprüchen dargelegt ist. Die Beschreibung und die Zeichnungen sind dementsprechend als Veranschaulichung und nicht im einschränkenden Sinne zu betrachten.

Beispielsweise kann die Übermittlungsfunktion einfach die Mindestmenge an Information über die vorzugebenden Abonnenten und das verursachende Tupel auflegen, wie etwa z. B. seinen Primärschlüssel in eine getrennte Warteschlange. Aus dieser Warteschlange kann in einem zweiten Schritt ein weiteres Programm die Nachricht aufbauen, die an die vorgegebenen Abonnenten geliefert werden soll. Das Programm kann sogar auf der Grundlage dieser Warteschlangen-Eingabe eine Liste von Abonnenten erstellen und die Liste an eine gespeicherte Verfahrensweise weitergeben, die dann auf wirksamere Weise die Nachrichten an die Abonnenten erstellen und tatsächlich übermitteln wird.

Es sollte angemerkt werden, dass sich ein Nachrichtenvermittler üblicherweise mit veröffentlichten, d. h. neu erzeugten Nachrichten befasst. Damit genügen EINFÜGE-Auslöser, um diese Situation zu bewältigen. Aber Benachrichtigungsmaschinen, die auf relationaler Datenbanktechnik aufgebaut sind, wie sie in der vorliegenden Erfindung beschrieben werden, können auch einfach mit AKTUALISIERTEN oder GELÖSCHTEN Daten fertig werden, z. B. auch Nachrichten: statt des Erzeugens eines Abonnementauslösers, der anspricht, wenn ein neues Tupel EINGEFÜGT wird, kann der gleiche Abonnementauslöser erzeugt werden, der anspricht, wenn Veränderungen hinsichtlich AKTUALISIEREN oder LÖSCHEN an der Tabelle vorgenommen werden.

Weiterhin können die Konzepte der Erfindung auf beliebige Systeme zum Festhalten von Daten angewendet werden, die nicht notwendigerweise wie eine objektbezogene Datenbank organisiert sein müssen. Der Ausdruck ,Datenbank' sollte damit in einem sehr allgemeinen Sinn verstanden werden.

Claims

1. Verfahren zum Benachrichtigen eines oder einer Vielzahl von Abonnenten über Veränderungen von mindestens einer Datenbanktabelle T in einem Datenbanksystem,
wobei das Verfahren die folgenden Schritte umfasst:
Speichern einer oder einer Vielzahl von Darstellungen von Abonnentenanforderungen zu bestimmten Veränderungen an Datenbanktabelle T in einer oder einer Vielzahl von Metadatentabellen,
Benutzen eines oder mehrerer Abonnentenauslöser, die als einer oder mehrere Datenbankauslöser eingerichtet sind, die zur der Datenbanktabelle T gehören, und die auf Veränderungen der Datenbanktabelle T reagieren,
Ermitteln von Datensätzen der Datenbanktabelle T, die den in der Metadatentabelle gespeichert Abonnementanforderungen genügen durch eine Anweisung zur Datenbankanfrage, die sich mindestens auf die Datenbanktabelle T und die Metadatentabelle bezieht.

2. Verfahren nach Anspruch 1, wobei die Anweisung zur Datenbankabfrage von bestimmten Werten der Abonnementanforderungen unabhängig ist und nur indirekt durch den Tabelleninhalt von Metadaten auf bestimmte Werte der Abonnementanforderungen Bezug nimmt.

3. Verfahren nach Anspruch 1, das weiterhin die Schritte des Bereitstellens der Datensätze durch Benachrichtigungsmittel umfasst, die durch den Abonnementauslöser ermittelt werden.

4. Verfahren nach Anspruch 3, wobei das Benachrichtigungsmittel eine benutzerdefinierte Funktion in dem Datenbanksystem ist.

5. Verfahren nach dem vorhergehenden Anspruch, das den Schritt des Speicherns der Abonnements in der Metadatentabelle in disjunktiver Normalformat umfasst.

6. Verfahren nach dem vorhergehenden Anspruch, das den Schritt des Ansammelns von Abonnements zu einer vorgegebenen Datenbanktabelle in einem einzigen Auslöser umfasst.

7. Verfahren nach dem vorhergehenden Anspruch, das den Schritt des Speicherns der Benachrichtigungen in einer Abonnentendatenbank umfasst.

8. Verfahren nach dem vorhergehenden Anspruch, das dadurch gekennzeichnet ist, dass es Benachrichtigungen unter Verwendung elektronischer Postsysteme sendet.

9. Verfahren nach dem vorhergehenden Anspruch 7 oder Anspruch 8, wobei die Benachrichtigungen Nachrichten sind.

10. System, das Mittel hat, um das Verfahren nach einem der vorhergehenden Ansprüche auszuführen.

11. System nach dem vorhergehenden Anspruch, in dem die Abonnementauslöser Datenbankauslöser sind.

12. System nach dem vorhergehenden Anspruch, das Benachrichtigungsmittel hat, die ihrerseits eine benutzerdefinierte Funktion sind.

13. Rechnerprogramm zur Ausführung in einem Datenverarbeitungssystem, das Teile von Rechnerprogrammcodes umfasst, mit denen das Verfahren nach einem beliebigen der Ansprüche 1 bis 9 ausgeführt wird.

14. Rechnerprogrammprodukt, das in einem rechnernutzbaren Medium gespeichert ist, das rechnerlesbare Programmittel umfasst, um einen Rechner zu veranlassen, das Verfahren nach einem beliebigen der Ansprüche 1 bis 9 auszuführen.