Novell Home

ZEN 2 Inventory Database Schema

Novell Cool Solutions: Feature

Digg This - Slashdot This

Posted: 1 Sep 1999
 

This document provides information about the schema of the ZENworks Inventory database. To follow this document effectively, you should be familiar with terminology like CIM (Common Information Model) and DMI (Desktop Management Interface). You should also have a solid understanding of RDBMS and database concepts.

This document explains the ZENworks 2 Inventory Database Schema and is a copyrighted, protected document owned solely by Novell, Inc., 122 East 1700 North, Provo, Utah. Any unauthorized use of this material or software will be considered a violation of copyright.

Important: Novell, Inc. reserves the right to change the Schema Database at any time without notice. We recommend you use the views, which are less likely to change than the tables.

Contents

What is CIM (Common Information Model)?
Implementation of CIM Model in Sybase relational database
A case study of CIM Schema implementation on SYBASE for ZENworks 2
Indexes of Associations
Storage Classes in the database
Association classes and attributes
Non-CIM Tables used in the Schema
Q&A About This Article Updated March 15, 2000

What is CIM (Common Information Model)?

The Common Information Model (CIM) is a common data model of an implementation-neutral schema for describing overall management information in a network/enterprise environment. CIM is comprised of a Specification and a Schema. The Specification defines the details for integration with other management models (i.e. SNMP's MIBs or the DMTF's MIFs) while the Schema provides the actual model descriptions.

The data model as specified by CIM is implemented using a SYBASE relational database. The schema of the database is created out of CIM Specifications of its 2.1 schema. Though CIM has specified its schema in an object-oriented paradigm, we have modeled the same using a relational model.

For more information on CIM, please refer to the Distributed Management Task Force web site.

Implementation of CIM Model in Sybase relational database

Tables

Every CIM class (core or extended) and association has a corresponding table with the same name as that of the CIM class, created in the database. All the attributes of this class/association correspond with the columns of the table with same name. Rows of the CIM Table correspond with the instances of the CIM classes. Also, every CIM table has a special attribute called an ID, which is used as a primary key of that table. This attribute uniquely identifies the rows of the table. Thus, in order to access a row of the table(s) you must know the ID of that row.

Class Example:

The core CIM class CIM_ManagedSystemElement would be mapped to CIM.T_ManagedSystemElement. Similarly, the class attributes Caption, Description etc would also be created as columns of the table with correct recommended attribute types.

Association Example:

For CIM classes which are derived from other CIM classes with multi-level inheritance, the mapping makes use of relational Views which derive reference attributes from multiple relational tables.

CIM.SystemDevice is an association object which associates a CIM.UnitaryComputerSystem object with that of CIM.Processor Object. This would be modeled in the relational database as follows:

In this example, the UnitaryComputerSystem view has a row with ID 3, and the Processor view has a row with ID 10. Both need to be associated, since they belong to a single managed workstation.

A row in the SystemDevice view will have two columns: Group Component and Part Component. Group Component will have value 3 and Part Component will have value 10, which will point them to the correct rows in the UnitaryComputerSystem and the Processor views.

For example:

The CIM_UnitaryComputerSystem class is derived from CIM_ComputerSystem class, derived from CIM_System class derived from CIM_LogicalElement derived from CIM_ManagedSystemElement.

This would be represented in the relational database by the following five tables:

  • CIM.T_UnitaryComputerSystem,
  • CIM.T_ComputerSystem,
  • CIM.T_System,
  • CIM.T_LogicalElement,
  • CIM.T_ManagedSystemElement

and a relational View called CIM.UnitaryComputerSystem, which would extract attributes from the five tables.

CIM.T_ManagedSystemElement

Id$

Class$

Caption

Description

Install Date

Name

Status

CIM.T_LogicalElement

Id$

Class$

CIM.T_System

Id$

Class$

CreationClass Name

Name

Name Format

PrimaryOwner Contact

PrimaryOwner Name

Roles

CIM.T_ComputerSystem

Id$

Class$

NameFormat

CIM.T_UnitaryComputerSystem

Id$

Class$

Initial LoadInfo

Last LoadInfo

Reset Capability

