Die Elemente des Meta-Schemas sind Klassen, Eigenschaften und Methoden. Das Meta-Schema unterstützt außerdem Bezeichnungen und Verknüpfungen als Klassentypen und Verweise als Eigenschaftstypen.
Klassen können in einer Verallgemeinerungshierarchie angeordnet werden, die Teiltypbeziehungen zwischen Klassen darstellt. Die Verallgemeinerungshierarchie ist ein zielgerichtetes Diagramm auf Stammbasis, das keine Mehrfachvererbung unterstützt.
Eine reguläre Klasse enthält möglicherweise Skalar- oder Array-Eigenschaften eines beliebigen spezifischen Typs, beispielsweise "Boolean", "Integer" und "String". Sie kann keine eingebetteten Klassen oder Verweise auf andere Klassen enthalten.
Eine Verknüpfung ist eine spezielle Klasse, die mehrere Verweise enthält. Sie stellt eine Beziehung zwischen mehreren Objekten dar. Aufgrund der Art der Definition von Verknüpfungen kann eine Beziehung zwischen Klassen eingerichtet werden, ohne dass eine der verwandten Klassen davon betroffen ist. Dies bedeutet, dass eine zusätzliche Verknüpfung die Schnittstelle der verwandten Klassen nicht betrifft. Nur Verknüpfungen können Verweise haben.
Das Schemafragment in folgender Abbildung zeigt die Beziehungen zwischen einigen CIM-Objekten, die von ZfD verwendet werden.
Die Abbildung veranschaulicht, wie das CIM-Schema einem relationalen DBMS-Schema zugeordnet wird. Die Klassen werden mit dem Klassennamen als Feldüberschrift angezeigt. Die Verknüpfungen werden innerhalb der Linien zwischen zwei Klassen beschrieben.
Die Vererbungshierarchie dieses Schemafragments wird in folgender Abbildung des CIM 2.2-Schemas dargestellt. Die Verweise vom Typ "Ref" sind fett ausgezeichnet. Jeder Teiltyp einer Verknüpfung schränkt dabei den Typ des Verweises ein.
CIM ist ein Objektmodell mit Klassen, Vererbung und Polymorphismus. Die erzeugte Zuordnung zu einem relationalen Schema behält diese Funktionen in vollem Umfang bei. Die folgenden zwei Aspekte sind Bestandteil der relationalen Zuordnung:
Logisches Schema:Das logische Schema definiert, wie die Daten zu Anwendungen (vergleichbar mit einer API) angezeigt werden. Das Ziel ist, dass das logische Schema ungeachtet der zugrunde liegenden Datenbank das gleiche bleibt, damit die Anwendungssoftware unverändert auf jeder unterstützten Datenbank ausgeführt werden kann. Obwohl SQL der Standard ist, kann dieses Ziel nicht vollständig erreicht werden. Der Anwendungssoftware müssen weitere Informationen zur verwendeten Datenbank vorliegen. Diese Informationen können abstrahiert und in einem kleinen Bereich des Anwendungscode isoliert werden.
Physikalisches Schema: Das physikalische Schema definiert, wie die Daten in der Datenbank strukturiert werden. Das Schema ist wegen der Struktur von SQL und RDBMS spezifisch für eine Datenbank. In diesem Dokument wird das physikalische Schema nur allgemein beschrieben.
Eine Tabelle in der Datenbank stellt jede Klasse in der CIM-Hierarchie dar. Eine Spalte des entsprechenden Typs in der Tabelle stellt jede nicht vererbte Eigenschaft in der Klasse dar. Jede Tabelle hat außerdem einen Primärschlüssel, "id$". Hierbei handelt es sich um eine 64-Bit-Ganzzahl, die eine Instanz eindeutig bezeichnet. Eine Instanz einer CIM-Klasse wird durch eine Zeile in jeder Tabelle dargestellt, die einer Klasse in der jeweiligen Vererbungshierarchie entspricht. Jede Zeile hat den gleichen Wert für "id$".
Jede CIM-Klasse wird außerdem durch eine Ansicht dargestellt, die "id$" verwendet, um Zeilen aus den verschiedenen Tabellen in der Vererbungshierarchie miteinander zu verbinden. So ergibt sich eine Zusammensetzung der Eigenschaften (vererbte und lokale) für eine Instanz dieser Klasse. Die Ansicht enthält außerdem eine zusätzliche Spalte, "class$" vom Typ Integer, die den Typ der tatsächlichen Klasse (ohne übergeordnete Elemente) der Instanz darstellt.
Verknüpfungen werden auf die gleiche Art und Weise zugeordnet wie reguläre Klassen, und zwar mit einer Verweiseigenschaft, die von einer Spalte mit dem Feld "id$" der referenzierten Objektinstanz dargestellt wird. Somit können Verknüpfungen verbunden werden, indem eine Verbindung zwischen dem Verweisfeld in der Verknüpfung und dem Feld "id$" in der referenzierten Tabelle erstellt wird.
Folgende Abbildung veranschaulicht eine standardmäßige Abfrage mit dieser Zuordnung:
Diese Abfrage ermittelt alle Computer, die mit einem vorgegebenen Netzwerksegment verbunden sind. Die betreffenden Klassen und Beziehungen werden durch Rahmen hervorgehoben.
Folgende Themen beschreiben die beiden Schematypen:
Das logische Schema ist das Datenbankschema, das von den Benutzern der Datenbank und dem Anwendungsprogramm angezeigt werden kann. Das Schema besteht aus gespeicherten Prozeduren und Ansichten. Die zugrunde liegenden Tabellen können von der Anwendung nicht angezeigt werden.
In der Regel verfügt jede CIM-Klasse über folgende Elemente:
ZfD-Inventarkomponenten verwenden JDBC*, um SQL-Anweisungen in den RDBMS auszuführen und RDBMS-Datentypen in Java*-Datentypen umzuwandeln (und umgekehrt). Die Verwendung von JDBC mit gespeicherten Prozeduren und Ansichten bietet eine Abstraktionsebene, die den Anwendungscode von der zugrunde liegenden Datenbank-Technologie sowie Änderungen des physikalischen Schemas isoliert.
Die verschiedenen Elemente des logischen Schemas werden in folgenden Abschnitten detailliert behandelt:
Es wird empfohlen, die unveränderten CIM-Namen im Datenbankschema zu verwenden. Es können möglicherweise weiterhin einige Probleme auftreten, da es bei den Benennungsschemas Unterschiede gibt. Es folgen einige Beispiele:
Die meisten dieser Probleme werden während der Schema-Erstellung folgendermaßen vermieden: Die Groß-/Kleinschreibung von CIM-Namen wird beibehalten, Namen mit mehr als 30 Zeichen werden abgekürzt und alle Namen, die ein Teil der reservierten Wortgruppen sind, werden in Anführungszeichen (" ") eingeschlossen.
Jeder Name mit mehr als 28 Zeichen wird auf einen Stammnamen von höchstens 28 Zeichen abgekürzt, um ein Präfix von zwei Zeichen zuzulassen. Auf diese Weise können alle verknüpften SQL-Schema-Elemente den gleichen Stammnamen verwenden. Der Abkürzungsalgorithmus verkürzt einen Namen, damit dieser mnemonisch, erkennbar und außerdem innerhalb des Bereichs eindeutig ist. Der abgekürzte Name erhält das "#"-Zeichen als Suffix, um Konflikte mit anderen Namen zu vermeiden. Beachten Sie aber, dass das "#"-Zeichen in CIM nicht zulässig ist. Wenn bei mehreren Namen innerhalb des gleichen Bereichs die gleiche Abkürzung entsteht, wird eine zusätzliche Stelle angehängt, damit der Name eindeutig wird. Beispiel: AttributeCachingForRegularFilesMin wird abgekürzt auf AttCacForRegularFilesMin#.
Alle abgekürzten Namen werden in die Tabelle der abgekürzten Namen geschrieben, damit ein Programm den echten CIM-Namen ermitteln und den abgekürzten Namen abrufen kann, der mit SQL verwendet wird.
Ansichten sind die Schema-Elemente, die am häufigsten durch Anwendungscode und Abfragen beeinflusst werden. Sie verwenden den gleichen Namen wie die CIM-Klasse, die sie darstellen. Die Klasse CIM_UnitaryComputerSystem wird beispielsweise durch eine Ansicht namens CIM.UnitaryComputerSystem dargestellt.
Gegebenenfalls werden Namen für Indizes und Hilfstabellen erstellt, indem der Klassenname und der Eigenschaftsname getrennt durch ein "$"-Zeichen verknüpft werden. Diese Namen werden in der Regel abgekürzt. NetworkAdapter$NetworkAddresses wird beispielsweise abgekürzt auf NetAdapter$NetAddresses#. Dies wirkt sich nicht nachteilig auf Benutzer des ZfD-Schemas aus.
In SQL ist ein Benutzer mit dem gleichen Namen wie das Schema der Eigentümer des jeweiligen Schemas, beispielsweise CIM, ManageWise® und ZENworks®.
Außerdem gibt es einen MW_DBA-Benutzer, der Datenbank-Verwalterrechte für alle Schema-Objekte hat. Die Funktion MW_Reader hat Nur-Lese-Zugriff auf alle Schema-Objekte und die Funktion MW_Updater hat Lese-/Schreib-Zugriff auf alle Schema-Objekte.
Anwendungsprogramme sollten (abhängig von den jeweiligen Anforderungen) folgendermaßen auf die Datenbank zugreifen: als MW_Reader oder MW_Updater für eine Sybase-Datenbank, als MWO_Reader oder MWO_Updater für eine Oracle-Datenbank und als MWM_Reader oder MWM_Updater für eine Datenbank auf MS SQL Server 2000.
CIM-Datentypen werden dem geeignetsten Datentyp zugeordnet, der in der Datenbank enthalten ist. In der Regel erfordert die Java-Anwendung den Typ nicht, da sie JDBC für den Zugriff auf die Daten verwendet.
Java unterstützt keine nicht signierten Typen. Sie sollten also Klassen oder Ganzzahlen der nächsten Größe verwenden, um sie darzustellen. Stellen Sie außerdem sicher, dass beim Lesen oder Schreiben in der Datenbank keine Probleme auftreten. Das Lesen oder Schreiben einer negativen Zahl in einem nicht signierten Feld in der Datenbank kann beispielsweise einen Fehler verursachen.
Zeichenketten in CIM und Java sind Unicode*, demnach wird die Datenbank mit dem UTF8-Zeichensatz erstellt. Durch die Globalisierung treten keine Probleme auf. Dennoch können in Abfragen Probleme mit der Groß-/Kleinschreibung entstehen.
Alle Datenbanken behalten die gespeicherte Schreibweise der Zeichenketten bei. Beim Zugriff auf die Daten während Abfragen wird aber möglicherweise die Groß-/Kleinschreibung nicht beachtet. In ZfD sind die Komponenten der Inventarabfrage und des Datenexports nicht betroffen, da die abgefragten Daten aus der Datenbank abgerufen werden, bevor sie abgefragt werden, und so automatisch die Groß-/Kleinschreibung beachtet wird.
In CIM werden Zeichenketten möglicherweise mit oder ohne eine maximale Zeichengröße angegeben. Viele Zeichenketten haben keine angegebene Größe, das bedeutet, dass die Größe unbegrenzt sein kann. Aus Gründen der Effizienz werden diese unbegrenzten Zeichenketten einer variablen Zeichenkette mit einer Maximalgröße von 254 Zeichen zugeordnet. CIM-Zeichenketten mit einer Maximalgröße werden variablen Datenbank-Zeichenketten der gleichen Größe zugeordnet. Die Größe in der Datenbank wird in Byte und nicht als Zeichen angegeben, da ein Unicode-Zeichen für das Speichern möglicherweise mehr als ein Byte benötigt.
Jede CIM-Klasse wird in der Datenbank durch eine Ansicht dargestellt, die alle lokalen und vererbten Non-Array-Eigenschaften dieser Klasse enthält. Diese Ansicht erhält die gleiche Bezeichnung wie die CIM-Klasse. Die CIM-Klasse CIM_System stellt beispielsweise eine SQL-Ansicht mit der Bezeichnung CIM.System dar, wie die folgende Abbildung veranschaulicht.
Die Ansicht "CIM.System" wird mit Attributen erstellt, die aus mehreren Tabellen ausgewählt wurden. Zu diesen Attributen gehören: "id$", ausgewählt aus cim.t$ManagedSystemElement,class$, (dieses Attribut wird mit der Funktion mw_dba.extractClass automatisch ausgefüllt), "Caption", ausgewählt aus cim.t$ManagedSystemElement, "Description", ausgewählt aus cim.t$ManagedSystemElement, "InstallDate", ausgewählt aus cim.t$ManagedSystemElement, "Status", ausgewählt aus cim.t$ManagedSystemElement, "CreationClassName", ausgewählt aus cim.t$System, "Name", ausgewählt aus cim.t$ManagedSystemElement. "NameFormat" ausgewählt aus cim.t$System.NameFormat, "PrimaryOwnerContact" ausgewählt aus cim.t$System und "PrimaryOwnerName" ausgewählt aus cim.t$System. Die Ansicht wird erstellt, indem die Tabellen CIM.t$ManagedSystemElement und CIM.t$System zusammen geführt werden, in denen der Wert "id$" identisch ist.
Im Folgenden wird die Ansicht "CIM.SYSTEM" dargestellt:
CREATE VIEW CIM.System
{
id$,
class$,
Caption,
Description,
InstallDate,
Status,
CreationClassName,
Name,
NameFormat,
PrimaryOwnwerContact,
PrimaryOwnerName
}
AS SELECT
CIM.t$ManagedSystemElement.id$
MW_DBA.extractClass(CIM.t$ManagedSystemElement.id$),
CIM.t$ManagedSystemElement.Caption,
CIM.t$ManagedSystemElement.Description,
CIM.t$ManagedSystemElement.InstallDate,
CIM.t$ManagedSystemElement.Status,
CIM.t$System.CreationClassName,
CIM.t$ManagedSystemElement.Name,
CIM.t$System.NameFormat,
CIM.t$System.PrimaryOwnerContact,
CIM.t$System.PrimaryOwnerName
FROM
CIM.t$ManagedSystemElement,
CIM.t$System
WHERE
CIM.t$ManagedSystemElement.id$ = CIM.t$System.id$
Zusätzlich zu den Eigenschaften der Klasse verfügt die Ansicht über die zwei folgenden Felder:
Id$: Eine Objektkennung, die die bestimmte Instanz der Klasse eindeutig bezeichnet. Weitere Informationen hierzu finden Sie unter Objektkennung "Id$" .
Class$: Ein Feld mit einer Ganzzahl, die den tatsächlichen Typ der Klasse bezeichnet. Der tatsächliche Typ von einem CIM_System kann beispielsweise jede konkrete Unterklasse im CIM_System sein.
Ansichten können mit einer SELECT-Anweisung abgefragt und mit einer UPDATE-Anweisung aktualisiert werden. Da Ansichten nicht mit den INSERT- und DELETE-Anweisungen verwendet werden können, verwenden Sie die Konstruktor- und Destruktor-Prozeduren.
"Id$" ist eine 64-Bit-Objektkennung, die eine bestimmte Instanz einer Klasse eindeutig bezeichnet, beispielsweise eine Instanz der Klasse "CIM_Processor". Diese Objektkennung wird in der Regel als Zugriffsnummer zu einer bestimmten Instanz verwendet. "Id$" ist als signierte Nummer für ein einfaches Verfahren in Java als Datentyp "Long" konzipiert.
"Id$" enthält die folgenden drei Informationsbestandteile, die extrahiert werden können, indem die entsprechende gespeicherte Prozedur aufgerufen wird.
Dieses Feld kann mit der Funktion MW_DBA.extractClass() extrahiert werden. Dieses Feld wird für Typentscheidungen oder den Zugriff auf weitere Informationen zur Klasse aus der Tabelle MW_DBA.Class verwendet.
Die Standort-ID bezeichnet die Datenbank eindeutig an einem bestimmten Standort. Dadurch wird die Objektkennung für bis zu 256 Standorte eindeutig, sodass bei Inventardaten von mehreren Standorten ein Roll-up in eine einzelne Datenbank (Stammserver mit Datenbank) für Abfrage und Bericht durchgeführt werden kann, ohne Schlüsselkonflikte zu verursachen. Die Standort-ID kann mit der Funktion MW_DBA.extractSite() extrahiert werden.
Dieser Teil kann mit der Funktion MW_DBA.extractId() extrahiert werden. Aus der Sicht eines Endbenutzers ist dies nicht sinnvoll.
Das Feld "id$" wird als Ganzes als Zugriffsnummer zu einer Instanz einer Klasse verwendet. Wenn eine Verknüpfungsklasse eine Beziehung zwischen Instanzen von zwei Klassen darstellt, enthalten die Verweisfelder der Verknüpfung den Wert "id$" der referenzierten Instanzen (wie die Zeiger). Deshalb werden "id$" und diese Verweisfelder häufig in Join-Bedingungen beim Erstellen von Datenbankabfragen verwendet, die mehrere Ansichten referenzieren.
Jede konkrete (nicht abstrakte) CIM-Klasse hat eine im Konstruktor gespeicherte Prozedur, die aufgerufen werden muss, um eine Instanz der Klasse zu erstellen. Diese gespeicherte Prozedur verfügt über Eingabeparameter, die dem Benutzer ermöglichen, einen Wert für jede Eigenschaft in der Klasse anzugeben, sowie einen Ausgabeparameter, der den Wert "id$" zurückgibt, welcher der erstellten Instanz zugeteilt wurde. Die Anwendung verwendet diesen zurückgegebenen Wert "id$", um Verknüpfungsklassen zu erstellen, die diese bestimmte Instanz referenzieren.
Der Konstruktor wird bezeichnet, indem das Präfix "c$" dem Stammnamen hinzugefügt wird. Jeder Parameter wird bezeichnet, indem das Präfix "p$" dem Stammeigenschaftsnamen hinzugefügt wird. Beispiel: Der Konstruktor für CIM_UnitaryComputerSystem, eine Unterklasse von CIM_System, wird CIM.c$UnitaryComputerSystem benannt und für Oracle entsprechend dem folgenden Beispiel erstellt:
CREATE PROCEDURE CIM.c$UnitaryComputerSystem
(
p$id$ OUT NUMBER,
p$Caption IN CIM.t$ManagedSystemElement.Caption%TYPE DEFAULT NULL,
p$Description IN CIM.t$ManagedSystemDescription%TYPE DEFAULT NULL,
p$InstallDate IN CIM.t$ManagedSystemElement.InstallDate%TYPE DEFAULT NULL,
p$Status IN CIM.t$ManagedSystemElement.Status%TYPE DEFAULT NULL,
p$CreationClassName IN CIM.t$System.CreationClassName%TYPE DEFAULT NULL,
p$Name IN CIM.t$ManagedSystemElement.Name%TYPE DEFAULT NULL,
p$PrimaryOwnerContact IN CIM.t$System.PrimaryOwnerContact%TYPE DEFAULT NULL,
p$PrimaryOwnerName IN CIM.t$System.PrimaryOwnerName%TYPE DEFAULT NULL,
p$NameFormat IN CIM.t$System.NameFormat%TYPE DEFAULT NULL,
p$LastLoadInfo IN CIM.t$UnitaryComputerSystem.LastLoadInfo%TYPE DEFAULT NULL,
p$ResetCapability IN CIM.t$UnitaryComputerSystem.ResetCapability%TYPE DEFAULT NULL,
p$PowerManagementSupported IN CIM.t$UnitaryComputerSystem.PowerManagementSupported%TYPE DEFAULT NULL,
p$PowerState IN CIM.t$UnitaryComputerSystem.PowerState%TYPE DEFAULT NULL
)IS
temp NUMBER;
BEGIN
LOOP
SELECT CIM.s$UnitaryComputerSystem.NEXTVAL INTO temp FROM DUAL;
SELECT MW_DBA.makeId(240, temp) INTO temp FROM DUAL;
EXIT WHEN MOD(temp,100) != 0;
END LOOP;
p$id$ := temp;
INSERT INTO CIM.t$ManagedSystemElement (id$, classOid$, Caption, Description, InstallDate, Status, Name)VALUES(p$id$, HEXTORAW('0302100203'), p$Caption, p$Description, p$InstallDate, p$Status, p$Name);
INSERT INTO CIM.t$System (id$, CreationClassName, PrimaryOwnerContact, PrimaryOwnerName, NameFormat)VALUES(p$id$, p$CreationClassName, p$PrimaryOwnerContact, p$PrimaryOwnerName, p$NameFormat);
INSERT INTO CIM.t$UnitaryComputerSystem (id$, LastLoadInfo, ResetCapability, PowerManagementSupported, PowerState) VALUES(p$id$, p$LastLoadInfo, p$ResetCapability, p$PowerManagementSupported, p$PowerState);
END;
Gespeicherte Prozeduren können entweder mit Positionsargumenten oder Schlüsselwortargumenten bezeichnet werden (oder mit einer Kombination der beiden). Wenn Positionsargumente verwendet werden, müssen sie Vorrang vor Schlüsselwortargumenten haben. Verwenden Sie immer Schlüsselwortargumente, wenn Sie Prozeduren aufrufen, die im Konstruktor gespeichert sind. Dadurch wird eine bessere Isolierung von CIM-Schema-Änderungen gewährleistet, die das Einfügen von zusätzlichen Parametern oder das Aufzeichnen von vorhandenen Parametern bewirken, wobei jeder Parameter einen Positionsaufruf unterbrechen kann, ohne dass die Ursache erkannt wird. Die Prozeduren werden so erzeugt, dass alle ausgelassenen Parameter standardmäßig auf "NULL" gesetzt werden.
Die Positionsnotation kann für den ersten Parameter "p$id$" verwendet werden. Hierbei handelt es sich um den Ausgabeparameter, der die Objektkennung der neu erstellten Instanz zurückgibt.
Das folgende Beispiel für einen JDBC-Code zeigt, wie eine gespeicherte Prozedur mit Positionsnotation für das erste Argument und Schlüsselwortnotation für alle späteren Argumente auf Sybase aufgerufen werden sollen.
CallableStatement CS =
conn.prepareCall( "{call CIM.c$UnitaryComputerSystem( ?, p$Name=?, p$Description=?)}" )
cs.registerOutParameter ( 1, java.sql.Types.BIGINT ); //id$
cs.setString( 2, "Bogus_UCS_1") ; //Name
cs.setString( 3, "Created with mixture of positional & keyword args" ); // Description
cs.executeUpdate();
long id = cs.getLong ( 1 );
SQLWarning w = cs.getWarnings();
if( w != null )
printWarnings( w );
else
System.out.println("Created UCS id$ = " + id );
Die Syntax für Schlüsselwortnotation ist in Sybase ASA, MS SQL 2000 und Oracle unterschiedlich. In Sybase ASA und MS SQL 2000 ist die Syntax KEYWORD=Wert. In Oracle ist die Syntax KEYWORD => Wert. Ein korrekt angegebener Code erstellt die Aufrufzeichenkette dynamisch mit der entsprechenden Syntax für die verwendete Datenbank.
Jede nicht abstrakte CIM-Klasse hat eine im Destruktor gespeicherte Prozedur, die aufgerufen wird, um eine Instanz der Klasse zu eliminieren. Diese gespeicherte Prozedur hat nur einen Eingabeparameter, der die Objekt-ID (id$) der Instanz angibt, die eliminiert werden soll, und keinen Wert zurückgibt.
Der Destruktor löscht die entsprechenden Zeilen aus allen relevanten Tabellen, einschließlich der Zeilen in der Vererbungskette. Außerdem werden alle Verknüpfungen gelöscht, die auf die zu eliminierende Instanz verweisen. Es wird nur die Verknüpfung eliminiert, jedoch kein verknüpftes Objekt. Wenn die Verknüpfung eliminiert werden soll, müssen die Programmierer sicherstellen, dass die Objekte nicht eliminiert werden. Der Destruktor wird bezeichnet, indem der Stammname das Präfix "d$" erhält und der einzelne Parameter für die Objekt-ID mit "p$id$" bezeichnet wird. Diese Prozedur wird über eine Positionsnotation aufgerufen. Der Destruktor für CIM_UnitaryComputerSystem beispielsweise, eine konkrete Unterklasse von CIM_System, wird als CIM.d$UnitaryComputerSystem bezeichnet.
Das physikalische Schema umfasst Elemente, die für das Implementieren der Datenbank benötigt werden. Das physikalische Schema ist bei jeder Datenbank unterschiedlich. Ein repräsentatives physikalisches Schema besteht aus:
Das logische Schema befindet sich in der obersten Ebene des physikalischen Schemas. Benutzer und Anwendungen müssen das physikalische Schema nicht kennen.