© copyright ibm corporation 2005, 2016

IBM Cognos Framework Managerバージョン 11.0.0

ユーザー・ガイド

IBM

注記

本書および本書で紹介する製品をご使用になる前に、 487 ページの『特記事項』に記載されている情報をお読みください。

製品情報

この資料は、IBM Cognos Analytics バージョン 11.0.0 を対象として作成されています。また、その後のリリースも対象となる場合があります。

お客様の環境によっては、資料中の円記号がバックスラッシュと表示されたり、バックスラッシュが円記号と表示されたりする場合があります。

　

原典： IBM Cognos Framework ManagerVersion 11.0.0User Guide

発行：日本アイ・ビー・エム株式会社

担当：トランスレーション・サービス・センター

Licensed Materials - Property of IBM

© Copyright IBM Corporation 2005, 2016.

目次

はじめに . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix

第 1 章新機能 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111.0.4 で変更された機能 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

第 2 章 Framework Manager の開始 . . . . . . . . . . . . . . . . . . . . . . . 3問題の分析 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3IBM Cognos Analytics アプリケーションの構築 . . . . . . . . . . . . . . . . . . . . . . . 4使用するオブジェクト . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5プロジェクトの作成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9プロジェクトのオープン . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11プロジェクト・ページ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

プロジェクト・ビューアー . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11プロジェクトのオプションの変更 . . . . . . . . . . . . . . . . . . . . . . . . . . . 14オブジェクトの並べ替え . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15「エクスプローラー」タブ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16「ダイアグラム」タブ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17「ディメンション・マップ」タブ . . . . . . . . . . . . . . . . . . . . . . . . . . . 18「プロパティー」ウィンドウ . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18「ツール」ウィンドウ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

プロジェクト内のオブジェクトの命名規則 . . . . . . . . . . . . . . . . . . . . . . . . . 23サンプル・モデル . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Great Outdoors ウェアハウス・モデル . . . . . . . . . . . . . . . . . . . . . . . . . 25Great Outdoors 販売モデル . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

第 3 章 Model Design Accelerator . . . . . . . . . . . . . . . . . . . . . . . 29エクスプローラー・ツリー . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29エクスプローラー・ダイアグラム . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30Model Accelerator ワークスペース . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

クエリー・サブジェクト・ダイアグラム . . . . . . . . . . . . . . . . . . . . . . . . . 31関係編集モードの使用 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32「モデル警告」ビュー . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

ダイアグラムの設定の変更 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33プロジェクトの作成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34スター・スキーマ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35スター・スキーマの管理 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

第 4 章データ・ソースからのメタデータのインポート . . . . . . . . . . . . . . . . 39データ・ソース . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39データ・ソースのセキュリティー . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40ネイティブ・メタデータ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40データ・ソース接続 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

データ・ソース接続の作成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44メタデータのインポート . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

リレーショナル・データベースからのメタデータのインポート . . . . . . . . . . . . . . . . . 47IBM Cognos モデルからのメタデータのインポート . . . . . . . . . . . . . . . . . . . . . 51Architect モデルまたは Impromptu カタログからのメタデータのインポート . . . . . . . . . . . . 52IBM Cognos DecisionStream または IBM Cognos Data Manager からのメタデータのインポート . . . . . 52サード・パーティーのメタデータ・ソースからのメタデータのインポート . . . . . . . . . . . . . 56他のソースからのメタデータのトラブルシューティング . . . . . . . . . . . . . . . . . . . 66

© Copyright IBM Corp. 2005, 2016 iii

データ・ソースとして XML を使用したメタデータのインポート . . . . . . . . . . . . . . . . 68同じ名前のオブジェクトのインポート . . . . . . . . . . . . . . . . . . . . . . . . . 69

第 5 章リレーショナル・メタデータのモデル作成 . . . . . . . . . . . . . . . . . . 71インポート・ビューの設定 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71ビジネス・ビューの設定 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72関係 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

カーディナリティー . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73関係の変更 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77関係を表す複雑な式の作成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77関係の作成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78関係のショートカットの作成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78関係の検出と生成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79ブリッジ・テーブル . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

クエリー・サブジェクト . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84データ・ソース・クエリー・サブジェクト . . . . . . . . . . . . . . . . . . . . . . . . 84モデル・クエリー・サブジェクト . . . . . . . . . . . . . . . . . . . . . . . . . . . 87ストアード・プロシージャー・クエリー・サブジェクト . . . . . . . . . . . . . . . . . . . 89行列式 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94既存のオブジェクトに基づくモデル・クエリー・サブジェクトの作成 . . . . . . . . . . . . . . . 98関連オブジェクトの表示 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99クエリー・セットの作成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99クエリー・サブジェクトまたはクエリー・セットのテスト . . . . . . . . . . . . . . . . . . 103クエリー・サブジェクトの検証 . . . . . . . . . . . . . . . . . . . . . . . . . . . 106クエリー・サブジェクトの更新 . . . . . . . . . . . . . . . . . . . . . . . . . . . 108クエリー・サブジェクトをディメンションに変換する . . . . . . . . . . . . . . . . . . . . 108モデル・クエリー・サブジェクトをデータ・ソース・クエリー・サブジェクトに変換する . . . . . . . . 109SQL の編集 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109SQL のタイプの変更 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110SQL 生成方法の変更 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116

ディメンション . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118正規化されたデータ・ソース . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119標準ディメンションの作成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119レベルのメンバーのソート . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126役割 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128数値データ・ディメンションの作成 . . . . . . . . . . . . . . . . . . . . . . . . . . 130数値データをクエリー・アイテムに変換する . . . . . . . . . . . . . . . . . . . . . . . 131範囲の関係 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132既存のオブジェクトに基づく標準ディメンションの作成 . . . . . . . . . . . . . . . . . . . 133関連オブジェクトの表示 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133ディメンションのテスト . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134標準ディメンションをクエリー・サブジェクトに変換する . . . . . . . . . . . . . . . . . . 137

多言語メタデータ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138多言語メタデータのサポート . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138多言語レポート環境の設定 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139多言語データ・ソースによるモデル作成 . . . . . . . . . . . . . . . . . . . . . . . . 140マクロを使用して多言語データをモデル化する . . . . . . . . . . . . . . . . . . . . . . 141プロジェクトへの言語の追加 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142変換テーブルのエクスポート . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143変換テーブルのインポート . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144例 - リレーショナル・メタデータの多言語プロジェクトの作成 . . . . . . . . . . . . . . . . . 144

クエリー・アイテム . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146クエリー・アイテムの集計方法の変更 . . . . . . . . . . . . . . . . . . . . . . . . . 150クエリー・アイテムの形式設定 . . . . . . . . . . . . . . . . . . . . . . . . . . . 159プロンプト・コントロールの定義 . . . . . . . . . . . . . . . . . . . . . . . . . . . 159クエリー・アイテムを数値データに変換する . . . . . . . . . . . . . . . . . . . . . . . 165

iv IBM Cognos Framework Manager バージョン 11.0.0: ユーザー・ガイド

ビジネス・ルール . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166計算の作成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166フィルターの作成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169フィルターの適用 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172例 - 各国の通貨名の表示 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174パラメーター・マップの作成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175例 - リレーショナル・メタデータの言語値の指定 . . . . . . . . . . . . . . . . . . . . . 177セッション・パラメーターの作成 . . . . . . . . . . . . . . . . . . . . . . . . . . . 177リレーショナル・データ・ソース・クエリー・サブジェクトでのパラメーターの使用 . . . . . . . . . 179クエリー・マクロを使用したプロンプトの作成 . . . . . . . . . . . . . . . . . . . . . . 180

モデルの編成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191スター・スキーマ・グループの作成 . . . . . . . . . . . . . . . . . . . . . . . . . . 192ショートカット . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197フォルダーまたはネームスペースの作成 . . . . . . . . . . . . . . . . . . . . . . . . 201クエリー・アイテム・フォルダーの作成 . . . . . . . . . . . . . . . . . . . . . . . . 203数値データ・フォルダーの作成 . . . . . . . . . . . . . . . . . . . . . . . . . . . 203

永続的なモデル . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204永続モデルの作成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205永続モデルのテスト . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206

モデルの分析 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207モデルを分析する手順 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212

第 6 章 SAP BW メタデータ . . . . . . . . . . . . . . . . . . . . . . . . . . 215SAP BW データ・ソースからのインポート . . . . . . . . . . . . . . . . . . . . . . . . 215

SAP BW メタデータおよびデータへのアクセス権限 . . . . . . . . . . . . . . . . . . . . 216SAP BW 構造 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218SAP BW 階層 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218保護された InfoCube にアクセスする手順 . . . . . . . . . . . . . . . . . . . . . . . 220SAP BW データ・ソースからインポートする手順 . . . . . . . . . . . . . . . . . . . . . 221

SAP BW オブジェクトを Framework Manager にマップする . . . . . . . . . . . . . . . . . . 222ディメンション (SAP BW) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223

標準ディメンションの変更 (SAP BW) . . . . . . . . . . . . . . . . . . . . . . . . . 224役割 (SAP BW) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230キー数値ディメンションの変更 (SAP BW) . . . . . . . . . . . . . . . . . . . . . . . 233関連オブジェクトの表示 (SAP BW) . . . . . . . . . . . . . . . . . . . . . . . . . . 233ディメンションまたは他のオブジェクトのテスト (SAP BW) . . . . . . . . . . . . . . . . . 234モデル・クエリー・サブジェクト (SAP BW) . . . . . . . . . . . . . . . . . . . . . . . 237

クエリー・アイテム (SAP BW) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240クエリー・アイテムの集計方法の変更 (SAP BW) . . . . . . . . . . . . . . . . . . . . . 244クエリー・アイテムの形式設定 (SAP BW) . . . . . . . . . . . . . . . . . . . . . . . 248プロンプト・コントロールの定義 (SAP BW) . . . . . . . . . . . . . . . . . . . . . . . 249SAP BW 変数 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254数値変数のプロパティー値 (SAP BW) . . . . . . . . . . . . . . . . . . . . . . . . . 258特性変数のプロパティー値 (SAP BW) . . . . . . . . . . . . . . . . . . . . . . . . . 259選択リスト・プロンプト (SAP BW) . . . . . . . . . . . . . . . . . . . . . . . . . . 260

ビジネス・ルールの追加 (SAP BW) . . . . . . . . . . . . . . . . . . . . . . . . . . . 260計算の作成 (SAP BW) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261フィルターの作成 (SAP BW) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263フィルターの適用 (SAP BW) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266パラメーター・マップの作成 (SAP BW) . . . . . . . . . . . . . . . . . . . . . . . . 268セッション・パラメーターの作成 (SAP BW) . . . . . . . . . . . . . . . . . . . . . . . 270

モデルの編成 (SAP BW) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271ショートカット (SAP BW) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272フォルダーまたはネームスペースの作成 (SAP BW) . . . . . . . . . . . . . . . . . . . . 273

目次 v

第 7 章パッケージの発行 . . . . . . . . . . . . . . . . . . . . . . . . . . . 277モデルまたはパッケージの検証 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277パッケージの作成または変更 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280

パッケージの作成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281パッケージの変更 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282

セキュリティー . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282ユーザー、グループ、および役割 . . . . . . . . . . . . . . . . . . . . . . . . . . . 283データ・セキュリティーの追加 . . . . . . . . . . . . . . . . . . . . . . . . . . . 284オブジェクト・セキュリティー . . . . . . . . . . . . . . . . . . . . . . . . . . . 286パッケージ・セキュリティーの変更 . . . . . . . . . . . . . . . . . . . . . . . . . . 289

言語の指定 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2901 つのパッケージの言語の指定 . . . . . . . . . . . . . . . . . . . . . . . . . . . 290すべてのパッケージの言語の指定 . . . . . . . . . . . . . . . . . . . . . . . . . . . 290

消去オプションの設定 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291外部化されたクエリー・サブジェクトおよびディメンション . . . . . . . . . . . . . . . . . . . 291パッケージの発行 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293

OLAP データ・ソースに基づくパッケージの発行 . . . . . . . . . . . . . . . . . . . . . 296スクリプトの実行によるパッケージの発行 . . . . . . . . . . . . . . . . . . . . . . . . 298最新バージョンのパッケージを使用するようにレポートを更新する . . . . . . . . . . . . . . . 298

第 8 章プロジェクトの管理 . . . . . . . . . . . . . . . . . . . . . . . . . . 301モデル内のメタデータ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301

パッケージの閲覧 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301パッケージでのオブジェクトの分布の表示 . . . . . . . . . . . . . . . . . . . . . . . . 302モデル文書の作成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302

マルチユーザーのモデル作成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303プロジェクトの分岐とマージ . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303セグメント化プロジェクトとリンク・プロジェクト . . . . . . . . . . . . . . . . . . . . . 310外部リポジトリーによる管理 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315

メタデータの管理 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316プロジェクトのコピー、移動、名前変更、または削除 . . . . . . . . . . . . . . . . . . . . 316パッケージ変更の影響の分析 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319新規ソースへのオブジェクトの再マップ . . . . . . . . . . . . . . . . . . . . . . . . 321メタデータのエクスポート . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323プロジェクトの再使用 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324モデル移植性 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326

プロジェクトの同期 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334同期する手順 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336

クエリー動作 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337ガバナー . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338自動集計が処理される場所の指定 . . . . . . . . . . . . . . . . . . . . . . . . . . . 346クエリー処理タイプの設定によるパフォーマンスの改善 . . . . . . . . . . . . . . . . . . . 346レポートを実行する際にキャッシュ・データを再使用してパフォーマンスを改善する . . . . . . . . . 347トランザクション・モードの指定 . . . . . . . . . . . . . . . . . . . . . . . . . . . 349関数セットの選択 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 350サービス品質 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351クエリーの制御および最適化 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353

第 9 章動的クエリー・モードの使用 . . . . . . . . . . . . . . . . . . . . . . . 355Framework Manager モデルおよびパッケージが動的クエリー・モードを使用できるようにする . . . . . . 356動的クエリー・モードを使用する場合の考慮事項 . . . . . . . . . . . . . . . . . . . . . . 359動的クエリー・モードのガバナー . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360メモリー内キャッシュ機能 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370高度な Null 消去 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371メンバーの順序 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372フィルターを適用して結合を最適化する . . . . . . . . . . . . . . . . . . . . . . . . . 374

vi IBM Cognos Framework Manager バージョン 11.0.0: ユーザー・ガイド

モデル内での集計クエリーの作成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376別個のデータ・セットをリンクするためのブリッジ・テーブルの作成 . . . . . . . . . . . . . . . . 377ストアード・プロシージャーとトランザクション・アクセス・モード . . . . . . . . . . . . . . . . 377

第 10 章メタデータ・モデリング・ガイド . . . . . . . . . . . . . . . . . . . . 381IBM Cognos のモデル作成の概念を理解する . . . . . . . . . . . . . . . . . . . . . . . . 381

リレーショナル・モデル作成の概念 . . . . . . . . . . . . . . . . . . . . . . . . . . 381モデル設計に関する考慮事項 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 391ディメンション・モデル作成の概念 . . . . . . . . . . . . . . . . . . . . . . . . . . 400

リレーショナル・モデルの作成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402リレーショナル・モデル作成の基盤の定義 . . . . . . . . . . . . . . . . . . . . . . . . 402ディメンションによるモデルの表現方法の定義 . . . . . . . . . . . . . . . . . . . . . . 412モデルの整理 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415

第 11 章 IBM Cognos ソフトウェアによって生成される SQL . . . . . . . . . . . . 419ディメンション・クエリーについて . . . . . . . . . . . . . . . . . . . . . . . . . . . 419

単一ファクト・クエリー . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 419一致するディメンションに対する複数ファクト、複数細分性のクエリー . . . . . . . . . . . . . . 4211-1 の関係としての 1-n の関係のモデル作成 . . . . . . . . . . . . . . . . . . . . . . . 424一致しないディメンションに対する複数ファクト、複数細分性のクエリー . . . . . . . . . . . . . 426

あいまいに識別されているディメンションおよびファクトの解決 . . . . . . . . . . . . . . . . . 430階層のレベルを表すクエリー・サブジェクト . . . . . . . . . . . . . . . . . . . . . . . 430分割が不要であったクエリーの解決 . . . . . . . . . . . . . . . . . . . . . . . . . . 431

第 12 章モデルのアップグレード . . . . . . . . . . . . . . . . . . . . . . . . 437アップグレード前のモデルの検証 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 437モデルのオープンとアップグレード . . . . . . . . . . . . . . . . . . . . . . . . . . . 438

アップグレードとガバナー . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 438アップグレードとデータ型 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 439アップグレードと、SAP BW メタデータに基づくクエリー・サブジェクト . . . . . . . . . . . . . 440

アップグレードされた IBM Cognos ReportNet モデルの検証と修復 . . . . . . . . . . . . . . . . 440ディメンション情報を行列式またはディメンションに変換する . . . . . . . . . . . . . . . . . 441アップグレードされた IBM Cognos ReportNet モデルのオブジェクトの選択と修復 . . . . . . . . . 445

セグメント化されたプロジェクトおよびリンクされているプロジェクトのアップグレード . . . . . . . . . 446

付録 A. パターンを使用したデータの表示形式の設定 . . . . . . . . . . . . . . . . 447パターンのガイドライン . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 447日時の記号 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 448小数点の形式の記号 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455

付録 B. ユーザー補助機能 . . . . . . . . . . . . . . . . . . . . . . . . . . . 457Framework Manager のユーザー補助機能 . . . . . . . . . . . . . . . . . . . . . . . . 457Framework Manager のキーボード・ショートカット . . . . . . . . . . . . . . . . . . . . . 457

Model Design Accelerator のキーボード・ショートカット . . . . . . . . . . . . . . . . . . 457IBM とユーザー補助機能 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 458

付録 C. トラブルシューティング. . . . . . . . . . . . . . . . . . . . . . . . . 459Framework Manager で新規プロジェクトを開始する際の認証の問題 . . . . . . . . . . . . . . . 459以前のバージョンの Cognos Framework Manager からアップグレードした後に新しいプロジェクトを作成しようとすると BMT-MD-003 エラーになる . . . . . . . . . . . . . . . . . . . . . . . . . 459Oracle で 2 つの CLOB を比較できない . . . . . . . . . . . . . . . . . . . . . . . . . 459ERWin からインポートしたメタデータのメモリー不足エラー . . . . . . . . . . . . . . . . . . 459Framework Manager からゲートウェイ URI にアクセスできない . . . . . . . . . . . . . . . . 460オブジェクト名が誤った言語で表示される . . . . . . . . . . . . . . . . . . . . . . . . . 461Teradata からインポートしたモデルのクエリー・サブジェクトをテストしたときのエラー . . . . . . . . 461Oracle での完全外部結合で返される結果が正しくない. . . . . . . . . . . . . . . . . . . . . 461

目次 vii

入力 SQL クエリー・サブジェクトのエラー . . . . . . . . . . . . . . . . . . . . . . . . 461QE-DEF-0259 エラー . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 462外部化されたキー数値ディメンションに古いプロンプト値が維持される . . . . . . . . . . . . . . . 462古いモデルでレベルのオブジェクト・セキュリティーが表示される . . . . . . . . . . . . . . . . 463CWM ファイルへの Framework Manager モデルのエクスポートがエラー「MILOG.TXT が見つかりませんでした」で失敗する . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463アップグレード後の内部結合用 SQL の違い . . . . . . . . . . . . . . . . . . . . . . . . 463完全外部結合が Oracle 9i および 10GR1 に送信されない . . . . . . . . . . . . . . . . . . . 464数値の計算で説明不能な不一致が発生する . . . . . . . . . . . . . . . . . . . . . . . . . 464値を検索すると予期しない結果が返される場合がある . . . . . . . . . . . . . . . . . . . . . 466

付録 D. Transformer で使用する SAP BW データの作業ガイドライン . . . . . . . . 467Framework Manager におけるパッケージを使用した SAP BW データの処理 . . . . . . . . . . . . 468

SAP BW Business Explorer Query Designer でのクエリーの作成 . . . . . . . . . . . . . . . 468Framework Manager でのパッケージの作成 . . . . . . . . . . . . . . . . . . . . . . . 471Transformer でのモデルの作成 . . . . . . . . . . . . . . . . . . . . . . . . . . . 474

Framework Manager における外部化された CSV ファイルを使用した SAP BW データの処理. . . . . . . 476SAP BW クエリーの要件 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 477Framework Manager の考慮事項 . . . . . . . . . . . . . . . . . . . . . . . . . . 479SAP BW データからの PowerCube の作成 . . . . . . . . . . . . . . . . . . . . . . . 481

付録 E. 予約語 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483

付録 F. XML データ型 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 485

特記事項 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 487

索引 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 491

viii IBM Cognos Framework Manager バージョン 11.0.0: ユーザー・ガイド

はじめに

IBM® Cognos® Framework Manager はメタデータ・モデル作成ツールです。モデルとは、1 つ以上のデータ・ソースに含まれる情報をビジネスの観点から表現したものです。このビジネス表現にセキュリティーと多言語機能を追加すると、世界中のさまざまなユーザー・グループのニーズに 1 つのモデルで応えられるようになります。

この資料には、レポート作成やパッケージ配布のためのモデルの準備に役立つ手順、例、注意事項、ヒントをはじめとする背景情報が記載されています。

対象読者

この資料は、データ・モデル作成者が IBM Cognos Framework Manager を使用する際に役立つことを目的としています。Framework Manager を使用する前に、データ・モデル作成とクエリーの書き方を理解しておく必要があります。

情報の入手方法

Web で製品資料 (各国語版のすべての資料を含む) を検索するには、IBMKnowledge Center (http://www.ibm.com/support/knowledgecenter) にアクセスしてください。

将来の見通しに関する記述

このドキュメントには製品の現在の機能が記載されています。現在利用できない項目への言及が含まれる場合もありますが、将来的に使用可能になることを示唆するものではありません。このような言及は、なんらかの資料、規約、または機能を提供するという誓約、保証、または法的義務ではありません。特性や機能の開発、公開、およびその時期に関しては、引き続き IBM が単独裁量権を有します。

サンプルに関する特記事項

Sample Outdoors 社、Great Outdoors 社、GO 販売、Sample Outdoors またはGreat Outdoors 名のすべてのバリエーション、および Planning サンプルでは、IBM および IBM のお客様向けのサンプル・アプリケーションを開発するために使用されるサンプル・データにより、架空の企業活動が描出されています。これらの架空データには、販売取引、商品流通、財務、および人事のサンプル・データが含まれます。実在する名称、住所、連絡先電話番号、取引額とは一切関係がありません。また、サンプル・ファイルの中には、手動またはコンピューターで生成された架空のデータ、学術的ソースまたは公共のソースを基に編集された実際のデータ、版権所有者の許可を得て使われているデータなどが、サンプル・アプリケーションを開発するためのサンプル・データとして使用されている場合もあります。参照される製品名は、それぞれの所有者の商標である可能性があります。許可なく複製することは禁止されています。

© Copyright IBM Corp. 2005, 2016 ix

http://www.ibm.com/support/knowledgecenter


ユーザー補助機能

ユーザー補助機能は、運動障害または視覚障害など身体に障害を持つユーザーが情報技術製品を快適に使用できるようにサポートします。 IBM Cognos FrameworkManager は、ユーザー補助機能を備えています。詳細については、 457 ページの『付録 B. ユーザー補助機能』を参照してください。

x IBM Cognos Framework Manager バージョン 11.0.0: ユーザー・ガイド

第 1 章新機能

このセクションは、アプリケーションのアップグレード、配布戦略、および研修の要件を計画するのに役立ちます。

アップグレードについては、「IBM Cognos Analytics インストールおよび設定ガイド」および 437 ページの『第 12 章モデルのアップグレード』のトピックを参照してください。

IBM Cognos Analytics の本リリースの新機能については、「IBM Cognos AnalyticsNew Features Guide 」を参照してください。

IBM Cognos 製品でサポートされている環境 (オペレーティング・システム、パッチ、ブラウザー、Web サーバー、ディレクトリー・サーバー、データベース・サーバー、アプリケーション・サーバーについての情報を含む) の最新のリストを確認するには、IBM Software Product Compatibility Reports のページ(www.ibm.com/support/docview.wss?uid=swg27047186) を参照してください。

11.0.4 で変更された機能IBM Cognos Framework Manager バージョン 11.0.4 では、次の機能が変更されました。

外部アプリケーション用ディスパッチャー URI

「外部アプリケーション用ディスパッチャー URI」の形式が、http://<server>:<port>/p2pd/servlet/dispatch から http://<server>:<port>/bi/v1/disp に変更されました。以前のバージョンの Cognos Framework Managerからアップグレードする場合は、IBM Cognos Configuration のこの値を更新してください。

© Copyright IBM Corp. 2005, 2016 1

http://www.ibm.com/support/docview.wss?uid=swg27047186

2 IBM Cognos Framework Manager バージョン 11.0.0: ユーザー・ガイド

第 2 章 Framework Manager の開始

IBM Cognos Framework Manager は、IBM Cognos ソフトウェアのクエリー生成を支援するメタデータのモデル作成ツールです。モデルとは、1 つ以上のデータ・ソースの物理情報とビジネス情報を含むメタデータの集まりです。 IBM Cognos ソフトウェアでは、正規化および非正規化されたリレーショナル・データ・ソースやさまざまな OLAP データ・ソースに基づく業績管理が可能です。セキュリティーや多言語機能を追加すると、1 つのモデルで世界中のさまざまなユーザー・グループのレポート作成、随時実行可能なクエリー、および分析のニーズに応えられるようになります。

IBM Cognos Framework Manager を使って作業を開始する前に、解決するレポート作成に関する問題に精通しておく必要があります。

開始するには、以下を行います。

手順1. レポート作成の問題を分析します。

2. 使用するオブジェクトについて学習します。

3. プロジェクトを作成するか、開きます。

4. Framework Manager でウィンドウを検討します。

5. Framework Manager に組み込まれているサンプル・モデルを検討します。

問題の分析開始する前に、解決を試みるレポート作成の問題について、またその解決にどのようなデータを使用できるかについて理解しておく必要があります。

以下の問題に対処することができない場合は、レポート作成要件についてユーザーに話してください。

手順1. あなたとユーザーは、レポート作成要件に同意していますか?

解決すべき問題として、多言語使用、パフォーマンス、セキュリティー、およびクエリー・アイテムとフィルターを編成して結合する方法が含まれる可能性があります。

2. 必要なデータおよびメタデータがデータ・ソースに含まれていますか?

プライマリー・キー、インデックス、外部キーなどのメタデータがないと、レポートの実行に時間がかかりすぎたり、正しくない結果になってしまったりする可能性があります。必要なデータおよびメタデータがデータ・ソースに含まれていない場合、そのデータ・ソースを変更できますか? あるいはそれに対処できますか?

3. 複数のソースに同じデータが存在していますか?


存在している場合、レポート作成要件に最も合ったデータ・ソースを選択してください。データ・ウェアハウスが使用可能な場合、一般的には稼働データベースよりデータ・ウェアハウスを使用する方が望ましいと言えます。スター・スキーマに基づいたデータ・ウェアハウスが理想的です。これが存在しておらず、レポート作成アプリケーションが頻繁に使用されることが予想される場合は、それを作成することを検討してください。

4. どのデータ・ソース表がファクト表で、どれがディメンションですか? また、ファクト表とディメンションを兼ねているのはどれですか?

5. 各ディメンションのキーと属性は何ですか?

6. どの関係が必要ですか?

7. 表間に複数の関係パスが存在していますか?

存在している場合、それぞれのパスは何を表していますか? それぞれに対して優先パスを定義する必要があります。

タスクの結果

データ・ソースの名前、データ・ソース内のテーブルおよび列の名前を調べ、 IBMCognos によって予約されている名前を使用していないことを確認します。予約語を使用する必要がある場合、SQL 仕様で単語を引用符で囲んでください。例えば、select Orderdate, "Timezone" のようにします。詳細については、 483 ページの『付録 E. 予約語』を参照してください。

IBM Cognos Analytics アプリケーションの構築IBM Cognos Analytics コンポーネントを使用して、レポート・アプリケーションおよび分析アプリケーションを構築できます。

IBM Cognos Analytics アプリケーションの存続期間は数カ月から数年にまで及ぶことがあります。その期間中にデータは変更される可能性があり、新しい要件が生じます。基本データが変更されると、作成者は既存のコンテンツを変更して新しいコンテンツを作成する必要があります。やがて、管理者もモデルやデータ・ソースを更新する必要が生じます。データ・ソースの使用方法の詳細については、「IBMCognos Analytics 管理およびセキュリティー・ガイド」および「IBM CognosFramework Manager ユーザー・ガイド」を参照してください。

始める前に

実用的なアプリケーションには、変更管理やデータ制御などを目的としたプロセスに加え、技術インフラストラクチャー、セキュリティー・インフラストラクチャー、ポータルなどが含まれています。追加情報については、IBM Cognos SolutionsImplementation Methodology ツールキットを参照してください。このツールキットには、実装ロードマップやサポート・ドキュメントが含まれます。ツールキットに関する情報は、IBM サポート・ポータル (www.ibm.com/support/entry/portal/support) で入手できます。

IBM Cognos Analytics を使用してすべての IBM Cognos Analytics コンポーネントにまたがるアプリケーションを構築する際には、データ・ソースとモデルを探して準備し、コンテンツを作成して発行してから、情報を配信します。次の図は、ワ


http://www.ibm.com/support/entry/portal/support

ークフローの概要を示しています。

手順1. データ・ソースとモデルを見つけて準備します。

IBM Cognos Analytics では、リレーショナル・データ・ソースとディメンション・データ・ソースの両方の多様なデータ・ソースからレポートを作成できます。データベース接続は Web 管理インターフェースで作成され、モデルの作成や、オーサリング、およびアプリケーションの実行の目的に使用されます。

オーサリングや表示の目的でデータを使用するには、Studio/Authoring ツールに (パッケージと呼ばれる) メタデータのモデルのサブセットが必要になります。このメタデータは Framework Manager での詳細なモデル化を必要とする場合があります。

2. コンテンツを作成して発行します。

レポート、スコアカード、分析、ワークスペースなどは、IBM CognosAnalytics の Studio/Authoring ツールを使用して作成されます。どのStudio/Authoring ツールを使用するかは、レポートの内容、使用期間、対象読者などによって異なり、ディメンションを使用してデータをモデル化するか、リレーショナルにデータをモデル化するかによっても異なります。例えば、IBMCognos Query Studio および IBM Cognos Analysis Studio ではセルフサービスによるレポート作成と分析が行われ、IBM Cognos Analytics - Reportingではスケジュールされたレポートが作成されます。通常、Reporting のレポートおよびスコアカードは広範囲の利用者を想定して作成され、発行され、バーストや配布などのスケジュールが設定されます。また、Reporting を使用してセルフサービスによるレポート作成のためのテンプレートを準備することもできます。

3. 情報を配信して表示します。

IBM Cognos ポータルからコンテンツを配信し、他のメカニズムによって保存および配信された情報を表示します。作成に使用した Studio/Authoring ツール内からレポート、分析、スコアカードなどを実行することもできます。

調整とパフォーマンスについては、「IBM Cognos Analytics 管理およびセキュリティー・ガイド」および IBM サポート・ポータル (www.ibm.com/support/entry/portal/support) を参照してください。

使用するオブジェクトIBM Cognos Framework Manager で作業を行うとき、プロジェクトに含まれるいくつかのオブジェクトを使用して作業します。

第 2 章 Framework Manager の開始 5

http://www.ibm.com/support/entry/portal/support

プロジェクト

プロジェクトには、1 つのモデル、ネームスペース、パッケージ、データ・ソース、およびモデル情報の維持および共有のための関連情報が含まれます。単一のプロジェクトが多数のデータ・ソースやテーブルを使用することがあります。

IBM Cognos Framework Manager プロジェクトは、プロジェクト・ファイル(.cpf) とプロジェクトを定義する特定の .xml ファイルとを含むフォルダーとして表示されます。プロジェクト・フォルダー内のファイルは、プロジェクトごとに一意となります。プロジェクトおよび関連ファイルはプロジェクト・フォルダーに含まれます。

一般に、2 次ファイルは、「プロジェクトの管理」メニューの移動、名前変更、削除などのコマンドによる操作から影響を受ける可能性があるので、プロジェクト・フォルダーに追加しないでください。 2 次ファイルをプロジェクト・フォルダーに追加することにした場合、それらのファイルは絶対パスと共に追加されます。それらを元の場所から移動する場合には、再ターゲットを行う必要があります。

プロジェクト・フォルダーの内容を以下に示します。

<プロジェクト名>.cpfFramework Manager のプロジェクト・ファイル。プロジェクトを定義する.xsd ファイルおよび .xml ファイルを参照します。

archive-log.xmlアーカイブされたメインのログ・ファイルの一部を含むファイル。

customdata.xmlダイアグラムのレイアウト情報を含むファイル。

このファイルが削除された場合、レイアウト情報は失われます。自動レイアウトが適用されます。

IDLog.xml分岐およびマージを使用するモデルのオブジェクトをトラッキングするファイル。

log.xmlモデルに加えられたすべての変更のリスト。

mda_metadata.xmlデータ・ソースからインポートされたメタデータを含む、Model DesignAccelerator ファイル。

mda_engine_project.xmlスター・スキーマの定義を含む、Model Design Accelerator ファイル。

model.xmlFramework Manager ユーザーによって作成される実際のモデル・データ。

preferences.xmlFramework Manager プロジェクトの設定。

session-log.xml


モデル内の保存されていないトランザクションのリスト。プロジェクトが保存されると、このリストは削除されます。「トランザクション履歴の表示」を使用して、このファイルの内容を表示します。

Framework Manager が開始されると、既存の session-log.xml ファイルはsession-log-backup.xml に名前変更されます。

session-log-backup.xml

直前のセッションでは session-log.xml であったファイル。このファイルを使用して、現行セッションに予期されない中断が発生した場合に、モデル作成者は保存されていないモデル・トランザクションを復元するためのスクリプトを実行できます。

このファイルは、Framework Manager が開始されるたびに削除されます。このファイルのコピーを保持する必要がある場合は、必ず現在のFramework Manager セッションを終了する前にコピーを作成してください。

repository.xmlリポジトリーに追加されたプロジェクトまたはセグメントごとの、ログに記録されたバージョン履歴。このファイルは、プロジェクトをリポジトリーに追加した場合にのみ存在します。

upgradeReport.htmアップグレードの後に表示される、アップグレード概要メッセージの内容。

モデル

モデルとは、関連する 1 つ以上のレポート作成アプリケーションに必要な、ディメンション、クエリー・サブジェクト、その他のオブジェクトのセットのことです。

Framework Manager モデルは、いくつかの方法で値をデータ・ソースに追加するメタデータ・レイヤーです。最も重要なのは、ソース・データに含まれる情報のビジネス・ビューを提供して、レポート作成、分析、およびクエリーを単純化することです。ビジネス・ビューでは、以下のことが可能です。

v レポートを作成するビジネス・エリアを表すフォルダーに、項目を整理して入れます。

v 数値、通貨、日付、時刻、およびその他のフォーマットを使用して、項目をフォーマット設定します。

v ユーザーが選択した言語で操作できるように複数言語でフォルダー名、項目名、説明、ヒント、およびデータを提示します。

v リレーショナル・データ・ソースに送信される SQL クエリーの生成を自動化します。

v デフォルトのプロンプトを指定します。

これには、IBM Cognos Software が記述名を使用してユーザーにプロンプトを出しながら、実際にはクエリーのパフォーマンスを向上させるためにコードまたはキー値を対象にフィルター処理を行うことなどが含まれます。

特に、Framework Manager モデルを変更することによって、データ・ソースに送信されるクエリーを効率的で、正しく構成された、安全なクエリーにすることがで


きます。クエリーの生成を制御する規則を指定すること、データの特定の行または列に対するユーザー・アクセスを制限すること、およびデータの関係をモデル化してユーザーがデータの複雑さを意識しないようにすることができます。

ネームスペース

ネームスペースは、クエリー・アイテム、ディメンション、クエリー・サブジェクト、その他のオブジェクトを一意に識別します。複数の異なるデータベースは別個のネームスペースにインポートして、名前の重複を避けてください。

パッケージ

パッケージは、ディメンション、クエリー・サブジェクト、およびプロジェクトに定義されたその他のオブジェクトのサブセットです。パッケージは、IBM CognosAnalytics サーバーに対して実際に発行されるものであり、レポート、分析、および随時クエリーの作成に使用されます。

ディメンション

ディメンションとは、ビジネスの主要な側面 (例えば、製品、日付、市場など) に関するデータを広義でグループ化したものです。

IBM Cognos Framework Manager で扱うことのできるディメンションのタイプには、標準ディメンションと数値データ・ディメンションとがあります。 SAP BWでは、数値データ・ディメンションはキー数値と呼ばれます。

クエリー・サブジェクト

クエリー・サブジェクトは、継承関係のあるクエリー・アイテムのセットです。

ほとんどの場合、クエリー・サブジェクトはテーブルのような働きをします。どの列に対してクエリーが実行された場合でも、クエリー・サブジェクトは同じ行のセットを生成します。

以下のような、異なるタイプのクエリー・サブジェクトがあります。

データ・ソースデータ・ソース・クエリー・サブジェクトは、単一のデータ・ソース内のデータを直接参照します。 IBM Cognos Framework Manager は、ユーザーがモデルにインポートしたテーブルおよびビューごとに、リレーショナル・データ・ソース・クエリー・サブジェクトを自動的に作成します。

モデルモデル・クエリー・サブジェクトは、データ・ソースから直接生成されるのではなく、他のモデル・クエリー・サブジェクトも含め、他のクエリー・サブジェクトまたはディメンション内のクエリー・アイテムをベースにしています。モデル・クエリー・サブジェクトを使用することによって、データ・ソースの、より抽象的でビジネス指向のビューを作成できます。

ストアード・プロシージャーストアード・プロシージャー・クエリー・サブジェクトは、リレーショナル・データ・ソースからプロシージャーをインポートするときに生成されま


す。 IBM Cognos Framework Manager では、ユーザー定義のストアード・プロシージャーのみがサポートされます。システム・ストアード・プロシージャーはサポートされません。

クエリー・アイテム

クエリー・アイテムは、レポート内に配置できるモデルの最小単位です。それは、製品が導入された日付など、物事の単一の特性を表します。

クエリー・アイテムは、クエリー・サブジェクトまたはディメンションに含まれます。例えば、テーブル全体を参照するクエリー・サブジェクトは、そのテーブル内の各列を表すクエリー・アイテムを含みます。

ユーザーにとって、クエリー・アイテムはレポートを作成するために最も重要なオブジェクトです。ユーザーはクエリー・アイテムのクエリー・アイテム・プロパティーを使用して、レポートを構築します。

プロジェクトの作成IBM Cognos Framework Manager では、プロジェクトのコンテキストに対して作業を行います。プロジェクトには、組織内のビジネス・モデルやビジネス・ルールに応じてユーザー用に編成したオブジェクトが含まれます。そのオブジェクトは、プロジェクト・ページに表示されます。

始める前に

メタデータをインポートする前に、プロジェクトを作成しておく必要があります。

プロジェクト・セグメントの作成の詳細については、 313 ページの『セグメントの作成』を参照してください。

Model Design Accelerator を使ったプロジェクトの作成の詳細については、 34 ページの『プロジェクトの作成』を参照してください。

手順1. 「ようこそ」ページで、「新規プロジェクトの作成」をクリックします。

Framework Manager を既に使用している場合は、「ファイル」、「新規作成」の順にクリックします。

ヒント: 認証の問題が発生している場合は、Microsoft Internet Explorer の信頼できるサイトのリストに Cognos Analytics ドメインを追加します。

2. 「新しいプロジェクト」ページで、プロジェクトの名前と場所を指定し、「OK」をクリックします。

デフォルトで、新規プロジェクトは動的クエリー・モードを使用します。互換クエリー・モードを使用するには、「動的クエリー・モードの使用」チェック・ボックスのチェックを外します。詳細については、 356 ページの『FrameworkManager モデルおよびパッケージが動的クエリー・モードを使用できるようにする』を参照してください。

3. 「言語を選択」ページで、プロジェクトの設計言語をクリックします。


「OK」をクリックした後、選択した言語を変更することはできません。ただし、他のプロジェクト言語を追加することはできます。詳細については、 142ページの『プロジェクトへの言語の追加』を参照してください。

永続モデルに対する適切な設計言語の選択の詳細については、 204 ページの『永続的なモデル』を参照してください。

注: 選択した言語が SAP BW サーバーでサポートされない場合、IBM CognosConfiguration のコンテンツ・ロケール・マッピングが使用されます。マッピングが定義されていない場合、Framework Manager は SAP BW サーバーのデフォルト言語を使用します。

4. 「OK」をクリックして、設計言語を選択します。

「メタデータ・ウィザード」が表示されます。

5. メタデータを即時にインポートするか、後でインポートするかを選択します。

v 即時にインポートするには、インポート・ソースを選択し、「次へ」をクリックします。

v 後でメタデータをインポートする場合は、「キャンセル」をクリックします。

6. メタデータを即時にインポートすることを選択した場合、「メタデータ・ウィザード」の指示に従います。

v データ・ソース接続を選択し、「次へ」をクリックします。

目的のデータ・ソース接続がリストされていない場合は、最初にそれを作成する必要があります。

v インポートするオブジェクトのチェック・ボックスをオンにします。

v インポート時にオブジェクト名の重複をどのように処理するのかを指定します。インポートして一意の名前を作成するかどうかを選択します。一意の名前を作成することを選択した場合、インポートされたオブジェクトは数字付きで表示されます。例えば、プロジェクトの中には QuerySubject とQuerySubject1 が表示されます。

v システム・オブジェクトをインポートする場合、「システム・オブジェクトを表示」チェック・ボックスをオンにし、インポートするシステム・オブジェクトを選択します。

v 関係の作成に使用する基準を指定し、「インポート」をクリックします。

詳細については、 72 ページの『関係』を参照してください。

インポートできなかったオブジェクトのリストおよびインポートされたオブジェクトの数が表示されます。

7. 「終了」をクリックします。

プロジェクト・ファイル (.cpf) および関連するすべてのファイルを、1 つのフォルダーに保存します。異なる名前または形式でプロジェクトを保存する際には必ず、別個のフォルダーにプロジェクトを保存してください。


プロジェクトのオープンメタデータをインポートしたり、既存のメタデータに対して変更を加えたりするには、事前にプロジェクトを開いておく必要があります。

サポートされている現行バージョンより古いモデル・スキーマを使ってプロジェクトが作成された場合、モデルをアップグレードするようプロンプトが出される可能性があります。

モデルがリポジトリーにチェックインされる場合、そのモデルはアップグレードできません。モデルをソース管理システムから手動でチェックアウトし、新規バージョンの IBM Cognos Framework Manager でそのモデルを開いてください。

セグメント化されたモデルをアップグレードする場合、各セグメントを個別に開いてアップグレードする必要があります。各セグメントをアップグレードした後、最上位のプロジェクト、つまりマスター・プロジェクトをアップグレードすることができます。

手順1. 「ようこそ」ページで、「プロジェクトを開く」をクリックします。

ヒント: Framework Manager を使用している場合、「ファイル」、「開く」の順にクリックします。

2. プロジェクト・フォルダーを参照して見つけ、.cpf ファイルをクリックします。

3. 「OK」をクリックします。

プロジェクト・ページプロジェクトを作成したり開いたりすると、プロジェクト・ページが表示されます。プロジェクト・ページは、プロジェクト・メタデータを設計、パッケージ化、および発行する場所です。このページにはいくつかのウィンドウとビューが含まれており、それらを使用して、プロジェクト内のオブジェクトを表示したり変更したりできます。

プロジェクト・ビューアープロジェクト・ビューアーは、プロジェクト内のオブジェクトを階層ビューで表示します。プロジェクト・ビューアーを使用して、オブジェクトを表示、変更、および作成できます。

関係は、「ダイアグラム」タブと「エクスプローラー」タブの両方に示されます。インポートされた関数は、「エクスプローラー」タブに示されます。

プロジェクト・ビューアーは、以下のアイコンを使用してオブジェクトおよび状態を表します。プロジェクトによって、これらのアイコンの一部または全部が使用されます。


アイコンオブジェクト

プロジェクト

ルート・ネームスペース、またはプロジェクト内の他のいずれかのネームスペース

データ・ソース・フォルダー

データ・ソース

パラメーター・マップ・フォルダー

パラメーター・マップ

パッケージ

パッケージ・フォルダー

発行されたパッケージ

計算

「使用方法」プロパティーが「属性」に設定された計算

「使用方法」プロパティーが「識別子」に設定された計算

埋め込み計算

「使用方法」プロパティーが「ファクト」に設定された計算

既存のモデル・オブジェクトに基づくモデル・ディメンション

データ・ソースからインポートされたディメンション

無効なディメンション。このディメンションは、データ・ソースからインポートされています。

フィルター



階層

階層内のレベル

数値データ

準加算数値データ

既存のモデル・オブジェクトに基づく数値データ・ディメンション。

データ・ソースからインポートされた数値データ・ディメンション。

無効な数値データ・ディメンション。このディメンションは、データ・ソースからインポートされています。

クエリー・アイテム

「使用方法」プロパティーが「識別子」に設定されたクエリー・アイテム

「使用方法」プロパティーが「ファクト」に設定されたクエリー・アイテム

ショートカット・クエリー・サブジェクトの下にあるクエリー・アイテム

既存のモデル・オブジェクトに基づくクエリー・サブジェクト

データ・ソースからインポートされたクエリー・サブジェクト

無効なクエリー・サブジェクト。このクエリー・サブジェクトは、データ・ソースからインポートされています。

多次元データに基づくクエリー・サブジェクト

「使用方法」プロパティーが「ファクト」に設定されたクエリー・アイテムを含むクエリー・サブジェクト。このクエリー・サブジェクトは、既存のモデル・オブジェクトに基づきます。

「使用方法」プロパティーが「ファクト」に設定されたクエリー・アイテムを含むクエリー・サブジェクト。このクエリー・サブジェクトは、データ・ソースからインポートされています。



「使用方法」プロパティーが「ファクト」に設定されたクエリー・アイテムを含むクエリー・サブジェクト。このクエリー・サブジェクトは、データ・ソースからインポートされたもので、無効です。

関係

更新されたリンク済みセグメントまたはプロジェクト。このアイコンは、他のアイコンの上に重なって表示されます。

リンク済みオブジェクト。このアイコンは、他のアイコンの上に重なって表示されます。

ショートカット。このアイコンは、他のアイコンの上に重なって表示されます。

無効なオブジェクト。このアイコンは、他のアイコンの上に重なって表示されます。

プロジェクトのオプションの変更プロジェクトのテストおよび変更の自動保存のオプションを 1 つ以上変更できます。

テスト・オプションは、このプロジェクトのために実行されるすべてのテストにグローバルに適用されます。選択したオブジェクトのテストについては、 71 ページの『第 5 章リレーショナル・メタデータのモデル作成』または 215 ページの『第 6 章 SAP BW メタデータ』を参照してください。

プロジェクトの自動保存は、電源異常などの予期しない中断が発生した場合に、データの損失を防ぐうえで役立つ場合があります。プロジェクトを自動的に保存するようにする場合は、保存操作の時間間隔を選択できます。

自動保存機能を使用するようにした場合でも、ダイアログ・ボックスが開いていて、そのダイアログ・ボックスが IBM Cognos Framework Manager の他の領域をロックしているときは、Framework Manager は変更を保存できません。例えば、「フォルダーの作成」ウィザードで表示されるダイアログ・ボックスを使用しているときは、メニュー・バーからコマンドにアクセスすることはできません。ダイアログ・ボックスを閉じた後、指定した自動保存間隔が経過すると、FrameworkManager は変更を自動的に保存します。

手順1. 「プロジェクト」、「オプション」の順にクリックします。

2. 「テスト・オプション」タブで、目的のオプションを選択します。


目的操作永続性

取得行数を制限する「返す最大行数を制限」チェック・ボックスを選択し、必要な行数を入力します。

この設定では、ディメンション、クエリー・サブジェクト、およびクエリー・セットのテスト時のデータ取得のパフォーマンスは改善されません。

この設定は、モデル内のすべてのディメンション、クエリー・サブジェクト、クエリー・セットに適用されます。

この設定は保存され、任意のプロジェクトとの次のセッションで使用されます。

詳細度を指定する「クエリー情報で示される情報のレベル (Level ofInformation shown inQuery Information)」スライダーを、必要な詳細量を表す場所までドラッグします。

この設定は保存され、このプロジェクトとの次のセッションで使用されます。

関連するデザイン・モード・フィルターを適用する

「テスト時にすべての関連したデザイン・モード・フィルターを適用」チェック・ボックスを選択します。

これは、別のディメンション、クエリー・サブジェクト、またはクエリー・セット内の、使用方法がデザイン・モードに設定されたすべての関連フィルターに適用されます。

この設定は保存され、任意のプロジェクトとの次のセッションで使用されます。

3. プロジェクトを自動的に保存する場合は、「自動保存」タブで、「オン」を選択し、プロジェクトを自動的に保存する頻度を表す数値 (分単位) を入力します。


オブジェクトの並べ替えデフォルトで、「プロジェクト・ビューアー」にリストされるルート・ネームスペース・オブジェクトは、追加された順序で表示されます。オブジェクトの順序はその名前に基づいて変更することができます。オブジェクトは昇順または降順に並べ替えることができます。

並べ替えるオブジェクトを選択する際、すべての選択項目がメタデータ・ツリーで同じレベルになければなりません。ただし、並べ替えることができるのは、1 つのレベルのいくつかのオブジェクトだけです。選択されなかったオブジェクトに対する、並び替えられるオブジェクトの位置は、並び替えリストの最初のオブジェクトの位置を基点とします。例えば、オブジェクトを昇順で並び替える際、名前の頭文字が "A" に最も近いオブジェクトが「プロジェクト・ビューアー」でその現行位置に残り、選択した他のオブジェクトそれに続きます。


選択したオブジェクトを並べ替える際、子を含めることができます。例えば、西部の小売業者、東部の小売業者という 2 つのクエリー・サブジェクトが 1 つのレベルで表示されるとします。各クエリー・サブジェクトは子を持ちます。それらは親の 1 つ下のレベルに表示されます。西部の小売業者と東部の小売業者を並び替えるときに、その子を含める場合、東部の小売業者と西部の小売業者が 1 つのレベルで「プロジェクト・ビューアー」にリストされます。各クエリー・サブジェクトの子はその親の下でグループ化され、昇順でリストされます。

子オブジェクトの子孫を含めることもできます。選択したオブジェクトのタイプと数によっては、より多くの時間がオブジェクトの並べ替えに必要になる場合があります。

階層の読み取り専用オブジェクトまたはレベルが選択項目に含まれる場合、IBMCognos Framework Manager で、それらのオブジェクトを並べ替えることができないことを示すメッセージが表示されます。

手順1. 「プロジェクト・ビューアー」で、並べ替えるルート・ネームスペース・オブジ

ェクトを選択します。

選択したオブジェクトが同じレベルにあることを確認してください。

「エクスプローラー」タブまたは「ダイアグラム」タブでオブジェクトを選択することもできます。

2. 「ツール」、「並べ替え」の順にクリックします。

3. 名前によってオブジェクトを昇順で並べ替えるか、降順で並び替えるかをクリックします。

4. 選択したオブジェクトだけを並び替えるか、選択したオブジェクトとその子を並べ替えるかを選択します。

選択したオブジェクトの子を並び替える場合、子オブジェクトの子孫すべてを含めることもできます。


「エクスプローラー」タブ「エクスプローラー」タブは、一般のファイル・システムと似た方法でプロジェクトの内容を示します。オブジェクトを名前、クラス、または説明に基づいて配置します。

プロジェクト内に多数のオブジェクトがある場合、「エクスプローラー」タブを使用してそれらをより簡単に見つけることができます。

「エクスプローラー」タブを使用して、オブジェクトおよび関係を表示、作成、変更できます。フォルダーおよびネームスペースを作成して、複数のオブジェクトをグループ化することもできます。


「ダイアグラム」タブ「ダイアグラム」タブを使用して、プロジェクト内のオブジェクト間の関係を表示します。オブジェクト間の関係は線で示されます (カーディナリティー表記)。オブジェクトおよびネームスペースを展開することにより、オブジェクト階層やオブジェクト間の関係を表示できます。

ヒント: ダイアグラムに表示されるモデル領域を制御することもできます。右下隅の「概要」ボタンをクリックアンドホールドし、ポインターをダイアグラム上にドラ

ッグします。

「ダイアグラム」タブでは、以下のいずれかの操作を行えます。

v オブジェクトおよび関係を表示、作成、変更する。

v フォルダーおよびネームスペースを作成してオブジェクトをグループ化する。

v ダイアグラムの設定を変更する。

v オブジェクトのレイアウトをスター型レイアウトまたは標準レイアウトのどちらかに変更する (「ダイアグラム」、「自動レイアウト」をクリック)。

v オブジェクトに焦点を合わせる (「ダイアグラム」、「フォーカル・ポイントを設定」をクリック)。

v オブジェクトを見つける (「プロジェクト・ビューアー」でオブジェクトを右クリックし、「ダイアグラムで見つける (Locate in Diagram)」をクリック)。

v ズームインまたはズームアウトする (「ダイアグラム」、「ズーム」をクリック)。

v 「ダイアグラム」メニューのすべてのオブジェクトを展開または省略する。

v 印刷用にダイアグラムを保存する (「ダイアグラム」、「スクリーン・キャプチャー」をクリックし、ピクチャーの名前を指定)。

v 「コンテキスト・エクスプローラー」を起動する (「ダイアグラム」タブでオブジェクトを右クリックし、「コンテキスト・エクスプローラーを起動」をクリック)。

v 「コンテキスト・エクスプローラー」でダイアグラムを印刷する (「コンテキスト・エクスプローラー」背景を右クリックし、「印刷」をクリック)。「印刷」ボタンは、「コンテキスト・エクスプローラー」ツールバーから使用することもできます。この右クリック・メニューには、「印刷プレビュー」を使用してダイアグラムをプレビューするためのコマンドや、「ページ設定」を使用してページ・レイアウト・オプションを変更するためのコマンドも含まれています。

ダイアグラムの設定の変更ダイアグラムの 1 つ以上の設定を変更できます。「ダイアグラムの設定」タブで、メインダイアグラムの設定を定義します。「コンテキスト・エクスプローラー」タブで、コンテキスト・ダイアグラムの内容の取り込み方と表示方法を定義します。

手順

1. 「ダイアグラム」、「ダイアグラムの設定」の順にクリックします。

2. 詳細度を設定します。


クエリー・アイテム、関係、範囲の関係、カーディナリティー、説明を選択できます。

3. 表記のタイプを選択します。

Merise 表記または Crowsfeet 表記を使用できます。デフォルトでは、IBMCognos Framework Manager は Merise 表記を使用します。Merise 表記では、関係の各端に、その端の最小カーディナリティーと最大カーディナリティーがマークされます。 Crowsfeet 表記を使用することもできます。この表記では、関係が図示されます。

4. オブジェクトをより簡単に位置合わせするには、「スナップ・オプション」をオンにします。

5. 背景を等間隔の線の網目にするには、「グリッドを表示」チェック・ボックスを選択します。

6. テキストのフォントと色を選択します。

7. これらの設定をすべての新規プロジェクトのデフォルトにするかどうかを選択します。


「ディメンション・マップ」タブ「ディメンション・マップ」タブを使用して、「プロジェクト・ビューアー」で選択したディメンションの階層とレベルを表示、作成、変更できます。範囲の関係を表示および変更することもできます。

「ディメンション・マップ」タブをクリックすると、「数値データ」タブと「属性」タブが表示されます。「数値データ」タブは、モデルで使用できるすべての数値データおよび範囲の関係を表示または変更する場合に使用します。「属性」タブは、選択したクエリー・アイテムの役割を表示または変更する場合に使用します。

クエリー・アイテムに計算を組み込むこともできます。

ヒント: SAP BW メタデータを表示する最善の方法は、スター型レイアウトです。「ダイアグラム」メニューから、「ダイアグラムの自動レイアウト (Auto LayoutDiagram)」、「星形」をクリックします。

「プロパティー」ウィンドウ「プロパティー」ウィンドウは、プロジェクト・ビューアー、「エクスプローラー」タブ、「ダイアグラム」タブ、「ディメンション・マップ」タブ、「従属関係」タブ、「検索」ウィンドウ、または「集計」ウィンドウで、最後に選択したオブジェクトのプロパティーを示します。オブジェクト・プロパティーはインポートの際に設定され、いくつかのプロパティー値はモデル作成の際に変更できます。「プロパティー」ウィンドウを使用して、オブジェクトのプロパティーを追加、変更、または削除できます。

複数のオブジェクトのプロパティーを同時に変更することもできます。複数のオブジェクトを選択した場合、IBM Cognos Framework Manager には、すべてのオブジェクトに共通のプロパティーだけが表示されます。次の操作を実行できます。

v プロパティー見出しをダブルクリックして、プロパティー値をソートします。


値がソートされる方向を示す矢印が表示されます。昇順と降順との間で切り替えることができます。

v プロパティー見出しの右にある矢印をクリックして、プロパティー値にフィルターを掛けます。

値をクリックするか、または「カスタム」をクリックして、表示する行の基準を定義できます。

v プロパティーの隣にある矢印をクリックして、強調表示された領域をその値を適用するプロパティーにドラッグすることにより、プロパティー値を複数のオブジェクトに適用します。

v 「プロパティー」ウィンドウでオブジェクト名を右クリックすることにより、行と列の幅をサイズ変更します。

さらに表示の余地を確保する必要があれば、「プロパティー」ウィンドウのサイズを変更するか、またはそれを移動してウィンドウ内でフロート表示させます。例えば、複数のモニターがある場合、「プロパティー」ウィンドウを別のモニターに移動できます。

複数のプロパティー値の置換各テキスト文字列プロパティーの複数の値を置換することができます。

複数のプロパティー値を置換する際、置換した値に依存するエレメントが IBMCognos Framework Manager によって自動的に更新されます。従属関係 (データ・ソースおよびパラメーター・マップの名前など) を更新できない場合、モデルを手動で検証する必要があります。

プロパティー値全体をマッチングすることも、値の一部をマッチングすることもできます。プロパティー値の一部とマッチングすることで、単一テキスト・プロパティーに対して複数の置換を実行することができます。例えば、"nation" を検索してそれを "region" に置換する場合、プロパティー値 "This nation and that nation"は "This region and that region" に置換されます。ただし、"national" は"regional" に置換されます。

ヒント: プロパティー値を置換する前に、「プロパティー」ウィンドウを大きくして、置換する値が含まれるプロパティーの列を広げてください。

手順

1. 「プロジェクト・ビューアー」ウィンドウで、複数のオブジェクトを選択します。

ヒント: 置換を実行する前に検索するプロパティーのセットを減らすには、最初にプロパティーをフィルターに掛けます。「プロパティー」タブで、フィルターに掛ける列見出しを右クリックし、「自動フィルターの設定」をクリックします。

2. 次のいずれかを選択します。

v モデルに複数の言語が含まれている場合、「言語」タブをクリックします。

v モデルに含まれている言語が 1 つだけの場合、「プロパティー」タブをクリックします。


3. 置換する値が含まれているプロパティーの列見出しを右クリックし、「一括置換」をクリックします。

4. 「検索対象」および「置換対象」ボックスに、検索テキスト文字列と置換テキスト文字列を入力します。

ヒント: 空のプロパティーを置換する場合、「検索対象」ボックスをブランクのままにします。

5. 大文字と小文字の区別をする検索を実行するには、「大文字と小文字を区別」チェック・ボックスをオンにします。

6. 完全プロパティー・テキストを検索するには、「セル・コンテンツ全体を照合」チェック・ボックスをオンにします。

ヒント: 含まれているテキストに関係なくすべてのプロパティー・フィールドを置換するには、「検索対象」ボックスにアスタリスクを 1 つ入力し、「セル・コンテンツ全体を照合」チェック・ボックスをオンにします。

7. 以下の 1 つ以上を実行します。

v 「置換」をクリックして現在選択されているオブジェクトを置換し、次の一致を検索します。

v 「次へ」をクリックして、次の一致するオブジェクトを選択します。

v 「すべて置換」をクリックして、一致するすべてのプロパティー (リストの最初の一致するプロパティーから始まる) を置換します。

v 置換が終了したら、「閉じる」をクリックします。

プロパティーに対して変更が加えられると、タブに結果が表示されます。

一括置換がリストの最後のオブジェクトに達すると、置換された数を示すメッセージが表示されます。

「ツール」ウィンドウ「ツール」ウィンドウには、「要約」タブ、「検索」タブ、および「従属関係」タブがあります。

「ツール」ウィンドウを別個のウィンドウに変えることができます。この変更を行うには、ウィンドウのタイトル・バーをクリックし、ウィンドウのアウトラインが太線になるまで任意の方向にドラッグします。これで、「ツール」ウィンドウをデスクトップ上の任意の場所にドラッグできるようになります。このウィンドウをIBM Cognos Framework Manager ウィンドウ内のウィンドウに再び変えるには、ウィンドウのアウトラインが細線になるまで Framework Manager のいずれかの枠に向かってドラッグします。

「要約」タブ「要約」タブには、「プロジェクト・ビューアー」内の選択したオブジェクトに使用できる言語、統計、タスクが表示されます。

「プロジェクト」セクションには、設計言語とアクティブな言語が表示されます。アクティブな言語を変更することができます。


「統計情報」セクションには、現在選択しているオブジェクトにあるオブジェクトの数がクラス別に表示されます。選択したオブジェクトにフォルダーが含まれる場合は、フォルダーのコンテンツ数が計数に含まれます。選択対象オブジェクトとして、プロジェクト、ネームスペース、およびフォルダーがあります。デフォルトの選択対象オブジェクトは、プロジェクトです。

「タスク」セクションには、現在選択されているオブジェクトに適用できる操作が、オブジェクト・クラスに基づいて表示されます。フォルダーを選択した場合は、フォルダーに対する操作がリストされます。そのフォルダー内のオブジェクトを選択した場合は、オブジェクトとフォルダーの両方に対する操作がリストに含まれます。

オブジェクト・クラスの詳細については、c10 場所¥templates¥bmt¥CR1Model¥BMTModelSpecification.xsd ファイルを参照してください。

「検索」タブの使用大きなプロジェクトに対して作業を行う際、タスクを完了するために必要なオブジェクトが見つけにくい場合があります。「検索」タブを使用して、さまざまな検索基準 (場所、クラス、条件、またはプロパティーなど) を適用することにより、オブジェクトを素早く見つけることができます。

始める前に

モデルに複数の言語が含まれている場合、オブジェクトを検索する前に「言語を定義」ダイアログ・ボックスで「アクティブな言語」値を指定してください。

手順

1. 「ツール」、「検索」の順にクリックします。

ヒント:

v 「ツール」ウィンドウが表示されない場合、「表示」、「ツール」をクリックします。「ツール」ウィンドウを「Framework Manager」ウィンドウの下部にドラッグし、検索結果が見やすくなるようにサイズ変更してください。

v 検索プロパティーのセットを減らすには、最初にプロパティーをフィルターに掛けます。「プロパティー」タブで、フィルターに掛ける列見出しを右クリックし、「自動フィルターの設定」をクリックします。

2. 「検索文字列」ボックスに、検索するテキストを入力します。

大文字、小文字、または大/小文字混合の文字列を使用できます。検索で大/小文字の区別はありません。有効なワイルドカード文字は "*" と "?" です。

3. 二重下矢印ボタンをクリックして、検索基準ボックスを表示します。

4. 「条件」リストで、検索文字列に適用する条件を選択します。


「検索文字列」値をモデルのテキストとマッチングする方法が「条件」ボックスで決定されます。これには、選択可能な検索条件のリストが含まれています。ワイルドカード文字を使って検索を行う場合、「に等しい値」条件を使用します。

正規表現は複雑ですが、テキスト文字列のマッチングを行うための強力な方法です。正規表現を使って検索を行うには、「正規表現」条件を使用します。正規表現の検索では大/小文字の区別があります。例えば、"Car" という単語を含むすべてのオブジェクトを検索する場合、文字列 "¥Car" (引用符は付けない)を検索します。

「条件」ボックスの値は、セッション別に保存されます。

5. 「検索範囲」リストで、検索するモデル階層の一部を選択します。

「検索範囲」ボックスの値は、セッション別に保存されます。

6. 「クラス」リストで、検索する単一のオブジェクト・クラスを選択します。

7. 「プロパティー」リストで、検索するプロパティーのタイプを選択します。

「(すべてのプロパティー)」プロパティーは、すべてのプロパティーを検索します。「オブジェクト名」プロパティーは、検索を各オブジェクトの名前に制限します。「テキストのプロパティー」プロパティーは、テキスト文字列を含むプロパティーのセット (「説明」や「画面のヒント」など) を検索します。ただし、オブジェクト名は含まれません。

「プロパティー」ボックスの値は、セッション別に保存されます。

8. 「検索」をクリックします。

「検索」タブの下部に結果がリストされます。検索結果には、単一オブジェクトに関する複数の値が含まれる場合があります (テキスト・プロパティーなど)。複数の値を持つオブジェクトをクリックすると、そのオブジェクトに属するすべての値が選択されます。モデルに複数の言語が含まれている場合、モデル内の各言語のプロパティーが検索結果に含まれます。

一度検索を行った後、「サブセット」チェック・ボックスをオンにできるようになります。「サブセット」チェック・ボックスをオンにする場合、次の検索が既存の検索結果に対して行われます。各検索が終了すると、「サブセット」チェック・ボックスはオフになります。「サブセット」チェック・ボックスをオンにすることで、連続のサブセット検索を行えます。

9. 「プロジェクト・ビューアー」でオブジェクトを表示するには、「検索」タブのオブジェクトをクリックします。

10. ダイアグラムでオブジェクトを表示するには、「検索」タブのオブジェクトを右クリックし、「ダイアグラムで検索 (Locate in Diagram)」をクリックします。

タスクの結果

「検索」タブの「一括置換」ボタンを使用すると、検索結果のオブジェクトのセットに対して検索操作と置換操作を行えます。「一括置換」ボタンをクリックする


と、「プロパティー」タブに結果セットが表示され、「一括置換」ダイアログが表示されます。そのダイアログでプロパティーを選択して、検索操作と置換操作を適用することができます。

「プロパティー」ウィンドウから一括置換を開始することもできます。詳細については、 19 ページの『複数のプロパティー値の置換』を参照してください。

「従属関係」タブ「従属関係」タブには、選択したオブジェクトに従属するオブジェクトが表示されます。

プロジェクト内のオブジェクトの命名規則プロジェクト内のすべてのオブジェクトには、一意の識別子が必要です。参照は、オブジェクトのタイプに応じて、1 つ以上のパートから構成されます。それらのパートには、プロジェクトのデフォルト言語で表現された、オブジェクト名とプロジェクト階層内の場所とが含まれます。

注: 2 つのディメンションまたはクエリー・サブジェクトがプロジェクト内で同じ名前を持つためには、それらが異なるネームスペース内になければなりません。

1 パートの ID

プロジェクト内のいくつかのオブジェクトには、1 パートの ID があります。 1 パートの ID は、ネームスペースに他のネームスペースが含まれる場合でも、プロジェクト全体で一意でなければなりません。以下のオブジェクトには 1 パートの IDがあります。

v ネームスペース

v 関数

v ネームスペースへのショートカット

v フォルダーへのショートカット

2 パートの ID

プロジェクト内のいくつかのオブジェクトには、それを含むネームスペースの名前とオブジェクトの名前とで構成される、2 パートの ID があります。オブジェクト名は、それを含むネームスペース内で一意でなければなりません。以下のオブジェクトには 2 パートの ID があります。

v 標準ディメンション

v 数値データ・ディメンション

v クエリー・サブジェクト

v クエリー・サブジェクトへのショートカット

例えば、go_sales ネームスペースに「Product」という名前のクエリー・サブジェクトが含まれるとします。「Product」クエリー・サブジェクトには次の名前があります。ここで、大括弧とピリオドは、Framework Manager がオブジェクト ID のために使用する構文です。

[go_sales].[Product]


3 パートの ID

プロジェクト内のいくつかのオブジェクトには、それを含むクエリー・サブジェクトの ID に基づく、3 パートの ID があります。各名前は、それを含むクエリー・サブジェクト内で一意でなければなりません。以下のオブジェクトには 3 パートのID があります。

v 階層

v 数値データ

v クエリー・アイテム

例えば、go_sales ネームスペースに「Product」という名前のクエリー・サブジェクト、および「Product Code」という名前のクエリー・アイテムが含まれるとします。「Product Code」クエリー・アイテムには次の名前があります。ここで、大括弧とピリオドは、IBM Cognos Framework Manager がオブジェクト ID のために使用する構文です。

[go_sales].[Product].[Product Code]

4 パートの ID

プロジェクト内のレベルには、ネームスペース名、ディメンション名、階層名、およびレベル名から構成される、4 パートの ID があります。

例えば、go_data_warehouse ネームスペースに「Account」という名前のディメンションが含まれるとします。「Account」内の階層は「Balance sheet」で、これには「Account」という名前のレベルが含まれます。「Account」レベルには次の名前があります。ここで、大括弧とピリオドは、Framework Manager がオブジェクトID のために使用する構文です。

[go_data_warehouse].[Account dimension].[Balance sheet].[Account]

5 パートの ID

プロジェクト内のいくつかのオブジェクトには、ネームスペース名、ディメンション名、階層名、レベル名、およびクエリー・アイテム名から構成される、5 パートの ID があります。 5 パートの ID は、メンバー内で一意な名前の中でキャプションおよびビジネス・キーとしても使用されます。詳細については、 125 ページの『メンバー内で一意な名前』を参照してください。

例えば、go_data_warehouse ネームスペースに「Account」という名前のディメンションが含まれるとします。「Account」内の階層は「Balance sheet」で、これには「Account」という名前のレベルが含まれます。「Account」レベルには、「Account name」という名前のクエリー・アイテムが含まれます。「Accountname」クエリー・アイテムには次の名前があります。ここで、大括弧とピリオドは、Framework Manager がオブジェクト ID のために使用する構文です。

[go_data_warehouse].[Account dimension].[Balance sheet].[Account].[Accountname]


サンプル・モデル検討用にいくつかのサンプル・モデルが IBM Cognos Framework Manager に備わっています。サンプル・モデルは、メタデータのモデル作成のガイドラインを使用して作成されています。

各サンプル・モデルで、クエリー・アイテムにはデフォルトの表示形式が定義されています。名前および説明は多くの異なる言語に翻訳されています。Language_lookup パラメーター・マップの使用により、各ユーザーにはその優先言語によるフォルダー名とアイテム名および説明が自動的に表示されます。

サンプルのレポートおよびパッケージについて詳しくは、「Reporting ユーザー・ガイド」を参照してください。

Great Outdoors ウェアハウス・モデルこのモデルには、Great Outdoors という架空の企業の財務情報と人事情報が格納されています。このモデルでは、ディメンション・リレーショナル・データ・ソースへのアクセスが行われます。

このサンプル・モデルは、c10 場所¥webcontent¥samples¥models¥great_outdoors_warehouse にあります。

サンプル・モデルには、以下のビューが含まれます。

v データベース・ビュー

データ・ソースからインポートされたオブジェクトが含まれます。これらのオブジェクトはビジネス分野ごとにネームスペースにグループ化され、すべてのビジネス分野に共通のテーブルは GO というネームスペースにグループ化されています。

さらに、モデル・クエリー・サブジェクト、ショートカット、フィルターがネームスペースに編成されています。ネームスペースは、ユーザーにはフォルダーとして表示されます。このように情報を関連ビジネス・カテゴリーに編成することで、ユーザーは必要とする情報を見つけやすくなります。

すべての結合と行列式が、このビューで定義されます。

行列式を必要とするユーザーと検索テーブルのために、モデル・クエリー・サブジェクトがいくつか追加されています。

v ビジネス・ビュー

ビジネスまたはアプリケーションのニーズ面のデータを表すモデル・クエリー・サブジェクトが含まれます。

言語用を含め、計算がこのビューで定義されます。

このビューはモデル移植性を高め、計算を直接データ・ソース・クエリー・サブジェクトにするときに生じるメタデータ・クエリーを防止します。

v ディメンション・ビュー


Framework Manager で作成された標準ディメンション、数値データ・ディメンション、および範囲の関係が含まれます。

v 分析ビュー

分析 (ディメンション) パッケージ用 Studio/Authoring ツールで表示されるモデルの一部が含まれます。

ディメンション・ビューの標準ディメンションと数値データ・ディメンションへのショートカットはスター・スキーマでグループ化され、フォルダー内のモデルのルートにビジネス分野 1 つにつき 1 つ置かれます。これらには、名前の終わりに明確に「(分析)」のマークが付けられます。これらは別個のネームスペースに置かれません。そうすると、Studio/Authoring ツールでメタデータ・ツリーに別のレベルが追加されてしまうからです。

v クエリー・ビュー

クエリーおよびレポート作成パッケージ用 Studio/Authoring ツールで表示されるモデルの一部が含まれます。

ディメンション・ビューのモデル・クエリー・サブジェクトへのショートカットはスター・スキーマでグループ化され、フォルダーにビジネス分野 1 つにつき1 つ置かれます。これらには、モデルのルートで名前の終わりに明確に「(クエリー)」のマークが付けられます。

さらに、サンプル・モデルにはパッケージがあります。1 つは分析用、1 つはクエリーおよびレポート作成用です。 IBM Cognos Analysis Studio でクエリーおよびレポート作成パッケージを使用することはできません。

Great Outdoors 販売モデルこのモデルには、Great Outdoors という架空の企業の販売分析情報が格納されています。このモデルでは、トランザクション・システムへのアクセスが行われます。

このサンプル・モデルは、c10 場所¥webcontent¥samples¥models¥great_outdoors_sales にあります。

サンプル・モデルには、以下のビューが含まれます。

v データベース・ビュー

データ・ソースからインポートされたクエリー・サブジェクトが含まれます。これはトランザクション・データ・ソースであるため、ファクト表のほとんどはキーがありません。マルチパート・キーを使用している場合もあれば、キーの計算と未確定カーディナリティーの解決のためにモデル・クエリー・サブジェクトが追加されている場合もあります。

すべての結合と行列式が、このビューで定義されます。

v ビジネス・ビュー

ビジネスまたはアプリケーションのニーズ面のデータを表すモデル・クエリー・サブジェクトと参照ショートカットが含まれます。言語用を含め、計算がこのビューで定義されます。


v ディメンション・ビュー

標準ディメンション、数値データ・ディメンション、および範囲の関係が含まれます。ディメンションは、ビジネス・ビューのモデル・クエリー・サブジェクトに基づきます。

このビューは、必要に応じてクエリー・サブジェクトの名前が変更される場所でもあります。

v 分析ビュー

分析 (ディメンション) パッケージ用 Studio/Authoring ツールで表示されるモデルの一部が含まれます。

ディメンション・ビューの標準ディメンションと数値データ・ディメンションへのショートカットはスター・スキーマでグループ化され、フォルダー内のモデルのルートにビジネス分野 1 つにつき 1 つ置かれます。これらには、名前の終わりに明確に「(分析)」のマークが付けられます。これらは別個のネームスペースに置かれません。そうすると、Studio/Authoring ツールでメタデータ・ツリーに別のレベルが追加されてしまうからです。

v クエリー・ビュー

クエリーおよびレポート作成パッケージ用 Studio/Authoring ツールで表示されるモデルの一部が含まれます。

ディメンション・ビューのモデル・クエリー・サブジェクトへのショートカットはスター・スキーマでグループ化され、フォルダーにビジネス分野 1 つにつき1 つ置かれます。これらには、モデルのルートで名前の終わりに明確に「(クエリー)」のマークが付けられます。

さらに、サンプル・モデルにはパッケージがあります。1 つは分析用、1 つはクエリーおよびレポート作成用です。 IBM Cognos Analysis Studio でクエリーおよびレポート作成パッケージを使用することはできません。


第 3 章 Model Design Accelerator

Model Design Accelerator は IBM Cognos Framework Manager を拡張したものです。これを使用することで、リレーショナル・スター・スキーマ・モデルを簡単に作成することができます。これは、実証済みのモデル作成プラクティスに従う単一ファクト表リレーショナル・スター・スキーマをモデル作成者が作成する上で役立ちます。幅広い経験を持っていない、また訓練を受けていない初心者のモデル作成者でも、モデルを作成することができます。経験のあるモデル作成者であれば、モデル作成にかかる時間全体を短縮することができます。 Model DesignAccelerator は、各設計手順を評価し、潜在的な問題点を識別し、ユーザーがそれを解決するのを支援します。

モデルの設計を開始する前に、解決を試みるレポート作成の問題について、またその解決にどのようなデータを使用できるかについて理解しておく必要があります。

Model Design Accelerator を開始するには、次の操作を実行します。

v プロジェクトを作成し、データ・ソースを選択します。

v Model Design Accelerator のユーザー・インターフェースを検討します。

v スター・スキーマ・モデルを作成します。

v スター・スキーマ・モデルを管理する方法を検討します。

Model Design Accelerator には、モデルの作成に役立ついくつかのビューおよびダイアログ・ボックスが備えられています。

v エクスプローラー・ツリー

v エクスプローラー・ダイアグラム

v Model Accelerator

v クエリー・サブジェクト・ダイアグラム

v 関係編集モード

v モデル警告

v オプション

各ビューのポップアップ・メニューにアクセスするには、ビューで右クリックします。「オプション」ダイアログ・ボックスは、どのポップアップ・メニューからでも使用できます使用できます。

エクスプローラー・ツリーエクスプローラー・ツリーを使用して、「メタデータ」ウィザードの使用により選択したオブジェクトを表示します。データ・ソース・オブジェクトは、他のファイル・システムと類似した階層ビューで表示されます。

データ・ソースのグラフィカル・ビューを表示するには、エクスプローラー・ダイアグラムを使用します。データ・ソースに多数のオブジェクトが含まれる場合は、エクスプローラー・ツリーを使用してオブジェクトを見つける方が簡単です。


エクスプローラー・ツリーは、以下のアイコンを使用してオブジェクトを表します。


プロジェクト

データ・ソース内の表

データ・ソース内の列

列のデータ型のプロパティーは、それを数値データとして識別します。


列のプロパティーは、それをキーとして識別します。


列のプロパティーは、それを数値データとしてもキーとしても識別しません。

データ・ソース

エクスプローラー・ダイアグラムエクスプローラー・ダイアグラムは、データ・ソース・メタデータのグラフィカル・ビューを表示します。エクスプローラー・ダイアグラムを使用して、メタデータを検討し、オブジェクト間の関係を確認します。

エクスプローラー・ダイアグラムにアクセスするには、エクスプローラー・ツリーで 1 つ以上のオブジェクトを選択します。その後、エクスプローラー・ツリーの上

にある「エクスプローラー・ダイアグラム」アイコン

をクリックします。

「エクスプローラー・ダイアグラム」ウィンドウでは、以下のことを行えます。

v オブジェクトおよび関係を表示する。

v オブジェクトのレイアウトをスター型レイアウトまたは標準のツリー型レイアウトに変更する。

v ファクトを含むいずれかの表に基づいて、初期スター・スキーマを作成する。

v ズームインまたはズームアウトする。

v ダイアグラムの設定を変更する。

エクスプローラー・ダイアグラムを使用する方法には次の 2 つがあります。エクスプローラー・ツリーで、関心のあるオブジェクトのサブセットを選択してエクスプローラー・ダイアグラムに追加できます。エクスプローラー・ツリーで、すべてのオブジェクトをエクスプローラー・ダイアグラムに追加することもできます。それから、関心あるオブジェクトを保持し、その他のオブジェクトを除去できます。「関連した表を表示」メニュー項目および「表を削除」メニュー項目を使用して、検討するオブジェクトだけのビューを作成します。ダイアグラムは、データ・ソース・メタデータの読み取り専用のビューです。表を追加または除去すると、単にダイアグラムが変更されます。データ・ソースは変更されません。


ダイアグラム・メニュー・オプションを使用して、他のオブジェクトへの関係を検討します。ダイアグラム・メニュー・オプションにアクセスするには、エクスプローラー・ダイアグラムでオブジェクトを選択して右クリックするか、またはツールバーを使用します。表を右クリックして、スター型またはツリー型のレイアウトでその表の周囲にダイアグラムを表示するオプションを選択します。アイコンを使用して、いくつかのダイアグラム・メニュー・オプションにアクセスすることもできます。

エクスプローラー・ダイアグラムで任意の 1 つの表を選択することにより、初期スター・スキーマを作成できます。その表を右クリックして、「この表からスター・スキーマを生成」を選択すると、完全なスター・スキーマ設計が作成されます。

連結ボタンをクリックして、エクスプローラー・ダイアグラムをワークスペースに連結できます。連結されたウィンドウで、画面を水平または垂直のどちらに分割するかをオプションで選択できます。

「オプション」ダイアログ・ボックスを使用して、デフォルトのダイアグラム設定をカスタマイズします。例えば、テーブルが多数の列を含んでいるかまたは長い名前を使用する場合、ダイアグラム内のデータが完全に表示されないことがあります。「全般」タブで最大表サイズのオプションを調整して、すべてのデータが表示されるようにしてください。「色」タブを使用して、ダイアグラム特性の識別に使用されるデフォルトの色を変更します。

Model Accelerator ワークスペースプロジェクトを作成した後に、Model Design Accelerator セッションでの作業を開始します。 Model Accelerator は、スター・スキーマの作成場所となるグラフィカル・ワークスペースです。

スター・スキーマを構築するには、レポートに含める数値データを使用してファクト・クエリー・サブジェクトを設計します。次に、モデル・クエリー・サブジェクトを構築してコンテキストを提供し、それらの数値データを記述します。クエリー・サブジェクトを結合する行は、関係が存在することを示します。クエリー・サブジェクト・ダイアグラムを使用して、選択したクエリー・サブジェクトの作成に使用されたデータ・ソース表を表示します。

Model Design Accelerator は、モデル作成の実証済みプラクティスを基準として各設計ステップを評価し、潜在的な問題点を識別および解決する作業を支援します。操作によって潜在的な問題が生じた場合、「モデル警告」ビューが表示されます。

スター・スキーマを完成させた後に、モデルを生成します。 Framework Managerでモデルを洗練できます。パッケージを作成して、モデルを IBM CognosAnalytics サーバーに公開し、Studio/Authoring ツールでのオーサリング・レポートを開始します。

クエリー・サブジェクト・ダイアグラムクエリー・サブジェクト・ダイアグラムを使用して、スター・スキーマの作成に使用されたデータ・ソース・テーブルを表示します。これらの表は、生成されたモデルの一部として Framework Manager にインポートされます。クエリー・サブジェ

第 3 章 Model Design Accelerator 31

クト・ダイアグラムにアクセスするには、Model Accelerator ワークスペース内のクエリー・サブジェクトをダブルクリックします。

「クエリー・サブジェクト・ダイアグラム」ウィンドウでは、以下のことを行えます。

v 選択したクエリー・サブジェクトの作成に使用されたデータ・ソース・テーブルを表示する。

v 関係編集モードを使用して、関係を作成、変更、削除、またはオーバーライドする。

v オプション・ダイアログを使用して、ダイアグラムの設定を変更する。

「オプション」ダイアログ・ボックスを使用して、デフォルトのダイアグラム設定をカスタマイズします。例えば、テーブルが多数の列を含んでいるかまたは長い名前を使用する場合、ダイアグラム内のデータが完全に表示されないことがあります。「オプション」ダイアログ・ボックスで最大テーブル・サイズのオプションを調整して、すべてのデータが表示されるようにしてください。別のオプションは、ダイアグラム特性の識別に使用されるデフォルトの色を制御します。

関係編集モードの使用「関係編集モード」を使用して、モデル結合を作成、変更、削除、またはオーバーライドします。

「関係編集モード」にアクセスする方法は 2 つあります。

v Model Design Accelerator が潜在的な問題を検出すると、「モデル警告」ウィンドウが表示されます。「モデル警告」ビューのオプション「テーブル間の結合を手動で設定し直します」は、「関係編集モード」の機能を有効にします。

v 「Model Accelerator」ワークスペースのクエリー・サブジェクトをダブルクリックして「クエリー・サブジェクト・ダイアグラム」にアクセスすることができます。そこで「関係作成モードに移行」をクリックします。

手順1. 結合する 2 つのテーブルを選択します。

2 つのテーブルの間に直接結合を作成できない場合、中間表を使用します。中間表を追加するには、テーブルを「エクスプローラー・ツリー」から「クエリー・サブジェクト・ダイアグラム」にドラッグします。その後、中間表を使ってテーブルをリンクすることにより、必要な結合を作成します。

ヒント: 中間表には破線のアウトラインがあります。

2. 「モデル関係を作成」アイコンをクリックします。

「関係を変更」ダイアログ・ボックスが表示されます。新しい結合線が表示されます。

3. 各テーブルから列を選択し、新規関係を作成します。

4. 該当する関係カーディナリティーを選択します。

5. 「OK」を 2 回クリックして、「Model Accelerator」ワークスペースに戻ります。


操作の結果として無効なモデルが生成される場合、「モデル警告」ビューが表示されます。

タスクの結果

「関係編集モード」で、結合する列を選択して、「モデル関係を作成」アイコンをクリックすることもできます。「関係を変更」ダイアログ・ボックスが表示され、選択された列の間の結合がそこに表示されます。

「モデル警告」ビュー「モデル警告」ビューは、Model Design Accelerator が潜在的な問題を検出したときに表示されます。有効なモデルの作成に役立つように、Model DesignAccelerator は各操作を評価します。「モデル警告」ビューは、問題の原因となった操作について説明し、適用可能な場合には、問題を修正するためのオプションを示します。

示されるオプションのいくつかは、それを選択して「OK」をクリックすると自動的に実行されます。その他のオプションでは、Model Design Accelerator 内またはFramework Manager に生成されたモデル内で手動の変更を行う必要があります。

Model Design Accelerator は操作の意図を判別できないこともあるので、ユーザーが手動で結合を作成して問題を解決しなければならないこともあります。「テーブル間の結合を手動で設定し直します」オプションが使用可能な場合、これは「モデル警告」ビューから関係編集モードの機能をアクティブにします。

「テーブル間の結合を手動で設定し直します」を選択すると、結合アイコンが「モデル警告」ビューの左上に表示されます。識別された問題を解決するために、必要に応じて手動の結合を作成できます。

詳細については、 32 ページの『関係編集モードの使用』を参照してください。

従属のモデル作成オプションが連続している場合は、「キャンセル」をクリックして最後の操作を取り消します。モデル作成オプションがない場合は、「キャンセル」をクリックして最後の操作を取り消してから、Model Accelerator ワークスペースに戻ります。

ダイアグラムの設定の変更「オプション」ダイアログ・ボックスを使用して、ダイアグラム・ビューの 1 つ以上の設定を変更することができます。 Model Design Accelerator には 3 つのダイアグラム・ビューがあります。「Model Accelerator」ワークスペース、「エクスプローラー・ダイアグラム」、「クエリー・サブジェクト・ダイアグラム」の 3 つです。

手順1. いずれかのダイアグラム・ビューで右クリックしてポップアップ・メニューにア

クセスします。「オプション」を選択し、「一般」タブをクリックします。

2. 関係を表す表記のタイプを選択します。


使用できる表記は、単純化された Crowsfeet、標準 Crowsfeet、または数値カーディナリティーのいずれかです。デフォルトで、Model Design Acceleratorは、関係を図形表記で表す単純化された Crowsfeet を使用します。

3. 「エクスプローラー・ダイアグラム」および「クエリー・サブジェクト・ダイアグラム」に対して最大テーブル・サイズを設定します。

4. 「Model Accelerator」ワークスペースに対して最大テーブル・サイズを設定します。

5. 各ツール・アイコンの横にテキスト記述を表示するかどうかを選択します。

6. 「Model Design Accelerator」を開始するたびに導入画面を表示するかどうかを選択します。

7. 「色」タブをクリックして、ダイアグラム・オブジェクトの色を変更します。

ダイアグラム・オブジェクトの各特性に対してデフォルトの色が割り当てられています。色を変更して表示をカスタマイズします。

「ビューの背景色」は、アクティブ・ウィンドウで行われる変更の結果として、スター・スキーマ設計が変更されることを示します。これにより、編集のために使用されるウィンドウと表示だけのために使用されるウィンドウを簡単に識別することができます。


プロジェクトの作成Model Design Accelerator では、プロジェクトのコンテキストに対して作業を行います。

手順1. IBM Cognos Framework Manager の「ようこそ」ページで、「Model

Design Accelerator を使用して新しいプロジェクトを作成」をクリックします。

Framework Manager を使用している場合、「ツール」メニューから「ModelDesign Accelerator を実行」を選択することができます。この場合、新規プロジェクトは作成されません。スター・スキーマがオープン・プロジェクトと関連付けられ、生成されるモデルがそのプロジェクトに追加されます。



4. 「OK」をクリックして、設計言語を選択します。

設計言語を変更することはできませんが、Framework Manager で他の言語を追加することはできます。

「メタデータ・ウィザード」が表示されます。

5. データ・ソースを選択する場合、「メタデータ・ウィザード」の指示に従います。

v データ・ソースを選択し、「次へ」をクリックします。


目的のデータ・ソースがリストされていない場合は、最初にそれを作成する必要があります。

インポートは、一度に 1 つのデータ・ソースからのみ行えます。複数のデータ・ソースからインポートする場合は、複数のインポートを実行する必要があります。

v 使用するオブジェクトのチェック・ボックスをオンにします。

オブジェクトは何個でも選択できます。選択したメタデータすべてをスター・スキーマの設計作業で使用することができます。モデルを生成する際に、モデルに必要なオブジェクトだけが Framework Manager にインポートされます。

v 「続行」をクリックして、Model Design Accelerator に入ります。

設計手順の概要を示す導入画面が表示される場合があります。導入画面を閉じて、Model Design Accelerator の使用を開始します。

6. データ・ソースから選択したオブジェクトを使用してスター・スキーマ・モデルを作成します。

7. 次のいずれかを実行します。

セッションの内容を保存して作業を続行するには、「保存」をクリックします。

セッションの内容を保存して Framework Manager に入るには、「閉じる」をクリックします。

スター・スキーマの設計に基づいてモデルを生成し、Framework Manager に入るには、「モデルを生成」をクリックします。

モデルを生成しない設計の保存とクローズは、何度でも行うことができます。詳細については、『スター・スキーマ』を参照してください。

スター・スキーマModel Design Accelerator を使用してスター・スキーマを作成することは、3 つのステップから成るプロセスです。

v レポート内に必要な数値データを持つファクト・クエリー・サブジェクトを構築します。

v 数値データにコンテキストを付与するための関連したクエリー・サブジェクトを構築します。

v モデルを生成します。

いつでもマウス・ポインターをオブジェクト上に移動して停止し、そのオブジェクトのプロパティーを表示できます。プロパティーには、データ・ソース内のオブジェクトの起源が示されています。「エクスプローラー・ダイアグラム」ビューには、アイテムがスター・スキーマで使用されるかどうかも表示されます。結合を右クリックして、「関係ダイアログ (Relationship Dialog)」を表示できます。

作業の際には設計を保存してください。 Model Design Accelerator を終了してから再びそこに戻るとき、保存したスター・スキーマの作業を再開できます。


注: Model Design Accelerator に再び戻ると、最後のワーク・セッションが開かれます。 Model Design Accelerator から別のプロジェクトを参照することはできません。

ファクト・クエリー・サブジェクトの構築

エクスプローラー・ツリーを使用して、データ・ソース内のテーブルおよび列を閲覧します。レポートに含める数値データを選択し、それらを Model Accelerator ワークスペース内のファクト・クエリー・サブジェクトに追加します。数値データは、データベース表またはビューの中の数値列のうち、グループ化または集計が可能なものです。数値データの例としては、「生産費用」や「数量」があります。Model Design Accelerator は、必要なキーを追跡してそれらをモデルの中に自動的に含めます。キーを追加するための要件はありません。レポート作成者に対して閲覧可能にするパッケージ内の数値データだけを選択します。

エクスプローラー・ツリー内の数値データを選択して、それらを ModelAccelerator ワークスペース内のファクト・クエリー・サブジェクトにドラッグします。エクスプローラー・ダイアグラムから選択を行うこともできます。

追加されるすべての数値データは、データ・ソース内の同じテーブルからのデータでなければなりません。複数のテーブルから数値データを追加したり、数値データではないクエリー・アイテムを追加したりしようとすると、「モデル警告」ダイアログ・ボックスが表示されます。これは、Model Design Accelerator が 1 つのファクト・テーブルのスター・スキーマ・モデルだけをサポートするためです。

関連するクエリー・サブジェクトの構築

エクスプローラー・ツリーからのオブジェクトを使用して、スター・スキーマ・モデル内のクエリー・サブジェクトを構築します。エクスプローラー・ツリーから列を選択して、それらを Model Accelerator ワークスペース内の適切なクエリー・サブジェクトに追加します。必要に応じて、ワークスペースにクエリー・サブジェクトまたは列を追加したり、そこから削除したりできます。

クエリー・サブジェクトの構築に役立つように、エクスプローラー・ダイアグラムを使用して、データ・ソースから選択したテーブルとビューのメタデータを調べます。クエリー・サブジェクトは、エクスプローラー・ビューまたはエクスプローラー・ダイアグラムから作成できます。

エクスプローラー・ダイアグラムでは、1 つのクエリー・サブジェクトを選択すること、または多数を選択してそれらの関係を表示させることができます。

モデルの生成

スター・スキーマが完成したとき、またはテストの準備ができたら、「モデルを生成」をクリックしてモデルを構築し、IBM Cognos Framework Manager を開始します。

結果として生成されたモデルに対して Model Advisor テストが適用されます。「モデル検証の結果」タブで、識別された問題を確認します。それぞれの問題につ


いての説明と、その問題から影響を受けるオブジェクトのリストが示されています。 Model Advisor について詳しくは、 207 ページの『モデルの分析』を参照してください。

作成したスター・スキーマ・モデルには、通常はデータ・ソースからのクエリー・アイテムのサブセットだけが含まれます。モデルを生成すると、スター・スキーマ・モデルをサポートするために必要なメタデータだけが Framework Manager にインポートされます。

モデルを生成するたびに、オープンした Framework Manager プロジェクトに新しいネームスペースが作成されます。物理ビューには、スター・スキーマ・モデルをサポートするためにインポートされたテーブルだけが含まれます。ビジネス・ビューには、クエリー・サブジェクトの作成時に選択した列だけを含むモデル・クエリー・サブジェクトが含まれます。これらは Model Design Accelerator 内に作成したオブジェクトです。プレゼンテーション・ビューには、ビジネス・ビュー内のモデル・クエリー・サブジェクトを参照するショートカットの集合が含まれます。

Framework Manager では、計算、フィルター、付加的な言語、およびディメンション構造を追加することにより、モデルを拡張できます。しかし、新しいモデルを生成するたびに新しいネームスペースが作成され、拡張はその新しいネームスペースに適用されません。

いつでも Model Design Accelerator に戻ってスター・スキーマを編集できます。Framework Manager 内のモデルを IBM Cognos Studio/Authoring ツールで使用するには、そのモデルを発行する必要があります。

スター・スキーマの管理スター・スキーマを設計する 1 つの方法は、スタンドアロン・モデルを作成することです。これを行うには、プロジェクトを作成し、Model Design Accelerator 内にスター・スキーマを構築し、モデルを生成して、そのモデルを IBM CognosFramework Manager プロジェクトに保存します。

スター・スキーマ・モデル設計は、モデルを生成することなく、何回でも保存して閉じることができます。モデルを生成した後には、「ツール」メニューの「ModelDesign Accelerator を実行」を選択して、Model Design Accelerator に戻ることができます。次のいずれかを実行できます。

v 現在のスター・スキーマ (存在する場合) を編集する。

v インポートされた同じデータ・ソース・メタデータを使用して、新しいスター・スキーマを作成する。

Model Design Accelerator メタデータは、プロジェクト・フォルダーのmda_metadata.xml ファイルに保存されます。 mda_metadata.xml ファイルを異なるプロジェクト・フォルダーにコピーすることにより、スター・スキーマを別のプロジェクトに移動できます。

モデルを生成するたびに、オープンした Framework Manager プロジェクトにネームスペースが作成されます。物理ビューには、スター・スキーマ・モデルをサポートするために必要だったテーブルだけが含まれます。ビジネス・ビューには、クエリー・サブジェクトの作成時に選択した列だけを含むモデル・クエリー・サブジェ


クトが含まれます。これらは Model Design Accelerator 内に作成したオブジェクトです。プレゼンテーション・ビューには、ビジネス・ビューに作成したモデル・クエリー・サブジェクトに対する一連のショートカットが含まれます。

生成される後続のモデルごとに、ネームスペースの新しいセットが FrameworkManager プロジェクトに作成されます。各ネームスペース名には、前のバージョンから区別するための番号が付加されます。例えば、最初のモデルには「PhysicalView」という名前のネームスペースが含まれるとします。 2 番目のモデルには、「Physical View1」が含まれます。

スター・スキーマ設計が完了したとき、結果として生じる Framework Manager 内のモデルを、計算、フィルター、付加的な言語、およびディメンション構造を追加して拡張できます。スター・スキーマを変更してモデルを再生成する場合、元の設計と拡張は上書きされません。


第 4 章データ・ソースからのメタデータのインポート

IBM Cognos Framework Manager でモデルを作成するには、メタデータをインポートする必要があります。

メタデータは、各種データ・ソースから (リレーショナル・データ・ソースとディメンション・データ・ソースの両方から) インポートすることができます。新規モデルにインポートすることも、既存のモデルにインポートすることもできます。インポートする前に、レポート作成要件を満たすデータおよびメタデータがデータ・ソースに含まれているかどうかを判別することが重要です。

データ・ソースモデルを作成し、メタデータをインポートするには、まずデータ・ソースを定義する必要があります。

IBM Cognos ソフトウェアは、さまざまなタイプのデータ・ソースをサポートしています。データ・ソース接続情報は、使用するデータ・ソースのタイプごとに異なる可能性があります。

Framework Manager モデルでは、カタログとスキーマはデータ・ソース・オブジェクトに関連付けられるプロパティーです。これらのプロパティーが存在する場合は、実行時に SQL ステートメントで生成されるオブジェクトを修飾します。

モデルのマップ対象のデータ・ソースを切り替えるときに、修飾レベルはしばしば削除されます。リレーショナル・データベース管理システム (RDBMS) は、受け取った SQL ステートメントを準備するときに、適切なネームスペース検索を適用します。ベンダーによっては、RDBMS はオブジェクトへの参照を解決するために、最大 2 つの場所で調べる場合があります。参照を解決できない場合は、エラーになります。

IBM Cognos Framework Manager は、RDBMS から渡されたテーブルと列の名前を保持します。これらの名前は、生成された Cognos SQL ステートメントに現れます。Cognos SQL では、大/小文字を保持するため、および特殊文字やキーワードとの競合を避けるために、名前に引用符を使用します。

IBM Cognos 認証を使用して、データ・ソースを保護することができます。IBMCognos 認証では、データ・ソース内でも定義されているセキュリティーが考慮されます。データ・ソース・サインオンを作成することにより、データベース・ログオン・プロセスをエンド・ユーザーから分離することができます。サインオンでは、データベースへのアクセスに必要なユーザー ID とパスワードが保管されます。データ・ソースを配布することもできます。

データ・ソース接続の詳細については、「IBM Cognos Analytics 管理およびセキュリティー・ガイド」を参照してください。


データ・ソースのセキュリティーIBM Cognos 認証またはデータ・ソース固有のセキュリティーを使用して、データ・ソースのセキュリティーを定義できます。データ・ソースに対する IBMCognos 認証を定義しても、データベース・ベンダー固有のセキュリティーをオーバーライドしません。

データ・ソースによっては、次のタイプの IBM Cognos 認証を 1 つ以上使用できます。

v 認証なし

IBM Cognos Analytics は、サインオン資格情報を提示せずにデータ・ソースにログオンします。

v IBM Cognos サービスの資格情報

IBM Cognos Analytics は、IBM Cognos サービスに対して指定されたログオンを使用して、データ・ソースにログオンします。ユーザーは個々のデータベースにサインオンする必要はありません。ただし、一般的に実働環境では、個々のデータベースでサインオンを行うほうが適切だといえます。

v 外部ネームスペース

IBM Cognos Analytics は、指定された外部認証ネームスペースへの認証に使用されるのと同じ資格情報で、データ・ソースにログオンします。指定されたネームスペースはアクティブでなければならず、ユーザーはデータ・ソースへのアクセスより前にそのネームスペースにログオンしていなければなりません。また、ネームスペース認証に使用される資格情報は、データ・ソース認証に関係のあるものでなければなりません。

すべてのデータ・ソースが、「すべてのユーザー」グループや、個々のユーザー、グループ、役割に対して定義されるデータ・ソース・サインオンもサポートしています。データ・ソースからデータ・ソース・サインオンが要求されたが、そのデータ・ソースのためのサインオンへのアクセス権がない場合は、データ・ソースにアクセスするたびにログオンのプロンプトが出されます。

IBM Cognos Analytics は、データ・ソースに対して定義されたセキュリティーも考慮します。例えば、IBM Cognos キューブの場合、セキュリティーはキューブ・レベルで設定できます。Microsoft Analysis Services データ・ソースの場合は、キューブの役割を使用してセキュリティーを設定できます。

ネイティブ・メタデータIBM Cognos は、OLAP データ・ソースおよびリレーショナル・データ・ソースをサポートします。ネイティブ・メタデータという用語は、OLAP データ・ソースに基づくモデル、パッケージ、クエリーなどのオブジェクトを指します。ネイティ

ブ・メタデータを含むネームスペースは、次のアイコン

を使用して、それが他のタイプのメタデータを含むネームスペースとは異なることを示します。

OLAP データ・ソースは、メタデータを豊富に含むデータ・ソースです。これらのデータ・ソースのための明示的なモデル作成は Framework Manager では無効であ


り、パッケージは直接ポータルに発行されます。詳細については、 296 ページの『OLAP データ・ソースに基づくパッケージの発行』を参照してください。

レベルは、ラベル内の世代名を使用して作成されます。レベルに名前を指定する方法を変更する場合、その変更はキューブを生成したアプリケーションでディメンション構築設定を変更することで行えます。詳しくは、ベンダーの資料を参照してください。

リレーショナル・データ・ソースでは、IBM Cognos Analysis Studio での作業を可能にするため、および他の Studio/Authoring ツールのドリル機能を使用可能にするために、ディメンションのモデル作成が必要です。ディメンションのモデル作成について詳しくは、 118 ページの『ディメンション』を参照してください。

IBM Cognos コンポーネントを UNIX サーバーにインストールした場合は、ファイル・ベースのデータ・ソースを UNIX サーバーに配置してください。このようにすると、/<サーバー名>/cubes/Great Outdoors Company.mdc のように UNIXパスを使用してファイルにアクセスできます。

複合パッケージには、OLAP およびリレーショナル・メタデータの両方が含まれます。

データ・ソース接続データ・ソース接続には、データベースの場所やタイムアウト期間など、データベースに接続するために必要なパラメーターを指定します。接続には、資格情報およびサインオンを含めることができます。

データ・ソース接続の詳細については、「IBM Cognos Analytics 管理およびセキュリティー・ガイド」を参照してください。特定のデータ・ソースに接続するためのパラメーターについては、ベンダー資料を参照してください。

複数のデータ・ソース接続

各データ・ソースには、データベースに対する 1 つ以上の物理接続を含めることができます。

データ・ソースの複数のデータ・ソース接続へのアクセス権がある場合は、IBMCognos Framework Manager プロジェクトを開くときに、データ・ソース接続を選択するようプロンプトが出されます。単一のデータ・ソースで複数のデータ・ソース接続を使用することにより、ある環境から別の環境への移行が容易になるとともに、プロジェクトの整合性を維持することができます。

例えば、複数のデータ・ソース接続を使用して、テスト・データ・ソースからのメタデータを扱うことができます。 GoSales データ・ソース接続を使用して、新規プロジェクトを作成します。プロジェクトに含めるオブジェクトを作成および変更し、意図したようにプロジェクトがモデル化されていることを確認するためのテストを行います。セッションを閉じて Framework Manager プロジェクトを再び開いた後、実動データ・ソース接続を選択することができます。パッケージを IBMCognos Analytics サーバーに発行した場合、ユーザーはレポートで使用するデータ・ソース接続を選択します。

第 4 章データ・ソースからのメタデータのインポート 41

同一データ・ソースへの複数の接続を IBM Cognos Administration で定義する必要があります。データ・ソースごとに複数の接続をサポートする場合は、データ・ソースのカタログ名とスキーマ名を明確にし、IBM Cognos Administration でデータベースごとに接続を作成します。

ヒント: 異種メタデータが含まれる複数のキューブを扱う場合は、キューブごとに別個のデータ・ソースを使用してください。 Studio/Authoring ツールで OLAP パッケージを展開するためには、両方のキューブの内部名が同じでなければなりません。複数の異なるデータ・ソース接続を使用する保存レポートを実行する場合は、キューブ名の他に、ディメンション名、階層名、レベル名、属性名も、両方のキューブで同じでなければなりません。単一データ・ソースをキューブごとの別個の接続で使用する場合は、すべてのキューブの内部名が同じでなければなりません。

分離レベル

分離レベルでは、データベースを変更するトランザクションをどのように扱うかが指定されます。デフォルトでは、デフォルト・オブジェクト・ゲートウェイが使用されます。データベースのタイプによっては、サポートされていない分離レベルもあります。分離レベルの名前は、データベースの製造元によって異なる場合があります。

レポートや分析で実行するクエリーでは、読み取り専用の処理が想定されています。クエリーは、トランザクションと呼ばれる作業単位でデータ・ソースに対して実行され、デフォルトの分離レベルまたは管理者が定義した分離レベルで実行されます。レポート作成者は、ストアード・プロシージャーを実行するクエリーによってプロシージャーの書き込みデータがコミットされることは想定しないようにする必要があります。環境によっては、データベースの機能のためにプロシージャーによる変更がコミットされる場合があります。Framework Manager で書き込み用のマークが付けられたストアード・プロシージャーでは、変更がコミットされますが、これを使用できるのは Event Studio のみです。

異なる分離レベルで実行する特定のクエリーが必要な場合は、異なるデータベース接続を定義する必要があります。

SAP BW などの OLAP データ・ソースについては、トランザクション作業単位は読み取り専用です。

次に、分離レベルを分離度の順番に示します。

v 非コミット読み取り

他のトランザクションによって行われた変更の内容を、ただちに別のトランザクションで使用できるようにします。

表 1. 非コミット読み取りのデータベース・タイプおよび相当する分離レベル

データベース・タイプ相当する分離レベル

Oracle 該当なし

Db2 非コミット読み取り

Microsoft SQL Server 非コミット読み取り

Sybase Adaptive Server Enterprise 非コミット読み取り


表 1. 非コミット読み取りのデータベース・タイプおよび相当する分離レベル (続き)


Informix® ダーティー・リード

v コミット読み取り

トランザクションによるアクセスを、他のトランザクションでコミットされた行に限定します。

表 2. コミット読み取りのデータベース・タイプおよび相当する分離レベル


Oracle コミット読み取り

Db2 カーソル固定

Microsoft SQL Server コミット読み取り

Sybase Adaptive Server Enterprise コミット読み取り

Informix コミット読み取り

v カーソル固定

トランザクションによる処理が行われている行を、別のトランザクションが更新できないようにします。

表 3. カーソル固定のデータベース・タイプおよび相当する分離レベル


Oracle 該当なし

Db2 該当なし

Microsoft SQL Server 該当なし

Sybase Adaptive Server Enterprise 該当なし

Informix カーソル固定

v 反復可能読み取り

トランザクションによって選択または更新されている行を、そのトランザクションが終了するまで、別のトランザクションで変更できないようにします。

表 4. 反復可能読み取りのデータベース・タイプおよび相当する分離レベル


Oracle 該当なし

Db2 読み取り固定

Microsoft SQL Server 反復可能読み取り

Sybase Adaptive Server Enterprise 反復可能読み取り

Informix 反復可能読み取り

v ファントム防止

トランザクション開始後に挿入または削除された行を、トランザクションのアクセスから保護します。


表 5. ファントム防止のデータベース・タイプおよび相当する分離レベル


Oracle 該当なし

Db2 該当なし

Microsoft SQL Server 該当なし

Sybase Adaptive Server Enterprise 該当なし

Informix 該当なし

v 直列化

並行処理された一連のトランザクションで、直列処理と同様の結果を生成します。

表 6. 直列化のデータベース・タイプおよび相当する分離レベル


Oracle 直列化

Db2 反復可能読み取り

Microsoft SQL Server 直列化

Sybase Adaptive Server Enterprise 直列化

Informix 該当なし

データ・ソース接続の作成データ・ソース接続では、データベースの場所やタイムアウトまでの時間など、データベースに接続するために必要なパラメーターが指定されます。これらのパラメーターによって、データ・ソースの接続文字列が形成されます。

データベースの認証情報は、サインオンを作成してデータ・ソース接続に組み込むことができます。認証情報は暗号化されサーバーに保存されるため、ユーザーは、接続を使用するたびにデータベース認証情報を入力する必要はありません。データ・ソースの作成時に作成されるサインオンは、"すべてのユーザー"グループが利用できます。このサインオンを利用できるユーザーは後で変更できます。また、新しいサインオンを作成してユーザーを追加することもできます。

管理者が、Framework Manager でモデルを作成する前に、必要なすべてのデータ・ソースを設定すれば、Framework Manager メタデータ・ウィザードですべての接続を利用できます。

始める前に

データ・ソースを保存するフォルダーと Cognos ネームスペースに対する書き込み権限が必要です。保護された特性である「データ・ソース接続」に対する実行権限も必要です。

このタスクについて

データ・ソースは Cognos ネームスペースに保存されます。データ・ソースには、一意の名前を付ける必要があります。例えば、データ・ソースとグループに同じ名


前は使用できません。既存のデータ・ソース接続を Framework Manager で編集することはできません。

手順1. インポート先のネームスペース、フォルダー、またはセグメントをクリックし

ます。

2. 「操作」、「メタデータ・ウィザードを実行」の順にクリックします。

3. 「メタデータ・ソースを選択」ウィンドウで、「データ・ソース」、「次へ」の順にクリックします。

4. 「データ・ソースを選択」ウィンドウで、「新規作成」をクリックします。

5. 「名前と説明を指定」ページに一意の接続名を入力し、必要に応じて説明や画面のヒントを入力し、「次へ」を選択します。

6. 接続ページの「タイプ」ドロップダウン・リストで、作成するデータ・ソースのタイプを選択します。

使用しているデータ・ソースがリストにない場合は、「その他のタイプ」を選択します。

7. 必要に応じて、データ・ソースの分離レベルを指定します。

8. 接続文字列を構成するすべてのパラメーターを入力し、その他の設定 (サインオンやタイムアウトなど) があれば、それも指定します。

9. 「接続をテスト」、「テスト」の順にクリックし、パラメーターが正しいかどうかを検査します。

プロンプトが出されたら、ユーザー ID とパスワードを入力するか、またはサインオンを選択して、「OK」をクリックします。「ユーザー DSN」へのODBC 接続をテストする場合、テストを正常に行うために DSN の作成者としてログオンする必要があります。

「ステータス」列で、接続が成功したかどうかを確認できます。成功しなかった場合は、「閉じる」を選択し、前の手順に戻って接続パラメーターを確認します。

10. 「JDBC 接続の設定」チェック・ボックスをオンにした場合は、データ・ソースに対する JDBC 接続情報を指定します。JDBC 接続情報は、手順 7 で入力した接続情報と同じデータベースに対して指定する必要があります。

「接続をテスト」をクリックして JDBC 接続情報を検証することもできます。

JDBC 接続情報が必要となるのは、「動的クエリー・モードの使用」オプションが有効化された状態でパッケージを Framework Manager から発行する場合です。

タスクの結果

Framework Manager で作成するデータ・ソース接続は IBMDB2® CognosAdministration、および新規管理インターフェースの「管理」 > 「データ・サーバー接続 (Data server connections)」でも使用できます。


次のタスク

「プロジェクト・ビューアー」の「データ・ソース」フォルダーからデータ・ソース接続をテストできます。データ・ソースを右クリックし、「テスト」をクリックします。

メタデータのインポートメタデータを新しいプロジェクトまたは既存のプロジェクトにインポートできます。メタデータのインポートは、プロジェクトを拡張するために何度でも実行できる操作です。また、モデルを Common Warehouse Metamodel (CWM) にエクスポートすることもできます。

IBM Cognos Framework Manager は、メタデータおよび外部データ・ソースからのデータを使用してプロジェクトを構築できます。

メタデータをインポートするには、必要なソースとその場所を指定する必要があります。インポートは、一度に 1 つのデータ・ソースからのみ行えます。複数のデータ・ソースからインポートする場合は、複数のインポートを実行する必要があります。

以下の場所からメタデータをインポートできます。

v Oracle、IBM DB2、Microsoft SQL Server などのリレーショナル・データベース

v SAP BW データ・ソース

v IBM Cognos のモデル

v Architect モデルおよび Impromptu カタログ

v IBM Cognos DecisionStream または Data Manager のモデル

v IBM メタデータ・ソース

v サード・パーティーのメタデータ・ソース

v データ・ソースとしての XML

データ・ソース接続を使った作業について詳しくは、 41 ページの『データ・ソース接続』を参照してください。

重複オブジェクト名

メタデータをインポートするとき、インポートで重複オブジェクト名をどのように処理するかを選択できます。そのオブジェクトをインポートしないか、またはインポートして一意の名前を作成するかのオプションがあります。それらの重複オブジェクトを除くすべてのオブジェクトをインポートする利点は、新しいデータベース・オブジェクトを、個別に指定したり同期処理をしたりすることなくプロジェクトに追加できることです。同じテーブル名のメタデータをインポートするには、2つのネームスペースを作成して、各テーブルを異なるネームスペースにインポートする必要があります。

SAP BW メタデータをインポートするとき、IBM Cognos Framework Managerは一意の名前を各オブジェクトに割り当てます。そのため、モデル内のオブジェクトを名前変更してから再びインポートする場合、Framework Manager はそれが既


に存在していることを認識します。異なる一意の名前でオブジェクトを再インポートするには、新しいネームスペースを作成して、オブジェクトをそのネームスペースに再インポートする方法があります。

同じ名前を持つ複数のオブジェクトをインポートすることもできます。

リレーショナル・データベースからのメタデータのインポートリレーショナル・データベースからメタデータをインポートする際、すべてのメタデータをインポートすることも、特定のオブジェクト・タイプ (テーブル、列、ビュー、同義語、ストアード・プロシージャー、および関数など) を選択することもできます。システム・オブジェクトをリレーショナル・ソースからインポートすることもできます。システム・ストアード・プロシージャーはサポートされません。IBM Cognos Framework Manager では、ユーザー定義のストアード・プロシージャーのみがサポートされます。

以下の表は、Framework Manager オブジェクトにマップされるデータベース・オブジェクトを示しています。

データベース・オブジェクト Framework Manager オブジェクト

表クエリー・サブジェクト

列クエリー・アイテム

ビュークエリー・サブジェクト

同義語クエリー・サブジェクト

プロシージャークエリー・サブジェクト

関数プロジェクト関数

Microsoft SQL Server および Microsoft Analysis Server からインポートされる名前付きセットは、Framework Manager モデルで読み取り専用の計算として保管されます。計算には、それを名前付きセットとして識別するフラグ、およびディメンション名を含むプロパティーがあります。

IBM Cognos Analytics (BI) は、実質的にプロシージャーおよび関数のグループである Oracle パッケージをサポートしていません。その結果として、Oracle パッケージの同義語は Framework Manager に表示されません。Oracle ストアード・プロシージャー、関数、および同義語は Cognos Analytics でサポートされています。また、Oracle パッケージを参照しない限り、Framework Manager MetadataWizard を使用してインポートできます。

手順1. インポート先のネームスペース、フォルダー、またはセグメントをクリックしま

す。



3. 「メタデータ・ソースを選択」ダイアログ・ボックスで、インポートするメタデータのタイプを選択します。

「データ・ソース」オプションは、IBM Cognos ソフトウェアで定義されているデータ・ソースのリストを提供します。

v インポートする特定のリレーショナル・メタデータ・ソースを選択します。




v インポート時にオブジェクト名の重複をどのように処理するのかを指定します。インポートして、固有の名前を作成するのか、インポートしないのかを選択します。一意の名前を作成することを選択した場合、インポートされたオブジェクトは数字付きで表示されます。例えば、プロジェクトの中にはQuerySubject と QuerySubject1 が表示されます。


v 関係を作成するために使用する基準を指定します。

v すべてのカーディナリティーを 1 に変換する場合、「ファクト検出が有効」チェック・ボックスをオフにします。 n カーディナリティーを削除すると、ファクト検出および二重カウントの自動防止が無効になります。詳細については、 424 ページの『1-1 の関係としての 1-n の関係のモデル作成』を参照してください。

4. 「インポート」をクリックします。

インポートできなかったオブジェクトのリストとインポートされたオブジェクトの数を含むインポート統計が表示されます。


次のタスク

メタデータをインポートした後に、以下の領域のインポートしたメタデータを確認する必要があります。

v 関係およびカーディナリティー。 403 ページの『インポートしたメタデータの検証』を参照してください。

v 行列式。 94 ページの『行列式』を参照してください。

v クエリー・アイテムの「使用方法」プロパティー。 159 ページの『クエリー・アイテムの形式設定』を参照してください。

v クエリー・アイテムの「標準集計」プロパティー。 159 ページの『クエリー・アイテムの形式設定』を参照してください。

SAP HANA 入力パラメーターとデータ・ソース・クエリー・サブジェクト・パラメーターの対応関係


Framework Manager に組み込まれているデータ・ソース・クエリー・サブジェクトでは、SAP HANA の分析ビューや計算ビューで定義されている入力パラメーターに対応するパラメーターを設定できます。

SAP HANA _SYS_BIC スキーマからオブジェクトをインポートすると、入力パラメーターのメタデータを取得するために _SYS_BI.BIMC_VARIABLE_VIEW に対するクエリーが実行されます。SAP HANA に対するモデル作成者のサインオンに_SYS_BI.BIMC_VARIABLE_VIEW へのアクセス権がないと、SAP HANA から例外が返されます。その場合、そのサインオンでアクセス権を付与してもらわなければ、モデル作成者は _SYS_BI スキーマからオブジェクトを選択できません。SAPHANA の分析ビューや計算ビューのクエリーで使用するサインオンには、そのようなオブジェクトに対してクエリーを実行するための適切な権限が必要です。

入力パラメーターが含まれている SAP HANA ビューは、Framework Manager でデータ・ソース・クエリー・サブジェクトとして表示されます。データ・ソース・クエリー・サブジェクト・エディターには、BIMC_VARIABLE_VIEW から返される入力パラメーターのセットを表示するタブが含まれています。それぞれのデータ・ソース・クエリー・サブジェクト・パラメーターには、名前とデータ型のほかに、クエリー実行時に値を受け取るためのプロンプトがあります。パラメーター名は、SAP HANA ビューの入力パラメーターに割り当てられている名前と同じです。SAP HANA によって実行される SQL 文の SAP HANA PLACEHOLDER 節でその名前が使用されます。

パラメーターのデータ型と _SYS_BI.BIMC_VARIABLE_VIEW から返されるデータ型の対応関係を以下にまとめます。

表 7. SAP HANA と Framework Manager のパラメーターのデータ型

SAP HANA Framework Manager

STRING、ALPHANUM Character32

SECONDDATE、LONGDATE dateTime

SECONDTIME Time

DAYDATE Date

SDFLOAT、FIXED、DECIMAL_FLOAT Decimal

FLOAT、DOUBLE Float64

INTEGER、INT Int32

値の定義で指定するプロンプト・マクロを使用して、各パラメーターに値を渡せます。プロンプトに割り当てる名前は、パラメーター名と同じでなくてもかまいません。プロンプトのデータ型は、以下の表のように定義できます。

表 8. Framework Manager とプロンプトのパラメーターのデータ型

Framework Manager プロンプト

CharacterLength16 string

dateTime timestamp

Time time

Date date

Decimal decimal


表 8. Framework Manager とプロンプトのパラメーターのデータ型 (続き)

Framework Manager プロンプト

Float 64 double

Int32 integer

SAP HANA パラメーターは、必須パラメーターとしてもオプション・パラメーターとしても定義できます。プロンプト・マクロでデフォルト値が定義されていれば、そのパラメーターはオプション・パラメーターとみなされます。実行時にレポートからプロンプトに値が渡されないと、そのパラメーターは、SAP HANA に渡される SQL 文のプレースホルダー・セットに組み込まれません。promptmany マクロを使用する場合は、プロンプトに渡される複数の値が区切り文字で区切られているリストとして結合され、SAP HANA のプレースホルダーに渡されます。

プロンプトが含まれていない定数やマクロ式をパラメーターで定義することもできます。定数の値は、SAP HANA 入力パラメーターを参照する SAP HANA ビューの関連ロジックでサポートされている値でなければなりません。

データ・ソース・クエリー・サブジェクトをインポートによって作成すると、論理SQL クエリーが割り当てられます。そのクエリーは編集しないでください。述部は、詳細フィルターを使用して定義できます。その他の計算フィールドは、データ・ソース・クエリー・サブジェクトかデータ・ソース・クエリー・サブジェクトを参照するモデル・クエリー・サブジェクトに関連する計算フィールドを使用して定義できます。

Framework Manager は SAP の変数をインポートしません。クエリー・サブジェクトで、SAP HANA に渡す SQL 文に述部を組み込む詳細フィルターを定義できます。

データ・ソース・クエリー・サブジェクトは、「オブジェクトを更新」アクションによって更新できます。このアクションを実行すると、データ・ソース・クエリー・サブジェクトに関連するパラメーター・セットが再作成されます。あるいは、データ・ソース・クエリー・サブジェクト・パラメーターを SAP HANA ビュー・パラメーターに合わせて調整するために、パラメーターのプロパティーを追加したり、削除したり、更新したり、パラメーターの名前を変更したりすることもできます。

重要:

v インポートした SAP HANA ビューに、名前が同じでデータ型やオプション・プロパティーが異なる SAP 入力パラメーターが含まれている場合は、データ・ソース・クエリー・サブジェクトのパラメーター値の定義で固有のプロンプト名を割り当ててください。

v SAP HANA の入力パラメーターに複数の値を設定できる場合、プロンプト・マクロ関数は #promptmany でなければなりません。そうでなければ、間違った構文が生成され、クエリーが失敗します。

フィルター演算式の IN 演算子の引数として使用する入力パラメーターは、そのような入力パラメーターの一例です。


モデル作成者は、プロンプト関数を手動で #prompt から #promptmany に変更しなければなりません。

Framework Manager のパラメーター値の定義の例

以下のパラメーター値は、1 つの入力値を受け入れるよう定義されています。値を指定しなければ、このパラメーターはオプション・パラメーターとみなされます。

#prompt('optional_prompt', 'string', '0')#

以下のパラメーター値は、1 つの入力値を受け入れるよう定義されています。オプション・パラメーターではありません。

#prompt('mandatory_prompt', 'integer')#

以下のパラメーター値は、1 つ以上の入力値を受け入れるよう定義されています。

#promptmany('multi_value_prompt', 'date')#

以下のパラメーター値は、マクロとして定義されています。引用符の中にスペースが入っていることに注目してください。

#' '#

以下のパラメーター値は、定数として定義されています。

123

IBM Cognos モデルからのメタデータのインポート既存の IBM Cognos モデルからメタデータをインポートすることができます。

注: 別の IBM Cognos Framework Manager プロジェクトからインポートする場合、式の構文は各言語に合わせて調整されません。例えば、設計言語としてフランス語を使用して Framework Manager プロジェクトを作成し、計算とフィルターでフランス語固有の構文を使用します。その後、設計言語として英語を使用して新規プロジェクトを作成し、フランス語のプロジェクトを新規プロジェクトにインポートします。計算およびフィルターで定義されている式は無効です。メタデータをインポートした後、式を手動で変更する必要があります。


す。


3. 「IBM Cognos Model」、「次へ」の順にクリックします。

4. 目的のモデル (.cpf ファイル) を見つけ、「開く」、「次へ」の順にクリックします。

5. 「インポート」ウィザードの指示に従います。


v インポート時にオブジェクト名の重複をどのように処理するのかを指定します。

インポートして、固有の名前を作成するのか、インポートしないのかを選択します。一意の名前を作成することを選択した場合、インポートされたオブ


ジェクトは数字付きで表示されます。例えば、プロジェクトの中にはQuerySubject と QuerySubject1 が表示されます。

6. 「次へ」、「終了」の順にクリックします。

Architect モデルまたは Impromptu カタログからのメタデータのインポート

IBM Cognos Architect モデルまたは Impromptu カタログからメタデータをインポートするには、最初にそのメタデータを XML ファイルに変換する必要があります。 IBM Cognos Series 7 と IBM Cognos Analytics の間の違いにより、 IBMCognos Framework Manager の移行済みメタデータをインポートした後、メタデータをテストして調整する追加作業が必要になります。

手順1. Architect モデルまたは Impromptu カタログがエクスポートされていること

を確認します。

2. インポート先のネームスペース、フォルダー、またはセグメントをクリックします。


4. 「IBM Cognos Architect (.xml)」または「IBM Cognos Impromptu(.xml)」のいずれかをクリックし、「次へ」をクリックします。

5. インポートするメタデータが含まれている Architect または Impromptu のXML ファイルを見つけます。

「XML プレビュー」ウィンドウのメッセージにより、有効な XML ファイルが選択されたことが確認されます。

6. 「開く」をクリックします。

7. Series 7 セキュリティー情報が含まれているネームスペースを選択します。

8. 「インポート」をクリックします。

作成されたオブジェクトのリストが表示されます。

9. インポートされたメタデータを検証する場合、「インポート後に検証する(Verify after import)」チェック・ボックスをクリックします。


IBM Cognos DecisionStream または IBM Cognos DataManager からのメタデータのインポート

IBM Cognos Framework Manager を使用して、IBM Cognos DecisionStream または IBM Cognos Data Manager によって作成された XML ファイルからメタデータをインポートできます。

以下のものをインポートできます。

v 物理メタデータ・ネームスペースにある物理レイヤー

このレイヤーには、インポートされたテーブルを表すデータ・ソースのクエリー・サブジェクトが含まれます。物理レイヤーには、クエリー・サブジェクトと、クエリー・サブジェクト間の物理関係とが含まれます。これらの物理関係


は、インポート・ファイル内に定義されている関係から推測されます。インポートされたテーブルは Framework Manager クエリー・サブジェクトになり、サロゲート・キーは Framework Manager 行列式になります。

v ディメンション・ネームスペースにあるディメンション・レイヤー

このレイヤーには、標準ディメンション、数値データ・ディメンション、および範囲の関係が含まれます。標準ディメンションには、一致するものと一致しないものとがあります。数値データ・ディメンションのオブジェクトは、インポートされるスターに対応します。範囲の関係は、インポート・ファイル内に定義されている関係から推測されます。

v 「ビジネス・ビュー」ネームスペースにある論理レイヤー

このレイヤーには、「ディメンション」ネームスペース内の標準ディメンションおよび数値データ・ディメンションへのショートカットが含まれます。それらのショートカットは、インポート・ファイルからのスターと同じ名前のネームスペースである、スター・スキーマ・グループに編成されます。

次の図は、DecisionStream および Data Manager のオブジェクトが FrameworkManager オブジェクトにマップされる方法を示しています。

ファクト

スターは、物理メタデータ・ネームスペース内の Framework Manager クエリー・サブジェクトに、またはディメンション・ネームスペース内の数値データ・ディメンションとしてマップされます。以下のファクト属性がモデルに含まれます。


属性名 Framework Manager へのマッピング

テーブル名 (Table name) ファクトを表すモデル・クエリーがベースとするデータベース・クエリー・サブジェクトの名前。

短縮名 (Short name) クエリー・サブジェクトの説明

ビジネス名 (Business name) カスタム・プロパティー

説明 (Description) クエリー・サブジェクトの説明

列名 (Column name) クエリー・アイテムの名前

列タイプ (Column type) クエリー・アイテムのデータ型

列の長さ (Column length) クエリー・アイテムのサイズ

列の短縮名 (Column short name) カスタム・プロパティー

列のビジネス名 (Column business name) カスタム・プロパティー

列記述 (Column description) クエリー・アイテムの説明

列タイプ (Column type) クエリー・アイテムの使用法

テーブル・キー (Table keys) 物理メタデータ・ネームスペース内の行列式

接続

接続は Framework Manager データ・ソースにマップされます。

注: データ・ソース接続が IBM Cognos Administration 内に自動的に作成されることはありません。インポート・プロシージャーの手順で説明されているように、IBM Cognos Administration 内に接続を手動で作成する必要があります。詳細については、 52 ページの『IBM Cognos DecisionStream または IBM Cognos DataManager からのメタデータのインポート』を参照してください。

以下のデータ・ソース属性がモデルに含まれます。


接続の短縮名 (Connection short name) カスタム・プロパティー

接続のビジネス名 (Connection businessname)

データ・ソース名

接続の説明 (Connection description) データ・ソースの説明

接続 (Connectivity) type.interface プロパティー



接続文字列 (Connection string) カスタム・プロパティー

ディメンション・ビルド

ディメンション・ビルドは、Framework Manager に最上位のネームスペースとしてマップします。

階層

階層、レベル、および列を含むディメンションは、階層、レベル、およびクエリー・アイテムを含む Framework Manager の標準ディメンションにマップされます。

一致するスター

一致するスターは、ビジネス・ビュー・ネームスペースにある FrameworkManager ネームスペースにマップされます。これにはディメンションを参照するショートカットが含まれます。

以下の一致するスター属性がモデルに含まれます。


スターの短縮名 (Star short name) スターを表すネームスペースの名前

スターのビジネス名 (Star business name) ファクトを表す数値データ・ディメンションの名前

スターの説明 (Star description) ファクトを表す数値データ・ディメンションの説明

ファクト (Facts) 数値データ・ディメンションへのショートカット

ディメンション (Dimensions) 標準ディメンションへショートカット

階層 (Hierarchies) DecisionStream ディメンションを表す標準ディメンション内の階層

モデル・プロパティー

エクスポート・ファイルには、以下のモデル・プロパティーが含まれます。


スキーマ・バージョン (Schema version) マップされません



カタログのバージョン (Catalog version) カスタム・プロパティー

モデルの短縮名 (Model short name) 最上位のモデル・オブジェクトを表すネームスペースの名前

モデルのビジネス名 (Model business name) カスタム・プロパティー

モデルの説明 (Model description) 最上位のモデル・オブジェクトを表すネームスペースの説明

IBM Cognos DecisionStream または IBM Cognos Data Managerからインポートする手順

手順



3. 「IBM Cognos DecisionStream (.xml)」または「IBM Cognos DataManager (.xml)」、「次へ」の順にクリックします。

4. インポートするメタデータが含まれている XML ファイルを見つけます。

「XML プレビュー」ウィンドウのメッセージにより、有効な XML ファイルが選択されたことが確認されます。

5. 「開く」、「インポート」の順にクリックします。

作成されたオブジェクトのリストが表示されます。

6. インポートされたメタデータを検証する場合、「インポート後に検証する(Verify after import)」チェック・ボックスをクリックします。


8. IBM Cognos Administration でデータ・ソース接続を作成します。 IBMCognos Administration で定義する名前は、Framework Manager の「データ・ソース」フォルダーに表示されるデータ・ソース名と同じでなければなりません。

サード・パーティーのメタデータ・ソースからのメタデータのインポート

IBM Cognos Framework Manager を使用して、リレーショナル・メタデータなどのメタデータを他のソースからインポートできます。メタデータは、メタデータ・ブリッジを使用してインポートされます。

リレーショナルおよび他のメタデータを同じモデルにインポートできます。新しいFramework Manager モデルから開始して、他のメタデータをリレーショナル・メタデータの前にインポートできます。これにより、同じ名前を持つ複数のオブジェクトをインポートする場合に競合を回避できます。


他のメタデータをインポートするとき、インポート・ウィザードを介して提供される情報に基づいてデータ・ソースが作成されます。他のソース内にある 1 つ以上の物理オブジェクトがデータベース・スキーマ、カタログ、またはその両方を参照する場合は、カタログまたはスキーマのプロパティーがメタデータに定義されたカタログまたはスキーマの名前に設定された、1 つの Framework Manager データ・ソースが作成されます。カタログまたはスキーマを参照しない物理オブジェクトには、一般データ・ソースが作成されます。

別のデータ・ソースからメタデータにアクセスする場合、物理モデルのインポートを行う必要があります。

必ずしも、すべてのデータ・ソースにレポート作成に適したメタデータが含まれていたり、すべての概念が Framework Manager にマップされたりするとは限りません。メタデータのインポートは Framework Manager に合わせて調整され、互換性のあるメタデータだけがインポートされます。

すべてのメタデータ・ブリッジは、さらにモデル作成を続けるための基礎となる物理レイヤーを提供します。どれほど充実した Framework Manager モデルが生成されるかは、メタデータ・ソースがどれほど充実しているかに直接関係しています。

複数のデータベース

他のメタデータ・ソースは、複数のデータベースに基づくことがあります。それらの複数のデータ・ソースを Framework Manager にインポートする最良の方法は、複数のインポートを実行することです。インポートごとに、その特定のデータ・ソースに対応するアイテムを選択します。

例えば、別のメタデータ・ソースから初めてインポートするときは、datasource1とそのデータ・ソースに対応するすべてのアイテムを選択します。 2 回目には、datasource2 とそのデータ・ソースに対応するすべてのアイテムを選択します。すべてのデータ・ソースとそれらに対応するアイテムをインポートするまで、インポートを続けます。

サード・パーティーに固有のインポート・オプション

メタデータは、Meta Integration Model Bridge (MIMB) によってサード・パーティーのデータ・ソースから抽出されます。 Framework Manager に適用されないオプションもあります。サポートされるツールおよびオブジェクト・マッピングについて詳しくは、Meta Integration の Web サイトを参照してください。

インポート中に表示されるオプションは、選択されたデータ・ソースに基づいています。

Framework Manager のオプション

IBM Cognos Framework Manager の使用可能なオプションは、選択するメタデータ・ソースのタイプに関係なく同一です。次の表は、Framework Manager でオブジェクトを作成するために使用するオプションを示しています。


Framework Manager のオプション説明

論理/物理表現 (Logical/Physicalrepresentation)

論理オブジェクトおよび物理オブジェクトをどのように表現するかを指定します。

「統合 (Integrated)」は、論理オブジェクトと物理オブジェクトを 1 つの統合されたオブジェクトとして表します。

「分離 (Separated)」は、論理オブジェクトと物理オブジェクトを 2 つの関連したオブジェクトとして表します。これはデフォルトです。

「分離 (詳細) (Separated (verbose))」は、論理オブジェクトと物理オブジェクトを 2つの異なるオブジェクトとして表します。

ディメンション/論理表現(Dimensional/Logical representation)

「統合 (Integrated)」は、ディメンション・オブジェクトを 1 つの統合されたオブジェクトとして表します。これはデフォルトです。

「分離 (Separated)」は、ディメンション・オブジェクトを 1 つのディメンション・オブジェクトと 1 つの論理オブジェクトとして表します。

ダイアグラム表現 (Diagram representation) ダイアグラムをプロジェクト内でどのように表現するかを指定します。

「ネームスペースとして (AsNamespaces)」は、ダイアグラムをネームスペースとして表すように指定します。

「パッケージとして (As Packages)」は、ダイアグラムをパッケージとして表すように指定します。

「両方 (Both)」は、ダイアグラムをネームスペースとパッケージの両方として表すように指定します。これはデフォルトです。

「なし (None)」は、ダイアグラムをプロジェクト内で表現しないように指定します。



ネームスペース階層 (Namespace hierarchy) パッケージの階層を保持する場所を指定します。

「すべて (All)」は、パッケージの階層をすべてのネームスペースで保持するように指定します。これはデフォルトです。

「なし (None)」は、パッケージの階層を保持しないように指定します。

「ディメンション・レベルのみ(Dimensional level only)」は、パッケージの階層をディメンション・ネームスペースだけに保持するように指定します。

「論理レベルのみ (Logical level only)」は、パッケージの階層を論理ネームスペースだけに保持するように指定します。

「物理レベルのみ (Physical level only)」は、パッケージの階層を物理ネームスペースだけに保持するように指定します。

論理のみのクラス (Logical only classes) 論理のみのクラスを表現するかどうかを指定します。

「無視 (Ignore)」は、論理のみのクラスを無視するように指定します。

「表示 (Show)」は、論理のみのクラスをそのすべての属性と共に表示するように指定します。これはデフォルトです。

論理のみの属性 (Logical only attributes) 論理のみの属性を表現するかどうかを指定します。このオプションは、論理のみのクラスに含まれる論理のみの属性には影響を与えません。

「除去 (Drop)」は、クラスに論理のみの属性が含まれる場合に、その論理情報を表示しないように指定します。

「無視 (Ignore)」は、論理のみの属性を無視するように指定します。

「表示 (Show)」は、論理のみの属性を表示するように指定します。これはデフォルトです。



参照されないディメンション属性(Unreferenced dimension attributes)

参照されないディメンション属性をプロジェクト内でどのように表現するかを指定します。参照されないディメンション属性は、レベルには参加しないで、他のディメンション属性からは参照されないディメンション属性です。

「すべて無視 (Ignore All)」は、参照されないディメンション属性をすべて無視するように指定します。

「結合を無視 (Ignore Join)」は、結合に参加している参照されないディメンション属性だけを無視するように指定します。

「すべて表示 (Show All)」は、参照されないディメンション属性をすべて表示するように指定します。これはデフォルトです。

「結合を表示 (Show Join)」は、結合に参加している参照されないディメンション属性だけを表示するように指定します。

ディメンション情報のないディメンション(Dimensions without dimensionalinformation)

ディメンション情報を含まないディメンションを表現する方法を指定します。

「ディメンション (Dimension)」は、ディメンションおよびデフォルトの階層とレベルを作成します。これはデフォルトです。

「モデル・クエリー (Model Query)」は、modelQuery を作成します。

キューブの作成 (Create cubes) インポートでキューブを作成可能にするかどうかを指定します。キューブは、そのキューブを作成するために必要なすべての情報を含むネームスペースとして表現されます。

画面ヒントに内容を追加する (Populatescreentip)

インポートで説明フィールドを画面ヒントとして使用するかどうかを指定します。

「はい (True)」は、IBM Cognos Analytics- Reporting、Query Studio、または IBMCognos Workspace Advanced で、説明フィールドの内容を画面ヒントとして表示できるようにします。

ディメンション情報を含むネームスペースの名前 (Name of the namespace containingthe dimensional information)

ディメンション情報を含むネームスペースの名前を指定します。デフォルトは「ディメンション・モデル (Dimensional Model)」です。



論理情報を含むネームスペースの名前(Name of the namespace containing thelogical information)

論理情報を含むネームスペースの名前を指定します。デフォルトは「論理モデル (LogicalModel)」です。

物理情報を含むネームスペースの名前(Name of the namespace containing thephysical information)

物理情報を含むネームスペースの名前を指定します。デフォルトは「物理モデル(Physical Model)」です。

サブジェクト・エリアを含むネームスペースの名前 (Name of the namespace containingthe subject areas)

サブジェクト・エリアを含むネームスペースの名前を指定します。デフォルトは「サブジェクト・エリア (Subject Area)」です。

整合性検査 (Consistency Check) 整合性検査のレベルを指定します。

「基本 (Basic)」は、標準的な整合性検査レベルです。

「詳細 (Extensive)」は、モデルをより詳細に検証します。

「なし (None)」は、検証を実行しないように指定します。

IBM メタデータ・ソースからのインポートIBM Cognos Framework Manager を使用して、メタデータを IBM InfoSphere®

DataStage® などの IBM データ・ソースからインポートできます。サード・パーティーのデータ・ソースと同様に、メタデータは Meta Integration Model Bridge(MIMB) を使用して抽出されます。

詳細については、 56 ページの『サード・パーティーのメタデータ・ソースからのメタデータのインポート』を参照してください。

IBM メタデータ・ソースのインポート・オプション

表示されるオプションは、選択されたデータ・ソースに基づいています。Framework Manager に適用されないオプションもあります。

Framework Manager のオプション

IBM Cognos Framework Manager の使用可能なオプションは、選択するメタデータ・ソースのタイプに関係なく同一です。次の表は、Framework Manager でオブジェクトを作成するために使用するオプションを示しています。



論理/物理表現 (Logical/Physicalrepresentation)

論理オブジェクトおよび物理オブジェクトをどのように表現するかを指定します。

「統合 (Integrated)」は、論理オブジェクトと物理オブジェクトを 1 つの統合されたオブジェクトとして表します。

「分離 (Separated)」は、論理オブジェクトと物理オブジェクトを 2 つの関連したオブジェクトとして表します。これはデフォルトです。

「分離 (詳細) (Separated (verbose))」は、論理オブジェクトと物理オブジェクトを 2つの異なるオブジェクトとして表します。

ディメンション/論理表現(Dimensional/Logical representation)

「統合 (Integrated)」は、ディメンション・オブジェクトを 1 つの統合されたオブジェクトとして表します。これはデフォルトです。

「分離 (Separated)」は、ディメンション・オブジェクトを 1 つのディメンション・オブジェクトと 1 つの論理オブジェクトとして表します。

ダイアグラム表現 (Diagram representation) ダイアグラムをプロジェクト内でどのように表現するかを指定します。

「ネームスペースとして (AsNamespaces)」は、ダイアグラムをネームスペースとして表すように指定します。

「パッケージとして (As Packages)」は、ダイアグラムをパッケージとして表すように指定します。

「両方 (Both)」は、ダイアグラムをネームスペースとパッケージの両方として表すように指定します。これはデフォルトです。

「なし (None)」は、ダイアグラムをプロジェクト内で表現しないように指定します。



ネームスペース階層 (Namespace hierarchy) パッケージの階層を保持する場所を指定します。

「すべて (All)」は、パッケージの階層をすべてのネームスペースで保持するように指定します。これはデフォルトです。

「なし (None)」は、パッケージの階層を保持しないように指定します。

「ディメンション・レベルのみ(Dimensional level only)」は、パッケージの階層をディメンション・ネームスペースだけに保持するように指定します。

「論理レベルのみ (Logical level only)」は、パッケージの階層を論理ネームスペースだけに保持するように指定します。

「物理レベルのみ (Physical level only)」は、パッケージの階層を物理ネームスペースだけに保持するように指定します。

論理のみのクラス (Logical only classes) 論理のみのクラスを表現するかどうかを指定します。

「無視 (Ignore)」は、論理のみのクラスを無視するように指定します。

「表示 (Show)」は、論理のみのクラスをそのすべての属性と共に表示するように指定します。これはデフォルトです。

論理のみの属性 (Logical only attributes) 論理のみの属性を表現するかどうかを指定します。このオプションは、論理のみのクラスに含まれる論理のみの属性には影響を与えません。

「除去 (Drop)」は、クラスに論理のみの属性が含まれる場合に、その論理情報を表示しないように指定します。

「無視 (Ignore)」は、論理のみの属性を無視するように指定します。

「表示 (Show)」は、論理のみの属性を表示するように指定します。これはデフォルトです。



参照されないディメンション属性(Unreferenced dimension attributes)

参照されないディメンション属性をプロジェクト内でどのように表現するかを指定します。参照されないディメンション属性は、レベルには参加しないで、他のディメンション属性からは参照されないディメンション属性です。

「すべて無視 (Ignore All)」は、参照されないディメンション属性をすべて無視するように指定します。

「結合を無視 (Ignore Join)」は、結合に参加している参照されないディメンション属性だけを無視するように指定します。

「すべて表示 (Show All)」は、参照されないディメンション属性をすべて表示するように指定します。これはデフォルトです。

「結合を表示 (Show Join)」は、結合に参加している参照されないディメンション属性だけを表示するように指定します。

ディメンション情報のないディメンション(Dimensions without dimensionalinformation)

ディメンション情報を含まないディメンションを表現する方法を指定します。

「ディメンション (Dimension)」は、ディメンションおよびデフォルトの階層とレベルを作成します。これはデフォルトです。

「モデル・クエリー (Model Query)」は、modelQuery を作成します。

キューブの作成 (Create cubes) インポートでキューブを作成可能にするかどうかを指定します。キューブは、そのキューブを作成するために必要なすべての情報を含むネームスペースとして表現されます。

画面ヒントに内容を追加する (Populatescreentip)

インポートで説明フィールドを画面ヒントとして使用するかどうかを指定します。

「はい (True)」は、IBM Cognos Analytics- Reporting、Query Studio、または IBMCognos Workspace Advanced で、説明フィールドの内容を画面ヒントとして表示できるようにします。

ディメンション情報を含むネームスペースの名前 (Name of the namespace containingthe dimensional information)

ディメンション情報を含むネームスペースの名前を指定します。デフォルトは「ディメンション・モデル (Dimensional Model)」です。



論理情報を含むネームスペースの名前(Name of the namespace containing thelogical information)

論理情報を含むネームスペースの名前を指定します。デフォルトは「論理モデル (LogicalModel)」です。

物理情報を含むネームスペースの名前(Name of the namespace containing thephysical information)

物理情報を含むネームスペースの名前を指定します。デフォルトは「物理モデル(Physical Model)」です。

サブジェクト・エリアを含むネームスペースの名前 (Name of the namespace containingthe subject areas)

サブジェクト・エリアを含むネームスペースの名前を指定します。デフォルトは「サブジェクト・エリア (Subject Area)」です。

整合性検査 (Consistency Check) 整合性検査のレベルを指定します。

「基本 (Basic)」は、標準的な整合性検査レベルです。

「詳細 (Extensive)」は、モデルをより詳細に検証します。

「なし (None)」は、検証を実行しないように指定します。

サード・パーティーのメタデータ・ソースからインポートする手順

始める前に

メタデータをインポートする前に、データ・ソースへの接続を作成しておく必要があります。

手順



3. 「サード・パーティーのメタデータ・ソース」、「次へ」の順にクリックします。

4. インポートするメタデータ・タイプをクリックします。

5. 「サード・パーティー固有のインポート・オプション」ダイアログで、「ファイル」オプションを使用して、インポートするメタデータが含まれているファイルを識別します。

必要な他のオプションをクリックします。表示されるオプションは、選択されたデータ・ソースに基づいています。

注: デフォルト・オプションを使用してください。デフォルト・オプションは、メタデータ・インポートを最適化します。オプションを変更すると、予期しない結果が表示される場合があります。デフォルト・オプションに戻すには、「デフォルトを使用」をクリックします。


6. 「次へ」をクリックします。

7. 「Framework Manager 固有のインポート・オプション」ダイアログ・ボックスで、目的のオプションをクリックし、「次へ」をクリックします。

8. 「メタデータ・ウィザード」の指示に従います。




v インポート時にオブジェクト名の重複をどのように処理するのかを指定します。インポートして、固有の名前を作成するのか、インポートしないのかを選択します。一意の名前を作成することを選択した場合、インポートされたオブジェクトは数字付きで表示されます。例えば、プロジェクトの中にはQuerySubject と QuerySubject1 が表示されます。



インポートできなかったオブジェクトのリストとインポートされたオブジェクトの数を含むインポート統計が表示されます。


インポート後のモデル化:

ソース・メタデータには、IBM Cognos Analytics との互換性がある論理構造があります。ソース・モデルとのより高い精度を実現するために、インポートの際にこの構造が保持されます。

インポートの後、物理メタデータのみを使用できます。

手順

1. モデルを分析し、検討します。 207 ページの『モデルの分析』を参照してください。

2. 行列式を設定します。

3. 「使用方法」プロパティーを設定します。

ブリッジの中には、ファクトの手動設定が必要なものがあります。メタデータ・ソースからそれを取得できないからです。

4. 関係およびカーディナリティーを検証します。

5. 未確定の関係 (複数の有効な関係、再帰的関係、帰納的関係など) を解決します。

他のソースからのメタデータのトラブルシューティングこのセクションには、IBM Cognos Framework Manager にインポートしたメタデータに関する作業で発生する可能性がある問題について記載しています。


テーブル・ビューを含む関係は、Oracle Designer ファイルからインポートされない少なくとも 1 つのテーブル・ビューを含む主キーと外部キーとの関係は、OracleDesigner ファイルから Framework Manager にインポートされません。

主キーと外部キーとの関係を手動で作成します。

別のソースのクエリー・サブジェクトをテストすることはできない別のデータ・ソースからインポートしたクエリー・サブジェクトをテストすることはできません。

例えば、クエリー・サブジェクトをテストし、次のエラー・メッセージを受け取ったとします。

QE-DEF-0177 'sqlPrepareWithOptions' 処理中にエラーが発生しました。ステータス='-201'。

UDA-SQL-0196 テーブルまたはビュー"GOSALES1.COGNOS.COM.GOSALES.CONVERSION_RATE" がディクショナリーに見つかりませんでした。

この問題を解決するには、以下の状態が存在するようにします。

v インポートによって作成され、クエリー・サブジェクトが参照する FrameworkManager データ・ソース・オブジェクトが、IBM Cognos Analytics ContentStore に同一名の対応データ・ソースを持っている。

v 対応する Content Store データ・ソースが有効であり、接続情報が正しい。

v インポートによって作成され、クエリー・サブジェクトが参照するデータ・ソース・オブジェクトのオプションのスキーマまたはカタログ・プロパティーが正しい。大文字と小文字が区別される識別子を受け入れるデータベースの場合は、大文字と小文字も正しいことを確認します。

v クエリー・サブジェクトで表されるデータベース・オブジェクト (テーブルまたはビュー) が同一名でデータベースに存在し、現行接続内でアクセス可能である。

v 「クエリー・タイプ」が有効である。SAP BW からクエリー・サブジェクトをインポートし、データ・ソースの「クエリー・タイプ」プロパティーの値を変更した場合は、無効な「クエリー・タイプ」が存在している可能性があります。デフォルトでは、「クエリー・タイプ」の値は「多次元」です。これを変更しないでください。

他のメタデータ・ソースからインポートされたいくつかの式が有効ではないIBM Cognos Analytics では、MIMB での式の構文解析のサポートが改善されています。他のメタデータ・ソースと IBM Cognos Analytics との間で同等となる関数は解析されます。

以下のものは、例外となります。

v IBM Cognos Analytics と他のメタデータ・ソースとの間にマッピングが存在しない関数


v 特殊な構文を使用する式

解決策:

他方のメタデータ・ソースから式をインポートした後、IBM Cognos Analytics と他方のメタデータ・ソースとの間のマッピングを持たない関数がある場合、同等のFramework Manager 構文に準拠するように Framework Manager を使って式を手動で編集します。

特別な構文を使用する式がある場合、次の操作を実行します。

手順

1. Framework Manager で、$$1 や $$2 などの参照を使用する埋め込み計算を表すすべてのインポート対象クエリー・アイテムを識別します。

2. 「プロパティー」ウィンドウで、各クエリー・アイテムの「patternMapping」プロパティーに提供されている情報を見つけます。

「patternMapping」プロパティーは、インポートされる計算のパラメーターと元のモデルの実際のオブジェクト参照の間のマッピングを示します。

3. 壊れているクエリー・サブジェクトをダブルクリックします。

4. 手順 1 で識別されるクエリー・アイテムに対応した埋め込み計算をダブルクリックします。

5. 計算にデフォルト名 ("Calculation...") が割り当てられている場合、それを実際のクエリー・アイテム名で置き換えます。

6. インポートされるパラメーターを、そのパラメーターを表す実際の FrameworkManager オブジェクト参照で置き換えます。

7. 壊れている各クエリー・サブジェクトに対してこの手順を繰り返します。

データ・ソースとして XML を使用したメタデータのインポートIBM Cognos Framework Manager では、XML ファイルを表形式データ・ソースとしてインポートすることができます。ローカルでインポートすることも、有効なURL を使ってリモート・サイトからインポートすることもできます。 FrameworkManager では、XML ファイルを使用して、メタデータをモデル化し、パッケージを作成します。

Reporting、Query Studio、または IBM Cognos Workspace Advanced のいずれかによってクエリーが処理される際、実行時に XML ファイルが検証され、解析されます。VALIDATE=ON オプションを接続文字列に追加する場合、FrameworkManager は、メタデータを説明する XML ファイルの <columnList> タグを部分的に検証します。サポートされるデータ型の詳細については、 485 ページの『付録F. XML データ型』を参照してください。

XML ファイルを検証するには、xmldata.xsd スキーマを使用する必要があります。スキーマは ¥c10¥bin フォルダー内にあります。 XML ファイル自体にスキーマの場所を指定する必要はありません。

XML をデータ・ソースとして使用する場合は、次の点を確認してください。

v ネイティブ SQL を使用して XML ファイルのデータにアクセスしない


v バイナリー・ラージ・オブジェクト (BLOB) にアクセスしない

v sqlColumns() および sqlTables() メタデータ呼び出しのみを使用する

それ以外の呼び出しは、サポートされない関数エラーを返します。

v XML ファイルは整形式であり、有効である

始める前に

メタデータをインポートする前に、データ・ソースへの接続を作成しておく必要があります。 XML データ・ソースが別のコンピューター上にある場合、そのデータ・ソースへのアクセス権を持つアカウントを使用する必要があります。

XML データ・ソースへの接続を作成した後、データ・ソースがデータ・ソース・リストに表示されます。

XML をデータ・ソースとして使用するには、XML、スキーマ、および XML に関連したその他のテクノロジーについて理解しておく必要があります。


す。


3. インポートする XML データ・ソースをクリックし、「次へ」をクリックします。

同じ名前のオブジェクトのインポートネームスペースは、フォルダーのようなコンテナーです。 IBM CognosFramework Manager プロジェクト内のオブジェクトは一意的に識別可能でなければなりません。同じ名前のオブジェクトを 2 つ持つ場合、それらは 2 つの別個のネームスペースに配置する必要があります。

例えば、財務データを含むデータベースがあるとします。テーブルの 1 つのセットは予測と実際の情報を表しています。予測と実際の情報のどちらにも、買掛金勘定および売掛金勘定という名前のテーブルがあります。これらのテーブルをFramework Manager にインポートし、プロジェクトで同じテーブル名を使用するには、2 つのネームスペースを作成する必要があります。一方のネームスペースをForecast、もう一方のネームスペースを Actual という名前にすることができます。

手順1. モデルまたはルート・ネームスペースをクリックし、「操作」、「作成」、「ネ

ームスペース」の順にクリックします。

2. ネームスペースを右クリックし、「名前を変更」をクリックして、記述名を入力します。


第 5 章リレーショナル・メタデータのモデル作成

注: SAP BW メタデータに関する情報は、別のトピックに記載されています。

メタデータをインポートした後で、それがユーザーのレポート作成要件を満たすようにセットアップされたことを確認し、必要とされる追加情報があれば提供する必要があります。 IBM Cognos Framework Manager での拡張は、元のデータ・ソースに影響を与えません。

ヒント: モデルがレポート作成要件を満たしていることを検証するために、レポートに表示されるオブジェクトを選択してテストできます。テスト結果では、ユーザーに表示されるレポート、および SQL と IBM Cognos Software からのメッセージ(存在する場合) を確認できます。または、いつでもパッケージを発行して、そのパッケージを使用してレポートを作成することもできます。

いつでもプロジェクトを検査して、それに含まれるオブジェクト間の参照が有効であることを確認できます。 277 ページの『モデルまたはパッケージの検証』を参照してください。

少なくとも、インポート・ビューおよびビジネス・ビューの 2 つのビューを作成します。 2 つ以上のビューを作成すると、アイテムを新しいデータ・ソースに再マップすることがさらに容易になります。

インポート・ビューの設定インポート・ビューには、データ・ソースからインポートしたメタデータが含まれます。

インポート・ビューでメタデータが正しく設定されるようにするには、次の操作を実行します。

手順1. レポート作成要件が関係に反映されていることを確認します。

2. クエリー・サブジェクトによって取得されるデータを最適化およびカスタマイズします。

3. ディメンションによって取得されるデータを最適化およびカスタマイズします。ディメンションを別のディメンション・ビューに格納することもできます。

4. 多言語メタデータのサポートを処理します。

5. クエリー・アイテムのプロパティーを確認することにより、データの使用方法および表示方法を制御します。


ビジネス・ビューの設定ビジネス・ビューでは、ユーザーがレポートを作成しやすいように、ソース・データの情報が層状になっています。

ビジネス・ビューでメタデータを拡張するには、次の操作を実行します。

手順1. ユーザーが取得できる情報を定義するビジネス・ルール (計算やフィルターな

ど) を追加します。

2. ユーザーに馴染みのあるビジネス概念を反映する個別のビューをユーザー・グループごとに作成することにより、モデルを整理します。

3. 後でクエリー・アイテム名に対して変更が行われても既存のレポートおよびレポート作成者に影響を与えない永続モデルを作成します。

タスクの結果

「Model Advisor」を使用しメタデータを分析し、モデルが現行のモデル化ガイドラインに従っていることを確認することができます。

関係関係は、モデル内の複数のオブジェクトに対するリレーショナル・クエリーを作成する方法を表します。関係が存在しなければ、これらのオブジェクトは分離したデータ・セットです。

関係は両方向に作用します。関係を十分に理解するためには、しばしば両方向を調べる必要があります。

以下のような、さまざまなタイプの関係があります。

v 1 対 1

1 対 1 の関係は、クエリー・サブジェクトのデータの 1 つのインスタンスが別のデータのインスタンス 1 つだけに関係があるときに存在します。例えば、学生それぞれが 1 つの学生番号を持っています。

v 1 対多またはゼロ対多

1 対多またはゼロ対多の関係は、クエリー・サブジェクトのデータの 1 つのインスタンスが別のデータの多数のインスタンスに関係があるときに存在します。例えば、教師それぞれに多数の学生がいます。

v 多対多

多対多の関係は、クエリー・サブジェクトのデータの多数のインスタンスが別のデータの多数のインスタンスに関係があるときに存在します。例えば、多数の学生に多数の教師がいます。

メタデータのインポート時、IBM Cognos Framework Manager は、データ・ソースの主キーと外部キーに基づいて、モデル内のオブジェクト間の関係を作成できます。モデルがビジネスの論理構造をより適切に表すようにモデル内の関係を作成したり削除したりできます。


メタデータのインポート後、必要な関係がプロジェクトに存在することと、カーディナリティーが正しく設定されていることを検証してください。参照整合性を使用せずにデータ・ソースが設計されている場合があります。多くの場合、さまざまな主キー制約と固有キー制約は指定されていません。これらの制約がなければ、Framework Manager はファクト表とディメンション表の間の必要な関係を生成できません。

Framework Manager は、関係に関与するオブジェクトの最も近い共通の親に関係を格納します。親として、フォルダーまたはネームスペースのどちらかが可能です。関与オブジェクトの 1 つを共通の親の外に移動すると、関係の両端にとって次の共通ネームスペースに関係が移動します。異なるフォルダーまたはネームスペースに関係を移動すると、関与オブジェクトも同じフォルダーまたはネームスペースに移動します。

ヒント: 指定したパターンに名前が一致する Relationship クラスのオブジェクトを検出するには、「検索」タブ (「ツール」ウィンドウ) を使用します。例えば、名前に Order Header が含まれる関係を検索する場合、Framework Manager は一方の端が Order Header である関係をすべて検出します。関係を名前変更した場合、このタイプの検索では名前変更した関係が検出されないことがあります。

カーディナリティー

2 つのクエリー・サブジェクトの間には関係が存在します。関係のカーディナリティーとは、2 つのクエリー・サブジェクトそれぞれにおける、関連する行の数です。行は、関係を表す式によって関連付けられます。通常、この式は、基礎となるテーブルのプライマリー・キーと外部キーを参照します。

IBM Cognos ソフトウェアでは、以下の目的で関係のカーディナリティーを使用します。

v ファクト・データの二重カウントの防止

v スター・スキーマ・モデルでよく発生するループ結合をサポートする

v 基礎となるデータ・ソース・システムへのアクセスの最適化

v ファクトやディメンションとして動作するクエリー・サブジェクトの識別

基礎となるさまざまなテーブルからの複数のファクトを使用するクエリーは、基礎となるファクト表ごとに別個のクエリーに分割されます。それぞれのファクト・クエリーでは、それぞれに該当するファクト表、およびそのファクト表に関連するディメンション表が参照されます。これらの個別のクエリーを 1 つの結果セットに結合するために、別のクエリーが使用されます。この後者の処理を、一般に「スティッチ・クエリー」といいます。 coalesce および完全外部結合が存在する場合、スティッチ・クエリーになります。

さらに、スティッチ・クエリーにより、IBM Cognos ソフトウェアはさまざまな細分性レベルでデータを適切に関連付けることができます。 388 ページの『複数ファクト、複数細分性のクエリー』を参照してください。

すべての関係とカーディナリティーにユーザーのレポート作成要件が反映されるようにする必要があります。

第 5 章リレーショナル・メタデータのモデル作成 73

詳細については、 382 ページの『生成されたクエリーのカーディナリティー』および 383 ページの『クエリーのコンテキスト内のカーディナリティー』を参照してください。

データ・ソースからのカーディナリティーの検出リレーショナル・データ・ソースからインポートする際に、指定した規則のセットに基づいてカーディナリティーが検出されます。

選択可能なオプションは以下のとおりです。

v プライマリー・キーと外部キーを使用

v 一意的にインデックスが付けられた列を表す、一致するクエリー・アイテム名を使用

v 一致するクエリー・アイテム名を使用

最も一般的な状況は、プライマリー・キーおよび外部キーを、一意的に索引付けされた列を表す一致するクエリー・アイテムと共に使用することです。この情報は、クエリー・アイテムのいくつかのプロパティーを設定するため、および関係を生成するために使用されます。

インポートされた索引およびキーの情報を表示するには、クエリー・サブジェクトを右クリックして、「定義を編集」をクリックします。クエリー・サブジェクトの場合、「行列式」タブで情報を変更できます。

オプションの関係、完全外部結合、および多対多の関係は、データ・ソースからインポートできます。 IBM Cognos Framework Manager はそれらをクエリーとして実行します。

注: すべての標準ディメンションはクエリー・サブジェクトとして開始します。クエリー・サブジェクトを標準ディメンションに変換した場合、そのクエリー・サブジェクトの行列式情報が 1 つの階層内のレベルを定義するための開始点として利用されることに注意してください。ディメンションの階層に作成されたレベルおよびキーを確認します。

表記デフォルトで Framework Manager は Merise 表記を使用します。 Merise 表記では、関係の各端に、その端の最小カーディナリティーと最大カーディナリティーがマークされます。 Crowsfeet 表記を使用することもできます。この表記では、関係が図示されます。

表記の変更方法について詳しくは、 17 ページの『ダイアグラムの設定の変更』を参照してください。

カーディナリティーを解釈するとき、関係の両端に表示される表記を確認する必要があります。

可能な終端のラベルには、以下のものがあります。

v 0..1 (ゼロまたは 1 つの一致)

v 1..1 (1 つだけの一致)

v 0..n (ゼロ個以上の一致)


v 1..n (1 つ以上の一致)

表記の最初の部分は、この関係の結合のタイプを示します。

v 内部結合 (1)

内部結合は、両方のオブジェクトからの一致する行をすべて表示します。

v 外部結合 (0)

外部結合は、一致しないアイテムも含む、両方のオブジェクトからのすべてのものを表示します。外部結合は、フル、左、右で修飾できます。左および右の外部結合は、それぞれ関係の左側また右側からすべてのものと、他方の側で一致するものだけを取得します。

内部結合または外部結合のどちらを使用するかによって、ユーザーに表示されるレポートが異なります。例えば、販売員および発注をリストしたレポートをユーザーが必要としているとします。外部結合を使用して販売員と発注とを結び付けた場合、レポートにはすべての販売員が、発注の有無に関わらず表示されます。内部結合を使用した場合、レポートには発注を行った販売員だけが表示されます。

あるオブジェクト内のデータと一致するものが他のオブジェクトには存在しないことがあります。ただし、関係の最小カーディナリティーが 1 の場合、内部結合が常に使用されて、それらのレコードは無視されます。逆に、すべてのアイテムが一致してもモデル内の関係の最小カーディナリティーが 0 の場合、外部結合が常に使用されますが、その結果は内部結合を使用した場合と同じになります。例えば、あるオブジェクトの基礎表に、他のオブジェクトの必須 (NULL にできない) 外部キーが含まれるとします。データとカーディナリティーとが必ず一致するようにしてください。

表記の 2 番目の部分は、オブジェクト間でのクエリー・アイテムの関係を定義します。

生成されたクエリーのカーディナリティー

IBM Cognos ソフトウェアでは、最小/最大カーディナリティーとオプション・カーディナリティーの両方がサポートされています。

0:1 では、0 が最小カーディナリティー、1 が最大カーディナリティーです。

1:n では、1 が最小カーディナリティー、n が最大カーディナリティーです。

1:1 対 1:n のカーディナリティーが指定された関係は、最大カーディナリティーに注目して、一般的に「1 対 n」と呼ばれます。

最小カーディナリティー 0 は、その関係がオプションであることを示しています。一致するものがないときでも関係の他方の側の情報をクエリーに保持するには、最小カーディナリティー 0 を指定してください。例えば、顧客と販売実績の間の関係を 1:1 対 0:n と指定することができます。この指示により、販売データがない場合でも、要求された顧客情報がレポートに表示されます。

したがって、1 対 n 関係を次のように指定することも可能です。

v 0:1 対 0:n


v 0:1 対 1:n

v 1:1 対 0:n

v 1:1 対 1:n

「関係定義」ダイアログ・ボックスの「関係の影響」文を使用すると、カーディナリティーを理解するうえで役立ちます。例えば、Sales Staff (1:1) が Orders (0:n)に結合されています。

カーディナリティーはファクト・クエリー・サブジェクトの検出を決定し、ファクト・データの二重カウントの防止に使用されるため、モデル内のカーディナリティーを正しく指定することが重要です。

クエリーの生成時に、IBM Cognos ソフトウェアは以下の基本的な規則に従ってカーディナリティーを適用します。

v クエリーのコンテキスト内でカーディナリティーが適用されます。

v 1 対 n のカーディナリティーは、n 側がファクト・データを意味し、1 側がディメンション・データを意味します。

v 特定のクエリーに回答するために必要な関係に応じて、クエリー・サブジェクトはファクト・クエリー・サブジェクトまたはディメンション・クエリー・サブジェクトとして動作します。

散在データ分析またはレポートのモデル作成時は、ビジネス上の問題の性質対データ・ソースの性質を考慮することが重要です。

一般的なシナリオとして、スター・スキーマでのディメンションとファクト表の関係はオプションであるということがあります。これは、ファクト表にすべてのディメンション・メンバーが必須であるというわけではないことを意味します。 OLAPエンジンはこれを補償するために、データのないディメンション交点についてはOLAP 構造の作成時に適切な値を挿入します。

例えば、Analysis Studio ユーザーが次のレポートを作成したいとします。

地域 2005 2006

Canada 1,000,000

Mexico 500,000 750,000

United States 1,000,000 1,250,000

モデル作成時に、パフォーマンスを高めるためにディメンションとファクト間のオプションの関係をオーバーライドするのはよくあることです。しかし、ファクトのないディメンション・メンバーに関する情報を必要とする散在データに対して分析


またはレポート作成を行うときは、有効なディメンション交点のデータが返されるように、外部結合を有効にする必要があります。

外部結合を有効にするには、以下のようにします。

v データベース管理者に問い合わせて、データ・ソースが完全外部結合をサポートできることを確認します。

v 外部結合を有効にしてメタデータをインポートします。

関係の変更IBM Cognos Framework Manager でデータをインポートしたり、関係を作成したりした後、関係の名前を変更し、カーディナリティーを再定義することができます。

リストから演算子を選択するか、式エディターで式を手動変更することにより、カスタム関係式を作成することができます。

関係を表す複雑な式を作成することもできます。

オブジェクトを選択し、「ツール」メニューの「コンテキスト・エクスプローラーを起動」をクリックすることにより、オブジェクトの既存の関係を表示できます。

手順1. 関係をクリックし、「操作」、「定義を編集」の順にクリックします。

2. 既存のエレメントを変更するには、「関係式」タブで、目的のクエリー・アイテム、カーディナリティー、および演算子を選択します。

クエリー・アイテムのデータ型は同じでなければなりません。

3. 追加の結合を作成するには、「関係式」タブで「リンクの新規作成」をクリックし、新規関係を定義します。

4. 関係をテストするには、「関係 SQL」タブで、返される行数を識別し、「テスト」をクリックします。


メタデータが OLAP データ・ソースからのものである場合、「閉じる」をクリックします。

関係を表す複雑な式の作成モデルに含まれる関数、パラメーター、およびオブジェクトを使用することにより、関係を表す複雑な式を作成できます。

手順1. 関係をクリックし、「操作」、「定義を編集」の順にクリックします。

2. 「関係式」タブで、「式」ボックスの横にある省略符号 (...) ボタンをクリックします。

3. 式を定義します。


セッション・パラメーターまたはプロンプトを挿入した場合、式のテスト時にそ

れらが表す値を指定するときは、「オプション」ボタン



関係の作成関係を作成することにより、ユーザーが 1 つのレポートにまとめる論理的に関連したオブジェクトを結合します。この操作は、メタデータのインポート時に選択されなかったオブジェクト間の関係、データ・ソースで結合されていなかったオブジェクト間の関係、または複数のソースからのオブジェクト間の関係に有用です。

クエリー・アイテム間の関係を直接作成できます。

関係を表す複雑な式を作成することもできます。

IBM Cognos Framework Manager を使用して、選択した基準に基づいてオブジェクト間の関係を自動的に生成することもできます。

オブジェクトを選択し、「ツール」メニューの「コンテキスト・エクスプローラーを起動」をクリックすることにより、オブジェクトの既存の関係を表示できます。

手順1. 1 つまたは 2 つのディメンション、クエリー・サブジェクト、またはクエリ

ー・アイテムを、Ctrl キーを押しながらクリックします。

2. 「操作」、「作成」、「関係」の順にクリックします。

この関係が関係のショートカットの有効なターゲットであれば、FrameworkManager はその関係へのショートカットを作成するかどうかを尋ねます。詳細については、『関係のショートカットの作成』を参照してください。


「関係定義」ダイアログ・ボックスが表示されます。このダイアログ・ボックスを使用して関係を変更できます。

関係のショートカットの作成関係のショートカットは、既存の関係へのポインターです。関係のショートカットを使用して、既存の関係の定義を再利用できます。ソースとしての関係に対するどのような変更も、ショートカットに自動的に反映されます。関係のショートカットを使用して、クエリー・サブジェクト間の未確定の関係を解決することもできます。

IBM Cognos Framework Manager は、関係が作成されて次の条件が両方とも該当するときは必ず、関係のショートカットを作成するかどうかを尋ねます。

v 新しい関係の少なくとも一方の端がショートカットである。

v 元のオブジェクト間に関係が存在する。


手順1. 関係のショートカットに関与させるオブジェクトを、Ctrl キーを押しながらク

リックします。

2. 「操作」、「作成」、「関係」の順にクリックします。

その関係へのショートカットを作成するかどうかを Framework Manager が尋ねます。

3. 「はい」をクリックします。

一方の端がモデル・オブジェクトで、もう一方の端が別のモデル・オブジェクトかまたは別のモデル・オブジェクトへのショートカットであるすべての関係のリストが表示されます。

4. 両方の端がモデル・オブジェクトかまたはモデル・オブジェクトへのショートカットになるすべての関係を取得するには、「すべて検索」をクリックします。

5. 関係のショートカットのターゲットにする関係をクリックします。


関係の検出と生成IBM Cognos Framework Manager を使用して、モデル内の 2 つ以上の既存のオブジェクトの間の関係を検出および生成することができます。これは、ステージでメタデータをインポートする際や、既存の関係に適用される基準を変更する際に便利です (外部結合を含めるかどうかなど)。

スター・スキーマ・メタデータをインポートする際、命名規則が設定されていなければ、一致する列またはクエリー・アイテム名に基づいて関係を生成することは避けてください。多くの場合、データ・ウェアハウスは、列に対して命名規格を適用します (例えば、ディメンションのサロゲート・キーのデフォルト列名としてsurr_key)。この場合、一致する列名に基づいて関係を生成すると、すべてのディメンション表の間に不適切な関係が生成されます。

手順1. Ctrl を押しながら 2 つ以上のオブジェクトをクリックします。

2. 「ツール」、「関係を検出」の順にクリックします。

3. 各テーブルのペアに適用する規則を選択します。

規則検索結果

プライマリー・キーと外部キーを使用プライマリー・キーと外部キーの関係に基づいて結合を作成します。クエリー・アイテム名が一致している必要はありません。

一意的にインデックスが付けられた列を表す、一致するクエリー・アイテム名を使用

基本となる列の 1 つあるいは両方に一意的にインデックスが付けられる場合、名前とデータ型が一致するクエリー・アイテム間の結合を作成します。


規則検索結果

一致するクエリー・アイテム名を使用名前とデータ型が一致するクエリー・アイテム間の結合を作成します。これは、可能な限り多くの関係を生成します。

4. Framework Manager を使用して以下の間の関係を検出および生成するかどうかを示します。

v 選択されるオブジェクト

v 選択される各オブジェクトと選択されないプロジェクトのすべてのオブジェクト

v 選択されるオブジェクトとプロジェクト内の他のすべてのオブジェクト

5. Framework Manager を使用して外部結合、またはデータ・ソースに存在する外部結合に基づいて内部結合を作成するかどうかを示します。

6. 二重カウントの自動防止を無効にする場合、「ファクト検出が有効」チェック・ボックスをオフにすることにより、すべての n カーディナリティーを 1 に変換します。

詳細については、 381 ページの『第 10 章メタデータ・モデリング・ガイド』を参照してください。


ブリッジ・テーブル論理データ・モデルには、多対多の関係が 1 つ以上含まれている可能性があります。物理データのモデル化の手法では、テーブルを追加することで、多対多の関係を 1 対多の関係に変換します。これらのテーブルをブリッジ・テーブルと呼びます。

ブリッジ・テーブルとファクト・テーブルの間の重要な違いは、ブリッジ・テーブルの関係は必須であるということです。ブリッジ・テーブルの関係では、一方のサブジェクト・エリアから戻されるレコードに基づいて、他方のサブジェクト・エリアからのデータが制限されます。ファクト・テーブルには、この制限はありません。これは、他の 2 つのデータ・セットが一致しないディメンションとして動作するためです。一方のデータ・セットに適用されるフィルターが、他方のデータ・セットに影響を及ぼすことはありません。

ブリッジ・テーブルを作成することには、以下のようないくつかの利点があります。

v ブリッジのそれぞれの側に存在するデータ・ストリームが正しく結合される。

v フィルターが一方のデータ・ストリームだけに適用されても、両方のストリームにフィルター処理が行われる。一方のストリームからのデータが他方のストリームと正しく関連付けられている場合、どの列にフィルターを適用しても、データの行全体がフィルターで除外されます。詳細フィルターおよび概要フィルターを使用できます。

v 二重カウントを避けられる。


例えば、不動産物件および物件の所有者を表す 2 つのスター・スキーマを含むモデルがあるとします。複数の物件が複数の所有者によって所有され共有されています。物件の所有者のスキーマには、OWNER と OWNER_FACT という 2 つのクエリー・サブジェクトが含まれています。物件のスキーマには、PROPERTY と PROPERTY_FACTという 2 つのクエリー・サブジェクトが含まれています。 OWNER テーブルとPROPERTY テーブルの間の多対多の関係をキャプチャーするには、ブリッジ・テーブルを追加します。ブリッジ・テーブルには、OWNER_ID と PROPERTY_ID というクエリー・アイテムが含まれています。関係にコンテキストや意味を加える他のクエリー・アイテム (share_percentage など) も含まれています。ブリッジ・テーブルのカーディナリティーは両方の関係で [1..n] で、OWNER テーブルおよび PROPERTY テーブルのカーディナリティーは [1..n] です。

以下の図のテーブル OWNER_PROPERTY_BRIDGE は、物件の所有者および所有者が所有する物件を取得するために作成されています。

クエリーを実行すると、動的クエリー・モードがどのテーブルを結合する必要があるのかを判別します。 1 対多の関係の多の側にあるクエリー・サブジェクトは、ファクトとして扱われます。前の図では、1 対多の関係があるためにOWNER_PROPERTY_BRIDGE がファクトと見なされます。そのため、期待する結果セットがクエリーから返されない可能性があります。

クエリー・サブジェクトには、「ブリッジ」という値を設定できる使用プロパティーがあります。このプロパティーによって、動的クエリー・モードは、クエリー・サブジェクトが 1 対多の関係であるからといってファクトではないことを認識し、クエリーを生成することができます。 1 つのモデルに複数のブリッジが含まれる可能性があります。

v 1 人の所有者が複数の物件を所有する可能性があります。

v 1 つの物件に複数の所有者が存在する可能性があります。

v 1 つの物件に同じ請負業者との複数の保守契約が存在する可能性があります。

次の図で例を示します。

図 1. ブリッジ・テーブルによる 2 つのスキーマの結合


制約事項

ブリッジ・テーブルには、次の制約があります。

v 動的クエリー・モードでは、ディメンション間の多対多の関係を解決するためにブリッジ・テーブルが使用されていることを前提としています。ディメンション・テーブルとファクト・テーブルの間にブリッジ・テーブルを導入する設計手法はサポートされていません。

v 動的クエリー・モードには、2 つのクエリー・サブジェクトの間のあいまいでない結合パスが必要です。以下の図のモデルは、OWNER と PROPERTY の間の 2 つの結合パスを定義しています。

クエリーで OWNER、PROPERTY、および CONTRACTOR のアイテムのみが参照されている場合、動的クエリー・モードは、どのブリッジ・テーブルを使用すべきか判別できないため、以下のエラーを返します。

– クエリー 'Query1' には、[VIEW].[OWNER_PROPERTY_BRIDGE]、[VIEW].[OWNER_PROPERTY_BROKER_BRIDGE] という複数の並列ブリッジ・クエリー・サブジェクトに対する暗黙的および明示的な参照が含まれています。

v グループ化されたヘッダー/フッターが動的クエリー・モードによって自動的に計算される場合、レポートに集計が含まれる可能性があります。クエリーには、データをフィルタリングしたり、新しい属性や数値データを計算したりする式を

図 2. 複数のブリッジ・テーブルによる 2 つのスキーマの結合

図 3. ブリッジ・テーブルによる 2 つのスキーマの結合


含めることもできます。ブリッジ・クエリー・サブジェクトが存在するシナリオでは、動的クエリー・モードがエラーを返す可能性があります。

v アイテムまたはフィルターを使用するストリング、算術、または論理式で、ブリッジ・クエリー・サブジェクトのいずれかの側のクエリー・サブジェクトのアイテムを参照することはできません。

– このクエリーはサポートされていません。クエリー 'Query1' には、ブリッジ・クエリー・サブジェクトの反対側を参照する式を持つデータ・アイテム'FullName' が含まれています。

– このクエリーはサポートされていません。クエリー 'Query1' には、ブリッジ・クエリー・サブジェクトの反対側を参照する式を持つ詳細フィルターが含まれています。

– このクエリーはサポートされていません。クエリー 'Query1' には、ブリッジ・クエリー・サブジェクトの反対側を参照する式を持つ概要フィルターが含まれています。

v データの自動グループ化および集計を実行するようにクエリーを設定する必要があります。動的クエリー・モードでは、ブリッジ・クエリー・サブジェクトのいずれかの側のサブジェクトのアイテムを射影する詳細クエリーは使用できません。

– このクエリーはサポートされていません。クエリー 'Query1' はブリッジ・クエリー・サブジェクトを参照するため、プロパティー '自動グループ化および集計' を「いいえ」に設定できません。

v 集計値を計算するアイテムに pre-filter 節を含めることはできません。

– クエリー 'Query1' には、プレフィルター集計式を持つデータ・アイテム'PrefilteredTotal' が含まれています。これは、クエリーがブリッジ・クエリー・サブジェクトを参照する場合にはサポートされません。

v ブリッジ・クエリー内での平均の集計はサポートされていません。デフォルトの集計が平均に設定されているファクトを参照するブリッジ・クエリーは、以下のエラーで失敗します。

– このクエリーはサポートされていません。クエリー 'Query1' には、暗黙的な平均集計式を持つデータ・アイテム 'costs' が含まれています。これは、クエリーがブリッジ・クエリー・サブジェクトを参照する場合にはサポートされません。

v 分析式はサポートされておらず、以下のエラーを生成します。

– このクエリーはサポートされていません。クエリー 'Query1' には、分析の集計式を持つデータ・アイテム 'theRank' が含まれています。これは、クエリーがブリッジ・クエリー・サブジェクトを参照する場合にはサポートされません。

– このクエリーはサポートされていません。クエリー 'Query1' には、移動集計式を伴うデータ・アイテム 'nextRow' が含まれています。これは、クエリーがブリッジ・クエリー・サブジェクトを参照する場合にはサポートされません。

v ブリッジ・クエリーを含めた場合、クロス集計レポートのサポートが非常に制限されます。このような状況で生成される主なエラーを次に示します。

– このクエリーはサポートされていません。ブリッジ・テーブルにアクセスする場合にサポートされるのは、単純なクロス集計クエリーのみです。


– このクエリーはサポートされていません。クエリー 'Query1' には、関係クロス集計ではサポートされない明示的な集計式が含まれています。

v DMR パッケージに対して作成されたレポート。一般的には、ブリッジ・テーブルのロジックが実装されている場所であるリレーショナル・プロバイダーにクエリー全体をプッシュする必要があります。クエリーでローカル OLAP 処理が必要な場合、ブリッジ機能を適用できず、以下のエラーが生成されます。

– このクエリーはサポートされていません。 DMR クエリー 'Query1' にはOLAP 処理 (サブクエリーがブリッジ・クエリー・サブジェクトを参照する場合にはサポートされない) が必要です。

v ピュア・リレーショナル・クエリーと同様、ハンド・コーディングされた集計式はサポートされないため、以下のエラーが生成されます。

– このクエリーはサポートされていません。クエリー 'Query1' には、DMR モデルに対してサポートされない明示的な集計式が含まれています。

v カスタム集計式。これらは通常、レポートのヘッダーおよびフッターに関連付けられます。単純なハンド・コーディング式 (所有者の propertyValue に対するTotal など) はサポートされる可能性がありますが、複雑な式では、以下のエラーが生成されます。

– このクエリーはサポートされていません。ブリッジ・テーブルがアクセスしている場合、カスタム・フッター式はサポートされません。



クエリー・サブジェクトによって取得されるデータを最適化およびカスタマイズするために、IBM Cognos Framework Manager を使ってクエリー・サブジェクトを変更します。例えば、フィルターや計算を追加することができます。クエリー・サブジェクトの定義を変更すると、Framework Manager は関連するクエリー・アイテムを再生成します。これにより、クエリー・サブジェクトのプロパティーのすべての変更点が、そのクエリー・サブジェクトに属するすべてのクエリー・アイテムに確実に反映されます。

Framework Manager には、以下のような種類のクエリー・サブジェクトがあります。

v データ・ソース・クエリー・サブジェクト

v モデル・クエリー・サブジェクト

v ストアード・プロシージャー・クエリー・サブジェクト

さらに、 394 ページの『クエリー・サブジェクトとディメンション』も参照してください。

データ・ソース・クエリー・サブジェクトリレーショナル・メタデータに基づくクエリー・サブジェクトは、データ・ソースからデータを取得する方法を記述した SQL ステートメントによって定義されます。


データ・ソース・クエリー・サブジェクトは、単一のデータ・ソース内のデータを直接参照します。 IBM Cognos Framework Manager は、ユーザーがモデルにインポートしたテーブルおよびビューごとに、データ・ソース・クエリー・サブジェクトを自動的に作成します。

例えば、Great Outdoors Warehouse サンプル・データベースから従業員詳細ファクト・テーブルをインポートするとします。その後、Framework Manager は次のSQL ステートメントを使用してクエリー・サブジェクトを作成します。

Select * from [go_data_warehouse].EMPLOYEE_DETAIL_FACT

Framework Manager は、データ・ソースからのテーブル形式のデータを表すクエリー・サブジェクトを生成します。例えば、テーブル全体を参照するクエリー・サブジェクトは、そのテーブル内の各列を表すクエリー・アイテムを含みます。 SQLが特定の列だけを選択する場合、それらの列だけがクエリー・アイテムとして表されます。

各データ・ソース・クエリー・サブジェクトは、一度に 1 つのデータ・ソースからのデータだけを参照できます。ただし、データ・ソース・クエリー・サブジェクトの利点は、取得するデータを定義する SQL を直接編集できることです。つまり、クエリーが取得するデータを制御するためのパラメーターを挿入して、任意の SQLに基づくクエリー・サブジェクトを作成できます。

列およびテーブルに対する参照を引用符で囲まずに、クエリー・サブジェクトのSQL ステートメントを作成している場合があります。この方法は、解析するメタデータ・テーブルに対して大/小文字を区別する検索を使用しないリレーショナル・データ・ソース環境で有効です。クエリー・サブジェクトの SQL ステートメントは、Cognos SQL、ネイティブ SQL、またはパススルー SQL となります。ネイティブ SQL ステートメントおよびパススルー SQL ステートメントは、必要なものを完備している必要があり、その SQL の外部にあるもの (データベース・プロンプト、変数、通常は呼び出し元アプリケーションによって提供されるネイティブ・フォーマットなど) を参照することはできません。一方、Cognos SQL ステートメントは、モデルまたはリレーショナル・データ・ソースからのメタデータを使用して分析されます。デフォルトで、Cognos SQL は大/小文字を区別するので、SQL ステートメント内に示されたとおりの名前を使用してメタデータを検索します。

クエリー・サブジェクトに複数のデータ・ソースを使用するには、データ・ソースのクエリー・サブジェクトまたは他のモデル・クエリー・サブジェクトにアクセスするモデル・クエリー・サブジェクトを使用します。

データ・ソース・クエリー・サブジェクトの作成データ・ソース・クエリー・サブジェクトは、単一のデータ・ソース内のデータを直接参照します。 IBM Cognos Framework Manager は、ユーザーがモデルにインポートしたテーブルおよびビューごとに、データ・ソース・クエリー・サブジェクトを自動的に作成します。データ・ソース・クエリー・サブジェクトは追加作成することができます。

クエリー・サブジェクトには、クエリー・アイテム、他のクエリー・サブジェクト、またはディメンションなどのオブジェクトを任意に組み合わせて追加することができます。独立した計算およびフィルターを追加することができ、計算およびフィルターをクエリー・サブジェクトに埋め込むこともできます。


モデル・クエリー・サブジェクト (モデルに存在するメタデータに基づく) や、ストアード・プロシージャー・クエリー・サブジェクト (リレーショナル・データ・ソースのストアード・プロシージャーから生成される) を作成することもできます。

手順

1. ネームスペース・フォルダーを選択し、「操作」、「作成」、「クエリー・サブジェクト」の順にクリックします。

2. 「名前」ボックスに、新しいクエリー・サブジェクトの名前を入力します。

3. 「データ・ソース」、「OK」の順にクリックします。

4. 「新しいクエリー・サブジェクト」ウィザードですべての手順を実行します。

データ・ソースがデータ・ソース・クエリー・サブジェクトに対して一意的に識別されるようにするために、「終了」ボタンが表示されるまではウィザードを終了しないでください。


6. 作成したクエリー・サブジェクトを右クリックして「定義を編集」をクリックします。

7. 「SQL」タブをクリックし、「使用可能なデータベース・オブジェクト」ボックスから「SQL」ボックスにオブジェクトをドラッグします。

プロジェクトに複数のデータ・ソースが含まれており、さまざまなデータ・ソースからクエリー・サブジェクトにオブジェクトを追加するには、「データ・ソースを挿入」をクリックし、必要なデータ・ソースを選択して、「OK」をクリックします。

マクロを挿入したり、計算やフィルターを組み込んだりすることもできます。詳細については、 166 ページの『計算の作成』または 169 ページの『フィルターの作成』を参照してください。

8. 実行する操作を選択します。

目的操作

細分性を制御する「行列式」タブをクリックします。 94 ページの『行列式』を参照してください。

クエリー・サブジェクトをテストする「テスト」タブをクリックします。 103 ページの『クエリー・サブジェクトまたはクエリー・セットのテスト』を参照してください。

SQL を表示する「クエリー情報」タブをクリックします。 109 ページの『SQL の編集』を参照してください。

データ・ソースのシステム・テーブルを表示する

「システム・オブジェクトを表示」チェック・ボックスをオンにします。



変更によって無効にされた関係、他のクエリー・サブジェクト、計算、またはフィルターがある場合、警告が表示されます。

10. 「使用方法」および「標準集計」プロパティーが正しく設定されていることを確認します。 150 ページの『クエリー・アイテムの集計方法の変更』を参照してください。

モデル・クエリー・サブジェクト

モデル・クエリー・サブジェクトは、データ・ソースから直接生成されるのではなく、他のモデル・クエリー・サブジェクトも含め、他のクエリー・サブジェクトまたはディメンション内のクエリー・アイテムをベースにしています。モデル・クエリー・サブジェクトを使用することによって、データ・ソースの、より抽象的でビジネス指向のビューを作成できます。

通常、モデル・クエリー・サブジェクトはインポート・ビューではなくビジネス・ビューに作成されます。ビジネス・ビューについて詳しくは、 191 ページの『モデルの編成』を参照してください。

モデル・クエリー・サブジェクトは、モデル内のメタデータに基づいているので、それにより以下の操作が可能になります。

v モデル内に存在する複雑な SQL ステートメントの再利用

v 同じクエリー・サブジェクト内の別のデータ・ソースからのオブジェクトの参照

モデル・クエリー・サブジェクトを別のモデルからインポートする場合は、モデル・クエリー・サブジェクトが参照するデータ・ソース・クエリー・サブジェクトもインポートしなければ、モデル・クエリー・サブジェクトは機能しません。

SQL を編集する場合、モデル・クエリー・サブジェクトをデータ・ソース・クエリー・サブジェクトに変換する必要があります。

リレーショナル・メタデータのモデル・クエリー・サブジェクトの作成モデル・クエリー・サブジェクトは、他のクエリー・サブジェクトまたはディメンション内のクエリー・アイテム (他のモデル・クエリー・サブジェクトも含む) をベースにしています。モデル・クエリー・サブジェクトを使用することによって、データ・ソースの、より抽象的でビジネス指向のビューを作成できます。

クエリー・サブジェクトには、クエリー・アイテム、他のクエリー・サブジェクト、またはディメンションなどのオブジェクトを任意に組み合わせて追加することができます。独立した計算およびフィルターを追加することができ、計算およびフィルターをクエリー・サブジェクトに埋め込むこともできます。

既存のクエリー・サブジェクトおよびクエリー・アイテムにマージすることにより、新規モデル・クエリー・サブジェクトを作成することができます ( 98 ページの『既存のオブジェクトに基づくモデル・クエリー・サブジェクトの作成』)。単一データ・ソースのデータを直接参照するデータ・ソース・クエリー・サブジェクトや ( 84 ページの『データ・ソース・クエリー・サブジェクト』)、リレーショナル・データ・ソースのストアード・プロシージャーから生成されるストアード・プ


ロシージャー・クエリー・サブジェクト ( 89 ページの『ストアード・プロシージャー・クエリー・サブジェクト』) を作成することもできます。

IBM Cognos Studio/Authoring ツールでモデル・クエリー・サブジェクトを使用する際、IBM Cognos Analytics は、基本となるデータ・ソース・クエリー・サブジェクトに対して定義した関係ではなく、モデル・クエリー・サブジェクトに対して定義した関係を使用します。基本となるデータ・ソース・クエリー・サブジェクトに対して定義された関係が使用されるようにする場合、モデル・クエリー・サブジェクトに対して関係または行列式を定義しないでください。

手順

1. ネームスペース・フォルダーを選択し、「操作」、「作成」、「クエリー・サブジェクト」の順にクリックします。


3. 「モデル」、「OK」の順にクリックします。

4. 「クエリー・サブジェクト定義」タブをクリックします。

5. アイテムをモデル・クエリー・サブジェクトに追加するには、アイテムを「使用可能なモデル・オブジェクト」ボックスから「クエリー・アイテムと計算」ボックスにドラッグします。

アイテムおよび計算の順序は変更可能です。ただし、クエリー・サブジェクトにクエリー・アイテム・フォルダーが含まれる場合、順序の変更は「プロジェクト・ビューアー」でのみ行えます。

6. フィルターを埋め込むこともできます。

計算またはフィルターをモデル・クエリー・サブジェクトに追加した場合、Framework Manager は単にモデルにアクセスするのではなく、データ・ソースに進む必要があります。

7. クエリー・サブジェクトをテストする場合、「テスト」タブをクリックします。



9. 「使用方法」および「標準集計」プロパティーが正しく設定されていることを確認します。

タスクの結果

関連トピックは、以下のとおりです。

v 埋め込み計算 ( 261 ページの『計算の作成 (SAP BW)』)

v 埋め込みフィルター ( 263 ページの『フィルターの作成 (SAP BW)』)

v テストおよびテストの設定オプション ( 234 ページの『ディメンションまたは他のオブジェクトのテスト (SAP BW)』)

v 複数のクエリー・サブジェクトのプロパティーの同時変更 ( 19 ページの『複数のプロパティー値の置換』)


ストアード・プロシージャー・クエリー・サブジェクトストアード・プロシージャー・クエリー・サブジェクトは、リレーショナル・データ・ソースからプロシージャーをインポートするときに生成されます。IBM CognosFramework Manager では、ユーザー定義のストアード・プロシージャーのみがサポートされます。システム・ストアード・プロシージャーはサポートされません。

プロシージャーが返す可能性のある結果セットの記述を取得するには、プロシージャーを Framework Manager で実行する必要があります。

ストアード・プロシージャーは、単一の一様結果セットを返さなければなりません。IBM Cognos Analytics は、最初に返される結果セットのみサポートします。プロシージャーが条件付きで異なる結果セットを返すことができる場合は、形式がFramework Manager でメタデータの定義に使用されるものと整合していなければなりません。

各結果セットは、列の数、タイプ、名前が同じなど、同じ形式を返さなければなりません。 IBM Cognos Analytics で多重定義シグニチャーがサポートされていますが、各プロシージャーは、結果セットごとに別個のクエリー・サブジェクトを持つ、一意的に指定されるプロシージャーとして定義されなければなりません。

出力パラメーターはサポートされていません。

ストアード・プロシージャー・クエリー・サブジェクトをインポートまたは作成すると、破損オブジェクトとして表示されます。それを実行して基礎ストアード・プロシージャーを検証し、射影のリストを指定する必要があります。リレーショナル・データ・ソースのストアード・プロシージャーの場合、結果セットがどのようなものかを示す静的メタデータはしばしば存在しません。実行時にのみ結果セットが分かる場合があります。データ・ソースでストアード・プロシージャーが更新された場合、Framework Manager でストアード・プロシージャーを実行すると、新たに生成されたクエリー・アイテムを使用してクエリー・サブジェクトが更新されます。

関数がストアード・プロシージャー・クエリー・サブジェクトとしてインポートされることがあります。ストアード・プロシージャー定義を参照して、プロシージャーに渡す必要があるものとプロシージャーが返そうとするものを確認します。関数の可能性があると思える各ストアード・プロシージャー・クエリー・サブジェクトを編集してテストします。テストが失敗した場合は、クエリー・サブジェクトは関数であり、削除する必要があります。

詳細については、 90 ページの『ストアード・プロシージャー・クエリー・サブジェクトの作成または変更』を参照してください。

Informix データ・ソースのストアード・プロシージャー

Informix Dynamic Server または Parallel Server データ・ソースのストアード・プロシージャーがある場合は、パラメーターを編集する必要があります。ストアード・プロシージャーのオリジナル・ソースを参照して、ストアード・プロシージャーが正しくマップされていることを確認してください。


Informix 7.x および 8.x は、ストアード・プロシージャーの名前のみ FrameworkManager に提供します。結果セットを取得できるように、すべてのパラメーター(パラメーター名、データ型、モード、サイズ、精度、小数部桁数、値など) を指定する必要があります。 Informix 9.x は、ストアード・プロシージャーとユーザー定義関数のメタデータに、デフォルトのパラメーター値を提供します。すべてのパラメーターを使用前に確認してください (特にモード属性)。

Informix 関数は、ストアード・プロシージャーとしてインポートされます。インポートした後、「定義を編集」ダイアログ・ボックスの「f(x)」ボタンをクリックして、関数に変更する必要があります。このボタンは、これらの関数に対してのみ有効です。次に、結果を表す引数を選択するか、テスト結果から得た値を使用します。

Composite Information Server のストアード・プロシージャー

Composite Information Server のストアード・プロシージャーがある場合は、ストアード・プロシージャーのオリジナル・ソースを参照して、ストアード・プロシージャーが正しくマップされていることを確認してください。

Composite 関数は、ストアード・プロシージャーとしてインポートされます。インポートした後、「定義を編集」ダイアログ・ボックスの「f(x)」ボタンをクリックして、関数に変更する必要があります。このボタンは、これらの関数に対してのみ有効です。次に、結果を表す引数を選択するか、テスト結果から得た値を使用します。

ストアード・プロシージャー・クエリー・サブジェクトの作成または変更ストアード・プロシージャー・クエリー・サブジェクトの変更は、インポートまたは作成後に行えます。整合性を保つために、変更されたクエリー・サブジェクトは、元のストアード・プロシージャーと同じ結果セット構造を返す必要があります。

IBM Cognos Framework Manager では、ユーザー定義のストアード・プロシージャーのみがサポートされます。システム・ストアード・プロシージャーはサポートされません。

ストアード・プロシージャーにはさまざまなタイプがあります。


ストアード・プロシージャーのタイプ説明

データ・クエリー読み取り専用トランザクションを発行します。

ストアード・プロシージャーのタイプが「データ・クエリー」に設定されている場合、ストアード・プロシージャーは読み取り専用トランザクションを発行します。 EventStudio でストアード・プロシージャーを実行すると、ストアード・プロシージャーによってデータベースが更新されることを示すエラー・メッセージが出されます。エラーの原因は、基本となるデータベースによってサポートされるパッシブ・トランザクションがストアード・プロシージャーに含まれていることにあります。このエラーは、「OK」をクリックしてストアード・プロシージャーによってデータベースが更新されるようにすることによって解決できます。これ以外のアクションは必要ありません。

データ変更レコードをデータ・ソースに書き込みます。Event Studio でストアード・プロシージャーを使用する際にこのタイプを使用します。

Event Studio ユーザーがタスクでパラメーターを選択できるようにする場合、パラメーターの前後に引用符を付ける必要があります。

警告: 「定義を編集」ダイアログ・ボックスでデータ変更ストアード・プロシージャーをテストすると、データがデータ・ソースに作成されます。 Framework Manager でトランザクションをデータ・ソースにロールバックすることはできません。ストアード・プロシージャーのテストの結果として不要なデータがデータ・ソースに作成される場合、データ・ソースでロールバックが行えるように設定されていれば、データベース管理者はロールバックを行うことができます。データソースにデータを書き込まずにストアード・プロシージャーをテストするには、「ツール」メニューから「テスト」をクリックします。

単一データ・ソースのデータを直接参照するデータ・ソース・クエリー・サブジェクトや ( 84 ページの『データ・ソース・クエリー・サブジェクト』)、モデルに存在するメタデータに基づくモデル・クエリー・サブジェクト ( 87 ページの『モデル・クエリー・サブジェクト』) を作成することもできます。


手順

1. 次の操作を実行します。

目的操作

ストアード・プロシージャー・クエリー・サブジェクトを作成する

ネームスペース・フォルダーを選択し、「操作」メニューから、「作成」、「クエリー・サブジェクト」の順にクリックします。

「名前」ボックスに、新しいクエリー・サブジェクトの名前を入力します。

「ストアード・プロシージャー」をクリックし、「OK」をクリックします。

「新しいクエリー・サブジェクト」ウィザードですべての手順を実行します。

ストアード・プロシージャー・クエリー・サブジェクトを変更する

変更するストアード・プロシージャー・クエリー・サブジェクトを選択します。

「操作」メニューの「定義を編集」をクリックします。

2. 「定義」タブをクリックし、実行する操作を選択します

目的操作

別のストアード・プロシージャーを使用する「ストアード・プロシージャー名」ボックスで、ストアード・プロシージャーの名前を入力します。

ストアード・プロシージャーのタイプを変更する

「タイプ」ボックスで、「データ・クエリー」または「データ変更」を選択します。

ストアード・プロシージャーを格納するデータ・ソースを変更する

「データ・ソース」ボックスの横の省略符号(...) ボタンをクリックします。

ストアード・プロシージャーをインポートすると、新規データ・ソースが作成されます。元のデータ・ソースを指し、新規データ・ソースを削除することができます。

引数を編集する引数をクリックし、省略符号 (...) ボタンをクリックします。

「クエリー・サブジェクト定義」ダイアログ・ボックスの「構文」ボックスに、使用する正しい構文が表示されます。


目的操作

予測されるクエリー・アイテムを生成する「テスト」タブをクリックします。 103 ページの『クエリー・サブジェクトまたはクエリー・セットのテスト』を参照してください。


Framework Manager はストアード・プロシージャーを実行し、クエリー・サブジェクトが結果セットを返す場合に、クエリー・サブジェクトを検証します。

ストアード・プロシージャーが結果セットを返さない場合、クエリー・サブジェクトはモデルに保存されると無効なクエリー・サブジェクトになります。無効なクエリー・サブジェクトが発行済みのパッケージに組み込まれる場合、無効なクエリー・サブジェクトはレポートで使用できません。

4. 新規作成される各クエリー・アイテムの「使用方法」および「標準集計」プロパティーが正しく設定されていることを確認します。

例えば、クエリー・アイテムが ID である場合、ファクトとして設定される可能性があります。

タスクの結果

データ・ソースが変更される場合、ストアード・プロシージャー・クエリー・サブジェクトを更新することができます。 108 ページの『クエリー・サブジェクトの更新』を参照してください。

例 - ストアード・プロシージャーでのプロンプトの使用ストアード・プロシージャーの変数に対してプロンプトを定義すると、ユーザーはレポートで変数を設定できるようになります。

手順

1. sp_FIND_ORDER_DATE ストアード・プロシージャーを使用するストアード・プロシージャー・クエリー・サブジェクトを作成します。

「クエリー・サブジェクト定義」ダイアログ・ボックスが表示されます。

2. 「定義」タブで @order_number 引数を選択し、省略符号 (...) ボタンをクリックします。

3. 「値」ボックスに以下のマクロ構文を入力し、「OK」をクリックします。

#prompt('Order Number','integer')#

注: 番号記号の外側にあるものはすべて、マクロ実行時に Framework Managerによって削除されます。

4. 変数に関してプロンプトをテストする場合は、次の操作を実行します。

v 「テスト」、「テスト・サンプル」の順にクリックします。

「プロンプト値」ダイアログ・ボックスが表示されます。


v 「名前」列で発注番号をクリックします。

v 「値」フィールドに「1234」と入力し、「OK」をクリックします。

発注番号 1234 の日付を示す 1 つのレコードが返されます。

Framework Manager は現行セッション中、あるいはプロンプト値をクリアするまでこの値を使用します。


行列式

行列式は、クエリー・サブジェクトでのデータのサブセットやグループを表現することにより細分性を表します。行列式を使用すると、この反復データが正しく集計されるようになります。行列式は、データ・ソースにおけるキー/インデックスの概念と最も密接な関連があり、データ・ソース内の固有キー/インデックス情報に基づいてインポートされます。インポートされる行列式を常に確認し、必要に応じて変更するか、追加の行列式を作成することを推奨します。行列式を変更すると、データ・ソースのインデックス/キー情報をオーバーライドして、レポートや分析のニーズにより適合する情報に置き換えることができます。行列式を追加すると、アプリケーションに関連する反復データのグループを表すことができます。

次の "Time" の例では、"Day" (日) が一意の行列式になっています。一意でない行列式の例は "Month" です。"Month" のキーは、特定の月の日数だけ反復されます。

一意でない行列式を定義するときには、グループ化を指定してください。この指示により、IBM Cognos ソフトウェアは、その行列式に関連付けられているキーや属性がデータ内で繰り返されるときに、二重カウントを避けるための集計関数とグループ化を適用します。一意に識別とグループ化の両方を選択した行列式や、どちらも選択しない行列式を指定しないようお勧めします。

Year Key Month Key Month Name Day Key Day Name

2006 200601 January 06 20060101 Sunday, January1, 2006

2006 200601 January 06 20060102 Monday,January 2, 2006

このデータ・セットには、2 つの「グループ化」行列式 (Year と Month)、および1 つの一意な行列式 (Day) の合計 3 つの行列式を定義できます。この概念はレベルや階層の概念と似ていますが、まったく同じではありません。

行列式の名前キー属性一意に識別グループ化

年 Year Key なしいいえはい

月 Month Key Month Name いいえはい



日 Day Key Day Name

Month Key

Month Name

Year Key

はいいいえ

この場合、データ内のグループを識別するのに十分な情報が各キーに含まれているため、それぞれの行列式で 1 つのキーだけを使用します。 Month のキーには、どの年の月であるかを判別するための十分な情報が含まれていないことが多いため、問題となる可能性が高いですが、 Month のキーが特定の年の月を一意的に識別できない場合、Month の行列式のキー定義に Year キーを組み込みます。

注: 年を考慮せずに月をグループ化する行列式を作成することも可能ですが、2006年 2 月のすべてのデータが一緒にグループ化される代わりに、すべての年の 2 月のデータがすべて一緒にグループ化されるため、レポート作成ではこの方法はあまり使用されません。

行列式をいつ使用するか

行列式を使用するとデータの細分性に関するさまざまな問題を解決できますが、次に示すような主要なケースでは、常に行列式を使用してください。

v ディメンションとして動作するクエリー・サブジェクトに複数の細分性レベルがあり、異なるキーのセットでファクト・データに結合される場合。

例えば Time に複数のレベルがあり、Month キーで Inventory (在庫) に結合され、Day キーで Sales (売上) に結合される場合が考えられます。

詳細については、 388 ページの『複数ファクト、複数細分性のクエリー』を参照してください。

v 反復されるキーまたは属性に対して、カウントまたは他の集計関数を実行する必要がある場合。

例えば Time には Month キーおよび (すべての日で反復される) Days in themonth 属性があります。レポートで Days in the month を使用する場合、月の各日の「Days in the month」(月の日数) を合計するのは無意味です。その代わりに、選択した Month キーに対応する Days in the month の固有値が必要です。 SQL では、XMIN(Days in the month for Month_Key) となります。また、Cognos SQL には Group by 節もあります。

また、次のようなやや特殊なケースでも、行列式が必要になります。

v データ・ソースからテキスト BLOB データを取得するとき、データ行を一意に識別する必要がある。

BLOB を照会するときには、追加的なキーまたはインデックス・タイプの情報が必要です。データ・ソースの中にこの情報がない場合、行列式を使ってそれを追加できます。レポート用に作成された関係と競合する、データ・ソースからインポートされた行列式をオーバーライドしてください。


クエリー・サブジェクトが BLOB データにアクセスする場合、複数セグメントのキーを使用することはできません。集計クエリーでは、クエリーの集計部分とは別個に BLOB データを取得する必要があります。そうするには、行を一意に識別する、複数のセグメントを持たないキーが必要です。

v クエリー・サブジェクトに関して指定されている一意な行列式よりも少ないキーを使用する結合が指定されている。

関係の 0..1 側または 1..1 側にある一意な行列式のキーによって参照される列のサブセットに基づいて結合が構築されている場合、競合が発生します。この競合を解決するには、行列式に完全に適合するよう関係を変更するか、関係をサポートするよう行列式を変更します。

v レポート用に作成された関係と競合する、データ・ソースからインポートされた行列式をオーバーライドする必要がある。

例えば、複数の列に関して 2 つのクエリー・サブジェクトで行列式が存在し、クエリー・サブジェクト間の関係ではこれらの列のサブセットだけが使われるような場合が考えられます。関係の中で追加の列を使用するのが不適切な場合には、クエリー・サブジェクトの行列式の情報を変更してください。

行列式の指定行列式は、クエリー・サブジェクトの細分性を制御します。

クエリー・サブジェクトに行列式がある場合、クエリー・サブジェクトの各クエリー・アイテムを行列式のいずれかに含める必要があります。

行列式は、モデルで指定されている順序で処理されます。行列式の順序は変更可能です。クエリー・サブジェクトに複数の行列式が存在する場合、要求されるすべてのアイテムをカバーしている最初の行列式が使用されます。行列式は、必要な各結合のコンテキスト、および要求される項目のコンテキストで評価されます。

行列式が定義されているデータ・ソース・クエリー・サブジェクトがインポートされます。これらのデフォルトの行列式は、データ・ソースのキーとインデックスに基づいて生成されます。

モデル・クエリー・サブジェクトの行列式は、自動的には定義されません。行列式が必要な場合、手動で定義する必要があります。

ストアード・プロシージャー・クエリー・サブジェクトは、行列式を持ちません。

Reporting で定義されているクエリーで指定された、ユーザーが入力する SQL で行列式を使用することはできません。

手順

1. 目的のクエリー・サブジェクトをクリックし、「操作」、「定義を編集」をクリックします。

2. 「行列式」タブをクリックします。

3. 「行列式」ボックスの下の「追加」をクリックします。


エントリー「新しい行列式」がボックスに表示されます。このエントリーに意味のある名前を付けるには、エントリーを右クリックし、「名前を変更」をクリックします。

4. キーを定義するには、「使用できるアイテム」ボックスのクエリー・アイテムを右クリックし、「鍵として追加」をクリックします。

ヒント: クエリー・アイテムを「キー」ボックスにドラッグすることもできます。

5. この行列式と関連付ける必要があるクエリー・アイテムを識別するには、「使用できるアイテム」ボックスのクエリー・アイテムを右クリックし、「属性として追加」をクリックします。

ヒント: クエリー・アイテムを「属性」ボックスにドラッグすることもできます。

行列式に属性を定義しないようにすることもできます。 Framework Managerはこのタイプの行列式を使用して、インデックスが付けられたクエリー・アイテムを示します。

6. 選択された行列式を一意の識別子として使用することを指定するには、「一意に識別」チェック・ボックスをオンにします。

これは、このアイテムのデータが基本データ・ソースのすべての行で固有の場合にのみ行ってください。

固有であることに間違いなければ、複数の固有の行列式を指定することができます。クエリーの際に、使用する固有の行列式が、使用される関係によって決定されます。

7. 「グループ化」チェック・ボックスをオンにして、その行列式に関連付けられているキーや属性がデータ内で繰り返されるときに、二重カウントを回避するための集計関数とグループ化が IBM Cognos Analytics で適用されることを指定します。

8. 行列式の順序を変更する場合、矢印ボタンを使用します。

行列式は、モデルで指定されている順序で処理されます。


タスクの結果

詳細については、 384 ページの『行列式』および 419 ページの『第 11 章 IBMCognos ソフトウェアによって生成される SQL』を参照してください。

SQL に対する行列式の影響生成される SQL に対する行列式の影響を理解していることは大切です。行列式は、そのクエリー・サブジェクトと関係のある他のクエリー・サブジェクトとそのクエリー・サブジェクト自体とを含む、データのグループ化と集計に影響を与えます。

例えば、次の情報を検討してください。各製品ラインには、製品タイプの多数のオカレンスが含まれます。各製品タイプには、製品の多数のオカレンスが含まれま


す。製品では、製品キーがサロゲート・キーで、製品番号が属性として使用されるビジネス・キーになります。製品キーに基づいて結合されるデータは、製品ライン、製品タイプ、またはその両方によるレポートを受け取るとき、適切に集計されます。

行列式キーグループ化一意に識別属性

製品ライン製品ライン・コード

はい製品ライン

製品タイプ製品タイプ・コード

はい製品タイプ

製品製品キーはい費用

利益

製品名

製品番号

既存のオブジェクトに基づくモデル・クエリー・サブジェクトの作成

既存のモデル・オブジェクトを選択し、それらをマージして新しいモデル・クエリー・サブジェクトにすることができます。これは、クエリー・サブジェクトを短時間で作成するために既存のメタデータを再利用することができることを意味します。

SAP BW モデル・クエリー・サブジェクトに関する情報は別のトピック ( 239 ページの『既存のオブジェクトに基づくモデル・クエリー・サブジェクトの作成 (SAPBW)』) で示されています。


マージできるオブジェクトには、以下のものがあります。

v リレーショナル・データ・ソース・クエリー・サブジェクトおよびショートカット

v モデル・クエリー・サブジェクトおよびショートカット

v モデルおよびデータ・ソース・クエリー・サブジェクト内のクエリー・アイテム、フィルター、および計算

v モデルとデータ・ソース・クエリー・サブジェクト間のリレーションシップおよびリレーションシップのショートカット

新しいクエリーを作成するために、1 回の操作で同タイプのオブジェクトをいくつでもマージすることができます。マージでは、必ず新規モデル・クエリー・サブジェクトが作成されます。

新規クエリー・サブジェクトには、元のクエリー・サブジェクトに含まれているフィルターがすべて含まれます。


手順1. マージして 1 つのクエリー・サブジェクトにするオブジェクトを、Ctrl を押し

ながらクリックします。

2. 「操作」、「新規クエリー・サブジェクトにマージ」の順にクリックします。

関連オブジェクトの表示

「コンテキスト・エクスプローラー」でオブジェクトを非表示にすることができます。レイアウトを変更したり、「コンテキスト・エクスプローラー」にすべてのオブジェクトを合わせたりすることもできます。また、ズームインおよびズームアウトしたり、出力したり、出力前にダイアグラムをプレビューしたりすることもできます。ページ・セットアップを変更することもできます。

「ディメンション・マップ」タブを使用してディメンションを検討することもできます。

手順1. 検討する 1 つ以上のオブジェクトを選択します。

2. 「ツール」メニューから「コンテキスト・エクスプローラーを起動」をクリックします。

3. 接続されているオブジェクトを表示するには、1 つ以上のオブジェクトをクリックし、該当するボタンをクリックします。

目的ボタン

選択されているオブジェクトと関連したオブジェクトを表示する。

オブジェクトの即時参照を表示する。

オブジェクトのすべての参照を表示する。

4. オブジェクトに関する詳細 (その関係やクエリー・アイテムなど) を表示する場合、オブジェクトを右クリックし、「ダイアグラムをナビゲート」、「ダイアグラムの設定」の順にクリックした後、目的の詳細を選択します。

クエリー・セットの作成サポートされないデータ型もあります。通常、BFILE、BLOB、CLOB、LONG、およびVARRAY データ型、またはネストしたテーブル列では、セットは許可されません。

クエリー・サブジェクトは、結合、交差、または排他の set 演算を使用して定義できます。別のデータ・ソースにある類似のデータを、マージするか、比較するか、または等価にするように、クエリー・セットを定義できます。クエリー・セットは、複数の異なるシステムにあるデータからモデルを作成する際に役立ちます。

クエリー・セットを作成する多くの理由があります。複数の異なるデータ・ソース間で一致するディメンションを作成するため、クエリー・セットが必要となることがあります。または、2 つのクエリーの内容を比較してそれらのクエリーに同じデータが含まれるかどうかを判別できます。これはテスト環境では一般的な操作で


す。または、NULL を返す複数のクエリーを比較することができます。あるいは、実際には 1 対 1 関係であるファクト対ファクト関係を処理することができます。(実際には 1 対 1 関係でない場合、複数細分性のクエリーを作成します 388 ページの『複数ファクト、複数細分性のクエリー』。)

クエリー・セットは、2 つのクエリー・サブジェクトからのみ構成されます。クエリー・セットを、他の 2 つのクエリー・セットをマージして作成することもできます。クエリー・セットには以下を含めることができます。

v 2 つのクエリー・サブジェクトのすべての行 (結合操作)。

例えば、企業が最近別の企業と合併したために顧客全体の完全なリストが必要となる場合があります。

v 複数のクエリー・サブジェクトの間で共通の行のみ (交差操作)。

例えば、どのスタッフ・メンバーがマネージャーでもあるかを知ることができます。

v クエリー・セットで、最初のクエリー・サブジェクトに存在して 2 番目のクエリー・サブジェクトには存在しない行のみ (排他演算)。

例えば、製品が販売された今年の地域と 10 年前の地域の違いを強調して示すことができます。

射影のリスト内の項目名は、デフォルトで、集合演算内の最初のクエリー・サブジェクトに割り当てられた項目となります。

クエリー・セット内の 2 つのクエリー・サブジェクトと他のクエリー・サブジェクトとの関係は、クエリー・セットには含まれません。

レポートには、使用される演算子に応じた複数の異なる結果が示されます。例えば、さまざまな従業員の名前を含む 2 つのクエリー・サブジェクトがあるとします。

最初のクエリー・サブジェクトには、以下の行が含まれます。

行値

1 Jane

2 John

3 John

4 Michael

5 Michael

2 番目のクエリー・サブジェクトには、以下の行が含まれます。


行値

1 Jane

2 John

3 John

4 Patrick

クエリー・セットを作成します。使用する演算子に応じて、異なる結果が示されます。

演算子検索結果メモ

結合 (Union) Jane、John、Michael、Patrick すべての項目が示されます。値は重複しません。

交差 (Intersect) Jane、John 共通の項目が示されます。値は重複しません。

除外 (Except) Michael 共通ではない項目が示されます。値は重複しません。

2 番目のクエリー・サブジェクトがクエリー・セット内で最初にリストされている場合には、結果が Patrick になります。

すべて結合 (Union All) Jane、Jane、John、John、John、John、Michael、Michael、Patrick

すべての項目が示されます。値は重複します。

すべて交差 (Intersect All) Jane、John、John 共通の項目が示されます。値は重複します。

すべて排他 (Except All) Michael、Michael 共通ではない項目が示されます。値は重複します。

2 番目のクエリー・サブジェクトがクエリー・セット内で最初にリストされている場合には、結果が Patrick になります。


クエリー・セットを作成する手順

手順

1. 以下の要件を満たす 2 つのクエリー・サブジェクトを選択します。

v クエリー・サブジェクトに含まれている列の数が同じである。

v 列の順序が同じである。

v 列のデータ型が同じ、または類似している。

データ・ソースで 2 番目の結果セットのデータ型を最初の結果セットのものと互換性のあるデータ型に自動的に変換できる場合、データ型はまったく同じである必要はありません。

例えば、ある 1 つのクエリー・サブジェクトに国データが含まれており、データ型として int を使用するとします。もう 1 つのクエリー・サブジェクトに国データが含まれており、データ型として smallint を使用します。Framework Manager はこれらのクエリー・サブジェクトを int16 およびint32 としてインポートし、set 演算を実行します。

2. 「操作」、「クエリー・セットを定義」の順にクリックします。

3. 「定義」タブをクリックします。

4. 「名前」ボックスで、クエリー・セットの名前を付けます。

5. 「クエリー・サブジェクト」ボックスを確認し、Select 節に表示されるクエリー・サブジェクトの順序が正しいことを確認します。

クエリー・サブジェクトのいずれか 1 つのみに表示される列名 (別名) の特定のセットが必要な場合、順序が重要になります。順序が正しくない場合、このクエリー・セットをキャンセルし、再び開始してください。

結合と交差に関しては、クエリー・サブジェクトの順序は重要ではありません。順序を変更しても、同じ応答を受け取ることができます。除外の場合は、クエリー・サブジェクトの順序は重要です。

6. 「演算子」ボックスを使用して、クエリー・サブジェクトの行を結合する方法を定義します。

オプション説明

結合 (Union) 両方のセットからすべての固有の行を取得します。重複は削除されます。

交差 (Intersect) クエリー・サブジェクト間で共通する行を取得します。

除外 (Except) 最初のクエリー・サブジェクトには存在し、2 番目のクエリー・サブジェクトには存在しない行を取得します。

7. 「すべて結合 (Union All)」、「すべて交差 (Intersect All)」、または「すべて除外 (Except All)」演算子を作成するには、「重複行を削除」チェック・ボックスをオフにします。



目的操作

クエリー・サブジェクトに埋め込まれた計算を処理する

「計算」タブをクリックします。

計算を追加または編集し、計算の順序を変更することができます。

クエリー・サブジェクトに埋め込まれたフィルターを処理する

「フィルター」タブをクリックします。

フィルターの追加または編集、フィルターの順序の変更、およびフィルターの使用の変更を行えます。

クエリー・セットをテストする「テスト」タブをクリックします。


タスクの結果


v 埋め込み計算 ( 166 ページの『計算の作成』)

v 埋め込みフィルター ( 169 ページの『フィルターの作成』)

v 行列式 ( 94 ページの『行列式』)

v クエリー・セットのテストまたはテスト設定の変更 (『クエリー・サブジェクトまたはクエリー・セットのテスト』)

クエリー・サブジェクトまたはクエリー・セットのテスト

オブジェクトのテストオブジェクトをテストして、返される結果を確認することができます。このテストは、オブジェクトの作成時やその後に行うことができます。テスト可能なオブジェクトは、ディメンション、クエリー・サブジェクト、クエリー・セット、階層、レベル、計算、およびクエリー・アイテムです。

レポートに表示されるオブジェクトを選択してテストすることにより、パッケージを発行する前に特定のレポートに表示されるデータを確認できます。これにより、最初にパッケージを作成して発行する必要がなくなるので、モデルのデバッグとモデルがレポート作成要件を満たすことの検証とがより容易になります。

オブジェクトをテストするとき、IBM Cognos Framework Manager はサンプル・データを返します。形式設定はサンプル・データに適用されません。形式設定をテストする必要がある場合、パッケージを発行して IBM Cognos のStudio/Authoring ツールでオブジェクトを表示しなければなりません。

テスト対象に応じて異なる結果が表示されることがあります。例えば、式エディターを使用してクエリー・サブジェクトに組み込まれた計算をテストする場合、Framework Manager は式だけをテストしてアイテムはテストしないので、クエリー・アイテムの集計設定はテストに適用されません。計算を含むクエリー・サブジェクト全体をテストすると、集計設定が適用されるので別の結果が生成されます。例えば、集計設定が要約された場合、テストに示される行数は小さくなります。


数値データ・ディメンションをテストするとき、SQL は数値データではなく集計を使用します。

セグメント化されたモデルの子セグメントをテストする場合、テスト対象のオブジェクトが別の子セグメント内のオブジェクトを参照していて、参照されているオブジェクトを現在のプロジェクトでは使用できない場合に、エラーが出されることがあります。親モデルにすべてのオブジェクトが含まれていること、および親モデルをテストするときにはこのエラー・メッセージが表示されないことを確認してください。

ガバナー設定はテストの結果に影響を与えることがあります。詳細については、338 ページの『ガバナー』を参照してください。

既存のテスト設定を変更して、テストによって表示される結果をカスタマイズできます。例えば、他の設定に加えて、返される行数も制御できます。

オブジェクトを作成または変更する際の手順

手順

1. テストするオブジェクトを選択します。

2. 「操作」、「定義を編集」の順にクリックし、「テスト」または「クエリー情報」タブをクリックします。

「テスト結果」ボックスは、初めは空であり、クエリーを実行するまで空です。

バイナリー・ラージ・オブジェクトが含まれている結果セットはすべて [blob]として表示されます。

3. クエリーを実行し、すべてのテスト結果を戻すには、「テスト・サンプル」をクリックします。

4. 行の数を追加する場合、「合計行数」をクリックします。

5. クエリー・アイテムの「標準集計」プロパティーまたは式で参照される準加算数値データの「集計規則」プロパティーを適用する場合、「自動合計」チェック・ボックスをオンにします。

このチェック・ボックスをオフにする場合、クエリーの結果セットの行ごとに 1行が返されます。

6. クエリー結果に関する詳細を取得する場合は、「クエリー情報」タブをクリックします。


特定のレポートに表示するデータを表示する手順

手順

1. レポートに表示するオブジェクトを選択します。

2. 「ツール」、「テスト」をクリックします。



4. 問題が見つかった場合にその問題に関する詳細を表示するには、「クエリー情報」タブをクリックします。

「テスト」ウィンドウにクエリーの結果が表示されない場合、データ・ソースからのデータがガバナーのいずれかの値を超過している可能性があります。クエリーは指定された制限で停止しますが、「テスト結果」ウィンドウにはデータが含まれません。ヒント: 各ガバナーをゼロに設定してください。

テスト設定の変更テスト設定を変更することにより、テストをカスタマイズすることができます。

手順

1. 使用するオブジェクトを選択します。

2. 「操作」、「定義を編集」の順にクリックし、「テスト」タブまたは「クエリー情報」タブをクリックします。

3. 「オプション」、「テスト設定」の順にクリックします。

4. 必要なオプションを選択します。


すべてのデータを取得して、指定した数の行を表示する

「返す最大行数を制限」チェック・ボックスを選択し、必要な行数を入力します。



この設定はモデルと一緒に保存され、次のセッションで使用されます。

詳細度を指定する「結果情報に表示される情報のレベル (Level ofInformation shown inResults Information)」スライダーを、必要な詳細レベルを表す場所にドラッグします。

この設定はこのモデルと一緒に保存され、次のセッションで使用されます。

セッション・パラメーターを一時的にオーバーライドする

「セッション・パラメーター」ボックスで、「設定」をクリックします。

「セッション・パラメーター」ダイアログ・ボックスが表示されます。

オーバーライド値は、モデルと一緒には保存されません。この設定は、現行セッションにのみ適用されます。







セキュリティー・フィルターを適用する

「セキュリティー・フィルター」ボックスで、「編集」をクリックします。


プロンプト値を変更する「現在のプロンプト値」ボックスで、「プロンプト」をクリックします。

「モデルがマネージャーにプロンプトを出す」ダイアログ・ボックスが表示されます。ダイアログ・ボックスには、モデル内のすべてのプロンプトとそれらの値が表示されます。

プロンプト値は、モデルと一緒には保存されません。

この設定は、現行セッションにのみ適用されます。

5. 「OK」を 2 回クリックします。

タスクの結果


v ガバナーの設定

v セキュリティー・フィルター

v セッション・パラメーターの一時的なオーバーライド

v プロンプト値の変更

v ディメンションの操作

v クエリー・サブジェクトの操作

クエリー・サブジェクトの検証「クエリー・サブジェクト定義」ダイアログ・ボックスを開かずにクエリー・サブジェクトの定義を検証することができます。これは、次のような場合に便利です。

v 新規クエリー・アイテムがクエリー・サブジェクトに追加された場合

v 基になるクエリー・サブジェクトの定義が変更された場合


v ストアード・プロシージャーのパラメーターが変更された場合


SAP BW クエリー・サブジェクトの検証に関する情報は別のトピック ( 240 ページの『モデル・クエリー・サブジェクトの検証 (SAP BW)』) で示されています。

「オブジェクトの検証」コマンドは、すべてのクエリー・サブジェクトを包括的に検査し、それを確実に実行できるようにします。

評価プロセスの内容は、選択されるクエリー・サブジェクトのタイプによって異なります。

クエリー・サブジェクトのタイプ評価プロセス

リレーショナル・データ・ソースのクエリー・サブジェクト

派生アイテムに基づく要求がリレーショナル・データ・ソースに送られます。

データ・ソース参照のリストが更新されます。

物理属性 (データ型など) が必要に応じて更新されます。

リレーショナル・メタデータに基づくモデル・クエリー・サブジェクト

派生アイテムに基づく要求がデータ・ソースに送られます。

キャッシュに入れられている SQL (存在する場合) が更新されます。

物理属性 (データ型など) が必要に応じて更新されます。

ストアード・プロシージャー・クエリー・サブジェクト

ストアード・プロシージャーの最新パラメーターに基づく要求がデータ・ソースに送られます。

派生クエリー・アイテムのリストが更新されます。

クエリー・サブジェクトがリレーショナル・データ・ソースから派生している場合はそのクエリー・サブジェクトを更新することもできます ( 108 ページの『クエリー・サブジェクトの更新』)。あるいは、プロジェクト全体を同期することもできます ( 334 ページの『プロジェクトの同期』)。

手順1. 評価するクエリー・サブジェクトを選択します。

2. 「ツール」、「オブジェクトの検証」の順にクリックします。


タスクの結果

「標準集計」プロパティーを「サポート対象外」に変更した場合、クエリー・サブジェクトを評価するときにプロパティーはリセットされます。プロパティーが他のいずれかの値に設定される場合、プロパティーは変更されません。

クエリー・サブジェクトの更新リレーショナル・データ・ソースを使用する場合、プロジェクト全体の同期を実行する代わりにクエリー・サブジェクトだけを更新することを選択することができます。プロジェクトの同期を実行して、別のデータ・ソースの変更を同期する必要があります。

クエリー・サブジェクトは、データ・ソースの定義に基づいて更新されます。クエリー・サブジェクトを更新する際、新規メタデータがデータ・ソースから取り出され、クエリー・アイテムは再び同期されます。

クエリー・サブジェクトがリレーショナル・データ・ソースからのものである場合はそのクエリー・サブジェクトを評価することもできます ( 106 ページの『クエリー・サブジェクトの検証』)。

モデル・クエリー・サブジェクトに関して「オブジェクトを更新」コマンドを使用することはできません。

手順1. 1 つ以上のクエリー・サブジェクトを選択します。

2. 「ツール」、「オブジェクトを更新」をクリックします。

ヒント: 「クエリー・サブジェクト定義」ダイアログ・ボックスの SQL ステートメントを変更した場合、「OK」をクリックすると、「オブジェクトを更新」操作が開始されます。

クエリー・サブジェクトをディメンションに変換する階層やレベルを定義するなど、ディメンションに関連した機能を使用する場合、クエリー・サブジェクトを標準ディメンションまたは数値データ・ディメンションに変換できます。モデル・クエリー・サブジェクトはモデル・ディメンションになります。

データ・ソース・クエリー・サブジェクトをデータ・ソース・ディメンションに変換できますが、クエリー・サブジェクトやモデル・ディメンションと比べると、データ・ソース・ディメンションの機能は限定されます。標準ディメンションについても数値データ・ディメンションについても、データ・ソース・ディメンションの使用を中止してください。 381 ページの『第 10 章メタデータ・モデリング・ガイド』に記載されているベスト・プラクティスに従って新規モデルを作成して、モデルのリレーショナル・ファウンデーションとしてクエリー・サブジェクトを使用するようにしてください。標準ディメンションおよび数値データ・ディメンションを、データ・ソース・クエリー・サブジェクトまたはモデル・クエリー・サブジェクト、あるいはその両方に基づいたモデル・オブジェクトとして定義します。データ・ソース・ディメンションの既存ユーザーのための移行方法に関するガイドは、将来のリリースで提供されます。


クエリー・サブジェクトに行列式が指定されている場合、各行列式に指定したキーは、レベルごとにビジネス・キーのある階層を構築するために使用されます。行列式は 1 つの階層を形成します。各行列式の最初の文字列属性が、ビジネス・キャプションに使用されます。使用したい属性がキャプションになっていない場合は、キャプションを手動で変更する必要があります。

クエリー・サブジェクトをディメンションに変換することは、単なる開始点です。この方法で作成された各ディメンションを調べて、要件が反映されていることを確認してください。

ディメンションをクエリー・サブジェクトに変換することもできます ( 137 ページの『標準ディメンションをクエリー・サブジェクトに変換する』)。

行列式を使用してディメンションの別個の階層を作成することはできません。クエリー・サブジェクトを変換した後に、ディメンションの別個の階層を作成する必要があります。

以下のオブジェクトをディメンションに変換することはできません。

v クエリー・セット

v ストアード・プロシージャー・クエリー・サブジェクト

v SAP BW クエリー・サブジェクト

手順1. 変換するクエリー・サブジェクトを選択します。

2. 「操作」、「標準ディメンションに変換」または「数値データ・ディメンションに変換」の順にクリックします。

モデル・クエリー・サブジェクトをデータ・ソース・クエリー・サブジェクトに変換する

SQL を編集する場合に、モデル・クエリー・サブジェクトをデータ・ソース・クエリー・サブジェクトに変換できます。

複数のデータ・ソースを参照するモデル・クエリー・サブジェクトは変換しないでください。

手順1. 変換するモデル・クエリー・サブジェクトを選択します。

2. 「操作」、「データ・ソース・クエリー・サブジェクトに変換」の順にクリックします。

このコマンドは、クエリーを実行済みであり、「定義を編集」ダイアログ・ボックスの「クエリー情報」タブに SQL がある場合のみ使用できます。

SQL の編集SQL は、リレーショナル・データベース管理システムの作成、更新、およびそれへのクエリーのための業界標準言語です。


リレーショナル・データ・ソース・クエリー・サブジェクトの定義を編集する場合、次の SQL を使用できます。

v 113 ページの『Cognos SQL』

v 114 ページの『ネイティブ SQL』

v 115 ページの『パススルー SQL』


モデル・クエリー・サブジェクトの SQL を編集する場合は、「クエリー情報」タブからモデル・クエリー・サブジェクトの SQL をコピーし、新しいデータ・ソース・クエリー・サブジェクトに貼り付ける必要があります。モデル・クエリー・サブジェクトをデータ・ソース・クエリー・サブジェクトに変換することもできます。モデル・クエリー・サブジェクトが複数のデータ・ソースを参照する場合は、SQL を編集しないでください。 109 ページの『モデル・クエリー・サブジェクトをデータ・ソース・クエリー・サブジェクトに変換する』を参照してください。

列の別名を変更すると、その列を表すクエリー・アイテムが再生成されます。クエリー・アイテムに加えた変更は、IBM Cognos Framework Manager がそのクエリー・アイテムを新規クエリー・アイテムと見なすため、保持されません。

コメントの前と最後に /* と */ をそれぞれ使用することにより、SQL にコメントを追加できます。

次に例を示します。

select country /* this is a multilinecomment

another line

another line

*/

手順1. 変更するデータ・ソース・クエリー・サブジェクトをクリックします。

2. 「操作」、「定義を編集」の順にクリックします。

3. 「SQL」タブをクリックし、オブジェクトを「SQL」ボックスにドラッグするか、目的の SQL を入力します。


SQL のタイプの変更データ・ソース・クエリー・サブジェクトを生成する SQL のタイプを選択するときは、以下の要因を比較検討し、最も重要な要因を決定する必要があります。


タイプ利点欠点

Cognos SQL Cognos SQL は、例えばクエリー時に未使用要素を除去することによって、クエリー・サブジェクトのパフォーマンスを高めます。

サポートされているどのデータベースでも SQL が機能します。

標準外 SQL は入力できません。

ネイティブ SQL すべての関連クエリー・サブジェクトでパフォーマンスが最適化されます。

データベース固有の SQL を使用できます。

データ・ソースがサポートしていない SQL はサブクエリーに使用できません。

異なるデータベース・タイプでは SQL が機能しない場合があります。

パススルー SQL データベースがサポートする任意の SQL を入力できます。

Framework Manager がパフォーマンスを自動的に最適化する機会がありません。

異なるデータ・ソースではSQL が機能しない場合があります。

ネイティブ SQL への変更に関する前提条件既存のクエリー・サブジェクトをネイティブ SQL に変更する場合はまず、ネイティブ・データ・ソースに適用される規則を SQL が反映するようにして、クエリーが適切に実行されるようにする必要があります。

以下を行う必要があります。

v 既存のテーブル名を編集します。

Cognos SQL では、2 つの部分で構成される名前をクエリー・サブジェクトに付けます。例えば、[gosales].[ProductLine] は、ProductLine クエリー・サブジェクトが gosales データベースからのものであることを意味します。そのため、ネイティブ SQL に切り替える際には、データ・ソース・ベンダーで必要な親エレメントがすべてのテーブル名に含まれていることを確認する必要があります。

命名規則の詳細については、 23 ページの『プロジェクト内のオブジェクトの命名規則』を参照してください。

v SQL がサブクエリーとして有効であることを確認します。

IBM Cognos Framework Manager は、ネイティブ SQL クエリー・サブジェクトをサブクエリーとして処理します。例えば、次のような Cognos SQL クエリー・サブジェクトがあるとします。

選択


P.ProductName, P.Margin From Product P

これをネイティブ SQL に変更する場合、Framework Manager は次のようなステートメントを生成します。

選択

oracle_plain.ProductName as Productname,

oracle_plain.Margin as Margin

From

(GOSALES1_OR_92_WE...SELECT

P.PRODUCTNAME, P.MARGIN

FROM

PRODUCT P}

)oracle_plain

そのため、サブクエリーに対して課される追加のデータベース制限 (例えば With節を使用しないという制限) にクエリー・サブジェクトが準拠していることを確認する必要があります。パススルー SQL の制限はこれと同じではありません。しかし、ネイティブ SQL はラージ・クエリーの一部として処理されるので、そのパフォーマンスは向上します。

クエリー・ツール (Oracle の SQL*Plus など) を使ってネイティブ SQL をテストするには、SQL を Select ステートメントの From 節に置く必要があります。例えば、クエリー・ツールで次のような構文を使用することができます。

Select * from (<Native SQL>) T1

v 別名を派生列に割り当てます。

値が計算される列に別名を割り当てます。次に例を示します。

SELECTLength(Country) as LGTH

FROM Country

v 別名の前後に二重引用符を挿入します。

クエリー・サブジェクトの SQL タイプを変更すると、別名の大/小文字が変更される場合があります。それが生じると、変更されたクエリー・アイテムを参照するクエリー・サブジェクトがすべて無効になります。大/小文字が変更されないようにするために、以下のように別名の前後に二重引用符を挿入します。

選択COUNTRY as "test" from COUNTRY

v データ・ソース・クエリー・サブジェクトで SQL ステートメントの射影リスト(Select 節) にマクロが含まれる場合、クエリー・アイテムの「列名」プロパティーと一致する別名を SQL で指定します。

マクロは対応するクエリー・アイテムの「列名」プロパティーとは異なる列名に対して評価を行うため、エラーが発生する可能性があります。そうなると、システムはアイテムを射影リストで見つけることができません。射影リストは静的です。


別名を割り当てることにより、マクロの評価結果が変更されても、射影リストのアイテムの名前は常に同じになります。

例えば、以下のクエリーにはセッション・パラメーター runLocale が含まれており、その値はクエリーが取得する列を指定します。

選択

#$ColumnMap{$runLocale}# asCountryNameAlias

From

[GoSales].Country

番号記号 (#) はマクロ用に予約されています。 Framework Manager は、マクロを実行する際に、番号記号の外側にあるものをすべて除去します。

手順

1. 変更するクエリー・サブジェクトをクリックします。

2. 「操作」、「定義を編集」の順にクリックし、「クエリー情報」タブをクリックします。


3. 「オプション」、「SQL 設定」の順にクリックします。

4. 「SQL タイプ」リストを使用して SQL のタイプを変更します。

タイプをネイティブ SQL に変更する場合、上記のチェックリストを確認し、ネイティブ・データ・ソースに適用される規則を SQL が反映するようにします。


6. SQL を表示する場合は、「テスト・サンプル」をクリックします。

7. 実際のクエリーを表示する場合は、「クエリー」をクリックします。

8. IBM Cognos Analytics が使用する XML を表示するには、「応答」をクリックします。


Cognos SQLデフォルトで、IBM Cognos Framework Manager は Cognos SQL を使用してクエリー・サブジェクトを作成および編集します。 Cognos SQL は SQL 規格を厳守し、すべてのリレーショナル・データ・ソースおよび表形式データ・ソースに対応します。 Framework Manager は可能な限り最適化された SQL を生成します。このような理由で、Cognos SQL は推奨されています。

Framework Manager のクエリー・サブジェクトはデータベースのビューに似ているので、各クエリー・サブジェクトの SQL はビューに適用される SQL 規格に準拠する必要があります。例えば、空の列や名前が一意ではない列には、別名を割り当てる必要があります。このレベルの規格適合があるので、Cognos SQL は SQL規格を厳守しないベンダー固有の SQL よりも動作に一貫性があります。

Cognos SQL によって次のようなクエリー・サブジェクトを作成できるので、一般にその使用が勧められています。

v 複数のデータ・ソースからメタデータを取得できる。


v データベースの制限が少ない。

v IBM Cognos アプリケーションとより効率的に対話できる。

SQL 標準の構文:

データ・ソースがサポートしているなら、Cognos SQL で With 節を使用できます。 With 節は、より判読しやすい SQL を生成するため、およびより最適なデータ取得プランをデータ・ソースに生成させるために使用されます。データ・ソースは、同じテーブルをスキャンしなければならないケースをより簡単に検出できるので、それらをインライン・ビューまたは一時テーブルとして解決することができます。

デフォルトでは、「SQL 生成時に WITH 節を使用」ガバナーが設定されていれば、IBM Cognos Framework Manager は SQL 標準の共通テーブル・コンストラクターを使用します。

基礎となるデータ・ソース・ソフトウェアがサポートする機能に要求が限定されている場合は、クエリー・パフォーマンスを高めるために、With 節を使用してください。データ・ソースがサポートしていない機能を要求が使用する場合、With 節を使用すると、クエリーがさらに分解されることがあり、パフォーマンスの低下につながる可能性があります。このような場合は、With 節を使用しないほうが、基礎データ・ソースにとってより適切なクエリー・セットが生成される場合があります。

派生テーブルを使用する Cognos SQL の例を次に示します。

SELECT * FROM

(SELECT SNO C1, AVG(QTY) C2, COUNT(*) C3 FROMSUPPLYGROUP BY SNO) T1,

(SELECT MAX(QTY) C1 FROM SUPPLY) T2

この例を Cognos SQL がどのように With 節にするかを次に示します。

WITH T1 AS (SELECT SNO C1, AVG(QTY) C2, COUNT(*)C3 FROMSUPPLY GROUP BY SNO),

T2 AS (SELECT MAX(QTY) C1 FROM SUPPLY)

SELECT *FROM T1, T2

再帰的処理には With 節を使用しないでください。

With 節の詳細については、 338 ページの『ガバナー』を参照してください。

データ型の検査と SQL 検証は継続的に改良されています。この理由と、すべてのベンダーが SQL 標準に完全に準拠しているわけではないという理由から、以前はデータ・ソースに渡された無効または未確定の SQL 式が渡されなくなります。SQL 標準の仕様にないデータ型を返す式がある場合は、構文 {expr} を使用して式をデータ・ソースに渡してください。ユーザーも同じ技法を使用する必要があります。

ネイティブ SQLネイティブ SQL は、Oracle SQL など、データ・ソースが使用する SQL です。ネイティブ SQL を使用して、入力する SQL ステートメントをデータベースに渡し


ます。 IBM Cognos Analytics によって、入力内容にステートメントが追加される場合があります。プロジェクト内の複数のデータ・ソースを参照するクエリー・サブジェクトで、ネイティブ SQL を使用することはできません。

IBM Cognos Framework Manager で指定されてデータベースによって処理されるSQL は、ネイティブ SQL でもパススルー SQL でも、必要なものをすべて完備している必要があります。データベース・プロンプト、変数、通常は呼び出し元アプリケーションによって提供されるネイティブ・フォーマットなど、その SQL の外部にあるものを参照することはできません。

ネイティブ SQL バージョンを使用する作業を選択する場合には、単一のデータ・ソースに基づくクエリー・サブジェクトに対してそれを使用できます。これにより、Cognos SQL では使用できないキーワードを使用することができ、SQL を別のアプリケーションから Framework Manager にコピーして貼り付けることができます。

クエリーが生成されるとき、Framework Manager は、指定のデータ・ソース接続を使用する各クエリー・サブジェクトの SQL を結合して単一のクエリーにします。これはクエリーのパフォーマンスを改善するために役立ちます。ただし、SQLは一連のサブクエリーとして生成されるので、ネイティブ SQL クエリーは、データベース・ベンダーが派生した表に適用する制限に従う必要があります。

従業員および管理者のリストを返すネイティブ SQL の例を以下に示します。

SELECT

lpad(' ', (level-1)* 4) enameEMP_CHART,

level, empno, ename, job, mgr

FROM

emp

CONNECT BY PRIOR

empno = mgr

AND

deptno not in (20,30)

START WITH

mgr IS NULL

ORDER BY

level, job

パススルー SQL派生した表の内部で、入力する SQL ステートメントが無効な場合は、パススルーSQL を使用します。パススルー SQL により、データ・ソースがサブクエリーに課す制約を受けることなく、ネイティブ SQL を使用できます。これは、パススルーSQL クエリー・サブジェクトがサブクエリーとして処理されないためです。代わりに、各クエリー・サブジェクトの SQL は、クエリー結果が生成されるデータ・ソースに直接送られます。

各クエリー・サブジェクトは IBM Cognos Framework Manager によって最適化される代わりに別個のステートメントとしてデータ・ソースに送られるので、パフ


ォーマンスは低下します。そのため、ネイティブ SQL とパススルー SQL との間で選択するとき、パフォーマンスがより重要なのか、またはサブクエリーでは許可されない SQL を使用することがより重要なのかを決める必要があります。

通常は、データ・ソース固有の構成体を含むクエリー・サブジェクトで、With やOrderBy 節の中など、派生したテーブル内では使用できないクエリー・サブジェクトを作成する必要がある場合にのみ、パススルー SQL を使用します。

Framework Manager で指定されてデータベースによって処理される SQL は、ネイティブ SQL でもパススルー SQL でも、必要なものをすべて完備している必要があります。データベース・プロンプト、変数、通常は呼び出し元アプリケーションによって提供されるネイティブ・フォーマットなど、その SQL の外部にあるものを参照することはできません。

例えば、システム日付を含むシステム指向レポートを以下に示します。

SELECT

TO_CHAR(SYSDATE, 'DAY, DDTH MONTH YYYY')

FROM

SYS.DUAL

番号記号 (#) はマクロ用に予約されていること、および列名は一意でなければならないことに注意してください。 Framework Manager は、マクロを実行する際に、番号記号の外側にあるものをすべて除去します。

SQL 生成方法の変更データ・ソース・クエリー・サブジェクトまたはモデル・クエリー・サブジェクトのリレーショナル・データ・ソースからデータを取得する SQL を、IBM CognosFramework Manager がどのように生成するかを指定できます。

クエリー・サブジェクトの「SQL 生成 (SQL Generation)」タイプは、「ビューとして」または「最小化」のどちらかに設定できます。デフォルトは、「最小化」に設定されています。

生成タイプを「最小化」に設定した場合は、選択したクエリー・アイテムの値を取得するために必要なテーブルと結合の最小セットのみが、生成 SQL に含まれます。

生成タイプを「ビューとして」に設定した場合、Framework Manager は、クエリー・サブジェクトを定義した完全 SQL ステートメントが含まれるクエリーを生成します。クエリーがブロックとして実行されるようにする場合は、「ビューとして」を使用します。 SQL はビューとして扱われます。例えば、クエリーが実行のたびに同じ行数を返すようにしたい場合があります。

最小化された SQL を使用するとパフォーマンスが向上し、結果として大幅に高速で実行されるクエリーになります。最小化された SQL の生成は、ディメンション表を表すクエリー・サブジェクトの場合に特にメリットがあります。単一のモデル・クエリー・サブジェクトを使用してディメンションをモデル化することにより、大幅に高速で実行される小 SQL クエリーのメリットを引き出すことができます。


例えば、次のクエリー・サブジェクトの「SQL 生成タイプ (SQL GenerationType)」は、「ビューとして」です。このクエリー・サブジェクトには、ネストされた select ステートメントが含まれていることに注意してください。

selectNew_Query_Subject.COUNTRYCODE as COUNTRYCODE,New_Query_Subject.EUROINUSESINCE as EUROINUSESINCEfrom(selectCONVERSIONRATE.COUNTRYCODE as COUNTRYCODE, COUNTRY.EUROINUSESINCE as EUROINUSESINCEfrom"2 - GOSales1 - OLE-DB".GOSALES1.dbo.CONVERSIONRATE CONVERSIONRATE,"2 - GOSales1 - OLE-DB".GOSALES1.dbo.COUNTRY COUNTRYwhere(COUNTRY.SALESCOUNTRYCODE = CONVERSIONRATE.COUNTRYCODE)) New_Query_Subject

「SQL 生成タイプ (SQL Generation Type)」を「最小化」に変更すると、Framework Manager は単純化された次の SQL を生成します。

selectCONVERSIONRATE.COUNTRYCODE as COUNTRYCODE,COUNTRY.EUROINUSESINCE as EUROINUSESINCEfrom"2 - GOSales1 - OLE-DB".GOSALES1.dbo.CONVERSIONRATE CONVERSIONRATE,"2 - GOSales1 - OLE-DB".GOSALES1.dbo.COUNTRY COUNTRYwhere(COUNTRY.SALESCOUNTRYCODE = CONVERSIONRATE.COUNTRYCODE)

最小化された SQL は、各クエリー・アイテムの戻り結果セットが同等である場合に最も効果があります。ある列に別の列のレコードに対応していないレコードがある場合、最小化されたクエリーの結果には、追加の行ができます。これは、「SQL生成タイプ (SQL Generation Type)」を「ビューとして」に設定することにより回避できます。

例えば、どの製品でも使用されていない製品タイプがあり、それらの製品タイプすべてで製品ラインが共通である場合は、製品タイプが存在する製品ラインが報告されますが、それらの製品タイプには関連製品がありません。

手順1. 変更するクエリー・サブジェクトをクリックします。

2. 「操作」、「定義を編集」の順にクリックした後、「クエリー情報」タブをクリックします。


3. 「オプション」、「SQL 設定」の順にクリックします。

4. 「SQL を生成」を「ビューとして」または「最小化」に設定します。


6. SQL を表示する場合は、「テスト・サンプル」をクリックします。

7. 実際のクエリーを表示する場合は、「クエリー」をクリックします。

8. IBM Cognos Analytics が使用する XML を表示するには、「応答」をクリックします。



モデル・クエリー・サブジェクトと SQL タイプ別のモデル・クエリー・サブジェクトに基づくモデル・クエリー・サブジェクトは、独自のロジックを使用する代わりに親クエリー・サブジェクトのロジックを使用できます。子モデル・クエリー・サブジェクトが「最小化」 SQL タイプを使用する場合、親のロジックは使用されません。子モデル・クエリー・サブジェクトが「ビューとして」 SQL タイプを使用する場合、親のロジックが使用されます。

例えば、すべての製品に対するすべての返品理由を示す、「返品」という名前のモデル・クエリー・サブジェクトを作成したとします。「返品」を実行すると、700項目を超えるリストが表示されます。次に、「返品」に基づく別のモデル・クエリー・サブジェクトを作成して、「返品理由」という名前を付けます。このモデル・クエリー・サブジェクトには、「返品理由」クエリー・アイテムだけが含まれます。 SQL タイプを「最小化」に設定した場合、「返品理由」クエリー・サブジェクトを実行すると 5 つの返品理由が表示されます。 SQL タイプを「ビューとして」に設定した場合、「返品理由」クエリー・サブジェクトは「返品」クエリー・サブジェクトのロジックを使用して 700 を超える数の項目を表示します。

ディメンションディメンションとは、ビジネスの主要な側面 (例えば、製品、日付、市場など) に関するデータを広義でグループ化したものです。

IBM Cognos Framework Manager で扱うことのできるディメンションのタイプには、標準ディメンションと数値データ・ディメンションとがあります。 SAP BWでは、数値データ・ディメンションはキー数値と呼ばれます。

例えば、販売分析のプロジェクトに以下のディメンションを含めるとします。

名前タイプ説明

時刻標準ディメンション販売された年、四半期、月、週、日に編成された販売日

地域標準ディメンション販売地域、国、都市にグループ化された販売場所

製品標準ディメンション製品タイプ、ブランド、モデル、色、パッケージに編成された製品詳細

顧客標準ディメンション顧客情報

売上数値データ・ディメンション売上数量、収益、利益などの購入の詳細

標準ディメンションおよび数値データ・ディメンションを使用して、リレーショナル・データ・ソースの分析を使用可能にする必要があります。ほとんどのデータ・ソースで、数値データ・ディメンションは複数の標準ディメンションによって共有される傾向があります。標準ディメンションはしばしば共有ディメンションと呼ば


れます。クラスターに編成された数値データ・ディメンションおよび標準ディメンションは、しばしばスター・スキーマ・グループと呼ばれますが、機能エリア・グループまたはサブジェクト・エリア・グループと呼ぶこともできます。

関心があれば、 394 ページの『クエリー・サブジェクトとディメンション』のトピックも参照してください。

正規化されたデータ・ソース

正規化されているデータ・ソースまたはスノーフレーク・データ・ソースには、多くの場合、1 つのビジネス概念を記述するテーブルが複数含まれています。例えば、Product (製品) の正規化表現に、1..n 関係によって関連付けられる 4 つのテーブルが含まれているとします。各 Product Line (製品ライン) には 1 つ以上のProduct Types (製品タイプ) があります。各 Product Type には 1 つ以上のProduct (製品) があります。 Product には複数の言語による名前と説明があり、これらは Product Multilingual (製品マルチリンガル) 検索テーブルに含まれています。

モデルを簡略化する 1 つの方法は、記述可能なビジネス概念ごとに 1 つのモデル・クエリー・サブジェクトを作成することです。ユーザーは個々のクエリー・サブジェクト間の関係を知らない可能性があることに加えて、各モデル・オブジェクトを展開してクエリー・アイテムを選択するには余分な手間がかかるため、クエリー・サブジェクトをグループ化しておくと便利です。

分析の次の手順では、各クエリー・サブジェクト用のレベルを設定した標準ディメンションを作成します。

標準ディメンションの作成

標準ディメンションには、内容を説明する情報とビジネス・キー情報が含まれており、細分性の高い順から低い順に情報が階層として編成されます。通常は複数のレベルが存在し、各レベルにはキーとキャプションが必要です。レベル用のキーが 1つもない場合は、計算の中でキーを作成することを推奨します。


モデルの標準ディメンションは、モデルで既に定義されているデータ・ソースまたはモデル・クエリー・サブジェクトに基づきます。各レベルに関して、ビジネス・キーおよび文字列タイプのキャプションを定義する必要があります。モデルの検証時には、ビジネス・キーとキャプション情報の欠落が検出されます。モデルの標準ディメンションを数値データ・ディメンションに結合する代わりに、基礎となるクエリー・サブジェクトでの結合を作成し、標準ディメンションと数値データ・ディメンション間の範囲の関係を作成してください。

標準ディメンションを作成するとき、データのディメンションを理解している必要があります。次の質問に回答できる必要があります。

v ディメンションにはどのようなレベルがありますか?

v 階層を形成するレベルはどのような順序と組み合わせになっていますか?

v レベル間にはどのような関係がありますか?

v レベルを一意的に識別するものは何ですか?

v 各レベルにはどのようなデータ要素が関連付けられていますか?

v あるデータは毎月記録され、別のデータは毎日記録されるなど、細分性に複数のレベルがありますか?

v データ・ソースに外部キーが定義されていますか?

IBM Cognos Framework Manager で、標準ディメンションに複数の階層を指定できます。標準ディメンションの複数の階層は、同じクエリーのビューとして動作します。ただし、クエリーで一度に使用できるのは 1 つの階層のみです。例えば、クロス集計レポートの行に 1 つの階層を使用し、クロス集計レポートの列に同じディメンションの別の階層を使用することはできません。同じレポート内で両方の階層が必要な場合は、各階層に 1 つずつ、2 つのディメンションを作成する必要があります。詳細については、 412 ページの『複数の階層を持つディメンションのモデル作成』を参照してください。

標準ディメンションを作成することに加えて、複数のディメンションをマージして単一のディメンションにすることやクエリー・サブジェクトをディメンションに変換することもできます。

一致するディメンションでは、複数ファクトのクエリーが使用可能です。

データ・ソース・ディメンションを使用できますが、これらの機能はクエリー・サブジェクトやモデル・ディメンションと比べると限定されます。標準ディメンションについても数値データ・ディメンションについても、データ・ソース・ディメンションの使用を中止してください。 381 ページの『第 10 章メタデータ・モデリング・ガイド』に記載されているベスト・プラクティスに従って新規モデルを作成して、モデルのリレーショナル・ファウンデーションとしてクエリー・サブジェクトを使用するようにしてください。標準ディメンションおよび数値データ・ディメンションを、データ・ソース・クエリー・サブジェクトまたはモデル・クエリー・サブジェクト、あるいはその両方に基づいたモデル・オブジェクトとして定義します。データ・ソース・ディメンションの既存ユーザーのための移行方法に関するガイドは、将来のリリースで提供されます。


標準ディメンションを作成する手順

手順

1. ディメンションを置くネームスペースまたはフォルダーを選択します。

2. 「操作」、「作成」、「標準ディメンション」の順にクリックした後、「ディメンション」タブをクリックします。

3. 「階層を追加」をクリックした後、1 つ以上のオブジェクトを「使用できるアイテム」ボックスから「階層」ボックスにドラッグします。

1 つのディメンションに対して複数の階層を定義することができます。最初の階層はデフォルト (プライマリー) 階層として使用されます。

レベルをコピーすることによって、代替階層を作成することもできます。レベルをクリックし、ディメンションの右側の境界線にドラッグします。コピーできるレベルは、同じディメンション内のレベルだけです。

4. 「レベルを追加」をクリックし、1 つ以上のオブジェクトを「使用できるアイテム」ボックスから新規レベルへドラッグします。

「ディメンション定義」ダイアログ・ボックスまたは「ディメンション・マップ」タブでレベルのコピーを作成することもできます。レベルをクリックし、階層内の別の場所にドラッグします。レベルの属性もすべてコピーされます。コピーできるレベルは、同じディメンション内のレベルだけです。

5. レベル内の別のアイテムを使用する場合、「使用できるアイテム」ボックスから「階層コントロール内のレベルを選択して、クエリー・アイテムを表示します」ボックスにドラッグします。

役割の指定を促すプロンプトが表示されます。

デフォルトで、Framework Manager はネームスペースの名前を追加します。

ヒント: 複数の部分 (名と姓など) から成るキーを作成するには、アイテムを結合する新規属性を作成した後、新規属性がビジネス・キーであることを指定します。

6. 現行レベルより上のレベルのキーはこのレベルのメンバーを識別する必要がないことを示す場合、アイテムを選択し、「一意のレベル」チェック・ボックスをオンにします。これは、コンテキストに関係なく、レベルに属するキー値が一意であると見なされることを示します。場合によっては、SQL クエリーを最適化するために IBM Cognos ソフトウェアで「一意のレベル」設定が使用されることがあります。

注:「一意のレベル」チェック・ボックスは、このレベルのメンバーの MUN IDの生成や処理に影響を与えません。 MUN はすべて完全修飾です。

7. 実行する追加タスクを選択します。

v 役割を指定する ( 128 ページの『役割』)。

v 「追加」をクリックした後、式を定義することにより、計算を埋め込む( 166 ページの『計算の作成』)。


ディメンションに埋め込まれている計算を変更するには、「ディメンション・マップ」タブで、「属性」をクリックし、クエリー・アイテムを右クリックして、「式を編集」をクリックします。

v フィルターを埋め込む ( 169 ページの『フィルターの作成』)。

v レベルのソート特性を指定する ( 126 ページの『レベルのメンバーのソート』)。

v ディメンションをテストする ( 134 ページの『ディメンションのテスト』)。

v SQL を編集し、各種オプションを変更する ( 113 ページの『CognosSQL』)。


9. 複数の階層を持つディメンションのデフォルト階層を変更するには、次のようにします。

v 「プロパティー」ウィンドウで、「デフォルト階層」ボックスの省略符号(...) ボタンをクリックします。

v 別の階層を選択し、「OK」をクリックします。

タスクの結果

「ディメンション・マップ」タブを使用して標準ディメンションを作成することも

できます。「標準ディメンション」ボタンをクリックします。

標準ディメンションの階層

階層は、レベルの順序付きリスト、またはアイテムの集合です。階層内の各クエリー・アイテムには一意の名前が必要です。

IBM Cognos Framework Manager で、標準ディメンションに複数の階層を指定できます。標準ディメンションの複数の階層は、同じクエリーのビューとして動作します。最初の階層は、プライマリーまたはデフォルトの階層です。

クエリーで一度に使用できるのは 1 つの階層のみです。例えば、クロス集計レポートの行に 1 つの階層を使用し、クロス集計レポートの列に同じディメンションの別の階層を使用することはできません。同じレポート内で両方の階層が必要な場合は、各階層に 1 つずつ、2 つのディメンションを作成する必要があります。詳細については、 412 ページの『複数の階層を持つディメンションのモデル作成』を参照してください。

例えば、販売員は責任者別または販売支店別に表示することができ、それを 2 つの階層を持つ 1 つのディメンションとしてモデル化できます。


対抗する軸の階層など、同じレポート・クエリーで両方の階層が必要な場合は、各階層に標準ディメンションを作成する必要があります。例えば、以下は 2 つのディメンションで表した販売員です。

ヒント: 複数の階層を持つディメンション用にデフォルトの階層を変更するには、「プロパティー」ウィンドウの「デフォルト階層」ボックスで省略符号 (...) ボタンをクリックして、異なる階層を選択します。

ディメンション内の階層に多数のメンバーが含まれる場合、IBM Cognos エンジンがローカルで作成されたキューブ用に 1 つの大きなクエリーを生成しているために、いずれかの IBM Cognos Studio/Authoring ツールでのクエリーの実行が遅くなることがあります。この問題を解決するには、「プロパティー」ウィンドウで「ワイド・メンバー・ツリー」プロパティーを「true」に設定します。そうすると、このエンジンは、ローカルで作成されたキューブ用に複数のより小さなクエリーを生成します。

均衡階層:

均衡階層のそれぞれのパスは、同じ深さにまで降りていきます。

例えば以下の図で、最上位レベルは製品ライン (レベル 1) です。レベル 2 は製品タイプ、レベル 3 は製品です。


バランスのとれていない階層:

バランスのとれていない階層の分岐は、分岐の下降レベルが異なります。

例えば、次のダイアグラムでは、組織の最上位は CEO (レベル 1) です。レベル 2は、副会長と、CEO のエグゼクティブ・アシスタントです。副会長とは異なり、エグゼクティブ・アシスタントには従属レベルがありません。

バランスのとれていない階層は、不規則である場合もあります。バランスのとれていない不規則階層では、レベルにギャップがあり、レベルの下降深さが異なります。

不規則な階層およびネットワーク階層:

リレーショナル・メタデータで、データ・ソース内の不規則な階層とネットワーク階層とをフラット化します。


標準ディメンションのレベル最も単純なレベル定義はビジネス・キーとキャプションから成り、それぞれが 1 つのクエリー・アイテムを参照します。レベルのインスタンス (または行) は、そのレベルのメンバーとして定義されます。それを識別する一意のメンバー名は、現在のレベルおよび上位レベルのビジネス・キーの値で構成されます。例えば、[gosales].[Products].[ProductsOrg].[Product]->[All Products].[1].[1].[2] では、ネームスペース [gosales] にある [Products] ディメンションの ProductsOrg階層の Product (4 番目のレベル) にあるメンバーを識別します。この製品のキャプションは TrailChef Canteen で、これはメタデータ・ツリーとレポートに表示される名前です。

階層の第 1 レベルは、All レベルとして自動的に定義されます。それには階層のトップレベルを表す単一のルート・メンバーが含まれます。例えば、Time ディメンションの All レベルの名前は Time (All) となります。 All レベルを削除または移動することはできません。その名前、説明、および画面のヒントを変更することはできます。

階層のレベルを正しく指定しない場合、不正確な集計が生じることがあります。

メンバー内で一意な名前:

メンバー内で一意な名前 (MUN) は、テーブル内のレコードを見つけるためにビジネス・キーを使用するように、データ・ソース内でメンバーを見つけるための方法となります。

メンバー内で一意な名前は、レポートで使用されるメンバー・データ・アイテムのための式、フィルターと式の中のメンバーへの参照のための式、および OLAP データ・ソース間のドリルスルーで使用されます。異なる OLAP データ・ソース間でのMUN のメンバー・キーは一致していなければなりません。

メンバー内で一意な名前が変わると、MUN がレポート仕様に含まれているために、式やフィルター、レポートで直接参照されているメンバーが見つからなくなります。メンバー内で一意な名前が変わる理由は、以下のようにさまざまです。

v 階層またはレベル構造の変更によってレベルの一意の名前が変わることがある。

v ビジネス・キー値が変更されたため、メンバー・キーのパスが変更された。

v 設計中または時間の経過と共に、アプリケーションが変更された。

v キューブのカテゴリー・コードの一意性が予期できない。

v 実稼働環境にテスト環境よりも多くのメンバーがある。

v データ・ソースにメンバーが存在しなくなっている。

こうした問題を回避するためのベスト・プラクティスは、以下のとおりです。

v メンバー・キーにディメンション内で一意なコードとキーを使用する。

v ドリルスルーを有効にする場合、ターゲット環境とソース環境間の類似するディメンションに一意の共通する値を使用する。

v ドリルスルーのためにディメンションを使用してモデル化されたリレーショナル・モデルを使用するとき、ルート・ビジネス・キーが他のデータ・ソースのルート・メンバーと適合することを確認する。


v ビジネス・キーとディメンション・メタデータ構造が、実働環境とテスト環境で同じになるようにする。

v 実働に移行した後には、IBM Cognos Framework Manager でビジネス・キーを変更しない。

v データ・ソースのディメンション内にある一意でないキーを解決しておく。カテゴリー・コードには波形記号を使用しない。

v 一意ではないソース値によって構築された Transformer キューブがある場合、Transformer の「不要カテゴリーを一掃」機能はカテゴリー・コードを変更する可能性が大きいので、使用しない。 MDL ファイルのバックアップ・コピーを保持すること。

レベルのキー:

キーは、レベル内でメンバーを一意に識別するクエリー・アイテムです。例えば、「製品番号」は製品を一意に識別しますが、都市を一意に識別するには「都市」、「州」、「国」のすべてが必要になります。キーはレベルに含まれる場合も含まれない場合もあります。外部キーは、数値データ・ディメンションをその標準ディメンションに関連付けるために使用します。

各レベルには、キーとして定義されたアイテムが必要です。

データ型が BLOB であるクエリー・アイテムがモデル・ディメンションに含まれる場合には、行列式を持つクエリー・サブジェクトを作成してから、モデル・クエリー・サブジェクトに基づくモデル・ディメンションを作成します。

レベルのメンバーのソートディメンションを使用してモデル化されたリレーショナル・メタデータでは、ディメンションにソート特性を指定することができます。ディメンション内の個々のレベルに対してソートを指定することもできます。ディメンション内の個々のレベルに対してソートする際、データがモデルに送信される順序が適切であることを確認することができます。データがモデルに送信される順序は、相対時間期間を超えてデータが報告されるときに特に重要になることがあります。

デフォルトのソート順序は、昇順のアルファベット順です (レベル・キャプションによって異なる)。ソート順序を指定する際、データが別の列 (ビジネス・キーなど)でソートされます。

手順1. 「プロジェクト・ビューアー」ウィンドウで、ディメンションまたはレベルを選

択します。


3. 「メンバー・ソート」タブをクリックします。

4. 適用するソート・オプションを選択します。


ソート・オプション説明

メタデータ (メンバー・ツリーの表示) メタデータ・ツリーに表示する際のメンバーのソート方法を指定するためにのみ使用されます。

レポート作成者はメタデータ・ツリーのソートを変更できません。

データ - デフォルト・レポートのソートとしてのみ

レポートのメンバーのデフォルト・データ・ソートとして使用されます。

データ・ソートが指定されない場合、データはデータベースに入った順で取得されます。

レポート作成者はこの値をオーバーライドし、レポートに表示されるメンバーに対して別のソートを適用することができます。

データ - 常時 (OLAP 互換) メンバー相関関数 (MRF) にメンバーの順序の整合性を提供するために使用されます。この設定は、MRF が必要な場合にのみ使用してください。そうしないと、ソートによって不要なオーバーヘッドが発生することになります。レポート作成者は、MRF に送られるメンバーの順序を変更できません。ただし、作成者はレポートに表示されるメンバーに対して別のソートを適用することができます。

ソートが指定されず、MRF が使用される場合、レポート作成者は MRF が処理されるときにエラーを受け取ります。

このオプションが設定されると、「メタデータ」オプションが選択されていない場合でも、レベルのメンバーもメタデータ・ツリーでソートされます。レポート作成者はメタデータ・ツリーのソートを変更できません。

ヒント

v ディメンションのレベル内の、ソート・オプションを定義していないすべて子レベルに対してデフォルトのソート順序を適用するには、「検出」をクリックします。

v ディメンションのレベル内のすべての子レベルからソート・オプションを削除するには、「すべてクリア」をクリックします。

5. 「ソートのプロパティーを割り当てるレベルを選択」ボックスで、レベルをクリックします。

6. 「使用可能なデータ・アイテム」ボックスで、ソートするアイテムをクリックし、右矢印をクリックしてそれを「レベルのソートのプロパティー」ボックスに追加します。上下矢印を使用して、アイテムの順序を変更します。

ヒント: ソート順序を昇順または降順に変更するには、「ソート順序」をクリックします。


7. レポートで Null 値をソートする方法を指定するには、アイテムの横にある「Null」ボックスをクリックし、「最初」、「最後」、または「無指定」をクリックします。

「最初」を選択すると Null 値は最初に置かれ、「最後」を選択すると Null 値は下部に置かれます。「無指定」を選択すると、データ・ソースで定義されている設定が使用されます。


役割役割は、IBM Cognos Studio のメンバー・ツリーに表示される内容を定義します。役割を使用して、メタデータを整理して管理し、ユーザーに対するデータの表示方法を決定します。

クエリー・アイテムの代わりに役割を参照する式を作成することもできます。roleValue 関数を使用して、特定の役割を参照する必要があります。例えば、階層内の特定の役割に対してクエリーを実行したいのに、その役割を果たすクエリー・アイテムが階層の各レベルで異なることがあります。単一のクエリーは、各レベルで複数の異なるクエリー・アイテムに及ぶことができます。役割を知っていても基礎となるクエリー・アイテムを知らないときは、roleValue 関数も使用できます。

複数の役割を 1 つのクエリー・アイテムに割り当てることができますが、同じ役割を同一のレベル内にある複数の異なるクエリー・アイテムに割り当てることはできません。

すべての親子階層、およびレベルに基づく階層のすべてのレベルに対して、デフォルトの役割が事前定義されます。これらの役割のほとんどは、IBM CognosStudio/Authoring ツールに表示されません。

IBM Cognos Analytics で予約されている役割は、アンダースコアーで始まります。カスタム役割の名前をアンダースコアーで始めることはできません。

デフォルトの役割

デフォルトの役割には次のものが含まれます。

v _businessKey

レベルのキーを表します。レベルの各セットのデータを識別するために十分な情報が、レベルのビジネス・キーにあれば、レベルを一意なものとして定義できます。

_businessKey 役割は、レベル内の 1 つの属性だけに割り当てることができます。

「ルート・ビジネス・キー」プロパティーは、ルート・メンバーのビジネス・キーの値を示します。ルート・メンバーは、ディメンションを使用してモデル化されたリレーショナル・モデルのために作成された人工的なレベルです。一致するディメンションでドリルスルーを使用可能にするには、「ルート・ビジネス・キー」プロパティーを設定する必要があります。

v _memberCaption


IBM Cognos Studio/Authoring ツールに表示されるメンバーのキャプションを示します。

_memberCaption 役割は、メンバー関数を利用するため、および IBM CognosStudio/Authoring ツールでレベルのドラッグや廃棄を使用可能にするために必要です。

_memberCaption 役割を割り当てられるアイテムのデータ型が文字列に設定されていることを確認してください。

v _memberDescription

ディメンション内のメンバーについての説明を返します。

カスタム役割

デフォルトでは、属性は役割なしで含められます。既存の役割に属性を割り当てることや、カスタムの役割を作成することができます。作成する各役割には、一意の名前が必要です。

モデル内のカスタム役割は翻訳できます。

役割の指定役割は、IBM Cognos Studio のメンバー・ツリーに表示される内容を定義します。役割を使用して、メタデータを整理して管理し、ユーザーに対するデータの表示方法を決定します。

手順

1. 定義する役割が含まれるディメンションをクリックします。

2. 「操作」メニューの「定義を編集」をクリックします。

3. 「ディメンション」タブをクリックします。

4. 「階層」ボックスで、必要とするレベルをクリックします。

5. 「階層コントロール内のレベルを選択して、クエリー・アイテムを表示します」ボックスで、クエリー・アイテムをクリックします。

6. 「役割」の下の省略符号 (...) ボタンをクリックします。


v Framework Manager によって定義される役割を使用するには、「デフォルトの役割」タブをクリックし、役割を選択します。

v 役割を作成するには、「カスタム役割」タブをクリックし、「追加」をクリックします。

8. 「閉じる」をクリックします。


タスクの結果

「ディメンション・マップ」タブを使用して役割を定義することもできます。「属性」をクリックし、クエリー・アイテムを右クリックして、「役割を編集」をクリックします。


数値データ・ディメンションの作成モデルの数値データ・ディメンションに表示されるのは数値データのみです。キーなどのクエリー・アイテムは非表示になります。

数値データ・ディメンションは、ファクトの集まりです。互いの間で有効な関係を持つ 1 つ以上のクエリー・サブジェクトに関して、1 つの数値データ・ディメンションを作成できます。

モデルの数値データ・ディメンションは、量的な項目のみで構成される必要があります。設計上、モデルの数値データ・ディメンションには結合するキーがないため、モデルの数値データ・ディメンションへの結合を作成することはできません。モデルの数値データ・ディメンションを標準ディメンションに結合する代わりに、基礎となるクエリー・サブジェクトでの結合を作成してください。次に、それらの間の範囲の関係を手作業で作成するか、有効範囲を検出します (両方のディメンションが同じネームスペースにある場合)。

データ・ソース・ディメンションを使用できますが、これらの機能はクエリー・サブジェクトやモデル・ディメンションと比べると限定されます。標準ディメンションについても数値データ・ディメンションについても、データ・ソース・ディメンションの使用を中止してください。 381 ページの『第 10 章メタデータ・モデリング・ガイド』に記載されているベスト・プラクティスに従って新規モデルを作成して、モデルのリレーショナル・ファウンデーションとしてクエリー・サブジェクトを使用するようにしてください。標準ディメンションおよび数値データ・ディメンションを、データ・ソース・クエリー・サブジェクトまたはモデル・クエリー・サブジェクト、あるいはその両方に基づいたモデル・オブジェクトとして定義します。データ・ソース・ディメンションの既存ユーザーのための移行方法に関するガイドは、将来のリリースで提供されます。

「利益幅」など、既存のビジネス・ルールに基づいた計算を埋め込むことにより、値を追加できます。

数値データ、クエリー・アイテム、および計算の順序を変更できます。

数値データ・ディメンションにフォルダーが含まれる場合、順序の変更は「プロジェクト・ビューアー」でのみ行えます。

数値データ・ディメンションの階層とレベルは定義できません。

手順1. 数値データ・ディメンションを配置するネームスペースをクリックします。

2. 「操作」、「作成」、「数値データ・ディメンション」の順にクリックします。

3. 「数値データ・ディメンション」タブをクリックします。

4. 「モデル・オブジェクト」ボックスから数値データを「数値データ」ボックスにドラッグします。

5. 目的の操作を実行します。


目的操作

計算を埋め込む「追加」をクリックします。

数値データを右クリックして、「追加」または「編集」をクリックすることもできます。

フィルターを埋め込む「フィルター」タブをクリックします。

数値データ・ディメンションをテストする「テスト」タブまたは「クエリー情報」タブをクリックします。

数値データをクエリー・アイテムに変換する数値データを右クリックして、「クエリー・アイテムに変換」をクリックします。

注: 「クエリー情報」タブを使用して数値データ・ディメンションをテストする場合、IBM Cognos Analytics は数値データ・ディメンションを検証します。「テスト」タブを使用して数値データ・ディメンションをテストする場合、IBMCognos Analytics は数値データ・ディメンションを実行します。検証用 SQLは実行用 SQL とはわずかに異なります。数値データ・ディメンションの確定版SQL を生成するには、「テスト」タブを使用してください。


タスクの結果

「ディメンション・マップ」タブを使用して数値データ・ディメンションを作成す

ることもできます。「数値データ・ディメンション」ボタン

をクリックしてください。


v 388 ページの『複数ファクト、複数細分性のクエリー』

v 166 ページの『計算の作成』

v 169 ページの『フィルターの作成』

v 134 ページの『ディメンションのテスト』

v 150 ページの『クエリー・アイテムの集計方法の変更』

数値データをクエリー・アイテムに変換する数値データ・ディメンションを作成済みで、それを標準ディメンションに結合する場合は、結合を作成する必要があります。結合はキーを必要としますが、キーはクエリー・アイテムであり、数値データではありません。キーとして使用する数値データは、クエリー・アイテムに変換する必要があります。

クエリー・アイテムを数値データに変換することもできます ( 165 ページの『クエリー・アイテムを数値データに変換する』)。


手順1. 数値データが含まれる数値データ・ディメンションをダブルクリックします。


3. 数値データを右クリックし、「クエリー・アイテムに変換」、「OK」の順にクリックします。

範囲の関係ディメンションを使用してモデル化したリレーショナル・モデルで、どのディメンションと数値データが共に使用されるかを定義するために、範囲の関係が必要です。

ディメンションをディメンション・マップにドラッグするとき、またはクエリー・サブジェクトをディメンション・ネームスペースに移動してそれを標準ディメンションに変換するときに、範囲の関係が自動的に生成されます。

注: 範囲の関係へのショートカットはサポートされていません。

範囲の関係は、レポート作成で使用できる数値データのレベルを定義するためのもので、数値データ・ディメンションと標準ディメンションの間にのみ存在します。範囲の関係は結合とは異なり、Where 節には影響を及ぼしません。範囲の関係では、クエリーの形成方法を制御する条件や基準は設定されません。指定されたファクトを使ってディメンションを照会できるかどうかが指定されるだけです。範囲の関係が欠落する場合、結果として実行時にエラーが発生します。

数値データ・ディメンションに関して範囲の関係を設定すると、その数値データ・ディメンション内のすべての数値データに同じ設定が適用されます。数値データ・ディメンション内の数値データに関して異なるレベルでデータがレポートされる場合は、数値データにおいて範囲を設定することができます。データをレポートできる最下位レベルを指定できます。

数値データ・ディメンションを作成すると、IBM Cognos Framework Manager によって、その数値データ・ディメンションと既存の各標準ディメンションの間で範囲の関係が作成されます。 Framework Manager は、詳細の最下位レベルから始まって、数値データ・ディメンションと標準ディメンションの間の結合パスを検索します。使用可能な多くの結合パスが存在する場合、Framework Manager によって作成される範囲の関係は、意図されたものと異なる可能性があります。このようなケースでは、範囲の関係を編集する必要があります。

範囲の関係の定義範囲の関係は、レポート作成で使用できる数値データのレベルを定義するためのもので、数値データ・ディメンションと標準ディメンションの間にのみ存在します。

手順

1. 「ディメンション・マップ」タブをクリックします。

ヒント: 背景色によって強調表示された範囲の関係を表示するには、「有効範囲

の表示」ボタンをクリックします。

2. 1 つ以上の数値データ・ディメンションをクリックします。


3. 範囲を設定するディメンションのレベルをクリックします。

ヒント: Framework Manager で範囲の関係を定義する場合、数値データ・ディ

メンションと標準ディメンションを選択し、「範囲を決定」ボタンをクリックします。

4. 「範囲を設定」ボタン


タスクの結果

範囲を削除する場合、階層またはディメンションを選択し、「範囲を削除」ボタン


階層を選択する場合、ディメンションの他の階層で設定された範囲に影響を与えることなく、特定の階層から範囲を削除することができます。

ディメンションを選択する場合、すべての階層のすべての範囲が削除されます。数値データ・ディメンションと標準ディメンションの間の範囲の関係も削除されます。

既存のオブジェクトに基づく標準ディメンションの作成複数の既存のオブジェクトをマージすることにより、新しい標準ディメンションを作成できます。それらのオブジェクトは、ディメンション、クエリー・サブジェクト、またはクエリー・アイテムのいずれかです。

手順1. ディメンションに必要なオブジェクトを選択します。

2. 「操作」、「新規標準ディメンションにマージ」の順にクリックします。

関連オブジェクトの表示

「プロジェクト・ビューアー」で選択するクエリー・サブジェクトまたはディメンションと接続されているオブジェクトのビジュアル表示を検討することができます。「コンテキスト・エクスプローラー」には、選択されているオブジェクトが接続されているオブジェクトが表示されます。接続されているオブジェクトを選択し、その参照を表示することもできます。








目的ボタン





ディメンションのテスト標準ディメンションをテストすると、デフォルトとして定義されている階層と関連付けられている属性が返されます。





テスト対象に応じて異なる結果が表示されることがあります。例えば、式エディターを使用してクエリー・サブジェクトに組み込まれた計算をテストする場合、Framework Manager は式だけをテストしてアイテムはテストしないので、クエリー・アイテムの集計設定はテストに適用されません。計算を含むクエリー・サブジェクト全体をテストすると、集計設定が適用されるので別の結果が生成されます。例えば、集計設定が要約された場合、テストに示される行数は小さくなります。






オブジェクトを作成または変更する際の手順

手順


2. 「操作」、「定義を編集」の順にクリックし、「テスト」または「クエリー情報」タブをクリックします。




4. 行の数を追加する場合、「合計行数」をクリックします。

5. クエリー・アイテムの「標準集計」プロパティーまたは式で参照される準加算数値データの「集計規則」プロパティーを適用する場合、「自動合計」チェック・ボックスをオンにします。





手順







テスト設定の変更テスト設定を変更することにより、テストをカスタマイズすることができます。

手順































タスクの結果


v ディメンションの操作 ( 118 ページの『ディメンション』)

v クエリー・サブジェクトの操作 ( 84 ページの『クエリー・サブジェクト』)

標準ディメンションをクエリー・サブジェクトに変換する標準ディメンションをモデル・クエリー・サブジェクトまたはデータ・ソース・クエリー・サブジェクトに変換できます。

クエリー・サブジェクトをディメンションに変換することもできます。 108 ページの『クエリー・サブジェクトをディメンションに変換する』を参照してください。

ディメンションが複数の階層を持つ場合、ディメンションをクエリー・サブジェクトに変換すると、デフォルトの階層だけが組み込まれます。


手順1. 標準ディメンションをクリックします。

2. 「操作」、「クエリー・サブジェクトに変換」の順にクリックします。

多言語メタデータ

複数の言語で発行されるモデルでは、さまざまな言語でモデル・オブジェクトを表示し、変更することができます。

さまざまな理由で、インポート・ビューでの多言語のサポートを扱う必要が生じます。各ディメンションおよびクエリー・サブジェクトに含まれるクエリー・アイテムの数を減らすことができます。ディメンション、クエリー・サブジェクト、およびクエリー・アイテムの数が少ないと、モデルはより管理しやすくなります。さまざまなビジネス・ビューを使用する代わりに、1 つの場所で複数言語の作業をすべて行うことにより、保守が容易になります。これにより、すべてのモデル作成者が使用するために言語が適切にセットアップされるので、整合性が確保されます。これはセグメント化されたモデルの場合に特に重要です。

多言語メタデータのサポート多言語メタデータのサポートを追加するために必要ないくつかの手順があります。

手順1. 多言語データ・ソースからメタデータをインポートします。 140 ページの『多

言語データ・ソースによるモデル作成』を参照してください。

2. モデルがサポートする言語を定義します。 142 ページの『プロジェクトへの言語の追加』を参照してください。

3. レポートがデータ・ソースの言語値になったときに使用されるロケールを変換する 1 つ以上のパラメーター・マップを定義します。 175 ページの『パラメーター・マップの作成』を参照してください。

4. マクロを使用して、キーとして runLocale セッション・パラメーターを使って、言語の検索テーブルの言語値を動的に置き換えます。 180 ページの『クエリー・マクロを使用したプロンプトの作成』を参照してください。

5. 変換テーブルの多言語プロパティーをエクスポートします。変換プログラムはそれを使用して、各言語の正しいテキストを入力します。 143 ページの『変換テーブルのエクスポート』を参照してください。

6. 変換されたプロパティー値を含むテーブルをインポートします。 144 ページの『変換テーブルのインポート』を参照してください。

7. 指定する言語でメタデータを発行します。 277 ページの『第 7 章パッケージの発行』を参照してください。

タスクの結果

多言語でのモデル化を可能にする方法の詳細については、 144 ページの『例 - リレーショナル・メタデータの多言語プロジェクトの作成』を参照してください。


多言語レポート環境の設定作成したレポートでデータを複数の言語で表示したり、異なる地域設定を使用したりすることができます。つまり、1 つのレポートを作成すると、そのレポートを世界中のあらゆるユーザーが使用できることになります。

IBM Cognos に付属しているサンプル・データベースには、名前や説明などのテキスト・フィールドが 25 カ国語以上で格納されています。これにより、多言語レポート作成環境のデモンストレーションを行うことができます。サンプル・データベースでどのようにデータが格納されるか、多言語データを使用できるようにサンプル・データベースがどのように設定されているかについては、「IBM CognosAnalytics 管理およびセキュリティー・ガイド」を参照してください。

多言語レポート作成環境の作成プロセスは、次のとおりです。

v 多言語メタデータを使用する。

データ・ソース管理者は、多言語データを個々のテーブル、行、または列に格納できます。

多言語レポートを作成するためのデータベース構成の詳細については、「IBMCognos Analytics 管理およびセキュリティー・ガイド」を参照してください。

v 多言語モデルを作成する。

モデル作成者は、Framework Manager を使用し、OLAP 以外のデータ・ソース・タイプのモデルに多言語メタデータを追加します。多言語メタデータを追加するには、モデルがサポートする言語を定義し、オブジェクト名や説明などのモデル内のテキスト文字列を翻訳し、各パッケージにエクスポートする言語を定義します。データ・ソースに多言語データが含まれる場合、モデル作成者はレポート・ユーザーのデフォルト言語でデータを取得するクエリーを定義できます。

詳細については、IBM Cognos Framework Manager「ユーザー・ガイド」を参照してください。

v 多言語マップを作成する。

管理者やモデルの作成者は、Map Manager という Microsoft Windows オペレーティング・システムのユーティリティーを使用して地図をインポートし、IBMCognos Analytics - Reporting で地図のラベルを更新します。また、管理者やモデルの作成者は国または地域名や都市名などの地図特性に対して代替の名前を定義し、地図に表示されるテキストの多言語のバージョンを提供できます。

詳細については、IBM Cognos Map Manager「Installation and User Guide」を参照してください。

v 多言語レポートを作成する。

レポート作成者は、Reporting を使用して、各種の言語で表示できるレポートを作成します。例えば、ドイツのユーザーがレポートを開いたときに、タイトルなどのテキストがドイツ語で表示されるように指定できます。また、テキスト・オブジェクトの翻訳を追加したり、言語依存の他のオブジェクトを作成したりすることができます。


詳しくは、「IBM Cognos Analytics - Reporting User Guide」を参照してください。

v レポートの表示言語を指定する。

IBM Cognos Analytics ポータルを使用して、次のことが行えます。

– ポータル内のエントリーごとに名前、画面のヒント、説明などの多言語プロパティーを定義する。

– レポートの実行時に使用されるデフォルト言語を指定する。

ヒント: デフォルト言語は、「実行オプション」ページ、レポート・プロパティー、または設定で指定できます。

– レポートの実行時に使用されるデフォルト以外の言語を指定する。

詳しくは、「IBM Cognos Analytics Getting Started」ガイドを参照してください。

データは、次のいずれかで指定した言語および地域設定で表示されます。

v ユーザーの Web ブラウザー・オプション

v 実行オプション

v IBM Cognos Analytics ポータルの設定

ユーザーまたは作成者が追加するテキストは、入力された言語で表示されます。

多言語データ・ソースによるモデル作成プロジェクトが複数の言語を扱えるようにするには、複数の言語をサポートするようにデータ・ソースをセットアップする必要があります。

多言語リレーショナル・データ・ソース

リレーショナル・データ・ソースでは、以下の 1 つ以上を使用することにより、複数の言語をサポートできます。

v 言語固有のデータベース表

データ・ソースには、サポートされる言語ごとに同じ表が含まれている必要があります。例えば、Product 表が英語、フランス語、およびドイツ語をサポートする場合、データ・ソースは Product_en、Product_fr、および Product_de という名前の表を持ちます。

v 言語固有の列

データベース表には、サポートされる言語ごとに同じ列が含まれている必要があります。例えば、Product 表が英語、フランス語、およびドイツ語をサポートする場合、表は ProductName_en、ProductName_fr、および ProductName_deの列を持ちます。

v 言語固有の行

データベース表には、例えば LANG という名前の列など、データの各行の言語を示すための追加の列が含まれている必要があります。


これらのソリューションにより、多言語データ・ソースが大きくなり、管理が困難になることがあります。

クエリー・サブジェクト定義でパラメーター・マップおよびセッション・パラメーターを使用することにより、単一のリレーショナル・クエリー・サブジェクトをモデル化して、可能なすべてのデータ・ソース言語を表すことができます。詳細については、 180 ページの『クエリー・マクロを使用したプロンプトの作成』および138 ページの『多言語メタデータ』を参照してください。

注: 式の構文は、モデルの設計言語に固有のものとなります。別の言語で設計されたモデルからオブジェクトをインポートする場合は、式の構文を調整しなければならないことがあります。

多言語 SAP BW データ・ソース

SAP BW メタデータでは、多言語レポートをサポートするためにパラメーターを使用する必要はありません。それは、SAP BW が現在のユーザーのログオン設定と一致する言語でデータを自動的に提供するためです。現在のユーザーの言語でのメタデータが存在しない場合、Framework Manager はデフォルト言語でのデータを取得します。

マクロを使用して多言語データをモデル化するサポートされる言語ごとに複数のテーブル、列、または行に格納される多言語データをモデル化できます。パラメーター・マップとセッション・パラメーターを指定したマクロを使用して、レポートを表示するユーザーの優先言語でデータを取得するディメンションまたはクエリー・サブジェクトを作成できます。

クエリー・サブジェクト定義内のパラメーターの場所は、データ・ソース内の多言語データの場所によって決まります。マクロにパラメーター・マップがなければなりません。

データ・ソースでの場所例

別の列に言語キーのある列パラメーターの場所は Select リスト内です。

選択PRODUCT_TYPE.PRODUCT_TYPE_CODE,PRODUCT_TYPE.PRODUCT_LINE_CODE,PRODUCT_TYPE.PRODUCT_TYPE_#$Language_lookup{$runLocale}# as Product_typefrom[gosales].PRODUCT_TYPEPRODUCT_TYPE


データ・ソースでの場所例

LANG などの特殊列で言語が識別される行パラメーターの場所はフィルター内です。

選択PRODUCT.PRODUCT_NAME,PRODUCT_MULTILINGUAL.PRODUCT_NUMBERfrom[gosales].PRODUCT,[gosales].PRODUCT_MULTILINGUALWherePRODUCT.PRODUCT_NUMBER =PRODUCT_MULTILINGUAL.PRODUCT_NUMBERand(PRODUCT_MULTILINGUAL."LANGUAGE" =#sq($Language_lookup{$runLocale})#

プロジェクトへの言語の追加プロジェクトへの言語の追加はいつでも行えます。例えば、以前に言語の値が変換されなかった場合に行います。

言語をプロジェクトに追加する際、IBM Cognos Framework Manager は、プロジェクト内の各オブジェクトのすべての多言語プロパティーに対して新規プロパティー値を生成します。多言語プロパティーは、レポートに表示される任意のテキスト・プロパティーです。例えば、「名前」、「説明」、および「画面のヒント」などです。

Framework Manager がこれらのテキスト・プロパティーに割り当てる新規値は言語コード (先頭) と元のプロパティー値の組み合わせです。例えば、ディメンションの名前が Country で、オランダ語を追加する場合、Framework Manager は値として (nl)Country を持つ名前を挿入します。

各プロジェクトには、2 種類の言語定義が含まれます。

v 設計言語

これは、モデルが最初に作成されたときの言語です。この値はモデルに保管され、変更することはできません。これはデフォルトの言語値となります。

v アクティブな言語

これは、モデル・コンテンツが現在表示されている言語です。モデルを開く際、コンピューターの地域と言語の設定に最も近い言語が、そのモデルのアクティブな言語として設定されます。この値は、現行セッション中に限り、いつでも変更できます。その後のセッションでは、モデルは引き続き設計言語で開かれます。

手順1. 「プロジェクト」、「言語」、「言語を定義」の順にクリックします。

2. 「使用できる言語」ボックスで、追加する各言語を選択し、矢印ボタンをクリックして「プロジェクト言語」ボックスに移動します。


ヒント: 言語を削除するには、「プロジェクト言語」ボックスで言語を選択し、矢印ボタンをクリックして「使用できる言語」ボックスに移動します。

3. アクティブな言語を変更する場合、「プロジェクト言語」ボックスで言語をクリックし、「アクティブに設定」、「OK」の順にクリックします。

プロンプトで、プロジェクトに対して行った変更を受け入れ、「OK」をクリックします。

4. 「プロパティー」ウィンドウに多言語プロパティー値を表示する場合、「言語」タブをクリックします。

変換テーブルのエクスポート

モデル・オブジェクトを翻訳するタスクを単純化するために、変換テーブルを生成してエクスポートできます。変換テーブルには、「名前」、「説明」、「画面のヒント」など、多言語プロパティー用に定義されたすべてのテキスト文字列のリストが含まれます。その後、翻訳者は Microsoft Excel などの外部アプリケーションを使用して、必要な情報をテーブルに入力できます。

変換テーブルは、コンマ区切り値ファイル (.csv) または Unicode テキスト・ファイル (.txt) としてエクスポートできます。変換テーブルが非ラテン言語を含んでいるか、または自分のコンピューターとは言語設定が異なるコンピューターによってインポートされる場合には、変換テーブルを Unicode テキスト・ファイルとしてエクスポートする必要があります。

変換テーブルのエクスポート

手順

1. エクスポートするオブジェクトを選択します。

2. 「プロジェクト」、「言語」、「変換ファイルをエクスポート」の順にクリックします。

3. 「プロジェクト言語」ボックスで、エクスポートする言語をクリックし、矢印ボタンをクリックして「エクスポートする言語」ボックスに移動します。

変換テーブルを使用するモデルの設計言語をエクスポートする必要があります。例えば、設計言語としてフランス語を使用するモデルで変換テーブルを使用する場合、フランス語をエクスポートする必要があります。

IBM Cognos Framework Manager は、選択する各言語に適したロケール・コードをエクスポートします。変換対象として選択しない言語がある場合、変換テーブルの各新規言語列の最初の行に言語コードを手動で入力する必要があります。

4. 「エクスポートするモデル・オブジェクト」ボックスで、すべてのモデル・オブジェクトをエクスポートするか、それとも事前に選択されているオブジェクトとその子だけをエクスポートするかを選択します。

5. 変換テーブルの場所と名前を入力します。



変換テーブルのインポート

ファイルから翻訳済みデータをインポートすることにより、モデルに定義された言語ごとにテキスト・プロパティー値を追加できます。インポートされるファイルは、翻訳者が必要な翻訳値を入力するために使用した変換テーブルでなければなりません。

変換テーブルには、その変換テーブルを使用するモデルの設計言語を含める必要があります。変換テーブルには、プロジェクトに定義された言語のサブセットを含めることができます。

変換テーブルのインポート

手順

1. 「プロジェクト」、「言語」、「変換ファイルをインポート」の順にクリックします。

2. 「プロジェクト言語」ボックスで、変換テーブルの言語をクリックし、矢印ボタンをクリックして「変換前」および「変換後」ボックスに移動します。

このモデルの設計言語を選択する必要があります。

3. 「変換の適用対象」ボックスで、変換をすべてのモデル・オブジェクトに適用するか、それとも事前に選択されているオブジェクトとその子だけに適用するかを選択します。

4. 変換ファイルの場所と名前を入力します。


例 - リレーショナル・メタデータの多言語プロジェクトの作成英語、フランス語、ドイツ語のレポート作成者が使用できるモデルを作成します。メタデータが IBM Cognos Studio でレポート作成者に必要な言語で自動的に表示されるようにもします。

go_data_warehouse サンプルで以下を行う必要があります。

v メタデータを変換する。

v マクロを使用して多言語プロジェクトを作成する。

Language_lookup パラメーター・マップおよび runLocale セッション・パラメーターを使用することにより、ディメンションおよびクエリー・サブジェクトで多言語のコンテンツが表示されるように変更することができます。

手順1. go_data_warehouse プロジェクトを開きます。

2. 英語、フランス語、ドイツ語がサポート対象言語であることを確認します。

v 「プロジェクト」、「言語」、「言語を定義」の順にクリックします。

v 「プロジェクト言語」ウィンドウに英語、フランス語、およびドイツ語が含まれていることを確認します。

v 「プロジェクト・ビューアー」ウィンドウでクエリー・アイテムをクリックし、「プロパティー」ウィンドウで「言語」タブをクリックします。


名前、説明、およびツール・チップ・テキストに関して、それぞれの言語でエントリーが 1 つ表示されます。

3. プロジェクトの言語およびオブジェクトすべてを GOSLDW-ML.csv という名前のコンマ区切り値ファイル (.csv) にエクスポートします。

v 「プロジェクト」、「言語」、「変換ファイルをエクスポート」の順にクリックします。

v 「プロジェクト言語」ボックスで、Ctrl を押しながら「英語」、「フランス語」、および「ドイツ語」をクリックし、上矢印をクリックして「エクスポートする言語」ボックスに移動します。

v 「言語のエクスポート先ファイル」ボックスに GOSLDW-ML.csv の場所を入力します。

4. Microsoft Excel で GOSLDW-ML.csv ファイルを開き、文字列を変換します。

各列は特定の言語を表します。ファイルにはモデルに存在するテキスト文字列だけが含まれています。

5. Framework Manager で、変換されたファイルをインポートします。

v 「プロジェクト」、「言語」、「変換ファイルをインポート」の順にクリックします。

v 「プロジェクト言語」ボックスで、「フランス語」および「ドイツ語」を「変換後」ボックスに移動します。

v 「変換テーブルのインポート元ファイル」ボックスに GOSLDW-ML.csv の場所を入力します。

6. 「プロジェクト・ビューアー」で、Language_lookup パラメーター・マップをダブルクリックします。

キーは、runLocale セッション・パラメーター (現行ユーザーの言語を識別する) の可能な値と一致します。これらのキーは、go_data_warehouse データベースで定義されている言語値にマップされます。

7. パラメーター・マップに次の情報が含まれていることを確認します。

キー値

de DE

en EN

fr FR

8. 多言語列が含まれているオブジェクトを選択し (「発注方法」ディメンションなど)、「操作」、「定義を編集」の順にクリックします。

クエリー・アイテム名に付加された言語 ID がパラメーター・マップおよびrunLocale セッション・パラメーターによって置き換えられます。

選択

ORDER_METHOD_DIMENSION.ORDER_METHOD_KEY,


ORDER_METHOD_DIMENSION.ORDER_METHOD_CODE,

ORDER_METHOD_DIMENSION.ORDER_METHOD_#$Language_lookup{$runLocale}# AS ORDER_METHOD

from

[go_data_warehouse].ORDER_METHOD_DIMENSION

9. 結果をプレビューするには、「テスト」、「テスト・サンプル」の順にクリックします。

10. 「プロジェクト」、「セッション・パラメーター」の順にクリックし、runLocale セッション・パラメーター値を fr に変更します。

11. 「発注方法」ディメンションを再びテストし、結果を表示します。

クエリー・アイテムクエリー・アイテムは、レポート内に配置できるモデル内の最も小さなオブジェクトです。それは、製品が導入された日付など、物事の単一のインスタンスを表します。

リレーショナル・メタデータでは、以下の方法でクエリー・アイテムのプロパティーを変更できます。

v 「使用方法」プロパティーと「標準集計」プロパティーを設定して、クエリー・アイテムの意図する使用方法を反映させる

v クエリー・アイテムを形式設定して、レポート内でのデータの表示方法を制御する

v 列をプロンプトとして識別して、プロンプト情報をユーザーに示す方法を制御する

また、複数のクエリー・アイテムのプロパティーを同時に変更することもできます。詳細については、 19 ページの『複数のプロパティー値の置換』を参照してください。

「計算の定義」ダイアログ・ボックスでクエリー・アイテムを名前変更できます。クエリー・アイテムを名前変更すると、参照が更新されてこのクエリー・アイテムになります。

レポートにはモデル内の 1 つ以上のオブジェクトから複数の異なるクエリー・アイテムを含めることができるので、クエリー・アイテム・プロパティーは最終レポートの多くの側面を制御します。モデル・ディメンションまたはモデル・クエリー・サブジェクトを作成するとき、クエリー・アイテムは基礎となるデータ・ソース・クエリー・アイテムのプロパティーを継承します。

クエリー・アイテムまたは数値データのプロパティーには、以下のものがあります。

クエリー・アイテムのプロパティー説明

名前クエリー・アイテムまたは数値データの名前。



説明クエリー・アイテムまたは数値データの説明。

最終変更日時クエリー・アイテムまたは数値データが最後に変更された日付。プロパティーは現在の日時によって自動的に更新されます。

最終変更者クエリー・アイテムまたは数値データを最後に変更したユーザー。このプロパティーは、アイテムが変更されると自動的に更新されます。

値は現在のログオン・ユーザー名となります。

モデルのコメントモデルについての内部コメントを追加するために使用します。この情報は、「発行の影響を分析」ダイアログおよびモデル・レポートで使用されます。パッケージ・ユーザーはコメントにアクセスできません。

画面のヒントユーザーのために発行済みパッケージに表示できる記述。

式定期的に使用するための算出値をユーザーに提供する埋め込み計算の作成に使用します。

このプロパティーは、数値データ専用です。

注: 「式」プロパティーは SAP BW によって使用されません。

外部名データ・ソースに表示される名前。

非表示発行済みパッケージでクエリー・アイテムまたは数値データを非表示にするか表示にするかを指定します。

「非表示」が「True」に設定されて、クエリー・アイテムや数値データがユーザーに表示されない場合でも、クエリー・アイテムまたは数値データはモデル内の他のオブジェクトによって必要とされることがあるので、発行済みパッケージ内に常に存在します。「パッケージ発行 (Package Publish)」ウィザードには、クエリー・アイテムや数値データが表示されません。

例えば、計算は非表示のクエリー・アイテムを利用することがあります。



使用方法クエリー・アイテムによって表されるデータの意図された使用方法。

このプロパティーはクエリー・アイテム専用です。

書式情報がレポートに表示される方法。

通貨使用される通貨。

このプロパティーは、「プロパティー」ウィンドウでは変更できません。「形式」プロパティーを使用して、通貨を変更します。

データ型データ・ソースに設定されたデータ型。

このプロパティーはデータ・ソース内で設定されるため、Framework Manager では読み取り専用です。

精度総桁数。


スケールスケールで表される桁数。

例えば、100,000 が 100,000,000 を意味するように、数値を 1000 単位で表すことができます。


サイズクエリー・アイテムまたは数値データのサイズ。


NULL 可能クエリー・アイテムまたは数値データがNull 値を含むことができるかどうか。




表示タイプクエリー・アイテムが表示される方法。

IBM Cognos Studio/Authoring ツールで、列値は図、リンク、または値として表すことができます。

デフォルトは、値です。


MIME タイプ列値が使用する形式。

例えば、「表示タイプ」が図に設定されている場合、「MIME タイプ」は jpeg などになります。


注: 「MIME タイプ」プロパティーは SAPBW によって使用されません。

プロンプト情報プロンプトの動作。

標準集計発行済みパッケージで、クエリー・アイテム、数値データ、または計算に関連付けられた集計のタイプ。

集計規則ディメンションを使用してモデル化されたリレーショナル・メタデータで、準加算集計のための規則。

SAP BW メタデータで、「集計規則」プロパティーは読み取り専用です。

割り当て規則数値データに定義された割り当てのタイプを指定します。

値の「デフォルト」は、リスト・クエリーでは定数割り当てが使用され、クロス集計クエリーでは 1 回のみの割り当てが使用されるように指定します。値の「定数」は、すべてのクエリーで定数割り当てが使用されるように指定します。

ソート不可このクエリー・アイテムの値がソート可能かどうかを指定します。

このプロパティーは、BLOB などのラージ・オブジェクトを含むクエリー・アイテムのためのものです。


クエリー・アイテムの集計方法の変更レポートでのいくつかのクエリー・アイテムと数値データの集計方法を変更できます。 IBM Cognos Framework Manager は、クエリー・アイテムまたは数値データを集計するレポートをユーザーが作成するときに、集計規則を適用します。

メタデータがインポートされると、Framework Manager はクエリー・アイテムおよび数値データの「使用方法」プロパティーと「標準集計」プロパティーに、クエリー・アイテムまたは数値データが含まれるオブジェクトのタイプに応じて値を割り当てます。「使用方法」プロパティーは、クエリー・アイテムで表されるデータの目的の用途を示します ( 154 ページの『使用方法プロパティー』)。「標準集計」プロパティーは、クエリー・アイテムまたは数値データに適用される集計のタイプを示します ( 155 ページの『標準集計プロパティー』)。ユーザーは「標準集計」プロパティーの値をオーバーライドできます。準加算数値データの場合は、「集計規則」プロパティーを変更することにより、追加の集計規則を指定できます ( 155 ページの『準加算数値データの集計規則の定義』)。

「標準集計」プロパティーを変更するときに、平均や最大値など、インポートでは使用できない値を選択できます。どの集計値が必要かを知るには、データが何を表すかを理解する必要があります。例えば、部品番号を集計する場合、適用される集計値は、カウント、重複値を除くデータの個数、最大値、および最小値のみです。

一般に、集計関数を式に追加するのではなく、「標準集計」プロパティーを使用します。必要な自動集計が集計プロパティーでサポートされていない場合、または式が複雑でアイテムのプロパティーを使用した管理ができない場合は、式の集計関数を使用します。

個別の値 (個別の顧客など) をカウントする際にリスト、クロス集計、およびグラフ内の結果の整合性を保つには、文字列値ではなく値を一意的に識別するビジネス・キーを参照します。この方法により、異なる顧客に同じ名前が使用されている場合に、意図せずに行が欠落してしまうことを防ぐことができます。

次の例では、リレーショナル・モデルで個別の顧客をカウントする方法を説明します。

1. Customer クエリー・サブジェクトの Customer Key クエリー・アイテムのコピーを作成し、それに Customer Count という名前を付けます。

2. Customer Count の「使用方法」プロパティーを「ファクト」に設定します。

3. Customer Count の「標準集計」プロパティーを「重複値を除くデータの個数」に設定します。

4. 形式設定が必要な場合は、「表示形式」を「数値」に設定し、「小数の桁数」や「桁区切り記号」の「No.」などの形式プロパティーを必要に応じて指定します。

Count (distinct [Customer Key]) の式のクエリー・アイテムは、予期しない動作になる可能性があります。

次の例では、ディメンションを使用してモデル化されたリレーショナル (DMR) モデルで個別の顧客をカウントする方法を説明します。


1. 前の例の手順に従って、Customer クエリー・サブジェクトの Customer Count

クエリー・アイテムを作成します。

2. 手順 1 の Customer Count クエリー・アイテムを、数値データ・ディメンションに追加します。

3. 「標準集計」プロパティーと「形式」プロパティーの設定は継承されます。

あるいは、元の Customer Key を Customer クエリー・サブジェクトから数値データ・ディメンションに追加することもできます。次に、「標準集計」プロパティーを「重複値を除くデータの個数」に設定し、必要に応じて表示形式を設定します。

ディメンションのプロパティーを設定するための規則

IBM Cognos Framework Manager は以下の規則を使用して、「使用方法」および「標準集計」プロパティーを設定します。

オブジェクト使用方法プロパティー標準集計プロパティー

標準ディメンションのクエリー・アイテム

属性非サポート

数値データ・ディメンションのクエリー・アイテム

識別子カウント

数値データ・ディメンションの数値データ

ファクト数値データが計算の場合は自動

数値データが計算ではない場合は合計

数値データが準加算の場合、「集計規則」プロパティーを使用して準加算集計の規則を定義します。 155 ページの『準加算数値データの集計規則の定義』を参照してください。

クエリー・サブジェクトのプロパティーを設定するための規則すべてのタイプのクエリー・サブジェクトで、「使用方法」および「標準集計」プロパティーを変更できます。これらのプロパティーの設定は、データ型などの特性と、キーおよび関係への参加とに基づきます。

モデル・クエリー・サブジェクトに対して、IBM Cognos Framework Manager は基になるクエリー・サブジェクトの設定を使用します。ソースのクエリー・サブジェクトがそれらのプロパティーを使用しない場合、データ・ソースとストアード・プロシージャーのクエリー・サブジェクトのための規則が適用されます。

データ・ソースまたはストアード・プロシージャーのクエリー・サブジェクトで、クエリー・サブジェクトをインポートするとき、Framework Manager は以下の規則を使用して「使用方法」および「標準集計」プロパティーを設定します。



クエリー・アイテムが行列式内のキーの一部である


クエリー・アイテムが関係に参加する


クエリー・アイテムのデータ型が日付または時刻である


クエリー・アイテムのデータ型が数値または時間間隔である

ファクトアイテムが計算の場合は自動

アイテムが計算ではない場合は合計

上記のいずれも適用されない属性非サポート

計算のプロパティーを設定するための規則IBM Cognos Framework Manager はいくつかの規則を使用して、計算に「使用方法」および「標準集計」プロパティーを設定します。

計算集計を解釈するための規則:

標準集計プロパティーの計算設定は、計算の演算の順序を制御します。

Framework Manager で、計算集計タイプ設定は、以下にのみ適用されます。

v 独立した計算

v 数値データ・ディメンションの数値データに基づき、同じ数値データ・ディメンションに埋め込まれた計算。

これはクエリー・サブジェクトに埋め込まれた計算ではサポートされません。

詳細については、 398 ページの『モデルの計算における演算順序の設定』を参照してください。

Framework Manager は以下の規則を使用して、「標準集計」プロパティー内の計算集計タイプを解釈します。

v 標準集約関数 (平均、カウント、最大、最小、標準偏差、合計、分散) およびモデル・クエリー・サブジェクトへの参照は、最初に集計されます。その後、他の操作が集計結果に適用されます。

例えば、行ごとに借入を貸方で除算するための SQL は次のようになります。

選択customer, debt, credit, debt/credit aspercent_debt from x

すべての顧客を集計するための SQL は次のようになります。

Select sum(debt), sum(credit), sum(debt)/sum(credit)as percent_debt from (Select customer, debt, credit from x)


v 計算内のクエリー・アイテムがファクトであり、クエリー・アイテムの集計タイプが平均、カウント、最大、最小、または合計である場合、クエリー・アイテムの集計タイプが使用されます。

v 計算内のクエリー・アイテムに集計タイプが設定されていない場合、集計タイプ「最小」がクエリーに適用されます。 SQL 内で集計設定を「なし」にすることはできません。

v 集計関数が詳細コンテキストで使用されるとき、それらの関数は単一行の値に適用されたかのように解釈されます。例えば、Reporting レポートで「自動グループ化および集計」プロパティーが「false」に設定されます。

v クエリー・アイテムの集計は、アイテム定義から派生した集計式に基づきます。

例えば、次の独立した計算を合計するとします。

[namespace].[Company].[debt]/ [namespace].[Company].[credit]

計算は、次の式によって集計されます。

Total([namespace].[Company].[debt]) / Total([namespace].[Company].[credit])

v スカラー集計 (実行集計、ランキング集計、および移動集計) は、For 節が明示的に指定されていなければ、レポートの細分性のために計算されます。

v 集計関数の細分性は、行列式のグループ化によって、またはキューブ内の対応するレベルのキーによって設定されます。

例えば、Rank([namespace].[Company].[debt] は Rank([namespace].[Company].[debt] for Report) として解釈されます。

自動集計タイプを決定するための規則:

独立した計算および埋め込み計算で、IBM Cognos Framework Manager はいずれかの規則を使用して集計タイプを決めます。

計算集計タイプ

平均、最大、最小、合計などの集計関数を含む式に基づく

算出値

if-then-else 操作および if 条件参照ファクト・アイテムがある

算出値

非サポートを除くいずれかのタイプを使用して計算を参照する

算出値

非サポートではない集計タイプがある算出値

使用方法がファクトに設定され、集計タイプが平均、カウント、最大、最小、または合計に設定された、モデル・クエリー・サブジェクトを参照する式に基づく。ただしクエリー・アイテム式は集計関数を使用しない。

集計

集計のための規則は以下を参照してください。

上記のいずれの規則も適用されない非サポート


要約集計タイプを決めるための規則:

独立した計算および埋め込み計算で、IBM Cognos Framework Manager はいずれかの規則を使用して集計タイプを決めます。


集計タイプが平均、カウント、最大、最小、または合計であるクエリー・アイテムに対する参照だけを含むファクト

クエリー・アイテム集計タイプを使用する

数値または間隔タイプ合計

時刻、日時、または日付タイプ最大

上記のいずれの規則も適用されないカウント

使用方法プロパティー「使用方法」プロパティーは、各クエリー・アイテムで表されるデータの目的の用途を示します。インポートのときに、データ・ソース内のクエリー・アイテムが表すデータのタイプに従って、「使用方法」プロパティーが設定されます。

このプロパティーが正しく設定されていることを検証する必要があります。例えば、関係に関与する数値列をインポートする場合、「使用方法」プロパティーは「識別子」に設定されます。このプロパティーを変更することができます。

リレーショナル・クエリー・アイテムの場合、「使用方法」プロパティーの値は、クエリー・アイテムが基づいているデータベース・オブジェクトのタイプによって異なります。

使用方法プロパティーデータベース・オブジェクト説明

識別子キー、インデックス、日付、日時

関係が設定されたファクト列のデータをグループ化または集計するために使用される列を表します。

インデックス付き列も表します。

日付または時刻タイプの列も表します。

ファクト数値、時間間隔製品原価など、グループ化または集計できる数値データを含んだ列を表します。

属性文字列説明など、識別子でもファクトでもない列を表します。


標準集計プロパティー「標準集計」プロパティーは、クエリー・アイテムまたは計算を発行するときの集計のタイプを示します。ユーザーは、このデフォルト設定を使用してデータのグループに計算を実行するか、または異なるタイプの集計を適用することができます。

例えば、「数量」クエリー・アイテムの「標準集計」プロパティー値が「合計」であり、レポート内で「製品名」ごとにグループ化される場合、レポートの「数量」列は各製品の合計数量を示します。

以下の集計タイプがリレーショナル・データ・ソースでサポートされます。

v 自動

v 平均値

v 算出値

v カウント

v 重複値を除くデータのカウント

v 最大

v 最小

v 合計

準加算数値データの集計規則の定義ディメンションを使用してモデル化されたリレーショナル・メタデータの数値データの場合は、関連ディメンションごとに集計規則を定義できます。これらの規則は「標準集計」プロパティーに追加され、そのディメンションにおける情報に関して準加算数値データをどのように集計するかを指定するのに使用されます。準加算数値データはいくつかのディメンションについて合計されるものであり、他のいくつかのディメンションにわたって合計されるべきではありません。数値データが加算的でないディメンションについては、異なる集計規則を指定する必要があります。

数値データ式に集計関数が含まれる場合、その数値データの集計規則は無視されます。

集計規則は次の順序で適用されます。

v クエリーに含まれるディメンションに「標準集計」プロパティーが適用されますが、「集計規則」ダイアログ・ボックスでは参照されません。

v 「集計規則」ダイアログ・ボックスで指定した集計が、規則を指定した順序で指定ディメンションに適用されます。

v クエリーで指定したレポート・レベルの集計

例えば、在庫は月グレーンの開始残高と決算残高とともにデータ・ウェアハウスに記録されます。異なる期間の在庫について報告する必要がある場合は、その期間内の適切なタイム・スライスでの値を使用する集計を適用します。開始残高の場合、値は前月の最終残高です。決算残高の場合、値は当月の最終残高です。この例では、在庫数値データの「標準集計」プロパティーは「合計」であり、時間ディメンションの集計規則の値は「最後」です。

ディメンションごとに集計規則を 1 つだけ定義できます。


注: 数値データとディメンションが構成される基になるクエリー・サブジェクト間に、直接の関係が存在しなければなりません。例えば、次のような在庫数値データ・ディメンションと時間ディメンションを考えてみます。

ある特定の期間について記録された最終期末棚卸高を生成する、次のような期末棚卸高の集計規則を定義する必要があります。

IBM Cognos が時間ディメンションに基づいて集計規則の「最後」を期末棚卸高に適用するには、時間ディメンションと期末棚卸高数値データを作成する基になるクエリー・サブジェクト間に直接の関係が存在しなければなりません。これは、在庫数値データ・ディメンションと時間ディメンション間に定義された範囲の関係に追加されます。


関係が存在しない場合、期末棚卸高数値データが含まれるクエリーを実行すると、次のエラーになります。

RQP-DEF-0564 数値データ '[ディメンション・ビュー].[在庫].[期末棚卸高]' に対する準加算的ディメンション '[ディメンション・ビュー].[時間ディメンション]' のファクト・グレイン (クエリー・サブジェクトの結合) を特定できません。ディメンションが構成される基のクエリー・サブジェクト間で、関係が定義されていることを確認してください。

散在データの場合は、準加算数値データはサポートされていません。散在データは、ディメンション値の組み合わせの多くが関連ファクト・データを持たない多次元データです。

SAP BW メタデータの場合、「集計規則」プロパティー値は読み取り専用です。代わりに「準集計」プロパティーが使用されます。

手順

1. 処理に使用する数値データをクリックします。

2. 「プロパティー」ウィンドウで、「集計規則」プロパティーの省略符号 (...) ボタンをクリックします。

3. この数値データのディメンションを追加するには、「追加」をクリックしてディメンションを選択します。

数値データ・ディメンションと標準ディメンション間に範囲の関係が存在する場合は、ディメンションへのショートカットを組み込むことができます。

4. 集計操作を指定するには、「集計規則」ボックスの省略符号 (...) ボタンをクリックします。

以下の操作がサポートされています。

v 合計

v 最小

v 最大

v 平均値

v 最初のページ


v 最後

5. 集計規則の順序を変更する場合は、矢印ボタンを使用します。


タスクの結果

集計規則を設定すると、数値データのアイコンが変わります。

「準集計」プロパティーリレーショナル・メタデータの場合、「準集計」プロパティー値は「サポート対象外」に設定され、読み取り専用です。

IBM Cognos Framework Manager で値が「サポート対象外」に設定されている場合、IBM Cognos Studio/Authoring ツールでは準集計動作は無視されます。

将来のリリースでは、「準集計」プロパティーはサポートされなくなります。代わりに、準加算数値データのための「集計規則」プロパティーを使用してください。

使用方法および集計規則の決定

IBM Cognos Framework Manager で「使用法を決定」コマンドおよび「集計規則を決定」コマンドを使用するとき、「使用方法」および「標準集計」の値をそれらのデフォルト値にリセットすることになります。これにより、それらのプロパティーに対して行ったすべての変更は上書きされます。

集計値を生成するとき、Framework Manager は「使用方法」プロパティー値とそのオブジェクト・タイプとに基づく値を割り当てます。

「使用方法」プロパティー値「標準集計」プロパティー値

識別子度数


ファクト合計

使用規則および集計規則を決定する手順:

手順

1. 「プロジェクト・ビューアー」ウィンドウで、1 つ以上のディメンションまたはクエリー・サブジェクトをクリックします。

2. 「プロパティー」ウィンドウで、「プロパティー」タブをクリックします。

3. 「使用方法」プロパティーを「不明」に変更します。

4. 「標準集計」プロパティーを「サポート対象外」に変更します。

5. 「ツール」、「使用法を決定」をクリックします。

6. 「ツール」、「集計規則を決定」の順にクリックします。


クエリー・アイテムの形式設定レポート内にクエリー・アイテムを表示する方法を指定できます。「形式」プロパティーを使用して、テキスト、日付、通貨などの表示形式を選択します。各表示形式には、データの表示方法をさらに詳細に指定するためのプロパティーが含まれています。

例えば、「通貨」表示形式を数値クエリー・アイテムに割り当ててから、「データ形式」ダイアログ・ボックスの「小数桁数」「いいえ」プロパティーを使用して、レポートに表示する小数の桁数を指定できます。

いくつかの記号は言語に依存するので、使用するロケールが適切なフォントをサポートする場合にのみ正常に表示されます。例えば、日本の通貨記号を正常に表示するためにはロケールが日本語に設定されていなければなりません。

IBM Cognos Framework Manager で必要な通貨が表示されない場合、通貨記号をサポートするための適切な言語パックをインストールしたことを確認する必要があります。例えば、インドの通貨記号 (ルピー) を表示するためには、この記号を表示できるオペレーティング・システムを実行するか、または言語パックをインストールする必要があります。日本語のオペレーティング・システムや日本語の言語パックは、インドの通貨記号を表示できるものの 1 つです。

複数のクエリー・アイテムのプロパティーを同時に定義できます。ただし、クエリー・アイテムに複数の異なる表示形式がある場合は、以前に指定されたすべてのプロパティーがオーバーライドされて、データ・ソースからのデフォルト値が使用されます。選択された複数のクエリー・アイテムで元の表示形式が同じである場合、選択されたクエリー・アイテムのすべてのプロパティーは同一に設定されます。

例えば、2 つのクエリー・アイテムで同じ小数点記号を使用し、小数点の桁数は異なるようにするためには、それぞれのクエリー・アイテムを個別に変更する必要があります。両方が選択されて同時に変更された場合は、両方のクエリー・アイテムで小数点の桁数を含むすべてのプロパティーが同一に設定されます。

クエリー・アイテムの表示形式を設定する手順

手順

1. 「プロジェクト・ビューアー」ウィンドウで、表示形式を設定するクエリー・アイテムをクリックします。

2. 「プロパティー」ウィンドウの「プロパティー」タブで、「表示形式」プロパティーをクリックします。

3. 該当する「表示形式」を選択します。

4. 「プロパティー」ボックスで、該当するプロパティー値を選択するか、入力します。


プロンプト・コントロールの定義プロンプトは、ユーザーが必要とするレポート内の情報を素早く見つけるために役立ちます。プロンプトは、通常レポート内で定義されます。ただし、


Studio/Authoring ツールでモデル内のディメンションやクエリー・サブジェクトの定義を変更して、プロンプトの動作を変更することができます。

これは ProductTypeCode のような、レポートに値は表示されないもののデータをフィルター操作するために役立つクエリー・アイテムの場合に便利です。一般に、追加のプロンプト機能を利用できるようにレポート内で入力プロンプトを定義するほうが優れています。ただし、ユーザーはいくつかの変数を変更できません。それらの変数については、レポートの代わりに IBM Cognos Framework Manager を使用して入力プロンプトを定義できます。

Framework Manager で設定された「プロンプト情報」プロパティーを使用すると、デフォルトのフィルター処理およびプロンプト処理を制御することができます。プロパティーは、以下によって使用されます。

v Query Studio。フィルター式を作成したり、プロンプトおよびプロンプト・クエリーで使用および表示されるアイテムを設定したりするため。

v Reporting の「プロンプト・ページを作成」ツール。フィルター式を作成したり、プロンプトおよびプロンプト・クエリーで使用および表示されるアイテムを設定したりするため。

v Reporting 内の生成済みプロンプト。プロンプトおよびプロンプト・クエリーで使用および表示されるアイテムを設定するため。

プロンプトを値として使用するための構文は、次のとおりです。

?<PromptName>?

プロンプトは、次の場所で使用できます。

v パラメーター・マップ

v セッション・パラメーター

v ストアード・プロシージャー引数

v 式 (フィルター、計算、関係など)

例えば、ストアード・プロシージャーは特定の製品番号を持つすべての行を返します。ストアード・プロシージャーの引数として製品番号を使用する代わりに、?Product_Number? などのプロンプトを使用できます。

プロンプトの例については、 180 ページの『クエリー・マクロを使用したプロンプトの作成』および 93 ページの『例 - ストアード・プロシージャーでのプロンプトの使用』を参照してください。

プロンプトの作成について詳しくは、「Reporting ユーザー・ガイド」を参照してください。

プロンプト・コントロールを定義する手順

手順

1. クエリー・アイテムをクリックします。


3. 「プロンプト情報」プロパティーの横にある正符号 (+) をクリックします。


これは複合クエリー・アイテムのプロパティーです。

4. 必要な動作を反映するように以下のプロパティーを変更します。

目的プロパティー

レポートの実行時に生成されるプロンプト・コントロールのタイプを設定する。

プロンプトのタイプ

生成されるプロンプトを、生成される一連のカスケード・プロンプトの一部として設定する。

カスケード・オン・アイテム参照

プロンプトでレポート・ユーザーに対して表示されるクエリー・アイテムを指定する。

プロンプトの値は、クエリー・アイテムのデータ値です。

プロンプトの各値は、「使用アイテム参照」プロパティーで指定されるクエリー・アイテムの値と関連付けられます。

表示アイテム参照

プロンプトからフィルターに渡されるクエリー・アイテムを指定します。

各値は、「表示アイテム参照」プロパティーで指定されるクエリー・アイテムの値と関連付けられます。

使用アイテム参照

データを取得するためにフィルター式で使用されるクエリー・アイテムを指定します。

フィルター・アイテム参照

「プロンプトのタイプ」プロパティー「プロンプトのタイプ」プロパティーは、編集ボックスやプルダウン・リストなど、レポートの実行時に生成されるプロンプト・コントロールのタイプを設定します。

このプロパティーのデフォルト値は「サーバーで判別」です。

注: 属性に設定されたプロンプト・タイプが処理されるようになりました。属性上のプロンプト・タイプと一致するプロンプトが、レポート・ユーザーに表示されます。前のリリースでは属性上のプロンプト・タイプが処理されなかったので、いくらかの違いが生じることがあります。

値プロンプト・コントロール

サーバーで判別プロンプト・コントロールのタイプは、クエリー・アイテムのデータ型など、サーバー内の情報に基づいています。



編集ボックス簡単なテキスト・ボックス。列のデータ型が日付または日付時刻の場合、この値によって、日付または日付時刻のコントロールがテキスト・ボックスと共に生成されます。

日付の選択カレンダー・インターフェースのある日付のコントロール。

日時の選択カレンダー・インターフェースのある日付時刻のコントロール。

SAP BW メタデータでは、この値は関係ありません。

間隔の選択日付時刻インターバル・コントロール。


時刻の選択選択された期間に基づいてデータにフィルターを掛ける時間コントロール。例えば、発注時刻に対して「時間の選択」プロンプトを定義した場合、ユーザーは時間コントロールを使用して 1:00 より後に行ったすべての発注を表示したり、10:00 から 11:00 までの間に行ったすべての発注を表示したりすることができます。

時刻メンバーを参照する場合は、厳密な値だけを使用しなければなりません。

範囲を使用する場合は、範囲の終点がデータ・ソース内の値に対応していなければなりません。

値の選択ドロップダウン・リスト。

検索による選択ユーザーが値を検索するためのリスト・コントロール。


ツリーによる選択階層ノードに基づくプロンプトのためのツリー・プロンプト・コントロール。

「カスケード・オン・アイテム参照」プロパティー「カスケード・オン・アイテム参照」プロパティーは、生成されたプロンプトが、一連の生成されたカスケード・プロンプトの一部であることを示します。このプロパティーで参照するクエリー・アイテムは、カスケード内の親アイテムです。システムはユーザーに現在のクエリー・アイテムの指定を求めるプロンプトを出す前に、カスケード・アイテムの指定を求めるプロンプトを出します。


例えば、製品ラインの指定を求めるプロンプトを出してから選択されたライン内の製品の指定を求めるプロンプトを出すためには、「製品」クエリー・アイテムの「カスケード・オン・アイテム参照」プロパティーを「製品ライン」に設定します。

表示アイテム参照プロパティーおよび使用アイテム参照プロパティー「表示アイテム参照」プロパティーは、プロンプトでユーザーに表示されるクエリー・アイテムを指定します。「使用アイテム参照」プロパティーは、プロンプトからフィルターに渡されるクエリー・アイテムを指定します。表示アイテムのリスト内の各値は、「使用アイテム参照」プロパティーで指定されたクエリー・アイテムの値に関連付けられます。

例えば、プロンプトには国名を表示しながら、国コードを使用してデータを取得することができます。「表示アイテム参照」プロパティーを国名に設定し、「使用アイテム参照」プロパティーを国コードに設定します。プロンプトに国名が示されるので、レポート・ユーザーは必要な値を容易に選択できます。一方で、フィルターに国コードを使用するとデータの取得がより効率的になります。

これらのプロパティーは、以下によって使用されます。


v Reporting の「プロンプト・ページを作成」ツール。プロンプトおよびプロンプト・クエリーで使用および表示されるアイテムを設定するため。


注: 「使用アイテム参照」プロパティーの値と「フィルター・アイテム参照」プロパティーの値の間には互換性が必要です。そうでない場合、レポート・ユーザーは予期しない結果を受け取る可能性があります。詳細については、『フィルター・アイテム参照プロパティー』を参照してください。

デフォルト: 値が設定されない場合、プロパティーはデフォルトでクエリー・アイテムの名前になります。

これらのプロパティーは、「プロンプトのタイプ」プロパティーが「値の選択」または「検索による選択」に設定された、データ駆動型のプロンプト・コントロールにのみ使用されます。

フィルター・アイテム参照プロパティー「フィルター・アイテム参照」プロパティーは、Reporting または Query Studioでフィルターを生成するときに使われるクエリー・アイテムを識別します。このプロパティーを使用すると、索引のないストリング列の代わりに索引付き数値列がフィルターで使われるようになるため、より効率的なクエリーの作成に役立ちます。

例えば、レポート作成者が Country Name (国名) クエリー・アイテムのフィルターを作成する予定であるとします。 Country Name クエリー・アイテムを使用するすべてのフィルターで Country Name の代わりに Country Code (国別コード)を使うよう、「フィルター・アイテム参照」プロパティーを設定できます。


別の例として、レポート作成者が、Orders (注文) テーブルに表示される CountryCode (国別コード) クエリー・アイテムのフィルターを作成する予定であるとします。ここで、Country テーブルは読み取る行が少ないため、Country テーブル内のCountry Code をフィルターで使用するのが適切と判断されるとします。この場合、モデルで「フィルター・アイテム参照」を Country.Country Code に設定できます。

このプロパティーは、以下のものによって使用されます。

v Query Studio (フィルター式を作成するために)

v Reporting のプロンプト・ページ作成ツール (フィルター式を作成するために)

デフォルト: 値を設定しない場合、プロパティーのデフォルトとして、クエリー・アイテムの名前が指定されます。

「フィルター・アイテム参照」プロパティーと「使用アイテム参照」プロパティーの使用

「フィルター・アイテム参照」プロパティーの値と「使用アイテム参照」プロパティーの値の間で、互換性が必要です。「使用アイテム参照」プロパティーの値は、「フィルター・アイテム参照」プロパティーで期待されるタイプである必要があります。そうでない場合、レポート・ユーザーは予期しない結果を受け取る可能性があります。レポート・ユーザーがプロンプト・ページを作成せずにフィルターを作成した場合に、これが発生することがあります。

例えば、あるモデルで「使用アイテム参照」プロパティーが Employee Number(従業員番号) に、「フィルター・アイテム参照」プロパティーが Employee Name(従業員名) にそれぞれ設定されているとします。 Reporting で、レポート作成者がプロンプト・ページを作成せずに以下のフィルターを作成するとします。

Reference.EmployeeName in ?parm1?

プロンプト・ページを作成せずにフィルターを作成した場合、Reporting によってプロンプトが自動的に生成されます。プロンプトが生成されるため、Reporting はFramework Manager モデル内の Employee Name クエリー・アイテムからの「プロンプト情報」プロパティーを使用します。

「使用アイテム参照」は、フィルターに渡される値が従業員番号であることを示します。「フィルター・アイテム参照」は従業員名に基づいてデータをフィルターします。フィルターは次のとおりです。Reference].[Employee Name] in ("1", "2").Employee Name 値には "1" および "2" が存在しないため、レポートはブランクになります。

ディメンションでモデル化されたリレーショナル・メタデータ用にフィルター・アイテム参照を使用する

ディメンションでモデル化されたリレーショナル・メタデータの場合、レベルではなく _memberCaption 役割を持つ属性で「プロンプト情報」が指定されます。「プロンプト情報」プロパティーは属性において設定されますが、レベル上に存在するかのように処理されます。デフォルトでは、レポートにレベルが含まれる場合、ユーザーはレベルのプロンプトで MUN を入力するよう促されます。代わりにキャプション値を入力するには、属性の「フィルター・アイテム参照」プロパティーを属


性自体に設定してください。プロンプト付きフィルターが適用されると、フィルターされる値は属性値に基づくようになります。

例えばレベル Product Line (製品ライン) に、役割 _memberCaption を持つ属性Product Line があるとします。「フィルター・アイテム参照」プロパティー値がProduct Line に設定されている場合、レポート・ユーザーは Product Line 値を入力するよう促されます。「フィルター・アイテム参照」プロパティー値がブランクのままである場合、ユーザーは MUN を入力するよう促されます。

注:「ツリーによる選択」プロンプト・タイプと共に「フィルター・アイテム参照」プロパティーを使用しないでください。「ツリーによる選択」プロンプトではレベルまたは階層だけのフィルターが可能であるため、「フィルター・アイテム参照」プロパティーを設定するとエラーが発生します。

プロンプトのテストプロンプトを参照するモデル・オブジェクトをテストするとき、IBM CognosFramework Manager からプロンプト値の入力を求められます。 FrameworkManager はこの値を、セッションの期間中またはプロンプト値がクリアされるまで使用します。

プロンプト値のセッション値を「オプション」ダイアログ・ボックスで変更できます。このダイアログ・ボックスは、ディメンションまたはクエリー・サブジェクトを変更するとき、あるいは計算、フィルター、クエリー・セット、複雑な関係を定義するときに使用できます。プロンプト値は、その値を参照する式をテストする時点で変更できます。

「プロンプト」ダイアログ・ボックスの「テスト時に値を毎回プロンプトする」チェック・ボックスを選択すると、オブジェクトをテストするたびに値の入力を求めるプロンプトが Framework Manager から出されます。オブジェクトの更新時やカウントの実行時、Framework Manager は既存のプロンプト値があればそれを使用します。

モデル・クエリー・サブジェクト内のクエリー・アイテムのプロンプトは、そのクエリー・アイテムにのみ関連付けられます。データ・ソース・クエリー・サブジェクト内のクエリー・アイテムのプロンプトはクエリー・サブジェクト全体に関連付けられるため、クエリー・サブジェクト内のどのクエリー・アイテムをテストするときにも、プロンプトが表示されます。

クエリー・アイテムを数値データに変換する数値データ・ディメンション内のクエリー・アイテムを数値データに再変換できます。

数値データをクエリー・アイテムに変換するには、 131 ページの『数値データをクエリー・アイテムに変換する』を参照してください。

手順1. クエリー・アイテムが含まれる数値データ・ディメンションをダブルクリックし

ます。



3. クエリー・アイテムを右クリックし、「数値データに変換」をクリックします。


ビジネス・ルールモデル内のディメンションやクエリー・サブジェクトにビジネス・ルールを追加すると、取得されるデータを調整して、正しい情報をユーザーに提供することができます。

ビジネス・ルールを作成して、レポートではなくモデルの中にそれを保管することには、多くの利点があります。ビジネス・ルールが必要になるたびにユーザーがビジネス・ルールを再作成する必要がないため、時間の節約になります。すべてのユーザーが同じ定義を使用するため、ビジネス・ルールの一貫性が維持されます。例えば、「Low Margin」(薄利) とはどんな意味か、組織全体で同じになります。ビジネス・ルールを一括して保守するため、容易に更新できます。ルールの進化に合わせてすべてのレポートが自動的に更新されます。例えば「Low Margin」の定義が変更された場合、Low Margin 計算を使用するすべてのレポートが自動的に更新されます。ビジネス・ルールはセキュリティーを強化します。

例えば、以下を行うことができます。

v 計算されたデータをユーザーがレポートに含めることができるよう、計算を追加する。『計算の作成』を参照してください。

v クエリー・サブジェクトで取り出されるデータを制限するために、フィルターを作成して適用する。 169 ページの『フィルターの作成』を参照してください。

v レポートでディメンションやクエリー・サブジェクトが使われるたびに自動的に表示されるプロンプトを追加する (レポート利用者はデータのフィルター操作を促されるようになります)。 159 ページの『プロンプト・コントロールの定義』を参照してください。

v マクロでセッション・パラメーターとパラメーター・マップを使用して、式を動的に解決する。 177 ページの『セッション・パラメーターの作成』、 175 ページの『パラメーター・マップの作成』、 180 ページの『クエリー・マクロを使用したプロンプトの作成』を参照してください。

v ユーザーがレポートをセットアップするときに表示されるデータを制御するために、セキュリティー・フィルターを作成する。 284 ページの『データ・セキュリティーの追加』を参照してください。

計算の作成計算を作成して、定期的に使用するための算出値をユーザーに提供できます。計算には、クエリー・アイテム、パラメーター、変数、算出メンバー、式、および関数などの式コンポーネントを使用できます。

疑問符 (?) などの句読文字は、7 ビット ASCII 文字コードでなければなりません。マルチバイト対応のキーボードで句読文字を入力する場合、7 ビット ASCII で表記した文字を入力してください。例えば、疑問符は Alt+063 を入力します。

計算の名前には、式演算子に使用される記号は使用しないでください。式が評価されるときに、構文エラーが生じることがあります。例えば、「Margin * 10」という名前の計算は [Margin * 10]< 20 などの式で使用されるとエラーとなります。


式では、演算子または関数によっては、特定のディメンション・タイプのオペランドが必要とされる場合があります。必要とされるタイプのオペランドではない場合、そのオペランドを適切なタイプに強制変更するために、1 つ以上の強制変更規則が適用されることがあります。モデル・クエリー・サブジェクトでは式に強制変更規則が適用されないので、それらの式が有効であることを強制変更規則には依存しないで確認してください。強制変更規則について詳しくは、「IBM CognosAnalytics - Reporting ユーザー・ガイド」を参照してください。

インポートしたユーザー定義関数を計算に挿入する場合、その関数名がベンダーに固有の名前を繰り返していないことを確認してください。例えば、ユーザー定義関数の名前が CHAR の場合、Microsoft SQL Server の「char」と同一であると見なされるので、その関数を「計算の定義」ダイアログ・ボックスでテストするとエラーを受け取ります。データベースで使用される関数名について詳しくは、そのデータベースの製品資料を参照してください。

クエリーの際に、IBM Cognos Framework Manager は値がゼロの除数を含む計算に対して Null 値を戻します。平均や mod などを求める関数では除算演算子が明示的に示されないために、Framework Manager はゼロ除算のエラーを検出できません。

Framework Manager は、独立した計算および埋め込み計算をサポートします。

v 独立した計算は、式を再使用したり、標準集計プロパティーの計算設定を使って演算の順序を制御したりする場合に使用します。詳細については、 398 ページの『モデルの計算における演算順序の設定』を参照してください。

独立した計算を 1 つ以上のディメンションまたはクエリー・サブジェクトに適用して、計算済みデータをレポートに提供すること、またはユーザーが使用できるようにそれをパッケージに含めることができます。独立した計算またはそれに対するショートカットをフォルダーに移動することにより、モデル・オブジェクトの編成を改善できます。

Analysis Studio では、独立した計算を使用できません。代わりに数値データ・ディメンションの埋め込み計算を使用してください。

v 埋め込み計算は、ディメンションまたはクエリー・サブジェクトが 1 つだけ含まれる計算を使用する場合に使用します。

埋め込み計算は、リレーショナル・データ・ソースのクエリー・サブジェクト、モデル・クエリー・サブジェクト、またはディメンションを変更する際に作成できます。

埋め込み計算から開始する場合、後にそれを他のディメンションまたはクエリー・サブジェクトに適用可能な独立した式に変換できます。ヒント: 「計算」タブで計算式を右クリックして、「独立した計算に変換」をクリックします。

計算を埋め込むとき、データ・ソースのクエリー・サブジェクトには、式で参照されるクエリー・サブジェクトに対する関係が存在しなければなりません。この関係は、式が参照するモデル・クエリー・サブジェクトが、式を埋め込むデータ・ソースのクエリー・サブジェクトと同じテーブルに基づいている場合でも必要です。


計算の作成手順

手順


v 独立した計算を作成するには、ネームスペースまたはフォルダーをクリックし、「操作」、「作成」、「計算」の順にクリックします。

v 数値データ・ディメンションの埋め込み計算を作成するには、ディメンションをダブルクリックします。「数値データ・ディメンション」タブで、「追加」をクリックします。

v 標準ディメンションの埋め込み計算を作成するには、ディメンションをダブルクリックします。「ディメンション」タブで、階層を選択して「追加」をクリックします。

v データ・ソース・クエリー・サブジェクトの埋め込み計算を作成するには、データ・ソース・クエリー・サブジェクトをダブルクリックします。「計算」タブで、「追加」をクリックします。

v モデル・クエリー・サブジェクトの埋め込み計算を作成するには、モデル・クエリー・サブジェクトをダブルクリックします。「クエリー・サブジェクト定義」タブで、「追加」をクリックします。

「計算の定義」ダイアログが表示されます。

2. 「名前」ボックスに、計算の名前を入力します。


目的操作

アイテムを追加する「モデル」タブで、クエリー・アイテム、フィルター、または計算をクリックし、矢印をクリックします。

関数を追加する「関数」タブで、コンポーネントを選択し、矢印をクリックします。

パラメーターを追加する「パラメーター」タブで、パラメーターをクリックし、矢印をクリックします。


「オプション」ボタンをクリックし、「返す最大行数を制限」チェック・ボックスを選択し、要求する戻り行数を入力します。



目的操作

セッション・パラメーターをオーバーライドする

「オプション」ボタンをクリックし、「設定」をクリックし、「オーバーライド値」フィールドに値を入力し、「OK」をクリックします。

プロンプト値をオーバーライドする「オプション」ボタンをクリックした後、「プロンプト」をクリックします。


4. 計算をテストするには、「テスト」ボタン


テストできるのは、クエリー・アイテムが含まれる計算のみです。計算に関数(例えば _add_days) が含まれる場合、「テスト・サンプル」ボタンは使用できません。

ヒント: 無効な式が計算に含まれる場合は、式エディターの「ヒント」ボックスで詳細を確認してください。


6. 計算が返すデータのタイプを指定するには、「データ型」プロパティーを変更します。

IBM Cognos Studio/Authoring ツールはこの情報を使用して、計算が返すデータの形式を設定します。

タスクの結果


v 177 ページの『セッション・パラメーターの作成』

v 134 ページの『ディメンションのテスト』

フィルターの作成フィルターは、フィルターの適用対象のディメンション、クエリー・サブジェクト、計算、またはレポート用に、行またはインスタンスが取り出されるために満たす必要のある条件を指定する式です。フィルターはブール値を返して、ディメンションまたはクエリー・サブジェクトから返される行を制限できるようにします。

例えば、in_range 関数を使用して、特定の時間枠内に導入された製品のデータを取り出すフィルターを作成できます。この例の構文は、次のようになります。

[gosales_goretailers].[Products].[概要date]in_range {Feb 14, 1999 : July 14, 2007}


注: 日付または時間関数を使用するときは、24 時間クロックを使用する必要があります。 IBM Cognos Framework Manager は、式での「a.m.」や「p.m.」をサポートしません。例えば、午後 8 時を表すために 20:00 を使用します。

セキュリティー・フィルターを作成することにより、プロジェクト内のディメンションまたはクエリー・サブジェクトで表されるデータを制限できます。セキュリティー・フィルターは、ユーザーがレポートをセットアップする際に表示されるデータを制御します。

ガバナーを適用することによって、パッケージ内のクエリーが取得するデータを制限することもできます。

Framework Manager は、独立したフィルターおよび埋め込みフィルターをサポートします。

v 独立したフィルターは、式を再使用する場合に使用します。

独立したフィルターを 1 つ以上のディメンションまたはクエリー・サブジェクトに追加して、フィルター済みディメンションやクエリー・サブジェクトがレポート内で使用されるときにクエリーが取得するデータを制限すること、またはユーザーが使用できるようにそのデータをパッケージに含めることができます。独立したフィルターまたはそれに対するショートカットをフォルダーに移動することにより、モデル・オブジェクトの編成を改善できます。

v 埋め込みフィルターは、ディメンションまたはクエリー・サブジェクトが 1 つだけ含まれるフィルターを使用する場合に使用します。

埋め込みフィルターは、ディメンション、リレーショナル・データ・ソースのクエリー・サブジェクト、またはモデル・クエリー・サブジェクトを変更する際に作成できます。

埋め込みフィルターから開始する場合、後にそれを他のディメンションまたはクエリー・サブジェクトに適用可能な独立した式に変換できます。ヒント: 「フィルター」タブでフィルター式を右クリックして、「独立したフィルターに変換」をクリックします。

フィルターを埋め込むとき、データ・ソースのクエリー・サブジェクトには、式で参照されるクエリー・サブジェクトに対する関係が存在しなければなりません。この関係は、式が参照するモデル・クエリー・サブジェクトが、式を埋め込むデータ・ソースのクエリー・サブジェクトと同じテーブルに基づいている場合でも必要です。

関係のないクエリー・サブジェクトにフィルターを作成するには、次のいずれかを実行します。

– 新しいクエリー・サブジェクトとフィルターを含むクエリー・サブジェクトとの間に結合パスがあることを確認します。

– 埋め込みフィルターを、必要なデータ・ソース・クエリー・サブジェクトに基づくクエリー・アイテムに基づくものとします。

– 計算を独立したフィルターに変換して、それがクエリー・サブジェクトの一部とならないようにします。

– 埋め込みオブジェクトを参照する独立したフィルターを作成します。


フィルターの作成手順

手順


v 独立したフィルターを作成するには、ネームスペースまたはフォルダーをクリックし、「操作」、「作成」、「フィルター」の順にクリックします。

v 埋め込みフィルターを作成する場合は、フィルターを含めるディメンションまたはクエリー・サブジェクトをダブルクリックし、「フィルター」タブをクリックした後、「追加」をクリックします。

2. 「名前」ボックスに、フィルターの名前を入力します。


ヒント: 無効な式がフィルターに含まれる場合は、式エディターの「ヒント」ボックスで詳細を確認してください。

目的操作

クエリー・アイテムおよびフィルターを追加する

「モデル」タブで、目的のオブジェクトを「式の定義」ボックスにドラッグします。

関数を追加する「関数」タブで、関数を「式の定義」ボックスにドラッグします。

パラメーターを追加する「パラメーター」タブで、パラメーターを「式の定義」ボックスにドラッグします。










タスクの結果

ガバナーを適用することによって、パッケージ内のクエリーが取得するデータを制限することもできます。詳細については、 338 ページの『ガバナー』を参照してください。


v 284 ページの『データ・セキュリティーの追加』

v 175 ページの『パラメーター・マップの作成』


v 103 ページの『クエリー・サブジェクトまたはクエリー・セットのテスト』

v 184 ページの『必須プロンプトとオプション・プロンプト』

フィルターの適用フィルターを適用するには、ディメンション、データ・ソース・クエリー・サブジェクト、またはモデル・クエリー・サブジェクトを変更する必要があります。クエリー・サブジェクトには、フィルターによって参照されるクエリー・アイテムが含まれているか、クエリー・アイテムを含むクエリー・サブジェクトへの関係パスが存在する必要があります。

ディメンションまたはクエリー・サブジェクトの中に独立型のフィルターを埋め込むことができますが、埋め込みフィルターごとに個別の使用法が必要な場合は、さまざまなバージョンの独立型フィルターを作成する必要があります。このようにしない場合、「必ず使用すべき」と設定されたインスタンスが存在するなら、オプションだと想定されたプロンプトでユーザーが入力を要求される可能性があります。必須およびオプションのプロンプトについては、 184 ページの『必須プロンプトとオプション・プロンプト』を参照してください。

例えばクエリー・サブジェクト A で独立型のフィルターを埋め込んで、それをオプションとして定義するとします。クエリー・サブジェクト B では、それを必須として定義します。両方のクエリー・サブジェクトを使用するレポートをユーザーが作成した場合、オプションと定義されたものも含めて、両方のフィルターで値を選ぶよう要求されます。同じクエリーの中で使われる場合、フィルターのすべてのインスタンスは必須と見なされます。これを解決するには、それぞれ独自の名前を付けて、さまざまなバージョンのフィルターを作成してください。

フィルターの適用手順

手順

1. フィルターを作成します。

2. フィルターを選択し、「操作」、「定義を編集」の順にクリックします。

3. 「フィルター」タブをクリックし、作成したフィルターを「フィルター」ボックスにドラッグします。

4. フィルターの使用方法値を選択します。


使用方法値説明

常時この使用方法値は、指定したデータがすべてのレポートからフィルターで除外されるようにする場合に使用します。例えば、保管しているものの報告しないようにする廃止情報が企業にある場合があります。

「常時」は使用方法のデフォルト値です。

デザイン・モードのみサンプル・レポート用にデータの小サブセットを取得します。この使用方法値は、すべてのデータを見る必要はないとき (例えばクエリー・サブジェクトのテスト時) に使用します。

Framework Manager でデザイン・モード・フィルターを適用するには、「テスト時にすべての関連したデザイン・モード・フィルターを適用」オプションを選択します。このオプションは、「テスト設定」タブで選択できます。

ユーザーは、レポートのレイアウトや書式の設計に重点を置いて、作業中にすべてのデータを取得したいわけではないときに、QueryStudio でデザイン・モード・フィルターを必要とする場合があります。 Query Studioでデザイン・モード・フィルターにアクセスするには、限定データを使用してレポートを実行します。

オプションフィルターがオプションであることを指定します。データをフィルターに掛けるプロンプトがユーザーに出されますが、ユーザーはそのプロンプトをブランクのままにしておくことができます。プロンプトがブランクの場合、Framework Manager はフィルターを無視し、ディメンションまたはクエリー・サブジェクトのすべてのデータを取得します。

オプション・プロンプトには ? ? 構文が必要です。

この使用方法値は、フィルターをいつ適用するかをユーザーが制御する場合に使用します。例えば、1 つの国について見たいときもあれば、すべての国のデータを見たいときもあります。国のオプション・フィルターは、次のようになります。

([GeoNamespace].[Countries]

.[CountryName]=

?WhichCountry?)


5. SQL を表示する場合は、「クエリー情報」タブをクリックします。


例 - 各国の通貨名の表示特定の国の通貨名を表示するクエリーを作成します。これを行うには、特定の国コードのデータを返すフィルターを作成し、各国の通貨名を取得するモデル・クエリー・サブジェクトにフィルターを適用します。

以下の例では、リレーショナル・データ・ソースを使用しています。

手順1. go_sales サンプル・モデルを開きます。これは、<c10 の場所

>/webcontent/samples/Models/go_sales/go_sales.cpf にあります。

2. 変換レート・テーブルの、値が 2 の国コードだけにデータの取得を限定するフィルターを作成します。

v 「フィルター」フォルダーをクリックし、「操作」、「作成」、「フィルター」の順にクリックし、新規フィルターに ConversionRateCountryCode という名前を付けます。

v 「モデル」タブをクリックします。

v 「使用可能なコンポーネント」ボックスで「データベース・ビュー」フォルダーを開いた後、「GoSales」フォルダーを開きます。

v 「国コード」クエリー・アイテムを「変換レート」クエリー・サブジェクトから「式の定義」ボックスに追加し、式の最後に ='2' と入力します。

v 「OK」をクリックします。

3. ISO Code という名前のモデル・クエリー・サブジェクトを作成します。

v 「使用可能なモデル・オブジェクト」ボックスで「データベース・ビュー」フォルダーを開きます。

v 「国」クエリー・アイテムおよび ISO 3 文字コード・クエリー・アイテムを「国」クエリー・サブジェクトから「クエリー・アイテムと計算」ボックスに追加します。

4. ConversionRateCountryCode フィルターを適用します。

v 「フィルター」タブをクリックします。

v 「フィルター」フォルダーを開き、ConversionRateCountryCode を「フィルター」ボックスにドラッグします。

5. 「クエリー情報」タブをクリックします。

結果セットに影響を与えない場合でも、生成される SQL にはフィルターが含まれます。

6. ConversionRateCountryCode フィルターの使用を「オプション」に変更します。

v 「フィルター」タブをクリックします。

v ConversionRateCountryCode フィルターの「使用方法」の下の省略符号 (...)ボタンをクリックし、「オプション」をクリックします。




パラメーター・マップの作成パラメーターを使用して、レポートが実行されるときの置き換えを可能にする、条件付きクエリー・サブジェクトを作成します。パラメーター・マップは、キーと値のペアを保管するオブジェクトです。

パラメーター・マップは、データ・ソースの参照テーブルと似ています。各パラメーター・マップには、キーのために 1 つと、キーが表す値のために 1 つの、2 つの列があります。キーと値は、手動で入力すること、ファイルからインポートすること、またはモデル内の既存のクエリー・アイテムに基づくものとすることができます。

パラメーター・マップをファイルにエクスポートすることもできます。パラメーター・マップを変更するには、マップ値をファイルにエクスポートし、追加や変更を行ってから、IBM Cognos Framework Manager にインポートして戻します。この方法は、大型で複雑なパラメーター・マップを扱う際に特に役立ちます。

すべてのパラメーター・マップのキーは、Framework Manager が正しい値を一貫して取得できるように、固有でなければなりません。パラメーター値を引用符で囲まないでください。パラメーターを使用する式の中では引用符を使用できます。

パラメーターの値を別のパラメーターにすることもできます。ただし、値全体を番号記号 (#) で囲む必要があります。パラメーターを値としてネストする際の制限は5 レベルです。

パラメーター・マップを関数への引数として使用するときは、ドル記号 ($) の代わりにパーセント記号 (%) を使用する必要があります。

別名は、名前の一部としてパラメーター・マップを使用するクエリー・アイテムに、そして複数言語による名前を「言語」タブ (「プロパティー」ウィンドウ) 内のオブジェクトに追加するために割り当てます。

パラメーター・マップを、50,000 行などの大きな結果セットを持つクエリー・アイテムやテーブルに基づくものとはしないでください。パラメーター・マップを式または SQL で使用するたびに、Framework Manager はこの大きなクエリーを実行することになってしまいます。その結果、パフォーマンスが低下します。パラメーター・マップはより小さい参照テーブルのために使用する必要があります。

パラメーター・マップの手動作成手順

手順

1. 「パラメーター・マップ」フォルダーをクリックし、「操作」、「作成」、「パラメーター・マップ」の順にクリックします。

2. 「名前」ボックスに、新しいパラメーター・マップの名前を入力します。

3. 「パラメーター・キーを手動で入力するか、ファイルからインポートする」をクリックし、「次へ」をクリックします。



v 手動で値を入力するには、「新規キー」をクリックし、キーを入力した後、Tab を押してそのキーの値を入力します。

v キーと値をインポートするには、「ファイルをインポート」をクリックし、該当する .csv ファイルまたは .txt ファイルの場所を指定します。 .txt ファイルをインポートに使用するためには、値がタブで区切られていなければならず、ファイルが UTF8 形式または Unicode 形式で保存されていなければなりません。ANSI テキスト・ファイルはサポートされていません。

注: データ・ソース・クエリー・サブジェクトでパラメーターを使用する場合、値には英語固有の句読点を使用しなければなりません。つまり、小数部を表すにはピリオド (.) を、値のリストを区切るにはコンマ (,) を、それぞれ使用する必要があることになります。

5. 必要に応じて既存のパラメーターを変更します。

目的操作

デフォルト値を割り当てる「デフォルト値」ボックスに、値を入力します。

式で使用されるキーがマップされない場合、デフォルト値が使用されます。

デフォルト値の設定はオプションです。しかし、デフォルトが設定されない場合、非マップ・キーによってエラーが生成される可能性があります。

オンデマンドでロードするキーを多数含んだパラメーター・マップは、レポート実行時のロードが遅い場合があります。「オンデマンドでロード」を true に設定することにより、ロードを特定のレポートに必要なキーのみに制限することができます。

デフォルトでは、値は false に設定されているので、すべてのキーがロードされます。

パラメーターを削除する行を選択し、「削除」をクリックします。

パラメーターを変更する変更する行を選択し、「編集」ボタンをクリックして、値を入力します。

キーと値をすべて消去する「マップをクリア」をクリックします。


既存のクエリー・アイテムのパラメーター・マップを基準とする手順

手順




3. 「既存のクエリー・アイテムのパラメーター・マップを基準とする」、「次へ」の順にクリックします。

4. キーとして使用するクエリー・アイテムをクリックした後、値として使用するクエリー・アイテムをクリックします。

どちらのクエリー・アイテムも同じクエリー・サブジェクトから派生したものである必要があります。


6. 「デフォルト値」ボックスに値を入力します。




タスクの結果

例 - リレーショナル・メタデータの言語値の指定ある国際企業が製品情報を英語とフランス語で保管しています。従業員はパラメーター・マップおよびマクロを使用して、必要な情報と一致するデータを取得できます。

以下を含む Language_lookup パラメーター・マップを作成します。

キー値

en EN

fr FR

「製品ライン」クエリー・サブジェクトの SQL を確認すると、以下のようになっています。

選択

PRODUCT_LINE.PRODUCT_LINE_CODE,

#'PRODUCT_LINE.PRODUCT_LINE_' + $Language_lookup{$runLocale}#as Product_Line

from

[gosales].PRODUCT_LINE PRODUCT_LINE

runLocale マクロは、言語値を指定するために Language_lookup マクロによって使用されるロケール設定を返します。

セッション・パラメーターの作成セッション・パラメーターは、IBM Cognos Framework Manager がセッションに関連付ける変数です。


例えば、ユーザー ID および優先言語は共にセッション・パラメーターです。セッション・パラメーターはキーと値の組なので、各セッション・パラメーターをセッション・パラメーターという名前のパラメーター・マップの項目と見なすことができます。セッション・パラメーターはパラメーター・マップの項目と同じ方法で使用しますが、セッション・パラメーターの構文は少し異なっています。

環境とモデルの、2 つのタイプのセッション・パラメーターがあります。

環境セッション・パラメーターは事前定義されて、Content Manager に保管されています。デフォルトで、以下のセッション・パラメーターが Framework Managerに表示されます。

v runLocale

Framework Manager での現在のアクティブ言語のコードを返します。モデルのコンテンツはこの言語で示されます。

現行セッション内についてのみ、アクティブ言語をいつでも変更できます。その後のセッションでは、モデルは引き続き設計言語で開かれます。詳細については、 142 ページの『プロジェクトへの言語の追加』を参照してください。

v account.defaultName

認証プロバイダーに定義された現在のユーザーの名前を指定します。例えば、ユーザーの姓名などです。

匿名でログオンした場合、Anonymous が表示されます。

v account.personalInfo.userName

IBM Cognos Analytics へのログオンに使用するユーザー ID を指定します。

匿名でログオンした場合、このパラメーターは表示されません。

v current_timestamp

現在の日時を指定します。

v machine

Framework Manager がインストールされるコンピューターの名前を指定します。

認証ソースが他のパラメーターをサポートし、それらに関する情報を認証ソースに入力した場合は、account.personalInfo.email や account.personalInfo.surname など、別のセッション・パラメーターが表示されます。

モデル・セッション・パラメーターを使用して、追加のパラメーターを定義できます。モデル・セッション・パラメーターは、_env という名のパラメーター・マップに保管されています。それらはプロジェクト内に設定されていて、パッケージによって発行できます。

モデル・セッション・パラメーターの値は、Framework Manager モデル内のオブジェクトの範囲内に設定されていなければなりません。その範囲には、既存の環境セッション・パラメーターや静的値の使用も含まれます。


各セッション・パラメーターには、名前とデフォルト値とが必要です。値が返す結果をテストするために、オーバーライド値を定義できます。オーバーライド値は、モデルがオープンされている間だけ有効で、モデルを保存するときには保存されません。オーバーライド値が存在しない場合、Framework Manager はセッション・パラメーターを含むクエリーを実行するときにデフォルト値を使用します。

パラメーターの使用を制御する規則には、以下のものがあります。

v 可能なすべての戻り値は同じデータ型でなければなりません。

v 定義できるのは 1 つの値だけです。

セッション・パラメーターの作成手順

手順

1. 「プロジェクト」、「セッション・パラメーター」の順にクリックします。

2. 「新規キー」をクリックし、セッション・パラメーターのキーと値を入力します。

3. オーバーライド値の扱いを選択します。

v プロジェクトを編集するたびにオーバーライド値を設定しなければならないのを避けるには、セッション・パラメーターを値として設定します。

v プロジェクト設定を発行するたびに事前に削除しなければならないのを避けるには、セッション・パラメーターをセッション・オーバーライドとして設定します。


目的操作

パラメーター値を変更する変更する値が含まれる行をクリックし、「編集」をクリックして、値を入力します。

デフォルト値を割り当てる「デフォルト値」ボックスに値を入力します。キーの値が無効の場合、FrameworkManager はデフォルト値を使用します。

パラメーターを削除する行をクリックし、「削除」ボタンをクリックします。環境セッション・パラメーターを削除することはできません。

オーバーライド値をクリアする行をクリックし、「オーバーライドをクリア」をクリックします。


リレーショナル・データ・ソース・クエリー・サブジェクトでのパラメーターの使用

モデル・オブジェクトが基づいているデータ・ソース・オブジェクトに対する変更は、モデル・オブジェクトに反映されません。したがって、データ・ソース・クエリー・サブジェクトにパラメーターを追加する場合は、そのパラメーターを参照するモデル・オブジェクトを作成するかどうかを検討してください。作成する場合は、データ・ソース・クエリー・サブジェクト内のパラメーター化オブジェクトに別名を割り当てる必要があります。こうすることで、パラメーター値が変わって


も、そのオブジェクトを参照するモデル・クエリー・サブジェクト、フィルター、または計算が、正しい結果を返すようになります。

例えば、次の SQL は、runLocale という名前のセッション・パラメーターを含んだデータ・ソース・クエリー・サブジェクトを定義しています。 runLocale パラメーター値は、クエリーが取得する列を指定します。別名はショートカットのように動作するので、モデル・オブジェクトが CountryNameAlias を参照すると、IBMCognos Framework Manager はその別名が割り当てられた値を取得します。

選択#$ColumnMap{$runLocale}# asCountryNameAliasFrom[GoSales].Country

クエリー・マクロを使用したプロンプトの作成マクロは、クエリー・サブジェクトを定義する Select ステートメントのどこにでも挿入できるコード・フラグメントです。セッション・パラメーター、パラメーター・マップ、およびパラメーター・マップ・エントリーへの参照を含めることができます。パラメーター値はクエリーを実行するときに設定されます。

例えば、言語セッション・パラメーターを使用して、現行ユーザーの言語設定に一致するデータのみを表示することができます。

以下のようにさまざまにマクロを使用できます。

v SQL に挿入できます。

例: Select * from Country where Country.Name = #$myMap{$runLocale}#

v ストアード・プロシージャー・クエリー・サブジェクトに引数を提供することができます。

引数の値がハードコーディングされていなければ、ストアード・プロシージャー・クエリー・サブジェクトを使用して異なるデータを返すことができます。

v 計算やフィルターなどの式に挿入できます。

例えば、フィルター [gosales].[Sales staff].[Staff name] =

#$UserLookUpMap{$UserId}# などです。

v データ・ソース・クエリー・サブジェクトのプロパティーの値を動的に設定するのに使用できます。

このことは、ユーザーがそれぞれ異なる接続情報を指定し、したがって異なるデータ・ソースにアクセスすることを可能にします。マクロを含むことができるプロパティーは、「Content Manager データ・ソース」、「カタログ」、「キューブ」、「スキーマ」です。

「Content Manager データ・ソース」プロパティーを使用した例:#$DataSourceMap{$UserId}#

v パラメーター・ウィザードとして使用できます。

パラメーターは他のパラメーターを参照できます。例: Map1, Key = en-us,

Value = #$myMap{$UserId}#


v 「セッション・パラメーター」ダイアログ・ボックスで使用できます。

例えば、MySessionParameter, value = #$myMap{$UserGroup}# などです。

以下のクエリー・サブジェクト要素はパラメーターに置き換えることができます。

要素例

Select リストで識別されるクエリー・アイテム

#'Product_name_'+ $languageCode#

From 節で識別されるテーブル Product_#$language#

Where 節 Product_lang = #sq($languageCode)#

データ・ソース、スキーマ、またはソース・プロパティーの名前

#$data_source#.#$schema#.Products

構文次の構文を使用して、セッション・パラメーターおよびパラメーター値を参照します。

オブジェクト構文例

セッション・キー $session_key #$my_account#

パラメーター・マップ・キー $map{<key>} #$map_one{'abc'}#

セッション・パラメーターによってキーが定義されるパラメーター・マップ・エントリー

$map{$session_key} #$map_one{$my_account}#

以下の要素を追加して、マクロ式をより詳細に定義できます。

記号目的

一重引用符 ' 文字列の一部として一重引用符があるリテラル文字列の輪郭を示します。

クエリー・アイテムがある場合など、一重引用符が文字列内に表示されるときには、文字列の両側に一重引用符を付けてその文字列を囲み、中の一重引用符を二重にする必要があります。例えば、「ab'c」は 'ab''c' のように記述します。

一重引用符がマクロ内に表示される場合、文字列を大括弧で囲む必要があります。例えば、「ab'c」は [ab'c] のように記述します。

一重引用符がプロンプト内に表示される場合、文字列を記号で囲む必要はありません。

式の単一引用符をエスケープする場合は、' を使用します。


記号目的

大括弧 [ ] モデル・オブジェクト (ネームスペースやクエリー・サブジェクトなど)、および制限文字(番号記号、ハイフン、スペースなど) を含むマクロ名を囲みます。

ブレースとも呼ばれる中括弧 { } IBM Db2 での dateadd など、パーサーで認識できず、最初の引数がキーワードである関数を呼び出します。

例:

dateadd({month},2,<dateexpression>)

+ 演算子 'abc' + 'xyz' のように、2 つの文字列を連結します。

一重引用符関数 (sq) 文字列式の結果を一重引用符記号で囲みます。クエリー・アイテムがある場合など、一重引用符が文字列内に表示されるときには、文字列の両側に一重引用符を付けてその文字列を囲み、中の一重引用符を二重にする必要があります。この関数を使用して、リテラル・パラメーター駆動の値に照らしてテストするための節を構築できます。


#sq($my_sp)#

セッション・パラメーター (my_sp) の値がab'cc の場合、結果は次のとおりです。

'ab"cc'

二重引用符関数 (dq) 文字列式の結果を二重引用符記号で囲みます。この関数を使用して、ブランク・スペースやパーセント記号 (%) などの非識別子文字が含まれる表名および列名を参照できます。


#dq('Column' + $runLocale)#

runLocale=en-us の場合、結果は次のとおりです。

"Column en-us"


記号目的

大括弧関数 (sb) 一組の大括弧を引数に挿入して、フィルターや計算などのオブジェクト参照を、モデル・クエリーおよびモデル式の中に構築します。


#sb('my item in ' + $runLocale)#

runLocale=en-us の場合、結果は次のとおりです。

[my item in en-us]

マクロの作成マクロは、クエリー・サブジェクトを定義する Select ステートメントのどこにでも挿入できるコード・フラグメントです。セッション・パラメーター、パラメーター・マップ、およびパラメーター・マップ・エントリーへの参照を含めることができます。パラメーター値はクエリーを実行するときに設定されます。

パラメーターを参照するときは、以下のようにする必要があります。

v 1 つ以上のパラメーターの各セットの始めと終わりに番号記号 (#) を使用します。

番号記号の間にあるものはすべて、実行時に処理されるマクロ式として扱われます。 Framework Manager は、番号記号の外側にあるものはすべて除去します。

v 各パラメーター・マップ・エントリーの先頭にドル記号 ($) 付けます。

v アルファベット文字 (a..z, A..Z) で始まる名前を使用します。

既存の引用符または大括弧の間にマクロを挿入しないでください。IBM CognosFramework Manager は、これらの要素の内側にあるものは実行しません。

手順

1. 変更するデータ・ソース・クエリー・サブジェクトを選択します。


3. 「SQL」タブで、「マクロを挿入」をクリックしてマクロ・エディターを開始します。

4. 「利用可能なコンポーネント」ボックスで、使用するパラメーター・マップ、セッション・パラメーター、または関数をクリックして、「マクロ定義」ボックスにドラッグします。

必ず番号記号の間にマクロ式を入力するようにしてください。番号記号の前または後にテキストを入力した場合、「OK」をクリックすると、FrameworkManager はそのテキストを削除します。

5. 一重引用符機能または二重引用符機能を挿入します。


ヒント: 引用符を置くための選択項目のメニューを表すこれらのボタン

の横にある矢印をクリックします。

6. パラメーター・マップまたはセッション・パラメーターを編集する場合は、それを「マクロ定義」ボックスでクリックします。

「パラメーター・マップ」または「セッション・パラメーター」ダイアログ・ボックスが表示されます。セッション・パラメーターのオーバーライド値の設定や、新しいアイテムの追加、値の変更が可能です。

7. 「情報」ボックスでマクロを確認します。

マクロが正しくない場合は、エラー・メッセージが表示されます。

ヒント: マクロをクリアするには、「すべてクリア」アイコン



必須プロンプトとオプション・プロンプトクエリー・マクロを使用して、IBM Cognos Framework Manager モデルに必須プロンプトとオプション・プロンプトを作成できます。2 つのプロンプト・マクロ関数 (prompt および promptmany) を使用して、単一値プロンプトと複数値プロンプトを作成できます。クエリー・サブジェクトを定義する SQL ステートメントのどこにでもプロンプト・マクロを挿入できます。

計算などの式でプロンプト・マクロを使用する場合は、正符号 (+) などの多重定義演算子を使用するときにデータ型を指定する必要があります。正符号を使用して、2つのアイテムを連結したり、2 つのアイテムを加算したりすることができます。

ディメンション・レベルでフィルターを定義し、そのフィルターで prompt マクロまたは promptmany マクロを使用する場合は、データ型 memberuniquename とデフォルト値を指定する必要があります。フィルターの適用については、 172 ページの『フィルターの適用』を参照してください。


members( [MS_gosales].[New Dimension].[PRODUCTLINE].[PRODUCTLINE])

in ( set( #promptmany('what', 'memberuniquename',

'[MS_gosales].[PROD1].[PRODUCTLINE].[PRODUCTLINE]

->[all].[1]')# ) )

必須プロンプトの例を次に示します。

selectCOUNTRY_MULTILINGUAL.COUNTRY_CODE as COUNTRY_CODE,COUNTRY_MULTILINGUAL.COUNTRY as COUNTRY,COUNTRY_MULTILINGUAL."LANGUAGE" as LANGUAGE1,COUNTRY_MULTILINGUAL.CURRENCY_NAME as CURRENCY_NAMEfromgosales.gosales.dbo.COUNTRY_MULTILINGUAL COUNTRY_MULTILINGUALwhere COUNTRY_MULTILINGUAL.COUNTRY = #prompt('CountryName')#


マクロ・プロンプトの構文でデフォルト値を指定すると、エラーが表示されることがあります。 where Country = ?Enter Country? などのプロンプト構文を使用してください。

prompt および promptmany 関数には、以下のパラメーターがあります。すべての引数値は、文字列として指定する必要があります。

Name

このパラメーターは必須で、プロンプトの名前を指定します。Name パラメーターは、ユーザーが作成したプロンプト・ページのパラメーター名を参照することも可能です。この場合、マクロが生成するデフォルトのプロンプト・ページではなくユーザーが作成したプロンプト・ページがレポートの実行時に表示されます。

データ型

このパラメーターはオプションで、プロンプト値のデータ型を指定します。デフォルト値は string です。プロンプト値は検証されます。string の場合、指定された値は一重引用符に囲まれ、文字列内部の一重引用符は二重になります。

値には次のものがあります。

v boolean

v date

v datetime

v decimal

v double

v float

v int

v integer

v interval

v long

v memberuniquename

memberuniquename は実際のデータ型ではありません。この値は、パラメーターのデータ型が、メンバー内で一意の名前 (Member Unique Name:MUN) である場合に使用する必要があります。

v numeric

v real

v short

v string

v time

v timeinterval

v timestamp

v token


token は実際のデータ型ではありません。SQL を渡すための方法です。トークンによって値が渡されるわけではありません。

v xsddate

v xsddatetime

v xsddecimal

v xsddouble

v xsdduration

v xsdfloat

v xsdint

v xsdlong

v xsdshort

v xsdstring

v xsdtime

DefaultText

このパラメーターはオプションで、デフォルトで使用されるテキストを指定します。値が指定された場合、プロンプトはオプションです。

スペースを使用し、「プロンプト値」ダイアログ・ボックスで値が指定されていない場合、通常は Where 句は生成されません。

テキストを使用し、「プロンプト値」ダイアログ・ボックスで値が指定されていない場合は、通常は Where 句はデフォルト値を使用して生成されます。

指定したテキストによって有効な SQL 文が生成されることを確認してください。

注:データ型が memberuniquename の場合は、DefaultText パラメーターの値を指定する必要があります。次に例を示します。

(#prompt('WhichLevel', 'memberuniquename',

'[goSalesAgain].[PRODUCT1].[PRODUCT].[PRODUCT(All)]->[all]')#)

テキスト

このオプションのパラメーターには、ユーザー指定値の前に配置する「'and

column1 = '」などのテキストを指定します。

QueryItem

このパラメーターはオプションです。プロンプト・エンジンでは、クエリー・アイテムの「プロンプト情報」プロパティーを使用できます。プロンプト値がコードでも、説明情報を表示できます。

TextFollowing

このパラメーターはオプションで、多くの場合、promptmany 関数に使用される閉じ括弧を指定します。また、このパラメーターは、プロンプトがオプションで、SQL文で後ろにハードコードされたフィルターが続く場合にも便利です。


例 - 国または地域のプロンプトの選択レポートが実行されるとき、表示するデータの国または地域の選択を求めるプロンプトをユーザーに出すことができます。次のコード例は、マクロを使用してさまざまなプロンプトを作成する方法を示しています。

データ型が指定されていない必須プロンプト:

以下に注意してください。

v Datatype 引数は指定されていません。そのため、これは文字列になります。この場合、文字列で間違いありません。

v DefaultText 引数は指定されていません。そのため、これは必須プロンプトになります。

selectCOUNTRY_MULTILINGUAL.COUNTRY_CODE as COUNTRY_CODE,COUNTRY_MULTILINGUAL.COUNTRY as COUNTRY,COUNTRY_MULTILINGUAL."LANGUAGE" as LANGUAGE1,COUNTRY_MULTILINGUAL.CURRENCY_NAME as CURRENCY_NAMEfromgosales.gosales.dbo.COUNTRY_MULTILINGUAL COUNTRY_MULTILINGUALwhere COUNTRY_MULTILINGUAL.COUNTRY = #prompt('CountryName')#

データ型が指定されている必須プロンプト:


v このプロンプトは、応答として有効な整数値を必要とします。

v DefaultText 引数は指定されていません。そのため、これは必須プロンプトになります。

selectCOUNTRY_MULTILINGUAL.COUNTRY_CODE as COUNTRY_CODE,COUNTRY_MULTILINGUAL.COUNTRY as COUNTRY,COUNTRY_MULTILINGUAL."LANGUAGE" as LANGUAGE1,COUNTRY_MULTILINGUAL.CURRENCY_NAME as CURRENCY_NAMEfromgosales.gosales.dbo.COUNTRY_MULTILINGUAL COUNTRY_MULTILINGUALwhere COUNTRY_MULTILINGUAL.COUNTRY_CODE >#prompt('Starting CountryCode','integer','','',

'[gosales].[COUNTRY_MULTILINGUAL].[COUNTRY_CODE]')#

データ型およびデフォルト値を指定したオプションのプロンプトと必須のフィルター:


v このプロンプトでは、ユーザーは有効な整数応答を提供できます。

v DefaultText 引数が指定されています。そのため、ユーザーは値の入力を省略することができます。省略する場合、値として 10 が使用されます。これにより、それはオプションのプロンプトとなります。ただし、オプションのフィルターにはなりません。

例 1:


selectCOUNTRY_MULTILINGUAL.COUNTRY_CODE as COUNTRY_CODE,COUNTRY_MULTILINGUAL.COUNTRY as COUNTRY,COUNTRY_MULTILINGUAL."LANGUAGE" as LANGUAGE1,COUNTRY_MULTILINGUAL.CURRENCY_NAME as CURRENCY_NAMEfromgosales.gosales.dbo.COUNTRY_MULTILINGUAL COUNTRY_MULTILINGUALwhere COUNTRY_MULTILINGUAL.COUNTRY_CODE >#prompt('Starting CountryCode',

'integer','10'

)#

例 2:

[gosales].[COUNTRY].[COUNTRY] = #prompt('countryPrompt','string','''Canada''')#Result 2:[gosales].[COUNTRY].[COUNTRY] = 'Canada'


v defaultText パラメーターは、マクロのコンテキストでそのまま有効になるように指定する必要があります。この値に対しては、書式設定が実行されないためです。詳細については以下を参照してください。

v 例 2 のデフォルト文字列 Canada は、単一引用符を使用して文字列として指定されています。ここでは、埋め込み用の単一引用符が二重に指定されているので、引用符が 3 つになっています。その結果、式の中で文字列が一重引用符の中に正しく表示されるようになります。

v 一般的に、datatype が string の場合、ストアード・プロシージャー・パラメーターのコンテキスト以外では、必ず defaultText を上記の注のように指定する必要があります。

v defaultText が date 型や datetime 型の場合、SQL のコンテキストでは特別な書式を使用する必要があります。そのような書式の例は、'DATE

''2012-12-25''' や 'DATETIME ''2012-12-25 12:00:00''' などです。それ以外のコンテキストではすべて、キーワードもエスケープされた単一引用符もないdate/datetime ('2012-12-25' など) を使用します。

テキストを値に付加するプロンプト:


v DefaultText 引数が空白文字として指定されています。この例では、生成されるテキストは空白文字だけで、Where 節はクエリーから除去されます。

v Text 引数が指定されています。この引数は、ユーザー提供のプロンプト値より前に、生成された SQL に書き込まれます。

selectCOUNTRY_MULTILINGUAL.COUNTRY_CODE as COUNTRY_CODE,COUNTRY_MULTILINGUAL.COUNTRY as COUNTRY,COUNTRY_MULTILINGUAL."LANGUAGE" as LANGUAGE1,COUNTRY_MULTILINGUAL.CURRENCY_NAME as CURRENCY_NAMEfromgosales.gosales.dbo.COUNTRY_MULTILINGUAL COUNTRY_MULTILINGUAL#prompt('Starting CountryCode',

'integer',' ', // < = = this is a space'where COUNTRY_MULTILINGUAL.COUNTRY_CODE >')#


構文の置換:


v Datatype 引数が token に設定されています。これは、ユーザー提供の値が何もチェックされずに入力されることを意味します。

値に対してチェックが実行されないため、式が無効であることが式エディターで指摘される場合があります。有効なユーザー提供の値が提供されるか、有効なデフォルト値が提供されると、式エディターは式が有効であると解釈します。

v Token は、ユーザーのピック値リストがある場合にのみ使用してください。

v DefaultText 引数が指定されています。したがって、これはオプションのプロンプトであり、生成される SQL では group by COUNTRY が使用されます。

選択COUNTRY_MULTILINGUAL.COUNTRY_CODE as COUNTRY_CODE,COUNTRY_MULTILINGUAL.COUNTRY as COUNTRY,COUNTRY_MULTILINGUAL."LANGUAGE" as LANGUAGE1,COUNTRY_MULTILINGUAL.CURRENCY_NAME as CURRENCY_NAMEfromgosales.gosales.dbo.COUNTRY_MULTILINGUAL COUNTRY_MULTILINGUAL#prompt('Sort column',

'token','group by COUNTRY',

'group by ')#

例 - パラメーター・マップを使用するプロンプトの作成レポートが実行されるとき、ユーザーにレポート内のデータの言語を選択させることができます。以下の例は、これを行うためのいくつかの方法を示しています。

セッション変数を使用するプロンプト:


v プロンプトの名前は、パラメーター・マップ PromptLabels で lookup を使用して指定されます。キー値は、セッション変数 $language です。

v Where 節はパラメーター化された列を使用しています。

selectORDER_METHOD.ORDER_METHOD_CODE as ORDER_METHOD_CODE,ORDER_METHOD.ORDER_METHOD_#$language#as ORDER_METHOD_ENfromgosales.gosales.dbo.ORDER_METHOD ORDER_METHOD#prompt($PromptLabels{$language},'',' ','where ORDER_METHOD.ORDER_METHOD_' + $language + '>')#

プロンプトをネストするパラメーター・マップ:


v このモデルには、#$PromptLabels{$language}# を使用するパラメーター・マップ DynPromptLabels があります。


v SQL 内に直接コード化される代わりに、プロンプト情報の一部がパラメーター・マップから実行されます。

v プロンプトを含むマクロ全体をパラメーター・マップの値として指定できます。

selectORDER_METHOD.ORDER_METHOD_CODE as ORDER_METHOD_CODE,ORDER_METHOD.ORDER_METHOD_#$language#as ORDER_METHOD_ENfromgosales.gosales.dbo.ORDER_METHOD ORDER_METHOD#prompt($DynPromptLabels{'ex9'},'',' ','where ORDER_METHOD.ORDER_METHOD_' + $language + '>')#

例 - 複数の値プロンプトの作成レポートが実行されるとき、ユーザーに 1 つ以上の値を選択させることができます。以下の例は、これを行うためのいくつかの方法を示しています。

必要最小設定のプロンプト:


v ユーザーは少なくとも 1 つの値を入力しなければなりません。

v これは、国または地域の入力を求める最初のプロンプト例と似ています 187 ページの『データ型が指定されていない必須プロンプト』。

selectCOUNTRY_MULTILINGUAL.COUNTRY_CODE as COUNTRY_CODE,COUNTRY_MULTILINGUAL.COUNTRY as COUNTRY,COUNTRY_MULTILINGUAL."LANGUAGE" as LANGUAGE1,COUNTRY_MULTILINGUAL.CURRENCY_NAME as CURRENCY_NAMEfromgosales.gosales.dbo.COUNTRY_MULTILINGUAL COUNTRY_MULTILINGUALwhere COUNTRY_MULTILINGUAL.COUNTRY IN (#promptmany('CountryName')#)

データ型の指定された必要最小設定のプロンプト:


v これは、国または地域の入力を求める 2 番目のプロンプト例と似ています 187 ページの『データ型が指定されている必須プロンプト』。

selectCOUNTRY_MULTILINGUAL.COUNTRY_CODE as COUNTRY_CODE,COUNTRY_MULTILINGUAL.COUNTRY as COUNTRY,COUNTRY_MULTILINGUAL."LANGUAGE" as LANGUAGE1,COUNTRY_MULTILINGUAL.CURRENCY_NAME as CURRENCY_NAMEfromgosales.gosales.dbo.COUNTRY_MULTILINGUAL COUNTRY_MULTILINGUALwhere COUNTRY_MULTILINGUAL.COUNTRY_CODE IN (#promptmany('Selected CountryCodes',

'integer','','','[gosales].[COUNTRY_MULTILINGUAL].[COUNTRY_CODE]')#

)

データ型とデフォルト値が指定されたオプションのプロンプト:

In 節および両方の括弧は、SQL ステートメントの一部です。


selectCOUNTRY_MULTILINGUAL.COUNTRY_CODE as COUNTRY_CODE,COUNTRY_MULTILINGUAL.COUNTRY as COUNTRY,COUNTRY_MULTILINGUAL."LANGUAGE" as LANGUAGE1,COUNTRY_MULTILINGUAL.CURRENCY_NAME as CURRENCY_NAMEfromgosales.gosales.dbo.COUNTRY_MULTILINGUAL COUNTRY_MULTILINGUALwhere COUNTRY_MULTILINGUAL.COUNTRY_CODE IN (#promptmany('Selected CountryCodes',

'integer','10'

)#)

構文の前にテキストを追加するプロンプト:


v この例では TextFollowing 引数を使用しています。

selectCOUNTRY_MULTILINGUAL.COUNTRY_CODE as COUNTRY_CODE,COUNTRY_MULTILINGUAL.COUNTRY as COUNTRY,COUNTRY_MULTILINGUAL."LANGUAGE" as LANGUAGE1,COUNTRY_MULTILINGUAL.CURRENCY_NAME as CURRENCY_NAMEfromgosales.gosales.dbo.COUNTRY_MULTILINGUAL COUNTRY_MULTILINGUAL#promptmany('Selected CountryCodes',

'integer',' ', // < = = this

is a space'where COUNTRY_MULTILINGUAL.COUNTRY_CODE IN

( ','',')'

)#

構文の前にテキストを追加するオプションのプロンプト:

選択COUNTRY_MULTILINGUAL.COUNTRY_CODE as COUNTRY_CODE,COUNTRY_MULTILINGUAL.COUNTRY as COUNTRY,COUNTRY_MULTILINGUAL."LANGUAGE" as LANGUAGE1,COUNTRY_MULTILINGUAL.CURRENCY_NAME as CURRENCY_NAMEfromgosales.gosales.dbo.COUNTRY_MULTILINGUAL COUNTRY_MULTILINGUAL,gosales.gosales.dbo.COUNTRY XXwhere COUNTRY_MULTILINGUAL.COUNTRY_CODE = XX.COUNTRY_CODE#promptmany('Selected CountryCodes',

'integer',' ',

' and COUNTRY_MULTILINGUAL.COUNTRY_CODE IN (','',')'

)#

モデルの編成モデルを編成すると、ユーザーはモデル内のデータをより容易に見つけたり理解したりできるようになります。また、モデルの管理および保守もより容易になります。

以下のようにして、モデル内に複数のビューまたはレイヤーを作成することをお勧めします。


v 別個のネームスペースまたはフォルダーにデータ・ソースからのメタデータを保存します。

IBM Cognos Framework Manager では、これはインポート・ビューと呼ばれます。

v クエリー・サブジェクトまたはディメンション・オブジェクトを使用したクエリーの実行に影響する複雑さを解決するために、オプションのネームスペースかフォルダーを 1 つ以上作成する。

IBM Cognos Analysis Studio または任意の OLAP スタイルのクエリーを使用するためには、ディメンション・オブジェクトのあるメタデータを表すモデル内にネームスペースかフォルダーが必要です。

v ディメンションやクエリー・サブジェクトへのショートカットを含むメタデータの拡張されたビジネス・ビュー用に、ネームスペースまたはフォルダーを 1 つ以上作成します。

Framework Manager では、これらはビジネス・ビューと呼ばれます。ビジネスの概念を使用して、ビジネス・ビューのモデルを作成します。それぞれ異なるユーザー・グループに適した多数のビジネス・ビューを 1 つのモデルに含めることができます。それらのビジネス・ビューを発行します。

どのビューにもセキュリティーを定義することが可能です。これは実際のビジネス要件に依存します。例えば、誰でもオブジェクトを参照できる状態を避ける必要があれば、インポート・ビュー内のオブジェクトにセキュリティーを追加します。通常、ビジネス・ビューにはセキュリティーが適用されます。

スター・スキーマ・グループの作成

どのオブジェクトがグループを形成しているかに関するコンテキストをユーザーに示すショートカットのグループを素早く作成するために、「スター・スキーマ・グループ」ウィザードを使用します。これにより、ユーザーはモデルをより直観的に利用できるようになります。また、スター・スキーマ・グループでは異なるグループ内で共有ディメンションを繰り返すことができるため、複数ファクトのレポートも作成しやすくなります。こうして、さまざまなグループに共通するアイテムや、部門の枠を超えた組織全体の (つまり複数ファクトの) レポート作成方法をユーザーが理解しやすくなります。詳細については、 388 ページの『複数ファクト、複数細分性のクエリー』を参照してください。

また、スター・スキーマ・グループには、複数の結合パスを持つクエリー用のコンテキストも用意されています。モデルのビジネス・ビュー内にスター・スキーマ・グループを作成すると、多くの結合パスを使用できる場合に、どれを選択すべきかを明確にすることができます。これは特に、ファクトのないクエリーの場合に便利です。

スター・スキーマ設計では、数値によるトランザクション・データが中央のファクト表に含まれ、関連する複数のディメンション表がファクト表から放射状に広がっています。


スター・スキーマ・グループには、選択したディメンション、クエリー・サブジェクト、またはショートカットを含めることができます。スター・スキーマ・グループ内のオブジェクトとグループ外のオブジェクトとは、相互に参照できません。そのため、Framework Manager は、グループ外のオブジェクトから参照されるオブジェクトへのショートカットを自動的に作成します。


v 販売日付 (時間)

v 販売場所 (地域)

v 製品詳細 (製品)

v 顧客情報 (顧客)

ファクト表には数量を含めます。

スター・スキーマの作成

手順

1. 1 つ以上のディメンションまたはクエリー・サブジェクトを選択します。

2. 「ツール」、「スター・スキーマ・グループを作成」の順にクリックします。

3. オブジェクトをグループから除外するには、「使用できるオブジェクト」ボックスで、オブジェクトの横にあるチェック・ボックスをオフにします。


v グループへのショートカットを追加するには、「選択したすべてのオブジェクトのショートカットを作成」をクリックします。

v オブジェクトをグループに移動するには、「スター・スキーマ外部で使用するオブジェクトに対してのみショートカットを作成」をクリックします。

5. 選択されたオブジェクトを別のネームスペースに移動するには、「このグループの新規ネームスペースを作成」チェック・ボックスがオンになっていることを確認し、「ネームスペース名」ボックスに名前を入力します。



7. 複数の関係が存在する場合 (ロール・プレイング・ディメンションとも呼ばれる)、その関係のショートカットを作成します ( 78 ページの『関係のショートカットの作成』)。名前を変更する必要がある場合は、ディメンションまたはクエリー・サブジェクトを個別に作成します。

1 つのディメンションまたはクエリー・サブジェクトに基づいたスター・スキーマ・グループ一般に、スター・スキーマ・グループに入れたいディメンションまたクエリー・サブジェクトのそれぞれとの関係が設定されているのがファクトである場合は、単一オブジェクトを選択します。 1 つのオブジェクトに基づいたスター・スキーマ・グループを作成すると、以下のようになります。

v Framework Manager は、グループに入れたいオブジェクトを素早く選択できるように、関係が設定されているオブジェクトのリストを表示します。

v グループの名前はファクト表の名前に基づきます。

v 新しいグループは、選択したオブジェクトと同じ親の下に作成されます。

複数のディメンションまたはクエリー・サブジェクトに基づいたスター・スキーマ・グループまだ関係が定義されていないディメンションまたはクエリー・サブジェクトをグループ化する場合は、複数のディメンションまたはクエリー・サブジェクトを選択すると有用です。新しいグループは、ディメンションまたはクエリー・サブジェクトの最も近い共通の親の下に置かれます。

複数の一致するスター・スキーマの解決

複数のファクト・クエリー・サブジェクトに結合されたディメンション・クエリー・サブジェクトが存在することがあります。数値データ・ディメンションやファクト・クエリー・サブジェクトのアイテムを含めずに、複数のディメンションまたはディメンション・クエリー・サブジェクトのアイテムを使ってレポート作成する際には、結合のあいまいさが問題になります。これを、ファクトのないクエリーといいます。

次の例では、Product dimension (製品ディメンション) と Time dimension (時間ディメンション) が、Product forecast fact (製品販売予測ファクト) および Salesfact (販売ファクト) に関連付けられています。


このような関係を使用して、Product と Time のアイテムのみを使用するレポートをどのようにして作成すればよいのでしょうか。例えば、どの製品について 2005年の売上予測をしたか、または 2005 年にどの製品が実際に売れたかということがビジネス上の問題点となり得ます。このクエリーに含まれるのは Product と Timeのみですが、これらのディメンションは複数のファクトを経由して関連しています。ビジネス上のどの問題点が問われているかを推測する方法はありません。この場合、ファクトのないクエリーのコンテキストを設定する必要があります。

この例では、Product、Time、Product forecast へのショートカットを含むネームスペースと、Product、Time、Sales を含むネームスペースの 2 つを作成することを推奨します。


すべてのスター・スキーマに関してこの作業を行うと、ファクトとすべてのディメンションへのショートカットを 1 つのネームスペース内に配置することにより、結合のあいまいさを解消できます。各ネームスペース内の一致するディメンションのショートカットは同じであり、元のオブジェクトの参照となります。注: 標準ディメンションと数値データ・ディメンションにはまったく同じ規則が適用されます。

各スター・スキーマにネームスペースを使用することで、どのアイテムを使用すべきかユーザーにとって明確になります。 2005 年にどの製品が実際に販売されたかに関するレポートを作成するには、Sales ネームスペースの Product と Year を使用します。このコンテキストで該当する唯一の関係は Product、Time、Sales 間の関係であり、これを使ってデータが返されます。

スター・スキーマの解決:

手順

1. 数値データ・ディメンションの 1 つを選択します。

2. 「ツール」メニューから「スター・スキーマ・グループを作成」をクリックします。

3. オブジェクトをグループから除外するには、「使用できるオブジェクト」ボックスで、オブジェクトの横にあるチェック・ボックスをオフにします。

4. 「選択したすべてのオブジェクトのショートカットを作成」をクリックします。


5. 選択されたオブジェクトを別のネームスペースに移動するには、「このグループの新規ネームスペースを作成」チェック・ボックスがオンになっていることを確認し、「ネームスペース名」ボックスに名前を入力します。


7. 他の数値データ・ディメンションに対してこの手順を繰り返します。

スノーフレーク・ディメンションのスター・ディメンションとしてのモデル化スノーフレーク・ディメンションは、下位のカーディナリティー属性をディメンション・テーブルから削除し、人工的なキーによって元のディメンションに再びリンクされる 2 次ディメンションに配置します。

スノーフレーク・ディメンションをスター・ディメンションとしてモデル化するには、次の操作を実行します。

手順

1. データへのアクセスに必要なクエリー・サブジェクトを選択し、新規ネームスペースに配置します ( 201 ページの『フォルダーまたはネームスペースの作成』)。

2. すべての関係が正しいことを確認します ( 72 ページの『関係』)。

3. 多言語メタデータを処理します ( 138 ページの『多言語メタデータ』)。

4. スノーフレーク・ディメンションごとにモデル・ディメンションを作成します。

v 必要なクエリー・サブジェクトを選択します。

v 「操作」、「新規標準ディメンションにマージ」の順にクリックします。

v 新規モデル・ディメンションの名前を変更します。デフォルトで、その名前は元のオブジェクトの名前の連結によって構成されます。

5. 複数レベルが必要な場合、次のいずれかを行います。

v ディメンション・マップを使用して、ディメンションの階層およびレベルを定義します ( 119 ページの『標準ディメンションの作成』)。

v レベルが単一クエリー・サブジェクトに保管されている場合、行列式を指定します ( 94 ページの『行列式』)。

ショートカットショートカットは、関係やディメンション、クエリー・サブジェクト、フォルダーなどのオブジェクトへのポインターです。ユーザー・グループ間で重なり合いがあり、複数のフォルダーにメタデータを含めたい場合は、ビジネス・ビューでショートカットを使用します。ショートカットによって、1 つのオブジェクトへの参照を複数持つことができます。

例えば、Orders、Products、および Customers というフォルダーを作成するとします。Orders と Customers の両方に同じディメンションを含める場合は、そのディメンションへのショートカットを作成し、両方のフォルダーに追加する必要があります。


注: ネームスペースまたはフォルダーへの 2 つのショートカットが、モデル内で同じ名前であってはなりません。他のタイプのショートカット (例えばクエリー・サブジェクトのショートカット) の場合、名前は親ネームスペース内で固有でなければなりません。

ショートカットの作成時、IBM Cognos Framework Manager は「画面のヒント」プロパティーと「説明」プロパティーを設定しません。これらのプロパティーを定義しない限り、IBM Cognos Studio/Authoring ツールで表示される値は、ショートカットが参照するオブジェクトで定義された値と同じになります。

ヒント: ショートカットが参照するオブジェクトに移動するには、ショートカットを右クリックし、「ターゲットに移動」をクリックします。

ショートカットは、表示方式の観点から見るとモデル・オブジェクトに比べて柔軟性が低いですが、ターゲット・オブジェクトが更新されるとショートカットも自動的に更新されるため保守の必要は格段に少なくなります。保守の容易さが重要で、しかもクエリー・サブジェクトの表示をカスタマイズする必要がない場合は、ショートカットを使用してください。

IBM Cognos Framework Manager には次の 2 種類のショートカットがあります。

v 標準ショートカット。ターゲット・オブジェクトを単純に参照します。

v 別名ショートカット。元のオブジェクトのコピーであるかのように、完全に独立して動作します。別名ショートカットは、クエリー・サブジェクトとディメンションでのみ使用可能です。

標準ショートカットは通常、スター・スキーマ・グループと共に一致するディメンションとして使用され、まったく同じ名前と外観を持つ複数の参照を複数の場所に作成します。次の例では、Products (製品) と Order Time (注文時刻) に対して作成されたショートカットが参照として動作します。 Product Forecast と SalesTarget の両方から Products を得るようクエリーが作成されている場合、クエリーはオリジナルに基づく Products の定義を使用し、この定義はクエリーに 1 回だけ出現します。


別名ショートカットは通常、ロール・プレイング・ディメンションや共有テーブルで使用されます。この資料にはロール・プレイング・ディメンションの例が既に掲載されているため、共有テーブルの場合について説明します。この例では、SalesStaff (販売員) と Sales Branch (販売支店) を別々の階層として扱うことができます。販売員は支店間で異動する場合があることがわかっているため、Sales Branchと Sales Staff のそれぞれに対する独立した注文のレポート、および両方を一緒にした注文のレポートを作成できる必要があります。そのためには、Sales Staff 階層のレベルとして使用できる Sales Branch の別名を作成する必要があります。

新しい別名ショートカットを設定すると、Sales Branch ごとの注文と Sales Staffごとの注文を、現在の支店情報と共に同時に取得するクエリーを作成できます。

ショートカットと関係

ショートカットを配置する場所を決定するときは、ショートカットの範囲が関係に与える影響を考慮する必要があります。ターゲット・クエリー・サブジェクトとは異なるフォルダー内のショートカットは、ターゲット・クエリー・サブジェクトの関係を使用します。ターゲット・クエリー・サブジェクトと同じフォルダー内のショートカットは、ターゲット・クエリー・サブジェクトの関係を無視し、ショートカットに対して指定された関係のみを使用します。

ターゲット・クエリー・サブジェクトの関係とは異なる関係をショートカットに対して指定できます。ショートカットから他のクエリー・サブジェクトへの関係を作成することにより、モデル内の結合間エラーを回避します。

範囲の関係へのショートカットを作成することはできません。

ショートカットとディメンションまたはクエリー・サブジェクト

ショートカットを使用すると、維持するディメンションまたはクエリー・サブジェクトが少なくなります。インポート・ビューでディメンションまたはクエリー・サブジェクトを保持し、ビジネス・ビューでショートカットを保持できます。ショートカットは、スター・スキーマ・グループの作成時に最もよく使用されます。


ディメンションまたはクエリー・サブジェクトへのショートカットを作成する場合は、ショートカットに含めるクエリー・アイテムをカスタマイズすることはできません。ディメンションまたはクエリー・サブジェクトの全体がショートカットに含められます。

以前のリリースのモデルを開くと、「ショートカット処理」ガバナーは「自動」に設定されます。「自動」を使用すると、以前のリリースと同じ方法でショートカットが機能します。つまり、ターゲットと同じフォルダーにあるショートカットは別名 (つまり独立したインスタンス) として動作し、モデル内の他の場所にあるショートカットはオリジナルへの参照として動作します。「Treat As」プロパティーを利用するには、モデルを検証して、修復時にガバナーを「明示的」に変更することを推奨します。修復処理では、「自動」設定によって従う規則に基づき、「TreatAs」プロパティーから得られる正しい値にすべてのショートカットが変更されます。つまり、ショートカットの「Treat As」プロパティーに 1 つ以上の変更を加えない限り、モデルの動作は変わりません。

新しいモデルを作成すると、「ショートカット処理」ガバナーは常に「明示的」に設定されます。

ガバナーが「明示的」に設定されると、「Treat As」プロパティーからショートカットの動作が取得され、モデル内のどの場所にあるかに関わらず、ショートカットの動作方法を完全に制御することができます。

ショートカットは、「スター・スキーマ・グループを作成」ウィザードで作成できます。例えば、ファクト表とそのディメンション表は、インポート・ビューに格納されます。いくつかのスター・スキーマ・グループ内の一致するディメンションを表す場合、ディメンション表ごとに存在できるディメンションまたはクエリー・サブジェクトは 1 つだけです。ディメンションまたはクエリー・サブジェクトの他のすべてのインスタンスには、ショートカットを使用します。ショートカットを使用することにより、共有ディメンション表によって関連した複数のファクト表が関係するクエリーを構築できます。

ロール・プレイング・ディメンションの場合は、 404 ページの『ロール・プレイング・ディメンション』に記載された 2 つの主なアプローチがあります。役割ごとにクエリー・サブジェクトと標準ディメンションを作成した後、スター・スキーマ・グループでショートカットを参照として使用して、ロール・プレイング・ディメンションを一致するディメンションとして使用できるようにすることができます。あるいは、各スター・スキーマ・グループで役割ごとにショートカットを作成し、各ロール・プレイング・ショートカットとその関連ファクト・ショートカット間の新しい結合を作成することができます。ショートカットのターゲットが同一フォルダーに含まれない限り、すべてのショートカットが別名として動作します。

オブジェクトに対して指定したセキュリティーは、その保護オブジェクトを参照するショートカットに渡されます。保護オブジェクトへのショートカットがある場合は、保護オブジェクトを表示する権限のあるユーザーのみが、発行済みパッケージ内のショートカットを表示できます。

ショートカットがディメンションまたはクエリー・サブジェクトへのショートカットである場合は、「Treat As」プロパティーでショートカットの動作を指定できます。このプロパティーは、以下のいずれかに設定できます。


v 参照

いくつかの場所にあるクエリー・サブジェクトの厳密なレプリカが、同一クエリー内で参照された場合に 1 つのオブジェクトとして動作するようにするときに使用します。

v 別名

クエリー・サブジェクトの厳密なレプリカが、独立結合パス上の独立オブジェクトとして動作するようにするときに使用します。先に独立結合パスをモデルで定義する必要があります。

「ショートカット処理」ガバナーは、すべてのショートカットの動作を制御します。「ショートカット処理」ガバナーは、「Treat As」プロパティーよりも優先されます。例えば、ガバナーが「自動」に設定されている場合、ショートカットの動作は、「Treat As」プロパティーの設定にかかわらず、ショートカットのそのターゲットとの相対的な場所によって決まります。詳細については、 338 ページの『ガバナー』を参照してください。

ショートカットを作成する手順

手順

1. ショートカットを作成するクエリー・サブジェクト、ディメンション、またはフォルダーを右クリックし、次のいずれかの操作を実行します。

v 「作成」、「別名ショートカット」の順にクリックする。

v 「作成」、「ショートカット」の順にクリックする。

v 「スター・スキーマ・グループを作成」をクリックする。このコマンドは、「ツール」メニューからも使用できます。

2. クエリー・サブジェクトまたはディメンションへのショートカットの「プロパティー」ウィンドウで、「Treat As」プロパティーを「別名」または「参照」に設定します。

フォルダーまたはネームスペースの作成フォルダーまたはネームスペースを作成して、モデル内のオブジェクトを編成できます。

ネームスペースについて知っておくべき最も重要な点は、いったんレポートを作成し始めた後、発行されたネームスペースの名前を変更すると、IBM Cognos のコンテンツに影響するということです。これは、ネームスペースの名前を変更すると、メタデータ内に発行されているオブジェクトの ID が変更されるためです。 IBMCognos Framework Manager では、オブジェクト ID の一部としてネームスペースが使用されるため、各ネームスペースの名前はモデル内で一意でなければなりません。ネームスペース内の各オブジェクトの名前も一意である必要があります。スター・スキーマ・グループでは、ショートカットを別個のネームスペースの中に置きます。これにより、ネームスペース内の各オブジェクトに関する一意の ID が自動的に作成されます。これにより、リレーショナル・データベースでは、別のスター・スキーマ・グループ内にある一致するディメンションへのショートカットに同じ名前を使用できます。


更新されたモデルに対してクエリー、レポート、分析のいずれかを次回実行しようとすると、エラーが発生します。発行済みのネームスペースの名前を変更する必要がある場合は、「発行の影響を分析」を使用して、どのレポートに影響があるかを確認してください。

フォルダーは、ネームスペースと比べてかなり単純です。フォルダーは純粋に整理を目的とするもので、オブジェクト ID やコンテンツには影響しません。フォルダーを作成することで、サブジェクトや機能領域ごとにオブジェクトを編成できます。これにより、特に大規模なプロジェクトでは、メタデータを見つけやすくなります。

フォルダーの主な欠点は、すべてのクエリー・サブジェクト、ディメンション、ショートカットに対して一意の名前を付ける必要があることです。このため、共有オブジェクトを格納するには、最適とはいえません。

ヒント: 「ダイアグラム」タブでメタデータを表示するとき、フォルダーやネームスペースを展開または省略することができます。「ダイアグラム」メニューで、「すべて省略」または「すべて展開」をクリックします。

フォルダーにセキュリティーを設定した後にオブジェクトをフォルダーに移動する場合、除外が適切に設定されていることを確認してください。

フォルダーの作成手順

手順

1. 「操作」、「作成」、「フォルダー」の順にクリックします。

2. 「フォルダー名」ボックスに、新しいフォルダーの名前を入力します。


4. オブジェクトを移動するかショートカットを作成するかを選択します。

v 選択したオブジェクトをフォルダーに移動するには、「選択したアイテムを新規フォルダーに移動 (Move the selected items to the new folder)」をクリックします。関係に関与するオブジェクトを移動すると、そのオブジェクトへの関係も移動します。

v 選択したオブジェクトを参照するショートカットを作成するには、「選択したアイテムのショートカットを作成 (Create a shortcut for the selecteditems)」をクリックします。発行されるパッケージに再帰的構造が作成されるのを避けるために、ネームスペース内のすべてのオブジェクトは選択しないでください。

5. フォルダーに追加するオブジェクトを選択します。


ネームスペースの作成手順

手順

1. 「操作」、「作成」、「ネームスペース」の順にクリックします。

2. ネームスペースを右クリックし、「名前を変更」をクリックして、ネームスペースに一意の記述名を付けます。


3. メタデータをインポートするか、モデル・オブジェクトまたはオブジェクトへのショートカットをネームスペースに移動することによって、オブジェクトを追加します。

クエリー・アイテム・フォルダーの作成クエリー・アイテム・フォルダーを作成する場合、モデル・クエリー・サブジェクトの「定義を編集」ダイアログ・ボックスに示されるクエリー・アイテムの順序は変更できません。プロジェクト・ビューアーに示されるアイテムの順序のみ変更できます。

クエリー・アイテム・フォルダーを作成して、多数のクエリー・アイテムを含むクエリー・サブジェクトまたはディメンションを編成できます。クエリー・アイテム・フォルダーに含めることができるのは、クエリー・アイテムおよびクエリー・アイテム・フォルダーだけです。

クエリー・アイテム・フォルダーの作成手順

手順

1. 「プロジェクト・ビューアー」ウィンドウで、クエリー・サブジェクトまたはディメンションをクリックします。

2. 「操作」、「作成」、「クエリー・アイテム・フォルダー」の順にクリックします。

「プロジェクト・ビューアー」の、そのクエリー・サブジェクトまたはディメンションに属するクエリー・アイテムの下に、新しいクエリー・アイテム・フォルダーが表示されます。

3. 目的のクエリー・アイテムをクエリー・アイテム・フォルダーにドラッグします。

親のクエリー・サブジェクトまたはディメンションに存在しないクエリー・アイテムを追加することはできません。

数値データ・フォルダーの作成数値データ・フォルダーを作成して、多数のクエリー・アイテムを含む数値データ・ディメンションを編成できます。数値データ・フォルダーを他の数値データ・フォルダー内にネストすることができます。

数値データ・ショートカットからは数値データ・フォルダーを作成できません。

数値データ・フォルダーを作成する場合、数値データ・ディメンションの「定義を編集」ダイアログ・ボックスに示される数値データの順序は変更できません。数値データの順序は、プロジェクト・ビューアーでのみ変更できます。

数値データ・フォルダーの作成手順

手順

1. 「プロジェクト・ビューアー」ウィンドウで、数値データ・ディメンションをクリックします。

2. 「操作」、「作成」、「数値データ・フォルダー」の順にクリックします。


「プロジェクト・ビューアー」の、その数値データ・ディメンションに属する数値データの下に、新しいフォルダーが表示されます。

3. 目的のクエリー・アイテムを数値データ・フォルダーにドラッグします。

親の数値データ・ディメンションに存在しない数値データを追加することはできません。

永続的なモデルモデルを構築するときには、後にユーザーの要件が変更されて、その変更をモデルに反映させなければならなくなる可能性について検討する必要があります。開発者の目標は、既存のレポート、レポート作成者、およびエンド・ユーザーに影響を与えることなく必要な変更に対応できる柔軟なモデルを構築することです。

クエリー・アイテムの名前変更は、モデル作成者がモデル内に実装する必要のある、最も頻繁に生じる変更の 1 つです。モデルが永続的である場合は、既存のレポートに影響を与えることなく、それらの種類の変更を素早く行うことができます。名前変更されたクエリー・アイテムを参照する計算およびフィルターも有効なままとなります。

永続的なモデルは、単一言語およびマルチリンガルの両方の環境で、ビジネス要件の変更の結果としてクエリー・アイテムを名前変更するときに役立ちます。マルチリンガル環境ではさらに、他の言語の既存のレポート参照を切断するリスクなしでクエリー・アイテムのために言語特定のラベルを指定できるので、永続的なモデルによって翻訳プロセスが簡単になります。

永続的なモデルでの作業を行うとき、以下の条件に注意してください。

v プロジェクトのために設計言語を指定します。

ビジネス要件に含まれない言語のロケール・バージョンを選択します。英語 (ジンバブエ) など、使用頻度の少ないロケールにすることもできます。例えば、英語 (ジンバブエ) を設計言語にしてプロジェクトを作成した場合、アクティブ言語も英語 (ジンバブエ) になります。プロジェクトの設計言語は、モデルを作成した後には変更できません。

v モデルを設計している時は、設計言語とアクティブ言語は同じでなければなりません。

設計には、ネームスペース、クエリー・サブジェクトなどの新しいアイテムの作成や、計算を組み込んだり、モデル構造を変更したりすることが含まれます。例えば、設計アクティビティーの場合、設計言語とアクティブ言語の両方が、英語(ジンバブエ) であるべきです。

v ビジネス・ユーザー用にモデル・アイテムの名前を変更している時には、アクティブ言語は設計言語と異なっているべきです。

クエリー・アイテムの名前を変更する用意ができた時に、アクティブ言語の設定を設計言語以外の言語に変更してください。例えば、クエリー・アイテムを名前変更している時、設計言語は英語 (ジンバブエ) になっています。アクティブ言語はドイツ語です。


v アクティブ言語が設計言語と異なっている間は、モデルの構造を変更しないでください。

構造変更を行う場合は、アクティブ言語を設計言語に戻してから、必要な変更を行ってください。

モデルを永続的にするには、プロジェクト・プロパティー「設計ロケールを参照 IDに使用」を true に設定します。

注: 永続的なモデルのプロセスは、リレーショナル・データ・ソースのディメンション・モデル作成 (DMR) ではサポートされません。

永続的なモデルについて詳しくは、IBM Cognos Customer Service Center(http://www.ibm.com/software/data/support/cognos_crc.html) の「Support」セクションの「Proven Practices」ドキュメントを参照してください。

永続モデルの作成

手順1. 「ようこそ」ページで、「新規プロジェクトの作成」をクリックします。

ヒント: IBM Cognos Framework Manager を使用している場合は、「ファイル」メニューの「新規作成」をクリックします。


3. 「言語を選択」ページで、プロジェクトの設計言語をクリックした後、「OK」をクリックします。

このセクションで前述したとおり、適切な設計言語が選択されていることを確認してください。「OK」をクリックした後、選択した言語を変更することはできません。ただし、他のプロジェクト言語を後から追加することはできます。

4. 「メタデータ・ウィザード」で「次へ」をクリックし、メタデータをインポートします。

5. 「メタデータ・ウィザード」の指示に従います。



v インポート時にオブジェクト名の重複をどのように処理するのかを指定します。インポートして一意の名前を作成するかどうかを選択します。一意の名前を作成することを選択した場合、インポートされたオブジェクトは数字付きで表示されます。例えば、プロジェクトの中には QuerySubject とQuerySubject1 が表示されます。





インポートできなかったオブジェクトのリストおよびインポートされたオブジェクトの数が表示されます。


プロジェクト・ファイル (.cpf) および関連するすべてのファイルを、1 つのフォルダーに保存します。異なる名前または形式でプロジェクトを保存する際には必ず、別個のフォルダーにプロジェクトを保存してください。

7. 「プロジェクト・ビューアー」でプロジェクト名をクリックし、プロジェクト・プロパティーの「設計ロケールを参照 ID に使用」を「true」に設定します。

注: モデルのクエリー・アイテムの名前を変更した後でこのプロパティーを「false」に再び変更すると、このモデルに基づいているレポートが壊れてしまいます。

8. 「プロジェクト」、「言語」、「言語を定義」の順にクリックし、必要な言語をプロジェクトに追加します。その際、追加する言語のうちの 1 つを「アクティブな言語」として選択します。

アクティブな言語を指定する際、設計言語と同じでないことを確認してください。詳細については、 142 ページの『プロジェクトへの言語の追加』を参照してください。

9. プロジェクトを保存します。

10. 必要なパッケージを作成し、IBM Cognos Analytics サーバーに発行します。

発行されたパッケージを使用して、IBM Cognos Analytics - Reporting、IBMCognos Query Studio、または IBM Cognos Event Studio でコンテンツを作成します。例えば、Reporting または Query Studio でレポートを作成します。

タスクの結果

これで、モデルをテストしてそれが想定どおり機能することを確認できるようになります。

永続モデルのテスト

手順1. 永続モデルの作成で発行したパッケージを使って Reporting を起動し、レポー

トを作成して保存します。

2. Framework Manager で、永続モデルの作成で作成したプロジェクトを開き、プロジェクトのアクティブな言語が設計言語と同じでないことを確認します。

3. アクティブな言語で、手順 1 で発行したパッケージに組み込まれているいくつかのクエリー・アイテムの名前を変更します。

4. IBM Cognos Analytics サーバーにパッケージを再発行して元のパッケージをオーバーライドします。

5. 再発行されたパッケージを使用して Reporting を再び起動し、手順 1 で作成したレポートを開きます。


レポートの「挿入できるオブジェクト」ウィンドウに、変更されたクエリー・アイテムの名前が表示されます。ただし、レポート仕様ではクエリー・アイテムの名前が、アクティブな言語 (変更を行ったときの言語) ではなく、設計言語で示されます。

6. レポートを実行します。

名前が変更されたクエリー・アイテムを表す列には、新規名が表示されます。

タスクの結果

クエリー・アイテムの名前を変更しても既存のレポートは壊れないので、このモデルは永続モデルです。

モデルの分析モデル内のメタデータを分析するために、自動化ツール Model Advisor を使用できます。これは、現在のモデル作成ガイドラインに基づいて規則を適用し、調査の必要なモデル領域を識別します。ハイライトされた問題の性質と可能な処置について理解するうえで役立つ、資料の適切なセクションへのリンクが提供されます。Model Advisor は知識の豊富なモデル作成者に置き換わるものではなく、新しいモデル作成者にとっての支援ツール、経験のあるモデル作成者にとっての診断ツールとなります。

選択したモデル、またはモデルのサブセットに対して実行する 1 つ以上のテストを選択することができます。モデルを分析する前にモデルを検証してエラーを修正してください。詳細については、 277 ページの『モデルまたはパッケージの検証』を参照してください。

新しいモデルを分析する場合には、以下のワークフローを使用します。

v 新しくインポートされるオブジェクトを分析します (特に関係および行列式)。

v 識別される問題を使って、クエリー生成における潜在的な問題を解決します。

v 追加のビューを作成するときには、Model Advisor を使って各ビューの潜在的な問題を分析します。

v モデルを発行する前に、発行されるオブジェクトに対して Model Advisor を使用します。

以前からある確立されたモデル、または未完成のモデルを分析する場合には、Model Advisor を使ってモデル作成の手法を検証します。新しいモデルの場合と同様のワークフローを使用しますが、データベース・ビューから始めて作業を進めてください。

カーディナリティーによって識別されるファクト

このテストでは、該当する関係の末端におけるカーディナリティーが常に「多」(n)であるクエリー・サブジェクトを検索します。このカーディナリティーを持つクエリー・サブジェクトはクエリー生成時にファクトとして扱われるため、それらを正しく識別することが重要です。


ファクトまたはディメンションとして動作できるクエリー・サブジェクト

このテストでは、「多」(n) と「1 またはゼロ」(1、0) のカーディナリティーの組み合わせを持つクエリー・サブジェクトを検索します。混合カーディナリティーの場合、クエリーで使われる他のクエリー・サブジェクトに応じて、クエリー・サブジェクトの動作が変更されることがあります。このため、場合によっては予測不能なクエリーが発生します。クエリー・サブジェクトがファクトとして評価されると、クエリー・パスにそれが含まれます。ディメンションとして評価されるなら、クエリーで直接参照されない場合にそれがスキップされる可能性があります。予測可能な動作を得るには、これらのシナリオを解決する必要があります。

混合カーディナリティーは、スノーフレーク・ディメンションまたはマスター詳細関係に含まれるクエリー・サブジェクトを示す可能性があります。スノーフレーク・ディメンションの中間テーブルの場合、解決すべき問題はありません。複数のクエリー・パスを使用できる状況では、問題が発生する可能性があります。このようなケースは、複数の関係を持つクエリー・サブジェクトのテストでハイライトされます。

複数の関係を持つクエリー・サブジェクト

このテストでは、2 つのオブジェクト間で多数の関係があるクエリー・サブジェクト、またはスター・スキーマ結合パターンを表さないループ結合があるクエリー・サブジェクトを検索します。

2 つのクエリー・サブジェクト間の複数の関係は、多くの場合、ロール・プレイング・ディメンションに関連しています。ロール・プレイング・ディメンションでは、各ロール (役割) における別個の結合と別個の独立した動作を可能にする別名を作成します。 (スター・スキーマの場合を除いて) ループ結合を示す複数の結合パスのために、クエリーの不適切な分割という問題が発生する可能性があります。これにより、ユーザーにとって、クエリー生成の予測可能性が影響を受けます。

IBM Cognos ソフトウェアに複数の関係があり、選択するための区別基準がない場合には、アルファベット順で最初にくる関係が使われます。別の関係を使用するクエリーを作成する必要がある場合には、常に問題が生じます。さらに、関係で定義されたロールに固有の基準に対するフィルターを使用する必要がある場合、これらのフィルターが互いに排他的であれば、レポートにはデータがまったく表示されません。ロール・プレイング・ディメンションとその例については、 404 ページの『ロール・プレイング・ディメンション』を参照してください。

注: カーディナリティーによってファクトとディメンションが明確に識別される場合、共通のディメンション表セットに複数のファクト表が結合されているときにスター・スキーマ・データが原因で発生するループ結合を、IBM Cognos ソフトウェアは自動的に解決できます。スター・スキーマ結合パターンは問題のある結合と見なされないため、Model Advisor はそれらを無視します。

自身に結合するクエリー・サブジェクト

このテストでは、再帰的関係および帰納的関係を探します。これらの関係は、複数レベルの細分性が存在することを示唆します。 IBM Cognos Framework Manager


は再帰的関係をインポートしますが、クエリー実行時にはそれらを使用しません。再帰的関係 (自己結合ともいう) は、表示のためにのみ、モデルに示されます。

ほとんどの場合、自身に結合するクエリー・サブジェクトは親子関係を示します。親子関係を持つデータ・セットの深さは、限定的である場合も、無制限である場合もあります。どちらのケースを扱っているか識別する唯一の方法は、データおよび表現されているビジネス概念を理解することです。

親子関係が検出されたときに問題が生じるかどうかは、アプリケーションでのデータの使用方法によって決まります。場合によっては単一レベルの関係だけが必要とされるケースもありますが、このシナリオはかなり容易にモデル化できます。さらに、各レベルにデータが完全に入ること、およびレベルの数が限定的であることが分かっている場合にも、モデル化のみのソリューションを選択できます。しかし、データ量がかなり多い場合、各レベルにデータが完全に入らない場合 (不規則または不均衡な階層)、またはデータのレベル数が時間と共に変化する可能性がある場合には、Framework Manager でモデル化する前に、一定の列数を持つフラット構造にデータを変換してください。

関係と競合する行列式

このテストでは、クエリー・サブジェクトに定義された関係と競合する行列式を探します。行列式を使用することで、レポート内の集計が正しくなり、クエリーが正しく生成されるようになります。

行列式は、クエリー・サブジェクトでのデータのサブセットやグループを表現することにより細分性を表します。行列式を使用すると、この反復データが正しく集計されるようになります。行列式は、データ・ソースにおけるキー/インデックスの概念と最も密接な関連があり、データ・ソース内の固有キー/インデックス情報に基づいてインポートされます。インポートされた行列式を必ず確認し、必要に応じて変更するか、追加の行列式を作成してください。行列式を変更すると、データ・ソースのインデックス/キー情報をオーバーライドして、レポートや分析のニーズにより適合する情報に置き換えることができます。行列式を追加すると、アプリケーションに関連する反復データのグループを表すことができます。

Model Advisor は行列式を持つクエリー・サブジェクトを検査して、以下のいずれかの基準を満たすものにフラグを立てます。

v 固有の行列式のすべてのクエリー・アイテムが関係によって参照され、関係のカーディナリティーが 1:1 および 0:1 のどちらでもない

v 固有の行列式の一部のクエリー・アイテムが関係によって参照され、関係のカーディナリティーが 1:n および 0:n のどちらでもない

また、関係のキーが「Group By」行列式のキーとマッチしないことが検出された場合にも、Model Advisor はフラグを立てます。

最小化した SQL 設定をオーバーライドする因子

このテストでは、SQL 生成タイプの「最小化」設定をオーバーライドするさまざまな要因を検索します。例えば、変更されたデータ・ソース・クエリー・サブジェクト、モデル・クエリー・サブジェクト間の関係、モデル・クエリー・サブジェクトの行列式などです。


最小化された SQL を使用すると、選択されたクエリー・アイテムの値を取得するために必要な最低限のテーブルと結合のセットだけが、生成される SQL に含まれます。

最小化された SQL の例として、互いに結合される 4 つのクエリー・サブジェクトProduct Line (製品ライン)、Product Type (製品タイプ)、Product (製品)、およびProduct Multilingual (製品マルチリンガル) を考えます。

モデル・クエリー・サブジェクトでこれらを組み合わせることができます。

例えば Products (モデル) クエリー・サブジェクトの全体をテストすると、クエリーの from 節で 4 つのテーブルが参照されていることがわかります。

selectPRODUCT_LINE.PRODUCT_LINE_CODE as Product_Line_Code,PRODUCT_LINE.PRODUCT_LINE_EN as Product_Line,PRODUCT_TYPE.PRODUCT_TYPE_CODE as Product_Type_Code,PRODUCT_TYPE.PRODUCT_TYPE_EN as Product_Type,PRODUCT.PRODUCT_NUMBER as Product_Number,PRODUCT_MULTILINGUAL.PRODUCT_NAME as Product_NamePRODUCT_MULTILINGUAL.DESCRIPTION as Product_Description,PRODUCT.INTRODUCTION_DATE as Introduction_Date,PRODUCT.PRODUCT_IMAGE as Product_Image,PRODUCT.PRODUCTION_COST as Production_Cost,


PRODUCT.MARGIN as Marginfromgosl_82..gosl.PRODUCT_LINE PRODUCT_LINE,gosl_82..gosl.PRODUCT_TYPE PRODUCT_TYPE,gosl_82..gosl.PRODUCT PRODUCT,gosl_82..gosl.PRODUCT_MULTILINGUAL PRODUCT_MULTILINGUALwhere(PRODUCT_MULTILINGUAL."LANGUAGE" - N'EN')and(PRODUCT_LINE.PRODUCT_LINE_CODE = PRODUCT_TYPE.PRODUCT_LINE_CODE)and(PRODUCT_TYPE.PRODUCT_TYPE_CODE = PRODUCT.PRODUCT_TYPE_CODE)and(PRODUCT.PRODUCT_NUMBER = PRODUCT_MULTILINGUAL.PRODUCT_NUMBER

Product Name (製品名) だけをテストした場合、結果としてできたクエリーでは、必要とされたテーブル Product Multilingual だけが使用されることがわかります。これが、最小化された SQL の効果です。

selectPRODUCT_MULTILINGUAL.PRODUCT_NAME as Product_Namefromgosl_82..gosl.PRODUCT_MULTILINGUAL PRODUCT_MULTILINGUALwhere(PRODUCT_MULTILINGUAL."LANGUAGE" - N'EN")

計算集計タイプを使用する埋め込み計算

このテストでは、埋め込み計算のために「標準集計」プロパティーが「算出」に設定されている箇所を検出します。

計算される集計タイプは、以下の場合にのみサポートされます。

v 独立した計算

v 数値データ・ディメンションの中に埋め込まれた、同じ数値データ・ディメンションの数値データに基づく計算

算出集計の詳細については、 152 ページの『計算集計を解釈するための規則』を参照してください。

メタデータのキャッシュ競合を起こす可能性があるクエリー・サブジェクト

このテストでは、キャッシュされたメタデータをオーバーライドする要因を検索します。例えば、SQL が変更されたデータ・ソース・クエリー・サブジェクト、または計算やフィルターを含むクエリー・サブジェクトです。

IBM Cognos Framework Manager は、データ・ソースからインポートされるメタデータを保管します。しかし、ガバナー設定や、モデルで行われる特定の操作によっては、クエリーを準備するときにこのメタデータが使用されない可能性があります。「実行時の拡張モデル移植性を許可」ガバナーを選択した場合、クエリーの準備の前に、Framework Manager はメタデータについての情報を得るために常にデータ・ソースを照会します。「実行時の拡張モデル移植性を許可」ガバナーを選択していない場合、Framework Manager はデータ・ソースを照会する代わりに、モデルに保存済みのメタデータにアクセスします。ただし例外もあり、主に次のようなケースです。


v データ・ソース・クエリー・サブジェクトでの SQL の変更。これには、マクロの使用も含まれます。

v データ・ソース・クエリー・サブジェクトへの計算やフィルターの追加。

注: IBM Cognos ソフトウェアによって生成されるメタデータ・クエリーは、ほとんどのベンダーのリレーショナル・データベース管理システムでサポートされており、ほとんどのレポート作成アプリケーションでは目立った影響がありません。

Model Advisor は、リレーショナルに基づくメタデータ・モデルでのみ使用されるよう意図されています。モデル全体に対して Model Advisor を実行しないでください。そうする代わりに、コンテキストに照らしてフィードバックを理解するために、一度に 1 つずつ、特定のビューに適用してください。例えばインポート・ビュー内の問題がまだ処理されていない場合、中間ビューでのモデル作成によって問題を解決できる可能性があります。

大きなモデルやネームスペースの場合、Model Advisor によって結果が直ちに戻されないことがあります。

Model Advisor はデータ・センシティブではないため、データをよく理解したうえで、ニーズに合わせて適切にメタデータをモデル化する必要があります。 ModelAdvisor によってフラグが立てられたすべての項目が問題を示しているとは限りません。 Model Advisor で提起されるそれぞれの問題のコンテキストが重要です。

モデルを分析する手順

手順1. 分析する 1 つ以上のオブジェクトをクリックします。

v クエリー・サブジェクト、ディメンション、階層、計算、クエリー・アイテム、またはショートカットを選択し、特定のレポートに表示されるオブジェクトを分析して、作成する前にレポートをテストします。

v フォルダーまたはネームスペースを選択し、そのオブジェクトをすべて分析します。オブジェクトが別のフォルダーまたはネームスペースのオブジェクトを参照している場合、参照されるオブジェクトも分析されます。

v パッケージを発行する前に、パッケージを選択してそれがモデル化のガイドラインに従っていることを確認します。

2. 「ツール」、「Model Advisor を実行」の順にクリックします。

ヒント: 1 つ以上のオブジェクトを右クリックして「Model Advisor を実行」をクリックすることもできます。

3. 「オプション」タブから、分析で使用する基準を選択します。

4. 「分析」をクリックします。

5. 「Model Advisor」タブで、識別される問題を確認します。

それぞれの問題には説明が付けられています。また、それぞれの問題に関する詳細へのリンクや、その問題によって影響を受けるオブジェクトのリストもあります。


6. オブジェクトに問題があるかどうかを調べるには、レポートの「操作」列の「コ

ンテキスト・エクスプローラー」アイコンをクリックします。

「コンテキスト・エクスプローラー」には、選択されているオブジェクトが接続されているオブジェクトが表示されます。関連するオブジェクトを選択して、接続されているオブジェクトを表示することができます。


第 6 章 SAP BW メタデータ

注: リレーショナル・メタデータに関する情報は、別のトピックに記載されています。

メタデータをインポートした後で、それがユーザーのレポート作成要件を満たすようにセットアップされたことを確認し、必要とされる追加情報があれば提供する必要があります。 IBM Cognos Framework Manager での拡張は、元のデータ・ソースに影響を与えません。

ヒント: モデルがレポート作成要件を満たしていることを検証するために、レポートに表示されるオブジェクトを選択してテストできます。テスト結果では、ユーザーに表示されるレポート、および SQL と IBM Cognos Software からのメッセージ(存在する場合) を確認できます。または、いつでもパッケージを発行して、そのパッケージを使用してレポートを作成することもできます。

いつでもプロジェクトを検査して、それに含まれるオブジェクト間の参照が有効であることを確認できます。 277 ページの『モデルまたはパッケージの検証』を参照してください。

IBM Cognos Framework Manager で SAP BW メタデータを扱うとき、以下のことを行えます。

v メタデータのインポート。

v ディメンションに関する作業。

v クエリー・アイテムのプロパティーを調べて、データが使用されフォーマット設定される方法を制御すること。

v 必要な場合、取得したデータを洗練してユーザーが適切な情報を使用できるようにするために、計算やフィルターなどのビジネス・ルールを追加します。

v ユーザーに馴染みのあるビジネス概念を反映する個別のビューをユーザー・グループごとに作成することにより、モデルを整理します。

v 必要な場合、Framework Manager および IBM Cognos Studio/Authoring ツールの設定を調整して、パフォーマンスを最適化します。

モデルに対する作業を行った後に、パッケージを作成してユーザーのために発行できます。詳細については、 293 ページの『パッケージの発行』を参照してください。

注: IBM Cognos Administration で、SAP BW キューブのパッケージおよびクエリーを直接作成することもできます。詳しくは、「管理およびセキュリティー・ガイド」のパッケージに関するセクションを参照してください。

SAP BW データ・ソースからのインポートSAP BW データ・ソースからインポートするとき、すべてのメタデータをインポートすることも、選択したオブジェクトだけをインポートすることもできます。


SAP BW メタデータ・オブジェクトを IBM Cognos Framework Manager オブジェクトにマップする方法について詳しくは、 222 ページの『SAP BW オブジェクトを Framework Manager にマップする』を参照してください。

複数の異なるビュー (またはレイヤー) をモデル内に持つことができます。それらは、データ・ソースからインポートしたメタデータを含むインポート・ビューと、メタデータを拡張するビジネス・ビューです。メタデータをインポートした後に、そのメタデータをビジネス・ビューにコピーできます。その結果 2 つのビューが使用可能となります。それらのビューは、BW InfoProvider を使用して同期する必要があります。

ヒント: 計算されたキー数値を SAP BW Query から公開する場合は、SAP BWQuery をインポートする必要があります。

SAP BW メタデータおよびデータへのアクセス権限SAP BW データ・ソースを使用するとき、InfoCube または InfoQuery メタデータへのユーザー・アクセス権限は、これらのオブジェクト内のデータへのアクセスを一緒に許可するわけではありません。 Framework Manager で SAP BW からメタデータを取得できるようにするには、SAP BW システム内でアクセス権限をセットアップする必要があります。適切なアクセス権限がユーザーに確実に与えられるようにするには、ユーザーの役割に割り当てられる権限を確認します。

SAP BW システム内の情報キューブまたはデータ・ソース (InfoCube) をFramework Manager でインポートできるようにするには、以下の承認オブジェクトを構成する必要があります。

v S_RFC

「アクティビティー」フィールドに「16」という値を設定します。

「保護する RFC の名前 (Name of RFC to be protected)」フィールドに「SYST, RSOB, SUGU, RFC1, RS_UNIFICATION, RSAB, SDTX, SU_USER,RSNDI_SHIE」という値を設定します。

保護対象のフィールドにする「RFC のタイプ (Type of RFC)」オブジェクトに「FUGR」という値を設定します。

v S_TABU_DIS


「承認グループ」フィールドに「&NC&」という値を設定します。

注: &NC& は、承認グループがないテーブルを表します。セキュリティー上の理由から、新しい承認グループを作成して、テーブル RSHIEDIR をそれに割り当ててください。この新しい承認グループにより、ユーザーがアクセスできるテーブルを、モデル作成ツールで必要な上記のもののみに制限できます。新しい承認グループは、SAP システムでカスタマイズすることによって作成します。

v S_USER_GRP

「アクティビティー」フィールドに「03, 05」という値を設定します。


「ユーザー・マスター・メイン内のユーザー・グループ (User group in usermaster main)」フィールドをデフォルト値に設定します。

v S_RS_COMP

「アクティビティー」フィールドをデフォルト値に設定します。

「情報領域 (Info Area)」フィールドに「InfoArea Technical Name」という値を設定します。

「Info Cube」フィールドに「InfoCube Technical Name」という値を設定します。

「レポート作成コンポーネントの名前 (ID) (Name (ID) of reportingcomponents)」フィールドをデフォルト値に設定します。

「レポート作成コンポーネントのタイプ (Type of reporting components)」フィールドをデフォルト値に設定します。

v S_RS_COMP1

「アクティビティー」フィールドをデフォルト値に設定します。

「レポート作成コンポーネントの名前 (ID) (Name (ID) of reportingcomponents)」フィールドをデフォルト値に設定します。

「レポート作成コンポーネントのタイプ (Type of reporting components)」フィールドをデフォルト値に設定します。

「所有者 (責任者) (Owner (Person Responsible))」フィールドをデフォルト値に設定します。

v S_RS_HIER


「階層名」フィールドに「Hierarchy Name」という値を設定します。

「InfoObject」フィールドに「InfoObject Technical Name」という値を設定します。

「バージョン」フィールドに「Hierarchy Version」という値を設定します。

v S_RS_ICUBE


「InfoCube sub-object」フィールドに「DATA」と「DEFINITION」という値を設定します。

「情報領域 (Info Area)」フィールドに「InfoArea Technical Name」という値を設定します。

「InfoCube」フィールドに「InfoCube Technical Name」という値を設定します。

ヒント

第 6 章 SAP BW メタデータ 217

v &NC& は、承認グループがないテーブルを表します。セキュリティー上の理由から、新しい承認グループを作成して、テーブル RSHIEDIR をそれに割り当ててください。この新しい承認グループにより、ユーザーがアクセスできるテーブルを、Framework Manager で必要な上記のもののみに制限できます。新しい承認グループは、SAP システムでカスタマイズすることによって作成します。

v アスタリスク (*) を単独で使用すると、すべての値を表すことができます。文字列の任意の場所でこれを使用すると、部分的な値を表すことができます。

SAP BW 構造既存の SAP BW クエリーの多くに、IBM Cognos クエリーで使用してユーザーに表示される情報の量と順序を制御できる構造が含まれています。例えば、デュアル構造を使用して、各軸に構造が 1 つあるクロス集計レポートを作成できます。

以下の構造があります。

v キー数値構造

SAP BW Query Designer は、クエリーにキー数値が追加されると、キー数値構造を自動的に作成します。クエリー・メタデータを IBM Cognos FrameworkManager にインポートするには、キー数値が少なくとも 1 つなければなりません。レポートでキー数値を使用しない場合でも同じです。したがって、常にキー数値構造があることになります。

v 特性構造

特性構造は、1 つ以上のディメンションからの特性値 (メンバー) の集合です。クエリーに構造を追加し、その構造に必要メンバーを追加することによって、SAP の特性構造を作成します。 IBM Cognos ソフトウェアでは、構造は複数ルート・レベルが 1 つだけの追加ディメンションとして表示されます。

SAP BW クエリーを Framework Manager にインポートすると、キー数値と呼ばれる数値データ・ディメンションにキー数値構造が表示され、特性構造が追加ディメンションとして表示されます。

同じ SAP BW クエリーを Framework Manager に再インポートする場合は、「SAP BW デュアル構造のサポート」チェック・ボックスに同じ設定を使用する必要があります。Framework Manager は、同じクエリーに対して異なる設定を選択することを許可しません。そうすると、モデルにさまざまなオブジェクトが生成されることになり、エラーにつながるからです。クエリーごとに異なる設定を使用できます。

SAP BW 階層メタデータのインポート時、Framework Manager は各 SAP BW 特性にディメンションを生成します。

ある特定の特性に関連付けられた階層を 1 つだけレポートで使用できます。したがって、単一特性の階層を表す複数のディメンションを 1 つのフォルダーまたはモデル・クエリー・サブジェクトにグループ化し、ユーザーが容易にレポート作成を行えるようにする必要があります。


SAP BW データ・ソースに複数の階層がある場合は、最初にインポートされる階層がデフォルト階層になります。

Framework Manager は、以下のタイプの階層をサポートします。

v 特性

すべての特性値のリストです。

v テキスト・ノード

非リーフ・ノードはテキストのみを含み、他のデータ・ソース・オブジェクトは参照しません。

v 特性値

表示階層の各レベルのノードは、別の特性からの値です。

v 帰納的

表示階層全体のノードは、特性自体からのものです。

特性が時間ディメンションにないが日付であり、SAP BW で日付として扱われる場合、特性は日付データ型でインポートされます。

Framework Manager は、ノードのタイプが 2 つ以上含まれる階層をサポートしません。このような階層はインポートされますが、Framework Manager モデルでは隠蔽されます。

SAP BW 用の階層メタデータは自動的に生成されるので、Framework Manager で変更することはできません。

バージョン化階層SAP BW データ・ソースから以下のタイプのバージョン化階層をインポートできます。

v バージョン依存階層

階層は複数のバージョンを持つことができます。「地域別の販売」や「マネージャー別の販売」など、階層のバージョンごとに異なる構造を持つことができます。メタデータ・インポートの際、Framework Manager は各バージョンを別々の階層と見なし、それぞれのディメンションを作成します。

v 全体階層時間依存

各バージョンに、同じ階層の他のバージョンと重なり合わない期間が関連付けられています。バージョンごとに異なる構造にすることができます。メタデータ・インポートの際、Framework Manager は各バージョンを階層と見なし、適用可能期間をディメンション名の一部として含めます。

v 時間依存階層構造

単一バージョンの階層がありますが、階層内のノードに適用可能期間を割り当てることができます。時とともに新しいレベルが導入されたり削除したりして、階層の構造が変わることがあります。例えば、さまざまな販売地区を表すレベルが


時とともに追加されることがあります。メタデータ・インポートの際、Framework Manager は時間依存階層構造を非バージョン化階層と見なし、現在日付時点の階層の構造を認識します。

使用される階層と、バージョン管理に使用する日付 (時間依存階層の場合) は、ディメンションのタイプによって決まります。

Framework Manager は、時間依存階層内に含まれる日付に基づいて、時間依存階層のクエリー・キー日付を設定します。その後、特定のバージョンの階層を選択できます。バージョンが時間に合っている階層の場合、デフォルトは現在の日時です。特性に適用する階層は、クエリー・キー日付のタイプ (固定、現在、または変数) によって異なります。クエリー・キー日付は特定の日付に対して設定されます。

固定日付の場合は、基礎となる SAP BW クエリーの固定日付に対応するバージョンのみ組み込んでください。例えば、SAP BW クエリーに 2005 などの固定日付がある場合は、2005 のみがインポートされます。

現在日付の場合は、将来の妥当な時点までは、現在に適した時間幅を包含するバージョンのみ組み込んでください。

変数の場合は、変数に使用される日付を Framework Manager で設定し、その日付に適用できる階層のバージョンのみ組み込んでください。

Framework Manager を使用して SAP BW データをモデル化した場合、SAP BWの表示階層に適用されるバージョンおよび日付は、モデルにインポートされません。したがって、Framework Manager で階層のすべてのバージョンにアクセスできます。

時間依存階層と変数を SAP BW で定義して、階層の発効日を設定できます。この場合は、Framework Manager で固定日付を変数に割り当て、その日付に対応するディメンションのみモデルに組み込んでください。

バージョン化階層が時間依存でなく、固定バージョンを持っている場合は、Framework Manager で、選択したバージョンに関連付けられた階層のバージョンのみ組み込んでください。そうしないと、アクセス不能な階層がユーザーに示されます。

保護された InfoCube にアクセスする手順

手順1. InfoCube にアクセスする Business Explorer Query Designer でクエリーを作

成します。

2. 承認が存在する基本 InfoCube の各 InfoObject に対して承認変数を作成します。

3. 各変数の「入力準備 (Ready for Input)」オプションが使用不可になっていることを確認します。

デフォルトでは、このオプションは使用可能になっています。

4. OLE DB for OLAP 経由でクエリーにアクセスできるようにします。


5. クエリーを保存します。

6. Framework Manager で、InfoCube の代わりにクエリーを参照します。

SAP BW データ・ソースからインポートする手順

手順1. データ・ソースへの接続が存在することを確認します。

データ・ソース接続の作成の詳細については、「IBM Cognos管理およびセキュリティー・ガイド」を参照してください。

2. インポート先のネームスペース、フォルダー、またはセグメントをクリックし、「操作」メニューから「メタデータ・ウィザードを実行」をクリックします。

3. 「データ・ソース」を選択し、「次へ」をクリックします。

4. SAP BW データ・ソース接続を選択し、「次へ」をクリックします。

5. インポートするオブジェクトを選択します。

再インポートの場合は、既存のオブジェクトが更新されます。

新規オブジェクトをインポートする際に同じ名前のオブジェクトが存在している場合、新規オブジェクトがインポートされ、元の名前に数字が付加されます。例えば、プロジェクトの中には QuerySubject と QuerySubject1 が表示されます。

インポートされた後、クエリー・アイテムを削除するには、クエリー・サブジェクト全体を削除する必要があります。

6. 特性構造およびキー数値構造をインポートする場合、「SAP BW デュアル構造のサポート」チェック・ボックスをオンにします。

「オブジェクトを選択」ページの内容が更新され、データ・ソースのデュアル構造が反映されます。

注: (基本データ・ソースが変更されたなどの理由で) 同じ SAP BW クエリーを再インポートする場合、このチェック・ボックスに関して同じ設定を使用する必要があります。同じクエリーに対して異なる設定を使用することはできません。異なるオブジェクトがモデルに生成され、エラーになるからです。

7. インポートする言語を選択します。

その言語はデータ・ソースに存在していなければなりません。

後でプロジェクトに言語を追加することは可能ですが、データ・ソースから言語固有のメタデータを返し、インポートすることはできません。インポートが完了した後、手動で言語固有のメタデータを追加する必要があります。

8. Framework Manager でディメンションの短縮名、長い名前、または技術名を表示するかどうかを示します。

v 短縮名を選択してフィールドが空の場合、長い名前が表示されます。

v 長い名前を選択してフィールドが空の場合、短縮名が表示されます。


v 短縮名または長い名前のいずれかを選択してどちらのフィールドも空の場合、技術名が表示されます。

9. モデルのオブジェクトを Business Explorer Query Designer と同じ方法で編成するには、「オブジェクトが SAP BW の編成になるようモデルを拡張する」オプションを選択します。

これで、各特性のフォルダーが完成します。


インポートできなかったオブジェクトのリストが、インポートされたオブジェクトの数とともに表示されます。


タスクの結果

インポートの後、使用方法プロパティー値および集計プロパティー値を確認します。集約すべきでない数値列 (交換レートなど) がファクト表に含まれる場合があります。

別の SAP BW システムでクエリーを再作成する際、SAP BW 移行メカニズムを使用してクエリーをトランスポートします。こうすることで各数値データの技術名が同じままとなり、クエリーを参照するプロジェクトがあれば、プロジェクトに対して変更を加えることなくそのプロジェクトをいずれかのシステムにダイレクトすることができます。

SAP BW オブジェクトを Framework Manager にマップするSAP BW オブジェクトは、以下の IBM Cognos Framework Manager オブジェクトにマップされます。

SAP BW オブジェクト Framework Manager オブジェクト

クエリー、InfoCube、RemoteCube、MultiCube

ネームスペース

特性ディメンションが含まれているフォルダー。

メタデータをインポートする際に「オブジェクトが SAP BW の編成になるようモデルを拡張する」オプションを選択して、特性ごとにフォルダーを用意する必要があります。

注: デフォルトで、Framework Manager はSAP BW の通貨特性と単位特性をインポートします。これらの特性は、必要がない場合には削除できます。


SAP BW オブジェクト Framework Manager オブジェクト

ディメンションディメンション。ディメンションには、それぞれの表示階層を表す階層が含まれることがあります。デフォルトの階層には次のものを表す 2 つのレベルが含まれています。

- すべての特性値の集計 (All 値とも呼ばれる)

- すべての特性値

キー数値キー数値と呼ばれる数値データ・ディメンションの一部であるクエリー・アイテム。

表示階層レベルレベル。

注: レベル名を意味のあるものとするためには、Administrator Workbench で定義する必要があります。

属性「使用方法」プロパティー値が「属性」に設定されたレベルに関連付けられているクエリー・アイテム。

SAP BW 変数データ・ソース・プロパティー。

Framework Manager がサポートする SAPBW 変数について詳しくは、 254 ページの『SAP BW 変数』を参照してください。

SAP BW からメタデータを取得するためのアクセス権限を設定する方法について詳しくは、 216 ページの『SAP BW メタデータおよびデータへのアクセス権限』を参照してください。

ディメンション (SAP BW)ディメンションとは、ビジネスの主要な側面 (例えば、製品、日付、市場など) に関するデータを広義でグループ化したものです。

IBM Cognos Framework Manager で扱うことのできるディメンションのタイプには、標準ディメンションと数値データ・ディメンションとがあります。SAP BW では、数値データ・ディメンションはキー数値と呼ばれます。



時刻標準ディメンション販売された年、四半期、月、週、日に編成された販売日



地域標準ディメンション販売地域、国、都市にグループ化された販売場所

製品標準ディメンション製品タイプ、ブランド、モデル、色、パッケージに編成された製品詳細

顧客標準ディメンション顧客情報

売上キー数値ディメンション売上数量、収益、利益などの購入の詳細

標準ディメンションの変更 (SAP BW)



ディメンションが SAP BW メタデータに基づいている場合、基礎となるクエリーは編集できません。

標準ディメンションを変更する手順

手順

1. 変更する標準ディメンションをクリックします。



v レベルを選択し、「追加」をクリックした後、式を定義することにより、計算を埋め込む ( 261 ページの『計算の作成 (SAP BW)』)。

v フィルターを埋め込む ( 263 ページの『フィルターの作成 (SAP BW)』)。

v ディメンションをテストする ( 234 ページの『ディメンションまたは他のオブジェクトのテスト (SAP BW)』)。



標準ディメンションの階層 (SAP BW)

階層は、レベルの順序付きリスト、またはアイテムの集合です。階層内の各クエリー・アイテムには一意の名前が必要です。

IBM Cognos Framework Manager で、標準ディメンションに複数の階層を指定できます。標準ディメンションの複数の階層は、同じクエリーのビューとして動作します。最初の階層は、プライマリーまたはデフォルトの階層です。

クエリーで一度に使用できるのは 1 つの階層のみです。例えば、クロス集計レポートの行に 1 つの階層を使用し、クロス集計レポートの列に同じディメンションの別の階層を使用することはできません。同じレポート内で両方の階層が必要な場合は、各階層に 1 つずつ、2 つのディメンションを作成する必要があります。詳細については、 412 ページの『複数の階層を持つディメンションのモデル作成』を参照してください。

例えば、販売員は責任者別または地域別に表示することができ、それを 2 つの階層を持つ 1 つのディメンションとしてモデル化できます。

IBM Cognos Software は、階層タイプに関して障害の生じないデフォルトの設定値を使用します。

v SAP BW 特性を表すディメンションでは、「バランス」プロパティーが true に設定され、「不規則」プロパティーが false に設定されます。

v 表示階層を表すディメンションでは、「バランス」プロパティーが false に設定され、「不規則」プロパティーが true に設定されます。

IBM Cognos Software は実際の階層構造を判別しないので、これらの設定は適切な値を反映していないことがあります。 IBM Cognos Framework Manager およびIBM Cognos の Studio/Authoring ツールでディメンション設定を調整することにより、SAP BW モデルおよびクエリーのパフォーマンスを改善できます。ディメンションごとに、「バランス」および「不規則」プロパティーを調べて、それらの値が適切に設定されていることを確認します。

ディメンションでの階層に加えて、SAP BW メタデータにも階層があります。詳細については、 218 ページの『SAP BW 階層』を参照してください。


均衡階層:

均衡階層のそれぞれのパスは、同じ深さにまで降りていきます。

例えば以下の図で、最上位レベルは製品ライン (レベル 1) です。レベル 2 は製品タイプ、レベル 3 は製品です。

SAP BW において、階層のすべてのリーフ・ノードは特性の値ですが、それぞれのパスが階層の最下位レベルにまで降りていく必要はありません。

ディメンションの「バランス」プロパティーを変更することにより、ディメンションが均衡階層 (バランスの取れている階層) を表すかどうかを定義できます。ディメンションがどんな種類のオブジェクトを表しているか、および階層が均衡しているかどうかに応じて、異なる値を設定します。

ディメンションによる表現「バランス」プロパティーの値

特性 true

均衡している表示階層 true

不均衡な (バランスの取れていない) 表示階層

false

不明な構造の表示階層 false

表示階層のない特性を表すディメンションの場合、このプロパティーは読み取り専用となり、値 true が割り当てられます。

均衡型の表示階層の場合は、それに関連するディメンションの「バランス」プロパティーを true に設定してください。デフォルトでは、すべての表示階層の値がfalse です。すべてのリーフ特性値が階層の最低レベルに出現する場合、その階層は均衡しています。適切な場合に「バランス」プロパティーを true に設定すると、IBM Cognos Analytics サーバーはより効率的な MDX を生成できます。


すべてのパスの深さが同じである場合は、「バランス」プロパティーを true に設定します。そうでない場合は false に設定します。

不均衡な (バランスの取れていない) 階層の「バランス」プロパティーに値 true を割り当てた場合、このディメンションを扱うクエリーは間違ったデータを返す可能性があります。

均衡している階層の「バランス」プロパティーに値 false を割り当てた場合、パフォーマンスが遅くなる可能性があります。

バランスのとれていない階層:

バランスのとれていない階層の分岐は、分岐の下降レベルが異なります。

例えば、次のダイアグラムでは、組織の最上位は CEO (レベル 1) です。レベル 2は、副会長と、CEO のエグゼクティブ・アシスタントです。副会長とは異なり、エグゼクティブ・アシスタントには従属レベルがありません。


SAP BW では、これは表示階層に「未割り当て」(つまり「#」) ノードがある場合のみ起こります。ただし、このようなノードが存在するからといって、バランスのとれていない階層であるということにはなりません。正確に知るためには、階層のレイアウトを調べる必要があります。


不規則な階層:

階層内の少なくとも 1 つのパスが少なくとも 1 つのレベルをスキップします。


例えば、最高のレベルは企業 (レベル 1)、レベル 2 は支社、レベル 3 は建物、レベル 4 は部署となります。いくつかの支社は 1 つの建物の場所だけがあり、その中の部署は複数の建物の場所にある部署と同じです。

SAP BW で、これは表示階層に「割り当てられていない」(または #) ノードがあるときにのみ生じます。ただし、そのようなノードがあっても階層が常に不規則であるとは限りません。正確に知るためには、階層のレイアウトを調べる必要があります。

IBM Cognos Software は、階層タイプに関して障害の生じないデフォルトの設定値を使用します。

v SAP BW 特性を表すディメンションでは、「バランス」プロパティーが true に設定され、「不規則」プロパティーが false に設定されます。

v 表示階層を表すディメンションでは、「バランス」プロパティーが false に設定され、「不規則」プロパティーが true に設定されます。

ディメンションの「不規則」プロパティーを変更することにより、ディメンションが不規則な階層を表すかどうかを定義できます。設定する値は、ディメンションが表すオブジェクトのタイプ、および階層が不規則かどうかの知識に依存します。

ディメンションによる表現「不規則」プロパティーの値

特性 false

不規則ではない表示階層 false

不規則な表示階層 true


ディメンションによる表現「不規則」プロパティーの値

不明な構造の表示階層 true

表示階層なしで特性を表すディメンションは、読み取り専用です。

表示階層が不規則ではない場合、それが関連付けられたディメンションの「不規則」プロパティーを「false」に設定します。「不規則」プロパティーを適宜「false」に設定することにより、IBM Cognos Analytics サーバーはより効率的にMDX を生成できます。

不規則ではない階層の「不規則」プロパティーに値の「true」を割り当てた場合、このディメンションを含むクエリーは不正確なデータを返すことがあります。

不規則な階層の「不規則」プロパティーに値の「false」を割り当てた場合、パフォーマンスが低下することがあります。

不規則な階層、バランスのとれていない階層、および集計値に関する制限:

不規則な階層およびバランスのとれていない階層では、階層の個別のパスの間に、そして下位レベルに子孫がない中間レベルのノードの間に、隔離が生じることがあります。レポート内に単一のディメンションからの複数のクエリー・アイテムがあり、それらが階層内の連続または隣接するレベルからのものである場合、レポート内のディメンションの下位レベルに関連付けられたファクト値は、高位レベルに関連付けられた値に常に集計されている必要があります。

ただし、クエリー・アイテムが連続または隣接するレベルからのものではない場合、基礎となる SAP BW 階層が不規則であるかバランスがとれていないときには、高位レベルの値が低位レベルからのファクト値の集計を反映していない可能性があります。高位レベルに関連付けられた集計されたファクト値は、データ・ソース内の集計値を反映します。これは OLAP データ・ソースの典型的な動作ですが、リレーショナル・データ・ソースに対するレポートの作成に慣れたユーザーにとっては、直観に反するものと感じられることがあります。

ネットワーク階層:

階層のメンバーには複数の親があります。

例えば、1 人の従業員が複数の異なる組織に属していて、複数の管理者を持つことがあります。 SAP BW では、この従業員はすべての組織にそれぞれ含まれるのではなく、すべての従業員のカウントに 1 回だけ含まれます。


標準ディメンションのレベル (SAP BW)レベルは、通常は共通の細分性の属性の集合です。各レベルには、キーとして定義されたアイテムと、キャプションとして定義された別のアイテムが必要です。 SAPBW データ・ソースでは、レベルにはメンバーが含まれます。

階層の第 1 レベルは、All レベルとして自動的に定義されます。それには階層のトップレベルを表す単一のルート・メンバーが含まれます。例えば、Time ディメンションの All レベルの名前は Time (All) となります。 All レベルを削除または移動することはできません。その名前、説明、および画面のヒントを変更することはできます。

階層のレベルを正しく指定しない場合、不正確な集計が生じることがあります。

メンバー内で一意な名前:

メンバー内で一意な名前 (MUN) は、テーブル内のレコードを見つけるためにビジネス・キーを使用するように、データ・ソース内でメンバーを見つけるための方法となります。

メンバー内で一意な名前は、レポートで使用されるメンバー・データ・アイテムのための式、フィルターと式の中のメンバーへの参照のための式、および OLAP データ・ソース間のドリルスルーで使用されます。異なる OLAP データ・ソース間でのMUN のメンバー・キーは一致していなければなりません。

役割 (SAP BW)

クエリー・アイテムの代わりに役割を参照する式を作成することもできます。roleValue 関数を使用して、特定の役割を参照する必要があります。例えば、階層内の特定の役割に対してクエリーを実行したいのに、その役割を果たすクエリー・アイテムが階層の各レベルで異なることがあります。単一のクエリーは、各レベルで複数の異なるクエリー・アイテムに及ぶことができます。役割を知っていても基礎となるクエリー・アイテムを知らないときは、roleValue 関数も使用できます。


複数の役割を 1 つのクエリー・アイテムに割り当てることができますが、同じ役割を同一のレベル内にある複数の異なるクエリー・アイテムに割り当てることはできません。

すべての親子階層、およびレベルに基づく階層のすべてのレベルに対して、デフォルトの役割が事前定義されます。これらの役割のほとんどは、IBM CognosStudio/Authoring ツールに表示されません。

IBM Cognos Analytics で予約されている役割は、アンダースコアーで始まります。カスタム役割の名前をアンダースコアーで始めることはできません。

デフォルトの役割

デフォルトの役割には次のものが含まれます。

v _businessKey

レベルのキーを表します。ビジネス・キーは組織全体で一貫性のあるものでなければならないので、この役割は、データ・ソースから別のデータ・ソースにドリルスルーするためにも使用されます。

_businessKey 役割は、レベル内の 1 つの属性だけに割り当てることができます。

v _dimensionUniqueName

Framework Manager モデルに定義されたディメンションの名前を返します。

v _hierarchyUniqueName

Framework Manager モデルに定義された階層の名前を返します。

v _levelLabel

レベルに割り当てられたラベルを返します。

v _levelNumber

レベルの数を返します。

v _levelUniqueName

レベルに割り当てられた名前を返します。

v _longName

レベルの長い名前を表すクエリー・アイテムに割り当てられます。

v _memberCaption

IBM Cognos Studio/Authoring ツールに表示されるメンバーのキャプションを示します。

v _memberDescription

ディメンション内のメンバーについての説明を返します。

v _memberUniqueName

IBM Cognos メンバー内で一意な名前を返します。


v _parentUniqueName

選択されたクエリー・アイテムの親に割り当てられる名前を定義します。

v _planningDefault

数値データが選択されたときに使用するクエリー・アイテムを指定します。この役割を適用できるのは、IBM Cognos Planning および SAP BW だけです。

v _rollupType

クエリー・アイテムを集計する方法を定義します。

v _shortName

レベルの短縮名を表すクエリー・アイテムに割り当てられます。

クエリー・アイテムがデフォルトの役割を使用する場合、その役割は変更できません。これは SAP BW メタデータにのみ適用されます。

カスタム役割

カスタムの役割を作成できます。作成する各役割には、一意の名前が必要です。IBM Cognos で予約されている役割は、アンダースコアーで始まります。カスタム役割の名前をアンダースコアーで始めることはできません。モデル内のカスタム役割は翻訳できます。

OLAP データ・ソース内のユーザー定義プロパティーには、クエリー・アイテムと同じ名前の役割が割り当てられます。

役割の指定 (SAP BW)役割は、IBM Cognos Studio のメンバー・ツリーに表示される内容を定義します。役割を使用して、メタデータを整理して管理し、ユーザーに対するデータの表示方法を決定します。

手順

1. 定義する役割が含まれるディメンションをクリックします。


3. 「ディメンション」タブをクリックします。

4. 「階層」ボックスで、必要とするレベルをクリックします。

5. 「階層コントロール内のレベルを選択して、クエリー・アイテムを表示します」ボックスで、クエリー・アイテムをクリックします。

6. 「役割」の下の省略符号 (...) ボタンをクリックします。

7. 「カスタム役割」タブをクリックして、「追加」をクリックします。



タスクの結果

「ディメンション・マップ」タブを使用して役割を定義することもできます。「属性」をクリックし、クエリー・アイテムを右クリックして、「役割を編集」をクリックします。


キー数値ディメンションの変更 (SAP BW)キー数値ディメンションは、「販売数量」や「価格」などのファクトの集合です。

キー数値は、標準ディメンションを介して相互に関連しています。キー数値ディメンションはレポートや分析で使用されると、名前や数値などのクエリー・アイテムの値を示すか、Null、ゼロ、または無効を示します。機能領域を完全に比較して対比するレポートを作成するためには、複数のキー数値ディメンションをレポートで使用しなければならない場合もあります。

「利益幅」など、既存のビジネス・ルールに基づいた計算を埋め込むことにより、値を追加できます。

複数のディメンションのプロパティーを同時に変更することもできます ( 19 ページの『複数のプロパティー値の置換』)。

キー数値ディメンションの階層とレベルは定義できません。

ディメンションが SAP BW メタデータに基づいている場合、基礎となるクエリーは編集できません。ただし、計算とフィルターを追加することができます。

手順1. 変更するキー数値ディメンションをクリックします。



v 「追加」をクリックした後、式を定義することにより、計算を埋め込む( 261 ページの『計算の作成 (SAP BW)』)。

v 矢印ボタンを使用することにより、数値データ、アイテム、または計算の順序を変更する。ただし、数値データ・ディメンションにフォルダーが含まれる場合、順序の変更は「プロジェクト・ビューアー」でのみ行えます。

v フィルターを埋め込む ( 263 ページの『フィルターの作成 (SAP BW)』)。

v ディメンションをテストする ( 234 ページの『ディメンションまたは他のオブジェクトのテスト (SAP BW)』)。


関連オブジェクトの表示 (SAP BW)

「プロジェクト・ビューアー」で選択するクエリー・サブジェクトまたはディメンションと接続されているオブジェクトのビジュアル表示を検討することができます。「コンテキスト・エクスプローラー」には、選択されているオブジェクトが接続されているオブジェクトが表示されます。接続されているオブジェクトを選択し、その参照を表示することもできます。







目的ボタン





ディメンションまたは他のオブジェクトのテスト (SAP BW)ディメンション、レベル、階層、クエリー・アイテム、またはモデル・クエリー・サブジェクトをテストできます。

標準ディメンションをテストすると、ディメンションで最初に検出された階層に関連付けられた属性が返されます。




テスト対象に応じて異なる結果が表示されることがあります。例えば、式エディターを使用してクエリー・サブジェクトに組み込まれた計算をテストする場合、Framework Manager は式だけをテストしてアイテムはテストしないので、クエリー・アイテムの集計設定はテストに適用されません。計算を含むクエリー・サブジ


ェクト全体をテストすると、集計設定が適用されるので別の結果が生成されます。例えば、集計設定が要約された場合、テストに示される行数は小さくなります。





オブジェクトを作成または変更する際のテストの手順 (SAP BW)

手順


2. 「操作」メニューの「定義を編集」をクリックし、「テスト」または「クエリー情報」タブをクリックします。




4. 式をテストする際にクエリー・アイテムの「標準集計」プロパティーまたは式で参照される数値データを適用する場合、「自動合計」チェック・ボックスをオンにします。





手順







テスト設定の変更 (SAP BW)テスト設定を変更することにより、テストをカスタマイズできます。

手順































タスクの結果

詳細については、 223 ページの『ディメンション (SAP BW)』および『モデル・クエリー・サブジェクト (SAP BW)』を参照してください。

モデル・クエリー・サブジェクト (SAP BW)


クエリー・サブジェクトによって取得されるデータを最適化およびカスタマイズするために、IBM Cognos Framework Manager を使ってクエリー・サブジェクトを変更します。例えば、フィルターや計算を追加することができます。クエリー・サブジェクトの定義を変更すると、Framework Manager は関連するクエリー・アイテムを再生成します。これにより、クエリー・サブジェクトのプロパティーのすべての変更点が、そのクエリー・サブジェクトに属するすべてのクエリー・アイテムに確実に反映されます。


SAP BW メタデータの場合、IBM Cognos Framework Manager でモデル・クエリー・サブジェクトを操作することができます。

モデル・クエリー・サブジェクトは、データ・ソースから直接生成されるのではなく、他のモデル・クエリー・サブジェクトも含め、他のクエリー・サブジェクトまたはディメンション内のクエリー・アイテムをベースにしています。モデル・クエリー・サブジェクトを使用することによって、データ・ソースの、より抽象的でビジネス指向のビューを作成できます。

複数のディメンションを含むモデル・クエリー・サブジェクトを作成した場合、他のクエリー・サブジェクトやディメンションと共にそのモデル・クエリー・サブジェクトを使用すると、問題が発生することがあります。モデル・クエリー・サブジェクト内の項目がモデルの論理に反しないことを確認してください (例:「国または地域」項目と「市」項目の間に挿入された「製品」項目)。レポートでモデル・クエリー・サブジェクトを検査してください。グループ化が正常に機能している場合は、そのモデル・クエリー・サブジェクトが有効です。

モデル・クエリー・サブジェクトの作成 (SAP BW)

既存のクエリー・サブジェクトとクエリー・アイテムをマージすることで、新しいモデル・クエリー・サブジェクトを作成することもできます ( 239 ページの『既存のオブジェクトに基づくモデル・クエリー・サブジェクトの作成 (SAP BW)』)。

手順

1. ネームスペース・フォルダーを選択し、「操作」メニューから、「作成」、「クエリー・サブジェクト」の順にクリックします。


3. 「モデル」をクリックし、「OK」をクリックします。

注: SAP BW メタデータの場合、作成できるのはモデル・クエリー・サブジェクトのみです。

4. 「クエリー・サブジェクト定義」タブをクリックします。

5. アイテムをモデル・クエリー・サブジェクトに追加するには、アイテムを「使用可能なモデル・オブジェクト」ボックスから「クエリー・アイテムと計算」ボックスにドラッグします。

アイテムおよび計算の順序は変更可能です。ただし、クエリー・サブジェクトにクエリー・アイテム・フォルダーが含まれる場合、順序の変更は「プロジェクト・ビューアー」でのみ行えます。

6. モデル・クエリー・サブジェクトに計算を埋め込むには、「追加」をクリックして計算を定義します。

7. モデル・クエリー・サブジェクトにフィルターを埋め込むには、「フィルター」タブをクリックします。

8. モデル・クエリー・サブジェクトをテストするには、「テスト」タブをクリックします。




タスクの結果


v 埋め込み計算 ( 261 ページの『計算の作成 (SAP BW)』)

v 埋め込みフィルター ( 263 ページの『フィルターの作成 (SAP BW)』)

v テストおよびテストの設定オプション ( 234 ページの『ディメンションまたは他のオブジェクトのテスト (SAP BW)』)

v 複数のクエリー・サブジェクトのプロパティーの同時変更 ( 19 ページの『複数のプロパティー値の置換』)

既存のオブジェクトに基づくモデル・クエリー・サブジェクトの作成(SAP BW)既存のモデル・オブジェクトを選択し、それらをマージして新しいモデル・クエリー・サブジェクトにすることができます。

これは、クエリー・サブジェクトを短時間で作成するために既存のメタデータを再利用することができることを意味します。

マージできるオブジェクトには、以下のものがあります。

v モデル・クエリー・サブジェクトおよびショートカット。

v モデル・クエリー・サブジェクト内のクエリー・アイテム、フィルター、および計算。

新しいクエリーを作成するために、1 回の操作で同タイプのオブジェクトをいくつでもマージすることができます。マージでは、必ず新規モデル・クエリー・サブジェクトが作成されます。

新規クエリー・サブジェクトには、元のクエリー・サブジェクトに含まれているフィルターがすべて含まれます。

モデル・クエリー・サブジェクトがモデルの論理と矛盾していないことを確認します。例えば、複数の特性を持つクエリー・サブジェクトを他のクエリー・サブジェクトと一緒に使用する場合、レポートの実行時に問題が発生する可能性があります。

別のクエリー・サブジェクトのクエリー・アイテムや同じディメンションの階層は含めないでください。これは実行時エラーの原因となります。

手順

1. マージして 1 つのクエリー・サブジェクトにするオブジェクトを、Ctrl を押しながらクリックします。

2. 「操作」、「新規クエリー・サブジェクトにマージ」の順にクリックします。


モデル・クエリー・サブジェクトの検証 (SAP BW)

「クエリー・サブジェクト定義」ダイアログ・ボックスを開かずにクエリー・サブジェクトの定義を検証することができます。これは、次のような場合に便利です。

v 新規クエリー・アイテムがクエリー・サブジェクトに追加された場合

v 基になるクエリー・サブジェクトの定義が変更された場合

「オブジェクトの検証」コマンドは、選択されたオブジェクトを評価し、それを確実に実行できるようにします。

IBM Cognos Framework Manager がクエリー・サブジェクトを評価する際、要求が SAP BW データ・ソースに送られます。その後、必要に応じてクエリー・サブジェクトの物理属性 (データ型など) が更新されます。

プロジェクト全体を同期することもできます ( 334 ページの『プロジェクトの同期』)。

手順

1. 評価するクエリー・サブジェクトを選択します。

2. 「ツール」メニューの「オブジェクトの検証」をクリックします。

タスクの結果

「標準集計」プロパティーを「サポート対象外」に変更した場合、クエリー・サブジェクトを評価するときにプロパティーはリセットされます。プロパティーが他のいずれかの値に設定される場合、プロパティーは変更されません。

注: 無効なクエリー・サブジェクトごとにエラー・メッセージが表示されます。オブジェクトの状況も「無効」になります。

クエリー・アイテム (SAP BW)クエリー・アイテムは、レポート内に配置できるモデルの最小単位です。それは、製品が導入された日付など、物事の単一のインスタンスを表します。

キー数値および属性は、IBM Cognos Framework Manager にクエリー・アイテムとしてインポートされます。

同じレポート内では、1 つのディメンションから 1 つの階層だけを使用してください。

SAP BW メタデータでは、名前や画面ヒントなどのテキスト・ベースのプロパティーだけを変更できます。

レポートにはモデル内の 1 つ以上のオブジェクトから複数の異なるクエリー・アイテムを含めることができるので、クエリー・アイテム・プロパティーは最終レポートの多くの側面を制御します。モデル・ディメンションまたはモデル・クエリー・サブジェクトを作成するとき、クエリー・アイテムは基礎となるデータ・ソース・クエリー・アイテムのプロパティーを継承します。


クエリー・アイテムまたは数値データのプロパティーには、以下のものがあります。


名前クエリー・アイテムまたは数値データの名前。

説明クエリー・アイテムまたは数値データの説明。

最終変更日時クエリー・アイテムまたは数値データが最後に変更された日付。プロパティーは現在の日時によって自動的に更新されます。

最終変更者クエリー・アイテムまたは数値データを最後に変更したユーザー。このプロパティーは、アイテムが変更されると自動的に更新されます。

値は現在のログオン・ユーザー名となります。

モデルのコメントモデルについての内部コメントを追加するために使用します。この情報は、「発行の影響を分析」ダイアログおよびモデル・レポートで使用されます。パッケージ・ユーザーはコメントにアクセスできません。

画面のヒントユーザーのために発行済みパッケージに表示できる記述。

式定期的に使用するための算出値をユーザーに提供する埋め込み計算の作成に使用します。

このプロパティーは、数値データ専用です。

注: 「式」プロパティーは SAP BW によって使用されません。

外部名データ・ソースに表示される名前。



非表示発行済みパッケージでクエリー・アイテムまたは数値データを非表示にするか表示にするかを指定します。

「非表示」が「True」に設定されて、クエリー・アイテムや数値データがユーザーに表示されない場合でも、クエリー・アイテムまたは数値データはモデル内の他のオブジェクトによって必要とされることがあるので、発行済みパッケージ内に常に存在します。「パッケージ発行 (Package Publish)」ウィザードには、クエリー・アイテムや数値データが表示されません。

例えば、計算は非表示のクエリー・アイテムを利用することがあります。

使用方法クエリー・アイテムによって表されるデータの意図された使用方法。


書式情報がレポートに表示される方法。

通貨使用される通貨。

このプロパティーは、「プロパティー」ウィンドウでは変更できません。「形式」プロパティーを使用して、通貨を変更します。

データ型データ・ソースに設定されたデータ型。


精度総桁数。




スケールスケールで表される桁数。

例えば、100,000 が 100,000,000 を意味するように、数値を 1000 単位で表すことができます。


サイズクエリー・アイテムまたは数値データのサイズ。


NULL 可能クエリー・アイテムまたは数値データがNull 値を含むことができるかどうか。


表示タイプクエリー・アイテムが表示される方法。

IBM Cognos Studio/Authoring ツールで、列値は図、リンク、または値として表すことができます。

デフォルトは、値です。


MIME タイプ列値が使用する形式。

例えば、「表示タイプ」が図に設定されている場合、「MIME タイプ」は jpeg などになります。


注: 「MIME タイプ」プロパティーは SAPBW によって使用されません。

プロンプト情報プロンプトの動作。

標準集計発行済みパッケージで、クエリー・アイテム、数値データ、または計算に関連付けられた集計のタイプ。



集計規則ディメンションを使用してモデル化されたリレーショナル・メタデータで、準加算集計のための規則。

SAP BW メタデータで、「集計規則」プロパティーは読み取り専用です。

割り当て規則数値データに定義された割り当てのタイプを指定します。

値の「デフォルト」は、リスト・クエリーでは定数割り当てが使用され、クロス集計クエリーでは 1 回のみの割り当てが使用されるように指定します。値の「定数」は、すべてのクエリーで定数割り当てが使用されるように指定します。

ソート不可このクエリー・アイテムの値がソート可能かどうかを指定します。

このプロパティーは、BLOB などのラージ・オブジェクトを含むクエリー・アイテムのためのものです。


v 「使用方法」および「標準集計」プロパティー『クエリー・アイテムの集計方法の変更 (SAP BW)』

v 通貨記号の変更 248 ページの『クエリー・アイテムの形式設定 (SAP BW)』

v プロンプト 249 ページの『プロンプト・コントロールの定義 (SAP BW)』

v 複数のクエリー・アイテムのプロパティーを同時に変更する 19 ページの『複数のプロパティー値の置換』

クエリー・アイテムの集計方法の変更 (SAP BW)

メタデータがインポートされると、Framework Manager はクエリー・アイテムおよび数値データの「使用方法」プロパティーと「標準集計」プロパティーに、クエリー・アイテムまたは数値データが含まれるオブジェクトのタイプに応じて値を割り当てます。「使用方法」プロパティーは、クエリー・アイテムで表されるデータの目的の用途を示します ( 154 ページの『使用方法プロパティー』)。「標準集計」プロパティーは、クエリー・アイテムまたは数値データに適用される集計のタイプを示します ( 155 ページの『標準集計プロパティー』)。ユーザーは「標準集計」プロパティーの値をオーバーライドできます。準加算数値データの場合は、「集計規則」プロパティーを変更することにより、追加の集計規則を指定できます ( 155 ページの『準加算数値データの集計規則の定義』)。

「標準集計」プロパティーを変更するときに、平均や最大値など、インポートでは使用できない値を選択できます。どの集計値が必要かを知るには、データが何を表


すかを理解する必要があります。例えば、部品番号を集計する場合、適用される集計値は、カウント、重複値を除くデータの個数、最大値、および最小値のみです。

一般に、集計関数を式に追加するのではなく、「標準集計」プロパティーを使用します。必要な自動集計が集計プロパティーでサポートされていない場合、または式が複雑でアイテムのプロパティーを使用した管理ができない場合は、式の集計関数を使用します。

個別の値 (個別の顧客など) をカウントする際にリスト、クロス集計、およびグラフ内の結果の整合性を保つには、文字列値ではなく値を一意的に識別するビジネス・キーを参照します。この方法により、異なる顧客に同じ名前が使用されている場合に、意図せずに行が欠落してしまうことを防ぐことができます。

次の例では、リレーショナル・モデルで個別の顧客をカウントする方法を説明します。

1. Customer クエリー・サブジェクトの Customer Key クエリー・アイテムのコピーを作成し、それに Customer Count という名前を付けます。

2. Customer Count の「使用方法」プロパティーを「ファクト」に設定します。

3. Customer Count の「標準集計」プロパティーを「重複値を除くデータの個数」に設定します。

4. 形式設定が必要な場合は、「表示形式」を「数値」に設定し、「小数の桁数」や「桁区切り記号」の「No.」などの形式プロパティーを必要に応じて指定します。

Count (distinct [Customer Key]) の式のクエリー・アイテムは、予期しない動作になる可能性があります。

次の例では、ディメンションを使用してモデル化されたリレーショナル (DMR) モデルで個別の顧客をカウントする方法を説明します。

1. 前の例の手順に従って、Customer クエリー・サブジェクトの Customer Count

クエリー・アイテムを作成します。

2. 手順 1 の Customer Count クエリー・アイテムを、数値データ・ディメンションに追加します。

3. 「標準集計」プロパティーと「形式」プロパティーの設定は継承されます。

あるいは、元の Customer Key を Customer クエリー・サブジェクトから数値データ・ディメンションに追加することもできます。次に、「標準集計」プロパティーを「重複値を除くデータの個数」に設定し、必要に応じて表示形式を設定します。

ディメンションのプロパティーを設定するための規則 (SAP BW)

IBM Cognos Framework Manager は以下の規則を使用して、「使用方法」および「標準集計」プロパティーを設定します。



標準ディメンションのクエリー・アイテム


数値データ・ディメンションのクエリー・アイテム


数値データ・ディメンションの数値データ

ファクト数値データが計算の場合は自動

数値データが計算ではない場合は合計

数値データが準加算の場合、「集計規則」プロパティーを使用して準加算集計の規則を定義します。 155 ページの『準加算数値データの集計規則の定義』を参照してください。

SAP BW メタデータでは、ディメンションに関してこれらのプロパティーを変更できません。

計算のプロパティーを設定するための規則 (SAP BW)SAP BW メタデータでの計算のための「標準集計」プロパティーは、「自動」に設定されます。自動が何を意味するかを決める際には、以下の規則が適用されます。


キー・アイテム非サポート

他のすべてのアイテム算出

モデル・クエリー・サブジェクトのプロパティーを設定するための規則 (SAP BW)モデル・クエリー・サブジェクトに対して、Framework Manager はモデル・クエリー・サブジェクトの基礎となるオブジェクトの設定を使用します。

注: SAP BW メタデータの集計値を変更する場合、集計規則が適用されないので、集計は時間に基づくクエリーを実行できません。

使用方法プロパティー

このプロパティーが正しく設定されていることを検証する必要があります。例えば、関係に関与する数値列をインポートする場合、「使用方法」プロパティーは「識別子」に設定されます。このプロパティーを変更することができます。

SAP BW クエリー・アイテムの場合、「使用方法」プロパティーの値は、クエリー・アイテムが基づいているディメンション・アイテムのタイプによって異なります。


「使用方法」プロパティー値 SAP BW オブジェクト説明

識別子階層レベル階層の特定レベルの特性値を一意的に識別します。

ファクトキー数値通常は数値データであるキー数値を表します。日時データもサポートされます。

属性表示属性特性に関連付けられた表示属性を表します。

標準集計プロパティー

例えば、「数量」クエリー・アイテムの「標準集計」プロパティー値が「合計」であり、レポート内で「製品名」ごとにグループ化される場合、レポートの「数量」列は各製品の合計数量を示します。

以下の集計タイプが SAP BW データ・ソースでサポートされます。

v 自動

v 平均値

v ゼロ以外の平均値

このタイプは、データ・ソースに設定された場合にのみサポートされます。Framework Manager でプロパティーを「ゼロ以外の平均値」に変更することはできません。

v 算出値

v カウント

v 重複値を除くデータのカウント

v ゼロ以外のカウント

このタイプは、データ・ソースに設定された場合にのみサポートされます。Framework Manager でプロパティーを「ゼロ以外のカウント」に変更することはできません。

v 最大

v 中央値

v 最小

v 標準偏差

v 合計

v 分散

自動集計タイプを決定するための規則:

SAP BW オブジェクトに計算が含まれる場合、これらの規則が適用されます。


キー・アイテム非サポート

他のすべてのアイテム算出


集計規則のプロパティーディメンションでモデル化されたリレーショナル・メタデータの場合、このプロパティーは選択したディメンションに関する準加算的な数値データの集計方法を定義します。

SAP BW メタデータの場合、「集計規則」プロパティーは読み取り専用です。代わりに「準集計」プロパティーが使用されます。

「準集計」プロパティーSAP BW メタデータの場合、「準集計」プロパティーにはデータ・ソースで設定された値が示され、このプロパティーは読み取り専用です。

IBM Cognos Framework Manager で値が「サポート対象外」に設定されている場合、IBM Cognos Studio/Authoring ツールでは準集計動作は無視されます。

将来のリリースでは、「準集計」プロパティーはサポートされなくなります。代わりに、準加算数値データのための「集計規則」プロパティーを使用してください。

クエリー・アイテムの形式設定 (SAP BW)

例えば、「通貨」表示形式を数値クエリー・アイテムに割り当ててから、「データ形式」ダイアログ・ボックスの「小数桁数」「いいえ」プロパティーを使用して、レポートに表示する小数の桁数を指定できます。

いくつかの記号は言語に依存するので、使用するロケールが適切なフォントをサポートする場合にのみ正常に表示されます。例えば、日本の通貨記号を正常に表示するためにはロケールが日本語に設定されていなければなりません。

IBM Cognos Framework Manager で必要な通貨が表示されない場合、通貨記号をサポートするための適切な言語パックをインストールしたことを確認する必要があります。例えば、インドの通貨記号 (ルピー) を表示するためには、この記号を表示できるオペレーティング・システムを実行するか、または言語パックをインストールする必要があります。日本語のオペレーティング・システムや日本語の言語パックは、インドの通貨記号を表示できるものの 1 つです。

複数のクエリー・アイテムのプロパティーを同時に定義できます。ただし、クエリー・アイテムに複数の異なる表示形式がある場合は、以前に指定されたすべてのプロパティーがオーバーライドされて、データ・ソースからのデフォルト値が使用されます。選択された複数のクエリー・アイテムで元の表示形式が同じである場合、選択されたクエリー・アイテムのすべてのプロパティーは同一に設定されます。

例えば、2 つのクエリー・アイテムで同じ小数点記号を使用し、小数点の桁数は異なるようにするためには、それぞれのクエリー・アイテムを個別に変更する必要があります。両方が選択されて同時に変更された場合は、両方のクエリー・アイテムで小数点の桁数を含むすべてのプロパティーが同一に設定されます。


クエリー・アイテムの表示形式を設定する手順 (SAP BW)

手順

1. 「プロジェクト・ビューアー」ウィンドウで、表示形式を設定するクエリー・アイテムをクリックします。

2. 「プロパティー」ウィンドウの「プロパティー」タブで、「表示形式」プロパティーをクリックします。

3. 表示形式を通貨に設定し、その通貨の表示形式がすべてのタイプのレポートに適用されるようにします。

4. 「通貨の範囲」ボックスに、通貨のタイプを指定します。使用する通貨が表示されていない場合、「追加」ボタンをクリックします。

5. 「プロパティー」ボックスで、該当するプロパティー値を選択するか、入力します。


プロンプト・コントロールの定義 (SAP BW)

プロンプトは、次の場所で使用できます。

v パラメーター・マップ

v セッション・パラメーター

v 式 (フィルター、計算など)

注: キャプションとそのレベルのビジネス・キー (MUN) とでデータ型が異なる場合、キャプションの「プロンプトのタイプ」の設定と「フィルター・アイテム参照」を組み合わせて使用します。これにより、Studio/Authoring ツールでフィルター操作を行うときに正しいデータ型が使用されるようになります。

これは ProductTypeCode のような、レポートに値は表示されないもののデータをフィルター操作するために役立つクエリー・アイテムの場合に便利です。一般に、追加のプロンプト機能を利用できるようにレポート内で入力プロンプトを定義するほうが優れています。ただし、ユーザーはいくつかの変数を変更できません。それらの変数については、レポートの代わりに IBM Cognos Framework Manager を使用して入力プロンプトを定義できます。

Framework Manager で設定された「プロンプト情報」プロパティーを使用すると、デフォルトのフィルター処理およびプロンプト処理を制御することができます。プロパティーは、以下によって使用されます。


v Reporting の「プロンプト・ページを作成」ツール。フィルター式を作成したり、プロンプトおよびプロンプト・クエリーで使用および表示されるアイテムを設定したりするため。


プロンプトを値として使用するための構文は、次のとおりです。

?<PromptName>?


プロンプト・コントロールを定義する手順

手順

1. クエリー・アイテムをクリックします。


3. 「プロンプト情報」プロパティーの横にある正符号 (+) をクリックします。

これは複合クエリー・アイテムのプロパティーです。

4. 必要な動作を反映するように以下のプロパティーを変更します。

目的プロパティー

レポートの実行時に生成されるプロンプト・コントロールのタイプを設定する。

プロンプトのタイプ

生成されるプロンプトを、生成される一連のカスケード・プロンプトの一部として設定する。

カスケード・オン・アイテム参照

プロンプトでレポート・ユーザーに対して表示されるクエリー・アイテムを指定する。

プロンプトの値は、クエリー・アイテムのデータ値です。

プロンプトの各値は、「使用アイテム参照」プロパティーで指定されるクエリー・アイテムの値と関連付けられます。

表示アイテム参照

プロンプトからフィルターに渡されるクエリー・アイテムを指定します。

各値は、「表示アイテム参照」プロパティーで指定されるクエリー・アイテムの値と関連付けられます。

使用アイテム参照

データを取得するためにフィルター式で使用されるクエリー・アイテムを指定します。

フィルター・アイテム参照

「プロンプトのタイプ」プロパティー「プロンプトのタイプ」プロパティーは、編集ボックスやプルダウン・リストなど、レポートの実行時に生成されるプロンプト・コントロールのタイプを設定します。

このプロパティーのデフォルト値は「サーバーで判別」です。

注: 属性に設定されたプロンプト・タイプが処理されるようになりました。属性上のプロンプト・タイプと一致するプロンプトが、レポート・ユーザーに表示されます。前のリリースでは属性上のプロンプト・タイプが処理されなかったので、いくらかの違いが生じることがあります。



サーバーで判別プロンプト・コントロールのタイプは、クエリー・アイテムのデータ型など、サーバー内の情報に基づいています。

編集ボックス簡単なテキスト・ボックス。列のデータ型が日付または日付時刻の場合、この値によって、日付または日付時刻のコントロールがテキスト・ボックスと共に生成されます。

日付の選択カレンダー・インターフェースのある日付のコントロール。

日時の選択カレンダー・インターフェースのある日付時刻のコントロール。


間隔の選択日付時刻インターバル・コントロール。


時刻の選択選択された期間に基づいてデータにフィルターを掛ける時間コントロール。例えば、発注時刻に対して「時間の選択」プロンプトを定義した場合、ユーザーは時間コントロールを使用して 1:00 より後に行ったすべての発注を表示したり、10:00 から 11:00 までの間に行ったすべての発注を表示したりすることができます。

時刻メンバーを参照する場合は、厳密な値だけを使用しなければなりません。

範囲を使用する場合は、範囲の終点がデータ・ソース内の値に対応していなければなりません。

値の選択ドロップダウン・リスト。

検索による選択ユーザーが値を検索するためのリスト・コントロール。


ツリーによる選択階層ノードに基づくプロンプトのためのツリー・プロンプト・コントロール。

「カスケード・オン・アイテム参照」プロパティー「カスケード・オン・アイテム参照」プロパティーは、生成されたプロンプトが、一連の生成されたカスケード・プロンプトの一部であることを示します。このプロパティーで参照するクエリー・アイテムは、カスケード内の親アイテムです。システムはユーザーに現在のクエリー・アイテムの指定を求めるプロンプトを出す前に、カスケード・アイテムの指定を求めるプロンプトを出します。


例えば、製品ラインの指定を求めるプロンプトを出してから選択されたライン内の製品の指定を求めるプロンプトを出すためには、「製品」クエリー・アイテムの「カスケード・オン・アイテム参照」プロパティーを「製品ライン」に設定します。

表示アイテム参照プロパティーおよび使用アイテム参照プロパティー「表示アイテム参照」プロパティーは、プロンプトでユーザーに表示されるクエリー・アイテムを指定します。「使用アイテム参照」プロパティーは、プロンプトからフィルターに渡されるクエリー・アイテムを指定します。表示アイテムのリスト内の各値は、「使用アイテム参照」プロパティーで指定されたクエリー・アイテムの値に関連付けられます。

例えば、プロンプトには国名を表示しながら、国コードを使用してデータを取得することができます。「表示アイテム参照」プロパティーを国名に設定し、「使用アイテム参照」プロパティーを国コードに設定します。プロンプトに国名が示されるので、レポート・ユーザーは必要な値を容易に選択できます。一方で、フィルターに国コードを使用するとデータの取得がより効率的になります。

これらのプロパティーは、以下によって使用されます。


v Reporting の「プロンプト・ページを作成」ツール。プロンプトおよびプロンプト・クエリーで使用および表示されるアイテムを設定するため。


注: 「使用アイテム参照」プロパティーの値と「フィルター・アイテム参照」プロパティーの値の間には互換性が必要です。そうでない場合、レポート・ユーザーは予期しない結果を受け取る可能性があります。詳細については、 163 ページの『フィルター・アイテム参照プロパティー』を参照してください。

デフォルト: 値が設定されない場合、プロパティーはデフォルトでクエリー・アイテムの名前になります。

これらのプロパティーは、「プロンプトのタイプ」プロパティーが「値の選択」または「検索による選択」に設定された、データ駆動型のプロンプト・コントロールにのみ使用されます。

フィルター・アイテム参照プロパティー「フィルター・アイテム参照」プロパティーは、Reporting または Query Studioでフィルターを生成するときに使われるクエリー・アイテムを識別します。このプロパティーを使用すると、索引のないストリング列の代わりに索引付き数値列がフィルターで使われるようになるため、より効率的なクエリーの作成に役立ちます。

例えば、レポート作成者が Country Name (国名) クエリー・アイテムのフィルターを作成する予定であるとします。 Country Name クエリー・アイテムを使用するすべてのフィルターで Country Name の代わりに Country Code (国別コード)を使うよう、「フィルター・アイテム参照」プロパティーを設定できます。


別の例として、レポート作成者が、Orders (注文) テーブルに表示される CountryCode (国別コード) クエリー・アイテムのフィルターを作成する予定であるとします。ここで、Country テーブルは読み取る行が少ないため、Country テーブル内のCountry Code をフィルターで使用するのが適切と判断されるとします。この場合、モデルで「フィルター・アイテム参照」を Country.Country Code に設定できます。

このプロパティーは、以下のものによって使用されます。

v Query Studio (フィルター式を作成するために)

v Reporting のプロンプト・ページ作成ツール (フィルター式を作成するために)

デフォルト: 値を設定しない場合、プロパティーのデフォルトとして、クエリー・アイテムの名前が指定されます。

「フィルター・アイテム参照」プロパティーと「使用アイテム参照」プロパティーの使用

「フィルター・アイテム参照」プロパティーの値と「使用アイテム参照」プロパティーの値の間で、互換性が必要です。「使用アイテム参照」プロパティーの値は、「フィルター・アイテム参照」プロパティーで期待されるタイプである必要があります。そうでない場合、レポート・ユーザーは予期しない結果を受け取る可能性があります。レポート・ユーザーがプロンプト・ページを作成せずにフィルターを作成した場合に、これが発生することがあります。

例えば、あるモデルで「使用アイテム参照」プロパティーが Employee Number(従業員番号) に、「フィルター・アイテム参照」プロパティーが Employee Name(従業員名) にそれぞれ設定されているとします。 Reporting で、レポート作成者がプロンプト・ページを作成せずに以下のフィルターを作成するとします。

Reference.EmployeeName in ?parm1?

プロンプト・ページを作成せずにフィルターを作成した場合、Reporting によってプロンプトが自動的に生成されます。プロンプトが生成されるため、Reporting はFramework Manager モデル内の Employee Name クエリー・アイテムからの「プロンプト情報」プロパティーを使用します。

「使用アイテム参照」は、フィルターに渡される値が従業員番号であることを示します。「フィルター・アイテム参照」は従業員名に基づいてデータをフィルターします。フィルターは次のとおりです。Reference].[Employee Name] in ("1", "2").Employee Name 値には "1" および "2" が存在しないため、レポートはブランクになります。

ディメンションでモデル化されたリレーショナル・メタデータ用にフィルター・アイテム参照を使用する

ディメンションでモデル化されたリレーショナル・メタデータの場合、レベルではなく _memberCaption 役割を持つ属性で「プロンプト情報」が指定されます。「プロンプト情報」プロパティーは属性において設定されますが、レベル上に存在するかのように処理されます。デフォルトでは、レポートにレベルが含まれる場合、ユーザーはレベルのプロンプトで MUN を入力するよう促されます。代わりにキャプション値を入力するには、属性の「フィルター・アイテム参照」プロパティーを属


性自体に設定してください。プロンプト付きフィルターが適用されると、フィルターされる値は属性値に基づくようになります。

例えばレベル Product Line (製品ライン) に、役割 _memberCaption を持つ属性Product Line があるとします。「フィルター・アイテム参照」プロパティー値がProduct Line に設定されている場合、レポート・ユーザーは Product Line 値を入力するよう促されます。「フィルター・アイテム参照」プロパティー値がブランクのままである場合、ユーザーは MUN を入力するよう促されます。

注:「ツリーによる選択」プロンプト・タイプと共に「フィルター・アイテム参照」プロパティーを使用しないでください。「ツリーによる選択」プロンプトではレベルまたは階層だけのフィルターが可能であるため、「フィルター・アイテム参照」プロパティーを設定するとエラーが発生します。

プロンプトのテストプロンプトを参照するモデル・オブジェクトをテストするとき、IBM CognosFramework Manager からプロンプト値の入力を求められます。 FrameworkManager はこの値を、セッションの期間中またはプロンプト値がクリアされるまで使用します。

プロンプト値のセッション値を「オプション」ダイアログ・ボックスで変更できます。このダイアログ・ボックスは、ディメンションまたはクエリー・サブジェクトを変更するとき、あるいは計算、フィルター、クエリー・セット、複雑な関係を定義するときに使用できます。プロンプト値は、その値を参照する式をテストする時点で変更できます。

「プロンプト」ダイアログ・ボックスの「テスト時に値を毎回プロンプトする」チェック・ボックスを選択すると、オブジェクトをテストするたびに値の入力を求めるプロンプトが Framework Manager から出されます。オブジェクトの更新時やカウントの実行時、Framework Manager は既存のプロンプト値があればそれを使用します。

モデル・クエリー・サブジェクト内のクエリー・アイテムのプロンプトは、そのクエリー・アイテムにのみ関連付けられます。データ・ソース・クエリー・サブジェクト内のクエリー・アイテムのプロンプトはクエリー・サブジェクト全体に関連付けられるため、クエリー・サブジェクト内のどのクエリー・アイテムをテストするときにも、プロンプトが表示されます。

SAP BW 変数SAP BW 変数は、クエリーの定義時にセットアップされる SAP BW クエリーのパラメーターです。クエリーの実行時に SAP BW 変数に値が設定されます。これらの変数はプレースホルダーとして機能し、さまざまに処理できます。これらは実行時にプロンプトとして自動的に表示されます。

SAP BW 変数情報は、データ・ソースに 1 つ以上の変数が関連付けられている場合にのみ存在する、「SAP BW 変数」という名前の複合カスタム・プロパティーに含まれます。「SAP BW 変数」プロパティーには複合プロパティーが 1 つ以上含まれます。複合プロパティーのそれぞれに、固有の名前が割り当てられなければな


りません。各プロパティーは、1 つの SAP BW 変数の記述を表します。変数情報はカスタム・プロパティーで指定されるため、Framework Manager はこれらのプロパティーを検証しません。

SAP BW 変数情報は、SAP BW BAPI MDDataProviderBW::GetVariables を使用して取得されます。

Framework Manager は以下のタイプの SAP BW 変数をサポートします。

v 特性

特性変数には特性値および階層ノードの 2 つの種類があります。特性値の変数は、特性値を取ります。階層ノードの変数は、表示階層内の任意の位置から値を取ります。

v 階層

選択された階層に基づいて IBM Cognos ソフトウェアが実行時に自動的に値を設定するため、ユーザーに値を求めるプロンプトは表示されません。階層の変数は、特性の階層のプレースホルダーとして機能します。階層変数の値はすべて読み取り専用です。

v 数式

実行時にユーザーが数値を入力します。数式変数は、クエリー実行時のみ数式構成要素を入力する必要がある場合に使用します。例えば、付加価値税率に数式変数を使用して、実行時点の率を処理できます。

v 承認

承認変数は他の変数と似ていますが、IBM Cognos ソフトウェアがユーザーの資格情報を使用して自動的に変数値を設定します。 SAP BW はこれらの資格情報を、セキュリティーが適用されている SAP BW クエリーに必要な情報を提供するために使用します。

階層の変数は、特性の階層のプレースホルダーとして機能します。階層変数の値はすべて読み取り専用です。

「名前」プロパティー

このプロパティーは文字列値です。

SAP BW の等価変数: VARIABLE_NAME

制限事項: 読み取り専用。

「キャプション」プロパティー

このプロパティーの文字列値は複合であり、ロケールに依存します。値がロケール名のカスタム・プロパティーでモデル内の各ロケールを表します。例えば、モデル内に en-ca と fr-fr というロケールが存在する場合は、en-ca と fr-fr という 2 つのカスタム・プロパティーを定義します。

デフォルト値は SAP BW から取得されます。


「選択タイプ」プロパティー

使用可能な値は、value、interval、complex、multiValued です。

表 9. 「選択タイプ」プロパティーの等価変数

値 SAP BW の等価変数

値SAP_VAR_SEL_TYPE_VALUE

間隔SAP_VAR_SEL_TYPE_INTERVAL

complexSAP_VAR_SEL_TYPE_COMPLEX

multiValuedSAP_VAR_SEL_TYPE_COMPLEX


「エントリー・タイプ」プロパティー


表 10. 「エントリー・タイプ」プロパティーの等価変数

値 SAP BW の等価変数

オプションSAP_VAR_INPUT_TYPE_OPTIONAL

mandatorySAP_VAR_INPUT_TYPE_MANDATORY

mandatoryNotInitialSAP_VAR_INPUT_TYPE_MANDATORY_NOT_INITIAL


「デフォルトの最小値」プロパティーおよび「デフォルトの最大値」プロパティー

これらのプロパティーのそれぞれが、値の範囲を指定します。


制約事項: 「デフォルトの最大値」プロパティーは、「選択タイプ」が間隔の変数に対してのみ適用可能です。

「説明」プロパティー

このプロパティーは文字列値です。

「SAP BW 変数の型」プロパティー

使用可能な値は、numeric、characteristic、hierarchy、または hierarchicalNode です。


デフォルトは SAP BW から取得されます。


「プロンプトのタイプ」プロパティー

デフォルト値は変数の型に依存します。このプロパティーの値が事前定義値の 1 つでない場合、使用される値は hierarchyPickList です。「プロンプトのタイプ」プロパティーの事前定義値は、以下のとおりです。

表 11. 「プロンプトのタイプ」プロパティーの等価変数

値制約事項

typeIn 数値変数の場合は必須、特性値の場合はオプション

pickList 特性変数の場合のオプション

calendar 0CALDAY に基づいた特性変数の場合のみ

hierarchyPickList すべての表示階層の場合のオプション

notApplicable 階層変数の場合は必須

このプロパティーを使用して、プロンプトのタイプを指定します。

選択リストまたは階層選択リストのどちらかを使用する変数プロンプトのパフォーマンスを向上させることができます。「レベル制限」、「選択リスト値の初期数」、および「デフォルト値を使用」プロパティーを使用して、これらのタイプの変数プロンプトのパフォーマンスを制御できます。

選択リスト・プロンプトまたは階層選択リスト・プロンプトを入力プロンプトに変更すると、パフォーマンスが大幅に向上します。アプリケーション・サーバーが選択リストに値を設定する必要がなくなるからです。ただし、ユーザーは特性値を正確に入力できなければなりません。

制約事項: 特性や数式など、いくつかのタイプの変数では読み取り専用です。

「レベル制限」プロパティー

このプロパティーは数値です。

デフォルト値は 1 です。

このプロパティーを使用して、階層選択リストに設定される特性値の数を減らします。値が取得される階層のレベルの数には限度があります。

値がデフォルトのゼロ (0) の場合は、階層のすべてのレベルの特性値が (プロンプトのタイプに適用できれば) 選択リストに設定されます。それ以外の場合、プロパティーは値が取得されるレベルの範囲をコロンで区切って指定します (ルート・レベルはゼロです)。


不規則な階層の場合は、使用する可能性のあるすべてのレベルを (一部の分岐にそのレベルがないとしても) 指定する必要があります。

制約事項: 「プロンプトのタイプ」が hierarchyPickList の階層ノード変数に対してのみ適用可能です。

「デフォルト値を使用」プロパティー

このプロパティーは、デフォルト値を使用するかどうかを決定するためのブール値プロパティーです。このプロパティーが true に設定された場合は、関連する変数のプロンプトがユーザーに対して出されず、常にデフォルト値が適用されます。

このプロパティーは、変数に単一値を設定するために使用します。変数の値を求めるプロンプトがユーザーに出されず、結果として IBM Cognos Analytics サーバーは選択リストに値を設定しません。ただし、ユーザーは変数の値を変更できなくなります。

デフォルト値は false です。

「キーとキャプションの表示」プロパティー

SAP BW 変数のキーとキャプションを表示するには、このプロパティーを true に設定します。このプロパティーは、選択リスト・プロンプトおよび階層ノード・プロンプトに対してのみ適用可能です。

デフォルト値は false です。

「選択リスト値の初期数」プロパティー

このプロパティーは、選択リスト、階層選択リスト、またはプロンプトの設定に使用される値の初期数を指定します。

デフォルト値はゼロ (0)、つまりすべてです。

数値変数のプロパティー値 (SAP BW)数値変数には以下の変数プロパティーを適用できます。

プロパティーデフォルト値

タイプ数値

キャプション

選択タイプ値

項目タイプ SAP BW から取得

デフォルトの最小値

デフォルトの最大値

プロンプトのタイプ typeIn

デフォルト値を使用 false

数値変数のデフォルト値は、読み取り専用である「プロンプトのタイプ」プロパティーのもの以外は変更可能です。


特性変数のプロパティー値 (SAP BW)特性変数には特性値および階層ノードの 2 つの種類があります。特性値の変数は、特性値を取ります。階層ノードの変数は、表示階層内の任意の位置から値を取ります。

特性値変数のプロパティー値特性値変数には以下の変数プロパティーを適用できます。


タイプ特性

キャプション

選択タイプ SAP BW から取得


デフォルトの最小値項目タイプが値または複合である場合、デフォルトのプロパティーが示されます。

項目タイプが間隔である場合、デフォルトの最小プロパティーが示されます。この値はSAP BW から取得されます。

デフォルトの最大値項目タイプが値または複合である場合、デフォルトのプロパティーが示されます。

項目タイプが間隔である場合、デフォルトの最大プロパティーが示されます。この値はSAP BW から取得されます。

プロンプトのタイプ typeIn または pickList

これは参照先ディメンションに含まれるメンバーの数に依存します。

値が無効な場合は、typeIn が使用されます。


キーとキャプションの表示 false

選択リスト値の初期数ゼロ (0)

0CALDAY ディメンションの特性値変数は日付としてモデルに示されます。「データ型」プロパティーは「xsdDate」に設定され、「プロンプトのタイプ」プロパティーは「カレンダー」に設定されます。「プロンプトのタイプ」プロパティーは、0CALDAY ディメンションに対して読み取り専用となります。

階層ノード変数のプロパティー値階層ノード変数には以下の変数プロパティーを適用できます。


タイプ特性

キャプション

選択タイプ SAP BW から取得




デフォルト LowValue

デフォルト HighValue

プロンプトのタイプ階層 PickList

「プロンプトのタイプ」プロパティーをtypeIn または pickList に変更できます。

レベル制限ゼロ (0)


選択リスト・プロンプト (SAP BW)各選択リスト・プロンプトには、事前定義された数の値が含まれています。これらの値は、「値の最大数 (Maximum Number of Values)」プロパティーによって決まります。

実際の値数がデフォルトの値数以下である場合、単一の選択リスト・プロンプトとしてプロンプトが生成されます。実際の値の数がデフォルトの数よりも大きい場合、2 つのプロンプトが次の順序で生成されます。

v 開始値が 1 で終了値が「値の最大数 (Maximum Number of Values)」プロパティーによって決まる、結合範囲パラメーター。

このパラメーターは、タイプが xsdUnsignedLong で、オプションです。パラメーターの名前は、元のプロンプト名の後に _range_prompt を付けたものです。キャプションはロケール固有のものとなります。これが多言語モデルである場合、キャプションのテンプレートをメッセージ・ファイルに保管する必要があります。

v デフォルト数の値を含む選択リスト・プロンプト

ビジネス・ルールの追加 (SAP BW)SAP BW で作成されたビジネス・ルールは、IBM Cognos Framework Managerにインポートされます。モデルにさらにビジネス・ルールを追加して、取得データを絞り込んだり、適切な情報をユーザーが使用できるようにしたりすることができます。

ビジネス・ルールを作成して、レポートではなくモデルの中にそれを保管することには、多くの利点があります。ビジネス・ルールが必要になるたびにユーザーがビジネス・ルールを再作成する必要がないため、時間の節約になります。すべてのユーザーが同じ定義を使用するため、ビジネス・ルールの一貫性が維持されます。例えば、「Low Margin」(薄利) とはどんな意味か、組織全体で同じになります。ビジネス・ルールを一括して保守するため、容易に更新できます。ルールの進化に合わせてすべてのレポートが自動的に更新されます。例えば「Low Margin」の定義が変更された場合、Low Margin 計算を使用するすべてのレポートが自動的に更新されます。ビジネス・ルールはセキュリティーを強化します。


手順1. ユーザーがレポートに計算データを含めることができるように、計算を追加しま

す (『計算の作成 (SAP BW)』)。

2. クエリー・サブジェクトが取得するデータを制限できるように、フィルターを作成して適用します ( 263 ページの『フィルターの作成 (SAP BW)』)。

3. レポートでディメンションまたはクエリー・サブジェクトが使用されるたびに自動的に表示されるプロンプトを追加します。そうすることで、データをフィルターに掛けるプロンプトがレポート利用者に出されるようになります ( 249 ページの『プロンプト・コントロールの定義 (SAP BW)』)。

4. セッション・パラメーター ( 270 ページの『セッション・パラメーターの作成(SAP BW)』) とパラメーター・マップ ( 268 ページの『パラメーター・マップの作成 (SAP BW)』) を使用して、式を動的に解決します。

5. ユーザーがレポートをセットアップするときに表示されるデータを制御するためのセキュリティー・フィルターを作成します ( 284 ページの『データ・セキュリティーの追加』)。

計算の作成 (SAP BW)

疑問符 (?) などの句読文字は、7 ビット ASCII 文字コードでなければなりません。マルチバイト対応のキーボードで句読文字を入力する場合、7 ビット ASCII で表記した文字を入力してください。例えば、疑問符は Alt+063 を入力します。

計算の名前には、式演算子に使用される記号は使用しないでください。式が評価されるときに、構文エラーが生じることがあります。例えば、「Margin * 10」という名前の計算は [Margin * 10]< 20 などの式で使用されるとエラーとなります。

式では、演算子または関数によっては、特定のディメンション・タイプのオペランドが必要とされる場合があります。必要とされるタイプのオペランドではない場合、そのオペランドを適切なタイプに強制変更するために、1 つ以上の強制変更規則が適用されることがあります。モデル・クエリー・サブジェクトでは式に強制変更規則が適用されないので、それらの式が有効であることを強制変更規則には依存しないで確認してください。強制変更規則について詳しくは、「IBM CognosAnalytics - Reporting ユーザー・ガイド」を参照してください。

インポートしたユーザー定義関数を計算に挿入する場合、その関数名がベンダーに固有の名前を繰り返していないことを確認してください。例えば、ユーザー定義関数の名前が CHAR の場合、Microsoft SQL Server の「char」と同一であると見なされるので、その関数を「計算の定義」ダイアログ・ボックスでテストするとエラーを受け取ります。データベースで使用される関数名について詳しくは、そのデータベースの製品資料を参照してください。

クエリーの際に、IBM Cognos Framework Manager は値がゼロの除数を含む計算に対して Null 値を戻します。平均や mod などを求める関数では除算演算子が明示的に示されないために、Framework Manager はゼロ除算のエラーを検出できません。

独立した計算を 1 つ以上のディメンションまたはクエリー・サブジェクトに適用して、計算済みデータをレポートに提供すること、またはユーザーが使用できるよう


にそれをパッケージに含めることができます。独立した計算またはそれに対するショートカットをフォルダーに移動することにより、モデル・オブジェクトの編成を改善できます。

計算の作成手順

手順

1. ネームスペースまたはフォルダーをクリックし、「操作」メニューで「作成」、「計算」の順にクリックします。

2. 「名前」ボックスに、計算の名前を入力します。


目的操作

アイテムを追加する「モデル」タブで、クエリー・アイテム、フィルター、または計算をクリックし、矢印をクリックします。

関数を追加する「関数」タブで、コンポーネントを選択し、矢印をクリックします。

パラメーターを追加する「パラメーター」タブで、パラメーターをクリックし、矢印をクリックします。



この設定によって、ディメンションおよびクエリー・サブジェクトのテスト時のデータ取得パフォーマンスが向上するわけではありません。





4. 計算をテストするには、「テスト」ボタン



テストできるのは、クエリー・アイテムが含まれる計算のみです。計算に関数(例えば _add_days) が含まれる場合、「テスト・サンプル」ボタンは使用できません。


6. 計算が返すデータのタイプを指定するには、「データ型」プロパティーを変更します。

IBM Cognos Studio/Authoring ツールはこの情報を使用して、計算が返すデータの形式を設定します。

フィルターの作成 (SAP BW)

例えば、in_range 関数を使用して、特定の時間枠内に導入された製品のデータを取り出すフィルターを作成できます。この例の構文は、次のようになります。

[gosales_goretailers].[Products].[概要date]in_range {Feb 14, 1999 : July 14, 2007}

注: 日付または時間関数を使用するときは、24 時間クロックを使用する必要があります。 IBM Cognos Framework Manager は、式での「a.m.」や「p.m.」をサポートしません。例えば、午後 8 時を表すために 20:00 を使用します。

セキュリティー・フィルターを作成することにより、プロジェクト内のディメンションまたはクエリー・サブジェクトで表されるデータを制限できます。セキュリティー・フィルターは、ユーザーがレポートをセットアップする際に表示されるデータを制御します。


Framework Manager は、独立したフィルターおよび埋め込みフィルターをサポートします。

v 独立したフィルターは、式を再使用する場合に使用します。

独立したフィルターを 1 つ以上のディメンションまたはクエリー・サブジェクトに追加して、フィルター済みディメンションやクエリー・サブジェクトがレポート内で使用されるときにクエリーが取得するデータを制限すること、またはユーザーが使用できるようにそのデータをパッケージに含めることができます。独立したフィルターまたはそれに対するショートカットをフォルダーに移動することにより、モデル・オブジェクトの編成を改善できます。

v 埋め込みフィルターは、ディメンションまたはクエリー・サブジェクトが 1 つだけ含まれるフィルターを使用する場合に使用します。

埋め込みフィルターは、ディメンション、リレーショナル・データ・ソースのクエリー・サブジェクト、またはモデル・クエリー・サブジェクトを変更する際に作成できます。


埋め込みフィルターから開始する場合、後にそれを他のディメンションまたはクエリー・サブジェクトに適用可能な独立した式に変換できます。ヒント: 「フィルター」タブでフィルター式を右クリックして、「独立したフィルターに変換」をクリックします。

フィルターを埋め込むとき、データ・ソースのクエリー・サブジェクトには、式で参照されるクエリー・サブジェクトに対する関係が存在しなければなりません。この関係は、式が参照するモデル・クエリー・サブジェクトが、式を埋め込むデータ・ソースのクエリー・サブジェクトと同じテーブルに基づいている場合でも必要です。

関係のないクエリー・サブジェクトにフィルターを作成するには、次のいずれかを実行します。

– 新しいクエリー・サブジェクトとフィルターを含むクエリー・サブジェクトとの間に結合パスがあることを確認します。

– 埋め込みフィルターを、必要なデータ・ソース・クエリー・サブジェクトに基づくクエリー・アイテムに基づくものとします。

– 計算を独立したフィルターに変換して、それがクエリー・サブジェクトの一部とならないようにします。

– 埋め込みオブジェクトを参照する独立したフィルターを作成します。


v セキュリティー・フィルター 284 ページの『データ・セキュリティーの追加』

v パラメーター 268 ページの『パラメーター・マップの作成 (SAP BW)』

v セッション・パラメーター 270 ページの『セッション・パラメーターの作成(SAP BW)』


フィルターの作成手順

手順


v 独立したフィルターを作成するには、ネームスペースまたはフォルダーをクリックし、「操作」、「作成」、「フィルター」の順にクリックします。

v 埋め込みフィルターを作成する場合は、フィルターを含めるディメンションまたはクエリー・サブジェクトをダブルクリックし、「フィルター」タブをクリックした後、「追加」をクリックします。

2. 「名前」ボックスに、フィルターの名前を入力します。


ヒント: 無効な式がフィルターに含まれる場合は、式エディターの「ヒント」ボックスで詳細を確認してください。


目的操作

クエリー・アイテムおよびフィルターを追加する

「モデル」タブで、目的のオブジェクトを「式の定義」ボックスにドラッグします。

関数を追加する「関数」タブで、関数を「式の定義」ボックスにドラッグします。

パラメーターを追加する「パラメーター」タブで、パラメーターを「式の定義」ボックスにドラッグします。









タスクの結果

ガバナーを適用することによって、パッケージ内のクエリーが取得するデータを制限することもできます。詳細については、 338 ページの『ガバナー』を参照してください。


v 284 ページの『データ・セキュリティーの追加』

v 175 ページの『パラメーター・マップの作成』


v 103 ページの『クエリー・サブジェクトまたはクエリー・セットのテスト』

v 184 ページの『必須プロンプトとオプション・プロンプト』


フィルターの適用 (SAP BW)

ディメンションまたはクエリー・サブジェクトの中に独立型のフィルターを埋め込むことができますが、埋め込みフィルターごとに個別の使用法が必要な場合は、さまざまなバージョンの独立型フィルターを作成する必要があります。このようにしない場合、「必ず使用すべき」と設定されたインスタンスが存在するなら、オプションだと想定されたプロンプトでユーザーが入力を要求される可能性があります。必須およびオプションのプロンプトについては、 184 ページの『必須プロンプトとオプション・プロンプト』を参照してください。

例えばクエリー・サブジェクト A で独立型のフィルターを埋め込んで、それをオプションとして定義するとします。クエリー・サブジェクト B では、それを必須として定義します。両方のクエリー・サブジェクトを使用するレポートをユーザーが作成した場合、オプションと定義されたものも含めて、両方のフィルターで値を選ぶよう要求されます。同じクエリーの中で使われる場合、フィルターのすべてのインスタンスは必須と見なされます。これを解決するには、それぞれ独自の名前を付けて、さまざまなバージョンのフィルターを作成してください。

フィルターの適用手順

手順

1. フィルターを作成します。

2. フィルターを選択し、「操作」、「定義を編集」の順にクリックします。

3. 「フィルター」タブをクリックし、作成したフィルターを「フィルター」ボックスにドラッグします。

4. フィルターの使用方法値を選択します。


常時この使用方法値は、指定したデータがすべてのレポートからフィルターで除外されるようにする場合に使用します。例えば、保管しているものの報告しないようにする廃止情報が企業にある場合があります。

「常時」は使用方法のデフォルト値です。



デザイン・モードのみサンプル・レポート用にデータの小サブセットを取得します。この使用方法値は、すべてのデータを見る必要はないとき (例えばクエリー・サブジェクトのテスト時) に使用します。

Framework Manager でデザイン・モード・フィルターを適用するには、「テスト時にすべての関連したデザイン・モード・フィルターを適用」オプションを選択します。このオプションは、「テスト設定」タブで選択できます。

ユーザーは、レポートのレイアウトや書式の設計に重点を置いて、作業中にすべてのデータを取得したいわけではないときに、QueryStudio でデザイン・モード・フィルターを必要とする場合があります。 Query Studioでデザイン・モード・フィルターにアクセスするには、限定データを使用してレポートを実行します。

オプションフィルターがオプションであることを指定します。データをフィルターに掛けるプロンプトがユーザーに出されますが、ユーザーはそのプロンプトをブランクのままにしておくことができます。プロンプトがブランクの場合、Framework Manager はフィルターを無視し、ディメンションまたはクエリー・サブジェクトのすべてのデータを取得します。

オプション・プロンプトには ? ? 構文が必要です。

この使用方法値は、フィルターをいつ適用するかをユーザーが制御する場合に使用します。例えば、1 つの国について見たいときもあれば、すべての国のデータを見たいときもあります。国のオプション・フィルターは、次のようになります。

([GeoNamespace].[Countries]

.[CountryName]=

?WhichCountry?)




パラメーター・マップの作成 (SAP BW)

パラメーター・マップは、データ・ソースの参照テーブルと似ています。各パラメーター・マップには、キーのために 1 つと、キーが表す値のために 1 つの、2 つの列があります。キーと値は、手動で入力すること、ファイルからインポートすること、またはモデル内の既存のクエリー・アイテムに基づくものとすることができます。

パラメーター・マップをファイルにエクスポートすることもできます。パラメーター・マップを変更するには、マップ値をファイルにエクスポートし、追加や変更を行ってから、IBM Cognos Framework Manager にインポートして戻します。この方法は、大型で複雑なパラメーター・マップを扱う際に特に役立ちます。

すべてのパラメーター・マップのキーは、Framework Manager が正しい値を一貫して取得できるように、固有でなければなりません。パラメーター値を引用符で囲まないでください。パラメーターを使用する式の中では引用符を使用できます。

パラメーターの値を別のパラメーターにすることもできます。ただし、値全体を番号記号 (#) で囲む必要があります。パラメーターを値としてネストする際の制限は5 レベルです。

パラメーター・マップを関数への引数として使用するときは、ドル記号 ($) の代わりにパーセント記号 (%) を使用する必要があります。

別名は、名前の一部としてパラメーター・マップを使用するクエリー・アイテムに、そして複数言語による名前を「言語」タブ (「プロパティー」ウィンドウ) 内のオブジェクトに追加するために割り当てます。

注: SAP BW メタデータを使用する場合、クエリー・アイテムを使用してパラメーター・マップのキーおよび値を生成することはできません。

パラメーター・マップの手動作成手順

手順



3. 「パラメーター・キーを手動で入力するか、ファイルからインポートする」をクリックし、「次へ」をクリックします。


v 手動で値を入力するには、「新規キー」をクリックし、キーを入力した後、Tab を押してそのキーの値を入力します。

v キーと値をインポートするには、「ファイルをインポート」をクリックし、該当する .csv ファイルまたは .txt ファイルの場所を指定します。 .txt ファイルをインポートに使用するためには、値がタブで区切られていなければならず、ファイルが UTF8 形式または Unicode 形式で保存されていなければなりません。ANSI テキスト・ファイルはサポートされていません。


注: データ・ソース・クエリー・サブジェクトでパラメーターを使用する場合、値には英語固有の句読点を使用しなければなりません。つまり、小数部を表すにはピリオド (.) を、値のリストを区切るにはコンマ (,) を、それぞれ使用する必要があることになります。


目的操作

デフォルト値を割り当てる「デフォルト値」ボックスに、値を入力します。



オンデマンドでロードするキーを多数含んだパラメーター・マップは、レポート実行時のロードが遅い場合があります。「オンデマンドでロード」を true に設定することにより、ロードを特定のレポートに必要なキーのみに制限することができます。

デフォルトでは、値は false に設定されているので、すべてのキーがロードされます。

パラメーターを削除する行を選択し、「削除」をクリックします。

パラメーターを変更する変更する行を選択し、「編集」ボタンをクリックして、値を入力します。

キーと値をすべて消去する「マップをクリア」をクリックします。


デフォルト値とパラメーター・マップ「デフォルトの最小値」および「デフォルトの最大値」プロパティーには、パラメーター・マップを使用する式を含めることができます。パラメーター・マップを使用して、ユーザーのロケールに基づくターゲット通貨変数の値を定義できます。例えば、ISO 通貨コードを提供するパラメーター・マップを定義します。「デフォルトの最小値」プロパティーの値は、次のように定義できます。

#$Currency_Map[runLocale}#

このパラメーター・マップは、SAP BW 変数の Target Currency がレポートで使用されるときに使用されます。

パラメーター・マップを使用できる SAP BW 変数に関連したプロパティーはこれらだけです。


セッション・パラメーターの作成 (SAP BW)

例えば、ユーザー ID および優先言語は共にセッション・パラメーターです。セッション・パラメーターはキーと値の組なので、各セッション・パラメーターをセッション・パラメーターという名前のパラメーター・マップの項目と見なすことができます。セッション・パラメーターはパラメーター・マップの項目と同じ方法で使用しますが、セッション・パラメーターの構文は少し異なっています。

環境とモデルの、2 つのタイプのセッション・パラメーターがあります。

環境セッション・パラメーターは事前定義されて、Content Manager に保管されています。デフォルトで、以下のセッション・パラメーターが Framework Managerに表示されます。

v runLocale

Framework Manager での現在のアクティブ言語のコードを返します。モデルのコンテンツはこの言語で示されます。

現行セッション内についてのみ、アクティブ言語をいつでも変更できます。その後のセッションでは、モデルは引き続き設計言語で開かれます。詳細については、 142 ページの『プロジェクトへの言語の追加』を参照してください。

v account.defaultName

認証プロバイダーに定義された現在のユーザーの名前を指定します。例えば、ユーザーの姓名などです。

匿名でログオンした場合、Anonymous が表示されます。

v account.personalInfo.userName

IBM Cognos Analytics へのログオンに使用するユーザー ID を指定します。

匿名でログオンした場合、このパラメーターは表示されません。

v current_timestamp

現在の日時を指定します。

v machine

Framework Manager がインストールされるコンピューターの名前を指定します。

認証ソースが他のパラメーターをサポートし、それらに関する情報を認証ソースに入力した場合は、account.personalInfo.email や account.personalInfo.surname など、別のセッション・パラメーターが表示されます。

モデル・セッション・パラメーターを使用して、追加のパラメーターを定義できます。モデル・セッション・パラメーターは、_env という名のパラメーター・マップに保管されています。それらはプロジェクト内に設定されていて、パッケージによって発行できます。


モデル・セッション・パラメーターの値は、Framework Manager モデル内のオブジェクトの範囲内に設定されていなければなりません。その範囲には、既存の環境セッション・パラメーターや静的値の使用も含まれます。

各セッション・パラメーターには、名前とデフォルト値とが必要です。値が返す結果をテストするために、オーバーライド値を定義できます。オーバーライド値は、モデルがオープンされている間だけ有効で、モデルを保存するときには保存されません。オーバーライド値が存在しない場合、Framework Manager はセッション・パラメーターを含むクエリーを実行するときにデフォルト値を使用します。

パラメーターの使用を制御する規則には、以下のものがあります。

v 可能なすべての戻り値は同じデータ型でなければなりません。

v 定義できるのは 1 つの値だけです。

セッション・パラメーターの作成手順

手順

1. 「プロジェクト」、「セッション・パラメーター」の順にクリックします。

2. 「新規キー」をクリックし、セッション・パラメーターのキーと値を入力します。

3. オーバーライド値の扱いを選択します。

v プロジェクトを編集するたびにオーバーライド値を設定しなければならないのを避けるには、セッション・パラメーターを値として設定します。

v プロジェクト設定を発行するたびに事前に削除しなければならないのを避けるには、セッション・パラメーターをセッション・オーバーライドとして設定します。


目的操作

パラメーター値を変更する変更する値が含まれる行をクリックし、「編集」をクリックして、値を入力します。

デフォルト値を割り当てる「デフォルト値」ボックスに値を入力します。キーの値が無効の場合、FrameworkManager はデフォルト値を使用します。

パラメーターを削除する行をクリックし、「削除」ボタンをクリックします。環境セッション・パラメーターを削除することはできません。

オーバーライド値をクリアする行をクリックし、「オーバーライドをクリア」をクリックします。


モデルの編成 (SAP BW)

以下のようにして、モデル内に複数のビューまたはレイヤーを作成することをお勧めします。



IBM Cognos Framework Manager では、これはインポート・ビューと呼ばれます。

v クエリー・サブジェクトまたはディメンション・オブジェクトを使用したクエリーの実行に影響する複雑さを解決するために、オプションのネームスペースかフォルダーを 1 つ以上作成する。

IBM Cognos Analysis Studio または任意の OLAP スタイルのクエリーを使用するためには、ディメンション・オブジェクトのあるメタデータを表すモデル内にネームスペースかフォルダーが必要です。


Framework Manager では、これらはビジネス・ビューと呼ばれます。ビジネスの概念を使用して、ビジネス・ビューのモデルを作成します。それぞれ異なるユーザー・グループに適した多数のビジネス・ビューを 1 つのモデルに含めることができます。それらのビジネス・ビューを発行します。

どのビューにもセキュリティーを定義することが可能です。これは実際のビジネス要件に依存します。例えば、誰でもオブジェクトを参照できる状態を避ける必要があれば、インポート・ビュー内のオブジェクトにセキュリティーを追加します。通常、ビジネス・ビューにはセキュリティーが適用されます。

ショートカットを使用して、またはネームスペースやフォルダーを作成して、メタデータを複数のフォルダーに含めることにより、モデルを編成できます。

ショートカット (SAP BW)

例えば、Orders、Products、および Customers というフォルダーを作成するとします。Orders と Customers の両方に同じディメンションを含める場合は、そのディメンションへのショートカットを作成し、両方のフォルダーに追加する必要があります。

注: ネームスペースまたはフォルダーへの 2 つのショートカットが、モデル内で同じ名前であってはなりません。他のタイプのショートカット (例えばクエリー・サブジェクトのショートカット) の場合、名前は親ネームスペース内で固有でなければなりません。

ショートカットの作成時、IBM Cognos Framework Manager は「画面のヒント」プロパティーと「説明」プロパティーを設定しません。これらのプロパティーを定義しない限り、IBM Cognos Studio/Authoring ツールで表示される値は、ショートカットが参照するオブジェクトで定義された値と同じになります。

ヒント: ショートカットが参照するオブジェクトに移動するには、ショートカットを右クリックし、「ターゲットに移動」をクリックします。






ショートカットとディメンション

ショートカットを使用すると、維持するディメンションが少なくなります。インポート・ビューでディメンションを保持し、ビジネス・ビューでショートカットを保持できます。

ディメンションへのショートカットを作成する場合は、ショートカットに含めるクエリー・アイテムをカスタマイズすることはできません。ディメンション全体がショートカットに含められます。

オブジェクトに対して指定したセキュリティーは、その保護オブジェクトを参照するショートカットに渡されます。保護オブジェクトへのショートカットがある場合は、保護オブジェクトを表示する権限のあるユーザーのみが、発行済みパッケージ内のショートカットを表示できます。

ショートカットを作成するクエリー・サブジェクト、ディメンション、またはフォルダーを右クリックして、「作成」、「ショートカット」をクリックします。

フォルダーまたはネームスペースの作成 (SAP BW)フォルダーまたはネームスペースを作成して、モデル内のオブジェクトを編成できます。






ヒント: 「ダイアグラム」タブでメタデータを表示するとき、フォルダーやネームスペースを展開または省略することができます。「ダイアグラム」メニューで、「すべて省略」または「すべて展開」をクリックします。

フォルダーにセキュリティーを設定した後にオブジェクトをフォルダーに移動する場合、除外が適切に設定されていることを確認してください。

SAP BW メタデータでは、ネームスペースへのショートカットはサポートされていません。

フォルダーの作成手順

手順

1. 「操作」、「作成」、「フォルダー」の順にクリックします。

2. 「フォルダー名」ボックスに、新しいフォルダーの名前を入力します。


4. オブジェクトを移動するかショートカットを作成するかを選択します。

v 選択したオブジェクトをフォルダーに移動するには、「選択したアイテムを新規フォルダーに移動 (Move the selected items to the new folder)」をクリックします。関係に関与するオブジェクトを移動すると、そのオブジェクトへの関係も移動します。

v 選択したオブジェクトを参照するショートカットを作成するには、「選択したアイテムのショートカットを作成 (Create a shortcut for the selecteditems)」をクリックします。発行されるパッケージに再帰的構造が作成されるのを避けるために、ネームスペース内のすべてのオブジェクトは選択しないでください。

5. フォルダーに追加するオブジェクトを選択します。


ネームスペースの作成手順

手順

1. 「操作」、「作成」、「ネームスペース」の順にクリックします。


2. ネームスペースを右クリックし、「名前を変更」をクリックして、ネームスペースに一意の記述名を付けます。

3. メタデータをインポートするか、モデル・オブジェクトまたはオブジェクトへのショートカットをネームスペースに移動することによって、オブジェクトを追加します。


第 7 章パッケージの発行

パッケージを発行して、ユーザーがメタデータを使用できるようにします。使用するユーザー・グループに基づいてパッケージを作成します。パッケージには、特定のユーザーまたはユーザー・グループがレポート作成に必要とするすべての情報が含まれていなければなりません。

パッケージを発行する際には、以下のタスクが関係します。

v モデルを検査して、問題があれば修復する。

v モデルを分析して、メタデータを発行する前に検討の必要な、潜在的なモデル作成上の問題がないかを調べる。

v セキュリティーを設定して、IBM Cognos 製品全体でのメタデータおよびデータに対するアクセスを制限する。

v 各パッケージと共に発行される言語を指定する。

v パッケージを作成または変更する。

v パッケージ・ユーザーが使用可能な消去オプションを指定する。

v パッケージを発行する。

v パッケージを検査して、問題があれば修復する。

パッケージを発行するとき、クエリー・サブジェクトやディメンションを外部化して、IBM Cognos Transformer や他のアプリケーションで使用できる形式に変換するというオプションがあります。

注: クエリーの外部化は、Transformer の将来のリリースではサポートされなくなります。

モデルまたはパッケージの検証モデル作成プロセスのどの時点でも、モデル全体またはモデル内の選択したオブジェクト (例えばパッケージ) の妥当性を検査できます。まず、モデルを検証し、問題をすべて修復した後、モデル内の各パッケージを個別に検証します。パッケージを検証することによって、クエリーが失敗する原因になる可能性のある無効オブジェクトを検出して除去することができます。

モデルまたはパッケージの検証時、IBM Cognos Framework Manager は以下のカテゴリーについてメッセージを出します。

カテゴリー説明

内部モデル不整合オブジェクトが適切に定義されていること、および重複名が使用されていないことを検証します。このテスト・グループは必ず実行してください。

無効または不完全なオブジェクト参照ダングリング参照または欠落オブジェクト参照を検査します。


カテゴリー説明

行列式の完全性キーと属性を使用して行列式が完全に定義されていること、およびすべてのクエリー・アイテムが行列式に存在することを検証します。

ディメンションの完全性レベル・メンバーのキャプションとビジネス・キーを使用してディメンションが完全に定義されていることを検証します。

クエリーのステータスクエリー・サブジェクトとディメンションの評価ステータスが有効であり、「再評価が必要」または「無効」に設定されていないことを検証します。

クエリーのステータスでは、ショートカット・オブジェクトは検証されません。例えば、あるオブジェクトへのショートカットを作成したとします。そのオブジェクトは何らかの理由で無効になりました。オブジェクトを検証すると、オブジェクトは無効であるためにメッセージが表示されます。ショートカットを検証しても、メッセージは表示されません。

後方互換性維持されているものの将来のリリースでは非推奨になる旧リリースの機能がモデルに含まれていることを通知します。

関係のカーディナリティーの検証多対多の関係が検出されると警告します。

どのカテゴリーも、1 つのオブジェクトに関して複数のメッセージが出されることがあります。メッセージごとに、重大度、オブジェクト・アイコン、オブジェクトID、メッセージの記述、問題の修正方法の説明、オブジェクトに対して実行可能な操作が示されます。問題の原因となったオブジェクトを変更するか、FrameworkManager に問題を修復させることにより、問題を直ちに修正できる場合があります。

手順1. 次のいずれかを選択します。

目的操作

モデルを検証する「プロジェクト」メニューの「モデル検証」をクリックします。

パッケージを検証する「プロジェクト・ビューアー」で、パッケージを右クリックして、「選択したオブジェクトを検証」をクリックします。

選択したオブジェクトを検証する「プロジェクト・ビューアー」で、オブジェクトを 1 つ以上選択して右クリックし、「選択したオブジェクトを検証」をクリックします。


2. 「オプション」タブで、結果に表示するメッセージ重大度レベルを選択します。

デフォルトでは、メッセージ重大度レベルのすべてのチェック・ボックスが選択されています。目的に合わないものはクリアしてください。

3. 検証するカテゴリーを選択します。

デフォルトでは、カテゴリーのすべてのチェック・ボックスが選択されています。目的に合わないものはクリアしてください。

4. 「モデル検証」をクリックします。

「モデル検証の結果」タブに結果が表示されます。

5. メッセージをソートするには、重大度、オブジェクト・タイプ、または名前の列見出しで「ソート」をクリックします。

6. メッセージに関連するオブジェクトを表示するには、「操作」見出しの下の「プロジェクト・ビューアーで検索 (Find in Project Viewer)」をクリックします。

7. グループの問題を修復するには、リストからグループ化基準を選択します。

8. 修復する問題の各メッセージの横にあるチェック・ボックスを選択します。

ヒント:

v メッセージをすべて選択するには、チェック・ボックス列の最上部のチェック・ボックスを選択します。選択したメッセージをすべてクリアするには、チェック・ボックス列の最上部のチェック・ボックスをクリアします。

v メッセージをグループ化した場合、グループ内のすべてのメッセージを選択するには、グループ・チェック・ボックス列の最上部のチェック・ボックスを選択します。

v メッセージ詳細情報を非表示するには、グループ見出しで「省略」をクリックします。

9. 「選択済みを修復 (Repair Selected)」をクリックします。

Framework Manager は、次の順序で問題を修復します。

v 無効な参照

v 無効なオブジェクト、無効な関係、無効な集計規則、欠落しているロケール、サポートされないプロンプト・タイプ、推測された役割、再評価 (これらは特に順序なし)

v アップグレードされたモデルのエラー

メッセージの「操作」見出しの下の「定義を編集」アイコンをクリックすることによって、問題を修復することもできます。ダイアログ・ボックスで、必要に応じてオブジェクトの定義を変更します。

タスクの結果

修復プロセスが完了すると、修復結果の概要が表示されます。モデルまたはパッケージが再度検証され、結果が「モデル検証の結果」タブに表示されます。

ヒント: パッケージの検証時に修復できない問題は、モデル検証を使用して修復できる場合があります。

第 7 章パッケージの発行 279

独立したフィルターの場合、基礎となるオブジェクトが無効の可能性があるときは、「再評価が必要」というメッセージが表示されます。修復オプションは独立したフィルターには機能しません。独立したフィルターが有効になるようにするには、各フィルターを開いて保存します。

パッケージの作成または変更パッケージを作成して、ユーザーがメタデータを使用できるようにします。パッケージは、プロジェクトのサブセットです。パッケージには、特定のユーザーまたはユーザー・グループがレポート作成に必要なすべての情報が含まれていなければなりません。セキュリティーをパッケージに適用することもできます。

例えば、ある業務の異なるさまざまな領域からの情報を含むデータ・ソースがある場合に、人事と財務に分けてそれぞれ別のパッケージを作成するという決定が行われます。パッケージが広範囲に及ぶ (ただし関連した) レポート作成の必要を満たすようにしてください。各レポートには、単一パッケージからの情報のみを含めることができます。

パッケージを作成または変更する際、以下の情報を検討してください。

v パッケージの再利用

ネストされたパッケージを作成することにより、パッケージを再利用することができます。ネストされたパッケージを作成する際、他の既存のパッケージに基づくマスター・パッケージを作成します。ネストされたパッケージを使用すると時間の節約になり、保守がより簡単になります。ネストされたパッケージを使用する別の利点は、マスター・パッケージだけを発行するという点です。

例えば、カナダ、メキシコ、米国という名前の 3 つの別個のパッケージを作成します。各パッケージには、パッケージに適したプロジェクト・オブジェクトおよびセキュリティーが含まれています。北アメリカというマスター・パッケージを 1 つ作成し、カナダ、メキシコ、米国の各パッケージを含めることができます。

パッケージを再利用して、複数のデータ・ソースへの接続を持つ集約パッケージを作成することもできます。

v オブジェクトの選択、非表示、または選択解除

パッケージを作成する際、ユーザーの要件に基づいてプロジェクトのオブジェクトを選択できるかどうかを選択することができます。


選択レポートでオブジェクトを使用することができ、ユーザーはオブジェクトを選択することができます。



非表示ユーザーはオブジェクト内のデータを選択できないため、そのデータは使用することができません。

例えば、モデル・クエリー・サブジェクトをパッケージに組み込みます。モデル・クエリー・サブジェクトはデータ・ソース・クエリー・サブジェクトに依存するため ( 84 ページの『クエリー・サブジェクト』)、データ・ソース・クエリー・サブジェクトをパッケージに追加する必要があります。ユーザーにデータ・ソース・クエリー・サブジェクトを表示しない場合はそれを非表示にします。

選択解除オブジェクトは発行されません。レポートで使用できず、ユーザーは選択できません。

注: IBM Cognos Framework Manager では、Ctrl+shift と Alt+shift 機能がサポートされています。含めるオブジェクトまたは非表示にするオブジェクトを複数選択する場合は、これらのキー操作を使用します。例えば、大きな枝内にある2 つのアイテムのみを含める場合は、まず枝全体を選択します。次に、Ctrl キーを押しながら Shift キーをクリックし、含めるアイテムを選択解除して、残りの選択アイテムを非表示にします。

v モデル・クエリー・サブジェクトのパッケージへの組み込み

モデル・クエリー・サブジェクトがマクロまたはプロンプトで他のクエリー・サブジェクトを参照する場合、参照されるクエリー・サブジェクトを必ずパッケージに組み込みます。

これは以下の状況で発生します。

– モデル・クエリー・サブジェクトのマクロが別のクエリー・サブジェクトのクエリー・アイテムを参照する場合。

– 「プロンプト情報」プロパティーで別のクエリー・サブジェクトが参照される場合。

パッケージがサーバーに発行された後、ユーザーが使用できるようになります。

パッケージの作成

手順1. 「パッケージ」フォルダーをクリックし、「操作」メニューで「作成」、「パッ

ケージ」の順にクリックします。

2. 「Provide Name」ページで、パッケージの名前を入力し、必要に応じて説明と画面のヒントを入力します。「次へ」をクリックします。

3. 既存パッケージからのオブジェクトを組み込むのか、それともプロジェクトからのオブジェクトを組み込むのかを指定し、組み込むオブジェクトを指定します。


他のパッケージを作成している場合は、「既存のパッケージを使用」をクリックしてパッケージの参照を追加することをお勧めします。

4. パッケージのデフォルトのアクセス権を使用するかどうかを選択します。

v デフォルトのアクセス権を使用する場合は、「終了」をクリックします。

v アクセス権を設定するには、「次へ」をクリックします。

5. 誰がパッケージにアクセスできるのかを指定し、「次へ」をクリックします。

ユーザー、グループ、またはロールを追加することができます。

6. パッケージに組み込む言語を「選択した言語」ボックスに移動し、「次へ」をクリックします。

7. パッケージ内で使用可能にするデータ・ソース関数の集合を「選択した関数セット」ボックスに移動します。

データ・ソース・ベンダー用の関数セットが選択可能でない場合、それがプロジェクトに追加済みであることを確認してください。詳細については、 350 ページの『関数セットの選択』を参照してください。

8. 「終了」をクリックし、パッケージを発行するかどうかを選択します。

パッケージの変更

手順1. 変更するパッケージをクリックします。


3. パッケージに追加するオブジェクトまたはパッケージから削除するオブジェクトをクリックします。

ヒント: オブジェクトのオプションを使って切り替えを行うには、オブジェクト・アイコンをクリックするか、リストからオプションを選択します。


5. 変更するパッケージに参照を追加するか、パッケージから参照を削除する場合は、「編集」をクリックします。

セキュリティーIBM Cognos Framework Manager では、セキュリティーは IBM Cognos 製品上のメタデータおよびデータへのアクセスを制限するための手段です。

Framework Manager には、次のように異なるタイプのセキュリティーがあります。

v データ・セキュリティー

セキュリティー・フィルターを作成し、特定のクエリー・サブジェクトに適用します。フィルターは、ユーザーがレポートをセットアップするときに表示されるデータを制御します。

v オブジェクト・セキュリティー


オブジェクトへのユーザー・アクセスを許可する、オブジェクトへのユーザー・アクセスを拒否する、またはオブジェクトを全ユーザーから隠蔽しておくことにより、オブジェクトを直接保護します。

v パッケージ・セキュリティー

パッケージにセキュリティーを適用し、そのパッケージへのアクセス権を持つユーザーを特定します。

どのタイプのセキュリティーでも、ユーザー、グループ、および役割を使用してアクセス権を定義します。

データへのアクセスを制限するのは、ビジネス上の理由があります。例えば、特定のユーザーのみが閲覧を許可されている機密データがある場合があります。多種多様なデータがあっても、ユーザーは特定のテーブルまた列のデータを取り出すだけでよい場合もあります。あるいは、テーブルにレコードが多数含まれていても、ユーザーはそのテーブルのレコードのサブセットを取り出すだけでよい場合もあります。

SAP BW メタデータを使用する場合は、レベル・メンバーへのユーザーのアクセスに影響を与える基礎 SAP BW セキュリティーが存在することがあります。Framework Manager で SAP BW セキュリティーをオーバーライドすることはできません。詳細については、 215 ページの『SAP BW データ・ソースからのインポート』を参照してください。

Framework Manager でセキュリティーを追加する前に、IBM Cognos Analyticsにセキュリティーが正しくセットアップされていることを確認してください。詳細については、「管理およびセキュリティー・ガイド」を参照してください。

ユーザー、グループ、および役割ユーザーおよびグループは、認証と承認を目的として作成されます。 IBM CognosAnalytics で独自のユーザーとグループを作成できます。または、他の認証プロバイダーで作成されたユーザーとグループを使用することもできます。

セキュリティー、ユーザー、グループ、および役割について詳しくは、「管理およびセキュリティー・ガイド」を参照してください。

ユーザー数

ユーザー・エントリーは、ユーザーやコンピューター・アカウントを一意に識別するために、認証プロバイダーによって作成、管理されます。IBM Cognos Analyticsではユーザーを作成できません。

ユーザーについての情報 (姓名、パスワード、ID、ロケール、E メール・アドレスなど) は、プロバイダーで保管されます。

ユーザーは、認証プロバイダーで定義されたグループや IBM Cognos Analytics で定義されたグループのメンバーになれます。1 人のユーザーが 1 つ以上のグループに所属することもできます。ユーザーが複数のグループのメンバーである場合、そのアクセス権は結合されます。


グループと役割

グループの例には、従業員、開発者、営業部員などがあります。グループのメンバーには、ユーザーや他のグループを含めることができます。グループ・メンバーシップは、そのユーザーを識別する基本情報の 1 つです。ログオンしたユーザーが、セッションで使用するグループを選択することはできません。ユーザーがログオンすると、所属するグループに設定されたすべての権限が付与されます。

役割は、特殊なグループです。これは、組織の中で類似する責任と類似する権限を持つユーザーから成る集合を表します。役割のメンバーには、ユーザー、グループ、他の役割を含めることができます。役割のメンバーシップは、そのユーザーを識別する基本情報には含まれません。

認証プロバイダーで組織によって作成されたグループを使用できます。またはCognos ネームスペースで新しいグループを作成することもできます。

以下のような場合に IBM Cognos グループを作成します。

v 認証プロバイダーでグループを作成できない場合。

v 複数のネームスペースにまたがるグループが必要な場合。

v 配布可能な、移植性が高いグループが必要な場合。

v IBM Cognos 管理上の特定のニーズを満たす必要がある場合。

v IBM Cognos Analytics ソフトウェアでのみ使われる情報によって組織のセキュリティー・システムが混乱することを防ぎたい場合。

データ・セキュリティーの追加セキュリティー・フィルターを作成することにより、プロジェクト内のクエリー・サブジェクトによって表されるデータを制限できます。セキュリティー・フィルターは、ユーザーがレポートをセットアップするときに表示されるデータを制御します。

例えば、販売チームが販売担当重役 1 人と販売責任者 4 人で構成されているとします。販売担当重役のグループと販売責任者のグループが含まれるセキュリティー・フィルターを作成し、そのフィルターを給与クエリー・サブジェクトに適用します。ユーザーがパッケージを使用できるようになり、販売責任者および販売担当重役向けのレポートが生成されると、販売責任者の給与情報を見ることができるのは、販売担当重役だけです。グループの詳細については、 283 ページの『ユーザー、グループ、および役割』を参照してください。

ユーザーが複数の役割を持っている場合、それらの役割に属するセキュリティー・フィルターは OR で結合されます。役割が別の役割に基づいている場合、セキュリティー・フィルターは AND で結合されます。

既存のセキュリティー・フィルターをセキュリティー・フィルターのベースにすることができます。このオプションを選択した場合、セキュリティー・フィルターはフィルターとすべてのフィルター・プロパティーを継承します。


セキュリティー・フィルターを作成するときは、既存のプロジェクト・フィルターを使用したり、式エディターを使用して新規フィルターを作成したりすることもできます。詳細については、 169 ページの『フィルターの作成』を参照してください。

手順1. 必要なクエリー・サブジェクトをクリックします。

2. 「操作」、「データ・セキュリティーを指定」の順にクリックします。

3. 新しいユーザー、グループ、または役割を追加するには、以下のようにします。

v 「グループを追加」をクリックします。

v 「ユーザーとグループを選択」ウィンドウで、ユーザー、グループ、または役割を追加します。この方法については、「管理およびセキュリティー・ガイド」を参照してください。

v 「ユーザーとグループを選択」ウィンドウで、「OK」をクリックします。

4. 既存のグループをグループのベースにする場合は、「基準」列でグループをクリックします。

ヒント: 目的のグループがリストに表示されない場合は、グループをセキュリティー・フィルターに追加する必要があります。

5. グループにフィルターを追加する場合は、「フィルター」列で、「埋め込みフィルターを作成/編集 (Create/Edit Embedded Filter)」かまたは「モデルから挿入」をクリックします。

CSVIdentityName マクロ関数データ・ソースに格納された UserClass 値に基づいた行レベル・セキュリティーが必要な場合は、ログオンしているユーザーに基づいてデータ・ソースの値を対応する役割およびグループにマップするパラメーター・マップを実装します。

この実装を行うには、CSVIdentityName マクロ関数でパラメーター・マップを引数として使用します。このマクロ関数は、現行ユーザーのアカウント、グループ、および役割に関する情報を取得します。パラメーター・マップから、'clerks'、'technicians'、または 'typists' などの一重引用符で囲まれたコンマ区切り値の文字列を返します。

CSVIdentityName マクロ関数は、指定マップのキーとして使用されます。返されたリストを使用して、部分 In 節を構築したり、現行ユーザーの ID 名に基づいてデータをフィルターに掛けたりすることができます。

例えば、名前が Roles_Groups パラメーター・マップに対応しない次のようなユーザー・クラスがあるとします。

キー (役割またはグループ) 値 (ユーザー・クラス)

すべてのユーザー Group1

作成者 Group2

システム管理者 Group3

クエリー・ユーザー Group2

NTLM Group2


次のクエリー・サブジェクトがあります。

(Security_column, value 1, value 2, value 3)

このクエリー・サブジェクトにフィルターを追加すると、フィルターはマクロを使用して値のリストを検索します。次に例を示します。

Security_column in (#CSVIdentityName(%Roles_Groups)#)

「すべてのユーザー」、「作成者」、および「システム管理者」役割のユーザーの場合、条件ではこれは次のようになります。

Security_column in ('Group1','Group2','Group3')

CSVIdentityNameList マクロ関数データ・ソース内のセキュリティー・データが IBM Cognos Analytics で定義された役割およびグループと等しい場合は、CSVIdentityNameList マクロ関数を使用できます。このマクロ関数は、オプションとしてリスト・セパレーターをパラメーターで受け取った後、フィルターの In 演算子で使用できるセパレーター区切りリストを返します。パラメーター・マップは必要ありません。


Security_column in (#CSVIdentityNameList()#)

「すべてのユーザー」、「作成者」、および「システム管理者」役割のユーザーの場合、条件ではこれは次のようになります。

Security_column in ('Everyone','Authors','SystemAdministrators')

次の点に注意してください。

v ユーザーはいくつかのグループまたは役割に属することができます。

v グループと役割を区別することができないため、グループと役割はそれぞれ一意の名前でなければなりません。

v この関数はフィルターでのみ機能し、常に 0..n 個の値を返します。

オブジェクト・セキュリティープロジェクト内のオブジェクトに、メタデータのセキュリティーを直接適用することができます。

オブジェクトに基づくセキュリティーを設定しない場合、パッケージへのアクセス権限を持つすべてのユーザーに対してプロジェクト内の全オブジェクトが表示されます。あるオブジェクトに関する許可/拒否が設定されていないユーザー、グループ、および役割は、未定義と見なされます。そのオブジェクトは、親オブジェクトで定義されたセキュリティーを継承します。オブジェクトへのアクセスを明示的に許可または拒否すると、継承された設定はオーバーライドされます。そのため、親オブジェクトと子オブジェクトの設定が異なるようになります。親オブジェクトにセキュリティーを適用すると、モデル内のすべての子オブジェクトにもセキュリティーが適用されます。 1 つのオブジェクトのセキュリティーを設定した後、すべてのオブジェクトに対してそれを設定する必要があります。それを行うには、ルート・ネームスペースでセキュリティーを設定することができます。


選択されたユーザー、グループ、または役割に対してのみ、オブジェクトを表示する必要が生じることがあります。例えば、プロジェクトの中に「Salary」(給与) クエリー・サブジェクトがあるとします。 Managers (管理職) グループに対してSalary クエリー・サブジェクトを表示し、他のユーザーには非表示にすることができます。

あるユーザーが複数のユーザー・グループのメンバーであり、そのうち 1 つのユーザー・グループで表示されるオブジェクトが他のユーザー・グループで拒否される場合には、そのユーザーはそのオブジェクトにアクセスできません。例えば Janeが Sales (セールス) および Marketing (マーケティング) の 2 つのユーザー・グループに属しているとします。 Sales グループは Products (製品) および Sales クエリー・サブジェクトにアクセスできる反面、Sales Forecast (販売予測) クエリー・サブジェクトへのアクセスは拒否されるとします。 Marketing グループはProducts、Sales、および Sales Forecast クエリー・サブジェクトにすべてアクセスできるとします。 Jane は Sales Forecast にアクセスできません。

オブジェクトをセキュリティーで保護すると、IBM Cognos Framework Managerでパッケージが自動的に作成されます。パッケージ名は、アンダースコアー (_) および保護されたオブジェクトの名前から成ります。このようなオブジェクトに基づくパッケージは、「エクスプローラー」に表示されます。このパッケージを使用すると、プロジェクト内のどのオブジェクトが含まれるか、非表示になるか、特定のユーザー・グループから除外されるかを確認できます。

パッケージにオブジェクトを組み込んでユーザーに発行するたびに、同じセキュリティー規則がそのオブジェクトにも適用されます。保護されたオブジェクトを含むパッケージを発行した場合、パッケージ定義とオブジェクト・セキュリティー設定の交差 (共通) 部分となるオブジェクトがユーザーに表示されます。オブジェクトに基づくセキュリティーを使用しない場合、パッケージに適用されるセキュリティーは変わりません。

オブジェクト・セキュリティーの範囲

オブジェクトに対して指定したセキュリティーは、その保護オブジェクトを参照するショートカットに渡されます。保護されたオブジェクトへのショートカットがある場合、保護されたオブジェクトを表示する権限を持つユーザーだけが、発行済みパッケージ内のショートカットを表示できます。

保護されたオブジェクトがモデル・クエリー・サブジェクト、計算、またはフィルターで参照される場合、オブジェクトのセキュリティーはモデル・クエリー・サブジェクト、計算、フィルターには渡されません。

ショートカットを含むパッケージを作成する場合、保護されたオブジェクトをパッケージに組み込む必要はありません。

例えば、セールス・マネージャーだけが Sales Target (セールス・ターゲット) クエリー・サブジェクトを表示できるとします。ここで Sales Target へのショートカットを作成します。モデルをパッケージ化するときに、ショートカットを含めますが、Sales Target クエリー・サブジェクトは含めません。発行済みパッケージでショートカットを表示できるユーザーは、セールス・マネージャーだけです。


モデルがセグメント化される場合、マスター・モデルからオブジェクト・セキュリティーが継承されません。すべてのモデル・セグメントでオブジェクト・セキュリティーを定義する必要があります。

オブジェクト・ベースのセキュリティーの追加オブジェクト・ベースのセキュリティーを実装するには、特定のユーザー、グループ、または役割をオブジェクトに追加します。そのユーザー、グループ、または役割だけがオブジェクトにアクセスすることができます。

オブジェクト・ベースのセキュリティーを追加する際には、以下のヒントが役立ちます。

v オブジェクト・ベースのパッケージのリストを表示するには、「パッケージ」フォルダーをダブルクリックします。リストが「エクスプローラー」タブに表示されます。その特定のオブジェクト・ベースのパッケージに対して保護されているオブジェクトを表示するには、「パッケージ」フォルダーをクリックし、「操作」メニューから「パッケージ」、「パッケージを閲覧」の順にクリックします( 301 ページの『パッケージの閲覧』)。

v オブジェクト・ベースのセキュリティーがモデルで設定されているかどうかを判別するには、「パッケージ」フォルダーをクリックし、「操作」メニューから「パッケージ」、「パッケージを閲覧」の順にクリックします。「役割エクスプローラー (Roles Explorer)」タブをクリックします。オブジェクト・ベースのセキュリティーが設定されている場合、「すべてのユーザー」役割のパッケージが表示されます。

v モデルで明示的に保護されているオブジェクトを判別するには、「プロジェクト・ビューアー」のオブジェクト・アイコンを確認します。左上隅のアイコンにオーバーレイのマークが付いています。

v 特定のオブジェクトの下で明示的に保護されているすべてのオブジェクトを検索するには、オブジェクトを選択し、「ツール」、「すべての保護されたオブジェクトを検索」の順にクリックします。

手順

1. 保護するオブジェクトをクリックし、「操作」メニューから「オブジェクト・セキュリティーを指定」をクリックします。

ヒント: 一度に複数のオブジェクトを選択できます。

2. 変更するユーザー、グループ、または役割を選択します。または、「追加」をクリックして、新規ユーザー、グループ、または役割を追加します。

詳細については、「管理およびセキュリティー・ガイド」を参照してください。

3. 次のいずれかの操作を実行して、各ユーザー、グループ、または役割に対してセキュリティー権限を指定します。

v ユーザー、グループ、または役割へのアクセスを拒否するには、ユーザー、グループ、または役割の名前の横にある「拒否」チェック・ボックスをオンにします。「拒否」は「許可」より優先されます。

v ユーザー、グループ、または役割に対してアクセス権限を付与するには、「許可」チェック・ボックスをオンにします。


ヒント: アクセスが明示的に拒否されない場合に、すべてのユーザーに対してオブジェクトすべてを表示するには、「すべてのユーザー」役割の「許可」チェック・ボックスをオンにします。


オブジェクト・ベースの新規パッケージおよび更新されたパッケージのリストが表示されます。

個々のオブジェクトのオブジェクト・ベースのセキュリティーの削除特定のユーザー、グループ、または役割のオブジェクト・ベースのセキュリティーを削除するには、そのユーザー、グループ、または役割のパッケージを「プロジェクト・ビューアー」から削除します。

オブジェクト・ベースのセキュリティーをモデルから完全に削除するには、「すべてのユーザー」役割のパッケージを「プロジェクト・ビューアー」から削除します。「すべてのユーザー」グループのすべてのオブジェクトへのアクセスを拒否することはできません。

手順

1. 必要なオブジェクトをクリックします。

2. 「操作」、「オブジェクト・セキュリティーを指定」の順にクリックします。

3. すべてのユーザー、グループ、または役割の「許可」チェック・ボックスと「拒否」チェック・ボックスの両方をオフにすることにより、セキュリティー権限を削除します。


この変更によって影響を受けるパッケージのリストが表示されます。

パッケージ・セキュリティーの変更発行されたパッケージのアクセス権を変更できます。変更された権限設定で指定されるものは、現在そのパッケージにアクセスできるユーザー、グループ、または役割のみです。これらの設定によって、IBM Cognos Framework Manager のパッケージ定義が影響を受けることはありません。

初期パッケージ・セキュリティーは、パッケージを初めて発行するときに定義します。詳細については、 293 ページの『パッケージの発行』を参照してください。

パッケージ・セキュリティーを定義する場合は、そのパッケージにアクセスできるユーザー、グループ、役割と、それらが持つアクセス権限のタイプ (読み取り、書き込みなど) を指定します。どのユーザーがそのパッケージの管理権限を持つかも決定します。特権の中でも特に管理者には Framework Manager のパッケージを再発行し、パッケージがサーバーに再発行されるときにレポートが影響を受けないようにする責任があります。

手順1. IBM Cognos Analytics ポータルにログオンします。

2. 「チーム・コンテンツ (Team content)」で、セキュリティー設定を変更するパッケージを見つけます。


3. パッケージのショートカット・メニューから、「プロパティー」をクリックします。

4. 「権限」タブで、「親の権限をオーバーライドする (Override parentpermissions)」チェック・ボックスを選択します。

5. ユーザー、グループ、または役割を追加または削除して、それらのアクセス権限のタイプを指定します。

アクセス権について詳しくは、「IBM Cognos Analytics 管理およびセキュリティー・ガイド」または「IBM Cognos Analytics ご利用の手引き」を参照してください。

6. 「全般」タブの「拡張」セクションで、パッケージの非表示や無効化など、その他の設定を指定できます。

7. 設定の変更が完了したら、「OK」をクリックします。

言語の指定各パッケージで発行される言語を指定することができます。同じモデルに基づいて複数のパッケージを作成し、それぞれのパッケージで異なる言語を使用するようにすることができます。

例えば、メキシコ営業所のパッケージにスペイン語と英語を含めることができます。カナダ営業所のパッケージにフランス語と英語を含めることができます。

すべてのパッケージの言語を同時に指定することもできます。

ユーザーがパッケージで必要とする言語を指定するには、事前に言語をプロジェクトに追加しておく必要があります ( 138 ページの『多言語メタデータ』)。

1 つのパッケージの言語の指定

手順1. 「プロジェクト・ビューアー」で、変更するパッケージをクリックします。

2. 「プロパティー」タブで「言語」プロパティーを見つけ、「クリックして編集」をクリックします。

3. 「使用できるプロジェクト言語」ボックスで言語をクリック (または Ctrl を押しながら複数の言語をクリック) し、矢印アイコンを使用して「選択した言語」ボックスに移動します。

すべてのパッケージの言語の指定

手順1. 「プロジェクト・ビューアー」で、「パッケージ」フォルダーをクリックしま

す。

2. 「操作」メニューで、「パッケージ」、「パッケージ言語を指定」をクリックします。

3. 各パッケージに指定する言語のチェック・ボックスをオンにします。


消去オプションの設定IBM Cognos Framework Manager で発行したパッケージの消去プロパティーを設定できます。このプロパティーによって、IBM Cognos の Studio/Authoring ツール・ユーザーがマルチエッジ消去とシングル・エッジ消去のどちらを選択できるかが決まります。消去できる値のタイプもこのプロパティーによって決まります。ユーザーが消去できる値のタイプは、Studio/Authoring ツールによって異なります。

パッケージを作成する際、消去プロパティーは自動的に true に設定されます。発行されたパッケージに基づいて値を変更する場合、パッケージを再発行する必要があります。

手順1. 「プロジェクト・ビューアー」で、変更するパッケージをクリックします。

2. 「プロパティー」タブで消去プロパティーを見つけ、以下のいずれかの値を選択します。

v 「Null 消去を許可」- true の場合、このプロパティーは IBM Cognos のStudio/Authoring ツール・ユーザーが消去を使用できるようにします。false の場合、発行されたパッケージで消去を使用できません。

v 「マルチエッジ消去を許可」- true の場合、ユーザーはマルチエッジ消去オプションまたはシングル・エッジ消去オプションを選択できます。 falseの場合、ユーザーはシングル・エッジ消去にのみアクセスできます。「Null消去を許可」プロパティーを true にする必要もあります。

v 「消去オプションへのアクセスを許可」- true の場合、ユーザーは、ゼロや欠落値など、消去される値のタイプを選択できます。デフォルトで、すべてのタイプの値が消去されます。「Null 消去を許可」プロパティーを trueにする必要もあります。

外部化されたクエリー・サブジェクトおよびディメンションパッケージを発行するとき、他の IBM Cognos アプリケーションで使用できる形式にクエリー・サブジェクトやディメンションを外部化するというオプションがあります。SAP BW メタデータに基づいてモデルを外部化するときには、特別の注意を払う必要があります。

詳細については、 476 ページの『Framework Manager における外部化されたCSV ファイルを使用した SAP BW データの処理』を参照してください。

最初に、使用する方式を指定して、各オブジェクトをどのように外部化するかを定義します。パッケージを発行するとき、クエリー・サブジェクトおよびディメンションを外部化することを指定します。

「ガバナー」ダイアログ・ボックスで取得する行数の最大値を指定した場合、この設定は無視されます。

外部化の方式として、いくつかのオプションがあります。


デフォルト方式

デフォルト方式を使用して、外部化しないパッケージ内のオブジェクトを指定します。パフォーマンスを改善するため、パッケージ内のすべてのオブジェクトを外部化しないことがあります。

タブ方式

タブ方式を使用して、クエリー・サブジェクトまたはディメンションの結果を含むタブ区切りファイルを生成します。生成されたファイルは、データ・ソースとして直接使用できます。生成されたファイルには、BOM (バイト・オーダー・マーク)のある UTF-16 LE (リトル・エンディアン) エンコードを使用する、Unicode に基づくデータが含まれます。外部化するように設定されたクエリー・サブジェクトまたはディメンションごとに 1 つのファイルが生成されます。

Transformer は Unicode をサポートしないので、この方式は Transformer では使用できません。 Transformer では、CSV 方式を使用してファイルを作成してください。

外部化自動集計プロパティー

出力を集計するか、グループ化するか、またはその両方を行うように指定できます。デフォルトで、IBM Cognos Framework Manager は、集計やグループ化を適用しないで、行を詳細レベルで返します。リレーショナル・データが外部化されるときに集計されるようにするには、このプロパティーを使用します。クエリー・サブジェクトを外部化する前に、その行列式を指定します。

「外部化自動集計」プロパティーを使用して、「標準集計」プロパティーの設定値を、「使用方法」プロパティーが「ファクト」に設定されたクエリー・アイテムに適用します。

Group By 節の中のアイテムを特定の順序で配置するには、まず行列式を指定してから、「外部化自動集計」プロパティーを設定します。

「外部化自動集計」プロパティーは、すべての外部化方式で使用できます。

サポートされるデータ型

Framework Manager は、文字列、整数、および日付をサポートします。時間ディメンションはサポートされません。 Framework Manager のファクト・クエリー・サブジェクトで日付キーを使用して、Transformer が時間ディメンションを生成するようにします。

ショートカット

ショートカットがパッケージに含まれていて、それが外部化されたクエリー・サブジェクトを指している場合、そのショートカットも外部化されます。データ・ファイルの名前は、ショートカットが指しているクエリー・サブジェクトの名前です。複数のショートカットが同じクエリー・サブジェクトを指している場合、そのクエリー・サブジェクトはショートカットが発生するたびに外部化されます。


クエリー処理

いくつかのクエリーは、複数のクエリーの発行、データを取得するためのローカル処理の実行、またはその両方を生じさせます。これを防止するために、モデル内のすべてのデータ・ソース・オブジェクトの「クエリー処理」プロパティーが「データベースのみ」に設定されるようにしてください。クエリーの処理方法について詳しくは、 346 ページの『クエリー処理タイプの設定によるパフォーマンスの改善』を参照してください。

ディメンションを外部化するプロセス

以下のタスクを実行して、ディメンションを外部化します。

v 外部化するディメンションを含むモデル・クエリー・サブジェクトまたはデータ・ソース・クエリー・サブジェクトを作成します。詳細については、 84 ページの『クエリー・サブジェクト』を参照してください。

v 必要なフィルターを追加します。

リレーショナル・メタデータのフィルターについて詳しくは、 169 ページの『フィルターの作成』を参照してください。 SAP BW メタデータのフィルターについて詳しくは、 263 ページの『フィルターの作成 (SAP BW)』を参照してください。

v 「プロパティー」ウィンドウでの「外部化メソッド」プロパティーに、使用するメソッドを設定します。

v パッケージを発行して、選択したディメンションを外部化します。

パッケージの発行IBM Cognos Framework Manager では、Content Manager のフォルダーにパッケージを発行して、ユーザーがそのフォルダーにアクセスできるようにすることができます。

パッケージをネットワーク上の場所に発行することもできます。ユーザーがネットワーク上の場所のパッケージを使用することはできません。ネットワーク上の場所への発行は、パッケージをバックアップする場合に便利です。 LAN 上の場所に発行する際は、既存のファイル (特に、Framework Manager モデルおよび現在開かれているモデル) を上書きしないように注意してください。

オブジェクトが除外または非表示にされるものの、それがクエリー・パスで必要であれば、そのオブジェクトは組み込まれます。ただし、発行されたパッケージで非表示というマークが付けられます。

優先されるガバナー設定は、現在開かれているモデルに (それが親モデルか子モデルかに関係なく) 適用されます。

この問題を回避するには、パッケージを発行する前にトラブルシューティングを行ってください。トラブルシューティングは、「発行」ウィザードの「発行前にパッケージを検証」チェック・ボックスを使用して、そのパッケージに一式が含まれており、エラーがないことを確認することによって行います。

パッケージを発行する際、以下を行えます。


v サーバー上で保持するモデル・バージョンの数を設定します。モデル・バージョンの詳細については、 298 ページの『最新バージョンのパッケージを使用するようにレポートを更新する』を参照してください。

ヒント: パッケージに対して設定されているモデル・バージョンの数を確認するには、パッケージを選択し、「プロパティー」ウィンドウで「最大バージョン」プロパティーを見つけます。

v クエリー・サブジェクトおよびディメンションを外部化し、Transformer とともに使用できるようにします ( 291 ページの『外部化されたクエリー・サブジェクトおよびディメンション』)。

v パッケージで動的クエリー・モードを使用するかどうかを指定します。

動的クエリー・モードについての詳細は、 356 ページの『Framework Manager モデルおよびパッケージが動的クエリー・モードを使用できるようにする』を参照してください。

注: IBM Cognos PowerCube および SAP BW キューブおよびクエリーについては、IBM Cognos Administration でパッケージを直接作成することができます。詳しくは、「IBM Cognos Analytics 管理およびセキュリティー・ガイド」のパッケージに関するセクションを参照してください。

手順1. 発行するパッケージを選択します。

2. 「操作」メニューで、「パッケージ」、「パッケージを発行」の順にクリックします。

3. パッケージを発行する場所を選択します。

v レポート・サーバーにパッケージを発行するには、「IBM Cognos ContentStore」、「開く」の順にクリックして既存のフォルダーを選択するか、Content Store で新規フォルダーを作成します。

v ネットワーク上の場所にパッケージを発行するには、「ネットワーク上の場所」をクリックします。プロジェクト・ファイルが保管されているディレクトリーとは異なる場所を選択するようにしてください。一般的には、モデルと同じ場所に保存することは避けます。モデルが上書きされる可能性があるからです。

4. IBM Cognos Content Store に発行する際にモデルのバージョン管理を有効にするには、「モデルのバージョン管理を有効にする」チェック・ボックスをオンにし、保持するパッケージのモデル・バージョンの数を入力します。

ヒント: そのサーバーで最後に発行されたバージョンを除くすべてのバージョンを削除するには、「旧モデル・バージョンをすべて削除」チェック・ボックスをオンにします。


6. 「セキュリティーを追加」ウィンドウで、パッケージのセキュリティーを定義します (オプション)。


目的操作

ユーザー、グループ、または役割を作成、追加、または削除する。「ユーザー・アクセス」タブで、「追加」を

クリックします。

「ユーザーとグループを選択」ウィンドウで、ユーザー・セキュリティーを定義します。「ユーザーとグループを選択」ウィンドウの使い方の詳細については、「管理およびセキュリティー・ガイド」を参照してください。「ユーザー・アクセス」タブで定義されるユーザー、グループ、または役割には、読み取り、書き込み、実行、および通過の権限が与えられます。

ユーザー、グループ、または役割に対して管理権限を付与する。「管理者アクセス」タブで、「追加」をクリ

ックします。

「ユーザーとグループを選択」ウィンドウで、管理者セキュリティーを定義します。「ユーザーとグループを選択」ウィンドウの使い方の詳細については、「管理およびセキュリティー・ガイド」を参照してください。「管理者アクセス」タブで定義されるユーザー、グループ、または役割には、読み取り、書き込み、ポリシー設定、および通過の権限が与えられます。

注: 「発行」ウィザードの「セキュリティーを追加」ウィンドウは、パッケージの初回発行時にのみ表示されます。パッケージを同じ場所に再発行する場合、既存のセキュリティーをオーバーライドすることはできません。発行済みパッケージのセキュリティーの変更については、 289 ページの『パッケージ・セキュリティーの変更』を参照してください。


8. クエリー・サブジェクトを外部化する場合、「外部化されたクエリー・サブジェクトのファイルを生成」チェック・ボックスをオンにします。

9. デフォルトで、パッケージは発行前に検証されます。発行前にモデルを検証しない場合、「発行前にパッケージを検証」チェック・ボックスをオフにします。

10. 動的クエリー・モードによってサポートされるデータ・ソースがパッケージに含まれる場合、パッケージの動的クエリー・モードを有効にすることもできます。「動的クエリー・モードの使用」チェック・ボックスをオンにします。「発行」をクリックしたときに、この選択について確認を求められます。このステップは、プロジェクトの「クエリー・モード」プロパティーが「互換」に設定されている場合に当てはまります。

注: サポートされているデータ・ソースとサポートされていないデータ・ソースが混在しているパッケージが動的クエリー・モードで発行されると、Studiosでそのパッケージを開いたときにエラーが表示されます。


動的クエリー・モードによってサポートされるデータ・ソースの詳細については、「IBM Cognos 管理およびセキュリティー・ガイド」を参照してください。

11. 「発行」をクリックします。

クエリー・サブジェクトを外部化することにした場合、作成されたファイルがFramework Manager によってリストされます。


OLAP データ・ソースに基づくパッケージの発行IBM Cognos Framework Manager を使用して、OLAP データ・ソースに接続し、キューブに基づいてパッケージを作成することができます。その後、IBM CognosAdministration に直接パッケージを発行することができます。これにより、IBMCognos Studio での使用が可能になります。

デフォルトで、それぞれのパッケージには、ただ 1 つのキューブへの接続が含まれています。複数のキューブを含むパッケージを作成する場合、メタデータ・ウィザードを実行し、キューブごとにパッケージを作成します。その後、必要に応じて、個々のパッケージを含むパッケージを作成します。

複数のキューブを含むパッケージを作成する前に、パフォーマンスの潜在的影響について検討してください。 IBM Cognos Administration でパッケージが使用されるたびに、パッケージで定義されている各データ・ソースへの接続が確立されます。複数のキューブを含む大きなパッケージを作成すると、パフォーマンスに悪影響を与える可能性があります。多くのキューブを含む大きなパッケージを 1 つ作成することによるパフォーマンスの潜在的影響を埋め合わせるために、1 つのキューブにつき 1 つのパッケージを作成し、必要に応じて、作成するパッケージの組み合わせを小さめにします。

デフォルトで、OLAP データ・ソースに基づくパッケージにはベンダー関数リストは含まれません。ベンダー関数リストを含める場合は、含める関数セットを指定し、パッケージを再発行してください。

注: 単一のキューブを含むパッケージを発行するには、IBM CognosAdministration を使用します。 IBM Cognos Administration からのパッケージの発行の詳細については、「管理およびセキュリティー・ガイド」を参照してください。

パッケージを作成および発行する手順手順

1. 「ようこそ」ページで、「新規プロジェクトの作成」をクリックします。

ヒント: Framework Manager を既に使用している場合、「ファイル」、「新しいプロジェクト」の順にクリックします。


認証情報の入力を要求するプロンプトが出されることがあります。



「OK」をクリックした後、選択した言語を変更することはできません。ただし、他の言語を追加することはできます。詳細については、 142 ページの『プロジェクトへの言語の追加』を参照してください。

4. 「メタデータ・ウィザード」ダイアログ・ボックスで、「データ・ソース」、「次へ」の順にクリックします。

5. 選択可能なデータ・ソース接続のリストからデータ・ソースを選択し、「次へ」をクリックします。

選択可能なデータ・ソース接続がリストにない場合、「新規作成」をクリックしてデータ・ソース接続を作成します。

6. パッケージに名前を指定し、「次へ」をクリックします。

必要に応じて、パッケージの説明と画面のヒントを指定することができます。

7. パッケージにアクセスできるユーザーを指定します。

ユーザー、グループ、またはロールを追加することができます。詳細については、 283 ページの『ユーザー、グループ、および役割』を参照してください。

8. 「完了」をクリックし、メタデータをインポートして、パッケージを作成します。

9. プロンプトが出されたら、「はい」をクリックしてパッケージを発行するか、「いいえ」をクリックして「プロジェクト・ビューアー」に戻ります。

タスクの結果

ネームスペースが「プロジェクト・ビューアー」に表示されます。 FrameworkManager では、ネイティブ・メタデータ・モデルのオブジェクトは表示されません。 IBM Cognos の Studio/Authoring ツールでは、ネイティブ・メタデータ・パッケージの使用時に、ネイティブ・メタデータ・オブジェクトが表示されます。

別のパッケージを追加する手順

手順

1. 「プロジェクト・ビューアー」で、使用するモデルを右クリックし、「メタデータ・ウィザードを実行」をクリックします。

2. 「メタデータ・ウィザード」ダイアログ・ボックスで、「データ・ソース」、「次へ」の順にクリックします。

3. 選択可能なデータ・ソース接続のリストからデータ・ソースを選択し、「次へ」をクリックします。

選択可能なデータ・ソース接続がリストにない場合、「新規作成」をクリックしてデータ・ソース接続を作成します。

4. パッケージに名前を指定し、「次へ」をクリックします。

必要に応じて、パッケージの説明と画面のヒントを指定することができます。

5. パッケージのアクセス権を指定します。


ユーザー、グループ、または役割をパッケージに追加することができます。詳細については、 283 ページの『ユーザー、グループ、および役割』を参照してください。

6. 「完了」をクリックし、メタデータをインポートして、パッケージを作成します。

7. プロンプトが出されたら、「はい」をクリックしてパッケージを発行するか、「いいえ」をクリックして「プロジェクト・ビューアー」に戻ります。

タスクの結果

ネームスペースが「プロジェクト・ビューアー」に表示されます。 FrameworkManager では、ネイティブ・メタデータ・モデルのオブジェクトは表示されません。 IBM Cognos の Studio/Authoring ツールでは、ネイティブ・メタデータ・パッケージの使用時に、ネイティブ・メタデータ・オブジェクトが表示されます。

スクリプトの実行によるパッケージの発行IBM Cognos レポートは、レポートの基になるパッケージのオブジェクトに依存します。パッケージに現時点で存在していないオブジェクトをレポートが使用する場合、レポートは実行されません。物理データ・ソースに対して変更を加え、スクリプトを使用してモデルを生成し、パッケージを再発行する場合に、この問題が生じることがあります。スクリプトを実行してパッケージを発行した後、パッケージ発行の影響の分析によって、破損したレポートは識別されません。

スクリプトを使用してパッケージを発行する際にこの問題を回避するには、指定された順序で発行作業を実行してください。

手順1. パッケージを発行する手順はすべて除いて、スクリプトを実行します。

2. モデルを検証するか、パッケージ発行の影響を分析します。

3. パッケージを発行します。

最新バージョンのパッケージを使用するようにレポートを更新する初めてパッケージを発行する際に、IBM Cognos サーバー上に対応するパッケージを作成します。パッケージにはモデルは含まれますが、レポートは含まれません。

パッケージを発行する際、サーバーに保持するモデルのバージョンの番号を選択することができます。次回パッケージを発行する際、サーバー上の既存のパッケージのモデルのバージョンが更新されます。

新規または変更されたレポートは、最新バージョンのパッケージのモデルを使用します。レポートが保存されるときに、使用されるモデルのバージョンがレポートの仕様に保存されます。パッケージが再発行される場合、レポートで最新バージョンのパッケージのモデルが使用されていることがレポート作成者に通知されます。レポート作成者は、更新を完了するためにレポートを保存する必要があります。レポートの基礎になっているパッケージが再発行された後、保存されているレポートを開くと、次のいずれかの処理が行われます。

v 元のバージョンのパッケージがまだ存在する場合、レポートは元のバージョンのパッケージに対して実行されます。最新バージョンのパッケージに対してレポー


トを実行する場合、最新バージョンのパッケージを使用するようにレポートを更新する必要があります。以下の手順を参照してください。

v 元のバージョンのパッケージが存在しない場合、レポートは更新され、最新バージョンのパッケージに対して実行されます。

手順

次のいずれかを実行します。

v レポートを編集して保存することにより、1 つのレポートを最新バージョンのモデルに移動します。

v モデルを再発行する前に、「発行」ウィザードの「旧モデル・バージョンをすべて削除」チェック・ボックスをオンにすることにより、すべてのレポートを最新バージョンのモデルに移動します。

v モデルを再発行する前に、モデルのバージョン制限を 1 に設定することにより、モデルのバージョン管理を無効にします。


第 8 章プロジェクトの管理

プロジェクトの存続期間中に、データが変更され、新しい要件が表示されて、モデルとデータ・ソースを更新する必要が生じることがあります。

プロジェクトを発行した後に、内容を管理するために以下のことを行えます。

v モデル内のメタデータについて理解する。

v マルチユーザー・モデル作成機能を実装する。

v メタデータを管理する。

v プロジェクトを同期化する。

v クエリーの動作を制御して最適化する。

モデル内のメタデータ発行済みモデルに変更を加える前に、以下の作業を行ってメタデータをよく理解しておくことをお勧めします。

v プロジェクトを閲覧してプロジェクト内のパッケージと役割を調べる。

v パッケージ内のオブジェクトを表示して、特定のオブジェクトがどこに存在するかを調べる。

v 会社の具体的要件を満たすためのモデルに関する文書を作成する。

パッケージの閲覧プロジェクトが多数存在する場合やプロジェクトにオブジェクト・ベースのセキュリティーが存在する場合、すべてが編成された状態を保つことが難しい場合があります。パッケージを閲覧して、プロジェクト内のパッケージおよび役割を表示することができます。

「パッケージの内容」タブから、プロジェクト内のすべてのパッケージ (通常およびオブジェクト・ベース) のリスト、および各パッケージの選択済み、選択解除済み、または非表示のオブジェクトを確認できます。

「オブジェクト・セキュリティー」タブから、プロジェクト内のすべてのユーザー、グループ、および役割のリスト、およびオブジェクト・ベースのセキュリティーが適用されるパッケージを確認できます。また、プロジェクト内のオブジェクトがその特定のユーザー、グループ、または役割に対して非表示になっているか、それとも表示されているかも確認できます。

手順1. 「パッケージ」フォルダーを選択します。

2. 「操作」メニューで、「パッケージ」、「パッケージを閲覧」の順にクリックします。



目的操作

パッケージの内容を表示する「パッケージの内容」タブをクリックします。

パッケージを編集する「パッケージの内容」タブをクリックし、パッケージを選択して、「編集」をクリックします。

詳細については、 280 ページの『パッケージの作成または変更』を参照してください。

各パッケージのセキュリティーを表示します。

「オブジェクト・セキュリティー」タブをクリックし、パッケージを選択します。


パッケージでのオブジェクトの分布の表示オブジェクトのパッケージ包含を表示すると、パッケージごとのオブジェクトの格納場所が分かります。また、そのパッケージでオブジェクトが選択されているか、選択解除されているか、あるいは非表示になっているかも分かります。

オブジェクトが保護されている場合、オブジェクトが存在するオブジェクト・ベースのパッケージも表示されます。

手順1. 表示するオブジェクトをクリックし、「操作」、「パッケージ包含を編集」の順

にクリックします。

2. パッケージを編集するには、「パッケージの編集」をクリックします。

詳細については、 280 ページの『パッケージの作成または変更』を参照してください。


モデル文書の作成メタデータをモデル化した後、カスタマイズおよび出力が可能なモデルの HTMLまたは XML 表現を作成することができます。これは、モデルのデバッグに便利です。また、プロセス要件を満たすためにこのタイプの文書が会社で必要な場合にこれを使用できます。

モデル文書を作成する際、モデル全体を文書化することも、モデルのサブセットを選択することもできます。モデル全体を文書化するには、最上位のネームスペースをクリックします。モデル文書は、選択されたオブジェクトおよびそのオブジェクトのすべてのプロパティーと子を示します。

レポートは XML または HTML 形式で表示、保存、または出力することができます。デフォルトで、IBM Cognos Framework Manager 内の XML 形式は常に生XML です。ブラウザーでの XML レポート出力をカスタマイズするには、独自のXSLT 変換を提供することができます。

HTML 出力をカスタマイズするには、<インストール場所>/configuration ディレクトリーにある fm.ini ファイルの ModelDocXSL セクションにパスおよび XSL


ファイルを指定することにより、独自の XSLT を使用することができます。Framework Manager は、モデル・レポートの HTML 版を表示する際に、指定された XSL ファイルを使用します。

手順1. 文書化するオブジェクトをクリックします。

ヒント: モデル全体を文書化するには、最上位のネームスペースをクリックします。

2. 「ツール」、「モデル・レポート」の順にクリックします。

モデル・レポートが表示されます。

レポートの形式は、保存、出力、または変更が可能です。

マルチユーザーのモデル作成分岐とマージによって、またはセグメント化とリンクによって、マルチユーザーのモデル作成を IBM Cognos Framework Manager に実装できます。

v 分岐とマージ

分岐とマージを使用してマルチユーザー・プロジェクトを管理する場合、各ユーザーはプロジェクト内の同じオブジェクトを同時に変更できます。各ユーザーはプロジェクト全体のコピーを持ち、その任意の部分に対して作業することができます。それらの分岐をルート・プロジェクトにマージバックするとき、ルート・プロジェクトと分岐との間にあるすべての競合が解決されます。詳細については、『プロジェクトの分岐とマージ』を参照してください。

v セグメント化とリンク

セグメント化とリンクを使用してマルチユーザー・プロジェクトを管理する場合、各ユーザーはプロジェクト内の同じ部分を同時に閲覧できます。ただし、各ユーザーによって変更されるのはプロジェクトの個別の部分となるようにする必要があります。リンクを使用して、別のユーザーが作業しているプロジェクトを、他のさまざまなユーザーが同時に参照できるようにします。詳細については、 310 ページの『セグメント化プロジェクトとリンク・プロジェクト』を参照してください。

プロジェクトの分岐とマージ分岐とマージは、複数のユーザーが同時に同じモデルで作業することを可能にします。そのためには、プロジェクトのコピーであるルート・プロジェクトの分岐を、プロジェクト所有者が作成します。チーム・メンバーは、ルート・プロジェクトと切り離して、必要に応じて分岐を変更できます。分岐は必要に応じてルート・プロジェクトにマージバックすることができます。ルート・プロジェクトと分岐の間の矛盾は、マージ・プロセスで解決されます。

作成できる分岐の数に制限はありません。分岐から分岐を作成することができます。

第 8 章プロジェクトの管理 303

分岐とマージ

プロジェクトを分岐するときは、以下のガイドラインに従ってください。

v 組織でメタデータをどのように共有するかを決定します。詳細については、『分岐の方法』を参照してください。

v プロジェクトを論理部分に分割し、プロジェクトを分岐させて論理部分を作成します。詳細については、 306 ページの『プロジェクトの分岐方法』を参照してください。

v さまざまな分岐で作業するチーム・メンバー間のコミュニケーションは、非常に重要です。分岐に大きな変更を加える前に、他のチーム・メンバーに話して、変更がそれぞれの分岐に与える影響を調べてください。例えば、分岐にオブジェクトを追加しても他のチーム・メンバーにはおそらく影響を与えませんが、他のチーム・メンバーがそれぞれの分岐で使用しているオブジェクトを削除すると、分岐をルート・プロジェクトにマージバックしたときに、矛盾が生じることになります。

v 作成したときの逆順に分岐をマージします。例えば、Sean がルート・プロジェクトから分岐を作成します。Susan が Sean の分岐から分岐を作成します。分岐をルート・プロジェクトにマージバックするときが来たら、まず Susan が自分の分岐を Sean の分岐にマージバックし、次に Sean が自分の分岐をルート・プロジェクトにマージバックします。

v 多くの変更を加えてごくたまにマージするのではなく、分岐にいくつか変更を加えるたびに、頻繁に分岐をルート・プロジェクトにマージバックしてください。こうすることにより、マージ・プロセスで矛盾を解決しやすくなります。すべての分岐をルート・プロジェクトにマージバックした後に、プロジェクトを再度分岐させることができます。各チーム・メンバーは、更新されたバージョンのモデルを受け取ります。

v 分岐プロジェクトでは、アーカイブされたトランザクションはメインプロジェクトにマージバックする際に使用できません。詳細については、 328 ページの『トランザクション履歴の表示と保存』を参照してください。

分岐の方法プロジェクトを分岐する前に、プロジェクト内でメタデータを共有する方法を決める必要があります。このセクションでは、メタデータを共有するためのいくつかの一般的な方法を説明します。

ハブ・アンド・スポーク

ハブ・アンド・スポークでは、プロジェクトはすべての機能領域によって共有される必要のある共通のメタデータを使用します。ルート・プロジェクトは、すべての機能領域で必要となるオブジェクトを含む、完全にモデル化された物理レイヤーから構成されます。ルート・プロジェクトは、それぞれの機能領域に向けて分岐されています。それぞれの機能領域は、複数の担当者が作業している場合、独自の分岐を作成できます。いつでも機能領域のモデル作成者は、分岐をルート・プロジェクトにマージして戻し、ルート・プロジェクトを更新してから再び分岐させることによって、各機能領域が更新を受け取るようにすることができます。すべての機能領域で共通のオブジェクトは、ルート・プロジェクトに保持されます。


機能領域固有のメタデータ

機能領域に固有のメタデータでは、プロジェクトに共通のメタデータはわずかしかないか、またはまったくありません。各機能領域はプロジェクト内に独自のオブジェクトを個別に作成します。各機能領域は、他の機能領域内のオブジェクトを認識しません。モデル作成の監督者は、分岐のマージを制御して、各機能領域から他の機能領域内のオブジェクトを見えないようにします。

レイヤーごとの配布

レイヤーごとの配布では、メタデータが複数の層に編成されます。それぞれのレイヤーには、その上位のレイヤーのメタデータに対するアクセス権が必要です。例えば、あるモデルに 3 つのレイヤーが含まれているとします。最上位のレイヤーはルート・プロジェクトで、完全にモデル化された物理レイヤーから構成されます。ルート・プロジェクトは分岐して、2 番目のレイヤーである中間分岐を作成します。中間分岐には完全にモデル化された開発レイヤーが含まれます。中間分岐は分岐し


て、3 番目のレイヤーであるプレゼンテーション分岐を作成します。プレゼンテーション分岐には、レポート作成パッケージが定義されて発行される、完全にモデル化されたビジネス・レイヤーが含まれます。

プロジェクトの分岐方法プロジェクトを分割するいくつかの方法を以下に示します。

v タスクおよびスキル・セット別

スター・スキーマとパッケージの作業をする人、計算とフィルターの作業をする人、ディメンションの作業をする人、およびクエリーとオブジェクト命名の作業をする人に対応した別々の分岐を作成します。

v モデル・レイヤー別

インポート・レイヤー、中間レイヤー、およびプレゼンテーション・レイヤーに対応した別々の分岐を作成します。

v 事業単位または機能領域別

販売および小売業者に対応した別々の分岐を作成します。

v データ・ソースのタイプ別

リレーショナル・データ・ソース、ディメンション・データ・ソース、およびERP データ・ソースに対応した別々の分岐を作成します。

分岐の作成プロジェクトに分岐を作成できます。


新しい分岐に関連付けられたログ・ファイルは空になります。読み取り専用プロジェクトの分岐を作成した場合、その結果の分岐は書き込み可能です。

手順

1. 分岐元のプロジェクトを開きます。

2. 「プロジェクト」、「分岐先」の順にクリックします。

3. 「プロジェクト名」ボックスに、プロジェクトの名前を入力します。

4. 「場所」ボックスで、分岐バージョンを格納するフォルダーのパスを入力します。

プロジェクトのマージ枝をそのルート・プロジェクトに再びマージすることができます。

枝をルート・プロジェクトに再びマージするために、IBM Cognos FrameworkManager は、枝に対して実行されたトランザクションのリストを表示します。それぞれのトランザクションの横には、チェック・ボックスがあります。チェック・ボックスがオンになっているトランザクションごとに、Framework Manager はマージ先のプロジェクトに対してトランザクションの実行を試みます。トランザクションが正常に完了するとチェック・マークが付けられ、次のトランザクションが試行されます。トランザクションが失敗すると、そのトランザクションに "X" のマークが付けられ、処理が停止します。

トランザクションが失敗したときに、問題を即時に訂正することもできます。例えば、オブジェクトが欠落している場合、Framework Manager は欠落しているオブジェクトを識別し、それを別のオブジェクトで置き換えるようプロンプトを出します。

トランザクション・リストの最後に達したときに、変更を受け入れるかキャンセルすることができます。変更を受け入れる場合、正常に完了したトランザクションはトランザクション・リストから削除されます。変更を受け入れない場合、トランザクション・リストは更新されず、後で同じマージを再実行することができます。

競合によっては、マージ・プロセスの際に解決できないものがあります。あるいは、複数のトランザクションが失敗トランザクションと関連している場合があります。このような場合は、「従属トランザクションの選択解除」チェック・ボックスをオンにすることにより、トランザクションをスキップすることができます。その後、Framework Manager は、失敗トランザクションと関連した各トランザクションのチェック・ボックスをオフにします。 Framework Manager がトランザクション・リストの実行を再開する際にそのチェック・ボックスがオフになっていると、トランザクションは実行されません。トランザクション・リストの最後に達したときに、その時点までの変更を受け入れ、スキップされたトランザクションをトラブルシューティングし、エラーを修正して、マージを再実行することができます。マージを再実行する際、トランザクション・リストには、実行されなかったトランザクションだけが含まれています。

注: トランザクション・リストを実行する前に、Framework Manager はマージするプロジェクトのバックアップを作成します。バックアップはマージするプロジェクトと同じディレクトリーに保管されます。


手順

1. 枝のマージ先のプロジェクトを開きます。

2. 「プロジェクト」、「マージ元」の順にクリックします。

3. 「マージ元のプロジェクトの選択」ダイアログ・ボックスで、「ファイル・タイプ」、「すべてのファイル (*.*)」の順にクリックします。

4. マージする枝の log.xml ファイルを見つけ、「開く」をクリックします。

「マージの実行」ウィンドウが開き、トランザクションのリストが表示されます。選択したトランザクションが実行されます。

トランザクション履歴リストにデータを取り込むために Framework Managerで必要なのは log.xml ファイルと IdLog.xml ファイルだけであり、プロジェクトの全セットは必要ありません。プロンプトが出されたときに .cpf ファイルを直接開く場合、log.xml ファイルが Framework Manager によって見つけられ、開かれます。 log.xml ファイルを直接開くことには、マルチユーザー環境に配布する必要がある大きなファイルの数が減るという利点があります。

5. トランザクションの実行方法を選択します。

v トランザクション・リスト全体を最初から最後まで続けて実行するには、「実行」をクリックします。

v 1 つのトランザクションを実行してから停止するには、「ステップ」をクリックします。

トランザクションが完了すると、チェック・マークまたは "X" が横に表示されます。チェック・マークは、マージ先のモデルに対してトランザクションが正常に適用されたことを示します。 "X" は、トランザクションが失敗したことを意味します。各トランザクションの詳細な情報は「トランザクションの詳細」の下にリストされます。トランザクションが失敗すると、マージ・プロセスが停止します。

6. 次のいずれかを選択します。

目的操作

失敗したトランザクションを修正する309 ページの『失敗したトランザクション

の修正』を参照してください。

現在のトランザクションをスキップし、その次のトランザクションを実行する

「スキップ」をクリックします。

現在のトランザクションを実行して停止する「ステップ」をクリックします。

トランザクション・リストの現在のトランザクションから最後までを実行する

「継続」をクリックします。

この時点までのトランザクションの実行を受け入れ、プロジェクト・ページに戻る

「承諾」をクリックします。

この時点までのトランザクションのすべての実行を取り消し、プロジェクト・ページに戻る

「元に戻す」をクリックします。

7. トランザクション・リストの最後に達するか、または変更を受け入れるか元に戻すまで、前のステップを実行します。


変更を受け入れた場合、その変更が「プロジェクト・ビューアー」に表示されます。変更を元に戻した場合、変更は表示されません。

8. 変更を受け入れた場合、マージしたプロジェクトをプロジェクト・ページに保存します。変更を保存しないことにする場合、保存せずにプロジェクトを閉じます。

注: 「マージの実行」ウィンドウで変更を受け入れるがプロジェクトの保存は行わない場合、同じマージを再び実行することができなくなります。トランザクションを受け入れた後、そのトランザクションはトランザクション・リストから削除されます。

失敗したトランザクションの修正:

マージ・プロセスの際に、トランザクションが失敗することがあります。あるオブジェクトを別のオブジェクトに置き換えることによって、ほとんどのトランザクションを修正できます。プロジェクトを変更することによって、すべてのトランザクションを修正できます。

ケース 1

分岐プロジェクトで作成されるオブジェクトがルート・プロジェクトにありません。「マージ」ダイアログ・ボックスに、ルート・プロジェクトに欠落しているオブジェクトの名前を示す「置換」ボックスが表示されています。

この問題を解決するために、次の方法でルート・プロジェクトから代わりのオブジェクトを選択できます。

v プロジェクト・ビューアーまたはダイアグラムで、欠落したオブジェクトの代わりに使用するオブジェクトの名前を選択します。

「マージ」ダイアログ・ボックスで、オブジェクトは「置換フィールド」に表示されます。

v 「置換」をクリックします。

欠落しているオブジェクトが、選択した置換オブジェクトに置き換えられて、トランザクションが再実行されます。

より複雑な問題の場合には、「オブジェクト命名の競合解決」ダイアログ・ボックスで、ルート・プロジェクトに見つからないオブジェクトを選択するように求めるプロンプトが出されることがあります。警告が表示された場合、このダイアログ・ボックスを使用して問題を解決することはできません。代わりに、ルート・プロジェクトの変更またはトランザクションのスキップを行うことができます。

ケース 2

失敗したトランザクションはすべて、ルート・プロジェクトを変更することにより問題を解決できます。まず必要に応じてモデルを変更し、次に「マージの実行」ダイアログ・ボックスで「継続」をクリックして、失敗したトランザクション以降のすべてのトランザクション・リストを実行します。


ケース 3

トランザクションを修正できません。この問題を解決するには、以下を実行してください。

v 「スキップ」をクリックして、次のトランザクションをスキップします。

v 失敗したトランザクションのチェック・ボックスをクリアします。

v 「従属トランザクションの選択解除」チェック・ボックスが選択されていることを確認します。

v 「マージの実行」ダイアログ・ボックスで、「継続」をクリックします。

セグメント化プロジェクトとリンク・プロジェクトIBM Cognos Framework Manager を使用して、セグメント、プロジェクト、およびフォルダーを作成し、リンクさせることができます。セグメントとは、メインプロジェクト内のプロジェクトのことです。セグメントはそのメインプロジェクトによって所有されます。リンクとは、既存プロジェクトへのショートカットのことです。リンクされたプロジェクトを複数のプロジェクトで共有できます。

プロジェクト・セグメントは完全なプロジェクトであり、そのプロジェクトに対する変更はそのリンク先のすべてのプロジェクトに影響を与えます。セグメントを別個のプロジェクトとして開く場合は、そのセグメントが完全なプロジェクトとして構造化されていなければなりません。各セグメントに物理層が存在し、セグメントのベースとなるデータ・ソース・クエリー・サブジェクトのサブセットが物理層に含まれていなければなりません。これらのデータ・ソース・クエリー・サブジェクトは、データとメタデータへのアクセスを提供するので、適切なセグメントに含まれていなければなりません。

セグメント内の物理層を変更しないでください。変更はリンクされた親モデルに反映され、データ・ソース・クエリー・サブジェクトを共有するすべてのモデル・セグメントに影響を与えます。変更が行われたモデルの外では、モデルが閉じられて再び開かれるまで変更がはっきりとは分からない場合があります。

プロジェクトをセグメント化する前に、フォルダーとネームスペースの名前を正しく指定しておく必要があります。プロジェクトがセグメント化されてからフォルダーやネームスペースの名前を変更することはできません。

オブジェクト・セキュリティーのアップグレードや設定など、ルート・モデルで行われた変更は、セグメント化モデルに継承されません。このような変更は、モデルの各セグメントに適用する必要があります。


メインプロジェクトには、セグメントを含めてモデル全体へのアクセス権があります。メインプロジェクトで作業するときにセグメントに変更を加えることができますが、セグメントが複数のユーザーによってアクセスされている場合は、更新内容が失われる可能性があります。


注: プロジェクト構造を変更するときは、セグメントを個別プロジェクトとして開かないでください。代わりに、メインプロジェクトを確認し、その中から変更を加えてください。

整合性の維持と情報の再利用のための関連情報が含まれる他のプロジェクトに、セグメントをリンクさせることができます。モデル・セグメントをリンクさせる場合は、プロジェクトのセグメント化のためのステップに従ってください。一般的な手法として、比較的完全なセグメントにリンクし、モデルを定期的に検証します。

プロジェクトのセグメント化

プロジェクト分割を理解することは、マルチユーザー・モデル作成環境で安定度を確保し複雑さを最小化するうえで非常に重要です。プロジェクトをセグメント化する場合は、以下のようにします。

v 物理層を、次の方法で、できるだけ完全にモデル化します。

– メインプロジェクト内のネームスペースとフォルダーへのすべてのプロジェクト内リンクが、同じ識別子を使用するようにする。 69 ページの『同じ名前のオブジェクトのインポート』を参照してください。

例えば、メインプロジェクトがあり、そのプロジェクト内にフォルダーへのリンクがあるとします。メインプロジェクトと同じ名前のネームスペースに、リンク先フォルダーが存在しなければなりません。メインプロジェクトでの識別子とリンク・フォルダーの識別子が同じでない場合、メインプロジェクトからリンクでオブジェクトを参照する関係、ショートカット、または式が、目的を果たさない可能性があります。

– プロジェクト内のすべてのオブジェクトが一意の識別子を持つようにする。

例えば、NewQS という名前のクエリー・サブジェクトを含んだメイン・プロジェクトがあり、そのプロジェクトにセグメントがあるとします。セグメントを開き、NewQS という名前の新しいクエリー・サブジェクトを追加して、セグメントを保存します。メインプロジェクトを開くと、エラーが発生します。NewQS という名前のクエリー・サブジェクトがメインプロジェクトに既に存在するからです。

– メインプロジェクトとプロジェクト内セグメントの両方で参照を更新する。

例えば、メインプロジェクトがあり、そのプロジェクト内にセグメントがあるとします。メインプロジェクトには、query subject1 と query subject2 の間に存在する qs1_qs2 という名前の関係があります。 query subject 2 という名前のクエリー・サブジェクトはセグメントにあります。セグメントを開き、query subject2 を query subject3 に名前変更し、セグメントを保存します。メインプロジェクトを開くと、エラーが発生します。関係 qs1_qs2 が壊れているからです。 Framework Manager では、ショートカット、モデル・クエリー・サブジェクト、式などの参照に依存するオブジェクトもすべて、影響を受けます。

– メインプロジェクトとプロジェクト内セグメントを同じ言語にする。

例えば、メインプロジェクトがあり、そのプロジェクト内にセグメントがあるとします。セグメントでは、言語として英語とフランス語を定義しました。メインプロジェクトを開き、言語として中国語を追加し、セグメントを


保存します。セグメントを開くと、エラーが発生します。言語の中国語がセグメントで定義されていないからです。

v ネームスペースを使用して物理層を編成します。

複数のセグメントに必要と思われるクエリー・サブジェクト、計算、およびフィルターのためのネームスペースを作成する必要があります。

計画したモデル・セグメントに固有のクエリー・サブジェクトの集合ごとに、ネームスペースを作成する必要があります。

v セグメント化プロジェクトを作成するときはデフォルトのプロジェクト名を受け入れます。

セグメント化プロジェクトは、マスター・プロジェクト・フォルダー内のサブフォルダーに作成されなければなりません。デフォルトのプロジェクト名は、それが含まれるフォルダーまたはネームスペースと同じです。

v 作成したネームスペースごとにモデルをセグメント化します。

v 可能であればソース・コントロール・リポジトリーを使用して、プロジェクトおよびセグメントへのアクセスを制限し、変更を追跡します。

プロジェクトのセグメント化およびリンクに関する制限プロジェクトのセグメント化およびリンクには、以下の制約が適用されます。

v セグメント化またはリンクされたプロジェクト内のオブジェクトが、使用不可のセグメント内に存在するプロジェクトを参照している場合、それらのオブジェクトをテストすることはできません。

v セグメント化またはリンクされたプロジェクト内の新しいオブジェクトが、使用不可のセグメント内に存在するプロジェクトを参照する場合、それらのオブジェクトを作成することはできません。

v プロジェクトにリンクすると、参照されるすべてのオブジェクト (ネームスペース・オブジェクト、データ・ソース、およびパラメーター・マップ) はリンクされます。パッケージはリンクされません。

v 子セグメントに対する変更は、最新表示 (F5) を実行した後でも、メインのプロジェクトに反映されません。これが生じるのは、親プロジェクトまたはメインのプロジェクト自体にリンクされた別の子セグメントが開いているためです。すべての子セグメント・プロジェクトを閉じてから、メインのプロジェクトを再び開いてください。

v プロジェクト内のどこにセグメントを作成するかによって、どこからそのセグメントを見ることができるかが決まります。ネストしたセグメントをメインのプロジェクトから作成した場合、そのネストしたセグメントはメインのプロジェクトから見ることができます。ネストしたセグメントを含むセグメントをスタンドアロン・プロジェクトとして開いた場合、そのネストしたセグメントを見ることはできません。ネストしたセグメントをスタンドアロン・プロジェクトとして開いたセグメントから作成した場合、そのネストしたセグメントはスタンドアロン・プロジェクトから見ることができます。メインのプロジェクトを開いた場合、スタンドアロンのセグメント化されたプロジェクトから作成された、ネストしたセグメントを見ることはできません。


セグメントの作成セグメントを使用することで、ビジネス・ルールと組織要件に従ってプロジェクトを編成し、プロジェクト情報を共有および再利用できます。

フォルダー・レベルまたはネームスペース・レベルでセグメントを作成します。専用の関連プロジェクト・ファイルを備えた新しいフォルダーに、新規プロジェクトを作成できます。

新しいセグメントが作成されると、その新しいセグメントにメインプロジェクトの既存のパラメーター・マップがコピーされます。セグメントが作成された後、パラメーター・マップは各セグメント固有のものであるため、セグメント間で共有することはできません。例えば、メインプロジェクトで作業する場合、セグメントに属するクエリー・サブジェクトでパラメーター・マップを使用できます。ただし、セグメントを開くと、パラメーター・マップは使用できません。

セグメントにアクセスできるのは、それが作成されたプロジェクトからに限られます。例えば、メインプロジェクトを開いて、セグメント (セグメント A) を作成します。次に、セグメント A 内に別のセグメント (セグメント B) を作成します。メインプロジェクトにはセグメント A とセグメント B が表示されます。ただし、セグメント A 自体を開くと、セグメント B は表示されません。

セグメントを作成する前に、プロジェクトを事業単位に分割することを検討してください。例えば、「販売」というプロジェクトがあるとします。2 つのフォルダーを作成できます。1 つは「製品」というフォルダー、もう 1 つは「発注」というフォルダーです。「販売」プロジェクトを「製品」フォルダーと「発注」フォルダーで分割できます。

手順

1. 分割するフォルダーまたはネームスペースをクリックします。

2. 「プロジェクト」、「セグメントの作成」の順にクリックします。

プロジェクト名のデフォルト設定を受け入れることができます。

3. セグメントの名前を変更するには、「プロジェクト名」ボックスに別の名前を入力します。

この操作でフォルダー名が変わるわけではありません。フォルダーの名前を変更する場合は、セグメントを作成する前に「プロジェクト・ビューアー」で名前を変更する必要があります。

使い勝手上、フォルダーとセグメントの名前を両方とも同じにしておいてください。


「プロジェクト・ビューアー」が最新表示になり、セグメント化フォルダーまたはセグメント化ネームスペースを表すアイコンが表示されます。

リンクの作成リンクを作成する目的は、大きな各プロジェクトにわたる作業を編成しやすくすること、整合性を維持すること、および情報を再使用することです。


例えば、「在庫」というプロジェクトに「製品」というフォルダーが含まれているとします。「販売製品」から「在庫製品」へのリンクを作成できます。「在庫製品」フォルダーに対して行われた変更または追加は、「販売製品」フォルダーに表示されるようになります。

モデル・セグメントをリンクさせる場合は、モデル・セグメンテーションのためのステップに従うようにしてください。詳細については、 311 ページの『プロジェクトのセグメント化』を参照してください。

リンク・プロジェクトは他のプロジェクトによって共有されます。マスター・プロジェクト・ディレクトリー内のサブディレクトリーにリンク・プロジェクトを作成すべきではありません。

始める前に

プロジェクト、フォルダー、またはネームスペースにリンクするためには、それらを作成しておく必要があります。

リンクさせる各プロジェクトに、同じ設計言語と言語が定義されていなければなりません。

手順

1. 「プロジェクト・ビューアー」で、リンク先のプロジェクト、セグメント、ネームスペース、またはフォルダーをクリックします。

ヒント: フォルダー、ネームスペース、プロジェクト、またはセグメントへのリンクのみ作成できます。

2. 「プロジェクト」、「セグメントのリンク」の順にクリックします。

3. リンク先のオブジェクトが含まれるプロジェクトの .cpf ファイルを見つけてクリックします。

4. 「開く」をクリックします。

v 選択したプロジェクトのアップグレードが必要な場合は、プロンプトが出されます。詳細については、 437 ページの『第 12 章モデルのアップグレード』を参照してください。

v プロジェクトがマップ・ドライブ名を使用している場合は、マップ・ドライブ名を保持するか UNC パスに変更するかのプロンプトが出されます。

プロジェクトが他のプロジェクトによって共有される場合は、UNC パスを選択する必要があります。

5. リンク先のプロジェクト、セグメント、ネームスペース、またはフォルダーを選択します。

v 別のプロジェクトにリンクするには、「プロジェクトを追加」をクリックし、.cpf ファイルを見つけて「開く」をクリックします。プロジェクトを選択し、「追加」をクリックします。

v セグメントにリンクするには、セグメントをクリックし、「追加」をクリックします。



「プロジェクト・ビューアー」に新しいフォルダーが表示されます。

読み取り専用プロジェクトの利用プロジェクトに対して不要な変更が加えられないようにしつつ、他の開発者が読み取り専用プロジェクトを利用できるようにすることができます。

プロジェクトの読み取り専用化は、ファイル・プロパティーを変更することによって行えます。プロジェクトが読み取り専用になると、ユーザー・インターフェースに変化が生じます。グレー化された名前、プロパティー、または操作は、変更不可であることを示します。

手順

1. 保護されるプロジェクトをホストする共有を作成します。

2. プロジェクトを利用する開発者すべてに対してその共有への読み取り専用アクセス権限を付与します。

外部リポジトリーによる管理IBM Cognos Framework Manager を外部ソース管理システムと共に使用できます。この手順は、Framework Manager プロジェクト・ファイルを外部リポジトリーに入れる方法を説明したものです。 Framework Manager でプロジェクトの作業をし、外部リポジトリーでプロジェクト・ファイルのバージョン管理を行えます。

外部ソース管理システムを使用するには、以下のようにします。

v プロジェクトを閉じておきます。

v repository.xml ファイルが存在する場合は削除します。

v プロジェクト・ディレクトリーに存在するファイルをすべて外部リポジトリーに追加します。

プロジェクト・ディレクトリーとは、プロジェクト名.cpf ファイルが入っているディレクトリーのことです。

v 外部リポジトリーからプロジェクト・ファイルをチェックアウトします。

v Framework Manager でプロジェクトの作業をします。

v 変更を保存します。

v 外部リポジトリーにプロジェクト・ファイルをチェックインします。

プロジェクトのセグメント化

外部リポジトリーに保管されるプロジェクトのセグメントを作成できます。セグメントとは、メインプロジェクト・ディレクトリーの下に保管されるプロジェクト・ディレクトリーのことです。プロジェクト・ディレクトリーと同じ階層をリポジトリーで維持してください。

セグメントはスタンドアロン・プロジェクトとして個別に開くことができます。

メインプロジェクトの一部としてセグメントを開くこともできます。その場合は、変更するセグメントごとにプロジェクトをチェックアウトする必要があります。


メタデータの管理モデル化の特定の目標を満たすようにモデルのメタデータを変更することができます。

以下を実行することができます。

v レポート作成環境でプロジェクトを分かりやすく整理するために、プロジェクトのコピー、移動、名前の変更、または削除を行う。

v モデルに対して加えられた変更がモデルを使用するパッケージおよびレポートに与える影響を調べるために分析する。

v オブジェクトを新規ソースに再マップする。

v モデルをエクスポートし、異なるデータ・ウェアハウス・ツールおよびリポジトリーの間でメタデータを交換する。

v 異なるデータのセットで同じモデルおよびレポートを再利用する。

v モデルを 1 つのリレーショナル・データベースから別のリレーショナル・データベースに移動する。

プロジェクトのコピー、移動、名前変更、または削除プロジェクトは、簡単に見つけることができるように分りやすく整理してください。 IBM Cognos Framework Manager 内で、プロジェクトをコピー、移動、名前変更、および削除できます。

セグメント化およびリンクを使用してプロジェクトを管理できます。これらのプロジェクト管理機能は、ビジネス・ルールおよび組織上の必要に基づいてプロジェクトを編成し、実行時の処理オプションを設定し、他のユーザー・アクセスをプロジェクトのセクションに付与するのに役立ちます。詳細については、 313 ページの『セグメントの作成』および 313 ページの『リンクの作成』を参照してください。

プロジェクトにインポートする各データ・ソースで使用するためのベンダー固有の機能を特定することもできます。詳細については、 350 ページの『関数セットの選択』を参照してください。

プロジェクトがセグメント化されている場合、セグメントはスタンドアロン・プロジェクトとして扱われます。既存のプロジェクト内のプロジェクトを保存またはコピーする場合、それはセグメントとして扱われます。

プロジェクトのコピープロジェクトをコピーするときは、そのプロジェクトのレプリカを別の場所に作成します。サブフォルダーを含め、プロジェクト・フォルダー内のすべてのファイルが、新しい場所にコピーされます。あるフォルダー内のプロジェクトに変更を加えても、その変更は他のフォルダー内のプロジェクトのコピーに反映されません。

セグメント化モデルをコピーすると、すべてのセグメントに加えてメインプロジェクトもコピーされます。

プロジェクトをコピーできないために、代わりに「名前を付けて保存」を使用しなければならない場合もあります。既存の名前でプロジェクトを保存すると現行プロジェクトに上書きされますが、新規名でプロジェクトを保存すると新しいプロジェ


クト・フォルダーが作成されます。この操作は、読み取り専用プロジェクトに加えた変更を保存する場合や、元のプロジェクトに上書きせずにプロジェクトを別の名前で保存したり新しい場所に保存したりする場合に有用です。

元のフォルダーと同じフォルダーにプロジェクトのコピーを作成することはできません。既存のプロジェクト・フォルダーの下にプロジェクトをコピーした場合、Framework Manager はそれをプロジェクト・セグメントのように扱います。詳細については、 310 ページの『セグメント化プロジェクトとリンク・プロジェクト』を参照してください。

プロジェクトまたはセグメントがコピーするときに開いている場合は、最後に保存されたバージョンがコピーされます。

手順

1. 「ファイル」、「プロジェクトの管理」、「コピー」の順にクリックします。

2. 「元」ボックスで参照ボタンをクリックし、コピーするプロジェクトの .cpf ファイルを選択します。

注: プロジェクト・フォルダー名は、テキスト・ボックスに表示されます。

3. 「先」ボックスに、プロジェクト名を入力します。

デフォルトでは、プロジェクト名とプロジェクトが保存されるディレクトリーは同じです。

4. 「場所」ボックスで、新しい場所を入力するか、参照ボタンをクリックしてプロジェクトの新しい場所を選択します。


プロジェクトの移動フォルダー内のプロジェクトの数が増えすぎてプロジェクトを探しにくくなった場合、プロジェクトを他の場所に移動することもできます。プロジェクトを移動する際、実際には、プロジェクトを新規フォルダーにコピーし、現行フォルダーから削除していることになります。プロジェクト・フォルダー内のすべてのファイル (サブフォルダーも含む) が、その新しい場所に移動されます。

セグメント化されたモデルを移動すると、すべてのセグメントとメイン・プロジェクトが移動されます。

プロジェクトを移動する前に、Framework Manager でプロジェクトを閉じる必要があります。

手順

1. 「ファイル」、「プロジェクトの管理」、「移動」の順にクリックします。

2. 「元」ボックスで参照ボタンをクリックし、移動するプロジェクトの .cpf ファイルを選択します。


3. 「先」ボックスに、新しい場所を入力するか、参照ボタンをクリックして新しいプロジェクトの場所を選択します。



プロジェクトの名前変更プロジェクトの名前を変更する際、.cpf ファイルに新規名を指定します。プロジェクトの場所は変更しません。 2 次プロジェクト・ファイルおよびログ・ファイルに元の名前が保持されます。

Framework Manager の「ようこそ」ページの最新プロジェクト・リストにプロジェクトが表示され、その名前変更に進む場合、リンクをクリックしてプロジェクトを開くことはできません。プロジェクトは、「ファイル」メニューの「開く」コマンドを使って開く必要があります。

プロジェクトの名前を変更する前に、Framework Manager でプロジェクトを閉じる必要があります。

手順

1. 「ファイル」、「プロジェクトの管理」、「名前を変更」の順にクリックします。

2. 「元」ボックスで参照ボタンをクリックし、名前を変更するプロジェクトの.cpf ファイルを選択します。


3. 「先」ボックスにプロジェクトの新規名を入力し、「OK」をクリックします。

元のプロジェクト・フォルダーと .cpf ファイルの名前が同じである場合、フォルダーと .cpf ファイルの両方の名前が変更されます。

プロジェクトの削除プロジェクトを削除する際、プロジェクト・フォルダーおよびそのすべてのコンテンツ (存在するすべてのユーザー・ファイルを含む) がファイル・システムから削除され、ごみ箱に送られます。

プロジェクトがセグメント化されている場合にメイン・プロジェクトを削除すると、セグメントも削除されます。プロジェクトのセグメントを削除すると、セグメントだけが削除されます。その基になるモデルは削除されません。

一般に、セグメントはモデル内から削除します。「ファイル」メニューの「削除」を使ってセグメントを削除すると、セグメントがモデル内に引き続き存在しているかのように表示されます。詳細については、 310 ページの『セグメント化プロジェクトとリンク・プロジェクト』を参照してください。

プロジェクトを削除する前に、プロジェクトおよびそのすべてのセグメントが閉じられていることを確認してください。 Framework Manager はファイル・ロック・メカニズムをサポートしていないため、特定の状況下では、セグメントが開いているプロジェクトを削除することができます。セグメントが開いているプロジェクトを削除すると、今後セグメントを保存できなくなります。

手順

1. 「ファイル」、「管理」、「プロジェクト」、「削除」の順にクリックします。

2. 「プロジェクト・フォルダー」ボックスで参照ボタンをクリックし、削除するプロジェクトの .cpf ファイルを選択します。




プロジェクト・フォルダーおよびそのすべてのコンテンツが削除されます。

パッケージ変更の影響の分析パッケージを発行してレポートを実行する前に、モデルに加えた変更がパッケージとそれを使用するレポートにどのような影響を与えるかを調べることができます。パッケージに加えられた変更を検出し、それぞれの変更の詳細と、選択した特定の変更の影響を受けるレポートを調べることができます。

パッケージを使用して作成されるレポートは、モデルに加えた変更の影響を受ける場合があります。例えば、パッケージに新しいオブジェクトを追加しても、レポートに影響を与えません。クエリー・アイテムの名前を変更すると、確実にレポートに影響を与えます。そのクエリー・アイテムがパッケージ定義に存在しないため、レポート定義は有効ではなくなります。永続モデル機能を使用する場合は、クエリー・アイテム名の変更がレポートに与える影響を回避できます。詳細については、204 ページの『永続的なモデル』を参照してください。

注: レポートは発行済みパッケージを使用するので、モデルに変更を加えても、それを使用するパッケージを発行しなければ、レポートは変更の影響を受けません。

オブジェクトの名前を変更した場合は、分析の結果に「変更」として表示されます。

分析は、モデルが直接使用するオブジェクトだけでなく、基礎オブジェクトに対しても行われます。例えば、データ・ソース・クエリー・サブジェクトに基づいたモデル・クエリー・サブジェクトがあるとします。モデル・クエリー・サブジェクトを変更すると、変更されたオブジェクトとして表示されます。データ・ソース・クエリー・サブジェクトを変更した場合も、変更されたオブジェクトとして表示されます。

分析されるオブジェクトのタイプとして、クエリー・サブジェクト、クエリー・アイテム、数値データ、標準ディメンション、数値データ・ディメンション、階層、レベル、独立したフィルター、独立した計算があります。

手順1. 「プロジェクト・ビューアー」で、発行されたパッケージをクリックします。

2. 「操作」、「パッケージ」、「発行の影響を分析」の順にクリックします。

3. 以下の中から目的の処理を選択します。

目的操作

レポートの従属関係を表示する 320 ページの『レポートの従属関係の検索』を参照してください。

オブジェクトの従属関係を表示する 320 ページの『オブジェクトの従属関係を表示』を参照してください。


目的操作

オブジェクトの詳細を調べるオブジェクトが含まれる行をクリックします。

オブジェクトの詳細が「変更の詳細」項目に表示されます。

「プロジェクト・ビューアー」でオブジェクトを検索する

オブジェクトが含まれる行で、「操作」の「プロジェクト・ビューで検索」をクリックします。

結果をソートする列の上部にある「ソート」をクリックします。

モデル作成者のコメント、最終変更者、および最終変更日を表示する

二重下矢印をクリックします。


レポートの従属関係の検索オブジェクトを使用するレポートを検索することができます。

手順

1. 「発行の影響を分析」ダイアログ・ボックスから、次のいずれかを実行します。

v 個々のチェック・ボックスをオンにすることにより、レポートの従属関係を判別する各オブジェクトを選択します。

v チェック・ボックス列の最上部にあるチェック・ボックスをオンにすることにより、すべてのオブジェクトを選択します。

2. 「レポートの従属関係を検索」をクリックします。

3. 検索範囲を指定します。

目的操作

すべてのフォルダーを検索する「すべてのフォルダー」をクリックします。

検索を特定のフォルダーに制限する「制限された検索 (フォルダーを参照して選択)」をクリックします。フォルダーの名前を入力するか「参照」をクリックしてフォルダーを検索します。

4. 「検索」をクリックします。

レポート名のリストが「レポートの従属関係」ウィンドウの「影響を受けるレポート」の下に表示されます。直接的な従属関係と間接的な従属関係の両方が結果に示されます。レポートに間接的に影響を与えるオブジェクトの名前はより明るい色で表示されます。

5. 結果をソートするには、列の上部にある「ソート」をクリックします。


オブジェクトの従属関係を表示他のオブジェクトに従属するオブジェクトを検索したり、子オブジェクトの従属関係を表示したりすることができます。


パラメーター・マップの従属関係を表示することはできません。

手順

1. 「プロジェクト・ビューアー」で、オブジェクトをクリックします。

2. 「ツール」、「オブジェクトの従属関係を表示」をクリックします。

選択されたオブジェクトに従属するオブジェクトが「従属オブジェクト」の下に表示されます。

3. 従属オブジェクトのオブジェクト ID を表示するには、「オブジェクト ID を表示」チェック・ボックスをオンにします。

4. オブジェクトが子を持ち、子オブジェクトの従属関係を表示する場合、子オブジェクトを含むオブジェクトの横にある正符号 (+) をクリックします。

5. 親オブジェクトの下の子オブジェクトをクリックします。

子オブジェクトに従属するオブジェクトが「従属オブジェクト」の下に表示されます。

6. オプション: 以下の方法でオブジェクトの従属関係を表示することもできます。

v 「プロジェクト・ビューアー」で、オブジェクトを右クリックし、「オブジェクトの従属関係を表示」を選択します。

v 「コンテキスト・エクスプローラー」ウィンドウで、オブジェクトを右クリックし、「オブジェクトの従属関係を表示」を選択します。

v 「発行の影響を分析」ウィンドウで、オブジェクトを含む行の「操作」の下の「依存関係の表示」アイコンをクリックします。

新規ソースへのオブジェクトの再マップIBM Cognos Framework Manager モデルのライフサイクル中、使用するデータ・ソースの変更が必要になる場合があります。例えば、同じデータを持つ別のデータベースに対してモデルを使用したり、トランザクション・スキーマからスター・スキーマまたはスノーフレーク・スキーマにモデルを移行したり、既存のデータベースまたはインポート・ビューを新規ビューに置換したりする場合があります。これらの操作はすべて、レポートに影響を与える可能性があります。例えば、オブジェクトの名前を変更すると、レポートが無効になる場合があります。

より高いレベルのモデル・オブジェクトを再マップし、実行が継続されて正しいデータが返されるようにすることにより、モデルの変更やデータ・ソースの変更による影響を最小限に抑えることができます。再マップする際、元のオブジェクトのオブジェクト参照または名前を、別のオブジェクトのオブジェクト参照または名前にマッチングおよび置換します。クエリー・アイテムおよび数値データを再マップすることができます。個々のオブジェクトを手動で再マップすることも、複数のオブジェクトを同時に再マップすることもできます。複数のオブジェクトを再マップする際、Framework Manager は指定するマッチング条件を使って、元のオブジェクトのアイテムを他方のオブジェクトのアイテムにマッチングします。マッチング条件と一致するオブジェクトだけが再マップされます。元のオブジェクトと他方のオブジェクトのどちらにも、マッチング条件としてオブジェクト名またはオブジェクト参照を使用することができます。


再マップのマッチング条件を変更する際、後続のオブジェクトへの再マップに使用する条件を指定することになります。

モデル・クエリー・サブジェクトまたはモデル・ディメンションにフィルターまたは計算が含まれる場合、その再マップの際にモデルのフィルターまたは計算も再マップされます。これに関するメッセージや警告は出されません。

モデルに対して変更を行う際は常に、影響を受けるレポートをすべて検証します。影響を受けるレポートの識別については、 320 ページの『オブジェクトの従属関係を表示』および 320 ページの『レポートの従属関係の検索』を参照してください。

データ・ソース・クエリー・サブジェクトまたはデータ・ソース・ディメンションを再マップすることはできません。再マップは、モデルの設計ロケールを使用する場合にのみサポートされます。

手順1. 「プロジェクト・ビューアー」で、オブジェクトを右クリックし、「新規ソース

に再マップ」を選択します。

2. マッチング条件を変更する場合、「オプション」をクリックし、次の操作を実行します。

v 再マップに使用するオブジェクト、および再マップする元のオブジェクトに対してマッチング条件を選択します。

オブジェクトのマッチングは、名前またはオブジェクト参照によって行えます。

v デフォルトの条件オプションは、再マップに使用するオブジェクトの場合は「名前により」で、再マップする元のオブジェクトの場合は「オブジェクト参照により」です。

v 「OK」をクリックします。

v 指定した条件を使用するには、「マッチング条件オプションを使用」チェック・ボックスをオンにします。

マッチング条件が「名前により」対「名前により」の場合、文字列内のスペースは削除されます。

オブジェクト参照が存在しない場合、オブジェクト名が使用されます。

3. 以下の 1 つ以上を実行します。

目的操作

個々のオブジェクトを手動で再マップする「使用可能なモデル・オブジェクト」の下のオブジェクトを、「クエリー・アイテム、数値データ、計算、およびフィルター」の下の再マップするオブジェクトにドラッグします。

オブジェクトの新しい値が「再マップ先」の下に表示されます。


目的操作

複数のオブジェクトを自動的に再マップする「使用可能なモデル・オブジェクト」の下のクエリー・サブジェクトを、「クエリー・アイテム、数値データ、計算、およびフィルター」の下の任意の行にドラッグします。

マッチング条件を満たすすべてのオブジェクトが再マップされ、その値が「再マップ先」に表示されます。

オブジェクトの式を変更するオブジェクトの横にある省略符号 (...) ボタンをクリックします。式の作成方法の詳細については、 166 ページの『計算の作成』を参照してください。

再マップ値を元のソース値に復元する復元するオブジェクトが含まれる行を右クリックし、「元の値に復元」を選択します。

選択されているオブジェクトの再マップ値と元の値をクリアする

オブジェクトが含まれている行をクリックし、「クリア」をクリックします。

すべてのオブジェクトの再マップ値をクリアする

「すべてクリア」をクリックします。

4. 再マップが終了したら、「OK」をクリックします。

メタデータのエクスポートIBM Cognos Framework Manager モデルを Common Warehouse Metamodel(CWM) ファイルとしてエクスポートすることができます。 CWM は異なるデータ・ウェアハウス・ツールおよびリポジトリーの間でメタデータを交換します。CWM メタモデルの各インスタンスは、XMI (.xml メタデータ交換) ドキュメントを使って交換されます。

Framework Manager モデルを Common Warehouse Metamodel (CWM) ファイルとしてエクスポートする際、結合、フォルダー、ネームスペース、プロンプト、および計算はエクスポートされません。エクスポートされるのは、クエリー・サブジェクト、クエリー・アイテム、および関数だけです。

CWM にエクスポートする際、デフォルト・オプションを使用します。このオプションは、メタデータのエクスポートを最適化します。このオプションの変更は、エクスポートに影響を与える特定の情報がある場合にのみ行ってください。エクスポート・オプションの詳細については、Meta Integration の Web サイトを参照してください。

エクスポート・パスに日本語を使用しないでください。

手順1. エクスポートするメタデータのルート・ネームスペースを右クリックし、「モデ

ルをエクスポート」をクリックします。

プロジェクトを保存するようプロンプトが表示されます。

2. エクスポート・ターゲットを選択します。


3. 「Framework Manager 固有のエクスポート・オプション」ダイアログ・ボックスで、目的のオプションをクリックします。

注: 通常はデフォルト・オプションを使用します。デフォルト・オプションは、メタデータ・インポートを最適化します。オプションを変更すると、予期しない結果が表示される場合があります。デフォルトのオプションに戻すには、「デフォルトを使用」をクリックします。


5. 「サード・パーティー固有のエクスポート・オプション」ダイアログ・ボックスで、「ファイル」オプションを使用して、エクスポート・メタデータが含まれているファイルを識別します。

必要な他のオプションをクリックします。

「オプションの説明」ウィンドウで、選択可能なオプションの説明を確認できます。オプションは、選択されるデータ・ソースに基づきます。詳しくは、データ・ソース・ベンダーの資料を参照してください。


入力の検証は、エクスポート・プロセス表示の結果として行われます。

7. 「次へ」、「終了」の順にクリックします。

プロジェクトの再使用同じモデルおよびレポートを、複数の異なる実際のデータのセットで使用しなければならないことがあります。複数の異なるデータベース、アカウント、または単一のデータベース内の複数のスキーマを、データ・セットにすることができます。

以下の状態のとき、複数のデータ・セットを扱うことがあります。

v 実動で使用するものとは別のデータ・セットを使用するとき。

v 各部署に独自のデータ・セットがある大きな企業。

v 顧客データを直接制御できない OEM アプリケーション。

プロジェクトで使用される表および列は、すべてのデータ・セットで論理的に同一のものでなければなりません。さらに、それぞれのケースで正しいデータ・セットが識別されていることを確認する必要があります。

IBM Cognos Framework Manager 内のデータ・ソースは、クエリー・サブジェクトに必要なすべてのデータ・ソース表のロケーションを識別する情報を含んでいます。この情報は、Content Store 内のデータ・ソースの名前、およびオプションのカタログ名とスキーマ名です。カタログ名およびスキーマが適切なデータ・セットを使用していることを確認してください。

複数の異なる Content Store が使用されていて、各 Content Store に異なるバージョンのプロジェクトが配布されている場合は、各サイトのプロジェクトにデータ・ソース情報を指定できます。 Content Store が 1 つだけの場合、各プロジェクトを別個のパッケージとして発行できます。これらのソリューションでは、多くの手作業での保守が必要となります。保守のレベルを軽減するために、以下のいずれかのオプションを使用できます。


データ・ソース情報の判別

最も簡単なソリューションは、Content Store 内のデータ・ソースの名前、カタログの名前 (該当する場合)、およびデータベース内のスキーマの名前を決めておくことです。これらの名前を、すべてのデータ・セットで使用できます。

いくつかのデータ・セットが同じ Content Store を使用する場合、各データ・セットのために別個の接続を単一の Content Store 内に作成します。詳細については、「IBM Cognos 管理およびセキュリティー・ガイド」を参照してください。Framework Manager が複数の接続を扱う方法について詳しくは、 41 ページの『複数のデータ・ソース接続』を参照してください。

Content Store 内のデータ・ソースの名前を顧客データベースの名前とは異なるものにできるので、このソリューションは大きな柔軟性を提供します。ただし、それでもカタログ名とスキーマ名とは、すべてのデータ・セットで同じにする必要があります。これを保証することは、すべてのデータ・セットが同じデータベース・タイプを使用する場合でも困難です。異なるデータベース・タイプが含まれる場合、それは不可能となることがあります。例えば、SQL Server にはカタログ・レベルがありますが、Oracle にはそれがありません。

ユーザー・ベースのデフォルト・データ・セット ID の使用

各データベース・ユーザーには、デフォルトのスキーマおよびカタログ (該当する場合) に対するアクセス権限があります。スキーマおよびカタログが定義されていない場合、またはそれらが Framework Manager プロジェクト・データ・ソースでブランクになっている場合には、デフォルトが使用されます。前のソリューションと同様に、このオプションを複数の接続と結合させることができるので、複数の異なるユーザーが、同じデータ・ソースに複数の異なるデータベースを使用できます。

しかし、クエリー・サブジェクトを編集するときは、IBM Cognos FrameworkManager はカタログ名およびスキーマ名をデータ・ソース内で使用して、それらをデータ・ソース・ツリーから SQL ウィンドウにドラッグしたアイテムとマッチさせます。この理由で、モデルの作成中に、プロジェクト・データ・ソース内でカタログ名およびスキーマ名をブランクにすることはできません。

そのため、プロジェクト内の各データ・ソースのカタログおよびスキーマでは、マクロ式を使用する必要があります。これにより、カタログ名またはスキーマ名が実行時にはブランクとなりますが、モデル作成の際に必要なカタログまたはスキーマが明示的に設定されます。

カタログまたはスキーマを明示的に設定する手順

手順

1. デザイン・モードにあるかどうかを示す値を持つ単一セッション・パラメーターを作成します。デザイン・モードにある場合、このセッション・パラメーターの値を特定の値に設定します (design など)。デザイン・モードにない場合、値を空のままにしておきます。

ヒント: プロジェクトを使用するか、値をオーバーライドする場合、編集のためにモデルを開くたびにそれを設定する必要があります。


2. 各プロジェクト・データ・ソースのカタログおよびスキーマに、以下を含むパラメーター・マップを作成します。

v 空のデフォルト値。

v その名前が上記セッション・パラメーターの設計値であるキー、およびその値がそのデータ・ソースのデザイン・モードのカタログまたはスキーマの名前であるキー。

3. データ・ソースを選択し、カタログおよびスキーマのプロパティー値を、対応するパラメーター・マップおよびセッション・パラメーターを使用するマクロで置き換えます。

コマンドの使用例を次に示します。

#$DBSchemaName ($DeployOrDesign) #

モデル移植性IBM Cognos Framework Manager モデルを使用して、別のデータベース・インスタンスのデータにアクセスすることができます。データベース・インスタンスは同じベンダーからのものと、別のベンダーからのものの場合があります。

Framework Manager モデルを 1 つのリレーショナル・データベースから別のリレーショナル・データベースに移動する際に考慮すべき点がいくつかあります。同一プラットフォーム上の同一のデータベース間の変更とは異なり、データ・ソース接続情報の変更だけでは不十分な場合があります。

インデックスに基づいて行列式および関係を生成することを検討し、インデックスの信頼性がレポート作成のための関数的従属関係または関係の説明になるとは考えないでください。

SQL ステートメントでカタログまたはスキーマ修飾が先頭に付けられたモデルにスカラー関数がインポートされます。テーブルやビューと同じように、ベンダーを切り替える際にロケーション修飾を削除したり変更したりしなければならなくなる場合があります。例えば、ORACLE データベースに対してモデルを作成し、同等のSQL Server データベースを指すように接続が変更されると、エラーになります。適切なデータ・ソース・タイプに変更されず、モデル・データ・ソース・タイプはOR のままとなるからです。

モデルを 1 つのリレーショナル・データベースから別のリレーショナル・データベースに移動するには、次の操作を実行します。

v DDL (データ定義言語) を評価し、以下を行うことにより、物理名の移植性を判別します。

– 物理名を最小公分母に制約する (31 文字など)。

– ANSI 規格およびベンダー資料の予約キーワードの使用を避ける。

– ベンダー固有のデータ・フィールドの使用を避ける。

– 変換を避ける。

– 精度および小数部桁数がすべてのベンダーでサポートされていることを確認する。

– 一貫性および互換性のある照合を使用する。

– 名前における大/小文字の使用を統一する (例えば、すべて小文字など)。


v DDL を評価し、データベース修飾の移植性を判別します。

v DDL を評価し、データ型の互換性および精度と小数部桁数に関して、データ型の移植性を判別します。

v モデルおよびレポート内のネイティブ SQL ステートメントを調べ、サポートされるまたはサポートされないリレーショナル固有の構文について確認します。

v ベンダー固有の関数の使用について検討します。

同等のベンダー関数または共通関数が存在しない場合があります。共通関数がリレーショナル・データベースでサポートされていないと、以前は発生しなかったローカル処理が発生する場合があります。

v データ・ソースのプロパティー・タイプを検討します。

使用する RDBMS を変更する場合 (例えば Oracle から SQL Server に変更する場合)、Framework Manager でデータ・ソースのタイプ・プロパティーを変更します。

v データ・ソース・クエリーを更新します。

テーブルをインポートする際、Framework Manager は、実行時に内部的に使用されるテーブルおよび列に関する物理情報をインポートします。例えば、照合順序は、物理テーブルを再作成することによってのみ調整されます。

v 移動したモデルをテストします。

テストによってのみ明らかになる他の差異も存在します。例えば、パフォーマンス特性や、照合に基づいてデータを配列する方法などです。

ログ・ファイルを使用してモデルを別の環境に移動するIBM Cognos Framework Manager では、プロジェクトに対して実行された操作を表示して再生することや、Script Player を使用してトランザクションをバッチ・モードで再生することができます。操作ログは、トランザクションのセットを含むXML ファイルです。各トランザクションには、シーケンス番号と 1 つ以上の操作があります。各操作は、名前と入力パラメーターから成ります。いくつかの操作には出力パラメーターもあります。操作ログ・ファイルはプロジェクト・フォルダーにあります。

例えば、テスト環境でプロジェクトに変更を行ったとします。プロジェクトを実稼働環境に移動するときに、ログ・ファイルを使用してテスト環境で実行したすべての操作 (または一連の操作) を再生することにより、実稼働環境に同じプロジェクトを作成できます。

次の 2 つの操作ログ・ファイルがあります。 log.xml ファイルには、実行されてプロジェクトに保存されたすべてのトランザクションが含まれています。このファイルは、初めてプロジェクトを保存したときに作成され、プロジェクトを削除するまで存続します。一時ファイルには、現行セッションで実行して保存していないトランザクションが含まれます。一時ファイルは、プロジェクトを閉じるときに削除されます。

注: スクリプトに既存のプロジェクトへの従属関係がある場合は、適切な結果を得るために、プロジェクトがスクリプト・トランザクションに合わせて調整されていることを確認してください。


ログ・ファイルが大きいと、パフォーマンスに影響する可能性があります。ログ・ファイル内の項目をアーカイブして、サイズを削減することができます。

トランザクション履歴の表示と保存:

操作ログ・ファイルのトランザクション履歴を表示し、それをスクリプトとして保存することができます。

手順

1. 「プロジェクト」、「トランザクション履歴の表示」の順にクリックします。

ヒント: ダイアログ・ボックスを大きくするには、キャプションをダブルクリックします。もう一度ダブルクリックすると、ダイアログ・ボックスが元の大きさに戻ります。

2. 目的のトランザクション番号をクリックします。

ヒント: トランザクションの詳細を表示するには、トランザクション番号の横の正符号 (+) をクリックします。

3. 「スクリプトとして保存」をクリックします。

4. ファイルの名前を入力します。

5. 「保存」をクリックします。ファイルを logs フォルダーには保存しないでください。


ログ・ファイルからのトランザクションの再生:

特定のトランザクションを再生するか、プロジェクトまたはセグメント・アクション・ログ・ファイルのトランザクションの組み合わせを再生するかを選択することができます。

ログ・ファイルからトランザクションを再生する際、スクリプト・プレイヤーはログ・ファイルのコマンドを既存のモデルの内容に適用します。ログ・ファイルによって作成されるオブジェクトがモデルに既に存在する場合、エラーが表示されます。

ログ・ファイルのスクリプトが正常に実行された後、元のプロジェクトのバックアップがプロジェクトの親ディレクトリーに作成されます。スクリプトで実行されたトランザクションを元に戻す場合、バックアップを使用してプロジェクトをその元の状態に復元することができます。

モデルの内容と競合するコマンドがあれば、それを無効にするか、クリアする必要があります。その後、スクリプトを再実行することができます。あるいは、「同期」コマンドを使用することもできます。これは空モデルで開始します。

Framework Manager を使用せずに独自のスクリプトを生成する場合、重複なしでタイム・スタンプを昇順にする必要があります。

手順

1. 「プロジェクト」、「スクリプトの実行」の順にクリックします。

2. 必要なスクリプトを選択し、「開く」をクリックします。


3. トランザクションの詳細を表示する場合、トランザクションをクリックします。

4. 必要な開始点または停止点を設定します。

v スクリプトを実行するための開始点を設定するには、スクリプトを選択し、「開始点の設定」をクリックします。これは、命令をスキップしたり、既に実行済みの命令を実行したりするために、いつでも行うことができます

。v スクリプトの停止点を設定するには、スクリプトを選択し、「停止点の設

定」をクリックします。

スクリプトを停止して手動で修正を行い、再び開始することができます。

ヒント: 停止点を削除するには、「停止点の削除」をクリックします。

5. ツールバー・ボタンを使って、実行する操作を選択します。

ボタン説明

スクリプトを実行します。

エラーが発生した後、このボタンをクリックすると、失敗した命令の再実行が試行されます。

次のトランザクションにスキップし、スクリプトを最後まで実行します。

選択されたトランザクションだけを実行します。

次のトランザクションにスキップし、停止します。ただし、トランザクションの実行は行われません。

スクリプトが実行されると、「プロジェクト」ウィンドウが更新されます。

6. スクリプトによってエラーが検出された場合、オブジェクトを再ターゲット化するか、必要に応じて一時プロジェクトを変更することにより、エラーを修正します。

詳細については、 332 ページの『無効なオブジェクトによって生じたエラーの修正』を参照してください。

7. スクリプトが完了したら、「承諾」をクリックして変更を受け入れるか、「元に戻す」をクリックして変更を元に戻します。

注: 「承諾」または「元に戻す」をクリックした後、現行セッションで「元に戻す」および「やり直し」を使用できなくなります。

バッチ・モードでの操作ログの実行:

ScriptPlayer の使用:

構文

コマンド・プロンプトで、BmtScriptPlayer.exe のインストール場所まで確実にナビゲートします。


以下の構文を使って Script Player を実行します。

BmtScriptPlayer [-c|-m] <projectname> [-a <actionlogname>][options]

ここで <projectname> はプロジェクトの名前、<actionlogname> は操作ログの名前です。

例えば、次のようになります。

BmtScriptPlayer -m goSales.cpf -a import.xml

オプション

以下のオプションを使用すると、Script Player の実行方法を指定できます。

UNIX 環境で操作している場合、コマンド行で渡される資格情報を非表示にするために、スクリプトを作成することができます。

-a FILEPATH

指定した操作ログを適用します。

FILEPATH は操作ログ・ファイルのパスです (ファイル名を含む)。

-b NUM

NUM で指定される数値と同じ、またはより大きいシーケンス番号を使ってトランザクションを実行します。

デフォルトは、最初のトランザクションです。

-c FILEPATH

新しいプロジェクトを作成します。

FILEPATH はモデル・プロジェクト (.cpf) ファイルのパスです (ファイル名を含む)。

操作ログを指定せずにこのオプションを使用した場合、空のモデルが作成されます。

FILEPATH で指定したモデルが既に存在する場合、警告なしで置換されます。

-e NUM

NUM で指定される数値と同じ、またはより小さいシーケンス番号を使ってトランザクションを実行します。

このオプションを指定しない場合、最大のシーケンス番号を持つトランザクションまたはトランザクション番号 9999 のうち、先に現れるトランザクションにおいて実行が終了します。シーケンス番号 10,000 以上のトランザクションを含む操作ログでは、このオプションを使用する必要があります。

-g

モデルをアップグレードします (必要な場合)。

このオプションを指定しない場合、以前のバージョンで作成されたモデルであれば、実行が終了します。

操作ログを指定せずにこのオプションを指定した場合、モデルのアップグレードだけが実行されます。


-h 経過時間をミリ秒で指定します。このオプションは、Unix オペレーティング・システムや Linux オペレーティング・システムでは使用できません。

-i FILEPATH

認証情報が含まれるファイルのパス (ファイル名を含む) を指定します。

-k DIRECTORY

インストール・ディレクトリーを指定します。

-l FILEPATHScript Player を実行するときに使用するオプションを含むファイルに、パスを指定します (ファイル名を含む)。

-L オブジェクト ID ログ (IDLog.xml) を作成しないことを指定します。このオプションは、Unix オペレーティング・システムや Linux オペレーティング・システムでは使用できません。

-m FILEPATH

既存のプロジェクトを開きます。

FILEPATH はモデル・プロジェクト (.cpf) ファイルのパスです (ファイル名を含む)。

-n

モデルを保存しません。

このオプションは、操作ログ・ファイルをテストする場合に使用できます。

-p PASSWORD

指定したパスワードを使って認証します (必要な場合)。

-s NAMESPACE

指定したネームスペースを使って認証します (必要な場合)。

-t DIRECTORY

テンプレート・ディレクトリーを指定します。

-T PASSWORD

セキュリティー・パスポートを指定します。パスポートとは、パスポートを必要とするプラグインでの対話を保護するために使われる暗号化文字列です。

-u USER

指定したユーザー名を使って認証します (必要な場合)。

-x

トランザクション・エラーが存在する場合、テスト実行を終了します。

デフォルトでは、(無効なモデルや操作ログなどの) 重大エラーの場合にのみ、Script Player が終了します。軽微なトランザクション失敗の場合は実行を続けます。

-y PASSPORT

指定したパスポートを使って認証します (必要な場合)。

このオプションは、他に指定された資格情報 (-s、-p、および -u) をオーバーライドします。 Script Player は認証をスキップして、指定されたパスポートをセッションに関連付けます。


-z アクション出力パラメーターを使用して、拡張アクション・ログを作成します。

例

この表は、Script Player コマンドの例をいくつか示しています。

表 12. Script Player コマンドの例

コマンド説明

BmtScriptPlayer -c <projectname> プロジェクトを作成します。

BmtScriptPlayer -c <projectname>-a <actionlogname>

プロジェクトを作成して、操作ログからすべてのトランザクションを適用します。

BmtScriptPlayer -c <projectname>-a <actionlogname> -b2 -e20

プロジェクトを作成して、番号 2 から 20までのトランザクションを操作ログから適用します。

BmtScriptPlayer -m <projectname>-a <actionlogname> -e20

既存のプロジェクトを開いて、番号 1 から20 までのトランザクションを操作ログから適用します。

BmtScriptPlayer-m <projectname>-a <actionlogname> -n

既存のプロジェクトを開いて、操作ログからすべてのトランザクションを適用します。プロジェクトを保存しません。

無効なオブジェクトによって生じたエラーの修正:

トランザクションによって参照されるオブジェクトが存在しなくなっているか、またはそのオブジェクトを名前変更した場合、スクリプト・ファイルを実行するときやモデルを検証するときにエラーが発生することがあります。

オブジェクトが存在しなくなっている場合、欠落しているオブジェクトを別のオブジェクトに再ターゲットします。

スクリプトの使用

スクリプトの使用中にオブジェクトを再ターゲットした場合、残りのスクリプト・トランザクションはすべて新しいオブジェクトを使用します。別の理由でスクリプトが停止した場合は、一時プロジェクトを変更して問題を修正する必要があります。

注: メインのプロジェクトに変更を加えてエラーを修正すると、予期しない結果が生じることがあります。常に一時プロジェクトを変更してエラーを修正してください。

スクリプトでエラーが生じたときは、問題を解決する方法を選択できます。


解決策操作

このオブジェクトを含むトランザクションをスキップする

「除外」をクリックして、「このオブジェクトを使用するトランザクションの除外(Exclude Transactions that Use thisObject」ダイアログ・ボックスで、任意の除外レベルを選択します。

現在のトランザクション、および除外されたオブジェクト参照するすべての後続のトランザクションは無視されます。例えば、トランザクションが除外されたオブジェクトを使用するパッケージを作成しようとしても、そのパッケージは作成されません。注: トランザクションをスキップする前に、エラーを修正する必要があります。

オブジェクトの今回の出現および後続のすべての出現を置き換える

「置換」をクリックして、「欠落したオブジェクトの置換 (Replace Missing Objects)」ダイアログ・ボックスで、任意のオプションを選択します。

手動で問題を修正する「停止」をクリックしてから、一時プロジェクトで問題を修正します。

オブジェクトの再ターゲット

トランザクションが存在しなくなったオブジェクトを参照する場合、スクリプトは停止して、問題のあるオブジェクトの名前を示すダイアログ・ボックスが表示されます。「置換」をクリックして新しいオブジェクトを選択することにより、オブジェクトを再ターゲットできます。

欠落したオブジェクトが式の中に示されている場合、スクリプトは停止して、問題のあるオブジェクトの名前を示すダイアログ・ボックスが表示されます。欠落したオブジェクトを含む式を開いて、問題を手動で修正する必要があります。

スクリプトで発生した他のエラーの修正

一時プロジェクトを変更して、スクリプトのエラーを修正する必要があります。メインのプロジェクトに変更を加えてエラーを修正すると、予期しない結果が生じることがあります。

ヒント: 「同期」ダイアログ・ボックスを移動または最小化して、プロジェクトを表示および変更することができます。

ログ・ファイル・エントリーのアーカイブ時間の経過と共に、プロジェクトのログ・ファイルは大きくなることがあります。大きなログ・ファイルは、ログ・ファイルの操作時は特に、IBM CognosFramework Manager のパフォーマンスに影響を与える場合があります。ログ・ファイル内のエントリーの一部を削除して、archive-log.xml ファイルの内容に付加することができます。 Framework Manager は、選択されたトランザクションより前のすべてのログ・ファイル・エントリーをアーカイブします。選択されたトランザクションはアーカイブされません。


アーカイブされたトランザクションは、プロジェクトの同期化の際に使用できます。詳細については、『プロジェクトの同期』を参照してください。

アーカイブされたトランザクションは、トランザクション履歴に表示されなくなります。これらのトランザクションは、プロジェクトの分岐やマージの際に使用できません。例えば、分岐プロジェクトでは、アーカイブされたトランザクションはメインプロジェクトにマージバックする際に使用できません。

手順

1. 「プロジェクト」、「トランザクション履歴の表示」の順にクリックします。

2. アーカイブする最後のトランザクションの後に行われたトランザクションのエントリーをログ・ファイルで見つけます。

現行ログ・ファイル内の選択したトランザクションより前のすべてのトランザクションが、アーカイブされます。

3. 「ログ・ファイルをアーカイブ」をクリックします。

プロジェクトの同期IBM Cognos Framework Manager ログ・ファイルを使用して、プロジェクトを同期化することができます。

以下の場合は、プロジェクトを同期化するようにすることもできます。

v 別のパーティー・モデル作成ツールでメタデータを更新した。

v 多次元モデル作成ツールを使用してメタデータに変更を加えた。

プロジェクトを同期化するときは、元のプロジェクトで行ったすべての操作をログ・ファイルから再生することによって、新しいプロジェクトを作成します。

セグメント化モデルまたはリンク・モデルが含まれるプロジェクトを同期化する前に、特別な考慮が必要です。

データ・ソースがリレーショナル・データベースである場合は、クエリー・サブジェクトのみ更新でき、完全プロジェクト同期を行う必要はありません。他のデータ・ソースで行われた変更を同期化するには、プロジェクト同期を実行する必要があります。

データ・ソースのサブセットをインポートする場合、データ・ソースに追加された新しいオブジェクトは、同期化の際に含められません。操作ログには、もともと指定したオブジェクトのインポートが記録されています。同期化の際は、もともとインポートされたオブジェクトだけが再インポートされます。

プロジェクト同期を使用して、モデルの完全操作履歴を実行し、モデルのメタデータを更新できます。操作ログの一部を、後で使用するために別個のスクリプト・ファイルに保存することもできます。また、同じモデルをバッチ・モードで構築する場合は、操作ログ全体をスクリプト・ファイルに保存することができます。操作ログ・スクリプトを実行しようとしてエラーが発生した場合は、 332 ページの『無効なオブジェクトによって生じたエラーの修正』を参照してください。


同期化の後、新しい変更を受け入れて新規プロジェクトを作成するか、あるいは元のプロジェクトに戻るかを選択できます。新しい変更を受け入れる場合は、元のプロジェクトが置き換えられます。

プロジェクトで行ったすべての操作が再実行されるため、同期化には長時間を要する場合があります。

トランザクションによって参照されるオブジェクトが、名前変更されたか削除されたために、存在しなくなっている場合は、同期化の過程でエラーを受け取ります。例えば、Products という名前のテーブルをインポートした後、そのテーブルをデータ・ソースで New Products という名前に変更した場合、プロジェクトを同期化するときにエラーを受け取ります。 New Products という名前のテーブルが以前に別の名前を使用してインポートされたことは、同期化では検出できません。オブジェクトを手動で再ターゲット化して、同期化を完了する必要があります。同期エラーの修正については、 332 ページの『無効なオブジェクトによって生じたエラーの修正』を参照してください。

注: IBM Cognos ReportNet の操作ログは、このリリースではサポートされていません。

プロジェクトの同期化の前に、同期化がセグメント化モデルおよびリンク・モデルに与える影響を理解しておく必要があります。また、データ・ソース接続が変わっていないこと、およびデータ・ソースがオンラインであることを確認する必要があります。キー・クエリー・サブジェクトをいくつかテストすることにより、接続を確認できます。

セグメント化モデル

セグメント化モデルは、メインプロジェクトを同期化する方法だけで同期化する必要があります。プロジェクト全体の同期化の結果は、メインプロジェクトのログ・ファイルに書き込まれます。個々のセグメントの同期化機能は、メインプロジェクトの最初の同期化後に失われます。

メインプロジェクトで作業中にセグメントを変更した場合は、メインログ・ファイルが更新されます。セグメントで作業中に変更を行った場合は、セグメント・ログ・ファイルが更新されます。

同期コマンドが必ずしもログ・ファイルで示される順序で実行されるとは限りません。これは、複数のセグメントを並行して更新する可能性があり、元の操作の時刻に基づいて操作ログが再生されるからです。ログ・ファイル間をジャンプするためのコマンドが表示されることがあります。その場合は、単一ステップ実行などのデバッグ機能が使いにくくなります。

リンク・モデル

ログ・ファイルは、更新されたモデルではなく、開かれているプロジェクトに含まれます。


メインプロジェクトを開き、リンク・モデルに変更を加えた場合、操作はメインプロジェクトのログ・ファイルに記録されます。その後リンク・モデルを同期化すると、変更は失われます。同期化で使用されたログ・ファイルのセットに変更が示されていないからです。

同期化は、メインプロジェクトまたはスタンドアロン・セグメントに対してのみ実行できます。メインプロジェクト内のリンクされたプロジェクトまたはセグメントを同期化することはできません。セグメントがリンク・プロジェクトによって更新された場合、同期化によって予測不能な結果がメインプロジェクトに生じる可能性があります。

モデル同期化をリンク・プロジェクトと組み合わせて使用しないでください。

同期する手順

手順1. 「プロジェクト」、「同期」の順にクリックします。

2. 「プロジェクトをこのディレクトリーにバックアップ」チェック・ボックスをオンにすることにより、Framework Manager プロジェクトのバックアップを作成することができます。

3. トランザクションの詳細を表示する場合、トランザクションをクリックします。

4. 必要な開始点または停止点を設定します。

v スクリプトを実行するための開始点を設定するには、スクリプトを選択し、「開始点の設定」をクリックします。これは、命令をスキップしたり、既に実行済みの命令を実行したりするために、いつでも行うことができます

。v スクリプトの停止点を設定するには、スクリプトを選択し、「停止点の設

定」をクリックします。

スクリプトを停止して手動で修正を行い、再び開始することができます。

ヒント: 停止点を削除するには、「停止点の削除」をクリックします。

5. ツールバー・ボタンを使って、実行する操作を選択します。

ボタン説明

スクリプトを実行します。

エラーが発生した後、このボタンをクリックすると、失敗した命令の再実行が試行されます。

次のトランザクションにスキップし、スクリプトを最後まで実行します。

選択されたトランザクションだけを実行します。

次のトランザクションにスキップし、停止します。ただし、トランザクションの実行は行われません。


スクリプトが実行されると、「プロジェクト」ウィンドウが更新されます。

6. スクリプトによってエラーが検出された場合、オブジェクトを再ターゲット化するか、必要に応じて一時プロジェクトを変更することにより、エラーを修正します。

詳細については、 332 ページの『無効なオブジェクトによって生じたエラーの修正』を参照してください。

7. スクリプトが完了したら、「承諾」をクリックします。

元のプロジェクトは一時プロジェクトの内容に置き換えられます。

ヒント: プロジェクトを前の状態に戻すには、「元に戻す」をクリックします。

クエリー動作IBM Cognos Framework Manager プロジェクト内のクエリーの動作を監視および調整することにより、モデルのパフォーマンスを向上させることができます。

次のいずれかのステップを実行できます。

手順1. システム・リソース要件が減るようにガバナーを設定し、パッケージのメタデー

タに適切な制限が含まれるようにすることにより、パフォーマンスを向上させます。例えば、取得されるデータ量やクエリーにかかる時間に対して制限を設定することができます。詳細については、 338 ページの『ガバナー』を参照してください。

2. 集計の計算をローカルで行うか、データベースで行うかを指定します。リレーショナル・メタデータについては、適切なタイプのクエリー処理を選択することによって、パフォーマンスを向上させることができます。レポートを初めて実行した後、クエリー再利用機能をオンにすることにより、データベースを再クエリーすることなくレポートを作成することができます。詳細については、 346 ページの『自動集計が処理される場所の指定』を参照してください。

3. クエリー処理タイプを設定して SQL 処理をデータベース・サーバーで実行するかローカルで処理するかを決めることにより、パフォーマンスを向上させます。詳細については、 346 ページの『クエリー処理タイプの設定によるパフォーマンスの改善』を参照してください。

4. ストアード・プロシージャーを含むクエリー・サブジェクトのトランザクション・モードを指定し、クエリー・サブジェクトをすべての Studio/Authoringツールで使用できるようにします。詳細については、 349 ページの『トランザクション・モードの指定』を参照してください。

5. レポート実行時にキャッシュ・データを再利用することにより、パフォーマンスを向上させます。キャッシュ・データを再利用することにより、データベースを再クエリーせずにレポートを作成することができます。詳細については、 347ページの『レポートを実行する際にキャッシュ・データを再使用してパフォーマンスを改善する』を参照してください。

6. プロジェクトで定義されているデータ・ソースのベンダー固有の関数セットを選択します。詳細については、 350 ページの『関数セットの選択』を参照してください。


7. プロジェクト内のデータ・ソースに基づいて個々の関数の動作を指定します。詳細については、 351 ページの『サービス品質』を参照してください。

8. IBM Cognos Framework Manager のメタデータ・ウィザードを使って作成されたデータ・ソースのプロパティーを変更することにより、クエリーの実行方法を制御および最適化します。詳細については、 353 ページの『クエリーの制御および最適化』を参照してください。

ガバナーガバナーは、システム・リソース要件を削減し、パフォーマンスを向上させるために使用します。パッケージを作成する前にガバナーを設定して、指定した制限をパッケージ内のメタデータに含めます。それ以降に発行されるすべてのパッケージは、この新しい設定を使用します。


新規プロジェクトでは、モデルのガバナーには値が定義されていません。必要であれば、「ガバナー」ウィンドウを開き、設定を変更する必要があります。「ガバナー」ウィンドウで「OK」をクリックして値を保存すると、ガバナーの値が設定されます。 Reporting でガバナーを設定することもできます。Reporting でのガバナー設定は、モデルでのガバナー設定をオーバーライドします。

動的クエリー・モード (DQM) 固有のガバナーについては、 360 ページの『動的クエリー・モードのガバナー』を参照してください。

レポート・テーブルの最大数

ユーザーがクエリーまたはレポートで取得できるテーブルの数を制御できます。取り出されたテーブルは、クエリーまたはレポートに表示されるたびにカウントされます。固有テーブルの数が制限ではありません。クエリーまたはレポートがテーブル数の設定制限を超えると、エラー・メッセージが表示され、クエリーまたはレポートはデータなしで表示されます。

ゼロ (0) と設定すると、制限が設定されないことを意味します。

注: このガバナーは、動的クエリー・モードでは使用されません。

取得した行の最大数

クエリーまたはレポートで返される行数を制御することによって、データ取得制限を設定できます。行は取り出されるたびにカウントされます。

レポートを実行していてデータ取得制限を超えると、エラー・メッセージが表示され、クエリーまたはレポートはデータなしで表示されます。

このガバナーを使用して、クエリー・サブジェクト・テストまたはレポート設計モードで取り出されるデータの制限を設定することもできます。



クエリー・サブジェクトを外部化した場合、モデルを発行するときはこの設定は無視されます。詳細については、 291 ページの『外部化されたクエリー・サブジェクトおよびディメンション』を参照してください。

クエリー実行時間の限度

クエリーが使用できる時間を制限できます。事前設定した秒数に達すると、エラー・メッセージが表示されます。



大規模テキスト・アイテムの上限

ユーザーがクエリーまたはレポートで取得できる BLOB (バイナリー・ラージ・オブジェクト) の文字長を制御できます。 BLOB の文字長が設定制限を超えると、エラー・メッセージが表示され、クエリーまたはレポートはデータなしで表示されます。


外部結合

クエリーまたはレポートで外部結合を使用できるかどうかを制御できます。外部結合では、1 つのテーブルに一致する行がなくても、もう 1 つのテーブルのすべての行が取り出されます。このタイプの結合では、非常に大規模でリソース集中のクエリーやレポートになる可能性があります。

ガバナーは、デフォルトでは外部結合を拒否するように設定されています。例えば、Framework Manager でクエリー・アイテムをテストするときに、外部結合は自動的には生成されません。

以下の場合に SQL が自動的に生成されます。

v レポートを実行する。

v Framework Manager でクエリー・アイテムまたは関係をテストする。

v 他のオブジェクトに基づいて新しいモデル・クエリー・サブジェクトを作成する。

設定を「拒否」のままにしておくと、外部結合を含んだ関係を「ダイアグラム」タブで作成する場合のみ通知されます。外部結合を含んだ関係をデータ・ソース・クエリー・サブジェクトで作成する場合は通知されません。

ガバナーを「許可」に設定した場合、ディメンション対ファクトの関係は、内部結合から外部結合に変更されます。

外部結合ガバナーは、以下の場合は適用されません。

v 他の手段で生成された SQL。このガバナーを「拒否」に設定した場合、データ・ソース・クエリー・サブジェクトで検出された永続 SQL には適用されません(SQL がインポートで生成された、手動で入力された、または既存オブジェクトに基づいたものであるかに関係ない)。


v Framework Manager がスティッチ・クエリーを作成するために外部結合を生成する必要がある。スティッチ・クエリーとは、ローカル処理された外部結合を使用して 2 つ以上のサブクエリーの結果をローカルに結合するクエリーのことです。

注: このガバナーは、SAP BW データ・ソースには適用されません。


製品を超えた結合

クエリーまたはレポートで製品を超えた結合を使用できるかどうかを制御できます。製品を超えた結合では、結合のないテーブルからデータが取り出されます。このタイプの結合では、データの取得に時間がかかる場合があります。

このガバナーのデフォルト値は「拒否」です。製品を超えた結合を許可するには、「許可」を選択します。

ショートカット処理

IBM Cognos ソフトウェアのショートカット処理を制御できます。

以前のリリースのモデルを開くと、「ショートカット処理」ガバナーは「自動」に設定されます。「自動」は、ターゲットと同じフォルダーにあり、別名つまり独立インスタンスとして動作するショートカットです。ただし、モデル内の他の場所にあるショートカットは、オリジナルへの参照として動作します。新しいモデルを作成すると、「ショートカット処理」ガバナーは常に「明示的」に設定されます。

ガバナーを「明示的」に設定した場合、ショートカット動作は「Treat As」プロパティーから取り込まれます。「ショートカット処理」ガバナーが「自動」に設定されている場合は、モデルを検証し、修復時にガバナーを「明示的」に変更してください。これにより、「自動」設定が従う規則に基づいて、「Treat As」プロパティーの適切な値にすべてのショートカットが変更されます。

「ショートカット処理」ガバナーは、「Treat As」プロパティーよりも優先されます。例えば、ガバナーが「自動」に設定されている場合、ショートカットの動作は、「Treat As」プロパティーの設定に関係なく、ショートカットのそのターゲットとの相対的な場所によって決まります。

SQL 結合構文

以下の設定のいずれかを選択することにより、モデル内の内部結合のための SQL生成を制御できます。

v ガバナーを「サーバーで判別」に設定すると、CQEConfig.xml ファイルを使用してガバナーの値が決定されます。アクティブな CQEConfig.xml ファイルがない場合、または CQEConfig.xml ファイルにガバナーのパラメーター・エントリーがない場合は、「暗黙的」設定が使用されます。

v 「暗黙的」設定では、where 節が使用されます。



SELECT publishers.name, publishers.id,books.title FROM publishers, books WHERE publishers.id= books.publisher_id ORDER BY publishers.name, books.title;

v 「明示的」設定では、on 述語にキーワード inner join を含んだ from 節が使用されます。


SELECTpublishers.name, publishers.id,books.title FROM publishers INNER JOIN books ON publishers.id= books.publisher_id ORDER BY publishers.name, books.title;

Reporting のクエリー・プロパティーで結合タイプを設定することにより、このガバナーの値をオーバーライドできます。

このガバナーに使用する設定に関係なく、左外部結合、右外部結合、および完全外部結合には「明示的」設定が使用されます。

このガバナーは、入力された SQL には影響を与えません。

数値属性のグループ化 (クエリー・アイテム数)

ガバナーを「サーバーで判別」に設定すると、CQEConfig.xml ファイルを使用してガバナーの値が決定されます。アクティブな CQEConfig.xml ファイルがない場合、または CQEConfig.xml ファイルにガバナーのパラメーター・エントリーがない場合は、「無効」設定が使用されます。

「無効」設定は、属性の数値データの集計が行われないようにします。これはデフォルトの動作です。例えば、次のようになります。

select Product.Product_line_code as Product_line_code,Order_method.Order_method_code as Order_method_code,XSUM(Sales.Quantity for Product.Product_line_code) as Quantity from ...

「使用可能」設定は、属性の数値データの集計を許可します。注: これは、バージョン 8.3 より前の IBM Cognos Framework Manager のデフォルト動作です。

select Product.Product_line_code as Product_line_code,Order_method.Order_method_code as Order_method_code,XSUM(Sales.Quantity for Order_method.Order_method_code,Product.Product_line_code)as Quantityfrom ...

これらの例では、Order_method.Order_method_code as Order_method_code が数値データ属性を定義しています。

XSUM 構文が集計数値データを定義しています。

レベル属性の SQL 生成

あるレベル (メンバー・キャプション) の属性に対して生成される SQL での最小集計の使用を制御できます。

ガバナーを「サーバーで判別」に設定すると、CQEConfig.xml ファイルを使用してガバナーの値が決定されます。アクティブな CQEConfig.xml ファイルがない場


合、または CQEConfig.xml ファイルにガバナーのパラメーター・エントリーがない場合は、「最小」設定が使用されます。

「最小」設定は、属性の最小集計を生成します。この設定は、重複レコードの可能性がある場合にデータの整合性を確保します。例えば、次のようになります。

select XMIN(Product.Product_linefor Product.Product_line_code) as Product_line, //level attributeProduct.Product_line_code as Product_line_codefrom(...) 製品

「グループ化」設定は、属性の集計なしで group by 節にレベルの属性を追加します。 distinct 節は、射影のリストのすべてのアイテムに対する group by を示します。「グループ化」設定は、データに重複レコードがない場合に使用されます。マテリアライズ・ビューの使い方を向上させることができ、パフォーマンスの改善につながる場合があります。例えば、次のようになります。

select distinctProduct.Product_line as Product_line,//level attribute,Product.Product_line_codeas Product_line_codefrom(...) 製品


行列式属性の SQL 生成

グループ化プロパティーが有効な行列式の属性に対して生成される SQL での最小集計の使用を制御できます。

ガバナーを「サーバーで判別」に設定すると、CQEConfig.xml ファイルを使用してガバナーの値が決定されます。アクティブな CQEConfig.xml ファイルがない場合、または CQEConfig.xml ファイルにガバナーのパラメーター・エントリーがない場合は、「最小」設定が使用されます。

「最小」設定は、属性の最小集計を生成します。この設定は、重複レコードの可能性がある場合にデータの整合性を確保します。例えば、次のようになります。

select PRODUCT_LINE.PRODUCT_LINE_CODEas Product_line_code,XMIN(PRODUCT_LINE.PRODUCT_LINE_ENfor PRODUCT_LINE.PRODUCT_LINE_CODE)as Product_line //attributefromgreat_outdoors_sales..GOSALES.PRODUCT_LINE PRODUCT_LINEgroup byPRODUCT_LINE.PRODUCT_LINE_CODE //key

「グループ化」設定は、属性の集計なしで group by 節に行列式の属性を追加します。この設定は、データに重複レコードがない場合に使用されます。マテリアライズ・ビューの使い方を向上させることができ、パフォーマンスの改善につながる場合があります。例えば、次のようになります。

selectPRODUCT_LINE.PRODUCT_LINE_CODE as Product_line_code,PRODUCT_LINE.PRODUCT_LINE_EN as Product_line //attributefrom


great_outdoors_sales..GOSALES.PRODUCT_LINE PRODUCT_LINEgroup byPRODUCT_LINE.PRODUCT_LINE_CODE //keyPRODUCT_LINE.PRODUCT_LINE_EN //attribute

SQL パラメーター構文

このガバナーは、生成される SQL がパラメーター・マーカーを使用するかリテラル値を使用するかを指定します。

ガバナーを「サーバーで判別」に設定すると、CQEConfig.xml ファイルを使用してガバナーの値が決定されます。アクティブな CQEConfig.xml ファイルがない場合、または CQEConfig.xml ファイルにガバナーのパラメーター・エントリーがない場合は、「マーカー」設定が使用されます。

Reporting でこのガバナーの値をオーバーライドできます。

動的 SQL アプリケーションでは、値が後で与えられることを示すマーカーをテキストに含んだステートメントを準備することができます。これは、同じクエリーが異なる値で何度も使用されるときに最も効率的です。この手法を使用すると、データベースが SQL ステートメントを逐一解析しなければならない回数が減り、キャッシュ・ステートメントの再利用が増えます。ただし、クエリーがより複雑なステートメントで大量のデータをナビゲートする場合は、他のクエリーと一致する機会は低くなります。このような場合は、マーカーの代わりにリテラル値を使用すると、パフォーマンスが向上することがあります。

実行時の拡張モデル移植性を許可

このガバナーは、Cognos ReportNet 1.x モデルの初期アップグレード時に選択されます。メタデータでデータ型が更新されるまでは IBM Cognos モデルがReportNet 1.x モデルとして機能できるように、データ型が杓子定規に適用されるのを防止します。モデルが正常にアップグレードされたことを検証した後、このガバナーをクリアしてください。

初期アップグレードの場合以外にも、このガバナーには限定的使用法があります。例えば、あるデータ・ソース用にモデルを作成済みであり、そのモデルを別のデータ・ソースに対して実行したいとします。新しいデータ・ソースは元のデータ・ソースと構造的に似ていなければならず、2 つのデータ・ソースのデータベース・スキーマが同じでなければなりません。このガバナーを選択すると、IBM CognosAnalytics は、モデルに既にキャッシュされたメタデータを使用する代わりに、データ・ソースからメタデータを取得してキャッシュに入れます。新しいデータ・ソースに対するモデルの変更とテストを完了した時点で、このガバナーをクリアしてください。

このガバナーを使用しない場合は、元のデータ・ソースと新しいデータ・ソースで以下のメタデータが同じであることを確認する必要があります。

v 照合順序名

v 照合レベル

v 文字セット

v Null 可能性


v 精度

v スケール

v 列の長さ

v データ型

ローカル・キャッシュの使用を許可

このガバナーは、このモデルに基づいたすべてのレポートがキャッシュ・データを使用することを指定する場合に選択します。新しいモデルでは、このガバナーはデフォルトで有効になっています。

この設定は、モデルを使用するすべてのレポートに影響を与えます。モデルとは異なる設定をレポートが使用するようにする場合は、Reporting を使用してください。詳細については、 347 ページの『レポートを実行する際にキャッシュ・データを再使用してパフォーマンスを改善する』を参照してください。

ディメンション情報の動的生成を許可

このガバナーは、ReportNet 1.x モデルの初期アップグレード時にのみ選択されます。このガバナーは、データ・ソース内の関係、キー情報、インデックス情報からディメンション情報の形態を導き出すことにより、ReportNet 1.x との一貫性のある動作を可能にします。

SQL 生成時に WITH 節を使用

データ・ソースが With 節をサポートする場合は、IBM Cognos SQL で With 節を使用するようにすることもできます。

IBM Cognos Analytics で作成されるモデル用に、With 節をオンにします。アップグレードされたモデルの場合、この節は、アップグレード前に Cognos ReportNetモデルで明示的にオンになっていない場合、オフになります。

SAP BW データ・ソースの Null 値を消去

発行済みパッケージを使用するレポートまたは分析で Null を抑止するかどうかを制御できます。このガバナーは、現行 Framework Manager セッション中のテスト結果にも適用されます。SAP BW データ・ソースに対してのみサポートされます。

クエリーによっては、Null 値がフィルターで除外されないためにサイズが非常に大きくなることがあります。ヌル抑止が行われると、行または列のすべての値が Null(空) である行または列が削除されます。ヌル抑止は SAP BW によって行われます。これにより、IBM Cognos クライアント製品に転送されるデータ量が減少し、パフォーマンスが向上します。

デフォルトでは、Null 値は抑止されます。このガバナーをクリアすると、Null 値は抑止されなくなります。

Reporting に、このガバナーをオーバーライドする「消去」というプロパティーがあります。「消去」プロパティーを「なし」に設定した場合は、Null 値を抑止するようにガバナーが設定されていても、結果セットに Null 値が含まれます。


注: このガバナーは CSV ファイルの作成時は適用されません。したがって、データに Null 値がある場合は、CSV ファイルにも Null 値が含まれます。

発行時にモデル全体を処理

発行されるパッケージには、パッケージの作成時に選択されたモデル・オブジェクトが組み込まれます。さらに、それらのモデル・オブジェクトは、従属オブジェクトを識別してパッケージに組み込むために分析されます。

複雑なモデルや非常に大規模なモデルでは、分析にかなりの時間を要する場合があります。発行時間を短縮するには、このガバナーを設定して、このような分析ステップをスキップし、モデル全体が Content Store に書き込まれるようにします。必要なオブジェクトだけが発行されるのではなくモデル全体が発行されるので、結果のパッケージはサイズが大きくなる場合がありますが、発行に必要な時間は短縮されます。

モデルとマージ可能な外部データ・ソースの最大数 (Maximumexternal data sources that can be merged with a model)

外部データを使用するために、レポート・ユーザーは既存のパッケージにデータをインポートします。このガバナーは、インポートできる外部データ・ファイルの数を制御します。

デフォルトは、1 です。

外部データ・ソースについて詳しくは、「IBM Cognos Analytics - Reporting ユーザー・ガイド」を参照してください。

最大外部データ・ファイル・サイズ (KB) (Maximum external datafile size (KB))

外部データを使用するために、レポート・ユーザーは既存のパッケージにデータをインポートします。このガバナーは、各外部データ・ファイルのサイズを制御します。

デフォルトでは、レポート・ユーザーがインポートできる最大ファイル・サイズは2560 KB です。


最大外部データ行カウント (Maximum external data row count)

外部データを使用するために、レポート・ユーザーは既存のパッケージにデータをインポートします。このガバナーは、各外部データ・ファイルに存在できる行数を制御します。

デフォルトでは、レポート・ユーザーがインポートできる最大行数は、20000 です。



自動集計が処理される場所の指定データ・ソースの「自動集計処理」プロパティーによって、レポートの詳細レベルより上の自動集計の計算方法が決まります。ローカル・クエリー処理が有効な場合、デフォルトは「ローカル」に設定され、ローカル・クエリー処理が有効でない場合、デフォルトは「データベース」に設定されます。

注: このプロパティーは SAP BW データ・ソースには適用されません。

このプロパティーに指定できるオプションは以下のとおりです。

v 無指定

自動集計は指定されません。

v ローカル

自動集計はすべて、実行集計 (例えば RSUM など) を使ってローカル (レポート・サーバー) で計算されます。実行集計ではデータが取得されるため、この計算のコストがより多くかかります。このオプションは、使用されていないリソースがデータベース・コンピューターよりローカル・コンピューターの方が多い場合、またはそれが最も早い方法であることが経験を通して分かっている場合のみ使用してください。

v データベース

可能な場合、自動集計は基本データベース・ソフトウェアによって計算されます。可能でない場合はローカルで計算されます (ローカル・クエリー処理が有効な場合)。実行集計が使用されますが、コストはレポート・サーバーではなく、データベース・サーバーの負担となります。このオプションは、使用されていないリソースがローカル・コンピューターよりデータベース・コンピューターの方が多い場合、またはそれが最も早い方法であることが経験を通して分かっている場合のみ使用してください。

v 拡張

自動集計はすべて、拡張集計 (例えば XSUM) を使用してデータベース・サーバーで計算されます。拡張集計では、この計算の総コストが明らかになります。一般的に、これは最も早い方法ですが、それはデータベースがマテリアライズ・ビューを利用するようにセットアップされている場合だけです。 OLAP 機能がサポートされているデータベースでは、これは該当する OLAP 集約関数に変換されます。

手順1. 「プロジェクト・ビューアー」で、変更するデータ・ソースをクリックします。

2. 「プロパティー」ウィンドウの「自動集計処理」リスト・ボックスで、目的の集計処理のタイプを選択します。

クエリー処理タイプの設定によるパフォーマンスの改善データ・ソースのクエリー処理プロパティーにより、SQL 処理がデータベース・サーバーによって行われるか、またはローカルに処理されるかが決まります。リレーショナル・メタデータについては、適切なタイプのクエリー処理を選択することによって、パフォーマンスを向上させることができます。


クエリー処理には次の 2 つのタイプがあります。

v ローカルのみ

データベース・サーバーにおいて、SQL が可能な限り処理され、実行されます。しかし、一部のレポートまたはレポートのセクションでは、ローカルの SQL 処理が使用されます。

v データベースのみ

データベース・サーバーにおいて、すべての SQL が処理され、実行されます。レポートまたはレポートのセクションでローカルの SQL 処理が必要な場合は、エラーが表示されます。

通常、データベース・サーバーのほうが SQL やレポートをより高速に実行できますが、場合によりローカルな処理が必要となることがあります。例えば、データベースの交差結合を作成する場合や、サポートされていない SQL99 の機能の使用をユーザーに許可する場合は、「ローカルのみ」の処理を選択します。

二重カウントを防止するために At 節を生成する必要のあるクエリーなど、いくつかの複合クエリーではローカルのみの処理が必要です。

動的クエリー・モードのクエリー処理

動的クエリー・モードでは、クエリー処理の設定が SAP BW データ・ソースだけに影響を与えます。

v ローカルのみ

現時点では、「ローカルのみ」はサポートされていません。

v データベースのみ

レポート・サーバーによってクエリー処理はほとんど、おそらくまったく行われません。データベースがクエリーを処理できない場合に限り、ローカル処理が行われます。この値は、デフォルト設定ではレポートのパフォーマンスが不十分で、この設定を使用するとパフォーマンスが向上する場合に限り考慮してください。この設定を使用すると結果が変わる可能性があることに注意してください。結果が依然として正しいことを確かめるため、注意深くテストしてください。

「プロジェクト・ビューアー」で、変更するデータ・ソースをクリックします。「プロパティー」ウィンドウの「クエリー処理」リスト・ボックスで、「ローカルのみ」または「データベースのみ」のいずれかをクリックします。

レポートを実行する際にキャッシュ・データを再使用してパフォーマンスを改善する

レポートを実行すると、クエリー要求がデータベースに送られて、結果セットが返されます。最初のレポートの実行後に、レポートを変更することもあります。多くの場合、レポートは再びデータベースを照会しなくても作成できます。この機能を利用するためには、クエリーの再使用の機能をオンにします。

クエリーの再使用がオンになっているとき、レポートを初めて実行すると、クエリーはレポート・サーバー上のキャッシュに保管されます。また、いくつかのデー


タ・ソース・リソースは、それらを使用するトランザクションが解放されるまで使用可能にならないことがあります。現在のデフォルトのタイムアウトは 60 分です。特定のデータベース処理がデータベース・オブジェクトの変更を含んでいる場合は、タイムアウト期間が満了するまで待機するか、またはレポートのためのクエリーの再使用を無効にすることができます。

レポートを初めて実行するときにはキャッシュが作成され、応答時間が少し長くなることがあります。レポート利用者は後続のレポート実行のたびにパフォーマンスの向上を実感することができ、応答時間は最高で 80% ほど短縮されます。このようにパフォーマンスが向上するのは、レポートがデータベースを繰り返し照会する必要がなくなるためです。さらに、データベースを照会する数が削減されると全体的なシステム・パフォーマンスが改善されて、すべてのユーザーに有利な影響を与えます。

クエリーの再使用は、モデルまたは個別のレポートに対して設定できます。特定のモデルを使用するすべてのレポートがキャッシュ・データを使用するように指定するには、IBM Cognos Framework Manager でモデルの「ローカル・キャッシュの使用を許可」ガバナーを有効にして、モデルを再発行します。この設定はデフォルトで、IBM Cognos Viewer でレポートとして実行される分析を含む、このモデルを使用するすべてのレポートに影響を与えます。

IBM Cognos Viewer でのクエリーの再使用

レポートでモデルとは異なる設定を使用するには、IBM Cognos Analytics -Reporting を使用してください。「プロパティー」ウィンドウで、「ローカル・キャッシュを使用」プロパティーを変更します。常にクエリーを実行するには、プロパティーを「いいえ」に設定します。キャッシュの結果を使用するには、プロパティーを「はい」に設定します。レポートでモデルと同じ設定を使用するには、設定を「デフォルト」に変更します。

1 つのレポートの「ローカル・キャッシュを使用」プロパティーを変更しても、他のレポートは影響を受けません。

Query Studio でのキャッシュ・データの再使用

IBM Cognos Query Studio は、さまざまな条件のもとでキャッシュ・データを再使用します。モデルでクエリーの再使用がオンになっていて、キャッシュ・データ・セットのサブセットによってアクションを実行できる場合、レポートはキャッシュ・データを使用します。例えば、フィルターの追加や列の除去のようにレポートを変更するとレポート・データが変更されることがありますが、キャッシュ・データのサブセットによって要求を実行することができます。

クエリーの再使用がオフになっていても、キャッシュ・データ・セットによって変更なしでアクションを実行できる場合、レポートはキャッシュ・データを使用します。例えば、レポート形式の変更は、クエリーの再使用がオフになっていても以前のデータ・セットを使用します。これはカーソルの再使用と呼ばれます。カーソルの再使用は、キャッシュ・データによって変更なしで要求を実行できる場合に使用されます。


Query Studio で作成されたレポートは、モデルに指定されたものと同じ設定を常に使用します。モデルでクエリーの再使用がオンになっている場合、レポートはキャッシュ・データの使用を試行します。

特定の環境でクエリーの再使用を使用するかどうかを決める

クエリーの再使用をオンにするかどうかを決める前に、以下の点を検討してください。

v ほとんどのレポート利用者がレポートを対話式に実行し、1 回だけ実行する場合には、キャッシュ・データによる大幅なパフォーマンスの向上は期待できません。

注: クエリーの再使用の設定とは関係なく、バッチ・モードで実行されるレポートはデータをキャッシュに入れません。

v キャッシュのサイズは拡張性に影響を与えることがあります。例えば、レポートに大きな結果セットがある場合、キャッシュも大きくなります。これはサーバー環境のサイズを決めて構成する際に検討に含める必要があります。

トランザクション・モードの指定

ストアード・プロシージャーを含むクエリー・サブジェクトによって使用されるトランザクションのタイプを指定することができます。

デフォルトで、ストアード・プロシージャーを含むクエリー・サブジェクトは、読み取り専用トランザクションで実行されます。しかし、ストアード・プロシージャーに、読み取り/書き込みトランザクションを必要とする操作が含まれることもあります。「トランザクション・アクセス・モード」プロパティーと「トランザクション・ステートメント・モード」プロパティーにより、読み取り/書き込みトランザクションで実行されるクエリー・サブジェクトを、他のすべての Studio/Authoringツールで使用できるようになりました。

データ・ソースの「トランザクション・アクセス・モード」プロパティーは、新規トランザクションのアクセス・モードを指定します。以下のアクセス・モードのオプションがあります。

v 無指定 - 新規トランザクションはデフォルト・モードで開始されます。

v 読み取り専用 - 新規トランザクションは読み取り専用モードで開始されます。

v 読み取り/書き込み - 新規トランザクションは読み取り/書き込みモードで開始されます。

デフォルト: 動的クエリー・モードの場合、デフォルトは無指定です。互換クエリー・モードの場合、デフォルトは読み取り専用です。

制限: 動的クエリー・モードでは、「トランザクション・アクセス・モード」プロパティーは、ストアード・プロシージャーに基づくクエリー・サブジェクトでのみサポートされています。

「トランザクション・ステートメント・モード」プロパティーは、トランザクションが終了するときに取るアクションを指定します。以下のアクションを選択できます。


v 無指定 - トランザクションが終了するときに取るデフォルトのアクションを指定します。

v ロールバック - トランザクションは終了時にロールバックされます。

v コミット - トランザクションは終了時にコミットされます。

v 自動コミット - トランザクションが終了するときに自動コミットが実行されます。

デフォルト: ロールバック。基となるデータベースが自動コミットをサポートしている場合、デフォルトのアクションはコミットになります。

制限: 「トランザクション・ステートメント・モード」プロパティーは、動的クエリー・モードでは無視されます。

プロジェクト・ビューアーで、変更するデータ・ソースをクリックします。「プロパティー」ウィンドウの「トランザクション・アクセス・モード」リスト・ボックスと「トランザクション・ステートメント・モード」リスト・ボックスで、必要な設定をクリックします。

関数セットの選択ベンダー固有の関数の集合は、関数セットと呼ばれています。リレーショナル・メタデータを含むプロジェクトを作成する際、使用できるすべてのベンダーの関数セットが式エディターでリストされます。ただし、プロジェクトで使用するベンダーだけがリストされるように関数セットを制限することもできます。プロジェクトで定義されている各データ・ソースの固有のベンダーを識別することによって関数セットをカスタマイズします。

IBM Cognos Framework Manager のリレーショナル・データ・ソースで定義した関数を使用することができます。ユーザー定義関数をインポートした場合、選択しやすいように Framework Manager でリストされます。インポートしなかった場合、関数の名前を式に入力することができます。関数を修飾する必要がある場合、Framework Manager にインポートする必要があります。

ベンダー固有の関数の中には、幅広いアクセス権限を持つスキーマで作成されたものもあります。幅広いアクセス権限を持つスキーマと制限付きアクセス権限を持つスキーマの両方が同じデータベース・インスタンス上にある場合、幅広いアクセス権限を持つスキーマで作成された関数を制限付きアクセス権限を持つスキーマのIBM Cognos ソフトウェアで使用することはできません。

認識されない関数がレポートに入力される場合、その関数はネイティブ関数であると見なされます。詳細については、 114 ページの『ネイティブ SQL』を参照してください。

注: SAP BW メタデータを含むプロジェクトを作成する際、SAP BW データに適用される関数だけが Framework Manager によって自動的にリストされます。

手順1. 「プロジェクト」、「プロジェクトの関数リスト」の順にクリックします。

2. 「データ・ソース・タイプに基づいて関数リストを設定する」チェック・ボックスをオンにします。


ヒント: このフィルターを無効にするには、「すべての関数セットを含める」チェック・ボックスをオンにします。

3. 「関数セット」ページで、適切なデータ・ソース行をクリックします。

4. 「関数セット」フィールドのドロップダウン・リストから、このデータ・ソースで使用する関数セットを選択します。

5. 終了するまで手順 2 から 4 までを繰り返します。


サービス品質IBM Cognos Framework Manager を使用して、任意の組み合わせのデータ・ソース・タイプを照会できますが、すべてのデータ・ソースが同じ方法で関数をサポートしてはいません。サービス品質インジケーターは、開発者とユーザーに、個々の関数をモデル内のデータ・ソースと共に使用するときの動作に関する視覚的なヒントを提供します。

データ・ソースに指定された各関数には、使用されるデータ・ソースのタイプに応じて異なるサービス品質があります。複数のパッケージでサービス品質が同じではないクエリー機能については、クエリー機能ごとにサービスのレベルをオーバーライドして、そのモデルでの特定の状況について説明するテキストを追加できます。ユーザーはサービス品質インジケーターとコンテキスト固有の説明とを見て、レポートで使用する関数を決める際にこの情報を使用します。

サービス品質インジケーターをオーバーライドすることの影響

IBM Cognos Framework Manager は、データ・ソース・タイプに基づいて関数のサービス品質を決めます。モデルのコンテキストを考慮して、製品によって決められたサービス品質をオーバーライドすることができます。サービス品質をオーバーライドすることにより、ユーザーにガイダンスを提供できます。これにより、データ・ソースでのその関数のサポート・レベルが変わることはありません。

複数のサブパッケージが結合してパッケージが作成されているときは、親パッケージでのサービス品質のオーバーライドが優先されます。親のオーバーライドがない場合には、子パッケージのサービス品質が集計されます。

ユーザーの検討

最終的な目標は、ユーザーにビジネス要件を満たすための十分な情報を提供し、しかも混乱させるほど多くの情報は提供しないようにすることです。ユーザーがサービス品質インジケーターに基づいて使用する関数を決定できない場合は、異なるユーザーのグループに対して別個のパッケージを発行することを検討する必要があります。ユーザーが「制約なし」よりも小さいサービス品質を持つ関数へのアクセス権を必要とする場合は、サービス品質を設定するときにそれらの関数の制約を文書化しておく必要があります。

パフォーマンスに対する影響

サービス品質インジケーターは、クエリーのパフォーマンスに対して直接の影響を与えません。サービス・インジケーターの目的は、どの関数を使用可能とするかに


関していくらか制御できるようにすることです。そして、ユーザーが、実行時間の長いクエリーや失敗するクエリーを生じさせるような関数を使用しないようにできます。

データ・ソースでは使用できない関数を使用する場合、Framework Manager はレポート・サーバーでのローカル処理により補正を試行することに注意してください。そのための作業はデータ・ソース・サーバーではなくレポート・サーバーで行われるので、これはクエリーのパフォーマンスに影響を与えることがあります。

状態によっては、ローカルで処理を行うとデータ・ソース・サーバーからより多くのデータを取得する必要が生じるために、データ・ソース・サーバーとネットワークの両方が影響を受けることがあります。例えば、リレーショナル・データ・ソースでは OLAP 関数を使用できません。リレーショナル・データ・ソースで OLAP関数を使用しようとすると、Framework Manager はデータ・ソース内のディメンション情報を使用してローカル・キューブを生成し、そのキューブに対して OLAP関数を実行します。これにより、データ・ソース・サーバーからディメンション情報を取得すること、およびレポート・サーバーで追加の処理を行うことが必要になります。

サービス品質インディケーターの定義関数のサービス品質はデータ・ソース・レベルで指定され、パッケージ内の個々の関数に設定することも、すべての関数に設定することもできます。

設定可能なサービス品質インディケーターを次に挙げます。

v 使用不可 (X)

この関数は、パッケージ内のどのデータ・ソースに対しても使用できません。

v 制限された可用性 (!!)

この関数は、パッケージ内の一部のデータ・ソースに対しては使用できません。

v 制限されたサポート (!)

この関数はパッケージ内のすべてのデータ・ソースに対して使用できますが、そのデータ・ソースに対してそのままサポートされているとは限りません。IBMCognos ソフトウェアでは、その関数に近似したローカル関数が使用されます。近似した関数が使用されるので、パフォーマンスが悪かったり、結果が予期したとおりにならなかったりする可能性があります。

v 制約なし (チェック・マーク)

この関数はすべてのデータ・ソースに対して使用できます。

モデルに複数のタイプのデータ・ソースが存在する場合、サービス品質の値は、以下の規則に従って集計されます。

v あるデータ・ソースのサービス品質が「制約なし」、「制限されたサポート」、または「制限された可用性」として定義され、別のデータ・ソースでは「使用不可」として定義される場合、その関数のサービス品質は「制限された可用性」になります。

v それ以外の場合はすべて、最小の公分母が使用されます。例えば、あるデータ・ソースのサービス品質が「制約なし」で、別のデータ・ソースでは「制限された


サポート」の場合、その関数のサービス品質は「制限されたサポート」になります。あるデータ・ソースのサービス品質が「制限されたサポート」で、別のデータ・ソースでは「制限された可用性」の場合、サービス品質は「制限された可用性」として報告されます。

手順

1. 「プロジェクト」、「プロジェクトの関数リスト」、「サービス品質を定義」の順にクリックします。

2. ツリー・ノードを展開し、各関数のサービス品質を表示します。

3. サービス品質をオーバーライドするには、各関数の横の矢印をクリックし、リストからサービス品質インディケーターを選択します。

4. サービス品質を変更した後、関数に関する詳しい情報を右側のテキスト・ボックスに追加できます。

ユーザーはこの情報を使用して、レポートでこの関数を使用するかどうかを決定できるようになります。

ヒント: サービス品質をデフォルトに戻すには、「オーバーライドを削除」をクリックします。


クエリーの制御および最適化IBM Cognos Framework Manager のメタデータ・ウィザードを使用して作成したデータ・ソースのプロパティーを変更することができます。データ・ソースのプロパティーは、クエリーをデータベースに対して実行する方法を制御および最適化するために役立ちます。

ポータルを使用して作成したデータ・ソースのプロパティーは変更できません。これらのデータ・ソースは、ポータルでのみ変更できます。詳細については、「IBMCognos 管理およびセキュリティー・ガイド」を参照してください。

データ・ソース・プロパティー説明

名前作成時にユーザーが指定したデータ・ソース接続の記述名。

クエリー処理 SQL 処理がデータベース・サーバーによって行われるかまたはローカルに処理されるかを決めます

集計処理集計計算がローカルに計算されるかまたはデータベース内で計算されるかを決めます

トランザクション・アクセス・モード新規トランザクションのアクセス・モードを指定します。詳細については、 349 ページの『トランザクション・モードの指定』を参照してください。


データ・ソース・プロパティー説明

トランザクション・ステートメント・モードトランザクションが終了するときに取るアクションを指定します。詳細については、349 ページの『トランザクション・モードの指定』を参照してください。

Content Manager データ・ソース Content Manager 内で示されるデータ・ソースの名前を指定します。 XML データ・ソースを使用する場合、このプロパティーはパラメーター化できます。

カタログさまざまなデータベースのさまざまな情報を表します。例えば、データベースが SQL サーバーの場合、この要素にはデータベースの名前が含まれます。データベースが Oracleの場合、これは使用されません。

キューブキューブの名前を指定します。

スキーマさまざまなデータベースのさまざまな情報を表します。例えば、SQL Server またはOracle の場合、この要素には所有者の名前が含まれます。

タイプ親オブジェクトのタイプを指定します。

クエリー・タイプこのデータ・ソースが認識可能なクエリー・モデルのタイプを指定します。例えば、SQLソースはリレーショナルで、MDS ソースは多次元です。

クエリー・インターフェースこの要素には、プロバイダー・タイプを示す2 文字が含まれます。これはアプリケーションによって保守されます。

関数セット ID データ・ソースに適用される関数セットを定義します。パッケージが作成されるとき、セキュリティー・ビューに関数セットを最初に取り入れるために使用されます。

パラメーター・マップ Oracle Essbase 別名テーブル・マップを表すparameterMap を参照します。


第 9 章動的クエリー・モードの使用

動的クエリー・モードでは、改善されたクエリー実行手法によりクエリーおよびデータ・ソースが最適化されており、複雑なクエリー、多量のデータ、および適時性への期待に対応できます。

リレーショナル・データ・ソースの場合、動的クエリー・モードによって、JDBC接続、64 ビットの接続、メモリー内キャッシュ機能が提供されます。ディメンションでモデル化されたリレーショナル・データ・ソースの場合、JDBC 接続、64 ビットの接続、メモリー内キャッシュ、Null 消去の最適化、マスター詳細の最適化の機能が提供されます。

動的クエリー・モードは、多数のリレーショナル・データ・ソースと OLAP データ・ソースで使用できます。動的クエリー・モードでサポートされているデータ・ソースの最新リストについては、サポート対象のソフトウェア環境(www.ibm.com/support/docview.wss?uid=swg27047186) Web サイトを参照してください。

ヒント: XML データ・ソースを動的クエリー・モードで使用することはできません。

動的クエリー・モードは、IBM Cognos Analytics の新規アプリケーションに推奨されます。ただし、既存の IBM Cognos Framework Manager プロジェクトに対しても動的クエリー・モードを有効にできます。既存のアプリケーションを動的クエリー・モードに移行する場合は、モデルを調整し、移行先のレポートとの差異を解決するようにレポートを変更する必要があります。レポートの差異は、クエリーの動作の変更のために生じます。例えば、ソート、集計、および消去を変更する場合は、既存のレポートを変更する必要があります。動的クエリー・モードでベスト・プラクティスおよびクエリー構文の制約をより強化すると、移行先のレポートで警告やエラーが表示される可能性があります。

IBM Cognos Analytics バージョン 11.0.x 以前で動的クエリー・モードを使用して作業する方法について詳しくは、IBM Redbooks® 資料 IBM Cognos DynamicQuery (http://www.redbooks.ibm.com/abstracts/sg248121.html) を参照してください。

動的クエリー・モードがもたらす効果

次の表に、動的クエリー・モードがもたらす効果の概要を組織内のユーザー役割ごとに示します。


http://www.ibm.com/support/docview.wss?uid=swg27047186

http://www.redbooks.ibm.com/abstracts/sg248121.html


表 13. ユーザー役割と動的クエリー・モードが組織にもたらす効果

役割ビジネス上の問題解決策

IT 責任者およびデータ・プロフェッショナル

Java™ ベースのアーキテクチャーを使用しているか、あるいは移行しようとしており、データ・ソースへの JDBC またはJava 接続が必要です。

OLAP データ・ソースへの Java接続、XMLA 接続、および数多くのリレーショナル・データ・ソースへの JDBC 接続を使用して、広範なデータ利用を可能にします。

IT 責任者および IT管理者

64 ビット・コンピューターのみをサポートするデータベース・ベンダーが増えてきています。64 ビット・テクノロジーに対して行った投資をアプリケーションで生かしたいと考えています。

メモリー管理機能が優れ、スケーラビリティーとパフォーマンスの高い 64 ビット環境をサポートします。

モデル作成者およびIT 責任者

ビジネス・ユーザーは、情報を見てすぐに答えを得たいと考えています。IT 責任者としては、アプリケーションのセキュリティーを維持しつつこの機能を実現したいと考えています。

メモリー内キャッシュ機能では、各ユーザーのセキュリティー権限を維持しつつ、クエリー計画とクエリー結果の両方を保存できます。結果として、ビジネス・ユーザーはセキュリティー上の危険を冒すことなく情報を迅速に得ることができます。

Cognos Analytics 部門責任者および IT 責任者

OLAP およびリレーショナル・テクノロジーにこれまでに投資をしており、その投資を最大限に活用して最大の効果を引き出したいと考えています。

特定のバージョンの OLAP テクノロジーに関して、MDX をカスタマイズおよび拡張することによって、OLAP データ・ソースへのアクセスが最適化されています。

リレーショナル・データ・ソースの SQL 生成を最適化します。

Cognos Analytics 管理者

クエリーの計画および実行時に起きることのトラブルシューティングを簡単に行うのはたやすいことではないと感じています。

Dynamic Query Analyzer を使用したログの可視化とトラブルシューティングによって、詳細なログ記録とクエリーの視覚化を行います。

Framework Manager モデルおよびパッケージが動的クエリー・モードを使用できるようにする

モデルを作成し、動的クエリー・モードを有効にして IBM Cognos Analytics にパッケージを発行することができます。

モデルとパッケージは、動的クエリー・モードによってサポートされているデータ・ソースを使用する必要があります。サポートされているデータ・ソースとサポートされていないデータ・ソースが混在しているパッケージが動的クエリー・モードを有効にして発行されると、レポート作成コンポーネントと Studio/Authoringツールでそのパッケージを開いたときにエラーが表示されます。


動的クエリー・モードは、サポートされているデータ・ソースを使用する新規Framework Manager プロジェクトで有効にすることができます。「動的クエリー・モードの使用」プロジェクト・プロパティーは、そのプロジェクト内のすべてのモデル操作を制御するグローバル設定です。プロジェクト・レベルで有効になっていると、モデル・オブジェクトの検証、クエリー・サブジェクトのテスト、データの更新やインポート、およびパッケージの発行は、すべて自動的に動的クエリー・モードを使用して実行されます。パッケージを使用するすべてのレポートも動的クエリー・モードを使用して実行されます。

既存のプロジェクトのクエリー・モードを変更するには、「クエリー・モード」プロジェクト・プロパティーを「動的」または「互換」に設定します。

Framework Manager パッケージでの動的クエリー・モードの使用が有効になると、そのパッケージを使用しているすべてのレポートは動的クエリー・モードを使用して実行されます。「動的クエリー・モードの使用」オプションをクリアした状態でパッケージを再発行することで、互換クエリー・モードに戻すことができます。

プロジェクトで互換クエリー・モードが使用されていても、パッケージの発行、クエリーとディメンションのテストには、動的クエリー・モードを使用することができます。動的クエリー・モードを使用してクエリーをテストするには、「動的クエリー・モードの使用」チェック・ボックスを選択します。動的クエリー・モードを使用してパッケージを発行するには、発行ウィザードの最後のページにある「動的クエリー・モードの使用」チェック・ボックスを選択してください。「発行」をクリックしたときに、この選択について確認を求められます。


以下の手順は、Framework Manager を使用してプロジェクト、接続、およびパッケージを作成するプロセスを示しています。データ・ソース接続など、このプロセスの特定の部分は、Cognos Analytics 管理インターフェースでも行えます。詳しくは、「IBM Cognos Analytics 管理およびセキュリティー・ガイド」を参照してください。

手順1. Framework Manager を開き、「新規プロジェクトの作成」を選択します。

2. 「新しいプロジェクト」ダイアログ・ボックスで、プロジェクトの名前と場所を指定し、「動的クエリー・モードの使用」チェック・ボックスを選択します。

3. プロジェクトの設計言語を選択し、「OK」をクリックします。

4. メタデータ・ウィザードで、「データ・ソース」をメタデータ・ソースとして選択し、「新規」をクリックして、リレーショナル・データ・ソースへの接続を作成します。

5. 「名前」フィールドに、接続の名前を入力します。

6. 「タイプ」リストから、必要なリレーショナル・データベース (IBM DB2 または Oracle) を選択するか、OLAP クライアント (Oracle Essbase またはIBM Cognos TM1 など) を選択します。

第 9 章動的クエリー・モードの使用 357

7. リレーショナル・データベースの場合のみ、「JDBC 接続の設定」チェック・ボックスが選択されていることを確認します。

8. データベース管理者から提供される接続情報に基づいて、適切な情報を入力します。認証タイプを選択し、該当する場合はサインオン資格情報を構成します。

9. リレーショナル・データベースの場合のみ、「database (JDBC) 接続文字列(database (JDBC) connection string)」ダイアログ・ボックスで、サーバー名、ポート番号、およびデータベース名を指定します。

10. 接続をテストします。「結果を表示」ページで、動的クエリー・モードの接続テストのステータスが「成功」になる必要があります。成功になった場合、新規データ・ソースがリストに表示され、動的クエリー・モードまたは互換クエリー・モードのいずれかを使用してそのデータ・ソースに対してクエリーを実行できます。

11. データ (リレーショナル・データベースからテーブル、OLAP データベースからキューブ) を選択してインポートします。

12. 「テスト」タブをクリックします。プロジェクトの「クエリー・モード」プロパティーを「動的」に設定すると、テスト・クエリーは動的クエリー・モードで実行されます。「クエリー・モード」プロパティーを「互換」に設定する場合でも、「テスト」タブに動的クエリー・モードを使用するようにするオプションがあります。このオプションは、クエリー・サブジェクトが動的クエリー・モードがサポートするデータ・ソースに対するものである場合のみ表示されます。

13. このオプションが使用できる場合、「動的クエリー・モードの使用」を選択します。

14. 「テスト・サンプル」をクリックします。テスト・クエリーは IBM Cognosゲートウェイを通して Cognos Analytics サーバーの 1 つに送信され、それからデータベースに送信されます。テスト・クエリーによって取得されたデータは、「テスト」タブに表示されます。

15. オプション: 「クエリー情報」タブで、生成された Cognos SQL とネイティブSQL、および Cognos Analytics サーバーからの XML 応答を確認します。

動的クエリー・モードを使用するすべてのモデル・オブジェクトをテストし、SQL が正常に生成されたことを確認します。ディメンションを使用してモデル化したリレーショナル・モデルを構築している場合、データ・ソース、モデル・クエリー・サブジェクト、標準ディメンション、数値データ・ディメンションなど、基礎となるオブジェクトをテストします。

16. 「プロジェクト・ビューアー」で、「パッケージ」を右クリックし、「作成」をクリックして、「パッケージ作成」をクリックします。

17. パッケージ名を入力します。

18. 「発行ウィザード」ダイアログ・ボックスで、「モデルのバージョン管理を有効にする」をクリアし、「次へ」を 2 回クリックして、「オプション」ページを表示します。

19. 「動的クエリー・モードの使用」チェック・ボックスをオンにします。

20. 「発行」をクリックし、次に「終了」をクリックします。


タスクの結果

IBM Cognos Analytics でパッケージが使用可能になりました。今後、レポートと分析で動的クエリー・モードが使用されます。

ヒント: パッケージのプロパティーを表示して、パッケージが使用するクエリー・モードのタイプを確認できます。

動的クエリー・モードを使用する場合の考慮事項動的クエリー・モードを使用すると、整合したモデル作成とレポート作成のベスト・プラクティスを実行できます。

Framework Manager で動的クエリー・モードで作業する場合、以下の側面について考慮してください。

複数ファクトのクエリー

フィルター (つまり射影) に追加のファクトをドラッグすることはできません。また、クエリーにファクトが 1 つしかない場合は、フィルターで複数ファクトのクエリーを実行することはできません。この場合、次のエラーが発生します。

XQE-PLN-0084 SQL を生成できません。フィルター条件[GOSALES_OR].[PRODUCT_copy].[PRODUCTNUMBER] = 10 を、ファクト射影を含まないファクト・ストリーム (PRODUCT_copy) に適用することができなかったためです。

ディメンションを使用してモデル化されたリレーショナル (DMR) データ・ソースに関する考慮事項

ビジネス・アナリストは、使用しているデータから何を調べたらいいのかが常に分かっているわけではありません。そのため、データからどのような質問に対する答えが得られるかを調べなければならないことがあります。モデルの調整を試みたり、データに対して実行するために生成された SQL をデータベース管理者に調整してもらうことはできません。最も効率の良いクエリー戦略は、キャッシュやデータ・ソースの機能などのテクノロジーをうまく組み合わせて使用した、アドホックな分析またはレポートを生成するという方法です。

独自のフィルター条件がそれぞれ設定されている評価指標が含まれるレポートを作成するよう依頼されることがあります。例えば、宿泊の収益の合計、会員メンバーによる収益、ここ 6 カ月の間に登録した会員メンバーによる収益を表示するホテルのレポートなどです。このクエリーは、各評価指標を別個に計算し、最終結果を結合することによって解決できます。

それぞれ細分性が異なる複数の大規模なファクト表のデータを組み合わせることができます。例えば、いくつかの条件を満たす一連の顧客またはアカウントの、長期間にわたる行動を分析するための市場分析クエリーを表示するアドホック・レポートを作成できます。


複数のデータ・ソースに基づくモデル

サポートされているデータ・ソースとサポートされていないデータ・ソースの両方を含むモデルに対して動的クエリー・モードを有効にすることはできません。サポートされているデータ・ソースとサポートされていないデータ・ソースが混在しているパッケージが動的クエリー・モードが有効な状態で発行されると、レポート作成コンポーネントおよび Studio/Authoring ツールでそのパッケージを開いたときにエラーが表示されます。

Framework Manager での SAP BW モデルの限定的なサポート

動的クエリー・モードでは、IBM Cognos Framework Manager での SAP BW データ・ソースのモデル化は限定的にしかサポートされていません。例えば、モデル内に、ショートカット、クエリー・サブジェクト、計算式、フィルターが含まれる式などのオブジェクトを作成することはできません。

テスト機能は無効です。パッケージをモデル化および発行することはできますが、ディメンションや他のオブジェクトをテストすることはできません。

動的クエリー・モードで SAP BW メタデータをモデル化する場合、次の操作がサポートされます。

v プロンプトの属性の設定 (modelFilterReference)

v 変数プロンプト・タイプの変更

v 変数のデフォルト値の設定

v SAP BW に対するすべてのガバナーの使用

詳細については、 215 ページの『第 6 章 SAP BW メタデータ』を参照してください。

Framework Manager へのリレーショナル・メタデータのインポート

ユーザー、グループ、ロールにおいて、動的クエリー・モードを使用してリレーショナル・メタデータを IBM Cognos Framework Manager プロジェクトにインポートするには、「リレーショナル・メタデータのインポート」機能が必要です。詳しくは、「IBM Cognos Analytics 管理およびセキュリティー・ガイド」を参照してください。

動的クエリー・モードのガバナーIBM Cognos Framework Manager では、動的クエリー・モードに固有のガバナーを提供しています。

パッケージを作成する前にモデルでガバナーを指定して、その指定された制限が各パッケージのメタデータで使用されるようにしてください。その後発行されるすべてのパッケージはこの新しい設定を使用します。

重要:

キャッシングに影響を与えるガバナーの場合、次のいずれかの方法でキャッシングを有効にする必要があります。


v IBM Cognos Framework Manager で、「ローカル・キャッシュの使用を許可」ガバナーを有効にする。

v IBM Cognos Analytics - Reporting でのレポートについて、「ローカル・キャッシュを使用」のクエリー・プロパティーを有効にする。

ガバナーの使用法について詳しくは、 338 ページの『ガバナー』を参照してください。

(DQM) 正確な数値の除算になるよう SQL 生成を調整する

このガバナーは、除算のある計算を調整して、レポートにとって意味のある情報が除算の結果に必ず入るようにする方法を制御します。

「Double にキャスト」設定は、計算を以下のように変換します。

v [item1] / [item2] は cast([item1] as double precision) / [item2] になります

v cast ([item1] as decimal(9,2)) / [item2] は cast(cast([item1] as

decimal(9,2)) as double precision) / [item2] になります

「Double にキャスト (条件付き)」設定は、計算を以下の方法で変換します。分子がキャスト・オペレーションでない場合は、この設定を使用します。

v [item1] / [item2] は cast([item1] as double precision) / [item2] になります

v cast ([item1] as decimal(9,2)) / [item2] は cast([item1] as double

precision) / [item2] になります

「調整なし」設定は、計算の変換を行いません。

デフォルト設定は「Double にキャスト」です。

(DQM) キャッシュは接続コマンド・ブロックの影響を受ける

このガバナーは、キャッシュのキーに接続コマンド・ブロックの拡張した値を含めるかどうかを指定します。クエリーから返されるデータがコマンド・ブロック内のステートメントによって決まる場合、このガバナーを設定する必要があります。

例えば、ユーザー名のセッション・パラメーターを参照するマクロを含む、接続コマンド・ブロックを作成します。その結果、コマンド・ブロックの拡張した値は、ユーザーごとに異なります。ログ記録にのみユーザー名が使用される場合は、この差異は重要ではありません。この場合はキャッシュを共有できるため、このガバナーをオフにできます。ただし、ユーザー名がデータの取得を制御する場合は、キャッシュを共有できないため、このガバナーを選択する必要があります。

このガバナーを選択すると、キャッシュを共有するのは、キャッシュにデータをロードするために同じバージョンの拡張接続コマンド・ブロックを共有して使用するユーザーのみになります。

このガバナーが選択されていない場合、接続コマンド・ブロックにおける差異は無視されます。

ガバナーは、デフォルトで選択されています。


詳細については、「IBM Cognos Analytics 管理およびセキュリティー・ガイド」のコマンド・ブロックについての章を参照してください。

(DQM) キャッシュは DB 情報の影響を受ける

このガバナーは、接続するユーザーによって共有される Framework Manager のパッケージに関連付けられたキャッシュの機密性を制御します。またこのガバナーは、そのキャッシュにおける共有を制限するために使用するデータベース情報も指定します。この情報は、最初に IBM Content Manager および FrameworkManager で指定され、キャッシュに対して要求が行われると提供されます。

「DB + 接続 + サインオン」設定は、ユーザーが同じデータ・ソース、接続文字列、およびサインオン情報を指定したときのみにキャッシュが共有されることを指定します。これは、最も制約の多いキャッシュのレベルです。

「DB + 接続」設定は、ユーザーが同じデータ・ソースと接続文字列を指定したときのみにキャッシュが共有されることを指定します。

「DB」設定は、ユーザーが同じデータ・ソースを指定したときのみにキャッシュが共有されることを指定します。

「なし」設定では、データ・ソース、接続文字列、サインオン情報のいずれもキャッシュによって使用されないことを指定します。これは最も制限の緩いキャッシュのレベルです。

デフォルト設定は、「DB + 接続 + サインオン」です。

ヒント: このセクションで使用する「データ・ソース」という語句は、FrameworkManager で定義されているデータ・ソースのことです。これは Content Managerデータ・ソース名、カタログ名、スキーマ名をカプセル化します。

(DQM) キャッシュは、モデル・セキュリティーの影響を受ける

このガバナーは、キャッシュへのアクセスで使用されるセキュリティーを制御します。

設定が「自動」である場合は、Cognos ユーザーとユーザー・クラスを使用して、モデルにあるすべてのセキュリティー・フィルターに対するアクセスを確認します。キャッシュを特定するために、セキュリティー・オブジェクトとモデルのセキュリティー・フィルターが併せて使用されます。

設定が「User」になっている場合は、キャッシュを識別するために、Cognos のユーザー ID が使われます。キャッシュは、現在のユーザーにのみ再使用可能です。他のユーザーとの共有は行われません。

設定が「UserClass」になっている場合は、キャッシュを識別するために、Cognosのユーザー・クラスが使われます。

設定が「なし」の場合は、モデルにセキュリティー・フィルターがあったとしても、セキュリティー・フィルターのチェックは無効になります。

デフォルト設定は「自動」です。


(DQM) コンテキスト依存の結合選択

このガバナーは、ファクトを含まないスター・スキーマ・グループにおけるクエリーの結合パスの計算を制御する場合に使用します。

結合パスを選択するには、スター・スキーマ・グループを使用します。

「無効」と設定すると、主クエリーの結合パスが計算されるときに、スター・スキーマ・グループは無視されることになります。複数の結合パスがある場合、アルファベット順でソートの先頭になるものが選択されます。

「自動」と設定すると、ある一定の場合に、結合パスの計算に影響を与えるためにスター・スキーマ・グループが使用されることになります。その場合とは、クエリーで直接アクセスされるすべてのクエリー・サブジェクトとショートカットが最も低いデータベース・クエリー・サブジェクトにアンワインドでき、すべてのかつ中間クエリー・サブジェクトが関係を持たない場合です。それ以外の場合、スター・スキーマ・グループは無視されます。この動作は、互換性のあるクエリー・モードにおける結合パスの計算方法でもあります。

「明示的」と設定すると、結合パスの計算に影響を与えるためにスター・スキーマ・グループが使用されることになります。クエリー・サブジェクトまたはショートカットで「(DQM) 結合パスで使用」のプロパティーが「有効」に設定されている場合は、それらのクエリー・サブジェクトやショートカットが作成された表がSQL 内の最後の結合パスで使用されます。結合パスで使用されるとマークされているクエリー・サブジェクトがない場合、コンテキスト依存の結合選択はスター・スキーマ・グループに適用されません。

デフォルトの設定は「無効」です。

例えば、Store、Country_or_region、Camera_sales (ファクト)、 Returned_cameras(ファクト) という 4 つのクエリー・サブジェクトがあるとします。指定される結合は、以下のようになります。 Store と Camera_sales との間、Store とReturned_cameras との間、Country_or_region と Camera_sales との間、Country_or_region と Returned_cameras との間。

カメラが返品された店舗と国を表示したレポートを作成するとします。このレポートには、店舗と国しか記載されません。このレポートのコンテキストは、レポートのタイトルにしか表示されません。Returned_cameras クエリー・サブジェクトが選択されていないため、このクエリーにはファクトがありません。正しい出力を得るためには、結合パスが Store -> Returned_cameras -> Country_or_region になっていなければなりません。結合パスには、Returned_cameras が含まれていなければなりません。グループ Store、Returned_cameras、および Country_or_region へのスター・スキーマを作成しないと、結合パスは Camera_sales を通過します。この結果は、 Camera_sales がアルファベット順で最初のファクト・クエリー・サブジェクトであるために得られたものです。この問題を解決するには、スター・スキーマ・グループを作成します。まず Returned_cameras というフォルダーを作成し、その下に Store、Returned_cameras、および Country_or_region へのショートカットを作成します。「(DQM) コンテキスト依存の結合選択」ガバナーを「自動」に設定します。


重要: この例は、非常に単純化したものです。通常、モデルには、数百ものクエリー・サブジェクトが含まれており、ネームスペースとフォルダーに編成されています。このガバナーを「自動」に設定した場合、すべてのフォルダーとネームスペースがスター・スキーマ・グループの候補となります。すると、意図しない結合パスが使用される可能性があります。ガバナーを「明示的」に設定し、クエリー・サブジェクトやショートカットの「(DQM) 結合パスで使用」プロパティーを「有効」に設定して、あいまいさを排除してください。この設定の組み合わせを使用することにより、クエリーの処理は、「(DQM) 結合パスで使用する」プロパティーが「有効」に設定されたオブジェクトを含むフォルダーおよびネームスペースに限定されます。

(DQM) ローカル・キャッシュ・ポリシー

クエリーの再使用が有効な場合、動的クエリー・モードは、デフォルトで、クエリーでのデータ集計の最低レベルについてのキャッシュの作成を試みます。「自動グループ化および集計」のクエリー・プロパティーが「いいえ」に設定されているクエリーのデータ、または、Cognos ではなくベンダーの組み込み関数を使用する式が含まれるクエリーのデータは、動的クエリーによってキャッシュに入れられません。レポート作成者は、Cognos Analytics - Reporting の「検証」機能を重要な変換に対して使用することで、どこにクエリー再利用の適用が可能か不可能かを判別するために、動的クエリー・モードからフィードバックを取得できます。

さらに複雑なレポートの場合、レポート作成者は、結合や集合演算を含む複数のクエリーを定義し、それらを他のクエリーの中で使用することがあります。特にデータ量が多い場合など、場合によってはレポート作成者が、結合または集合演算がデータ・ソースに強制的にプッシュされるようにクエリーの再利用を無効にできます。

その他のシナリオにおいて、レポート作成者は、クエリー内のデータ集計の最低レベルに対するキャッシュを作成するというデフォルトの戦略を受け入れるのではなく、1 つのレポート内のどのクエリーをキャッシュに入れて再利用するかを制御するように決定することがあります。再使用ポリシー・ガバナーを変更することにより、レポート作成者は、データをキャッシュに入れるためにどのクエリーを使用するかを制御することができます。このガバナーは、レポート内からオーバーライドできません。また、一度アクティブになると、動的クエリーが非集計データ・セットをキャッシュに入れるように強制します。1 つのモデルを 2 回発行することが必要になる場合があります。つまり、一般的なレポート作成および対話的分析に関してデフォルトの戦略によって 1 回、そして「クエリーごとに明示」または「レイアウトによって参照されるクエリー」が設定されたポリシーによりもう 1 回ということです。

デフォルト戦略をオーバーライドすることにより最適化可能なレポートでは、第 2のオプションを使用することになります。レポート作成者は、レポートのうち可能な限り最小の数のクエリーをキャッシュに入れるようにすることにより、再利用の頻度が低いキャッシュが作成されて、限界に達した場合に他のキャッシュが削除されてしまうことになるのを回避する必要があります。


(DQM) カーソル・モード

このガバナーは、クエリーに必要なリソースを、解放するまでどの程度の期間保持するかを制御するために使用します。

クエリー・エンジンは、データをデータ・ソースからデータ・セットにカーソルを使用してロードします。カーソルは、全体を読み込むことも、部分的に読み込むことも可能です。クエリー・エンジンが最後のレコードを読み込むとすぐ、結果セットは完成し、データベース・リソースは解放されます。

「自動」設定を指定すると、クエリー・エンジンは、要求された数のレコードが読み込まれるとデータの読み込みを停止します。リソースは、追加のデータ要求に備えてアクティブなまま保持されます。停止したクエリーは、今後のデータ取得要求のためにデータベース接続とカーソルを保持します。停止したクエリーは、指定されたアイドル時間が経過した後、解放されます。その結果、すべてのデータがレンダリングされた後か、特定のアイドル時間または最大存続期間が経過した後で、データベース・リソースは解放されます。解放されるまでの間、これらのリソースは他のクエリーには使用できません。

「ページごとのクエリー」設定を指定すると、クエリー・エンジンは、現在のレポート・ページがユーザーにレンダリングされるとすぐリソースを解放します。以前にロードされた完全な結果セットが要求される場合も含め、この後は追加のページ要求が発生するたびに、データベース接続とカーソルの再確立が必要になります。この設定では、データ・ソース・リソースが最も速く解放されますが、クエリーの再実行には時間とリソースが最も多くかかります。

「バックグラウンドでロード」設定を指定すると、クエリー・エンジンは、要求されたデータの一部を戻してから、残りのデータをキャッシュにロードするバックグラウンド・スレッドを開始します。バックグラウンド・スレッドは、より低い優先度で実行されます。その後の要求では、バックグラウンド・スレッドによってロードされたデータがキャッシュから戻されます。バックグラウンド・スレッドが十分なデータをロードする前に追加のデータが必要になった場合は、新しい要求が優先されます。この設定を使用すると、最初のページの応答が速くなり、後続のページの応答時間も向上します。リソースは、すべてのデータがキャッシュにロードされるとすぐ解放されます。ただし、キャッシュ・データのために他の設定よりも多くメモリーを使用します。

デフォルト設定は「自動」です。

(DQM) マスター詳細の最適化

ページ・セットやマスター詳細関係が含まれているビジネス・レポートでは、データ・ソースに対して大量の要求が発行されることがあります。データは一時的にキャッシュに入れられ、詳細レイアウトにより新しいデータが必要になると、データ・ソースから新しい行を取り出すためにローカル・クエリーが実行されます。それらの追加のデータ要求のため、データ・ソースの負荷が大きくなり、レポートの実行時間に影響します。

例えば、あるリスト・フレームには、別のリスト・フレームとのマスター詳細関係があるかもしれません。マスター・リスト・フレームが 1000 行のデータをレンダリングする場合、詳細リスト・フレーム・クエリーを 1000 回実行することが必要


です。実際のところ、1 (マスター) + 1000 (詳細) のデータ要求が発行されます。そのような状況では、動的クエリー・モードで「(DQM) マスター詳細の最適化」のガバナーを使用することにより、製品パフォーマンスを向上させることができます。

レポートに関するこのタイプの最適化を適用するためには、以下の条件が満たされていなければなりません。

v 「(DQM) マスター詳細の最適化」ガバナーがモデルに対して有効でなければなりません。デフォルトでこのガバナーは、無効になっています。

v 動的クエリー・モードで、詳細クエリーのためのクエリーの再使用の適用が可能でなければなりません。

v マスター詳細関係により、マスターおよび詳細クエリーから射影された項目の間のリンクが定義されていなければなりません。詳細クエリーには、プロンプトを使用する付加的なフィルターを含めることもできます。

レポート作成者は、Cognos Analytics - Reporting において、「重要な変換」オプションを使用してレポートを検証することにより、マスター詳細の最適化を適用可能かどうかを確認できます。返される情報には、レポートで最適化機能を有効にすることができなかった理由が示されている場合があります。

「無効」設定を指定した場合、詳細クエリーのキャッシングは行われません。デフォルトではこの設定になっています。

「リレーショナル詳細クエリーをキャッシュ」設定を指定すると、詳細クエリーのキャッシングが行われます。

(DQM) 小さいレベルの最大サイズ

このガバナーを使用して、『小さい』レベルの最大サイズを定義します。

DMR レベルの「(DQM) 桁」プロパティーがこのガバナー設定の桁 N (logN) よりも大きい場合、その DMR レベルは『大きい』とみなされます。

DMR レベルに対する以下の OLAP 関数では、そのレベルのすべてのメンバーをDMR キューブにロードして実行する必要があります。

v TopCount

v TopSum

v Toppercent

v BottomCount

v BottomSum

v BottomPercent

v Filter

v Head

v Tail

これらの OLAP 関数のいずれかが大きい DMR レベルに適用される場合、動的クエリーは SQL 要求を生成します。その要求はデータベースに送信されて、動的クエリーによって検索されるデータの量を減らします。


デフォルトの設定値は 0 です。

注: この最適化は DMR だけに適用されます。これが有効になるのは、ガバナーが0 より大きい場合で、「ローカル・キャッシュの使用を許可」ガバナーが無効になっているときです。

(DQM) 集計クエリーの結合演算子

このガバナーは、集計クエリーを結合する構文を制御するために使用します。

「異ならない」設定は、集計クエリーを結合するために常に「異ならない」を使用する必要があることを指定します。デフォルトではこの設定になっています。

「等価演算子」設定は、集計クエリーを結合するために常に「等価演算子」を使用する必要があることを指定します。結合する列に Null 値が含まれていないことが確実である場合を除き、この設定を使用すべきではありません。

「自動」設定が指定されている場合、列が NULL 可能な場合には結合で「異ならない」が使用され、それ以外の場合には「等価演算子」が使用されます。

(DQM) 複数ファクトの結合演算子

このガバナーは、複数ファクト・クエリーの結合に使用する Cognos SQL で完全外部結合の構文を制御するために使用します。

「異ならない」設定は、結合するために常に「異ならない」を使用する必要があることを指定します。

「等価演算子」設定は、結合で常に「等価演算子」を使用する必要があることを指定します。結合する列に Null 値が含まれていないことが確実である場合を除き、この設定を使用すべきではありません。

「自動」設定は、列が NULL 可能な場合には結合で「異ならない」を使用し、それ以外の場合には結合で「等価演算子」を使用することを指定します。

デフォルト設定は、「異ならない」です。

次の例では、FS1 と FS2 の間の結合が Item_Code (NULL 不可能) およびCustomer_Number (NULL 可能) という 2 つの列に適用されます。このガバナーは、「異ならない」に設定されます。

SELECTCOALESCE(

FS1.Item_Code,FS2.Item_Code) AS Item_Code,

COALESCE(FS1.Customer_Number,FS2.Customer_Number) AS Customer_Number,

FS1.Order_Quantity AS Order_Quantity,FS2.Plan_Sales_Quantity AS Plan_Sales_Quantity

FROMFS1

FULL OUTER JOIN FS2ON

FS1.Item_Code IS NOT DISTINCT FROM FS2.Item_Code AND(FS1.Customer_Number IS NOT DISTINCT FROM FS2.Customer_Number)


次の例は、ガバナーが「等号演算子」に設定されている同じ結合を示しています。

SELECTCOALESCE(




FROMFS1


FS1.Item_Code = FS2.Item_Code AND(FS1.Customer_Number = FS2.Customer_Number)

Customer_Number は NULL 可能なので、Customer_Number の値が NULL の場合、つなぎが適切に適用されない結果が出力で示される可能性があります。

次の例では、同じ結合でガバナーが「自動」に設定されています。

SELECTCOALESCE(




FROMFS1


FS1.Item_Code = FS2.Item_Code AND(FS1.Customer_Number IS NOT DISTINCT FROM FS2.Customer_Number)

この場合、列が NULL 可能な場合にのみ、「異ならない」が使用されます。これにより、正しい結果が提供され、デフォルト・ガバナー設定よりパフォーマンスが向上します。

(DQM) (DQM) ネストされた集計の処理

このガバナーは、ネストされた標準集計のある計算で、最上位の集計の有効範囲を定義する構文を制御するために使用します。

最上位の集計に有効範囲が定義されていない場合、ネストされた標準集計のある計算に関して、互換クエリー・モード (CQM) と動的クエリー・モード (DQM) では動作が異なります。

以下の例で、計算にはネストされた標準集計があります。

total(total( m1 for X ) - total( m2 for X)

)

「レポートの範囲に設定」設定は、最上位の集計に『FOR REPORT』の有効範囲があることを指定します。これは DQM の動作です。


「削除」設定は、最上位の集計が計算から削除されることを指定します。これはCQM の動作です。

「サーバーで判別」設定は、最上位の集計に『FOR REPORT』の有効範囲があることを指定します。将来のリリースでは、この設定にサーバー・サイド構成設定が追加される可能性があります。

デフォルトの設定は「サーバーで判別」です。

(DQM) パラメーター・マップのクエリー・アイテムの形式を設定

このガバナーは、パラメーター・マップに取り込まれるキー値のペアをフォーマット設定するかどうかを定義する構文を制御するために使用します。このガバナーは、クエリー・アイテムに基づくパラメーター・マップに適用されます。

IBMCognos Analytics 11.0.0 から 11.0.7 の場合、キー値のペアはフォーマット設定されません。以下の例で、キー値のペアはフォーマット設定されません。

キー値

20100000 空ストリング

20100101 2010-01-01 00:00:00.000

20100102 2010-01-02 00:00:00.000

20100103 2010-01-03 00:00:00.000

20100104 2010-01-04 00:00:00.000

IBMCognos Analytics 11.0.8 + の場合、キー値のペアはクエリー・アイテムのデータ型に基づいてフォーマット設定されます。以下の例で、キー値のペアは、パラメーター・マップに取り込まれる前にフォーマット設定されます。

キー値

20100000 空ストリング

20100101 2010 年 1 月 1 日 12:00:00 AM

20100102 2010 年 1 月 2 日 12:00:00 AM

20100103 2010 年 1 月 3 日 12:00:00 AM

20100104 2010 年 1 月 4 日 12:00:00 AM

「ON」の設定は、パラメーター・マップに取り込まれるキー値のペアがフォーマット設定されることを指定します。

「OFF」の設定は、パラメーター・マップに取り込まれるキー値のペアがフォーマット設定されないことを指定します。

デフォルトの設定は「OFF」です。


メモリー内キャッシュ機能動的クエリー・モードにより、レポートのパフォーマンスを最適化し、サポート対象データ・ソースに対する負荷を軽減するデータ・キャッシュが提供されます。メタデータ・ツリーのデータが設定され、レポートや対話式クエリーが実行されるとき、利用可能なキャッシュのうちどれを使用できるのかが動的クエリー・モードによって判別されます。

動的クエリー・モードは、モデル作成者、レポートの作成者、および管理者に対して、以下の決定を下す際に役立つコントロールを提供します。

v セッション間で共有可能なキャッシュをセキュリティーで判別する方法。

v 要求で、キャッシュ・データを使用するのではなく、基礎となるデータ・ソースに常にアクセスするかどうか。

v キャッシュを消去するタイミング。

リレーショナル・データ・ソースの場合、「ローカル・キャッシュの使用を許可」のガバナーにより、クエリーの再使用をデフォルトで有効にするか無効にするかが定義されます。常にデータ・ソース内の最新のデータをクエリーする必要のあるアプリケーションの場合、このガバナーは無効に設定されることになります。

レポート作成者は、クエリーの「ローカル・キャッシュを使用」プロパティーを指定することにより、モデル・ガバナーの設定をオーバーライドすることができます。このプロパティーが変更されなければ、ガバナーによって定義される設定が、動的クエリー・モードにより適用されます。

動的クエリー・モードにより、どのキャッシュを使用できるのかをセキュリティーにより制御する方法を定義するモデル・ガバナーが提供されます。デフォルトでは、動的クエリー・モードは、データ・ソースからデータを取り出すために使用されるデータベース・サインオン、モデル・セキュリティー規則、および接続コマンド・ブロックを考慮します。

デフォルトの規則の設定が細かすぎる場合、モデル作成者は、以下のガバナーの設定値を変更することができます。

v キャッシュは DB 情報の影響を受ける

v キャッシュはモデル・セキュリティー・ガバナーの影響を受ける

v キャッシュは接続コマンド・ブロックの影響を受ける

例えば、アプリケーションで、ユーザーが (監査またはチャージバック規則のために) 独自のサインオンでデータ・ソースに接続することが必要とされる一方、ユーザーがその同じデータにアクセスすることは許可されているかもしれません。「キャッシュは DB 情報の影響を受ける」の設定を緩くすると、作成されるキャッシュ・データ・セットが少なくなり、より多くの要求で同じキャッシュ・オブジェクトを再利用できるようになります。

デフォルトでは、以下の条件が存在する場合、動的クエリー・モードによりリレーショナル・キャッシュが自動的に削除されます。

v キャッシュが 5 分間使用されなかった (アイドル状態であった) 場合。

v セッションが所有するキャッシュ・オブジェクトの最大数に達した場合。


v 動的クエリー・サーバー内のキャッシュ・オブジェクトの最大数に達した場合。

アイドル・タイムアウトとクエリー・サービスの限界のデフォルト値は、IBMCognos Administration で変更可能です。

リレーショナル・データ・ソースの場合は、次のいずれかの設定を変更することによってキャッシングを有効にします。

v IBM Cognos Framework Manager で、「ローカル・キャッシュの使用を許可」ガバナーを有効にする。

v IBM Cognos Analytics - Reporting でのレポートについて、「ローカル・キャッシュを使用」のクエリー・プロパティーを有効にする。

IBM Cognos Administration を使用すると、キャッシュの使用量を分析し、キャッシュ・ストレージを手動で、またはスケジュール機能を使用して自動で保守できます。キャッシュの管理について詳しくは、「IBM Cognos Analytics 管理およびセキュリティー・ガイド」を参照してください。

キャッシュが機能する方法の詳細については、IBM Redbooks 資料、IBM CognosDynamic Query (http://www.redbooks.ibm.com/abstracts/sg248121.html) を参照してください。

高度な Null 消去Null 値しか含まれていない行や列を消去すると、レポートが読みやすくなります。

たとえば、特定の四半期に売上がない製品があると、データのないセルが多数ある非常に大きなレポートになることがあります。

テーブルを評価して Null 値しか含まれていない行および列はどれかを判別するのにかかる時間は主に、テーブル内のセルの数によって決まります。また、軸のネスト・レベルや、複雑な算出列が使用されているなどの要素も Null 消去にかかる時間に影響します。

テーブル内のセルの数は、交差結合の数 (メンバー・セットのデカルト積) によって判別されます。公差結合の数の算出方法は次のとおりです。

crossjoin ({a1,a2}, {b1,b2}, {c}) = {(a1,b1,c) (a1,b2,c) (a2,b1,c) (a2,b2,c)}

次の例では、解決されたエッジには 1 × 1 × 170 × 818 × 818 = 113,751,080 の処理対象の組 (セル) があります。




IBM Cognos Analytics では、IBM Cognos Query Studio、および IBM CognosAnalytics - Reporting で OLAP データ・ソースを使用してレポートを作成する際の消去のためのクエリー最適化機能が用意されており、消去を有効にすることができます。

セルの式が Null と評価された場合はクエリー評価の際に計算する必要がないため、処理が必要となるセルの数が減ります。

結果は、キューブの構造、カーディナリティー、レポートのスタイル、クエリーのサイズ、結果の散在度の兼ね合いによって異なります。

IBM Cognos Analysis Studio では、動的クエリー・モードが有効にされたパッケージを使用すると、データ・ソースで行および列の Null 消去が処理され、パフォーマンスが向上します。

Null 消去および IBM Cognos TM1® データ・ソースに特化した最適化の実装について詳しくは、IBM Redbooks 資料、IBM Cognos Dynamic Query(www.redbooks.ibm.com/abstracts/sg248121.html) を参照してください。

メンバーの順序メンバーの順序はディメンション分析における、基本的な側面です。メンバー関連、および時系列の機能が意味のある結果を生むかどうかは、メンバーの順序に依存しています。

これらの機能の例には、NextMember、PreviousMember、ClosingPeriod、およびOpeningPeriod が含まれます。

動的クエリー・モードは、メンバーの順序が一貫性を保つようにするため、自然順序およびソート指定の仕組みを含みます。

自然順序

メンバーのデフォルトの順序は、自然順序と呼ばれます。 OLAP 化されたリレーショナルにおけるメンバーの自然順序は、NULL を最後とする、メンバー・キャプシ

図 4. ネストされた 5 つのセットを含むクロス集計



ョンの昇順です。複数のキャプションが同一の場合、副ソート・キーはビジネス・キーで、昇順です。ビジネス・キーは一意であるとみなされます。

例えば、製品売上データ・モデルのディメンションで、「返品理由」レベルがあると想定します。モデル内に明示的なメンバー・ソート指定がない場合、動的クエリー・モードはメンバーをメンバー・キャプションのアルファベット順でソートします。

v 欠陥品

v 未完成品

v 不満

v 発注ミス

v 発送ミス

互換クエリー・モードでは、一貫性のあるデフォルトのソートは行われず、自然順序はクエリーおよびデータ・ソースに依存します。

ソート指定

IBM Cognos Framework Manager では、ビジネスの必要に応じて、メンバー・ソート指定を明示的に設定できます。このオプションは、「ディメンション定義」ウィンドウの「メンバーのソート」タブから利用できます。

メンバー関連の分析は、順序が明示的でも暗黙的 (自然順序) でも、常にメンバーの順序の影響を受けます。メンバーの特定の順序がビジネスを把握する上で重要である場合は、「レベルのソート」プロパティーを使用して明示的なソート指定を定義します。複数の「レベルのソート」プロパティーは、リストされた順番で適用されます。すべてのソート・プロパティーが同一の場合、自然順序が適用されます。

明示的なソート指定がない場合、自然順序が適用されます。自然順序に依存していて、メンバーの特定の順序が必要な場合に、メンバー関連の機能において予期しない結果が生じることがあります。この問題は、特に時間ディメンションの月レベルで発生します。

動的クエリー・モードでは、「メンバーのソート」タブに表示される「ソート・オプション」ボックスの設定はすべて無視されます。代わりに、次のソート・オプションが実施されます。

v メタデータ・ツリー表示は、常にメンバーの順序を順守します。

v メンバーは常に順序付けられます。レポート作成者は、メンバーを表示する際に他のソート順を適用することができます。

メンバーの順序を明示的に指定するには、「ディメンション定義」ウィンドウの「レベルのソートのプロパティー」ボックスを使用します。メンバーのデフォルトのソート順は、レベルのメンバー・キャプションの昇順です。

メンバーのソート順を指定する方法の詳細については、「IBM Cognos FrameworkManager ユーザー・ガイド」を参照してください。


例

モデルで定義されたメンバーの順序は、ディメンションで定義された階層に準じます。ただし、レポートのソートは以下のレポート・レイアウトに準じます。例えば、小売業ディメンションは以下の階層を定義します。

v 地域

v 小売業者の国または地域

v 小売業者

v 小売業者の所在地

このサンプル・モデルでは、「小売業者の国または地域」レベルは、国または地域の名称を含むメンバー・キャプションの昇順でソートされます。レポート内で「小売業者の国または地域」レベルを射影する場合、定義された階層に基づき、「地域」内でのキャプションの順序でメンバーが表示されます。リスト・レポート内の「地域」または「小売業者の国または地域」を、レポートのソートを行わずに射影すると、出力結果は以下のように表示されます。

表 14. 「地域」および「小売業者の国または地域」のレポート出力

地域小売業者の国または地域

Americas Brazil

Americas Canada

Americas Mexico

Americas United States

Asian Pacific Australia

Asian Pacific China

Asian Pacific Japan

Asian Pacific Korea

Asian Pacific Singapore

Central Europe Belgium

Central Europe France

代わりに、レポート・リストで列にアルファベット順のソートを適用した「小売業者の国または地域」のみを射影することもできます。結果は、キャプションのアルファベット順に「小売業者の国または地域」メンバーが表示されたリストです。

メンバー関連の処理は、レポートのソートによって干渉されることはありません。それらは、引き続きモデル内のメンバー・ソート順 (明示的でも暗黙的であっても)に依存します。

フィルターを適用して結合を最適化するレポートのクエリーで、複数のデータ・ソースにまたがるリレーショナル結合が必要になることがあります。例えば、トランザクション・データベースを使用して一連の顧客の詳細情報を見つけた後に、その情報を企業の販売ウェアハウスと結合する場合などがあります。動的クエリー・モードでは、ローカル・クエリー実行によって、複数のリレーショナル・データ・ソースにまたがる結合を実行できます。


動的クエリー・モードでは、フィルター結合を使用して結合の実行方法を最適化します。結合を進めるためのクエリーを実行してキー値のセットを収集した後、他のデータ・ソースに対して実行するクエリーに、そのキー値のセットを追加します。そのデータ・ソースに送信する述語 (フィルター基準) を拡張して、結合で処理する必要があるローカル・データの処理量を減らします。その結果、パフォーマンスが桁違いに向上する可能性があります。


結合の「フィルター・タイプ」プロパティーを設定することにより、IBM CognosAnalytics - Reporting または IBM Cognos Framework Manager で結合にフィルターを適用できます。

結合ごとに、それぞれの側でカーディナリティーを指定する必要があります。カーディナリティーは [0..1]、[1..1]、[0..n]、[1..n] のいずれかにできます。カーディナリティーが [0..1] または [1..1] として指定されている側は、一般に 1 の側と呼ばれます。カーディナリティーが [0..n] または [1..n] として指定される側は、一般に多の側と呼ばれます。大抵の場合、「1」の側のオペランドの行は、「多」の側と比べて極端に少なくなります。

結合にフィルターを適用すると、「多」の側にフィルターが適用されることによって「多」のオペランドの行のセットのサイズが減ります。結合フィルターは、「1」の側のオペランドから取得された結合キーの値に基づいています。

どちらのクエリーの場合も、Cognos Analytics - Reporting 内でアクセスされる外部データ・ソースからデータを取得することもできます。データ・ソースのタイプが異なる場合、データ・タイプに互換性があることを確認してください。そうしないと、結合式を編集して、結合するクエリー・アイテムの間で明示的にキャストが行われるようにする必要が生じる可能性があります。

重要: 結合にフィルターを適用できるのは、動的クエリー・モードを使用している場合だけです。

手順1. Cognos Analytics - Reporting でフィルターを適用する場合は、「クエリー・

エクスプローラー」を開き、「クエリー」をクリックします。

2. Cognos Framework Manager でフィルターを適用する場合は、「ツール」 >「コンテキスト・エクスプローラーを起動」をクリックします。

3. 最適化する結合を選択し、「フィルター・タイプ」プロパティーを設定します。

以下の値のいずれかを選択します。

中生成されるフィルターは、「1」の側の結合オペランドからの結合キーの定数値で構成される IN 述語です。

指定の値の間生成されるフィルターは、「1」の側のオペランドからの結合キーの最小値および最大値で構成される BETWEEN 述語です。

これはデフォルト値です。


テーブル生成されるフィルターは、テーブル値コンストラクター形式の IN 述部です。

IN 述語および BETWEEN 述語は、多くのデータ・ソースの SQL 構文でサポートされていますが、テーブルまたは行のコンストラクターはあまり一般的ではありません。データ・ソースでサポートされていない場合、「テーブル」オプションは選択しないでください。クエリーの分解およびローカル・クエリー処理の実行には動的クエリー・モードが使用されますが、フィルター結合を使用しない場合よりも速くなることはありません。

レポートの IN 述語で大きな値リストが作成されると、データベース・ベンダーが IN 述語の最適化または書き換えに使用している方式によって、パフォーマンスが影響を受ける可能性があります。また、データ・ソースに送信される SQLステートメントのサイズも大きくなります。可能な場合には、代わりに BETWEEN述語を使用してください。

ヒント: レポートの作成者は、Cognos Analytics - Reporting の検証機能を使用して、フィルター結合をデータベースにプッシュできない理由を説明するメッセージを参照できます。

モデル内での集計クエリーの作成IBM Cognos Framework Manager モデル内で集計クエリーにするクエリー・サブジェクトを指定することにより、クエリー・アイテム内の式で明示的集計を入力せずに、集計されたデータを取得できます。

既に集計されているクエリー・アイテムを、集計クエリーから、IBM CognosAnalytics で作成されるレポートに追加できます。作成するレポートごとに、複雑な式や計算を繰り返す必要はありません。

手順1. Cognos Framework Manager で、集計クエリーにするクエリーを選択します。

2. 「(DQM) 使用」プロパティーを「集計クエリー」に設定します。

3. クエリー・サブジェクトの定義の「フィルター」タブで、フィルターを作成します。

4. 集計が行われるタイミングを指定するには、以下のようにフィルターの「(DQM) アプリケーション」プロパティーを設定します。

デフォルトの値は「自動集計前」です。以下の値のいずれかを選択します。

自動集計前生成される詳細フィルターは、作成したフィルター式と一致します。

自動集計後

生成される詳細フィルターは、作成したフィルター式の集計を使用します。例えば、以下のフィルター式を作成するとします。

[NameSpace].[Summary_query_subject].[QUANTITY]>100*1000


ファクト・アイテム QUANTITY がその集計式に置き換えられ、フィルターが概要フィルターとして解釈されます。

aggregate([NameSpace].[Summary_query_subject].[QUANTITY])>100*1000

この例では、「aggregate」がファクト・アイテム QUANTITY の標準集計を表します。集計の範囲は、集計クエリー・サブジェクトのグループ化列の範囲です。

5. 集計クエリー・サブジェクトのデータのキャッシュを有効にするには、集計クエリー・サブジェクトの「(DQM) ローカル・キャッシュを使用」プロパティーを「有効」に設定します。この設定は、モデルまたはクエリーのいずれかで「(DQM) ローカル・キャッシュを使用」プロジェクト・ガバナーが有効な場合にのみ適用されます。

別個のデータ・セットをリンクするためのブリッジ・テーブルの作成データベース・スキーマを、一致するディメンションで関連付けられている別個のスター・スキーマの形にできない場合、ブリッジ・テーブルを作成して、スター・スキーマまたはサブジェクト・エリアをリンクします。

IBM Cognos Framework Manager でブリッジ・テーブルを使用して、別個の 2つのデータ・セット間に多対多の関係を作成します。

詳細については、 80 ページの『ブリッジ・テーブル』を参照してください。

手順1. Cognos Framework Manager で、ブリッジ・テーブルとして使用するクエリ

ー・サブジェクトを作成します。

2. 「(DQM) 使用」プロパティーを「ブリッジ」に設定します。

3. 集計クエリー・サブジェクトのデータのキャッシュを有効にするには、集計クエリー・サブジェクトの「(DQM) ローカル・キャッシュを使用」プロパティーを「有効」に設定します。この設定は、モデルまたはクエリーのいずれかで「(DQM) ローカル・キャッシュを使用」プロジェクト・ガバナーが有効な場合にのみ適用されます。

ストアード・プロシージャーとトランザクション・アクセス・モードストアード・プロシージャーに基づいたクエリー・サブジェクトの場合は、IBMCognos Framework Manager で「トランザクション・アクセス・モード」プロパティーを変更して、データの処理を制御します。

動的クエリー・モードでは、ストアード・プロシージャーに基づいたクエリー・サブジェクトの場合、モデル・データ・ソースに対して指定される「トランザクション・アクセス・モード」プロパティーが使用されます。他のすべてのクエリー・サブジェクトの場合、JDBC 接続は JDBC ドライバーのデフォルトのトランザクション・アクセス・モードを使用します。

クエリーが実行されると、「トランザクション・アクセス・モード」プロパティーに基づいて JDBC 接続が設定されます。


「トランザクション・アクセス・モード」プロパティーは、以下のいずれかの値に設定できます。

無指定動的クエリー・モードでは、JDBC ドライバーのデフォルトのトランザクション・アクセス・モード (通常は読み取り/書き込み) が使用されます。この設定がデフォルトです。デフォルトのトランザクション・アクセス・モードを判別するには、JDBC ドライバー・ベンダーの資料を参照してください。

読み取り専用動的クエリー・モードでは、JDBC 接続は読み取り専用モードに設定されます。

読み取り/書き込み動的クエリー・モードでは、JDBC 接続は読み取り/書き込みモードに設定されます。

ヒント: 読み取り専用モードおよび読み取り/書き込みモードのサポートと適用は、データベース・ベンダーによって異なります。詳細については、データベース・ベンダーの資料を参照してください。

トランザクション・アクセス・モードの指定について詳しくは、「IBM CognosFramework Manager ユーザー・ガイド」を参照してください。

トランザクション・アクセス・モードとローカル・キャッシュ

レポートがローカル・キャッシュを使用してクエリーの結果セットを解決できることを、モデルおよびレポートで指定できます。クエリーは、特定の基準を満たした場合に、ローカル・キャッシュのコンシューマー候補になります。このらの基準の多くは、Cognos Framework Manager のガバナーを使用して設定することができます。候補クエリーにストアード・プロシージャーが含まれる場合、ローカル・キャッシュが使用されるかどうかは、次の「トランザクション・アクセス・モード」プロパティー値の設定によります。

無指定ストアード・プロシージャーの結果セットは、ローカル・キャッシュを使用して解決されます。

読み取り専用ストアード・プロシージャーの結果セットは、ローカル・キャッシュを使用して解決されます。

読み取り/書き込みストアード・プロシージャーの結果セットの解決にローカル・キャッシュは使用されません。ストアード・プロシージャーが含まれるクエリーが再度実行されます。

適切なトランザクション・アクセス・モードを設定しなければ、状況によっては、レポートは必要なデータを返しません。例えば、データを生成して結果セットを返すストアード・プロシージャーがあるとします。モデル・データ・ソースのトランザクション・アクセス・モードを「無指定」または「読み取り専用」に設定した場合、キャッシュに保管されているその同じ結果セットが返されます。このような結


果になるのは、クエリーの結果セットの解決にローカル・キャッシュが使用されるためです。常に最新の結果セットを知りたい場合は、トランザクション・アクセス・モードを「読み取り/書き込み」に設定します。

トランザクション・アクセス・モードとデータ変更クエリー・サブジェクト

データ変更ストアード・プロシージャーを含んだクエリー・サブジェクトは、書き込みアクセスを必要とします。それにもかかわらず、モデルのデータ・ソースの「トランザクション・アクセス・モード」プロパティーを「読み取り専用」に設定した場合は、エラー・メッセージが表示されます。

例えば、Cognos Framework Manager で、読み取り専用のモデル・データ・ソースを使用するデータ変更ストアード・プロシージャーをテストすると、次のエラー・メッセージが表示されます。

XQE-PLN-0309 The [Namespace].[data_Modification_Stored_ProcedureName]data modification query subject requires that thetransaction access mode property is set to Read-Writeon the [read_Only_Model_Data_Source] model data source.

この問題を解決するには、「トランザクション・アクセス・モード」プロパティーを「読み取り/書き込み」に設定する必要があります。

トランザクション・アクセス・モードと複数のモデル・データ・ソースを使用するクエリー

同じ Content Manager データ・ソースを参照する複数の Framework Manager モデル・データ・ソースをクエリーが使用する場合、クエリーは、名前がアルファベット順で最初のモデル・データ・ソースに対して指定された JDBC 接続トランザクション・アクセス・モードを使用します。


第 10 章メタデータ・モデリング・ガイド

IBM Cognos Framework Manager は、IBM Cognos Analytics のクエリー生成を支援するメタデータ・モデル作成ツールです。モデルとは、1 つ以上のデータ・ソースの物理情報とビジネス情報を含むメタデータの集まりです。 IBM CognosAnalytics では、正規化および非正規化されたリレーショナル・データ・ソースやさまざまな OLAP データ・ソースに基づく業績管理が可能です。

IBM Cognos のモデル作成の概念を理解する始める前に、ビジネス・レポートの作成と分析で使われるメタデータのモデル作成に関して、IBM Cognos のモデル作成の基本概念を理解しておく必要があります。

リレーショナル・モデル作成の概念IBM Cognos Framework Manager でモデルを作成するときには、必ずしも完全なスター・スキーマになるようにデータ・ソースを設計する必要はないことを理解しておくことが重要です。アプリケーションのために必要なパフォーマンスを実現できるようにデータ・ソースが最適化されている限り、スノーフレークまたは他の形式で正規化されたスキーマも同じように使用できます。ただし一般的には、スター・スキーマの概念に従って論理モデルを作成することを推奨します。この方法はIBM Cognos Analysis Studio では必要条件であり、しかもユーザー用のデータを編成する効果的な方法であることが実証されています。

複雑なデータ・ソースを使用するアプリケーションの開発を始めるときには、ビジネスに対するユーザーの見方を反映する簡素化されたビューを作成し、この資料のガイドラインを使って予測可能なクエリーと結果が得られるようにそのビューを設計することを推奨します。リレーショナル・モデルを適切に構築すると、アプリケーションの基盤としての役割を果たし、IBM Cognos ソフトウェアのディメンション機能を利用する場合にも作業を開始しやすくなります。

スター・スキーマのデータ・ソースを使って作業を開始した場合、スター・スキーマ作成で使われる概念は、クエリーと分析のアプリケーションを作成するときにも役立つため、モデルの作成作業が軽減されます。この資料のガイドラインは、アプリケーションのニーズを満たすモデルを設計するための作業を支援します。

カーディナリティー

2 つのクエリー・サブジェクトの間には関係が存在します。関係のカーディナリティーとは、2 つのクエリー・サブジェクトそれぞれにおける、関連する行の数です。行は、関係を表す式によって関連付けられます。通常、この式は、基礎となるテーブルのプライマリー・キーと外部キーを参照します。

IBM Cognos ソフトウェアでは、以下の目的で関係のカーディナリティーを使用します。

v ファクト・データの二重カウントの防止

v スター・スキーマ・モデルでよく発生するループ結合をサポートする


v 基礎となるデータ・ソース・システムへのアクセスの最適化

v ファクトやディメンションとして動作するクエリー・サブジェクトの識別

基礎となるさまざまなテーブルからの複数のファクトを使用するクエリーは、基礎となるファクト表ごとに別個のクエリーに分割されます。それぞれのファクト・クエリーでは、それぞれに該当するファクト表、およびそのファクト表に関連するディメンション表が参照されます。これらの個別のクエリーを 1 つの結果セットに結合するために、別のクエリーが使用されます。この後者の処理を、一般に「スティッチ・クエリー」といいます。 coalesce および完全外部結合が存在する場合、スティッチ・クエリーになります。

さらに、スティッチ・クエリーにより、IBM Cognos ソフトウェアはさまざまな細分性レベルでデータを適切に関連付けることができます。 388 ページの『複数ファクト、複数細分性のクエリー』を参照してください。

生成されたクエリーのカーディナリティー:

IBM Cognos ソフトウェアでは、最小/最大カーディナリティーとオプション・カーディナリティーの両方がサポートされています。

0:1 では、0 が最小カーディナリティー、1 が最大カーディナリティーです。

1:n では、1 が最小カーディナリティー、n が最大カーディナリティーです。

1:1 対 1:n のカーディナリティーが指定された関係は、最大カーディナリティーに注目して、一般的に「1 対 n」と呼ばれます。

最小カーディナリティー 0 は、その関係がオプションであることを示しています。一致するものがないときでも関係の他方の側の情報をクエリーに保持するには、最小カーディナリティー 0 を指定してください。例えば、顧客と販売実績の間の関係を 1:1 対 0:n と指定することができます。この指示により、販売データがない場合でも、要求された顧客情報がレポートに表示されます。

したがって、1 対 n 関係を次のように指定することも可能です。

v 0:1 対 0:n

v 0:1 対 1:n

v 1:1 対 0:n

v 1:1 対 1:n

「関係定義」ダイアログ・ボックスの「関係の影響」文を使用すると、カーディナリティーを理解するうえで役立ちます。例えば、Sales Staff (1:1) が Orders (0:n)に結合されています。

カーディナリティーはファクト・クエリー・サブジェクトの検出を決定し、ファクト・データの二重カウントの防止に使用されるため、モデル内のカーディナリティーを正しく指定することが重要です。


クエリーの生成時に、IBM Cognos ソフトウェアは以下の基本的な規則に従ってカーディナリティーを適用します。

v クエリーのコンテキスト内でカーディナリティーが適用されます。

v 1 対 n のカーディナリティーは、n 側がファクト・データを意味し、1 側がディメンション・データを意味します。

v 特定のクエリーに回答するために必要な関係に応じて、クエリー・サブジェクトはファクト・クエリー・サブジェクトまたはディメンション・クエリー・サブジェクトとして動作します。

モデル内のカーディナリティーがどのような動作を発生させるかについての評価を確認するには、Model Advisor を使用します。

詳細については、 419 ページの『単一ファクト・クエリー』および 421 ページの『一致するディメンションに対する複数ファクト、複数細分性のクエリー』を参照してください。

クエリーのコンテキスト内のカーディナリティー:

複数ファクトのクエリーを生成するときにクエリーをいつどこで分割するかを決定するためにカーディナリティーが使用されるため、クエリーのコンテキスト内のカーディナリティーには重要な役割があります。ディメンションとファクトが間違って認識されると、不要なスティッチ・クエリーが作成されてパフォーマンスが低下したり、クエリーが正しく形成されずに間違った結果が得られたりする可能性があります。

次の例は、IBM Cognos ソフトウェアでカーディナリティーがどのように解釈されるかを示しています。

例: ディメンションやファクトとして機能するクエリー・サブジェクト:

この例では、「販売支店」が「注文ヘッダー」に相対的なディメンションとして機能し、「注文ヘッダー」が「販売支店」に相対的なファクトとして機能します。

第 10 章メタデータ・モデリング・ガイド 383

例:1 つのクエリーに 4 つのクエリー・サブジェクトが含まれている場合:

この例では、4 つのクエリー・サブジェクトすべてがクエリーに含まれています。「販売員」と「注文の詳細」はファクトとして扱われます。「注文ヘッダー」と「販売支店」はディメンションとして扱われます。

このクエリーに対して生成される SQL は分割され、「販売員」と「注文詳細」がファクトとして扱われます。これらの 2 つのサブクエリーの結果は、「販売支店」から取得された情報を使用して結合 (スティッチ) されます。その結果、レポートには「販売支店」ごとの「注文詳細」および「注文ヘッダー」情報が表示され、その横に「販売支店」ごとの「販売員」情報がリストされます。

例:1 つのクエリーに 3 つのクエリー・サブジェクトが含まれている場合:

この例では、3 つのみのクエリー・サブジェクトがクエリーに含まれています。「注文詳細」は使用されていません。「注文ヘッダー」はここではファクトとして扱われています。「販売員」は、ここでもファクトとして扱われています。

この例の SQL でも、前の例と同様の結果を返すスティッチ・クエリーが生成されます。スティッチ処理では、完全外部結合を使用して処理の両側の情報が維持されることに注意してください。

行列式

行列式は、クエリー・サブジェクトでのデータのサブセットやグループを表現することにより細分性を表します。行列式を使用すると、この反復データが正しく集計されるようになります。行列式は、データ・ソースにおけるキー/インデックスの概念と最も密接な関連があり、データ・ソース内の固有キー/インデックス情報に基づいてインポートされます。インポートされる行列式を常に確認し、必要に応じて変


更するか、追加の行列式を作成することを推奨します。行列式を変更すると、データ・ソースのインデックス/キー情報をオーバーライドして、レポートや分析のニーズにより適合する情報に置き換えることができます。行列式を追加すると、アプリケーションに関連する反復データのグループを表すことができます。

次の "Time" の例では、"Day" (日) が一意の行列式になっています。一意でない行列式の例は "Month" です。"Month" のキーは、特定の月の日数だけ反復されます。

一意でない行列式を定義するときには、グループ化を指定してください。この指示により、IBM Cognos ソフトウェアは、その行列式に関連付けられているキーや属性がデータ内で繰り返されるときに、二重カウントを避けるための集計関数とグループ化を適用します。一意に識別とグループ化の両方を選択した行列式や、どちらも選択しない行列式を指定しないようお勧めします。

Year Key Month Key Month Name Day Key Day Name

2006 200601 January 06 20060101 Sunday, January1, 2006

2006 200601 January 06 20060102 Monday,January 2, 2006

このデータ・セットには、2 つの「グループ化」行列式 (Year と Month)、および1 つの一意な行列式 (Day) の合計 3 つの行列式を定義できます。この概念はレベルや階層の概念と似ていますが、まったく同じではありません。


年 Year Key なしいいえはい

月 Month Key Month Name いいえはい

日 Day Key Day Name

Month Key

Month Name

Year Key

はいいいえ

この場合、データ内のグループを識別するのに十分な情報が各キーに含まれているため、それぞれの行列式で 1 つのキーだけを使用します。 Month のキーには、どの年の月であるかを判別するための十分な情報が含まれていないことが多いため、問題となる可能性が高いですが、 Month のキーが特定の年の月を一意的に識別できない場合、Month の行列式のキー定義に Year キーを組み込みます。

注: 年を考慮せずに月をグループ化する行列式を作成することも可能ですが、2006年 2 月のすべてのデータが一緒にグループ化される代わりに、すべての年の 2 月のデータがすべて一緒にグループ化されるため、レポート作成ではこの方法はあまり使用されません。


マルチパート・キーが指定された行列式の使用

上記の Time ディメンションの例では、行列式で各データ・セットを識別するために 1 つのキーで十分でしたが、常にそうであるとは限りません。

例えば、次の Geography ディメンションでは、1 つを除くすべての行列式でマルチパート・キー定義を使用しています。

地域 Region キー State/Province キー City キー

North America USA Illinois Springfield

North America USA Missouri Springfield

North America USA California Dublin

Europe Ireland 該当なし Dublin

Time の例と同じように、このデータ・セットには 2 つの「グループ化」行列式(Region と State/Province)、および 1 つの一意な行列式 (City) の、合計 3 つの行列式を定義できます。


地域 Region キーなしいいえはい

State/Province State/Provinceキー

なしいいえはい

CityRegion キー

State/Provinceキー

City キー

なしはいいいえ

この場合、City を一意にするために、Region キー、State/Province キー、およびCity キーを使用しました。このようにしたのは、上記のデータの場合、同じ市の名前が複数の State/Province (州) で繰り返され、さらにそれが複数の Region (地域)で繰り返されているためです。

行列式は指定された順序で評価される

行列式に階層の概念はありませんが、評価の順序が存在します。 IBM Cognos ソフトウェアは、クエリー・サブジェクトから選択された一連のアイテムを評価するとき、「行列式」タブで設定された順序でアイテムをそれぞれの行列式 (キーおよび属性) と 1 つずつ比較します。このような方法で、IBM Cognos ソフトウェアは最も良く適合する行列式を選択します。

次の例では、Current month (現在の月)、Days in the month (月の日数)、およびローカライズされた Month (月の名前) という属性が Month キーに関連付けられています。このいずれかの属性を参照するクエリーが送信されたとき、マッチング条件を満たす最初の行列式は Month 行列式になります。他の属性が必要でない場合は、行列式の評価が Month で停止して、この行列式が SQL の group 節と for節で使用されます。


ディメンションの他の属性も含まれている場合、以前の行列式にそれらの属性がまだ一致していなければ、一致が見つかるか最後の行列式に達するまで IBM Cognosソフトウェアは評価を続けます。このような理由で、一意な行列式にすべてのクエリー・アイテムが関連付けられます。他に一致が見つからない場合、データをどのようにグループ化するか決定するために、データ・セット全体の一意なキーが使用されます。

行列式をいつ使用するか

行列式を使用するとデータの細分性に関するさまざまな問題を解決できますが、次に示すような主要なケースでは、常に行列式を使用してください。

v ディメンションとして動作するクエリー・サブジェクトに複数の細分性レベルがあり、異なるキーのセットでファクト・データに結合される場合。

例えば Time に複数のレベルがあり、Month キーで Inventory (在庫) に結合され、Day キーで Sales (売上) に結合される場合が考えられます。

詳細については、 388 ページの『複数ファクト、複数細分性のクエリー』を参照してください。

v 反復されるキーまたは属性に対して、カウントまたは他の集計関数を実行する必要がある場合。

例えば Time には Month キーおよび (すべての日で反復される) Days in themonth 属性があります。レポートで Days in the month を使用する場合、月の各日の「Days in the month」(月の日数) を合計するのは無意味です。その代わりに、選択した Month キーに対応する Days in the month の固有値が必要です。 SQL では、XMIN(Days in the month for Month_Key) となります。また、Cognos SQL には Group by 節もあります。

また、次のようなやや特殊なケースでも、行列式が必要になります。


v データ・ソースからテキスト BLOB データを取得するとき、データ行を一意に識別する必要がある。

BLOB を照会するときには、追加的なキーまたはインデックス・タイプの情報が必要です。データ・ソースの中にこの情報がない場合、行列式を使ってそれを追加できます。レポート用に作成された関係と競合する、データ・ソースからインポートされた行列式をオーバーライドしてください。

クエリー・サブジェクトが BLOB データにアクセスする場合、複数セグメントのキーを使用することはできません。集計クエリーでは、クエリーの集計部分とは別個に BLOB データを取得する必要があります。そうするには、行を一意に識別する、複数のセグメントを持たないキーが必要です。

v クエリー・サブジェクトに関して指定されている一意な行列式よりも少ないキーを使用する結合が指定されている。

関係の 0..1 側または 1..1 側にある一意な行列式のキーによって参照される列のサブセットに基づいて結合が構築されている場合、競合が発生します。この競合を解決するには、行列式に完全に適合するよう関係を変更するか、関係をサポートするよう行列式を変更します。

v レポート用に作成された関係と競合する、データ・ソースからインポートされた行列式をオーバーライドする必要がある。

例えば、複数の列に関して 2 つのクエリー・サブジェクトで行列式が存在し、クエリー・サブジェクト間の関係ではこれらの列のサブセットだけが使われるような場合が考えられます。関係の中で追加の列を使用するのが不適切な場合には、クエリー・サブジェクトの行列式の情報を変更してください。

複数ファクト、複数細分性のクエリーディメンション・データが格納されているテーブルがさまざまなキー列で複数のファクト表に結合されている場合は、複数ファクト、複数細分性のクエリーがリレーショナル・データ・ソースで発生します。

このセクションでは、ディメンションという用語が概念的な意味で使用されていることに注意してください。1:1 または 0:1 のカーディナリティーが設定されたクエリー・サブジェクトは、ディメンションとして機能します。詳細については、 381ページの『カーディナリティー』を参照してください。

一般に、ディメンション・クエリー・サブジェクトには、反復するキーが設定された属性データの個別のグループやレベルがあります。IBM CognosStudio/Authoring ツールでは、レポート内に存在する細分性の最低共通レベルにデータが自動的に集計されます。反復データが含まれている列に対して合計を作成すると、二重カウントが発生します。データの細分性のレベルを適切にモデル作成すれば、二重カウントを防止できます。

注: レポートでは、最低共通レベルより下の細分性レベルのデータを表示できます。このようにすると、より上位の細分性のデータは反復されますが、行列式が正しく適用されていれば、合計には影響しません。

次の例では、「販売」と「製品販売予測」という 2 つのファクト・クエリー・サブジェクトが、「時間」ディメンションと「製品」ディメンションという 2 つのディ


メンション・クエリー・サブジェクトを共有しています。

この例の細分性問題の焦点は「時間」です。「販売」は「日キー」で「時間」に結合され、「製品販売予測」は「月キー」で「時間」に結合されています。これらは別個の結合キーであるため、少なくとも 2 つの行列式を「時間」で明確に識別する必要があります。例えば、「月」と「日」の行列式でそれらのキーを指定します。「日」は「時間」の一意なキーで、「月」キーはその月の日ごとに反復されます。

例えば、「月」の行列式は次のようになります。


「製品」クエリー・サブジェクトには、少なくとも「製品ライン」、「製品タイプ」、「製品」の 3 つの行列式がある可能性があり、「製品キー」で両方のファクト表と関連付けられています。「製品」クエリー・サブジェクトについては細分性の問題は発生しません。

デフォルトでは、レポートが集計され、細分性の最低共通レベルの各ファクト表からレコードが取得されます。「販売」の「数量」、「製品販売予測」の「予想販売量」、「時間」の「月」、「製品」の「製品名」を使用するレポートを作成すると、各ファクト表における細分性の最低共通レベルからレコードが取得されます。この例では、月レベルと製品レベルになっています。

複数の細分性レベルにデータが存在する場合に二重カウントを防止するには、「時間」クエリー・サブジェクト用に少なくとも 2 つの行列式を作成します。例については、 384 ページの『行列式』を参照してください。

月製品名数量予想販売量

2007.4 Aloe Relief 1,410 1,690

2007.4 Course ProUmbrella

132 125

2007.2 Aloe Relief 270 245


1

2006.2 Aloe Relief 88 92

「時間」クエリー・サブジェクトで行列式を正しく指定しないと、間違って集計される場合があります。例えば、「製品販売予測」の「月」レベルに存在する「予想販売量」の値は、「時間」クエリー・サブジェクトで毎日反復されています。行列式が正しく設定されていないと、「予想販売量」の値に月の日数が乗算されてしまいます。


月製品名数量予想販売量

2007.4 Aloe Relief 1,410 50,700


132 3,750

2007.2 Aloe Relief 270 7,134


29

2006.2 Aloe Relief 88 2,576

「予想販売量」列の数値が異なっていることに注意してください。

モデル設計に関する考慮事項モデルを作成するときには、どんなアプリケーションにも適した万能のモデルを実現するワークフローは存在しない点を理解しておくことが重要です。モデルの作成を始める前に、機能性、使いやすさ、パフォーマンスに関するアプリケーションの要件を理解しておくことが重要です。このセクションに示されている多くの質問の答えは、データ・ソースの設計とアプリケーションの要件によって決まります。

関係と行列式を作成する場所関係をどこに作成すればよいか迷うことがよくあります。データ・ソース・クエリー・サブジェクトの間に関係を作成すべきか、モデル・クエリー・サブジェクトの間に作成すべきか、それとも両方の間に作成するのがよいか、その答えは、モデル化しようとしているデータ・ソースの複雑さによって異なります。

データ・ソース・クエリー・サブジェクトでは、関係と行列式が両方とも使用されます。

モデル・クエリー・サブジェクトでは、関係と行列式を使用した場合の副作用について次のように考慮する必要があります。

v モデル・クエリー・サブジェクトはビューとして機能し始めるため、クエリー・サブジェクトの「SQL 生成」タイプの「ビューとして」または「最小化」の設定がオーバーライドされます。

つまり、クエリー・サブジェクト内のどのアイテムが参照されるかに関わらず、SQL は同じです。詳細については、 392 ページの『最小化された SQL とは』を参照してください。

v モデル・クエリー・サブジェクトは、スタンドアロン・オブジェクトになります。

つまり、参照されるオブジェクト間の関係を除いて、基盤となる関係は適用されなくなります。基盤となるクエリー・サブジェクトのメタデータから以前に推測されていた関係を追加で作成する必要が生じることがあります。

v モデル・クエリー・サブジェクトに行列式を作成しても、関係が一緒に作成されていないと、その行列式は無視されます。

以下に、「最小化された SQL」設定を意図的にオーバーライドしてモデルを簡素化するモデル・クエリー・サブジェクトの関係の例を示します。この例では、


ORDER_HEADER (注文ヘッダー) と ORDER_DETAILS (注文の詳細) が組み合わされて、1 つのファクトとして動作します。これらは独自のフォルダーに配置されており、ORDER_HEADER と ORDER_DETAILS の間の関係を除き、これらに対するすべての関係は削除されています。モデル・クエリー・サブジェクトを作成して関係を付加した後に問題となるのは、この関係のみです。

モデル内のどこに関係および行列式を指定するか決定するには、最小化された SQLがアプリケーションに与える影響を理解しておく必要があります。

関係、行列式、および最小化された SQL の詳細については、「IBM CognosFramework Manager User Guide」の Model Advisor に関するトピックを参照してください。

最小化された SQL とは最小化された SQL を使用すると、選択されたクエリー・アイテムの値を取得するために必要な最低限のテーブルと結合のセットだけが、生成される SQL に含まれます。

最小化された SQL の例として、Product (製品) テーブルを以下に示します。 4 つのクエリー・サブジェクト Product Line (製品ライン)、Product Type (製品タイプ)、Product (製品)、および Product Multilingual (製品マルチリンガル) がすべて互いに結合されています。

モデル・クエリー・サブジェクトでこれらを組み合わせることができます。


Products モデル・クエリー・サブジェクトの全体をテストすると、クエリーのfrom 節で 4 つのテーブルが参照されていることがわかります。

selectPRODUCT_LINE.PRODUCT_LINE_CODE as Product_Line_Code,PRODUCT_LINE.PRODUCT_LINE_EN as Product_Line,PRODUCT_TYPE.PRODUCT_TYPE_CODE as Product_Type_Code,PRODUCT_TYPE.PRODUCT_TYPE_EN as Product_Type,PRODUCT.PRODUCT_NUMBER as Product_Number,PRODUCT_MULTILINGUAL.PRODUCT_NAME as Product_NamePRODUCT_MULTILINGUAL.DESCRIPTION as Product_Description,PRODUCT.INTRODUCTION_DATE as Introduction_Date,PRODUCT.PRODUCT_IMAGE as Product_Image,PRODUCT.PRODUCTION_COST as Production_Cost,PRODUCT.MARGIN as Marginfromgosl_82..gosl.PRODUCT_LINE PRODUCT_LINE,gosl_82..gosl.PRODUCT_TYPE PRODUCT_TYPE,gosl_82..gosl.PRODUCT PRODUCT,gosl_82..gosl.PRODUCT_MULTILINGUAL PRODUCT_MULTILINGUALwhere(PRODUCT_MULTILINGUAL."LANGUAGE" - N'EN')and(PRODUCT_LINE.PRODUCT_LINE_CODE = PRODUCT_TYPE.PRODUCT_LINE_CODE)and(PRODUCT_TYPE.PRODUCT_TYPE_CODE = PRODUCT.PRODUCT_TYPE_CODE)and(PRODUCT.PRODUCT_NUMBER = PRODUCT_MULTILINGUAL.PRODUCT_NUMBER

Product name (製品名) だけをテストした場合、結果としてできたクエリーでは、必要とされたテーブル Product Multilingual だけが使用されることがわかります。これが、最小化された SQL の効果です。

selectPRODUCT_MULTILINGUAL.PRODUCT_NAME as Product_Namefromgosl_82..gosl.PRODUCT_MULTILINGUAL PRODUCT_MULTILINGUALwhere(PRODUCT_MULTILINGUAL."LANGUAGE" - N'EN")

例: 最小化された SQL が重要になる場合

正規化されたデータ・ソースのモデルを作成している場合は、最小化された SQLを使用すると、一部の要求で使われるテーブルの数が減ってパフォーマンスが向上


するため、使用を検討することができます。この場合、データ・ソース・クエリー・サブジェクト間の関係と行列式を作成した後、関係が設定されていないモデル・クエリー・サブジェクトを作成するのが最善です。

オブジェクト間に関係がなければスター・スキーマ・グループを作成できないという誤解が一般的になっていますが、それは正しくありません。グループに含めるモデル・クエリー・サブジェクトを選択して、「スター・スキーマ・グループ」ウィザードを使用してください。または、ショートカットを作成して、新しいネームスペースにそれらを移動することもできます。関係へのショートカットは必要ありません。この機能はダイアグラム内の表示のみを目的としたものです。Studio/Authoring ツールでのクエリー生成と表示に対しても、同じ効果があります。

例: 最小化された SQL が、予測可能なクエリーほど重要ではない場合

データ・ソース内の複数の要素を 1 つのデータ・オブジェクトであるかのように動作させるために、それらをカプセル化する必要が生じることがあります。例えば、常にファクトに結合される必要があるセキュリティー・テーブルなどです。 GreatOutdoors Sales モデルの Order Header と Order Details は、一緒にファクトを表すテーブル・セットであるため、これらを常に一緒に照会するのが適切でしょう。例については、 391 ページの『関係と行列式を作成する場所』を参照してください。

メタデータ・キャッシュとはIBM Cognos Framework Manager は、データ・ソースからインポートされるメタデータを保管します。しかし、ガバナー設定や、モデルで行われる特定の操作によっては、クエリーを準備するときにこのメタデータが使用されない可能性があります。

「実行時の拡張モデル移植性を許可」ガバナーを有効にした場合、クエリーの準備の前に、Framework Manager はメタデータについての情報を得るために常にデータ・ソースを照会します。このガバナーを有効にしていないと、ほとんどの場合、Framework Manager はデータ・ソースを照会する代わりに、モデルに保存済みのメタデータにアクセスします。主に次のような場合は、例外となります。

v データ・ソース・クエリー・サブジェクトの SQL が変更された場合。これには、マクロの使用も含まれます。

v データ・ソース・クエリー・サブジェクトに計算やフィルターが追加された場合。

注: 生成されたメタデータ・クエリーは、ほとんどのベンダーのリレーショナル・データベース管理システムでサポートされており、ほとんどのレポート作成アプリケーションでは目立った影響がありません。

クエリー・サブジェクトとディメンションクエリー・サブジェクトとディメンションはそれぞれ使用目的が異なります。クエリー・サブジェクトはリレーショナル・クエリーの生成に使用され、スター・スキーマ規則を使ってこれを作成できます。他方、ディメンションはリレーショナル・ソースのディメンション・モデル作成に使用され、OLAP の動作を可能にします。


クエリー・サブジェクトはディメンションの基盤であるため、適切なリレーショナル・モデルを作成することは、ディメンション・モデルを成功させるための重要な条件です。

ディメンション・モデルが必要になるのは、レポート内のドリルアップとドリルダウンを有効にしたり、Studio/Authoring ツールのメンバー関数にアクセスしたりするために、IBM Cognos Analysis Studio を使用する場合のみです。多くのアプリケーションでは、OLAP 機能は必要ありません。例えば、主にアドホックなクエリーやレポート作成のためのアプリケーションでは、ドリルアップやドリルダウンは不要です。あるいは IBM Cognos ReportNet のモデルを保守している場合もあります。これらの場合には、クエリー・サブジェクトのみに基づいてパッケージを発行するよう選択できます。

クエリー・サブジェクトの行列式は標準ディメンションのレベルや階層と同じではありませんが、1 つの階層にこれらを密接に関連付けることができます。クエリー・サブジェクトをディメンションの基盤として使用することを計画している場合は、作成しようとしている階層の構造を考慮して、集計時に正しい結果が得られるような行列式を必ず作成しておく必要があります。以下の点を確認してください。

v 標準ディメンションの階層の各レベルに対して指定された行列式がクエリー・サブジェクトに存在する。

v 標準ディメンションのレベルと同じ順序で行列式が指定されている。

v 集計方法が異なる複数の階層を設定しようとしている場合は、他の階層用のソースとして別の行列式を持つ追加のクエリー・サブジェクトを作成すべきかどうかを検討する。

正しい結果と良好なパフォーマンスを実現する完全なリレーショナル・モデルを作成すると、ディメンション・モデルを開発するための強固な基盤になります。さらに、データ・ソースと Studio/Authoring ツールに公開されるオブジェクトの間にモデル・オブジェクト (クエリー・サブジェクトまたはディメンション) のレイヤーを存在させることにより、変更をユーザーに意識させずに済みます。

モデル・オブジェクトとショートカットモデル・オブジェクトとショートカットの主な違いは、モデル・オブジェクトの場合、アイテムを含める/除外する操作や、アイテムの名前変更を自由に行うことができる点です。クエリー・アイテムを限定的に含める必要がある場合や、アイテムの名前を変更する必要がある場合は、ショートカットの代わりにモデル・オブジェクトを使用できます。






標準ショートカットは通常、スター・スキーマ・グループと共に一致するディメンションとして使用され、まったく同じ名前と外観を持つ複数の参照を複数の場所に作成します。次の例では、Products (製品) と Order Time (注文時刻) に対して作成されたショートカットが参照として動作します。 Product Forecast と SalesTarget の両方から Products を得るようクエリーが作成されている場合、クエリーはオリジナルに基づく Products の定義を使用し、この定義はクエリーに 1 回だけ出現します。

別名ショートカットは通常、ロール・プレイング・ディメンションや共有テーブルで使用されます。この資料にはロール・プレイング・ディメンションの例が既に掲載されているため、共有テーブルの場合について説明します。この例では、SalesStaff (販売員) と Sales Branch (販売支店) を別々の階層として扱うことができます。販売員は支店間で異動する場合があることがわかっているため、Sales Branchと Sales Staff のそれぞれに対する独立した注文のレポート、および両方を一緒にした注文のレポートを作成できる必要があります。そのためには、Sales Staff 階層のレベルとして使用できる Sales Branch の別名を作成する必要があります。


新しい別名ショートカットを設定すると、Sales Branch ごとの注文と Sales Staffごとの注文を、現在の支店情報と共に同時に取得するクエリーを作成できます。

以前のリリースのモデルを開くと、「ショートカット処理」ガバナーは「自動」に設定されます。「自動」を使用すると、以前のリリースと同じ方法でショートカットが機能します。つまり、ターゲットと同じフォルダーにあるショートカットは別名 (つまり独立したインスタンス) として動作し、モデル内の他の場所にあるショートカットはオリジナルへの参照として動作します。「Treat As」プロパティーを利用するには、モデルを検証して、修復時にガバナーを「明示的」に変更することを推奨します。修復処理では、「自動」設定によって従う規則に基づき、「TreatAs」プロパティーから得られる正しい値にすべてのショートカットが変更されます。つまり、ショートカットの「Treat As」プロパティーに 1 つ以上の変更を加えない限り、モデルの動作は変わりません。

新しいモデルを作成すると、「ショートカット処理」ガバナーは常に「明示的」に設定されます。

ガバナーが「明示的」に設定されると、「Treat As」プロパティーからショートカットの動作が取得され、モデル内のどの場所にあるかに関わらず、ショートカットの動作方法を完全に制御することができます。

フォルダーとネームスペース






モデルの計算における演算順序の設定比率関連の計算などの場合には、算術演算より前に計算項目の集計を実行するのが効率的である場合があります。

例えば、以下の Order details (注文の詳細) ファクトには各注文についての情報が含まれています。

Margin は、利益率を次のように計算します。

Margin = (Revenue - Product cost) / Revenue

Order details ファクトを使って各製品の Revenue (収益)、Product cost (製品原価)、Margin を表示するクエリーを実行すると、次のような結果になります。

Product number (製品番号) Revenue (収益)

Product cost (製品コスト) Margin (利益)

1 $23,057,141 $11,292,005 61038%

2 $11,333,518 $6,607,904 49606%


これを見ると、Margin の値が不適切であるようです。これは、Margin を計算するときの演算順序が原因です。 Margin は次のように計算されます。

Margin = sum( (Revenue - Product cost) / Revenue )

算術演算の後に集計が実行されているため、この場合は不適切な結果になっています。

Margin に関して適切な値が得られるようにするには、以下のように、算術演算の前に集計を実行する必要があります。

Margin = ( sum(Revenue) - sum(Product cost) ) / sum(Revenue)

これにより、次のような結果が生成されます。

Product number (製品番号) Revenue (収益)

Product cost (製品コスト) Margin (利益)

1 $23,057.141 $11,292,005 51.03%

2 $11,333,518 $6,607,904 41.70%

IBM Cognos Framework Manager でこのような結果を得るには、Margin に関する独立した計算を作成して、その「標準集計」プロパティーを「算出」に設定することができます。計算式の各クエリー・アイテムは、「標準集計」プロパティーで指定されたとおりに集計されます。 Revenue および Product cost の「標準集計」プロパティーは「合計」に設定されており、したがって、計算時にはこれらの項目を集計するのに合計が使われます。

注: クエリー・サブジェクト内に埋め込まれた計算では、計算集計タイプがサポートされません。これがサポートされるのは、独立した計算、および数値データ・ディメンションに埋め込まれた、同じ数値データ・ディメンションの数値データに基づく計算の場合のみです。

例えば、数値データ・ディメンション Sales に埋め込まれた次のような Margin 計算を考えてみましょう。

この例で、Margin は同じ数値データ・ディメンション Sales 内の数値データProduct cost および Revenue に基づいています。 Margin の「標準集計」プロパティーが「算出」に設定されている場合、次のように集計されます。

Margin = sum(Revenue - Product cost ) / sum(Revenue)

Margin が数値データ Product cost および Revenue のソース・クエリー・アイテム (Sales (model).Product cost、Sales (model).Revenue) に基づいている場合、計算集計はサポートされず、自動集計として動作します。この場合、Margin は次のように集計されます。

Margin = sum( Revenue - Product cost) / Revenue)


クエリー・アイテムが集計される方法の変更について、詳しくは「IBM CognosFramework Manager User Guide」を参照してください。

モデル・サイズの影響モデルのサイズが、Framework Manager アプリケーションの効率に影響を与える場合があります。

非常に大きなモデルを処理すると、処理時間が長くなり、極端な場合にはメモリー不足になる場合があります。「発行の影響を分析」、「レポートの従属関係を検索」、「パッケージを発行」、「Model Advisor を実行」などの操作は、50 MB未満のモデルで最適に実行されます。

ディメンション・モデル作成の概念標準ディメンションと数値データ・ディメンションを使用すると、メタデータのOLAP 表示、ドリルアップ、ドリルダウンなど、さまざまな OLAP 機能を使用できます。 IBM Cognos Analysis Studio でリレーショナル・データ・ソースを使用するには、スター・スキーマ・グループ (複数のディメンションを持つ 1 つのファクト) を使用する必要があります。

モデルを作成するときには、スター・スキーマの概念が適用されているリレーショナル・モデルに基づいてモデルの標準ディメンションとモデルの数値データ・ディメンションを作成することを推奨します。

データ・ソース・クエリー・サブジェクトをデータ・ソース・ディメンションに変換することはできますが、クエリー・サブジェクトやモデル・ディメンションに比べてデータ・ソース・ディメンションの機能は限られているため、一般的には使用しないことを推奨します。

標準ディメンション標準ディメンションは、数値データ・ディメンションでモデル化されるデータのコンテキストを示す記述的データを表します。標準ディメンションは、「レベル」と呼ばれる情報のグループに細分化されます。さらに、さまざまなレベルを階層に編成することができます。例えば、製品のディメンションでは Product Line (製品ライン)、Product Type (製品タイプ)、Product というレベルが Product という 1つの階層に編成されることがあります。別の例として、時間のディメンションでは、Year、Quarter (四半期)、Month、Week、Day というレベルが 2 つの階層に編成されます。 1 つの階層 YQMD には Year、Quarter、Month、Day レベルが含まれ、もう 1 つの階層 YWD には Year、Week、Day レベルが含まれます。

最も単純なレベル定義はビジネス・キーとキャプションから成り、それぞれが 1 つのクエリー・アイテムを参照します。レベルのインスタンス (または行) は、そのレベルのメンバーとして定義されます。それを識別する一意のメンバー名は、現在のレベルおよび上位レベルのビジネス・キーの値で構成されます。例えば、[gosales].[Products].[ProductsOrg].[Product]->[All Products].[1].[1].[2] では、ネームスペース [gosales] にある [Products] ディメンションの ProductsOrg階層の Product (4 番目のレベル) にあるメンバーを識別します。この製品のキャプションは TrailChef Canteen で、これはメタデータ・ツリーとレポートに表示される名前です。


レベルの各セットのデータを識別するために十分な情報が、レベルのビジネス・キーにあれば、レベルを一意なものとして定義できます。Great Outdoors Sales モデルでは、さまざまな製品タイプに割り当てられる製品番号がないため、Product レベルのメンバーは Product type の定義を必要としません。一意として定義されないレベルは、上位レベルの細分性のキーが必要であるためにマルチパート・キーを使用する行列式に似ています。 386 ページの『マルチパート・キーが指定された行列式の使用』を参照してください。先祖メンバーの中に一意でないメンバーがあり、レベルが一意として定義されている場合には、一意でないメンバーのデータが1 つのメンバーとしてレポートされます。例えば、City が一意として定義され、名前によって識別される場合には、英国の London とカナダの London のデータが結合されます。

数値データ・ディメンション数値データ・ディメンションは、標準ディメンションで記述される量的データを表します。さまざまな OLAP 製品においてさまざまな用語で呼ばれていますが、数値データ・ディメンションとは、単にファクト・データが含まれるオブジェクトのことです。数値データ・ディメンションにはファクト・クエリー・サブジェクトをディメンション・クエリー・サブジェクトに結合するために使われる外部キーが含まれていないため、ファクト・クエリー・サブジェクトとは異なります。これは、数値データ・ディメンションがリレーショナル・データ・オブジェクトであるかのように結合されるよう意図されていないためです。クエリー生成のために、数値データ・ディメンションは基礎となるクエリー・サブジェクトを介して標準ディメンションとの関係を導出します。同様に、他の数値データ・ディメンションとの関係は、一致するディメンションとして動作するよう作成されたクエリー・サブジェクトに基づく標準ディメンションを介して得られます。複数のファクト、複数の細分性を持つクエリーを有効にするには、標準ディメンションと数値データ・ディメンションを作成する前に、クエリー・サブジェクトと行列式を適切に作成しておく必要があります。

範囲の関係範囲の関係は、レポート作成で使用できる数値データのレベルを定義するためのもので、数値データ・ディメンションと標準ディメンションの間にのみ存在します。範囲の関係は結合とは異なり、Where 節には影響を及ぼしません。範囲の関係では、クエリーの形成方法を制御する条件や基準は設定されません。指定されたファクトを使ってディメンションを照会できるかどうかが指定されるだけです。範囲の関係がない場合、実行時にエラーが発生するか、レポートの他のアイテムによっては想定よりも上位のレベルでファクト・データが集計される可能性があります。

数値データ・ディメンションに関して範囲の関係を設定すると、その数値データ・ディメンション内のすべての数値データに同じ設定が適用されます。数値データ・ディメンション内の数値データに関して異なるレベルでデータがレポートされる場合は、数値データにおいて範囲を設定することができます。データをレポートできる最下位レベルを指定できます。

この例では、Sales Target (販売目標) 数値データ・ディメンションに数値データが1 つだけ存在し、その範囲は Order Time ディメンションの Order Month レベルまでと、Product ディメンションの Product レベルまでに設定されています。つまり、ユーザーが月レベルを超えてドリル操作しようとすると、反復データが表示さ


れます。

リレーショナル・モデルの作成IBM Cognos Framework Manager ではリレーショナル・データ・ソースのディメンション・モデル作成が可能ですが、そのためには適切なリレーショナル・モデルが存在する必要があります。

IBM Cognos ReportNet には、複数ファクトのクエリーを可能にして二重カウントを防ぐためのディメンション機能がいくつか備わっていました。 IBM CognosReportNet に続いて、IBM Cognos ソフトウェアには、メタデータのディメンション表示用に特別に設計された機能と、リレーショナル・データ・ソースを使ったOLAP 機能が備わっています。 IBM Cognos ReportNet でリレーショナル・モデル作成に適用された概念は、引き続き使用されます。ただし、少しの変更点については「Framework Manager User Guide」で説明されているとおりです。

新しい Framework Manager モデルを作成するときには、ディメンション・モデル作成機能を使用するつもりがない場合でも、クエリー生成を定義する一般的な手順に従います。レポート内のドリルアップとドリルダウンを有効にしたり、Studio/Authoring ツールのメンバー関数にアクセスしたりする目的で IBMCognos Analysis Studio で使用するためには、リレーショナル・データ・ソースのディメンション・モデルを作成する必要があります。

リレーショナル・モデル作成の基盤の定義モデルとは、関連する 1 つ以上のレポート作成アプリケーションで必要とされる関連オブジェクトから成るセットです。適切なリレーショナル・モデルはディメンション・モデルの基盤になります。

リレーショナル・モデル作成の基盤を定義するときには、次のことを考慮してください。

v メタデータのインポート。インポートの詳細については、「IBM CognosFramework Manager User Guide」を参照してください。

v 403 ページの『インポートしたメタデータの検証』.

v 403 ページの『あいまいな関係の解決』.

v スター・スキーマの概念を使用したリレーショナル・モデルの簡素化。その際、ファクトとディメンションのカーディナリティーを分析し、関係と行列式をどこに配置するかを決定します ( 391 ページの『モデル設計に関する考慮事項』)。


v 必要に応じてデータ・セキュリティーを追加します。データ・セキュリティーの詳細については、「Framework Manager User Guide」を参照してください。

次に、必要に応じてモデルのディメンション表現方法を定義し、表示のためにモデルを整理することができます。

インポートしたメタデータの検証メタデータをインポートした後に、インポートしたメタデータを確認する必要があります。

以下の領域を検証してください。

v 関係とカーディナリティー

v 行列式

v クエリー・アイテムの「使用方法」プロパティー

v クエリー・アイテムの「標準集計」プロパティー

ここでは関係とカーディナリティーについて説明します。「使用方法」および「標準集計」プロパティーについては、「Framework Manager ユーザー・ガイド」を参照してください。

ファクトおよびディメンションのカーディナリティーの分析:

関係のカーディナリティーは、キーの特定のセット (または結合) に基づいて別のテーブルの行に関係する 1 つのテーブルの行数を定義します。 IBM Cognos ソフトウェアでは、どのクエリー・サブジェクトがファクトやディメンションとして動作するかを推定するためにカーディナリティーが使用されます。このため、ディメンション表から成る共通セットに複数のファクト表が結合されている場合にスター・スキーマ・データによって発生する一般的な形式のループ結合を、IBM Cognos ソフトウェアは自動的に解決することができます。

予測可能なクエリーにするためには、カーディナリティーがどのように使用されるかを理解して、それをモデルに正しく適用することが重要です。基になるデータ・ソース・スキーマを調べて、カーディナリティーによってファクトやディメンションが間違って識別されるため予測不能なクエリー結果になる可能性がある領域を扱うことをお勧めします。 Framework Manager の Model Advisor 機能を使用すると、カーディナリティーがどのように解釈されるかを理解するうえで役立ちます。

詳細については、 381 ページの『カーディナリティー』を参照してください。

あいまいな関係の解決クエリー・サブジェクトやディメンションによって表されるデータを複数のコンテキストまたは役割で表示できる場合、あるいは複数の方法で結合できる場合には、あいまいな関係が発生します。

最も一般的なあいまいな関係は、次のとおりです。

v 404 ページの『ロール・プレイング・ディメンション』

v 407 ページの『ループ結合』

v 408 ページの『再帰的関係と帰納的関係』


Model Advisor を使用すると、クエリー生成で問題を発生させる可能性のある関係を検出して、以下に説明するいずれかの方法で解決することができます。なお、ここで説明する以外にも問題を解決する方法があることに注意してください。主な目標は、クエリー・パスを明確にすることです。

ロール・プレイング・ディメンション:

別のテーブルとの間に複数の有効な関係があるテーブルを、ロール・プレイング・ディメンションといいます。これは通常、Time や Customer (顧客) などのディメンションに見られます。

例えば、Sales fact (販売ファクト) と Time クエリー・サブジェクトの間に、Order Day (注文日)、Ship Day (発送日)、Close Day (完了日) というキーに基づく複数の関係があるとします。

インポートされたオブジェクト、ファクト・クエリー・サブジェクト、ロール・プレイング・ディメンション・クエリー・サブジェクトに対する関係を削除します。役割ごとのモデル・クエリー・サブジェクトを作成します。ユーザーに表示されるメタデータ・ツリーが短くなるように、不要なクエリー・アイテムを除外することを考慮してください。各モデル・クエリー・サブジェクトとファクト・クエリー・サブジェクトとの間に、適切な関係がただ 1 つ存在するようにしてください。注:このようにすると「Minimized SQL」設定がオーバーライドされますが、Time ディメンションが単一のテーブルで表されている限り、この場合には問題と見なされません。


同じ概念を共有しない他のファクトでこれらの役割をどのように使用するかを決定します。例えば Product forecast (製品販売予測) ファクトに含まれている時間キーは 1 つだけです。データとビジネスを理解したうえで、Time 用に作成されたすべて (または一部) の役割を Product forecast ファクトに適用するかどうか決定する必要があります。

この例では、次のいずれかの操作を実行できます。

v 一致する時間ディメンションとなる追加のクエリー・サブジェクトを作成して、一致するディメンションとしての明確な名前をそれに付けます。

最もよく使われる役割を選択します。次に、このバージョンが、これを必要とするすべてのファクトに結合されるようにします。この例では、Close Day が選択されています。


v Product forecast ファクトで、Ship Day、Order Day、Close Day を入れ替え可能な時間クエリー・サブジェクトとして扱うことができます。

この場合、各ロール・プレイング・ディメンションと Product forecast ファクト間の結合を作成する必要があります。 Product forecast ファクトを照会する場合、一度に 1 つだけ時間ディメンションを使用できます。そうしない場合、レポートにデータが含まれない可能性があります。例えば、Month_key=ShipMonth Key (200401)、Month key=Close Month Key (200312) のように指定します。


ディメンション・モデルを作成する場合、各モデル・クエリー・サブジェクトを標準ディメンションのソースとして使用し、ディメンションと階層に適切な名前を付けます。それぞれの役割に固有の、対応する範囲の関係が存在するようにしてください。

ループ結合:

通常、モデルの中にループ結合があると、予期しない動作が発生します。これには、スター・スキーマのループ結合は含まれません。

注: カーディナリティーによってファクトとディメンションが明確に識別される場合、共通のディメンション表セットに複数のファクト表が結合されているときにスター・スキーマ・データが原因で発生するループ結合を、IBM Cognos ソフトウェアは自動的に解決できます。

ループ結合の場合、クエリー・サブジェクトの定義のあいまいさが、問題の主な兆候です。あいまいに定義されたクエリー・サブジェクトがループ結合に含まれる場合、特定のクエリーでどの結合が使用されるかは、(関係の場所、結合パスのセグメント数など) さまざまな要因に基づいて決定され、他のすべてが等しい場合は、アルファベット順で最初の結合パスが使われます。これはユーザー側の混乱を招くため、結合パスを明確に識別できるようにモデルを作成することを推奨します。

クエリー・サブジェクトの定義があいまいなループ結合の例として、Sales Staff (販売員) と Branch (支店) を考えます。

この例では、Branch を Order (注文) に直接結合することも、Sales Staff 経由でOrder に結合することも可能です。主な問題は、Branch と Order が結合された場


合、結合パスを Branch、Sales Staff、Order にした場合とは結果が異なる点です。このようになる理由は、従業員が支店間を異動する可能性があるためです。その年の途中で異動した従業員は、以前の支店で多くの売上を得たとしても、現在の支店で集計されてしまいます。このようにモデルが作成されていると、どの結合パスが選ばれるか保証できず、クエリーで選択されるアイテムによって変化する可能性が高くなります。

再帰的関係と帰納的関係:

再帰的関係と帰納的関係は、複数レベルの細分性が存在することを意味します。IBM Cognos Framework Manager は再帰的関係をインポートしますが、クエリー実行時にはそれらを使用しません。自己結合である再帰的関係は、表現のためにのみモデル内に表示されます。

実際に機能する再帰的関係を作成するには、別名ショートカット、データ・ソース・クエリー・サブジェクトのコピー、またはモデル・クエリー・サブジェクトを作成できます。次に、元のクエリー・サブジェクトと新しいクエリー・サブジェクト間の関係を作成します。モデル・クエリー・サブジェクトを使用すると、クエリー・サブジェクトに含めるクエリー・アイテムを指定できるため、柔軟性を高める


には、通常、この選択肢が適しています。ただし、保守の観点からは、ショートカットが優れています。詳細については、 395 ページの『モデル・オブジェクトとショートカット』を参照してください。

例えば Sales Staff (販売員) クエリー・サブジェクトでは、Sales_Staff_Code (販売員コード) と Manager_Code (責任者コード) の間に帰納的関係が存在します。

Manager を表すモデル・クエリー・サブジェクトを作成します。 Manager とSales Staff の間に 1..1 対 1..n の関係を作成します。次に、新しいモデル・クエリー・サブジェクトに結合します。

Sales Staff に基づく Manager のモデル・クエリー・サブジェクトを使用した単純な 2 レベル構造の場合、モデルは次のようになります。

帰納的な均衡階層の場合は、階層内の追加のレベルごとにこの手順を繰り返します。

深い帰納的階層または非均衡階層の場合は、データ・ソース内の階層を平らにして、その (フラット化された) 階層のモデルを 1 つの標準ディメンションで作成することを推奨します。


リレーショナル・モデルの簡素化スター・スキーマの概念をディメンション・データやファクト・データに適用することで、モデルを簡素化できます。

説明データを表すクエリー・サブジェクトのモデル作成:

IBM Cognos のディメンション・モデルの作成では、モデルの論理層にスター・スキーマの原則を適用する必要があります。

正規化されているデータ・ソースまたはスノーフレーク・データ・ソースには、多くの場合、1 つのビジネス概念を記述するテーブルが複数含まれています。例えば、Product (製品) の正規化表現に、1..n 関係によって関連付けられる 4 つのテーブルが含まれているとします。各 Product Line (製品ライン) には 1 つ以上のProduct Types (製品タイプ) があります。各 Product Type には 1 つ以上のProduct (製品) があります。 Product には複数の言語による名前と説明があり、これらは Product Multilingual (製品マルチリンガル) 検索テーブルに含まれています。

モデルを簡略化する 1 つの方法は、記述可能なビジネス概念ごとに 1 つのモデル・クエリー・サブジェクトを作成することです。ユーザーは個々のクエリー・サブジェクト間の関係を知らない可能性があることに加えて、各モデル・オブジェクトを展開してクエリー・アイテムを選択するには余分な手間がかかるため、クエリー・サブジェクトをグループ化しておくと便利です。

分析の次の手順では、各クエリー・サブジェクト用のレベルを設定した標準ディメンションを作成します。

ファクト・データのモデル作成:

データ・ソースには、多くの場合、ファクトを含むマスター詳細テーブルが存在します。例えば、データの挿入と更新に Order header (注文ヘッダー) および Orderdetails (注文の詳細) テーブルが使用される場合は、マスター詳細の構造が効果的です。レポート作成や分析にこれらのテーブルを使用する場合は、これらを 1 つの論理的なビジネス概念にまとめてモデルを簡略化することができます。または、Returned Items (返品された製品) などのディメンションをそれらの間に挿入することもできます。どの解決策を選択するかは、要件によって異なります。


この例のモデルを簡略化するには、スター・スキーマの概念を適用することにより、Order header と Order details の両方の外部キーを結合して Order detailsレベルですべての数値データを含む 1 つのモデル・クエリー・サブジェクトを作成します。このクエリー・サブジェクトを、Order header および Order details が結合されたのと同じクエリー・サブジェクトに結合します。これらの間の結合を定義している関係を除き、2 つのデータ・ソース・クエリー・サブジェクトから元の関係を削除することができます。モデル・クエリー・サブジェクトへの関係を作成することの長所と短所については、 392 ページの『最小化された SQL とは』にある例を参照してください。

次の例では、Order header と Order details が Sales という名前の新しいモデル・クエリー・サブジェクトに結合されています。このクエリー・サブジェクトはProduct、Time、Order method (発注方法) に結合されています。

分析の次の手順では、モデル・クエリー・サブジェクトに基づいて数値データ・ディメンションを作成します。


ディメンションによるモデルの表現方法の定義IBM Cognos Framework Manager では、リレーショナル・データ・ソースのディメンション・モデル作成機能を使用できます。階層やレベルを持つディメンション・モデルを作成したり、複数の数値データを持つファクトを使用したりできます。その後、モデルで範囲を設定することにより、ディメンションを数値データに関連付けることができます。

リレーショナル・データ・ソースを IBM Cognos Analysis Studio で使用して、レポート内のドリルアップとドリルダウンを有効にしたり、Studio/Authoring ツールのメンバー関数にアクセスしたりするには、リレーショナル・データ・ソースからディメンション・モデルを作成する必要があります。

リレーショナル・モデルを基盤レイヤーとして使用し、ディメンションによるモデルの表現方法を定義することができます。

その後、表示のためにモデルを整理することができます。 415 ページの『モデルの整理』を参照してください。

標準ディメンションの作成



複数の階層を持つディメンションのモデル作成さまざまな階層表示を同じデータに対して適用できる場合は、複数の階層が発生します。階層の性質、および必要なレポートによっては、特定のケースに適用されるモデリング手法を評価する必要が生じることがあります。

例えば、販売員を責任者別または地域別に表示することができます。 IBM CognosStudio/Authoring ツールでは、これらの階層は別個の、しかし交換可能な論理構造として扱われ、基礎となる同じクエリーにバインドされます。

以下では、2 つの階層を持つ 1 つのディメンションとして販売員を示します。


Framework Manager では、階層が次のように定義されます。

Framework Manager では、標準ディメンションで複数の階層を指定することができます。標準ディメンションの複数の階層は、同じクエリーのビューとして動作します。ただし、クエリーで一度に使用できるのは 1 つの階層のみです。例えば、クロス集計レポートの行に 1 つの階層を使用し、クロス集計レポートの列に同じディメンションの別の階層を使用することはできません。同じレポート内で両方の階層が必要な場合は、各階層に 1 つずつ、2 つのディメンションを作成する必要があります。レベルや集計がかなり異なる複数の階層がある場合には、その階層の基盤として、適切な行列式を持つ別個のクエリー・サブジェクトを使うようにモデル化す


ることができます。唯一の要件は、階層の基盤として使われるすべてのクエリー・サブジェクトで、ファクト・データを提供するクエリー・サブジェクトへの結合が定義されている必要があるという点です。

以下は、階層ごとの個別のディメンションです。

階層ごとに大きく異なる列のセットが関連しており、別個の単純なクエリーを使って別個のディメンションとして階層をモデル化する方がユーザーにとって分かりやすい場合は、この方法を使用してください。

数値データ・ディメンションの作成

数値データ・ディメンションは、ファクトの集まりです。互いの間で有効な関係を持つ 1 つ以上のクエリー・サブジェクトに関して、1 つの数値データ・ディメンションを作成できます。

モデルの数値データ・ディメンションは、量的な項目のみで構成される必要があります。設計上、モデルの数値データ・ディメンションには結合するキーがないため、モデルの数値データ・ディメンションへの結合を作成することはできません。モデルの数値データ・ディメンションを標準ディメンションに結合する代わりに、基礎となるクエリー・サブジェクトでの結合を作成してください。次に、それらの間の範囲の関係を手作業で作成するか、有効範囲を検出します (両方のディメンションが同じネームスペースにある場合)。

範囲の関係の作成

範囲の関係は、レポート作成で使用できる数値データのレベルを定義するためのもので、数値データ・ディメンションと標準ディメンションの間にのみ存在します。範囲の関係は結合とは異なり、Where 節には影響を及ぼしません。範囲の関係では、クエリーの形成方法を制御する条件や基準は設定されません。指定されたファクトを使ってディメンションを照会できるかどうかが指定されるだけです。範囲の関係が欠落する場合、結果として実行時にエラーが発生します。

数値データ・ディメンションに関して範囲の関係を設定すると、その数値データ・ディメンション内のすべての数値データに同じ設定が適用されます。数値データ・


ディメンション内の数値データに関して異なるレベルでデータがレポートされる場合は、数値データにおいて範囲を設定することができます。データをレポートできる最下位レベルを指定できます。

数値データ・ディメンションを作成すると、IBM Cognos Framework Manager によって、その数値データ・ディメンションと既存の各標準ディメンションの間で範囲の関係が作成されます。 Framework Manager は、詳細の最下位レベルから始まって、数値データ・ディメンションと標準ディメンションの間の結合パスを検索します。使用可能な多くの結合パスが存在する場合、Framework Manager によって作成される範囲の関係は、意図されたものと異なる可能性があります。このようなケースでは、範囲の関係を編集する必要があります。

モデルの整理リレーショナル・モデルの基盤を用意し、ディメンションによる表現を作成した後、モデルを整理することができます。


v クエリー・サブジェクトを使ったクエリー実行に影響する複雑さを解決するために、オプションのネームスペースまたはフォルダーを 1 つ以上作成します。

IBM Cognos Analysis Studio を使用するためには、ディメンション・オブジェクトを持つメタデータを表すモデル内のネームスペースまたはフォルダーが必要です。


ビジネスの概念を使用して、ビジネス・ビューのモデルを作成します。それぞれ異なるユーザー・グループに適した多数のビジネス・ビューを 1 つのモデルに含めることができます。それらのビジネス・ビューを発行します。

v 『スター・スキーマ・グループ』を作成します。

v 必要に応じてオブジェクト・セキュリティーを適用します。

v パッケージを作成してメタデータを発行します。

ここに掲載されていないトピックについては、「Framework Manager UserGuide」を参照してください。

スター・スキーマ・グループ一致するディメンションの概念はディメンション・モデルの作成のみに適用されるのではなく、クエリー・サブジェクトにも同様に適用されます。

どのオブジェクトがグループを形成しているかに関するコンテキストをユーザーに示すショートカットのグループを素早く作成するために、「スター・スキーマ・グループ」ウィザードを使用します。これにより、ユーザーはモデルをより直観的に利用できるようになります。また、スター・スキーマ・グループでは異なるグループ内で共有ディメンションを繰り返すことができるため、複数ファクトのレポートも作成しやすくなります。こうして、さまざまなグループに共通するアイテムや、


部門の枠を超えた組織全体の (つまり複数ファクトの) レポート作成方法をユーザーが理解しやすくなります。詳細については、 388 ページの『複数ファクト、複数細分性のクエリー』を参照してください。

また、スター・スキーマ・グループには、複数の結合パスを持つクエリー用のコンテキストも用意されています。モデルのビジネス・ビュー内にスター・スキーマ・グループを作成すると、多くの結合パスを使用できる場合に、どれを選択すべきかを明確にすることができます。これは特に、ファクトのないクエリーの場合に便利です。

複数の一致するスター・スキーマ、またはファクトのないクエリー:

複数のファクト・クエリー・サブジェクトに結合されたディメンション・クエリー・サブジェクトが存在することがあります。数値データ・ディメンションやファクト・クエリー・サブジェクトのアイテムを含めずに、複数のディメンションまたはディメンション・クエリー・サブジェクトのアイテムを使ってレポート作成する際には、結合のあいまいさが問題になります。これを、ファクトのないクエリーといいます。

次の例では、Product dimension (製品ディメンション) と Time dimension (時間ディメンション) が、Product forecast fact (製品販売予測ファクト) および Salesfact (販売ファクト) に関連付けられています。

このような関係を使用して、Product と Time のアイテムのみを使用するレポートをどのようにして作成すればよいのでしょうか。例えば、どの製品について 2005


年の売上予測をしたか、または 2005 年にどの製品が実際に売れたかということがビジネス上の問題点となり得ます。このクエリーに含まれるのは Product と Timeのみですが、これらのディメンションは複数のファクトを経由して関連しています。ビジネス上のどの問題点が問われているかを推測する方法はありません。この場合、ファクトのないクエリーのコンテキストを設定する必要があります。

この例では、Product、Time、Product forecast へのショートカットを含むネームスペースと、Product、Time、Sales を含むネームスペースの 2 つを作成することを推奨します。

すべてのスター・スキーマに関してこの作業を行うと、ファクトとすべてのディメンションへのショートカットを 1 つのネームスペース内に配置することにより、結合のあいまいさを解消できます。各ネームスペース内の一致するディメンションのショートカットは同じであり、元のオブジェクトの参照となります。注: 標準ディメンションと数値データ・ディメンションにはまったく同じ規則が適用されます。

各スター・スキーマにネームスペースを使用することで、どのアイテムを使用すべきかユーザーにとって明確になります。 2005 年にどの製品が実際に販売されたかに関するレポートを作成するには、Sales ネームスペースの Product と Year を使用します。このコンテキストで該当する唯一の関係は Product、Time、Sales 間の関係であり、これを使ってデータが返されます。


第 11 章 IBM Cognos ソフトウェアによって生成される SQL

このドキュメントは、IBM Cognos ソフトウェアによって生成される SQL について説明しています。

このドキュメントに記載されている SQL サンプルは、長さの関係で編集されており、特定の例に重点が置かれています。これらの例では、バージョン 8.2 サンプル・モデルが使用されています。

ディメンション・クエリーについてディメンション・クエリーは、複数ファクト・クエリーを可能にすることを目的としています。

複数ファクト・クエリーの基本的な目標は、次のとおりです。

v ファクトの行がディメンションの行よりも多い場合など、共通ディメンション全体にファクト・データが完全には配置されていない場合にデータを保持する。

v 複数の異なる細分性レベルにファクト・データが存在する場合に、適切なグループ化で各ファクトが単一クエリーで表されるようにすることで、二重カウントを防止する。場合によっては、基礎となるクエリー・サブジェクトのための行列式を作成しなければならないこともあります。

単一ファクト・クエリースター・スキーマ・グループに対するクエリーは、単一のファクト・クエリーになります。

次の例では、作成されたすべてのクエリーのフォーカスは Sales です。Sales のデータをより有意義なものにするために、属性と記述がディメンションで示されます。ディメンションとファクトの関係はすべて、1-n です。


月と製品でフィルターに掛けると、結果は次のようになります。


一致するディメンションに対する複数ファクト、複数細分性のクエリー

複数ファクトおよび一致するディメンションに対するクエリーでは、各ファクト表とテーブルのディメンション間のカーディナリティーが考慮され、各ファクト表の行をすべて返す SQL が作成されます。

例えば、「Sales」と「Product Forecast」はどちらもファクトです。

この例は簡略化されたものです。IBM Cognos のモデル作成の推奨事項を使用して構築されたモデルに実際に表示される例ではないことに注意してください。

結果

「Month」および「Product」別の、「Sales」および「Product Forecast」に対する個別のクエリーでは、次の結果が生じます。「Sales」データは、実際は日のレベルで保存されています。

第 11 章 IBM Cognos ソフトウェアによって生成される SQL 421

「Sales」および「Product Forecast」に対するクエリーでは、各ファクト表とテーブルのディメンション間のカーディナリティーが考慮され、各ファクト表の行をすべて返す SQL が作成されます。ファクト表は、共通のキーである月と製品を使用して照合され、可能な場合は細分性の最下位の共通レベルに集計されます。この例では、日が月に自動集計されます。このタイプのクエリーでは Null 値が返されることがよくあります。その理由は、1 つのファクト表内のディメンション要素の組み合わせがもう一方のファクト表に存在しない場合があるためです。

「February 2004」の「Course Pro Umbrella」は、販売予測には存在しますが、販売実績には存在していないことに注目してください。「Sales」および「ProductForecast」のデータは、異なる細分性のレベルに存在します。「Sales」のデータは日のレベルに存在しますが、「Product Forecast」は月のレベルに存在します。

SQL

スティッチ・クエリーと呼ばれる、IBM Cognos ソフトウェアによって生成されるSQL は、間違って解釈されることがよくあります。スティッチ・クエリーでは、各スターにそれぞれ対応した複数のサブクエリーを使用します。これらのサブクエリーは、共通のキーを使用した完全外部結合によって結合されます。ここでの目標は、クエリーのどちらかの側で発生するすべてのディメンション・メンバーを保持することです。

次の例は、スティッチ・クエリーの主な機能を示すために短く編集されたものです。

selectcoalesce(D2.MONTH_NAME,D3.MONTH_NAME) as MONTH_NAME,coalesce(D2.PRODUCT_NAME,D3.PRODUCT_NAME) as PRODUCT_NAME,D2.EXPECTED_VOLUME as EXPECTED_VOLUME,D3.QUANTITY as QUANTITYfrom (select TIME.MONTH_NAME as MONTH_NAME,PRODUCT_LOOKUP.PRODUCT_NAME as PRODUCT_NAME,XSUM(PRODUCT_FORECAST_FACT.EXPECTED_VOLUME forTIME.CURRENT_YEAR,TIME.QUARTER_KEY,TIME.MONTH_KEY,


PRODUCT.PRODUCT_LINE_CODE, PRODUCT.PRODUCT_TYPE_CODE,PRODUCT.PRODUCT_KEY) as EXPECTED_VOLUMEfrom(select TIME.CURRENT_YEAR as CURRENT_YEAR,TIME.QUARTER_KEY as QUARTER_KEY,TIME.MONTH_KEY as MONTH_KEY,XMIN(TIME.MONTH_NAME for TIME.CURRENT_YEAR,TIME.QUARTER_KEY,TIME.MONTH_KEY) as MONTH_NAMEfrom TIME_DIMENSION TIMEgroup by TIME.MONTH_KEY) TIMEjoin PRODUCT_FORECAST_FACT PRODUCT_FORECAST_FACTon (TIME.MONTH_KEY = PRODUCT_FORECAST_FACT.MONTH_KEY)join PRODUCT PRODUCT on (PRODUCT.PRODUCT_KEY =PRODUCT_FORECAST_FACT.PRODUCT_KEY)where(PRODUCT.PRODUCT_NAME in ('Aloe Relief','Course ProUmbrella')) and(TIME.MONTH_NAME in ('April 2004','February 2004','February2006'))group byTIME.MONTH_NAME,PRODUCT_LOOKUP.PRODUCT_NAME) D2full outer join(select TIME.MONTH_NAME as MONTH_NAME,PRODUCT_LOOKUP.PRODUCT_NAME as PRODUCT_NAME,XSUM(SALES_FACT.QUANTITY for TIME.CURRENT_YEAR,TIME.QUARTER_KEY, TIME.MONTH_KEY,PRODUCT.PRODUCT_LINE_CODE, PRODUCT.PRODUCT_TYPE_CODE,PRODUCT.PRODUCT_KEY ) as QUANTITYfromselect TIME.DAY_KEY,TIME.MONTH_KEY,TIME.QUARTER_KEY,TIME.CURRENT_YEAR,TIME.MONTH_EN as MONTH_NAMEfrom TIME_DIMENSION TIME) TIMEjoin SALES_FACT SALES_FACTon (TIME.DAY_KEY = SALES_FACT.ORDER_DAY_KEY)join PRODUCT PRODUCT on (PRODUCT.PRODUCT_KEY = SALES_FACT.PRODUCT_KEY)wherePRODUCT.PRODUCT_NAME in ('Aloe Relief','Course Pro Umbrella'))and (TIME.MONTH_NAME in ('April 2004','February 2004','February2006'))group byTIME.MONTH_NAME,PRODUCT.PRODUCT_NAME) D3on ((D2.MONTH_NAME = D3.MONTH_NAME) and(D2.PRODUCT_NAME = D3.PRODUCT_NAME))

coalesce 文の機能

coalesce 文は、一致するディメンションからのクエリー・アイテムを扱うための効率的な手段です。この文は、クエリー・サブジェクトから返される最初の Null 以外の値を受け入れるために使用されています。この文を使用すると、完全外部結合を行う場合に、繰り返しを含まないキーの完全なリストを取得できます。

完全外部結合を使用する理由

完全外部結合は、各ファクト表からすべてのデータを取得するために必要です。内部結合では、在庫の品目が販売された場合にのみ結果が生じます。右外部結合では、品目が在庫にある販売すべてが取得されます。左外部結合では、販売された在庫品目すべてが取得されます。完全外部結合は、在庫にあった品目と販売された品目を把握するための唯一の手段です。


1-1 の関係としての 1-n の関係のモデル作成1-n の関係がデータに存在するが、1-1 の関係としてモデルが作成されている場合は、メタデータによって IBM Cognos ソフトウェアに提供されている情報が不十分なため、必然的に SQL トラップが発生します。

1-n の関係が 1-1 としてモデル作成されている場合に発生する一般的な問題は次のとおりです。

v 複数細分性のクエリーで発生する二重カウントが自動的に防止されない。

IBM Cognos ソフトウェアでは、ファクトを検出し、スティッチ・クエリーを生成することで二重カウントを補正することはできません。二重カウントは、一致するディメンション間で、階層関係や、異なるレベルの細分性を操作した場合に発生します。

v 複数ファクト・クエリーが自動的に検出されない。

IBM Cognos ソフトウェアでは、複数ファクトのクエリーを検出するのに十分な情報を保持しないことがあります。複数ファクトのクエリーでは、内部結合が実行され、最後に評価された結合をドロップすることでループ結合が取り除かれます。結合がドロップされることにより、クエリーに含まれているディメンションおよびファクトによっては、誤った結果または予期できない結果が発生する場合があります。

クエリー・サブジェクト間またはディメンション間で 1-1 の関係のみを使用するようにカーディナリティーを変更した場合は、Time または Time と Product を使用した Product Forecast および Sales に対するクエリーによって、1 つの Select文が生成されます。その結果、循環参照を避けるために 1 つの結合がドロップされます。

次の例では、個別のクエリー結果を「Sales」または「Product Forecast」と比較した場合に、このクエリー結果が誤っていることを示しています。

個別のクエリー結果は次のとおりです。


これらのクエリーを 1 つのクエリーに結合すると、結果は次のようになります。

SQL

循環結合パスがモデル内で検出されたため、結合パスの完結に不要な関係の 1 つが、生成された SQL に含まれていません。この例では、「Time」と「ProductForecast」の間の関係がドロップされています。

有用な結果をもたらすクエリーが循環結合パスから作成されることはほとんどありません。

selectTIME_.MONTH_NAME as MONTH_NAME,PRODUCT_LOOKUP.PRODUCT_NAME as PRODUCT_NAME,XSUM(SALES_FACT.QUANTITY forTIME_.CURRENT_YEAR, TIME_.QUARTER_KEY, TIME_.MONTH_KEY,PRODUCT.PRODUCT_LINE_CODE, PRODUCT.PRODUCT_TYPE_CODE,PRODUCT.PRODUCT_KEY ) as QUANTITY,XSUM(PRODUCT_FORECAST_FACT.EXPECTED_VOLUME for TIME_.CURRENT_YEAR,TIME_.QUARTER_KEY, TIME_.MONTH_KEY, PRODUCT.PRODUCT_LINE_CODE,PRODUCT.PRODUCT_TYPE_CODE, PRODUCT.PRODUCT_KEY ) as EXPECTED_VOLUMEfrom(select TIME.DAY_KEY,TIME.MONTH_KEY, TIME.QUARTER_KEY,TIME.CURRENT_YEAR,TIME.MONTH_EN as MONTH_NAMEfrom TIME_DIMENSION TIME) TIMEjoinSALES_FACT on (TIME_.DAY_KEY = SALES_FACT.ORDER_DAY_KEY)joinPRODUCT_FORECAST_FACT on (TIME_.MONTH_KEY =PRODUCT_FORECAST_FACT.MONTH_KEY)joinPRODUCT (PRODUCT.PRODUCT_KEY = PRODUCT_FORECAST_FACT.PRODUCT_KEY)where(PRODUCT.PRODUCT_NAME in ('Aloe Relief','Course Pro Umbrella'))and(TIME_.MONTH_NAME in ('April 2004','February 2004','February 2006'))group byTIME_.MONTH_NAME, PRODUCT.PRODUCT_NAME


一致しないディメンションに対する複数ファクト、複数細分性のクエリー

一致しないディメンションがクエリーに追加された場合、スティッチ・クエリーによって返される結果の性質が変化します。レコードを細分性の最下位共通レベルに集計できなくなります。これは、一方のクエリーに、他方のクエリーには共通していないディメンションが存在するためです。その結果、2 つの相関リストが返されます。

結果

対応するスター・スキーマに対する個別のクエリー結果は次のようになります。


両方のスター・スキーマから同じアイテムをクエリーすると、次の結果が生じます。


この結果、「Sales」のレコードの下位レベルの細分性では、月と製品の組み合わせごとに、多くのレコードを返します。 Product Forecast から返される行と、Salesから返される行の間には、1-n の関係が存在します。

この結果を、一致するディメンションに対する複数ファクト、複数細分性のクエリーの例で返された結果と比較すると、より多くのレコードが返されており、「Expected Volume」の結果が複数の発注方法で繰り返されていることがわかります。発注方法をクエリーに追加すると、Quantity データと Expected Volume データ間の関係が、1-n の関係に変化します。「Expected Volume」の 1 つの値を「Quantity」の 1 つの値に関連付けることは、できなくなります。

「Month」のキーを使用してグループ化することで、この例の結果は、複数ファクト、複数細分性のクエリー結果と同じデータ・セットに基づいていますが、細分性がさらに大きくなっていることがわかります。

SQL

この例に対して生成されたスティッチ SQL は、複数ファクト、複数細分性のクエリーで生成された SQL とよく似ています。主な相違は、「Order Method」が追加されている点です。「Order Method」は一致するディメンションではなく、「Sales Fact」テーブルに対するクエリーのみに影響を及ぼします。

selectD2.QUANTITY as QUANTITY,D3.EXPECTED_VOLUME as EXPECTED_VOLUME,coalesce(D2.PRODUCT_NAME,D3.PRODUCT_NAME) as PRODUCT_NAME,coalesce(D2.MONTH_NAME,D3.MONTH_NAME) as MONTH_NAME,D2.ORDER_METHOD as ORDER_METHODfrom(selectPRODUCT.PRODUCT_NAME as PRODUCT_NAME,TIME.MONTH_NAME as MONTH_NAME,ORDER_METHOD.ORDER_METHOD as ORDER_METHOD,XSUM(SALES_FACT.QUANTITY for TIME.CURRENT_YEAR,TIME.QUARTER_KEY,TIME.MONTH_KEY,PRODUCT.PRODUCT_LINE_CODE,PRODUCT.PRODUCT_TYPE_CODE,


PRODUCT.PRODUCT_KEY,ORDER_METHOD_DIMENSION.ORDER_METHOD_KEY) asQUANTITYfromPRODUCT_DIMENSION PRODUCTjoinSALES_FACT SALES_FACTon (PRODUCT.PRODUCT_KEY = SALES_FACT.PRODUCT_KEY)joinORDER_METHOD_DIMENSION ORDER_METHODon (ORDER_METHOD.ORDER_METHOD_KEY = SALES_FACT.ORDER_METHOD_KEY)join TIME_DIMENSION TIMEon ( TIME.DAY_KEY = SALES_FACT.ORDER_DAY_KEY)where(PRODUCT.PRODUCT_NAME in ('Aloe Relief','Course Pro Umbrella'))and( TIME.MONTH_NAME in ('April 2004','February 2004','February 2006'))group byPRODUCT.PRODUCT_NAME,TIME.MONTH_NAME,ORDER_METHOD.ORDER_METHOD) D2full outer join(selectPRODUCT.PRODUCT_NAME as PRODUCT_NAME,TIME.MONTH_NAME as MONTH_NAME,XSUM(PRODUCT_FORECAST_FACT.EXPECTED_VOLUME for TIME.CURRENT_YEAR,TIME.QUARTER_KEY,TIME.MONTH_KEY,PRODUCT.PRODUCT_LINE_CODE,PRODUCT.PRODUCT_TYPE_CODE,PRODUCT.PRODUCT_KEY) as EXPECTED_VOLUMEfromPRODUCT_DIMENSION PRODUCTjoinPRODUCT_FORECAST_FACT PRODUCT_FORECAST_FACTon (PRODUCT.PRODUCT_KEY = PRODUCT_FORECAST_FACT.PRODUCT_KEY)join(selectTIME.CURRENT_YEAR as CURRENT_YEAR,TIME.QUARTER_KEY as QUARTER_KEY,TIME.MONTH_KEY as MONTH_KEY,XMIN(TIME.MONTH_NAME for TIME.CURRENT_YEAR, TIME.QUARTER_KEY,TIME.MONTH_KEY) as MONTH_NAMEfromTIME_DIMENSION TIMEgroup byTIME.CURRENT_YEAR,TIME.QUARTER_KEY,TIME.MONTH_KEY) TIMEon (TIME.MONTH_KEY = PRODUCT_FORECAST_FACT.MONTH_KEY)where(PRODUCT.PRODUCT_NAME in ('Aloe Relief','Course Pro Umbrella'))and(TIME.MONTH_NAME in ('April 2004','February 2004','February 2006'))group byPRODUCT.PRODUCT_NAME,TIME.MONTH_NAME) D3on ((D2.PRODUCT_NAME = D3.PRODUCT_NAME) and(D2.MONTH_NAME = D3.MONTH_NAME))


あいまいに識別されているディメンションおよびファクトの解決クエリー・サブジェクトは、別のクエリー・サブジェクトに対して n および 1 の関係の双方に存在する場合、定義があいまいであると見なされます。クエリー・サブジェクトの定義があいまいであることは、クエリー生成の観点から見ると、特に問題とはならないこともあります。クエリー・サブジェクトは、次のようなケースを念頭において評価することを推奨します。この評価の目的は、クエリー分割が意図した正しい場合にのみ行われ、無用なクエリー分割が起こらないようにすることです。

階層のレベルを表すクエリー・サブジェクトあいまいに定義されているクエリー・サブジェクトのうち、問題のないケースの 1つは、クエリー・サブジェクトにより説明的な階層の中間レベルが表されている場合です。1 つの例が次の「Product」階層です。

この例では、「Product type」と「Product」の双方があいまいに定義されているとみなすことができますが、このあいまいさは、生成される結果に対しても、またこのようなクエリー・サブジェクトを 1 つ以上使用しているクエリーのパフォーマンスにも、悪影響を及ぼすものではありません。このクエリー・パターンを修正する


必要はありません。ファクト検出規則を使用すると、「Product forecast」クエリー・サブジェクトまたは「Sales」クエリー・サブジェクトのアイテムを組み合わせるクエリーでは、識別されるファクトが 1 つのみとなるためです。この例は、分析用のモデルを作成する際に階層を縮小して単一の標準ディメンションとする場合のベスト・プラクティスであるといえます。

この例を使用して作成できるクエリーには、次のようなものがあります。

クエリーでアイテムを使用できるクエリー・サブジェクト

クエリーでファクトとして機能するクエリー・サブジェクト

Product line と Product type 製品タイプ

Product line、Product type、およびProduct

製品

Product line、Product type、Product、および Sales

売上

Product line と Sales 売上

Product type と Product forecast 製品販売予測

分割が不要であったクエリーの解決分割されているが、実は分割が不要なクエリーが存在する場合は、これらの分割されているクエリーを解決する必要があります。

すべての関係の n 側のクエリー・サブジェクトはファクトとして識別されます。次の例では、「Order Header」と「Country Multilingual」がファクトとして機能しています。実際には、「Country Multilingual」クエリー・サブジェクトは説明情報だけを含み、検索テーブルであると考えられます。ディメンションあるいはビジネス・モデルの観点からは、「Country Multilingual」は「Country」の延長といえます。

このようなモデルをそのままにすると問題がある理由

市および国または地域別の注文数を示すレポートをオーサリングし、このモデルをテストします。このモデルを使用すると、誤った結果が返されます。市の注文数は


正しく表示されますが、一部の市が誤った国または地域に含まれます。これは、誤って関連付けられている結果を示した例です。

このようなケースでは、まず最初に SQL を確認するのが一般的です。

SQL

この例には、スティッチ・クエリーがあります。このクエリーは、モデル内に複数のファクトがある場合には道理にかなっています。スティッチ・クエリーとは、複数のファクトをつなげようとするクエリーです。このクエリーでは、ファクトを互いに関連付ける関係と、モデルに定義されている一致するディメンション、または共通するディメンションの行列式を使用します。スティッチ・クエリーは、完全外部結合を使用した 2 つのクエリーで識別できます。ラッパー・クエリーでは、一致するディメンションに coalesce ステートメントを含める必要があります。

SQL に次の問題があることに注意してください。

v クエリーに coalesce ステートメントがない。

v RSUM によって、有効なキーの作成が試行されたことが示されている。

selectD3.COUNTRY as COUNTRY,D2.CITY as CITY,D2.number_of_orders as number_of_ordersfrom(selectSALES_BRANCH.CITY as CITY,XCOUNT(ORDER_HEADER.ORDER_NUMBER for SALES_BRANCH.CITY) asnumber_of_orders,RSUM(1 at SALES_BRANCH.CITY order by SALES_BRANCH.CITYasc local)as scfromgosales.gosales.dbo.SALES_BRANCH SALES_BRANCHjoingosales.gosales.dbo.ORDER_HEADER ORDER_HEADERon (SALES_BRANCH.SALES_BRANCH_CODE = ORDER_HEADER.SALES_BRANCH_CODE)group bySALES_BRANCH.CITYorder byCITY asc) D2full outer join(selectCOUNTRY_MULTILINGUAL.COUNTRY as COUNTRY,RSUM(1 at COUNTRY_MULTILINGUAL.COUNTRY order byCOUNTRY_MULTILINGUAL.COUNTRY asc local) as scfromgosales.gosales.dbo.COUNTRY_MULTILINGUAL COUNTRY_MULTILINGUALgroup byCOUNTRY_MULTILINGUAL.COUNTRY


order byCOUNTRY asc) D3on (D2.sc = D3.sc)

各クエリー内のスティッチ列を見ると、これらの列が、関連していない基準に従って計算されていることがわかります。この状況は、レポートの国または地域と市に明確な関係が存在しない理由を示しています。

それでは、スティッチ・クエリーがなぜ存在しているのでしょうか。この疑問に答えるには、モデルを見る必要があります。

この例では、レポートに使用されているクエリー・アイテムが、異なるクエリー・サブジェクトから取得されています。Country (地域) は Country Multilingual から、City は Sales Branch から、Number of Orders は Order Header クエリー・サブジェクトの Order Number の数からそれぞれ取得されています。

問題は、クエリーが分割されていることにあります。これは、クエリー・エンジンによりこのクエリーが複数ファクトのクエリーとして認識されているために起きています。ただし、両方のファクトには共通のアイテムがないため、分割にはクエリーをつなげるための有効なキーがありません。

この問題を解決するには複数の方法がありますが、どちらの方法を採用する場合にも、データに対する理解が必要です。

解決策 1

フィルターを Country Multilingual に追加して、関係のカーディナリティーを 1-1に変更します。


Select *from [GOSL].COUNTRY_MULTILINGUALWhereCOUNTRY_MULTILINGUAL."LANGUAGE"='EN'

または、フィルターを関係に追加して、カーディナリティーを 1-1 に変更します。

COUNTRY.COUNTRY_CODE = COUNTRY_MULTILINGUAL.COUNTRY_CODEand COUNTRY_MULTILINGUAL.LANGUAGE = 'EN'

どちらを選択しても、このクエリーに 1 つのファクトを含むモデルが作成されます。

解決策 2

関連するクエリー・サブジェクトを統合し、モデルを簡略化します。モデルを簡略化し、クエリーの生成中にエラーが発生する可能性を最小限に抑えることで、最大の利点が得られます。

どちらの解決策でも、正しいクエリー結果が得られます。

SQL にはスティッチ・クエリーが含まれなくなります。

selectCountry.c7 as COUNTRY,SALES_BRANCH.CITY as CITY,XCOUNT(ORDER_HEADER.ORDER_NUMBER for Country.c7,SALES_BRANCH.CITY)as number_of_ordersfrom(selectCOUNTRY.COUNTRY_CODE as c1,COUNTRY_MULTILINGUAL.COUNTRY as c7from


gosales.gosales.dbo.COUNTRY COUNTRYjoingosales.gosales.dbo.COUNTRY_MULTILINGUAL COUNTRY_MULTILINGUALon (COUNTRY.COUNTRY_CODE = COUNTRY_MULTILINGUAL.COUNTRY_CODE)where COUNTRY_MULTILINGUAL.LANGUAGE='EN') Countryjoingosales.gosales.dbo.SALES_BRANCH SALES_BRANCHon (SALES_BRANCH.COUNTRY_CODE = Country.c1)joingosales.gosales.dbo.ORDER_HEADER ORDER_HEADERon (SALES_BRANCH.SALES_BRANCH_CODE = ORDER_HEADER.SALES_BRANCH_CODE)group byCountry.c7,SALES_BRANCH.CITY


第 12 章モデルのアップグレード

モデルをアップグレードすると、このリリースの新機能を利用できるようになります。

最新バージョンの IBM Cognos ソフトウェアをインストールすると、前バージョンの製品で作成されたモデルのほとんどは自動的にアップグレードされます。ユーザー用に発行したパッケージは Content Manager データベースで自動的にアップグレードされます。パッケージは以前と同じように機能し続け、レポートもすべて実行し続けます。 IBM Cognos Framework Manager でモデルをアップグレードするのは、発行したメタデータを変更する場合のみにしてください。

モデルが正常にアップグレードされない場合、モデルを使用するレポートは実行されません。その場合、Framework Manager でモデルを開き、手動でアップグレードして、再発行してください。

モデルをアップグレードするプロセスは、アップグレードするモデルが IBMCognos ReportNet で作成したものか、旧バージョンの IBM Cognos Analytics で作成したものかによって異なります。

モデルをアップグレードするには、次の操作を実行します。

v アップグレードする前にモデルを検証します。

v モデルを開いてアップグレードします。

v アップグレードされた ReportNet モデルを検証および修復します。

製品資料の最新版 (各国語版のすべての資料を含む) を入手するには、IBMKnowledge Center (http://www.ibm.com/support/knowledgecenter) にアクセスしてください。

アップグレード前のモデルの検証アップグレードの前にモデルに存在していた問題は、アップグレード処理では解決されません。アップグレードを開始する前に、モデルを検証し、既存の環境で問題が報告された場合にはそれをすべて修正します。

IBM Cognos ReportNet から IBM Cognos Analytics にアップグレードする際には、ReportNet モデルのディメンション情報が正しく設定されていることを確認してください。詳細については、 441 ページの『ディメンション情報を行列式またはディメンションに変換する』を参照してください。




モデルのオープンとアップグレード最新バージョンの IBM Cognos ソフトウェアをインストールすると、前バージョンの製品で作成されたモデルのほとんどは自動的にアップグレードされます。

モデルをアップグレードする際には、以下を行う必要があります。

v アップグレードの際に設定されるガバナーの影響を理解しておく。

詳細については、『アップグレードとガバナー』を参照してください。

v 変更されたデータ型を確認する。

詳細については、 439 ページの『アップグレードとデータ型』を参照してください。

v SAP BW メタデータに基づくクエリー・サブジェクトのアップグレードの影響を理解しておく。

詳細については、 440 ページの『アップグレードと、SAP BW メタデータに基づくクエリー・サブジェクト』を参照してください。

詳細については、 446 ページの『セグメント化されたプロジェクトおよびリンクされているプロジェクトのアップグレード』を参照してください。

アップグレードとガバナー以下のガバナーは、アップグレード・プロセスで自動的に設定されます。

v 「実行時の拡張モデル移植性を許可」ガバナー ( 343 ページの『実行時の拡張モデル移植性を許可』) が選択されます。

このガバナーは、ReportNet 1.x モデルのアップグレード時に使用されます。メタデータでデータ型が更新されるまでは IBM Cognos Analytics モデルがReportNet 1.x モデルとして機能できるように、データ型が杓子定規に適用されるのを防止します。モデルが正常にアップグレードされたことを検証後、このガバナーをクリアしてください。

すべてのデータ・ソース・クエリー・サブジェクトのステータス・プロパティーは、「再評価が必要」に設定されます。「再評価が必要」のフラグが立てられたデータ型がモデル内にあればクエリー・エンジンはそれらを無視し、データ・ソースからデータ型情報を取得します。この場合は、レポート実行時のパフォーマンスにわずかに悪影響を与える可能性があります。

v 「ディメンション情報の動的生成を許可」ガバナー ( 344 ページの『ディメンション情報の動的生成を許可』) が選択されます。

このガバナーは、データ・ソース内の関係、キー情報、インデックス情報からディメンション情報の形態を導き出すことにより、ReportNet との一貫性のある動作を確保します。

このガバナーが選択されていて、モデルにクエリー・サブジェクトが含まれているがディメンションが含まれていない場合、IBM Cognos Analytics は二重カウ


ントを回避するクエリーを生成します。これも、ReportNet との互換性をもたらします。モデルの検証時、このガバナーが選択されていると警告が表示されます。

v 「ショートカット処理」ガバナー ( 340 ページの『ショートカット処理』) が「自動」に設定されます。

このガバナーは、IBM Cognos Analytics のショートカット処理を制御します。このガバナーが「自動」に設定されている場合、モデルは ReportNet の場合と同様に機能します。つまり、ターゲットと同じフォルダーにあるショートカットは、別名つまり独立インスタンスとして動作します。ただし、モデル内の他の場所にあるショートカットは、オリジナルへの参照として動作します。新しいモデルを作成すると、このガバナーは常に「明示的」に設定されます。

v 「SAP BW データ・ソースの Null 値を消去」ガバナー ( 344 ページの『SAPBW データ・ソースの Null 値を消去』) が選択されます (SAP BW メタデータの場合のみ)。

このガバナーは、SAP BW メタデータに基づいてモデル内の外部結合の作成を制御します。

クエリーによっては、Null 値がフィルターで除外されないためにサイズが非常に大きくなることがあります。ヌル抑止が行われると、行または列のすべての値が Null (空) である行または列が削除されます。

SAP BW はヌル抑止を行います。これにより、IBM Cognos Studio/Authoringツールに転送されるデータ量が減少し、パフォーマンスが向上します。

アップグレードとデータ型IBM Cognos Analytics は、IBM Cognos ReportNet で使用できないデータ型をサポートしています。これは、アップグレード中にメタデータをインポートするときデータ型がマップされる方法に影響を与えることがあります。

注: データ型のマッピングは、データ・ソース・ベンダーによって異なります。

次の表は、ReportNet でのデータ型と IBM Cognos Analytics でのデータ型との間の主な違いを示しています。

ReportNet IBM Cognos Analytics

char nChar

decimal 数値

varChar nVarChar

varChar timestampTZ

varChar IntervalTZ

データ型はモデルに保管されるので、IBM Cognos Analytics は、クエリー・アイテムのデータ型を判別する必要が生じるたびにデータ・ソースにアクセスしなくても済みます。これにより、パフォーマンスが改善されます。

第 12 章モデルのアップグレード 439

いくつかのクエリー・アイテム (ほとんどは計算) は、アップグレードの後に形が崩れて表示されることがあります。これは以下の状況で生じることがあります。

v 計算の基礎となる項目のデータ型が変更されたので、データ型を計算に自動的に割り当てることができません。

v プロンプトを含む保存された計算は適正にテストされませんでした。

影響を受けた計算をテストして問題を修正する必要があります。

アップグレードと、SAP BW メタデータに基づくクエリー・サブジェクト

SAP BW メタデータに基づくクエリー・サブジェクトは、ディメンションに変換されません。その代わりに、アップグレード処理によって非表示ディメンションと、元のクエリー・サブジェクトと同じ名前およびクエリー・アイテムを持つ新しいモデル・クエリー・サブジェクトとが作成されます。モデル・クエリー・サブジェクトは、既存のレポートとの互換性を保つ、新しく作成された非表示ディメンションを指し示します。

レベルおよび階層を含まないモデル・クエリー・サブジェクトは、数値データ・ディメンションに変換されます。

アップグレードの後に、モデルを検討して、新しく作成された標準ディメンションおよび数値データ・ディメンションが分析要件およびレポート作成要件を満たすことを確認してください。

ReportNet 1.x モデルを IBM Cognos 8.3 モデルにアップグレードした後に、基礎となる SAP BW オブジェクト用として初期インポートの後にキー数値フォルダーに追加された数値データは、同期フェーズの間は追加されません。解決策は、オブジェクトを再インポートすることです。

この問題は、IBM Cognos Analytics の後のバージョンのモデルには影響を与えません。

アップグレードされた IBM Cognos ReportNet モデルの検証と修復このセクションおよびそのサブセクションは、IBM Cognos ReportNet から IBMCognos Analytics にモデルをアップグレードする場合にのみ当てはまります。

メタデータをアップデートした後、モデルの検証を促すプロンプトが IBM CognosFramework Manager によって出されます。ディメンション情報またはアップグレードとデータ型に関するセクションでリストされているデータ型のいずれかが含まれる各オブジェクトに対して警告が表示されます。大きなモデルを検証する際は、確認するネームスペースを一度に 1 つだけにしてください。オブジェクトを個別に確認することもできます。

修復プロセスではまず、選択されているすべてのアイテムが評価されます。この評価によって、新規データ型に関する問題は自動的に解決され、モデルのディメンション情報を修復するよう促すプロンプトが出されます。 1 つ以上のチェック・ボックスをオンにし、アイテムを修復することができます。


アップグレード処理とは別にモデルを検証することには、いくつかの利点があります。これにより以下のことが行えます。

v 既存のモデルを開き、クエリー機能に変更を加えることなくアップグレードおよび発行することができる。

v モデル要件の再評価のための時間を取ることができる。

v 継続して実動モデルを設計し、ディメンション情報なしでそれを発行して、徐々にディメンションおよび行列式に移動することができる。

アップグレード処理の際に、以下を行う必要があります。

v ディメンション情報を持つクエリー・サブジェクトを、行列式を持つクエリー・サブジェクトかディメンションのいずれかに変換する。

v オブジェクトを選択および修復する。

検証を行う前にモデルに対して変更を加える場合、行列式を変更しないでください。これを行うと、ディメンション情報が失われ、モデルを後で検証できなくなる可能性があります。

ディメンション情報を行列式またはディメンションに変換するIBM Cognos ReportNet では、ディメンション情報は固有性とディメンション階層を結合したものです。 IBM Cognos Analytics では、標準ディメンションのディメンション情報は、行列式と階層に分けられます。行列式は固有性と細分性を制御します。この制御は、複数ファクトかつ複数グレーンのクエリーの場合は特に、リレーショナル・データ・ソースに基づいたクエリー・サブジェクトに必要です。階層は、すべてのデータ・ソースの階層、レベル、キー、属性のディメンション概念に対応します。

ディメンション情報が含まれるクエリー・サブジェクトは、アップグレード時に行列式にもディメンションにも変換されません。ディメンション情報によって既に指定されているメタデータはモデルに保持され、クエリー・サブジェクトが修復されるまでクエリー・サブジェクト用に存続します。 IBM Cognos Analytics でディメンション情報を変更することはできませんが、その情報を行列式またはディメンションにアップグレードできます。クエリー・サブジェクトがアップグレードされるまで、IBM Cognos Analytics は ReportNet で既に指定されたディメンション情報を使用します。詳細については、 442 ページの『ディメンション情報マッピング』を参照してください。

アップグレード後にモデルを検証なしで変更する場合は、行列式に変更を加えないでください。ディメンション情報が失われる恐れがあります。ディメンション情報を確認するときは、ディメンション情報がクエリー・サブジェクトにどのように適用されるかと、IBM Cognos Analytics でモデル内のクエリー・サブジェクトをどのように使用するかを理解する必要があります。詳細については、 443 ページの『変換後の確認』を参照してください。

メタデータの処理の詳細については、 381 ページの『第 10 章メタデータ・モデリング・ガイド』を参照してください。


ディメンション情報マッピングIBM Cognos Analytics モデルで、ReportNet モデル・クエリー・サブジェクト内のディメンション情報を、行列式のあるクエリー・サブジェクトまたはディメンションにマップできます。

v 行列式

行列式を使用して、アプリケーションを拡張する際に既存のレポートを保持します。

行列式は細分性を表すもので、クエリー・サブジェクト内のデータのサブセットやグループによって表現されます。それらにより、この反復データが正しく集計されることになります。行列式は、データ・ソースの一意のキーやインデックス情報に基づいてインポートされます。

ディメンション情報とは異なり、モデル・クエリー・サブジェクトは基盤となるクエリー・サブジェクト用に指定された行列式を継承します。モデル内の、通常はデータ・ソース・クエリー・サブジェクト上に、できるだけ早く行列式を指定してください。異なる細分性制御のために異なる行列式を指定するケースでは、データ・ソース・クエリー・サブジェクトの複数のインスタンスを作成するか、またはデータ・ソース・クエリー・サブジェクトから行列式を除去します。その後、異なる細分性制御を必要とするモデル・クエリー・サブジェクトごとに、新しい行列式を作成します。

v ディメンション

モデルを Analysis Studio で使用する、レポートでのドリルアップとドリルダウンを有効にする、または Studio/Authoring ツール内のメンバー関数にアクセスする場合に、ディメンションを使用します。標準ディメンションだけが作成されます。アップグレードの際に、数値データ・ディメンションを作成するためのメタデータが不足するので、それらのディメンションは手動で作成する必要があります。その後、モデルで範囲を設定することにより、ディメンションを数値データに関連付けることができます。

クエリー・サブジェクトをディメンションにアップグレードする場合、モデル内のクエリー・アイテムの名前は変更されます。例えば、以前は namespace.querysubject.query item として修飾されていたクエリー・アイテムは、namespace.dimension.hierarchy.level.query item として修飾されるようになります。この名前変更によって多くの既存レポートが無効になるので、既存のモデルを活用してディメンション機能の必要な新しいアプリケーションを構築するときにのみ、クエリー・サブジェクトをディメンションにアップグレードしてください。

ディメンション情報は、以下のように行列式およびディメンションにマップされます。


ディメンション情報行列式ディメンション

階層リレーショナル・データ・ソースでは、最初の階層が行列式を作成します。

階層

SAP BW データ・ソースでは、代替階層がディメンションの代替階層にアップグレードされます。

レベル「一意に識別」または「グループ化」が指定された行列式

レベル

階層の第 1 レベルは、All レベルとして自動的に定義されます。それには階層のトップレベルを表す単一のルート・メンバーが含まれます。

All レベルを削除または移動することはできません。その名前、説明、および画面のヒントを変更することはできます。

キー一意のキーが選択されていない場合、高位のレベルのキー・セグメントがキーに含められます。

_businessKey 役割

一意のキーが選択された場合、レベルのキー・セグメント (複数も可) だけがキーに含められます。

一意のレベル

アルファベット順で最初のテキスト属性

_memberCaption 役割

属性属性

関連付けられていない属性は、通常は最も低いレベルに対応する、最後の行列式に割り当てられます。

_memberDescription 役割、カスタム役割、または役割なしに、手動で割り当てることができます。

変換後の確認ディメンション情報のあるクエリー・サブジェクトを行列式のあるクエリー・サブジェクトに変換した後に、以下の設定を確認する必要があります。

v 一意に識別

一意の行列式を定義すると、データ内のグループを識別するために十分な情報が各キーに格納されていることが示されます。

v グループ化


一意ではない行列式を定義するときには、「グループ化」を指定してください。このように指定すると、その行列式に関連付けられているキーや属性がデータ内で繰り返されるときに、二重カウントを回避するための集計関数とグループ化がIBM Cognos Analytics で適用されます。

v ReportNet に存在した複数または代替の階層

ReportNet 内のクエリー・サブジェクトに 2 つの階層が存在する場合、最初の階層だけがリレーショナル・データ・ソースの行列式にアップグレードされます。 2 番目のクエリー・サブジェクトを作成して、他の階層の行列式を手動で指定する必要があります。

SAP BW データ・ソースでは、代替階層が行列式にアップグレードされます。

ディメンション情報のあるクエリー・サブジェクトをディメンションに変換した後に、以下の設定を確認する必要があります。

v _businessKey 役割

この役割は、レベルのキーを表すもので、レベル内の 1 つの属性だけに割り当てることができます。

v 一意のレベル

一意のレベルは、このレベルのメンバーを識別するために上位のレベルのキーは必要ないことを示します。

v _memberCaption 役割

IBM Cognos Studio/Authoring ツールでメンバー関数を利用するには、ディメンションの各レベルに _memberCaption 役割を割り当てる必要があります。レベルのための属性がない場合、モデルを検証するときにキャプションの不在が強調表示されます。

すべてのキャプションは、文字列データ型でなければなりません。このタイプの属性で使用可能なものがない場合には、文字列データ型の計算を作成して、新しいアイテムに _memberCaption 役割を割り当てます。これは主に AnalysisStudio の問題です。

v 属性

ディメンションに属性を含めて、それらを正しいレベルに関連付けます。デフォルトで、それらは役割なしで含められます。カスタムの役割を作成することや、既存の役割に属性を割り当てることができます。

v 複数の階層

標準ディメンションに複数の階層を含めることもできますが、クエリー時に使用できる階層は 1 つのみです。例えば、クロス集計レポートの行に 1 つの階層を使用し、クロス集計レポートの列に同じディメンションの別の階層を使用することはできません。同じレポート内で両方の階層が必要な場合は、各階層に 1 つずつ、2 つのディメンションを作成する必要があります。


アップグレードされた IBM Cognos ReportNet モデルのオブジェクトの選択と修復

修復プロセスではまず、選択されているすべてのアイテムが評価されます。この評価によって、新規データ型に関する問題は自動的に解決され、モデルのディメンション情報を修復するよう促すプロンプトが出されます。

アップグレードされたモデルを検証および修復する際、以下の警告が表示される場合があります。

警告説明

再評価が必要多くの場合、このメッセージはデータ型の変更に関連して出されます。

この警告が出されるアイテムのほとんどは、選択して修復することができます。修復オプションを使用して、特定のメタデータを評価およびアップグレードします。

結合式がクエリー・サブジェクトで定義される行列式情報と競合しています (Joinexpression conflicts with the determinantinformation defined in the query subject)

時折、クエリー・サブジェクトに対して指定されるインデックスおよびキーの情報が、クエリー・サブジェクトに対して指定される関係と一致しない細分性のレベルを暗黙に示す場合があります。

このレベルのクエリー・アイテムには、キャプションの役割が指定されているものがありません

レベルを定義する際、ビジネス・キーおよびキャプションの役割が指定されていることを確認してください。その役割は IBM CognosStudio のメンバー関数に必要です。また、Analysis Studio のメンバー指向ツリーでの支援にも必要です。

すべてのキャプションは、文字列データ型でなければなりません。使用可能なこの型の属性が存在しない場合、文字列データ型の計算を作成し、メンバー・キャプションの役割を新規アイテムに割り当てます。これは主にAnalysis Studio の問題です。

クエリー・サブジェクトのキーおよび属性を説明する 1 つ以上の行列式を指定する必要があります (One or more determinantsthat describe the keys and attributes ofthe query subject should be specified)

行列式は、データ・ソースのキーの情報に基づきます。 ReportNet からアップグレードされるクエリー・サブジェクトには行列式が存在しない場合があります (特にモデル・クエリー・サブジェクト)。行列式を使用して、クエリー・サブジェクトのデータの細分度、およびクエリー・アイテム間の関数的従属関係を指定します。ただし、単一のレベルまたはファクト・データを表すクエリー・サブジェクトに対する行列式の指定は必須ではありません。


セグメント化されたプロジェクトおよびリンクされているプロジェクトのアップグレード

この情報は、アップグレード元の製品バージョンに関係なく当てはまります。

セグメント化されたプロジェクトのセグメントは、マスター・プロジェクトを開く際に自動的にアップグレードされます。

リンクされているプロジェクトをあるプロジェクトが使用している場合、リンクされているプロジェクトをアップグレードしてからプロジェクトをアップグレードする必要があります。

セグメント化されたモデルまたはリンクされているモデルが前バージョンの IBMCognos Framework Manager で作成された場合、アップグレードを行う前と後に、それぞれの子モデルおよび親モデルのガバナー設定を確認する必要があります。最上位の親モデルのガバナー設定が発行時に適用されます。

前バージョンの Framework Manager で作成されたスクリプトを実行する場合、スクリプトはアップグレード処理を迂回します。スクリプトを実行する前と後に、ガバナー設定が正確であることを確認してください。

セグメント化されたプロジェクトが自動的にアップグレードされない場合、以下の手順を実行します。

手順1. 各セグメントを個別のプロジェクトとして開きます。その際、階層内でレベルの

最も低いセグメントから開始します。

2. 手順に従ってモデルをアップグレードします。

詳細については、 437 ページの『第 12 章モデルのアップグレード』を参照してください。

セグメントの修復は行わないでください。

3. アップグレードが完了した後、プロジェクトを保存します。

4. 階層内の各セグメントをアップグレードし、メイン・プロジェクトの作業に戻ります。

5. マスター・プロジェクトの完全モデルを修復します。

6. マスター・プロジェクトをアップグレードした後、各セグメントをチェックインし、マスター・プロジェクトをチェックインします。


付録 A. パターンを使用したデータの表示形式の設定

デフォルトの表示形式が適切でない場合は、テキストや数字のパターンを使用してデータの表示形式を設定できます。例えば日付の場合、テキスト形式を使用して紀元記号を含む完全な書式で表示することも、スペースを節約するために、数字のみを使用して西暦年の最後の 2 桁のみを表示する短い書式で表示することもできます。

記号やパターンでは、基本的なデータの書式設定と同様の結果を得られます。例えば、小数点の後に表示する小数点以下の桁数を設定できます。この設定を行うには、パターンを使用する方法と、「小数点以下の桁数」プロパティーを使用する方法があります。パターンでは、複雑な要求にも柔軟に対応できます。

サポートされているコンテンツ言語それぞれにつき、パターンで使用する特定の記号セットが必要です。各言語コードに対し、必要な表が 2 つあります。1 つは日時の記号の表、もう 1 つは小数点の記号の表です。小数点の記号は全ロケール共ですが、日時の記号は 6 つのロケール・グループに分かれています。「日時の記号」で、どのロケール・グループに該当するかを確認してください。

パターンを定義するには、「データ形式」ダイアログ・ボックスを開き、各形式のタイプについて「パターン」プロパティーを編集します。言語テーブルの表に定義されている記号を使用し、次のガイドラインに従います。

パターンのガイドラインパターンを定義する際には、使用する記号の数によって、データの表示方法が変わります。テキスト、数字、およびテキストと数字の両方を使用する値では、それぞれ規則が異なります。

テキスト

テキストの場合は、完全な形式で表示するか、省略して表示するかを指定できます。

記号の数意味例

4 以上完全なテキストの形式「EEEE」で「Monday」と表示

4 未満省略形「EEE」で「Mon」と表示

数字

パターンに使用した記号の数で、レポートに表示される桁の最小数が設定されます。指定した桁数よりも小さい数値には、ゼロが追加して表示されます。例えば、分数に「mm」と指定し、データベースでの値が「6」の場合は、レポートには「06」と表示されます。


注: 年の値は、これとは異なる方法で扱われます。年に 2 つの記号を指定すると、年の最後の 2 桁が表示されます。例えば、「yyyy」では「2013」が、「yy」では「13」が表示されます。

テキストと数字

テキストか数字のいずれかを表示できる値 (月など) では、テキストと数字のどちらを表示するか、また、テキストの場合は省略形を使用するかどうかを指定できます。

記号の数意味例

3 以上テキスト「MMMM」で「January」を表示

「MMM」で「Jan」を表示

3 未満数字「MM」では「01」を表示

「M」では「1」を表示

日時の記号日時の記号は、ロケールに分割されています。以下のセクションに、各ロケールの詳細を示します。

ロケール・グループ A

ロケール:af-za, en, en-au, en-be, en-bw, en-ca, en-gb, en-hk, en-ie, en-in, en-mt,en-nz, en-ph, en-sg, en-us, en-vi, en-za, fo-fo, gl-es, id, id-id, is, is-is, it, it-ch,it-it, kk-kz, ms, ms-bn, ms-my, nb-no, nl, nl-be, nl-nl, no, no-no, om-et, om-so,pl, pl-pl, pt, pt-br, pt-pt, so-dj, so-et, so-ke, so-so, sv, sv-fi, sv-se , sw-ke, sw-tz

意味記号表示形式例

紀元記号 G テキスト AD

年 y 数値 2013

(「元旦からの週数」の) 年

Y 数値 2013

月 M テキストと数字「7 月」と「07」

元旦からの週数 w 数値 27

月初めからの週数 W 数値 2

元旦からの日数 D 数値 189

日 d 数値 10



月初めからの曜日の数

F 数値 2 (7 月の第 2 水曜日)

曜日 (1 = 1 日目) e 数値 2

曜日 E テキスト火曜日

午前または午後を示すマーカー

a テキスト午後

24 時間制による時刻(1～24)

k 数値 24


K 数値 0


h 数値 12


H 数値 0

分 m 数値 30

秒 s 数値 55

ミリ秒 S 数値 978

タイム・ゾーン z テキスト太平洋標準時

テキストで使用されるエスケープ

' 該当なし該当なし

一重引用符 '' 該当なし '

ロケール・グループ B

ロケール:be-by, bg-bg, el, el-gr, fi, fi-fi, hr, hr-hr, hu, hu-hu, ja, ja-jp, ko, ko-kr,ro, ro-ro, ru, ru-ua, ru-ru, sh-yu, sk, sk-sk, sl-si, sq-al, sr-sp, th, tr, tr-tr, uk-ua,zh, zh-cn, zh-hk, zh-mo, zh-sg, zh-tw



年 a 数値 2013


A 数値 2013

付録 A. パターンを使用したデータの表示形式の設定 449


月 n テキストと数字「7 月」と「07」




日 j 数値 10



曜日 (1 = 1 日目) e 数値 2



X テキスト午後


h 数値 24


K 数値 0


k 数値 12


H 数値 0

分 m 数値 30

秒 s 数値 55






ロケール・グループ C

ロケール:ca-es, cs, cs-cz, da, da-dk, es, es-ar, es-bo, es-cl, es-co, es-cr, es-do,es-ec, es-es, es-gt, es-hn, es-mx, es-ni, es-pa, es-pe, es-pr, es-py, es-sv, es-us,es-uy, es-ve, eu-es, mk-mk




年 u 数値 2013


U 数値 2013





日 t 数値 10



曜日 (1 = 1 日目) e 数値 2





h 数値 24


K 数値 0


k 数値 12


H 数値 0

分 m 数値 30

秒 s 数値 55








ロケール・グループ D

ロケール:de, de-at, de-be, de-ch, de-de, de-lu



年 j 数値 2013


J 数値 2013





日 t 数値 10



曜日 (1 = 1 日目) e 数値 2





h 数値 24


K 数値 0


k 数値 12


H 数値 0

分 m 数値 30



秒 s 数値 55






ロケール・グループ E

ロケール:fr, fr-be, fr-ca, fr-ch, fr-fr, fr-lu



年 a 数値 2013


A 数値 2013





日 j 数値 10



曜日 (1 = 1 日目) e 数値 2



X テキスト午後


h 数値 24


K 数値 0




k 数値 12


H 数値 0

分 m 数値 30

秒 s 数値 55






ロケール・グループ F

ロケール:ga-ie


紀元記号 R テキスト AD

年 b 数値 2013


B 数値 2013


元旦からの週数 t 数値 27

月初めからの週数 T 数値 2

元旦からの日数 l 数値 189

日 L 数値 10



曜日 (1 = 1 日目) e 数値 2







u 数値 24


K 数値 0


k 数値 12


U 数値 0

分 n 数値 30

秒 s 数値 55


タイム・ゾーン c テキスト太平洋標準時




小数点の形式の記号全ロケール共通

記号意味

0 ゼロの場合でも表示される桁。

# ゼロの場合は表示されない桁。

. 小数点記号のプレースホルダー。

, 桁区切り記号のプレースホルダー。

E 形式が指数の場合の、仮数と指数の区切り。

; 正の数と負の数の形式の区切り。

- 負の数のデフォルトのプレフィックス。

% 100 で乗算して、パーセントとして表示。

1000 で乗算して、千分率として表示。

通貨記号。この記号をパターンに使用すると、標準の小数点記号の代わりに、通貨の小数点記号が使用されます。


記号意味

国際通貨の符号。国際通貨記号に置換されます。この記号をパターンに使用すると、標準の小数点記号の代わりに、通貨の小数点記号が使用されます。

X プレフィックスやサフィックスに使用できる、その他の文字。

' プレフィックスやサフィックスで特殊文字を囲む引用符。

/u221E 無限大記号。

/uFFFD 数字ではない。


付録 B. ユーザー補助機能

ユーザー補助機能は、動作が制限されている方、視力の限られた方など、身体に障害を持つ方々に IT 製品をご使用いただけるように支援する機能です。

Framework Manager のユーザー補助機能主なユーザー補助機能として、アクセラレーターおよびコマンド・キーを使ってFramework Manager をナビゲートすることができます。

v 画面上の下線の付いた文字は、アクセラレーターを指定します。例えば、「ファイル」メニューのアクセラレーターは F です。 Microsoft Windows では、Altキーを押しながらアクセラレーター・キーを押すと操作が起動されます。例えば、Alt キーを押しながら F を押すと「ファイル」メニューが表示されます。また、拡張アクセラレーターが有効になっている場合は、それを使用することもできます。

v コマンド・キーはアクションを直接トリガーします。通常は Ctrl キーを使用します。例えば、印刷するには Ctrl + P を押します。

Framework Manager のキーボード・ショートカットキーボード・ショートカットで Framework Manager 内をナビゲートし、いくつかのタスクを実行できます。

この製品では、アプリケーション固有のキーに加えて、Microsoft Windows オペレーティング・システムの標準ナビゲーション・キーが使用されています。

次のキーボード・ショートカットは、米国の標準キーボードに基づいています。

説明ショートカット

コンテキスト・ヘルプ F1

新規ファイル Ctrl + N

ファイルを開く Ctrl + O

ファイルの保存 Ctrl + S

取り消し Ctrl + Z

再実行 Ctrl + Y

切り取り Ctrl+X

コピー Ctrl+C

貼り付け Ctrl+V

削除 Del

Model Design Accelerator のキーボード・ショートカットキーボード・ショートカットで Model Design Accelerator 内をナビゲートし、いくつかのタスクを実行できます。


説明ダイアグラム・ショートカット

ツリーとして自動レイアウト Ctrl + A

スターとして自動レイアウト Ctrl + S

拡大 Ctrl + +

縮小 Ctrl + -

ダイアグラムをウィンドウに合わせる Ctrl + 0 (ゼロ)

ズーム率 100% Ctrl + 1


再実行 Ctrl + Y

直接関連した表を追加する Ctrl + D

多対 1 の関係でリンクされたすべての表を再帰的に追加する

Ctrl + T

1 対多の関係を持つ表を追加する Ctrl + O

多対 1 の関係を持つ表を追加する Ctrl + M

選択した表を削除する Del

選択した表を除くすべての表を除去する Shift + Del

説明 Model Accelerator ショートカット

名前を変更 F2

削除 Del

拡大 Ctrl + +

縮小 Ctrl + -

ダイアグラムをウィンドウに合わせる Ctrl + 0 (ゼロ)

ズーム率 100% Ctrl + 1


再実行 Ctrl + Y

IBM とユーザー補助機能ユーザー補助機能に対する IBM の取り組みの詳細については、IBM アクセシビリティー・センター (http://ibm.com/able) を参照してください。


付録 C. トラブルシューティング

Framework Manager で作業する際に問題が発生する場合があります。

他のトラブルシューティング・トピックについては、「IBM Cognos Analytics トラブルシューティング・ガイド」を参照してください。

Framework Manager で新規プロジェクトを開始する際の認証の問題Framework Manager で新規プロジェクトを開始する際に、IBM Cognos Analyticsにログオンできない場合があります。

Cognos Analytics を Windows Server 2012 で実行中に問題が発生します。

この問題を回避するには、Microsoft Internet Explorer の信頼できるサイトのリストに Cognos Analytics ドメインを追加します。

以前のバージョンの Cognos Framework Manager からアップグレードした後に新しいプロジェクトを作成しようとすると BMT-MD-003 エラーになる

バージョン 11.0.3 以前の IBM Cognos Framework Manager からアップグレードする場合は、IBM Cognos Configuration の「外部アプリケーション用ディスパッチャー URI」の値を変更する必要があります。

「外部アプリケーション用ディスパッチャー URI」の形式が、http://<server>:<port>/p2pd/servlet/dispatch から http://<server>:<port>/bi/v1/disp に変更されました。

Oracle で 2 つの CLOB を比較できないOracle を使用しているとき、IBM Cognos Analytics で、「C2 は C3 と等しい」(C2 = C3) という条件指定がある場合などに 2 つの CLOB を比較すると、Oracle実行時エラーが発生します。

この問題を回避するには、DBMS_LOB.compare メソッドを使用します。

where 0 = dmbs_lob.compare (c1, c2)

ERWin からインポートしたメタデータのメモリー不足エラー表示テーブルに基づいてクエリー・サブジェクトをテストすると、sqlPrepareWithOptions 処理の実行中にメモリー不足エラーが発生する場合があります。

この問題を解決するには、ERWin モデルと同じ Content Manager 接続を使用してデータ・ソース・クエリー・サブジェクトを作成します。


Framework Manager からゲートウェイ URI にアクセスできないFramework Manager で新しいプロジェクトを作成する際に、Framework Managerから Gateway URI にアクセスできません。

以下のメッセージが表示されます。

次の URL のサービスにアクセスできません:

http://hostname:80/ibmcognos/bi/v1/disp/

b_acton=xts.run&m=portal/close.xts

ゲートウェイの URI 情報が正しく設定され、サービスが使用可能であることを確認してください。

詳しくは、ご利用のサービスの管理者にお問い合わせください。

このメッセージは、ゲートウェイが正しく設定されていない場合に表示されます。ゲートウェイ URI は、IBM Cognos Analytics がインストールされているコンピューターの名前に設定し、使用しているゲートウェイのタイプを反映する必要があります。ゲートウェイ URI を設定するには、管理者としてログオンする必要があります。

手順1. Framework Manager を閉じます。

2. IBM Cognos Configuration の「エクスプローラー」ウィンドウで、「環境」をクリックします。

3. 「プロパティー」ウィンドウの「ゲートウェイ URI」ボックスに適切な値を入力します。

v ISAPI を使用する場合、cognos.cgi を cognosisapi.dll に置き換えます。

v apache_mod を使用するには、cognos.cgi を mod_cognos.dll に置き換えます。

v サーブレット・ゲートウェイを使用するには、次のように入力します。

http[s]://host:port/context_name/servlet/Gateway

注: <コンテキスト名>は、ServletGateway WAR ファイルを配布したときにServletGateway Web アプリケーションに割り当てた名前です。

v Web サーバーを使用しない場合、ディスパッチャーをゲートウェイとして使用するには、次のように入力します。

http[s]://host:port/p2pd/servlet/dispatch

4. 必要に応じて、「ゲートウェイ URI」のホスト名の部分を、localhost からコンピューターの IP アドレスまたはコンピューター名に変更します。

5. 「ファイル」メニューの「保存」をクリックします。

6. 「操作」メニューの「再開」をクリックします。


オブジェクト名が誤った言語で表示される複数の言語を SAP BW クエリーから Framework Manager モデルにインポートすると、SAP BW から取得したオブジェクト名の一部が正しくない言語で表示されます。

この問題を避けるには、Business Explorer Query Designer で SAP BW クエリーを各ログオン言語で再保存します。これにより、Framework Manager で言語テキストが正しく表示されるようになります。

Teradata からインポートしたモデルのクエリー・サブジェクトをテストしたときのエラー

Teradata からインポートしたモデルを使用している場合に、画像アイテムが含まれている一部のクエリー・サブジェクトをテストすると、次のエラーが表示されます。

QE-DEF-0177 "sqlOpenResult" 処理中にエラーが発生しました。ステータス='-28'。

UDA-SQL-0114 "sqlOpenResult" 処理に供給されたカーソルはアクティブではありません。

UDA-SQL-0107 "SgiCursor::doOpenResult()" 処理中に一般例外が発生しました。

[NCR][ODBC Teradata Driver][Teradata RDBMS] 不明な文字列の翻訳が要求されました。

理由は、GRAPHIC および VARGRAPHIC データ型がサポートされていないためです。

Oracle での完全外部結合で返される結果が正しくないバージョン 10.2 より前の Oracle データ・ソースを使用している場合、完全外部結合を行うと正しくないデータ結果が返されます。この問題を回避するため、IBMCognos Analytics では完全外部結合をローカル操作として処理します。

このため、明示的または暗黙的に外部結合を行うプロジェクトでは、クエリー処理を limitedLocal に設定する必要があります。

入力 SQL クエリー・サブジェクトのエラーDB2 で次のように定義したとします。

create type address as (number character (6),street varchar(35),city varchar(35))MODE DB2SQL;create table emp ( emp_no int, emp_address address);Select e.emp_no, e.emp_address..street from emp eSQL0206N "aBmtQuerySubject.2

付録 C. トラブルシューティング 461

入力 SQL クエリー・サブジェクトを定義すると、構造化タイプの属性参照用に割り当てられた名前のために、エラーが発生します。

この問題を解決するには、次の 2 つのオプションがあります。

v 元のクエリー・サブジェクトで単純な相関名を列に割り当てる。例えば Selecte.emp_no, e.emp_address..street as "ABC" from emp e

v 二重の中括弧 ({{ }}) で列を囲むことにより、クエリー・サブジェクトにパススルー表記を使用する

QE-DEF-0259 エラーこのエラーは、式の中の間違った位置で中括弧 { } を使用すると発生します。 IBMCognos Analytics では、中括弧 { } の中身はすべて関数と同じレベルでなければなりません。式内のその他の場所に中括弧を使用すると、次のエラー・メッセージが表示されます。

QE-DEF-0259 解析エラーが発生しました

中括弧は、固有の構文をデータ・ソースに送るために使用することもできます。例えば、データベースで関数のキーワードが使用され、このキーワードが IBMCognos Analytics では使用されない場合です。

IBM Cognos Analytics は、中括弧の中に入力される構文を検証しません。この構文はそのままデータ・ソースに送られます。

解決策は、中括弧が間違った位置に使用されていないことを確認することです。

例えば、式内に次のように入力した場合を考えてみます。

[ss_ole_both].[authors_lith].[au_id] = [ss_ole_both].[authors_latin].[au_id]{ collate Lithuanian_CI_AI}

この場合、次のエラー・メッセージが表示されます。

QE-DEF-0259 75 以前、またはその付近で解析エラーが発生しました。テキストの開始位置: 5 "le_both].[authors_lith].[au_id]=[ss_ole_both].[authors_latin].[au_id]{"

一方、次の式は有効です。

{ Q3.au_id } = { Q4.au_id collate lithuanian_CI_AI}

外部化されたキー数値ディメンションに古いプロンプト値が維持されるオプションのプロンプトを含む、キー数値ディメンション (SAP BW) があります。このディメンションをコンマ区切りファイル、またはタブ区切りファイルとして外部化すると、外部化したファイルには、すべてのデータ行が含まれません。これは、プロンプト値が維持されているためです。

例えば、Framework Manager でディメンションをテストする際に、ディメンションにプロンプト値を設定したとします。このプロンプト値はキャッシュに維持されます。「プロンプト」ダイアログ・ボックスでプロンプトの値をクリアしても、キ


ー数値ディメンションを外部化すると、結果として生成されるファイルには、前回使用したプロンプトでフィルターを掛けたデータが含まれます。

この問題を回避するには、次のいずれかを実行します。

v 外部化を行う前に、キー数値ディメンションをテストしない。

v モデルをいったん閉じてから再度開き、キー数値ディメンションを外部化する。

古いモデルでレベルのオブジェクト・セキュリティーが表示される以前に作成した IBM Cognos のモデルを使用する場合、レベルにオブジェクト・セキュリティーが定義されていることがあります。レベルのオブジェクト・セキュリティーはサポートされていません。

この問題を解決するには、古いモデルを発行する前に、モデルを検証および修復します。

手順1. 「プロジェクト」メニューの「モデル検証」をクリックします。

2. レベルを参照するセキュリティー表示を選択して、「修復」をクリックします。

CWM ファイルへの Framework Manager モデルのエクスポートがエラー「MILOG.TXT が見つかりませんでした」で失敗する

パスに日本語文字が含まれている場合、CWM ファイルへの Framework モデルのエクスポートがエラー「MILOG.TXT が見つかりませんでした」で失敗します。

この問題を解決するには、次のいずれかを実行します。

v 日本語文字が使用されていないエクスポート・パスを指定する。

v 使用するコンピューターのシステム・デフォルト言語を日本語に変更する。コントロール・パネルの「地域と言語のオプション」->「詳細設定」で、システム・デフォルト言語を設定できます。これを行う方法について詳しくは、MicrosoftWindows オペレーティング・システムのヘルプを参照してください。

アップグレード後の内部結合用 SQL の違いIBM Cognos 8.3 より前のバージョンの製品から移行した場合、INNER JOIN 構文に使用される SQL の生成に違いがあることがあります。

「SQL 結合構文」ガバナーの設定を構成することにより、内部結合に使用されるSQL 構文を制御できます。IBM Cognos Analytics のどのバージョンで生成されるSQL 結合構文でも、結果は同じになります。

暗黙的構文または明示的構文のどちらかを使用して実装できる RDBMS マテリアライズ・テクノロジーを使用する場合は、モデルの「SQL 結合構文」ガバナーに同じ構文設定を選択しておく必要があります。


完全外部結合が Oracle 9i および 10GR1 に送信されないOracle のバグ #2874433 が原因で、デフォルトでは、IBM Cognos Analytics によって完全外部結合が ORACLE 9i および 10GR1 に送信されません。そのため、IBM Cognos Analytics で「ローカルのみ」の処理を使用する必要があります。

Oracle で完全外部結合を有効にするには、次の操作を行う必要があります。

v バグ #2874433 の修正プログラムが含まれた、必要なパッチのセットを適用していることを確認する

v cogdmor.ini ファイルを変更して、完全外部結合を有効にする(Full_outer_join=T)

ini の設定を手動で編集してもその内容は次回のインストール時に上書きされるため、IBM Cognos Analytics または Framework Manager をインストールしたすべてのコンピューターで、手動で設定を複製する必要があります。

数値の計算で説明不能な不一致が発生する丸め誤差により、数値の計算で説明不能な不一致が発生することがあります。


v 回帰テストを実行したところ、数値に差が出た。これらの数値の差は単に、小数部の丸めにより発生したものです。

v レポートにゼロを表示しないよう指定した場合でも、レポート内にはゼロに丸められる小数部 (例えば、0.00000000000000426) があるため、ゼロが表示される。

丸めの問題は、IBM Cognos ソフトウェアに特有のものではなく、丸めが行われるすべての環境で発生する可能性があります。

2 進数の丸め誤差

2 進数の丸め誤差によって計算に不一致が発生することがあります。例えば、数値1.1 が 2 進数の浮動小数点数として表されていて、レポート形式に小数点以下の桁が多数含まれる場合、数値 1.1 が実際には 1.09999999999997 のようになることがあります。

レポート形式が小数点以下 1 桁のみを使用するよう設定されている場合、小数部の丸めが行われて、2 進数の丸めが補正されます。したがって、この数値が実際に1.09999999999997 のときにも 1.1 のように表示されます。この数値が計算で使用されると、丸め誤差が発生する可能性があります。例えば、Microsoft Excel の計算では (小数部の丸めは行わずに)2 進数が使用されますが、レポートの形式設定によって丸められた小数部が表示され、小さな不一致が発生することがあります。

除算の丸め誤差

数値の表現方法にかかわらず、除算を含む計算では通常、丸め誤差が発生します。このような計算の例として、「平均」や「基底値に対するパーセント」があります。


丸めの影響を最小限にするための設計に関するガイドライン

最も望ましい解決法は基礎となるデータベース・スキーマまたはキューブ・モデルを変更することですが、常にこの方法を採択できるとは限りません。これ以外の解決法としては、丸めの影響を最小限にするために、レポートを作成する際や IBMCognos FrameWork Manager でモデルを作成する際、および外部 OLAP キューブを作成する際に、次のガイドラインに従います。

v データを浮動小数点形式で保存することはできる限り避ける。これは特に、通貨値に当てはまります。通貨値は、固定小数点数または 2 などのスケール値を持つ整数のいずれかとして保存する必要があります。

例えば、キューブでは、2012 年の「キャンプ用品」の収益は「20,471,328.88」ドルです。収益の詳細が浮動小数点数として保存された場合、収益の計算時に丸め誤差が発生する可能性があります。

計算の順序によっては、丸め誤差が少し異なることがあります。"製品"の収益が最初に計算され、"時間"の収益が 2 番目に計算された場合、"時間"が最初に計算され"製品"が 2 番目に計算された場合とは異なる丸め誤差が発生することがあります。

総収入は前の例の数字として計算されるか、または小さな不一致が発生する可能性があります (例えば、20,471,328.88 に対して 20,471,328.8800001)。内部の数値は、表示される数値とは少し異なる場合があります。OLAP エンジンでの計算の順序によっては、同じレポートでも実行ごとに異なる数字になる場合もあります。

v レポートでは、できる限り除算を行わない。除算をどうしても行わなければならない場合は、計算プロセス中でなるべく後のほうに行ってください。例えば、Total([収益]/1000) ではなく、Total([収益])/1000 を使用します。

v 比較を行う際には、丸めが発生してもいいように余裕を持たせます。例えば、[利益率] を小数値とし、小数点なしのパーセンテージとして書式設定するとします。[利益率]<>0 (または [利益率] NOT BETWEEN 0 and 0) でフィルターをかけるとゼロ値は除外されますが、書式設定で 0% となったように見える値が引き続き返されます。

この問題を回避するには、次のいずれかの方法でフィルターをかけます。

– [利益率] NOT BETWEEN -0.005 and 0.005

– ([利益率] <- 0.005) OR ([利益率]> 0.005)

0.005 は 0.5% と同等で、浮動小数点の精度の喪失に応じて 0% または 1% として表示されます。

場合によっては、明示的に値を丸めて丸め誤差を制御することもできます。例えば、[利益率] の代わりに round([利益率],2) を使用します。

v 丸められた小数部を含む可能性のある計算を再利用するのではなく、毎回数値を再計算する。

Microsoft Analysis Services 2005/2008 については、 (Lifecycle Manager などで)実行ごとにレポート結果を比較する際には特に、追加の考慮事項がある場合があります。詳細については、Microsoft のドキュメントを参照してください。


値を検索すると予期しない結果が返される場合がある式エディターで、データ・アイテムの値を検索した際に、データ・アイテムが文字列データ型以外であると、予期しない結果が表示される場合があります。データ・アイテムの式は編集できるため、IBM Cognos Analytics の側でデータ型の種類を確実に特定することはできません。

そのため、IBM Cognos Analytics では、設定された集計および自動集計を確認することで、データ・アイテムのデータ型を推測します。


付録 D. Transformer で使用する SAP BW データの作業ガイドライン

Transformer バージョン 8.4 以降では、Content Manager に対して発行されたFramework Manager パッケージを使用して、SAP BW のデータを利用できます。Transformer モデルを作成するためのデータ・ソースとして、SAP ベースのパッケージを使用できます。その結果、Transformer PowerCube を、小規模つまり特定の領域のビジネス情報を配布するための高速なデータ・アクセス・キャッシュ方式として利用することができます。 SAP BW のデータを利用する場合には、この方法を推奨します。

Framework Manager で作成された SAP ベースのパッケージを使用するときには、特別な考慮事項があります。SAP クエリーの作成、Framework Manager による SAP ベースのパッケージの作成および Transformer でのパッケージの使用方法の詳細については、Framework Manager でのパッケージを使用した SAP BW データの処理に関するセクションを参照してください。 Framework Manager でのパッケージの作成の概要については、「IBM Cognos Framework Manager ユーザー・ガイド」の『パッケージの作成または変更』を参照してください。

Transformer バージョン 7.x、8.1、8.2、8.3

Transformer バージョン 7.x、8.1、8.2 では、クエリー・サブジェクトとディメンションが CSV ファイルで外部化された Framework Manager パッケージを使用して、SAP BW データを利用できます。 Transformer では、モデルを作成してPowerCube を生成するためのデータ・ソースとして CSV ファイルを使用できます。この方法は、IBM Cognos Analytics 用の PowerCube を作成するために IBMCognos Analytics でデータを利用するときに、IBM Cognos 環境でのみ使用します。

Transformer バージョン 8.3 では、発行されたパッケージをディメンションに使用し、CSV ファイルをファクトに使用します。

外部化された CSV ファイルを SAP データとともに Framework Manager で使用するときには、特別な考慮事項があります。詳細については、 476 ページの『Framework Manager における外部化された CSV ファイルを使用した SAP BWデータの処理』を参照してください。クエリー・サブジェクトとディメンションをCSV 方式で外部化する方法についての一般的な情報は、「Framework Manager UserGuide」の「Externalizing Query Subjects and Dimensions」を参照してください。


Framework Manager におけるパッケージを使用した SAP BW データの処理

Framework Manager で作成されて Content Manager へ発行された SAP ベースのパッケージを使用することによって、Transformer で SAP BW データを利用できます。SAP BW データを利用する場合には、この方法を推奨します。FrameworkManager で作成された SAP ベースのパッケージを使用するときには、特別な考慮事項があります。

Transformer を使用して、SAP BW クエリー・ソースからディメンション・データとファクト・データの両方をインポートできます。以下の手順は、SAP BW キューブを IBM Cognos Transformer キューブとして再構築する方法を示しています。再構築を行うには、SAP BW クエリー・パッケージが特別な形式になっている必要があります。

IBM Cognos Analytics を使用してディメンションとファクトの両方へアクセスする SAP BW クエリーをインポートするには、以下の 3 つの段階があります。

v SAP BW Business Explorer Query Designer でのクエリーの作成

v Framework Manager でのパッケージの作成

v Transformer でのモデルの作成

制限v この抽出処理を適用できるのは、SAP BW データ・ソースのみです。

v データ・ソースは、SAP BW データ・ソース内で定義し特別に構築したクエリーでなければなりません。

パッケージ作成の一般的な情報については、「Framework Manager User Guide」の「Create or Modify a Package」を参照してください。

SAP BW Business Explorer Query Designer でのクエリーの作成

インポートするキューブが含まれたクエリーを作成する必要があります。データベース内の単一の InfoCube を基準にしてクエリーを作成することを推奨します。複数のソースを基準にするクエリーは、データ取得の際に SAP BW エラーを引き起こす可能性があります。

クエリーの作成後に、変数を作成できます 470 ページの『変数の作成』。

手順1. 「Query Designer」で、「New Query」をクリックします。

2. 「New Query」ダイアログ・ボックスで、インポート対象のキューブを含む情報プロバイダーを選択します。

3. 「ツール」アイコンをクリックして、「InfoObject」の技術名を表示します。

4. インポートする特性を、左側の列にある「InfoObject」カタログからページの右側にあるいずれかのフィールドの 1 つにドラッグします。例えば、「列」または「行」にドラッグします。


選択した特性によって、Cognos Transformer キューブのメタデータが定義されます。特性には、次の制限事項が適用されます。

v データをセグメント化するためのオプション変数が少なくとも 1 つはある。

v データ・ソースの代表的な特性を選択する。キー数値またはディメンションを特性として選択できます。キー数値の場合は Cognos Transformer の数値データになり、ディメンションの場合は Cognos Transformer のディメンションになります。

v 方法 (明示的または変数) に関係なく、いずれの特性にも表示階層を割り当てない。

v SAP BW クエリーにあるすべてのキー数値を数値にする。

v 「Currency/Unit」の特性は選択しない。

v 選択したすべてのキー数値で同じ通貨を使用する。

v Framework Manager で抽出予定の特性のみを SAP BW クエリーに含める。不要な特性を含めるとデータ量が増え、パフォーマンスに悪影響があります。

v 特性は、必ずクエリー定義の「列」フィールドまたは「行」フィールドにコピーする。「Free Characteristics」フィールドや「フィルター」フィールドにコピーすると、パッケージからのインポート時には特性がディメンションとして表示されますが、ストリーム抽出処理で値を取得できません。

v フィルターを定義する場合は、クエリー定義の他の場所に含まれているディメンションのみを参照するようにする。

v 自由特性を含めた場合、その特性の値はキー数値の抽出データで表示されない。由特性上のフィルターは、返された SAP BW データのフィルターとして機能します。このフィルターは、InfoCube のサブセットを定義するためのフィルターとして使用できます。

v クエリーに対する入力プロンプトではなく、選択リストのプロンプトを使用する。選択リストのプロンプトには、データをセグメント化するための値が表示されます。

5. Cognos Transformer キューブにデータを挿入するメタデータを定義するには、含める対象として選択した各特性のプロパティーを変更する必要があります。特性を右クリックして、「プロパティー」を選択します。

6. 「Properties of Characteristic」ダイアログ・ボックスで、「Display As」の値を「キー」に変更し、「Suppress Results Rows」の値を「常時」に変更します。ここで適用した制限やフィルターは、Cognos Transformer にも移行されることに注意してください。

7. 手順 4 で選択した各特性について、手順 5～6 を繰り返します。

注: 必要な特性のみを選択する必要があります。過度なメモリー使用、システム・パフォーマンスの低下、およびシステム障害を防止するため、クエリーに含める特性を慎重に検討してください。データ量が許容範囲を超えないかどうか、SAP BW の管理者に相談することを推奨します。

8. 「Queries Properties」アイコンをクリックし、「拡張」タブで「AllowExternal Access to this Query」チェック・ボックスをオンにします。これによりクエリーが Framework Manager に公開されます。

付録 D. Transformer で使用する SAP BW データの作業ガイドライン 469

9. 「保存」をクリックし、「説明」と「Technical Name」を新しいクエリーに指定します。「Technical Name」フィールドでは、SAP BW の命名規則を使用することを推奨します。つまり、文字「Z」で始め、その後にわかりやすい名前または組織の標準的な名前規則に従う名前を続けます。この技術名はFramework Manager でクエリーを探すときに必要になるため、書きとどめておきます。

タスクの結果

これで変数を作成する準備が整いました『変数の作成』。SAP Query Designer の使用の詳細については、SAP BW のドキュメントを参照してください。

変数の作成Cognos Transformer から SAP に小さいクエリーを発行できるように、クエリー用のオプション・プロンプト・パラメーターを作成し、データ・セット全体を取得できるようにします。

Cognos Transformer で使用するために SAP BW のデータを抽出するときに変数を使用する方法については、定まった規則があるわけではありません。ただし、使用中の SAP 環境でパフォーマンスが劣化したりメモリー不足でエラーが発生する可能性があるほど多量のデータを要求しないように注意する必要があります。

基本的なガイドラインとして、抽出に変数を利用すると、変数が定義されているディメンションに存在するすべてのメンバーが Cognos Transformer によってまずフェッチされます。次に、その変数に一致するものを見つけるために、CognosTransformer で個々のデータ・フェッチが実行されて、ディメンション内のメンバーごとにファクト・データが抽出されます。

この処理により、SAP BW サーバーで処理できる大きさに Cognos Transformerでデータ抽出が分割されます。どのディメンションに適用するかに関して、定まった基準はありません。最適なパフォーマンスを確保するには、SAP BW のデータを把握して、どのディメンションでファクト・データが均等に分割できるかを判断する必要があります。

変数を定義するディメンションは、注意深く選択する必要があります。最適なパフォーマンスを得るには、少し実験が必要な場合があります。例えば、米国 (US)、カナダ (CA)、メキシコ (MX) の 3 つの国や地域をメンバーとして含む「国または地域」ディメンションがあるとします。ほとんどのビジネス (90 %) は米国で行われており、残りのビジネス (10 %) がカナダとメキシコに均等に計上されている場合、このディメンションではデータを均等に分割できません。結果として生成されるクエリーは、1 つの非常に大きな要求 (US) と 2 つの小さな要求 (CA と MX)になってしまいます。したがって、このディメンションは、適切な候補とはいえません。

非常に小さな要求が多数生成されるディメンションに変数を適用するのも、得策ではありません。例えば、SAP BW 環境でよく利用される「0MATERIAL」ディメンションは、実行する要求が小さくて多数になるため、適切な候補とはいえません。


10 箇所のコスト・センターにデータを均等に分割する「COSTCENTER」というディメンションが定義されているとすると、データを均等にセグメント化できる可能性があります。別の適切な候補としては、暦年や暦月でデータを適切なセクションに分割する方法もあります。

データ抽出用のクエリーには、変数を適用する必要はありません。変数を適用しないときに最適な抽出が行われる場合もあります。例えば、適切な方法の例としては、20 の個別のフェッチにデータを分割するディメンションに変数を適用して、抽出をテストする方法があります。この方法でパフォーマンスがよければ、5 つの別個のメンバーを含む別のディメンションに変数を適用して比較してみることもできます。

どの環境も異なるため、すべてに当てはまる公式はありませんが、SAP BW 環境が乱れるのを防ぐために慎重な方法を選ぶことを推奨します。

手順

1. Query Designer で、前の手順で選択した特性を右クリックし、「Restrict」を選択します。

データが均等に配分されるようにするため、キューブの代表的な特性であり、多数の値を生成しない特性を選択します。変数の各値に対する行数がほぼ同じになるような変数を作成します。粒度が細かすぎる変数 (1 つの値に対する行数が少なく、過剰な数のクエリーが生成される場合など) や、粗すぎる変数 (1 つの値に対する行数が 100 万を上回るような場合など) を作成しないようにします。

2. 「Selection for ...」ダイアログ・ボックスの「変数」タブをクリックし、「説明」ウィンドウ内の任意の場所を右クリックして、「変数を新規作成」を選択します。

注: 選択した特性のいずれかに変数がすでにある場合、新しい変数は作成せずに、手順 7 に進みます。

3. 「New Variable Wizard General Information」ページで「Variable Name」と「説明」を入力して、ディメンションを特性として選択します。「次へ」をクリックします。

4. 「詳細」ページで、「Variable Represents」フィールドの「単一の値」、「Multiple Single Values」、または「間隔」を選択し、「Variable entryis」フィールドの「オプション」を選択して、「Ready for Input」チェック・ボックスをオンします。「次へ」をクリックします。

5. 「デフォルト値」ページで、「デフォルト値」フィールドが空になっていることを確認します。

6. 「Selection for ...」ダイアログ・ボックスに戻るまで、「次へ」をクリックします。「説明」ウィンドウに新しい変数が表示されます。

7. 変数を選択してから右矢印をクリックして、選択した変数を「選択」ウィンドウに移動します。クエリーを保存します。これで Framework Manager にクエリーをインポートする準備が整いました。

Framework Manager でのパッケージの作成IBM Cognos Framework Manager でパッケージを作成するには、次の操作を行う必要があります。


v メタデータ・ウィザードを使用して SAP BW メタデータをインポートする『メタデータ・ウィザードを使用してインポートする手順』

Framework Manager を使用して、SAP BW クエリーをモデルにインポートし、Content Manager にエクスポートするためのパッケージを定義します。

インポート時には、次の点に留意してください。

– SAP BW クエリーで選択したクエリーは、「インポート」ダイアログ・ボックスの「Dimension Folders」で使用できる。

– 各ディメンションには少なくとも 1 つの階層が含まれている。

– 階層と同じ名前の主階層を常に選択する。

– 他の階層がある場合は、階層内の目的のレベルのセットがある階層を選択する。

– Framework Manager は、設定パラメーターがオンになっている場合にのみ、SAP BW データ・ソースからモデルに時間ディメンションをインポートする。時間ディメンションとして設定するとグローバルなエントリーになるため、インポートされたディメンションはすべて時間文字列として扱われます。

v パッケージを作成する 473 ページの『パッケージを作成する手順』

Content Manager に発行するパッケージを作成する際、2 つの階層がインポートされたディメンションで主階層を非表示にします。主階層は必須であり、クエリーが正しく機能するように必ずパッケージに含める必要があります。表示したくない場合は、階層を非表示にできます。

メタデータ・ウィザードを使用してインポートする手順

手順

1. Framework Manager で、「新規プロジェクトの作成」をクリックします。

2. 「プロジェクトを新規作成」ダイアログ・ボックス内のフィールドに入力します。「OK」をクリックします。

3. 「メタデータ・ウィザード」の手順をすべて実行します。データ・ソースの選択を要求するプロンプトが表示されたら、新しいデータ・ソースを作成する必要がある場合は「新規作成」をクリックします。

4. 「Select Objects」ページで、以前の手順 468 ページの『SAP BW BusinessExplorer Query Designer でのクエリーの作成』で SAP BW Query Designerで定義したクエリーを見つけます。変数を作成したときに指定した技術名のリストをスクロールします。フォルダー構造は、"Hierarchies > Level definitions >Query Item definitions"です。

5. レベルに直接関係する、主クエリー・アイテムを選択します。つまり、(キー)、(名前) などのラベルが付いているアイテムです。

ヒント: セカンダリー属性や追加属性は Transformer へのインポート時に削除されます。インポートされるのは、必要なアイテムのみです。ただし、パフォーマンスをよくするために、二次属性や追加属性を選択しないことを推奨します。ここですべての属性を選択した場合は、パッケージの発行時に不要なクエリー・アイテムを除外できます。


6. 「メタデータ・ウィザード」の残りの画面を操作し、デフォルト値をそのまま使用して、「次へ」をクリックします。ディメンションが生成されて、メタデータがインポートされます。

7. ウィザードの最後の画面で、結果を確認して「終了」をクリックします。

タスクの結果

これで、Transformer でモデルを作成する準備が整いました。パッケージ作成の詳細については、「Framework Manager User Guide」の「Create or Modify aPackage」を参照してください。

パッケージを作成する手順

手順

1. 「パッケージ」フォルダーをクリックし、「操作」メニューで「作成」、「パッケージ」の順にクリックします。

2. 「Provide Name」ページで、パッケージの名前を入力し、必要に応じて説明と画面のヒントを入力します。「次へ」をクリックします。

3. 前のセクションでインポートしたクエリーを選択します。

詳細については、 468 ページの『SAP BW Business Explorer Query Designerでのクエリーの作成』を参照してください。

4. パッケージで子オブジェクトを非表示にしたり除外したりする場合は、「Define objects」ページで、対象のオブジェクトを個別に選択する必要があります。親オブジェクトを除外すると、親の子もすべて除外されます。サイズの大きなキューブで多数のオブジェクトを除外した (含めるオブジェクトとして選択しなかった) 場合、処理に多大な時間がかかります。

注: Framework Manager では、Ctrl + Shift と Alt + Shift の機能がサポートされています。キューブに含める、または、キューブで非表示にするオブジェクトを複数選択する場合は、これらのキー操作を使用します。例えば、大きな枝内にある 2 つのアイテムのみを含める場合は、まず枝全体を選択します。次に、Ctrl キーを押しながら Shift キーをクリックし、含めるアイテムを選択解除して、残りの選択アイテムを非表示にします。

オブジェクトを含めたり、除外したり、非表示にしたりする方法については、「Framework Manager User Guide」の「Create or Modify a Package」を参照してください。

5. パッケージのデフォルトのアクセス権を使用するかどうかを選択します。

v デフォルトのアクセス権を使用する場合は、「終了」をクリックします。

v アクセス権を設定するには、「次へ」をクリックします。

6. 「Publish Package Wizard」を開くかどうかを尋ねるプロンプトで、「はい」をクリックします。

7. デフォルト値を選択し、「発行」をクリックします。これによりパッケージがContent Store に発行され、Transformer でパッケージにアクセスできるようになります。

8. 最後の画面で結果を確認し、「終了」をクリックします。


タスクの結果

これで、Transformer でモデルを作成する準備が整いました。パッケージ作成の詳細については、「Framework Manager User Guide」の「Create or Modify aPackage」を参照してください。

Transformer でのモデルの作成Transformer を使用して発行済みの SAP ベースのパッケージにアクセスし、モデルを作成するためのデータ・ソースとして使用します。モデルを作成した後、目的の IBM Cognos コンポーネントで使用可能な PowerCube を作成し、オリジナルの SAP BW ソースのディメンション・データとファクト・データにアクセスできるようになります。また、キューブ構築時のデータ結合に必要となるキーの一致情報があれば、Transformer モデル内の SAP メタデータを、他の企業のメタデータまたは個人のソースと組み合わせることができます。

Transformer モデルを作成するときには、「新規モデル・ウィザード」ではなく、「パッケージからディメンションを挿入」ウィザードを使用する必要があります。「パッケージからディメンションを挿入」ウィザードを使用する理由は次のとおりです。

v 各ディメンションおよびファクトに対して 1 つのクエリーが作成される。

v ディメンションを使用してモデル化されたリレーショナル・モデルと同じように、ファクトとディメンションがインポートされる。つまり、ファクトとディメンションが同時にインポートされます。

v ディメンションとファクトの間で範囲が正しく設定される。

v 適切なビジネス・キーとキャプション情報がディメンションに挿入される。

v メタデータのインポート時に、BW パッケージからキューブ構築に必要なアイテムのみがインポートされる。これにより属性の数を削減し、キューブ構築に必要なアイテムのみが含まれたデータ量に抑えることができます。

ビジネス・ルールを定義する場合は、Framework Manager ではなく Transformerモデルで作成します。 Framework Manager で定義した計算は Transformer にインポートできません。

Transformer でモデルを作成する手順

手順

1. Transformer で、「新規モデルを作成」をクリックします。

2. 「新規モデル・ウィザード」で「キャンセル」をクリックします。

3. 「ディメンション・マップ」ウィンドウを選択した状態で、「編集」メニューの「パッケージからディメンションを挿入」をクリックします。

4. 「参照」をクリックしてメタデータ・ブラウザーを開きます。

5. 「メタデータを参照」ダイアログ・ボックスで、SAP BW クエリーが含まれているパッケージを選択し、「OK」をクリックします。

6. 「パッケージからディメンションを挿入」ダイアログ・ボックスで、「終了」をクリックします。


7. 「パッケージからディメンションと数値データを選択」ダイアログ・ボックスで、データ・ソースに含めるディメンションと数値データをクリックします。

PowerCube に日付を指定するクエリー・アイテムを選択します。PowerCubeの日付は、トランザクション・データのみから取得できることに注意してください。

8. エラーまたは警告が発生した場合は、表示されます。「データ・ソース」ウィンドウでパッケージを展開し、データ・ソース・クエリーとクエリー・アイテムを表示します。キー数値と数値データは、「数値データ」ウィンドウに表示されます。

各数値データの集計規則が Transformer 内に正しく定義されていて、SAPBW に定義されている集計規則にできるだけ近い定義になっていることを確認します。

すべての数値データの保存タイプを 64 ビットの浮動小数点にする (推奨)。

各特性 (ディメンション) のルート・レベルに、一意のマークが付いていることを確認する。

SAP BW の表示階層には、通常は階層内の「not assigned」や「#」のノードに関連して、不規則なパスが含まれている場合がある。これらの階層にギャップがあると、Transformer の階層内の関連するレベルに空白ができます。Transformer では、空白に使用するテキストを定義できます (デフォルトのテキストは「<空白>」です)。各レベルの空白のエントリーに、より適切なテキストを定義することを推奨します。

9. 他のクエリーを追加する場合は、手順 3～7 を繰り返します。

ヒント:数値データを追加した後に、モデルに新しいディメンションを追加した場合、新しいディメンションのキーは Transformer によって「キー数値」に自動的に追加されません。そのため有効範囲がディメンション・マップで定義されません。この場合は手作業で、新しいディメンションのキーをディメンションの最下位レベルから「キー数値」に追加する必要があります。

10. モデルを保存します。

タスクの結果

このモデルを使用すると、目的の IBM Cognos コンポーネントで使用可能なPowerCube を作成し、オリジナルの SAP BW データ・ソースのディメンション・データとファクト・データにアクセスできるようになります。詳細については、「Transformer ユーザー・ガイド」の『モデルの作成』のセクションを参照してください。


Framework Manager における外部化された CSV ファイルを使用したSAP BW データの処理

他のアプリケーションで使用できる形式にクエリー・サブジェクトやディメンションを外部化するときには、特別な考慮事項があります。Framework Manager を使用して SAP BW からデータを抽出するときに、Framework Manager では、さまざまなタイプのディメンションが区別されることを理解しておく必要があります。ディメンションのタイプによって外部化されるときの動作が異なりますが、外部化する前に変更できます。

Transformer バージョン 7.x、8.1、8.2 では、クエリー・サブジェクトとディメンションが CSV ファイルで外部化された Framework Manager パッケージを使用して、SAP BW データを利用できます。 Transformer では、モデルを作成してPowerCube を生成するためのデータ・ソースとして CSV ファイルを使用できます。 Transformer バージョン 8.3 では CSV ファイルもサポートされていますが、ディメンション・データにはパッケージ・サポートを使用し、ファクト・データには CSV ファイルを使用することを推奨します。

このバージョンの Transformer で SAP BW データを利用する場合には、ContentManager に対して発行された Framework Manager パッケージを使用する方法を推奨します。パッケージ作成の一般的な情報については、「Framework ManagerUser Guide」の「Create or Modify a Package」を参照してください。パッケージの作成に関する SAP 固有の情報については、『Framework Manager におけるパッケージを使用した SAP BW データの処理』のトピックを参照してください。

Extract Size

Framework Manager の「Extract Size」データ・ソース・プロパティーでは、SAPBW から 1 回に取得されるデータ量が制御されます。

この設定が負の値、ゼロ、空のいずれかの場合は、1 つのクエリーが SAP BW に発行されて特性データが抽出されます。

この設定が正の値の場合は、複数のクエリーが SAP BW に発行されて、「ExtractSize」プロパティーで指定された MB 程度のデータが各クエリーに返されます。

この機能により、SAP BW サーバー上のクエリー結果の全体的なサイズを削減できます。クエリー全体の実行時間は長くなる場合がありますが、大きな特性の場合は、この機能を使用しないと、SAP BW サーバーでユーザーに割り当てられているメモリー容量を消費してしまう可能性があります。

抽出ファイルが作成される前に、特性ディメンションのデータ全体が FrameworkManager のメモリーにロードされます。Framework Manager のメモリー割り当てエラーで抽出が失敗しないように、必要なクエリー・アイテムのみを SAP BW から抽出することが重要です。

モデル・クエリー・サブジェクトは、IBM Cognos 内で実行されるクエリーと同じメカニズムを使用して抽出されます。そのため、「Extract Size」プロパティーは、クエリーの実行には効果がありません。


数値データ・ディメンション

数値データ・ディメンションを抽出するときには、必要な数値データが格納されたモデル・クエリー・サブジェクトを作成します。実現しようとしている細分性のレベルに応じて、各ディメンションの各レベルから、ビジネス・キー・クエリー・アイテムを格納します。

モデル・クエリー・サブジェクトの外部化については、 479 ページの『FrameworkManager の考慮事項』を参照してください。

特性ディメンション

特性ディメンションは、InfoCube や SAP BW クエリーなどの SAP BW データ・ソースのタイプに関係なく外部化されます。

Framework Manager では、ファクト・クエリー・アイテムを含まないすべてのディメンションを外部化するために 1 つの方法が使用されます。この場合、「ExtractSize」設定を使用して SAP BW からデータが抽出される方法が制御されます。

注:ファクト・クエリー・アイテムが含まれているかどうかに関わりなく、モデル・クエリー・サブジェクトは別の法で外部化されます。モデル・クエリー・サブジェクトの外部化については、 479 ページの『Framework Manager の考慮事項』を参照してください。

SAP BW InfoCube のキー数値ディメンション

InfoCube に基づくモデルからキー数値ディメンションを外部化するときに、Framework Manager では、モデル・クエリー・サブジェクトを外部化するために使用される方法とまったく同じ方法が使用されます。

数千を超えるトランザクションを含む InfoCube の場合、Framework Manager から直接 InfoCube を外部化すると、クライアントかサーバーどちらかの時間とメモリーの制限を簡単に超える場合があります。このような場合、SAP BW メタデータを外部化するためのベースとして SAP BW のクエリーを使用することを推奨します。

SAP BW クエリーのキー数値ディメンション

SAP BW のデータ・ソースからキー数値を外部化するには、BEx クエリーをベースとして使用するのが、ほとんどの場合に最善の方法です。BEx 変数を使用してキー数値ディメンションのデータを扱いやすいセクションに分割することにより、任意のトランザクション・データを SAP BW から大量に抽出できます。

ただし、この方法には、SAP BW から抽出できる内容と方法に制限があることに注意してください。このセクションの残りの部分では、既知の制限事項も含め、SAPBW からデータを抽出するために SAP BW クエリーがどのように使用されるかについて説明します。

SAP BW クエリーの要件このセクションの残りの部分では、SAP BW クエリーを、データを外部化するためのベースとして使用する場合を想定しています。レポート作成のベースとして使用


したり、InfoCube からデータを直接抽出することによってメモリーや時間の制限を超過する可能性がある状況は想定していません。

SAP BW クエリーは、どれでも外部化できるわけではありません。外部化するためには、SAP BW クエリーが次の制限を満たしていることが必要です。

v 特性表示を「キー」に設定する。表示を他の設定にすると、正しくないデータになる場合があります。

特性に表示される内容を変更するには、特性を右クリックして「プロパティー」を選択します。「Properties of Characteristic」ダイアログ・ボックスで、「Display As」の値を「キー」に変更します。

「キー」を使用することを推奨します。

v データ量および SAP BW サーバーで実行される集計の量を減らすために、クエリー内のすべての特性の集計をプロパティー・シートで無効にしておく。

特性の集計を無効にするには、SAP BW クエリーの端にある特性を右クリックして、「プロパティー」をクリックします。「プロパティー」ダイアログ・ボックスで、「Suppress Results Rows」の値を「常時」に設定します。

v SAP BW クエリー内の特性が 1 つでも「Key」以外の特性で表示されている場合は、すべての特性の集計を消去する。

v 「Currency/Unit」特性がクエリーに含まれないようにする。

v 明示的にも変数によっても、特性に表示階層が割り当てられないようにする。

v SAP BW クエリーに自由特性として特性が含められている場合、その特性の値はキー数値の抽出データに表示されない。

自由特性に対するフィルターは、SAP BW によって返されるデータに対するフィルターとして動作します。この機能は、InfoCube のサブセットを定義するための効果的なメカニズムとして使用できます。

そのようなフィルターは、SAP BW クエリーの軸に沿った特性にも適用できます。この場合、フィルターがかけられた値は、キー数値の抽出データに表示されます。

v SAP BW クエリーにあるすべてのキー数値を数値にする。

v キー数値の値は 1 つの通貨にする。目的の通貨の割り当てに、変数を使用しないでください。

v Framework Manager を使用して抽出する特性のみを SAP BW クエリーに含める。不要な特性を含めると SAP BW から転送されるデータ量が増え、パフォーマンスに悪影響を及ぼします。

SAP BW キューブを使用する作業のガイドラインと制約SAP BW キューブからメタデータをインポートするときには、CSV ファイルを使用する必要があります。パフォーマンス上の理由により、取得されるデータ量が制限される地理、期間、その他のディメンションでフィルターをかけることを推奨します。関連するディメンションとファクト表 (数値データ) にもディメンション・フィルターをかける必要があります。


詳細については、「Framework Manager User Guide」の「Create a Filter」を参照してください。

SAP BW のキューブは多次元であるため、集計はソースで適用されます。CognosTransformer にデータをインポートした後に集計タイプを変更すると、結果が有効でなくなります。

コンテキストによっては、特定の数値データの範囲外にある欠落したデータやメタデータが原因で、異なる結果になる場合があります。次が表示される場合もあります。

v NULL 値

v # 記号

v REST_H

v Not assigned

重複したトークンは、一意のレベルなどにおいて Cognos Transformer で問題を起こす可能性があるため、ディメンションにフィルターをかけて、インポートされたデータに重複したトークンが表示されないようにすることを推奨します。

最後に、フィルターをかけたデータを生成するために必要なクエリー・アイテムのみを選択します。

Framework Manager の考慮事項SAP BW クエリーから数値データ・ディメンションを抽出するときには、データ・ソースの「Extract Size」プロパティーによって、SAP BW サーバーから 1 回に取得されるデータ量が制御されます。ファクト・クエリー・アイテムが含まれているかどうかに関わりなく、モデル・クエリー・サブジェクトは別の方法で外部化されます。このシナリオでは、この設定は SAP BW サーバーには影響しませんが、Framework Manager がデータを取得するために 1 回に割り当てるメモリー量は、この設定に従って制限されます。

キー数値ディメンションに定義されているフィルターは、SAP BW クエリーからデータを抽出するときには実行されないことに注意してください。SAP BW クエリーからデータを抽出するときのパフォーマンスをよくするには、SAP BW クエリーにフィルターを定義する必要があります。

また、キー数値ディメンション内に定義されている計算も無視されます。これらの計算は、BEx にある SAP BW クエリー内か、Framework Manager にあるモデル・クエリー・サブジェクトに定義できます。

抽出された各特性には、階層 (存在する場合) の最下位レベルのクエリー・アイテムを少なくとも 1 つ含めてキー数値の抽出データとリンクする必要があります。実現しようとしている細分性のレベルに応じて、各ディメンションの各レベルから、ビジネス・キー・クエリー・アイテムを格納します。

SAP BW クエリーのキー数値を外部化するための変数の使用SAP BW クエリー内のトランザクション量から考えて、ほとんどの場合、1 つのクエリーで SAP BW からデータを抽出すると、SAP BW サーバーでユーザーに割り当てられているメモリーを超過してしまいます。Framework Manager では、1 つ


のオプション変数を使用して、SAP BW のクエリーからファクト・データを妥当な大きさのセクションに分割して抽出できます。

この機能を使用するには、SAP BW のクエリーに含まれる 1 つの特性 (自由特性として含まれた特性を除く) に次の制約を満たす変数を割り当てます。

v 単一の値ある。

v オプションである。

v デフォルト値がない。

v 特性または表示階層に定義されている。

SAP BW のクエリーに上記の変数が含まれていて、キー数値ディメンションが外部化されている場合、Framework Manager では、変数に関連付けられている各値に対してクエリーが実行されます。したがって、適切な特性を選択することにより、クライアントやサーバーのメモリー制限を超過せずにキー数値ディメンションを抽出することができます。クライアントとサーバー上のメモリー・キャッシュは、クエリーが終わるたびにフラッシュされます。

表示階層を使用して抽出データ・セクションを作成する場合は、変数の値を階層内の単一のレベルから取得することが重要です。複数のレベルから取得すると、さまざまなレベルで集計されたデータが抽出されることになります。変数の値を階層の単一のレベルに限定するには、Framework Manager で変数の「Level Restriction」を編集します。例えば、「2:2」などの値は、階層の第 2 レベルの値のみを使用することを示しています (レベル「0」は階層のルートです)。

上記の変数が 1 つ設定された SAP BW のクエリーがある場合、変数の値はクエリーが終わるたびにリセットされます。

SAP BW のクエリーに 1 つの変数以外のものが含まれているか、上記のように定義されていない場合、Framework Manager で変数を使用してキー数値ディメンションを小さなセクションに分割して抽出する処理は行われません。

外部化時に発生する問題に対する回避策Framework Manager からデータ・ソースを外部化するときには、次の場合に認証エラーが発生する可能性があります。

v モデルが Content Manager に発行されている場合

v IBM Cognos Configuration の Passport に割り当てられているタイムアウト期間よりも長い時間がデータの外部化にかかる場合

資格情報の再入力を求めるプロンプトはユーザーには表示されません。

エラーが発生しても、外部化されたデータは引き続き完全で有効です。ただし、モデル作成者が実際にモデルを発行することにした場合、モデル作成者は再認証してモデルを再発行する必要があります。その際にデータを外部化する必要はありません。

別の解決策として、モデルをネットワークに発行する方法があります。この場合、認証エラーは発生しません。


SAP BW データからの PowerCube の作成SAP BW のデータから IBM Cognos PowerCube を作成できます。FrameworkManager と Transformer の両方に関するガイドラインがあります。

詳細については、『Framework Manager のガイドライン』および『Transformerガイドライン』を参照してください。

Framework Manager のガイドライン1 つ以上の PowerCube を作成するためにデータを外部化するときには、次の点を考慮に入れます。

v 各特性の抽出データには、キー数値の抽出データにある代理キーのクエリー・アイテムと等しい共通キーのクエリー・アイテムが必要である。

v SAP BW クエリーに基づく抽出データの場合、すべての特性を SAP BW クエリーで「Key」として表示する (推奨)。

v 特性に表示階層がない場合、または新しい表示階層を作成する場合は、階層のレベルのベースになる 1 つ以上のクエリー・アイテムを抽出する。

v データを抽出するモデルに SAP BW メタデータをインポートするときには、PowerCube の作成に必須のクエリー・アイテムのみにモデルを限定する。これによってデータ抽出のパフォーマンスが上がります。

v SAP BW ベースのクエリー・サブジェクトおよびディメンションを外部化するとき、Null 値は CSV ファイルに含まれる。

v PowerCube の実際的な限度は、ディメンション (特性) 当たり 2,000,000 カテゴリー () である。

Transformer ガイドラインFramework Manager から抽出した SAP BW のデータを使用するときには、次の点を考慮に入れます。

v Transformer バージョン 8.3 では、「パッケージからディメンションを挿入」オプションを使用して、SAP データ・ソースの標準ディメンションを IBMCognos データ・ソースから直接挿入できる。

v Transformer のモデル・ウィザードを使用して、「列タイトル付き区切りフィールド・テキスト」タイプのデータ・ソースを挿入し、CSV ファイルを選択して起動する。 AUTO DESIGN は実行しないでください。

v 「データ・ソース」ウィンドウから「数値データ」ウィンドウに、キー数値のすべての列をドラッグする。各数値データの集計規則が Transformer 内に正しく定義されていて、SAP BW に定義されている集計規則にできるだけ近い定義になっていることを確認します。

v すべての数値データの保存タイプを 64 ビットの浮動小数点にする (推奨)。

v 日付ウィザードで、PowerCube に日付を設定するクエリー・アイテムを選択する。PowerCube の日付は、トランザクション・データのみから取得できることに注意してください。

v Framework Manager を使用して外部化した特性に対応するさまざまな CSV ファイルを挿入する。

各 CSV ファイルには、キー数値の CSV ファイルにある列に対応する列があります。さまざまな列を右クリックし、列のプロパティーを編集して、特性とキー


数値の間のリンクになる列が同じ名前になるようにします。例えば、キー数値の列の名前が「顧客」で、対応する顧客の CSV ファイルの名前が「顧客 - キー」だとすると、キー数値の CSV ファイルにある列の名前を「顧客 - キー」に変更できます。

v 各特性に対して、新規ディメンションを作成し、キー列や特性の他の属性を使用して、ディメンションのレベルを設定する。各レベルでは、必要に応じて、ラベル、短い名前、説明のプロパティーが元の列に指定されていることを確認します。

v 各特性 (ディメンション) のルート・レベルに、一意のマークが付いていることを確認する。

v SAP BW の表示階層には、通常は階層内の「not assigned」や「#」のノードに関連して、不規則なパスが含まれている場合がある。これらの階層にギャップがあると、Transformer の階層内の関連するレベルに空白ができます。

Transformer では、空白に使用するテキストを定義できます。デフォルトのテキストは blank ですが、各レベルの空白エントリーに、より適切なテキストを定義してください。


付録 E. 予約語

データ・ソース、テーブル、および列の名前には、IBM Cognos ソフトウェアが予約している名前を使用しないようにしなければなりません。

予約語を使用する必要がある場合、SQL 仕様で単語を引用符で囲んでください。例えば、select Orderdate, "Timezone" のようにします。

以下の語は予約されています。

範囲予約語

A から C abs、 all、 and、 any、 as、 asc、 at、avg、 between、 bigint、 bit_length、boolean、 both、 by、 call、 case、 cast、ceil、 ceiling、 char、 char_length、character、 character_length、 coalesce、count、 create、 cross、 cube、cume_dist、 current、 current_date、current_time、 current_timestamp、 cursor

D から M date、 day、 dbkey、 dec、 decimal、declare、 delete、 dense_rank、 desc、distinct、 double、 else、 end、 escape、except、 exists、 exp、 extract、 false、filename、 filter、 first、 first_value、float、 floor、 following、 for、 from、full、 group、 grouping、 hash、having、 hour、 in、 inner、 insert、int、 integer、 intersect、 interval、 into、is、 join、 last、 last_value、 leading、left、 like、 ln、 local、 localtime、localtimestamp、 loop、 lower、 max、merge、 min、 minute、 mod、 month

N から Q national、 natural、 nchar、 no、 not、ntile、 null、 nullif、 nulls、 numeric、nvarchar、 octet_length、 of、 on、 or、order、 others、 out、 outer、 over、partition、 perc、 percent_rank、percentile、 percentile_cont、percentile_disc、 position、 power、preceding、 precision、 qualify


範囲予約語

R から T range、 rank、 ratio_to_report、 ravg、rcount、 rdiff、 real、 recursive、returning、 right、 rmax、 rmin、rollup、 row、 row_number、 rows、rsum、 scroll、 second、 select、 set、sets、 smallint、 snapshot、 some、 sqrt、stddev、 stddev_pop、 stddev_samp、substring、 sum、 table、 tertile、 then、time、 timestamp、 timezone_hour、timezone_minute、 to、 top、 trailing、trim、 true

U から Z unbounded、 union、 unknown、updatable、 update、 upper、 user、using、 values、 var_pop、 var_samp、varchar、 variance、 varying、 when、where、 window、 with、 within、without、 xavg、 xcount、 xfirst、 xlast、xmax、 xmin、 xmovingavg、xmovingsum、 xntile、 xperc、 xrank、xratio、 xstddev、 xstddev_pop、 xsum、xtertile、 xvariance、 xvariance_pop、year、 zone

_cursor、_local、および _rowset も予約語です。


付録 F. XML データ型

IBM Cognos Framework Manager で XML を表形式データ・ソースとしてインポートできます。

XML から Framework Manager へのインポートにおいて、以下のデータ型がサポートされます。

v boolean

v byte

v date

v dateTime

v decimal

v double

v ENTITIES

v ENTITY

v float

v ID

v IDREF

v int

v integer

v language

v long

v Name

v NCName

v negativeInteger

v NMTOKEN

v NMTOKENS

v nonNegativeInteger

v NonPositiveInteger

v NOTATION

v positiveInteger

v QName

v short

v string

v time

v token

v unsignedLong

v unsignedInt

v unsignedShort


v unsignedByte

以下のデータ型はサポートされていません。

v base64Binary

v duration

v gYearMonth

v gYear

v gMonthDay

v gMonth

v hexBinary


特記事項

本書は IBM が世界各国で提供する製品およびサービスについて作成したものです。

この記述は、IBM から他の言語で提供されている場合があります。ただし、これを入手するには、本製品または当該言語版製品を所有している必要がある場合があります。

本書に記載の製品、サービス、または機能が日本においては提供されていない場合があります。日本で利用可能な製品、サービス、および機能については、日本 IBMの営業担当員にお尋ねください。本書で IBM 製品、プログラム、またはサービスに言及していても、その IBM 製品、プログラム、またはサービスのみが使用可能であることを意味するものではありません。これらに代えて、IBM の知的所有権を侵害することのない、機能的に同等の製品、プログラム、またはサービスを使用することができます。ただし、IBM 以外の製品とプログラムの操作またはサービスの評価および検証は、お客様の責任で行っていただきます。本書には、お客様が購入されたプログラムまたはライセンス資格に含まれない製品、サービス、または機能に関する説明が含まれる場合があります。

IBM は、本書に記載されている内容に関して特許権 (特許出願中のものを含む) を保有している場合があります。本書の提供は、お客様にこれらの特許権について実施権を許諾することを意味するものではありません。実施権についてのお問い合わせは、書面にて下記宛先にお送りください。

〒103-8510東京都中央区日本橋箱崎町19番21号日本アイ・ビー・エム株式会社法務・知的財産知的財産権ライセンス渉外

以下の保証は、国または地域の法律に沿わない場合は、適用されません。 IBM およびその直接または間接の子会社は、本書を特定物として現存するままの状態で提供し、商品性の保証、特定目的適合性の保証および法律上の瑕疵担保責任を含むすべての明示もしくは黙示の保証責任を負わないものとします。国または地域によっては、法律の強行規定により、保証責任の制限が禁じられる場合、強行規定の制限を受けるものとします。

この情報には、技術的に不適切な記述や誤植を含む場合があります。本書は定期的に見直され、必要な変更は本書の次版に組み込まれます。 IBM は予告なしに、随時、この文書に記載されている製品またはプログラムに対して、改良または変更を行うことがあります。

本書において IBM 以外の Web サイトに言及している場合がありますが、便宜のため記載しただけであり、決してそれらの Web サイトを推奨するものではありません。それらの Web サイトにある資料は、この IBM 製品の資料の一部ではありません。それらの Web サイトは、お客様の責任でご使用ください。


IBM は、お客様が提供するいかなる情報も、お客様に対してなんら義務も負うことのない、自ら適切と信ずる方法で、使用もしくは配布することができるものとします。

本プログラムのライセンス保持者で、(i) 独自に作成したプログラムとその他のプログラム (本プログラムを含む) との間での情報交換、および (ii) 交換された情報の相互利用を可能にすることを目的として、本プログラムに関する情報を必要とする方は、下記に連絡してください。

IBM Software GroupAttention: Licensing3755 Riverside Dr.Ottawa, ONK1V 1B7Canada

本プログラムに関する上記の情報は、適切な使用条件の下で使用することができますが、有償の場合もあります。

本書で説明されているライセンス・プログラムまたはその他のライセンス資料は、IBM 所定のプログラム契約の契約条項、IBM プログラムのご使用条件、またはそれと同等の条項に基づいて、IBM より提供されます。

この文書に含まれるいかなるパフォーマンス・データも、管理環境下で決定されたものです。そのため、他の操作環境で得られた結果は、異なる可能性があります。一部の測定が、開発レベルのシステムで行われた可能性がありますが、その測定値が、一般に利用可能なシステムのものと同じである保証はありません。さらに、一部の測定値が、推定値である可能性があります。実際の結果は、異なる可能性があります。お客様は、お客様の特定の環境に適したデータを確かめる必要があります。

IBM 以外の製品に関する情報は、その製品の供給者、出版物、もしくはその他の公に利用可能なソースから入手したものです。IBM は、それらの製品のテストは行っておりません。したがって、他社製品に関する実行性、互換性、またはその他の要求については確証できません。IBM 以外の製品の性能に関する質問は、それらの製品の供給者にお願いします。

IBM の将来の方向または意向に関する記述については、予告なしに変更または撤回される場合があり、単に目標を示しているものです。

本書には、日常の業務処理で用いられるデータや報告書の例が含まれています。より具体性を与えるために、それらの例には、個人、企業、ブランド、あるいは製品などの名前が含まれている場合があります。これらの名称はすべて架空のものであり、名称や住所が類似する企業が実在しているとしても、それは偶然にすぎません。

この情報をソフトコピーでご覧になっている場合は、写真やカラーの図表は表示されない場合があります。


このソフトウェア・オファリングは、展開される構成に応じて、セッションごとのCookie および持続的な Cookie を使用して、それぞれのお客様に関する以下の情報を収集する場合があります。

v 名前

v ユーザー名

v パスワード

その目的は、以下のとおりです。

v セッション管理

v 認証 (authentication)

v お客様の利便性の向上

v シングル・サインオン構成

v セッション管理、認証、お客様の利便性の向上およびシングル・サインオン構成以外の利用の追跡または機能上の目的

これらの Cookie を無効にすることはできません。

この「ソフトウェア・オファリング」が Cookie およびさまざまなテクノロジーを使用してエンド・ユーザーから個人を特定できる情報を収集する機能を提供する場合、お客様は、このような情報を収集するにあたって適用される法律、ガイドライン等を遵守する必要があります。これには、エンド・ユーザーへの通知や同意の要求も含まれますがそれらには限られません。

このような目的での Cookie を含む様々なテクノロジーの使用の詳細については、IBM のプライバシー・ポリシー (https://www.ibm.com/privacy/us/en/) を参照してください。

特記事項 489

https://www.ibm.com/privacy/us/en/

索引

日本語, 数字, 英字, 特殊文字の順に配列されています。なお, 濁音と半濁音は清音と同等に扱われています。

［ア行］あいまいなオブジェクト 430あいまいな関係 403アクセス

保護された InfoCube 216アップグレード

セグメント化されたプロジェクト 446モデル 11, 437リンクされたプロジェクト 446IBM Cognos ReportNet モデル 438

アドバイザー、モデルの 207移行

モデル 327移植性 327一意に識別される行列式 94, 96一意のキー 442一意の識別子 94

オブジェクト 23一意のレベル 119一重引用符 180一致するスター・スキーマ・グループ 416一致するディメンション 416

作成 99複数のファクト 421, 426

移動

プロジェクト 317メタデータ 316

インポート

関係 72重複オブジェクト名 46データベース 47データ・ソース 56データ・ソースからのメタデータ 39メタデータを Framework Manager に 46リレーショナル・メタデータ 79リレーショナル・メタデータの変換テーブル 144Architect XML ファイル 52DecisionStream 52IBM Cognos モデル 51Impromptu XML ファイル 52SAP BW 階層 218SAP BW メタデータ 216, 221SAP HANA メタデータ 49XML ファイルからのメタデータ 69

インポートしたメタデータ

チェック 403インポート・ビュー 71引用符 180

式 180マクロ 180

引用符を使用する

式 270マクロ 270

埋め込み文字列を使用する

式 270マクロ 270

永続的なモデル 204クエリー・アイテムの名前変更 319

「エクスプローラー」タブ 16エクスプローラー・ダイアグラム 30エクスプローラー・ツリー 29エクスポート

変換テーブル 143CWM ファイル 463CWM ファイルとしてのメタデータ 323

エスケープ記号 180エラー

修復 278エラー・メッセージ

QE-DEF-0177 461QE-DEF-0259 462UDA-SQL-0107 461UDA-SQL-0114 461XQE-PLN-0309 377

オブジェクト

一意の識別子 23検索 21再マップ 322探索 16, 17, 30並べ替え 16プロパティー 18命名規則 23

オブジェクトの再マップ 322オブジェクトのソート 16オブジェクトの並び替え 16オブジェクト・セキュリティー 282

計算 287削除 286ショートカット 287探索 301追加 286フィルター 287モデル・クエリー・サブジェクト 287

オプションのカーディナリティー 75, 382オプションの関係 74


オプション・プロンプト 184

［カ行］カーディナリティー

規則 75, 382クエリー 75, 382混合 207再定義 77タイプ 75, 382チェック 403データ・ソース 74ディメンションとファクト 403表記 74ファクト 2071-1 4241-n 424

カーディナリティーの規則 382解決

あいまいなオブジェクト 430分割されているクエリー 431

階層 384, 388, 442均衡 123, 226時間依存 219ネットワーク 125, 229バージョン化 219バランスのとれていない 124, 227標準ディメンション 122, 225不規則 125, 228複数 412役割の指定 128, 129SAP BW 218

概念 381外部化されたディメンション

プロンプト 462外部化する

クエリー・サブジェクト 291, 294数値データ・ディメンション 477特性ディメンション 477モデル・クエリー・サブジェクト 476Framework Manager の要件 479InfoCube キー数値 477SAP BW クエリーのキー数値 477, 480SAP BW クエリーの要件 478SAP BW ディメンション 467

外部キー 79外部結合 74, 79, 338

完全 74, 461Analysis Studio 76Oracle 464

加算 155, 247カスタム関係式 77カスタム・プロパティー

SAP BW 254カタログ 353

カテゴリー

検証の 278ガバナー

外部結合 339外部データ・ソースの最大数 345行列式属性の SQL 生成 342クエリー実行時間の限度 339最大外部データ行カウント 345最大外部データ・ファイル・サイズ 345実行時の拡張モデル移植性を許可 343取得した行の最大数 338ショートカット処理 340数値属性のグループ化 341製品を超えた結合 340設定 338ディメンション情報の動的生成を許可 344動的クエリー・モード 360発行時にモデル全体を処理 345レベル属性の SQL 生成 341レポート・テーブルの最大数 338ローカル・キャッシュの使用を許可 344, 347IBM Cognos ReportNet アップグレード 438SAP BW データ・ソースの Null 値を消去 344SQL 結合構文 340SQL 生成時に WITH 節を使用 344SQL パラメーター構文 343

環境

Framework Manager 6関係

あいまいな 403インポート 72カーディナリティー 73, 382カスタム 77行列式 207検出 79検証 72再帰的および帰納的 207細分性のレベル 408作成 78ショートカット 79, 199生成 79多対 1 73多対多 73, 74チェック 72, 403定義 72範囲 132複雑な式 77複数 207複数の有効な 404, 407変更 77変更する 770-1 730-n 731 対 1 731 対多 731-1 73


関係 (続き)

1-n 73, 424n-n 73Oracle Designer から 67

関係編集モード 32監査 303, 319関数

プロジェクト 350関数セット

追加 281, 350定義する 350

関数セット ID 353完全外部結合 74, 461

Oracle 464管理

パッケージ 286, 301, 302プロジェクト 301, 316, 327

関連オブジェクト 99, 134, 234キー 119, 224, 442

カーディナリティー 74外部 79役割 230, 232役割の指定 128, 129レベルの 1261 次 79

キー数値 216構造 218プロンプト 462変更する 233Framework Manager へのマッピング 222

キーボード・ショートカット 457規則

カーディナリティー 75ビジネス 166ビジネス、SAP BW メタデータの 261SAP BW メタデータの集計 244

帰納的関係 207, 408キャッシュ

メモリー内 370キャッシュされたメタデータ 207キャッシュ・データ 338

再使用 347キャッシュ・データの再使用 347キューブ 353共有ディメンション 400行列式 94

一意に識別 94, 96カーディナリティー 74関係 207クエリー・サブジェクト 395指定 94, 96定義する 384ディメンション情報から変換 442SQL 生成 97

行列式属性の SQL 生成

ガバナー 342

均衡階層 123, 226クエリー

スティッチ 403単一ファクト 419ファクトのない 416複数細分性 388複数ファクト 388, 421, 426分割 431

クエリー、SAP BWFramework Manager へのマッピング 222

クエリー処理 347, 353選択 347

クエリーの再使用 347クエリー・アイテム

数値データから変換 130定義 9プロパティー 18変換 132, 165


外部化 291, 294行列式 207, 395, 442組み込みファイル 291, 294検索する 21混合カーディナリティー 207最小化された SQL 207スター・スキーマ・グループ 415セキュリティー 285タブ・ファイル 291, 294探索 16, 17, 30定義 8ディメンション 207, 388ディメンションに変換 442テスト 67トランザクション・モード 349ファクト 207複数の関係 207プロパティー 18csv ファイル 291, 294DB2 461Impromptu クエリー定義ファイル 294Model Design Acclerator を使用する構築 36SAP BW 440Transformer ファイル 294

クエリー・サブジェクト・ダイアグラム 32クエリー・タイプ 353クエリー・マクロ

プロンプトの作成に使用する 184組み込みファイル 291, 294組み込み文字列 180

式 180マクロ 180

クリア

オブジェクト・セキュリティー 286グループ

スター・スキーマ 192追加 283

索引 493

ゲートウェイ

URI にアクセスできない 460計算

処理の順序 398セキュリティー 287説明不能な数値の不一致 464リレーショナル・メタデータ用に作成する 166SAP BW メタデータの作成 261

計算されたキー数値 216計算集計

リレーショナル・メタデータ 152計算集計タイプ 207, 398計算の集計 398計算の処理 398計算の処理の順序 398結合 72

オーバーライド 32外部 74, 76完全外部 74, 461削除 32作成 32内部 74, 79, 463フィルターを適用した最適化 375変更する 32, 77ループ 407Oracle 464

結合クエリー・セット 99言語

多言語環境のセットアップ 138パッケージの指定 290リレーショナル・メタデータの追加 142リレーショナル・メタデータの定義 142SAP BW クエリーの言語が間違っている 461

検索

オブジェクト 21検索する

オブジェクト 19, 21検索プロンプト 160, 161, 249, 250検出

関係 79検証

関係 72パッケージ 278モデル 278リレーショナル・クエリー・サブジェクト 107IBM Cognos ReportNet モデル 438, 441SAP BW クエリー・サブジェクト 240

交差クエリー・セット 99更新

クエリー・サブジェクト 108モデル・バージョン 294

構造

SAP BW 218構文

BmtScriptPlayer 329

コピー

プロジェクト 317コメント

SQL への追加 110コンテキスト・エクスプローラー 99, 134, 234

［サ行］再帰的関係 207, 408最小カーディナリティー 75, 382最小化された SQL 117, 207

モデル・クエリー・サブジェクト 118再生

操作ログ 329最大カーディナリティー 75, 382最大行数 338細分性 408削除

オブジェクト・セキュリティー 286プロジェクト 318

作成 323クエリー・マクロでプロンプトを 184数値データ・ディメンション 414スター・スキーマ・グループ 415セグメント 313ネームスペース 69パッケージ 281標準ディメンション 412プロジェクト 9, 34分岐 307リレーショナル・メタデータの数値データ・ディメンション

130リレーショナル・メタデータの数値データ・フォルダー 203リレーショナル・メタデータの関係 78リレーショナル・メタデータの関係のショートカット 79リレーショナル・メタデータのクエリー・アイテム・フォル

ダー 203リレーショナル・メタデータのクエリー・サブジェクト 86,

88, 92リレーショナル・メタデータのクエリー・セット 99リレーショナル・メタデータの計算 166リレーショナル・メタデータのディメンション 118, 119,

128, 129リレーショナル・メタデータのネームスペース 201リレーショナル・メタデータのパラメーター・マップ 175リレーショナル・メタデータの標準ディメンション 119,

133リレーショナル・メタデータのフィルター 169リレーショナル・メタデータのフォルダー 201リンク 314SAP BW メタデータのクエリー・サブジェクト 238SAP BW メタデータの計算 261SAP BW メタデータのディメンション 224SAP BW メタデータのネームスペース 273SAP BW メタデータのパラメーター・マップ 268SAP BW メタデータのフィルター 263


作成 (続き)

SAP BW メタデータのフォルダー 273サポートされている環境

多言語 138サポートする

複数ユーザー 303散在データ

準加算数値データ 157散在データと Analysis Studio 76サンプル・モデル 25時間制限 338時間のプロンプト 160, 161, 249, 250式

インポートされる 67カスタム 77関係 77中括弧 462プロンプトの使用 160

式エディター

値の検索 466関数セット 350

式の中括弧 462識別子

一意の 94自己結合 207自動集計 346自動集計タイプ

リレーショナル・メタデータ 153SAP BW メタデータ 246, 247

自動的に保存

オプション 14自動保存

オプション 14集計 384

タイプ 247表示 20リレーショナル・メタデータの規則 150, 152, 153, 155リレーショナル・メタデータのタイプ 155SAP BW メタデータの規則 244, 246, 247

集計規則 157「集計規則」プロパティー

リレーショナル・メタデータ 150集計クエリー

モデル内での作成 376集計処理 346, 353集計タイプ

算出 207修正

失敗したトランザクション 309従属関係、オブジェクト 321従属関係、レポート 320従属関係の表示 321修復

IBM Cognos ReportNet モデル 441準加算 158準加算数値データ 157, 248

準集計プロパティー 158SAP BW メタデータ 244, 248

ショートカット 395セキュリティー 287動作 338, 340

使用

複数のデータ・セット 324複数のデータ・ソース接続 41

消去

マルチエッジ 291Null 371null 291

消去オプション 291条件付きクエリー・サブジェクト 175, 268詳細度

設定 17, 33詳細なキー数値 468詳細なファクト・クエリー・サブジェクト 468使用方法プロパティー

リレーショナル・メタデータ 150, 154SAP BW メタデータ 244, 246

新機能 1図 11

設定 17, 33表示 17, 30, 32

数値属性のグループ化

ガバナー 341数値データ

クエリー・アイテムに変換 130計算集計タイプ 207準加算 157変換 132, 165IBM Cognos 8 Planning 468IBM Cognos Analytics のアップグレード 440

数値データの範囲の問題 132数値データ・ディメンション 400

作成 414ロールプレイング 404SAP BW の外部化 477

数値データ・フォルダー 203スキーマ 353スクリプト

累積 298スクリプト・ファイル

エラーの修正 332スター・スキーマ

グループ化 192複数 194Model Design Accelerator を使用して作成する 35Model Design Accelerator を使用する管理 37

スター・スキーマの概念 410スター・スキーマ・グループ 400

作成 415複数の一致する 416

スター・ディメンション 197スティッチ・クエリー 403

索引 495

ストアード・プロシージャー

データ・クエリーによるデータベースの更新 92トランザクション・アクセス・モード 377

ストアード・プロシージャー・クエリー・サブジェクト 89更新 108作成 92定義 8評価 107変更する 92例 93Composite 90Informix 89

スナップ・オプション

設定 17, 33スノーフレーク・データ・ソース 410スノーフレーク・ディメンション 197すべて結合クエリー・セット 99すべて交差クエリー・セット 99すべて排他クエリー・セット 99正演算子 180正規化されたデータ・ソース 410制御

アクセス 282SQL 生成 338

制限

セグメント化 312マクロ 183リンク 312

制限する

アクセス 282取得データ 338BLOB 339

生成

関係 79Model Design Accelerator を使用するモデルの生成 36

製品を超えた結合 338セキュリティー

タイプ 282探索 301パッケージ 281, 289フィルター 285レベル 463CSVIdentityName 関数 285CSVIdentityNameList 関数 286

セグメント 310使用に関する推奨事項 311

セグメント化

制限 312プロジェクト 313

セグメント化されたプロジェクト 310, 313, 446移動 317コピー 317削除 318同期する 335

セッション・パラメーター

リレーショナル・メタデータのための変更 178

セッション・パラメーター (続き)

SAP BW メタデータのための変更 270接続

クエリー・サブジェクト 99ディメンション 134, 234

設定

ガバナー 338消去 291詳細度 17, 33スナップ・オプション 17, 33テスト 105, 136, 236表記 17, 33フォント 17, 33

説明不能な数値の計算 464選択

クエリー処理 347ソート

オブジェクト 19概要 372レベル 126members 126

操作ログ 327バッチ・モードでの実行 329

属性 118, 119, 128, 129, 224, 230, 232, 442

［タ行］「ダイアグラム」タブ 17大括弧 180大規模テキスト・アイテムの上限 339多言語

データの使用 138データ・ソース 140

多言語モデル作成

パッケージ 290パラメーター 141リレーショナル・メタデータ 138リレーショナル・メタデータの例 144

多言語レポート 139多言語レポート環境

設定 138多次元

クエリー・サブジェクト 237タスク

表示 20多対 1 の関係 73多対多の関係 74タブ・ファイル 291, 294単一ファクト・クエリー 419探索

オブジェクト 16, 17, 30オブジェクト・ベースのセキュリティー 301クエリー・サブジェクト 99ディメンション 118, 134, 224, 234パッケージ 301役割 301


地域の設定

多言語環境のセットアップ 138チェック

関係 72プロジェクト 278

中括弧 180重複値を除くデータの個数 150重複オブジェクト名

インポート 46追加

オブジェクト・セキュリティー 286関数セット 350グループ 283データ・ソース関数 350パッケージへの言語 290役割 283ユーザー 283リレーショナル・メタデータの言語 142リレーショナル・メタデータのビジネス・ルール 166SAP BW メタデータのビジネス・ルール 261

通貨

表示形式 159, 248データ

セキュリティー 282, 285多言語の使用 138リレーショナル・メタデータの形式設定 159SAP BW メタデータの形式設定 248

データ型 439グラフィック 461

データ形式

小数点の形式の記号 455日時の記号 448パターンを使用する 447

データ抽出

変数を使用するための SAP BW のガイドライン 471データベース

インポート 47データベース関数

ベンダー固有 350データベースのみ 347データベース・レイヤー 71データ・ウェアハウス

関係 72データ・ソース 39

関数の追加 350ストアード・プロシージャーによる更新 92接続 44接続レベル 42多言語 140他のメタデータ・ソース 56プロパティー 230, 347プロパティーの変更 353メタデータのインポート 39リレーショナル・データベース 47Architect XML ファイル 52DecisionStream 52

データ・ソース (続き)

ERwin 56IBM Cognos モデル 51IBM DB2 Cube Views 56Impromptu XML ファイル 52Microsoft Analysis Server 47Microsoft SQL Server 47Oracle Designer 67Oracle パッケージ 47SAP BW 216XML ファイル 69

データ・ソース関数

追加 350データ・ソース接続

作成 44動的クエリー・モード 357分離レベル 42OLAP キューブ 40

データ・ソース・クエリー・サブジェクト

作成 86定義 8

テーブルの比較 99定義する

関数セット 350プロンプト・コントロール 160リレーショナル・メタデータの言語 142SAP BW メタデータのプロンプト・コントロール 249

ディメンション

あいまいな 430階層 412共有 400クエリー・サブジェクト 388クエリー・サブジェクトから変換 442検索する 21混合カーディナリティー 207作成 18識別 403準加算数値データ 157数値データ 400, 414スター・スキーマ・グループ 415探索 16, 17, 30定義 8標準 388, 395, 400, 412プロパティー 18変更する 18モデル (model) 388ロールプレイング 404SAP BW 467

ディメンション情報 442ディメンションを使用してモデル化されたリレーショナル・メ

タデータ

準加算数値データ 157ディメンション・クエリー 419

単一ファクト 419複数のファクトおよび細分性 421, 426

ディメンション・データ 410

索引 497

ディメンション・マップ 118, 119, 128, 129, 224「ディメンション・マップ」タブ 18ディメンション・モデル

スター・スキーマ 192テキストの表示形式 159, 248テキスト・ボックスのプロンプト 160, 161, 249, 250適用

リレーショナル・メタデータのフィルター 172SAP BW メタデータのフィルター 266

テスト

クエリー・サブジェクト 67, 461設定の変更 105, 136, 236プロジェクト 278プロンプト 165, 254リレーショナル数値データ・ディメンション 134リレーショナル標準ディメンション 134リレーショナル・クエリー・サブジェクト 103リレーショナル・クエリー・セット 103SAP BW 数値データ・ディメンション 234SAP BW 標準ディメンション 234

デフォルト・データ・セット

設定 325同期する

エラーの修正 332クエリー・サブジェクト 108セグメント化されたプロジェクト 335プロジェクト 334メタデータ 334リンクされたプロジェクト 335

統計

表示 20動的クエリー・モード 294, 295, 338, 339, 340, 342

概要 355ガバナー 360考慮事項 359データ・ソース接続 357パッケージ 357プロジェクト 357

特性

Framework Manager へのマッピング 222特性構造 218特性ディメンション

外部化する 477トラブルシューティング 459トランザクション

再生 328修正 309モード 349

トランザクションの記録 327トランザクション履歴

表示 328トランザクション・アクセス・モード 349

ストアード・プロシージャー 377トランザクション・ステートメント・モード 349トレース

トランザクション履歴 328

ドロップダウン・リスト・プロンプト 160, 161, 249, 250

［ナ行］内部結合 74, 79, 463名前変更

関係 77プロジェクト 318

名前を付けて保存

プロジェクトのコピー 317二重引用符 180二重カウント 94, 403, 424, 430日本語文字

エクスポート・パス 463入力 SQL 461入力プロンプト 160, 161, 249, 250ヌル消去 291ネームスペース 6

作成 69定義 8リレーショナル・メタデータ用に作成する 201SAP BW メタデータの作成 273

ネイティブ SQL 115ネイティブ・メタデータ 40ネストされたパラメーター 175, 268ネットワーク階層 125, 229

［ハ行］バージョン化階層 219バージョン管理

モデル 294排他クエリー・セット 99パススルー SQL 115破損したレポート 298パッケージ 6

管理 286, 301, 302検証 278作成 281セキュリティー 282セキュリティーの変更 289多言語サポート 290探索 301定義 8動的クエリー・モード 357発行 277, 294複数のキューブを含む 296変更する 281変更の分析 319包含の表示 302Cognos Administration での作成 215, 294

パッケージの複数のキューブ 296パッケージの変更

影響の分析 319


発行

パッケージ 277, 294, 298メタデータ 277OLAP データ・ソースに基づくパッケージ 296

パフォーマンスの向上

キャッシュ・データの再使用 347パフォーマンスのチューニング

クエリー処理 347パラメーター

データ・ソース・クエリー・サブジェクト内 180バランスのとれていない階層 124, 227範囲の関係 118, 119, 128, 129, 132, 224番号記号

マクロ用に予約済み 180非加算 155, 247ビジネス・ビュー 71ビジネス・レイヤー 71日付

表示形式 159, 248プロンプト 161, 250

日付のプロンプト 160, 249必須のカーディナリティー 75必須プロンプト 184ビューとしての SQL 117

モデル・クエリー・サブジェクト 118評価

リレーショナル・クエリー・サブジェクト 107SAP BW クエリー・サブジェクト 240

表記 17, 33, 73, 74表示

関連オブジェクト 99, 134, 234集計 20図 17, 30, 32タスク 20統計 20パッケージ包含 302プロパティー 18モデル・オブジェクト 11, 29SQL 110

表示階層レベル

Framework Manager へのマッピング 222表示形式

通貨 159, 248テキスト 159, 248date 159, 248

表示形式の設定

リレーショナル・メタデータのデータ 159SAP BW メタデータのデータ 248

標準集計プロパティー 155リレーショナル・メタデータ 150SAP BW メタデータ 244, 247

標準ディメンション 388, 395, 400階層 412作成 412ロールプレイング 404

開く

プロジェクト 11ファクト 414

あいまいな 430カーディナリティー 207混合カーディナリティー 207識別 403集計規則 157

ファクト間クエリー 403ファクトのないクエリー 416ファクト表 130, 192ファクト・データ 411フィルター

オプション 172セキュリティー 285, 287必須 172

フォルダー

クエリー・アイテム 203作成 201, 203ショートカットの使用 197数値データ 203

フォント

設定 17, 33不規則な階層 125, 228複雑な式

関係 77複数細分性のクエリー 388, 421, 426複数の PowerCube への接続 41複数の階層 412複数の関係 207複数のデータ・セット 324

デフォルト・データ・セットの設定 325複数のデータ・ソース接続

使用 41複数の有効な関係 404, 407複数ファクトのクエリー 388, 421, 426複数ユーザー

モデル作成 303物理レイヤー 71プライマリー・キー 79ブリッジ・テーブル

説明 80モデル内での作成 377

プレゼンテーション・レイヤー 71プロジェクト 6

移動 317オプション 14関数 350管理 301, 316, 327コピー 317削除 318作成 9, 34ショートカット 314セグメント化 313定義 6同期エラーの修正 332

索引 499

プロジェクト (続き)

同期する 334動的クエリー・モード 357トランザクションの再生 328トランザクション履歴の表示 328名前変更 318開く 11ファイル 6分岐 303マージ 303リンク 314Framework Manager 6

プロジェクトのオブジェクト

命名規則 23プロジェクト・ビューアー 11プロジェクト・ページ 11プロパティー

カタログ 353関数セット ID 353キューブ 353クエリー処理 353クエリー・インターフェース 353クエリー・タイプ 353参照のカスケード 163, 252参照のフィルター 163, 252集計規則 150集計処理 353準集計 244使用 150, 244使用アイテム参照 163, 252スキーマ 353データ・ソース 347トランザクション・アクセス・モード 353トランザクション・ステートメント・モード 353パラメーター・マップ 353表示 18表示アイテム参照 163, 252標準集計 150, 244プロンプト情報 160, 249プロンプトのタイプ 161, 250変更する 18Content Manager データ・ソース 353SAP BW データ・ソース 230SAP BW 変数 230SAP BW メタデータの集計規則 244

プロンプト

オプション 184キー数値 462検索 160, 161, 249, 250作成 184参照のカスケード 163, 252参照のフィルター 163, 252時間 160, 161, 249, 250式 160使用アイテム参照 163, 252使用と表示に異なる値を指定 163, 252

プロンプト (続き)

ストアード・プロシージャーの例 93定義する 160, 249テキスト・ボックス 161, 249, 250テスト 165, 254ドロップダウン・リスト 160, 161, 249, 250入力 160, 161, 249, 250必須 184表示アイテム参照 163, 252プロパティー 160, 161, 249, 250マクロで作成 184例 187date 160, 161, 249, 250SAP BW 変数 254

プロンプト情報プロパティー 160, 249分割されているクエリー 431分岐

作成 307プロジェクト 303方法 304

分析

パッケージに対する発行の影響 319モデル 207問題 3

分離レベル 42別名

パラメーターと共に使用 175, 268変換

クエリー・アイテムを数値データに 165クエリー・サブジェクトをディメンションに 109数値データをクエリー・アイテムに 130, 132標準ディメンション 138モデル・クエリー・サブジェクトをデータ・ソース・クエリ

ー・サブジェクトに 109変換テーブル

インポート 144エクスポート 143

変更

メタデータ 316SQL のタイプ 111

変更する

関係 77クエリー・アイテム・プロパティー 19実行時に SQL を 184ストアード・プロシージャー・クエリー・サブジェクト 92セッション・パラメーター 178, 270パッケージ 281プロパティー 18リレーショナル・クエリー・サブジェクト 19リレーショナル・ディメンション 19リレーショナル・メタデータのクエリー・アイテム 146リレーショナル・メタデータのフィルター 169SAP BW メタデータのクエリー・アイテム 240SAP BW メタデータのフィルター 263

編集

SQL 110


変数

外部化するときに使用する 480ストアード・プロシージャー 93SAP BW 254SAP BW ファクト・データのガイドライン 471

ベンダー固有のデータベース関数 350方法

分岐 304保護された InfoCube

アクセス 216

［マ行］マージ

クエリー・サブジェクト、リレーショナル 98クエリー・サブジェクト、SAP BW 239標準ディメンション、リレーショナル 133プロジェクト 303

マクロ

作成 183使用 180制限 183プロンプト 180

マスター詳細テーブル 411, 414マッピング

リレーショナル・メタデータのパラメーター値 175SAP BW オブジェクトを Framework Manager に 222SAP BW メタデータのパラメーター値 268

マルチエッジ消去 291マルチユーザーのモデル作成 303丸め誤差 464未確定のパス 194命名規則

オブジェクト 23メインプロジェクト 313メタデータ

移動 316インポート 46エクスポート 323キャッシュされた 207セキュリティー 282同期する 334発行 277変更 316マージ 98, 239理解 301リレーショナル 71SAP BW 215

メタデータ・ウィザード 34メモリー不足エラー 459メンバー内で一意な名前

リレーショナル・メタデータ 125SAP BW メタデータ 230

メンバーの順序

概要 372モデル 6

モデル (続き)

アップグレード 11, 437検証 278サンプル 25耐久性 204定義 7バージョン管理 294, 299発行 277分析 207リレーショナルの準備 711 つのリレーショナル・データベースから別のリレーショナ

ル・データベースへの移行 327Model Design Accelerator を使用するモデルの生成 36SAP BW メタデータの準備 215

モデル移植性 327, 338「モデル警告」ビュー 33モデル作成

多言語 140データ・ソース 140分散モデル 303マルチユーザー 303メインプロジェクト 303

モデル作成上の問題 207モデルのアップグレード

警告 446モデルの修復 278モデルのバージョン管理 299モデルの文書化 303モデルの編成 191, 271モデル文書 303モデル・オブジェクト 11

ショートカット 395パラメーターの使用 175, 268表示 11, 29

モデル・クエリー・サブジェクト

外部化する 476セキュリティー 287定義 8

モデル・セッション・パラメーター

リレーショナル・メタデータ 178SAP BW メタデータ 270

モデル・バージョン

更新 294モデル・ビジネス・ビュー 191, 271

［ヤ行］役割

探索 301追加 283ディメンション 128, 129

ユーザー

追加 283パッケージ 281

ユーザー補助機能 457キーボード・ショートカット 457

索引 501

有効な関係

複数 404要約集計

リレーショナル・メタデータ 154予約記号

番号記号 180予約語 483

［ラ行］理解

メタデータ 301リセット

使用方法プロパティー 158標準集計プロパティー 158

リテラル文字列 180式 180マクロ 180

リテラル文字列を使用する

式 270マクロ 270

リレーショナル・データ・ソースのクエリー・サブジェクト

更新 108評価 107

リレーショナル・メタデータ 71インポート・ビュー 71クエリー・アイテム 146スター・スキーマ 192ビジネス・ビュー 71ビジネス・ルール 166

リレーショナル・メタデータの数値データ・ディメンション

作成 130探索 134範囲の関係 132

リレーショナル・メタデータのクエリー・アイテム

永続モデル機能 319集計規則 155使用 154名前変更 319フォルダー 203変更する 19, 146役割 128, 129

リレーショナル・メタデータのクエリー・サブジェクト

関係 72行列式 94, 96クエリー・セット 99更新 108作成 86, 88, 98ショートカット 199ストアード・プロシージャー 89タイプ 84探索 99データ・ソース 85ディメンションから変換 138テスト 103パラメーター・マップ 175

リレーショナル・メタデータのクエリー・サブジェクト (続き)

評価 107変換 109変更する 19, 92モデル (model) 87SQL 84SQL の生成 117SQL のタイプの変更 111SQL の編集 110

リレーショナル・メタデータのクエリー・セット

作成 99テスト 103

リレーショナル・メタデータのショートカット

関係 79, 199使用 197ディメンションおよびクエリー・サブジェクト 199

リレーショナル・メタデータのデータ・ソース・クエリー・サ

ブジェクト 85行列式 94, 96パラメーターの使用 180

リレーショナル・メタデータのディメンション 118, 192階層 122キー 126均衡階層 123クエリー・サブジェクトから変換 109ショートカット 199数値データ 130スノーフレーク 197探索 134ディメンション・マップ 118, 119, 128, 129テスト 134ネットワーク階層 125バランスのとれていない階層 124範囲の関係 132標準 119不規則な階層 125変換 138変更する 19マージ 133役割 128, 129レベル 122, 125

リレーショナル・メタデータのディメンション・モデルを作成

する 412リレーショナル・メタデータのパラメーター

作成 175使用 180セッション 178多言語モデル作成 141データ・ソース・クエリー・サブジェクト 180ネストされた 175別名 175モデル・オブジェクト 175

リレーショナル・メタデータのパラメーター・マップ

検索テーブルとして使用 138作成 175

リレーショナル・メタデータのビジネス・ビュー 191


リレーショナル・メタデータのビジネス・ビュー (続き)

ショートカット 197, 199ショートカットと関係 199ネームスペース 201フォルダー 201

リレーショナル・メタデータのビジネス・ルール 166計算 166セッション・パラメーター 178パラメーター 180パラメーター・マップ 175フィルター 169プロンプト 160マクロ 180

リレーショナル・メタデータの標準ディメンション 119階層 122探索 134範囲の関係 132変換 138マージ 133レベル 122, 125

リレーショナル・メタデータのフィルター

オプション 169クエリー・サブジェクトへの適用 172作成 169使用法の決定 172必須 169複数のクエリー・アイテム 19複数のクエリー・サブジェクト 19複数のディメンション 19変更する 169

リレーショナル・メタデータのモデル・クエリー・サブジェク

ト 87既存のオブジェクトからの作成 98行列式 94, 96作成 88SQL タイプ 118

リレーショナル・メタデータの例

多言語モデル作成 144パラメーター・マップ 177プロンプト 187filter 174in_range 関数 169

リレーショナル・モデル

移行 327リレーショナル・モデル作成の概念 381リンク 310

作成 314制限 312

リンクされたプロジェクト 310, 446同期する 335

ループ結合 403, 407レイヤー 71レベル 118, 122, 224, 225, 230, 232, 442

セキュリティー 463レベル属性の SQL 生成

ガバナー 341

レポート

従属関係 320多言語 139モデルに対する変更を表示しない 299

レポート作成要件 3レポートではなく、モデルでの変更 299ローカルのみ 347ローカル・クエリー処理

集計処理 346ロール・プレイング・ディメンション 207, 404ログ・ファイル 327

エントリーのアーカイブ 334再生 328

ロケール、

参照：言語

［数字］1 対 1 の関係 73, 4241 対多の関係 73, 4242 進数の丸め誤差 464

AAnalysis Studio と散在データ 76Architect XML ファイル

インポート 52

BBLOB 339BmtScriptPlayer

構文 329

CCLOB

Oracle 459Cognos PowerCubes

参照： IBM Cognos PowerCubesCognos SQL 113Common Warehouse Metamodel 323

エクスポート 463Composite ストアード・プロシージャー 90Content Manager データ・ソース 353Crowsfeet 表記 17, 33csv ファイル 291, 294CSVIdentityName 関数 285CSVIdentityNameList 関数 286CWM,

参照： Common Warehouse Metamodel

索引 503

DDB2 461DB2 キューブのビュー

インポートされる式 67DecisionStream

インポート 52DMR (ディメンションを使用してモデル化されたリレーショナ

ル) メタデータ 412

EERWin メタデータ

メモリー不足エラー 459Event Studio

ストアード・プロシージャー 92

FFramework Manager

プロジェクト 6

GGRAPHIC データ型 461

IIBM Cognos 8 Planning と SAP BW データ 468IBM Cognos PowerCubes

発行 296IBM Cognos モデル

インポート 51IBM のユーザー補助機能のページ 459Impromptu XML ファイル

インポート 52Impromptu クエリー定義ファイル 294InfoCube

メタデータへのアクセス権限 216Framework Manager へのマッピング 222

InfoCube キー数値

外部化する 477Informix

関数 89ストアード・プロシージャー 89

in_range 関数 169, 263IQD

ファイル 294

Llevels

一意の 119ソート 126標準ディメンション 125, 230

levels (続き)

メンバー内で一意な名前 125, 230役割の指定 128, 129

Mmembers

ソート 126Merise 表記 17, 33Microsoft

SQL Server データ・ソース 47Microsoft Analysis Server

データ・ソース 47Model Accelerator 31Model Advisor 207Model Design Accelerator 29

エクスプローラー・ダイアグラム 30エクスプローラー・ツリー 29関係編集モード 32クエリー・サブジェクトの構築 36クエリー・サブジェクト・ダイアグラム 32結合 32スター・スキーマの管理 37スター・スキーマの作成 35ダイアグラムの色 30ダイアグラムの設定 33プロジェクトの作成 34メタデータ・ウィザード 34「モデル警告」ビュー 33モデルの生成 36Model Accelerator 31

MultiCubeFramework Manager へのマッピング 222

NNull

消去 371Null 値

SAP BW 338

OOLAP キューブ

データ・ソースとして 40OLAP データ・ソース

発行 296Oracle

完全外部結合 464Designer 67

Oracle 完全外部結合 461Oracle パッケージ

データ・ソース 47


PPowerCube

複数のデータ・ソースへの接続 41Framework Manager のガイドライン 481SAP BW データから作成 481Transformer ガイドライン 481

QQE-DEF-0177 461QE-DEF-0259 462

RRemoteCube

Framework Manager へのマッピング 222

SSAP BW

カスタム・プロパティー 254キー数値のインポート 216クエリーの言語が間違っている 461ファクト・データを使用するためのガイドライン 471Transformer 476

SAP BW クエリー

メタデータへのアクセス権限 216SAP BW クエリーのキー数値

外部化する 477SAP BW クエリー・サブジェクト 440SAP BW 構造 218SAP BW データ

Cognos Planning 468SAP BW ディメンション 467SAP BW 変数 230, 254SAP BW メタデータ 215

インポート 216SAP BW メタデータの数値データ・ディメンション

探索 234SAP BW メタデータのクエリー・アイテム

集計 247集計規則 247使用 246表示形式の設定 248変更する 240役割 230, 232

SAP BW メタデータのクエリー・サブジェクト

作成 238, 239パラメーター・マップ 268評価 240モデル (model) 237

SAP BW メタデータのショートカット

使用 272ディメンション 273

SAP BW メタデータのディメンション 223階層 225キー数値 233均衡階層 226ショートカット 273ディメンション・マップ 224テスト 234ネットワーク階層 229バランスのとれていない階層 227標準 224不規則な階層 228役割 230, 232レベル 225, 230

SAP BW メタデータのパラメーター

作成 268セッション 270地図 268

SAP BW メタデータのパラメーター・マップ 268作成 268

SAP BW メタデータのビジネス・ビュー 271ショートカット 272ショートカットとディメンション 273ネームスペース 273フォルダー 273

SAP BW メタデータのビジネス・ルール 261計算 261フィルター 263

SAP BW メタデータの標準ディメンション 224階層 225探索 234レベル 225, 230

SAP BW メタデータのフィルター

作成 263使用法の決定 266適用 266変更する 263

SAP BW メタデータのフォルダー

作成 273ショートカットの使用 272

SAP BW メタデータのモデル・クエリー・サブジェクト 237既存のオブジェクトからの作成 239作成 238

SAP BW メタデータの役割

ディメンション 230, 232SAP BW メタデータの例

in_range 関数 263SAP HANA データ・ソース 49SQL 419

行列式 97クエリー・サブジェクト 84コメント 110最小化 117, 118, 207スタンドアロン・ネイティブ 110, 115生成タイプ 117タイプの変更 111内部結合 463

索引 505

SQL (続き)

ネイティブ 110, 115パススルー 110, 115ビューとして 117, 118編集 110モデル・クエリー・サブジェクト 118Cognos 110, 113

SQL 生成

制御 338SQL パラメーター構文

ガバナー 343

TTransformer

SAP BW 476Transformer およびクエリー・サブジェクト 294Transformer バージョン 7.x

外部化 CSV ファイル 476Transformer バージョン 8.x

外部化 CSV ファイル 476

UUDA-SQL-0107 461UDA-SQL-0114 461

URIサービスにアクセスできない 460

URL でサービスにアクセスできない 460

VVARGRAPHIC データ型 461

WWith 節 338

XXML ファイル

インポート 69XQE-PLN-0309

エラー 377


© copyright ibm corporation 2005, 2016

Documents