DE69620303T2

DE69620303T2 - Verfahren und Gerät zum Teilen von Verwaltungsinformationen über einen gemeinsamen Speicher

Info

Publication number: DE69620303T2
Application number: DE1996620303
Authority: DE
Inventors: Thomas G. Bartz; Robert A. Potterveld
Original assignee: Hewlett Packard Co
Current assignee: Hewlett Packard Development Co LP
Priority date: 1996-06-11
Filing date: 1996-06-11
Publication date: 2002-08-08
Anticipated expiration: 2016-06-12
Also published as: DE69620303D1

Description

Hintergrund der Erfindung

1. Gebiet der Erfindung

Die vorliegende Erfindung bezieht sich auf das Gebiet von Unternehmensverwaltungssystemen und insbesondere auf ein rechnergestütztes, objektorientiertes gemeinsames Depot für die Speicherung von Informationen, die von Unternehmensverwaltungsservern im Auftrag von Anwendungsprogrammkunden verwaltet werden.

2. Beschreibung des Stands der Technik

Verwaltungssysteme, die in einem Unternehmen angewendet werden, verwenden häufig Berechnungssysteme, um Aspekte der Unternehmensverwaltung zu automatisieren. Die Unternehmensverwaltung, wie sie hierin verwendet wird, bezieht sich auf die Verwaltung aller Objekte, die von dem Unternehmen verwendet werden, und auf die verschiedenen Attribute von und Assoziationen zwischen Objekten. Eine Unternehmensverwaltung umfaßt sehr viele unterschiedliche Aspekte von Objekten in einem Unternehmen. Unternehmensverwaltungsanwendungsprogramme in der Vergangenheit haben einen spezifischen Aspekt der Gesamtunternehmensverwaltungsaufgabe verwaltet. Einige Anwendungen sind z. B. mit topologischen Informationen bezüglich Objekten in dem Unternehmen (auch als Beziehungsinformationen bezeichnet) beschäftigt. Ein weiteres typisches Anwendungsprogramm beschäftigt sich mit Attributinformationen bezüglich Objekten in dem Unternehmen. Ein Bestandsteuerungsprogramm ist ein Beispiel für ein Anwendungsprogramm, das mit Attributen (Bestandszählung) von verwalteten Objekten beschäftigt ist. Weitere Anwendungsprogramme beschäftigen sich mit Trendinformationen bezüglich Objekten in dem Unternehmen. Weitere Anwendungsprogramme verwalten Ereignisse und historische Attributinformationen bezüglich Objekten in dem Unternehmen.
Es ist wünschenswert, daß die Informationen, die von einem Verwaltungsanwendungsprogramm verwaltet werden, folgende Eigenschaften aufweisen:
Verfügbarkeit offen für andere Anwendungen und Endbenutzer
Konsistenz die Struktur von verwalteten Informationen ist bekannt und leicht zu manipulieren
Genauigkeit weist eine Integrität auf, ist akkurat und aussagefähig.
Bei früheren Entwürfen ist es üblich, die zwei letztgenannten oberen Ziele, nämlich Konsistenz und Genauigkeit, zu erzielen, indem teilweise bei der Verfügbarkeit der Informationen Abstriche vorgenommen werden. Ein Einschränken der Benutzung der gespeicherten Informationen durch andere Anwendungsprogramme oder durch Endbenutzer hilft, die Genauigkeit und Konsistenz der Informationen sicherzustellen, die von einem bestimmten Anwendungsprogramm verwaltet werden. Es ist bei früheren Entwürfen üblich, daß jedes Anwendungsprogramm seine eigenen Datenstrukturen zum Darstellen, Speichern und Wiedergewinnen der Informationen erzeugt und verwaltet, die von dem Anwendungsprogramm manipuliert werden (üblicherweise mit der Hilfe von Datenbankverwaltungsteilsystemen). Jedes spezifische Anwendungsprogramm ist deshalb unabhängig von allen anderen Anwendungsprogrammen.
Ein erstes Problem bei dem Entwurf von unabhängigen Anwendungsprogrammen für jede Verwaltungsaufgabe entsteht mit der verschwendeten, oft überflüssigen Bemühung, jedes Verwaltungsanwendungsprogramm zu erzeugen. Bei den älteren Entwürfen wäre es erforderlich, daß unabhängige Entwicklungsgruppen, die möglicherweise unabhängige Verkäufer repräsentieren, zustimmen, ihre jeweiligen Anwendungsprogramme zu einem bestimmten frühen Punkt in der Entwurfsphase zu integrieren. Selbst wenn eine derartige Kooperation bei konkurrierenden Verkäuferbeziehungen häufig ist, können die Zeitpläne, die den Entwicklungsbemühungen von unterschiedlichen Verkäufern zugeordnet sind, sich u. U. z. B. nicht ausreichend überlagern, um eine effektive Kooperation zwischen den jeweiligen Entwicklungsgruppen zu ermöglichen.
Ähnliche Anwendungsintegrationsprobleme können selbst dann entstehen, wenn unabhängige Anwendungsprogramme von einer einzelnen Gruppe entwickelt werden. Häufig werden die verschiedenen Verwaltungsanwendungsprogramme über eine Zeitdauer entwickelt. Jedes Anwendungsprogramm neigt dazu, seine eigenen, einzigartigen Strukturen und Verfahren zum Darstellen der verwalteten Objekte zu entwickeln. Diese überflüssige Entwicklungsbemühung kann die Komplexität und die damit verbundenen Kosten zur Entwicklung derartiger Verwaltungsanwendungsprogramme erhöhen.
Deshalb entsteht ein zweites Problem bei dem Entwurf von ungleichen Verwaltungsanwendungsprogrammen, nämlich die Schwierigkeit des Integrierens der Informationen, die durch potentiell mehrere, unabhängige Anwendungsprogramme verwaltet werden. Angesichts von unabhängigen Entwicklungsbemühungen, wie z. B. den oben beschriebenen, neigt die Vielzahl von unabhängig entwickelten Strukturen und Verfahren zum Darstellen von verwalteten Objekten dazu, in Richtung inkompatibler Entwürfe zu führen, die schwierig zu integrieren sein könnten. Das isolierte Verwaltungsanwendungsprogramm, das z. B. oben beschrieben wird und bei älteren Entwürfen üblich ist, ist für eine Verwaltungseinrichtung oder eine Verwaltungsaufgabe ausreichend, die von anderen Verwaltungsangelegenheiten isoliert ist. Wenn jedoch ein Operator oder eine Verwaltungseinrichtung die Integration von Informationen aus mehreren unterschiedlichen Aspekten des Unternehmens erfordert, sind isolierte, ungleiche Anwendungsprogramme, die typisch für ältere Entwürfe sind, nicht in der Lage, eine integrierte Ansicht der Objekte zu liefern, die in ihren jeweiligen Datenbanken gespeichert sind. Die Integration von Informationen wird oft zu einem manuellen Verfahren, das den Verwaltungseinrichtungen überlassen bleibt, die die Anwendungen verwenden. Die ungleichen Anwendungsprogramme können die Informationen, die von anderen Anwendungsprogrammen verwaltet werden, nicht ohne weiteres integrieren.
Ein drittes Problem bei der Benutzung von ungleichen Systemen für unterschiedliche Verwaltungsaufgaben, die gemeinsame Elemente von Informationen verwenden, entsteht bei der unvermeidbaren Duplizierung von gespeicherten Informationen und dem resultierenden Verlust der Datenintegrität. Da jede der ungleichen Verwaltungsaufgaben üblicherweise dem eigenen, einzigartigen Format sowie Struktur zum Speichern von Informationen zugeordnet ist, kommt es häufig vor, daß ähnliche Informationen in dem Informationsspeicher von mehreren Verwaltungsanwendungen dupliziert werden. Eine Verwaltungsanwendung kann z. B. Informationen bezüglich eines Angestellten bezüglich Lohnaspekten benötigen, während eine andere Anwendung Informationen bezüglich des gleichen Angestellten speichert, die nützlich sind, um Geschäftsreisen zu planen. Beide Verwaltungsanwendungen können einen Zugriff auf gemeinsame Informationen benötigen, wie z. B. einen Büro-Post-Stopp und eine Telephonerweiterung usw. Beide ungleiche Verwaltungsanwendungen können deshalb u. U. diese gemeinsamen Informationen zur Verwendung bei unterschiedlichen Operationen (z. B. Lohnzahlungen oder Reiseplanungen) speichern.
Diese Duplizierung von gespeicherten Informationen erhöht die Anforderungen einer zusammengesetzten Speicherkapazität des Unternehmens. Noch wichtiger ist, daß, wenn derartige gemeinsame Informationen modifiziert werden (der Angestellte zieht z. B. zu einem neuen Büro-Post-Stopp um), die Informationen in einer Anwendung aktualisiert werden können, jedoch in keiner anderen. Derartige potentielle Inkonsistenzen bei Informationen, die von Unternehmensverwaltungsanwendungen verwaltet werden, erzeugen Probleme für Informationsverwaltungseinrichtungen. Jede ungleiche Verwaltungsanwendung muß die Verantwortung zum Aktualisieren ihrer eigenen gespeicherten Version aller gemeinsamen Elemente von Informationen übernehmen. Wie bereits oben erläutert wurde, versucht jedes unabhängige Anwendungsprogramm, die Genauigkeit und Integrität von verwalteten Informationen sicherzustellen, indem die Zugänglichkeit der verwalteten Informationen für andere Anwendungen beschränkt wird. Die ungleichen Anwendungsprogramme versuchen, die Datenintegrität ihrer Privatkopien von gemeinsamen Daten aufrechtzuerhalten, indem jede Möglichkeit zum Zugriff durch andere Anwendungsprogramme beschränkt wird. Die oben beschriebenen Inkonsistenzen zwischen Duplikatkopien von verwandten Daten jedoch reduzieren, allgemeiner als eine unternehmensweite Sammlung von verwalteten Informationen betrachtet, die Gesamtintegrität der Speicherung von Informationen des Unternehmens.
Ein Unternehmen könnte versuchen, anfänglich alle möglichen Unternehmensinformationsverwaltungsteilsysteme früh in ihren Entwurfsphasen zu integrieren, um derartige Probleme einer Informationsduplizierung zu vermeiden. Ein derartiges Planen könnte eine insgesamt integrierte, unternehmensweite Informationsspeicherbasis erzeugen, die eine unnötige Duplizierung von gespeicherten Daten vermeiden kann. Unabhängig des Grads von Planen, das bei dem anfänglichen Entwurf einer integrierten Verwaltungsinformationsspeicherbasis angewendet wird, wird ein Bedarf nach neuen Verwaltungsinformationsanwendungen entstehen. Derartige neue Anwendungen erfordern einen wesentlichen Neuentwurf der anfänglich integrierten Informationsbasis. Dies erfordert wesentliche Bemühungen, die Informationsspeicherbasis neu zu entwerfen. Die Neuentwurfsbemühungen erfordern häufig die Betriebsmittel einer zentralen Verwaltungsinformationstechnologiegruppe, die die erforderlichen Veränderungen koordiniert, um die erwünschte Informationsintegration beizubehalten. Ein derartiger zentraler, integrationssteuerungsbasierender und menschlicher Neuentwurfseingriff ist jedoch mit dem Erzielen einer Dezentralisierung von Datenverarbeitungsbetriebsmitteln in einem Unternehmen unvereinbar.
Die EP-A-0304071 bezieht sich auf ein objektbasierendes Datenverarbeitungssystem, das einen erweiterbaren Satz von Objekttypen und einen entsprechenden Satz von Objektverwaltungseinrichtungen umfaßt. Ferner können Objekte jeweils einer oder mehreren Dateien eines herkömmlichen Computerdateisystems entsprechen. Die Objektverwaltungseinrichtungen sind angepaßt, um zumindest eine Operation bezüglich zumindest eines Objekttyps durchzuführen, indem anfänglich eine Aufrufanforderung durchgeführt wird. Ansprechend auf eine derartige Aufrufanforderung identifizieren Objektverwaltungsdienste eine Objektverwaltungseinrichtung und rufen dieselbe auf, die geeignet zum Durchführen der angeforderten Operation bezüglich des spezifizierten Datentyps sind. Gemäß diesem Dokument identifizieren die Objektverwaltungsdienste eine Objektverwaltungseinrichtung und rufen dieselbe auf, die in der Lage ist, eine identifizierte Operation bezüglich Objekten des Typs eines Objekts durchzuführen, das durch eine Anforderung von einer der Objektverwaltungseinrichtungen identifiziert wurde.
Es ist die Aufgabe der vorliegenden Erfindung, ein Datenverwaltungssystem und ein Datenverwaltungsverfahren zu liefern, die eine verbesserte Informationsspeicherung und - wiedergewinnung für Unternehmensverwaltungsanwendungsprogramme liefern.
Diese Aufgabe wird durch ein Datenverwaltungssystem gemäß Anspruch 1 und ein Datenverwaltungsverfahren gemäß Anspruch 6 gelöst.
Die vorliegende Erfindung löst die oben genannten Probleme, um dadurch den Stand der Technik zu verbessern, indem ein gemeinsames Depot von Informationen geschaffen wird, das von Verwaltungsinformationssystemanwendungsprogrammen gemeinschaftlich verwendet wird. Die Verfahren und Datenstrukturen der vorliegenden Erfindung bilden eine Anwendungsprogrammschnittstelle (im folgenden als API bezeichnet), die von Anwendungsprogrammentwicklern verwendet wird, um eine gemeinsame Struktur für gespeicherte Informationen zu liefern, und um eine Duplizierung von Informationen zu reduzieren, die von mehreren Anwendungsprogrammen verwendet werden.
Die Verfahren und Datenstrukturen der vorliegenden Erfindung speichern Informationen derart, daß eine Wiederverwendung und gemeinschaftliche Verwendung von Informationen unter mehreren Anwendungsprogrammen ermöglicht wird. Ein Abschnitt der Datenstrukturen, die durch die Verfahren der vorliegenden Erfindung manipuliert werden, speichert einen Objektidentifizierer, der ein Objekt eindeutig identifiziert, das den Verfahren der vorliegenden Erfindung geliefert wird. Die Objekte, die derart identifiziert sind, werden anfänglich der vorliegenden Erfindung durch Anwendungsprogramme unter Verwendung des gemeinschaftlich verwendeten, gemeinsamen Depots geliefert. Weitere Informationen, die mit dem Objektidentifizierer gespeichert werden, dienen dazu, gemeinsame Informationen in einer vordefinierten Struktur zu liefern, die anderen Anwendungsprogrammen bekannt ist und von denselben verwendet werden kann.
Ein Server-Programm ist jeder Benutzung der Informationen, die in dem gemeinsamen Depot gespeichert sind, zugeordnet. Die Server-Programme liefern einen API-Standard für Anwendungsprogramme, um die gemeinschaftlich verwendeten Daten in dem gemeinsamen Depot zu verwenden. Der Topologieverwaltungsdienst z. B. (auch als Beziehungsverwaltungsdienst bezeichnet), der in der EP-A-0750254 offenbart ist, liefert Verwaltungsinformationen, die sich auf topologische Verbindungen (im folgenden auch "Assoziationen" bezeichnet) unter gespeicherten Objekten beziehen. Andere Standard-Server sind definiert, um Objektattributinformationen (wie z. B. Bestandsdaten), trend- und ereignisbezogene Informationen, sowie historische Attributinformationen zu liefern. Die Verwendung einer Serverprogramm-API für jeden verwalteten Aspekt von Objekten, die in dem gemeinsamen Depot gespeichert sind, verbessert eine Datenintegrität, indem Vorschriften, die in den Server eingebettet sind, durchgesetzt werden, die legale Operationen bezüglich der Objekte, die durch den Server verwaltet werden, definieren.
Verfahren und eine Struktur in dem Bereich der vorliegenden Erfindung liefern auch Werkzeuge bzw. Hilfsprogramme, um bei der Entwicklung von neuen Server-Programmen zu helfen. Ein Metaschema wird verwendet, um Vorschriften zum Erzeugen von neuen Datenbanken, die in dem gemeinsamen Depot gespeichert sind, zu definieren. Andere Verfahren verwenden das Metaschema gemeinsam mit Entwickleranweisungen, um einen Serverprogrammquellencode zu erzeugen. Das Programmerzeugungsmerkmal der vorliegenden Erfindung erzeugt einen funktionellen Server, der mit anderen definierten Servern durch die Vorschriften des Metaschemas integriert ist, um ein vereinfachtes gemeinschaftliches Verwenden von Informationen zu ermöglichen. Anwendungsprogramme können dann durch den Entwickler entworfen sein, um die API-Schnittstelle für jeden Server zu verwenden, um Informationen, die in dem gemeinsamen Depot gespeichert sind, zu manipulieren. Die Sammlung von Serverprogrammen, die durch die gemeinsame Definition des Metaschemas, das beim Erzeugen der Server verwendet wird, integriert sind, ermöglicht es, daß Anwendungsprogramme Informationen, die von mehreren Serverprogrammen verwaltet werden, ohne weiteres integrieren.
Die Speicherung aller Informationen in dem gemeinsamen Depot, das durch die integrierten Serverprogramme verwaltet wird, ermöglicht auch eine Reduzierung von duplizierten Informationen, die in dem gemeinsamen Depot gespeichert sind. Da sich alle Informationen für die Unternehmensverwaltung in einem einzelnen Depot befinden, können Verfahren der vorliegenden Erfindung Vorschriften durchsetzen, die die unbeabsichtigte Duplizierung von Informationen reduzieren.
Die vorliegende Erfindung verwaltet das gemeinsame Depot unter Verwendung einer Standard-API unabhängig von der spezifischen Datenbankverwaltungsmaschine (im folgenden auch Datenbankverwaltungseinrichtung genannt), die die physische Speicherung der Informationen auf Speichermedien verwaltet. Die Struktur und Verfahren der vorliegenden Erfindung sind auf offenen Standarddatenbank-API (im folgenden auch als Datenbankverwaltungsschnittstelleneinrichtung bezeichnet) aufgebaut, wie z. B. ODBX von Microsoft oder DATA MANAGEMENT: SQL CALL LEVEL INTERFACE von X/Open (X/Open Preliminary Specification P303 ISBN 1-85912-015-6, war bisher Veröffentlichung S203 und wird Veröffentlichung C451 werden, erhältlich bei X/Open Company Ltd., Berks, Großbritannien ist). Diese Standards ermöglichen es den Serverprogrammen der vorliegenden Erfindung, jede zugrundeliegende Datenbankmaschine zu verwenden, die mit diesen Standards für die permanente physische Speicherung der verwalteten Daten vereinbar ist. Endbenutzerinstallationen unter Verwendung der vorliegenden Erfindung können deshalb jedes zur Zeit installierte Datenbankverwaltungsteilsystem verwenden.
Zahlreiche weitere Merkmale, Aufgaben und Vorteile der vorliegenden Erfindung werden aus der nachfolgenden Beschreibung gemeinsam mit den beigefügten Zeichnungen deutlich.