Power Management Supported

Power ManagementCapabilities

Power State

The same mechanism of implementing inheritance using relational Views applies to association classes and tables too.

Note: the view name is exactly the same as that of the CIM class name (CIM.UnitaryComputerSystem). This allows you to simply to access the view instead of accessing all the individual tables.

A case study of CIM Schema implementation on SYBASE for ZENworks 2

Every relational Database has a set of DDL (Data Definition Language) commands which can be used to create

  • tables,
  • views,
  • stored procedures,
  • packaged procedures,
  • triggers

and to grant and revoke rights for all of them.

Depending on the choice of the relational database, the DDL commands, and the SQL statements to INSERT/UPDATE/DELETE rows, are written in the form of a script file. The set of DDL commands in the script file, when executed on the database, would create the schema for the database.

These DDL statements will be used to create a CIM schema on the chosen relational database.

The following example is a list of DDL commands to create a sample schema for storing Hard Disk Information (CIM.DiskDrive) on a SYBASE database.

-- ==========================================================================

-- CIM_DiskDrive

-- ==========================================================================

CREATE TABLE t$DiskDrive

(

id$ NUMERIC(19,0) PRIMARY KEY,

FOREIGN KEY id$ ( id$ ) REFERENCES t$MediaAccessDevice( id$ ) ON DELETE CASCADE

);

GRANT ALL PRIVILEGES ON t$DiskDrive TO MW_DBA WITH GRANT OPTION;

CREATE VIEW DiskDrive

(

id$,

class$,

Caption,

Description,

InstallDate,

Name,

Status,

SystemCreationClassName,

SystemName,

CreationClassName,

DeviceID,

PowerManagementSupported,

Availability,

StatusInfo,

LastErrorCode,

ErrorDescription,

ErrorCleared,

ErrorMethodology,

CompressionMethod,

NumberOfMediaSupported,

MaxMediaSize,

DefaultBlockSize,

MaxBlockSize,

MinBlockSize,

NeedsCleaning

)

AS SELECT

t$ManagedSystemElement.id$,

t$ManagedSystemElement.class$,

t$ManagedSystemElement.Caption,

t$ManagedSystemElement.Description,

t$ManagedSystemElement.InstallDate,

t$ManagedSystemElement.Name,

t$ManagedSystemElement.Status,

t$LogicalDevice.SystemCreationClassName,

t$LogicalDevice.SystemName,

t$LogicalDevice.CreationClassName,

t$LogicalDevice.DeviceID,

t$LogicalDevice.PowerManagementSupported,

t$LogicalDevice.Availability,

t$LogicalDevice.StatusInfo,

t$LogicalDevice.LastErrorCode,

t$LogicalDevice.ErrorDescription,

t$LogicalDevice.ErrorCleared,

t$MediaAccessDevice.ErrorMethodology,

t$MediaAccessDevice.CompressionMethod,

t$MediaAccessDevice.NumberOfMediaSupported,

t$MediaAccessDevice.MaxMediaSize,

t$MediaAccessDevice.DefaultBlockSize,

t$MediaAccessDevice.MaxBlockSize,

t$MediaAccessDevice.MinBlockSize,

t$MediaAccessDevice.NeedsCleaning

FROM

t$ManagedSystemElement,

t$LogicalDevice,

t$MediaAccessDevice,

t$DiskDrive

WHERE

t$ManagedSystemElement.id$ = t$DiskDrive.id$ AND

t$LogicalDevice.id$ = t$DiskDrive.id$ AND

t$MediaAccessDevice.id$ = t$DiskDrive.id$;

GRANT ALL PRIVILEGES ON DiskDrive TO MW_DBA WITH GRANT OPTION;

GRANT SELECT ON DiskDrive TO MW_READER, ZENReader;

GRANT SELECT, DELETE, INSERT, UPDATE ON DiskDrive TO MW_Updater;

CREATE PROCEDURE c$DiskDrive

(

INOUT p$id$ NUMERIC(19,0) DEFAULT 0

)

BEGIN

INSERT INTO t$ManagedSystemElement (id$) VALUES(p$id$);

SET p$id$ = @@identity;

