DE102006047499A1

DE102006047499A1 - Datenerweiterbarkeit mit Hilfe externer Datenbanktabellen

Info

Publication number: DE102006047499A1
Application number: DE102006047499A
Authority: DE
Inventors: Alan M. Boulder Bland; Stephan Edward Frederick Friedl; Terry Don Westminster Jennings; Jeffrey James Boulder Olson; Barbara Jo Boulder West
Original assignee: Avaya Technology LLC
Current assignee: Avaya Technology LLC
Priority date: 2005-10-06
Filing date: 2006-10-05
Publication date: 2007-04-12
Also published as: GB0619051D0; GB2431022A; CN100541492C; US20070083572A1; JP4499699B2; CN101000612A; US7752230B2; JP2007102797A

Abstract

In einer Ausführungsform umfasst ein Datenverarbeitungssystem: DOLLAR A (a) eine erste Datenbank 304, die von einer ersten Seite unterhalten wird; DOLLAR A (b) eine zweite Datenbank 324, 328, die von einer zweiten Seite unterhalten wird, die sich von der ersten Seite unterscheidet; DOLLAR A (c) eine Arbeitswarteschlange 316, die dazu dient, Daten zu spezifizieren, die zu der zweiten Datenbank hinzugefügt werden sollen; DOLLAR A (d) ein Extraktions-, Transformations- und Lade-Modul 308, das dazu dient, Daten aus der ersten Datenbank in die Arbeitswarteschlange zu schreiben; und DOLLAR A (e) ein Datenimportmodul 320, das dazu dient, Daten aus der Arbeitswarteschlange in die zweite Datenbank zu importieren. In dem System ist die erste Seite nicht berechtigt, die Daten direkt in die zweite Datenbank zu schreiben.

Description

Gebiet der Erfindung
Die vorliegende Erfindung betrifft allgemein die Ereignisabwicklung und speziell die Überwachung des Leistungsverhaltens von Agenten.

Hintergrund der Erfindung

Kontaktzentralen wie etwa automatische Anrufverteilungs- oder ACD-Systeme werden von vielen Firmen angewendet, um Kundenkontakte zu bedienen. Eine typische Kontaktzentrale umfasst eine Vermittlungseinrichtung und/oder einen Server zum Empfangen und Lenken eingehender paketvermittelter und/oder leitungsvermittelter Kontakte sowie eine oder mehrere Ressourcen wie etwa als Agenten bezeichnete Sachbearbeiter und automatisierte Ressourcen (z. B. interaktive Sprachausgabe (IVR – Interactive Voice Response) -Einheiten), um die eingehenden Kontakte zu bedienen. Kontaktzentralen verteilen Kontakte, egal ob eingehende oder abgehende, zur Bedienung gemäß vordefinierter Kriterien an irgendeine geeignete Ressource. Bei vielen existierenden Systemen können die Kriterien zum Bedienen des Kontakts ab dem Zeitpunkt, zu dem die Kontaktzentrale des Kontakts gewahr wird, bis der Kontakt mit einem Agenten verbunden wird, vom Anwender spezifiziert werden (d. h. sind von dem Betreiber der Kontaktzentrale programmierbar), und zwar über eine Fähigkeit, die als Vektorisierung bezeichnet wird. Bei heutigen ACDs wird normalerweise, wenn der Controller des ACD-Systems feststellt, dass ein Agent verfügbar geworden ist, um einen Kontakt abzuwickeln, der Controller alle vordefinierten Kontaktabwicklungsfähigkeiten des Agenten feststellen (üblicherweise in einer gewissen Prioritätsreihenfolge) und an den Agenten den ältesten Kontakt mit der höchsten Priorität ausliefern, welcher mit der Fähigkeit mit höchster Priorität des Agenten übereinstimmt. Im Allgemeinen besteht der einzige Zustand, der dazu führt, dass an einen verfügbaren Agenten kein Kontakt abgegeben wird, darin, dass keine abzuwickelnden Kontakte warten.

Die Hauptaufgabe einer Kontaktzentralenverwaltung, einschließlich der Anrufverteilungsalgorithmen, besteht letztendlich darin, die Funktionsfähigkeit und die Profitabilität der Kontaktzentrale zu maximieren. Eine ständige Herausforderung bei der Verwaltung von Kontaktzentralen ist die Überwachung des Verhaltens von Agenten, um die Nutzung von Ressourcen der Kontaktzentrale zu optimieren und die Leistungsfähigkeit und Profitabilität der Agenten zu maximieren. Derzeitige Produkte zum Überwachen und Melden des Funktionsverhaltens von Kontaktzentralen, beispielsweise das Call Management System oder CMS^TM der Avaya Inc., sind als Data Warehouses (dt.: Daten-Lagerhaus) konfiguriert, die Daten aus mehreren Quellen extrahieren, die Daten in eine normierte Form umwandeln und die Daten in die Data Warehouse-Datenbank laden, typischerweise nach einem Stapelplan. Zusätzliche Berechnungen und Meldungen erfolgen nach dem Stapelladen.

Ein üblicher Typ eines Data Warehouse basiert auf der Dimensionsmodellierung. Die Dimensionsmodellierung stellt ein Datenmodell dar, das die Welt in Messwerte und Kontext einteilt. Messwerte sind üblicherweise numerisch und werden wiederholt erfasst. Numerische Messwerte stellen Fakten dar. Fakten werden von bestehendem Kontext in Textform umgeben, wenn der Fakt aufgezeichnet wird. Der Kontext wird oft in Dimensionen unterteilt. Faktentabellen werden bei der Dimensionsmodellierung genutzt, um Messwerte logisch mit mehreren Fremdschlüsseln zu modellieren, die auf die Kontextentitäten verweisen. Den Kontextentitäten ist jeweils ein Primärschlüssel zugeordnet. Ein "Schlüssel" ist ein Datenelement (z. B. Attribut oder Spalte), das eine Instanz einer Entität oder eines Datensatzes in einer Datensammlung, beispielsweise einer Tabelle, identifiziert. Ein "Primärschlüssel" ist eine Spalte oder eine Kombination von Spalten, deren Werte eindeutig eine Zeile in einer Tabelle identifizieren, oder ist das Attribut oder die Gruppe von Attributen, die aus den Kandidatenschlüsseln als das/die geeignetste(n) ausgewählt worden ist/sind, um eindeutig jede Instanz einer Entität zu identifizieren. Ein "Fremdschlüssel" bezeichnet eine Spalte oder eine Kombination von Spalten, deren Werte mit einem Primärschlüssel in einer anderen Tabelle übereinstimmen sollen, oder ist ein Primärschlüssel einer Stammentität, die über eine Beziehung zu einer Unterentität beiträgt. Typen von Primärschlüsseln sind ein natürlicher Schlüssel oder ein Schlüssel, der eine Bedeutung für Benutzer hat, und ein Surrogatschlüssel oder ein Schlüssel, der künstlich oder synthetisch eingeführt wird, für die Benutzer bedeutungslos ist und als Substitut für einen natürlichen Schlüssel genutzt wird.

Wenn die gleiche Entität (z. B. ein Agent) in mehreren Datenquellen (z. B. eingehendes Anrufsystem und abgehendes Anrufsystem) durch unterschiedliche natürliche Schlüssel repräsentiert wird, erzeugt ein herkömmliches Data Warehouse einen Surrogatschlüssel und ordnet diesen zu, um die Entität zu identifizieren. Der Surrogatschlüssel stellt einen internen Identifier dar, der von dem Data Warehouse verwaltet wird. Beispielsweise ist es möglich, dass in einer Kontaktzentrale ein Agent eingehende Anrufe von einem System und abgehende Anrufe von einem anderen System abwickelt, und zwar mit unterschiedlichen Identitäten in dem jeweiligen System. Data Warehouses verarbeiten üblicherweise jede Datenquelle unabhängig, wobei eine Datenkorrelation zwischen den Quellen zu einem späteren Zeitpunkt ausgeführt wird.

Einige Datenmodelle spezifizieren ein Verhalten, das als Slowly Changing Dimensions (dt: sich langsam verändernde Dimensionen) Typ 2 bezeichnet wird. Eine Dimension vom Typ 2 verfolgt die Historie von Änderungen an einer Entität im Zeitverlauf. Wenn ein Attribut einer Entität geändert wird, beispielsweise wenn ein Agent einer Kontaktzentrale seine Fähigkeiteneinstellung oder Gruppenzugehörigkeit ändert, wird ein neuer Surrogatschlüssel für diese Entität generiert und in die Datenbank wird eine neue Zeile eingefügt. Faktdaten, die mit der Entität verknüpft sind, können nun separat auf Aktivitäten hin verfolgt werden, die vor bzw. nach der Änderung erfolgt sind, und zwar durch Bezug auf den entsprechenden Surrogatschlüssel.