Kurze Beschreibung der Zeichnungen

Fig. 1 zeigt ein Allzweckdatenverarbeitungssystem, das die Strukturen und Verfahren der vorliegenden Erfindung enthalten kann;
Fig. 2 zeigt eine Übersicht der Struktur von Anwendungsprogrammen, die üblich für frühere Entwürfe sind, wobei jedes Programm seine eigene Informationsstruktur als eine private Datenbank verwaltet;
Fig. 3 zeigt eine Übersicht der Struktur von Anwendungsprogrammen, die strukturiert sind, um Informationen, die von Serverprogrammen verwaltet werden und in einem gemeinsamen Depot gespeichert sind, gemäß der Struktur und Verfahren der vorliegenden Erfindung gemeinschaftlich zu verwenden;
Fig. 4 stellt die Klassenvererbungsstruktur von exemplarischen Gemeinsame-Klasse-Definitionen dar, die physische Attribute eines Objekts wiedergeben, das in dem gemeinsamen Depot aus Fig. 3 verwaltet wird;
Fig. 5 stellt die Klassenvererbungsstruktur von exemplarischen Gemeinsame-Klasse-Definitionen dar, die logische Attribute eines Objekts wiedergeben, das in dem gemeinsamen Depot aus Fig. 3 verwaltet wird;
Fig. 6 zeigt die Struktur von Tabellen zum Speichern von Beziehungen zwischen verwalteten Objekten gemäß dem Metaschema des gemeinsamen Depots aus Fig. 3;
Fig. 7 zeigt die Struktur von Tabellen zum Speichern von Klassendefinitionen von verwalteten Objekten gemäß dem Metaschema des gemeinsamen Depots aus Fig. 3;
Fig. 8 zeigt die Struktur von Tabellen zum Speichern von objektinstanzspezifischen Attributinformationen für verwaltete Objekte gemäß dem Metaschema des gemeinsamen Depots aus Fig. 3;
Fig. 9 zeigt die Struktur von Tabellen zum Speichern von Objekttrendanalyseinformationen für verwaltete Objekte gemäß dem Metaschema des gemeinsamen Depots aus Fig. 3; und
Fig. 10 zeigt den allgemeinen Fluß von Informationen bei der Operation des Serverprogrammerzeugungshilfsprogramms der vorliegenden Erfindung zum Erzeugen neuer Serverprogramme, um Objekte, die in dem gemeinsamen Depot aus Fig. 3 gespeichert sind, zu manipulieren.

Detaillierte Beschreibung des bevorzugten Ausführungsbeispiels

