® Tivoli Data Warehouse
Version 1.3
Schema Reference
SC32-1497-00
® Tivoli Data Warehouse
Version 1.3
Schema Reference
SC32-1497-00
Note
Before using this information and the product it supports, read the information in Appendix C, “Notices,” on page 137.
First Edition (April 2005)
This edition applies to Tivoli Data Warehouse, Version 1.3 and to all subsequent releases and modifications until otherwise indicated in new editions.
© Copyright International Business Machines Corporation 2005. All rights reserved.
US Government Users Restricted Rights – Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp.
Contents
Preface ...... vii Geographic type (GeoTyp) ...... 36
Who should read this guide ...... vii Measurement (Msmt) ...... 37
Publications ...... vii Measurement group (MGrp)...... 40
Tivoli Data Warehouse publications . . . . . vii Measurement group member (MGrpMbr) . . . .41
Related publications ...... viii Measurement group type (MGrpTyp) ...... 42
Accessing publications online ...... xi Measurement rule (MsmtRul) ...... 42
Ordering publications ...... xi Measurement source (MSrc) ...... 43
Accessibility ...... xi Measurement source history (MSrc_History) . . .44
Contacting customer support ...... xii Measurement type (MsmtTyp) ...... 44
Conventions used in this guide ...... xii Measurement type relationship (MTypReln) . . .45
Typeface conventions ...... xii Measurement unit (MUnit) ...... 46
Operating system-dependent variables and paths xii Measurement unit category (MUnitCat) . . . . .46
Measurement unit conversion (MUnitCnv) . . . .47
Measurement unit subunit (MUnitSub) . . . . .47 Chapter 1. Introducing Tivoli Data
Prune event control (Prune_Event_Ctrl) . . . . .47
Warehouse ...... 1 Prune event log (Prune_Event_Log) ...... 48
How Tivoli Data Warehouse fits into your IT Prune measurement control (Prune_Msmt_Control) 48 enterprise ...... 1 Prune measurement log (Prune_Msmt_Log) . . .49
Components of a Tivoli Data Warehouse deployment 2 Relationship rule (RelnRul) ...... 49
Crystal Enterprise ...... 4 Relationship type (RelnTyp) ...... 50
Schema of Tivoli Data Warehouse ...... 5 Schema version (Schema_Version) ...... 50
Source component type (Src_CompTyp) . . . . .51
Chapter 2. Central data warehouse Source event attribute (Src_EventAttr) . . . . .51
schema ...... 7 Source event attribute type (Src_EAttrTyp) . . . .52
Active measurement type (Active_MsmtTyp) . . .10 Threshold measurement objective (MObj) . . . .52
Attribute domain (AttrDom) ...... 11 Threshold measurement objective range (MObjRng) 53
Attribute rule (AttrRul) ...... 12 Threshold severity level (SevLvl) ...... 54
Attribute type (AttrTyp) ...... 13 Time change difference (Time_Change_Diff) . . .54
Attribute type relationship (ATypReln) . . . . .13 Time change log (Time_Change_Log) ...... 55
Center (Centr) ...... 14 Time summary (TmSum) ...... 55
Component (Comp) ...... 14 Time zone (TmZon) ...... 56
Component attribute (CompAttr) ...... 18 Time zone install (TmZon_Install) ...... 57
Component change (Comp_Change) ...... 20 Translated Term (Translated_Term) ...... 57
Component event relationship (CEReln) . . . . .20
Component event relationship rule (CERelnRul) . .21 Chapter 3. Common static data . . . .59
Component extension (Comp_Ext)...... 22 Measurement Source ...... 59
Component relationship (CompReln) ...... 22 Component Type ...... 60
Component type (CompTyp) ...... 24 Relationship Type ...... 65
Component type keyword (CompTyp_Keyword) . .25 Relationship Rule ...... 68
Component type relationship (CTypReln) . . . .26 Time Summary ...... 70
Component type translation (CompTyp_Tran) . . .26 Measurement Unit Category ...... 71
Customer (Cust) ...... 27 Measurement Unit ...... 71
Event (Event)...... 28 Measurement Group Type ...... 72
Event attribute (EventAttr) ...... 30 Measurement Group ...... 73
Event attribute type (EAttrTyp) ...... 30 Measurement Type ...... 74
Event attribute type translation (EAttrTyp_Tran) . .31 Measurement Rule ...... 79
Event group (EGrp) ...... 32 Attribute Type ...... 82
Event group member (EGrpMbr) ...... 32 Attribute Rule ...... 90
Event group type (EGrpTyp) ...... 32 Event Type ...... 92
Event relationship (EventReln) ...... 33 Event Attribute Type ...... 93
Event relationship rule (ERelnRul)...... 33 Event Group Type ...... 93
Event type (EventTyp) ...... 34 Attribute domain ...... 93
Event type relationship (ETypReln) ...... 34
Extract control (Extract_Control) ...... 35 Chapter 4. Central data warehouse
Extract log (Extract_Log) ...... 36
views, sequences, and triggers . . . .95 Geographic area (GeoArea) ...... 36
© Copyright IBM Corp. 2005 iii
Standard views in the TWG_STD schema . . . .95 Sequences and triggers for the component
Standard view for the measurement type relationship (CompReln) table ...... 108
(MsmtTyp) table ...... 95 Sequences and triggers for the component
Standard view for the event type (EventTyp) change (Comp_Change) table ...... 109
table ...... 96 Sequences and triggers for the customer (Cust)
Standard view for the component type table ...... 109
(CompTyp) table ...... 96 Sequences and triggers for the extract control
Standard view for the attribute type (AttrTyp) (Extract_Control) and extract log (Extract_Log)
table ...... 97 tables ...... 109
Standard view for the relationship type (RelnTyp) Sequences and triggers for the measurement
table ...... 98 source (Msrc) and measurement source history
Standard view for the component attribute type (MSrc_History) tables...... 109
(CompAttr) table ...... 98 Sequences and triggers for the measurement
Standard view for the component relationship (Msmt) table ...... 111
(CompReln) table ...... 98 Sequences and triggers for the measurement
Standard view for the measurement (Msmt) table 99 type (MsmtTyp) table ...... 111
Standard view for the component (Comp) table 99 Sequences and triggers for the measurement
Standard view for the measurement source pruning log (Prune_Msmt_Log) table for
(Msrc) table ...... 100 pruning central data warehouse measurements . 111
Current views in the TWG.cur schema . . . . . 100 Sequences and triggers for the translated term
Current view for the component type (Translated_Term) table ...... 112
(CompTyp) table ...... 100 Sequences and triggers for the component event
Current view for the relationship rule (RelnRul) relationship (CEReln) table ...... 112
table ...... 100 Sequences and triggers for the event attribute
Current view for the attribute rule (AttrRul) (EventAttr) table ...... 112
table ...... 101 Sequences and triggers for the event
Current view for the attribute domain relationship (EventReln) table ...... 113
(AttrDom) table ...... 101 Sequences and triggers for the event (Event)
Current view for the component (Comp) table 101 table ...... 113
Current view for the component attribute Sequences and triggers for the event type
(CompAttr) table ...... 102 (EventTyp) table ...... 113
Current view for the component relationship Sequences and triggers for the attribute domain
(CompReln) table ...... 102 (AttrDom) table ...... 113
Current view for the measurement type Sequences and triggers for the component type
relationship (MTypReln) table ...... 102 keyword (CompTyp_Keyword) table . . . .113
Current view for the event type relationship Sequences and triggers for the measurement
(ETypReln) table ...... 103 objective (MObj) table ...... 114
Current view for the component type Sequences and triggers for the measurement
relationship (CTypReln) table ...... 103 objective range (MObjRng) table ...... 114
Current view for the attribute type relationship
(ATypReln) table ...... 103 Chapter 5. Data mart model and
Current view for the component event schema ...... 115
relationship rule (CERelnRul) table . . . . . 104 Components of a star schema ...... 116
Current view for the event relationship rule Fact table ...... 116
(ERelnRul) table ...... 104 Component dimension tables ...... 118
Current view for the measurement objective Metric dimension table ...... 118
(MObj) table ...... 104
Current view for the measurement type
Appendix A. Naming conventions . . 121 (MsmtTyp) table ...... 105
Warehouse pack names ...... 121 Inheritance views in the TWG_STD schema . . . 105
Product codes ...... 121 Inheritance view (AttrRul_inh) for the attribute
Tivoli Data Warehouse database names . . . . . 122 rule (AttrRul) table ...... 105
Warehouse pack-specific objects in the central data Inheritance view (MsmtRul_inh) for the
warehouse ...... 122 measurement rule (MsmtRul) table . . . . . 106
Staging tables ...... 123 Inheritance view (RelnRul_inh) for the
Warehouse pack-specific data in the generic (TWG) relationship rule (RelnRul) table ...... 106
central data warehouse tables ...... 123 Sequences and triggers for the TWG tables . . . 106
All codes (*_Cd) ...... 124 Sequences and triggers for the component
Component type codes ...... 124 (Comp) table ...... 106
Attribute type codes ...... 125 Sequences and triggers for the component
Measurement type names ...... 125 attribute (CompAttr) table ...... 107
iv Tivoli Data Warehouse Schema Reference
Product names — MSrc_Nm ...... 126 Learning about education ...... 133
Warehouse pack-specific objects in data marts . . 126 Searching knowledge bases ...... 133
Dimension tables based on components . . . 126 Search the documentation ...... 133
Metric dimension tables ...... 126 Search the Internet ...... 133
Translation tables for dimension tables . . . . 126 Obtaining fixes ...... 134
Fact tables for measurements ...... 127 Contacting IBM Software Support ...... 134
Fact tables for point in time data ...... 127 Determine the business impact of your problem 135
Objects in the DB2 Data Warehouse Center . . . 128 Describe your problem and gather background
Subject areas ...... 128 information ...... 135
Warehouse sources ...... 128 Submit your problem to IBM Software Support 135
Warehouse targets ...... 128
Processes ...... 129 Appendix C. Notices ...... 137
Steps ...... 129 Trademarks ...... 139
File names for steps ...... 130
Report file names ...... 131
Glossary ...... 141
Java resource bundles ...... 131
Index ...... 145
Appendix B. Support information . . . 133
Contents v vi Tivoli Data Warehouse Schema Reference
Preface
® With Tivoli Data Warehouse you can access the underlying data about your
network devices and connections, desktops, software, and turn that data into
relevant information to help drive innovation, decision making, and strategic
planning. You can also use that data to view your infrastructure as a whole. Tivoli
Data Warehouse provides a consolidated view of complex heterogeneous
environments.
Tivoli Data Warehouse Schema Reference provides information about the collection of
tables, views, indexes, and triggers that define and provide a logical classification
of the databases in your Tivoli Data Warehouse deployment.
Who should read this guide
This guide is for the following audience:
v Application programmers who want to use Tivoli Data Warehouse to store and
report on the data of their application
v Data warehousing experts who want to import Tivoli Data Warehouse data into
business intelligence applications
v Customers who want to use their local data in the data warehouse
Readers should be familiar with the following products or technologies:
® ® v IBM DB2 and relational database management system (RDBMS) design
concepts
v Structured Query Language (SQL)
v Tivoli software applications
v Data warehouse information and design, extract, transform, and load (ETL)
processes, and online analytical processing (OLAP) techniques
The readers should also have extensive knowledge of their local data (source data)
that they want to put in Tivoli Data Warehouse.
Publications
This section lists publications in the Tivoli Data Warehouse library and other
related documents.
Tivoli Data Warehouse publications
The following documents are available in the Tivoli Data Warehouse library:
v Tivoli Data Warehouse Release Notes, SC32-1399-01
Provides last-minute information about Tivoli Data Warehouse and lists
hardware requirements and software prerequisites.
v Installing and Configuring Tivoli Data Warehouse, GC32-0744
Describes how Tivoli Data Warehouse fits into your enterprise, explains how to
plan for its deployment, and gives installation and configuration instructions.
Additionally, this guide contains maintenance procedures and describes how to
install warehouse packs and reports.
© Copyright IBM Corp. 2005 vii Preface
™ This document also describes how to install DB2 Universal Database and
Crystal Enterprise for use with Tivoli Data Warehouse.
v Tivoli Data Warehouse Troubleshooting Guide, SC09-7776
Lists the messages generated by Tivoli Data Warehouse and describes the actions
you should take. It also contains troubleshooting information related to
installing, configuring, and using Tivoli Data Warehouse.
v Tivoli Data Warehouse Schema Reference, SC32-1497
Describes the database schemas used in the Tivoli Data Warehouse central data
warehouse and data mart. This includes the data model for the central data
warehouse and data mart and the tables in the central data warehouse.
The Tivoli Data Warehouse information center contains the documents from the
Tivoli Data Warehouse library in both PDF and HTML formats. All documents are
available in English; selected documents are available in other languages. The
information center is available online:
http://publib.boulder.ibm.com/infocenter/tiv3help/index.jsp?topic=
/com.ibm.tivoli.tdwi.doc/welcome.htm
Related publications
The following section describes additional publications that can help you
understand and use Tivoli Data Warehouse and its prerequisites.
The Tivoli Glossary
The Tivoli Software Glossary includes definitions for many of the technical terms
related to Tivoli software. The Tivoli Software Glossary is available at the following
Tivoli software library Web site:
http://publib.boulder.ibm.com/tividd/glossary/tivoliglossarymst.htm
IBM Redbooks
™ IBM Redbooks are developed and published by the IBM International Technical
Support Organization, the ITSO. They explore integration, implementation, and
operation of realistic customer scenarios. The following Redbooks contain
information about Tivoli Data Warehouse:
™ v Introduction to Tivoli Enterprise Data Warehouse, SG24-6607
Provides a broad understanding of Tivoli Data Warehouse. Some of the topics
that are covered are concepts, architecture, writing your own ETLs, and best
practices in creating data marts.
v IBM Tivoli Data Warehouse 1.3: Planning and Implementation, SG24-6343-00
Focuses on planning, installation, customization, use, maintenance, and
troubleshooting topics related to the new features of Tivoli Data Warehouse,
Version 1.3, using a number of case study scenarios and several warehouse
packs. A comprehensive chapter describes optimizing the overall performance of
a Tivoli Data Warehouse implementation, and focuses on DB2 optimization
techniques and remote warehouse agents.
Crystal Enterprise publications
The following documents describe how to install, use, and administer Crystal
Enterprise. These documents are available on the Crystal Enterprise 10 CD, which is
shipped with Tivoli Data Warehouse:
v Crystal Enterprise 10 Installation Guide
viii Tivoli Data Warehouse Schema Reference Preface
Provides information and procedures for installing Crystal Enterprise. This guide
also includes detailed instructions for the different installation modes available.
v Crystal Enterprise 10 Getting Started Guide
Provides basic installation information and serves as a general introduction to
Crystal Enterprise, ePortfolio, the Crystal Management Console, the Crystal
Publishing Wizard, and the overall product architecture.
v Using Limited Edition Features in ePortfolio
Provides information and procedures for accessing and using ePortfolio and its
report viewers.
v Crystal Enterprise 10 Administrator’s Guide
Provides information and procedures for the administrative tasks. Procedures are
provided for common tasks. Conceptual information and technical details are
provided for all advanced topics.
v Business Views Administration Guide
Provides information and procedures for the administrative tasks associated
with Business Views. Business Views provide an abstraction layer that helps
report designers and end users access the information they require. Conceptual
information and technical details are provided for all topics.
v Crystal Reports 10 User’s Guide
This manual is included in the Crystal Reports CD that is sold as an upgrade by
IBM to Tivoli Data Warehouse users. It provides procedures for typical reporting
tasks such as placing fields, formatting reports, and sorting records. It also
contains information about advanced formula creation and accessing different
types of data. Acts as a reference for basic reporting needs as well as an
introduction to new concepts in report creation.
DB2 Universal Database publications
The DB2 library contains important information about the database system and
data warehousing technology provided by IBM DB2 Universal Database Enterprise
Server Edition, IBM DB2 Warehouse Manager Standard Edition, and the DB2 Data
Warehouse Center.
If you are new to data warehousing and the DB2 product, there is a tutorial that
leads you through the basics of data warehousing and the use of the DB2 Data
Warehouse Center. This online tutorial is available from DB2 library.
Refer to the DB2 library for help installing, configuring, administering, and
troubleshooting DB2 products. The DB2 library is available online at the following
Web address:
http://publib.boulder.ibm.com/infocenter/db2help/index.jsp
The following documents are particularly relevant for people working with Tivoli
Data Warehouse:
v IBM DB2 Universal Database Quick Beginnings for DB2 Servers, GC09-4836
Guides you through the planning, installation, migration, and setup of a
® ® partitioned database system using IBM DB2 servers on Microsoft Windows
® and UNIX systems.
v IBM DB2 Universal Database Quick Beginnings for DB2 Clients, GC09-4832
Guides you through the planning, installation, migration, and setup of a
partitioned database system using IBM DB2 clients on Microsoft Windows and
UNIX systems.
Preface ix Preface
v IBM DB2 Universal Database Administration Guide: Implementation, SC09-4820
Covers the details of implementing your database design. Topics include
creating and altering a database, database security, database recovery, and
administration using the DB2 Control Center, a DB2 graphical user interface
(GUI).
v IBM DB2 Universal Database Administration Guide: Performance, SC09-4821
Provides information about configuring and tuning your database environment
to improve performance.
v IBM DB2 Universal Database Data Warehouse Center Administration Guide,
SC27-1123
Provides information about how to build and maintain a data warehouse using
the DB2 Data Warehouse Center.
v IBM DB2 Warehouse Manager Installation Guide, GC27-1122
Provides the information for installing the following DB2 Warehouse Manager
components: Information Catalog Manager, warehouse agents, and warehouse
transformers.
v IBM DB2 Universal Database Installation and Configuration Supplement, GC09-4837
Provides advanced installation considerations and guides you through the
planning, installation, migration, and setup of a platform-specific DB2 client.
After the DB2 client is installed, you configure communications for both the
client and server, using the DB2 GUI tools or the Command Line Processor. This
supplement also contains information on binding, setting up communications on
™ the server, the DB2 GUI tools, Distributed Relational Database Architecture
® application server (DRDA AS), distributed installation, the configuration of
distributed requests, and accessing heterogeneous data sources.
v IBM DB2 SQL Reference Volume 1, SC09-4844 and IBM DB2 SQL Reference Volume
2, SC09-4845
Describes SQL syntax, semantics, and the rules of the language. This book also
includes information about release-to-release incompatibilities, product
limitations, and catalog views.
You can order both volumes of the SQL Reference in the English language in
North America with the form number SBOF-8933.
v IBM DB2 Universal Database Message Reference Volume 1, GC09-4840 and IBM DB2
Universal Database Message Reference Volume 2, GC09-4841
Lists the messages and codes issued by DB2, the Information Catalog Manager,
and the DB2 Data Warehouse Center, and describes the actions you should take.
z/OS Publications ® This section lists publications in the DB2 Universal Database for z/OS , formerly
® DB2 Universal Database for z/OS and OS/390 library and other documentation
for those using Tivoli Data Warehouse on the z/OS operating system.
DB2 Universal Database for z/OS publications: This section lists publications in
the DB2 Universal Database for z/OS library:
v IBM DB2 Universal Database for z/OS Administration Guide, SC18-7413
Provides information about how to administer and customize DB2 Universal
Database for z/OS. Its audience is mainly composed of system administrators,
IT administrators, and users.
v IBM DB2 Universal Database for z/OS and OS/390 An Introduction to DB2 for
OS/390, SC26-9937
Provides information about how to get started with DB2 Universal Database for
z/OS. It also gives an overall view of the product.
x Tivoli Data Warehouse Schema Reference Preface
v IBM DB2 Universal Database for z/OS Messages and Codes, GC18-7422
Defines and explains the DB2 Universal Database for z/OS messages and codes.
v IBM DB2 Universal Database for z/OS Installation Guide, GC18-7418
Provides information about how to install DB2 Universal Database for z/OS.
v IBM DB2 Universal Database for z/OS Utility Guide and Reference, SC18-7427
Contains usage information for the tasks of system administration, database
administration, and database operation. It presents detailed information about
using utilities, syntax, keyword and parameter descriptions, and information
about starting, stopping, and restarting utilities. This book also includes job
control language (JCL) and control statements for each utility.
v IBM DB2 Universal Database for z/OS and OS/390 Diagnosis Guide and Reference,
LY37-3740
Provides information about how to debug and fix common problems with DB2
Universal Database for z/OS.
Accessing publications online
IBM posts publications for this and all other Tivoli products, as they become
available and whenever they are updated, to the Tivoli Software Information
Center Web site.
The product manuals for Tivoli Data Warehouse are located in an Information
Center at the following Web address:
http://publib.boulder.ibm.com/infocenter/tiv3help/index.jsp?topic=
/com.ibm.tivoli.tdwi.doc/welcome.htm
The Tivoli Software Information Center is located at the following Web address:
http://publib.boulder.ibm.com/tividd/td/tdprodlist.html
The DB2 product library is located at the following Web address:
http://publib.boulder.ibm.com/infocenter/db2help/index.jsp
Note: If you print PDF documents on other than letter-sized paper, select the Fit to
page check box in the Adobe Acrobat Print dialog. This option is available
when you click File → Print. Fit to page ensures that the full dimensions of a
letter-sized page print on the paper that you are using.
Ordering publications
You can order many IBM and Tivoli publications online at the following Web site:
http://www.elink.ibmlink.ibm.com/public/applications/publications/cgibin/pbi.cgi
Accessibility
Accessibility features help users with a physical disability, such as restricted
mobility or limited vision, to use software products successfully. For information
about the accessibility features of Tivoli Data Warehouse, refer to Installing and
Configuring Tivoli Data Warehouse.
Preface xi Preface
Contacting customer support
If you have a problem with any Tivoli product, refer to the following IBM Software
Support Web site:
http://www.ibm.com/software/sysmgmt/products/support/
If you have a problem with Tivoli Data Warehouse, refer to the following IBM
Support Web site:
http://www.ibm.com/software/sysmgmt/products/ support/TivoliDataWarehouse.html
If you have a problem with a DB2 product, refer to the following IBM Software
Support Web site:
http://www.ibm.com/software/data/db2
If you want to contact customer support, see the IBM Software Support Guide at the
following Web site:
http://techsupport.services.ibm.com/guides/handbook.html
The guide provides information about how to contact IBM Software Support,
depending on the severity of your problem, and the following information:
v Registration and eligibility
v Telephone numbers and e-mail addresses, depending on the country in which
you are located
v Information you must have before contacting IBM Software Support
Conventions used in this guide
This guide uses several conventions for special terms and actions and for operating
system-dependent commands and paths.
Typeface conventions
This guide uses the following typeface conventions:
Bold Lowercase and mixed-case commands, command options, and
flags that appear within text appear like this, in bold type.
Graphical user interface elements except for titles of windows and
dialogs also appear like this, in bold type.
Italic Variables, values you must provide, new terms, and words and
phrases that are emphasized appear like this, in italic type.
Monospace Code examples, output, and message text appear like this, in
monospace type.
Text strings you must type, when they appear within text, names
™ of Java methods and classes, and HTML and XML tags also
appear like this, in monospace type.
Operating system-dependent variables and paths
When referring to environment variables in a context that can occur only on a
system running a Windows operating system, environment variables and path
xii Tivoli Data Warehouse Schema Reference Preface
names are displayed using the Windows notation. For example, %SystemRoot%
and C:\Program Files\TWH\, respectively. If the context applies to both Windows
and UNIX operating systems, this guide uses the UNIX convention for specifying
environment variables and for directory notation. For example, $TEMP and
/usr/local/bin/.
To convert from the UNIX format to the Windows format, replace $variable with
%variable% for environment variables and replace each forward slash (/) with a
backslash (\) in directory paths.
Note: If you are using the bash shell on a Windows system, you can use the UNIX
conventions.
This guide uses the following environment variables:
Variable name Meaning
ProgramFiles Identifies the directory where program files are
installed. Usually, this is C:\Program Files\, but it
can also be represented with the SystemDrive
environment variable as
%SystemDrive%:\Program Files\.
TWH_TOPDIR The top-level directory in which the Tivoli Data
Warehouse files are installed. The default value on
Windows systems is %ProgramFiles%\TWH\. The
default value on UNIX systems is /opt/twh/.
Preface xiii Preface
xiv Tivoli Data Warehouse Schema Reference
Chapter 1. Introducing Tivoli Data Warehouse
This chapter gives an overview of Tivoli Data Warehouse. This chapter contains the
following sections:
v “How Tivoli Data Warehouse fits into your IT enterprise”
v “Components of a Tivoli Data Warehouse deployment” on page 2
v “Schema of Tivoli Data Warehouse” on page 5
How Tivoli Data Warehouse fits into your IT enterprise
Figure 1 on page 2 illustrates how Tivoli Data Warehouse fits into your IT
enterprise. The numbers in the figure correspond to the numbers in this list:
1. Your environment contains many products and services that monitor and
manage your IT enterprise. These products and services generate data that is
stored in a variety of formats, including relational databases, spreadsheet data,
log files, and other formats.
2. Extract, transform, and load (ETL) programs take the data from these various
sources and place it in a central data warehouse. This action requires that the data
be aggregated and converted into the standard format for historical data in the
central data warehouse. These central data warehouse ETL programs are
provided in applications called warehouse packs.
3. The central data warehouse contains the historical data from all your diverse
sources.
4. Another set of ETL programs extract a subset of historical data from the central
data warehouse. This subset of data is called a data mart. Like the ETL
programs in step 2, these data mart ETL programs are typically packaged in
warehouse packs.
A data mart ETL program can access any data in the central data warehouse,
including data placed there by the central data warehouse ETL program of
another warehouse pack.
5. Data marts contain historical data that is extracted from a central data
warehouse and are designed to help satisfy the analysis and reporting needs of
a specific department, team, customer, or application.
6. You use a program to analyze a specific aspect of your enterprise using the
data in one or more data marts. Tivoli Data Warehouse provides Crystal
Enterprise for reporting. You can pull data from Tivoli Data Warehouse using
an application such as IBM Tivoli Service Level Advisor. You could also use
another program to perform OLAP analysis, business intelligence reporting, or
data mining.
© Copyright IBM Corp. 2005 1
System management data from Tivoli and custom sources on Windows, UNIX, and z/OS systems 1
ETLs from warehouse packs 2
Central data warehouses
3
ETLs from warehouse packs 4
Data marts
5
IBM Tivoli Data Reporting 6 Service Level analysis tools Advisor tools
Figure 1. Overview of Tivoli Data Warehouse in an IT enterprise
Components of a Tivoli Data Warehouse deployment
A deployment of Tivoli Data Warehouse consists of the following components:
v Control server
v Central data warehouses
v Data marts
v DB2 warehouse agents and agent sites
v Crystal Enterprise
v Warehouse packs
2 Tivoli Data Warehouse Schema Reference
These components can be installed on one system for a quick start installation, or
distributed across the systems in your IT enterprise. Figure 2 illustrates the
components distributed across these systems.
Crystal ePortfolio Business Intelligence tools OLAP tools
Crystal Enterprise server
Central data Control server Data marts warehouses & Warehouse packs Operational data Tivoli Data Warehouse components
Figure 2. Components of a Tivoli Data Warehouse deployment
Figure 2 also shows other types of data analysis tools, which in this example are
located on systems outside the Tivoli Data Warehouse deployment.
Tivoli Data Warehouse control server
The Tivoli Data Warehouse control server is the system from which you
manage your data. It contains the control database for Tivoli Data
Warehouse. The control database contains metadata for both Tivoli Data
Warehouse and for the warehouse management functions of IBM DB2
Universal Database Enterprise Server Edition, such as the DB2 Data
Warehouse Center and the DB2 Warehouse Manager.
Central data warehouses
Central data warehouses contain the historical data for your enterprise.
Data in the central data warehouse is derived from operational data,
although operational data is not stored directly in the central data
warehouse.
Data marts
The data marts are subsets of the historical data that satisfy the needs of a
specific department, team, or customer. Additionally, data marts are
optimized for interactive reporting and data analysis.
Warehouse agents and agent sites
The DB2 warehouse agent is the component of IBM DB2 Warehouse
Manager Standard Edition that manages the flow of data between data
sources and targets that are on different systems.
DB2 warehouse agents and agent sites are not shown in Figure 2.
Warehouse packs
A warehouse pack is separately-installable software that provides any
combination of the following functions:
v Database tables and constants that define the data to be collected
v The ETL programs that move historical data from operational data
sources into a central data warehouse
v The ETL programs that extract data from a central data warehouse into a
data mart for reporting purposes
Chapter 1. Introducing Tivoli Data Warehouse 3
v Prepackaged reports about a specific aspect of system management
Crystal Enterprise
Crystal Enterprise Professional v.10 works with Tivoli Data Warehouse to provide
historical reporting. Warehouse packs provide reports designed for use with
Crystal Enterprise. You access the reports with a Web browser that connects to the
Crystal Management Server (CMS), which you install with Crystal Enterprise.
You typically use the following applications to manage Crystal Enterprise:
ePortfolio
ePortfolio is a Web-based desktop that is an interface for users to view,
schedule, and monitor published reports. You can also use ePortfolio to
help troubleshoot problems that users encounter when viewing and
scheduling reports.
Crystal Configuration Manager (CCM)
This server administration tool is provided in two forms. In a Windows
environment, you can use CCM to manage local and remote servers
through its GUI or from a command line. In a AIX environment, you can
use the CCM shell script (ccm.sh) to manage servers from a command line.
Crystal Management Console (CMC)
This Web application provides a single interface to use to perform almost
every task related to user management, content management, and server management.
Table 1 lists the products in the Crystal product family that Business Objects offers
to work with Tivoli Data Warehouse.
Table 1. Business Objects products for use with Tivoli Data Warehouse
Product Availability Purpose and Description
Crystal Enterprise Ships with Tivoli Data Analyze and deliver
Professional v.10 for Tivoli Warehouse out-of-the-box reports from
(Limited Use Version) Tivoli Data Warehouse to
decision-makers over the
Internet.
With Crystal Enterprise
Professional v.10, you can
install and use the reports
that Tivoli delivers; however,
you cannot create new
reports.
Crystal Enterprise v.10 Purchased separately Extend your reporting
Special Edition capabilities to develop,
deliver, and analyze new
reports created from your
Tivoli system management
data using Crystal Reports
across your organization
through the Crystal
Enterprise zero-client
interface.
Crystal Reports v.10 Special
Edition is required with this
product.
4 Tivoli Data Warehouse Schema Reference
Table 1. Business Objects products for use with Tivoli Data Warehouse (continued)
Product Availability Purpose and Description
Crystal Reports v.10 Special Purchased separately Add, modify, and design
Edition new reports from your Tivoli
system management data
with Crystal Reports.
Crystal Enterprise v.10
Special Edition is required
with this product.
Usage of the following products is subject to certain limitations and restrictions, as set
forth in the Crystal Enterprise 10 for Tivoli License Agreement. Please refer to the License
Agreement for a complete description of those limitations and restrictions.
Schema of Tivoli Data Warehouse
The Tivoli Data Warehouse schema consists of a collection of tables, views, indexes,
and triggers that define and provide a logical classification for the central data
warehouses and data marts in your deployment. This guide documents specific
details about this database schema.
Chapter 1. Introducing Tivoli Data Warehouse 5 6 Tivoli Data Warehouse Schema Reference
Chapter 2. Central data warehouse schema
This chapter describes the table definitions that compose the central data
warehouse schema. These tables all start with TWG.tableName to indicate that they
are part of the Tivoli Data Warehouse schema.
Table 2 shows when and by what method data is inserted into or changed in the
central data warehouse by both the Tivoli Data Warehouse installation program
and your warehouse pack.
The central data warehouse tables are created when Tivoli Data Warehouse is
installed. Data is inserted into these tables by both the Tivoli Data Warehouse
installation program and warehouse packs using the following mechanisms:
v The static data script that runs when Tivoli Data Warehouse is installed
v The Tivoli Data Warehouse script (twh_cdw_data.generic) that runs during a
warehouse pack installation to create common static data
v A warehouse pack script that runs during a warehouse pack installation to
create warehouse pack-specific static data
v A Tivoli Data Warehouse script that runs during an extract, transform, and load
(ETL) process to create dynamic data
v Your Java resource bundle files, which run during a warehouse pack installation
to allow reports to display translated data
This data populates the Translated_Term table. See “Translated Term
(Translated_Term)” on page 57.
The following table identifies which tables are populated by each method.
Table 2. Central data warehouse schema summary table
Table Name Tivoli Data Warehouse Warehouse pack Central data
Warehouse core pack installation warehouse ETL
installation installation (using your process
(using a static (using the warehouse (dynamically
data script) common static pack-specific loaded using
data script: data script) your warehouse
twh_cdw_ pack-specific
data.generic) data script)
“Active measurement type X
(Active_MsmtTyp)” on page 10
“Attribute domain (AttrDom)” on page X
11
“Attribute rule (AttrRul)” on page 12 X
“Attribute type (AttrTyp)” on page 13 X
“Attribute type relationship (ATypReln)” X
on page 13
“Center (Centr)” on page 14 X X
“Component (Comp)” on page 14 X
“Component attribute (CompAttr)” on X
page 18
© Copyright IBM Corp. 2005 7
Table 2. Central data warehouse schema summary table (continued)
Table Name Tivoli Data Warehouse Warehouse pack Central data
Warehouse core pack installation warehouse ETL
installation installation (using your process
(using a static (using the warehouse (dynamically
data script) common static pack-specific loaded using
data script: data script) your warehouse
twh_cdw_ pack-specific
data.generic) data script)
“Component change (Comp_Change)” on X
page 20
“Component event relationship (CEReln)” X
on page 20
“Component relationship (CompReln)” X
on page 22
“Component type (CompTyp)” on page X X
24
“Component event relationship rule X
(CERelnRul)” on page 21
“Component extension (Comp_Ext)” on X
page 22
“Component type keyword X
(CompTyp_Keyword)” on page 25
“Component type relationship X
(CTypReln)” on page 26
“Component type translation X
(CompTyp_Tran)” on page 26
“Customer (Cust)” on page 27 X X
“Event (Event)” on page 28 X
“Event attribute (EventAttr)” on page 30 X
“Event attribute type (EAttrTyp)” on X
page 30
“Event attribute type translation X
(EAttrTyp_Tran)” on page 31
“Event group (EGrp)” on page 32 X
“Event group member (EGrpMbr)” on X
page 32
“Event group type (EGrpTyp)” on page X
32
“Event relationship (EventReln)” on page X
33
“Event relationship rule (ERelnRul)” on X
page 33
“Event type (EventTyp)” on page 34 X
“Event type relationship (ETypReln)” on X
page 34
“Extract control (Extract_Control)” on X X
page 35
“Extract log (Extract_Log)” on page 36 X
8 Tivoli Data Warehouse Schema Reference
Table 2. Central data warehouse schema summary table (continued)
Table Name Tivoli Data Warehouse Warehouse pack Central data
Warehouse core pack installation warehouse ETL
installation installation (using your process
(using a static (using the warehouse (dynamically
data script) common static pack-specific loaded using
data script: data script) your warehouse
twh_cdw_ pack-specific
data.generic) data script)
“Geographic area (GeoArea)” on page 36 X
“Geographic type (GeoTyp)” on page 36 X
“Measurement (Msmt)” on page 37 X
“Measurement group (MGrp)” on page X
40
“Measurement group member X
(MGrpMbr)” on page 41
“Measurement group type (MGrpTyp)” X
on page 42
“Measurement rule (MsmtRul)” on page X
42
“Measurement source (MSrc)” on page 43 X
“Measurement source history X
(MSrc_History)” on page 44
“Measurement type (MsmtTyp)” on page X
44
“Measurement type relationship X
(MTypReln)” on page 45
“Measurement unit (MUnit)” on page 46 X
“Measurement unit category (MUnitCat)” X
on page 46
“Measurement unit conversion X
(MUnitCnv)” on page 47
“Measurement unit subunit (MUnitSub)” X
on page 47
“Prune event control (Prune_Event_Ctrl)” X
on page 47
“Prune event log (Prune_Event_Log)” on X
page 48
“Prune measurement control X
(Prune_Msmt_Control)” on page 48
“Prune measurement log X
(Prune_Msmt_Log)” on page 49
“Relationship rule (RelnRul)” on page 49 X
“Relationship type (RelnTyp)” on page 50 X
“Schema version (Schema_Version)” on X
page 50
“Source component type (Src_CompTyp)” X
on page 51
Chapter 2. Central data warehouse schema 9
Table 2. Central data warehouse schema summary table (continued)
Table Name Tivoli Data Warehouse Warehouse pack Central data
Warehouse core pack installation warehouse ETL
installation installation (using your process
(using a static (using the warehouse (dynamically
data script) common static pack-specific loaded using
data script: data script) your warehouse
twh_cdw_ pack-specific
data.generic) data script)
“Source event attribute (Src_EventAttr)” X
on page 51
“Source event attribute type X
(Src_EAttrTyp)” on page 52
“Threshold measurement objective X
(MObj)” on page 52
“Threshold measurement objective range X
(MObjRng)” on page 53
“Threshold severity level (SevLvl)” on X
page 54
“Time change difference X
(Time_Change_Diff)” on page 54
“Time change log (Time_Change_Log)” X
on page 55
“Time summary (TmSum)” on page 55 X
“Time zone (TmZon)” on page 56 X
“Time zone install (TmZon_Install)” on X
page 57
Active measurement type (Active_MsmtTyp)
This table defines what measurement types have current, or active, measurements
after the pruning process is complete.
The table is populated by a step in Tivoli Data Warehouse after the pruning
process runs.
Table 3. Active measurement type table (Active_MsmtTyp)
Column name Data type Null Primary Foreign Attribute name and description
option key key
MsmtTyp_ID INTEGER NOT Yes Yes Measurement Type ID
NULL
Active_Flag CHAR NOT No No Active Measurement Flag
NULL
Check_DtTm TIMESTAMP NOT Yes No Active Measurement Check Date Time
NULL
This field indicates the time at which the table
was updated.
10 Tivoli Data Warehouse Schema Reference
Attribute domain (AttrDom)
This table defines the set of valid values for valid combinations of attribute types
and component types. It is only used when the set of valid values is predefined.
For example, one of the attribute types that is valid for a component of type
IP_HOST is OS_TYPE. The OS_TYPE attribute type has a predefined set of values
® (see “Attribute domain” on page 93). AIX is one instance of a valid value for an
OS_TYPE attribute that can be associated with a host system.
Since data is not physically deleted from most central data warehouse tables,
domains are current or obsolete depending on their start and end dates and times.
These dates reflect the effective period during which the domain is current.
Attributes can be current, independent of their associated domains. Therefore,
current attributes are not disabled when a related domain is disabled.
This table is populated with common static data that is created in the central data
warehouse by the twh_cdw_data.generic script during a warehouse pack
installation. It is also populated with warehouse pack-specific static data that is
created by your warehouse pack script during a warehouse pack installation, if
applicable.
Table 4. Attribute domain table (AttrDom)
Column name Data type Null Is PK Is FK Attribute name and description
option
AttrDom_ID INTEGER NOT Yes No Attribute Domain ID
NULL
CompTyp_Cd CHAR(17) NOT No Yes Component Type Code
NULL
AttrTyp_Cd CHAR(17) NOT No Yes Attribute Type Code
NULL
AttrDom_Strt_DtTm TIMESTAMP NOT No No Attribute Domain Start DateTime
NULL
When an attribute domain is created, a
start date is assigned (usually the current
time stamp).
AttrDom_End_DtTm TIMESTAMP NOT No No Attribute Domain End DateTime
NULL
When an attribute is created, the end date
is set to Jan 1, 9999 indicating the attribute
domain is valid.
AttrDom_Val VARCHAR(254) NOT No No Attribute Domain Value
NULL
AttrDom_Ds VARCHAR(254) NULL No No Attribute Domain Description
You can translate this value.
Chapter 2. Central data warehouse schema 11
Table 4. Attribute domain table (AttrDom) (continued)
Column name Data type Null Is PK Is FK Attribute name and description
option
MSrc_Corr_Cd CHAR(6) NULL No Yes Measurement Source Code
If either the attribute or the component is
private, or used exclusively by a specific
warehouse pack, this column contains the
measurement source code (MSrc_Cd) of the
warehouse pack that created the attribute
domain. If the attribute and component are
shared, or used by more than one
warehouse pack, this is one of the
measurement source codes described in
“Measurement Source” on page 59.
Typically, it is MODEL1. In some case, it
might be SNMP or the product code if it’s a
unique domain type for that application.
Attribute rule (AttrRul)
This table defines which attributes are valid for a component type. For each
attribute in the Component Attribute table, there must be a corresponding rule
defined in the Attribute Rule table for each attribute type that is valid for a
particular component type.
This table is populated with common static data that is created in the central data
warehouse by the twh_cdw_data.generic script during a warehouse pack
installation. This table is also populated with warehouse pack-specific static data
that is created by your warehouse pack script during a warehouse pack
installation, if applicable.
Table 5. Attribute rule table (AttrRul)
Column name Data type Null Is PK Is FK Attribute name and description
option
CompTyp_Cd CHAR(17) NOT Yes Yes Component Type Code
NULL
AttrTyp_Cd CHAR(17) NOT Yes Yes Attribute Type Code
NULL
AttrRul_Strt_DtTm TIMESTAMP NOT No No Attribute Rule Start DateTime
NULL
When an attribute rule is created, a start
date is assigned (usually the current time
stamp).
AttrRul_End_DtTm TIMESTAMP NOT No No Attribute Rule End DateTime
NULL
When an attribute is created, the end date
is set to Jan 1, 9999 indicating the attribute
rule is valid.
12 Tivoli Data Warehouse Schema Reference
Table 5. Attribute rule table (AttrRul) (continued)
Column name Data type Null Is PK Is FK Attribute name and description
option
AttrRul_Dom_Ind CHAR NOT No No Attribute Rule Domain Indicator
NULL
This flag indicates whether there is a
predefined set of possible values for this
attribute type against this component type.
Valid values are uppercase Y (yes) or N
(no).
AttrTyp_Multi_Val CHAR NULL No No Attribute Multi Value
This flag indicates whether attributes of
this type can hold multiple concurrent
values. Valid values uppercase Y (yes) or N (no).
Attribute type (AttrTyp)
This table defines what types of attributes are valid.
It is populated with common static data that is created in the central data
warehouse by the twh_cdw_data.generic script during a warehouse pack
installation. This table is also populated with warehouse pack-specific static data
that is created by your warehouse pack script during a warehouse pack
installation, if applicable.
Table 6. Attribute type table (AttrTyp)
Column name Data type Null Is PK Is FK Attribute name and description
option
AttrTyp_Cd CHAR(17) NOT Yes No Attribute Type Code
NULL
AttrTyp_Nm VARCHAR(120) NOT No No Attribute Type Name
NULL
MSrc_Corr_Cd CHAR(6) NOT No Yes Measurement Source Code
NULL
For private attribute types, this is the
measurement source code of the warehouse
pack that defined the attribute. For shared
attribute types, this is one of the shared
measurement source codes described in
“Measurement Source” on page 59.
Attribute type relationship (ATypReln)
This table defines what relationships exist between attribute types.
It is populated with warehouse pack-specific static data that is created in the
central data warehouse by your warehouse pack script during a warehouse pack
installation, if applicable.
Chapter 2. Central data warehouse schema 13
Table 7. Attribute type relationship table (ATypReln)
Column name Data type Null Is PK Is FK Attribute name and description
option
ATyp_Source_Cd CHAR(17) NOT Yes Yes Attribute Type Source Code
NULL
ATyp_Target_Cd CHAR(17) NOT Yes Yes Attribute Type Target Code
NULL
RelnTyp_Cd CHAR(6) NOT Yes Yes Relationship Type Code
NULL
ATReln_Strt_DtTm TIMESTAMP NOT Yes No Attribute Type Relationship Start DateTime
NULL
When an attribute type relationship is
created, a start date is assigned (usually the
current time stamp).
ATReln_End_DtTm TIMESTAMP NOT No No Attribute Type Relationship End DateTime
NULL
When an attribute is created, the end date
is set to Jan 1, 9999 indicating the attribute
type relationship is valid.
Center (Centr)
This table defines a facility or location that delivers services to customers, for
example, Tivoli-Austin or Tivoli-Raleigh.
It is populated with static data that is created in the central data warehouse by a
script when Tivoli Data Warehouse is installed. If the warehouse pack is installed
in a multiple center environment, the users that install the warehouse pack update
this table to describe their specific environment.
Table 8. Center table (Centr)
Column name Data type Null Is PK Is FK Attribute name and description
option
Centr_Cd CHAR(6) NOT Yes No Center Code
NULL
Centr_Parent_Cd CHAR(6) NULL No No Center Parent Code
GeoArea_Cd CHAR(6) NULL No Yes Geographic Area Code
TmZon_ID INTEGER NOT No Yes Time Zone ID
NULL
Centr_Nm VARCHAR(120) NOT No No Center Name
NULL
Component (Comp)
Components are instances of component types. For example, a specific host name
(CompName=jdoe.dev.tivoli.com) is an instance of the component type HOST
(CompTyp_Cd=HOST ).
Components are the actual resources, such as individual workstations, bridges,
routers, hubs, applications, servers, and so on. Components are usually organized
in PCHILD hierarchies. The measurement is attached to the leaf component, or the
last child in the PCHILD hierarchy. For example, consider a router as a component.
14 Tivoli Data Warehouse Schema Reference
A router typically has multiple physical interfaces, such as asynchronous transfer
mode (ATM) interfaces. Each of the ATM interfaces is a child component of the
router component. Each ATM interface might have child components of its own
such as asynchronous transfer mode permanent virtual circuits (ATM PVCs). So, a
source application that reports measurement data on ATM PVCs needs to create
components for the router, the ATM interfaces, and the ATM PVCs, and store the
measurement against the specific ATM PVC component.
The Component (Comp) table hierarchies are created using relationships between
components. One important relationship in which every component takes part is
the naming or PCHILD relationship.
The component names in the Comp_Nm column must uniquely identify the
component within the context of the parent. For example, the actual asynchronous
transfer mode interface on a router is typically identified by a number, such as the
number 13. So 13 is used as the component name for the asynchronous transfer
mode interface.
The following rules are associated with the component table:
v Whenever possible, avoid the use of composite names in the Comp_Nm column.
For example, in the router example, use 13 as the Comp_Nm and not
terps.maryland.cp.edu-13.
v Because the component names are displayable strings, use names that make
sense to the user. Do not use a key or some unique identifier that is not
generally known to the user for the component name. The name of a component
makes it easy to relate the information in the central data warehouse back to the
physical resource or to information in the user interface of the source
application.
v Do not delete components from the central data warehouse. When a component
is no longer needed (for example, when a computer is scrapped), use the
Comp_End_DtTm column to indicate when the resource was deleted or
changed. By keeping the component, warehouse packs can continue to report on
historical data for that component.
v To rename a component, use one of the following techniques:
– If the component is frequently renamed, change the component name
(Comp_Nm). A trigger automatically updates the name attribute and
preserves the historical representation of the component name over time.
– If the component is rarely renamed because name changes are disruptive,
expire the original component by setting the Comp_End_DtTm and then
create a new component. An example of a rare and disruptive change is
renaming the component that represents a web site.
This table defines the component data. It is populated with warehouse
pack-specific dynamic data that is loaded into the central data warehouse by your
warehouse pack script during an ETL process. The twh_cdw_data.generic script
does not update the Component (Comp) table.
Chapter 2. Central data warehouse schema 15
Table 9. Component table (Comp)
Column name Data type Null Is PK Is FK Attribute name and description
option
Comp_ID INTEGER NOT Yes No Component ID
NULL
This ID is an ascending sequence number that
is generated by the DB2 relational database
management system (RDBMS) when you
CompTyp_Cd CHAR(17) NOT No Yes Component Type Code
NULL
This is the key to the CompTyp table.
Centr_Cd CHAR(6) NULL No Yes Center Code
The default value is CDW. You can create
centers as a way of interpreting your data.
For example, if you were a service provider,
you might have a center in New York and one
in San Francisco. In this case, you would look
up each center by host name, since host
names are associated with centers and all the
data associated with the host names are also
associated with the related centers.
Cust_ID INTEGER NULL No Yes Customer ID
The suggested default value is 1, which
indicates this is a central data warehouse
customer. Use the Customer ID in
combination with the Center Code to filter
data. For example, the New York center has
customers Ford and IBM.
Comp_Corr_ID INTEGER NULL No No Component Correlation ID
Comp_Corr_ID is a column that an
application can optionally use in a central data
warehouse ETL to correlate a component to its
parent. The value, if present, should be the
same as the Comp_ID value of the parent in
the central data warehouse database. The
comp_corr_id column can be used only if the
component in question has a single parent, as
defined by the relevant PCHILD relationships.
Note: If a second PCHILD relationship is
defined for a component, this column must be
re-initialized to zero.A data mart ETL cannot
use this column.
16 Tivoli Data Warehouse Schema Reference
Table 9. Component table (Comp) (continued)
Column name Data type Null Is PK Is FK Attribute name and description
option
Comp_Nm VARCHAR NOT No No Component Name
(254) NULL
The Comp_Nm must be a displayable or
readable string. The name should uniquely
identify the component within the context of
the component’s parent.
For standard Component Types, the
Comp_Nm must follow the naming
convention for that CompTyp_Cd. For
example, the Comp_Nm column for all
components with a CompTyp_Cd = IP_HOST
must be set to the fully qualified host name.
A component name is not typically a
composite name. For example, do not name a
component Router XYZ - Port 23. Create
unique components for both Router XYZ and
for Port 23, with a naming scope relationship
of PCHILD between the components.
Comp_Corr_Val VARCHAR NULL No No Component Correlation Value
(254)
Comp_Corr_Val is a column that an
application can optionally use in a central data
warehouse ETL during the creation of a
component. This column uniquely identifies a
component and correlates it to information in
the source application’s database. This column
is a free space for component types that are
defined in an application’s static script. If the
component type is defined in a common
script, such as the twh_cdw_data.generic
script, then the following conditions apply:
v The central data warehouse ETL cannot
search on the Comp_Corr_Val column
because if a component is shared, the ETL
cannot assume that this value pertains to
any one warehouse pack. If an application
needs to determine if the component is
shared, it can join the Comp table with the
CompReln table, where the COMP.CompId
equals either the Comp_Source_Id or the
Comp_Target_Id and the MSrc_Corr_Cd.
v If the shared component does not exist,
then applications may use this column as an
initial free space.
Comp_Strt_DtTm TIMESTAMP NOT No No Component Start DateTime
NULL
When a component is created, a start date is
assigned (usually the current time stamp).
Chapter 2. Central data warehouse schema 17
Table 9. Component table (Comp) (continued)
Column name Data type Null Is PK Is FK Attribute name and description
option
Comp_End_DtTm TIMESTAMP NOT No No Component End DateTime
NULL
The end date is when the component is placed
out of service; for example, when a PC
becomes obsolete and is marked as expired.
The Comp_End_DtTm should not be set for
components that use a standard component
type. The standard component types are
shared components and applications should
not expire shared components.
Expiring a component: When a component is
created, the end date is set to Jan 1, 9999
indicating it is valid.
Comp_Ds VARCHAR NULL No No Component Description
(254)
This is an optional description, which is a
displayable and readable string that can be
displayed on printed reports; for example,
John Henry’s primary PC.
MSrc_Cd CHAR(6) NULL No Yes Measurement Source Code
For private components, this is the
measurement source code of the warehouse
pack that defined the component. For shared
components, this is SHARED.
Component attribute (CompAttr)
Component attributes, which are recorded in the Component Attribute (CompAttr)
table, can be used to store additional information that helps describe a particular
component.
For example, you can use the OS_VERSION component attribute to indicate what
version of an operating system is being used by a particular host component.
The following guidelines are associated with component attributes:
v For IP_HOST components, use the last known IP address (AttrTyp_Cd =
LAST_IP_ADDRESS) as the attribute to save the IP_ADDRESS.
v If the IP address of a particular IP_HOST component changes, update the last
known IP address attribute, if it is available. With the Dynamic Host
Configuration Protocol (DHCP), the IP address can change for a given fully
qualified host name. When a warehouse pack updates the central data
warehouse, the assumption is that the warehouse pack typically has more recent
data than the central data warehouse. So if the value of the LAST_IP_ADDRESS
attribute does not match the IP address in the source application, it is likely that
DHCP assigned a new IP address.
v In addition to storing the name of a component in the Comp_Nm field of the
component table, store the name of the component in the NAME attribute.
Storing the name as an attribute allows data mart ETLs to retrieve past values of
the name (if the name changes) and allows central data warehouse ETLs to track
the changes in names over time.
18 Tivoli Data Warehouse Schema Reference
v Remember that for the IP_HOSTNAME attribute, a fully qualified host name
trumps a short host name. If there is a fully qualified host name in the attribute
field, do not overwrite the attribute value with a short host name.
This table is populated with warehouse pack-specific dynamic data that is loaded
into the central data warehouse by your warehouse pack script during an ETL
process.
The twh_cdw_data.generic script does not update this table.
Table 10. Component attribute table (CompAttr)
Column name Data type Null Is PK Is FK Attribute name and description
option
CompAttr_ID INTEGER NOT Yes No Component Attribute ID
NULL
Comp_ID INTEGER NOT No Yes Component ID
NULL
This ID is an ascending sequence number
that is generated by the DB2 relational
database management system (RDBMS)
when you insert a row.
AttrTyp_Cd CHAR(17) NOT No Yes Attribute Type Code
NULL
This is a key to the AttrTyp table. It
defines what type of attribute is being
collected; for example, INNCPU for the
number of processors on the box.
CompAttr_Strt_DtTm TIMESTAMP NOT No No Component Attribute Start DateTime
NULL
When a component attribute is created, a
start date is assigned (usually the current
time stamp).
CompAttr_End_DtTm TIMESTAMP NOT No No Component Attribute End DateTime
NULL
When a component attribute is created,
the end date is set to Jan 1, 9999
indicating it is valid.
CompAttr_Val VARCHAR(254) NOT No No Component Attribute Value
NULL
Chapter 2. Central data warehouse schema 19
Table 10. Component attribute table (CompAttr) (continued)
Column name Data type Null Is PK Is FK Attribute name and description
option
MSrc_Corr_Cd CHAR(6) NULL No Yes Measurement Source Code
For private component attributes, this is
the measurement source code of the
warehouse pack that inserts the attribute.
For shared component attributes, this is
the measurement source code of the
warehouse pack that inserts the attribute.
However, the behavior depends on
whether the attribute is single or
multi-valued:
v Single valued. In this case, multiple
warehouse packs can update the same
component attribute, each using it own
measurement source code. If the
attribute already exists, the original
attribute is expired.
v Multi-valued. In this case, each
warehouse pack creates a separate
component attribute entry, using its
own measurement source code.
Component change (Comp_Change)
Do not use this table. It is deprecated in Tivoli Data Warehouse, Version 1.3.
Component event relationship (CEReln)
This table defines what relationships exist between events and components.
It is populated with warehouse pack-specific dynamic data that is loaded into the
central data warehouse by your warehouse pack script during an ETL process. This
table is also populated with dynamic data that is created by a script during an ETL
process, if applicable.
Table 11. Component event relationship table (CEReln)
Column name Data type Null Is PK Is FK Attribute name and description
option
CEReln_ID BIGINT NOT Yes No Component Event Relationship ID
NULL
This column is populated with system
generated data.
Event_ID BIGINT NOT No Yes Event ID
NULL
20 Tivoli Data Warehouse Schema Reference
Table 11. Component event relationship table (CEReln) (continued)
Column name Data type Null Is PK Is FK Attribute name and description
option
Comp_ID INTEGER NOT No Yes Comp ID
NULL
This ID is an ascending sequence number
that is generated by the DB2 relational
database management system (RDBMS)
when you insert a row.
If the component does not exist, ignore this
table. For example, if you get an SAP
Server Up event, but no SAP Server
component exists, ignore this table. Most
event-based applications will not be able to
properly name components.
RelnTyp_Cd CHAR(6) NOT No Yes Relationship Type Code
NULL
MSrc_Cd CHAR(6) NOT No Yes Measurement Source Code
NULL
This is the measurement source code of the
warehouse pack that defined the
component event relationship.
Component event relationship rule (CERelnRul)
This table defines what relationships rules exist between event types and
component types.
It is populated with warehouse pack-specific static data that is created in the
central data warehouse by your warehouse pack script during a warehouse pack
installation, if applicable.
Table 12. Component event relationship rule table (CERelnRul)
Column name Data type Null Is PK Is FK Attribute name and description
option
EventTyp_ID INTEGER NOT Yes Yes Event Type ID
NULL
CompTyp_Cd CHAR(17) NOT Yes Yes Component Type Code
NULL
RelnTyp_Cd CHAR(6) NOT Yes Yes Relationship Type Code
NULL
CERul_Strt_DtTm TIMESTAMP NOT Yes No Component Event Relationship Rule Start
NULL DateTime
When a component event relationship rule
is created, a start date is assigned (usually
the current time stamp).
CERul_End_DtTm TIMESTAMP NOT No No Component Event Relationship Rule End
NULL DateTime
When a component event relationship rule
is created, the end date is set to Jan 1, 9999
indicating it is valid.
Chapter 2. Central data warehouse schema 21
Component extension (Comp_Ext)
This table is used when the value entered in the component name (Comp_Nm)
field is longer than 254 characters.
Table 13. Component extension table (Comp_Ext)
Column name Data type Null Is PK Is FK Attribute name and description
option
Comp_ID INTEGER NOT Yes Yes Component ID
NULL
This ID is an ascending sequence number
that is generated by the DB2 relational
database management system (RDBMS) when
you insert a row.
Comp_Long_Nm VARCHAR NOT No No Component Long Name
(3500) NULL
Comp_Long_Nm is used for component
names that are longer than 254 characters.
You can enter up to 3500 characters in this field.
Component relationship (CompReln)
Component relationships, which are recorded in the Component Relationship
(CompReln) table, can be used to store additional information that helps describe a
particular component. This table defines a connection, logical or physical, between
two separate components such as a server IP card and a switch IP port or a host
FC port and a switch FC port.
The following relationship rules apply only to warehouse packs that need to model
components as a hierarchy. For example, if you have a router with interfaces and
various protocols running over the physical interfaces, then the hierarchy between
the router, interfaces, and protocols needs to be modeled using component
relationships.
v All components that have subcomponents must use the PCHILD relationship
type (RelnTyp_Cd = PCHILD in the RelnTyp table) to model the naming
relationship between the components. When a child component record is created
in the central data warehouse, it should have only one parent. However,
multiple PCHILD parents can be defined in the warehouse pack template as a
way of indicating that the component may be created with one of several
potential parent components. In addition, a component can be defined in an
unlimited number of other non-PCHILD relationships.
v Component names must be unique within the context of the parent component.
v For the PCHILD relationship, warehouse packs must define which types of
components are the parents and which types of components are the children. In
the router example, add a row in the Component Type Relationship table
(CTypReln) where the parent component type (router) is specified in the
CTyp_Source_Cd column and the child component type (ATM interface) is
specified in the CTyp_Target_Cd column. The PCHILD relationship defines
patterns for names in the central data warehouse. In other words, the name of
an ATM interface will always be coupled with a router name to make it
meaningful.
v Any component that has more than one token in its name, such as a table name
comprised of the name of the owner and the name of the table,
ownerName.tableName, must have an entry for the PCHILD relationship in the
22 Tivoli Data Warehouse Schema Reference
Component Relationship table. Using a relationship defined in the Component
Relationship table allows components to have multiple names (parents). Every
name must resolve to a unique component. The relationship has to be defined
before it is used.
Use the PCHILD relationship type code to identify the parent component
relationships. For example, if a router has 13 interfaces, then each interface has a
row in the Component Relationship table where the component ID of the router
is specified as the component source ID, in the Comp_Source_ID column. See
Table 70 on page 65 for more information on PCHILD relationships.
This table is populated with warehouse pack-specific dynamic data that is loaded
into the central data warehouse by your warehouse pack script during an ETL
process. This table is also populated with dynamic data that is created by a script
during an ETL process, if applicable.
The twh_cdw_data.generic script does not create entries in the Component
Relationship (CompReln) table.
Table 14. Component relationship table (CompReln)
Column name Data type Null Is PK Is FK Attribute name and description
option
CompReln_ID INTEGER NOT Yes No Component Relationship ID
NULL
Comp_Source_ID INTEGER NOT No Yes Component Source ID
NULL
Comp_Target_ID INTEGER NOT No Yes Component Target ID
NULL
RelnTyp_Cd CHAR(6) NOT No Yes Relationship Type Code
NULL
CompReln_Strt_DtTm TIMESTAMP NOT No No Component Relationship Start DateTime
NULL
When a component relationship is created,
a start date is assigned (usually the current
time stamp).
CompReln_End_DtTm TIMESTAMP NOT No No Component Relationship End DateTime
NULL
When a component relationship is created,
the end date is set to Jan 1, 9999 indicating
it is valid.
MSrc_Corr_Cd CHAR(6) NULL No Yes Measurement Source Code
For private component relationships, this is
the measurement source code of the
warehouse pack that defines the component
relationship. For shared component
relationships, if both source component
type and target component type are shared,
this value is SHARED. If only one type is
shared, this is the measurement source code
of the warehouse pack that defines the
component relationship.
Chapter 2. Central data warehouse schema 23
Component type (CompTyp)
This table defines the types of components and subcomponents that are managed
by an application, for example, host, database, and event.
Component types represent the type or class of the resource, but not the resource
itself. For example, a server could be a component type and 9.67.241.43 would be
an instance of that server. Share component types as much as possible between
source applications to foster correlation of data. For example, if the resource is
connected to an IP network, use the standard IP_HOST component type, instead of
defining your own component. By using IP_HOST as a standard component type,
measurement data from a number of different sources can be correlated to a single
resource.
This table is populated with common static data that is created in the central data
warehouse by the twh_cdw_data.generic script during a warehouse pack
installation. It is also populated with warehouse pack-specific static data that is
created by your warehouse pack script during a warehouse pack installation, if
applicable.
Table 15. Component type table (CompTyp)
Column name Data type Null option Is PK Is FK Attribute name and description
CompTyp_Cd CHAR(17) NOT NULL Yes No Component Type Code
This is a name that is referenced
by a component to define its type.
It includes values such as
IP_HOST, DATABASE, and so on.
For private component types,
prefix the code with your product
code. For example,
XYZ_PRIVATE_TYPE.
CompTyp_Parent_Cd CHAR(17) NULL No No Component Type Parent Code
This column is reserved. Set it to
NULL.
CompTyp_Nm VARCHAR(120) NOT NULL No No Component Type Name
This is a longer description of the
CompTyp_Cd, for display in
reports.
CompTyp_Strt_DtTm TIMESTAMP NOT NULL No No Component Type Start DateTime
When a component type is
created, a start date is assigned
(usually the current time stamp).
CompTyp_End_DtTm TIMESTAMP NOT NULL No No Component Type End DateTime
When a component is created, the
end date is set to Jan 1, 9999
indicating it is a valid component
type.
24 Tivoli Data Warehouse Schema Reference
Table 15. Component type table (CompTyp) (continued)
Column name Data type Null option Is PK Is FK Attribute name and description
MSrc_Corr_Cd CHAR(6) NOT NULL No Yes Measurement Source Code
For private component types, this
is the measurement source code
of the warehouse pack that
defined the type. For shared
component types, this is one of
the shared measurement source
codes described in “Measurement
Source” on page 59.
Component type keyword (CompTyp_Keyword)
This table provides a search capability for locating component types in the central
data warehouse.
It allows for third parties to assign their own keywords and also for customers to
develop and use customized keywords in their implementation of the Tivoli Data
Warehouse.
This table associates keywords such as database, network, or Web with component
types, instead of component instances in the central data warehouse.
A single component type can have multiple keywords associated with it and the
same keyword can be assigned to different component types. This provides a way
for applications to organize the component types on their user interface. It also
prevents the number of component types from becoming cumbersome.
The Keyword_Parent_Nm column allows you to have a hierarchical grouping of
keywords. For example, the Web keyword can be grouped within the e-business
keyword. This also allows component type keywords to be inherited from the
parent component type.
This table defines what keywords are valid for a component type. It is populated
with warehouse pack-specific static data that is created in the central data
warehouse by your warehouse pack script during a warehouse pack installation, if
applicable.
Table 16. Component type keyword table (CompTyp_Keyword)
Column name Data type Null Is PK Is FK Attribute name and description
option
Keyword_ID INTEGER NOT Yes No Keyword ID
NULL
This column is populated with system
generated data.
CompTyp_Cd CHAR(17) NOT No Yes Component Type Code
NULL
This identifies the component type to
which this keyword is associated.
Keyword_Nm VARCHAR(230) NOT No No Keyword Name
NULL
This is associated with the component
type.
Chapter 2. Central data warehouse schema 25
Table 16. Component type keyword table (CompTyp_Keyword) (continued)
Column name Data type Null Is PK Is FK Attribute name and description
option
Keyword_Parent_Nm VARCHAR(230) NOT No No Keyword Parent Name
NULL
This allows for a hierarchical grouping
of keywords.
Component type relationship (CTypReln)
This table defines what relationships exist between component types.
It is populated with warehouse pack-specific static data that is created in the
central data warehouse by your warehouse pack script during a warehouse pack
installation, if applicable.
Table 17. Component type relationship table (CTypReln)
Column name Data type Null Is PK Is FK Attribute name and description
option
CTyp_Source_Cd CHAR(17) NOT Yes Yes Component Type Source Code
NULL
CTyp_Target_Cd CHAR(17) NOT Yes Yes Component Type Target Code
NULL
RelnTyp_Cd CHAR(6) NOT Yes Yes Relationship Type Code
NULL
CTReln_Strt_DtTm TIMESTAMP NOT Yes No Component Type Relationship Start
NULL DateTime
When a component type relationship is
created, a start date is assigned (usually the
current time stamp).
CTReln_End_DtTm TIMESTAMP NOT No No Component Type Relationship End
NULL DateTime
When a component is created, the end date
is set to Jan 1, 9999 indicating the
component type relationship is valid.
Component type translation (CompTyp_Tran)
This table, along with the Source Component Type (Src_CompTyp) table, enables
the creation of event-component relationships in the Component Event
Relationship table. This table defines what component type translations exist for an
event. For example, when modeling data for an application you might find that
there are several different component types defined for the same purpose. This
table allows you to map these different definitions to one common component
definition, enabling you to share the common component definitions.
Create one row per mapping of each event type, component type, source
component type, and relationship type.
This table is populated with warehouse pack-specific static data by your
warehouse pack script during a warehouse pack installation.
26 Tivoli Data Warehouse Schema Reference
Table 18. Component type translation (CompTyp_Tran)
Column name Data type Null Is PK Is FK Attribute name and description
option
EventTyp_ID BIGINT NOT No Yes Event Type ID
NULL
This is the ID for the event type. This is also
a foreign key to EventTyp.
CompTyp_Cd CHAR(17) NOT No Yes Component Type Code
NULL
This is the code for the component type.
This also is a foreign key to CompTyp.
SrcCompTyp_ID INTEGER NOT No Yes Source Component Type ID
NULL
This is the component type ID as identified
by the source application. This also is a
foreign key to Src_CompTyp.
RelnTyp_Cd CHAR(17) NOT No Yes Relationship Type Code
NULL
This is the code for the relationship type
between the component and event. This also
is a foreign key to RelnTyp.
MSrc_Cd CHAR(6) NOT No Yes Measurement Source Code
NULL
This is the code for the measurement source
application that defines the component type
translation. This is a foreign key to MSrc.
Customer (Cust)
This table contains the information that identifies individual customers in a
multiple customer environment.
It is populated with static data that is created in the central data warehouse by a
script when Tivoli Data Warehouse is installed. If the warehouse pack is installed
in a multiple customer environment, the users that install the warehouse pack
update this table to describe their specific environment.
Table 19. Customer table (Cust)
Column name Data type Null option Is PK Is FK Attribute name and description
Cust_ID INTEGER NOT NULL Yes No Customer ID
Cust_Parent_ID INTEGER NULL No No Customer Parent ID
GeoArea_Cd CHAR(6) NULL No Yes Geographic Area Code
TmZon_ID INTEGER NULL No Yes Time Zone ID
Cust_Acct_Cd CHAR(10) NULL No No Customer Account Code
Cust_Nm VARCHAR(120) NOT NULL No No Customer Name
Chapter 2. Central data warehouse schema 27
Event (Event)
The event tables in the central data warehouse store details about an event
instance. Create a single row in this table for each event that your warehouse pack
supports.
Event instance data has the following characteristics:
v Events happen at a single point in time.
v Events are of a particular event type.
v Event types can belong to any number of event type groups.
v Events can have any number of event attributes.
v Events can be related to any number of other events via event-event
relationships.
v Events can be related to any number of components via component-event
relationships.
An event is a point in time occurrence, whereas a component has a start and end
time.
You use event relationship entries for transactions that go through a number of
states. The start of the transaction event for a given transaction is related to all of
the state events for that transaction.
Simple events such as a change of state of a component can be handled by using
measurements with a time summary code (TmSum_Cd) value of P.
Each record in this table defines an event that has occurred and is of a specific
event type.
It is populated with warehouse pack-specific dynamic data that is loaded into the
central data warehouse by your warehouse pack script during an ETL process. This
table is also populated with dynamic data that is created by a script during an ETL
process, if applicable.
Table 20. Event table (Event)
Column name Data type Null Is PK Is FK Attribute name and description
option
Event_ID BIGINT NOT Yes No Event ID
NULL
This column is populated with system
generated data.
EventTyp_ID INTEGER NOT No Yes Event Type ID
NULL
This column is populated with system
generated data.
Event_DtTm TIMESTAMP NOT No No Event Start DateTime
NULL
When an event is created, a start date is
assigned (usually the current time stamp).
TmSum_Cd CHAR NOT No Yes Time Summary Code
NULL
28 Tivoli Data Warehouse Schema Reference
Table 20. Event table (Event) (continued)
Column name Data type Null Is PK Is FK Attribute name and description
option
Msrc_Cd CHAR(6) NOT No Yes Measurement Source Code
NULL
This column identifies which application
created the event.
Repeat_Cnt INTEGER NULL No No Repeat Count
This is the number of times this event
occurs within this time summary.
Centr_Cd CHAR(6) NULL No Yes Center Code
This is the center code for the multicenter.
Cust_ID INTEGER NULL No Yes Customer ID
Event_Corr_ID INTEGER NULL No No Event Correlation ID
Event_Corr_ID is a column that an
application can optionally use in a central
data warehouse ETL to correlate an event to
its parent. The value, if present, should be
the same as the Event_ID value of the
parent in the central data warehouse
database. The Event_Corr_ID column can be
used only if the event in question has a
single parent, as defined by the relevant
PCHILD relationships. Note: If a second
PCHILD relationship is defined for an
event, this column must be re-initialized to
zero. A data mart ETL cannot use this
column.
Event_Corr_Val VARCHAR(254) NULL No No Event Correlation Value
Event_Corr_Val is a column that an
application can optionally use in a central
data warehouse ETL during the creation of
an event. This column identifies the source
application event that is correlated to this
event. This column is also a free space for
source event types that are defined in an
application’s static script. If the event type
is defined in a common script, such as the
twh_cdw_data.generic script, then the
following conditions apply:
v The central data warehouse ETL cannot
search on the Event_Corr_Val column
because if an event is shared, the ETL
cannot assume that this value pertains to
any one warehouse pack. If an
application needs to determine if the
event is shared, it can join the Event table
with the EventReln table, where the
EVENT.EventId equals either the
Event_Source_Id or the Event_Target_Id
and the MSrc_Corr_Cd.
v If the shared event does not exist, then
applications may use this column as an
initial free space.
Chapter 2. Central data warehouse schema 29
Event attribute (EventAttr)
This table defines what attributes exist for an event.
It is populated with warehouse pack-specific dynamic data that is loaded into the
central data warehouse by your warehouse pack script during an ETL process. This
table is also populated with dynamic data that is created by a script during an ETL
process, if applicable.
Table 21. Event attribute table (EventAttr)
Column name Data type Null Is PK Is FK Attribute name and description
option
EventAttr_ID BIGINT NOT Yes No Event Attribute ID
NULL
This column is populated with system
generated data.
Event_ID BIGINT NOT No Yes Event ID
NULL
AttrTyp_Cd CHAR(17) NOT No Yes Attribute Type Code
NULL
This is a key to the AttrTyp table. It
defines what type of attribute is being
collected; for example, INNCPU for the
number of processors on the box.
Msrc_Cd CHAR(6) NOT No Yes Measurement Source Code
NULL
This column identifies which application
created the event.
EventAttr_Val VARCHAR(254) NOT No No Event Attribute Value
NULL
EventAttr_Long_Val LONGVAR NOT No No Event Attribute Long Value
CHAR(4096) NULL
Use this column for the event attribute
value if the length is greater than 3500. If
you need to use this column, you must
place an empty string in the
EventAttr_Val column.
Event attribute type (EAttrTyp)
This table defines what attribute types exist for an event.
It is populated with warehouse pack-specific dynamic data that is loaded into the
central data warehouse by your warehouse pack script during an ETL process. This
table is also populated with dynamic data that is created by a script during an ETL
process, if applicable.
30 Tivoli Data Warehouse Schema Reference
Table 22. Event attribute type table (EAttrTyp)
Column name Data type Null Is PK Is FK Attribute name and description
option
EAttrTyp_Cd VARCHAR(254) NOT Yes No Event Attribute Type Code
NULL
This is a key to the EAttrTyp table. It
defines what type of event attribute is
being collected. Use private event
attribute types if the event variable
content is unpredictable or unreliable.
EAttrTyp_Nm VARCHAR(254) NOT No No Event Attribute Name
NULL
MSrc_Cd CHAR(6) NOT No Yes Measurement Source Code
NULL
The twh_cdw_data.generic script defines
the standard attribute types. For private
event attribute types, use the MSrc_Cd
value of the application.
Event attribute type translation (EAttrTyp_Tran)
This table, along with the source event attribute type (Src_EAttrTyp) table, enables
the creation of event attributes in the Event Attribute table. This table defines what
event attribute type translations exist for an event. For example, when modeling
data for an application you might find that there are several different attribute
types defined for the same purpose. This table allows you to map these different
definitions to one common attribute type definition, enabling you to use one
common definition in the Tivoli Data Warehouse and still be able to correlate the
events in the central data warehouse back to the events in the source database.
Create one row per mapping of each event type, event attribute type, and source
event attribute type.
Table 23. Event attribute type translation (EAttrTyp_Tran)
Column name Data type Null Is PK Is FK Attribute name and description
option
EventTyp_ID BIGINT NOT No Yes Event Type ID
NULL
This is the ID for the event type. This is
also a foreign key to EventTyp.
EAttrTyp_Cd VARCHAR(254) NOT No Yes Event Attribute Type Code
NULL
This is the code for the event attribute type.
This also is a foreign key to EAttrTyp.
SrcEAttrTyp_ID INTEGER NOT No Yes Source Event Attribute Type ID
NULL
This is the event attribute type ID as
identified by the source application. This
also is a foreign key to Src_CompTyp.
MSrc_Cd CHAR(6) NOT No Yes Measurement Source Code
NULL
This is the code for the measurement source
application that defines the event attribute
type translation. This is a foreign key to MSrc.
Chapter 2. Central data warehouse schema 31
Event group (EGrp)
This table defines what groups are valid for an event group type.
It is populated with warehouse pack-specific static data that is created in the
central data warehouse by your warehouse pack script during a warehouse pack
installation, if applicable.
Table 24. Event group table (EGrp)
Column name Data type Null Is PK Is FK Attribute name and description
option
EGrp_Cd CHAR(6) NOT Yes No Event Group Code
NULL
EGrpTyp_Cd CHAR(6) NOT Yes Yes Event Group Type Code
NULL
EGrp_Parent_Cd CHAR(6) NULL No No Event Group Parent Code
EGrp_Nm VARCHAR(254) NOT No No Event Group Name
NULL
Event group member (EGrpMbr)
This table defines what groups of events are valid for an event type.
It is populated with warehouse pack-specific static data that is created in the
central data warehouse by your warehouse pack script during a warehouse pack
installation, if applicable.
Table 25. Event group member table (EGrpMbr)
Column name Data type Null Is PK Is FK Attribute name and description
option
EGrp_Cd CHAR(6) NOT Yes Yes Event Group Code
NULL
EGrpTyp_Cd CHAR(6) NOT Yes Yes Event Group Type Code
NULL
EventTyp_ID INTEGER NOT Yes Yes Event Type ID
NULL
Event group type (EGrpTyp)
This table defines the valid event group types.
It is populated with warehouse pack-specific static data that is created in the
central data warehouse by your warehouse pack script during a warehouse pack
installation, if applicable.
Table 26. Event group type table (EGrpTyp)
Column name Data type Null Is PK Is FK Attribute name and description
option
EGrpTyp_Cd CHAR(6) NOT Yes No Event Group Type Code
NULL
EGrpTyp_Nm VARCHAR(254) NOT No No Event Group Type Name
NULL
32 Tivoli Data Warehouse Schema Reference
Event relationship (EventReln)
This table defines a relationship, logical or physical, between two events.
It is populated with warehouse pack-specific dynamic data that is loaded into the
central data warehouse by your warehouse pack script during an ETL process. This
table is also populated with dynamic data that is created by a script during an ETL
process, if applicable.
Table 27. Event relationship table (EventReln)
Column name Data type Null Is PK Is FK Attribute name and description
option
EventReln_ID BIGINT NOT Yes No Event Relationship ID
NULL
This column is populated with system
generated data.
Event_Source_ID BIGINT NOT No Yes Event Source ID
NULL
Event_Target_ID BIGINT NOT No Yes Event Target ID
NULL
RelnTyp_Cd CHAR(6) NOT No Yes Relationship Type Code
NULL
Msrc_Cd CHAR(6) NOT No Yes Measurement Source Code
NULL
Event relationship rule (ERelnRul)
This table defines what relationship rules exist between event types.
It is populated with warehouse pack-specific static data that is created in the
central data warehouse by your warehouse pack script during a warehouse pack
installation, if applicable.
Table 28. Event relationship rule table (ERelnRul)
Column name Data type Null Is PK Is FK Attribute name and description
option
ETyp_Source_ID INTEGER NOT Yes Yes Event Type Source ID
NULL
ETyp_Target_ID INTEGER NOT Yes Yes Event Type Target ID
NULL
RelnTyp_Cd CHAR(6) NOT Yes Yes Relationship Type Code
NULL
ERul_Strt_DtTm TIMESTAMP NOT Yes No Event Relationship Rule Start DateTime
NULL
When an event relationship rule is created,
a start date is assigned (usually the current
time stamp).
ERul_End_DtTm TIMESTAMP NOT No No Event Relationship Rule End DateTime
NULL
When an event is created, the end date is
set to Jan 1, 9999 indicating the event
relationship rule is valid.
Chapter 2. Central data warehouse schema 33
Event type (EventTyp)
This table defines what types of events are valid for an event.
Event types can be private to a source application or be a derived common event
type. Each derived event type is associated with a certain data model. MODEL1 is
the common data model for Tivoli. An example of a derived event type is
Attempts To Login. Two different applications can generate events that correspond
to the derived event type Attempts To Login. They also have their own private
names for this event type such as Login Tries and Attempts To Logon. To link
these two private event types to the derived event type, you establish a
relationship between each private and derived event type using the relationship
type code (RelnTyp_Cd) value of DERIVE.
Applications can display the derived event type when one exists, and the private
event type name when no derived event type name exists, using the provided
database view.
This table is populated with warehouse pack-specific static data that is created in
the central data warehouse by your warehouse pack script during a warehouse
pack installation, if applicable.
Table 29. Event type table (EventTyp)
Column name Data type Null Is PK Is FK Attribute name and description
option
EventTyp_ID INTEGER NOT Yes No Event Type ID
NULL
This column is populated with system
generated data.
EventTyp_Nm VARCHAR(254) NOT No No Event Type Name
NULL
MSrc_Cd CHAR(6) NOT No Yes Measurement Source Code
NULL
EventTyp_Ds VARCHAR(254) NULL No No Event Type Description
This column is optional.
Event type relationship (ETypReln)
This table defines what relationships exist between event types.
It is populated with warehouse pack-specific static data that is created in the
central data warehouse by your warehouse pack script during a warehouse pack
installation, if applicable.
Table 30. Event type relationship table (ETypReln)
Column name Data type Null Is PK Is FK Attribute name and description
option
ETyp_Source_ID INTEGER NOT Yes Yes Event Type Source ID
NULL
ETyp_Target_ID INTEGER NOT Yes Yes Event Type Target ID
NULL
34 Tivoli Data Warehouse Schema Reference
Table 30. Event type relationship table (ETypReln) (continued)
Column name Data type Null Is PK Is FK Attribute name and description
option
RelnTyp_Cd CHAR(6) NOT Yes Yes Relationship Type Code
NULL
ETReln_Strt_DtTm TIMESTAMP NOT Yes No Event Type Relationship Start DateTime
NULL
When an event type relationship is created,
a start date is assigned (usually the current
time stamp).
ETReln_End_DtTm TIMESTAMP NOT No No Event Type Relationship End DateTime
NULL
When an event is created, the end date is
set to Jan 1, 9999 indicating the event type
relationship is valid.
Extract control (Extract_Control)
This table defines the extract control data, which is used in extracting data from
the source application database into the central data warehouse.
The table is populated with common static data that is created in the central data
warehouse by the twh_cdw_data.generic script during a warehouse pack
installation. The table is also populated with warehouse pack-specific static data
that is created by your warehouse pack script during a warehouse pack
installation, if applicable. This table is also populated with warehouse pack-specific
dynamic data that is loaded into the central data warehouse by your warehouse
pack script during an ETL process.
Table 31. Extract control table (Extract_Control)
Column name Data type Null option Is PK Is FK Attribute name and description
ExtCtl_Source VARCHAR(120) NOT NULL Yes No Extract Control Source
For multiple sources, append a number
plus a period to the beginning of each
source name in this field. For example,
you might have 1.source and 2.source,
where source indicates the name of the
source.
ExtCtl_Target VARCHAR(120) NOT NULL Yes No Extract Control Target
ExtCtl_From_RawSeq CHAR(10) FOR NULL No No Extract Control From Raw Sequence
BIT DATA
ExtCtl_To_RawSeq CHAR(10) FOR NULL No No Extract Control To Raw Sequence
BIT DATA
ExtCtl_From_IntSeq BIGINT NULL No No Extract Control From Integer Sequence
ExtCtl_To_IntSeq BIGINT NULL No No Extract Control To Integer Sequence
ExtCtl_From_DtTm TIMESTAMP NOT NULL No No Extract Control From Date and Time
ExtCtl_To_DtTm TIMESTAMP NOT NULL No No Extract Control To Date and Time
MSrc_Corr_Cd CHAR(6) NULL No Yes Measurement Source Code
This is the measurement source code of
the warehouse pack that creates the
extract control entry.
Chapter 2. Central data warehouse schema 35
Extract log (Extract_Log)
This table defines the extract log data. Its content is a record of all the extract
operations performed on the source application database.
It is populated with warehouse pack-specific dynamic data that is loaded into the
central data warehouse by your warehouse pack script during an ETL process. This
table is also populated with dynamic data that is created by a script during an ETL
process, if applicable.
Table 32. Extract log table (Extract_Log)
Column name Data type Null option Is PK Is FK Attribute name and description
ExtLog_Source VARCHAR(120) NOT NULL Yes No Extract Log Source
ExtLog_Target VARCHAR(120) NOT NULL Yes No Extract Log Target
ExtLog_Done_DtTm TIMESTAMP NOT NULL Yes No Extract Log Complete Date and
Time
ExtLog_From_RawSeq CHAR(10) FOR NULL No No Extract Log From Sequence
BIT DATA
ExtLog_To_RawSeq CHAR(10) FOR NULL No No Extract Log To Sequence
BIT DATA
ExtLog_From_IntSeq BIGINT NULL No No Extract Log From Sequence
ExtLog_To_IntSeq BIGINT NULL No No Extract Log To Sequence
ExtLog_From_DtTm TIMESTAMP NOT NULL No No Extract Log From Date and Time
ExtLog_To_DtTm TIMESTAMP NOT NULL No No Extract Log To Date and Time
Geographic area (GeoArea)
This table defines a geographic unit such as a country or region, state or province,
or city. It also includes larger areas such as North America (NA), Europe, Middle
East, and Africa (EMEA), and so on, plus smaller divisions such as US West. These
geographic units can be actual geopolitical units, or IBM organizational units.
This table is populated with static data that is created in the central data
warehouse by a script when Tivoli Data Warehouse is installed.
Table 33. Geographic area table (GeoArea)
Column name Data type Null option Is PK Is FK Attribute name and description
GeoArea_Cd CHAR(6) NOT NULL Yes No Geographic Area Code
GeoArea_Parent_Cd CHAR(6) NULL No No Geographic Area Parent Code
GeoTyp_ID INTEGER NULL No Yes Geographic Type ID
TmZon_ID INTEGER NULL No Yes Time Zone ID
GeoArea_Nm VARCHAR(120) NOT NULL No No Geographic Area Name
Geographic type (GeoTyp)
This table defines a standard type for geographic areas, for example, region,
country, state or province, or city.
36 Tivoli Data Warehouse Schema Reference
It is populated with static data that is created in the central data warehouse by a
script when Tivoli Data Warehouse is installed.
Table 34. Geographic type table (GeoTyp)
Column name Data type Null Is PK Is FK Attribute name and description
option
GeoTyp_ID INTEGER NOT Yes No Geographic Type ID
NULL
GeoTyp_Nm VARCHAR(120) NOT No No Geographic Type Name
NULL
Measurement (Msmt)
Source applications can use a variety of measurement tables to define
measurements.
The following rules are associated with all measurement tables:
v With the exception of P (point in time) data, hourly data is summarized on the
beginning (top) of the hour, daily data at midnight, weekly data at the end of
the week (this changes for localities that use Monday as the first day of the
week), monthly at midnight on the last day of the month, and so on. For
example, hourly data is summarized starting at the top of the hour (1 a.m., 2
a.m., and so on) and not 2:43 a.m., 3:43 a.m., and so on. See “Time Summary” on
page 70 for more details.
v Supported measurement granularities are listed in the time summary (TmSum)
table. See “Time Summary” on page 70 for more information.
v Put a measurement in the total column (Msmt_Tot_Val) if you add values
together from hourly data to make daily data. Use the minimum, maximum, and
average columns (Msmt_Min_Val, Msmt_Max_Val, and Msmt_Avg_Val) if you
average hourly values to get values for a day. For example, a counter for the
total number of users that logged on to an application is reported in the
Msmt_Tot_Val column. The value represents the total for that hour (5 users
logged on to the application), but the hourly measurements could be totaled for
a day to produce a daily total.
Data such as percentages and average response times should not be reported in
the Msmt_Tot_Val column. For example, totaling percentages produces values
that are not valid. The percentage data is reported in the Msmt_Avg_Val column
so that all the hourly percentages are averaged together.
v Measurements must include values for the Msmt_Smpl_Cnt and Msmt_Err_Cnt
columns if this data is available to the source application. If a source application
does not support Sample Count (Msmt_Smpl_Cnt) and Error Count
(Msmt_Err_Cnt), then a value of NULL is reported. Zero values indicate that
there were no samples or no errors for the interval. NULL values indicate that
the source application does not support these columns.
Total number of samples is the sum of Sample Count (Msmt_Smpl_Cnt) plus
Error Count (Msmt_Err_Cnt).
v Response time measurements must include values for the Msmt_Min_Val,
Msmt_Max_Val, Msmt_Avg_Val, Msmt_Smpl_Cnt, and Msmt_Err_Cnt columns,
assuming that the Msmt_Smpl_Cnt and Msmt_Err_Cnt column data is available.
v All data, except for P (point in time) data, must be summarized into hourly data
before saving the data in the central data warehouse. If data is available only in
time intervals larger than an hour, then what is available is used. If data is
available in smaller time intervals, it needs to be summarized to hourly.
Chapter 2. Central data warehouse schema 37
v Measurements for response time and utilization data needs to be reported only
if there is measurement data for that interval. For example, if a probe monitors
e-mail response time from 8 a.m. to 4 p.m., then only measurement data from 8
a.m. to 4 p.m. needs to be saved in the measurement table. Source applications
do not have to report measurements with zero values and zero sample counts
from midnight to 8 a.m. and from 4 p.m. to midnight.
v Determine whether MIN_E, MAX_E, and AVG_E are all valid and contain
meaningful data for the measurement data. If so, report all three values in the
measurement table, unless the measurement data is TOT_E. If all three values
are reported in the measurement table, there must be three rows in the
Measurement Group table for MIN_E, MAX_E, and AVG_E for that
measurement type.
There might be rare cases where you cannot provide all three values. For each
value that is reported, a corresponding row exists in the Measurement Group
Member table that indicates which value will be reported by the central data
warehouse ETL.
v A measurement typically contains TOT_E or AVG_E, not both.
The following conventions are useful for measurement tables:
v Save the measurement data with a single time summary code. For example, if
the data is summarized as hourly measurements, then do not save daily
measurements in the central data warehouse. If daily data is needed, then the
hourly measurements can be used to determine the daily data. Saving the same
data as hourly, daily, monthly, and so on, takes up additional disk space without
adding value. See “Time summary (TmSum)” on page 55 for more information.
v Note that response time measurements include only successful data points, and
do not include response data for failed or canceled data points.
This table is populated with warehouse pack-specific dynamic data that is loaded
into the central data warehouse by your warehouse pack script during an ETL
process. This table is also populated with dynamic data that is created by a script
during an ETL process, if applicable. The twh_cdw_data.generic script does not
update the Measurement (Msmt) table.
Table 35. Measurement table (Msmt)
Column name Data type Null Is PK Is FK Attribute name and description
option
Msmt_ID BIGINT NOT Yes No Measurement ID
NULL
Comp_ID INTEGER NOT No Yes Component ID
NULL
This ID is the link to the Comp table and is
an ascending sequence number that is
generated by the DB2 relational database
management system (RDBMS) when you
insert a row.
MsmtTyp_ID INTEGER NOT No Yes Measurement Type ID
NULL
TmSum_Cd CHAR NOT No Yes Time Summary Code
NULL
Msmt_Strt_Dt DATE NOT No No Measurement Start Date
NULL
Msmt_Strt_Tm TIME NOT No No Measurement Start Time
NULL
38 Tivoli Data Warehouse Schema Reference
Table 35. Measurement table (Msmt) (continued)
Column name Data type Null Is PK Is FK Attribute name and description
option
Msmt_Min_Val FLOAT NULL No No Measurement Minimum Value
This Measurement Minimum Value is
usually used in conjunction with the
Measurement Maximum Value and the
Measurement Average Value.
Msmt_Max_Val FLOAT NULL No No Measurement Maximum Value
This Measurement Maximum Value is
usually used in conjunction with the
Measurement Minimum Value and the
Measurement Average Value.
Msmt_Avg_Val FLOAT NULL No No Measurement Average Value
This Measurement Average Value is usually
used in conjunction with the Measurement
Minimum Value and the Measurement
Maximum Value.
Msmt_StdDev_Val FLOAT NULL No No Measurement Standard Deviation Value
This is the standard deviation value for the
measurement.
Msmt_Tot_Val FLOAT NULL No No Measurement Total Value
This Measurement Total Value is usually
used exclusive of the Measurement
Minimum Value, Measurement Maximum
Value, and Measurement Average Value. In
the MGrpMbr table, you indicate what
Measurements have an average, minimum,
or maximum value versus a total value.
Msmt_Smpl_Cnt INTEGER NULL No No Measurement Sample Count
Msmt_Smpl_Cnt should include successful
data points only. It should not include data
points included in Msmt_Err_Cnt. If the
number of samples is unknown, leave this
column NULL.
Msmt_Err_Cnt INTEGER NULL No No Measurement Error Count
This is the number of measurement errors
for a specified interval. Msmt_Err_Cnt
should be the number of failed and
cancelled data points (attempted data
points = Msmt_Smpl_Cnt +
Msmt_Err_Cnt). If the number of errors is
unknown, leave this column NULL.
MSrc_Corr_Cd CHAR(6) NULL No Yes Measurement Source Code
This is the code for the measurement
source application that inserts the measurement.
Chapter 2. Central data warehouse schema 39
Measurement group (MGrp)
This table defines the categories into which you can group measurement types.
Measurements can be grouped in various ways. For example, they can be grouped
into categories such as:
Capacity
Component capacity
Size Component size
Configuration
How components are configured
Availability
Uptime for a component
Utilization
Component consumption such as processor, disk space, or bandwidth
Errors Error rates such as downtime, packet loss, or collisions
Performance
How well the component is able to perform its function
Measurements can also be grouped into monitoring collections; that is,
measurements that are collected together as part of a particular monitoring activity.
You create measurement groups to help organize the measurement types. A
measurement can be in multiple groups and a warehouse pack can create as many
measurement groups as necessary to help organize the measurement types. For
example, a source application might have some best practices measurement types
that are always monitored as a default value. A measurement group could be
created that groups all the measurement types included in the best practices
profile.
You associate which types of measurements are associated with the group in the
Measurement Group Member (MGrpMbr) table. See “Measurement group member
(MGrpMbr)” on page 41.
All warehouse packs that put measurements into the central data warehouse are
required to use standard measurement groups so that applications performing
higher-level correlation know what data is to be expected from the source
application.
It is populated with common static data that is created in the central data
warehouse by the twh_cdw_data.generic script during a warehouse pack
installation. This table is also populated with warehouse pack-specific static data
that is created by your warehouse pack script during a warehouse pack
installation, if applicable.
Table 36. Measurement group table (MGrp)
Column name Data type Null Is PK Is FK Attribute name and description
option
MGrp_Cd CHAR(6) NOT Yes No Measurement Group Code
NULL
MGrpTyp_Cd CHAR(6) NOT Yes Yes Measurement Group Type Code
NULL
40 Tivoli Data Warehouse Schema Reference
Table 36. Measurement group table (MGrp) (continued)
Column name Data type Null Is PK Is FK Attribute name and description
option
MGrp_Parent_Cd CHAR(6) NULL No No Measurement Group Parent Code
MGrp_Nm VARCHAR(120) NOT No No Measurement Group Name
NULL
Measurement group member (MGrpMbr)
This table defines what groups of measurements are valid for a measurement type.
A measurement type can be a member of several measurement groups.
The table is populated with warehouse pack-specific static data that is created in
the central data warehouse by your warehouse pack script during a warehouse
pack installation, if applicable.
Table 37. Measurement group member table (MGrpMbr)
Column name Data type Null Is PK Is FK Attribute name and description
option
MGrp_Cd CHAR(6) NOT Yes Yes Measurement Group Code
NULL
MGrpTyp_Cd CHAR(6) NOT Yes Yes Measurement Group Type Code
NULL
MsmtTyp_ID INTEGER NOT Yes Yes Measurement Type ID
NULL
The following rules apply to the measurement group member table:
v For each measurement type that can contain a minimum, maximum, total, or
average value in the Measurement table, you must create a row in the
Measurement Group Member table that contains the measurement type ID and
the corresponding measurement group code. Table 38 shows the measurement
group code that corresponds to the columns in the measurement table.
Table 38. Mapping measurements in the Msmt table columns to MGrp_Cd columns in the
MGrpMbr table
Type of data Msmt table column name MGrp_Cd required in
MGrpMbr table
Minimum Msmt_Min_Val MIN_E
Maximum Msmt_Max_Val MAX_E
Total Msmt_Tot_Val TOT_E
Average Msmt_Avg_Val AVG_E
For example, if the measurement type that is assigned ID 14 can contain
minimum, maximum, and average values, but not a total, you create the rows
shown in Table 39 in the Measurement Group Member table for that
measurement type:
Table 39. Sample measurement group member (MGrpMbr table) MGrp_Cd MGrpTyp_Cd MsmtTyp_ID
CHAR(6) CHAR(6) INTEGER
MIN_E GROUP 14
Chapter 2. Central data warehouse schema 41
Table 39. Sample measurement group member (MGrpMbr table) (continued) MGrp_Cd MGrpTyp_Cd MsmtTyp_ID
CHAR(6) CHAR(6) INTEGER
MAX_E GROUP 14
AVG_E GROUP 14
You create rows in the Measurement Group Member table to associate which types
of measurements are associated with the group. In the following example, the
Average CPU Busy measurement type is a member of groups MIN_E, MAX_E, and
AVG_E. The Number of Runs measurement type is a member of group TOT_E.
insert into twg.mgrpmbr
(MGrp_Cd, MGrpTyp_Cd, MsmtTyp_ID)
select ’MIN_E’,’GROUP’, mt.MsmtTyp_ID from TWG.MsmtTyp mt
where MsmtTyp_Nm in ( ’Average CPU Busy’);
insert into twg.mgrpmbr
(MGrp_Cd, MGrpTyp_Cd, MsmtTyp_ID)
select ’MAX_E’,’GROUP’, mt.MsmtTyp_ID from TWG.MsmtTyp mt
where MsmtTyp_Nm in ( ’Average CPU Busy’);
insert into twg.mgrpmbr
(MGrp_Cd, MGrpTyp_Cd, MsmtTyp_ID)
select ’AVG_E’,’GROUP’, mt.MsmtTyp_ID from TWG.MsmtTyp mt
where MsmtTyp_Nm in ( ’Average CPU Busy’);
insert into twg.mgrpmbr
(MGrp_Cd, MGrpTyp_Cd, MsmtTyp_ID)
select ’TOT_E’,’GROUP’, mt.MsmtTyp_ID from TWG.MsmtTyp mt
where MsmtTyp_Nm in ( ’Number of Runs’ );
Measurement group type (MGrpTyp)
This table defines the valid measurement groups.
It is populated with common static data that is created in the central data
warehouse by the twh_cdw_data.generic script during a warehouse pack
installation. This table is also populated with warehouse pack-specific static data
that is created by your warehouse pack script during a warehouse pack
installation, if applicable.
Table 40. Measurement group type table (MGrpTyp)
Column name Data type Null Is PK Is FK Attribute name and description
option
MGrpTyp_Cd CHAR(6) NOT Yes No Measurement Group Type Code
NULL
MGrpTyp_Nm CHAR(120) NOT No No Measurement Group Type Name
NULL
Measurement rule (MsmtRul)
This table defines what measurement types are valid for each component type. For
most measurement types there is a single row in this table that associates a
measurement type, such as packet loss, to a particular component type (for
example, router interface). Some measurement types have multiple rows. There
must be a measurement rule for each valid combination of measurement type and
component type.
42 Tivoli Data Warehouse Schema Reference
The following example defines that IP_HOST components can have measurements
of type Available:
insert into twg.msmtrul
(CompTyp_Cd, MsmtTyp_ID)
select ’IP_HOST’, mt.MsmtTyp_ID from twg.msmttyp mt
where MsmtTyp_Nm in (’Available’)
;
The MsmtTyp_ID column in the Measurement Rule (MsmtRul) table contains the
integer that was assigned when the measurement type was defined. For rules
associated with all measurement tables, see “Measurement (Msmt)” on page 37.
If the common static data script does not define a rule for the combination your
warehouse pack needs, create a rule in your warehouse pack-specific static data
file, productCode_cdw_data.generic.
This table is populated with common static data that is created in the central data
warehouse by the twh_cdw_data.generic script during a warehouse pack
installation. It is also populated with warehouse pack-specific static data that is
created by your warehouse pack script during a warehouse pack installation, if
applicable.
Table 41. Measurement rule table (MsmtRul)
Column name Data type Null Is PK Is FK Attribute name and description
option
CompTyp_Cd CHAR(17) NOT Yes Yes Component Type Code
NULL
MsmtTyp_ID INTEGER NOT Yes Yes Measurement Type ID
NULL
Measurement source (MSrc)
This table defines the source of a measurement.
It is populated with common static data that is created in the central data
warehouse by the twh_cdw_data.generic script during a warehouse pack
installation. This table is also populated with warehouse pack-specific static data
that is created by your warehouse pack script during a warehouse pack
installation, if applicable.
Table 42. Measurement source table (MSrc)
Column name Data type Null Is PK Is FK Attribute name and description
option
MSrc_Cd CHAR(6) NOT Yes No Measurement Source Code
NULL
This is the product code for the warehouse
pack that collected the measurement.
MSrc_Parent_Cd CHAR(6) NULL No No Measurement Source Parent Code
If the MSrc_Parent_Cd is not NULL, there
must be a corresponding row in the MSrc
table for that parent.
MSrc_Nm VARCHAR(120) NOT No No Measurement Source Name
NULL
Chapter 2. Central data warehouse schema 43
Measurement source history (MSrc_History)
This table contains a record of previous values of a measurement source code. This
table is populated by a trigger.
Table 43. Measurement source history table (MSrc_History)
Column name Data type Null Is PK Is FK Attribute name and description
option
MSrc_Cd CHAR(6) NOT Yes Yes Measurement Source Code
NULL
This is the code for the measurement
source application that defines the
measurement source history.
MSrc_Nm VARCHAR(120) NOT No No Measurement Source Name
NULL
MSrc_Strt_DtTm TIMESTAMP NOT Yes No Measurement Source Start DateTime
NULL
When a measurement source is created, a
start date is assigned (usually the current
time stamp).
MSrc_End_DtTm TIMESTAMP NOT No No Measurement Source End DateTime
NULL
When a measurement is created, the end
date is set to Jan 1, 9999 indicating the
measurement source is valid.
Measurement type (MsmtTyp)
This table defines what types of measurements are valid for a component type.
Measurement types are the types of data that source applications use to manage
resources. Examples are response time and memory usage.
It is populated with common static data that is created in the central data
warehouse by the twh_cdw_data.generic script during a warehouse pack
installation. This table is also populated with warehouse pack-specific static data
that is created by your warehouse pack script during a warehouse pack
installation, if applicable.
Table 44. Measurement type table (MsmtTyp)
Column name Data type Null Is PK Is FK Attribute name and description
option
MsmtTyp_ID INTEGER NOT Yes No Measurement Type ID
NULL
This value is a sequence number that is
created by a trigger when you insert a row
of data.
MUnit_Cd CHAR(6) NOT No Yes Measurement Unit Code
NULL
MSrc_Cd CHAR(6) NOT No Yes Measurement Source Code
NULL
This is the code for the measurement source
application that defines the measurement
type.
MsmtTyp_Nm VARCHAR(120) NOT No No Measurement Type Name
NULL
44 Tivoli Data Warehouse Schema Reference
Table 44. Measurement type table (MsmtTyp) (continued)
Column name Data type Null Is PK Is FK Attribute name and description
option
MsmtTyp_Ds VARCHAR(254) NULL No No Measurement Type Description
Measurement type relationship (MTypReln)
This table defines relationships between measurement types. Create a single row in
this table for each relationship that your warehouse pack supports.
The table provides the following functionality:
v Source applications can use one measurement type name (MsmtTyp_Nm) while
consuming applications use another name to refer to the same item. For
example, a data mart that needs to show the units on its console can use
AvailKBytes for a measurement type name. At the same time, a consuming
application uses Available Disk Space for the measurement type name with a
measurement unit code (MUnitCd) of KB.
v Two or more source applications can use the same logical metric that a
consuming application would display as a common name. For example, Oracle
and Siebel use Oracle_Percent_Available and Siebel_Percent_Available, which
display as Percent Available.
v When a single source application changes the name of a measurement type
between releases, this table enables migration of reports and storage logic arrays
(SLAs) built using the older names.
v Two measurement source codes (MSrc_Cd) can be associated with a single
logical measurement type (MsmtTyp). One indicates that it is a standardized
measurement type while the other indicates which source application provides
the measurements.
This table is populated with warehouse pack-specific static data that is created in
the central data warehouse by your warehouse pack script during a warehouse
pack installation, if applicable.
Table 45. Measurement type relationship table (MTypReln)
Column name Data type Null Is PK Is FK Attribute name and description
option
MTyp_Source_ID INTEGER NOT Yes Yes Measurement Type Source ID
NULL
MTyp_Target_ID INTEGER NOT Yes Yes Measurement Type Target ID
NULL
RelnTyp_Cd CHAR(6) NOT Yes Yes Relationship Type Code
NULL
MTReln_Strt_DtTm TIMESTAMP NOT Yes No Measurement Type Relationship Start
NULL DateTime
When a measurement type relationship is
created, a start date is assigned (usually the
current time stamp).
Chapter 2. Central data warehouse schema 45
Table 45. Measurement type relationship table (MTypReln) (continued)
Column name Data type Null Is PK Is FK Attribute name and description
option
MTReln_End_DtTm TIMESTAMP NOT No No Measurement Type Relationship End
NULL DateTime
When a measurement type relationship is
created, the end date is set to Jan 1, 9999
indicating the measurement type
relationship is valid.
Measurement unit (MUnit)
This table defines the measurement units that are available.
It is populated with common static data that is created in the central data
warehouse by the twh_cdw_data.generic script during a warehouse pack
installation.
Table 46. Measurement unit table (MUnit)
Column name Data type Null Is PK Is FK Attribute name and description
option
MUnit_Cd CHAR(6) NOT Yes No Measurement Unit Code
NULL
MUnitCat_Cd CHAR(6) NULL No Yes Measurement Unit Category Code
MUnit_Nm VARCHAR(120) NOT No No Measurement Unit Name
NULL
Measurement unit category (MUnitCat)
A measurement unit category is a high level classification of measurements such
as:
Time duration
The amount of time required to perform an activity
Percentage
A ratio comparing one time or quantity against another
Quantity
A unit count associated with an activity; for example, bytes transferred
Rate A quantity over a fixed time period
This table defines what measurement unit categories are valid for a measurement
type.
It is populated with common static data that is created in the central data
warehouse by the twh_cdw_data.generic script during a warehouse pack
installation.
46 Tivoli Data Warehouse Schema Reference
Table 47. Measurement unit category table (MUnitCat)
Column name Data type Null Is PK Is FK Attribute name and description
option
MUnitCat_Cd CHAR(6) NOT Yes No Measurement Unit Category Code
NULL
MUnitCat_Nm VARCHAR(120) NOT No No Measurement Unit Category Name
NULL
Measurement unit conversion (MUnitCnv)
Do not use this table. It is deprecated in Tivoli Data Warehouse, Version 1.3.
Measurement unit subunit (MUnitSub)
This table defines the decomposition of a Measurement Unit into smaller units. It
can be used to convert measurements into corresponding measurement units for
correlation. For example, Bps (Bytes per second) breaks into bytes and seconds.
This table is populated with warehouse pack-specific static data that is created in
the central data warehouse by your warehouse pack script during a warehouse
pack installation, if applicable.
Table 48. Measurement unit subunit table (MUnitSub)
Column name Data type Null Is PK Is FK Attribute name and description
option
MUnit_Parent_Cd CHAR(6) NOT Yes No Measurement Unit Parent Code
NULL
MUnit_Sub_Cd CHAR(6) NOT Yes Yes Measurement Unit Subunit code
NULL
Prune event control (Prune_Event_Ctrl)
Because event data is expected to occur in high volume, Tivoli Data Warehouse
provides the prune event functionality to enable you to manage this event data.
This includes a prune event control (Prune_Event_Ctrl) table and a deletion
(pruning) step (CDW_c05_s010_Prune_Events) that is provided in the
CDW_c05_Prune_and_Mark_Active process.
This ETL step deletes data for a given event source code (eventsrc_cd) when the
date and time field for a data record is earlier than the current date and time (in
UTC) minus the prune age (prune_age) number of days. You can use the ETL
deletion step to perform the following tasks:
v Delete all rows in the Event table based on the event date and time
(Event_DtTm)
v Delete all rows in the EventAttr table based on the event date and time
(Event_DtTm) derived from the parent event
v Delete all rows in the EventReln table based on the event date and time
(Event_DtTm) derived from the newer of the source or target events
v Delete all rows in the CEReln table based on the event date and time
(Event_DtTm) derived from the event
Another table called prune event log keeps a history of all pruning activity.
Chapter 2. Central data warehouse schema 47
The prune event control table defines when data is deleted from the event tables.
This table is populated with static data that is created in the central data
warehouse by a script when Tivoli Data Warehouse is installed.
Table 49. Prune event control table (Prune_Event_Ctrl)
Column name Data type Null option Is PK Is FK Attribute name and
description
MSrc_Cd CHAR(6) NOT NULL Yes Yes Measurement Source Code
TmSum_Cd CHAR NOT NULL Yes Yes Time Summary Code
Event_Age DECIMAL(8, 0) NOT NULL No No Event Age
This is the age at which
events are pruned (date
duration yyyymmdd).
Prune event log (Prune_Event_Log)
This table records when data is deleted from the event tables and provides a
history of all pruning activity.
It is populated with warehouse pack-specific dynamic data that is loaded into the
central data warehouse by your warehouse pack script during an ETL process.
Table 50. Prune event log table (Prune_Event_Log)
Column name Data type Null Is PK Is FK Attribute name and description
option
Prune_Run_DtTm TIMESTAMP NOT No No Prune Run Date Time
NULL
This is the timestamp of the pruning action.
TmSum_Cd CHAR NULL No Yes Time Summary Code
MSrc_Cd CHAR(6) NULL No Yes Measurement Source Code
Event_Age DECIMAL(8, NOT No No Event Age
0) NULL
This is the age at which events are pruned
(date duration yyyymmdd).
Prune measurement control (Prune_Msmt_Control)
This table defines when data is deleted from the Measurement (Msmt) table.
It is populated with static data that is created in the central data warehouse by a
script when Tivoli Data Warehouse is installed.
Table 51. Prune measurement control table (Prune_Msmt_Control)
Column name Data type Null option Is PK Is FK Attribute name and
description
MSrc_Cd CHAR(6) NOT NULL Yes Yes Measurement Source Code
This is the measurement
source code of the warehouse
pack that creates the pruning
control entry.
48 Tivoli Data Warehouse Schema Reference
Table 51. Prune measurement control table (Prune_Msmt_Control) (continued)
Column name Data type Null option Is PK Is FK Attribute name and
description
TmSum_Cd CHAR NOT NULL Yes Yes Time Summary Code
PMsmtC_Age_In_Days DECIMAL(8, 0) NOT NULL No No Prune Measurement Control
Age in Days
This is the age at which
events are pruned (date
duration yyyymmdd).
Prune measurement log (Prune_Msmt_Log)
This table records when data is removed from the Measurement (Msmt) table.
It is populated with warehouse pack-specific dynamic data that is loaded into the
central data warehouse by your warehouse pack script during an ETL process.
Table 52. Prune measurement log table (Prune_Msmt_Log)
Column name Data type Null Is PK Is FK Attribute name and description
option
PMsmtL_Run_DtTm TIMESTAMP NOT No No Prune Measurement Log Run Date Time
NULL
This is the timestamp of pruning action
TmSum_Cd CHAR NULL No Yes Time Summary Code
MSrc_Cd CHAR(6) NULL No Yes Measurement Source Code
PMsmtL_Age_In_Days DECIMAL(8, NOT No No Prune Measurement Log Age in Days
0) NULL
This is the age at which events are logged
(date duration yyyymmdd).
Relationship rule (RelnRul)
This table defines which types of components can participate in which types of
relationships. For example, an IP connection associates a server network interface
card to a switch IP port, whereas an FC connection can associate a host FC port to
a switch FC port.
Because data is not physically deleted from most central data warehouse tables,
rules are current or obsolete depending on their start and end dates and times.
These dates and times reflect the effective period during which the rule is current.
Relationships can be current, independent of their associated rules. Therefore,
current relationships are not disabled when a related rule is disabled.
This table is populated with common static data that is created in the central data
warehouse by the twh_cdw_data.generic script during a warehouse pack
installation. This table is also populated with warehouse pack-specific static data
that is created by your warehouse pack script during a warehouse pack
installation, if applicable.
Chapter 2. Central data warehouse schema 49
Table 53. Relationship rule table (RelnRul)
Column name Data type Null Is PK Is FK Attribute name and description
option
CompTyp_Source_Cd CHAR(17) NOT Yes Yes Component Type Source Code
NULL
CompTyp_Target_Cd CHAR(17) NOT Yes Yes Component Type Target Code
NULL
RelnTyp_Cd CHAR(6) NOT Yes Yes Relationship Type Code
NULL
RelnRul_Strt_DtTm TIMESTAMP NOT No No Relationship Rule Start DateTime
NULL
When a relationship rule is created, a start
date is assigned (usually the current time
stamp).
RelnRul_End_DtTm TIMESTAMP NOT No No Relationship Rule End DateTime
NULL
When a relationship rule is created, the end
date is set to Jan 1, 9999 indicating the
relationship rule is valid.
Relationship type (RelnTyp)
This table defines the types of relationships that exist between two independent
components. This includes physical connections such as IP connections and Fibre
Channel (FC) connections, as well as logical relationships such as network
dispatchers associated with Web servers.
The table is populated with common static data that is created in the central data
warehouse by the twh_cdw_data.generic script during a warehouse pack
installation. It is also populated with warehouse pack-specific static data that is
created by your warehouse pack script during a warehouse pack installation, if
applicable.
Table 54. Relationship type table (RelnTyp)
Column name Data type Null Is PK Is FK Attribute name and description
option
RelnTyp_Cd CHAR(6) NOT Yes No Relationship Type Code
NULL
RelnTyp_Nm VARCHAR(120) NOT No No Relationship Type Name
NULL
MSrc_Corr_Cd CHAR(6) NOT No Yes Measurement Source
NULL
For private relationship types, this is the
measurement source code of the warehouse
pack that defined the relationship. For
shared relationship types, this is one of the
shared measurement source codes described
in “Measurement Source” on page 59.
Schema version (Schema_Version)
This table defines the version number of the central data warehouse schema.
50 Tivoli Data Warehouse Schema Reference
It is populated with static data that is created in the central data warehouse by a
script when Tivoli Data Warehouse is installed.
Table 55. Schema version table (Schema_Version)
Column name Data type Null Is PK Is FK Attribute name and description
option
Version_Cd CHAR(17) NOT Yes No Schema Version Code
NULL
Version_Nm VARCHAR(120) NOT No No Schema Version Name
NULL
Source component type (Src_CompTyp)
This table, along with the component type translation (CompTyp_Tran) table,
enables the creation of event-component relationships in the Component Event
Relationship table. This table defines what source component types exist for an
event. Create one row for each component type as identified by the source
application.
Table 56. Source component type table (Src_CompTyp)
Column name Data type Null Is PK Is FK Attribute name and description
option
Src_CompTyp_ID INTEGER NOT Yes No Source Component Type ID
NULL
This unique row ID is automatically
generated by Tivoli Data Warehouse.
MSrc_Cd CHAR(6) NOT No Yes Measurement Source Code
NULL
This is the code for the measurement source
application that defines the source
component type. This is also a foreign key
to MSrc.
SrcCompTyp_Nm VARCHAR(200) NOT No No Source Component Type Name
NULL
This is the component type name as
identified by the source application. ® Note: For IBM Tivoli Enterprise Console ,
this is the slot name.
Source event attribute (Src_EventAttr)
This table defines what source event attributes exist for an event. Create one row
for each event attribute as identified by the source application.
Table 57. Source event attribute table (Src_EventAttr)
Column name Data type Null Is PK Is FK Attribute name and description
option
Event_ID BIGINT NOT No Yes Event ID
NULL
This is the ID for the event. This is also a
foreign key to Event.
Chapter 2. Central data warehouse schema 51
Table 57. Source event attribute table (Src_EventAttr) (continued)
Column name Data type Null Is PK Is FK Attribute name and description
option
Src_EAttrTyp_ID INTEGER NOT No Yes Source Event Attribute Type ID
NULL
This is the ID for the event attribute type as
identified by the source application. This is
also a foreign key to Src_EAttrTyp.
MSrc_Cd CHAR(6) NOT No Yes Measurement Source Code
NULL
This is the code for the measurement source
application that defines the source
component type. This is also a foreign key
to MSrc.
SrcEAttrTyp_Val LONGVAR NOT No No Source Event Attribute Type Value
CHAR(4096) NULL
This is the event attribute type value as
identified by the source application.
Note: For IBM Tivoli Enterprise Console,
this is the slot name.
Source event attribute type (Src_EAttrTyp)
This table defines what source event attribute types exist for an event. Create one
row for each event attribute as identified by the source application.
Table 58. Source event attribute type table (Src_EAttrTyp)
Column name Data type Null Is PK Is FK Attribute name and description
option
Src_EAttrTyp_ID INTEGER NOT Yes No Source Event Attribute Type ID
NULL
This unique row ID is automatically
generated by Tivoli Data Warehouse.
MSrc_Cd CHAR(6) NOT No Yes Measurement Source Code
NULL
This is the code for the measurement source
application that defines the source
component type. This is also a foreign key
to MSrc.
SrcEAttrTyp_Nm VARCHAR(200) NOT No No Source Event Attribute Type Name
NULL
This is the event attribute type name as
identified by the source application.
Note: For IBM Tivoli Enterprise Console,
this is the slot name.
Threshold measurement objective (MObj)
This table defines what measurement objectives exist for component types.
It is populated with warehouse pack-specific static data that is created in the
central data warehouse by your warehouse pack script during a warehouse pack
installation, if applicable.
52 Tivoli Data Warehouse Schema Reference
The use of the start and end day of the week and start and end times for a
measurement objective range has to take into account that the central data
warehouse is always in Coordinated Universal Time (UTC). In other words, the
Greenwich Mean Time (GMT) offset of the source databases, in addition to the
measurement start time, must compensate for this.
Table 59. Threshold measurement objective table (MObj)
Column name Data type Null Is PK Is FK Attribute name and description
option
MObj_ID INTEGER NOT Yes No Measurement Objective ID
NULL
This column is populated with system
generated data.
MsmtTyp_ID INTEGER NOT No Yes Measurement Type ID
NULL
CompTyp_Cd CHAR(17) NOT No Yes Component Type Code
NULL
Centr_Cd CHAR(6) NULL No Yes Center Code
Cust_ID INTEGER NULL No Yes Customer ID
AttrDom_ID INTEGER NULL No Yes Attribute Domain ID
MSrc_Cd CHAR(6) NOT No Yes Measurement Source Code
NULL
This is the code for the measurement source
application that defines the measurement
objective.
MObj_Strt_DtTm TIMESTAMP NOT No No Measurement Objective Start DateTime
NULL
When a measurement objective is created, a
start date is assigned (usually the current
time stamp).
MObj_End_DtTm TIMESTAMP NOT No No Measurement Objective End DateTime
NULL
When a measurement objective is created,
the end date is set to Jan 1, 9999 indicating
the measurement objective is valid.
Threshold measurement objective range (MObjRng)
This table defines what measurement objective ranges exist for component types.
It is populated with warehouse pack-specific static data that is created in the
central data warehouse by your warehouse pack script during a warehouse pack
installation, if applicable.
Table 60. Threshold measurement objective range table (MObjRng)
Column name Data type Null Is PK Is FK Attribute name and description
option
MObjRng_ID INTEGER NOT Yes No Measurement Objective Range ID
NULL
This column is populated with system
generated data.
Chapter 2. Central data warehouse schema 53
Table 60. Threshold measurement objective range table (MObjRng) (continued)
Column name Data type Null Is PK Is FK Attribute name and description
option
MObj_ID INTEGER NOT No Yes Measurement Objective ID
NULL
This column is populated with system
generated data.
Sev_Cd CHAR(6) NULL No Yes Severity Code
MObjRng_Max_Val FLOAT NULL No No Measurement Objective Range Maximum
Value
This column is usually used in conjunction
with the Measurement Objective Range
Minimum Value.
MObjRng_Min_Val FLOAT NULL No No Measurement Objective Range Minimum
Value
This column is usually used in conjunction
with the Measurement Objective Range
Maximum Value.
MObjRng_Strt_Dow INTEGER NULL No No Measurement Objective Range Start Day Of
Week
MObjRng_End_Dow INTEGER NULL No No Measurement Objective Range End Day Of
Week
MObjRng_Strt_Tm TIME NULL No No Measurement Objective Range Start Time
MObjRng_End_Tm TIME NULL No No Measurement Objective Range End Time
Threshold severity level (SevLvl)
This table defines the severity levels at which a measurement objective range, a
specific threshold, can be defined.
It is populated with warehouse pack-specific static data that is created in the
central data warehouse by your warehouse pack script during a warehouse pack
installation, if applicable.
Table 61. Threshold severity level table (SevLvl)
Column name Data type Null Is PK Is FK Attribute name and description
option
Sev_Cd CHAR(6) NOT Yes No Severity Code
NULL
MSrc_Cd CHAR(6) NOT No Yes Measurement Source Code
NULL
This is the code for the measurement source
application that defines the severity level.
Sev_Nm VARCHAR(120) NOT No No Severity Name
NULL
Time change difference (Time_Change_Diff)
This table is reserved; do not reference it from a warehouse pack. The table defines
when daylight saving time (DST) is in effect for the central data warehouse.
54 Tivoli Data Warehouse Schema Reference
This table is populated with static data that is created in the central data
warehouse by a script when Tivoli Data Warehouse is installed.
Table 62. Time change difference table (Time_Change_Diff)
Column name Data type Null option Is PK Is FK Attribute name and
description
TDiff_To_DST DECIMAL(6, 0) NOT NULL No No Time Change Difference To
DST
TDiff_From_DST DECIMAL(6, 0) NOT NULL No No Time Change Difference
From DST
Time change log (Time_Change_Log)
This table is reserved; do not reference it from a warehouse pack. The table records
when daylight saving time (DST) changes for the central data warehouse.
This table is populated with static data that is created in the central data
warehouse by a script when Tivoli Data Warehouse is installed.
Table 63. Time change log table (Time_Change_Log)
Column name Data type Null Is PK Is FK Attribute name and description
option
TLog_DtTm TIMESTAMP NOT No No Time Change Log Date and Time
NULL
TLog_Diff DECIMAL(6, 0) NOT No No Time Change Log Difference
NULL
TLog_TmZn_Nm VARCHAR(120) NOT No No Time Change Log Time Zone Name
NULL
Time summary (TmSum)
The Time Summary table defines what time intervals are valid for a measurement
data summary. The table contains the codes that describe the intervals that are
used to summarize the measurement data. It is recommended that all measurement
data be summarized on an hourly basis for the following reasons:
v Summarizing data on an hourly basis reduces data and disk space requirements.
v The aggregation routine provided by Tivoli Data Warehouse automatically
creates higher levels of granularity if you provide the hourly summary.
This table is populated with common static data that is created in the central data
warehouse by the twh_cdw_data.generic script during a warehouse pack
installation.
Table 64. Time summary table (TmSum)
Column name Data type Null Is PK Is FK Attribute name and description
option
TmSum_Cd CHAR NOT Yes No Time Summary Code
NULL
TmSum_Nm VARCHAR(120) NOT No No Time Summary Name
NULL
Chapter 2. Central data warehouse schema 55
Time zone (TmZon)
This table is reserved; do not reference it from a warehouse pack.
The table defines a geographical area of the world that subscribes to the same
time, such as Eastern Standard Time (EST). The time zone is described by a (+ or -)
offset from UTC or GMT. This offset is captured as a time duration, hhmmss, where
hh represents hours (00 to 12), mm represents minutes (00 or 30), and ss represents
seconds (always 00 for the offset). The offset can be positive or negative, meaning
that it can be added or subtracted to convert between GMT and the designated
time zone. A time zone can be related to a country, region, state, province, or
group of cities.
Note: There can be more than one time zone name associated with the same GMT
offset. For example, Central Time (US & Canada) and Mexico City Time both
have an offset of -06:00. Also, there are several time zones with half hour
offsets, such as Newfoundland (-03:30) and India (+05:30).
The Oracle TIME_ZONE must be in numeric format, not the name equivalent. For
example, it should be -07:00 and not CST. To verify which format it is in, type this
command:
SELECT sessionTIMEZONE FROM DUAL;
To change it to numeric format, type this command:
ALTER DATABSE SET TIME_ZONE = ‘-07:00’;
Also, in Oracle, to convert data from the local time to GMT, create a SQL script
that does the following:
1. Create a temporary table in the target database and give the column where the
data will reside a name:
create temp table tableName (columnName VARCHAR2(30));
2. Insert the data to be converted into the temporary table:
insert into tableName select sessiontimezone from dual;
3. Use the following SQL statements:
--#IFSOURCE oracle
--#INSERT_INTO_TARGET
INSERT INTO databaseName (SRC_TIMEZONE DECIMAL(6,0))
SELECT DISTINCT to_number(substr(columnName,1,3)) *10000 FROM tableName;
;
For example, in the following example script, the tableName is
TEMP_TIMEZONE, the columnName is session_timezone, and the databaseName
is BWM.TMP_SRC_DB:
--#IFSOURCE oracle
--#IGNORE_ERROR
--#EXECUTE_AT_SOURCE
CREATE TABLE TEMP_TIMEZONE(session_timezone VARCHAR2(30));
--#EXECUTE_AT_SOURCE
INSERT INTO TEMP_TIMEZONE (session_timezone)
SELECT SESSIONTIMEZONE FROM DUAL;
--#INSERT_INTO_TARGET
INSERT INTO BWM.TMP_SRC_DB (SRC_TIMEZONE DECIMAL (6,0))
SELECT DISTINCT TO_NUMBER(SUBSTR(SESSION_TIMEZONE,1,3))*10000
FROM TEMP_TIMEZONE;
56 Tivoli Data Warehouse Schema Reference
;
--#EXECUTE_AT_SOURCE
DROP TABLE TEMP_TIMEZONE;
--#ENDIF
This table is populated with static data that is created in the central data
warehouse by a script when Tivoli Data Warehouse is installed.
Table 65. Time zone table (TmZon)
Column name Data type Null Is PK Is FK Attribute name and description
option
TmZon_ID INTEGER NOT Yes No Time Zone ID
NULL
TmZon_Nm VARCHAR(120) NOT No No Time Zone Name
NULL
TmZon_GMT_Offset DECIMAL(6,0) NOT No No Time Zone GMT Offset Duration
NULL
TmZon_CDW_Diff DECIMAL(6,0) NULL No No Time Zone Difference for the central data warehouse
Time zone install (TmZon_Install)
This table is reserved; do not reference it from a warehouse pack. The table defines
when daylight saving time (DST) starts and ends for the central data warehouse.
The installation also uses this data when determining the time zone of the central
data warehouse.
This table is populated with static data that is created in the central data
warehouse by a script when Tivoli Data Warehouse is installed.
Table 66. Time zone install table (TmZon_Install)
Column name Data type Null Is PK Is FK Attribute name and description
option
TInstall_Begin_DST DATE NOT No No Time Zone Install Begin DST Date
NULL
TInstall_End_DST DATE NOT No No Time Zone Install End DST Date
NULL
Translated Term (Translated_Term)
This table defines the translated resources for all source applications.
It is populated with warehouse pack-specific static data that is created in the
central data warehouse by the install program using your Java resource bundle
files during a warehouse pack installation, if applicable. If the resource bundles of
more than one warehouse pack contain a translated resource, the last one to be
installed is used.
Chapter 2. Central data warehouse schema 57
Table 67. Translated term table (Translated_Term)
Column name Data type Null Is PK Is FK Attribute name and description
option
Term_ID INTEGER NOT Yes No Term ID
NULL
This ID is an ascending sequence number
that is generated by a database trigger.
Term_Key VARCHAR(230) NOT Yes No Term Key
NULL
This key is composed of:
table.column.code_value, where code_value is
the code column in the table, for example,
CompTyp_Cd.
Note: This key is not a primary key on
OS/390.
Term_Locale VARCHAR(20) NOT No No Term Locale
NULL
This is the locale; for example, en_US, fr_FR,
and so on.
Term_Value VARCHAR(768) NOT No No Term Value
FOR BIT DATA NULL
This is the translated version of the value of
table.column referred to by Term_Key in
Unicode format. Because the column is
binary (for bit data), no code page applies to
the column.
Term_CValue VARCHAR(768) NULL No No Term Character Value
This is the character representation of the
Term_Value column.
58 Tivoli Data Warehouse Schema Reference
Chapter 3. Common static data
The central data warehouse contains tables that are used by all warehouse packs.
Within those tables, some rows are used by all warehouse packs and are referred
to as common static data, whereas other rows are used only by individual
warehouse packs. This chapter identifies the common static data.
The default set of central data warehouse tables is created when Tivoli Data
Warehouse is installed. Each of these tables has a prefix of TWG to indicate that
they are part of the Tivoli Data Warehouse schema. When your warehouse pack is
installed, and when your ETL processes run, your warehouse pack places
warehouse pack-specific entries in the central data warehouse tables for the
component, attribute, measurement, event, and relationship types, along with the
rules that define what characteristics apply to which component types. Review
Chapter 2, “Central data warehouse schema,” on page 7 for a detailed description
of the tables that are created. Your warehouse pack-specific data is also inserted
into any additional tables you create.
This chapter identifies the static data that is common to all warehouse packs. The
following tables contain static data:
v “Measurement Source”
v “Component Type” on page 60
v “Relationship Type” on page 65
v “Relationship Rule” on page 68
v “Time Summary” on page 70
v “Measurement Unit Category” on page 71
v “Measurement Unit” on page 71
v “Measurement Group Type” on page 72
v “Measurement Group” on page 73
v “Measurement Type” on page 74
v “Measurement Rule” on page 79
v “Attribute Type” on page 82
v “Attribute Rule” on page 90
v “Event Type” on page 92
v “Event Attribute Type” on page 93
v “Event Group Type” on page 93
v “Attribute domain” on page 93
Measurement Source
The Measurement Source table defines sources of measurements.
For rules associated with all measurement tables, see “Measurement (Msmt)” on
page 37.
© Copyright IBM Corp. 2005 59
Table 68. Measurement Source (MSrc Table)
MSrc_Cd MSrc_Parent_Cd MSrc_Nm Comments
Note: This column is not part of
the MSrc table.
EVENTS NULL Events
MODEL1 NULL Tivoli Common Data Model V1 Use MODEL1 if your application
extracts information from the
Tivoli common data resource
model.
SDESK1 NULL Service Desk Use SDESK1 if your application
extracts information from the
Tivoli Service Desk resource
model. Tivoli Service Desk is a
solution for enterprise problems
and systems management.
SHARED NULL Shared Use SHARED if your application
extracts information from a
shared data resource model.
SNMP NULL Simple Network Management Use SNMP if your application
Protocol extracts information from the
Tivoli Simple Network
Management Protocol resource
model. SNMP is a protocol used
for network management.
Tivoli NULL Tivoli Application This is a high-level measurement
source parent for all Tivoli
warehouse packs. No common
measurement types are defined
for this measurement source code.
Component Type
Component types represent the type or class of the resource, but not the resource
itself. For example, a server could be a component type and 9.67.241.43 would be
an instance of that server.
The following rules are associated with component types:
v Use the IP_HOST component type if the resource can be identified by a fully
qualified host name. Use the fully qualified host name as the component name.
Save the information about IP_HOST, such as the LAST_KNOWN_IPADDRESS,
as component attributes. See “Component attribute (CompAttr)” on page 18 for
details.
v Use the IP_INTERFACE component type if the IP resource does not have a fully
qualified host name. However, because correlation between IP resources is more
difficult using IP addresses, use the IP_INTERFACE only if the fully qualified
host name is not available. The IP_INTERFACE component type represents a
correlation component and not a host.
v Use ACTIVITY for a task that cannot be broken down into smaller units of
work. An activity can exist on a large scale, such as the delivery of a package to
a destination, or on a very small scale, such as the encryption of a network
packet.
60 Tivoli Data Warehouse Schema Reference
v Use CLUSTER for a set of machines that operate in an interconnected way, such
as mainframes.
v Do not use the COMPUTER_SYSTEM component type.
v Use POOL for a group of resources from which one or more can be used at any
point in time.
v Use the TRANSACTION component type for an instance of an activity or
process. Because processes can be complex, a transaction can have many parts
and can be combined in many different ways.
v Use the WEBSITE component type to represent the site that can be accessed
from the network. The site can include multiple machines, or any number of
databases and processors, but is referred to by a single name, which is specified
near the front of a URL after the protocol and the port. For example,
www.ibm.com is an instance of the WEBSITE component type.
v Use the WEBSITE_PATH component type to represent the path portion of a URL
that identifies the file to be accessed or program to be run on a particular Web
site. For example, in the URL http://www.ibm.com/stock/quote?ticker=IBM , the
path is /stock/quote (note the leading forward slash). WEBSITE_PATH
component types can be built in a PCHILD hierarchy, in which case each parent
in the PCHILD relationship serves to identify a portion of the overall path name.
Create these parent WEBSITE_PATH component types only if there are valuable
measurements or attributes to be recorded against the component. Otherwise,
create a single path component with the full path string.
v Use the WEBSITE_QUERY component type to represent the query portion of a
URL. The name of this component is formed as a concatenated string of all the
parameters (expressed as keyword=value pairs) passed on the URL, where the
parameters are sorted alphabetically by key. For example, in the URL
http://www.ibm.com/stock/quote?ticker=IBM , the query is quote?ticker=IBM .
As with WEBSITE_PATH component types, parts of the query string can be
represented as individual components, although it is expected that the entire
sequence of parameters will be represented by a single WEBSITE_QUERY
component type. The sequence of keys in the WEBSITE_QUERY name are
ordered according to the collation sequence appropriate for the locale in which
the WEBSITE_QUERY was run.
Web queries can be nested, meaning there can be multiple question marks in a
URL. When this happens, create a hierarchy of components of the
WEBSITE_QUERY component type using the PCHILD relationship to indicate
the nesting.
v Create warehouse pack-specific component types if the component type is
unique to the application. For example, if an application creates a view that
represents a service, then information about that view is known by that
application. Do not use warehouse pack-specific types if an appropriate shared
type is defined.
v You might need to change the source application to use common component
types. For example, an application might collect only the short host name or the
IP address to identify a resource, instead of the fully qualified host name. If you
want to use the IP_HOST component type, you must either compute the fully
qualified host name during the ETL, or change the source application to collect
the fully qualified host name.
v For MVS_SUBSYSTEM, the component name is the name that is specified in the
SUBSYS SUBNAME parameter in the IEFSSNxx member in SYS1.PARMLIB.
v For MVS_SYSTEM, the following guidelines apply:
– The component name is the 1 to 8 character SYSNAME that is specified in
IEASYSxx member in SYS1.PARMLIB.
Chapter 3. Common static data 61
– The SYSTEM_ID is the 1 to 4 character system identifier that is specified in
the SYS1.PARMLIB member SMFPRM00. This is a single valued attribute and
does not support attribute domains.
v For LOGICAL_PARTITION, the following guidelines apply:
– The component name is the logical partition name that is available on the
z/OS platform. This value must be 8 characters long and is defined when the
machine is configured.
– The logical partition ID is available on the z/OS platform. This value is a
hexadecimal number that can be up to 15 characters long and is defined
when the machine is configured.
v For SYSPLEX, the component name is the name displayed on a z/OS system
during initial program load (IPL).
Because data is not physically deleted from most central data warehouse tables,
types are current or obsolete depending on their start and end dates and times.
These dates and times do not track the history of enablement or disablement. They
reflect the effective period during which the type is current. Components can be
current, independent of their associated types. Therefore, current components are
not disabled when a related type is disabled.
Table 69. Component Type (CompTyp Table)
CompTyp_Cd CompTyp_ CompTyp_Nm CompTyp_ CompTyp_End_ MSrc_Corr_
Parent_Cd Strt_DtTm DtTm Cd
Base component types
ACTIVITY NULL Activity current timestamp 9999-01- MODEL1
- current timezone 01–00.00.00.00
CLUSTER NULL Cluster current timestamp 9999-01- MODEL1
- current timezone 01–00.00.00.00
COMPUTER_ NULL Computer current timestamp 9999-01- MODEL1
SYSTEM System - current timezone 01–00.00.00.00
LOGICAL_ NULL Logical Device current timestamp 9999-01- MODEL1
DEVICE - current timezone 01–00.00.00.00
POOL NULL Pool current timestamp 9999-01- MODEL1
- current timezone 01–00.00.00.00
TRANSACTION NULL Transaction current timestamp 9999-01- MODEL1
- current timezone 01–00.00.00.00
Business systems component types
BUSINESS_ NULL Business System current timestamp 9999-01- MODEL1
SYSTEM - current timezone 01–00.00.00.00
IP component types
IPX_INTERFACE NULL IPX Interface current timestamp 9999-01- MODEL1
- current timezone 01–00.00.00.00
IP_HOST NULL IP Host current timestamp 9999-01- MODEL1
- current timezone 01–00.00.00.00
IP_INTERFACE NULL IP Interface current timestamp 9999-01- MODEL1
- current timezone 01–00.00.00.00
IP_NODE NULL IP Node current timestamp 9999-01- MODEL1
- current timezone 01–00.00.00.00
MQ component types
62 Tivoli Data Warehouse Schema Reference
Table 69. Component Type (CompTyp Table) (continued)
CompTyp_Cd CompTyp_ CompTyp_Nm CompTyp_ CompTyp_End_ MSrc_Corr_
Parent_Cd Strt_DtTm DtTm Cd
MQ_ADAPTER NULL MQ Adapter current timestamp 9999-01- MODEL1
- current timezone 01–00.00.00.00
MQ_CHANNEL NULL MQ Channel current timestamp 9999-01- MODEL1
- current timezone 01–00.00.00.00
MQ_QUEUE NULL MQ Queue current timestamp 9999-01- MODEL1
- current timezone 01–00.00.00.00
MQ_QUEUE_ NULL MQ Queue current timestamp 9999-01- MODEL1
MANAGER Manager - current timezone 01–00.00.00.00
Services component types
SERVICE NULL Service current timestamp 9999-01- MODEL1
- current timezone 01–00.00.00.00
Service desk component types
CHANGE_ NULL Change Request current timestamp 9999-01- MODEL1
REQUEST - current timezone 01–00.00.00.00
CR_TASK NULL Change Request current timestamp 9999-01- SDESK1
Task - current timezone 01–00.00.00.00
SD_USER NULL Service Desk current timestamp 9999-01- SDESK1
User - current timezone 01–00.00.00.00
SERVICE_DESK NULL Service Desk current timestamp 9999-01- MODEL1
- current timezone 01–00.00.00.00
INCIDENT NULL Incident current timestamp 9999-01- MODEL1
- current timezone 01–00.00.00.00
PRODUCT_ORG_ NULL Software Usage current timestamp 9999-01- MODEL1
USAGE for an - current timezone 01–00.00.00.00
Organization
SNA component types
NETWORK_APPL NULL Network current timestamp 9999-01- MODEL1
Application - current timezone 01–00.00.00.00
SNA_CCU NULL SNA current timestamp 9999-01- MODEL1
Communication - current timezone 01–00.00.00.00
Control Unit
SNA_LINE NULL SNA Line current timestamp 9999-01- MODEL1
- current timezone 01–00.00.00.00
SNA_NETWORK NULL SNA Network current timestamp 9999-01- MODEL1
- current timezone 01–00.00.00.00
SNA_PU NULL SNA Physical current timestamp 9999-01- MODEL1
Unit - current timezone 01–00.00.00.00
SNMP_AGENT NULL SNMP Agent current timestamp 9999-01- MODEL1
- current timezone 01–00.00.00.00
SNMP_OBJ NULL SNMP Object current timestamp 9999-01- MODEL1
- current timezone 01–00.00.00.00
Software license component types
DISKS_LIC_ NULL Usage of current timestamp 9999-01- MODEL1
USAGE Software License - current timezone 01–00.00.00.00
with Disks
Capacity Type
Chapter 3. Common static data 63
Table 69. Component Type (CompTyp Table) (continued)
CompTyp_Cd CompTyp_ CompTyp_Nm CompTyp_ CompTyp_End_ MSrc_Corr_
Parent_Cd Strt_DtTm DtTm Cd
MEMORY_LIC_ NULL Usage of current timestamp 9999-01- MODEL1
USAGE Software License - current timezone 01–00.00.00.00
with Memory
Capacity Type
PROCS_LIC_ NULL Usage of current timestamp 9999-01- MODEL1
USAGE Software License - current timezone 01–00.00.00.00
with Processors
Capacity Type
PRODUCT_GRP_ NULL Software Usage current timestamp 9999-01- MODEL1
USAGE for a Group - current timezone 01–00.00.00.00
PRODUCT_INV NULL Software Product current timestamp 9999-01- MODEL1
Inventory - current timezone 01–00.00.00.00
SW_INVENTORY NULL Software current timestamp 9999-01- MODEL1
Inventory - current timezone 01–00.00.00.00
SW_USAGE NULL Software Usage current timestamp 9999-01- MODEL1
- current timezone 01–00.00.00.00
USERS_LIC_ NULL Usage of current timestamp 9999-01- MODEL1
USAGE Software License - current timezone 01–00.00.00.00
with Users
Capacity Type
Tivoli Management Framework component types
TME_ENDPOINT NULL Tivoli Endpoint current timestamp 9999-01- MODEL1
- current timezone 01–00.00.00.00
Tivoli Workload Scheduler component types
SCHED_ENGINE NULL Workload current timestamp 9999-01- MODEL1
Scheduler Master - current timezone 01–00.00.00.00
SCHED_JOB NULL Workload current timestamp 9999-01- MODEL1
Scheduler Job - current timezone 01–00.00.00.00
SCHED_ NULL Workload current timestamp 9999-01- MODEL1
JOBSTREAM Scheduler - current timezone 01–00.00.00.00
Jobstream
SCHED_ NULL Workload current timestamp 9999-01- MODEL1
WORKSTATION Scheduler - current timezone 01–00.00.00.00
Workstation
Web component types
WEBSITE NULL Website current timestamp 9999-01- MODEL1
- current timezone 01–00.00.00.00
WEBSITE_PATH NULL Website Path current timestamp 9999-01- MODEL1
- current timezone 01–00.00.00.00
WEBSITE_QUERY NULL Website Query current timestamp 9999-01- MODEL1
- current timezone 01–00.00.00.00
Web application server component types
J2EE_CELL NULL J2EE Cell current timestamp 9999-01- MODEL1
- current timezone 01–00.00.00.00
J2EE_DOMAIN NULL J2EE Domain current timestamp 9999-01- MODEL1
- current timezone 01–00.00.00.00
64 Tivoli Data Warehouse Schema Reference
Table 69. Component Type (CompTyp Table) (continued)
CompTyp_Cd CompTyp_ CompTyp_Nm CompTyp_ CompTyp_End_ MSrc_Corr_
Parent_Cd Strt_DtTm DtTm Cd
J2EE_NODE NULL J2EE Node current timestamp 9999-01- MODEL1
- current timezone 01–00.00.00.00
J2EE_SERVER NULL J2EE Server current timestamp 9999-01- MODEL1
- current timezone 01–00.00.00.00
® WAS_NODE_ NULL IBM WebSphere current timestamp 9999-01- MODEL1
AGENT Node Agent - current timezone 01–00.00.00.00
z/OS component types
CEC NULL Central current timestamp 9999-01- MODEL1
Electronic - current timezone 01–00.00.00.00
Complex
COUPLING_ NULL Coupling Facility current timestamp 9999-01- MODEL1
FACILITY - current timezone 01–00.00.00.00
™ MVS_SUBSYSTEM NULL MVS current timestamp 9999-01- MODEL1
Subsystem - current timezone 01–00.00.00.00
MVS_SYSAPPL NULL MVS System current timestamp 9999-01- MODEL1
Application - current timezone 01–00.00.00.00
MVS_SYSTEM NULL MVS System current timestamp 9999-01- MODEL1
- current timezone 01–00.00.00.00
LOGICAL_ NULL Logical Partition current timestamp 9999-01- MODEL1
PARTITION - current timezone 01–00.00.00.00
SYSPLEX NULL Sysplex current timestamp 9999-01- MODEL1
- current timezone 01–00.00.00.00
Relationship Type
The Relationship Type table defines the types of relationships that exist between
two independent components. This includes physical connections such as IP
connections and Fibre Channel (FC) connections, as well as logical relationships
such as network dispatchers associated with Web servers.
Table 70 lists the relationship types that are defined by the common data script,
twh_cdw_data.generic.
Table 70. Relationship Type (RelnTyp Table)
RelnTyp_ RelnTyp_Nm MSrc_ Comments
Cd Corr_Cd Note: This column is not part of the RelnTyp table.
CAUSES Causes MODEL1 This value represents a generic relationship where an entity causes
Relation another entity.
CNTRLS Controls MODEL1 This value represents a relationship where one entity (such as a
Relation software program or product) oversees and affects the operation of
another entity.
In this relationship, the controlling entity is the source, and the entity
that is controlled is the target.
Note: This relationship is not meant to be used to record every aspect
of cause and effect. Instead, this relationship is used to record major
areas of management and control, such as which disk controller is
responsible for which disk packs, or which administrative console is
responsible for which servers.
Chapter 3. Common static data 65
Table 70. Relationship Type (RelnTyp Table) (continued)
RelnTyp_ RelnTyp_Nm MSrc_ Comments
Cd Corr_Cd Note: This column is not part of the RelnTyp table.
DEPEND Depend MODEL1 This value represents a generic relationship where one entity (the
Relation source) requires the operation or services of another entity (the target)
in order to perform its job, and therefore the operational status of the
target affects the operational status of the source. If there is a more
specific type of dependency (such as RUNSON) that is appropriate,
use the more specific relationship.
DERIVE Derive Relation MODEL1 This value represents an alias for linking attribute, component,
measurement, and event types together. In this relationship, the source
represents the original type and the target represents the common,
normalized, or new type.
DESCRI Described MODEL1 The source component describes monitoring of the target component.
Monitoring of
Relation
INHERI Inherit Relation EVENTS This value represents a relationship among components in which the
child or sub-component shares all of the characteristics found in the
parent component and further defines itself by augmenting those
characteristics.
INSTOF Instance Of MODEL1 This value represents a generic relationship where an entity is an
Relation instance of another entity.
INSTON Installed On MODEL1 This value represents an Installed On relationship where the source is
Relation installed on the target.
INVOKE Invoke Relation MODEL1 This value represents a relationship in which a user causes a certain
transaction or unit of work to occur in a system. The source in this
relationship is the individual or group that caused the unit of work to
occur, and the target of the relationship is the action that was
performed. The targets of an INVOKE relationship are restricted to be
entities like jobs, transactions, or commands.
ISA Is a Relation EVENTS This value represents a relationship where an event inherits
definitions from a base event. In this relationship, the source is the
child event, and the target is the base event.
LCONT Logical MODEL1 This value represents a containment relationship between logical
Containment entities, such as files within packages. In this relationship, the source
Relation is the smaller entity, which is logically contained in the larger entity,
which is the target of the relationship.
MANAGE Manage MODEL1 This value represents a generic relationship where an entity manages
Relation another entity.
MEMBER Member MODEL1 This value represents a generic relationship where an entity is a
Relation member of a group. If there is another relationship type that more
accurately reflects the type of group or nature of the membership
(such as an administrative domain), then the more specific
relationship should be used. In this relationship, the source is the
single entity involved in the membership, and the target is the group
of which it is a member.
MONITR Monitoring MODEL1 This value represents the relationship between a management agent or
Relation management probe and the resource that it is monitoring. In this
relationship, the management agent or the probe is the source, and the
resource being monitored is the target.
66 Tivoli Data Warehouse Schema Reference
Table 70. Relationship Type (RelnTyp Table) (continued)
RelnTyp_ RelnTyp_Nm MSrc_ Comments
Cd Corr_Cd Note: This column is not part of the RelnTyp table.
NETWRK Network MODEL1 This value represents a relationship where one entity is connected to
Relation another entity across a communications or data processing network.
Many network connections are between peers; in this case, either
entity can be the source or target. However, as a convention, it is
suggested that if one entity has a higher standing in the network, it
should be represented as the source (for instance, a router should be
considered the source with respect to its downstream stations).
OWNS Owns Relation MODEL1 This value represents a relationship where one entity (assumed to be a
person or an organization) owns, in a financial or legal sense, another
entity. In this relationship, the source is the owner, and the target is
the entity that is owned.
PCHILD Parent Child MODEL1 An entity can only have one PCHILD parent, but it can have
Relation additional parents of other relationship types. A specific combination
of component names, following the PCHILD relationship from the
top, must identify one and only one entity.
PCONT Physical MODEL1 This value represents a relationship between physical entities, such as
Containment cards within slots. In this relationship, the source is the smaller entity,
Relation which is physically contained in the larger entity, which is the target
of the relationship.
PROVID Provides MODEL1 This value represents a generic relationship where an entity provides
Relation a service for another entity.
PROXY Proxy Relation MODEL1 This value represents a generic relationship where an entity is a proxy
for another entity.
ROOTR Root MODEL1 The transaction from which all subtransactions were spawned. For
Transaction example, if you start with a transaction called Buy Book that calls
Check If Available that in turn calls Find Price, then the root
transaction is Buy Book.
RUNSON Runs on MODEL1 This value represents a relationship where a particular software
Relation component or product runs on a computer.
In the RUNSON relationship, the software entity is the source, and the
host or machine on which the software entity runs is the target.
If the parent of a particular entity (in a PCHILD relationship) is
known to be running on a computer, all of the children are assumed
to also be running on that computer, so RUNSON relationships are
not required for all entities. This relationship is especially suited for
representing the fact that a particular server (the software
manifestation of a product) is related to the host or computer on
which it is running.
SAME Same Relation MODEL1 This value represents a generic relationship where an entity is the
same as another entity.
SOURCE Is Source of MODEL1 This relationship type is used to link events to a component. In this
Relation relationship the component is a source of the event, or target.
SUPPRT Supports MODEL1 This value represents a generic relationship where an entity supports
Relation another entity.
UPDATE Updates EVENTS This value represents a relationship where one entity updates another
Relation entity. In this relationship the source updates the target.
USES Uses Relation MODEL1 This value represents a generic relationship where an entity uses
another entity.
Chapter 3. Common static data 67
Relationship Rule
The Relationship Rule table defines which types of components can participate in
which types of relationships. For example, an IP connection associates a server
network interface card to a switch IP port, whereas an FC connection can associate
a host FC port to a switch FC port.
The following guidelines apply:
v For MVS_SUBSYSTEM, the component name is the name that is specified in the
SUBSYS SUBNAME parameter in the IEFSSNxx member in SYS1.PARMLIB.
v For MVS_SYSTEM, the following guidelines apply:
– The component name is the 1 to 8 character SYSNAME that is specified in
IEASYSxx member in SYS1.PARMLIB.
– The SYSTEM_ID is the 1 to 4 character system identifier that is specified in
the SYS1.PARMLIB member SMFPRM00. This is a single valued attribute and
does not support attribute domains.
v For LOGICAL_PARTITION, the following guidelines apply:
– The component name is the logical partition name that is available on the
z/OS platform. This value must be 8 characters long and is defined when the
machine is configured.
– The logical partition ID is available on the z/OS platform. This value is a
hexadecimal number that can be up to 15 characters long and is defined
when the machine is configured.
v For SYSPLEX, the component name is the name displayed on a z/OS system
during initial program load (IPL).
Table 71 lists the relationship rules that are defined by the common data script,
twh_cdw_data.generic.
Table 71. Relationship Rule (RelnRul Table)
CompTyp_Source_Cd CompTyp_Target_Cd RelnTyp_Cd RelnRul_Strt_ RelnRul_End_
DtTm DtTm
UNSET relationship rules
BUSINESS_SYSTEM CLUSTER PCHILD current timestamp - 9999-01-
current timezone 01–00.00.00.00
J2EE_CELL J2EE_NODE PCHILD current timestamp - 9999-01-
current timezone 01–00.00.00.00
J2EE_DOMAIN J2EE_NODE PCHILD current timestamp - 9999-01-
current timezone 01–00.00.00.00
J2EE_NODE J2EE_SERVER PCHILD current timestamp - 9999-01-
current timezone 01–00.00.00.00
J2EE_NODE WAS_NODE_AGENT PCHILD current timestamp - 9999-01-
current timezone 01–00.00.00.00
J2EE_SERVER IP_HOST RUNSON current timestamp - 9999-01-
current timezone 01–00.00.00.00
TRANSACTION ACTIVITY INSTOF current timestamp - 9999-01-
current timezone 01–00.00.00.00
WAS_NODE_AGENT IP_HOST RUNSON current timestamp - 9999-01-
current timezone 01–00.00.00.00
MQ relationship rules
68 Tivoli Data Warehouse Schema Reference
Table 71. Relationship Rule (RelnRul Table) (continued)
CompTyp_Source_Cd CompTyp_Target_Cd RelnTyp_Cd RelnRul_Strt_ RelnRul_End_
DtTm DtTm
MQ_QUEUE_MANAGER MQ_CHANNEL PCHILD current timestamp - 9999-01-
current timezone 01–00.00.00.00
MQ_QUEUE_MANAGER MQ_QUEUE PCHILD current timestamp - 9999-01-
current timezone 01–00.00.00.00
MVS_SYSTEM MQ_QUEUE_MANAGER PCHILD current timestamp - 9999-01-
current timezone 01–00.00.00.00
Service desk relationship rules
CHANGE_REQUEST CR_TASK PCHILD current timestamp - 9999-01-
current timezone 01–00.00.00.00
CHANGE_REQUEST INCIDENT CAUSES current timestamp - 9999-01-
current timezone 01–00.00.00.00
CHANGE_REQUEST SD_USER PCHILD current timestamp - 9999-01-
current timezone 01–00.00.00.00
INCIDENT SD_USER PCHILD current timestamp - 9999-01-
current timezone 01–00.00.00.00
SERVICE_DESK CHANGE_REQUEST PCHILD current timestamp - 9999-01-
current timezone 01–00.00.00.00
SERVICE_DESK INCIDENT PCHILD current timestamp - 9999-01-
current timezone 01–00.00.00.00
SNA relationship rules
SNA_CCU SNA_LINE NETWRK current timestamp - 9999-01-
current timezone 01–00.00.00.00
SNA_CCU SNA_PU NETWRK current timestamp - 9999-01-
current timezone 01–00.00.00.00
SNA_LINE SNA_PU NETWRK current timestamp - 9999-01-
current timezone 01–00.00.00.00
SNA_NETWORK SNA_CCU PCHILD current timestamp - 9999-01-
current timezone 01–00.00.00.00
SNA_NETWORK SNA_LINE PCHILD current timestamp - 9999-01-
current timezone 01–00.00.00.00
SNA_NETWORK SNA_PU PCHILD current timestamp - 9999-01-
current timezone 01–00.00.00.00
Tivoli Workload Scheduler relationship rules
MVS_SYSTEM SCHED_ENGINE PCHILD current timestamp - 9999-01-
current timezone 01–00.00.00.00
SCHED_ENGINE SCHED_JOB PCHILD current timestamp - 9999-01-
current timezone 01–00.00.00.00
SCHED_ENGINE SCHED_JOBSTREAM PCHILD current timestamp - 9999-01-
current timezone 01–00.00.00.00
SCHED_ENGINE SCHED_WORKSTATION PCHILD current timestamp - 9999-01-
current timezone 01–00.00.00.00
SCHED_JOB SCHED_JOBSTREAM LCONT current timestamp - 9999-01-
current timezone 01–00.00.00.00
SCHED_JOB SCHED_WORKSTATION RUNSON current timestamp - 9999-01-
current timezone 01–00.00.00.00
Web relationship rules
Chapter 3. Common static data 69
Table 71. Relationship Rule (RelnRul Table) (continued)
CompTyp_Source_Cd CompTyp_Target_Cd RelnTyp_Cd RelnRul_Strt_ RelnRul_End_
DtTm DtTm
WEBSITE WEBSITE_PATH PCHILD current timestamp - 9999-01-
current timezone 01–00.00.00.00
WEBSITE_PATH WEBSITE_QUERY PCHILD current timestamp - 9999-01-
current timezone 01–00.00.00.00
z/OS component types
CEC LOGICAL_PARTITION PCHILD current timestamp - 9999-01-
current timezone 01–00.00.00.00
COUPLING_FACILITY SYSPLEX LCONT current timestamp - 9999-01-
current timezone 01–00.00.00.00
MVS_SYSTEM LOGICAL_PARTITION RUNSON current timestamp - 9999-01-
current timezone 01–00.00.00.00
MVS_SYSTEM MVS_SUBSYSTEM PCHILD current timestamp - 9999-01-
current timezone 01–00.00.00.00
MVS_SYSTEM MVS_SYSAPPL PCHILD current timestamp - 9999-01-
current timezone 01–00.00.00.00
MVS_SYSTEM SYSPLEX LCONT current timestamp - 9999-01-
current timezone 01–00.00.00.00
Time Summary
The Time Summary table contains the codes that describe the intervals that are
used to summarize the measurement data.
Table 72 lists the time summary codes that are defined in the common data script,
twh_cdw_data.generic. Use only the codes defined by the twh_cdw_data.generic
script. Do not define your own codes in the warehouse pack-specific static data
script, productCode_cdw_data.generic. If you need additional codes, contact the
Tivoli Data Warehouse enablement team.
Point (P) data measurements represent a point in time occurrence and are typically
not summarized. Consequently, summarization does not typically apply to Point
(P) data measurements.
Table 72. Time Summary (TmSum Table)
TmSum_Cd TmSum_Nm
5 Five minutes
D Daily
F Fifteen minutes
H Hourly
M Monthly
P Point
Q Quarterly
T Thirty minutes
W Weekly
Y Yearly
70 Tivoli Data Warehouse Schema Reference
Measurement Unit Category
A measurement unit category is a high level classification of measurements.
Table 73 lists the measurement unit categories that are defined by the static data
script, twh_cdw_data.generic. Do not define your own categories in your
warehouse pack-specific static data script, productCode_cdw_data.generic. If you
need additional categories, contact the Tivoli Data Warehouse enablement team.
For rules associated with all measurement tables, see “Measurement (Msmt)” on
page 37.
Table 73. Measurement Unit Category (MUnitCat Table)
MUnitCat_Cd MUnitCat_Nm Description
Note: This column is not part of the
MUnitCat table.
PRC Percentage This indicates a ratio comparing one time or
quantity against another
QTY Quantity This indicates a unit count associated with
an activity; for example, bytes transferred
RT Rate This indicates a quantity over a fixed time
period
TM Time Duration This indicates the amount of time required to
perform an activity
Measurement Unit
This table defines the measurement units that are available in the common static
data script, twh_cdw_data.generic.
v Store the data in the central data warehouse in the measurement units used by
the source application. For example, if your source application traditionally
displays data in milliseconds, do not convert the data to seconds before saving it
in the central data warehouse.
v Table 74 on page 72 lists the measurement units that are supported. Use only the
units defined by the twh_cdw_data.generic. Do not define your own units of
measurement in your warehouse pack-specific static data script. If you need a
unit that is not listed, ask the warehouse team to add a new measurement unit.
v If measurements are collected in different units, save them in the central data
warehouse as different measurement types. For example, if the application
collects data about CPU time in both microseconds and milliseconds, then save ″ ″ the microsecond data with the measurement type CPU Time in Microseconds ″ and the millisecond data with the measurement type CPU Time in ″ Milliseconds . Do not create aliases between the two measurement types.
v If you need to display measurements with different units on the same graph in a
report, you can handle it with one of these techniques:
– Let the report writing tool handle the graphing. In some cases, this might
produce unusable report output. For example, if you graph an individual’s
salary and the income of a large corporation, the difference in the units might
be a problem.
– Convert the data to a standard unit when you load it into the data mart.
Make sure that you understand what range of values the data might have, to
ensure that the data can be converted without significant truncation or round
Chapter 3. Common static data 71
off error. For example, if you convert a WebSphere average servlet response
time from milliseconds to seconds, typical values will be truncated to zero.
For rules associated with all measurement tables, see “Measurement (Msmt)” on
page 37.
Table 74. Measurement Unit (MUnit Table)
MUnit_Cd MUnitCat_Cd MUnit_Nm
4KPgs QTY 4K Pages
B QTY Bytes
Bps RT Bytes per Second
Day TM Days
GB QTY Gigabytes
HSc TM Hundredths of a Second
Hr TM Hours
KB QTY Kilobytes
KBps RT Kilobytes per Second
MB QTY Megabytes
MBps RT Megabytes per Second
MICROS TM Microseconds
MSec TM Milliseconds
Min TM Minutes
PRC PRC Percentage
QTY QTY Quantity
Qpm RT Quantity per Minute
Qps RT Quantity per Second
Rps RT Requests per Second
SU QTY Service Units
Sec TM Seconds
TSEC TM Tenths of a Second
Measurement Group Type
Table 75 defines what types of groups are valid for a measurement group type.
For rules associated with all measurement tables, see “Measurement (Msmt)” on
page 37.
Table 75. Measurement Group Type (MGrpTyp Table)
MGrpTyp_Cd MGrpTyp_Nm
CATEG Category
COLL Data Collection Groups
GROUP Aggregate Types or Group Functions
STATE State
TRANS State Transition Groups
72 Tivoli Data Warehouse Schema Reference
Measurement Group
Measurement groups are created to help organize measurement types. A
measurement can be in multiple groups and a warehouse pack can create as many
measurement groups as necessary to help organize the measurement types.
You associate which types of measurements are associated with the group in the
Measurement Group Member (MGrpMbr) table. For more information, see
“Measurement group member (MGrpMbr)” on page 41.
All warehouse packs that put measurements into the central data warehouse are
required to use the standard measurement groups so that applications performing
higher-level correlation know what data is to be expected from the source
application.
The following rules are associated with the Measurement Group table:
v The following measurement groups are critical to cross-application reporting
and higher-level applications:
– AVG_E (Average value exists)
– MIN_E (Minimum value exists)
– MAX_E (Maximum value exists)
– TOT_E (Total value exists)
Use MIN_E, MAX_E, and AVG_E if values are reported in the minimum
(Msmt_Min_Val), maximum (Msmt_Max_Val), and average (Msmt_Avg_Val)
columns in the Measurement table. Typically, when management data is
summarized, the information that is produced is the minimum, maximum, and
average values for the interval. For example, an application might have the
minimum, maximum, and average response time values over the duration of an
hour. Another example would be that the minimum, maximum, and average
number of connected users would be summarized over the duration of an hour.
For rules associated with all measurement tables, see “Measurement (Msmt)” on
page 37.
Table 75 on page 72 lists the measurement groups that are created by the
twh_cdw_data.generic.
Table 76. Measurement Group (MGrp Table)
MGrp_Cd MGrpTyp_Cd MGrp_Parent_Cd MGrp_Nm
AVG_E GROUP NULL Average Value Exists
AVL CATEG NULL Availability
DISABL COLL NULL Measurements that are
Not Currently Available
for Data Collection
MAX_E GROUP NULL Maximum Value Exists
MIN_E GROUP NULL Minimum Value Exists
PERF CATEG NULL Performance
STATE CATEG NULL Percentage State
Measurements
STORAG CATEG NULL Storage
TOT_E GROUP NULL Total Value Exists
Chapter 3. Common static data 73
Table 76. Measurement Group (MGrp Table) (continued)
MGrp_Cd MGrpTyp_Cd MGrp_Parent_Cd MGrp_Nm
UTIL CATEG NULL Utilization
Measurement Type
This table defines what types of measurements are valid for a component type.
The following rules are associated with measurement types:
v Do not use abbreviations and acronyms in the MsmtTyp_Nm and MsmtTyp_Ds
columns of the Measurement Type table. These column contain strings that
appear on reports. If the data is used by cross-application reporting or
higher-level applications, warehouse pack-specific abbreviations appear out of
context and lose some of their meaning. Tivoli Developers: In addition, the use
of abbreviations can create legal problems.
v Use the common measurement types defined in twh_cdw_data.generic if
possible. Table 77 lists the common measurement types defined in
twh_cdw_data.generic. If your measurement type is warehouse pack-specific,
create a new entry in the measurement type table. Place your product code in
the measurement source code (MSrc_Cd) column to identify the measurement
type as unique to your warehouse pack.
For rules associated with all measurement tables, see “Measurement (Msmt)” on
page 37.
Note: In the measurement type table (Table 77), the MsmtTyp_ID column is a
sequence number that is populated by a trigger program when a new type
is added to the table. The MsmtTyp_ID column is initialized to 0 . When the
trigger program runs, it replaces the zero value with a unique ascending
sequence number ( 1 , 2 , 3 , 4 , and so on) beginning with the value 1 .
Table 77. Measurement Type (MsmtTyp Table)
MsmtTyp_ID MUnit_Cd MSrc_Cd MsmtTyp_Nm MsmtTyp_Ds
MODEL1 measurement types
1 Min MODEL1 Available The amount of time that the
resource is available
2 MB MODEL1 Available Memory The amount of free memory
3 PRC MODEL1 Bandwidth Utilization Bandwidth utilization
4 PRC MODEL1 Busy Device is busy
5 MB MODEL1 Capacity Capacity
6 Min MODEL1 Closing The amount of time that it took
to close the problem with the
resource
7 Min MODEL1 Degrading The amount of time that the
resource is degrading
8 PRC MODEL1 Device Unknown Device status is unknown
9 Hr MODEL1 Duration The amount of time needed to
complete the process
10 MB MODEL1 Free Space Free Space
74 Tivoli Data Warehouse Schema Reference
Table 77. Measurement Type (MsmtTyp Table) (continued)
MsmtTyp_ID MUnit_Cd MSrc_Cd MsmtTyp_Nm MsmtTyp_Ds
11 PRC MODEL1 Hardware Error Device is in the hardware error
state
12 QTY MODEL1 Hits Number of hits processed by the
Web Server
13 Qps MODEL1 Inbound Discard Rate Inbound discard rate
14 KB MODEL1 Kilobytes Sent Number of kilobytes sent from
the server
15 KB MODEL1 Largest Outstanding The largest message outstanding
Message
16 PRC MODEL1 No Device Device is not present
17 QTY MODEL1 Number of Bytes Received The number of bytes received
18 Qps MODEL1 Number of Bytes Received Number of bytes received rate
Rate
19 QTY MODEL1 Number of Bytes Sent The number of bytes sent
20 Qps MODEL1 Number of Bytes Number of bytes transmitted
Transmitted Rate rate
21 QTY MODEL1 Number of Runs The number of runs
22 QTY MODEL1 Number of Servers The number or quantity of
servers
23 QTY MODEL1 Number of Transactions The number of times that the
resource has changed state
24 QTY MODEL1 Number of Unsuccessful The number of runs that failed
Runs
25 QTY MODEL1 Number of Web Server The number of Web Server 500s
Errors status codes
26 PRC MODEL1 Offline Device offline
27 PRC MODEL1 Online Device online
28 Qps MODEL1 Outbound Discard Rate Outbound discard rate
29 PRC MODEL1 Powered Off Device is powered off
30 PRC MODEL1 Processor Utilization Processor utilization
31 Qps MODEL1 Receive Packet Rate Receive packet rate
32 PRC MODEL1 Receive Utilization Receive utilization
33 Min MODEL1 Repairing The amount of time that it took
to fix the problem associated
with the resource
34 Min MODEL1 Responding The amount of time that it took
to detect, isolate, and respond to
a problem with the resource
35 MSec MODEL1 Response Time The amount of time it took a
process to respond
36 Qps MODEL1 Transmit Packet Rate Transmit packet rate
37 PRC MODEL1 Transmit Utilization Transmit utilization
38 Min MODEL1 Unavailable The amount of time that the
resource is unavailable
Chapter 3. Common static data 75
Table 77. Measurement Type (MsmtTyp Table) (continued)
MsmtTyp_ID MUnit_Cd MSrc_Cd MsmtTyp_Nm MsmtTyp_Ds
39 Min MODEL1 Unknown The amount of time that the
state of the resource is unknown
40 Min MODEL1 Unmanaged The amount of time that the
resource is unmanaged
41 Min MODEL1 Unreachable The amount of time that the
resource is unreachable
42 MB MODEL1 Used Space Used space
43 PRC MODEL1 User Error Device is in the user error state
Service desk measurement types
44 QTY SDESK1 Number of Cancelled The number of change requests
Change Requests that were cancelled
45 QTY SDESK1 Number of Closed Change The number of change requests
Requests that have been closed
46 QTY SDESK1 Number of Closed Incidents The number of incidents that
have been closed
47 QTY SDESK1 Number of Emergency The number of emergency
Change Requests change requests
48 QTY SDESK1 Number of Opened Change The number of change requests
Requests that have been opened
49 QTY SDESK1 Number of Opened The number of incidents that
Incidents have been opened
50 QTY SDESK1 Number of Successful The number of change requests
Change Requests that have been implemented
successfully
51 QTY SDESK1 Number of Successful The number of change requests
Change Requests With that were implemented
Problems successfully with some problems
52 QTY SDESK1 Number of Unsuccessful The number of change requests
Change Requests that were unsuccessful
53 QTY SDESK1 Number of Withdrawn The number of change requests
Change Requests that were withdrawn
54 PRC SDESK1 Percent of Cancelled Change The percent of change requests
Requests that were cancelled
55 PRC SDESK1 Percent of Emergency The percent of change requests
Change Requests that were emergency requests
56 PRC SDESK1 Percent of Successful The percent of change requests
Change Requests that were implemented
successfully
57 PRC SDESK1 Percent of Successful The percent of change requests
Change Requests With that were implemented
Problems successfully with problems
58 PRC SDESK1 Percent of Unsuccessful The percent of change requests
Change Requests that were unsuccessful
59 PRC SDESK1 Percent of Withdrawn The percent of change requests
Change Requests that were withdrawn
SNMP measurement types
76 Tivoli Data Warehouse Schema Reference
Table 77. Measurement Type (MsmtTyp Table) (continued)
MsmtTyp_ID MUnit_Cd MSrc_Cd MsmtTyp_Nm MsmtTyp_Ds
60 PRC SNMP Bandwidth Utilization for (IfInOctets+IfOutOctets)*8*100/
Number of Octets time*IfSpeed IfSpeed is an
estimate of the current
bandwidth in bits per second.
IfSpeed = 1.3.6.1.2.1.2.2.1.5
61 PRC SNMP Interface Input Error Rate IfInErrors * 100 / (IfInUcastPkts
+ IfInNUcastPkts)
62 PRC SNMP Interface Output Error Rate IfOutErrors *
100/(IfInOutUcastPkts +
IfOutNUcastPkts
63 PRC SNMP Medium Buffer Ratio (BufferMdMiss/bufferMdHit) *
100 bufferMdMiss
(1.3.6.1.4.1.9.2.1.27) contains the
number of medium buffer
misses. BufferMdHit contains the
number of medium buffer hits.
1.3.6.1.4.1.9.2.1.26
64 PRC SNMP avgBusy5 5 minutes exponentially-decayed
moving average of the CPU
busy percentage.
1.3.6.1.4.1.9.2.1.58
65 QTY SNMP bufferNoMem Count of the number of buffer
create failures due to no free
memory. 1.3.6.1.4.1.9.2.1.47
66 B SNMP ciscomemoryPoolFree Number of bytes from memory
pool that are currently unused
on the managed device. Sum of
ciscoMemoryPoolUsed and
ciscoMemoryPoolFree is total
amount of memory in the pool.
1.3.6.1.4.1.9.9.48.1.1.1.6
67 PRC SNMP cpmCPUTotal5min The overall CPU busy
percentage in the 5 minute
period. 1.3.6.1.4.1.9.9.109.1.1.1.1.5
68 QTY SNMP etherStatsBroadcastPkts Total number of good packets
received directed to the
broadcast address. This does not
include multicast packets.
1.3.6.1.2.1.16.1.1.1.6
69 QTY SNMP etherStatsCRCAlignErrors Total number of packets received
with valid size with checksum or
alignment errors.
1.3.6.1.2.1.16.1.1.1.11
70 QTY SNMP etherStatsFragments Total number of packets received
with fewer than 64 octets, with
checksum or alignment errors.
1.3.6.1.2.1.16.1.1.1.11
71 QTY SNMP etherStatsJabbers Total number of packets received
longer than 1518 with checksum
or alignment errors.
1.3.6.1.2.1.16.1.1.1.12
Chapter 3. Common static data 77
Table 77. Measurement Type (MsmtTyp Table) (continued)
MsmtTyp_ID MUnit_Cd MSrc_Cd MsmtTyp_Nm MsmtTyp_Ds
72 QTY SNMP etherStatsMulticastPkts Total number of good packets
that are received directed to a
multicast address (excluding
broadcast addresses).
1.3.6.1.2.1.16.1.1.1.7
73 QTY SNMP etherStatsOctets Total Number of octets
(including those in bad packets)
received on the network. This
excludes framing bits, but
includes Frame Check Sum
(FCS) octets. 1.3.6.1.2.1.16.1.1.1.4
74 QTY SNMP ifInBroadcastPkts Number of packets, delivered by
this sub-layer to a higher
(sub-)layer, which were
addressed to a broadcast address
at this sub-layer.
1.3.6.1.2.1.31.1.1.1.3
75 QTY SNMP ifInDiscards Number of inbound packets
which were chosen to be
discarded even though no errors
had been detected to prevent
their being delivered to a
higher-layer protocol.
1.3.6.1.2.1.2.2.1.13
76 QTY SNMP ifInErrors For packet-oriented interfaces,
the number of inbound packets
that contained errors preventing
them from being delivered to a
higher-layer protocol.
1.3.6.1.2.1.2.2.1.14
77 QTY SNMP ifInMulticastPkts Number of packets, delivered by
this sub-layer to a higher
(sub-)layer, which were
addressed to a multicast address
at this sub-layer.
1.3.6.1.2.1.31.1.1.2
78 QTY SNMP ifInNUcastPkts Number of packets, delivered by
this sub-layer to a higher
(sub-)layer, which were
addressed to a multicast or
broadcast address at this
sub-layer. 1.3.6.1.2.1.31.1.1.1.3
79 QTY SNMP ifInOctets The total number of octets
received on the interface,
including framing characters.
1.3.6.1.2.1.2.2.1.10
80 QTY SNMP ifInUcastPkts Number of packets, delivered by
this sub-layer to a higher
(sub-)layer, which were not
addressed to a multicast or
broadcast address at this
sub-layer. 1.3.6.1.2.1.2.2.1.17
78 Tivoli Data Warehouse Schema Reference
Table 77. Measurement Type (MsmtTyp Table) (continued)
MsmtTyp_ID MUnit_Cd MSrc_Cd MsmtTyp_Nm MsmtTyp_Ds
81 QTY SNMP ifOutBroadcastPkts Number of packets that
higher-level protocols requested
be transmitted, and which were
addressed to a broadcast address
at this sub-layer, including those
that were discarded or not sent.
1.3.6.1.2.1.31.1.1.1.5
82 QTY SNMP ifOutDiscards The number of outbound
packets which were chosen to be
discarded even though no errors
had been detected to prevent
their being transmitted.
1.3.6.1.2.1.2.2.1.19
83 QTY SNMP ifOutErrors For packet-oriented interfaces,
the number of outbound packets
that could not be transmitted
because of errors.
1.3.6.1.2.1.2.2.1.20
84 QTY SNMP ifOutMulticastPkts Number of packets that
higher-level protocols requested
be transmitted, and which were
addressed to a multicast address
at this sub-layer, including those
that were discarded or not sent.
1.3.6.1.2.1.31.1.1.1.4
85 QTY SNMP ifOutOctets The total number of octets
transmitted out of the interface,
including framing characters.
1.3.6.1.2.1.2.2.1.16
86 QTY SNMP ifOutUcastPkts Total number of packets that
higher-level protocols requested
to be transmitted, and which
were not addressed to a
multicast or broadcast address at
this sub-layer, including those
that were discarded or not sent.
1.3.6.1.2.1.2.2.1.17
87 PRC SNMP sysTraffic Traffic meter value, i.e. the
percentage of bandwidth
utilization for the previous
polling interval.
1.3.6.1.4.1.9.1.5.1.1.8
88 PRC SNMP sysTrafficMeter Traffic meter value, i.e. the
percentage of bandwidth
utilization for the previous
polling interval. 1.3.6.1.4.1.9.5.1.1.32.1.2
Measurement Rule
This table defines what measurement types are valid for each component type.
Chapter 3. Common static data 79
Table 78 lists the common measurement rules defined in the common static data
script, twh_cdw_data.generic. If the common static data script does not define a
rule for the combination your warehouse pack needs, create a rule in your
warehouse pack-specific static data file, productCode_cdw_data.generic.
Table 78. Measurement Rule (MsmtRul Table)
CompTyp_Cd MsmtTyp_ID Comments
Note: This column is not part of the MsmtRul table.
IPX_INTERFACE 1 This measurement type ID value 1 corresponds to the
measurement type name value Available
IPX_INTERFACE 6 This measurement type ID value 6 corresponds to the
measurement type name value Closing
IPX_INTERFACE 7 This measurement type ID value 7 corresponds to the
measurement type name value Degrading
IPX_INTERFACE 33 This measurement type ID value 33 corresponds to the
measurement type name value Repairing
IPX_INTERFACE 34 This measurement type ID value 34 corresponds to the
measurement type name value Responding
IPX_INTERFACE 38 This measurement type ID value 38 corresponds to the
measurement type name value Unavailable
IPX_INTERFACE 39 This measurement type ID value 39 corresponds to the
measurement type name value Unknown
IPX_INTERFACE 40 This measurement type ID value 40 corresponds to the
measurement type name value Unmanaged
IPX_INTERFACE 41 This measurement type ID value 41 corresponds to the
measurement type name value Unreachable
IP_HOST 1 This measurement type ID value 1 corresponds to the
measurement type name value Available
IP_HOST 6 This measurement type ID value 6 corresponds to the
measurement type name value Closing
IP_HOST 7 This measurement type ID value 7 corresponds to the
measurement type name value Degrading
IP_HOST 33 This measurement type ID value 33 corresponds to the
measurement type name value Repairing
IP_HOST 34 This measurement type ID value 34 corresponds to the
measurement type name value Responding
IP_HOST 38 This measurement type ID value 38 corresponds to the
measurement type name value Unavailable
IP_HOST 39 This measurement type ID value 39 corresponds to the
measurement type name value Unknown
IP_HOST 40 This measurement type ID value 40 corresponds to the
measurement type name value Unmanaged
IP_HOST 41 This measurement type ID value 41 corresponds to the
measurement type name value Unreachable
IP_INTERFACE 1 This measurement type ID value 1 corresponds to the
measurement type name value Available
IP_INTERFACE 6 This measurement type ID value 6 corresponds to the
measurement type name value Closing
IP_INTERFACE 7 This measurement type ID value 7 corresponds to the
measurement type name value Degrading
80 Tivoli Data Warehouse Schema Reference
Table 78. Measurement Rule (MsmtRul Table) (continued)
CompTyp_Cd MsmtTyp_ID Comments
Note: This column is not part of the MsmtRul table.
IP_INTERFACE 33 This measurement type ID value 33 corresponds to the
measurement type name value Repairing
IP_INTERFACE 34 This measurement type ID value 34 corresponds to the
measurement type name value Responding
IP_INTERFACE 38 This measurement type ID value 38 corresponds to the
measurement type name value Unavailable
IP_INTERFACE 39 This measurement type ID value 39 corresponds to the
measurement type name value Unknown
IP_INTERFACE 40 This measurement type ID value 40 corresponds to the
measurement type name value Unmanaged
IP_INTERFACE 41 This measurement type ID value 41 corresponds to the
measurement type name value Unreachable
TME_ENDPOINT 1 This measurement type ID value 1 corresponds to the
measurement type name value Available
TME_ENDPOINT 6 This measurement type ID value 6 corresponds to the
measurement type name value Closing
TME_ENDPOINT 7 This measurement type ID value 7 corresponds to the
measurement type name value Degrading
TME_ENDPOINT 33 This measurement type ID value 33 corresponds to the
measurement type name value Repairing
TME_ENDPOINT 34 This measurement type ID value 34 corresponds to the
measurement type name value Responding
TME_ENDPOINT 38 This measurement type ID value 38 corresponds to the
measurement type name value Unavailable
TME_ENDPOINT 39 This measurement type ID value 39 corresponds to the
measurement type name value Unknown
TME_ENDPOINT 40 This measurement type ID value 40 corresponds to the
measurement type name value Unmanaged
TME_ENDPOINT 41 This measurement type ID value 41 corresponds to the
measurement type name value Unreachable
WEBSITE 1 This measurement type ID value 1 corresponds to the
measurement type name value Available
WEBSITE 6 This measurement type ID value 6 corresponds to the
measurement type name value Closing
WEBSITE 7 This measurement type ID value 7 corresponds to the
measurement type name value Degrading
WEBSITE 33 This measurement type ID value 33 corresponds to the
measurement type name value Repairing
WEBSITE 34 This measurement type ID value 34 corresponds to the
measurement type name value Responding
WEBSITE 38 This measurement type ID value 38 corresponds to the
measurement type name value Unavailable
WEBSITE 39 This measurement type ID value 39 corresponds to the
measurement type name value Unknown
WEBSITE 40 This measurement type ID value 40 corresponds to the
measurement type name value Unmanaged
Chapter 3. Common static data 81
Table 78. Measurement Rule (MsmtRul Table) (continued)
CompTyp_Cd MsmtTyp_ID Comments
Note: This column is not part of the MsmtRul table.
WEBSITE 41 This measurement type ID value 41 corresponds to the
measurement type name value Unreachable
WEBSITE_PATH 1 This measurement type ID value 1 corresponds to the
measurement type name value Available
WEBSITE_PATH 6 This measurement type ID value 6 corresponds to the
measurement type name value Closing
WEBSITE_PATH 7 This measurement type ID value 7 corresponds to the
measurement type name value Degrading
WEBSITE_PATH 33 This measurement type ID value 33 corresponds to the
measurement type name value Repairing
WEBSITE_PATH 34 This measurement type ID value 34 corresponds to the
measurement type name value Responding
WEBSITE_PATH 38 This measurement type ID value 38 corresponds to the
measurement type name value Unavailable
WEBSITE_PATH 39 This measurement type ID value 39 corresponds to the
measurement type name value Unknown
WEBSITE_PATH 40 This measurement type ID value 40 corresponds to the
measurement type name value Unmanaged
WEBSITE_PATH 41 This measurement type ID value 41 corresponds to the
measurement type name value Unreachable
WEBSITE_QUERY 1 This measurement type ID value 1 corresponds to the
measurement type name value Available
WEBSITE_QUERY 6 This measurement type ID value 6 corresponds to the
measurement type name value Closing
WEBSITE_QUERY 7 This measurement type ID value 7 corresponds to the
measurement type name value Degrading
WEBSITE_QUERY 33 This measurement type ID value 33 corresponds to the
measurement type name value Repairing
WEBSITE_QUERY 34 This measurement type ID value 34 corresponds to the
measurement type name value Responding
WEBSITE_QUERY 38 This measurement type ID value 38 corresponds to the
measurement type name value Unavailable
WEBSITE_QUERY 39 This measurement type ID value 39 corresponds to the
measurement type name value Unknown
WEBSITE_QUERY 40 This measurement type ID value 40 corresponds to the
measurement type name value Unmanaged
WEBSITE_QUERY 41 This measurement type ID value 41 corresponds to the
measurement type name value Unreachable
Attribute Type
Table 79 on page 83 lists the attribute types that are defined by the common static
data script, twh_cdw_data.generic.
For LOGICAL_PARTITION, the following guidelines apply:
82 Tivoli Data Warehouse Schema Reference
v The component name is the logical partition name that is available on the z/OS
platform. This value must be 8 characters long and is defined when the machine
is configured.
v The logical partition ID is available on the z/OS platform. This value is a
hexadecimal number that can be up to 15 characters long and is defined when
the machine is configured.
Table 79. Attribute Type (AttrTyp Table)
AttrTyp_Cd AttrTyp_Nm MSrc_ Comments
Corr_Cd Note: This column is not part of the AttrTyp table.
UNSET attribute types
END_TIME End Time MODEL1
LOGICAL_PART_ID Logical Partition MODEL1 This value is the Logical Partition ID that is available
ID on the z/OS platform. This value is a hexadecimal
number that can be up to 15 characters long and is
defined when the machine is configured.
MAX_CLOCK_SPEED Maximum Clock MODEL1
Speed
MAX_MEDIA_SIZE Maximum Media MODEL1
Size
PHYSICAL_MEMORY Physical Memory MODEL1
START_TIME Start Time MODEL1
SYSTEM_ID System ID MODEL1
SYSTEM_GUID System Global MODEL1 Represents a globally unique identifier (GUID). The
Unique Identifier value for the SYSTEM_GUID attribute type is
provided by the source application.
Base attribute types
ABSTRACT Abstract MODEL1 This attribute type specifies the abstract.
APPROVAL_TIMESTAP Approval MODEL1 This attribute type specifies the approval timestamp.
Timestamp
APPROVER_NAME Approver Name MODEL1 This attribute type specifies the approver name.
ASSIGNEE_NAME Assignee Name MODEL1 This attribute type specifies the assignee name.
BIOS_INFO BIOS Information MODEL1
CELL_PHONE_NUMBER Cell Phone MODEL1 This attribute type specifies the cell phone number.
Number
CLOSED_BY Closed By MODEL1 This attribute type specifies the closed by entity.
CLOSE_TIMESTAMP Close Timestamp MODEL1 This attribute type specifies the closed timestamp.
COMPANY Company MODEL1 This attribute type specifies the company.
CONTACT Contact Name MODEL1 This attribute type specifies the contact name.
CPU_MODEL_TYPE CPU Model Type MODEL1 This attribute type specifies the model type for the
central processing unit.
CPU_MODEL_VERSION CPU Model MODEL1 This attribute type specifies the model version for the
Version central processing unit.
DEPARTMENT Department MODEL1 This attribute type specifies the department.
DESCRIPTION Description MODEL1 This attribute type specifies a longer user-defined
explanation of the resource for display to users.
DIVISION Division MODEL1 This attribute type specifies the division.
DUE_DATE Due Date MODEL1 This attribute type specifies the due date.
Chapter 3. Common static data 83
Table 79. Attribute Type (AttrTyp Table) (continued)
AttrTyp_Cd AttrTyp_Nm MSrc_ Comments
Corr_Cd Note: This column is not part of the AttrTyp table.
EMPLOYEE_NUMBER Employee MODEL1 This attribute type specifies the employee number.
Number
E_MAIL_ADDRESS E-Mail Address MODEL1 This attribute type specifies the e-mail address.
FIRST_CALL_RES First Call MODEL1 This attribute type specifies the first call resolution.
Resolution
FIRST_NAME First Name MODEL1 This attribute type specifies the first name.
FIX_TIME Incident Fix Time MODEL1 This attribute type specifies the incident fix time.
GROUP Group MODEL1 This attribute type specifies the assignment group.
GUID Global Unique MODEL1 This attribute type specifies the globally unique
Identifier identifier.
IMPACT Impact MODEL1 This attribute type specifies the impact of an entity.
INVOKING_USER Invoking User MODEL1 This attribute type specifies the invoking user.
LAST_NAME Last Name MODEL1 This attribute type specifies the last name.
LLB_BUCKET_1 Bucket 1 Lower MODEL1 This attribute type specifies the lower limit boundary
Limit Boundary for bucket 1.
LLB_BUCKET_2 Bucket 2 Lower MODEL1 This attribute type specifies the lower limit boundary
Limit Boundary for bucket 2.
LLB_BUCKET_3 Bucket 3 Lower MODEL1 This attribute type specifies the lower limit boundary
Limit Boundary for bucket 3.
LLB_BUCKET_4 Bucket 4 Lower MODEL1 This attribute type specifies the lower limit boundary
Limit Boundary for bucket 4.
LLB_BUCKET_5 Bucket 5 Lower MODEL1 This attribute type specifies the lower limit boundary
Limit Boundary for bucket 5.
NAME Name MODEL1 This attribute type specifies the name of the entity,
for example, the component name. It can change over
time although the entity would remain the same.
NAME_GUID Name Global MODEL1 This attribute type specifies the name global unique
Unique Identifier identifier.
OPEN_TIMESTAMP Open Timestamp MODEL1 This attribute type specifies the open timestamp.
ORGANIZATION Organization MODEL1 This attribute type specifies the organization
associated with the entity.
OS_NAME Operating System MODEL1 This attribute type specifies the name of the
Name operating system. This attribute type can be different
depending on the source application that provides
the value. It is expected to be the value returned
when using the standard API call to get the value.
This is in contrast to the architecturally predefined
values in OS_TYPE.
OS_TYPE Operating System MODEL1 This attribute type specifies the type of operating
Type system running on this machine. The values for this
attribute type must be one of the following values. If
you need an operating systems that is not in this list,
contact the enablement team.
OWNER Owner MODEL1 This attribute type specifies the person or
organization that owns the entity. It can change over
time, but the entity remains the same.
PHONE_NUMBER Phone Number MODEL1 This attribute type specifies the phone number.
84 Tivoli Data Warehouse Schema Reference
Table 79. Attribute Type (AttrTyp Table) (continued)
AttrTyp_Cd AttrTyp_Nm MSrc_ Comments
Corr_Cd Note: This column is not part of the AttrTyp table.
PRIORITY Priority MODEL1 This attribute type specifies the priority of an entity.
MACHINE_TYPE Machine Type MODEL1 This attribute type specifies the machine type of the
device, as determined by the manufacturer of the
machine. Use this attribute type only for components
that represent hardware devices.
MAJOR_VERSION Major Version MODEL1 This attribute type specifies the major version
Number number of the software or hardware represented by
this component or by the primary software installed
on this component. For example, for the IP_HOST
attribute type, this is the operating system. For
® example, if the operating system was Windows NT
5.1, the major version would be 5. Manufacturers
generally do not guarantee forward compatibility
across major version changes.
MANAGED_BY Managed by MODEL1 This attribute type specifies who manages the entity.
MANUFACTURER Manufacturer MODEL1 This attribute type specifies the name of the company
that manufactured the component. The name should
be the full, registered trademark version of the name,
such as Sun Microsystems or IBM , to foster
commonality across warehouse packs.
MINOR_VERSION Minor Version MODEL1 This attribute type specifies the minor version
Number number of the software or hardware represented by
this component or the primary software installed on
this component. For example, for the IP_HOST
attribute, this is the operating system. For example, if
the operating system was Windows NT 5.1, the
minor version would be 1. Manufacturers generally
guarantee forward compatibility across minor version
changes.
MODEL Model MODEL1 This attribute type specifies the model number of the
Specification for component. The model number commonly is unique
this Hardware for a particular machine type, but can be globally
Device unique. Use this attribute type only for components
that represent hardware devices.
SERIAL_NUMBER Serial Number MODEL1 This attribute type specifies the serial number of the
component, which should uniquely identify the
component in some context other than the
management repository. For example, a machine
serial number uniquely identifies a machine in the
context of its manufacturer. An employee serial
number uniquely identifies a person within a
company.
SEVERITY Severity MODEL1 This attribute type specifies the severity of an entity.
SITE Site MODEL1 This attribute type specifies the site.
SUB_VERSION Sub Version MODEL1 This attribute type specifies additional information
Number that uniquely identifies the version for hardware, a
software component, or the primary software
installed on this component. It might represent the
build level or a patch level.
TYPE Type MODEL1 This attribute type specifies a value that allows
everyone to know the type, category, or class of an
entity.
Chapter 3. Common static data 85
Table 79. Attribute Type (AttrTyp Table) (continued)
AttrTyp_Cd AttrTyp_Nm MSrc_ Comments
Corr_Cd Note: This column is not part of the AttrTyp table.
ULB_BUCKET_1 Bucket 1 Upper MODEL1 This attribute type specifies the upper limit boundary
Limit Boundary for bucket 1.
ULB_BUCKET_2 Bucket 2 Upper MODEL1 This attribute type specifies the upper limit boundary
Limit Boundary for bucket 2.
ULB_BUCKET_3 Bucket 3 Upper MODEL1 This attribute type specifies the upper limit boundary
Limit Boundary for bucket 3.
ULB_BUCKET_4 Bucket 4 Upper MODEL1 This attribute type specifies the upper limit boundary
Limit Boundary for bucket 4.
ULB_BUCKET_5 Bucket 5 Upper MODEL1 This attribute type specifies the upper limit boundary
Limit Boundary for bucket 5.
USER_LABEL Label for a MODEL1 This attribute type specifies a component name that
Component is provided by the user of the source application.
Consumer applications can use this field to display
customized names for components. Use this field
only for a previously-entered customer alias.
VERSION Version Number MODEL1 This attribute type specifies the complete version
string for this component. This will typically be the
concatenation of the major, minor, and sub versions.
Business systems attribute types
BUSINESS_SYSTEM Business System MODEL1 This attribute type specifies the business system.
IP attribute types
INTERFACE_NAME Interface Name MODEL1 This attribute specifies the name of the interface.
IP_DOMAIN IP Domain MODEL1 This attribute type specifies the domain within which
host names are allocated. For example, in the fully
qualified host name groucho.raleigh.ibm.com , the
domain is raleigh.ibm.com . This attribute type
should only be used for domains that are related to
host names that are used in the IP protocol suite.
Other protocols should use similar, but different
attribute types.
IP_HOSTNAME IP Hostname MODEL1 This attribute type specifies the fully qualified name
of the IP host that is identified by an application. If
only the short name is available, enter it in the
IP_SHORT_HOSTNAME attribute type.
IP_SHORT_HOSTNAME IP Short MODEL1 This attribute type specifies the short name of the IP
Hostname host that is identified by an application.
IP_NET_ADDRESS IP Network MODEL1 This attribute type specifies the IP network address.
Address
LAST_IP_ADDRESS Last IP Address MODEL1 This attribute type specifies the last known IP
address.
LOCAL_IP_ADDR Local IP Address MODEL1 This attribute type specifies the local IP address.
LOCAL_PORT Local Port MODEL1 This attribute type specifies the local port.
REMOTE_IP_ADDR Remote IP MODEL1 This attribute type specifies the remote IP address.
Address
REMOTE_PORT Remote Port MODEL1 This attribute type specifies the remote port.
MQ attribute types
86 Tivoli Data Warehouse Schema Reference
Table 79. Attribute Type (AttrTyp Table) (continued)
AttrTyp_Cd AttrTyp_Nm MSrc_ Comments
Corr_Cd Note: This column is not part of the AttrTyp table.
MQ_ADAPTER_TYPE MQ Adapter MODEL1 This attribute type specifies the MQ adapter type.
Type
Service desk attribute types
CHANGE_REQUEST Change Requests SDESK1 This attribute type specifies change requests.
INCIDENT Incident SDESK1 This attribute type specifies the incident
SD_ASSETS_AFFECTD Assets Affected SDESK1 This attribute type specifies the assets affected.
SD_ASSIGN_GROUP Assignment SDESK1 This attribute type specifies the assignment group.
Group
SD_CAUSE_CODE Incident Cause SDESK1 This attribute type specifies the incident cause code.
Code
SD_COMPONENT Service Desk SDESK1 This attribute type specifies the component.
Component
SD_ITEM Service Desk Item SDESK1 This attribute type specifies the item.
SD_MODULE Service Desk SDESK1 This attribute type specifies the module.
Module
SD_PROBLEM_TYPE Problem Type SDESK1 This attribute type specifies the problem type.
SD_PRODUCT_TYPE Product Type SDESK1 This attribute type specifies the product type.
SD_RELATED_CHNGS Related Changes SDESK1 This attribute type specifies the related changes.
SD_RELATED_INCS Related Incidents SDESK1 This attribute type specifies the related incidents.
SD_REPORTD_BY_NM Reported By SDESK1 This attribute type specifies the reported by name.
SD_RISK_LEVEL Risk Level SDESK1 This attribute type specifies the risk level.
SD_SITE_CATEGORY Site Category SDESK1 This attribute type specifies the site category.
SD_STATUS_CODE Service Desk SDESK1 This attribute type specifies the status code.
Status Code
SD_SYSTEM Service Desk SDESK1 This attribute type specifies the system.
System
Service desk change attribute types
CHANGE Change Request SDESK1 This attribute type specifies the change request.
CR_ACT_END Change Request SDESK1 This attribute type specifies the actual end date and
Actual End Date time.
and Time
CR_ACT_OUTAGE_ED Change Request SDESK1 This attribute type specifies the actual outage end
Actual Outage date and time.
End Date and
Time
CR_ACT_OUTAGE_ST Change Request SDESK1 This attribute type specifies the actual outage start
Actual Outage date and time.
Start Date and
Time
CR_ACT_START Change Request SDESK1 This attribute type specifies the actual start date and
Actual Start Date time.
and Time
CR_APP_ACTION Change Request SDESK1 This attribute type specifies the approval actions.
Approval Actions
Chapter 3. Common static data 87
Table 79. Attribute Type (AttrTyp Table) (continued)
AttrTyp_Cd AttrTyp_Nm MSrc_ Comments
Corr_Cd Note: This column is not part of the AttrTyp table.
CR_APP_STATUS Change Request SDESK1 This attribute type specifies the approval status.
Approval Status
CR_BACKOUT_PLAN Change Request SDESK1 This attribute type specifies the backout plan.
Backout Plan
CR_COMPLETE_DATE Change Request SDESK1 This attribute type specifies the completion date.
Complete Date
CR_COMPLETION_CD Completion Code SDESK1 This attribute type specifies the completion code.
CR_END_DELAY Change Request SDESK1 This attribute type specifies the end delay in minutes.
End Delay (in
minutes)
CR_PLAN_END Change Request SDESK1 This attribute type specifies the planned end date
Planned End and time.
Date and Time
CR_PLAN_OUTAGE_ED Change Request SDESK1 This attribute type specifies the planned outage end
Planned Outage date and time.
End Date and
Time
CR_PLAN_OUTAGE_ST Change Request SDESK1 This attribute type specifies the planned outage start
Planned Outage date and time.
Start Date and
Time
CR_PLAN_START Change Request SDESK1 This attribute type specifies the planned start date
Planned Start and time.
Date and Time
CR_PRIORITY Change Request SDESK1 This attribute type specifies the priority.
Priority
CR_REQUEST_DATE Requested Date SDESK1 This attribute type specifies the requested date for
for the Change the change request.
Request
CR_START_DELAY Change Request SDESK1 This attribute type specifies the start delay.
Start Delay (in
minutes)
CR_STATUS_CODE Change Request SDESK1 This attribute type specifies the status code.
Status Code
SD_COORDINATOR_NM Change Request SDESK1 This attribute type specifies the coordinator name.
Coordinator
Name
Service desk task attribute types
CR_TASK Task SDESK1 This attribute type specifies the task.
CR_TASK_DESC Task Description SDESK1 This attribute type specifies the task description.
CR_TASK_PHASE Task Phase SDESK1 This attribute type specifies the task phase.
CR_TASK_STATUS Task Status SDESK1 This attribute type specifies the task status.
Service desk user attribute types
SD_USERID User SDESK1 This attribute type specifies the user ID.
Identification
(User ID)
SD_USER_TYPE User Type SDESK1 This attribute type specifies the user type.
88 Tivoli Data Warehouse Schema Reference
Table 79. Attribute Type (AttrTyp Table) (continued)
AttrTyp_Cd AttrTyp_Nm MSrc_ Comments
Corr_Cd Note: This column is not part of the AttrTyp table.
Services attribute types
SERVICE Service MODEL1 This attribute type specifies the service.
SNA attribute types
SNA_CCU_TYPE SNA MODEL1 This attribute type specifies the SNA communication
Communication control unit type.
Control Unit
Type
SNA_LINE_TYPE SNA Line Type MODEL1 This attribute type specifies the SNA line type.
SNA_PU_TYPE SNA Physical MODEL1 This attribute type specifies the SNA physical unit
Unit Type type.
Software license attribute types
LIC_REF_CODE License Reference MODEL1 This attribute type specifies the license reference
Code code.
SOFTWARE_PRODUCT Software Product MODEL1 This attribute type specifies the software product.
Tivoli Management Framework attribute types
TME_LABEL Tivoli Endpoint MODEL1 This attribute type specifies the endpoint label of a
Label resource.
TME_OBJECT_ID Tivoli Object ID MODEL1 This attribute type specifies the object ID of a
resource.
TME_POLICY_REGION Tivoli Endpoint MODEL1 This attribute type specifies the name of an endpoint
Policy Region policy region.
Web attribute types
URL_PROTOCOL Protocol Portion MODEL1 This attribute type represents the protocol portion of
of a URL a uniform resource locator (URL), known as a
uniform resource identifier (URI) scheme name. For
instance, in the URL
http://www.ibm.com/stock/quote?ticker=IBM , the
protocol is http (without the colon separator
character). This attribute type should only be used
for protocol specifications in a URL, not for general
protocol specification. This attribute type can have
one of the following values, and must be in
lowercase. For additional information see
http://www.iana.org/assignments/uri-schemes.
Web application server attribute types
J2EE_DOMAIN J2EE Domain MODEL1 This attribute type specifies the J2EE domain.
J2EE_NODE J2EE Node MODEL1 This attribute type specifies the J2EE node.
J2EE_SERVER J2EE Server MODEL1 This attribute type specifies the J2EE server.
WAS_CLUSTER IBM WebSphere MODEL1
Application
Server Cluster
z/OS component types
CF_MODEL_TYPE Coupling Facility MODEL1 This attribute type specifies the coupling facility
Model Type model type.
CF_MODEL_VERSION Coupling Facility MODEL1 This attribute type specifies the coupling facility
Model Version model version.
Chapter 3. Common static data 89
Table 79. Attribute Type (AttrTyp Table) (continued)
AttrTyp_Cd AttrTyp_Nm MSrc_ Comments
Corr_Cd Note: This column is not part of the AttrTyp table.
MVS_SUBSYS_TYPE MVS Subsystem MODEL1 This attribute type specifies the MVS subsystem type.
Type
MVS_SYSAPPL_TYPE MVS System MODEL1 This attribute type specifies the MVS system
Application Type application type.
Attribute Rule
This table defines which attributes are valid for a component type. For each
attribute in the Component Attribute table, there must be a corresponding rule
defined in the Attribute Rule table for each attribute type that is valid for a
particular component type.
Table 80 lists the attribute rules that are defined by the common static data script,
twh_cdw_data.generic.
For LOGICAL_PARTITION, the following guidelines apply:
v The component name is the logical partition name that is available on the z/OS
platform. This value must be 8 characters long and is defined when the machine
is configured.
v The logical partition ID is available on the z/OS platform. This value is a
hexadecimal number that can be up to 15 characters long and is defined when
the machine is configured.
Table 80. Attribute Rule (AttrRul Table)
CompTyp_ AttrTyp_Cd AttrRul_Strt_ AttrRul_End_ AttrRul_ AttrTyp_
Cd DtTm DtTm Dom_Ind Multi_Val
CEC CPU_MODEL_TYPE current timestamp - 9999-01- N N
current timezone 01–00.00.00.00
CEC CPU_MODEL_VERSION current timestamp - 9999-01- N N
current timezone 01–00.00.00.00
COMPUTER_ SYSTEM_GUID current timestamp - 9999-01- N N
SYSTEM current timezone 01–00.00.00.00
COUPLING_ CF_MODEL_TYPE current timestamp - 9999-01- N N
FACILITY current timezone 01–00.00.00.00
COUPLING_ CF_MODEL_VERSION current timestamp - 9999-01- N N
FACILITY current timezone 01–00.00.00.00
ENDPOINT SYSTEM_GUID current timestamp - 9999-01- N N
current timezone 01–00.00.00.00
IPX_ CONTACT current timestamp - 9999-01- N N
INTERFACE current timezone 01–00.00.00.00
IPX_ DESCRIPTION current timestamp - 9999-01- N N
INTERFACE current timezone 01–00.00.00.00
IPX_ NAME current timestamp - 9999-01- N N
INTERFACE current timezone 01–00.00.00.00
IPX_ TYPE current timestamp - 9999-01- N N
INTERFACE current timezone 01–00.00.00.00
IPX_ USER_LABEL current timestamp - 9999-01- N N
INTERFACE current timezone 01–00.00.00.00
90 Tivoli Data Warehouse Schema Reference
Table 80. Attribute Rule (AttrRul Table) (continued)
CompTyp_ AttrTyp_Cd AttrRul_Strt_ AttrRul_End_ AttrRul_ AttrTyp_
Cd DtTm DtTm Dom_Ind Multi_Val
IP_HOST CONTACT current timestamp - 9999-01- N N
current timezone 01–00.00.00.00
IP_HOST DESCRIPTION current timestamp - 9999-01- N N
current timezone 01–00.00.00.00
IP_HOST IP_DOMAIN current timestamp - 9999-01- N N
current timezone 01–00.00.00.00
IP_HOST IP_HOSTNAME current timestamp - 9999-01- N N
current timezone 01–00.00.00.00
IP_HOST IP_SHORT_HOSTNAME current timestamp - 9999-01- N N
current timezone 01–00.00.00.00
IP_HOST IP_NET_ADDRESS current timestamp - 9999-01- N N
current timezone 01–00.00.00.00
IP_HOST LAST_IP_ADDRESS current timestamp - 9999-01- N N
current timezone 01–00.00.00.00
IP_HOST NAME current timestamp - 9999-01- N N
current timezone 01–00.00.00.00
IP_HOST TYPE current timestamp - 9999-01- N N
current timezone 01–00.00.00.00
IP_HOST USER_LABEL current timestamp - 9999-01- N N
current timezone 01–00.00.00.00
IP_ CONTACT current timestamp - 9999-01- N N
INTERFACE current timezone 01–00.00.00.00
IP_ DESCRIPTION current timestamp - 9999-01- N N
INTERFACE current timezone 01–00.00.00.00
IP_ IP_DOMAIN current timestamp - 9999-01- N N
INTERFACE current timezone 01–00.00.00.00
IP_ IP_NET_ADDRESS current timestamp - 9999-01- N N
INTERFACE current timezone 01–00.00.00.00
IP_ NAME current timestamp - 9999-01- N N
INTERFACE current timezone 01–00.00.00.00
IP_ TYPE current timestamp - 9999-01- N N
INTERFACE current timezone 01–00.00.00.00
IP_ USER_LABEL current timestamp - 9999-01- N N
INTERFACE current timezone 01–00.00.00.00
J2EE_ MANUFACTURER current timestamp - 9999-01- N N
SERVER current timezone 01–00.00.00.00
J2EE_ VERSION current timestamp - 9999-01- N N
SERVER current timezone 01–00.00.00.00
J2EE_ WAS_CLUSTER current timestamp - 9999-01- N N
SERVER current timezone 01–00.00.00.00
LOGICAL_ LOGICAL_PART_ID current timestamp - 9999-01- N N
PARTITION current timezone 01–00.00.00.00
MQ_ MQ_ADAPTER_TYPE current timestamp - 9999-01- N N
ADAPTER current timezone 01–00.00.00.00
MVS_ MVS_SUBSYS_TYPE current timestamp - 9999-01- N N
SUBSYSTEM current timezone 01–00.00.00.00
Chapter 3. Common static data 91
Table 80. Attribute Rule (AttrRul Table) (continued)
CompTyp_ AttrTyp_Cd AttrRul_Strt_ AttrRul_End_ AttrRul_ AttrTyp_
Cd DtTm DtTm Dom_Ind Multi_Val
MVS_ MVS_SYSAPPL_TYPE current timestamp - 9999-01- N N
SUBSYSTEM current timezone 01–00.00.00.00
SNA_CCU SNA_CCU_TYPE current timestamp - 9999-01- N N
current timezone 01–00.00.00.00
SNA_LINE SNA_LINE_TYPE current timestamp - 9999-01- N N
current timezone 01–00.00.00.00
SNA_PU SNA_PU_TYPE current timestamp - 9999-01- N N
current timezone 01–00.00.00.00
TME_ CONTACT current timestamp - 9999-01- N N
ENDPOINT current timezone 01–00.00.00.00
TME_ DESCRIPTION current timestamp - 9999-01- N N
ENDPOINT current timezone 01–00.00.00.00
TME_ MAJOR_VERSION current timestamp - 9999-01- N N
ENDPOINT current timezone 01–00.00.00.00
TME_ MINOR_VERSION current timestamp - 9999-01- N N
ENDPOINT current timezone 01–00.00.00.00
TME_ NAME current timestamp - 9999-01- N N
ENDPOINT current timezone 01–00.00.00.00
TME_ SUB_VERSION current timestamp - 9999-01- N N
ENDPOINT current timezone 01–00.00.00.00
TME_ TME_LABEL current timestamp - 9999-01- N N
ENDPOINT current timezone 01–00.00.00.00
TME_ TYPE current timestamp - 9999-01- N N
ENDPOINT current timezone 01–00.00.00.00
TME_ USER_LABEL current timestamp - 9999-01- N N
ENDPOINT current timezone 01–00.00.00.00
TME_ VERSION current timestamp - 9999-01- N N
ENDPOINT current timezone 01–00.00.00.00
WAS_NODE_ MANUFACTURER current timestamp - 9999-01- N N
AGENT current timezone 01–00.00.00.00
WAS_NODE_ VERSION current timestamp - 9999-01- N N
AGENT current timezone 01–00.00.00.00
WEBSITE URL_PROTOCOL current timestamp - 9999-01- N N
current timezone 01–00.00.00.00
Event Type
Table 81 defines what types of events are defined by the common static data script,
twh_cdw_data.generic.
Table 81. Event Type (EventTyp Table)
EventTyp_ID EventTyp_Nm MSrc_Cd EventTyp_Ds
NULL Attribute Update EVENTS This event represents a change to
an existing event attribute, such
as status or severity.
92 Tivoli Data Warehouse Schema Reference
Table 81. Event Type (EventTyp Table) (continued)
EventTyp_ID EventTyp_Nm MSrc_Cd EventTyp_Ds
NULL Repeat Count EVENTS This event represents an update
to the initial Repeat_cnt in the
Event table. This value is the
new total and includes the events
that were counted in the
previous total.
Event Attribute Type
Table 82 defines what event attribute types are defined by the common static data
script, twh_cdw_data.generic.
Table 82. Event Attribute Type (EAttrTyp Table)
EAttrTyp_Cd EAttrTyp_Nm MSrc_Cd
IP_HOSTNAME Fully Qualified Hostname EVENTS
Event Group Type
Table 83 defines the valid event group types that are defined by the common static
data script, twh_cdw_data.generic.
Table 83. Event Group Type (EGrpTyp Table)
EGrpTyp_Cd EGrpTyp_Nm
TIVOLI Event Group for Tivoli Products
Attribute domain
The attribute domain (AttrDom) table defines the set of valid values for valid
combinations of attribute types and component types. For the list of valid values
and combinations, look in the common static data script, twh_cdw_data.generic.
Chapter 3. Common static data 93 94 Tivoli Data Warehouse Schema Reference
Chapter 4. Central data warehouse views, sequences, and
triggers
This section describes the views, sequences, and triggers for the tables in the
central data warehouse schema. They are defined in the
%TWH_TOPDIR%\cdw\schema\twh_cdw_create_misc.generic file and created
during the installation of Tivoli Data Warehouse.
The following details are included:
v “Standard views in the TWG_STD schema”
v “Current views in the TWG.cur schema” on page 100
v “Inheritance views in the TWG_STD schema” on page 105
v “Sequences and triggers for the TWG tables” on page 106
Standard views in the TWG_STD schema
The standard views provide an interface to the TWG tables that makes your SQL
independent of the table structure. When reading information in the central data
warehouse, use these views instead of accessing the tables directly. These views
also automatically resolve type aliases to the appropriate derived type. For more
information about derived types, refer to “Event (Event)” on page 28.
This section contains the definition of each standard view.
Standard view for the measurement type (MsmtTyp) table
------
-- a view of standard msmttyps
------
create view __ODS_TWG_STD.msmttyp
as select
m1.msmttyp_id,
m1.munit_cd,
m1.msrc_cd,
m2.msmttyp_nm,
m2.msmttyp_ds
from
__ODS_TWG.cur_msmttyp m1,
__ODS_TWG.cur_mtypreln mr,
__ODS_TWG.msmttyp m2
where
m1.msmttyp_id=mr.mtyp_source_id and
mr.relntyp_cd=’DERIVE’ and
m2.msmttyp_id=mr.mtyp_target_id
union all
select
m1.msmttyp_id,
m1.munit_cd,
m1.msrc_cd,
m1.msmttyp_nm,
m1.msmttyp_ds
from
__ODS_TWG.cur_msmttyp m1
where
not exists (
select 1 from
© Copyright IBM Corp. 2005 95
__ODS_TWG.cur_mtypreln mr
where
m1.msmttyp_id=mr.mtyp_source_id and
mr.relntyp_cd=’DERIVE’ )
and not exists (
select 1 from
__ODS_TWG.cur_mtypreln mr
where
m1.msmttyp_id=mr.mtyp_target_id and
mr.relntyp_cd=’DERIVE’ )
;
Standard view for the event type (EventTyp) table
------
-- a view of standard eventtyps
------
create view __ODS_TWG_STD.eventtyp
as select
e1.eventtyp_id,
e1.msrc_cd,
e2.eventtyp_nm,
e2.eventtyp_ds
from
__ODS_TWG.eventtyp e1,
__ODS_TWG.cur_etypreln er,
__ODS_TWG.eventtyp e2
where
e1.eventtyp_id=er.etyp_source_id and
er.relntyp_cd=’DERIVE’ and
e2.eventtyp_id=er.etyp_target_id
union all
select
e1.eventtyp_id,
e1.msrc_cd,
e1.eventtyp_nm,
e1.eventtyp_ds
from
__ODS_TWG.eventtyp e1
where
not exists (
select 1 from
__ODS_TWG.cur_etypreln er
where
e1.eventtyp_id=er.etyp_source_id and
er.relntyp_cd=’DERIVE’ )
and not exists (
select 1 from
__ODS_TWG.cur_etypreln er
where
e1.eventtyp_id=er.etyp_target_id and
er.relntyp_cd=’DERIVE’ )
;
Standard view for the component type (CompTyp) table
------
-- a view of standard comptyps
------
create view __ODS_TWG_STD.comptyp
as select
c1.comptyp_cd,
c1.comptyp_parent_cd,
c2.comptyp_nm,
c1.comptyp_strt_dttm,
96 Tivoli Data Warehouse Schema Reference
c1.comptyp_end_dttm,
c1.msrc_corr_cd
from
__ODS_TWG.cur_comptyp c1,
__ODS_TWG.cur_ctypreln cr,
__ODS_TWG.cur_comptyp c2
where
c1.comptyp_cd=cr.ctyp_source_cd and
cr.relntyp_cd=’DERIVE’ and
c2.comptyp_cd=cr.ctyp_target_cd
union all
select
c1.comptyp_cd,
c1.comptyp_parent_cd,
c1.comptyp_nm,
c1.comptyp_strt_dttm,
c1.comptyp_end_dttm,
c1.msrc_corr_cd
from
__ODS_TWG.cur_comptyp c1
where
not exists (
select 1 from
__ODS_TWG.cur_ctypreln cr
where
c1.comptyp_cd=cr.ctyp_source_cd and
cr.relntyp_cd=’DERIVE’ )
and not exists (
select 1 from
__ODS_TWG.cur_ctypreln cr
where
c1.comptyp_cd=cr.ctyp_target_cd and
cr.relntyp_cd=’DERIVE’ )
;
Standard view for the attribute type (AttrTyp) table
------
-- a view of standard attrtyps
------
create view __ODS_TWG_STD.attrtyp
as select
a1.attrtyp_cd,
a2.attrtyp_nm,
a1.msrc_corr_cd
from
__ODS_TWG.attrtyp a1,
__ODS_TWG.cur_atypreln ar,
__ODS_TWG.attrtyp a2
where
a1.attrtyp_cd=ar.atyp_source_cd and
ar.relntyp_cd=’DERIVE’ and
a2.attrtyp_cd=ar.atyp_target_cd
union all
select
a1.attrtyp_cd,
a1.attrtyp_nm,
a1.msrc_corr_cd
from
__ODS_TWG.attrtyp a1
where
not exists (
select 1 from
__ODS_TWG.cur_atypreln ar
where
a1.attrtyp_cd=ar.atyp_source_cd and
Chapter 4. Central data warehouse views, sequences, and triggers 97
ar.relntyp_cd=’DERIVE’ )
and not exists (
select 1 from
__ODS_TWG.cur_atypreln ar
where
a1.attrtyp_cd=ar.atyp_target_cd and
ar.relntyp_cd=’DERIVE’ )
;
Standard view for the relationship type (RelnTyp) table
------
-- a view of standard relntyps
------
create view __ODS_TWG_STD.relntyp
as select
relntyp_cd,
relntyp_nm,
msrc_corr_cd
from
__ODS_TWG.relntyp
;
Standard view for the component attribute type (CompAttr)
table
------
-- a view of standard compattrs
------
create view __ODS_TWG_STD.compattr
as select
ca.compattr_id,
ca.comp_id,
ca.attrtyp_cd,
ca.compattr_strt_dttm,
ca.compattr_end_dttm,
ca.compattr_val,
ca.msrc_corr_cd
from
__ODS_TWG.cur_compattr ca
;
Standard view for the component relationship (CompReln)
table
------
-- a view of standard comprelns
------
create view __ODS_TWG_STD.compreln
as select
cr.compreln_id,
cr.comp_source_id,
cr.comp_target_id,
cr.relntyp_cd,
cr.compreln_strt_dttm,
cr.compreln_end_dttm,
cr.msrc_corr_cd
from
__ODS_TWG.cur_compreln cr ;
98 Tivoli Data Warehouse Schema Reference
Standard view for the measurement (Msmt) table
------
-- a view of standard msmts
------
create view __ODS_TWG_STD.msmt
as select
m.msmt_id,
m.comp_id,
m.msmttyp_id,
m.tmsum_cd,
m.msmt_strt_dt,
m.msmt_strt_tm,
m.msmt_min_val,
m.msmt_max_val,
m.msmt_avg_val,
m.msmt_tot_val,
m.msmt_smpl_cnt,
m.msmt_err_cnt,
m.msrc_corr_cd,
m.msmt_stddev_val
from
__ODS_TWG.msmt m
;
Standard view for the component (Comp) table
------
-- a view of standard comps
------
create view __ODS_TWG_STD.comp
as select
c.comp_id,
c.comptyp_cd,
c.centr_cd,
c.cust_id,
c.comp_corr_id,
c.comp_nm,
c.comp_corr_val,
c.comp_strt_dttm,
c.comp_end_dttm,
c.comp_ds,
c.msrc_corr_cd,
c.comp_long_nm
from
__ODS_TWG.cur_comp c
where
not exists (
select 1 from __ODS_TWG.cur_compattr ca
where ca.comp_id = c.comp_id
and ca.attrtyp_cd = ’NAME’ )
union all
select
c.comp_id,
c.comptyp_cd,
c.centr_cd,
c.cust_id,
c.comp_corr_id,
ca.compattr_val as comp_nm,
c.comp_corr_val,
c.comp_strt_dttm,
c.comp_end_dttm,
c.comp_ds,
c.msrc_corr_cd,
c.comp_long_nm
Chapter 4. Central data warehouse views, sequences, and triggers 99
from
__ODS_TWG.cur_comp c,
__ODS_TWG.cur_compattr ca
where
ca.comp_id = c.comp_id
and ca.attrtyp_cd = ’NAME’
;
Standard view for the measurement source (Msrc) table
------
-- a view of standard msrc
------
create view __ODS_TWG_STD.msrc
as select
m.msrc_cd,
m.msrc_parent_cd,
m.msrc_nm
from
__ODS_TWG.msrc m
;
Current views in the TWG.cur schema
The current views provide a view of central data warehouse data that is current; in
other words, data whose starting and ending date and time includes the current
time. Use the current views of the TWG tables to extract only current central data
warehouse data.
An exception is the current view for the measurement type (MsmtTyp) table. For
information about this view, see “Current view for the measurement type
(MsmtTyp) table” on page 105.
Current view for the component type (CompTyp) table
------
-- a view of current comp types
------
create view __ODS_TWG.cur_comptyp
as select
comptyp_cd,
comptyp_parent_cd,
comptyp_nm,
comptyp_strt_dttm,
comptyp_end_dttm,
msrc_corr_cd
from __ODS_TWG.comptyp
where __NOW_TIMESTAMP_GMT
between comptyp_strt_dttm and comptyp_end_dttm;
grant all on __ODS_TWG.cur_comptyp to __ODS_TWG_STD;
Current view for the relationship rule (RelnRul) table
------
-- a view of current reln rules
------
create view __ODS_TWG.cur_relnrul
as select
comptyp_source_cd,
comptyp_target_cd,
relntyp_cd,
100 Tivoli Data Warehouse Schema Reference
relnrul_strt_dttm,
relnrul_end_dttm
from __ODS_TWG.relnrul
where __NOW_TIMESTAMP_GMT
between relnrul_strt_dttm and relnrul_end_dttm;
grant all on __ODS_TWG.cur_relnrul to __ODS_TWG_STD;
Current view for the attribute rule (AttrRul) table
------
-- a view of current attr rules
------
create view __ODS_TWG.cur_attrrul
as select
comptyp_cd,
attrtyp_cd,
attrrul_strt_dttm,
attrrul_end_dttm,
attrrul_dom_ind,
attrtyp_multi_val
from __ODS_TWG.attrrul
where __NOW_TIMESTAMP_GMT
between attrrul_strt_dttm and attrrul_end_dttm;
grant all on __ODS_TWG.cur_attrrul to __ODS_TWG_STD;
Current view for the attribute domain (AttrDom) table
------
-- a view of current attr domains
------
create view __ODS_TWG.cur_attrdom
as select
attrdom_id,
comptyp_cd,
attrtyp_cd,
msrc_corr_cd,
attrdom_strt_dttm,
attrdom_end_dttm,
attrdom_val,
attrdom_ds
from __ODS_TWG.attrdom
where __NOW_TIMESTAMP_GMT
between attrdom_strt_dttm and attrdom_end_dttm;
grant all on __ODS_TWG.cur_attrdom to __ODS_TWG_STD;
Current view for the component (Comp) table
------
-- a view of current comps
------
create view __ODS_TWG.cur_comp
as select
c.comp_id,
c.comptyp_cd,
c.centr_cd,
c.cust_id,
c.comp_corr_id,
c.comp_nm,
c.comp_corr_val,
c.comp_strt_dttm,
c.comp_end_dttm,
Chapter 4. Central data warehouse views, sequences, and triggers 101
c.comp_ds,
c.msrc_corr_cd,
ce.comp_long_nm
from __ODS_TWG.comp c
left outer join
__ODS_TWG.comp_ext ce
on
c.comp_id = ce.comp_id
where __NOW_TIMESTAMP_GMT
between c.comp_strt_dttm and c.comp_end_dttm;
grant all on __ODS_TWG.cur_comp to __ODS_TWG_STD;
Current view for the component attribute (CompAttr) table
------
-- a view of current compattrs
------
create view __ODS_TWG.cur_compattr
as select
compattr_id,
comp_id,
attrtyp_cd,
compattr_strt_dttm,
compattr_end_dttm,
compattr_val,
msrc_corr_cd
from __ODS_TWG.compattr
where __NOW_TIMESTAMP_GMT
between compattr_strt_dttm and compattr_end_dttm;
grant all on __ODS_TWG.cur_compattr to __ODS_TWG_STD;
Current view for the component relationship (CompReln) table
------
-- a view of current compreln
------
create view __ODS_TWG.cur_compreln
as select
compreln_id,
comp_source_id,
comp_target_id,
relntyp_cd,
compreln_strt_dttm,
compreln_end_dttm,
msrc_corr_cd
from __ODS_TWG.compreln
where __NOW_TIMESTAMP_GMT
between compreln_strt_dttm and compreln_end_dttm;
grant all on __ODS_TWG.cur_compreln to __ODS_TWG_STD;
Current view for the measurement type relationship
(MTypReln) table
------
-- a view of current mtypreln
------
create view __ODS_TWG.cur_mtypreln
as select
mtyp_source_id,
mtyp_target_id,
102 Tivoli Data Warehouse Schema Reference
relntyp_cd,
mtreln_strt_dttm,
mtreln_end_dttm
from __ODS_TWG.mtypreln
where __NOW_TIMESTAMP_GMT
between mtreln_strt_dttm and mtreln_end_dttm
;
grant all on __ODS_TWG.cur_mtypreln to __ODS_TWG_STD;
Current view for the event type relationship (ETypReln) table
------
-- a view of current etypreln
------
create view __ODS_TWG.cur_etypreln
as select
etyp_source_id,
etyp_target_id,
relntyp_cd,
etreln_strt_dttm,
etreln_end_dttm
from __ODS_TWG.etypreln
where __NOW_TIMESTAMP_GMT
between etreln_strt_dttm and etreln_end_dttm
;
grant all on __ODS_TWG.cur_etypreln to __ODS_TWG_STD;
Current view for the component type relationship (CTypReln)
table
------
-- a view of current ctypreln
------
create view __ODS_TWG.cur_ctypreln
as select
ctyp_source_cd,
ctyp_target_cd,
relntyp_cd,
ctreln_strt_dttm,
ctreln_end_dttm
from __ODS_TWG.ctypreln
where __NOW_TIMESTAMP_GMT
between ctreln_strt_dttm and ctreln_end_dttm
;
grant all on __ODS_TWG.cur_ctypreln to __ODS_TWG_STD;
Current view for the attribute type relationship (ATypReln)
table
------
-- a view of current atypreln
------
create view __ODS_TWG.cur_atypreln
as select
atyp_source_cd,
atyp_target_cd,
relntyp_cd,
atreln_strt_dttm,
atreln_end_dttm
from __ODS_TWG.atypreln
Chapter 4. Central data warehouse views, sequences, and triggers 103
where __NOW_TIMESTAMP_GMT
between atreln_strt_dttm and atreln_end_dttm
;
grant all on __ODS_TWG.cur_atypreln to __ODS_TWG_STD;
Current view for the component event relationship rule
(CERelnRul) table
------
-- a view of current cerelnrul
------
create view __ODS_TWG.cur_cerelnrul
as select
eventtyp_id,
comptyp_cd,
relntyp_cd,
cerul_strt_dttm,
cerul_end_dttm
from __ODS_TWG.cerelnrul
where __NOW_TIMESTAMP_GMT
between cerul_strt_dttm and cerul_end_dttm
;
grant all on __ODS_TWG.cur_cerelnrul to __ODS_TWG_STD;
Current view for the event relationship rule (ERelnRul) table
------
-- a view of current erelnrul
------
create view __ODS_TWG.cur_erelnrul
as select
etyp_source_id,
etyp_target_id,
relntyp_cd,
erul_strt_dttm,
erul_end_dttm
from __ODS_TWG.erelnrul
where __NOW_TIMESTAMP_GMT
between erul_strt_dttm and erul_end_dttm
;
Current view for the measurement objective (MObj) table
------
-- a view of current mobj
------
create view __ODS_TWG.cur_mobj
as select
mobj_id,
msmttyp_id,
comptyp_cd,
centr_cd,
cust_id,
attrdom_id,
msrc_cd,
mobj_strt_dttm,
mobj_end_dttm
from __ODS_TWG.mobj
where __NOW_TIMESTAMP_GMT
between mobj_strt_dttm and mobj_end_dttm
104 Tivoli Data Warehouse Schema Reference
;
grant all on __ODS_TWG.cur_mobj to __ODS_TWG_STD;
Current view for the measurement type (MsmtTyp) table
The current view for the measurement type table works differently from other
current views. This view is based on active measurements, listing only those
measurement types that contain measurement data. Or, if the ETL step has never
run, meaning no measurement types contain measurement data, the view will list
all measurement types. You might use this view if you are writing a data mart ETL
that uses this data.
------
-- a view of current msmttyp - meaning there are related msmts
-- if active_msmttyp is empty, meaning the check has never been done
-- then take all msmttyps
------
create view __ODS_TWG.cur_msmttyp
as select
mt.msmttyp_id,
mt.munit_cd,
mt.msrc_cd,
mt.msmttyp_nm,
mt.msmttyp_ds
from
__ODS_TWG.msmttyp mt,
__ODS_TWG.active_msmttyp at
where
mt.msmttyp_id=at.msmttyp_id and
at.active_flag=’Y’
union all
select
mt.msmttyp_id,
mt.munit_cd,
mt.msrc_cd,
mt.msmttyp_nm,
mt.msmttyp_ds
from
__ODS_TWG.msmttyp mt
where
not exists (
select 1 from __ODS_TWG.active_msmttyp )
;
grant all on __ODS_TWG.cur_msmttyp to __ODS_TWG_STD;
Inheritance views in the TWG_STD schema
If your warehouse pack needs to use inheritance, use these views to extract
information from the attribute rule (AttrRul), measurement rule (MsmtRul), and
relationship rule (RelnRul) tables. Use the table schema if you need to write to the
tables.
Inheritance view (AttrRul_inh) for the attribute rule (AttrRul)
table
create view __ODS_TWG.cur_attrrul_inh
as select
comptyp_cd,
attrtyp_cd,
attrrul_strt_dttm,
attrrul_end_dttm,
Chapter 4. Central data warehouse views, sequences, and triggers 105
attrrul_dom_ind,
attrtyp_multi_val
from
__ODS_TWG.cur_attrrul
;
grant all on __ODS_TWG.cur_attrrul_inh to __ODS_TWG_STD;
Inheritance view (MsmtRul_inh) for the measurement rule
(MsmtRul) table
create view __ODS_TWG.cur_msmtrul_inh
as select
comptyp_cd,
msmttyp_id
from
__ODS_TWG.msmtrul
;
grant all on __ODS_TWG.cur_msmtrul_inh to __ODS_TWG_STD;
Inheritance view (RelnRul_inh) for the relationship rule
(RelnRul) table
create view __ODS_TWG.cur_relnrul_inh
as select
comptyp_source_cd,
comptyp_target_cd,
relntyp_cd,
relnrul_strt_dttm,
relnrul_end_dttm
from
__ODS_TWG.cur_relnrul
;
grant all on __ODS_TWG.cur_relnrul_inh to __ODS_TWG_STD;
Sequences and triggers for the TWG tables
Sequences and triggers automate maintenance tasks for the central data warehouse.
Sequences assign sequential ID numbers to objects as they are created in the
database. For example, when you insert a component into the component (Comp)
table, a sequence sets the value of the TWG.Comp_ID to the next available
component ID number.
Triggers perform customized maintenance work. Each trigger is described in the
following sections.
Sequences and triggers for the component (Comp) table
When you insert a row into the component (Comp) table without setting the end
date and time value (Comp_End_DtTm), the __ODS_TWG.comp_i2 trigger sets the
value to the current time.
When you update a row in the component (Comp) table to change the end date
and time (Comp_End_DtTm), the __ODS_TWG.comp_u1 trigger sets the end date
and time for the attributes (CompAttr_Strt_DtTm, CompAttr_End_DtT) and
component relationships (CompReln_Strt_DtTm, CompReln_End_DtTm) for that
component to the current time, to indicate that they are no longer current.
106 Tivoli Data Warehouse Schema Reference
------
-- sequences and triggers for comp
------
__CREATE_SEQUENCE(__ODS_TWG.comp_id_seq)
;
--#OVERRIDE_TERMINATOR !
__CREATE_SEQUENCE_TRIGGER(__ODS_TWG.comp_i1 , __ODS_TWG.comp ,
__ODS_TWG.comp_id_seq , comp_id)
!
-- Provide a default END DTTM if none was specified
--#OVERRIDE_TERMINATOR !
create trigger __ODS_TWG.comp_i2
__CASCADE_CLAUSE
before insert on __ODS_TWG.comp
__MODE_CLAUSE
__BEGIN_BODY
__SET_VALUE(__NEW_ROW.comp_end_dttm ,
case when __NEW_ROW.comp_end_dttm is null
then __TO_TIMESTAMP(’9999-01-01-00.00.00.00’)
else __NEW_ROW.comp_end_dttm end);
__END_BODY
!
--#OVERRIDE_TERMINATOR !
create trigger __ODS_TWG.comp_u1
after update on __ODS_TWG.comp
__MODE_CLAUSE
__BEGIN_BODY
insert into __ODS_TWG.comp_change (change_dttm, comp_id)
values ( __NOW_TIMESTAMP_GMT , __NEW_ROW.comp_id);
update __ODS_TWG.compattr ca
set compattr_end_dttm = __NEW_ROW.comp_end_dttm
where ca.comp_id = __NEW_ROW.comp_id and
__NOW_TIMESTAMP_GMT between ca.compattr_strt_dttm and
ca.compattr_end_dttm;
update __ODS_TWG.compreln cr
set compreln_end_dttm = __NEW_ROW.comp_end_dttm
where ( cr.comp_source_id = __NEW_ROW.comp_id or
cr.comp_target_id = __NEW_ROW.comp_id ) and
__NOW_TIMESTAMP_GMT between cr.compreln_strt_dttm and
cr.compreln_end_dttm;
__END_BODY
!
Sequences and triggers for the component attribute
(CompAttr) table
When you insert a row into the component attribute (CompAttr) table without
setting the end date and time value (CompAttr_End_DtTm), the
__ODS_TWG.coma_i2 trigger sets the value to the current time.
When you insert a row for a component attribute that is in use but not defined as
multi-valued, the __ODS_TWG.coma_i3 trigger sets the end date and time
(CompAttr_End_DtTm) of the existing row to the start date and time
(CompAttr_Strt_DtTm) of the new row, to indicate that the component attribute
was changed at that time.
------
-- sequences and triggers for compattr
------
__CREATE_SEQUENCE(__ODS_TWG.compattr_id_seq)
Chapter 4. Central data warehouse views, sequences, and triggers 107
;
--#OVERRIDE_TERMINATOR !
__CREATE_SEQUENCE_TRIGGER(__ODS_TWG.coma_i1 , __ODS_TWG.compattr ,
__ODS_TWG.compattr_id_seq , compattr_id)
!
-- Provide a default END DTTM if none was specified
--#OVERRIDE_TERMINATOR !
create trigger __ODS_TWG.coma_i2
__CASCADE_CLAUSE
before insert on __ODS_TWG.compattr
__MODE_CLAUSE
__BEGIN_BODY
__SET_VALUE(__NEW_ROW.compattr_end_dttm ,
case when __NEW_ROW.compattr_end_dttm is null
then __TO_TIMESTAMP(’9999-01-01-00.00.00.00’)
else __NEW_ROW.compattr_end_dttm end);
__END_BODY
!
--#OVERRIDE_TERMINATOR !
create trigger __ODS_TWG.coma_i3
after insert on __ODS_TWG.compattr
__MODE_CLAUSE
__BEGIN_BODY
update
__ODS_TWG.compattr c
set
compattr_end_dttm = __NEW_ROW.compattr_strt_dttm
where
c.comp_id=__NEW_ROW.comp_id and
c.attrtyp_cd=__NEW_ROW.attrtyp_cd and
not exists (
select 1 from
__ODS_TWG.cur_attrrul a, __ODS_TWG.cur_comp c3
where
c.attrtyp_cd=a.attrtyp_cd and
a.attrtyp_multi_val=’Y’ and
c.comp_id = c3.comp_id and
c3.comptyp_cd = a.comptyp_cd ) and
c.compattr_strt_dttm =
( select
max(c2.compattr_strt_dttm)
from __ODS_TWG.compattr c2
where
c2.comp_id=__NEW_ROW.comp_id and
c2.attrtyp_cd=__NEW_ROW.attrtyp_cd and
c2.compattr_strt_dttm < __NEW_ROW.compattr_strt_dttm);
__END_BODY
!
Sequences and triggers for the component relationship
(CompReln) table
------
-- sequences and triggers for compreln
------
__CREATE_SEQUENCE(__ODS_TWG.compreln_id_seq )
;
--#OVERRIDE_TERMINATOR !
__CREATE_SEQUENCE_TRIGGER(__ODS_TWG.comr_i1 , __ODS_TWG.compreln ,
__ODS_TWG.compreln_id_seq , compreln_id) !
108 Tivoli Data Warehouse Schema Reference
Sequences and triggers for the component change
(Comp_Change) table
------
-- sequences and triggers for comp_change
------
__CREATE_SEQUENCE(__ODS_TWG.comp_chg_id_seq)
;
--#OVERRIDE_TERMINATOR !
__CREATE_SEQUENCE_TRIGGER(__ODS_TWG.comc_i1 , __ODS_TWG.comp_change ,
__ODS_TWG.comp_chg_id_seq , change_id)
!
Sequences and triggers for the customer (Cust) table
------
-- sequences and triggers for cust
------
__CREATE_SEQUENCE(__ODS_TWG.cust_id_seq)
;
--#OVERRIDE_TERMINATOR !
__CREATE_SEQUENCE_TRIGGER(__ODS_TWG.cust_i1 , __ODS_TWG.cust ,
__ODS_TWG.cust_id_seq , cust_id)
!
Sequences and triggers for the extract control
(Extract_Control) and extract log (Extract_Log) tables
When you insert a row into the extract control log, this trigger updates the extract
control table to indicate the new window for extracting a set of data.
------
-- sequences and triggers for extract_log
------
-- Extract window forward
--#OVERRIDE_TERMINATOR !
create trigger __ODS_TWG.extl_i1
after insert on __ODS_TWG.extract_log
__MODE_CLAUSE
__BEGIN_BODY
update __ODS_TWG.extract_control
set
extctl_from_rawseq = __NEW_ROW.extlog_to_rawseq ,
extctl_from_intseq = __NEW_ROW.extlog_to_intseq ,
extctl_from_dttm = __NEW_ROW.extlog_to_dttm
where
extctl_source = __NEW_ROW.extlog_source and
extctl_target = __NEW_ROW.extlog_target;
__END_BODY
!
Sequences and triggers for the measurement source (Msrc)
and measurement source history (MSrc_History) tables
The following triggers maintain the history of changes to the measurement source
name (MSrc_Nm) column of the measurement source (MSrc) table. When
MSrc_Nm is updated, the original value is stored in the measurement source
history (MSrc_History) table. If there is a previous row for a measurement source
name in the history table, its end date is updated.
Chapter 4. Central data warehouse views, sequences, and triggers 109
Measurement source history for version 1.2 warehouse packs
------
-- this trigger handles installing 1.2 weps
-- which update __ODS_TWG.msrc
------
--#OVERRIDE_TERMINATOR !
create trigger __ODS_TWG.msrc_u1
after update on __ODS_TWG.msrc
__MODE_CLAUSE
__BEGIN_BODY
insert into __ODS_TWG.msrc_history
values (
__NEW_ROW.msrc_cd, __NEW_ROW.msrc_nm,
__NOW_TIMESTAMP_GMT,
__TO_TIMESTAMP(’9999-01-01-00.00.00.00’)
);
__END_BODY
!
------
-- msrc_history
------
------
-- this trigger handles installing 1.2 weps
-- which insert into __ODS_TWG.msrc_history as a result of
-- an update of __ODS_TWG.msrc
------
--#OVERRIDE_TERMINATOR !
create trigger __ODS_TWG.msrh_i1
after insert on __ODS_TWG.msrc_history
__MODE_CLAUSE
__BEGIN_BODY
update __ODS_TWG.msrc_history mh
set msrc_end_dttm = __NEW_ROW.msrc_strt_dttm
where
mh.msrc_cd = __NEW_ROW.msrc_cd and
mh.msrc_strt_dttm =
( select
max(mh2.msrc_strt_dttm)
from __ODS_TWG.msrc_history mh2
where
mh2.msrc_cd= __NEW_ROW.msrc_cd and
mh2.msrc_strt_dttm < __NEW_ROW.msrc_strt_dttm);
__END_BODY
!
Measurement source history for version 1.1 warehouse packs
Version 1.1 warehouse packs do not use the measurement source history
(MSrc_History) table, so this trigger creates an entry in that table.
------
-- this trigger handles installing 1.1 weps
------
--#OVERRIDE_TERMINATOR !
create trigger __ODS_TWG.msrc_i1
after insert on __ODS_TWG.msrc
__MODE_CLAUSE
__BEGIN_BODY
insert into __ODS_TWG.msrc_history
values (
__NEW_ROW.msrc_cd, __NEW_ROW.msrc_nm,
__TO_TIMESTAMP(’1970-01-01-00.00.00.00’),
110 Tivoli Data Warehouse Schema Reference
__TO_TIMESTAMP(’9999-01-01-00.00.00.00’)
);
__END_BODY
!
Sequences and triggers for the measurement (Msmt) table
------
-- sequences and triggers for msmt
------
__CREATE_SEQUENCE(__ODS_TWG.msmt_id_seq)
;
--#OVERRIDE_TERMINATOR !
__CREATE_SEQUENCE_TRIGGER(__ODS_TWG.msmt_i1 , __ODS_TWG.msmt ,
__ODS_TWG.msmt_id_seq , msmt_id)
!
Sequences and triggers for the measurement type (MsmtTyp)
table
------
-- sequences and triggers for msmttyp
------
__CREATE_SEQUENCE(__ODS_TWG.msmttyp_id_seq)
;
--#OVERRIDE_TERMINATOR !
__CREATE_SEQUENCE_TRIGGER(__ODS_TWG.msmy_i1 , __ODS_TWG.msmttyp ,
__ODS_TWG.msmttyp_id_seq , msmttyp_id)
!
Sequences and triggers for the measurement pruning log
(Prune_Msmt_Log) table for pruning central data warehouse
measurements
The following SQL statements define a trigger that prunes measurement data from
the central data warehouse that corresponds to rows inserted into the measurement
pruning log (Prune_Msmt_Log) table.
Note: A different technique removes old event data from the central data
warehouse. No trigger is required for events.
------
-- sequences and triggers for prune_msmt_log
------
--#OVERRIDE_TERMINATOR !
create trigger __ODS_TWG.prul_i1
after insert on __ODS_TWG.prune_msmt_log
__MODE_CLAUSE
__BEGIN_BODY
delete from __ODS_TWG.Msmt m
where
__ADD_DATE_DURATION(m.msmt_strt_dt , __NEW_ROW.pmsmtl_age_in_days)
< __TO_DATE_TIMESTAMP(__NOW_TIMESTAMP_GMT) and
m.tmsum_cd = __NEW_ROW.tmsum_cd
and ( __NEW_ROW.msrc_cd =
(select mt.msrc_cd from __ODS_TWG.msmttyp mt
where mt.msmttyp_id = m.msmttyp_id)
Chapter 4. Central data warehouse views, sequences, and triggers 111
or ( __NEW_ROW.msrc_cd = m.msrc_corr_cd ) )
;
__END_BODY
!
Sequences and triggers for the translated term
(Translated_Term) table
When the translated term table for a warehouse pack is installed, this trigger
automatically calculates additional data that is needed for translating terms.
------
-- sequences and triggers for translated_term
------
__CREATE_SEQUENCE(__ODS_TWG.term_id_seq)
;
--#OVERRIDE_TERMINATOR !
__CREATE_SEQUENCE_TRIGGER(__ODS_TWG.trat_i1 , __ODS_TWG.translated_term ,
__ODS_TWG.term_id_seq , term_id)
!
-- set the varchar column equal to the value of the binary column
--#OVERRIDE_TERMINATOR !
create trigger __ODS_TWG.trat_i2
__CASCADE_CLAUSE
before insert on __ODS_TWG.translated_term
__MODE_CLAUSE
__BEGIN_BODY
__SET_VALUE(__NEW_ROW.term_cvalue, __NEW_ROW.term_value);
__END_BODY
!
Sequences and triggers for the component event relationship
(CEReln) table
------
-- sequences and triggers for cereln
------
__CREATE_SEQUENCE(__ODS_TWG.cereln_id_seq)
;
--#OVERRIDE_TERMINATOR !
__CREATE_SEQUENCE_TRIGGER(__ODS_TWG.coer_i1 , __ODS_TWG.cereln ,
__ODS_TWG.cereln_id_seq , cereln_id)
!
Sequences and triggers for the event attribute (EventAttr)
table
------
-- sequences and triggers for eventattr
------
__CREATE_SEQUENCE(__ODS_TWG.eventattr_id_seq)
;
--#OVERRIDE_TERMINATOR !
__CREATE_SEQUENCE_TRIGGER(__ODS_TWG.evea_i1 , __ODS_TWG.eventattr ,
__ODS_TWG.eventattr_id_seq , eventattr_id) !
112 Tivoli Data Warehouse Schema Reference
Sequences and triggers for the event relationship (EventReln)
table
------
-- sequences and triggers for eventreln
------
__CREATE_SEQUENCE(__ODS_TWG.eventreln_id_seq)
;
--#OVERRIDE_TERMINATOR !
__CREATE_SEQUENCE_TRIGGER(__ODS_TWG.ever_i1 , __ODS_TWG.eventreln ,
__ODS_TWG.eventreln_id_seq , eventreln_id)
!
Sequences and triggers for the event (Event) table
------
-- sequences and triggers for event
------
__CREATE_SEQUENCE(__ODS_TWG.event_id_seq)
;
--#OVERRIDE_TERMINATOR !
__CREATE_SEQUENCE_TRIGGER(__ODS_TWG.even_i1 , __ODS_TWG.event ,
__ODS_TWG.event_id_seq , event_id)
!
Sequences and triggers for the event type (EventTyp) table
------
-- sequences and triggers for eventtyp
------
__CREATE_SEQUENCE(__ODS_TWG.eventtyp_id_seq)
;
--#OVERRIDE_TERMINATOR !
__CREATE_SEQUENCE_TRIGGER(__ODS_TWG.evey_i1 , __ODS_TWG.eventtyp ,
__ODS_TWG.eventtyp_id_seq , eventtyp_id)
!
Sequences and triggers for the attribute domain (AttrDom)
table
------
-- sequences and triggers for attrdom
------
__CREATE_SEQUENCE(__ODS_TWG.attrdom_id_seq)
;
--#OVERRIDE_TERMINATOR !
__CREATE_SEQUENCE_TRIGGER(__ODS_TWG.atto_i1 , __ODS_TWG.attrdom ,
__ODS_TWG.attrdom_id_seq , attrdom_id)
!
Sequences and triggers for the component type keyword
(CompTyp_Keyword) table
------
-- sequences and triggers for comptyp_keyword
------
Chapter 4. Central data warehouse views, sequences, and triggers 113
__CREATE_SEQUENCE(__ODS_TWG.keyword_id_seq)
;
--#OVERRIDE_TERMINATOR !
__CREATE_SEQUENCE_TRIGGER(__ODS_TWG.ckey_i1 , __ODS_TWG.comptyp_keyword ,
__ODS_TWG.keyword_id_seq , keyword_id)
!
Sequences and triggers for the measurement objective (MObj)
table
------
-- sequences and triggers for mobj
------
__CREATE_SEQUENCE(__ODS_TWG.mobj_id_seq )
;
--#OVERRIDE_TERMINATOR !
__CREATE_SEQUENCE_TRIGGER(__ODS_TWG.mobj_i1 , __ODS_TWG.mobj ,
__ODS_TWG.mobj_id_seq , mobj_id)
!
Sequences and triggers for the measurement objective range
(MObjRng) table
------
-- sequences and triggers for mobjrng
------
__CREATE_SEQUENCE(__ODS_TWG.mobjrng_id_seq )
;
--#OVERRIDE_TERMINATOR !
__CREATE_SEQUENCE_TRIGGER(__ODS_TWG.mobr_i1 , __ODS_TWG.mobjrng ,
__ODS_TWG.mobjrng_id_seq , mobjrng_id) !
114 Tivoli Data Warehouse Schema Reference
Chapter 5. Data mart model and schema
This chapter describes the data model of the data mart and the database tables
used to implement that model.
The purpose of a data mart is to store business data so it can be easily reported
and analyzed. When building the historical reporting aspects of your warehouse
pack, you create a data mart ETL which places the data used for subject-oriented
reporting and analysis into a data mart. Often these tables contain data that has
been aggregated, or summarized, from data in the central data warehouse.
Your data is stored as one or more star schemas, master-detail tables, or sets of
related tables. This chapter focuses on data mart ETLs that use star schemas.
A data mart can contain star schemas and other tables for more than one
warehouse pack. For example, a single data mart might contain data for the
following reporting needs:
v Single customer analysis for performance engineers
v Infrastructure analysis for network analysts
v Summarized, overall customer health for service level agreement management
Naming conventions for the database tables keep data in schemas from multiple
warehouse packs from intermingling. See Appendix A, “Naming conventions,” on
page 121 for more information.
You typically do more database design when creating a data mart ETL than when
creating a central data warehouse ETL. This is because you design the schema for
the data mart. Contrast this with the schema for the central data warehouse, which
is defined by Tivoli Data Warehouse. Designing the schema gives you the
flexibility to change its style and features when your customer’s needs change.
As part of an earlier architecture and design phase, you performed the following
tasks:
v You studied the reporting needs of your customers. What business questions do
they need to answer? How do they want that data presented? This drives the
design of the data mart schema.
v You mapped historical data about your system management software into the
tables in the central data warehouse. The format of this data determines the ETL
programs you need to write.
Now you need to create the data mart ETL to make a subset of the data in the
central data warehouse available for historical reporting. You do this by creating
scripts that move data from the central data warehouse into staging tables, and
from there into the final star schema tables in the data mart. Use staging tables to
increase recoverability, simplify SQL statements for maintainability, and allow for
slowly changing dimension tables.
This chapter has the following section:
v “Components of a star schema” on page 116
© Copyright IBM Corp. 2005 115
Components of a star schema
A star schema consists of one fact table that contains measurable or countable fact
data. The fact table contains foreign keys to join to dimension data in a metric
dimension table and in one or more component dimension tables (hereafter
referred to as dimension tables). Tivoli Data Warehouse uses two types of fact tables,
measurement fact tables and event fact tables. Figure 3 shows a typical star schema
with one fact table, one metric dimension table, and dimension tables for four
components.
Dimension Table
Metric Dimension Table Dimension Table
FACT TABLE
Dimension Table Dimension Table
Figure 3. A typical star schema
You also use helper tables and views to efficiently populate the star schema. For
every metric dimension and component dimension table, you also have a
translation table. For every fact table, you have a staging table.
The following sections provide design considerations for star schemas and describe
the tables that make up a star schema.
Fact table
A fact table is a relational table that contains facts, such as the amount of free disk
space or the number of times a server crashed, and foreign keys that link the fact
table to each dimension table. For measurements, the facts are typically rapidly
changing data and numeric values (minimum, maximum, average, and totals). For
events, they are often counts (the number of events). New rows are inserted in the
fact table when the data mart ETL runs.
A fact table contains either measurement data or event data. One fact table cannot
contain both types of data. You cannot combine measurement and event data in one
star schema.
The following rules apply to the fact table:
v A fact table has a single integer column as the primary key. This column must
be called fact_id.
116 Tivoli Data Warehouse Schema Reference
v A fact table contains a cdw_id column to indicate which central data warehouse
provided the data. The cdw_id is an integer that is automatically assigned when
the warehouse pack is installed.
v A fact table must have a staging fact table.
Table 84 lists the columns in a fact table.
Table 84. Fact table columns
Column Data type Null Description
option
1 fact_id INTEGER NOT The primary key of the fact. You must
NULL create a sequence number trigger to
populate this column.
cdw_id INTEGER NOT The identifier of the source central data
NULL warehouse, which is assigned during the
installation of a warehouse pack.
1 metric_id INTEGER NOT Unique foreign key used for the metric
NULL dimension table.
foreignKey INTEGER NOT One or more foreign key columns to the
NULL dimension tables. This column is
repeated for each dimension table. This
is typically just a single column that
includes an integer ID. However, in
some cases another column, such as a
date, might be needed. It is possible to
use three or more columns to join into a
dimension table although single integer
IDs are more common.
meas_hour, TIMESTAMP NULL Contains summarized timestamps.
meas_date
For hourly fact tables, use the column
meas_hour and summarize on hourly
boundaries.
For fact tables for larger aggregations,
such as daily, weekly, monthly, and so
on, use the column meas_date. The
value in this column represents the start
of the time period being measured (day,
week, month, and so on). For example, it
is used when running a report that ″ requests Return the last 2 weeks of ″ data.
min_value FLOAT NULL The minimum value for metric
measurement.
max_value FLOAT NULL The maximum value for metric
measurement.
avg_value FLOAT NULL The average value for metric
measurement.
total_value FLOAT NULL The total value for metric measurement.
sample_count INTEGER NULL The number of samples taken for metric
measurement.
error_count INTEGER NULL The number of errors. This column is
optional and is aggregated by rollup
only if the column exists.
Chapter 5. Data mart model and schema 117
Table 84. Fact table columns (continued)
Column Data type Null Description
option
1 If you have too many facts or measurements to use an integer ID, you can use the
BIGINT data type.
Component dimension tables
A component dimension table represents descriptive information about a fact. The
data in a dimension table can represent slowly changing data, such as host name
or measurement descriptions.
Dimensions are typically string information used to constrain the numerical
information stored in the fact table. Dimensions are used to constrain the facts
(numerical data) selected when pulling information from a fact table for reporting.
At least one table in the star schema contains the Cust_ID field. Other tables in the
star schema must be able to filter their data by joining with the table that has the
Cust_ID.
The following rules apply to the dimension tables for components:
v Dimension tables contain component attributes (column name=component
attribute).
v More than one star schema can use a dimension table.
v One or more dimension tables contain component information.
v Dimension tables must have primary keys. The primary key for a dimension
table, in most cases, is a single integer field that is used as a foreign key in the
fact table.
v Slowly changing dimensions should, in most cases, be stored in dimension tables
separate from other dimension information. Examples of slowly changing
dimensions are file names and program versions and location information. You
should also create separate dimension views for these separate dimension tables.
v Dimension tables for warehouse packs for Tivoli software have a translation
table.
Metric dimension table
The metric dimension table is a required dimension table for both event and
measurement star schemas. This table describes the data categories, such as time,
accounts, products, or markets, of facts in a fact table. The table also contains
boolean columns that indicate whether a fact record will have a minimum,
maximum, and average value, or whether it will have a total value. Other
dimension tables can be present or not, at your discretion as a star schema
designer.
The following rules apply to the metric dimension table:
v A metric dimension table contains information about the measurements in the
star schema.
v More than one star schema can use a metric dimension table. It is common to
share metric dimension tables between star schemas for different time
aggregations.
v Metric dimension tables for warehouse packs for Tivoli software have a
translation table, which stages data as it comes into the data mart.
118 Tivoli Data Warehouse Schema Reference
The columns must include those shown in Table 85.
Table 85. Metric dimension table columns
Column Data type Null option Description
metric_id INTEGER NOT NULL A unique integer that identifies this
metric record. This number can be
generated by a sequence number
generator in the database or some
other mechanism. It is a foreign key
used to link the fact table of a star
schema to a specific metric record.
met_category VARCHAR(254) NULL A category used to group metrics;
for example, CPU.
met_desc VARCHAR(254) NULL A description of what the metric
actually measures; for example,
average CPU busy.
met_name VARCHAR(254) NOT NULL An internal short description of
what the measurement actually
measures; for example, avgcpubusy.
met_units VARCHAR(254) NULL A unit of measure such as
megabytes per second, total
megabytes free, MHz, and so on.
min_exists CHAR(1) NOT NULL This Y or N value indicates whether
this metric contains data for a
minimum value.
max_exists CHAR(1) NOT NULL This Y or N value indicates whether
this metric contains data for a
maximum value.
avg_exists CHAR(1) NOT NULL This Y or N value indicates whether
this metric contains data for the
average value.
total_exists CHAR(1) NOT NULL This Y or N value indicates whether
this metric contains data for a total
value.
msrc_nm VARCHAR(254) NULL This field represents the application
that supplies the data.
Chapter 5. Data mart model and schema 119 120 Tivoli Data Warehouse Schema Reference
Appendix A. Naming conventions
To prevent object name conflicts and to present a consistent user interface, follow
the naming conventions in this appendix.
The following topics are addressed:
v “Warehouse pack names”
v “Product codes”
v “Tivoli Data Warehouse database names” on page 122
v “Warehouse pack-specific objects in the central data warehouse” on page 122
v “Warehouse pack-specific data in the generic (TWG) central data warehouse
tables” on page 123
v “Warehouse pack-specific objects in data marts” on page 126
v “Objects in the DB2 Data Warehouse Center” on page 128
v “Report file names” on page 131
v “Java resource bundles” on page 131
Warehouse pack names
The APP_DISPLAY_NAME property specifies the name that is displayed to the
user by the warehouse pack installation program. For example, this field might
have the following value:
APP_DISPLAY_NAME=IBM Tivoli Sample Product Warehouse Enablement Pack
Do not use a comma (,) in the value of this field.
For optimal display in the warehouse pack installation program, use short names.
Names up to 26 characters can easily be displayed.
Product codes
To prevent object name conflicts, you must use a product code, which is shown in
this document as productCode, to uniquely identify a warehouse pack. The
following rules apply to the product code:
v The product code is typically the IBM code, sometimes referred to as the AVA
code, of the product that ships the warehouse pack. This is usually the same as
the first three characters of message numbers generated by the product. This
code is used for multiple versions of your warehouse pack.
v The product code consists of three alphanumeric characters. The first character
must be a letter, not a number. The second and third characters can be a letter or
a number. The following guidelines apply:
For third-party and customer applications:
Be careful not to use a product code assigned to an IBM or Tivoli
product or warehouse pack. You can ensure this by starting your
product code with a letter from K through Z. The second character of
the product code can be either a letter or number, but the third character
must be a number from 0 to 9. In addition, contact a representative of
the enablement team to ensure the product code you chose does not
conflict with other IBM or Tivoli warehouse packs.
© Copyright IBM Corp. 2005 121
For IBM and Tivoli software applications:
If your product provides a single warehouse pack, use your product’s
product code.
If your product provides multiple warehouse packs that can be
concurrently installed, change the second or third character of your
product code to a number.
Use the product code in the following places:
v In the installation properties file, twh_install_props.cfg, this is the value of the
AVA_CODE property.
v Names of directories and files, such as for the top level directory, SQL and ETL
scripts, TAG files, NLS jar files, after scripts, and XML and CSV files for reports.
v First part (schema) name for tables, such as for the stage, helper tables in the
central data warehouse, fact, dimension, and prune tables in the data mart.
v Values inserted into TWG.MSrc.
If appropriate, you can put more than a three character value in the TWG.MSrc
tables. Do this when the value does not indicate a specific warehouse pack, but
is used to group other msrc_cds together or to represent a shared measurement
source. For examples, the values Tivoli and MODEL1 indicate grouping.
v DB2 Data Warehouse Center objects, such as Subject Areas, Processes, Steps,
Warehouse Sources and Targets, and Warehouse Schemas.
v Values used by steps in version 1.1 warehouse packs.
v Warehouse pack-specific type code values in the TWG.comptyp, attrtyp and
similar tables. These are for types that are not shared between multiple
warehouse packs.
Tivoli Data Warehouse database names
Tivoli Data Warehouse databases have the following names:
TWH_MD
The control database on the control server
TWH_CDW
The first central data warehouse database that is defined on a Windows or
UNIX system
TCDW1, TCDW2, ...
Additional central data warehouses.
TWH_MART
The first data marts that is defined on a Windows or UNIX system
TMART1, TMART2, ...
Additional data marts.
You must use only these database names so that your ETL interchange (TAG) file
contains the information that the warehouse pack installation program needs to
correctly associate each source database in your ETL programs with the correct
database.
Warehouse pack-specific objects in the central data warehouse
Warehouse pack-specific objects in the central data warehouse must comply with
the following naming conventions:
122 Tivoli Data Warehouse Schema Reference
Only the following characters, numbers, and symbols are used in the names for
warehouse pack-specific objects in the central data warehouse. The first part of the
name for all objects is the product code.
v A through Z
v 0 through 9
v underscore (_)
v comma (,)
v period (.)
v slash (/)
v hyphen (-)
v ampersand (&)
v at sign (@)
v parentheses (())
If your warehouse pack supports DB2 Universal Database for z/OS, the names of
tables, views, and other database objects cannot be longer than 18 characters.
Note: When you put data into the central data warehouse, use your own schema.
Do not create objects in the central data warehouse (TWG) schema.
Staging tables
Staging tables must comply with the following naming conventions:
Example: CTO.STG_ORA
The variables in the name are:
productCode
Specifies the product code of the warehouse pack.
stagingTableDescription
Provides a description of the staging table.
For example, the staging table for fact table xyz.f_health_hour should be named
xyz.stg_f_health_hour.
Warehouse pack-specific data in the generic (TWG) central data
warehouse tables
Do not abbreviate product or service names. Use approved short names only.
Creating other versions of a name (by abbreviating it or changing it in any other
way) can cause confusion and confusion about names can cause legal and
translation problems. This naming convention applies to all static strings that are
translatable. For example, CompTyp_Nm, RelnTyp_Nm, AttrTyp_Nm, MGrp_Nm,
MGrpTyp_Nm, Munit_Nm, MsmtTyp_Nm, and MsmTyp_Ds.
Use the following capitalization guidelines for data in the component type names,
measurement type names, and measurement type descriptions:
v Use headline capitalization style.
Examples:
– Physical Reads
Appendix A. Naming conventions 123
– Average Processor Busy
v If product names are used, follow the capitalization rules for product names:
– Use initial caps for a full official name or for a simplified official name.
– Use lowercase when the shortened name is a generic name.
– Use capital letters when the shortened name is an all-caps abbreviation.
v For descriptions of any of the names above, use sentence style capitalization.
Examples:
– Measurement Source Code (name uses headline style capitalization)
This is the code for the measurement source application that defines the
measurement type. (description uses sentence-style capitalization)
– Average Processor Busy (name)
The average time a processor is busy. (description)
All codes (*_Cd)
All code values must comply with the following naming conventions:
v All code (_Cd) values must be uppercase. This rule applies to any new code
values and the current code values for the CompTyp_Cd, Centr_Cd,
RelnTyp_Cd, AttrTyp_Cd, MGrpTyp_Cd, MGrp_Cd, Munit_Cd, MunitCat_Cd,
and TmSum_Cd codes in the central data warehouse.
v The only exceptions are MUnit_Cd values which have some codes in uppercase
and some in mixed case, and the MSrc_Cd = Tivoli. The code values that are
already defined in mixed case remain, but all new codes values must be
uppercase.
v Depending on the specific table, follow one of these naming conventions for all
codes:
– Shared or common types. Shared or common types can be defined for
component types, attribute types, measurement types, measurement units,
relationship types, measurement groups, and measurement group types. Do
not define warehouse pack unique type codes if a common or shared type has
already been defined. See Chapter 3, “Common static data,” on page 59 for a
list of common types.
– productCode_ - See Chapter 3, “Common static data,” on page 59. This
convention includes AttrTyp_Cd.
– productCode - For codes that are space constrained, the underscore (_) is not
required. This applies to the RelTyp_Cd, MGrp_Cd, and MGrpTyp_Cd codes.
Component type codes
Component type codes are entered in the CompTyp_Cd column of the
TWG.CompTyp table. Component type codes must comply with the following
naming conventions:
v A through Z
v 0 through 9
v underscore (_)
v comma (,)
v period (.)
124 Tivoli Data Warehouse Schema Reference
v slash (/)
v hyphen (-)
v ampersand (&)
v at sign (@)
v parentheses (())
Maximum length is 17 characters.
Examples:
v CTO_DATABASE
v CTO_SEGMENT
The exceptions to this rule are the well-known shared component types such as:
IP_HOST, IP_INTERFACE, TME_ENDPOINT.
Attribute type codes
Attribute type codes are entered in the AttrTyp_Cd column of the TWG.AttrTyp
table. Attribute type codes must comply with the following naming conventions:
The values for short name for attribute type can be:
include:
v A through Z
v 0 through 9
v underscore (_)
v comma (,)
v period (.)
v slash (/)
v hyphen (-)
v ampersand (&)
v at sign (@)
v parentheses (())
The maximum length is 17 characters.
Examples:
v CTO_DUMPSP_TYPE
v CTO_SERVICE_TYP
The exceptions to this rule are the well-known shared attribute types such as:
LAST_IP_ADDRESS, TME_OBJECT_ID.
Measurement type names
Measurement type names are entered in the MsmtTyp_Nm column of the
TWG.MsmtType table. These names must follow a headline capitalization style.
This style capitalizes the initial letter of each word.
Examples:
v Physical Reads
v Average Processor Busy
Appendix A. Naming conventions 125
Product names — MSrc_Nm
Product names in the MSrc_Nm column must comply with the following naming
conventions:
v The name can be a long or a short name, but for IBM products it must be a
name that has been approved for use in the external publications of the product.
v Warehouse packs from companies other than IBM do not have to follow the IBM
product naming conventions.
v Version information is not required in the MSrc_Nm. If the approved IBM
product name contains the version, then the version cannot be removed from the MSrc_Nm.
Warehouse pack-specific objects in data marts
Only the following characters, numbers, and symbols are allowed in table names
in the data marts. All table names start with the warehouse pack product code.
v A through Z
v 0 through 9
v underscore (_)
If your warehouse pack supports DB2 Universal Database for z/OS, the names of
tables, views, and other database objects cannot be longer than 18 characters.
Dimension tables based on components
Component dimension tables must comply with the following naming conventions:
Use the singular version of the description instead of the plural; for example,
DATABASE, rather than DATABASES.
Examples:
v CTO.D_ORA_DATABASE
v CTO.D_ORA_DB_COMP
v CTO.D_ORA_DB_SUB_COMP
Metric dimension tables
Metric dimension tables based on measurement types must comply with the
following naming conventions:
Example: CTO.D_ORA_METRIC
Translation tables for dimension tables
The name of a translation dimension table is created by replacing the d_ in the
dimension table name with t_. For example, the translation table for the metric
dimension table CTO.D_ORA_METRIC is named CTO.T_ORA_METRIC. The
translation table for the component dimension table CTO.T_ORA_DATABASE is
named CTO.D_ORA_DATABASE.
126 Tivoli Data Warehouse Schema Reference
Fact tables for measurements
Fact tables containing measurement data must comply with the following naming
conventions:
The variables in the name are:
productCode
Specifies the product code of the warehouse pack.
F Indicates that the table is a fact table.
factDescription
Provides a description of the data in the fact table. Use any description you
need to describe this fact table to people writing or modifying reports.
timePeriod
Indicates the time period of the data in the fact table, such as HOUR, DAY,
WEEK, MONTH, QUARTER, and YEAR.
For example, an hourly fact table about an Oracle database in the warehouse pack
with product code CTO might be named CTO.F_ORA_DB_HOUR. The daily fact
table for the same set of measurements would be named CTO.F_ORA_DB_DAY.
Note: Only use 12 to 14 characters for fact table names. Staging tables are created
by appending stg_ to fact table names and staging table names can only be
18 characters long. Therefore, you must be able to append stg_ to the
beginning of a fact table name to create the staging table name.
Fact tables for point in time data
Fact tables containing point in time data, resulting from events, must comply with
the following naming conventions:
The variables in the name are:
productCode
Specifies the product code of the warehouse pack.
F Indicates that the table is a fact table.
factDescription
Provides a description of the data in the fact table. Use any description you
need to describe this fact table to people writing or modifying reports.
PIT Indicates a point in time fact table.
For example, a point in time fact table about events recording failed attempts to
hack into a computer in the warehouse pack with product code DGR might be
named DGR.F_FAILEDHACKS_PIT.
Note: Only use 12 to 14 characters for fact table names. Staging tables are created
by appending stg_, or stage_ if you are already using that convention, to
fact table names and staging table names can only be 18 characters long.
Therefore, you must be able to append stg_ or stage_ to the beginning of a
fact table name to create the staging table name.
Appendix A. Naming conventions 127
Objects in the DB2 Data Warehouse Center
When you create objects in the DB2 Data Warehouse Center, use only the following
characters, numbers, and symbols for the object name:
v A through Z
v a through z
v 0 through 9
v underscore (_)
v comma (,)
v period (.)
v slash (/)
v hyphen (-)
v ampersand (&)
v at sign (@)
v parentheses (())
The product code at the beginning of each object name must be uppercase.
Subject areas
A subject area identifies and groups the processes that relate to a logical area of the
business. Subject areas must comply with the following naming conventions:
Note:
than the maximum length restriction, use the short product name.
Examples: CTO_Tivoli_Manager_for_Oracle_v2.1.0_Subject_Area
Warehouse sources
Warehouse sources identify the source that provides data to your warehouse.
Warehouse sources must comply with the following naming conventions:
Note:
Example: CTO_TWH_CDW_Source
Warehouse targets
Warehouse targets are the databases that contain data that has been transformed.
Warehouse targets must comply with the following naming conventions:
Notes:
1.
2. TWH_CDW is used for
warehouse is a target.
3. TWH_MART is used for
128 Tivoli Data Warehouse Schema Reference
Examples:
v CTO_TWH_CDW_Target
v CTO_TWH_MART_Target
Processes
A process contains a series of steps that perform a transformation and movement
of data for a specific warehouse. A process name has the following format:
The process name has the following parts:
ProcessID
Is a process ID that indicates where and when the process is to run. The
process ID has one of the following formats:
v cnn
v mnn
Where:
c Indicates that the process is a central data warehouse ETL.
m Indicates that the process is a data mart ETL.
nn Is a two digit sequence number, which starts at 05 and increments
by 5.
processDescription
Is a description of the process.
Examples:
v JD5_c05_src_to_cdw_Process
v JD5_m05_cdw_to_mart_Process
Steps
A step is the definition of a single operation within the warehouse, often
implemented with an SQL script. Steps must comply with the following naming
conventions:
The variables in the step name are as follows:
PRODUCT_CODE
The product code of the warehouse pack must be uppercase.
processID
The process ID. For more information, see “Processes.”
nnn The order number of the step. Step numbers start at 010 and increment by
10 so that if a step needs to be added later, there is room to add it between
existing steps.
stepDescription
A description of the step. Include an indicator of which type of ETL uses
this step and a short description of the function provided by the script.
Standard step descriptions include:
v For the central data warehouse ETL:
Appendix A. Naming conventions 129
src_pre_extract
A step with this description performs tasks that must be done
before the data is extracted from an operational data source
database. Typical tasks include:
– Dropping and recreating staging tables
– Dropping and recreating the temporary extract control table
– Inserting To and From extract IDs into the temporary extract control
src_extract
A step with this description extracts data from the operational
data source. Typical tasks include:
– Inserting data into staging tables
– Updating the TWG extract control tables, based on the
temporary extract control
src_load
A step with this description loads the data from staging tables
into the central data warehouse. This creates your components
and events, records component attributes, and so forth.
v For the data mart ETL:
mart_pre_extract
A step with this description performs tasks that must be done
before the data is extracted from the central data warehouse.
Typical tasks are the same as the central data warehouse
pre-extract step.
mart_extract
A step with this description extracts data from the central data
warehouse.
mart_load
A step with this description loads the data from staging tables
into the data mart. This loads data into fact tables and
dimension tables.
mart_rollup
Invokes the rollupMulti UDP to create aggregate fact tables from
hourly fact tables. This step must happen after the fact tables
have been updated but before pruning.
mart_prune
A step with this description prunes old data from the data mart.
Sample step names include:
v DGR_c05_s010_src_pre_extract
v DGR_c05_s030_src_load
v DGR_m05_s010_mart_pre_extract
v DGR_m05_s040_mart_prune
File names for steps
For each step, there is a corresponding script file. The name of this file must be the
step name with the extension .generic. For example, the step
DGR_c05_s010_src_pre_extract is implemented in the file named
130 Tivoli Data Warehouse Schema Reference
DGR_c05_s010_src_pre_extract.generic. The step DGR_m05_s040_mart_prune is
implemented in the file named DGR_m05_s040_mart_prune.generic. Step names
are described in “Steps” on page 129.
Report file names
Report file names must comply with the following naming conventions, as well as
any imposed by Crystal Decisions:
v Names must be lowercase.
v Names can be no longer than eight characters not including the foreign-language
abbreviation suffix).
v Names must have the .rpt extension.
v Names cannot start with a number.
v Names cannot contain spaces.
v Names must consist of only alphanumeric characters.
Java resource bundles
Java resource bundles must comply with the following naming conventions:
Replace the variables as follows:
productCode
This specifies the product code of the warehouse pack and must match the
value of the AVA_CODE property.
version This specifies the version number of your warehouse pack and must match
the value of the APP_REL_VERSION property.
For example, if the twh_install_props.cfg file contains the properties
AVA_CODE=dgr and APP_REL_VERSION=2.1.0.0, then use the following file
names:
Appendix A. Naming conventions 131 132 Tivoli Data Warehouse Schema Reference
Appendix B. Support information
This section describes the following options for obtaining support for IBM
products:
v “Searching knowledge bases”
v “Obtaining fixes” on page 134
v “Contacting IBM Software Support” on page 134
Learning about education
IBM and its worldwide network of education partners offer a variety of course
types, online, on-site and instructor-led education, covering every aspect of the
Tivoli software portfolio.
View available Tivoli Data Warehouse 1.3 Training at:
Tivoli Software Education:
http://www.ibm.com/software/tivoli/education/
Virtual Skills Center for Tivoli Software:
http://www.cgselearning.com/tivoliskills/
Searching knowledge bases
If you have a problem with your IBM software, you want it resolved quickly. Begin
by searching the available knowledge bases to determine whether the resolution to
your problem is already documented.
Search the documentation
IBM provides extensive documentation that can be installed on your local
computer or on an intranet server. You can use the search function of the PDF to
query conceptual information, instructions for completing tasks, reference
information, and support documents.
Search the Internet
If you cannot find an answer to your question in the information center, search the
Internet for the latest, most complete information that might help you resolve your
problem. You can search a variety of resources including:
v IBM technotes
v IBM downloads
v IBM Redbooks
® v IBM developerWorks
v Forums and news groups
v Google
© Copyright IBM Corp. 2005 133
Obtaining fixes
A product fix might be available to resolve your problem. You can determine what
fixes are available for your IBM software product by checking the product support
Web site:
1. Go to the IBM Software Support Web site
(http://www.ibm.com/software/support).
2. Under Products A - Z, select your product name. This opens a product-specific
support site.
3. You can learn about fixes and optionally download the fixes.
For more information about types of fixes, see the Software Support Handbook
(http://techsupport.services.ibm.com/guides/handbook.html).
Contacting IBM Software Support
IBM Software Support provides assistance with product defects.
Before contacting IBM Software Support, your company must have an active IBM
software maintenance contract, and you must be authorized to submit problems to
IBM. The type of software maintenance contract that you need depends on the
type of product you have:
v For IBM distributed software products (including, but not limited to, Tivoli,
® ® Lotus , and Rational products, as well as DB2 and WebSphere products that
® run on Windows or UNIX operating systems), enroll in Passport Advantage in
one of the following ways:
– Online: Go to the following Passport Advantage Web page:
(http://www.lotus.com/services/passport.nsf/
WebDocs/Passport_Advantage_Home)
Click How to Enroll.
– By phone: For the phone number to call in your country, go to the IBM
Software Support Web site
(http://techsupport.services.ibm.com/guides/contacts.html) and click the
name of your geographic region.
™ v For IBM eServer software products (including, but not limited to, DB2 and
® ® ™ WebSphere products that run in zSeries , pSeries , and iSeries environments),
you can purchase a software maintenance agreement by working directly with
an IBM sales representative or an IBM Business Partner. For more information
about support for eServer software products, go to the IBM Technical Support
Advantage Web page (http://www.ibm.com/servers/eserver/techsupport.html).
If you are not sure what type of software maintenance contract you need, call
1-800-IBMSERV (1-800-426-7378) in the United States or, from other countries, go to
the contacts page of the IBM Software Support Handbook on the Web
(http://techsupport.services.ibm.com/guides/contacts.html) and click the name of
your geographic region for phone numbers of people who provide support for
your location.
Follow the steps in this topic to contact IBM Software Support:
1. Determine the business impact of your problem.
2. Describe your problem and gather background information.
3. Submit your problem to IBM Software Support.
134 Tivoli Data Warehouse Schema Reference
Determine the business impact of your problem
When you report a problem to IBM, you are asked to supply a severity level.
Therefore, you need to understand and assess the business impact of the problem
you are reporting. Use the following criteria:
Severity 1 Critical business impact: You are unable to use the program, resulting in a critical impact
on operations. This condition requires an immediate solution.
Severity 2 Significant business impact: The program is usable but is severely limited.
Severity 3 Some business impact: The program is usable with less significant features (not critical to
operations) unavailable.
Severity 4 Minimal business impact: The problem causes little impact on operations, or a reasonable
circumvention to the problem has been implemented.
Describe your problem and gather background information
When explaining a problem to IBM, be as specific as possible. Include all relevant
background information so that IBM Software Support specialists can help you
solve the problem efficiently. To save time, know the answers to these questions:
v What software versions were you running when the problem occurred?
v Do you have logs, traces, and messages that are related to the problem
symptoms? IBM Software Support is likely to ask for this information.
v Can the problem be re-created? If so, what steps led to the failure?
v Have any changes been made to the system? (For example, hardware, operating
system, networking software, and so on.)
v Are you currently using a workaround for this problem? If so, please be
prepared to explain it when you report the problem.
Submit your problem to IBM Software Support
You can submit your problem in one of two ways: ″ ″ v Online: Go to the Submit and track problems page on the IBM Software
Support site (http://www.ibm.com/software/support/probsub.html). Enter
your information into the appropriate problem submission tool.
v By phone: For the phone number to call in your country, go to the contacts page
of the IBM Software Support Handbook on the Web
(http://techsupport.services.ibm.com/guides/contacts.html) and click the name
of your geographic region.
If the problem you submit is for a software defect or for missing or inaccurate
documentation, IBM Software Support creates an Authorized Program Analysis
Report (APAR). The APAR describes the problem in detail. Whenever possible,
IBM Software Support provides a workaround for you to implement until the
APAR is resolved and a fix is delivered. IBM publishes resolved APARs on the
IBM product support Web pages daily, so that other users who experience the
same problem can benefit from the same resolutions.
For more information about problem resolution, see Searching knowledge bases
and Obtaining fixes.
Appendix B. Support information 135 136 Tivoli Data Warehouse Schema Reference
Appendix C. Notices
This information was developed for products and services offered in the U.S.A.
IBM may not offer the products, services, or features discussed in this document in
other countries. Consult your local IBM representative for information on the
products and services currently available in your area. Any reference to an IBM
product, program, or service is not intended to state or imply that only that IBM
product, program, or service may be used. Any functionally equivalent product,
program, or service that does not infringe any IBM intellectual property right may
be used instead. However, it is the user’s responsibility to evaluate and verify the
operation of any non-IBM product, program, or service.
IBM may have patents or pending patent applications covering subject matter
described in this document. The furnishing of this document does not give you
any license to these patents. You can send license inquiries, in writing, to:
IBM Director of Licensing
IBM Corporation
North Castle Drive
Armonk, NY 10504-1785 U.S.A.
For license inquiries regarding double-byte (DBCS) information, contact the IBM
Intellectual Property Department in your country or send inquiries, in writing, to:
IBM World Trade Asia Corporation
Licensing
2-31 Roppongi 3-chome, Minato-ku
Tokyo 106, Japan
The following paragraph does not apply to the United Kingdom or any other
country where such provisions are inconsistent with local law:
INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THIS ″ ″ PUBLICATION AS IS WITHOUT WARRANTY OF ANY KIND, EITHER
EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE.
Some states do not allow disclaimer of express or implied warranties in certain
transactions, therefore, this statement might not apply to you.
This information could include technical inaccuracies or typographical errors.
Changes are periodically made to the information herein; these changes will be
incorporated in new editions of the publication. IBM may make improvements
and/or changes in the product(s) and/or the program(s) described in this
publication at any time without notice.
Any references in this information to non-IBM Web sites are provided for
convenience only and do not in any manner serve as an endorsement of those Web
sites. The materials at those Web sites are not part of the materials for this IBM
product and use of those Web sites is at your own risk.
© Copyright IBM Corp. 2005 137
IBM may use or distribute any of the information you supply in any way it
believes appropriate without incurring any obligation to you.
Licensees of this program who wish to have information about it for the purpose
of enabling: (i) the exchange of information between independently created
programs and other programs (including this one) and (ii) the mutual use of the
information which has been exchanged, should contact:
IBM Corporation
2Z4A/101
11400 Burnet Road
Austin, TX 78758 U.S.A.
Such information may be available, subject to appropriate terms and conditions,
including in some cases payment of a fee.
The licensed program described in this document and all licensed material
available for it are provided by IBM under terms of the IBM Customer Agreement,
IBM International Program License Agreement or any equivalent agreement
between us.
Any performance data contained herein was determined in a controlled
environment. Therefore, the results obtained in other operating environments may
vary significantly. Some measurements may have been made on development-level
systems and there is no guarantee that these measurements will be the same on
generally available systems. Furthermore, some measurement may have been
estimated through extrapolation. Actual results may vary. Users of this document
should verify the applicable data for their specific environment.
Information concerning non-IBM products was obtained from the suppliers of
those products, their published announcements or other publicly available sources.
IBM has not tested those products and cannot confirm the accuracy of
performance, compatibility or any other claims related to non-IBM products.
Questions on the capabilities of non-IBM products should be addressed to the
suppliers of those products.
All statements regarding IBM’s future direction or intent are subject to change or
withdrawal without notice, and represent goals and objectives only.
This information is for planning purposes only. The information herein is subject to
change before the products described become available.
This information contains examples of data and reports used in daily business
operations. To illustrate them as completely as possible, the examples include the
names of individuals, companies, brands, and products. All of these names are
fictitious and any similarity to the names and addresses used by an actual business
enterprise is entirely coincidental.
COPYRIGHT LICENSE:
This information contains sample application programs in source language, which
illustrate programming techniques on various operating platforms. You may copy,
modify, and distribute these sample programs in any form without payment to
IBM, for the purposes of developing, using, marketing or distributing application
programs conforming to the application programming interface for the operating
platform for which the sample programs are written. These examples have not
138 Tivoli Data Warehouse Schema Reference
been thoroughly tested under all conditions. IBM, therefore, cannot guarantee or
imply reliability, serviceability, or function of these programs. You may copy,
modify, and distribute these sample programs in any form without payment to
IBM for the purposes of developing, using, marketing, or distributing application
programs conforming to IBM’s application programming interfaces.
If you are viewing this information in softcopy form, the photographs and color
illustrations might not display.
Trademarks
The following terms are trademarks or registered trademarks of International
Business Machines Corporation in the United States, other countries, or both:
IBM The IBM logo
AIX NetView
DB2 OS/2
DB2 Connect OS/390
DB2 DataJoiner Passport Advantage
DB2 DataPropagator pSeries
DB2 OLAP Server Rational
DB2 Universal Database Rational Rose
developerWorks Redbooks
Distributed Relational Database Architecture RS/6000
Domino Tivoli
DRDA Tivoli Enterprise
eServer Tivoli Enterprise Console
IMS TME
Informix WebSphere
Lotus xSeries
iSeries z/OS
MVS zSeries
Java and all Java-based trademarks and logos are trademarks or registered
trademarks of Sun Microsystems, Inc. in the United States, other countries, or both.
Intel, the Intel Inside logos, MMX, and Pentium are trademarks of Intel
Corporation in the United States, other countries, or both.
Linux is a trademark of Linus Torvalds in the United States, other countries, or
both.
Microsoft and Windows NT are registered trademarks of Microsoft Corporation in
the United States, other countries, or both.
UNIX is a registered trademark of The Open Group in the United States and other
countries.
Other company, product, and service names may be trademarks or service marks
of others.
Appendix C. Notices 139 140 Tivoli Data Warehouse Schema Reference
Glossary
agent site. In the DB2 Data Warehouse Center, the address http://www.ibm.com; and a person with
location, defined by a single network host name, where whom you have a customer relationship. Each
a warehouse agent application is installed. See also component type in the data model has a set of
default agent site and remote agent site. measurements and attributes that apply to all
components of that type. attribute. Data associated with a component. For
example, a server component might have attributes consumer application. An application that uses the
such as host name, IP address, operating system type, data in the central data warehouse for a specific
operating system version, number of CPUs, CPU speed, business need. Consumer applications utilize reporting
type of RAM, number of hard drives, network domain, and third-party online analytical processing (OLAP)
and so on. tools as well as planning, trend-tracking, analysis,
accounting, and data mining tools. See also source
base table. A table created with the CREATE TABLE application. statement. Such a table has both its description and
data physically stored in the database. Contrast with Control Center. See DB2 Control Center.
view.
control database. The component of Tivoli Data
central data warehouse. A component of Tivoli Data Warehouse that contains the metadata that describes
Warehouse that contains the cleansed historical data. the data in the warehouse, including the source of the
Data in the central data warehouse is derived from data, how the data was transformed before being
operational data, although operational data is not placed in the warehouse, when the data was collected,
stored directly in the central data warehouse. A Tivoli and the formats used to publish the data (for example,
Data Warehouse deployment can contain more than the star schemas used by Tivoli Data Warehouse
one central data warehouse. reports).
central data warehouse ETL. In Tivoli Data control server. (1) In Tivoli Data Warehouse, the
Warehouse, the extract, transform, and load (ETL) system where the control database component of Tivoli
process that reads the data from the operational data Data Warehouse is installed. (2) In DB2 replication, the
stores of the application that collects it (for example, a database location of the applicable subscription
log file, an IBM Tivoli Inventory repository, or an IBM definitions and Apply program control tables.
Tivoli Enterprise Console database), verifies the data,
makes the data conform to the Tivoli Data Warehouse database manager. A system program that manages
schema, and places the data into the central data data by providing the services of centralized control,
warehouse. See also extract, transform, and load. data independence, and complex physical structures for
Contrast with data mart ETL. efficient access, integrity, recovery, concurrency control,
privacy, and security.
Crystal Enterprise server. A server that is integrated
with Tivoli Data Warehouse and that stores reports. data definition language (DDL). A language for
You install the server when you install Crystal describing data and its relationships in a database.
Decisions’ Crystal Enterprise Professional v.10 that
data description language. See data definition ships with Tivoli Data Warehouse.
language.
CIM. See common information model.
data mart. A subset of a data warehouse that contains
cleanse. To transform the data extracted from data that is tailored and optimized for the specific
operational data stores so as to make it usable by the reporting needs of a department or team. A data mart
data warehouse. can be a subset of a warehouse for an entire
organization, such as data contained in online
common information model (CIM). An analytical processing (OLAP) tools. In a Tivoli Data
implementation-neutral, object-oriented schema for Warehouse deployment, there can be more than one
describing network management information. The data mart.
Distributed Management Task Force (DMTF) develops
and maintains CIM specifications. data mart ETL. In Tivoli Data Warehouse, the extract,
transform, and load (ETL) process that extracts a subset
component. An entity about which measurements are of data from the central data warehouse, transforms it,
collected for reporting purposes. Sample components and loads it into one or more star schemas. These
include a specific network storage device; the Web schemas then can be included in data marts to answer
© Copyright IBM Corp. 2005 141
specific business questions. See also extract, transform, Information Technology Infrastructure Library
and load. Contrast with central data warehouse ETL. (ITIL). A series of documents, created by the Office of
Government Commerce in United Kingdom, that are
data warehouse. A subject-oriented non-volatile used to help implement a framework for IT Service
collection of data used to support strategic decision Management (ITSM). This framework defines how to
making. The warehouse is the central point of data organize the system and network management
integration for business intelligence. It is the source of departments within specific organizations. For more
data for data marts within an enterprise and delivers a information, see http://www.itil-itsm-world.com/. common view of enterprise data.
ITIL. See Information Technology Infrastructure
Data Warehouse Center. See DB2 Data Warehouse Library.
Center.
IBM Console. In Tivoli Enterprise Data Warehouse,
DB2 Control Center. The component of IBM DB2 Version 1.1, the role-based user interface for
Universal Database Enterprise Server Edition that performing tasks using Tivoli management software. provides the graphical interface that shows database
objects (such as databases and tables) and their location. In DB2 Universal Database for z/OS, the
relationship to each other. From the DB2 Control unique name of a database server. An application uses
Center, you can perform the tasks provided by the the location name to access a DB2 database server.
DBA Utility, Visual Explain, and Performance Monitor
tools. metadata. Data that describes the characteristics of
stored data; descriptive data. For example, the
DB2 Data Warehouse Center. The component of IBM metadata for a database table might include the name
DB2 Universal Database Enterprise Server Edition that of the table, the name of the database that contains the
provides the graphical interface and the software table, the names of the columns in the table, and the
behind it that enables you to work with the column descriptions, either in technical terms or
components of the warehouse. You can use the DB2 business terms.
Data Warehouse Center to define and manage the
warehouse data and the processes that create the data not-fenced. Pertaining to a type of user-defined
in the warehouse. function or stored procedure that is defined to be run
in the database manager process. There is no protection
DDL. See data definition language. for the database manager from changes by this
function. See also fenced. default agent site. An agent site that is located on the
same system as the control server. A default agent site OLAP. See online analytical processing.
does not require the installation of IBM DB2 Warehouse
Manager Standard Edition. See also agent site and online analytical processing (OLAP). The process of
remote agent site. collecting data from one or many sources; transforming
and analyzing the consolidated data quickly and
ePortfolio. Crystal ePortfolio is a Web desktop that is interactively; and examining the results across different
an interface for end users to view, schedule, and dimensions of the data by looking for patterns, trends,
monitor published reports. You can also use ePortfolio and exceptions within complex relationships of that
to help troubleshoot problems that users encounter data.
viewing and scheduling reports.
operational data. Data that is collected by an
ETL. See extract, transform, and load. application during its operation. An application can
store its operational data in many formats, such as
extract, transform, and load (ETL). The process of relational databases, log files, and spreadsheet files. It is
collecting data from one or more sources, cleansing and live data, as opposed to the historical data in the
transforming it, and then loading it into a database. central data warehouse. See also operational data store.
extension script. A script that augments the Tivoli operational data store. The place where operational
Data Warehouse scripts. For example, extension scripts data resides, such as a database or a log file. See also
might be scripts that run before or after the ETL steps operational data. are run.
product code. The three-character code for a
fenced. In IBM DB2 Universal Database Enterprise warehouse pack that is used to uniquely identify a
Server Edition, pertaining to a type of user-defined warehouse pack and to keep the data and schema of
function or stored procedure that is defined to protect one warehouse pack separate from other warehouse
the database manager from modifications by the packs. Tivoli Data Warehouse documentation uses
function. The database manager is isolated from the productCode in contexts where the product code must be function or stored procedure by a barrier. See also
not-fenced.
142 Tivoli Data Warehouse Schema Reference
specified in lowercase or when case is not important, Tivoli Presentation Services. In Tivoli Enterprise Data
and PRODUCT_CODE when it must be specified in Warehouse, Version 1.1, the Tivoli user interface
uppercase. architecture. The IBM Console is an integral part of this
architecture.
RDBMS. See relational database management system.
trigger. In a database, a set of Structured Query
relational database. A database that can be perceived Language (SQL) statements that automatically initiate
as a set of tables and manipulated in accordance with an action when a specific operation, such as changing
the relational model of data. data in a table, occurs. A trigger consists of an event
(an INSERT, DELETE, or UPDATE statement issued relational database management system (RDBMS). A against an associated table) and an action (the related collection of hardware and software that organizes and procedure). Triggers are used to preserve data integrity provides access to a relational database. by checking on or changing data in a consistent
manner. remote agent site. An agent site that is located on the
same system as the control server. A remote agent site user-defined program. In DB2 Universal Database, a requires the installation of IBM DB2 Warehouse program that a user supplies and defines to the DB2
Manager Standard Edition. See also agent site and Data Warehouse Center, as contrasted with supplied default agent site. programs, which are included with and defined
automatically in the DB2 Data Warehouse Center. report interface (RPI). In Tivoli Enterprise Data
Warehouse, Version 1.1, the component that provides view. A logical table that consists of data that is historical reporting capabilities. Using the report generated by a query. A view is based on an interface, users can create and run reports; create and underlying set of base tables, and the data in a view is manage data marts that have the format required by determined by a SELECT statement that is run on the the Tivoli Enterprise Data Warehouse report-generating base tables. Contrast with base table. tools; and create and manage the groups that control
access to those data marts. warehouse. See data warehouse.
resource. A hardware, software, or data entity that is warehouse agent. In the DB2 Data Warehouse Center,
managed by Tivoli software. software that manages the flow of data between one or
more data sources and one or more target warehouses. report server. In Tivoli Enterprise Data Warehouse, Warehouse agents use Open Database Connectivity
Version 1.1, the system where the report interface (ODBC) drivers or the DB2 command line interface component is installed. See also report interface (RPI). (CLI) to communicate with different databases.
source application. An application whose data is warehouse enablement pack. A separately installable collected from its operational data stores and placed part of a Tivoli software product that provides Tivoli into the central data warehouse using an extract, Data Warehouse functionality by providing extract, transform, and load (ETL) process. See also consumer transform, and load (ETL) programs to populate the application. central data warehouse and create data marts, as well
as customizable reports to answer specific business star schema. A type of relational database schema
questions. Also called a warehouse pack. See also made up of a fact table and a set of dimension tables.
extract, transform, and load. In Tivoli Data Warehouse, the fact table holds the
values of the component’s metrics, and the dimension warehouse source. A subset of tables and views from tables hold the values of the attributes of a component a single database, or a set of files, that have been or a metric. defined in the DB2 Data Warehouse Center.
subsystem. In DB2 Universal Database for z/OS, a warehouse target. A subset of tables, indexes, and distinct instance of a relational database management aliases from a single database that are managed by the system (RDBMS). DB2 Data Warehouse Center.
tag file. A file that contains tag language which warehouse pack. See warehouse enablement pack. describes objects and object types to be added, updated
or deleted in the Data Warehouse Center or in the version 1.1 warehouse pack. A warehouse pack that
information catalog, when the file is imported. was created for Tivoli Enterprise Data Warehouse,
Version 1.1, but is running on Tivoli Data Warehouse, tag language file. See tag file. Version 1.3. See warehouse enablement pack.
version 1.2 warehouse pack. A warehouse pack that
was created to run on Tivoli Data Warehouse,
Version 1.3. See warehouse enablement pack.
Glossary 143 144 Tivoli Data Warehouse Schema Reference
Index
A CompAttr table 19 component attribute abbreviations 74 rules 18 accessibility xi component attribute table 19 active measurement type table, data definition 10 component dimension tables 118
Active_MsmtTyp table 10 component event relationship rule table 21 architecture component event relationship table 20
Tivoli Data Warehouse components 2 component extension table 22
AttrDom table 11 component relationship table 23 attribute domain table 11 component relationship, rules 22 attribute rule table component table 14, 16
data definition 12 component type
static data 90 rules 60 attribute type codes component type codes, naming conventions 124
naming conventions 125 component type keyword table 25 attribute type relationship table 14 component type relationship table 26 attribute type table component type table 60
data definition 13 data definition 24
static data 82, 83 static data 62
AttrRul table 12 component type translation table 27 AttrTyp table 13, 82 components
ATypReln table 14 rules 14
AVA code components of Tivoli Data Warehouse 2
See product code composite names 15
CompReln table 23
CompTyp table 24
B CompTyp_Keyword table 25 books CompTyp_Tran table 27
See documentation consumer applications 95
control database
about 3 C coexistence 122 metadata 3 capitalization guidelines 123 control server center table 14 defined 3
Centr table 14 introduction 3 central data warehouse Crystal Enterprise 4
creating tables 7 CTypReln table 26
database 122 Cust table 27
introduction 3 customer support, IBM xii
name of 122 customer table 27
naming conventions for objects in 122
schema 7 table data 59 D central data warehouse schema summary table 7
central data warehouse schema summary table, installation data
definition 7 mapping 59
central data warehouses data flow
definition 3 Tivoli Data Warehouse 1
CEReln table 20 data marts
CERelnRul table 21 best practices viii
codes, naming conventions 124 defined 3
common component types introduction 3
IP_HOST 60 name of 122
IP_INTERFACE 60 Data Warehouse Center
LAST_KNOWN_IPADDRESS 60 See DB2 Data Warehouse Center
WEBSITE 61 DB2
WEBSITE_PATH 61 tutorial ix
WEBSITE_QUERY 61 DB2 Data Warehouse Center
common data 59 naming conventions for objects in 128
Comp table 16 DB2 Universal Database
Comp_Ext table 22 documentation ix
© Copyright IBM Corp. 2005 145
DB2 Universal Database Server for OS/390 and z/OS G documentation x
GeoArea table 36 derived types
geographic area table 36 views for 95
geographic type 37 dimension tables
GeoTyp table 37 based on components 126
glossary, Tivoli viii based on measurement types 126 directory
names, notation xii documentation vii I
Crystal Enterprise server viii IBM customer support xii
DB2 ix inheritance, views 105
DB2 Universal Database Server for OS/390 and z/OS x IP addresses 18
IBM Redbooks viii IP_HOST 60
languages other than English viii IP_INTERFACE 60
online xi
ordering xi Tivoli Data Warehouse vii J Tivoli Glossary viii
jar file naming conventions 131
Java resource bundles E naming conventions 131 job control language (JCL) xi
EAttrTyp table 31
EattrTyp_Tran table 31 EGrp table 32 L EGrpMbr table 32
LAST_KNOWN_IPADDRESS 60 EGrpTyp table 32
environment variables
See also ProgramFiles environment variable
See also TWH_TOPDIR environment variable M
notation xii manuals
ERelnRul table 33 See documentation
ETL process mapping
naming conventions 129 data 59
ETL steps measurement
file names 130 response time 37
naming conventions 129 rules 37
ETypReln table 34 utilization data 38
event attribute table 30 measurement data, summarizing 70
event attribute type table 31 measurement group
static data 93 AVG_E 73
event attribute type translation table 31 MAX_E 73
event group member table 32 MIN_E 73
event group table 32 standard 73
event group type table 32 measurement group member table
static data 93 data definition 41
event relationship rule table 33 static data 41
event relationship table 33 measurement group table
event table 28 data definition 40
event type relationship table 34 static data 73
event type table 34 measurement group type table
static data 92 data definition 42
EventAttr table 30 static data 72
EventReln table 33 measurement groups
EventTyp table 34 standard 73
extract control table 35 measurement rule table
extract log table 36 data definition 43
static data 79, 80
measurement source history table 44
F measurement source table
data definition 43 fact tables
static data 59, 60 description of 116
measurement table description of columns 117
data definition 38 naming conventions 127
mapping MGrp_Cd columns in the MGrpMbr table 41
measurement type names, naming conventions 125
measurement type relationship table 45
146 Tivoli Data Warehouse Schema Reference
measurement type table O data definition 44
online publications xi static data 74
ordering publications xi measurement types
overview, graphic of Tivoli Data Warehouse 2 rules 74
measurement unit category
static data 71 measurement unit category table P
data definition 47 parent-child relationship 22
static data 71 path names, notation xii
measurement unit subunit table 47 PCHILD relationship type 22 measurement unit table performance
data definition 46 tracking 37, 40
static data 71, 72 product code
metric dimension tables 118 IBM and Tivoli software applications 122
MGrp table 40 rules 121
MGrpMbr table 41 third-party applications 121
MGrpTyp table 42 product names
MObj table 53 naming conventions 126
MObjRng table 53 productCode
Msmt table 38 See product code
MsmtRul table 43, 79 ProgramFiles environment variable xiii
MsmtTyp table 44, 74 prune event control table 48
MSrc table 43 prune event log table 48
MSrc_History table 44 prune measurement control table 48
MSrc_Nm, naming conventions 126 prune measurement log table 49
MTypReln table 45 Prune_Event_Ctrl table 48
MUnit table 46 Prune_Event_Log table 48
MUnitCat table 47 Prune_Msmt_Control table 48
MUnitSub table 47 Prune_Msmt_Log table 49 publications
See documentation N
naming conventions
attribute type codes 125 R
central data warehouse objects 122 redbooks, IBM viii
codes (*_Cd) 124 relationship rule table
component type codes 124 data definition 50
data in the central data warehouse tables 123 static data 68
data mart objects 126 relationship type table
database names 122 data definition 50
DB2 Data Warehouse Center objects 128 static data 65
dimension tables 126 RelnRul table 50
ETL steps 129 RelnTyp table 50
fact tables 127 report file naming conventions 131
measurements 127 resource bundles naming conventions 131
for report file names 131 response time measurement 37
jar files 131 rules
Java resource bundles 131 component 14
measurement type names 125 component attribute 18
MSrc_Nm 126 component relationship 22
processes 129 measurement 37
product codes 121 rules, component type 60
product names 126 rules, measurement type 74
staging tables 123
star schemas 126 subject areas 128 S warehouse sources 128 scenarios warehouse targets 128 notation customer viii
schema 5 environment variables xii
schema version table 51 path names xii
schemas, star schema 116 typeface xii sequences
central data warehouse tables 95
TWG tables 106
SevLvl table 54
Index 147
source application 1 tables (continued)
source component type table 51 measurement type relationship 45
source event attribute table 51 measurement unit 46
source event attribute type table 52 measurement unit category 47
sources measurement unit subunit 47
warehouse 128 metric dimension 118
Src_CompTyp table 51 metric dimension table 118
Src_EAttrTyp table 52 prune event control 48
Src_EventAttr table 51 prune event log 48
staging tables prune measurement control 48
naming conventions 123 prune measurement log 49
star schemas relationship rule 50
example, graphic 116 relationship type 50
naming conventions 126 schema version 51
static data script sequences 106
See twh_cdw_data.generic source component type 51
subject areas source event attribute 51
naming conventions 128 source event attribute type 52
summarizing measurement data 70 threshold measurement objective 53
threshold measurement objective range 53
threshold severity level 54
T time change difference 55
time change log 55 tables
time summary 55
active measurement type 10
time zone 57
attribute domain 11
time zone install 57
attribute rule 12
translated term 58
attribute type 13
triggers 106
attribute type relationship 14 views
center 14
current 100
central data warehouse schema summary 7
standard 95
columns for a metric dimension 119 targets
component 16
warehouse 128
component attribute 19
threshold measurement objective range table 53
component dimension 118
threshold measurement objective table 53
component event relationship 20
threshold severity level table 54
component event relationship rule 21
time change difference table 55
component extension 22
time change log table 55
component relationship 23
time summary table
component type 24
data definition 55
component type keyword 25
static data 70
component type relationship 26
time zone install table 57
component type translation 27
time zone table 57
customer 27
Time_Change_Diff table 55
event 28
Tivoli customer support
event attribute 30
See IBM customer support
event attribute type 31
Tivoli Data Warehouse
event attribute type translation 31
architecture 2
event group 32
data flow 1
event group member 32
documentation vii
event group type 32
Tivoli Software Information Center xi
event relationship 33
TmSum table 55
event relationship rule 33
TmZon table 57
event type 34
TmZon_Install table 57
event type relationship 34
translated term table 58
extract control 35 triggers
extract log 36
central data warehouse tables 95
fact table 116
TWG tables 106
geographic area 36 tutorial
geographic type 37
data warehousing ix
measurement 38
TWG tables, sequences and triggers for 106
measurement group 40 TWH_CDW
measurement group member 41
See central data warehouse
measurement group type 42
twh_cdw_data.generic 7
measurement rule 43 TWH_MART
measurement source history 44
See data marts
measurement source table 43
measurement type 44
148 Tivoli Data Warehouse Schema Reference
TWH_MD
See control database
TWH_TOPDIR environment variable xiii
types, derived
See derived types
U
utilization data measurement 38
V
variables, notation xii views
central data warehouse tables 95
current 100
inheritance 105
standard 95
TWG_STD schema 95
TWG.cur schema 100
W
warehouse agents and agent sites 3
warehouse packs
defined 3
warehouse sources 128
warehouse targets 128
Web sites
customer support xii
glossary viii
Information Center xi
order publications xi
WEBSITE 61
WEBSITE_PATH 61
WEBSITE_QUERY 61 wizard
Crystal Enterprise report publishing ix
Index 149 150 Tivoli Data Warehouse Schema Reference
Printed in USA
SC32-1497-00