Ein fortlaufendes Problem, mit dem Anbieter von Kontaktzentralen-Softwareprodukten konfrontiert sind, insbesondere von Produkten, die Dimensionsmodellierungssoftware enthalten, stellt die Integration der Firmendatenbank-Anwendungen (oder Applikationssoftware), die typischerweise von anderen Anbietern erworben wird, mit der Software der Kontaktzentrale dar. Der Anbieter der Kontaktzentralensoftware möchte eine einfache Integration mit der existierenden Applikationssoftware der Firmendatenbank, muss aber sorgfältig darauf achten, dass die Integration der Software nicht zu semantischen Inkonsistenzen und anderen Konflikten führt, die zur Meldung von Ungenauigkeiten oder, noch schlimmer, Software-Fehlfunktionen führt.

Eine Reihe von Ansätzen wird genutzt, um diesem Problem zu begegnen.

Bei einem solchen Ansatz bietet die Datenbank eine eingeschränkte Möglichkeit, die Arten von Erweiterungen, die ein spezieller Datenbanknutzer vornehmen kann, zu kontrollieren. Beispielsweise verbietet der Besitzer einer Datenbanktabelle das Löschen einer Spalte, um existierende Daten zu schützen. Es ist auch möglich, dass der Besitzer einer Tabelle gestatten möchte, Spalten zu der Tabelle hinzuzufügen, und er kann die Datenbank derart konfigurieren, dass einem Tabellennutzer gestattet wird, einen festgelegten Satz von Spalten hinzuzufügen. Wenn jedoch die existierenden Spalten Randbedingungen bezüglich ihrer Werte aufweisen, die über das herkömmliche relationale Modell hinausgehen, gibt es keine Möglichkeit sicherzustellen, dass die Daten in den neuen Spalten diesen Randbedingungen genügen. Beispielsweise gibt es bei der Dimensionsmodellierung für Dimensionstabellen mit Schlüsseln vom Typ 2 spezielle Regeln dafür, wann ein neuer Schlüssel generiert werden muss. Grundsätzlich wird, wenn sich der Wert irgendeiner der Spalten mit Nicht-Typ-2-Schlüsseln ändert, eine gesamte neue Zeile mit einem neuen Schlüssel vom Typ 2 und eine komplette Kopie aller aktuellen Daten in die Tabelle eingefügt. Durch diese Vorkehrung können die historischen Informationen, die mit der Dimensionstabelle verknüpft sind, gesichert werden. Wird jedoch einer willkürlichen dritten Seite gestattet, solche Spalten zu erzeugen, ist es erforderlich, dass sich die dritte Seite an der Schlüsselsemantik vom Typ 2 beteiligt. Leider bieten Datenbanken keine Möglichkeit, die Semantik vom Typ 2 zu garantieren. Beispielsweise kann der Anwender eine Schlüsseländerung vom Typ 2 rückgängig machen, die durch die Datenbanksoftware der Kontaktzentrale erfolgt ist, oder umgekehrt. Darüber hinaus krankt dieser Ansatz auch an Wettlaufsituationen, welche den Verlust von Aktualisierungen bewirken könnten.

Bei einem anderen Ansatz werden Datenbanktrigger an der Tabelle genutzt, um nach Änderungen von dritter Seite zu suchen, worauf, wenn sie identifiziert werden, eine Anwendung folgt, die eine entsprechende Semantik vom Typ 2 anwendet. Leider führt ein solcher Ansatz häufig zu Wettbewerbszuständen zwischen der Anwendung und der dritten Seite, welche verhindern, dass eine richtige logische Semantik aufrechterhalten wird. Einfach gesagt gibt es keine Möglichkeit, den zeitlichen Ablauf der dritten Seite, der den Änderungen an dem erweiterten Spaltensatz zugeordnet ist, zu kontrollieren. Oftmals ist die Anwendung aus irgendeinem Grund unwillig, Änderungen an einer Tabelle zu gestatten, beispielsweise während ein Extraktions-, Transformations- und Lade- oder ETL-Modul Zusammenfassungen anhand der Tabelle berechnet.

Ein weiterer Ansatz nutzt eine Transaktions- oder "Datenbanksperre", bei welcher Anfragen (Transaktionen) um eine festgelegte Zeitspanne verzögert werden. Eine Datenbanksperre kann helfen, kann aber für eine Komplettlösung schwer zu verwenden sein. Wenn beispielsweise die Transaktionshaltezeit langlebig ist, ist es möglich, dass die Anwendung der dritten Seite oder die Anwendung der Kontaktzentrale festfahren.

Zusammenfassung der Erfindung

Diesen und anderen Bedürfnissen wenden sich die verschiedenen Ausführungsformen und Konfigurationen der vorliegenden Erfindung zu. Die vorliegende Erfindung ist allgemein auf ein erweiterbares Datenmodel ausgerichtet.

Bei einer Ausführungsform der vorliegenden Erfindung umfasst ein Datenverarbeitungssystem:

(a) eine erste Datenbank, die von einer ersten Seite oder Teilnehmer unterhalten oder verwaltet wird;
(b) eine zweite Datenbank, die von einer zweiten Seite oder Teilnehmer unterhalten oder verwaltet wird, die sich von der ersten Seite unterscheidet;
(c) eine Arbeitswarteschlange, um Daten zu spezifizieren, die zu der zweiten Datenbank hinzugefügt werden sollen;
(d) ein Extraktions-, Transformations- und Lade-Modul, das dazu dient, Daten aus der ersten Datenbank in die Arbeitswarteschlange zu schreiben; und
(e) ein Datenimportmodul, das dazu dient, Daten aus der Arbeitswarteschlange in die zweite Datenbank zu importieren.

Die Berechtigungen der ersten Seite in Bezug auf die zweite Datenbank sind begrenzt. Zum Beispiel ist die erste Seite vorzugsweise nicht berechtigt, die Daten direkt in die zweite Datenbank zu schreiben (einzufügen, zu löschen und/oder zu aktualisieren) oder das Datenmodell, welches die zweite Datenbank definiert, zu modifizieren (einzufügen, zu löschen und/oder zu aktualisieren). Dies ist so, weil die zweite Seite für die Aufrechterhaltung und Modifizierung der zweiten Datenbank verantwortlich ist, darunter der anwendungsspezifischen Anpassung der zweiten Datenbank, um anwendungsspezifische Daten von der ersten Datenbank zu empfangen. Typischerweise stellen die erste und die zweite Seite unterschiedliche, nicht miteinander in Beziehung stehende Geschäftskörperschaften dar, die nicht unter gemeinsamer Kontrolle stehen und von denen keine ein Kontrollinteresse an der anderen hat.

Um das herstellereigene Schema der zweiten Datenbank vor der ersten Seite zu schützen, werden die Berechtigungen hinsichtlich der zweiten Datenbank für die erste Seite vorzugsweise auf Nur-Lesen festgelegt, was den Zugriff der ersten Seite betrifft. Vorzugsweise wird der ersten Seite verwehrt, ausgewählte Teile des Schemas anzuschauen. Dies geschieht, indem der Zugang nur über Datenbankansichten und nicht die echten Tabellen gestattet wird. Generell wird der ersten Seite ein direktes Schreiben von Daten nur in Arbeitswarteschlangentabellen und möglicherweise spezifizierte anwendungsspezifische Tabellen gestattet.

Bei einer zweiten Ausführungsform wird ein Verfahren zur Verfügung gestellt, das folgende Schritte umfasst:

(a) Empfangen eines Satzes von Spezifikationen von der ersten Seite, wobei die Spezifikationen eine Erweiterung an der zweiten Datenbank, die von der zweiten Seite unterhalten wird, spezifizieren;
(b) Modifizieren der zweiten Datenbank, wie in dem Satz von Spezifikationen angegeben, wobei die Modifikation eine anwendungsspezifische Tabelle, eine anwendungsspezifische Zeile in einer Tabelle und/oder eine anwendungsspezifische Spalte in einer Tabelle umfasst;
(c) Erzeugen einer Arbeitswarteschlange entsprechend der Modifikation;
(d) Empfangen erster Daten aus einer ersten Datenbank durch die Arbeitswarteschlange;
(e) Normieren der ersten Daten, um zweite Daten zu bilden; und
(f) Schreiben der zweiten Daten in. die anwendungsspezifische Tabelle, die anwendungsspezifische Zeile und/oder die anwendungsspezifische Spalte.

Das Verfahren führt effektiv eine Abbildung von Daten aus der ersten in die zweite Datenbank aus. Die ersten Daten sind semantisch kompatibel mit der ersten Datenbank und sind semantisch inkompatibel mit der zweiten Datenbank, und die zweiten Daten sind semantisch inkompatibel mit der ersten Datenbank und sind semantisch kompatibel mit der zweiten Datenbank. Der Begriff "Semantik", wie er vorliegend genutzt wird, bezeichnet die Beziehungen von Symbolen, Zeichen oder Gruppen von Symbolen oder Zeichen zu deren Bedeutungen und/oder zueinander. Die Beziehungen sind typischerweise unabhängig von der Art und Weise ihrer Interpretation und ihrer Nutzung. Zwei Symbole oder Zeichen sind "kompatibel", wenn sie in einer gemeinsamen Datenbank genutzt werden können, ohne dass zunächst semantische Änderungen an der Datenbank erforderlich sind, um der gleichzeitigen Benutzung selbiger Rechnung zu tragen.