Die vorliegende Erfindung weist eine Anwendungsprogrammschnittstelle (API) für Serverprogramme auf, die Objekte in einem gemeinsamen Depot im Auftrag von Kundenanwendungsprogrammen verwalten. Zusätzlich weist die vorliegende Erfindung ein Metaschema auf, das Standarddatenstrukturen und zugeordnete Hilfsprogramme zum Automatisieren der Struktur von Serverprogrammen definiert, um neue Aspekte von Objekten in dem gemeinsamen Depot zu verwalten.
Fig. 2 liefert eine Übersicht von üblichen Verfahren, die bei früheren Entwürfen für die Unternehmensverwaltung angewendet wurden. Jede eigene Unternehmensverwaltungsaufgabe ist mit einem kundenspezifischen Anwendungsprogramm entworfen. Jedes Anwendungsprogramm wies üblicherweise seine eigene Datenbank auf, die Informationen und eine zugeordnete Struktur lieferte, wie dies geeignet für die spezifische Anwendung war. Wie in Fig. 2 gezeigt ist, sind vier ungleiche Anwendungsprogramme 200, 202, 204 und 206 entworfen, um verschiedene Aspekte eines Unternehmens zu verwalten. Es ist dargestellt, daß jede Anwendung mit ihrer eigenen Datenbankstruktur 208 bis 218 in Wechselwirkung steht. SNMP TRAPS 200 ist ein Anwendungsprogramm, das z. B. ereignisbezogene Informationen verwaltet, indem es SNMP- Informationen, die von Systemen in einem Netz in der TRAPD. LOG-Datenbankstruktur 208 empfangen werden, protokolliert. ANWENDUNG B 206 ist ein Anwendungsprogramm, das z. B. die Assoziationen zwischen Objekten verwaltet. Wie dies bei früheren Entwürfen häufig vorkommt, werden die Informationen, die die Objekte darstellen, in einer Datenbank 216 gespeichert, während die topologischen Assoziationen separat in der Datenbankstruktur 218 gespeichert sind. Wie in Fig. 2 gezeigt ist, ist beim früheren Entwurf aufgrund der Unabhängigkeit der Datenbankspeicherung, die jedem Anwendungsprogramm zugeordnet ist, nur ein eingeschränktes gemeinschaftliches Verwenden von Informationen möglich. Anwendungsprogramme 202 und 204 sind so dargestellt, daß sie die NETZ DB-Datenbank 212 gemeinschaftlich verwenden. Ein derartiges gemeinschaftliches Verwenden kann auftreten, wenn mehrere Anwendungsprogramme von einem einzelnen Verkäufer oder von mehreren Verkäufern entworfen werden, die wie oben erwähnt sehr eng miteinander kooperieren.
Fig. 3 zeigt Anwendungsprogramme 300 bis 306, die denen aus Fig. 2 ähneln, die durch Serverprogramme 308 bis 314 der vorliegenden Erfindung mit dem gemeinsamen Depot 316 der vorliegenden Erfindung schnittstellenmäßig verbunden sind. Bei dieser Struktur werden alle Informationen, die Assoziationen zwischen Objekten darstellen, in dem gemeinsamen Depot 316 gemäß Standards, die durch das Metaschema definiert sind, gespeichert. Die Manipulation des gemeinsamen Depots 316 wird durch Standardserverprogramme 308 bis 314 durchgeführt. Wie oben erläutert ist, sind Serverprogramme 308 bis 314 jeweils gemäß Standards aufgebaut, die das Metaschema umfassen, das alle unterstützten Assoziationen zwischen Objekten in dem gemeinsamen Depot 316 definiert.
Fig. 1 zeigt ein Blockdiagramm der Computer-Hardware, die das Unternehmensverwaltungsdienstesystem der vorliegenden Erfindung enthält. In Fig. 1 enthält ein Computersystem 100 ein Verarbeitungselement 102, das mit anderen Elementen in dem Computersystem 100 über einen Systembus 104 in Verbindung steht. Eine Tastatur 106 wird verwendet, um Informationen von einem Benutzer des Systems einzugeben, wobei eine Anzeige 108 verwendet wird, um Informationen an den Benutzer auszugeben. Eine Netzschnittstelle 112 wird verwendet, um das Computersystem 100 schnittstellenmäßig mit einem Netz 118 zu verbinden, um es dem Computersystem 100 zu ermöglichen, als ein Knoten bei einem Netz zu wirken, und um so mit anderen Knoten in dem Netz zu kommunizieren. Eine Platte 114 wird verwendet, um die Software des Unternehmensverwaltungssystems der vorliegenden Erfindung zu speichern, und um die Informationen, die das gemeinsame Depot 316 aufweist, zu speichern. Ein Drucker 116 kann verwendet werden, um eine Druckkopieausgabe der Informationen zu liefern, die von der vorliegenden Erfindung verwaltet werden.
Ein Hauptspeicher 110 in dem Computersystem 100 enthält das Unternehmensverwaltungssystem 120 der vorliegenden Erfindung. Ein Anwendungsprogramm 126, das von einem Benutzer der vorliegenden Erfindung entwickelt wird, kommuniziert mit dem Unternehmensverwaltungssystem 120, wobei wiederum beide mit einem Betriebssystem 122 und einer Speicherverwaltungssoftware 124 kommunizieren, um die Unternehmensverwaltungsdienste im Auftrag von Kundenanwendungsprogrammen durchzuführen. Die vorliegende Erfindung weist Verfahren und Strukturen auf, die die Interaktionen zwischen dem Anwendungsprogramm 126, dem Unternehmensverwaltungssystem 120 und der Speicherverwaltungssoftware 124 definieren, um Informationen auf eine konsistente Weise zu speichern und zu manipulieren, um eine verbesserte Datenintegrität und ein verbessertes gemeinschaftliches Verwenden von Informationen zwischen mehreren Anwendungsprogrammen zu erleichtern. Weitere Verfahren der vorliegenden Erfindung unterstützen die automatisierte Erzeugung von Anwendungsprogrammen 126, Serverprogrammen in dem Unternehmensverwaltungssystem 120 und DBMS-Schemata, um die Struktur von Informationen zu definieren, die durch die Speicherverwaltungssoftware 124 manipuliert werden.
Die Kundenanwendungsprogramme 126 können lokal in dem Computersystem 100 operieren, oder bei anderen Computersystemen operieren, die mit dem Netz 118 verbunden sind oder über dasselbe kommunizieren. Es ist für Fachleute auch offensichtlich, daß die Informationen, die in dem gemeinsamen Unternehmensdepot 316 gespeichert sind, lokal auf einer Platte 114 gespeichert sein können oder lokal in dem Hauptspeicher 110, oder auch über andere Computersysteme verteilt sein können, auf die über das Netz 118 zugegriffen werden kann, oder in jeder Kombination von Speichervorrichtungen. Insbesondere können die Informationen, die in dem gemeinsamen Depot 316 gespeichert sind, in jeder Speichervorrichtung oder Speichereinrichtung gespeichert sein, die geeignete Kapazitäts- und Verhaltenscharakteristika aufweist. Die Platte 114 kann z. B. auch als eine Sammlung von Speichervorrichtungen implementiert sein, die über eine Mehrzahl von Berechnungssystemen 100 verteilt sind, die über das Netz 118 angebracht sind.

Gemeinsame Klassen:

Die vorliegende Erfindung umfaßt Standardobjektklassendefinitionen, genannt gemeinsame Klassen (im folgenden auch als Objektmodelle und Objektmodelleinrichtungen bezeichnet), die von den Verfahren der vorliegenden Erfindung verwendet werden. Die vorliegende Erfindung umfaßt mehrere Gemeinsame-Klasse- (Objektmodell-) Definitionen für viele Typen von Objekten, die in typischen Unternehmensverwaltungsanwendungsprogrammen unterstützt werden. Die Gemeinsame-Klasse- Definitionen werden von Anwendungsprogrammentwicklern auf zwei Weisen verwendet. Als erstes kann die Gemeinsame- Klasse-Definition von Anwendungsprogrammen gemeinsam mit Serverprogrammen (weitern unten beschrieben) verwendet werden, die Informationen bezüglich dieser Klasse von Objekten manipulieren. Zweitens kann ein Serverprogramm spezialisierte Teilklassen der Gemeinsame-Klasse-Objektdefinitionen definieren, um spezielle Objekte zu definieren, die von den Serverprogrammen verwaltet werden und in dem gemeinsamen Depot 316 gespeichert sind. Derartige Spezialisierungen von gemeinsamen Klassen können zusätzliche Details liefern, die von einem bestimmten Verwaltungsanwendungsprogramm benötigt werden.
Ein Durchsetzen der Definitionen der gemeinsamen Klasse oder der Gemeinsame-Klasse-Teilklasse bezüglich Objekten, die in dem gemeinsamen Depot 316 gespeichert sind und von den Serverprogrammen verwaltet werden, hilft, sicherzustellen, daß alle Daten, die in dem gemeinsamen Depot 316 gespeichert sind, eine konsistente Organisation aufweisen, und daß andernfalls unterschiedliche Teile von Daten auf ein Anwendungsprogramm beziehbar sind. Diese gemeinsamen Klassen sind Schnittstellenspezifizierungen für Objektklassen, die für ein breites Array von Anwendungsprogramm- und Serverprogrammentwicklern für nützlich gehalten werden. Diese Spezifizierungen verkapseln Daten, die für verschiedene Unternehmensverwaltungsaufgaben gemeinsam sind. Aus diesen Spezifizierungen implementieren Programmentwickler Teilklassen, die als eine Basis für spezifische Klassen von Objekten, die in einer bestimmten Verwaltungsanwendung verwaltet werden sollen, verwendet werden können. Umgekehrt können Anwendungsprogrammentwickler Anwendungsprogramme entwerfen, die die allgemeineren Schnittstellen, die durch die gemeinsame Klasse identifiziert sind, verwenden.
Die Fig. 4 und 5 stellen Objektklassentypen dar, die typisch für Gemeinsame-Klasse-Definitionen für Objekttypen sind, deren topologische Assoziationen von einem Topologieserver verwaltet werden sollen, der Informationen in dem gemeinsamen Depot 316 manipuliert. Ein Topologie-Server ist in der EP-A-0750254 erläutert. Die gleichen Objekte können auch durch andere Serverprogramme der vorliegenden Erfindung verwaltet werden, um die Objekte im Auftrag von anderen Anwendungsprogrammen zu manipulieren.
Eine Objekttypdefinition in den Fig. 4 und 5 ist durch einen Kasten angezeigt, der mit dem Objekttypnamen bezeichnet ist. Wenn ein erstes Objekt eine Spezialisierung eines zweiten Objektklassentyps ist, zeigt ein Pfeil von dem ersten Objekttypkasten zu dem zweiten, um die Vererbung der allgemeineren Objekttypattribute anzuzeigen.
In den Fig. 4 und 5 ist ein Allgemeinobjekttyp, der als OBJEKTKLASSE 400 bezeichnet ist, gezeigt. OBJEKTKLASSE 400 ist die allgemeinste Objekttypdefinition für Objekte, die durch Serverprogramme der vorliegenden Erfindung verwaltet werden. Beispiele von mehreren Spezialisierungen der OBJEKTKLASSE 400 sind in den Fig. 4 und 5 gezeigt, die nützlich zum Berechnen und für Netzverwaltungsanwendungsprogramme sind, die wiederum den Dienst des Topologie- (Beziehungs-)Serverprogramms der vorliegenden Erfindung verwenden.
Objekttypen in Fig. 4 sind typisch für spezialisierte Objekte, die physische Aspekte von Objekten darstellen, die durch ein Wert/Bestand-Verwaltungsanwendungsprogramm verwaltet werden sollen. TOR 402, SCHLITZ 404, KARTE 406, RÜCKWAND 408 und CHASSIS 410 sind Beispiele von spezialisierten Objekttypen, die von der OBJEKTKLASSE 400 abgeleitet sind, die nützlich für Anwendungsprogramme sind, die für die Verwaltung von Netz- und Berechnungsbetriebsmitteln entworfen sind. Andere exemplarische Objekttypen 412 bis 428 aus Fig. 4 sind für Anwendungsprogramme nützlich, die andere topologische Assoziationen unter Objekten oder Attributen derselben verwalten. Objekttypen TERMINATOR 420, VERBINDER 422 und MEDIUM 424 sind Spezialisierungen des Objekttyps MEDIENHARDWARE 418. Diese Spezialisierungsobjekttypen sind für die spezifischen Bedürfnisse eines oder mehrerer Anwendungsprogramme definiert, die eine spezielle Kenntnis von unterschiedlichen Typen von MEDIENHARDWARE- 418-Objekten erfordern. Ähnlich sind Objekttypen KABEL 426 und OPTISCHE VERBINDUNG 428 Spezialisierungen des MEDIUM- 424-Objekttyps, um weitere Details hinsichtlich Objekten zu liefern, die unterschiedliche Typen von Verbindungsmedien identifizieren.
Objekttypen, die in Fig. 5 dargestellt sind, sind weitere Beispiele von spezialisierten Objekten, die bei einem hypothetischen Unternehmensverwaltungsanwendungsprogramm nützlich sind. Die Objekttypen aus Fig. 5 stellen logische Charakteristika von Objekten dar, die durch ein Serverprogramm im Auftrag eines Verwaltungsanwendungsprogramms manipuliert werden. Objekttypen BENUTZER 502, SCHNITTSTELLE 504 und NETZPROTOKOLL 506 sowie Objekttypen 508 bis 558 aus Fig. 5, sind Beispiele von Objekttypen, die durch ein Serverprogramm im Auftrag eines hypothetischen Unternehmensverwaltungsanwendungsprogramms verwaltet werden.
Die Objekttypen, die in den Fig. 4 und 5 dargestellt sind, sollen die Objekttypen, die als Gemeinsame-Klasse-Objekte definierbar sind, nicht einschränken. Vielmehr sind die Objekttypen der Fig. 4 und 5 nur als Beispieleinrichtungen gedacht, um die Typen von Objekten darzustellen, die nützlicherweise von einem exemplarischen Serverprogramm der vorliegenden Erfindung, einem Topologie-Server, verwaltet werden können.