INSERT INTO t$LogicalElement (id$) VALUES(p$id$);

INSERT INTO t$LogicalDevice (id$) VALUES(p$id$);

INSERT INTO t$MediaAccessDevice (id$) VALUES(p$id$);

INSERT INTO t$DiskDrive (id$) VALUES(p$id$);

END;

GRANT EXECUTE ON c$DiskDrive TO MW_DBA, MW_Updater;

CREATE PROCEDURE d$DiskDrive

(

IN p$id$ NUMERIC(19,0)

)

BEGIN

DELETE FROM t$ManagedSystemElement WHERE id$ = p$id$;

DELETE FROM t$LogicalElement WHERE id$ = p$id$;

DELETE FROM t$LogicalDevice WHERE id$ = p$id$;

DELETE FROM t$MediaAccessDevice WHERE id$ = p$id$;

DELETE FROM t$DiskDrive WHERE id$ = p$id$;

END;

GRANT EXECUTE ON d$DiskDrive TO MW_DBA, MW_Updater;

The above DDL script does the following:

  1. Creates a Table with the name CIM.T_DiskDrive, with all the required attributes and types as per CIM. Only ID$, representing an instance of a DiskDrive object, uniquely is available because in this case, all other attributes constituting the HardDisk are derived from other tables.
  2. Grants all privileges (to INSERT, UPDATE, DELETE) to the required users of the tables (tablespace). As an example, MW_DBA and ManageWise are the users who are given the privileges.
  3. Creates a View with the name CIM.DiskDrive (Note : this is same as the CIM classname) with all the attributes and the tables they derived from (to mimic inheritance in object databases).
  4. Creates a Stored Procedure with the name CIM.new_DiskDrive, which is equivalent to the constructor in the object-oriented paradigm. This Stored Procedure could be called by ODBC/JDBC to create a row in (equivalent to an instance of the DiskDrive class) the DiskDrive, and all the tables in the inheritance tree.

Note: when a new row is inserted into the DiskDrive table:

  1. The new row inserted only has the ID filled with the value. All other columns are left null.
  2. The value of the ID field is automatically assigned by the database. See the DDL statement SET p$id$ = @@identity (Sybase)
  3. The stored procedure returns the value of the field ID$ after inserting the row. This returned value may be used further to populate other fields.
  4. The STORER program running on the NetWare server uses the ID$ column to update the table(s) with the values of other columns, to populate the DiskDrive information in the database.

Indexes of Associations

To make it faster to navigate through association classes, indexes of the navigation attributes are created.

Example:
While creating the Component Association Table, these CIM.T_Component indexes would be created using DDL Scripts:

CREATE INDEX i$Component$GroupComponent ON t$Component ( GroupComponent );
CREATE INDEX i$Component$PartComponent ON t$Component ( PartComponent );

These two indexes are created for GroupComponent and PartComponent attributes of the Component Table.

  • GroupComponent is used in getting the UnitaryComputerSystem Object (row)
  • PartComponent is used in getting the Processor object (row)

These two are used in an association called SystemDevice. Many components, like Processor, Mouse, and Keyboard, are associated to the UnitaryComputerSystem using this association.

There are other associations being used apart from SystemDevice, between various other classes and UnitaryComputerSystem. These associations are also indexed.

To enhance the processing speed for Inventory and Inventory Query, these additional indexes are used:

  1. Name attribute used by many CIM Classes (very useful)
    • Create index mname on t$ManagedSystemElement(name);
    • Create index mdesc on t$ManagedSystemElement(description);
  2. Processor
    • Create index pclock on t$processor(maxclockspeed);
    • Create index pfamily on t$processor(family);
  3. HardDisk Available Space
    • Create index totsize on t$MWDiskDrive(TotalSize);
  4. Display Type -- VGA, SVGA, etc.
    • Create index dtype on t$MWDesktopMonitor(MonitorDisplayType);
  5. Memory
    • Create index totext on t$ExtendedMemorySetting(TotalExtendedMemory);

Storage Classes in the database

This table contains CIM and extended CIM classes, with small descriptions of their usage and the contents that are used by ZENworks inventory.