Die vorliegenden Ausführungsformen können es unberechtigten Seiten (denen potentiell nicht vertraut wird) ermöglichen, Erweiterungen an einem Datenbankmodell vorzunehmen, während zugleich ein Schutz für die logische Semantik, die von dem Datenbankmodell benötigt wird, gegeben ist. Die unberechtigte Seite kennt die Komplexität der ersten, aber nicht der zweiten Datenbank, während die zweite Seite die Komplexitäten der zweiten, aber nicht der ersten Datenbank kennt. Durch die vorstehenden Ausführungsformen können effektiv die Kenntnisse der beiden Seiten miteinander verbunden werden, um die erste und die zweite Datenbank zu kombinieren, während zugleich effektiv Datenkonflikte, -kollisionen und andere Inkonsistenzen aufgrund von Konflikte ergebenden Modifikationen an der zweiten Datenbank verhindert werden. Die erste Seite wird daher davon entlastet, eine komplizierte Semantik, insbesondere Semantik vom Typ 2, des zweiten Datenbankmodells kennen und implementieren zu müssen. Beispielsweise kann die vorliegende Erfindung einen Mechanismus bereitstellen, um richtige Dimensionsschlüssel vom Typ 2 zu garantieren, wenn das Datenbankmodell die Dimensionsmodellierung nutzt.

Bei einer Konfiguration nutzt die Erfindung externe Tabellen (in den Arbeitswarteschlangen), um den Zugriff auf die (als "geschützte Tabellen" bezeichneten) Datenbanktabellen der Anwendung zu schützen. Die externen Tabellen umfassen eine so genannte Sandbox (dt.: Sandkasten), in welcher die Firma einfügen, löschen und aktualisieren kann. Datenbanktrigger oder ein ähnlicher Änderungsmeldemechanismus an der externen Tabelle geben Meldung an die Applikationssoftware, die dann entsprechende Änderungen an der entsprechenden geschützten Tabelle vornimmt. Die Änderungen können eine Durchsetzung der Dimensionssemantik vom Typ 2 für die geschützte Tabelle umfassen.

Bei einer weiteren Konfiguration kann die Firma nur in die externe Tabelle einfügen. In diesem Fall funktionieren die Trigger wie zuvor, wobei sie bewirken, dass entsprechende Änderungen in der geschützten Tabelle erfolgen. Sobald diese Änderungen abgeschlossen sind, wird die entsprechende Zeile aus der externen Tabelle gelöscht. Auf diese Weise implementiert die externe Tabelle eine Warteschlange für Arbeitsanfragen bezüglich von Änderungen an der geschützten Tabelle.

Die externen Tabellen können nicht von der unberechtigten Seite aufgestellt werden. Der Besitzer der geschützten Tabelle kann die externen Tabellen basierend auf Informationen aufstellen, die von der unberechtigten Seite gegeben werden. Beispielsweise können die Informationen umfassen, auf welche geschützte Tabelle sich die externe Tabelle bezieht, wie die Spalten der externen Tabelle lauten, ob die Spalten in der geschützten Tabelle oder als eine separate geschützte Tabelle erzeugt werden sollten, usw.

Bei beiden Konfigurationen können die geschützten Tabellen nicht von der unberechtigten Seite modifiziert werden. Die Triggermechanismen setzen die zusätzliche Semantik (z. B. Semantik vom Typ 2) durch, sodass die geschützte Tabelle immer eine richtige Semantik aufrechterhält. Die Applikation kann Triggervorgänge zeitweise aussetzen, während die geschützte Tabelle bearbeitet wird (z. B. summarische Daten anhand dieser gebildet werden). In diesem Fall kann die unberechtigte Seite verfolgen, welche Änderungen erfolgt sind, indem sie die Inhalte der externen Tabelle untersucht.

Andere Möglichkeiten zum Schützen der Tabellensemantik gestatten Zugriff (z. B. über die Structured Query Language oder SQL), erfordern aber, dass sich die ansonsten unberechtigte Seite an der Semantik der geschützten Tabelle beteiligt. Im Gegensatz dazu bietet die vorliegende Erfindung die externen Arbeitswarteschlangen, die für die unberechtigte Seite mit Hilfe von SQL zugänglich sind, nutzt vorzugsweise aber Trigger, um die richtige Semantik der geschützten Tabelle sicherzustellen. Erfindungsgemäß kann somit die Notwendigkeit vermieden werden, Tabellen zu schützen, wobei ein Nicht-SQL-Zugriff einer dritten Seite genutzt wird.

Aus den vorstehend genannten Gründen kann die Erfindung eine Schnittstelle bereitstellen, die in Echtzeit oder nahezu Echtzeit zwei unterschiedliche Daten aus zwei unterschiedlichen Quellen mischt oder multiplext. Die eine Quelle ist die Datensammlung der Firma und die Verarbeitungssoftware extern der Datensammlung und Verarbeitungssoftware der Kontaktzentrale, und die andere Quelle ist die Software der Kontaktzentrale selbst.

Diese und andere Vorteile werden anhand der Offenbarung der vorliegend enthaltenen Erfindung(en) deutlich werden.

Die Begriffe "zumindest eine", "eine oder mehrere" und "und/oder", wie sie vorliegend genutzt werden, sind offene Ausdrücke, die in ihrer Anwendung sowohl konjunktiv als auch disjunktiv sind. Beispielsweise bedeutet jeder der Ausdrücke "zumindest eines der Elemente A, B und C", "zumindest eines der Elemente A, B oder C", "eines oder mehrere der Elemente A, B und C, "eines oder mehrere der Elemente A, B oder C" und "A, B und/oder C" A allein, B allein, C allein, A und B zusammen, A und C zusammen, B und C zusammen oder A, B und C zusammen.

Die vorliegend beschriebenen Ausführungsformen und Konfigurationen sind weder vollständig noch erschöpfend. Wie zu erkennen sein wird, sind andere Ausführungsformen der Erfindung möglich, bei denen allein oder in Kombination eines oder mehrere der vorstehend angeführten oder nachstehend im Einzelnen beschriebenen Merkmale genutzt werden.

