Los elementos del esquema meta son clases, propiedades y métodos. El esquema meta también asiste indicaciones y asociaciones como tipos de clases y referencias como tipos de propiedades.
Las clases se pueden ordenar en una jerarquía de generalización que representa relaciones de subtipo entre clases. La jerarquía de generalización es un gráfico en raíz dirigido que no asiste varias herencias.
Una clase regular puede contener propiedades escalaras o de matriz de cualquier tipo intrínseco como booleano, entero, cadena y otros. No puede contener clases incrustadas o referencias a otras clases.
Una asociación es una clase especial que contiene dos o más referencias. Representa un relación entre dos o más objetos. Debido a la forma en la que se definen las asociaciones, es posible establecer una relación entre clases sin que afecte a ninguna de las clases relacionadas. Es decir, la adición de una asociación no afecta a la interfaz de la clase relacionada. Sólo las asociaciones pueden tener referencias.
El fragmento de esquema de la ilustración siguiente muestra las relaciones entre algunos objetos CIM que utiliza ZfD.
En la ilustración se muestra la manera en la que el esquema CIM se asigna a un esquema DBMS relacional. Las clases se muestran con el nombre de clase como el encabezado de recuadro. Las asociaciones están etiquetadas dentro de las líneas entre dos clases.
La jerarquía de herencia de este fragmento de esquema aparece en la siguiente ilustración del esquema de CIM 2.2. Las referencias que aparecen como tipo Ref se encuentran en negrita con cada subtipo de asociación limitando el tipo de referencia.
CIM es un modelo de objeto completo con clases, herencia y polimorfismo. La asignación generada a un esquema relacional conserva estas funciones en la máxima extensión. Los siguientes dos aspectos forman parte de la asignación relacional:
Esquema lógico: el esquema lógico define la forma en la que aparecen los datos en las aplicaciones, de manera similar a una API. El objetivo es que el esquema lógico permanece independientemente de la base de datos subyacente para que se pueda ejecutar el software de la aplicación sin cambiar en cualquier base de datos asistida. Aunque SQL es una norma, este objetivo no es del todo posible. El software de la aplicación tendrá que conocer más acerca de la base de datos que se está utilizando y esta información se puede extraer y aislar en un área pequeña del código de la aplicación.
Esquema físico: el esquema físico define la manera en la que se estructuran los datos en la base de datos. El esquema tiende a ser específico en la base de datos debido a la naturaleza de SQL y RDBMS. En este documento sólo se describen los esquema físicos en términos generales.
Una tabla de la base de datos representa cada clase de la jerarquía CIM.. Una columna del tipo adecuado de la tabla representa cada propiedad no heredada de la clase. Cada tabla también cuenta con una clave primaria, id$, que es un entero de 64 bits que identifica una instancia de manera única. Una instancia de una clase CIM se representa con una flecha en cada tabla que corresponde a una clase de su jerarquía de herencia. Cada fila tiene el mismo valor para id$.
Cada clase CIM también se representa con una vista que utiliza id$ para unir filas desde las distintas tablas de la jerarquía de herencia para producir un conjunto compuesto de propiedades (heredadas más locales) para una instancia de esa clase. La vista también contiene una columna adicional, class$, de tipo entero que representa el tipo de la clase de instancia real (el último nodo de un árbol).
Las asociaciones se asignan de la misma manera que las clases normales, con una propiedad de referencia que se representa con una columna con el campo id$ de la instancia de objeto de la que se hace la referencia. Así pues, las asociaciones se pueden cruzar uniendo el campo de referencia de la asociación y el campo id$ de la tabla de la que se hace referencia.
En la ilustración siguiente se representa una consulta típica mediante esta asignación:
Esta consulta busca todos los computadores conectados a un segmento de red determinado. Las clases y las relaciones implicadas se resaltan con bordes.
Los temas siguientes describen ambos tipos de esquema:
El esquema lógico es el esquema de la base de datos como lo ven los usuarios de la misma y el programa de instalación. El esquema consta de procedimientos y de vistas almacenadas. Las tablas subyacentes no están visibles en la aplicación.
Normalmente, cada clase CIM tiene lo siguiente:
Los componentes de Inventario de ZfD utilizan JDBC* para emitir instrucciones SQL en RDBMS y convertir entre tipos de datos RDBMS y tipos de datos Java*. El uso de JDBC con vistas y procedimientos almacenados proporciona un nivel de abstracción que aísla el código de la aplicación de la tecnología de la base de datos subyacente y de los cambios en el esquema físico.
En las secciones siguientes se tratan los distintos elementos del esquema lógico con mayor detalle:
Se recomienda que utilice los nombres CIM sin cambiar en el esquema de la base de datos. Algunos problemas se pueden producir todavía debido a las diferencias en la denominación de esquemas, como las siguientes:
La mayoría de estos problemas se evitan durante la generación de esquemas conservando el caso de los nombres CIM, abreviando los nombres más largos de 30 caracteres y colocando comillas alrededor de cualquier nombre que se encuentre en la unión de los conjuntos de palabras reservadas.
Cualquier nombre de más de 28 caracteres se abrevia a un nombre raíz de 28 caracteres o menos para permitir un prefijo de dos caracteres con el fin de que todos los elementos del esquema SQL asociados puedan utilizar el mismo nombre raíz. El algoritmo de abreviación acorta un nombre para que sea nemotécnico, reconocible y también único dentro de su ámbito. Al nombre abreviado se le asigna un carácter # como sufijo (tenga en cuenta que # es un carácter no válido en CIM) para evitar conflictos con otros nombres. Si dos o más nombre del mismo ámbito generan la misma abreviación, se añade un dígito adicional para que el nombre sea único. Por ejemplo, AttributeCachingForRegularFilesMin se abrevia como AttCacForRegularFilesMin#.
Todos estos nombre abreviados se escriben en una tabla de nombres de este tipo para que un programa busque el nombre CIM real y recupere el nombre abreviado con el fin de utilizarlo con SQL.
Las vistas son los elementos de esquema que se manipulan con mayor frecuencia por código de aplicación y consultas. Utilizan el mismo nombre que la clase CIM que representan. Por ejemplo, la clase CIM_UnitaryComputerSystem se representa con una vista denominada CIM.UnitaryComputerSystem.
Cuando sea necesario, se crean los nombres para índices y tablas auxiliares concadenando el nombre de la clase y el nombre de la propiedad separados por un carácter $. Estos nombres se abrevian por lo general. Por ejemplo, NetworkAdapter$NetworkAddresses se abrevia como NetAdapter$NetAddresses#. Esto no tiene un impacto adverso en los usuarios de esquema de ZfD.
En SQL, un usuario con el mismo nombre que el esquema es el propietario de cada esquema, por ejemplo, CIM, ManageWise®, ZENworks® y otros.
Además, hay un usuario MW_DBA que dispone de los privilegios y los derechos del administrador de la base de datos a todos los objetos del esquema. La función MW_Reader tiene acceso de sólo lectura a todos los objetos del esquema y la función MW_Updater tiene acceso de lectura-escritura-ejecución a todos los objetos del esquema.
Los programas de la aplicación deberían acceder a la base de datos como MW_Reader o MW_Updater para una base de datos Sybase, MWO_Reader o MWO_Updater para una base de datos Oracle, y MWM_Reader o MWM_Updater para una base de datos MS SQL Server 2000, según sus requisitos.
Los tipos de datos CIM se asignan al tipo de dato más adecuado que proporciona la base de datos. Por lo general, la aplicación Java no necesita el tipo porque utiliza JDBC para acceder a los datos.
Java no asiste de manera local los tipos sin asignar, por lo que debería emplear clases o tipos de enteros del siguiente tamaño para representarlos. Además, asegúrese de que no hay problemas al leer o escribir en la base de datos. Por ejemplo, al leer o escribir un número negativo en un campo sin firmar de la base de datos es probable que se produzca un error.
Las cadenas de CIM y Java son Unicode*, por lo que la base de datos se crea mediante el conjunto de caracteres UTF8. La internacionalización no representa ningún problema. Sin embargo, puede crear problemas con la distinción entre mayúsculas y minúsculas en las consultas.
Todas las bases de datos conservan el caso de los datos de cadena almacenado dentro de las mismas, pero pueden acceder a dichos datos teniendo en cuenta o no las mayúsculas o minúsculas durante las consultas. En ZfD, no se afecta a los componentes Consulta de inventario y Exportación de datos porque los datos consultados se recuperan de la base de datos antes de realizarse la consulta, por lo que se tiene cuidado automáticamente de la distinción entre mayúsculas y minúsculas.
En CIM, se pueden especificar las cadenas con o sin un tamaño máximo de caracteres. Muchas cadenas no tienen ningún tamaño especificado, lo que significa que no se puede limitar su tamaño. Por razones de eficacia, las cadenas sin limitar se asignan a una cadena de variables con un tamaño máximo de 254 caracteres. Las cadenas CIM con un tamaño máximo se asignan a las cadenas de base de datos de variables del mismo tamaño. El tamaño de la base de datos se toma en bytes y no como caracteres porque un carácter Unicode puede requerir más de un byte para el almacenamiento.
Cada clase CIM se representa en la base de datos con una vista que contiene todas las propiedades que no sean de matriz heredadas y locales de esa clase. La vista se denomina de la misma manera que la clase CIM. Por ejemplo, la clase CIM, CIM_System, representa una vista SQL denominada CIM.System, como se muestra en la siguiente ilustración.
La vista CIM.System se crea con atributos seleccionados a partir de varias tablas. Estos atributos incluyen: id$ seleccionado de cim.t$ManagedSystemElement,class$ se llena automáticamente mediante la función mw_dba.extractClass, Inscripción seleccionada de cim.t$ManagedSystemElement, Descripción seleccionada de cim.t$ManagedSystemElement, InstallDate seleccionada de cim.t$ManagedSystemElement, Status seleccionado de cim.t$ManagedSystemElement, CreationClassName seleccionado de cim.t$System, Nombre seleccionado de cim.t$ManagedSystemElement. NameFormat seleccionado de cim.t$System.NameFormat, PrimaryOwnerContact seleccionado de cim.t$System y PrimaryOwnerName seleccionado de cim.t$System. La vista se crea uniendo las tablas CIM.t$ManagedSystemElement y CIM.t$System en las que el id$ de ambas tablas es el mismo.
La vista CIM.SYSTEM es la siguiente:
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$
Además de las propiedades de la clase, la vista tiene los dos campos adicionales siguientes:
Id$: objeto identificador que identifica de manera única la instancia particular de la clase. Consulte Id$ del identificador de objeto .
Class$: campo de enteros que identifica el tipo real de la clase. Por ejemplo, el tipo real de un CIM_System puede ser cualquiera de las subclases concretas de CIM_System.
Se pueden consultar las vistas mediante la instrucción SELECT y actualizar mediante la instrucción UPDATE. Debido a que no se puede utilizar las vistas con las instrucciones INSERT y DELETE, utilice los procedimientos del constructor y del destructor.
Id$ es un objeto de 64 bits que identifica de manera única una instancia particular de una clase. Por ejemplo, una instancia de la clase CIM_Processor. Este identificador de objeto se utiliza generalmente como una referencia poco clara para una instancia concreta. Id$ se modela como un número firmado para facilitar la manipulación en Java como un tipo de dato largo.
Id$ contiene las tres partes siguientes de información, que se pueden extraer cada una de ellas invocando el procedimiento almacenado adecuado.
Este campo se puede extraer mediante la función MW_DBA.extractClass(). Este campo se utiliza para decisiones de tipo o para acceder a la información adicional acerca de la clase de la tabla MW_DBA.Class.
El ID del sitio identifica de manera única la base de datos de un sitio concreto. Este campo hace que el identificador del objeto sea único en 256 sitios para que los datos de inventario de varios sitios se puedan enviar a una base de datos única (Servidor raíz con base de datos) para las consultas e informes sin provocar conflictos de claves. El ID del sitio se puede extraer mediante la función MW_DBA.extractSite().
Esta parte se puede extraer mediante la función MW_DBA.extractId(). Eso no resulta útil desde la perspectiva de un usuario final.
El campo id$ se utiliza por completo como una referencia poco clara para una instancia de una clase. Cuando una clase de asociación representa una relación entre instancias de dos clases, los campos de referencia de la asociación mantienen el id$ de las instancias de las que se hace referencia (como los punteros). Así pues, id$ y estos campos de referencia se utilizan con frecuencia en condiciones de unión cuando se construyen las consultas de bases de datos que hacen referencia a más de una vista.
Cada clase CIM (no abstracta) concreta cuenta con un procedimiento de constructor almacenado que se debe llamar para crear una instancia de la clase. Este procedimiento almacenado tiene parámetros de entrada que permiten al usuario especificar un valor para cada propiedad de la clase y un parámetro de salida único que devuelve el id$ asignado para la instancia creada. La aplicación utiliza este valor id$ devuelto para construir clases de asociación que hacen referencia a esa instancia concreta.
El constructor se denomina añadiendo el prefijo c$ al nombre de la raíz y cada parámetro se denomina añadiendo el prefijo p$ al nombre de propiedad de raíz. Por ejemplo, el constructor para CIM_UnitaryComputerSystem, una subclase de CIM_System, se denomina CIM.c$UnitaryComputerSystem y se construye para Oracle como se muestra en el ejemplo siguiente:
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;
Los procedimientos almacenados se pueden llamar con argumentos de posición o argumentos de palabras clave o con una combinación de los dos. Si se proporcionan argumentos de posición, deben preceder a cualquier argumento de palabra clave. Utilice siempre argumentos de palabra clave cuando llame procedimientos almacenados de constructor. Así se proporciona un mejor aislamiento de cambios del esquema CIM que causan la inserción de parámetros adicionales o del registro de los parámetros existentes, cada uno de los cuales puede interrumpir una llamada de posición de una forma no detectable posible. Los procedimientos generados de este modo como cualquier parámetro omitido serán por defecto nulos.
Se puede utilizar la anotación de posición para el primer parámetro p$id$, que es el parámetro de salida que devuelve el identificador del objeto de la instancia recién creada.
El siguiente ejemplo de código JDBC muestra la manera en la que se llama un procedimiento almacenado mediante la anotación de posición para el primer argumento y anotación de palabra clave para todos los argumentos posteriores en 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 sintaxis para la anotación de la palabra clave es diferente en Sybase ASA, MS SQL 2000 y Oracle. En Sybase ASA y MS SQL 2000, la sintaxis es KEYWORD=valor. En Oracle, la sintaxis es KEYWORD => valor. El código adecuadamente escrito construirá de manera dinámica la cadena de llamada mediante la sintaxis adecuada para la base de datos que se está empleando.
Cada clase CIM no abstracta cuenta con un procedimiento de destructor almacenado que se debe llamar para destruir una instancia de la clase. Este procedimiento almacenado sólo tiene un parámetro de entrada que especifica el identificador (id$) del objeto de la instancia que se va a destruir y no devuelve ningún valor.
El destructor suprime las filas adecuadas de todas las tablas relevantes, incluyendo las filas de la cadena de herencia y las asociaciones que hacen referencia a la instancia que se está destruyendo. Sólo se destruye la asociación, no se destruyen los objetos asociados. Si hay que destruir la asociación, los programadores deben asegurarse de que no se destruyen. El destructor se denomina añadiendo el prefijo d$ al nombre raíz y el parámetro identificador de objeto único se denomina p$id$. Este procedimiento se llama mediante la anotación de posición. Por ejemplo, el destructor para CIM_UnitaryComputerSystem, una subclase concreta de CIM_System, se denomina CIM.d$UnitaryComputerSystem.
El esquema físico consta de elementos necesarios para implementar la base de datos. El esquema físico es diferente en cada base de datos. Un esquema físico típico consta de:
El esquema lógico se coloca encima del esquema físico y lo hace innecesario para que los usuarios y las aplicaciones conozcan el esquema físico.