-
GEBIET DER
ERFINDUNG
-
Die Erfindung betrifft das Verwalten
verwandter Daten, die jeweils in einer Vielzahl von Datenbanken
gespeichert sind.
-
ALLGEMEINER
STAND DER TECHNIK
-
Es ist häufig der Fall, dass verwandte
Daten in verschiedenen Datenbanken gespeichert sein können. Eine
Bank kann beispielsweise verwandte Daten, wie Kontoinformationen,
Kreditwürdigkeit,
Kundendaten, usw. in verschiedenen Datenbanken speichern. Es ist
verständlich,
dass im Laufe der Zeit verwandte Daten, die einem bestimmten Konto
(d. h. einem Kunden) zugeordnet sind, über die verschiedenen Datenbanken
hin inkonsistent werden können. Wenn
dem Konto zugeordnete Daten durch eine bestimmte Bankanwendung aus
einer der Datenbanken ausgewählt
und verarbeitet werden, kann das Endergebnis als solches unrichtig
werden, weil die ausgewählten
Daten mit ihren verwandten Daten, die in den anderen Datenbanken
gespeichert sind, nicht konsistent sind. Als weiteres Beispiel können bei
Telefonanwendungen verschiedene Daten, die auf irgendeine Weise
verwandt sind, z. B. Anlagen-, Bereitstellungs- und Wartungsdaten,
in verschiedenen Datenbanken gespeichert sein. Wenn eine Person
eine Anmeldung für
Telefondienst eingibt, werden die Anlagen zum Implementieren der
Anmeldung aus einer Bereitstellungsdatenbank ausgewählt. Die
ausgewählten
Anlagen können
jedoch nicht tatsächlich
verfügbar
sein. Der Grund dafür
kann zum Beispiel sein, dass die Anlagen wegen Wartungsarbeiten
als nicht verfügbar gekennzeichnet
waren und als solche in der Wartungsdatenbank gezeigt wurden, aber
unbeabsichtigterweise in der Bereitstellungsdatenbank als verfügbar gekenn zeichnet
belassen wurden. Auf diese Weise würde ein Techniker infolge eines
Versuchs, Anlagen zu verwenden, die nicht verfügbar waren, bei der Implementierung
des angeforderten Dienstes erfolglos sein. Es ist verständlich,
dass das Problem von inkonsistenten Daten zwischen mehreren Datenbanken
sowohl schwierig als auch kostspielig zu beheben ist.
-
KURZDARSTELLUNG
DER ERFINDUNG
-
Das vorgenannte Problem wird unter
Verwendung eines so genannten Intelligenten Datenmoduls (IDM) als
einer Schnittstelle zwischen einer Anwendung und der mit ihr verbundenen
Datenbank behoben, wobei gemäß einem
Merkmal der Erfindung die Intelligenten Datenmodule miteinander
kommunizieren, um zu bestimmen, ob Daten, die durch eine verbundene
Anwendung angefordert wurden, mit verwandten Daten, die in den anderen
Datenbanken gespeichert sind, konsistent sind, bevor die Anwendung
auf die Daten zugreifen kann. Wenn herausgefunden wird, dass die
Daten mit ihren verwandten Daten inkonsistent sind, dann kann das
Intelligente Datenmodul gemäß einem
anderen Merkmal der Erfindung entweder eine lokale oder eine entfernte
Datenabgleichungsfunktion aufrufen, um die verwandten Daten zu verarbeiten
und konsistent zu machen.
-
Andere Merkmale der Erfindung werden
aus der nachfolgenden ausführlichen
Beschreibung und den darauf folgenden Ansprüchen deutlich.
-
KURZE BESCHREIBUNG
DER ZEICHNUNGEN
-
Es zeigen:
-
1 ein
Blockdiagramm eines Systems von Operationsanwendungen, in welchem
die Prinzipien der Erfindung angewendet werden können;
-
2 die
logische Aufteilung von Daten in einer Datenbank, die in dem System
von 1 verwendet wird;
-
3 ein
erläuterndes
Beispiel für
eine Datenelementtabelle, die in einer Anwendungsdatenbank in dem
System von 1 gespeichert
ist;
-
4 ein
erläuterndes
Beispiel für
eine Stamm-Datenelementtabelle,
die in dem Datenverzeichnis von 1 gespeichert
ist;
-
5 ein
erläuterndes
Beispiel für
einen Datensatz, der verwendet wird, um ein entsprechendes Datenobjekt
zu definieren, und der in der Datenverzeichnistabelle von 1 gespeichert ist;
-
6 in
Form eines Ablaufdiagramms das Programm, welches eine Anforderung
von Anwendungsdaten entsprechend den Prinzipien der Erfindung verarbeitet;
-
7 ein
Beispiel für
verschiedene logische Regeln, welche in der Regelbasis verschlüsselt werden
können,
die mit einem Intelligenten Datenmodul von 1 verbunden ist; und
-
8 ein
Beispiel verschiedener logischer Regeln, welche in der Regelbasis
verschlüsselt
werden können,
die mit dem Datenabgleichungsprozessor von 1 verbunden ist.
-
AUSFÜHRLICHE
BESCHREIBUNG
-
Eine beispielhafte Ausführungsform
der Erfindung wird im Zusammenhang mit einer Anwendung diskutiert,
die die Bereitstellung von Telefondienst beinhaltet, welcher auf
verwandten Daten aufbaut, die in einer Vielzahl von verschiedenen
Datenbanken gespeichert sind, einschließlich z. B. von Anlagen-, Bereitstellungs-
und Wartungsdatenbanken. Es muss vorausgesetzt werden, dass solch
eine Diskussion nicht als eine Einschränkung der beanspruchten Erfindung
zu sehen ist, weil sie nur eine Anwendung davon ist.
-
In Anbetracht des Vorstehenden sind
die in 1 gezeigten Datenbanken 125-1 bis 125-N jeweils
mit Prozessoren 100-1 bis 100-N verbunden. Prozessoren 100-1 bis 100-N umfassen
jeweils Intelligente Datenmodule (IDM) 115-1 bis 115-N,
von welchen jedes eine entsprechende Anwendung unterstützt. IDM 115-1 bis 115-3 beispielsweise
unterstützen
jeweils Operationsanwendungen 110-1 bis 110-3,
die in 1 jeweils als
Anlagen-, Bereitstellungs- und Wartungsanwendungen identifiziert
sind. Die anderen IDM 115-4 bis 115-N unterstützen andere
Operationsanwendungen, die hier nicht identifiziert sind. Es ist
ersichtlich, dass IDM 115-1 bis 115-N durch entsprechende
Regelbasen 120-1 bis 120-N betrieben werden, wobei
eine Regelbasis ein Satz von logisch strukturierten Regeln ist,
welche ihre verbundene IDM anweist, welche Maßnahmen in einer gegebenen
Situation zu ergreifen sind, basierend auf der Konsistenz eines
Satzes verwandter Datenelemente, deren Werte aus einigen entsprechenden
der Datenbanken 125-1 bis 125-N wiederaufgerufen
wurden.
-
Eine Operationsanwendung 110-2 einer
Telefongesellschaft kann beispielsweise einen Vorgang zum Anfordern
von Daten auslösen,
die für
das Durchführen
einer bestimmten Operationsaufgabe benötigt werden, wie das Bereitstellen
eines neuen Telefondienstes. Gemäß einem
Merkmal der Erfindung richtet die Anwendung die Anforderung an ihr verbundenes
IDM, z. B. IDM 115-2. IDM 115-2 wiederum ruft
die durch den empfangenen Vorgang angeforderten Daten und alle der
Daten, die logisch mit den von dem empfangenen Vorgang angeforderten Daten
verwandt sind, wieder auf. Einige oder alle dieser logisch verwandten
Daten werden sehr wahrscheinlich aus anderen Datenbanken als Datenbank 125-2 wiederaufgerufen.
Nach Empfang der wiederaufgerufenen Daten verarbeitet IDM 115-2 die
Daten entsprechend bestimmten Regeln, die in ihrer verbundenen Regelbasis 120-2 gespeichert
sind, um zu bestimmen, ob die wiederaufgerufenen Daten logisch konsistent
sind. Wenn herausgefunden wird, dass die Daten konsistent sind,
dann liefert IDM 115-2 die angeforderten Daten zu ihrer
verbundenen Operationsanwendung 110-2, um die gewünschte Operationsaufgabe
abzuschließen.
Andernfalls fährt IDM 115-2 entsprechend
einer von einer Anzahl von verschiedenen Optionen fort, die durch
ihre verbundene Regelbasis 120-2 spezifiziert sind, einschließlich der
Option, die Anforderung von Daten auszusetzen, bis die Daten abgeglichen
sind, wie nachstehend im Einzelnen diskutiert wird.
-
In 1 wird
gezeigt, dass ein IDM 115i, z. B. IDM 115-1, zwischen seiner
verbundenen Operationsanwendung 110-i und Datenbank 125-i, z. B.
Datenbank 125-1, angeordnet ist, die die Operationsanwendung
110-i unterstützt.
Dies ermöglicht
jedem IDM 115i, den Fluss von Daten von und zu ihrer verbundenen
Anwendung zu steuern, so dass Synchronisation von Datenelementen,
die über
die Datenbanken in dem System verteilt sind, zu einer Bedingung
gemacht werden kann, um die Verwendung von Daten beim Abschließen irgendeiner
Operationsaufgabe der Anwendung fortzusetzen. IDM 115-1 bis 115-N halten
die Datensynchronisation durch Verarbeiten jedes Datenvorgangs entsprechend
den Regeln aufrecht, die in ihren entsprechenden verbundenen Regelbasen
120-i verschlüsselt
sind. (Derartige Regeln werden für
jede IDM 115i durch Themenexperten erzeugt, die den Zweck und die
Funktionen der verbundenen Anwendungen, die logischen Beziehungen
zwischen den Datenelementen in allen Datenbanken in dem System und
die relativen Operationsrisiken und Auswirkungen verstehen, die
mit dem Abschließen
gewisser Operationsaufgaben verbunden sind, wenn die Datenelemente,
die für
das Abschließen
jener Aufgaben erforderlich sind, mit logisch verwandten Datenelementen
in anderen Datenbanken in dem System synchronisiert oder nicht synchronisiert
werden können).
-
Damit ein IDM 115i seine vorgesehene
Funktion ausführt,
müssen
gewisse Attribute und Beziehungen zwischen den Datenelementen in
dem System definiert und aufgezeichnet werden. Ein derartiges Attribut
nennt sich „Eigentum", welches für jedes Datenelement
anzeigt, ob einzelne oder mehrere Kopien des Datenelements in den
Datenbanken in dem System existieren, und falls mehrere Kopien existieren,
welche Kopie dann als die „erste" Kopie angesehen
wird, d. h. die Kopie, von der angenommen wird, mit größerer Verläßlichkeit
fehlerfrei zu sein als von irgendeiner anderen Kopie. Die Datenbank,
die die erste Kopie eines bestimmten Datenelements enthält, wird
deswegen als der „Eigentümer" dieses Datenelements
angesehen. (Es sei angemerkt, dass Themenexperten, die ein System
von Anwendungen entwerfen, außerdem
kennzeichnen, ob ein Datenelement eine erste Kopie ist und dadurch
identifizieren, welcher Datenbank dieses Datenelement gehört). Ein
zweites Merkmal nennt sich ein „Datenobjekt", dessen Definition
hier ist, der Satz von all den Datenelementen zu sein, die logisch
mit dem (den) Datenelement(en) verwandt sind, die erforderlich sind,
damit eine Operationsanwendung eine gewünschte Operationsaufgabe abschließen kann,
einschließlich
des (der) Datenelements (Datenelemente), die ursprünglich angefordert
waren, wie nachstehend im Einzelnen beschrieben wird.
-
Jedes Datenelement, das in einer
Datenbank 125-i gespeichert ist, ist mit einem Attribut verbunden,
das die Eigentumseigenschaften dieser bestimmten Kopie des Datenelements
definiert. Ein Datenelement kann beispielsweise definiert sein als
(a) „lokale
Daten", wenn sie
nicht in irgendeiner anderen Datenbank gespeichert sind, (b) „erste
gemeinsam genutzte Daten",
wenn sie in mehreren Datenbanken gespeichert sind, aber die in Datenbank 125i gespeicherte
Kopie die erste Kopie ist, oder (c) „zweite gemeinsam genutzte
Daten", wenn sie
in mehreren Datenbanken gespeichert sind, aber die erste Kopie in einer
anderen Datenbank als Datenbank 125-i gespeichert ist. Solch eine
darstellende Identifikation von allen den Datenelementen in einer
Datenbank 125-i als entweder lokale, erste gemeinsam genutzte oder
zweite gemeinsam genutzte, ist in 2 illustriert.
Insbesondere die Informationen, die ein Datenelement in der Datenbank
als lokales, erstes gemeinsam genutztes oder zweites gemeinsam genutztes kennzeichnen,
werden so gezeigt, wie sie in einem entsprechenden Segment der Datenbank
gespeichert sind, das als eine „Datenelementtabelle" bezeichnet wird.
(Selbstverständlich
soll es so verstanden werden, dass 2 eine
Art darstellt, auf welche derartige Informationen in einer Datenbank
gespeichert werden können,
und dass irgendeine andere ähnliche
Speicheranordnung verwendet werden kann, solange entsprechend den
Prinzipien der Erfindung auf die gespeicherten Informationen zugegriffen
und sie verwendet werden können).
-
Ein erläuterndes Beispiel für eine Datenelementtabelle ist
in 3 gezeigt, welche
nachstehend detailliert beschrieben wird.
-
Eine beispielhafte Verwendung einer
Datenelementtabelle, die in einer Datenbank 125i gespeichert
ist, ermöglicht
der verbundenen IDM 115i zu identifizieren, ob andere Kopien von
Datenelementen, die durch eine Anwendung angefordert wurden, in
anderen Datenbanken existieren, und, falls ja, behält sie die
Datensynchronisation über
die Datenbanken bei, entsprechend spezifizierten Regeln, die in
ihrer verbundenen Regelbasis 120i gespeichert sind. So
ruft IDM 115i auf bekannte Weise die Eigentumsattribute, die mit
allen angeforderten Datenelementen verbunden sind, aus der Datenelementtabelle 300
wieder auf, die in ihrer verbundenen Datenbank 125-i gespeichert
sind. Wenn all die angeforderten Datenelemente lokale Daten sind,
dann ist es unwahrscheinlich, dass die Datenelemente mit Datenelementen
in anderen Datenbanken inkonsistent sind. In diesem Fall kann IDM
115i dann durch seine verbundene Regelbasis 120-i unterrichtet werden,
die Datenelemente selbst aus Datenbank 125-i wiederaufzurufen und
sie direkt zu Anwendung 110-i zu leiten, ohne die Datenelemente
weiter auf Konsistenz zu überprüfen. Es
ist außerdem
möglich,
dass die Regelbasis eine Anzahl von Regeln umfassen kann, die zum Überprüfen auf
logische Konsistenz unter Datenelementen konzipiert sind, selbst
wenn der Satz von lokalen Datenelementen aus derselben Datenbank
125-i wiederaufgerufen
würde.
In diesem Fall wäre
das Verarbeiten dieser lokalen Datenelemente dem der wiederaufgerufenen
Datenelemente aus mehreren Datenbanken ähnlich, wie nachstehend diskutiert.
In den meisten Fällen
existieren jedoch in anderen Datenbanken eine Anzahl von Datenelementen,
welche entweder Kopien von oder logisch verwandt mit den in Datenbank
125-i gespeicherten Datenelementen sind. Das entsprechende IDM 115i
muss deswegen die verwandten Datenelemente identifizieren, sie wiederaufrufen
und sie entsprechend den in ihrer verbundenen Regelbasis 120-i gespeicherten
Regeln verarbeiten, um zu bestimmen, ob die Datenelemente untereinander
konsistent sind.
-
In dem Fall, dass eine Anwendung
110-i ein bestimmtes gemeinsam genutztes Datenelement modifizieren
muss, dann wird „Eigentum" verwendet, um sicherzustellen,
dass alle Kopien dieses Datenelements ebenfalls modifiziert werden.
Wenn ein IDM 115i solch eine Anforderung von seiner verbundenen Anwendung
empfängt,
dann identifiziert das IDM 115i zuerst die Anzahl und Speicherstelle
von allen derartigen Kopien von diesem Datenelement. Da die in einer
bestimmten Datenbank vorhandene Datenelementtabelle die Eigentumsattribute
nur für
die Datenelemente identifiziert, die in ihrer „eigenen" Datenbank gespeichert sind, muss dann
das IDM 115i ein anderes Vorgehen verwenden, um in der Lage zu sein,
passenderweise die anderen Kopien des Datenelements zu ermitteln.
Ein solches Vorgehen kann sowohl durch zentrales Speichern der Informationen in
allen der Datenelementtabellen 300 in dem System realisiert werden,
als auch durch Bereitstellen eines Querverweises, der logisch verwandte
gemeinsam genutzte Datenelemente identifiziert. Dieses wird unter
Verwendung einer so genannten „Stamm-Datenelementtabelle" vorgenommen, die
in dem Datenverzeichnis 150 (1)
gespeichert ist.
-
Die in 4 gezeigte
Stamm-Datenelementtabelle 400 stellt insbesondere einen umfangreichen Querverweis
für alle
Datenelemente, die in allen der Systemdatenbanken 125i gespeichert
sind, zur Verfügung.
Die Stamm-Datenelementtabelle
400 identifiziert für
ein gemeinsam genutztes Datenelement die Anzahl, Speicherstellen
und Eigentumsattribute aller Kopien des gemeinsam genutzten Datenelements über alle
Datenbanken 125i in dem System. Auf diese Weise ermöglicht die
Stamm-Datenelementtabelle,
dass ein IDM 115i in einem einzigen Vorgang mit dem Datenverzeichnis
all die Datenelementinformationen wiederaufruft, die benötigt werden,
um die Modifikation eines gemeinsam genutzten Datenelements abzuschließen. Ein
Beispiel der in der Stamm-Datenelementtabelle enthaltenen Informationen
ist in 4 gezeigt.
-
Wann immer ein IDM 115i ein bestimmtes gemeinsam
genutztes Datenelement modifizieren soll, muss zum Beispiel IDM
115i zuerst aus der in ihrer verbundenen Datenbank 125i gespeicherten
Datenelementtabelle 300 bestimmen, ob das zu aktualisierende Datenelement
ein gemeinsam genutztes Datenelement ist. Wenn das der Fall ist,
dann muss IDM 115i eine Mitteilung formulieren und an das Datenverzeichnis 150 zur
Anforderung der Namen und Speicherstellen aller Kopien des gemeinsam
genutzten Datenelements senden, die in anderen Datenbanken speicherresident
und in der in Verzeichnis 150 gespeicherten Stamm-Datenelementtabelle
400 identifiziert sind. Datenverzeichnis 150 wiederum greift
auf die angeforderten Informationen zu und sendet sie zu IDM 115i
zurück.
Andererseits, wenn das gemeinsam genutzte Datenelement in der mit IDM
115i verbundenen Datenbank 125i gespeichert und die erste
gemeinsam genutzte Kopie ist, dann kann IDM 115i, entsprechend den
in seiner verbunden Regelbasis 120i spezifizierten Regeln,
diese Kopie des gemeinsam genutzten Elements sofort aktualisieren.
IDM 115i sendet dann eine Kopie des aktualisierten Datenelements
zu den anderen IDM 115, um die zweiten gemeinsam genutzten Datenelementkopien,
die in ihren entsprechenden Datenbanken 125 gespeichert sind, zu
aktualisieren. Wenn jedoch das in Datenbank 125i gespeicherte,
gemeinsam genutzte Datenelement eine zweite gemeinsam genutzte Kopie
ist, dann muss IDM 115i entsprechend den in seiner verbundenen Regelbasis 120i spezifizierten
Regeln die Erlaubnis, das Datenelement zu aktualisieren, von dem
IDM 115, das Eigentum der ersten gemeinsam genutzten Kopie besitzt, einholen.
Derartige Erlaubnis kann unmittelbar nach Anforderung gewährt werden
oder kann eine andere Serie von Aktionen durch das letztere IDM
115 auslösen,
bevor entweder Erlaubnis gewährt
oder verweigert wird.
-
Die Beschreibung der Datenelementtabellen und
Stamm-Datenelementtabelle
in den Abschnitten und obigem Beispiel sind nicht dazu gedacht,
das Verfahren zu definieren oder einzuschränken, in welchem diese Informationen
in der Systemarchitektur eingeschlossen sind, sondern nur um ein
passendes Referenzmodell zum Beschreiben der Arbeitsweisen anderer
Aspekte der Erfindung zu erstellen.
-
(Es sei angemerkt, dass die vorhergehende Diskussion
der Tabellen 300 und 400 nicht als eine Beschränkung ausgelegt werden soll,
weil es eine Reihe architektonischer Alternativen geben mag, welche
verwendet werden könnten,
um die eine oder andere Datentabelle zu implementieren. In einigen Anwendungen
kann es beispielsweise passender sein, nur Stamm-Datenelementtabelle 400 und nicht Datenelementtabellen
300 zur Verfügung
zu stellen. In diesem Fall würde
ein IDM 115i Stamm-Datenelementtabelle 400 jedes Mal abfragen müssen, wenn es
ein Datenelement identifizieren muss. Als Alternative kann eine
Kopie einer Stamm-Datenelementtabelle 400 in jeder der Datenbanken
125 oder IDM 115 gespeichert werden).
-
Ein wie vorstehend definiertes Datenobjekt bildet
den Mittelpunkt der Erhaltung von Datensynchronisation über alle
Datenbanken in dem System. Ein Datenobjekt für eine bestimmte Operationsaufgabe
ist der komplette Satz von Datenelementen, innerhalb welchem Datenkonsistenz überprüft werden muss,
um sicherzustellen, dass Datenqualität während des Abschließens der
Operationsaufgabe erhalten bleibt. Datenkonsistenz innerhalb eines
Datenobjekts wird durch Anwendung der Regeln überprüft, die zu diesem Zweck aufgestellt
wurden. Zum Sicherstellen der Erhaltung der Datenqualität über ein System
von Anwendungen muss ein Datenobjekt für jede Operationsaufgabe definiert
werden, welche entweder kritische Datenelemente verwendet oder betrifft. Während Datenobjekte
für unterschiedliche
Operationsaufgaben unterschiedlich sein werden, muss die Definition
eines Datenobjekts für
eine Aufgabe standardisiert sein. Aus diesem Grund können die
Definitionen von Datenobjekt für
entsprechende Systemoperationsaufgaben in Datenverzeichnis 150 gespeichert
sein, wie nachstehend besprochen wird.
-
Das Speichern der Definition eines
Datenobjekts in Datenverzeichnis 150 stellt einem IDM 115i Mittel
zur Verfügung,
um ein gewünschtes
Datenelement zu identifizieren und zu ermitteln, welches ein Teil
des Datenobjekts ist, das für
eine bestimmte Operationsaufgabe definiert ist. Ein IDM 115i kann dies
auf folgende Weise vornehmen.
-
Insbesondere das einzigartige Kennzeichen, das
mit allen Datenelementen, die ein Datenobjekt bilden, verbunden
ist, ist als ein Datensatz in Datenverzeichnis 150 gespeichert.
(Wenn gewünscht, könnte die
Datenobjektdefinition außerdem
für jedes Datenelement
seine Eigentumseigenschaften umfassen (z. B. lokales vs. erstes
gemeinsam genutztes vs. zweites gemeinsam genutztes)). In einem
Datenverzeichnisdatensatz kann ein Referenzdatenelement beispielsweise
durch die Identität
(z. B. dem bekannten adressierbaren Namen) der Datenbank, in der das
Datenelement gespeichert ist, und der Identität (z. B. dem bekannten adressierbaren
Namen) des Datenelements in dieser Datenbank beschrieben werden.
Eine logische Darstellung eines derartigen in Datenverzeichnis 150 gespeicherten
Datensatzes ist in 5 gezeigt.
Datensatz 500 wird verwendet, um ein Datenobjekt für eine mit
Schaltungsbereitstellung betitelte Aufgabe zu definieren.
-
Ein Ablaufdiagramm eines beispielhaften Softwareprogramms,
welches die Prinzipien der Erfindung in einem IDM 115i, z. B. 115-1,
implementiert, ist in 6 gezeigt.
Insbesondere auf den Empfang einer Anforderung einer bestimmten
Operationsaufgabe von ihrer verbundenen Anwendung 110-1 ansprechend,
wird das Programm bei Block 600 gestartet und geht zum
Empfangen der Datenanforderung zu 601. Das Programm (Block 602)
sieht dann in seiner verbundenen Datenelementtabelle 300 nach
(in seiner verbundenen Datenbank 125i gespeichert, wie
oben erwähnt),
um zu bestimmen, ob die angeforderten Datenelemente lokale Daten
oder gemeinsam genutzte Daten sind (entweder erste oder zweite).
Wenn das Programm (Block 603) bestimmt, dass die angeforderten
Datenelemente alle lokal sind, dann ruft Programm (Block 615)
die angeforderten Datenelemente aus seiner verbundenen Datenbank 125i wieder
auf und liefert (Block 614) das wiederaufgerufene Ergebnis
auf bekannte Weise an die anfordernde Anwendung.
-
Wenn das Programm feststellt, dass
einige der Datenelemente gemeinsam genutzte Datenelemente sind,
dann bildet das Programm (Block 604) eine Mitteilung zum
Anfordern des Datensatzes, der das Datenobjekt für die Operationsaufgabe definiert, die
durch die Anwendung identifiziert ist, und sendet die Mitteilung
an Datenverzeichnis 150. Nach Empfang der Mitteilung überträgt Datenverzeichnis 150, unter
Verwendung eines Kennzeichens, das in der Mitteilung enthalten ist
und das die Operationsaufgabe identifiziert, die die Daten verwenden
wird, das Kennzeichen zu einer Speicherstelle im Speicher. Datenverzeichnis 150 greift
dann auf diese Speicherstelle in verbundenem Speicher zu, um eine
Kopie des Datensatzes wiederaufzurufen, der das Datenobjekt definiert,
das benötigt
wird, um die Konsistenz der Daten zu verifizieren, die durch die
spezifizierte Aufgabe verarbeitet werden. Datenverzeichnis 150 sendet
dann die Kopie des Datensatzes an das IDM 115-1, welches
die Anforderung verursacht hat.
-
Nach dem Empfang des Datensatzes
von Datenverzeichnis 150 stellt das Programm (Block 605)
das benötigte
Datenobjekt zusammen, indem alle der Datenelemente erfasst werden,
die in dem von Datenverzeichnis 150 empfangenen Datensatz identifiziert
sind. Wenn so verfahren wird, bildet und sendet das Programm eine
Mitteilung zum Anfordern von Daten an jede der anderen IDM 115i,
z. B. IDM 115-2 und 115-3, deren verbundene Datenbank 125i Datenelemente
enthält,
die in dem empfangenen Datensatz identifiziert sind. Auf Empfang
solch einer Mitteilung ansprechend, ruft eine empfangende IDM 115i,
z .B. 115-2, auf bekannte Weise eine Kopie der angeforderten
Daten aus ihrer verbundenen Anwendungsdatenbank, z. B. 125-2,
wieder auf und sendet die Kopie zu dem IDM-115i-Programm, das die
Daten angefordert hat. Ansprechend auf Empfang der angeforderten
Datenelemente aus seiner eigenen Datenbank und aus anderen IDM 115i
stellt das IDM-115i-Programm die empfangenen Daten zu dem gewünschten
Datenobjekt zusammen und speichert das Datenobjekt in verbundenem
Speicher.
-
Verfolgt man das Beispiel weiter,
dann verarbeitet das Programm (Block 606) die Inhalte des
Datenobjekts entsprechend den in seiner verbundenen Regelbasis 120i gespeicherten
Regeln, um zu bestimmen, ob die Datenelemente, die derartige Inhalte bilden,
untereinander logisch konsistent sind. Derartiges Verarbeiten beinhaltet
typischerweise das Aufrufen einer Reihe von Schritten, die mehrere
Datenelemente in dem Datenobjekt (a) miteinander und (b) mit in
den Regeln verschlüsselten
Referenzwerten vergleichen, um zu bestimmen, ob die Datenelemente
den in den Regeln spezifizierten Bedingungen genügen. Wenn das Programm herausfindet,
dass die Datenelemente den in einer bestimmten Regel spezifizierten
Bedingungen genügen,
dann schließt
das Programm daraus, dass die Datenelemente "bestehen", d. h. in Bezug auf diese Regel konsistent
sind. Andernfalls schließt
das Programm daraus, dass die Datenelemente an dieser Regel „scheitern", d. h. in Bezug
auf diese Regel inkonsistent sind.
-
Auf dieselbe Weise verarbeitet das
Programm (Block 606) das Datenobjekt für jede Regel in Regelbasis 120-1,
die für
dieses Datenobjekt definiert ist. Wenn das Programm (Block 607)
bestimmt, dass das Datenobjekt jede derartige Regel einhält, dann
liefert das Programm (Block 614) die angeforderten Daten
zu der Anwendung. Wenn andererseits das Programm (Block 607)
feststellt, dass das Datenobjekt an einer oder mehreren Regeln scheitert,
dann kann das Programm (Block 608) in Regelbasis 120-1 spezifizierte
so genannte Korrekturregeln anwenden, als einen Weg, um zu versuchen,
die Inkonsistenz unter Verwendung von anderen Datenelementen in dem
Datenobjekt abzugleichen (und möglicherweise unter
Verwendung von anderen Datenelementen außerhalb des Datenobjekts, die
genau zu diesem Zweck wiederaufgerufen wurden). Wenn das Programm
(Block 609) herausfindet, dass derartige Korrekturregeln
erfolgreich sind – damit
ist gemeint, dass eines oder mehrere Elemente des Datenobjekts verändert wurden,
damit das Datenobjekt alle Regeln einhält, an denen es vorher gescheitert
ist – dann sendet
das Programm (Block 616) die Veränderungen (Aktualisierung)
zu all den IDM, deren verbundene Datenbanken die zu korrigierenden
Datenelemente enthalten. Derartiges Senden weist jene IDM an, dieselben
Datenelementkorrekturen vorzunehmen, wie sie an dem Datenobjekt
vorgenommen wurden. Dort, wo derartige Korrekturregeln existieren
und erfolgreich angewendet werden können, wird das Ergebnis sein,
dass das Datenobjekt letztendlich als konsistent befunden wird.
Im Anschluss an das Senden der Aktualisierungen an die betroffenen
IDM liefert das Programm (Block 614) die angeforderten
Daten an die Anwendung.
-
Wenn die Anwendung von Korrekturregeln daran
scheitert, ein Datenobjekt konsistent zu machen, sendet das Programm
(Block 610) eine Anforderung an Datenabgleichungsprozess
(DRP) 175, um die Daten abzugleichen, die das Datenobjekt
bilden, und dann bewertet das Programm (Block 611) das
Ergebnis, um zu festzustellen, ob das Datenobjekt konsistent ist.
Wenn das so ist, liefert das Programm (614) die angeforderten
Daten an ihre verbundene Anwendung 110-1, um die gewünschte Operationsaufgabe
abzuschließen.
Wenn nicht, und wenn das Programm daraus schließt, dass die Inkonsistenz durch
die Anwendung von entsprechenden Korrekturregeln nicht korrigiert
werden kann, dann sieht das Programm in seiner Regelbasis nach,
um die Maßnahme
zu bestimmen, welche ergriffen wird, um mit den inkonsistenten Daten
zu verfahren. Die Regelbasis kann beispielsweise das Programm unterrichten,
(a) die anfordernde Anwendung zu unterrichten, die Operationsaufgabe
zu unterbrechen, wenn sie im Verlauf ist, und zu warten, bis die
Dateninkonsistenz durch den Datenabgleichungsprozessor (DRP) 175 (1) abgeglichen worden ist, (b)
die angeforderten aber inkonsistenten Daten zu der Anwendung zusammen
mit einer auf die Inkonsistenz hinweisenden Warnung zu liefern,
oder (c) das inkonsistente Datenobjekt an DRP 175 mit einer Anforderung
zu verweisen, eine Suche nach alternativen Daten auszulösen, wie
in 6 (Block 612)
dargestellt ist.
-
Insbesondere als Antwort auf den
Empfang eines inkonsistente Daten enthaltenden Datenobjekts von
einem IDM 115i verarbeitet DRP 175 das Datenobjekt entsprechend
einem Satz an Korrekturregeln, die in seiner verbundenen Regelbasis 180 enthalten
sind. Unter Verwendung derartiger Korrekturregeln versucht DRP 175,
die inkonsistenten Datenelemente abzugleichen, indem Informationen
verwendet werden, die schon in dem Datenobjekt sind, und möglicherweise
außerdem
andere Datenelemente außerhalb
des Datenobjekts (Referenzdatenelemente genannt), die aus anderen
Datenbanken 125i wiederaufgerufen werden können. Derartige
andere Daten können
dazu dienen, den Wert eines bestimmten Datenelements in dem Datenobjekt
zu belegen oder zu widerlegen. Die von DRP 175 verwendeten
Regeln basieren auf Wissen, das durch Experten erlangt wurde, die
besondere Erfahrung bezüglich
des Bewertens und des Auflösens
von Inkonsistenz in Datenelementen haben.
-
Ein Kabelpaarzustand aus dem Bereitstellungsbereich
des Datenobjekts (d. h. der Bereich des Datenobjekts, dessen Datenelemente
aus der Bereitstellungsdatenbank 125-2, 1 genommen werden) kann beispielsweise „verfügbar" sein, was bedeutet,
dass das Kabelpaar betriebsbereit und zur Zuteilung verfügbar ist,
d. h. derzeitig nicht in Gebrauch. Wenn jedoch gleichzeitig der
Kabelpaarzustand in dem Wartungsbereich des Datenobjekts (von Datenbank 125-3, 1, erhalten) „nicht
verfügbar" ist, und diese Inkonsistenz
durch die IDM-115i-Regelbasis nicht gelöst werden kann, dann kann die
Inkonsistenz durch dieses IDM an DRP 175 zur Abgleichung
weiterverwiesen werden. Unter Verwendung von den in Regelbasis 180 verschlüsselten Regeln
versucht DRP 175 zu bestimmen, welches Datenelement korrekt
ist, d. h. der in dem Bereitstellungsbereich des Datenobjekts gezeigte
Kabelzustand oder der in dem Wartungsbereich gezeigte Kabelpaarzustand.
-
Die Regeln in Regelbasis 180 können als
ein weiteres Beispiel DRP 175 anweisen, diese Feststellung
zu treffen, indem es das neueste Datum überprüft, an dem eine Störung über das
Kabelpaar gemeldet wurde. DRP 175 würde dann auf die Wartungsdatenbank 125-3 mittels
seiner verbundenen IDM 115 zugreifen, um das Datenelement zu erhalten,
das dieses Datum aufzeichnet. Wenn das Datum innerhalb eines bestimmten
Zeitraumes liegt, beispielsweise in den letzten sieben Tagen vor
dem aktuellen Datum, dann kann Regelbasis 180 DRP 175 anweisen,
(a) zu erklären,
dass das Kabelpaar tatsächlich
außer
Betrieb ist, (b) den Wert des Kabelpaarzustands in dem Bereitstellungsbereich
des Datenobjekts auf „nicht
verfügbar" zu korrigieren und
(c) eine Anforderung an IDM 115-2 senden, um den Kabelpaarzustand
in der Bereitstellungsdatenbank 125-2 auf „nicht
verfügbar" zu aktualisieren.
DRP 175 fährt
dann auf ähnliche
Weise mit dem Abgleichen jeglicher anderer inkonsistenter Daten
in dem Datenobjekt weiter fort.
-
Wenn das vorher genannte Datum der
neuesten gemeldeten Störung
nicht innerhalb des bestimmten Zeitraumes liegt, dann kann Regelbasis 180 beispielsweise
DRP 175 anweisen festzulegen, dass der korrekte Kabelpaarzustand „verfügbar" ist, und den Kabelpaarzustand
sowohl in dem Wartungsbereich des Datenobjekts als auch in der Wartungsdatenbank 125-3 auf „verfügbar" aktualisieren. Wenn DRP 175 auf
diese Weise die Abgleichungsfunktion abschließt, werden alle logisch verwandten
Datenelemente in dem Datenobjekt und in den entsprechenden Datenbanken,
aus welchen die Datenelemente des Datenobjekts bezogen wurden, entsprechend den
Regeln in Regelbasis 180 konsistent sein.
-
Wenn DRP 175 mit den verfügbaren Informationen
den korrekten Wert für
den Kabelpaarzustand nicht schlüssig
feststellen kann, kann Regelbasis 180 DRP 175 anweisen,
eine Mitteilung oder eine Benachrichtigung zu erzeugen, mit der
eine manuelle Datenbanküberprüfung und/oder
eine Feldverifizierung der betroffenen Kabelpaare angefordert wird.
Zu diesem Zeitpunkt kann DRP 175 eine Mitteilung an IDM
115i senden, in der angezeigt wird, dass er nicht in der Lage war,
die Inkonsistenz abzugleichen, woraufhin IDM 115i, entsprechend
Operationsregeln in seiner verbundenen Datenbank 120-i, das Datenobjekt
verwerfen und eine Suche nach alternativen Daten auslösen kann.
-
Es sei vorausgesetzt, dass das Datenobjekt ohne
derartige manuelle Verifizierung konsistent gemacht werden kann,
und dass IDM 115i die Operationsaufgabe ausgesetzt hätte und
auf eine Antwort von DRP 175 gemäß Fall (a) wartete, wie vorstehend erwähnt. Dann
wird DRP 175 das nun konsistente Datenobjekt an IDM 115i
mit einer Mitteilung zurücksenden,
die anzeigt, dass die Inkonsistenz abgeglichen worden ist. Entsprechend
seinen eigenen in seiner verbundenen Regelbasis 120i gespeicherten Operationsregeln,
kann IDM 115i (a) dann das Datenobjekt wieder überprüfen, um die Konsistenz entsprechend
den in dieser Regelbasis gespeicherten Überprüfungsregeln zu bestätigen, (b)
zu einer anderen Zwischenaufgabe übergehen oder (c) sofort die angeforderten
Daten zu der anfordernden Anwendung liefern.
-
Unter Berücksichtigung des Vorhergehenden
wird nun eine Ausführungsform
des Anwendens der Prinzipien der Erfindung unter Verwendung der Operationsaufgabe
des Bereitstellens einer Mietleitungsschaltung diskutiert. Es sei
vorausgesetzt, dass das in 1 dargestellte
System mit einem Telekommunikationssystem verbunden ist und drei
Anwendungen umfasst, die von Anlagenprozessor 100-1, Breitstellungsprozessor 100-2 und
Wartungsprozessor 100-3 unterstützt werden.
-
Außerdem sei vorausgesetzt, dass
die drei Anwendungen als Teil ihrer verbundenen Datenbanken Datenelemente
aufweisen, welche bestimmte in dem Telekommunikationssystem verfügbare Übertragungspfade
beschreiben, nämlich
Pfadkennzeichen, Anlagentyp, Endpunkte und aktueller Betriebszustand.
Die Datenelemente beschreiben außerdem (a) die schon in dem
Netzwerk verwendeten Schaltungen (Schaltungskennzeichen, Schaltungstyp, Komponentenpfadsegmente,
Schaltungsendpunkte und aktueller Betriebszustand), und (b) kürzlich aufgetretene
Wartungsstörungen
(Störungsdatensatzkennzeichen,
betroffenes Pfadkennzeichen, Datum letzter gemeldeter Störung und
Datum letzter behobener Störung).
Einige dieser Datenelemente sind lokal für nur eine Anwendung, und der
Rest wird von zweien oder allen dreien der Anwendungen gemeinsam
genutzt. Die Identitäten
der bestimmten Datenelemente und ihr Typ (lokale, erste gemeinsam
genutzte oder zweite gemeinsam genutzte) sind in den Datenelementtabellen
in jeder der Datenbanken aufgezeichnet, die jeweils mit den drei
Anwendungen verbunden sind, so wie die in 3 dargestellte Tabelle 300 für die Bereitstellungsdatenbank. Stamm-Datenelementtabelle
400, 4, enthält alle der
Datenelementtabelleninformationen und Querverweise, die benötigt werden,
um gemeinsam genutzte Datenelemente, die in verschiedenen Datenbanken
gespeichert sind, zu identifizieren. Das für die Schaltungsbereitstellung
definierte Datenobjekt mit all seinen Bestandsdatenelementen ist
in Datenverzeichnis 150, wie in 5 gezeigt, gespeichert.
-
Es sei vorausgesetzt, dass ein Telefonkunde zu
diesem Zeitpunkt einen Auftrag für
eine Mietleitungsschaltung von Denver nach Chicago bei einem Vertreter
des Telekommunikationssystems platziert, das die Kontrolle über die
Bereitstellungsanwendung 110-2 hat. Der Vertreter wiederum
kommuniziert auf bekannte Weise mittels Bereitstellungsprozessor 100-2 mit
Anwendung 110-2, um den optimalen Leitweg für die angeforderte
Schaltung sicherzustellen. Die Bereitstellungsanwendung bestimmt
auf bekannte Weise einen derartigen optimalen Leitweg und gibt (d.
h. zeigt auf einem Computerbildschirm) Informationen aus, die den
angeforderten Leitweg beschreiben. Ein derartiger Leitweg kann drei
Segmente umfassen, nämlich
Segment A von Denver nach Kansas City, Segment B von Kansas City
nach St. Louis und Segment C von St. Louis nach Chicago. Die Bereitstellungsanwendung
kann außerdem
andere mit dem Leitweg verbundene Aspekte ausgeben, z. B. Dienstleistungsmerkmale,
Preisgestaltung, usw. Wenn die Ausgabe für den Kunden akzeptabel ist, dann
führt der
Vertreter den Auftrag mittels der Bereitstellungsanwendung aus und
wartet auf deren Bestätigung,
dass geeignete Anlagen und Segmente verfügbar sind und für diesen
Kundenauftrag reserviert worden sind.
-
Während
der Vertreter auf derartige Bestätigung
wartet, löst
die Bereitstellungsanwendung 110-2 automatisch den Prozess
des Auffindens spezifischer verfügbarer
Pfadsegmente aus, um die optimale Route zu bilden. Um dieses zu
tun, liefert Anwendung 110-2 an ihre verbundene IDM 115-2 Informationen,
die die Eigenschaften der gewünschten Schaltung
und den Bedarf an optimalem Leitweg beschreiben. Sie fordert außerdem von
IDM 115-2 das Schaltungs_Kennzeichen (circuit_id) und Pfad_Kennzeichen
(path_id) an, die jedes Schaltungssegment, das die Route bilden
wird, identifiziert und eine Bestätigung des Betriebszustandes (ckt_status)
von jeder derartigen Schaltung.
-
IDM 115-2 wiederum sucht nach drei
Pfadsegmenten, die verwendet werden können, um die optimale Route
zu bilden, und einen Pfad_Zustand (path_status) „OK" aufweisen – was bedeutet, dass der Pfad
sowohl betriebsbereit als auch zur Zuteilung verfügbar ist.
Unter Verwendung der durch die Bereitstellungsanwendung 110-2 zur
Verfügung
gestellten Informationen und der in der Bereitstellungsdatenbank 125-2 gespeicherten
Datenelemente, identifiziert IDM 115-2 zuerst die Pfad_Kennzeichen
jener Pfade, welche gute Kandidaten für Segmente sind, weil sie die
spezifizierten Schaltungsanforderungen erfüllen und einen Pfad_Zustand „OK" aufweisen. IDM 115-2 kann
außerdem
angewiesen werden, andere verfügbare
Kandidaten mit Pfad_Zustand „NICHT
OK" (nicht betriebsbereit)
zur Bewertung zu identifizieren, wie nachstehend erläutert. Sind
die Pfadkandidaten einmal identifiziert, dann stellt IDM 115-2 sicher,
dass die Datenelemente, die jeden identifizierten Pfadkandidaten
beschreiben, mit jeglichen anderen logisch verwandten Datenelementen jeweils
sowohl in den Anlagen- als auch den Wartungsdatenbanken 125-1 und 125-3 konsistent
sind. IDM 115-2 nimmt dies vor durch (a) Bestimmen der Identität und Speicherstelle
derartiger verwandter Datenelemente, (b) Wiederaufrufen jener Datenelemente
und (c) ihr Zusammenführen
in dem Datenobjekt, das zuvor für
die Schaltungsbereitstellungsaufgabe definiert worden ist. Dann
untersucht IDM 115-2 das Datenobjekt entsprechend den Regeln
in Regelbasis 120-2,
um sicherzustellen, dass das Datenobjekt allen relevanten darin
gespeicherten Regeln entspricht (d. h. sie einhält) oder korrigiert werden
kann, um alle derartigen Regeln einzuhalten.
-
Insbesondere sieht IDM 115-2 zuerst
in Datenelementtabelle 300 nach, die in seiner verbundenen Datenbank 125-2 gespeichert
ist, um zu bestimmen, welche der erforderlichen Datenelemente als lokal
identifiziert und welche als gemeinsam genutzte identifiziert sind.
Wenn herausgefunden wird, dass einige der benötigten Daten gemeinsam genutzte Daten
sind, und demzufolge logisch verwandte Datenelemente in anderen
Datenbanken gespeichert sind, dann sendet IDM 115-2 eine
Mitteilung an Datenverzeichnis 150 und fordert eine Kopie
des Datensatzes für
das Schaltungsbereitstellungsdatenobjekt an, wie vorstehend erläutert. Datenverzeichnis 150 wiederum
sendet den angeforderten Datensatz, in welchem der Datensatz (a)
alle als ein Teil des Schaltungsbereitstellungsdatenobjekts definierten Datenelemente
und (b) jeweils die Datenbank, die jedes derartige Datenelement
enthält,
identifiziert. In 5 ist
die logische Struktur der Informationen gezeigt, die in Datenverzeichnis 150 für das angeforderte
Schaltungsbereitstellungsdatenobjekt enthalten sind. Unter Verwendung
derartiger Informationen stellt IDM 115-2 dann die entsprechenden
Datenobjekte für
die Pfadkandidaten, die das gewünschte Schaltungssegment
bilden könnten,
zusammen und überprüft sie der
Reihe nach. Insbesondere erfasst IDM 115-2 zuerst alle
relevanten Daten für
Pfadsegment A von Denver nach Kansas City. Dabei erhält IDM 115-2 von
seiner verbundenen Datenbank 125-2 alle der in dem Datenobjekt
identifizierten Bereitstellungsdatenelemente. IDM 115-2 erhält außerdem von
IDM 115-1 und IDM 115-3 die verwandten Datenelemente,
die jeweils in Anlagen- und Wartungsdatenbanken 125-1 und 125-3 gespeichert
sind. IDM 115-2 stellt die letzteren Datenelemente zu einem Schaltungsbereitstellungsdatenobjekt
zusammen, sobald sie von jenen Datenbanken empfangen werden. IDM 115-2 speichert
dann vorübergehend
das zusammengestellte Datenobjekt in einen internen Speicher, so
dass die Elemente, die das gespeicherte Datenobjekt bilden, entsprechend
den in Regelbasis 120-2 gespeicherten logischen Regeln
auf Konsistenz hin analysiert werden können. Ein erläuterndes
Beispiel für
derartige logische Regeln ist in 7 gezeigt.
Wenn IDM 115-2 dementsprechend das Zusammenstellen des
Datenobjekts abgeschlossen hat, dann wendet es die logischen Regeln
auf die Daten an, die das Objekt bilden, um zu bestimmen, ob Pfad
A die in dem Auftrag des Vertreters festgelegte Spezifikation für das erste
Segment der gewünschten
Schaltung erfüllt.
-
Insbesondere die in 7 gezeigten Regeln spezifizieren verschiedene
Aktionen, die, beruhend auf dem Wert der drei Datenelemente des Pfad_Zustands,
ausgeführt
werden können,
die jeweils von den Anlagen-, Bereitstellungs- und Wartungsdatenbanken
erhalten wurden. Für
das vorliegende Beispiel sei vorausgesetzt, dass die Werte für einen
Pfad_Zustand sein könnten,
(a) „OK", was bedeutet, dass
der Pfad betriebsbereit und zur Verwendung in einer Schaltung verfügbar ist,
(b) „NICHT OK", was bedeutet, dass
der Pfad aufgrund einer aktuellen Störungsbedingung nicht verfügbar ist
oder (c) „EIN", was bedeutet, dass
der Pfad in Betrieb ist und einer anderen Schaltung zugeteilt worden
ist.
-
Außerdem sei vorausgesetzt, dass
alle die Pfade, die einen Zustand „EIN" aufweisen, in einem früheren Kandidatenauswahlprozess „aussortiert" worden waren, so
dass sie in der folgenden Diskussion nicht mehr berücksichtigt
werden müssen.
-
Es sei vorausgesetzt, dass zu diesem
Zeitpunkt der von jeder der Datenbanken 125-1 bis 125-3 für Pfad A
empfangene Pfad_Zustand „OK" ist – was bedeutet,
dass Pfad A die für
das gewünschte
Segment spezifizierten technischen Erfordernisse erfüllt, betriebsbereit
und zur Zuteilung verfügbar
ist und dass alle Pfad A definierenden Datenelemente über die
Datenbanken 125-1 bis 125-3 konsistent sind. Sobald
die Konsistenz des Datenobjekts für Pfad A entsprechend den Regeln
in Regelbasis 120-2 überprüft worden
ist, dann reserviert IDM 115-2, wieder entsprechend jenen
Regeln, Pfad A als das erste Segment der gewünschten Schaltung. IDM 115-2 nimmt
dies durch Erstellen eines Datensatzes für Schaltungssegment 1 mit dem
Wert des Pfad_Kennzeichens für
Pfad A vor, und durch Aktualisieren des Pfad_Zustands für Pfad A
in Datenbanken 125-1 bis 125-3 von „OK" auf „EIN", weil er dieser Schaltung
zugeteilt wurde.
-
Sobald IDM 115-2 alle mit
dem Reservieren von Pfad A als dem ersten Segment der gewünschten
Kundenschaltung verbundenen Aufgaben abgeschlossen hat, dann kann
IDM 115-2 mit dem Bestimmungsprozess beginnen, ob Pfad
B ein guter Kandidat für
das zweite Segment der gewünschten
Schaltung ist. Es sei vorausgesetzt, dass dann der von Datenbanken 125-1 bis 125-3 für Pfad B
empfangene Pfad_Zustand jeweils „OK", „NICHT
OK" und „OK" ist. In diesem Fall
weisen die Regeln dann (wie in 7 gezeigt)
IDM 115-2 an, den Wert von dem Datenelement Störung_Datum_Behoben
(tbl_date_clr) aus Datenbank 125-3 zu überprüfen. Es sei vorausgesetzt,
dass das Element Störung_Datum_Behoben
anzeigt, dass die letzte Störung
auf Pfad B drei Tage vor dem Datum der aktuellen Dienstanforderung
behoben worden ist.
-
Entsprechend der Absicht dieses Beispiels ist
es dem Fachmann bekannt, dass es, wenn der Pfad_Zustand für eine Schaltung
in den Bereitstellungs- und Anlagendatenbanken nicht miteinander übereinstimmt,
und die Wartungsdatenbank anzeigt, dass die Störung in dem Pfad innerhalb
der letzten sieben Tage behoben worden ist, dann sicher sein würde anzunehmen,
dass der Pfad OK ist und dass die Datenbank, welche „NICHT
OK" anzeigt, nicht stimmt.
In diesem Fall weist die Regel dann IDM 115-2 an, das Anlagen-IDM 115-1 zu
unterrichten, Datenbank 125-1 entsprechend zu aktualisieren,
d. h. das Datenelement Pfad_Zustand für Pfad B auf „OK" zu korrigieren und
dann Pfad B als das zweite Segment für die gewünschte Schaltung zu reservieren.
Sobald diese Aktivitäten
abgeschlossen sind, dann kann IDM 115-2 Pfad C als einen
Kandidaten für
das letzte Segment verarbeiten.
-
Auf ähnliche Weise verarbeitet IDM 115-2 die Daten
für Pfad
C, um zu bestimmen, ob er für
Verwendung geeignet ist. Es sei vorausgesetzt, dass zu diesem Zeitpunkt
der empfangene Pfad_Zustand von (a) Bereitstellungsdatenbank 125-2 „NICHT
OK" ist, (b) Anlagendatenbank 125-1 „OK" ist und (c) Wartungsdatenbank 125-3 „OK" ist. Außerdem sei
vorausgesetzt, dass das von Wartungsdatenbank 125-3 empfangene
Element Störung_Datum_Behoben
anzeigt, dass die letzte aufgezeichnete Störung vor mehr als sieben Tagen
behoben worden ist. Auf der Grundlage dieser Informationen für diesen
bestimmten Pfad_Zustand würde
ein Fachmann schließen, dass
eine weitere Untersuchung vorgenommen werden muss, um den Grund
der Inkonsistenz zu bestimmen. Die in 7 gezeigten
Regeln weisen deswegen IDM 115-2 an, Pfad C zurückzuweisen
und dann einen alternativen Pfad zu ermitteln, der als das letzte Segment
in Schaltungspfad C verwendet werden kann. Derartige Regeln weisen
außerdem
an, dass die Inkonsistenz in den Daten von Pfad C an DRP 175 zur
ausführlichen
Verarbeitung verwiesen werden soll. Es sei vorausgesetzt, dass dementsprechend
zu diesem Zeitpunkt eine weitere Suche ergibt, dass alternativer
Pfad C1 zwischen St. Louis und Chicago verfügbar ist, und dass Pfad C1
die in Regelbasis 120-2 gespeicherten Regeln erfüllt, so dass
IDM 115-2 angewiesen würde,
Pfad C1 als das letzte Segment in der gewünschten Schaltung zu reservieren.
-
Sobald die Pfade A, B und C1 identifiziert und
für die
gewünschte
Schaltung reserviert worden sind, (a) verbindet IDM 115-2 die
Schaltung mit einem einzigartigen Schaltungs_Kennzeichen für diese
Schaltung; (b) zeichnet das Pfad_Kennzeichen für die drei ausgewählten Segmente
jeweils als Schaltung_Segment_1 (ckt_seg_1), Schaltung_Segment_2
(ckt_seg_2) und Schaltung_Segment_3 (ckt_seg_3) auf; (c) zeichnet auf,
dass der Schaltungs_Zustand „OK" ist, und (d) sendet
zu diesem Zweck Informationen zu der Bereitstellungsanwendung zurück. Die
Bereitstellungsanwendung wiederum zeigt die Informationen auf dem Display
eines Computers an, der durch den vorgenannten Vertreter bedient
wird. Der Vertreter kann dann den Kunden informieren, dass die gewünschte Schaltung
von Denver nach Chicago bestätigt
worden ist.
-
8 stellt
ein Beispiel logischer Regeln dar, die DRP 175 anwenden
könnte,
um die vorher genannten Daten für
Pfad C abzugleichen. Um das vorstehend genannte Beispiel für Pfad C
zu wiederholen, zeigten Datenbanken 125-2, 125-1 und 125-3 jeweils
einen Pfad_Zustand „NICHT
OK", „OK" und „OK" mit einem Störung_Datum_Behoben
an, das älter
als sieben Tage ist. In diesem Fall spezifizieren die DRP 175 Regeln,
die Konsistenz des Pfad_Typs (path_type) in den Wartungs- und Anlagendatenbanken
als den nächsten
Verarbeitungsschritt zu überprüfen. Dies
wird vorgenommen, weil es möglich
ist, dass eine Störungsmeldung
in der Wartungsdatenbank für
ein falsches Pfad_Kennzeichen aufgezeichnet worden sein kann und
die zuverlässigste
Quelle von Pfad_Typ in der Anlagendatenbank enthalten ist, wo die
erste gemeinsam genutzte Kopie für
den Pfad gespeichert ist. Wenn die Pfad_Typen übereinstimmen, dann werden
die Daten für
die Endpunkte von Pfad C auf ähnliche
Weise überprüft. Wenn
herausgefunden wird, dass entweder der Pfad_Typ oder Endpunkte inkonsistent
sind, dann spezifizieren die DRP 175 Regeln, dass die Daten
manuell überprüft werden
müssen,
was zu einer Feldverifizierung führen
kann. Wenn andererseits DRP 175 herausfindet, dass die
Daten für
den Pfad_Typ und Endpunkte übereinstimmen,
dann spezifizieren die DRP-175-Regeln, dass der in der Bereitstellungsdatenbank
aufgezeichnete Pfad_Zustand nicht stimmt und weisen eine Aktualisierung
des Datenelements Pfad_Zustand in dieser Datenbank an. Weil Pfad
C zu diesem Zeitpunkt für
die beispielhafte Schaltung nicht weiter benötigt wird, kann er zur Verwendung
in einer anderen Schaltung verfügbar
gemacht werden.