Kurze Beschreibung der Zeichnungen
1 ist ein Blockdiagramm, das eine Kontaktzentrale entsprechend einer Ausführungsform der vorliegenden Erfindung darstellt;
2 ist ein Blockdiagramm eines Servers entsprechend einer Ausführungsform der vorliegenden Erfindung;
3 ist ein Blockdiagramm, das eine Ausführungsform des Ereignisverarbeitungsmoduls darstellt;
4 ist ein Ablaufdiagramm, das eine erste funktionale Ausführungsform des Ereignisverarbeitungsmoduls darstellt; und
5 ist ein Ablaufdiagramm, das eine zweite funktionale Ausführungsform des Ereignisverarbeitungsmoduls darstellt.
Detaillierte Beschreibung
Die Erfindung wird nachstehend im Zusammenhang mit einem beispielhaften Kommunikationssystem veranschaulicht. Obgleich sie gut geeignet für den Einsatz mit z. B. einem System ist, das eine ACD- oder eine ähnliche Kontaktabwicklungs-Vermittlungseinrichtung aufweist, ist die Erfindung nicht auf den Einsatz mit irgendeiner bestimmten Art von Kommunikationssystem-Vermittlungseinrichtung oder Konfiguration von Systemelementen beschränkt. Fachleute werden erkennen, dass die offenbarten Verfahren in einer beliebigen Anwendung genutzt werden können, bei welcher es wünschenswert ist, eine verbesserte Ereignis- (z. B. Kontakt-) Abwicklung bereitzustellen.
1 zeigt eine beispielhafte Ausführungsform der vorliegenden Erfindung. Eine Kontaktzentrale 100 umfasst einen zentralen Server 110, einen Satz von Datenspeichern oder Datenbanken 114, die kontakt- oder kundenbezogene Informationen und andere Informationen enthalten, welche den Wert und die Effizienz der Kontaktabwicklung verbessern können, sowie eine Mehrzahl von Servern, nämlich einen Sprachmail-Server 118, eine interaktive Sprachausgabeeinheit oder IVR (Interactive Voice Response) 122 sowie andere Server 126 (beispielsweise ein prädiktives Einwählprogramm (Dialer)), eine Vermittlungseinrichtung 130, eine Mehrzahl von arbeitenden Agenten, die paketvermittelte (erste) Telekommunikationseinrichtungen 134-1 bis N bedienen (beispielsweise Arbeitsplatzcomputer oder Personalcomputer) und/oder leitungsvermittelte (zweite) Telekommunikationseinrichtungen 138-1 bis M, die alle durch ein lokales Netz LAN (oder Weitverkehrsnetz WAN) 142 untereinander verbunden sind. Die Server können über optionale Kommunikationsleitungen 146 mit der Vermittlungseinrichtung 130 verbunden sein. Wie zu erkennen sein wird, können die anderen Server 126 auch einen Scanner (der normalerweise nicht mit der Vermittlungseinrichtung 130 oder dem Webserver verbunden ist), VoIP-Software, Videoanrufsoftware, Sprachbenachrichtigungssoftware, einen IP-Sprachserver, einen Fax-Server, einen Webserver und einen E-Mail-Server und dergleichen umfassen. Die Vermittlungseinrichtung 130 ist über eine Mehrzahl von Amtsleitungen 150 mit dem öffentlichen Telekommunikationsnetz oder PSTN 154 und über eine/mehrere Verbindung(en) 152 mit den zweiten Telekommunikationseinrichtungen 138-1 bis M verbunden. Ein Gateway 158 ist zwischen dem Server 110 und dem paketvermittelten Netz 162 angeordnet, um Kommunikationsvorgänge abzuwickeln, die zwischen dem Server 110 und dem Netz 162 laufen.
Der Begriff "Vermittlungseinrichtung" oder "Server", wie er vorliegend genutzt wird, sollte dahingehend verstanden werden, dass er eine Nebenstellenanlage- (PBX-), eine automatische Anrufverteilungs- (ACD-), eine Firmen-Vermittlungseinrichtung oder eine andere Art von Telekommunikationssystem-Vermittlungseinrichtung oder -Server einschließt, ebenso wie andere Arten von prozessorbasierten Kommunikationssteuerungseinrichtungen wie etwa Medienserver, Computer, Adjuncts, usw.
Die Vermittlungseinrichtung 130 und/oder der Server 110 können eine beliebige Architektur aufweisen, um Kontakte zu einer oder zu mehreren Telekommunikationseinrichtungen zu lenken. Beispielsweise können die Vermittlungseinrichtung und/oder der Server eine modifizierte Form des ACD-Systems auf Basis der Nebenstellenanlage (PBX) Definity^TM, der PBX MultiVantage^TM, des CRM Central 2000 Server^TM, des Communication Manager^TM, des Medienservers S8300^TM und/oder des Avaya Interaction Center^TM der Avaya Inc. darstellen. Typischerweise stellt die Vermittlungseinrichtung/der Server ein speicherprogrammgesteuertes System dar, das in herkömmlicher Weise Schnittstellen zu externen Kommunikationsverbindungen, ein Kommunikationskoppelnetz, Dienstschaltungen (z. B. Tongeneratoren, Ansageschaltungen usw.), einen Speicher zum Speichern von Steuerprogrammen und Daten sowie einen Prozessor (d. h. einen Computer) zum Ausführen der gespeicherten Steuerprogramme, um die Schnittstellen und das Koppelnetz zu steuern und eine automatische Kontaktverteilungsfunktionalität bereitzustellen, umfasst. Die Vermittlungseinrichtung und/oder der Server umfassen typischerweise eine (nicht gezeigte) Netzschnittstellenkarte, um Dienste für die bedienten Telekommunikationseinrichtungen bereitzustellen. Andere Arten bekannter Vermittlungseinrichtungen und Server sind im Fachgebiet allgemein bekannt und werden daher vorliegend nicht im Detail beschrieben.
Die ersten Telekommunikationseinrichtungen 134-1, ... 134-N sind paketvermittelt und können beispielsweise IP-Hardphones wie etwa die 4600 Series IP Phones^TM der Avaya Inc., IP-Softphones wie etwa das IP Softphone^TM der Avaya Inc., persönliche digitale Assistenten oder PDAs, Personalcomputer oder PCs, Laptops, paketbasierte H.320-Videotelefone und Konferenzschaltungseinheiten, paketbasierte Sprachbenachrichtigungs- und Antworteinheiten, paketbasierte herkömmliche Computertelefonie-Adjuncts und eine andere Kommunikationseinrichtung sein.
Die zweiten Telekommunikationseinrichtungen 138-1, ... 138-M sind leitungsvermittelt und können beispielsweise drahtgebundene und drahtlose Telefone, PDAs, H.320-Videotelefone und Konferenzschaltungseinheiten, Sprachbenachrichtigungs- und -Antworteinheiten, herkömmliche Computertelefonie-Adjuncts und eine andere Kommunikationseinrichtung sein.
Das paketvermittelte Netz 162 kann ein beliebiges Datennetz und/oder Netz mit verteilter Verarbeitung wie etwa das Internet sein.
Das paketvermittelte Netz 162 steht in Verbindung mit einer externen ersten Telekommunikationseinrichtung 174 über ein Gateway 178, und das leitungsvermittelte Netz 154 mit einer externen zweiten Telekommunikationseinrichtung 180.
Es sei betont, dass die Konfiguration der Vermittlungseinrichtung, des Servers, der Nutzer-Telekommunikationseinrichtungen und andere Elemente, wie sie in 1 gezeigt ist, lediglich der Veranschaulichung dient und nicht als die Erfindung auf irgendeine spezielle Anordnung von Elementen einschränkend betrachtet werden sollte.
Nehmen wir Bezug auf 2, so ist in dieser eine mögliche Konfiguration des Servers 110 dargestellt. Der Server 110 steht in Verbindung mit einer Mehrzahl von Teilnehmerkommunikationsleitungen 200a–y (welches eine oder mehrere Amtsleitungen, Telefonleitungen, usw. sein können) und einer Agentenkommunikationsleitung 204 (welches eine Übertragungsleitung für Sprache und Daten wie etwa eine LAN-Leitung 142 und/oder eine leitungsvermittelte Sprachleitung 140 sein kann). Der Server 110 kann ein Ereignisverarbeitungsmodul 228 wie beispielsweise eine modifizierte Form des Basic Call Management System^TM oder BCMS, Call Management System^TM und/oder Operational Analyst^TM der Avaya Inc. sein, welche Anrufdatensätze und Kontaktzentralen-Statistik zur Nutzung bei der Erzeugung von Kontaktzentralen-Berichten sammelt.
Unter den in dem Server 110 gespeicherten Daten befindet sich ein Satz von Kontaktwarteschlangen 208a–n und ein separater Satz von Agentenwarteschlangen 112a–n. Jede Kontaktwarteschlange 208a–n entspricht einem unterschied lichen Satz von Agenten-Fähigkeiten, ebenso wie jede Agentenwarteschlage 212a–n. Herkömmlich wird Kontakten eine Priorität zugeordnet und sie werden entweder in einzelnen Kontaktwarteschlangen 208a–n in der Reihenfolge ihrer Priorität eingereiht oder werden in unterschiedlichen einer Mehrzahl von Kontaktwarteschlangen, die einer unterschiedlichen Priorität entsprechen, eingereiht. Gleichfalls wird den Fähigkeiten jedes Agenten eine Priorität zugeordnet, und zwar entsprechend dem Niveau der Expertenkenntnisse bezüglich dieser Fähigkeit, und die Agenten werden entweder in einzelnen Agentenwarteschlangen 212a–n in der Reihenfolge ihre Niveaus an Fachkenntnissen eingereiht oder werden in unterschiedliche einer Mehrzahl von Agentenwarteschlangen 212a–n eingereiht, die einer Fähigkeit entsprechen und wovon jede einem unterschiedlichen Niveau an Fachkenntnissen entspricht. Unter den Steuerprogrammen in dem Server 110 befindet sich ein Kontaktvektor 216. Kontakte, die in der Kontaktzentrale eingehen, werden durch den Kontaktvektor 216 unterschiedlichen Kontaktwarteschlangen 208a–n zugeordnet, und zwar auf Basis einer Reihe vorbestimmter Kriterien, darunter der Identität des Kunden, den Ansprüchen des Kunden, den Ansprüchen der Kontaktzentrale, der momentanen Länge der Warteschlangen der Kontaktzentrale, dem Wert des Kunden und der Fähigkeit des Agenten, die zur richtigen Abwicklung des Kontakts erforderlich ist. Agenten, die zur Abwicklung von Kontakten zur Verfügung stehen, werden auf Basis der Fähigkeiten und/oder des Niveaus an Fähigkeiten, die sie besitzen, den Agentenwarteschlangen 212a–n zugeordnet.
3 stellt eine Ausführungsform des Ereignisverarbeitungsmoduls 228 dar. Das Modul 228 umfasst einen ersten Satz 300 von Einrichtungen, nämlich eine Firmendatenbank 304 und ein Extraktions-, Transformations- und Lade- oder ETL-Moduls 308, die von der Firma kontrolliert werden, sowie einen zweiten Satz 312 von Einrichtungen, nämlich die firmenkontrollierte(n) Spezifikation(en) 318, einen Datenmodellmodifikator 322, Arbeitswarteschlangen 316a–n, ein Datenimportmodul 320, eine Anbieter-Datenbank 324, eine Erweiterungstabelle 328, ein Semantik-Modul 332, eine Schlüsselverwaltung 336 sowie einen Identitätsauflösungsdienst 340, die alle von einer dritten Seite, beispielsweise dem Hersteller, Anbieter oder der Dienstanbieter- oder Verwaltungsentität der Kontaktzentralen-Software kontrolliert werden. Anders ausgedrückt besitzen die Firma und die dritte Seite einen ersten und einen zweiten Satz von Berechtigungen, was die Modifikation der Datenbanksoftware der Kontaktzentrale betrifft, wobei der erste Satz von Berechtigungen nicht die Fähigkeit einschließt, die Datenbanksoftware und/oder das Datenmodell der Kontaktzentrale zu modifizieren, und wobei der zweite Satz von Berechtigungen diese Fähigkeit einschließt. Das "Modifizieren der Datenbanksoftware und/oder des Datenmodells" umfasst beispielsweise die Fähigkeit, Dimensionen, Schlüssel oder Attribute sowie Zeilen und/oder Spalten von Tabellen einzufügen, zu löschen und/oder zu aktualisieren.
Die Firmendatenbank 304 sowie das ETL-Modul 308 sind herkömmlich. Wie zu erkennen sein wird, liest das ETL-Modul 308 Daten aus seiner Quelle, bereinigt diese und formatiert sie einheitlich und schreibt sie danach in das Ziel-Repository, welches als eine Arbeitswarteschlange 316 dargestellt ist. Beispielshalber führt das ETL-Modul 308 etwaige Abbildungen von Schlüsseln/Identifiern von externen Quellen auf natürliche Schlüssel aus, die von dem durch die dritte Seite kontrollierten System erkannt werden. Das ETL-Modul 308 stellt ferner sicher, dass die korrekten Daten geladen werden. Dies kann die Ausführung von Berechnungen oder anderen Transformationen an den Daten sowie die Verknüpfung dieser mit den richtigen Entitäten beinhalten. Beispiele für geeignete Software für die Firmendatenbank 304 sind die Datenbankprodukte von Oracle^TM sowie die SQL-Server-Datenbankprodukte von Microsoft^TM sowie die Software zur Verwaltung von Kundenbeziehungen von Siebel^TM, und Beispiele für geeignete ETL-Module sind die ETL-Systeme, die von Microsoft^TM, Oracle^TM, IBM^TM, der Ascential Software Corporation^TM und Hummingbird Ltd^TM angeboten werden.
Die firmenkontrollierte(n) Spezifikation(en) 318 und der Datenmodellmodifikator 322 stellen zusammen ein erweiterbares Datenmodell bereit, das von der dritten Seite nach Anforderung durch die Firma modifiziert werden kann. Die Spezifikation(en) stellt/stellen vorzugsweise eine Metadaten-Spezifikation der Firma dar. Die Spezifikation stellt eine Datei in eXtended Markup Language oder XML dar, welche die Tabellen und Spalten definiert, die in das Datenmodell eingefügt werden sollen, aus diesem gelöscht werden sollen oder in diesem aktualisiert werden sollen. Die Spezifikation stellt vorzugsweise einen Satz von XML-Tags und deren Beziehungen zueinander dar. Die Firma ändert die Spezifikation(en) manuell und/oder über eine Benutzerschnittstelle. Die Benutzerschnittstelle würde beispielsweise dem Nutzer eine Reihe von Anfragen stellen, was die vorgeschlagenen Modifikationen betrifft, und würde die Antworten in eine XML-Datei in der/den Spezifikation(en) schreiben. Um dies zu ermöglichen, kann die Firma bei einer Konfiguration ausgewählte Teile des Datenmodells und/oder der echten Tabellen für die Datenbank 324 anschauen (ohne Änderungsberechtigungen). Der Datenmodellmodifikator 322 implementiert die in der/den Spezifikation(en) 318 angegebene Modifikation. Das Datenmodell kann von dem Datenmodifikator 322 in zumindest folgender Weise modifiziert werden:

