Les éléments du méta-schéma sont les classes, les propriétés et les méthodes. Celui-ci prend également en charge les indications et les associations comme des types de classes et les références comme des types de propriétés.
Les classes peuvent être organisées selon une hiérarchie de généralisation qui représente des relations de sous-type entre les classes. La hiérarchie de généralisation est un graphique à racines et à direction qui ne prend pas en charge plusieurs héritages.
Une classe normale peut contenir des propriétés scalaires ou matricielles ou de n'importe quel type intrinsèque (booléen, entier, chaîne, et autres). Elle ne peut pas contenir de classes imbriquées ni de références à d'autres classes.
Une association est une classe spéciale qui contient deux ou plusieurs références, et représente une relation entre deux ou plusieurs objets. Étant donné la manière dont les associations sont définies, il est possible d'établir une relation entre les classes sans affecter aucune classe liée. Cela signifie que l'ajout d'une association ne modifie pas l'interface des classes liées. Seules les associations peuvent bénéficier de références.
La partie de schéma de l'illustration suivante montre les relations qui existent entre certains objets CIM utilisés par ZfD.
L'illustration montre comment le schéma CIM est mappé à un schéma SGBD relationnel. Les classes sont indiquées par leur nom dans l'en-tête du cadre. Les associations figurent sur les lignes entre deux classes.
La hiérarchie d'héritage de cet échantillon de schéma est présentée dans l'illustration suivante du schéma CIM 2.2. Les références indiquées comme étant de type Ref apparaissent en gras et chaque sous-type d'association précise le type de référence.
CIM est un modèle d'objet complet et polymorphique qui comprend des classes et un héritage. Le mappage à un schéma relationnel conserve le maximum de ces caractéristiques. Le mappage relationnel inclut les deux aspects suivants :
Schéma logique :Le schéma logique définit la manière dont les données apparaissent pour les applications, tout comme une API. L'objectif est que, quelle que soit la base de données sous-jacente, ce schéma logique ne change pas et que les logiciels d'applications puissent fonctionner sans être modifiés sur n'importe quelle base de données prise en charge. Bien que SQL soit une référence en la matière, la réalisation de cet objectif n'est pas totalement possible. Les logiciels d'applications doivent obtenir plus d'informations sur la base de données utilisée et ces informations peuvent être résumées et isolées dans une petite zone du code de l'application.
Schéma physique : Le schéma physique définit la manière dont les données sont structurées dans la base de données. Ce schéma est le plus souvent spécifique à la base de données étant donné la nature de SQL et du SGBDR. Ce document n'offre qu'une description générale du schéma physique.
Dans la base de données, chaque classe de la hiérarchie CIM est représentée par une table. Dans la table, chaque propriété non héritée de la classe est représentée par une colonne du type approprié. Chaque table possède également une clé primaire, id$, un entier de 64 bits qui identifie de manière unique une instance. Une instance de classe CIM est représentée par une ligne dans chaque table qui correspond à une classe dans sa hiérarchie d'héritage. Chaque ligne possède la même valeur d'id$.
Chaque classe CIM est également représentée par une vue qui utilise id$ pour joindre les lignes de plusieurs tables dans la hiérarchie d'héritage afin d'obtenir un ensemble composite de propriétés (héritées et locales) pour une instance de cette classe. La vue comprend également une colonne supplémentaire (class$) de type entier qui représente le type de la classe actuelle de l'instance (la dernière dans la hiérarchie).
Les associations sont mappées de la même manière que les classes ordinaires, c'est-à-dire qu'une propriété de référence est représentée par une colonne avec le champ id$ de l'instance de l'objet référencé. Par conséquent, les associations peuvent être parcourues en effectuant une jointure entre le champ de référence de l'association et le champ id$ de la table référencée.
L'illustration suivante décrit une requête typique qui utilise ce mappage :
Cette requête trouve tous les ordinateurs connectés à un segment de réseau donné. Les classes et les relations impliquées sont encadrées en rouge.
Les rubriques suivantes décrivent les deux types de schéma :
Il s'agit du schéma de base de données tel qu'il apparaît aux utilisateurs de la base de données et au programme de l'application. Ce schéma se compose de procédures stockées et de vues. Les tables sous-jacentes ne sont pas visibles par l'application.
Généralement, chaque classe CIM comprend les éléments suivants :
Les composants Inventaire de ZfD utilise la connectivité JDBC* pour émettre des instructions SQL vers SGBDR et effectuer la conversion des données entre le type SGBDR et le type Java*. L'utilisation de JDBC avec des procédures stockées et des vues fournit un niveau d'abstraction qui permet d'isoler le code d'application de la technologie de base de données sous-jacente et des modifications apportées au schéma physique.
Les différents éléments du schéma logique sont traités plus en détail dans les sections suivantes :
Nous vous conseillons d'utiliser les noms CIM (sans les modifier) dans le schéma de base de données. Cependant, il est possible que certains problèmes surgissent à cause des différences de modèles d'assignation de nom, par exemple :
La plupart de ces problèmes peuvent être évités si, lors de la création du schéma, la casse des noms CIM est conservée, tous les noms qui comprennent plus de 30 caractères sont abrégés et des guillemets sont placés autour de tous les noms faisant partie des ensembles de mots réservés.
Tout nom supérieur à 28 caractères est abrégé en nom racine de 28 caractères (au maximum) pour permettre l'ajout de préfixes de 2 caractères afin que tous les éléments du schéma SQL associé puissent utiliser le même nom racine. L'algorithme d'abréviation raccourcit un nom de manière à ce qu'il soit mnémonique, reconnaissable et unique dans son domaine. Le nom abrégé reçoit le caractère # comme suffixe (notez que # est un caractère non autorisé dans CIM) afin d'empêcher tout conflit avec d'autres noms. Si plusieurs noms d'un même domaine donnent une même abréviation, un chiffre supplémentaire est ajouté pour rendre le nom unique. Par exemple, AttributeCachingForRegularFilesMin est abrégé en AttCacForRegularFilesMin#.
Tous ces noms tronqués sont écrits dans la table des noms tronqués ; ainsi, un programme peut rechercher le vrai nom CIM et récupérer le nom tronqué pour l'utiliser avec SQL.
Les vues sont les éléments du schéma qui sont le plus souvent manipulés par le code d'application et les requêtes. Elles utilisent le même nom que la classe CIM qu'elles représentent. Par exemple, la classe CIM_UnitaryComputerSystem est représentée par une vue appelée CIM.UnitaryComputerSystem.
En cas de besoin, des noms d'index et de tables auxiliaires sont créés en concaténant le nom de la classe et le nom de la propriété, séparés par un caractère $. Ces noms sont généralement abrégés. Par exemple, NetworkAdapter$NetworkAddresses est abrégé en NetAdapter$NetAddresses#. Cela n'a aucun impact négatif sur les utilisateurs du schéma ZfD.
Dans SQL, un utilisateur portant le même nom que le schéma est le propriétaire de chaque schéma, par exemple, CIM, ManageWise® et ZENworks® notamment.
En outre, il existe un utilisateur MW_DBA qui possède les privilèges d'administrateur de base de données ainsi que les droits sur tous les objets Schéma. Le rôle de MW_Reader dispose d'un accès en lecture seule à tous les objets Schéma et le rôle MW_Updater dispose d'un accès d'exécution de lecture-écriture sur tous les objets Schéma.
Les programmes d'application doivent accéder à la base de données soit en tant que MW_Reader ou MW_Updater pour une base de données Sybase, MWO_Reader ou MWO_Updater pour une base de données Oracle et MWM_Reader ou MWM_Updater pour la base de données MS SQL Server 2000, en fonction de leurs conditions requises.
Les types de données CIM sont mappés au type de données le plus approprié fourni par la base de données. Généralement, l'application Java n'a pas besoin du type car elle utilise JDBC pour accéder aux données.
Comme Java ne prend pas en charge les types non signés en mode natif, vous devez utiliser des types de classes ou d'entiers de la taille suivante pour les représenter. De même, assurez-vous que ni la lecture ni l'écriture dans la base de données ne pose problème. Par exemple, la lecture ou l'écriture d'un nombre négatif dans un champ non signé de la base de données risque de provoquer une erreur.
Les chaînes de CIM et de Java étant de type Unicode*, la base de données est créée à l'aide du jeu de caractères UTF8. L'internationalisation ne pose pas de problème mais des problèmes de sensibilité à la casse dans les requêtes restent possibles.
Toutes les bases de données conservent la casse des chaînes qu'elles contiennent et elles peuvent y accéder par des requêtes en activant la sensibilité à la casse ou non. Dans ZfD, les composants de requête d'inventaire et d'exportation de données ne sont pas affectés car les données interrogées sont récupérées de la base de données avant le lancement de la requête et donc, la sensibilité à la casse est automatiquement prise en compte.
Dans CIM, les chaînes peuvent être spécifiées avec ou sans nombre de caractères maximum. Ne comportant pas de spécification de taille, beaucoup de chaînes peuvent être illimitées. Pour des raisons d'efficacité, ces chaînes illimitées sont mappées à une chaîne variable de 254 caractères au maximum. Les chaînes CIM dont la taille est maximale sont mappées à des chaînes de base de données de variables de même taille. La taille dans la base de données est exprimée en octets et non en caractères car un caractère Unicode peut représenter plusieurs octets lors du stockage.
Chaque classe CIM est représentée dans la base de données par une vue qui contient toutes les propriétés locales et héritées non matricielles de cette classe. Une vue porte le nom de la classe CIM à laquelle elle correspond. Par exemple, la classe CIM CIM_System représente une vue SQL appelée CIM.System, comme illustré ci-dessous.
La vue CIM.System est créée à l'aide d'attributs sélectionnés dans plusieurs tables. Ces attributs sont les suivants : id$ choisi dans cim.t$ManagedSystemElement, class$ est automatiquement complété grâce à la fonction mw_dba.extractClass, Caption choisi dans cim.t$ManagedSystemElement, Description choisi dans cim.t$ManagedSystemElement, InstallDate choisi dans cim.t$ManagedSystemElement, Status choisi dans cim.t$ManagedSystemElement, CreationClassName choisi dans cim.t$System, Name choisi dans cim.t$ManagedSystemElement. NameFormat sélectionné dans cim.t$System.NameFormat, PrimaryOwnerContact sélectionné dans cim.t$System et PrimaryOwnerName sélectionné dans cim.t$System. Cette vue est créée en joignant les tables CIM.t$ManagedSystemElement et CIM.t$System, où l'id$ des deux tables est le même.
Voici en quoi consiste la vue CIM.SYSTEM :
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$
En plus des propriétés de la classe, la vue comprend les deux champs suivants :
Id$ : Un identificateur d'objet qui identifie de manière unique l'instance particulière de la classe. Voir Identificateur d'objet Id$ .
Class$ : Un champ entier qui identifie le type réel de la classe. Par exemple, le type réel de CIM_System peut être l'une des sous-classes concrètes de CIM_System.
Il est possible d'effectuer des requêtes sur les vues à l'aide de l'instruction SELECT et de les mettre à jour à l'aide de l'instruction UPDATE. Étant donné que les vues ne peuvent pas être utilisées avec les instructions INSERT et DELETE, utilisez les procédures de construction et de destruction.
Id$ est un identificateur d'objet de 64 bits qui identifie de manière unique une instance particulière d'une classe. Par exemple, une instance de la classe CIM_Processor. Cet identificateur d'objet fonctionne généralement comme un identificateur opaque pour une instance particulière. Id$ a été conçu comme un nombre signé pour faciliter sa manipulation dans Java comme type de données long.
Il comprend les trois informations suivantes, qui peuvent toutes être récupérées en invoquant la procédure stockée appropriée.
Ce champ peut être extrait à l'aide de la fonction MW_DBA.extractClass(). Il est utilisé pour les décisions de type ou pour accéder à d'autres informations relatives à la classe à partir de la table MW_DBA.Class.
Cet ID identifie de manière unique la base de données à un endroit particulier. Ce champ rend l'identificateur d'objet unique dans 256 sites (au maximum) ; les données d'inventaire en provenance de plusieurs sites peuvent ainsi être transférées en amont vers une seule base de données (Serveur racine avec base de données) pour y effectuer des requêtes et établir des rapports sans provoquer de conflits de clés. Cet ID de site peut être extrait à l'aide de la fonction MW_DBA.extractSite().
Cet ID peut être extrait à l'aide de la fonction MW_DBA.extractId(). Cette donnée n'est pas très utile pour un utilisateur final.
Le champ id$ est utilisé comme identificateur opaque pour une instance de classe. Lorsqu'une classe d'association représente une relation entre des instances de deux classes, les champs de référence de l'association conservent l'id$ des instances référencées (comme les pointeurs). Par conséquent, l'id$ et ces champs de référence sont souvent utilisés dans des conditions de jointure lors de la création de requêtes de base de données qui référencent plusieurs vues.
Chaque classe CIM concrète (non abstraite) possède une procédure stockée de construction qui doit être appelée pour créer une instance de la classe. Cette procédure stockée possède des paramètres d'entrée qui permettent à l'utilisateur de préciser une valeur pour chaque propriété de la classe, et un seul paramètre de sortie qui renvoie l'id$ alloué à l'instance créée. L'application utilise la valeur de l'id$ renvoyée pour construire des classes d'association qui référence cette instance particulière.
Pour assigner un nom à la procédure de construction, il suffit de rajouter le préfixe c$ au nom racine ; pour les paramètres, il suffit de rajouter le préfixe p$ au nom de la propriété racine. Par exemple, la procédure de construction de CIM_UnitaryComputerSystem, une sous-classe de CIM_System, s'appelle CIM.c$UnitaryComputerSystem et est construite pour Oracle de la manière décrite dans l'exemple suivant :
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;
Les procédures stockées peuvent être appelées à l'aide d'arguments de position ou d'arguments de mot clé, ou encore à l'aide d'une combinaison des deux. Si vous indiquez des arguments de position, faites-les précéder les arguments de mot clé. Utilisez toujours des arguments de mot clé dans les appels de procédures stockées de construction. Ceci assure une meilleure protection contre les modifications du schéma CIM qui peuvent provoquer soit l'insertion de paramètres supplémentaires, soit l'enregistrement de paramètres existants, tous deux pouvant casser un appel de position de manière indétectable. Les procédures sont générées de façon que tout paramètre omis prenne par défaut la valeur NULL.
Il est possible d'utiliser la notation de position pour le premier paramètre p$id$, qui correspond au paramètre de sortie qui renvoie l'identificateur d'objet de la nouvelle instance créée.
L'exemple de code JDBC suivant illustre comment appeler une procédure stockée à l'aide de la notation de position pour le premier argument et la notation de mot clé pour les arguments suivants dans Sybase.
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 );
La syntaxe de la notation par mot clé est différente dans Sybase ASA, MQ SQL 2000 et Oracle. Dans Sybase ASA et MQ SQL 2000, la syntaxe est KEYWORD=valeur. Dans Oracle, la syntaxe est KEYWORD => valeur. Un code correctement écrit permet de dynamiser la construction de la chaîne d'appel à l'aide d'une syntaxe appropriée à la base de données utilisée.
Chaque classe CIM abstraite possède une procédure stockée de destruction qui est appelée pour détruire une instance de la classe. Cette procédure stockée ne comprend qu'un paramètre d'entrée qui précise l'identificateur d'objet (id$) de l'instance à détruire et elle ne renvoie pas de valeur.
Elle supprime les lignes appropriées dans les tables concernées, y compris les lignes de la chaîne d'héritage et toute association qui fait référence à l'instance qui est détruite. L'association est détruite mais les objets associés, eux, ne sont pas détruits. S'il faut détruire l'association, les programmeurs doivent s'assurer que les objets ne sont pas détruits. Pour assigner un nom à la procédure de destruction, il faut ajouter le préfixe d$ au nom racine et nommer le paramètre d'identification d'objet p$id$. Cette procédure est appelée à l'aide de la notation par position. Par exemple, la procédure de destruction de CIM_UnitaryComputerSystem, une sous-classe concrète de CIM_System, s'appelle CIM.d$UnitaryComputerSystem.
Le schéma physique comprend les éléments nécessaires à l'implémentation de la base de données. Il diffère selon chaque base de données. Un schéma physique standard comprend les éléments suivants :
Comme le schéma logique se place au-dessus du schéma physique, il n'est pas nécessaire aux utilisateurs ni aux applications de connaître le schéma physique.