The elements of the meta schema are classes, properties, and methods. The meta schema also supports indications and associations as types of classes and references as types of properties.
Classes can be arranged in a generalization hierarchy that represents subtype relationships between classes. The generalization hierarchy is a rooted, directed graph that does not support multiple inheritance.
A regular class may contain scalar or array properties of any intrinsic type such as Boolean, integer, string, and others. It cannot contain embedded classes or references to other classes.
An association is a special class that contains two or more references. It represents a relationship between two or more objects. Because of the way associations are defined, it is possible to establish a relationship between classes without affecting any of the related classes. That is, addition of an association does not affect the interface of the related classes. Only associations can have references. The schema fragment in the following illustration shows the relationships between some CIM objects that ZfS uses.
The illustration shows how the CIM schema maps to a relational DBMS schema. The classes are shown with the class name as the box heading. The associations are labeled within the lines between two classes.
The inheritance hierarchy of this schema fragment is shown in the following illustration of the CIM 2.2 schema. The references shown as type Ref are in bold with each association sub-type narrowing the type of the reference.
CIM is an object model complete with classes, inheritance, and polymorphism. The generated mapping to a relational schema preserves these features to the maximum extent. The following two aspects are part of the relational mapping:
Logical Schema: The logical schema defines how the data appears to applications, similar to an API. The goal is that the logical schema remains the same irrespective of the underlying database so that application software can run unchanged on any supported databases. Though SQL (pronounced as sequel) is a standard, this goal is not fully possible. Application software will need to know more about the database in use and this information can be abstracted and isolated to a small area of the application code.
Physical Schema: The physical schema defines how the data is structured in the database. The schema tends to be specific to the database because of the nature of SQL and RDBMS. This document will describe the physical schema in general terms only.
A table in the database represents each class in the CIM hierarchy. A column of the appropriate type in the table represents each non-inherited property in the class. Each table also has a primary key, id$, which is a 64-bit integer that uniquely identifies an instance. An instance of a CIM class is represented by a row in each table that corresponds to a class in its inheritance hierarchy. Each row has the same value for id$.
Each CIM class is also represented by a view that uses id$ to join rows from the various tables in the inheritance hierarchy to yield a composite set of properties (inherited plus local) for an instance of that class. The view also contains an extra column, class$, of type integer that represents the type of the actual (leaf-most) class of the instance.
Associations are mapped in the same manner as regular classes, with a reference property being represented by a column with the id$ field of the referenced object instance. Thus, associations can be traversed by doing a join between the reference field in the association and the id$ field in the referenced table.
The following illustration depicts a typical query using this mapping:
This query finds all the computers attached to a given network segment. The classes and relationships involved are highlighted with borders.
The following topics describe both the schema types:
The logical schema is the database schema as seen by users of the database and the application program. The schema consists of stored procedures and views. The underlying tables are not visible to the application.
Typically, each CIM class has the following:
ZfS Inventory components use JDBC to issue SQL statements to the RDBMS and to convert between RDBMS data types and Java* data types. The use of JDBC with stored procedures and views provides a level of abstraction that insulates application code from the underlying database technology and from changes to the physical schema.
The various elements of the logical schema are discussed in more detail in the following sections:
We recommend that you use the CIM names unchanged in the database schema. Some problems may still ensue because of the differences in the naming schemes, such as the following:
Most of these problems are avoided during schema generation by preserving the case of CIM names, abbreviating any names longer than 30 characters, and placing quotes around any name that is in the union of the sets of reserved words.
Any name longer than 28 characters is abbreviated to a root name of 28 or fewer characters to allow a two-character prefix so that all associated SQL schema elements can use the same root name. The abbreviation algorithm shortens a name so that it is mnemonic, recognizable, and also unique within its scope. The abbreviated name is given a # character as a suffix (note that # is an illegal character in CIM) to prevent clashes with other names. If two or more names within the same scope generate the same abbreviation, an additional digit is appended to make the name unique. For example, AttributeCachingForRegularFilesMin is abbreviated to AttCacForRegularFilesMin#.
All such mangled names are written to the mangled name table so that a program can look up the real CIM name and retrieve the mangled name to use with the SQL.
Views are the schema elements that are most often manipulated by application code and queries. They use the same name as the CIM class they represent. For example, the CIM_UnitaryComputerSystem class is represented by a view named CIM.UnitaryComputerSystem.
When necessary, names for indexes and auxiliary tables are created by concatenating the class name and property name separated by a $ character. These names are usually abbreviated. For example, NetworkAdapter$NetworkAddresses is abbreviated to NetAdapter$NetAddresses#. This does not have any adverse impact on ZfS schema users.
In SQL, a user with the same name as the schema is the owner of each schema, for example, CIM, ManageWise®, ZENworks®, and others.
Additionally, there is an MW_DBA user that has Database Administrator privileges and rights to all schema objects. The MW_Reader role has read-only access to all schema objects and the MW_Updater role has read-write-execute access to all schema objects.
Application programs should access the database as either MW_Reader or MW_Updater for a Sybase database and MWO_Reader or MWO_Updater for an Oracle database, depending on their requirements.
CIM data types are mapped to the most appropriate data type provided by the database. Usually, the Java application does not require the type because it uses JDBC to access the data.
Java does not natively support unsigned types, so you should use classes or integer types of the next size to represent them. Also, ensure that there are no problems while reading or writing to the database. For example, reading or writing a negative number to an unsigned field in the database is likely cause an error.
Strings in CIM and Java are Unicode*, so the database is created using the UTF8 character set. Internationalization does not pose any problems; however, it may create problem with case sensitivity in queries.
All databases preserve the case of string data stored within them, but may access the data as either case sensitive or otherwise during queries. In ZfS, the Inventory Query component is not affected because the queried data is retrieved from the database before being queried and so case sensitivity is automatically taken care of.
In CIM, strings may be specified with or without a maximum size in characters. Many strings have no specified size, which means they can be unlimited in size. For efficiency reasons, these unlimited strings are mapped to a variable string with maximum size of 254 characters. CIM strings with a maximum size are mapped to variable database strings of the same size. The size in the database is in bytes and not as characters because a Unicode character may require more than one byte for storage.
Each CIM class is represented in the database by a view that contains all the local and inherited non-array properties of that class. The view is named the same as the CIM class. For example, the CIM class CIM_System represents a SQL view named CIM.System, as shown in the following illustration.
The CIM.System view is created with attributes that are selected from multiple tables. These attributes include: id$ selected from cim.t$ManagedSystemElement,class$ is filled up automatically using the function mw_dba.extractClass, Caption selected from cim.t$ManagedSystemElement, Description selected from cim.t$ManagedSystemElement, InstallDate selected from cim.t$ManagedSystemElement, Status selected from cim.t$ManagedSystemElement, CreationClassName selected from cim.t$System, Name selected from cim.t$ManagedSystemElement. NameFormat selected from cim.t$System.NameFormat, PrimaryOwnerContact selected from cim.t$System, and PrimaryOwnerName selected from cim.t$System. The view is created by joining the tables CIM.t$ManagedSystemElement and CIM.t$System where the id$ of both the tables are same.
The CIM.SYSTEM view is as follows:
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$
In addition to the properties of the class, the view has the following two additional fields:
Id$: An object identifier that uniquely identifies the particular instance of the class. See Object Identifier Id$ .
Class$: An integer field that identifies the actual type of the class. For example, the actual type of a CIM_System can be any of the concrete subclasses of CIM_System.
Views can be queried using the SELECT statement and updated using the UPDATE statement. Because views cannot be used with the INSERT and DELETE statements, use the constructor and destructor procedures.
Id$ is a 64-bit object identifier that uniquely identifies a particular instance of a class. This object identifier is usually used as an opaque handle to a particular instance. Id$ is modeled as a signed number for ease of manipulation in Java as a long data type.
Id$ contains the following three parts of information, which can each be extracted by invoking the appropriate stored procedure.
This field can be extracted using the MW_DBA.extractClass() function. This field is used for type decisions or to access additional information about the class from the MW_DBA.Class table.
The site ID uniquely identifies the database on a particular site. This field makes the object identifier unique across as many as 256 sites so that inventory data from multiple sites can be rolled up into a single database (Root Server with Database) for querying and reporting without causing key conflicts. The site ID can be extracted using the MW_DBA.extractSite() function.
This part can be extracted using the MW_DBA.extractId() function. This is not useful from an end-user's perspective.
The id$ field is used in its entirety as an opaque handle to an instance of a class. When an association class represents a relationship between instances of two classes, the reference fields of the association hold the id$ of the referenced instances (like the pointers). Therefore, id$ and these reference fields are frequently used in Join conditions when constructing the database queries that reference more than one view.
Each concrete (non-abstract) CIM class has a constructor stored procedure that must be called to create an instance of the class. This stored procedure has input parameters that allow the user to specify a value for each property in the class, and a single output parameter that returns the id$ allocated to the created instance. The application uses this returned id$ value to construct association classes that reference that particular instance.
The constructor is named by prefixing the root name with c$, and each parameter is named by prefixing the root property name with p$. For example, the constructor for CIM_UnitaryComputerSystem, a subclass of CIM_System, is named CIM.c$UnitaryComputerSystem and is constructed for Oracle as shown in the following example:
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;
Stored procedures can be called with either positional arguments or keyword arguments, or with a combination of the two. If any positional arguments are supplied, they must precede any keyword arguments. Always use keyword arguments when calling constructor stored procedures. This provides better insulation from CIM schema changes that cause either the insertion of extra parameters or the recording of existing parameters, either of which can break a positional call in a possible undetectable way. The procedures are generated such that any omitted parameters will default to NULL.
It is permissible to use the positional notation for the first parameter p$id$, which is the output parameter that returns the object identifier of the newly created instance.
The following code sample shows how to call a stored procedure using positional notation for the first argument and keyword notation for all subsequent arguments on 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 );
The syntax for keyword notation differs in Sybase ASA and Oracle. In Sybase ASA, the syntax is KEYWORD=value. In Oracle, the syntax is KEYWORD => value. Properly written code will dynamically construct the call string using syntax appropriate for the database in use.
Each non-abstract CIM class has a destructor stored procedure that is called to destroy an instance of the class. This stored procedure has only one input parameter that specifies the object identifier (id$) of the instance to be destroyed and returns no value.
The destructor deletes the appropriate rows in all relevant tables, including the rows in the inheritance chain and any associations that reference the instance being destroyed. Only the association is destroyed; the associated objects associated are not destroyed. If there is need to destroy the association, the programmers must ensure that they are not destroyed.The destructor is named by prefixing the root name with d$ and the single object identifier parameter is named p$id$. This procedure is called using positional notation. For example, the destructor for CIM_UnitaryComputerSystem, a concrete subclass of CIM_System, is named as CIM.d$UnitaryComputerSystem.
The physical schema comprises elements necessary to implement the database. The physical schema differs for each database. A typical physical schema consists of:
The logical schema is layered on top of the physical schema and makes it unnecessary for users and applications to know the physical schema.