Metaschema:

Die Typen von Objekten, die wie definiert durch die gemeinsamen Klassen (und Spezialisierungen derselben) definiert sind und die Typen von verwalteten Informationen, die verwalteten Objekten zugeordnet sind, sind durch das Metaschema der vorliegenden Erfindung definiert. Der Zweck des Metaschemas besteht darin, eine Standardstruktur für die Speicherung von Verwaltungsinformationen in dem gemeinsamen Depot 316 der vorliegenden Erfindung zu definieren. Zusätzlich liefert das Metaschema einen Rahmen für die semantische Standardinterpretation der Verwaltungsinformationen, die den verwalteten Objekten, die durch die Serverprogramme der vorliegenden Erfindung verwaltet werden, zugeordnet sind.
Der Zweck des Metaschemas besteht darin, eine Standardstruktur für die Speicherung von Informationen, die verwalteten Objekten zugeordnet sind, in dem gemeinsamen Depot 316 zu definieren. Diese standardisierte Struktur ermöglicht eine verbesserte Integration von andernfalls ungleichen Verwaltungsanwendungsprogrammen durch ein Sicherstellen, daß ähnliche Informationen auf ähnliche Weisen gespeichert werden.
Verwaltungsdaten, die von ungleichen Anwendungsprogrammen durch die Standardstruktur und Semantik des Metaschemas gemeinschaftlich verwendet werden, umfassen:
Topologie - Informationen, die Assoziationen zwischen verwalteten Objekten beschreiben,
Attribut - Basisinformationen über ein verwaltetes Objekt, die Attribute des Objektes beschreiben, die für eines oder mehrere Anwendungsprogramme von Interesse sind,
Vorgeschichte und Trend - Informationen, die von Anwendungsprogrammen verwendet werden, die auch verwendet werden, um historische Veränderungen bei den verwalteten Objekten aufzuzeichnen, und um Trends bei Parametern zu erfassen, die dem verwalteten Objekt zugeordnet sind, und
Meldung - Informationen, die sich auf Ereignisse beziehen, die relevant für mehrere Objekte und mehrere Anwendungsprogramme sind.
Das Metaschema definiert Standardstrukturen zum Speichern dieser Informationen und zum Zuordnen dieser Informationen zu einem verwalteten Objekt. Das Metaschema weist eine Zahl von Datenbankschemadefinitionen für Tabellen auf, die die oben erwähnten Typen von Verwaltungsdaten speichern. Felder in jeder der Tabellen, die durch die Schemata definiert sind, sind einem atomaren Datentyp zugeordnet, und umfassen:
* Numerisch - umfaßt Ganzzahlen, Festkommadezimal- und Gleitkomma-Zahlen, die in verschiedenen Genauigkeitspegeln dargestellt sind,
* Boolesche - zeigt WAHR oder FALSCH an, Logik
* Datum - zeigt ein Datum in einem implementierungsabhängigen Format an,
* Zeitstempel - zeigt vergangene Zeit in Sekunden seit dem 1. Januar 1970 an,
* Aufgezählt - zeigt einen Wert aus einem endlichen Satz von sich gegenseitig ausschließenden Werten an (oft als eine Ganzzahl mit beschränktem Bereich von erlaubten Werten dargestellt),
* Zeichen - zeigt eine Zeichenfolge von Bytes mit fester Länge,
* Varchar - stellt eine Zeichenfolge von Bytes mit variabler Länge dar, und
* UUID - ein Wert, der als eine universale, eindeutige Identifizierung erzeugt wird.
Unter Verwendung dieser atomarer Datentypen kann die Standarddarstellung von Verwaltungsinformationen als Datenbankschemata definiert werden.

Topologieschemata:

Eine Topologie ist eine Sammlung von spezifischen topologischen Assoziationen aus einem ausgewählten Satz von verwalteten Objekten. Diese topologischen Assoziationen werden von einem Topologiedienstprogramm verwaltet. Die topologischen Assoziationen decken auf, wie Objekte bezüglich einander in Beziehung stehen, z. B. welche verwaltete Objekte weitere verwaltete Objekte enthalten und wie viele verwaltete Objekte miteinander verbunden sind. Der Topologiedienst enthält streng genommen die verwalteten Objekte selbst nicht. Vielmehr ist die Topologie die Informationen, die die Assoziationen zwischen den verwalteten topologischen Objekten beschreiben und bezieht sich nur indirekt auf die verwalteten Objekte.
Die Topologieschemata erfüllen die folgenden Ziele:
1. Die Fähigkeit, jede Sammlung von verwaltbaren Objekten darzustellen, ungeachtet davon, ob sie physischer oder logischer Natur sind (wie oben Bezug nehmend auf Fig. 4 und 5 besprochen wurde) und ungeachtet der tatsächlichen dargestellten Objekte und Topologien (d. h. Netze, Systeme, Dienste usw.).
2. Ermöglichen der Darstellung von vollständig willkürlichen Sammlungen von Objekten (d. h. wobei die Kriterien, durch die ein Satz von Objekten mit einem anderen Satz assoziiert ist, nicht notwendigerweise aus den Objektattributen abgeleitet werden können, die in dem gemeinsamen Depot 316 gespeichert und verwaltet werden).
3. Ermöglichen dessen, daß Objekte gleichzeitig zu mehreren, möglicherweise unabhängigen Sätzen von Topologieassoziationen gehören.
4. Ermöglichen von mehreren Typen von topologischen Assoziationen zwischen verwalteten Objekten, die z. B. enthalten: Inhalt, Verbindbarkeit und Abhängigkeit.
Ein häufiger Dienst bei der Unternehmensverwaltung ist die Verwaltung von topologischen Informationen. Wie topologische Informationen hierin verwendet werden, beziehen sie sich auf die Beziehungen zwischen verwalteten Objekten. Derartige topologische Informationen werden oft in einer graphischen Form dargestellt, um hierarchische sowie weitere Assoziationen zwischen verwalteten Objekten wiederzugeben. Beim Modellieren von Assoziationen zwischen Objekten, wie dies hierin beschrieben ist, werden die topologischen Aspekte der Objekte als Betriebsmittel oder Betriebsmittelaspekte bezeichnet. Die Beziehungen unter den Betriebsmitteln werden Assoziationen bezeichnet. Die Gemeinsames-Depot-Datenbank-Schemata der vorliegenden Erfindung definieren die Standardstruktur von topologischen Informationen, die von Serverprogrammen der vorliegenden Erfindung verwaltet werden. Fig. 6 stellt dar, wie die Tabellen, die durch die Topologieschemata definiert sind, organisiert sind.

RATYPE-Tabelle

Eine RATYP-Tabelle 600 aus Fig. 6 enthält den Namen jedes definierten Betriebsmittelaspekttyps. Einträge in anderen Tabellen werden auf diesen Typnamen verschlüsselt und dadurch dem bestimmten definierten Betriebsmittelaspekttyp zugeordnet. Jeder Eintrag in einer RATYPE-Tabelle 600 enthält ein type_name-Attribut 602, das den Betriebsmittelaspekttyp in dem gemeinsamen Depot 316 eindeutig identifiziert. Die Attribute der Inhaltstabelle 620 sind wie folgt definiert:
Andere Tabellen, die unten beschrieben werden, werden auf das type_name-Attribut 602 verschlüsselt, das in den Einträgen der RATYPE-Tabelle 600 zu finden ist.

RA-Tabelle:

Eine RA-Tabelle 604 aus Fig. 6 enthält Informationen, die spezifische Instanzen von topologischen Objekten eines bestimmten Betriebsmittelsaspekttyps beschreiben. Derartige spezifische Instanzen werden im folgenden als Betriebsmittelaspekte bezeichnet. Jeder Eintrag in einer RA-Tabelle 604 enthält ein type_name-Attribut 606 und ein ra_id- Attribut 608. Das type_name-Attribut 606 identifiziert den Betriebsmittelaspekttyp der Betriebsmittelaspektinstanz. Das ra_id-Attribut 608 identifiziert den Betriebsmittelaspekt eindeutig als ein Objekt in dem gemeinsamen Depot 316. Die Attribute der RA-Tabelle 604 sind wie folgt definiert:

RANANE-Tabelle:

Eine RANAME-Tabelle 610 aus Fig. 6 enthält Informationen, die vom Benutzer bereitgestellte Namen beschreiben, die einer bestimmten Betriebsmittelaspektinstanz zugeordnet sind. Jeder Eintrag in einer RANAME-Tabelle 610 enthält ein ra_id-Attribut 612 und ein aspect_name-Attribut 614. Das ra_id-Attribut 612 identifiziert den Betriebsmittelaspekt eindeutig, dem der RANAME-Eintrag zugeordnet ist. Das aspect_name-Attribut 614 ist ein vom Benutzer bereitgestellter Name, durch den der Betriebsmittelaspekt identifiziert wird. Das aspect_name-Attribut 614 wird von den Topologieverwaltungsserverprogrammen verwendet, um Betriebsmittelaspekte zu identifizieren, die sich tatsächlich auf das gleiche Betriebsmittel beziehen, das von dem Benutzer genannt wurde. Die Attribute der RANAME-Tabelle 610 sind wie folgt definiert:

RAINHERITANCE-Tabelle:

Eine RAINHERITANCE-Tabelle 616 aus Fig. 6 enthält Informationen, die beschreiben, welche Betriebsmittelaspekttypen Eltern jedes Betriebsmittelaspekttyps sind. In objektorientierten Klassendefinitionen erbt eine Klassendefinition alle Attribute ihrer Eltern. Jeder Betriebsmittelaspekttyp, der in der RATYPE-Tabelle 600 definiert ist, hat 0 oder mehr Elterneinträge, die in der RAINHERITANCE-Tabelle 616 definiert sind. Jeder Eintrag in der RAINHERITANCE-Tabelle 616 enthält ein type_name-Attribut 618 und ein type_name_parent-Attribut 620. Das type_name-Attribut 618 identifiziert den Betriebsmittelaspekttyp, für den der Eintrag einen Elterntyp definiert. Das type_name parent- Attribut 620 identifiziert den Elternbetriebsmittelsaspekttyp des Eintrags, von dem der Eintrag andere Attribute erbt. Die Attribute der RAINHERITANCE-Tabelle 616 sind wie folgt definiert:

ASSOCIATION RULE-Tabelle:

Eine ASSOCIATION_RULE-Tabelle 622 aus Fig. 6 enthält Informationen, die Vorschriften für die Bildung von Assoziationen für jeden Betriebsmittelaspekttyp beschrieben. Betriebsmittelaspekte eines bestimmten Betriebsmittelaspekttyps können Assoziationen mit Betriebsmittelaspekten gemäß den Vorschriften bilden, die durch Einträge in den Einträgen der ASSOCIATION_RULE-Tabelle 622 definiert sind. Jeder Eintrag in der ASSOCIATION_RULE-Tabelle 622 enthält ein type_name-Attribut 624, ein role-Attribut 626, ein min- Attribut 628, ein max-Attribut 630 und ein assoc_type_name- Attribut 632. Das type_name-Attribut 624 identifiziert den Betriebsmittelaspekttyp, für den der Eintrag eine Assoziationsvorschrift definiert. Das role-Attribut 626 identifiziert die benutzerdefinierte Funktion des Betriebsmittelaspekttyps beim Bilden einer Assoziation gemäß der definierten Vorschrift. Das min-Attribut 628 und das max- Attribut 630 definieren die minimale und die maximale Zahl von Assoziationen, die von einem Betriebsmittelsaspekt des identifizierten Typs zu anderen Betriebsmittelaspekten gebildet werden können. Das assoc_type_name-Attribut 632 identifiziert den Betriebsmittelaspekttyp des anderen Betriebsmittelaspektes, dem der Betriebsmittelaspekt des identifizierten Betriebsmittelaspekttyps gemäß der definierten Vorschrift zugeordnet sein kann. Die Attribute der ASSOCIATION-RULE-Tabelle 622 sind wie folgt definiert:

ASSOCIATION-Tabelle:

Eine ASSOCIATION-Tabelle 634 aus Fig. 6 enthält Informationen, die Assoziationen beschreiben, die tatsächlich zwischen zwei Betriebsmittelaspekten gebildet sind. Jeder Eintrag in der ASSOZIATION-Tabelle 634 enthält ein ra_id_1- Attribut 636, ein role_1-Attribut 638, ein ra_id_2-Attribut 640 und ein role_2-Attribut 642. Das ra_id_1-Attribut 636 identifiziert den ersten der beiden Betriebsmittelaspekte, die an der Assoziation teilnehmen, während das ra_id_2- Attribut 640 den anderen identifiziert. Das role 1-Attribut 638 und das role_2-Attribut 642 identifizieren die benutzerdefinierte Funktion von ra_id_1 bzw. ra_id_2 beim Bilden der Assoziation. Die Attribute der ASSOCIATION-Tabelle 634 sind wie folgt definiert:

TYPE ENFORCER-Tabelle:

Eine TYPE ENFORCER-Tabelle 644 aus Fig. 6 enthält Informationen, die Durchsetzerinformationen beschreiben, die einem bestimmten Betriebsmittelaspekttyp zugeordnet sind. Der Durchsetzer ist ein Verfahren zum Definieren von zusätzlichen Vorschriften bei der Erzeugung und Modifizierung der topologischen Informationen. Vorschriften über die einfacheren Vorschriften hinaus, die durch die Einträge der ASSOCIATION_RULE-Tabelle 622 definiert sind, können zu einem Betriebsmittelaspekttyp durch Einträge in dieser Tabelle hinzugefügt werden. Jeder Eintrag in eine TYPE_ENFORCER- Tabelle 644 enthält ein type_name-Attribut 646 und ein type_enforcer_id-Attribut 648. Das type_name-Attribut 646 identifiziert den Betriebsmittelaspekttyp eindeutig, dem der TYPE_ENFORCER-Eintrag zugeordnet ist. Das type_enforcer_id-Attribut 648 ist ein vom Benutzer bereitgestellter Objektidentifizierer, der verwendet wird, um den Durchsetzer aufzurufen, wenn Veränderungen an den topologischen Informationen vorgenommen werden. Die Attribute der TYPE_ENFORCER-Tabelle 644 sind wie folgt definiert:

RA_ENFORCER-Tabelle:

Eine RA_ENFORCER-Tabelle 650 aus Fig. 6 enthält Informationen, die Durchsetzerinformationen beschreiben, die einem bestimmten Betriebsmittelaspekt zugeordnet sind. Der Durchsetzer ist ein Verfahren zum Definieren von zusätzlichen Vorschriften bei der Erzeugung und Modifizierung der topologischen Informationen. Vorschriften über die einfacheren Vorschriften hinaus, die durch die Einträge der ASSOCIATION_RULE-Tabelle 622 definiert sind, können zu einem Betriebsmittelsaspekt durch Einträge in dieser Tabelle hinzugefügt werden. Jeder Eintrag in einer RA_ENFORCER- Tabelle 650 enthält ein ra_id-Attribut 652 und ein ra_enforcer_id-Attribut 654. Das ra_id-Attribut 652 identifiziert den Betriebsmittelaspekt eindeutig, dem der RA_ENFORCER-Eintrag zugeordnet ist. Das ra_enforcer_id- Attribut 654 ist ein vom Benutzer bereitgestellter Objektidentifizierer, der verwendet wird, um den Durchsetzer aufzurufen, wenn Veränderungen an den topologischen Informationen vorgenommen werden. Die Attribute der RA_ENFORCER- Tabelle 650 sind wie folgt definiert:

Verwaltetes-Objekt-Schemata:

Die oben beschriebenen Topologieschemata definieren eine Standardstruktur und Semantik für die Speicherung und Verwaltung von topologischen Assoziationsinformationen in dem gemeinsamen Depot 316. Die Topologieinformationen speichern nicht explizit die Objekte, die einem anderen zugeordnet sind. Vielmehr wird auf die Objekte nur indirekt durch Bezugnahme auf einen Objektidentifizierungsattributwert Bezug genommen, der das gespeicherte Objekt darstellt, das an anderer Stelle in den gemeinsamen Depots 316 der vorliegenden Erfindung gespeichert und verwaltet wird.
Objekte, die durch die Strukturen und Verfahren der vorliegenden Erfindung verwaltet werden, werden gemäß Schemata gespeichert, die Standardstrukturen für die Speicherung von Ojektattributen und historische, Ereignis- und Trend- Informationen, die sich auf die Objekte beziehen, definieren. Die Schemata, die die Informationen und darauf bezogene Struktur zum Speichern und Verwalten von Objekten definieren, sind im allgemeinen in zwei große Gruppen unterteilt: Klassendefinitionsschemata und Objektinstanzschemata. Die Klassendefinitionsschemata sind in Fig. 7 dargestellt, die unten beschrieben wird, und definieren eine Struktur zum Speichern von Informationen, die eine Objekttypklasse und so Informationen beschreiben, die auf alle Objekte dieser Objekttypklasse zutreffen. Die Objektinstanzschemata sind in Fig. 8 dargestellt, die unten besprochen wird, und definieren eine Struktur zur Speicherung von Informationen, die für eine bestimmte Instanz eines Objektes einer bestimmten Objekttypklasse eindeutig sind.

Klassendefinitionsschemata:

Fig. 7 stellt den allgemeinen Entwurf von Schemata dar, die die Struktur von Tabellen definieren, die Informationen über Objekttypklassen speichern. Die Schemadefinitionen, die in Fig. 7 dargestellt sind, stellen eine Union von vielen Strukturen dar, die in Alternativstandards für eine Objekttypklassenschemadefinition definiert sind. Insbesondere umfassen die Schemata aus Fig. 7 Merkmale und Objektklassendefinitionssprachen, die GDMO, CORBA IDL und Concise MIB umfassen. Die GDMO-Objektklassendefinitionssprache ist durch CCIT Recommendation X.722/ISO/ITU 10165-4 : 1991 INFORMATION TECHNOLOGY-OPEN SYSTEMS INTERCONNECTION STRUCTURE OF MANAGEMENT INFORMATION - PART 4: GUIDELINES FOR DEFINITION OF MANAGED OBJECTS definiert. Die CORBA IDL Objektklassendefinitionssprache ist durch die Objekt Management Group, Inc. (mit Sitz in Framingham Corporate Center, 492 Old Connecticut Path, Framingham, MA 01701 und im folgenden als OMG bezeichnet) definiert und ist in Standard-OMG-Veröffentlichungen dokumentiert, sowie in COMMON OBJECT REQUEST BROKER: ARCHITECTURE & SPECIFICATION von X/Open (X/Open CAE Specification C432 ISBN 1-85912-044-X war früher Veröffentlichung P210, erhältlich bei X/Open Company Ltd, Berks, Großbritannien und wird im folgenden als die CORBA-Spezifizierung bezeichnet). Concise MIB ist durch die Internet Engineering Task Force (IETF) - Network Working Group - RFC1212 definiert.

Klasseninformationstabelle:

Alle Klassen von Objekten, die von der vorliegenden Erfindung verwaltet werden, weisen einen Eintrag in der Klasseninformationstabelle 700 auf. Jeder Eintrag in der Klasseninformationstabelle 700 weist ein class_name-Attribut 702, ein creation_time-Attribut 704, ein specification_type- Attribut 706, ein metadata_provider-Attribut 708 und ein metadata_key_table-Attribut 710 auf. Das class_name- Attribut 702 identifiziert den Klassendefinitionseintrag in der Klasseninformationstabelle 700 eindeutig. Das creation_time-Attribut 704 speichert die Zeit der Erzeugung des Klassendefinitionseintrags. Das specification_type-Attribut identifiziert die Standardspezifizierungssprache, die verwendet wird, um die Klasse, wie oben beschrieben wurde, zu definieren. Die vorliegende Erfindung nimmt Concise MIB, GDMO, CORBA IDL und andere Spezifizierungstypen auf. Das metadata_provider-Attribut 708 und das metadata_key_table- Attribut 710 identifizieren Informationen, die benötigt werden, um mit einem Verfahren oder einer Entität in Wechselwirkung zu stehen, die ferner Informationen liefern, um die Klasse zu definieren. Die Attribute der Klasseninformationstabelle 700 sind wie folgt definiert:

Klassenreferenztabelle:

Einträge in der Klassenreferenztabelle 712 aus Fig. 7 beziehen sich auf alle Tabellen, die Attributwerte für eine bestimmte Klasse enthalten. Einige Klassendefinitionen benötigen mehrere Tabelle, um ihre verschiedenen Attributwerte für Objekte zu speichern. Ein Grund dafür sind sehr große Klassendefinitionen, deren kombinierte Attributtypen sich über die pro Eintrag Speicherbeschränkungen eines bestimmten Datenbankverwaltungsteilsystems hinaus erstrecken, das der Struktur und Verfahren der vorliegenden Erfindung des gemeinsamen Depots 316 zugrunde liegt. Ein weiterer Grund für mehrere Tabellen, die eine Klasse definieren, leitet sich aus Strukturen ab, die bei bestimmten Klassendefinitionen verwendet werden, die zusätzliche Tabellen erfordern, um die Klasse zu definieren. Die "SEQUENCE OF"- und "SET OF"-Struktur in der GDMO-Spezifizierungssprache z. B. und die "Tabellen"-Struktur in der Concise MIB- Definitionssprache stellen eine Liste von Werten dar. Jedesmal, wenn einer dieser Strukturen gefunden wird, oder wenn eine lange Klassendefinition die Länge pro Eintrag des zugrundeliegenden Datenbankverwaltungssystems überschreitet, wird eine Teiltabelle benötigt, um die Daten in der Struktur zu speichern.
Die Klassenreferenztabelle 712 weist einen Eintrag für jede Teiltabelle auf, die benötigt wird, um eine bestimmte Klasse zu beschreiben. Alle Einträge in der Klassenreferenztabelle weisen ein class_name-Attribut 714, ein subtable_no- Attribut 716, ein page no-Attribut 718, ein parent_attribute-Attribut 720, ein instance_table-Attribut 722 und ein history_table-Attribut 724 auf. Das class_name- Attribut 714 identifiziert die Klasse, für die dieser Eintrag eine Teiltabelle darstellt. Die Attribute der Klassenreferenztabelle 712 sind wie folgt definiert:

