DE10031716A1 - Abonnement und Benachrichtigung bei Datenbanktechnik - Google Patents
Abonnement und Benachrichtigung bei DatenbanktechnikInfo
- Publication number
- DE10031716A1 DE10031716A1 DE10031716A DE10031716A DE10031716A1 DE 10031716 A1 DE10031716 A1 DE 10031716A1 DE 10031716 A DE10031716 A DE 10031716A DE 10031716 A DE10031716 A DE 10031716A DE 10031716 A1 DE10031716 A1 DE 10031716A1
- Authority
- DE
- Germany
- Prior art keywords
- database
- subscription
- database table
- subscriber
- triggers
- 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.)
- Granted
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR 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/28—Databases characterised by their database models, e.g. relational or object models
- G06F16/284—Relational databases
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99931—Database or file accessing
- Y10S707/99933—Query processing, i.e. searching
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)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
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
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.
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?
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.
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.
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.
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.
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:
Bj = A(j1 ~ j1 vj1 Λ. . .Λ Ajnj ~ jnj vjnj)
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 = (A11 ~ 11 v11 Λ. . .Λ A1n1 ~ 1n1 v1n1) V. . .V (Ak1 ~ k1 vk1 Λ. . .Λ Aknk ~ knk vknk)
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 Bj = (Aj1 ~ vj1 Λ. . .Λ Ajnj ~ jnj vjnj)
ein Attribut höchstens einmal mit einem bestimmten
Vergleichsoperator erscheint, d. h.
∍ 1 ≦ j ≦ k ∍ 1 ≦ x, y ≦ nj : Ajx = Ajy Λ ~ jx = ~jy ⇒ vjx = νjy
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:
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 = (Ajl ~ jl vjl Λ. . .Λ Ajnj ~ jnj vjnj) 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 (14)
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.
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.
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
EP99113020 | 1999-07-06 | ||
EP99113020.4 | 1999-07-06 |
Publications (2)
Publication Number | Publication Date |
---|---|
DE10031716A1 true DE10031716A1 (de) | 2001-01-25 |
DE10031716B4 DE10031716B4 (de) | 2006-10-26 |
Family
ID=8238524
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
DE10031716A Expired - Fee Related DE10031716B4 (de) | 1999-07-06 | 2000-06-29 | Abonnement und Benachrichtigung bei Datenbanktechnik |
Country Status (3)
Country | Link |
---|---|
US (1) | US6826560B1 (de) |
JP (1) | JP3996328B2 (de) |
DE (1) | DE10031716B4 (de) |
Families Citing this family (33)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7152094B1 (en) * | 2001-07-31 | 2006-12-19 | Sprint Communications Company L.P. | Middleware brokering system adapter |
US20040002958A1 (en) * | 2002-06-26 | 2004-01-01 | Praveen Seshadri | System and method for providing notification(s) |
US7698276B2 (en) | 2002-06-26 | 2010-04-13 | Microsoft Corporation | Framework for providing a subscription based notification system |
US20040002988A1 (en) * | 2002-06-26 | 2004-01-01 | Praveen Seshadri | System and method for modeling subscriptions and subscribers as data |
US7177859B2 (en) * | 2002-06-26 | 2007-02-13 | Microsoft Corporation | Programming model for subscription services |
US8688462B2 (en) | 2003-01-31 | 2014-04-01 | Media Queue, Llc | Media auto exchange system and method |
US8700538B2 (en) | 2003-01-31 | 2014-04-15 | Media Queue, Llc | Media exchange system and method |
US8712867B2 (en) | 2003-01-31 | 2014-04-29 | Media Queue, Llc | System for providing access to playable media |
US8612311B2 (en) * | 2004-05-28 | 2013-12-17 | Media Queue, Llc | Hybrid distribution method for playable media |
US20040243479A1 (en) * | 2003-05-28 | 2004-12-02 | Gross John N. | Method of monitoring electronic commerce queue |
US8433622B2 (en) * | 2003-05-28 | 2013-04-30 | Media Queue, Llc | Method of controlling electronic commerce queue |
US8738541B2 (en) * | 2003-06-25 | 2014-05-27 | Media Queue, Llc | Method of processing rental requests and returns |
US8131739B2 (en) | 2003-08-21 | 2012-03-06 | Microsoft Corporation | Systems and methods for interfacing application programs with an item-based storage platform |
US7590643B2 (en) | 2003-08-21 | 2009-09-15 | Microsoft Corporation | Systems and methods for extensions and inheritance for units of information manageable by a hardware/software interface system |
US8238696B2 (en) | 2003-08-21 | 2012-08-07 | Microsoft Corporation | Systems and methods for the implementation of a digital images schema for organizing units of information manageable by a hardware/software interface system |
US8166101B2 (en) | 2003-08-21 | 2012-04-24 | Microsoft Corporation | Systems and methods for the implementation of a synchronization schemas for units of information manageable by a hardware/software interface system |
US7669177B2 (en) | 2003-10-24 | 2010-02-23 | Microsoft Corporation | System and method for preference application installation and execution |
US8626716B1 (en) * | 2004-04-08 | 2014-01-07 | Sprint Communications Company L.P. | Service broker enhancements |
US20050251811A1 (en) * | 2004-05-07 | 2005-11-10 | International Business Machines Corporation | Distributed messaging system supporting stateful |
US7805422B2 (en) * | 2005-02-28 | 2010-09-28 | Microsoft Corporation | Change notification query multiplexing |
US8146100B2 (en) | 2006-03-21 | 2012-03-27 | Sap Ag | System and method for event-based information flow in software development processes |
US8458725B2 (en) | 2006-04-10 | 2013-06-04 | Oracle International Corporation | Computer implemented method for removing an event registration within an event notification infrastructure |
US9390118B2 (en) * | 2006-04-19 | 2016-07-12 | Oracle International Corporation | Computer implemented method for transforming an event notification within a database notification infrastructure |
US8464275B2 (en) * | 2006-05-10 | 2013-06-11 | Oracle International Corporation | Method of using a plurality of subscriber types in managing a message queue of a database management system |
US20090248612A1 (en) * | 2008-03-31 | 2009-10-01 | Morris Robert P | Methods, Systems, And Computer Program Products For Providing Prior Values Of A Tuple Element In A Publish/Subscribe System |
US8335762B2 (en) | 2008-10-06 | 2012-12-18 | Microsoft Corporation | Resource tracking |
US20100257275A1 (en) * | 2009-04-02 | 2010-10-07 | Morris Robert P | Method and System For Changing A Subscription To A Tuple Based On A Changed State Of The Tuple |
US20110137889A1 (en) * | 2009-12-09 | 2011-06-09 | Ca, Inc. | System and Method for Prioritizing Data Storage and Distribution |
US8332349B1 (en) * | 2012-01-06 | 2012-12-11 | Advent Software, Inc. | Asynchronous acid event-driven data processing using audit trail tools for transaction systems |
US8886671B1 (en) | 2013-08-14 | 2014-11-11 | Advent Software, Inc. | Multi-tenant in-memory database (MUTED) system and method |
WO2016099569A1 (en) * | 2014-12-19 | 2016-06-23 | Nordholm Cameron | Multi-tenant publishing system |
US10599672B2 (en) | 2015-11-24 | 2020-03-24 | Cisco Technology, Inc. | Cursor-based state-collapse scheme for shared databases |
CN108197263A (zh) * | 2017-12-30 | 2018-06-22 | 苏州精易会信息技术有限公司 | 数据同步方法 |
Family Cites Families (11)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5101348A (en) * | 1988-06-23 | 1992-03-31 | International Business Machines Corporation | Method of reducing the amount of information included in topology database update messages in a data communications network |
JPH0660000A (ja) * | 1992-08-07 | 1994-03-04 | Hitachi Ltd | 情報処理システムおよび情報処理方法 |
US5497317A (en) * | 1993-12-28 | 1996-03-05 | Thomson Trading Services, Inc. | Device and method for improving the speed and reliability of security trade settlements |
US5809483A (en) * | 1994-05-13 | 1998-09-15 | Broka; S. William | Online transaction processing system for bond trading |
US5797002A (en) * | 1994-09-20 | 1998-08-18 | Papyrus Technology Corp. | Two-way wireless system for financial industry transactions |
JPH1011373A (ja) | 1996-06-21 | 1998-01-16 | Matsushita Electric Ind Co Ltd | 情報自動配送装置及び情報自動配送方法 |
US5903882A (en) * | 1996-12-13 | 1999-05-11 | Certco, Llc | Reliance server for electronic transaction system |
US6256676B1 (en) * | 1998-11-18 | 2001-07-03 | Saga Software, Inc. | Agent-adapter architecture for use in enterprise application integration systems |
US6338055B1 (en) * | 1998-12-07 | 2002-01-08 | Vitria Technology, Inc. | Real-time query optimization in a decision support system |
US6347307B1 (en) * | 1999-06-14 | 2002-02-12 | Integral Development Corp. | System and method for conducting web-based financial transactions in capital markets |
US6405191B1 (en) * | 1999-07-21 | 2002-06-11 | Oracle Corporation | Content based publish-and-subscribe system integrated in a relational database system |
-
2000
- 2000-06-29 DE DE10031716A patent/DE10031716B4/de not_active Expired - Fee Related
- 2000-06-30 US US09/608,737 patent/US6826560B1/en not_active Expired - Lifetime
- 2000-07-06 JP JP2000205082A patent/JP3996328B2/ja not_active Expired - Fee Related
Also Published As
Publication number | Publication date |
---|---|
JP2001043248A (ja) | 2001-02-16 |
US6826560B1 (en) | 2004-11-30 |
DE10031716B4 (de) | 2006-10-26 |
JP3996328B2 (ja) | 2007-10-24 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
DE10031716B4 (de) | Abonnement und Benachrichtigung bei Datenbanktechnik | |
DE60004537T2 (de) | In einer relationalen datenbank integriertes contextbasiertes system zur veröffentlichung und abonnierung | |
DE3689664T2 (de) | Verfahren und Gerät zur Verwaltung von veralteten Datenobjekten. | |
DE69705832T2 (de) | Verfahren zum definieren und anwenden von regeln für nachrichtenverteilung für transaktionsverarbeitung in einer verteilten anwendung | |
DE69523939T2 (de) | Verfahren zur erzeugung von objektstrukturen für den zugriff auf konventionelle, nicht objekt-orientierte geschäftsanwendungen | |
DE69521839T2 (de) | Datenbanksystem | |
DE69328162T2 (de) | Gerät und Verfahren zum Verfügbarstellen eines Teiles eines Namensraumes als ein Teil eines anderen Namensraumes | |
DE69736748T2 (de) | Editierumgebung für objektmodelle und verfahren zu deren anwendung | |
DE69910219T2 (de) | Transformation der perspektive auf tabellen von relationalen datenbanken | |
EP1151399B1 (de) | Integration heterogener Datenbank-Systeme | |
DE69510962T2 (de) | Semantisches netzwerk | |
DE69530595T2 (de) | System und verfahren für die x.500-datenbanknorm | |
EP1258812B1 (de) | Virtuelle Datenbank heterogener Datenstrukturen | |
EP1194865B1 (de) | Verfahren zur datenpflege in einem netzwerk teilweise replizierter datenbanksysteme | |
DE69936818T2 (de) | Protokoll zum Austausch von Konfigurationsdaten in einem Computernetzwerk | |
DE69516727T2 (de) | Verfahren und system um auf daten zuzugreifen | |
DE69704489T2 (de) | Verfahren und Vorrichtung zur strukturierten Kommunikation | |
DE69031164T2 (de) | Zeitlich begrenztes zentrumsystem für dezentralisiertes datenbanksystem | |
DE3856038T2 (de) | Datenintegration durch Objektverwaltung | |
WO1999067725A1 (de) | Verfahren und system zur schnellen speicherresidenten verarbeitung von transaktionsdaten | |
DE112017006106T5 (de) | Erzeugen von, Zugreifen auf und Anzeigen von Abstammungsmetadaten | |
CH704497B1 (de) | Verfahren zum Benachrichtigen, Speichermedium mit Prozessoranweisungen für ein solches Verfahren. | |
DE69517887T2 (de) | Verfahren und System zum Herstellen von Verbindungen in einem Datenbanksystem | |
DE3853751T2 (de) | Programmanpassung durch automatische Resourcensubstitution. | |
DE19813883B4 (de) | Verfahren, Computerprogrammprodukt und Dokumentenmanagementsystem zum Zugriff auf Internet-Informationen für geschlossene Benutzergruppen |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
OP8 | Request for examination as to paragraph 44 patent law | ||
8364 | No opposition during term of opposition | ||
8320 | Willingness to grant licences declared (paragraph 23) | ||
R119 | Application deemed withdrawn, or ip right lapsed, due to non-payment of renewal fee | ||
R119 | Application deemed withdrawn, or ip right lapsed, due to non-payment of renewal fee |
Effective date: 20150101 |