See the table.

Association classes and attributes

An association is a class that acts as a referencing entity, which associates one class with another. In ZENworks Inventory, CIM_UnitaryComputerSystem class is a focal point of reference. This means that all registered workstations in NDS have a unique row with a unique ID in it. It describes the name and properties of each workstation that is scanned and stored in the database. All other classes have an association with this class. To summarize, every class used in ZENworks Inventory associates itself to the UnitaryComputerSystem either directly or indirectly.

Direct Association

For example, a workstation's Processor information is represented in the database in the following manner:

  • The name of the workstation is stored in a UnitaryComputerSystem class table and the processor information is stored in MWProcessor class table.
  • These two are associated using another Class table called SystemDevice.
  • SystemDevice has two attributes called GroupComponent and PartComponent. GroupComponent points to UnitaryComputerSystem and the PartComponent points to MWProcessor. This is known as direct association.

Indirect Association

There are a few other associations called indirect associations. They point to UnitaryComputerSystem using other associations. For example:

Let us take the table MonitorResolution that contains the resolution of the desktop monitor. However other details of desktop monitor like type, mode, etc., are put in a table called MWDesktopMonitor.

  • MWDesktopMonitor is associated to UnitaryComputerSystem through SystemDevice association, and
  • MonitorResolution is associated to MWDesktopMonitor using MonitorSetting association.

The following table provides the details about the associations used in ZENworks Inventory.

This table is inserted as records in a table called UCSAssociation.

As an example of how to use this table, navigating from the Lookup class to Target Class where the Target Class is UnitaryComputerSystem, ZENworks uses all the associations between these two classes.

See the table.

NON-CIM Tables used in the Schema

There are a few tables that are not taken from CIM. These tables play the role of supporting the CIM Schema. In other words they are externals-lookup tables which are used for reference purposes when invoking Inventory. The following illustrates the use of these tables:

  1. UCSAssociation: This Table contains the association information till UnitaryComputerSystem. (The information contained in them is listed in the table above.) They are used by Inventory Query to find out the associations used to get the UnitaryComputerSystem. The Table is populated during the creation of the schema. More information will be added to the table when new CIM classes/extended classes are used to support additional hardware/software inventory requirements.

  2. DeleteTable: This Table is populated with a workstation's hardware/software information is written to the database. Every row in this Table maps to an entry in the CIM Tables. The information contained would be the CIM class populated, the row ID, and the machineID to identify the workstation name (this gets mapped to the row ID in UnitaryComputerSystem table).

    This Table is used when deleting a registered workstation and thereby deleting its information from the database. The Table is used by the deletion program to identify the rows that need to be deleted in order to delete the workstation information.

  3. LockTable: The Storer uses this Table when storing workstation inventory information into the database. It contains information about busyFlag and Modification Time.
    • The busyFlag when 1, indicates that the storer hasn't completed populating the workstation information.
    • The Modification time indicates the time the workstation was last created/modified in the inventory database. If the modification time has not changed since previous scan, then the database may not be updated.
  4. DMITable: This table is used to populate the DMI data of the workstation pertaining to non-CIM classes. Inventory information about the DMI classes that are mapped to CIM classes is stored in their respective Tables/classes. For those which are not mapped to CIM classes, the Inventory information is stored in this Table. The branch OtherDMIInformation of Workstation Inventory fetches information from this Table.

  5. DepClassAPI: This Table is used to get the Dependent class information of registered DMI Components that have a CIM mapping. The Dependent class names are populated by the Storer which is mapped to an Inventory API that fetches Inventory information, (such as Processor information). List of Classes names in this table are the ones that are mapped to CIM Classes

Q&A About this Article

Q: Ron U. wrote: With the advent of the Beta Support Pack for ZEN2, there is a new Sybase DB and you can migrate to it. Now, will the ZENworks 2 Database Schema article still be valid with this new Sybase Database? Does this new DB have a new schema?

A: There is no schema change in the beta support pack of ZENworks 2. The only change is that it is UTF8 enabled, which means it has the capability of storing Internationalized inventory data.
Posted March 15, 2000


Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions. www.webwiseone.com

© 2014 Novell