1. anwendungsspezifische Fakten können zu einer existierenden Faktentabelle hinzugefügt werden;
2. anwendungsspezifische Fakten können zu einer neuen Tabelle hinzugefügt werden, die parallel einer bestehenden Faktentabelle vorgesehen wird;
3. anwendungsspezifische Attribute können zu einer bestehenden Dimensionstabelle hinzugefügt werden;
4. anwendungsspezifische Attribute können zu einer neuen Tabelle hinzugefügt werden, die parallel zu einer bestehenden Dimensionstabelle vorgesehen ist; und
5. anwendungsspezifische Tabellen können hinzugefügt werden.

Dies vorausgesetzt, umfasst/umfassen die Spezifikationen typischerweise Spezifikationen, welche die Daten betreffen, die von dem ETL-Modul empfangen werden sollen. Beispiele für solche Spezifikationen sind Dimensionsidentitäten und Beziehungen zu anderen Objekten (d. h. Dimensionen, Schlüsseln und Attributen) in dem Datenmodell 324, die Identitäten neuer Reihen und Spalten sowie die Beziehungen zu anderen Objekten in dem Datenmodell, Schlüsselidentitäten und -typen sowie deren Beziehungen zu anderen Objekten in dem Datenmodell, Attributidentitäten und -beziehungen zu anderen Objekten in dem Datenmodell, die Identitäten von Spalten, welche Änderungen vom Typ 1 oder 2 erfordern, und dergleichen.
Wenn eine existierende Fakten- oder Dimensionstabelle erweitert wird, werden die Spalten, die in der/den Spezifikation(en) spezifiziert sind, von dem Modifikator 322 zu der existierenden Tabelle hinzugefügt. Dies ermöglicht eine einfachere und bessere Ausführung von Listenabfragen, kann aber zu breiten Tabellen führen. Dieser Ansatz ist natürlich beschränkt, wenn eine spezielle Datenbankimplementierung die Anzahl der Spalten, die in einer Tabelle gestattet sind, einschränkt.
Um Einschränkungen bezüglich breiter Tabellen zu umgehen, kann der Datenmodellmodifikator 322 eine neue Tabelle erzeugen, die parallel zu der bestehenden Tabelle vorgesehen wird. Die neue Tabelle enthält die anwendungsspezifischen Spalten sowie einen Schlüssel, der sich auf die bestehende Tabelle bezieht. Dieser Ansatz ist beliebig erweiterbar, erfordert aber eine Vereinigung, um auf die Spalten oder Datenfelder der Firma zuzugreifen. Neue Tabellen, die über diesen Ansatz erzeugt werden, werden von der dritten Seite in der gleichen Weise wie Standardtabellen verwaltet.
Der Modifikator 322 kann auch anwendungsspezifische Tabellen erzeugen, die vollständig von der Firma verwaltet werden.
Die neuen Tabellen und die Firmentabellen sind insgesamt in den Erweiterungstabellen 328 umfasst.
Für jede Tabelle mit anwendungsspezifischen Spalten und für jede Erweiterungstabelle 328 erzeugt der Modifikator 322 eine entsprechende Arbeitswarteschlange 316a–n. Jede Arbeitswarteschlange enthält die anwendungsspezifischen Spalten und den natürlichen Schlüssel und empfängt Daten von dem ETL-Modul 308 zum Import in die jeweilige anwendungsspezifische Spalte in der Datenbank 324 des Anbieters und/oder in die entsprechende anwendungsspezifische (Erweiterungs-)Tabelle 328. Vorzugsweise sind die einzigen Tabellen, in welche die Firma schreiben kann, die Arbeitswarteschlangentabellen und etwaige firmenkontrollierte anwendungsspezifische Tabellen.
Das Datenimportmodul 320 kopiert die Daten aus den Arbeitswarteschlangen 316a–n gegebenenfalls in die Datenbank 324 der dritten Seite und die Erweiterungstabellen 328. Das Modul 320 wirkt als ein Eingabeadapter, der die Datensätze in der Arbeitswarteschlange in normierte Ereignisse übersetzt und nötigenfalls Dimensionsaktualisierungen vornimmt. Ein "Ereignis" ist ein Vorkommnis oder ein Vorfall, und ein "normiertes Ereignis" ist ein Ausdruck für ein Ereignis, das mit den Datenstrukturen in dem Datenmodell der dritten Seite konsistent ist. Normierte Ereignisse werden für jede Aktualisierung erzeugt und werden zur Verarbeitung in das System 312 eingespeist. Beispielsweise konvertiert das Modul 320 natürliche Schlüssel zu Entitätsidentifiern oder für die Datenbank 324 der Kontaktzentrale internen Schlüsseln, und zwar mit Hilfe des (optionalen) Identitätsauflösungsdienstes (IRS – Identity Resolution Service) 340 und der Schlüsselverwaltung 336.
Das Datenimportmodul kann auf mehrerlei Weise anwendungsspezifische Ereignisse in normierte Ereignisse konvertieren. Beispielsweise kann ein XML-Schema für anwendungsspezifische Ereignisse definiert werden und ein Web-Dienst publiziert werden, der das XML in normierte Ereignisse übersetzt. Ein alternativer Ansatz besteht darin, einen anwendungsspezifischen Eingabeübersetzer zu implementieren, der Ereignisse von dem ETL-Modul 308 empfängt und diese in normierte Ereignisse übersetzt. Zusätzlich kann eine standardmäßige Ereignisquelle ihre eigenen anwendungsspezifisch gestaltbaren Ereignisfähigkeiten aufweisen.
Das Datenimportmodul kann derart terminiert werden, dass in es einem von der Firma spezifizierten Intervall läuft (z. B. täglich, stündlich, alle 5 Minuten, usw.), manuell aufgerufen wird, nachdem das ETL-Modul gelaufen ist, oder von einem Datenbanktrigger aufgerufen wird.
Der Identitätsauflösungsdienst 340 unterhält eine Tabelle mit Entitätsidentifiern, Hinweisen und entsprechenden natürlichen Schlüsseln. Ein "Hinweis" ist eine Form von Anweisung, die angibt, wann ein Surrogatschlüssel zur Nutzung gültig ist. Beispiele für Hinweise sind Ja/Nein-Merker bezüglich der Verfügbarkeit des Surrogatschlüssels für den momentanen Gebrauch, ein Datum und/oder eine Zeit, nach welchem/r der Surrogatschlüssel gültig ist, eine Signatur, die anzeigt, dass der Schlüssel gültig ist, ein bezeichnetes Ereignis, das auftreten muss, bevor der Schlüssel gültig ist, ein Zeitstempel (wie beispielsweise von der Entitäts-IDentifier- oder EID-Anforderung), der Surrogatschlüssel selbst, eine Sequenznummer und dergleichen. Bei einer Ausführungsform wird der Hinweis von der Schlüsselverwaltung genutzt, um von einer EID auf einen entsprechenden (gültigen) Surrogatschlüssel abzubilden.
Die Schlüsselverwaltung 336 verwaltet die Surrogatschlüssel. Wenn eine administrative Änderung bewirkt, dass ein neuer Surrogatschlüssel generiert wird, sendet die Schlüsselverwaltung 336 den Entitätsidentifier an den Identitätsauflösungsdienst 340 zusammen mit dem Hinweis, dass ein neuer Surrogatschlüssel verfügbar ist. Die Konfigurationen und Funktionsvorgänge des IRS 340 und der Schlüsselverwaltung 336 sind detailliert in der gleichzeitig anhängigen US-Anmeldung 11/199,828, eingereicht am 08. August 2005, mit dem Titel "Deferred Control of Surrogate Key Generation in a Distributed Processing Architecture" von Bland et al. beschrieben, die hier durch diese Bezugnahme einbezogen wird.
Das (optionale) Semantikmodul 332 bietet ein Objektmodell zum Aktualisieren von Dimensions- und Faktendaten an, versteckt die Details der Implementierung der realen Datenbank vor der Firma, einschließlich des realen Schemas, der Abstraktion der Datenbank der dritten Seite sowie der Dimensionssemantik vom Typ 2, verwaltet die Dimensionssemantik vom Typ 2 (d. h. wickelt Dimensionsänderungen vom Typ 2 ab, darunter die Erzeugung von Surrogatschlüsseln) und schreibt, in Zusammenarbeit mit dem Datenimportmodul 320, Dimensions- und Faktendaten in die Datenbanken.
Die Drittseiten-, Erweiterungstabellen- und Firmendatenbank, 304, 324 und 328, bilden zusammen die Datenbank 114 aus 1. Die Datenbanken enthalten Fakten und Messwerte und damit in Beziehung stehende Semantik, eine Anzahl von Firmenobjekten betreffend, beispielsweise Kunden, Agenten, Kontakte oder Arbeitsthemen, sowie die Agenten- und Kontaktwarteschlangen 208 und 212.
Die Funktionsweise des Datenmodellmodifikators 322 soll nun mit Bezug auf 4 diskutiert werden.
Der Prozess wird in Schritt 400 eingeleitet, wenn ein Eintrag durch die Firma in die Spezifikation(en) 318 geschrieben wird.
In Schritt 404 erkennt der Modifikator 322 den Eintrag durch ein geeignetes Verfahren. Das Verfahren kann beispielsweise in einem Abfragemechanismus bestehen, oder indem direkt der Modifikator 322 ausgelöst wird, nachdem der Eintrag erfolgte.
In Schritt 408 ruft der Modifikator 322 einen nächsten Eintrag in der/den Spezifikation(en) ab.
In Schritt 412 modifiziert der Modifikator 322 das Datenmodell wie durch den Eintrag angefordert.
In Schritt 416 löscht der Modifikator 322 den verarbeiteten Eintrag aus der/den Spezifikation(en).
Im Entscheidungsfeld 420 stellt der Modifikator 322 fest, ob es einen nächsten Eintrag in der/den Spezifikation(en) gibt. Falls nicht, kehrt der Modifikator 322 zu Schritt 400 zurück. Falls ja, kehrt der Modifikator 322 zu Schritt 408 zurück und wiederholt diesen in Bezug auf den nächsten Eintrag.
Ein Beispiel soll die Funktionsweise des Modifikators 322 veranschaulichen. Nehmen wir an, dass die Firma eine Agentenkennung zu dem Datenmodell hinzufügen möchte, weil die Firma eine interne Agentenkennung für jeden ihrer Agenten in der Kontaktzentrale hat. Die Firma möchte daher zu der Agentdimension des Datenmodells der dritten Seite hinzufügen. Die Firma erzeugt eine XML-Spezifikation, die angibt, dass eine Spalte (oder Dimension des Typs 2), die als "Kunden-ID" bezeichnet wird, zu der Tabelle Agentdimension hinzugefügt werden soll. Der Spaltentyp wird als "String" bezeichnet. Wie zu erkennen sein wird, sind andere potentielle Typen für Spalten eine numerische Währung, ein ganze Zahl, Gleitzahl und Datum/Zeit. Die XML-Spezifikation lautet folgendermaßen:
Unter Ansprechen darauf erzeugt der Modifikator in dem Datenmodell eine Erweiterungstabelle für die Tabelle Agentdimension, welche die Spalte Kunden-ID enthält (als ein Fremdschlüssel in dem Datenmodell der dritten Seite für die Datenbank 324) und fügt eine Arbeitswarteschlangentabelle hinzu, die mit der Erweiterungstabelle verknüpft ist. Nachdem Daten in die Arbeitswarteschlange für eine Kundenkennung geschrieben worden sind, werden sie von dem Datenimportmodul 320 in die entsprechende Erweiterungstabelle geschrieben. Wie zu erkennen sein wird, könnte die neue Spalte, anstatt dass eine separate Erweiterungstabelle erzeugt wird, direkt an das Datenmodell für die Datenbank 324 angefügt werden.
Die Funktionsweise des Datenimportmoduls 320, des Identitätsauflösungsdienstes 340, der Schlüsselverwaltung 336 und des Semantikmoduls 332 soll nun mit Bezug auf 5 beschrieben werden.
Im Schritt 500 schreibt das ETL-Modul 320 einen Datensatz/mehrere Datensätze in eine oder mehrere Arbeitswarteschlangen (z. B. Arbeitswarteschlangentabellen).
In Schritt 504 erkennt das Datenimportmodul 320 den/die neuen Datensatz/-sätze in der/den Arbeitswarteschlange(n). Die Erkennung erfolgt durch irgendein geeignetes Verfahren, beispielsweise durch einen Abfragemechanismus (bei welchem das Datenimportmodul periodisch (in definierten Intervallen) die Arbeitswarteschlangen nach Informationen über unverarbeitete Einträge abfragt), einen Datenbanktrigger (welcher Software in der Arbeitswarteschlange aktiviert; d. h. ein Datenbankcode in den Arbeitswarteschlangen ruft einen Applikationscode auf, wenn der Datenbankcode feststellt, dass eine neue Zeile in die Arbeitswarteschlangentabelle geschrieben worden ist) oder indem die Firma direkt eine Importapplikation auslöst, nachdem in die Warteschlangentabelle geschrieben werden ist.
In Schritt 508 ruft das Datenimportmodul 320 den nächsten (eingegebenen) Datensatz aus der Arbeitswarteschlange ab.
In Schritt 512 führt das Datenimportmodul 320 etwaig notwendige Transformationen an dem abgerufenen Datensatz zur Normierung der Daten aus. Beispielsweise werden die (externen) natürlichen Schlüssel der Firma in (interne) Schlüssel des Datenbankmodells (beispielsweise Entitätsidentifier) konvertiert.
In Schritt 516 liest das Datenimportmodul 320 den seit kürzestem existierenden Datensatz aus der Datenbank 114 für den spezifizierten internen Schlüssel.
In Schritt 520 vergleicht das Modul 320 die Attribute des existierenden Datenbank-Datensatzes mit den neuen Attributen in dem abgerufenen Datensatz.
Im Entscheidungsfeld 524 stellt das Modul 320 fest, ob sich irgendwelche Attribute geändert haben. Anders ausgedrückt stellt das Modul fest, ob die Attribute in dem abgerufenen Datensatz sich von den Attributen in der Datenbank 114 für den spezifizierten internen Schlüssel unterscheiden.
Wenn keine Änderung vorhanden ist, führt das Modul 320 in Schritt 528 keinerlei Änderung an der Datenbank 114 für den abgerufenen Datensatz aus.
Wenn eine Änderung vorhanden ist, stellt das Modul 320 im Entscheidungsfeld 536 fest, ob sich irgendwelche Attribute vom Typ 2 geändert haben.
Wenn sich kein Attribut vom Typ 2 geändert hat, führt das Modul 320 in Schritt 532 eine Aktualisierung vom Typ 1 aus. Bei einer Konfiguration wird, wenn eine Dimension vom Typ 1 konfiguriert wird, der Entitätsidentifier als der Schlüssel genutzt, und eine Aktualisierung in Schritt 532 beeinflusst die existierende Zeile in der Tabelle.
Wenn sich ein Attribut vom Typ 2 geändert hat, erzeugt das Semantikmodul in Schritt 540 einen neuen Surrogatschlüssel, und in Schritt 544 fügt das Datenimportmodul 320 einen neuen Datensatz, der den neuen Surrogatschlüssel und einen/mehrere neue(n) Attributwert(e) enthält, ein.
Bei einer Konfiguration, wenn eine Dimension vom Typ 2 konfiguriert wird und sich die Aktualisierung auf eine Dimension bezieht, wählen die Module 320 und 332 die momentanen Dimensionsdaten aus der Datenbank aus (wobei die Auswahl auf dem Entitätsidentifier oder der Nutzung der Schlüsselverwaltung 336 zur Abbildung des Entitätsidentifiers auf einen entsprechenden Surrogatschlüssel basiert) (Schritt 516); vergleicht die momentanen Daten mit den für die Aktualisierung angeforderten neuen Daten (falls keine Spalten geändert wurden, ist keine momentane Aktualisierung notwendig) (Schritt 520); stellt fest, welche Spalte vom Typ 2 ist (Schritt 536); erzeugt, wenn alle Änderungen auf Spalten vom Typ 1 beschränkt sind, eine Aktualisierungsanweisung, um die momentane Zeile in der Datenbank zu aktualisieren (Schritt 532); und fordert, falls sich eine Spalte vom Typ 2 geändert hat, einen neuen Surrogatschlüssel von der Schlüsselverwaltung an (Schritt 540) und generiert eine Einfügungsanweisung, um eine neue Zeile in die Datenbank mit dem neuen Surrogatschlüssel einzufügen (Schritt 544).
Falls eine Spalte vom Typ 2 konfiguriert wird und die Aktualisierung einen Fakt betrifft, aktualisieren die Module 320 und 322 den Fakt, indem sie einen Surrogatschlüssel von der Schlüsselverwaltung anfordern, und zwar unter Nutzung des Entitätsidentifiers und eines Hinweises (wie erwähnt informiert der Hinweis die Schlüsselverwaltung darüber, welcher Surrogatschlüssel für die spezielle Faktenaktualisierung gilt, und wird von dem IRS, dem Datenimportmodul oder einem Ereignisprozessor erzeugt und der Schlüsselverwaltung zur Verfügung gestellt) (Schritt 540), und erzeugt eine geeignete Anweisung in Structured Query Language (SQL), um die Faktdaten mit Hilfe des von der Schlüsselverwaltung bereitgestellten Surrogatschlüssels einzufügen oder zu aktualisieren (Schritt 544).
Eine Veranschaulichung der Funktionsweise des Dateneingabe- und des Semantikmoduls 320 und 332 soll unter Bezugnahme auf das vorstehende Beispiel diskutiert werden. Nehmen wir an, dass ein Agent "Bob Smith", der in der Datenbank 324 einen natürlichen Schlüssel "100" hat, eine entsprechende Kunden-ID "12345" aufweist. In der entsprechenden Arbeitswarteschlange schreibt das ETL-Modul einen Fremdschlüssel, nämlich "100" (der dem natürlichen Schlüssel der dritten Seite entspricht), und den entsprechenden natürlichen Schlüssel der Firma, oder die Kunden-ID, nämlich "12345". Das Datenimportmodul erkennt den Eintrag in der Arbeitstabelle und fügt einen entsprechenden Datensatz ein, nämlich eine neue Instanz "Bob Smith" mit einem neuen Schlüssel "101", weil die Änderung als eine Änderung vom Typ 2 spezifiziert ist. Der Datensatz stellt eine neue Zeile in der Tabelle Agentdimension dar, die durch den Schlüssel "101" identifiziert wird. Der Eintrag wird dann aus der Tabelle in der Arbeitswarteschlange gelöscht.
Eine Reihe von Varianten und Modifikationen der Erfindung können genutzt werden. Es wäre möglich, einige Merkmale der Erfindung vorzusehen, ohne dass andere vorgesehen werden.
Beispielsweise ist bei einer alternativen Ausführungsform die Erfindung nicht auf Dimensionsmodelle vom Typ 2 beschränkt, sondern auf irgendein Dimensionsmodell oder eine andere Art von relationalem (nicht-dimensionalem) Datenbankmodell. Die Erfindung ist insbesondere anwendbar auf jede Applikation, bei welcher eine komplizierte Semantik zwischen dem Datenmodell der Applikation und den Erweiterungen, die ein Kunde möglicherweise integrieren möchte, vorhanden ist. Obwohl eine Semantik vom Typ 2 ein gutes Beispiel für eine solche Komplexität darstellt, könnte es andere Anwendungen geben, die nur Typ-1-dimensionale oder nicht-dimensionale Datenbanken mit komplizierter Semantik umfassen.
Bei einer anderen alternativen Ausführungsform kann der Server und/oder die Vermittlungseinrichtung ein softwaregesteuertes System darstellen, das eine Verarbeitungseinheit (CPU), einen Mikroprozessor oder eine andere Art von digitalem Datenprozessor umfasst, der Software ausführt, oder eine anwendungsspezifische integrierte Schaltung (ASIC) wie auch verschiedene Teile oder Kombinationen solcher Elemente. Der Speicher kann einen Direktzugriffsspeicher (RAM), einen Nur-Lese-Speicher (ROM) oder Kombinationen dieser und anderer Arten elektronischer Speichereinrichtungen darstellen.
Die vorliegende Erfindung in ihren verschiedenen Ausführungsformen umfasst Komponenten, Verfahren, Prozesse, Systeme und/oder Vorrichtungen im Wesentlichen so, wie sie vorliegend dargestellt und beschrieben worden sind, einschließlich verschiedener Ausführungsformen, Teilkombinationen und Teilgruppen derselben. Fachleute auf dem Gebiet werden nach dem Verstehen der vorliegenden Offenbarung verstehen, wie die vorliegende Erfindung auszuführen und zu nutzen ist.
Die vorliegende Erfindung umfasst in verschiedenen Ausführungsformen das Bereitstellen von Einrichtungen und Prozessen ohne solche Elemente, die vorliegend oder in verschiedenen Ausführungsformen des Vorstehenden nicht dargestellt und/oder beschrieben worden sind, darunter ohne solche Elemente, die möglicherweise bei früheren Einrichtungen oder Prozessen verwendet worden sind, z. B. um das Funktionsverhalten zu verbessern, eine einfache Realisierung zu erreichen und/oder die Kosten der Realisierung zu reduzieren.
Die vorstehende Diskussion der Erfindung wurde zum Zwecke der Veranschaulichung und Beschreibung dargeboten. Mit dem Vorstehenden wird nicht beabsichtigt, die Erfindung auf die vorliegend offenbarte(n) Form oder Formen einzuschränken. In der vorstehenden detaillierten Beschreibung sind beispielsweise verschiedene Merkmale der Erfindung in. einer oder mehreren Ausführungsformen zusammengefasst, zum Zwecke der flüssigeren Offenbarung. Diese Methode der Offenbarung darf nicht dahingehend interpretiert werden, dass sie eine Intension widerspiegelt, dass die beanspruchte Erfindung mehr Merkmale erfordere, als explizit in jedem Anspruch angeführt sind. Wie die folgenden Ansprüche reflektieren, beruhen die erfindungsgemäßen Aspekte vielmehr auf weniger als allen Merkmalen einer einzigen vorstehend offenbarten Ausführungsform. Die folgenden Ansprüche seien hiermit also in diese detaillierte Beschreibung einbezogen, wobei jeder Anspruch für sich allein für eine separate bevorzugte Ausführungsform der Erfindung steht.
Obgleich darüber hinaus die Beschreibung der Erfindung die Beschreibung einer oder mehrerer Ausführungsformen und bestimmter Varianten und Modifikationen umfasste, liegen auch andere Varianten und Modifikationen innerhalb des Schutzumfangs der Erfindung, wie sie zum Beispiel nach dem Verstehen der vorliegenden Offenbarung im Rahmen der Fertigkeiten und Kenntnisse von Fachleuten auf dem Gebiet liegen werden. Es wird beabsichtigt, Rechte zu erlangen, die alternative Ausführungsformen in dem gestatteten Umfang einschließen, darunter alternative, austauschbare und/oder äquivalente Strukturen, Funktionen, Bereiche oder Schritte zu den beanspruchten, egal ob diese alternativen, austauschbaren und/oder äquivalenten Strukturen, Funktionen, Bereiche oder Schritte vorliegend offenbart sind oder nicht, und ohne die Absicht, etwaig patentierbare Erfindungsmerkmale öffentlich zu überlassen.