Klassenvorgeschichtenkonfigurationstabelle:

Einträge in der Klassenvorgeschichtenkonfigurationstabelle 742 enthalten Informationen bezüglich Konfigurationsdaten, die auf Objekte bezogen sind, die zu der entsprechenden Klasse gehören. Einige Gemeinsame-Klasse-Objekte speichern historische Aufzeichnungen von Konfigurationsdaten, um Veränderungen der Konfiguration über die Zeit zu protokollieren. Jeder Eintrag in der Klassenvorgeschichtenkonfigurationstabelle 742 weist ein class_name-Attribut 744, ein retention_threshold-Attribut 746 und ein snapshot_interval- Attribut 748 auf. Das class_name-Attribut 744 jedes Eintrags identifiziert die Klassendefinition, zu der der Konfigurationsvorgeschichteneintrag gehört. Das retention_threshold-Attribut 746 zeigt die Zeitdauer an, für die der Eintrag gültig ist und nach dem er gelöscht werden kann. Das snapshot_interval-Attribut 748 zeigt die reguläre Zeitperiode an, für die ein neuer Eintrag durch eine geeignete Verwaltungsanwendung oder Serverprogramme der vorliegenden Erfindung erzeugt werden soll. Die Attribute der Klassenvorgeschichtenkonfigurationstabelle 742 sind wie folgt definiert:

Codierte Klassenreferenztabelle:

Einträge in der codierten Klassenreferenztabelle 726 enthalten komplexe objekttypklassenbezogene Informationen in einer codierten Form, um eine Effizienz der Manipulation zu verbessern, und um Speicheranforderungen in dem gemeinsamen Depot 316 der vorliegenden Erfindung zu reduzieren. Jeder Eintrag in der codierten Klassenreferenztabelle weist ein class_name-Attribut 728, ein encode_data_table-Attribut 730 und ein encode_history_table-Attribut 732 auf. Das class_name-Attribut 728 jedes Eintrags identifiziert die Klassendefinition, zu der der codierte Klassenreferenzeintrag gehört. Das encode_data_table-Attribut 730 enthält den Namen einer anderen Tabelle mit codierten Daten für den Objektklassentyp. Das encode_history_table-Attribut 732 enthält den Namen einer anderen Tabelle mit codierten Vorgeschichteinformationen für die Objekttypklasse. Die Attribute der codierten Klassenreferenztabelle 726 sind wie folgt definiert:

Klasse-zu-Metaschlüssel-Tabelle:

Einträge in der Klasse-zu-Metaschlüssel-Tabelle 734 enthalten Informationen, die Zugriff auf Metadaten für die identifizierte Objektklassentypdefinition liefern. Diese Informationen werden üblicherweise, wenn überhaupt, durch Serverprogramme bereitgestellt, die Metadaten aus den Klassendefinitionsspezifizierungen verfügbar machen. Jeder Eintrag in der Klasse-zu-Metaschlüssel-Tabelle weist ein class_name-Attribut 736, ein metadata_key-Attribut 738 und weitere Attribute 740 auf. Das class_name-Attribut 728 jedes Eintrags identifiziert die Klassendefinition, zu der der codierte Klassenreferenzeintrag gehört. Das metadata_key-Attribut 738 und die anderen Attribute 740 liefern implementierungsspezifische Informationen, die geeignet zu der Bildung von Metadaten sind, die durch die Klassendefinitionshilfsprogramme und die darauf bezogenen Serverprogramme geliefert werden. Die Attribute der Klassenvorgeschichtenkonfigurationstabelle 726 sind wie folgt definiert:

Objektinstanzschemata:

Fig. 8 stellt den allgemeinen Entwurf von Schemata dar, die die Struktur von Tabellen definieren, die Informationen über spezifische Instanzen einer Objekttypklasse (d. h. spezifische Objekte einer bestimmten Typklasse) speichern.

Verwaltetes-Objekt-Tabelle:

Einträge in der Verwaltetes-Objekt-Tabelle 800 enthalten Identifizierungsinformationen für verwaltete Objekte, die in dem gemeinsamen Depot 316 gespeichert sind und durch Anwendungs- und Serverprogramme verwaltet werden. Es gibt für jedes Objekt, das durch die vorliegende Erfindung gespeichert und verwaltet wird, zumindest einen Eintrag in der Verwaltetes-Objekt-Tabelle 800. Jeder Eintrag in der Verwaltetes-Objekt-Tabelle weist ein oid-Attribut 802, ein class_name-Attribut 804, ein creation_time-Attribut 806 und ein modified_time-Attribut 808 auf. Das oid-Attribut 802 identifiziert das Objekt, das dem Verwaltetes-Objekt- Eintrag entspricht. Das class_name-Attribut 804 identifiziert die Objekttypklasse, zu der das verwaltete Objekt gehört. Das creation_time-Attribut 806 und das modified_time- Attribut 808 speichern die Zeit der Erzeugung bzw. der letzten Modifizierung des verwalteten Objekts. Wenn ein Objekt zu mehr als einer Objekttypklasse gehört, gibt es mehrere Einträge in der Verwaltetes-Objekt-Tabelle mit dem gleichen oid-Attribut 802, aber unterschiedlichen class_name-Attributen 804. Die Attribute der Verwaltetes- Objekt-Tabelle 800 sind wie folgt definiert:

Klasseninstanztabelle:

Einträge in der Klasseninstanztabelle 810 bestehen aus Informationen, die sich auf Objektinstanzen beziehen, die zu der Objekttypklasse gehören, der die Tabelle zugeordnet ist. Auf jede Klasseninstanztabelle 810 wird durch das instance_table-Attribut 722 der Klassenreferenztabelle 712, die oben Bezug nehmend auf Fig. 7 besprochen wurde, Bezug genommen. Jeder Eintrag in der Klasseninstanztabelle 810 weist ein oid-Attribut 812 und eine variable Zahl von anderen Attributen 814 auf. Das oid-Attribut 812 identifiziert das Objekt, das dem Klasseninstanzeintrag entspricht. Die variable Zahl von anderen Attributen 814 ist spezifisch für die Objektinstanz, die durch den Klasseninstanztabelleneintrag dargestellt wird. Die Attribute der Klasseninstanztabellen 810 sind wie folgt definiert:

Klassenvorgeschichtentabellen:

Einträge in den Klassenvorgeschichtentabellen 820 bestehen aus historischen Attributwerten von Objektinstanzen, die zu der Objekttypklasse gehören, der die Tabelle zugeordnet ist. Auf jede Klassenvorgeschichtentabelle 820 wird durch das history_table-Attribut 724 der Klassenreferenztabelle 712, die oben Bezug nehmend auf Fig. 7 erläutert wurde, Bezug genommen. Jeder Eintrag in der Klassenvorgeschichtentabelle 820 weist ein oid-Attribut 822, ein Datenattribut 824 und eine variable Zahl von anderen Attributen 826 auf. Das oid-Attribut 822 identifiziert das Objekt, das dem Klassenvorgeschichteneintrag entspricht. Die variable Zahl von anderen Attributen 826 ist spezifisch für die Objektinstanz, die durch den Klasseninstanztabelleneintrag dargestellt ist. Die Attribute der Klassenvorgeschichtentabellen 820 sind wie folgt definiert:

Klassencodierte Datentabellen:

Einträge in den klassencodierten Datentabellen 832 bestehen aus codierten Informationen, die sich auf Objektinstanzen beziehen, die zu der Objekttypklasse gehören, der die Tabelle zugeordnet ist. Auf jede klassencodierte Datentabelle 832 wird durch das encode_data_table-Attribut 730 der Codierte-Klasse-Referenztabelle 726, die oben Bezug nehmend auf Fig. 7 erläutert wurde, Bezug genommen. Jeder Eintrag in der klassencodierten Datentabelle 832 weist ein oid- Attribut 834, ein segment_no-Attribut 836 und eine variable Zahl von anderen Attributen auf, die als encoded_value- Attribut 838 dargestellt sind. Das oid-Attribut 834 identifiziert das Objekt, das dem klassencodierten Dateneintrag entspricht. Das segment_no-Attribut 836 zeigt an, welcher Abschnitt der codierten Attribute durch diesen Eintrag dargestellt ist (wenn das encoded_value-Attribut 838 die Länge überschreitet, die für einen einzelnen Eintrag erlaubt ist). Die variable Zahl von anderen Attributen im encoded_value-Attribut 838 ist spezifisch für die Objektinstanz, die durch den klassencodierten Datentabelleneintrag dargestellt ist. Die Attribute der klassencodierten Datentabellen 832 sind wie folgt definiert:

Klassencodierte Vorgeschichtentabelle:

Einträge in der klassencodierten Vorgeschichtentabelle 840 bestehen aus codierten historischen Attributwerten, die sich auf Objektinstanzen beziehen, die zu der Objekttypklasse gehören, der die Tabelle zugeordnet ist. Auf jede klassencodierte Vorgeschichtentabelle 840 wird durch das encode_history_table-Attribut 732 der Codierte-Klasse- Referenztabelle 726 Bezug genommen, die oben Bezug nehmend auf Fig. 7 erläutert wurde. Jeder Eintrag in der klassencodierten Vorgeschichtentabelle 840 weist ein oid-Attribut 842, ein Datumsattribut 844, ein segment_no-Attribut 846 und eine variable Zahl von anderen Attributen auf, die als encoded_value-Attribut 848 dargestellt sind. Das oid- Attribut 842 identifiziert das Objekt, das zu dem klassencodierten Vorgeschichteneintrag entspricht. Das segment_no- Attribut 846 zeigt an, welcher Abschnitt der codierten Attribute durch diesen Eintrag dargestellt ist (wenn das encoded_value-Attribut 848 die Länge überschreitet, die für einen einzelnen Eintrag erlaubt ist). Die variable Zahl von anderen Attributen im encoded_value-Attribut 848 ist spezifisch für die Objektinstanz, die durch den klassencodierten Vorgeschichtentabelleneintrag dargestellt ist. Die Attribute der klassencodierten Vorgeschichtentabelle 840 sind wie folgt definiert:

Historischer-Trend-Schemata:

Historischer-Trend-Schemata sind in Fig. 9 dargestellt und definieren die Struktur für die Speicherung von Daten, die über die Zeit gesammelt wurden, die auf verwaltete Objekte bezogen ist, die in dem gemeinsamen Depot 316 der vorliegenden Erfindung gespeichert sind. Anwendungs- und Serverprogramme manipulieren die Trennungsdaten, um erforderliche Verwaltungsanalyseaufgaben durchzuführen. Die Schemata, die in Fig. 9 dargestellt sind, für die Sammlung von Trenddaten sind nur als exemplarische Ausführungsbeispiele von genormten Schemata gedacht, die für die Sammlung und Wiedergewinnung derartiger Daten organisiert sind. Bei bestimmten Verwaltungsaufgaben ist es notwendig, Trenddaten sehr schnell aufgrund von Datenraten, die der bestimmten Objektinstanz zugeordnet sind, die sich auf die Trenddaten bezieht, einzufügen und wiederzugewinnen. In derartigen Fällen können Anwendungs- und Serverprogramme u. U. eine Adaptation von mehreren spezialisierten Schemata erfordern, die besser auf das bestimmte Verhalten oder Kapazitätsziele des bestimmten Objekts eingestellt sind.
Die Trenddatenschemata, die in Fig. 9 dargestellt sind, bestehen aus vier aufeinander bezogene Tabellen. Die Trendbeschreibungstabellen 900 beschreiben die Messungen (d. h. Variablen), die überwacht werden sollen. Die Trenddatensatztabellen 908 beschreiben den Datensatz oder Datenströme, für die die Variablen gemessen werden sollen. Die letzten beiden Tabellen, Grobtrenddatentabellen 918 und Reduzierttrenddatentabellen 928, speichern die tatsächlichen Trenddaten, die von Serverprogrammen gemessen und zur weiteren Analyse durch Anwendungsprogramme gespeichert werden.

Trendbeschreibungstabellen:

Einträge in den Trendbeschreibungstabellen 900 definieren die Variablen, die für eine bestimmte Trendanalyse gemessen werden sollen. Jeder Trendbeschreibungstabelleneintrag weist ein descript_id-Attribut 902 und eine variable Zahl von anderen Attributen 904 auf. Das descript_id-Attribut 902 ist eine eindeutige Identifizierung, die durch die Anwendungsprogramme erzeugt wird, die die Trenddaten verwenden, um eine bestimmte Variable, die gemessen werden soll, zu identifizieren. Die anderen Attribute 904 sind für die bestimmte Trendanalyseanwendung und Serverprogramme eindeutig, die die Variable, die gemessen werden soll, definierten. Die Attribute der Trendbeschreibungstabelle 900 sind wie folgt definiert:

Trenddatensatztabellen:

Einträge in Trenddatensatztabellen 908 enthalten Informationen, um einen Eintrag in einer Trendbeschreibungstabelle 900 und ein Objekt zu einem spezifischen Datensatzidentifizierer abzubilden, in dem die gemessenen Daten gespeichert sind. Jeder Eintrag in der Trenddatensatztabelle 908 weist ein oid-Attribut 910, ein descript_id-Attribut 912, ein dataset_id-Attribut 916 und andere Attribute 914 auf, die für das bestimmte Objekt und/oder die Variable eindeutig sind, die überwacht werden. Das oid-Attribut 910 identifiziert eine Objektinstanz (oben Bezug nehmend auf Fig. 8 beschrieben), die zu Zwecken des Sammelns von Trenddaten überwacht werden soll. Das descript_id-Attribut 912 identifiziert die Daten, die von dem identifizierten Objekt gesammelt werden sollen. Das descript_id-Attribut 912 entspricht einem Eintrag in den Trendbeschreibungstabellen 900, die oben beschrieben wurden. Das dataset_id-Attribut 916 identifiziert die Datensatztabellen eindeutig, die die gesammelten Daten speichern, die von dem identifizierten Objekt Bezug nehmend auf die identifizierte Trendbeschreibungsvariable gesammelt werden. Die Attribute der Trenddatensatztabelle 908 sind wie folgt definiert:

Grobtrenddatentabellen:

Einträge in den Grobtrenddatentabellen 918 enthalten die tatsächlichen Daten, die durch ein Überwachen der identifizierten Trendbeschreibungsvariable bezüglich des identifizierten Objektes gesammelt wurden. Jeder Eintrag in den Grobtrenddatentabellen 918 weist ein dataset_id-Attribut 920, ein sample_time-Attribut 922, ein Periodenattribut 924 und ein Wertattribut 926 auf. Alle Einträge, die den gleichen Wert für das dataset_id-Attribut 920 aufweisen, sind Teil des Datensatzes, der durch die entsprechende Trenddatensatztabelle 908 identifiziert wird, die oben beschrieben wurde. Das sample_time-Attribut 922 zeigt die Zeit an, zu der die Messung endete. Das Periodenattribut 924 zeigt die Länge der Zeitperiode an, über die die Messung vorgenommen wurde. Das Wertattribut 926 zeigt den Wert der identifizierten Messung an. Die Attribute der Grobtrenddatentabellen 918 sind wie folgt definiert:

Reduzierttrenddatentabelle:

Die Reduzierttrenddatentabelle 928 enthält identische Attribute wie die Grobtrenddatentabelle 918, die oben beschrieben wurde, ersetzt jedoch das Wertattribut 926 durch reduzierte Werte, die aus den Grobwerten berechnet werden, die in der Grobdatentabelle 918, die oben beschrieben wurde, gemessen wurden. Jeder Eintrag in den Reduzierttrenddatentabellen weist ein dataset_id-Attribut 930, ein sample_time-Attribut 932, ein Periodenattribut 934, ein min_value-Attribut 936, ein max_value-Attribut 938 und einen avg_value-Attribut 940 auf. Alle Einträge, die den gleichen Wert für das dataset_id-Attribut 930 aufweisen, sind Teil des Datensatzes, der durch die entsprechende Trenddatensatztabelle 908 identifiziert ist, die oben beschrieben ist. Das sample_time-Attribut 932 zeigt die Zeit an, zu der die Messung endete. Das Periodenattribut 934 zeigt die Länge der Zeitperiode an, über die die Messung vorgenommen wurde. Das min_value-Attribut 936, das max_value-Attribut 938 und das avg_value-Attribut 940 zeigen den minimalen, den maximalen bzw. den Durchschnittswert der gemessenen Variable des identifizierten Objektes an. Die Attribute der Reduzierttrenddatentabelle 930 sind wie folgt definiert:

SNMP-Trenddatenbeispiel:

Die Trenddatenschemata, die oben Bezug nehmend auf Fig. 9 beschrieben wurden, sind mit Hilfe eines Beispiels besser verständlich. SNMP ist ein bekanntes Netzverwaltungsprotokoll, das verwendet wird, um Netzkonfigurationen und - verhalten zu verwalten und zu überwachen. Die folgenden Tabellen beschreiben die trenddatenbezogenen Tabellen, wie sie auf das Überwachen einer typischen SNMP-Messung angewendet werden. SNMP-Trendbeschreibungstabelle: SNMP-Trenddatensatztabelle:
Die Grobtrenddaten- und Reduzierttrenddatentabellen für das oben beschriebene SNMP-Trenddatenbeispiel sind wie oben Bezug nehmend auf Fig. 9 beschrieben wurde.

Serverprogramme und Entwicklungshilfsprogramme:

Die Verfahren der vorliegenden Erfindung umfassen Standardserverprogramme, um das gemeinsame Depot 316 der vorliegenden Erfindung zu manipulieren. Alle Informationen, die in dem gemeinsamen Depot 316 gespeichert sind, halten sich an die Struktur des Metaschemas, wie dies oben definiert wurde. Die Standardserverprogramme der vorliegenden Erfindung liefern Dienste im Auftrag von Verwaltungskundenanwendungsprogrammen. Nur Serverprogramme führen direkt eine Speicherung, Wiedergewinnung und Verwaltung der Informationen, die zu verwalteten Objekten gehören, in dem gemeinsamen Depot 316 durch. Anwendungsprogramme, die eine Speicherung, eine Wiedergewinnung oder eine Manipulation von Informationen erfordern, fragen derartige Dienste bei einem Serverprogramm, das geeignet für die Informationsanfrage ist, an. Dies hilft, die Integrität und Konsistenz der Informationen sicherzustellen, die sich auf verwaltete Objekte in dem gemeinsamen Depot 316 beziehen. Die Mechanismen, durch die ein Anwendungsprogramm (oft als ein Kunde bezeichnet) mit einem Serverprogramm kommuniziert, sind eine Frage der Entwurfswahl durch den Implementierer der vorliegenden Erfindung. Mehrere Standardverfahren sind den Fachleuten bekannt.
Die Standardserver, die durch die vorliegende Erfindung geschaffen werden, umfassen einen Topologiedienst (wie in der EP-A-0750254 erläutert), eine Trenddatensammlung und einen Reduktionsdienst, um Daten zu messen und aufzuzeichnen, die sich auf bestimmte Aspekte von verwalteten Objekten beziehen, und eine Vorgeschichteattributdienst, um eine Vorgeschichte von Veränderungen bei Attributen von verwalteten Objekten aufzuzeichnen, die in dem gemeinsamen Depot 316 gespeichert sind. Viele Kundenanwendungsprogramme können unter Verwendung dieser Standarddienstprogramme in Verbindung mit den Datenstrukturen, die durch das Metaschema definiert sind, aufgebaut sein.
Wenn ein bestimmtes Anwendungsprogramm eine Wiedergewinnung oder Manipulation von Informationen in dem gemeinsamen Depot 316 erfordert, die nicht von den Standardserverprogrammen getragen wird, ermöglicht die vorliegende Erfindung die Entwicklung von neuen Serverprogrammen durch einen Softwareentwickler. Hilfsprogramme, die in der vorliegenden Erfindung geschaffen werden, akzeptieren eine objektorientierte Klassendefinition auf hoher Ebene der Informationen, die durch ein Verwaltungsanwendungsprogramm manipuliert werden sollen. Die objektorientierte Klassendefinition wird in der Form einer vorbereitenden IDL-Sprache-Beschreibung geliefert. Die IDL-Sprache wird in dem CORBA-Dokument von X/Open, das oben erläutert wurde, spezifiziert.
Ein Servererzeugungsentwicklungshilfsprogramm der vorliegenden Erfindung empfängt die vorbereitende IDL- Objektklassendefinition und erzeugt ein Datenbankschema für das zugrundeliegende Datenbankverwaltungsteilsystem, das von den Verfahren der vorliegenden Erfindung verwendet wird, um Informationen bezüglich der neu definierten Objektklasse zu speichern und wiederzugewinnen. Das Datenbankschema ist gemäß den Standards aufgebaut, die durch das Metaschema, das oben erläutert wurde, definiert sind. Informationen bezüglich der neuen Objektklasse werden gemäß der Struktur, die durch die Datenbankschemadefinition auferlegt wird, gespeichert und wiedergewonnen. Das Datenbankschema ist wiederum gemäß den Vorgaben der Metaschema- Struktur aufgebaut. Diese Struktur des zugrundeliegenden Datenbankschemas hilft beim Durchsetzen der erwünschten Integrität und Konsistenz der Informationen, die in dem gemeinsamen Depot 316 gespeichert und manipuliert werden.
Zusätzlich erzeugt das Servererzeugungsentwicklungshilfsprogramm ein Arbeitsgerüst des Quellencodes für ein Serverprogramm, um Basismanipulationen der Objekte durchzuführen, die durch die vorbereitende IDL-Sprache definiert sind. Der erzeugte Serverprogrammquellencode ist in dem Sinn "gerüstartig", daß er nur die Basisfunktionen des Erzeugens, Löschens, Aktualisierens und Wiedergewinnens von Informationen durchführt, die den Objekten zugeordnet sind, die durch die vorbereitende IDL-Objektklassendefinition definiert sind. Eine weitere anwendungsspezifische oder hochentwickelte Manipulation der neu definierten Objekte bleibt den Entwicklungsingenieuren überlassen. Wenn nur die oben beschriebenen Basisfunktionen benötigt werden, ist das "gerüstartige" Serverprogramm, das durch das Serverprogrammentwicklungshilfsprogramm erzeugt wird, vollständig und funktionell.
Das neu erzeugte Serverprogramm hilft, wenn es funktioniert, beim Sicherstellen der Integrität und Konsistenz der Manipulation von Informationen und Objekten, die in dem gemeinsamen Depot 316 gespeichert sind. Das erzeugte Serverprogramm hält sich an die Standardstrukturen zum Speichern, die durch das Metaschema definiert sind, und setzt diese durch. Anwendungsprogramme greifen nur auf Informationen bezüglich der neu definierten Objekte zu, die in dem gemeinsamen Depot 316 gespeichert sind, indem sie unterstützte Dienste durch Serverprogramme anfordern, die gemäß dem Metaschema und IDL-Objektklassentypinformationen erzeugt werden.
Diese Struktur ermöglicht die Integration von Informationen unter andernfalls ungleichen Verwaltungsanwendungsprogrammen. Alle Informationen, die in dem gemeinsamen Depot 316 gespeichert sind, halten sich an die Struktur, die durch das oben beschrieben Metaschema definiert ist. Die Integrität und Konsistenz der gespeicherten Informationen wird gegenüber alten Entwürfen verbessert, weil standardisierte Datenstrukturen nur von standardisierten Serverprogrammen manipuliert werden.
Fig. 10 zeigt den Fluß von Informationen bei der Operation des Serverprogrammerzeugungshilfsprogramms. Das Servererzeugungshilfsprogramm 1000 nimmt als Eingang die vorbereitende Objektklassen-IDL 1002. Das Servererzeugungshilfsprogramm 1000 verwendet implizit das Metaschema 1004 beim Verarbeiten des Eingangs der IDL 1002. Die vorbereitende Objektklassen-IDL 1002 spezifiziert die Objektattribute und zugeordnete Funktionen. Das Servererzeugungshilfsprogramm 1000 erzeugt als Ausgänge drei Informationsteile zum weiteren Verarbeiten, eine IDL 1006, ein Skelettserverprogramm 1010 und ein DBMS-Schema 1014.
Die IDL 1006 ist eine Adaptation der vorbereitenden Objektklassen IDL 1002, die von einem Servererzeugungshilfsprogramm 1000 modifiziert ist, um sich an die Strukturen und Vorschriften zu halten, die durch das Metaschema 1004 definiert sind. Die angepaßte IDL 1006 wird als Eingang von einem Standard-IDL-Sprache-Kompilierer 1008 verwendet, um Quellencodesegmente für ein Kundenanwendungsprogramm 1020 und für ein Gerüstserverprogramm 1010 zu erzeugen. Der IDL- Sprache-Kompilierer 1008 kann einer von mehreren standardmäßigen IDL-Kompilierern sein, die käuflich erhältlich sind. Die Ausgabe 1.3 des SunSoft OMG IDL Compiler Front End (CFE), der bei der Object Management Group (Adresse oben genannt) erhältlich ist, ist ein typisches derartiges IDL-Kompilierer-Hilfsprogramm zum Erzeugen von Quellencodesegmenten aus einer IDL-Sprache-Spezifizierung einer Objektklasse.
Das Gerüstserverprogramm 1010 wird durch die kombinierten Quellencodesegmente, die von dem Servererzeugungshilfsprogramm 1000 und dem IDL-Kompilierer 1008 ausgegeben werden, erzeugt. Das Skelettserverprogramm 1010 wird als Eingang zu dem Verfahren der Aufbauservers 1012 angewendet, das das tatsächlich ausführbare Serverprogramm 1022 erzeugt. Der Prozeß des Aufbauservers 1012 ist üblicherweise ein Standardquellencodekompilierer, wie z. B. ein C++-Kompilierer, der bei den meisten UNIX-Arbeitsplätzen vorgesehen ist.
DBMS-Schemata 1014 werden durch das Servererzeugungshilfsprogramm 1000 erzeugt und als Eingänge zu dem Verfahren zum Erzeugen des DBMS 1016 angewendet. Das Verfahren zum Erzeugen des DBMS 1016 wird als eine Komponente des zugrundeliegenden Datenbankverwaltungssystems geliefert, das die Informationen physisch speichert, die in dem gemeinsamen Depot 316 verwaltet werden. Die tatsächlichen DBMS-Tabellen 1026 werden durch das Verfahren zum Erzeugen des DBMS 1016 erzeugt und halten sich an die Struktur, die durch das Metaschema 1004 vorgegeben ist.
Der Anwendungsentwickler verwendet die Elemente 1000 bis 1016 auf der linken Seite der gestrichelten vertikalen Linie.
Es wurden Verfahren und eine Struktur für ein gemeinsames Depot beschrieben, um Verwaltungsinformationen gemeinschaftlich zu verwenden. Es soll offensichtlich sein, daß die bestimmten Ausführungsbeispiele, die in den Zeichnungen gezeigt und in dieser Spezifizierung erklärt wurden, nur zu Beispielszwecken dienen und nicht als Einschränkung der Erfindung aufgefaßt werden sollen, die in den folgenden Ansprüchen beschrieben ist. Ferner ist es offensichtlich, daß Fachleute zahlreiche Verwendungen und Modifizierungen der beschriebenen spezifischen Ausführungsbeispiele vornehmen können, ohne vom erfindungsmäßigen Konzept abzuweichen. Die Datenstrukturen, die z. B. hierin beschrieben sind, können in einer Vielzahl von bekannten Softwaredatenstrukturen implementiert sein. Ferner könnten die hierin beschriebenen Verfahren modifiziert werden, um eine Vielzahl von Datenstrukturen zum Speichern von Informationen zu manipulieren. Ähnlich könnten gleichwertige Strukturen und Verfahren für verschiedene beschriebene Strukturen und Verfahren eingesetzt werden. Folglich soll die Erfindung so aufgefaßt werden, daß sie jedes neuartige Merkmal und jede neuartige Kombination von Merkmalen umfaßt, die in den Verfahren und der Struktur, die oben beschrieben wurden, vorhanden sind, oder von dieser besessen werden.

Claims

1. Ein rechnergestütztes Datenverwaltungssystem (100) zum Verwalten von Informationen bezüglich Objekten, wobei jedes Objekt zu einer Objektklasse gehört und von Anwendungsprogrammen (1020) verwendet wird, wobei das Datenverwaltungssystem (100) folgende Merkmale aufweist:

eine Speichereinrichtung (100, 114) zum Speichern der Informationen; und

ein Metaschema (1004) zum Definieren von Standardstrukturen zum Speichern der Informationen, die durch das System verwaltet werden, in der Speichereinrichtung (110, 114), wobei die Informationen Attribute der Objekte und Beziehungen zwischen den Objekten aufweisen;

gekennzeichnet durch

eine Objektmodelldefinitionseinrichtung (1002, 1008) zum Definieren von Standardobjektklassen (400) von Objekten, die von den Anwendungsprogrammen (1020) verwendet werden, gemäß der Struktur, die durch das Metaschema (1004) definiert ist; und

eine Mehrzahl von Serverprogrammen (308-314, 1022) zum Bedienen von Anforderungen, die durch die Serverprogramme (308-214, 1022) empfangen werden, von den Anwendungsprogrammen (1020), um die Informationen bezüglich Objekten zu manipulieren, die in der Speichereinrichtung (110, 114) gespeichert sind, gemäß der Struktur der Informationen, die durch das Metaschema (1004) geschaffen werden, und gemäß den Standardobjektklassendefinitionen (400).

2. Das Datenverwaltungssystem (100) gemäß Anspruch 1, bei dem die Attribute der Objekte ferner zumindest eines einer Mehrzahl von Attributen aufweisen, die Standardobjektklassenattribute (700-848) und Trenddaten (900 -940), die auf die Objekte bezogen sind, umfassen.

3. Das Datenverwaltungssystem (100) gemäß Anspruch 1, bei dem die Beziehungen zwischen den Objekten topologische Assoziationsinformationen aufweisen, die auf die Objekte (600-654) bezogen sind.

4. Das Datenverwaltungssystem (100) gemäß Anspruch 1, das ferner folgende Merkmale aufweist:

eine Serverprogrammerzeugungseinrichtung (1000), zusammenwirkend mit dem Metaschema (1004) und mit der Objektmodelldefinitionseinrichtung (1002, 1008), zum Erzeugen von zusätzlichen Serverprogrammen (1022).

5. Das Datenverwaltungssystem (100) gemäß Anspruch 4, bei dem die Serverprogrammerzeugungseinrichtung (1000) ansprechend auf das Metaschema (1004) ist, um die Struktur von Serverprogrammen (1022) zu steuern, die durch die Serverprogrammerzeugungseinrichtung (1000) erzeugt werden.

6. Ein rechnergestütztes Datenverwaltungsverfahren (1000 -1026) zum Verwalten von Informationen bezüglich Objekten, wobei jedes Objekt zu einer Objektklasse gehört und von Anwendungsprogrammen (1020) verwendet wird, wobei das Datenverwaltungsverfahren folgende Schritte aufweist:

(a) Bereitstellen einer Speichereinrichtung (110, 114) zum Speichern der Informationen;

(b) Bereitstellen eines Metaschemas (1004);

(c) Definieren, gemäß dem Metaschema (1004), von Standardstrukturen zum Speichern der Informationen, die durch das Verfahren verwaltet werden, in der Speichereinrichtung (110, 114), wobei die Informationen Attribute (700-848) der Objekte und Beziehungen zwischen den Objekten (600-654) aufweisen; und

(d) Bereitstellen eines Objektmodells (1002);

gekennzeichnet durch folgende Schritte:

(e) Definieren, gemäß dem Objektmodell (1002, 1008), von Standardobjektklassen (400) von Objekten, die durch die Anwendungsprogramme (1020) verwendet werden, gemäß der Struktur, die durch das Metaschema (1004) definiert ist;

(f) Bereitstellen einer Mehrzahl von Serverprogrammen (1022); und

(g) Betreiben der Serverprogramme (1022), um Anforderungen eines Anwendungsprogramms (1020), um die Informationen bezüglich Objekten zu manipulieren, die in der Speichereinrichtung (110, 114) gespeichert sind, zu bedienen, gemäß der Struktur der Informationen, die durch das Metaschema (1004) bereitgestellt werden, und gemäß den Standardobjektklassendefinitionen (400).

7. Das Datenverwaltungsverfahren (1000-1026) gemäß Anspruch 6, bei dem die Attribute der Objekte ferner zumindest eines einer Mehrzahl von Attributen aufweisen, die Objektklassenattribute (700-848) und Trenddaten (900-940), die auf die Objekte bezogen sind, umfassen.

8. Das Datenverwaltungsverfahren (1000-1026) gemäß Anspruch 6, bei dem die Beziehungen zwischen den Objekten topologische Assoziationsinformationen aufweisen, die auf die Objekte (600-654) bezogen sind.

9. Das Datenverwaltungsverfahren (1000-1026) gemäß Anspruch 6, das ferner folgenden Schritt aufweist:

(h) Erzeugen (1000) von zusätzlichen Serverprogrammen (1022) zusammenwirkend mit dem Metaschema (1004) und der Objektklassendefinitionseinrichtung (1002, 1008).

10. Das Datenverwaltungsverfahren (1000-1026) gemäß Anspruch 9, bei dem der Serverprogrammerzeugungsschritt (1000) ansprechend auf das Metaschema (1004) ist, um die Struktur von Serverprogrammen (1022), die durch die Serverprogrammerzeugungseinrichtung (1000) erzeugt werden, zu steuern.