Claims

Datenverarbeitungssystem, umfassend: eine erste Datenbank (304), die von einer ersten Seite unterhalten wird; eine zweite Datenbank (324, 328), die von einer zweiten Seite unterhalten wird, die sich von der ersten Seite unterscheidet; Arbeitswarteschlangenmittel (316) zum Spezifizieren von Daten, die zu der zweiten Datenbank hinzugefügt werden sollen; Extraktions-, Transformations- und Lademittel (308) zum Schreiben von Daten aus der ersten Datenbank in die Arbeitswarteschlangenmittel; und Datenimportmittel (320) zum Importieren von Daten aus der Arbeitswarteschlange in die zweite Datenbank, wobei die erste Seite nicht berechtigt ist, die Daten direkt in die zweite Datenbank zu schreiben.
System nach Anspruch 1, bei welchem die erste Seite ein Kunde ist und die zweite Seite ein Verkäufer der zweiten Datenbank ist, wobei die erste Seite nicht berechtigt ist, die Semantik der zweiten Datenbank direkt zu modifizieren, wobei die erste Seite nicht berechtigt ist, bereits existierende Daten aus der zweiten Datenbank zu löschen und bereits existierende Daten in der zweiten Datenbank zu aktualisieren, und wobei die zweite Seite nicht berechtigt ist, die Semantik der ersten Datenbank direkt zu modifizieren, und welches ferner umfasst: Semantikmittel zum Ausführen von Aktualisierungen an Dimensionssemantik vom Typ 2 in der zweiten Datenbank, um den importierten Daten Rechnung zu tragen.
System nach Anspruch 2, bei welchem die erste Seite berechtigt ist, zumindest ausgewählte Teile der zweiten Datenbank anzuschauen, und welche ferner umfasst: eine Spezifikation (318), um eine zweite Datenbank, die von einer zweiten Seite unterhalten wird, zu erweitern, wobei die Spezifikation von der ersten Seite bereitgestellt wird; und Modifikatormittel (322), um ein Datenmodell zu modifizieren, das die zweite Datenbank beschreibt, um die Spezifikation zu reflektieren und die Arbeitswarteschlangenmittel, die der Modifikation entsprechen, zu erzeugen.
System nach einem der Ansprüche 1 bis 3, bei welchem die Arbeitswarteschlangenmittel einen natürlichen Schlüssel für die erste Datenbank umfassen, wobei der natürliche Schlüssel bezüglich der zweiten Datenbank extern ist, wobei die Datenimportmittel den natürlichen Schlüssel in einen für die zweite Datenbank internen und für die erste Datenbank externen Schlüssel konvertieren, und wobei die Modifikation zumindest eine der folgenden darstellt: (i) Hinzufügen von anwendungsspezifischen Fakten zu einer existierende Faktentabelle in der zweiten Datenbank; (ii) Hinzufügen von anwendungsspezifischen Fakten zu' einer neuen Tabelle, die parallel einer existierenden Faktentabelle in der zweiten Datenbank vorgesehen wird; (iii) Hinzufügen von anwendungsspezifischen Attributen zu einer existierenden Dimensionstabelle in der zweiten Datenbank; (iv) Hinzufügen von anwendungsspezifischen Attributen zu einer neuen Tabelle, die parallel einer existierenden Dimensionstabelle in der zweiten Datenbank vorgesehen ist; und (v) Hinzufügen einer anwendungsspezifischen Tabelle.
Verfahren, umfassend: (a) Empfangen, von einer ersten Seite, eines Satzes von Spezifikationen, die eine Erweiterung an einer zweiten Datenbank definieren, die von der zweiten Seite unterhalten wird; (b) Modifizieren der zweiten Datenbank wie in dem Satz von Spezifikationen angegeben, wobei die Modifikation zumindest entweder eine anwendungsspezifische Tabelle oder eine anwendungsspezifische Spalte in einer Tabelle umfasst; (c) Erzeugen einer Arbeitswarteschlange entsprechend der Modifikation; (d) Empfangen von ersten Daten aus einer ersten Datenbank durch die Arbeitswarteschlange; (e) Normieren der ersten Daten, um zweite Daten zu bilden, wobei die ersten Daten mit der ersten Datenbank semantisch kompatibel sind und mit der zweiten Datenbank semantisch inkompatibel sind und wobei die zweiten Daten mit der ersten Datenbank semantisch inkompatibel sind und mit der zweiten Datenbank semantisch kompatibel sind; und (f) Schreiben der zweiten Daten in zumindest entweder eine anwendungsspezifische Tabelle oder eine anwendungsspezifische Spalte in einer Tabelle.
Verfahren nach Anspruch 5, bei welchem eine Arbeitswarteschlange für jeden einer Mehrzahl von Spezifikationssätzen erzeugt wird, wobei die erste Seite ein Kunde ist und die zweite Seite ein Verkäufer der zweiten Datenbank ist, wobei die erste Seite nicht berechtigt ist, die Semantik der zweiten Datenbank direkt zu modifizieren, wobei die erste Seite nicht berechtigt ist, direkt in die zweite Datenbank zu schreiben und wobei die zweite Seite nicht berechtigt ist, die Semantik der ersten Datenbank direkt zu modifizieren, und welches ferner umfasst: (g) Gestatten, dass die erste Seite nur ausgewählte Teile der zweiten Datenbank anschaut.
Verfahren nach einem der Ansprüche 5 bis 6, bei welchem die Modifikation zumindest eine der folgenden darstellt: (i) Hinzufügen von anwendungsspezifischen Fakten zu einer existierenden Faktentabelle in der zweiten Datenbank; (ii) Hinzufügen von anwendungsspezifischen Fakten zu einer neuen Tabelle, die parallel einer existierenden Faktentabelle in der zweiten Datenbank vorgesehen wird; (iii) Hinzufügen von anwendungsspezifischen Attributen zu einer existierenden Dimensionstabelle in der zweiten Datenbank; (iv) Hinzufügen von anwendungsspezifischen Attributen zu einer neuen Tabelle, die parallel einer existierenden Dimensionstabelle in der zweiten Datenbank vorgesehen wird; und (v) Hinzufügen einer anwendungsspezifischen Tabelle.
Verfahren nach einem der Schritte 5 bis 7, bei welchem in Schritt (e) die Arbeitswarteschlange einen natürlichen Schlüssel für die erste Datenbank umfasst, wobei der natürliche Schlüssel bezüglich der zweiten Datenbank extern ist und wobei das Datenimportmodul den natürlichen Schlüssel in einen für die zweite Datenbank internen und für die erste Datenbank externen Schlüssel umwandelt, und welches ferner umfasst: (h) nach Schritt (b) Löschen des verarbeiteten Satzes von Spezifikationen.
Verfahren nach einem der Ansprüche 5 bis 8, bei welchem der Schreibschritt umfasst: (f1) Vergleichen eines ersten Satzes von Attributen in der zweiten Datenbank mit einem entsprechenden bereits existierenden zweiten Satz von Attributen in der zweiten Datenbank; (f2) wenn der erste und der zweite Satz von Attributen unterschiedlich sind, Feststellen, ob sich ein Attribut vom Typ 2 geändert hat; (f3) wenn sich kein Attribut vom Typ 2 geändert hat, Ausführen einer Aktualisierung vom Typ 1 an der zweiten Datenbank; und (f4) wenn sich ein Attribut vom Typ 2 geändert hat, Generieren eines neuen Surrogatschlüssels und Einfügen eines neuen Datensatzes in die zweite Datenbank, der den neuen Surrogatschlüssel und den ersten Satz von Attributen enthält.
Verfahren nach Anspruch 7, wobei die Modifikation (i) ist.
Verfahren nach Anspruch 10, wobei die Modifikation (ii) ist.
Verfahren nach Anspruch 11, wobei die Modifikation (iii) ist.
Verfahren nach Anspruch 12, wobei die Modifikation (iv) ist.
Verfahren nach Anspruch 13, wobei die Modifikation (v) ist.
Computerlesbares Medium, welches ausführbare Anweisungen zum Ausführen der Schritte gemäß Anspruch 5 umfasst.