Comments
Description
Transcript
MicroStrategy プロジェクト デザイン ガイド
プロジェクト デザイン ガイド バージョン : 9.0.1 文書番号 : 09330901 バージョン 9.0.1、第 7 版（2010 年 12 月） お客様がライセンスを受けたソフトウェアに対応するドキュメントかどうかを確認するため、ご使用のソフトウェアの [ ヘルプ ] メ ニューにある [ バージョン情報 ] に表示されるソフトウェアのバージョンと、このバージョン番号を比較してください。 文書番号 : 09330901 Copyright © 2010 by MicroStrategy Incorporated.All rights reserved. お客様が、MicroStrategy または MicroStrategy の正規販売店と書面または電子的な文書による契約を交わしていない場合は、次の 条件が適用されます。 このソフトウェアおよびドキュメンテーションは、MicroStrategy Incorporated の所有物かつ機密情報であり、第三者に譲渡するこ とはできません。Copyright © 2001-2010 by MicroStrategy Incorporated.All rights reserved. このソフトウェアおよびドキュメンテーションは現状のまま提供され、MICROSTRATEGY INCORPORATED またはソフトウェア またはドキュメンテーションの作成、製造、配布に関わった個人による、あらゆる種類の明示的保証または限定保証はありません。 これには、特定目的への商品性および適合性、譲渡可能な権限と不侵害、品質または正確性に関する黙示の保証が含まれますが、こ れらに限定されるものではありません。このソフトウェアおよびドキュメンテーションの品質と性能に関するすべての損害は、お客 様の責任になります。ソフトウェアやドキュメンテーションの欠陥が判明した場合は、 （MICROSTRATEGY, INC.、あるいはソフト ウェアまたはドキュメンテーションの作成、製作、または配布に関わった個人ではなく）お客様が、必要なすべてのサービス、修 理、または訂正にかかる費用を全額負担するものとします。一部の国では黙示の保証の除外を認めていませんので、上記の除外はお 客様には適用されない場合があります。 いかなる場合でも、MicroStrategy, Inc. あるいはソフトウェアの作成、製作、または配布に関わった個人は、利益の損失、預貯金の 損失、その他の特殊な、付随的、結果的、懲罰的な損害賠償を含む、どのような損害の支払い請求についてもお客様に対して責任を 負いません。この損害には、ソフトウェアおよびドキュメンテーションの使用、使用の不可、品質、または性能のために、お客様が 課せられた損害またはお客様が第三者に支払った損害も含まれますが、限定はされません。これは、MicroStrategy, Inc. または前記 の関係者または団体が、そのような損害や第三者による請求の可能性を忠告されていた場合も同様です。さらに、MicroStrategy, Inc. またはソフトウェアの作成、製作または配布に関わった個人は、契約保証、過失、補償または負担の怠慢についての厳格責任、本来 の目的を達成するための修正の不履行の原則、あるいはその他に基づき、ソフトウェアおよびドキュメンテーションの使用、使用不 可、品質、または性能により発生した損害についてのお客様または第三者からの請求に責任を負いません。MicroStrategy, Inc. の全 責任およびお客様の唯一の救済措置は、MicroStrategy, Inc. の選択により、購入額の全額返金またはソフトウェアの交換に限られま す。提供された口頭または書面の情報により、MicroStrategy, Inc. の責任が上記の責任の限度で指定された範囲よりも拡張されるこ とはありません。一部の国では、付随的または結果的な損害に対する責任の限定または除外は認められていませんので、上記の制限 がお客様に適用されない場合があります。 このマニュアル（ドキュメンテーション）およびソフトウェアに含まれる情報は、著作権で保護されており、すべての権利は MicroStrategy, Inc. が所有しています。MicroStrategy, Inc. は、個人または団体に通知する義務を負うことなく、ソフトウェアまたは ドキュメンテーションを定期的に変更する権利を留保します。MicroStrategy, Inc. の正式代表者の書面による事前の許可なしに、ソ フトウェアまたはドキュメンテーションの一部をコピー、複製、販売、またはその他の方法で配布することは禁止されています。米 国政府の制限付き権利。このソフトウェアとドキュメンテーションは民間の費用で開発されたこと、いずれの部分も公有財産ではな いこと、またこのソフトウェアとドキュメンテーションは、連邦調達規則およびそれに対する政府機関による補足に従った制限付き 権利を伴って提供される商業コンピュータ ソフトウェアであることが認識されています。米国政府による使用、複製または情報開 示は、DFAR 252.227-7013 の「Rights in Technical Data and Computer Software」条項の (c)(1)(ii) 項およびそれ以下、または FAR 52.227-19 の「Commercial Computer Software--Restricted Rights」条項の (c)(1) および (2) 項で規定されている制限のうち該当する ものの対象になります。契約者は、1861 International Drive, McLean, Virginia 22102 所在の MicroStrategy, Inc. です。ソフトウェア の未公開部分に関する権利は、米国著作権法のもとで保護されています。 以下は、MicroStrategy Incorporated の米国および他の特定の国における商標または登録商標です。 MicroStrategy、MicroStrategy 6、MicroStrategy 7、MicroStrategy 7i、MicroStrategy 7i Evaluation Edition、MicroStrategy 7i Olap Services、MicroStrategy 8、MicroStrategy 9、MicroStrategy Distribution Services、MicroStrategy MultiSource Option、MicroStrategy Command Manager、MicroStrategy Enterprise Manager、MicroStrategy Object Manager、MicroStrategy Reporting Suite、MicroStrategy Power User、MicroStrategy Analyst、MicroStrategy Consumer、 MicroStrategy Email Delivery、MicroStrategy BI Author、MicroStrategy BI Modeler、MicroStrategy Evaluation Edition、MicroStrategy Administrator、 MicroStrategy Agent、MicroStrategy Architect、MicroStrategy BI Developer Kit、MicroStrategy Broadcast Server、MicroStrategy Broadcaster、 MicroStrategy Broadcaster Server、MicroStrategy Business Intelligence Platform、MicroStrategy Consulting、MicroStrategy CRM Applications、MicroStrategy Customer Analyzer、MicroStrategy Desktop、MicroStrategy Desktop Analyst、MicroStrategy Desktop Designer、MicroStrategy eCRM 7、MicroStrategy Education、 MicroStrategy eTrainer、MicroStrategy Executive、MicroStrategy Infocenter、MicroStrategy Intelligence Server、MicroStrategy Intelligence Server Universal Edition、MicroStrategy MDX Adapter、MicroStrategy Narrowcast Server、MicroStrategy Objects、MicroStrategy OLAP Provider、MicroStrategy SDK、 MicroStrategy Support、MicroStrategy Telecaster、MicroStrategy Transactor、MicroStrategy Web、MicroStrategy Web Business Analyzer、MicroStrategy World、Alarm、Alarm.com、Alert.com、Angel、Angel.com、Application Development and Sophisticated Analysis、Best In Business Intelligence、Centralized Application Management、Changing The Way Government Looks At Information、DSSArchitect、DSS Broadcaster、DSS Broadcaster Server、DSS Office、DSSServer、DSS Subscriber、DSS Telecaster、DSSWeb、eBroadcaster、eCaster、eStrategy、eTelecaster、Information Like Water、Insight Is Everything、Intelligence Through Every Phone、Your Telephone Just Got Smarter、Intelligence To Every Decision Maker、Intelligent E-Business、 IWAPU、Personal Intelligence Network、Personalized Intelligence Portal、Query Tone、Quickstrike、Rapid Application Development、Strategy.com、 Telepath、Telepath Intelligence、Telepath Intelligence (and Design)、MicroStrategy Intelligent Cubes、The E-Business Intelligence Platform、The Foundation For Intelligent E-Business、The Integrated Business Intelligence Platform Built For The Enterprise、The Intelligence Company、The Platform For Intelligent E-Business、The Power Of Intelligent eBusiness、The Power Of Intelligent E-Business、The Scalable Business Intelligence Platform Built For The Internet、Industrial-Strength Business Intelligence、Office Intelligence、MicroStrategy Office、MicroStrategy Report Services、MicroStrategy Web MMT、MicroStrategy Web Services、Pixel Perfect、MicroStrategy Mobile、MicroStrategy Integrity Manager、および MicroStrategy Data Mining Services はすべて、MicroStrategy Incorporated の登録商標または商標です。 その他のすべての製品は、それぞれの所持者の商標です。仕様は、予告なしに変更される場合があります。MicroStrategy は、誤りや欠落に関する責 任を負いません。MicroStrategy は、開発予定または開発中である将来の製品やバージョンの入手可能性について、一切保証や確約はいたしません。 特許情報 この製品は特許を受けています。本契約に基づき販売される製品に、以下の特許のうち 1 つ以上が、適用される可能性があります。米国特許番号 6,154,766、6,173,310、6,260,050、6,263,051、6,269,393、6,279,033、6,501,832、6,567,796、6,587,547、6,606,596、6,658,093、6,658,432、6,662,195、 6,671,715、6,691,100、6,694,316、6,697,808、6,704,723、6,707,889、6,741,980、6,765,997、6,768,788、6,772,137、6,788,768、6,792,086、6,798,867、 6,801,910、6,820,073、6,829,334、6,836,537、6,850,603、6,859,798、6,873,693、6,885,734、6,888,929、6,895,084、6,940,953、6,964,012、6,977,992、 6,996,568、6,996,569、7,003,512、7,010,518、7,016,480、7,020,251、7,039,165、7,082,422、7,113,993、7,181,417、7,127,403、7,174,349、7,194,457、 7,197,461、7,228,303、7,260,577、7,266,181、7,272,212、7,302,639、7,324,942、7,330,847、7,340,040、7,356,758、7,356,840、7,415,438、7,428,302、 7,430,562、7,440,898、7,457,397、7,486,780、7,509,671、7,516,181、7,559,048、および 7,574,376。その他は特許出願中です。 各種の MicroStrategy 製品に、第三者が著作権を所有するテクノロジが含まれています。この製品には、著作権で保護された以下のテクノロジーの 1 つ以上が含まれる可能性があります。 Graph Generation Engine Copyright © 1998-2010.Three D Graphics, Inc. All rights reserved. Actuate® Formula One.Copyright © 1993-2010 Actuate Corporation.All rights reserved. XML パーサ Copyright © 2003-2010 Microsoft Corporation.All rights reserved. Xalan XSLT プロセッサ。Copyright © 1999-2010.The Apache Software Foundation.All rights reserved. Xerces XML パーサ。Copyright © 1999-2010.The Apache Software Foundation.All rights reserved. FOP XSL フォーマッティング オブジェクト。Copyright © 2004-2010.The Apache Software Foundation.All rights reserved. Intelligence Server メモリ管理の一部 Copyright 1991-2010 Compuware Corporation.All rights reserved. この製品には、OpenSSL Toolkit での使用のための OpenSSL プロジェクトによって開発されたソフトウェアが含まれます。 （http://www.openssl.org/） International Components for Unicode Copyright © 1999-2010 Compaq Computer Corporation Copyright © 1999-2010 Hewlett-Packard Company Copyright © 1999-2010 IBM Corporation Copyright © 1999-2010 Hummingbird Communications Ltd. Copyright © 1999-2010 Silicon Graphics, Inc. Copyright © 1999-2010 Sun Microsystems, Inc. Copyright © 1999-2010 The Open Group All rights reserved. Real Player および RealJukebox は、Real Networks, Inc. からライセンスの許可に基づいて含まれています。Copyright © 1999-2010.All rights reserved. 目次 ガイドの説明 .............................................................................. xiii このガイドについて..................................................................................... xv ビジネス シナリオと例の探し方....................................................... xv このガイドでの新規内容.....................................................................xvi 前提条件...................................................................................................xvii このガイドの対象読者 ........................................................................xvii リソース......................................................................................................... xviii ドキュメンテーション ....................................................................... xviii トレーニング.........................................................................................xxvi コンサルティング ................................................................................xxvi 国際化サポート ................................................................................... xxvii テクニカル サポート.......................................................................... xxvii ご意見 ........................................................................................................... xxxiii 1. MicroStrategy プラッ はじめに ........................................................................................ 1 トフォームの BI アーキ ビジネス インテリジェンスのアーキテクチャ ..................................... 2 テクチャ データ収集のソース システム ............................................................. 3 抽出、変換、およびロードのプロセス ............................................ 4 データ ウェアハウスのデータ格納とリレーショ ナル設計...................................................................................................... 5 MicroStrategy プラットフォーム .................................................................... 7 MicroStrategy メタデータ .......................................................................... 9 MicroStrategy Intelligence Server ................................................................ 11 MicroStrategy Desktop................................................................................. 12 MicroStrategy Web および MicroStrategy Web Universal......................... 13 MicroStrategy プロジェクト.................................................................... 14 MicroStrategy Architect................................................................................ 16 © 2010 MicroStrategy, Inc. v 目次 プ ロ ジ ェ ク ト デザ イ ン ガ イ ド プロジェクトのデザイン プロセス ......................................................... 16 2. 論理データ モデル ビジネス モデルとレポート 対象データの概念化 はじめに ...................................................................................... 19 論理データ モデルの概要 ........................................................................... 20 ファクト : ビジネスのデータと測定値................................................... 22 アトリビュート : データのレベルを表すコンテキスト .................... 24 アトリビュート エレメント : データのレベル値 ......................... 25 アトリビュート関係.............................................................................. 26 階層 : データ関係の組織化......................................................................... 26 データ モデルの一例.................................................................................... 27 論理データ モデルの作成 ........................................................................... 28 ユーザのニーズ ...................................................................................... 28 既存のソース システム ........................................................................ 29 ソース データから分析データへの変換 ......................................... 30 論理データ モデルの表記法....................................................................... 35 一意の識別子........................................................................................... 36 カーディナリティと比率..................................................................... 37 アトリビュート フォーム.................................................................... 38 3. 論理データ モデルの ウェアハウスの構造 物理ウェアハウス スキーマ はじめに ...................................................................................... 41 列 : データの識別子と値 ............................................................................. 43 テーブル : 関連するデータの物理的なグループ化............................. 43 キー構造によるテーブル内のデータの一意な識別 .................... 44 ルックアップ テーブル : アトリビュートの格納場所 ................ 45 関係テーブル : アトリビュート間の関係付けの特殊 なケース.................................................................................................... 47 ファクト テーブル : ファクト データと集計レベル.................... 48 異種の列名と同種の列名..................................................................... 51 スキーマの種類 : データ呼び出しのパフォーマンスと 冗長格納........................................................................................................... 53 高度に正規化されたスキーマ : 最小限の格納領域...................... 54 中度正規化スキーマ : 格納領域とクエリ パフォー マンスのバランス .................................................................................. 56 高度に非正規化されたスキーマ : 高いクエリ パ フォーマンス........................................................................................... 58 デザインのバランス..................................................................................... 61 各種スキーマの比較..................................................................................... 62 vi © 2010 MicroStrategy, Inc. プ ロ ジ ェ ク ト デザ イ ン ガ イ ド 目次 データの国際化のサポート........................................................................ 63 テーブルと列またはデータベースを通じた国際化 .................... 64 データベース内のさまざまな文字セットのサポート ................ 69 4. プロジェクトの作成お よび構成 はじめに ...................................................................................... 71 プロジェクト作成の概要 ............................................................................ 72 プロジェクトの接続コンポーネント ...................................................... 74 MicroStrategy メタデータ ........................................................................ 75 メタデータ シェル ................................................................................. 75 プロジェクト ソース............................................................................. 75 データベース インスタンス ............................................................... 77 プロジェクト........................................................................................... 77 プロジェクト接続の要約..................................................................... 78 メタデータ リポジトリの作成 .................................................................. 78 メタデータ リポジトリとデータ ソースへの接続 .............................. 79 メタデータ リポジトリへの接続....................................................... 79 データ ソースへの接続 ........................................................................ 80 プロジェクトの作成..................................................................................... 81 実稼働プロジェクトの作成 ................................................................ 82 Project Builder によるテスト / プロトタイプ プロジェ クトの作成 ............................................................................................... 97 ファクトとアトリビュートの作成 .......................................................... 99 他のスキーマレベル設定の構成............................................................... 99 プロジェクトの配備とレポートの作成................................................ 100 5. Architect によるプロ ジェクトの作成 はじめに .................................................................................... 103 プロジェクトの作成と変更...................................................................... 104 プロジェクト作成 / 表示オプションの定義................................. 104 Architect によるプロジェクトの作成 ............................................... 116 Architect によるプロジェクトへの変更 ........................................... 120 テーブルの追加、削除、および管理 .................................................... 122 Architect でのデータ ソースの表示................................................... 123 テーブルの追加 .................................................................................... 124 テーブルの削除 .................................................................................... 126 テーブルの更新、変更、および管理............................................. 128 プロジェクト内のテーブルの編成 : レイヤー............................. 135 ファクトの作成と変更 .............................................................................. 136 ファクトの作成 .................................................................................... 137 複数のファクトの作成と変更 .......................................................... 140 © 2010 MicroStrategy, Inc. vii 目次 プ ロ ジ ェ ク ト デザ イ ン ガ イ ド アトリビュートの作成と変更 ................................................................. 149 アトリビュートの作成 ....................................................................... 150 複数のアトリビュートの作成と変更............................................. 153 アトリビュート関係の定義...................................................................... 173 システム ディメンション エディタの使用 .................................. 178 アトリビュート関係の自動定義...................................................... 179 ユーザ階層の作成と変更 .......................................................................... 181 ユーザ階層の作成 ................................................................................ 182 6. ビジネス データの構築 ブロック : ファクト はじめに .................................................................................... 185 ファクトの作成............................................................................................ 187 複数の単純なファクトの同時作成 ................................................. 188 単純なファクトと高度なファクトの作成および変更 .............. 191 ファクトの構造............................................................................................ 197 ファクトの定義............................................................................................ 198 物理列のファクトへのマッピング : ファクト式 ........................ 199 ファクト列の名前とデータ タイプ : 列別名 ....................................... 206 ファクトがレポートされるレベルの変更 : レベル拡張 .................. 208 テーブル関係を使用したファクト テーブル上の 結合の定義 ............................................................................................. 211 ファクト関係を使用したファクト テーブル上の 結合の定義 ............................................................................................. 215 ファクトの強制的なアトリビュートへの関連付け : 直積結合.................................................................................................. 217 ファクト データのレベルの低下 : ファクト分解 ....................... 219 特定レベルでのファクトのレポート禁止 .................................... 223 7. ビジネス データのコン テキスト : アトリ ビュート はじめに .................................................................................... 225 アトリビュートの概要 .............................................................................. 226 アトリビュートの作成 .............................................................................. 229 複数のアトリビュートの同時作成 ................................................. 229 アトリビュートの追加と変更 .......................................................... 235 アトリビュート情報の一意のセット : アトリビュート エレメント .................................................................................................... 242 アトリビュート エレメントのデータ国際化のサ ポート...................................................................................................... 245 列データの説明と識別子 : アトリビュート フォーム ..................... 248 フォームの表示 : アトリビュート フォームのプロ パティ...................................................................................................... 250 アトリビュート フォーム式 ............................................................. 253 viii © 2010 MicroStrategy, Inc. プ ロ ジ ェ ク ト デザ イ ン ガ イ ド 目次 アトリビュートのデータ タイプの変更 : 列別名 ....................... 261 アトリビュート フォームと個別のアトリビュート ................. 264 アトリビュート関係................................................................................... 265 親アトリビュートと子アトリビュートの表示および 編集 .......................................................................................................... 268 多対多関係および結合子関係のサポート .................................... 269 同じルックアップ テーブルを使用する複数のアトリ ビュート : アトリビュート ロール......................................................... 281 アトリビュート ロールの指定 ......................................................... 284 複数の ID 列を持つアトリビュート : 複合アトリビュート ............ 291 例 : 複合アトリビュートの作成....................................................... 291 アトリビュートを使用したデータのブラウズとレポート ............ 294 アトリビュート フォームのデフォルト表示の定義 ................. 295 8. アトリビュートの構成 とブラウズを行うため の階層の作成 はじめに .................................................................................... 299 ユーザ階層の作成 ....................................................................................... 300 Architect によるユーザ階層の作成.................................................... 303 階層のタイプ................................................................................................ 303 システム階層 : プロジェクト スキーマ定義................................ 304 ユーザ階層 : 論理ビジネス関係....................................................... 305 階層の構成 .................................................................................................... 305 階層の構造 ............................................................................................. 306 階層の表示 : 階層ビュアー................................................................ 307 階層表示オプションの設定...................................................................... 307 アトリビュート エレメントの表示制御 ....................................... 308 階層内のアトリビュートのフィルタ処理 .................................... 312 エントリ ポイント ............................................................................... 313 階層ブラウズ......................................................................................... 315 階層ビュアーとテーブル ビュアーの使用 .......................................... 321 階層ビュアーの使用............................................................................ 321 テーブル ビュアーの使用.................................................................. 323 9. プロジェクトの最適化 と管理 はじめに .................................................................................... 325 MicroStrategy プロジェクト スキーマの更新 ......................................... 326 データ ウェアハウスとプロジェクトとの相互作用 : ウェアハウス カタログ ............................................................................. 328 ウェアハウス カタログの使用を開始する前の準備 ................. 329 ウェアハウス カタログへのアクセス............................................ 330 プロジェクトのテーブルの追加および削除................................ 330 © 2010 MicroStrategy, Inc. ix 目次 プ ロ ジ ェ ク ト デザ イ ン ガ イ ド ウェアハウスとプロジェクトのテーブルの管理....................... 332 データ ウェアハウス接続と動作のデフォルトの変更 ............. 339 カタログ SQL ステートメントのカスタマイズ........................... 347 テーブルと列のメッセージのトラブルシューティング.......... 354 プロジェクト内の複数のデータ ソースへのアクセス .................... 355 データ ソースとプロジェクトとの接続 ....................................... 356 プロジェクトへのデータの追加...................................................... 358 データベースの挿入パフォーマンスの向上 : パラメー ター化したクエリ ....................................................................................... 366 要約テーブルを使用するデータの保存 : 集計テーブル .................. 368 集計テーブルを使用する状況 .......................................................... 369 特定レベルにおけるクエリの頻度の決定 .................................... 373 関連する親子関係の検討................................................................... 373 圧縮率...................................................................................................... 374 集計テーブルの作成............................................................................ 375 プロジェクト内のテーブル サイズ : 論理テーブル サイズ...................................................................................................... 376 パフォーマンスを向上させるためのテーブルの分割 : パーティション マッピング..................................................................... 377 サーバによるパーティションとアプリケーション によるパーティションの違い .......................................................... 377 メタデータ パーティション マッピング ...................................... 378 ウェアハウス パーティション マッピング .................................. 381 メタデータ パーティション マッピングとウェア ハウス パーティション マッピングの違い .................................. 382 10. 時間ベースの比較やそ の他の比較を定義する ためのトランスフォー メーションの作成 はじめに .................................................................................... 385 トランスフォーメーションの作成 ........................................................ 386 式ベースのトランスフォーメーションとテーブル ベースのトランスフォーメーションの違い................................ 387 テーブル ベースのトランスフォーメーションの作成 ............. 388 式ベースのトランスフォーメーションの作成 ........................... 390 トランスフォーメーションの構成要素................................................ 392 トランスフォーメーション メトリックおよび結合子 アトリビュート............................................................................................ 394 A. MicroStrategy Tutorial はじめに .................................................................................... 397 MicroStrategy Tutorial とは ............................................................................. 397 MicroStrategy Tutorial のデータ モデル ...................................................... 401 データ モデリングの表記.................................................................. 402 x © 2010 MicroStrategy, Inc. プ ロ ジ ェ ク ト デザ イ ン ガ イ ド 目次 地域階層.................................................................................................. 402 製品階層.................................................................................................. 404 顧客階層.................................................................................................. 405 時間階層.................................................................................................. 408 MicroStrategy Tutorial のデータ モデルの表示 .................................. 409 MicroStrategy Tutorial のスキーマ ................................................................ 410 MicroStrategy Tutorial スキーマの探索 ................................................ 410 B. 論理テーブル はじめに .................................................................................... 415 論理テーブル................................................................................................ 415 論理テーブルの使用方法 .......................................................................... 417 論理テーブルの作成................................................................................... 419 論理表示のための SQL の使用.......................................................... 421 論理表示の例................................................................................................ 422 ビジネス ケース 1: 重複しないアトリビュートの ルックアップ テーブル ...................................................................... 422 ビジネス ケース 2: 複数のテーブルにわたるアトリ ビュート フォーム式........................................................................... 423 ビジネス ケース 3: 緩やかに変化するディメンション ............ 424 ビジネス ケース 4: 1 対多のトランスフォーメー ション テーブル ................................................................................... 435 ビジネス ケース 5: 複数のアトリビュート ルック アップ テーブルの外部結合 ............................................................. 436 C. データ タイプ はじめに .................................................................................... 441 外部データ タイプから MicroStrategy のデータ タイプ へのマッピング............................................................................................ 441 MicroStrategy のデータ タイプ ................................................................... 461 フォーマット タイプ.................................................................................. 462 データ タイプとフォーマット タイプの互換性 ................................ 463 Big Decimal ....................................................................................................... 465 Big Decimal データ タイプの使用 ...................................................... 465 MicroStrategy の 2 進数データ タイプのサポート................................. 467 用語集 ........................................................................................ 469 索引............................................................................................ 493 © 2010 MicroStrategy, Inc. xi 目次 xii プ ロ ジ ェ ク ト デザ イ ン ガ イ ド © 2010 MicroStrategy, Inc. はじめに ガイドの説明 この『MicroStrategy プロジェクト デザイン ガイド』には、 MicroStrategy でのプロジェクトの計画、作成、および変更に 関する包括的な情報を記載しており、プロジェクト関連のト ピックを幅広く網羅しています。以下に具体的なトピックを 示します。 © 2010 MicroStrategy, Inc. • 1 章、 「MicroStrategy プラットフォームの BI アーキテク チャ」では、ビジネス インテリジェンス アーキテクチャ と、MicroStrategy プラットフォームのいくつかの主要 コンポーネントについて簡単に紹介します。 • 2 章、 「論理データ モデル」では、論理データ モデリン グの概要を示します。ビジネス データ内のさまざまな要 素を識別してプロジェクトの計画を立てるうえで、この 手法をどのように役立てることができるかを示します。 • 3 章、 「論理データ モデルのウェアハウスの構造」では、 物理ウェアハウス スキーマに含まれる列やテーブルなど の各種コンポーネントについて説明し、論理データ モデ ルからデータベースにコンポーネントをマッピングして、 物理ウェアハウス スキーマを形成する方法を示します。 • 4 章、 「プロジェクトの作成および構成」では、プロジェ クトの作成に関連する主なコンポーネントについて説明 し、MicroStrategy でプロジェクトを作成するプロセスを、 手順を追って紹介します。 • 5 章、 「Architect によるプロジェクトの作成」では、 MicroStrategy で Architect を使用してプロジェクトを作成 するプロセスを、手順を追って紹介します。 xiii はじめに プロジェクト デザイン ガイド • 6 章、 「ビジネス データの構築ブロック : ファクト」では ファクトの構造を説明します。さまざまな種類のファク トを紹介して、それらがビジネス データにどのように関 係するかを示します。この章では、プロジェクト用の ファクトの作成に必要なすべての手順も説明します。 • 7 章、 「ビジネス データのコンテキスト : アトリビュー ト」では、アトリビュートの概念的構造について説明し ます。さまざまな種類のアトリビュートを紹介して、そ れらがビジネス データにどのように関係するかを示しま す。この章では、プロジェクト用のアトリビュート作成 に必要なすべての手順も説明します。 • 8 章、 「アトリビュートの構成とブラウズを行うための階 層の作成」では、MicroStrategy に含まれる各種の階層に ついて説明し、ユーザ階層を作成してプロジェクトの編 成と拡張に利用する方法を示します。 • 9 章、 「プロジェクトの最適化と管理」では、プロジェク トの最適化と、短期的および長期的な保守を、より効果 的に実施するための手法を説明します。 • 10 章、「時間ベースの比較やその他の比較を定義するた めのトランスフォーメーションの作成」では、 MicroStrategy に含まれる各種のトランスフォーメー ションについて説明し、プロジェクトでトランスフォー メーションを作成する方法を示します。 付録には次に示す参照用の追加情報が含まれています。これ らの情報は、ユーザの必要に応じて取捨選択して利用できま す。 • 「MicroStrategy Tutorial」（397 ページ）には、 MicroStrategy Tutorial プロジェクトに関する情報が記載さ れています。このプロジェクトには、メタデータとウェ アハウスのほか、MicroStrategy プラットフォームの機能 の理解に役立つように設計された一連のサンプル アプリ ケーションが含まれています。 • 「論理テーブル」（415 ページ）では、論理テーブル、さ まざまな種類の論理テーブル、および MicroStrategy で論 理テーブルとビューを作成する方法を説明します。 • 「データ タイプ」（441 ページ）には、MicroStrategy で使 用できる各種データ タイプに関する情報があります。 MicroStrategy をお手持ちの MDX キューブ ソース （SAP BW、Microsoft Analysis Services、Hyperion xiv © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド はじめに Essbase など）に統合する方法は、 『MicroStrategy MDX Cube Reporting Guide』で説明されています。 このガイドについて このガイドは複数の章で構成されており、いずれの章も内容 の概要で始まります。 以下の項では、付随している例の参照先と、このガイドを使 用する際の前提条件を説明します。また、このガイドの情報 の対象となるユーザ ロールについても説明します。 Tutorial プロジェクトの日付は、現在の MicroStrategy 年を反映するよう更新されます。このガイド内のサン プル ドキュメント、画像、および手順は、Tutorial プ ロジェクトで現在使用できない日付で作成されたもの があります。これらは、ご使用の Tutorial プロジェク トのデータの最初の年で置き換えてください。 ビジネス シナリオと例の探し方 このガイドで説明している多くの概念には、ビジネス シナ リオまたは他の説明付きの例が付随しています。レポート機 能の例は、MicroStrategy のウェアハウス、メタデータ、およ びプロジェクトのサンプルである MicroStrategy Tutorial を参 照してください。MicroStrategy Tutorial に関する情報は、 『MicroStrategy 基本レポーティング ガイド』を参照してくだ さい。 高度なレポートを作成する機能の具体的な例は、『上級レ ポーティング ガイド』に記載されています。 このガイドの他の例では Analytics Modules を使用していま す。Analytics Modules には、さまざまな業務分野のサンプル レポートが含まれています。サンプル レポートには、財務 レポート、人事、および顧客分析などの業務分野の分析のた めのデータが提示されます。 © 2010 MicroStrategy, Inc. このガイドについて xv はじめに プロジェクト デザイン ガイド このガイドでの新規内容 MicroStrategy 9.0.1 • プロジェクトを作成および変更するための MicroStrategy Architect の新しいオプション。 「プロジェクトのファクトに基づくメトリックの作成」 （113 ページ） 「アトリビュート関係の自動定義」（114 ページ） • パラメーター化されたクエリの MicroStrategy によるサ ポート。パラメーター化されたクエリは複数ソース オプ ションなど、データベースに情報を挿入する必要がある シナリオで、パフォーマンスを向上させるために役立ち ます（ 「データベースの挿入パフォーマンスの向上 : パラ メーター化したクエリ」（366 ページ）を参照）。 • 対応するデータ ソースから削除されたテーブルを、 MicroStrategy プロジェクト内から削除する新しいオプ ション。この新しいオプションについては、以下の項で 説明しています。 これらのテーブルを MicroStrategy Architect で削除す る方法については、「データ ソースから削除された テーブルのプロジェクトからの削除」（127 ページ） を参照してください。 これらのテーブルをウェアハウス カタログで削除す る方法については、「データ ソースから削除済みの テーブルのウェアハウス カタログからの削除」（336 ページ）を参照してください。 MicroStrategy 9.0 xvi このガイドについて • Architect と呼ばれる新しい直感的なデザイン ツールによ るプロジェクトの作成。Architect では、プロジェクトと オブジェクトの作成タスクを共通のインタフェースで実 行できます（「Architect によるプロジェクトの作成」 （103 ページ）を参照）。 • 特定言語のユーザ コミュニティに対応するためのプロ ジェクトの国際化（「データの国際化のサポート」（63 ページ）を参照）。 © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド はじめに • 新しいアトリビュート フォーム プロパティを活用したア トリビュート フォーム表示の定義（「フォームの表示 : アトリビュート フォームのプロパティ」（250 ページ）を 参照） 。 • 複数ソース オプションによる、単一プロジェクトの複数 のデータベース インスタンスへの接続（「プロジェクト 内の複数のデータ ソースへのアクセス」（355 ページ）を 参照） 。 前提条件 このガイドを利用する前に、次のことに関する知識が必要で す。 • 『導入と構成ガイド』に記載されている情報 • ビジネス インテリジェンス アプリケーションで使用する データの性質および構造 このガイドの対象読者 このドキュメントは、MicroStrategy プラットフォームを使用 して MicroStrategy プロジェクトをデザイン、作成、および 変更する方法を理解する必要があるすべてのユーザを対象と しています。 端的に言えば、次のビジネス インテリジェンス アプリケー ション ユーザが対象です。 © 2010 MicroStrategy, Inc. • プロジェクト デザイナ • データベース アドミニストレータ このガイドについて xvii はじめに プロジェクト デザイン ガイド リソース ドキュメンテーション MicroStrategy ではマニュアルとオンライン ヘルプの両方を 提供しています。これら 2 つの情報源は、次に説明するよう に異なるタイプの情報を提供します。 マニュアル : 一般に、MicroStrategy マニュアルでは次の情報 を提供します。 • 概要情報および概念 • 例 • 開始に必要なチェックリストおよび手順の概要 ヘルプ : 一般に、MicroStrategy ヘルプでは次の情報を提供し ます。 • 手順を実行するための詳細なステップ • ソフトウェアのすべての画面の各オプションの説明 マニュアル 以下のマニュアルは MicroStrategy ディスク、または MicroStrategy をインストールしたコンピュータから入手でき ます。これらのマニュアルには、以下の方法でアクセスでき ます。 Acrobat これらのマニュアルを表示するには、Adobe Reader が必要です。Acrobat Reader がコンピュータに インストールされていない場合は、 www.adobe.com/products/acrobat/readstep2 _allversions.html からダウンロードできます。 すべてのユーザが最初に読むのに最も適したガイドは、 『MicroStrategy 基本レポーティング ガイド』です。 xviii リソース © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド はじめに MicroStrategy の概要 • 『Introduction to MicroStrategy:Evaluation Guide』 MicroStrategy ソフトウェアの評価版のインストール、構 成、および使用の手順を説明しています。また、このガ イドでは、MicroStrategy 機能の評価プロセスを順を追っ て詳細に説明しています。この評価プロセスでは、 MicroStrategy Tutorial プロジェクトおよびそのサンプル ビジネス データを使用してレポーティングを実行できま す。 • 『MicroStrategy Quick Start Guide』 インストールおよび評価のプロセスの概要、およびその 他の情報を提供しています。 • 『Evaluate MicroStrategy for Linux Guide』 Microsoft Windows または Linux 環境で MicroStrategy Evaluation Edition Virtual Appliance を使用して、Linux 版 の MicroStrategy を評価します。このガイドには、Linux 環境で実行する MicroStrategy ソフトウェアをダウンロー ド、有効化、および評価するために必要なすべての詳細 情報が記載されています。 • 『MicroStrategy Reporting Suite Quick Start Guide』 部門で使用するソリューションとして MicroStrategy を評 価します。MicroStrategy Reporting Suite をダウンロード、 インストール、構成、および使用する方法についての詳 細情報が記載されています。 クエリ、レポートおよび分析に関するマニュアル • 『MicroStrategy 導入と構成ガイド』 MicroStrategy 製品を Windows、UNIX、Linux、および HP プラットフォームにインストールして構成するための情 報を、基本的な保守のガイドラインと共に提供していま す。 • 『MicroStrategy アップグレード ガイド』 既存の MicroStrategy 製品をアップグレードする手順を説 明しています。 © 2010 MicroStrategy, Inc. リソース xix はじめに プロジェクト デザイン ガイド • 『MicroStrategy プロジェクト デザイン ガイド』 MicroStrategy プロジェクトを作成および変更するための 情報、および、ファクト、アトリビュート、階層、ト ランスフォーメーション、高度なスキーマ、およびプロ ジェクト最適化を理解するための情報を提供しています。 • 『MicroStrategy 基本レポーティング ガイド』 MicroStrategy Desktop および MicroStrategy Web で作業を 開始するための手順と、レポート内のデータの分析方法 を説明しています。レポート、メトリック、フィルタ、 およびプロンプトの作成方法の基本が含まれています。 • 『MicroStrategy 上級レポーティング ガイド』 『基本レポーティング ガイド』の情報を基礎として構成 されており、MicroStrategy システムでの高度なトピック に関する手順を説明しています。これらのトピックには、 フリーフォーム SQL レポート、クエリ ビルダ レポート、 フィルタ、メトリック、データ マイニング サービス、カ スタム グループ、コンソリデーション、およびプロンプ トが含まれています。 • 『MicroStrategy Report Services ドキュメント作成ガイド』 『基本レポーティング ガイド』および『上級レポー ティング ガイド』での情報を基礎として構成されてお り、Report Services ドキュメントのデザインと作成の手 順を説明しています。 • 『MicroStrategy OLAP Services Guide』 MicroStrategy Intelligence Server の拡張機能である MicroStrategy OLAP Services に関する情報を提供します。 OLAP Services の機能には、インテリジェント キューブ、 派生メトリック、派生エレメント、動的小計、ビュー フィルタ、および動的ソースが含まれます。 • 『MicroStrategy Office User Guide』 MicroStrategy Office を使用して Microsoft® Excel、 PowerPoint、Word、および Outlook に MicroStrategy レ ポートおよびドキュメントを表示し、ビジネス データを 分析、書式設定、および配布する手順を説明しています。 • 『MicroStrategy Mobile User Guide』 MicroStrategy Mobile を使用してモバイル デバイスに MicroStrategy レポートおよびドキュメントを表示し、 xx リソース © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド はじめに データの表示および分析、さらにその他のビジネス タス クを実行する手順を説明しています。MicroStrategy Mobile をインストールして構成する方法、さらに MicroStrategy Desktop または MicroStrategy Web のデザイ ナが、MicroStrategy Mobile での使用を目的とした効果的 なレポートおよびドキュメントを作成する方法について 記載しています。 • 『MicroStrategy システム管理ガイド 第 1 巻』 MicroStrategy ビジネス インテリジェンス システムの実 装、配置、保守、調整、およびトラブルシューティング の概念および手順の概要を説明しています。 • 『MicroStrategy システム管理ガイド 第 2 巻』 MicroStrategy Command Manager、MicroStrategy Enterprise Manager、MicroStrategy Integrity Manager、および MicroStrategy Health Center などのさまざまな管理ツール の使用に関する概念および手順の概要を説明しています。 • 『MicroStrategy Functions Reference』 関数構文および式のコンポーネントについて、また、メ トリック、フィルタ、アトリビュート フォームでの関数 の使用手順について、および、ビジネス シナリオにおけ る関数の例について説明しています。 • 『MicroStrategy MDX Cube Reporting Guide』 MicroStrategy を MDX キューブ ソースに統合するための 情報を記載しています。SAP BW、Microsoft Analysis Services、および Hyperion Essbase などの MDX キューブ ソースのデータを MicroStrategy のプロジェクトおよびア プリケーションに統合できます。 • 『MicroStrategy Web Services Administration Guide』 MicroStrategy Web Services のインストール、構成、調整、 およびトラブルシューティングの概念とタスクを説明し ています。 Analytics Modules に関するマニュアル • 『Analytics Modules Installation and Porting Guide』 • 『Customer Analysis Module Reference』 • 『Sales Force Analysis Module Reference』 © 2010 MicroStrategy, Inc. リソース xxi はじめに プロジェクト デザイン ガイド • 『Financial Reporting Analysis Module Reference』 • 『Sales and Distribution Analysis Module Reference』 • 『Human Resources Analysis Module Reference』 情報の送信および警告を行う製品に関するマニュアル • 『MicroStrategy Narrowcast Server Getting Started Guide』 Narrowcast Server のインタフェースおよび機能を習得す るためのチュートリアルの使用手順について説明してい ます。 • 『MicroStrategy Narrowcast Server Installation and Configuration Guide』 Narrowcast Server のインストールと構成の情報を提供し ています。 • 『MicroStrategy Narrowcast Server Application Designer Guide』 Narrowcast Server アプリケーションのデザインの基礎情 報を提供しています。 • 『MicroStrategy Narrowcast Server System Administrator Guide』 Narrowcast Server の実装、保守、調整、およびトラブル シューティングの概念とおおまかなステップを説明して います。 • 『MicroStrategy Narrowcast Server Upgrade Guide』 既存の Narrowcast Server をアップグレードする手順を説 明しています。 ソフトウェア開発キット • MicroStrategy Developer Library（MSDL） MicroStrategy SDK を理解するための情報で、アーキテク チャ、オブジェクト モデル、カスタマイズのシナリオ、 コード サンプルなどの詳細を含みます。 xxii リソース © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド はじめに • MicroStrategy Web SDK SDK は、MicroStrategy SDK の一部として販売 Web されている MicroStrategy Developer Library に含ま れています。 • 『Narrowcast Server SDK Guide』 Narrowcast Server 機能のカスタマイズ、Narrowcast Server と他のシステムとの統合、Narrowcast Server 機能の他の アプリケーションへの組み込みを行う手順を説明してい ます。Narrowcast Server Delivery Engine と Subscription Portal API、および Narrowcast Server SPI に関するドキュ メントです。 インストールされたマニュアルおよびその他のドキュメン テーション ソースを利用するには、以下の手順を参照して ください。 • 「Windows でインストールされたマニュアルを利用するに は」（xxiii ページ） • 「UNIX および Linux でインストールされたマニュアルを 利用するには」（xxiv ページ） Windows でインストールされたマニュアルを利用するには 1 Windows の [ スタート ] メニューから、[ プログラム ]（ま たは [ すべてのプログラム ]）、[MicroStrategy]、 [Product Manuals] を順に選択します。ブラウザ内に ページが開いて、使用可能な PDF 形式のマニュアルおよ びその他のドキュメンテーション ソースのリストが表示 されます。 2 目的のマニュアルまたはその他のドキュメンテーション ソースのリンクをクリックします。 3 『Narrowcast Services SDK Guide』は、ダウンロードする 必要があります。このガイドを選択すると、[ ファイルの ダウンロード ] ダイアログ ボックスが開きます。[ この ファイルを上記の場所から開く ] を選択し、[OK] をク リックします。 Acrobat（PDF）マニュアルの左側にしおりが表示さ れていない場合は、[ 表示 ] メニューの [ ナビゲー ションパネル ] から [ しおり ] をクリックします。この © 2010 MicroStrategy, Inc. リソース xxiii はじめに プロジェクト デザイン ガイド 手順は、Adobe Acrobat Reader のバージョンによって 多少異なる場合があります。 UNIX および Linux でインストールされたマニュアルを利用する には 1 UNIX または Linux のコンピュータで、MicroStrategy を インストールしたディレクトリへ移動します。デフォル トの場所は /opt/MicroStrategy です。または、 /opt/MicroStrategy への書き込み許可がない場合 は、$HOME/MicroStrategy/install です。 2 MicroStrategy のインストール ディレクトリで、 Documentation フォルダを開きます。 3 Product_Manuals.htm ファイルを Web ブラウザで開 きます。ブラウザ内にページが開いて、使用可能な PDF 形式のマニュアルおよびその他のドキュメンテーション ソースのリストが表示されます。 4 目的のマニュアルまたはその他のドキュメンテーション ソースのリンクをクリックします。 5 『Narrowcast Services SDK Guide』は、ダウンロードする 必要があります。このガイドを選択すると、[ ファイルの ダウンロード ] ダイアログ ボックスが開きます。[ この ファイルを上記の場所から開く ] を選択し、[OK] をク リックします。 Acrobat（PDF）マニュアルの左側にしおりが表示さ れていない場合は、[ 表示 ] メニューの [ ナビゲー ションパネル ] から [ しおり ] をクリックします。この 手順は、Adobe Acrobat Reader のバージョンによって 多少異なる場合があります。 ヘルプ MicroStrategy には、ヘルプへのアクセス方法がいくつか用意 されています。 • xxiv リソース [ ヘルプ ] ボタン : [ ヘルプ ] ボタンを使用するか、また は大部分のソフトウェア ウィンドウに表示される [?] （疑問符）アイコンを使用してそのウィンドウに関するヘ ルプを開きます。 © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド はじめに • [ ヘルプ ] メニュー:[ ヘルプ ] メニューまたはいずれかの画 面の上部に表示されたリンクから、[MicroStrategy ヘル プ ] を選択し、ヘルプ システムの目次、検索フィールド、 および索引を表示します。 • F1 キー : F1 キーを押して、現在表示しているソフト ウェア ウィンドウの各オプションを説明する状況依存ヘ ルプを開きます。 ドキュメンテーション標準 MicroStrategy のオンライン ヘルプおよび PDF マニュアル （オンラインおよび印刷の両形式で利用可能）は、標準規格 に従って作成されているため、特定のタイプの内容を容易に 識別できます。次の表に、これらの標準を示します。 これらの標準は、マニュアルの言語によって異なる場 合があります。一部の言語では以下の表に優先する規 則があるためです。 タイプ 太字 意味 • 操作の対象となるボタン名、チェック ボックス、ダイアログ ボックス、オプ ション、リスト、メニュー、またはそれらの GUI エレメントおよび定義のリスト の一部 • ユーザが入力するテキスト 例 :[ ウェアハウスを選択 ] をクリックします。 例 :cmdmgr -f scriptfile.scp と入力し、[ENTER] 斜体 を押します。 • 本文および用語集で定義される新しい用語 • 他の製品マニュアルの名前 • コマンド構文の一部である場合は、ユーザが置き換える必要のある変数情報 は、メトリックの計算のレベルです。 例 : copy c:\filename d:\foldername\filename と入力します。 例 : 集計レベル Courier フォント • • • • • • 計算 コード例 レジストリ キー パスおよびファイル名 URL 画面に表示されるメッセージ 例: Sum(revenue)/number of months. 大文字の英数字 • キーボード コマンド キー（ENTER など） • ショートカット キー（CTRL + V など） 例: © 2010 MicroStrategy, Inc. 選択したテキストを太字にするには、CTRL + B キーを押します。 リソース xxv はじめに プロジェクト デザイン ガイド タイプ 意味 + 複数のキーを使用するキーボード コマンド（SHIFT + F1 など） 注意アイコンは、特定の状況に関して役に立つ情報を示します。 警告アイコンは、潜在的なセキュリティ上のリスクなど、先に進む前に参照しておく 必要のある重要な情報を示す警告です。 トレーニング MicroStrategy トレーニング サービスでは、広範囲のカリ キュラムを提供し、トレーニング コンサルタントは高度な スキルを備えています。すでに 800 を超えるさまざまな組織 の多くのお客様やパートナーの方々に MicroStrategy のト レーニングを活用していただいています。 このガイドを使用する前に利用すると役立つコース、または このガイドに関連する情報が含まれているコースには、以下 のものがあります。 • MicroStrategy Architect: プロジェクト デザイン トレーニング コースの最新情報、およびコースのカリキュ ラムの詳細については、 www.microstrategy.co.jp/Education を参照してく ださい。 コンサルティング MicroStrategy コンサルティング サービスでは、先端のテク ノロジ ソリューションを導入するための実績ある方法を提 供しています。サービスには複雑なセキュリティ アーキテ クチャのデザイン、パフォーマンスとチューニング、プロ ジェクトとテストの方法および推奨事項、戦略的プランニン グ、などが含まれます。コンサルティング サービスの詳細 は、www.microstrategy.co.jp/Consulting を参照し てください。 xxvi リソース © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド はじめに 国際化サポート MicroStrategy は、複数のロケールをサポートしています。ロ ケールのサポートには、一般に、ネイティブ データベース とオペレーティング システムのサポート、日付、数値の書 式、通貨記号のサポートなどが含まれます。翻訳されたイン タフェースとドキュメントを利用可能にすることも、ロケー ルのサポートに含まれます。サポートのレベルは、 MicroStrategy ビジネス インテリジェンス環境のコンポー ネントの観点から定義されます。MicroStrategy ビジネス インテリジェンス環境は、次のコンポーネントから構成さ れ、これらをまとめて構成と呼びます。 • ウェアハウス、メタデータ、および統計データベース • MicroStrategy Intelligence Server • MicroStrategy Web Server • MicroStrategy Desktop クライアント • Web ブラウザ MicroStrategy は、英語（米国）、フランス語、ドイツ語、イ タリア語、日本語、韓国語、ポルトガル語（ブラジル）、ス ペイン語、中国語（簡体字）、中国語（繁体字）、デンマーク 語、スウェーデン語での同種構成（すべてのコンポーネント の言語が同じ）での動作が保証されています。 MicroStrategy は、異種構成（一部のコンポーネントのロケー ルが異なる）も限定的にサポートしています。詳細は、 MicroStrategy テクニカル サポートに問い合せてください。 前述の各言語では、翻訳されたユーザ インタフェースが使 用可能です。また、前述の言語の一部では、オンライン ヘ ルプ ファイルと製品ドキュメンテーションの翻訳バー ジョンが用意されています。 テクニカル サポート 特定の MicroStrategy 製品に関して疑問がある場合は、以下 のいずれかを行ってください。 1 製品ガイド、ヘルプ、および README ファイルを参照 します。それぞれへのアクセス場所は前述のとおりです。 © 2010 MicroStrategy, Inc. リソース xxvii はじめに プロジェクト デザイン ガイド 2 MicroStrategy Knowledge Base オンライン （https://resource.microstrategy.com/support）を参照します。 アドミニス 問題によっては、組織内のテクニカル トレータに相談すると、すぐに解決できる場合も あります。 3 前述のステップでリストしたリソースで回答が得られな い場合は、MicroStrategy テクニカル サポートに直接問い 合せてください。MicroStrategy テクニカル サポートでの 対応が最も生産的に行われるよう、 http://www.microstrategy.com/download/files/support/tech_ser v_policies.zip の「Policies and Procedures（テクニカル サ ポート規定）」の日本語版のドキュメントを参照してくだ さい。利用できるサポートのタイプを判断するには、購 入契約の条件を参照してください。 MicroStrategy テクニカル サポートへは、社内のサポート連 絡担当者を通じてご連絡ください。サポート連絡担当者と は、MicroStrategy サポート担当者との連絡窓口として指定さ れた御社内の担当者のことです。お客様からのお問い合せお よびケースに関するご連絡はすべて、これら指定された担当 者を通じて行う必要があります。お客様は、サポート連絡担 当者として 2 名の従業員を指定することができ、サポート連 絡担当者の変更は、MicroStrategy テクニカル サポートへの 書面による事前の通知を行うことによって、年に 2 回まで要 請することができます。 MicroStrategy アドミニストレータの権限を持つサポート連絡 担当者を指定することを推奨します。これによりセキュリ ティの問題を排除し、ケースの解決の時間を短縮できます。 問題のトラブルシューティングおよび調査の際に、 MicroStrategy テクニカル サポート担当者が推奨する処置は MicroStrategy 内で管理権限が必要な場合があります。また、 指定されたサポート連絡担当者が MicroStrategy プロジェク トの完全な操作が許可されるセキュリティ レベルを有して おり、セキュリティ フィルタ定義などの潜在的な機密プロ ジェクト データへのアクセス権を有することを前提として 助言する場合があります。 xxviii リソース © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド はじめに 問題の迅速な解決のために MicroStrategy テクニカル サポートにケースを登録する前に、 サポート連絡担当者は、問題の迅速な解決のために次のス テップに従ってください。 1 問題が MicroStrategy ソフトウェアに関するものであり、 サードパーティ ソフトウェアではないことを確認しま す。 2 システムで使用されている MicroStrategy ソフトウェア が、現在サポートされているバージョンであることを製 品サポート有効期限スケジュール （http://www.microstrategy.com/Support/ Expiration.asp）で確認します。 3 問題の再現を試みて、常に発生するかどうかを確認しま す。 4 原因を特定するために、システムまたはプロジェクト オ ブジェクト定義の複雑度を最小化します。 5 その問題が、ローカル コンピュータ上で発生しているの か、ご利用の環境の複数のコンピュータ上で発生してい るのかを判別します。 6 問題に関する質問を MicroStrategy 顧客フォーラム （https://resource.microstrategy.com/forum/） に投稿して、他のユーザと問題について論議します。 次の表に、MicroStrategy テクニカル サポートに連絡する際 の場所、時間、および方法を示します。サポート連絡担当者 が MicroStrategy テクニカル サポートに営業時間中に電話で 連絡できない場合は、ボイスメール メッセージを残すか、 電子メールまたは FAX を送信するか、オンライン サポート インタフェースを使用してケースを記録してください。個々 © 2010 MicroStrategy, Inc. リソース xxix はじめに プロジェクト デザイン ガイド のテクニカル サポート センタは、特定の公休日には休業い たします。 北米 メール :[email protected] Web:https://resource.microstrategy.com/support FAX:(703) 842–8709 電話 :(703) 848–8700 時間 : 月曜～金曜（休日を除く）、東部標準時 午前 9:00 ～午後 7:00 EMEA: メール :[email protected] Web:https://resource.microstrategy.com/support FAX: +44 (0) 208 711 2525 European Technical Support Centre は、それぞれの国の法定公休日に休業いたします。 電話 : • ベルギー : + 32 2792 0436 • フランス : +33 17 099 4737 • ドイツ : +49 22 16501 0609 • アイルランド : +353 1436 0916 • イタリア : +39 023626 9668 • ポーランド : +48 22 321 8680 • スカンジナビアおよびフィンランド : +46 8505 20421 • スペイン : +34 91788 9852 • オランダ : +31 20 794 8425 • 英国 : +44 (0) 208 080 2182 • 国際代理店 : +44 (0) 208 080 2183 時間 : • 英国 : 月曜～金曜（休日を除く）、グリニッジ標準時の午前 9:00 ～午後 6:00 • EMEA（英国を除く）: 月曜～金曜（休日を除く）、中央ヨーロッパ標準時の午前 9:00 ～ 午後 6:00 ヨーロッパ 中東 アフリカ アジア太平洋 メール :[email protected] Web:https://resource.microstrategy.com/support 電話 : • オーストラリア : +61 2 9333 6499 • 韓国 :+82 2 560 6565、FAX: +82 2 560 6555 • 日本 :+81 3 3511 6720、FAX: +81 3 3511 6740 • アジア太平洋（オーストラリア、日本、および韓国を除く）:+65 6303 8969、FAX: +65 6303 8999 時間 : • 日本および韓国 : 月曜～金曜（休日を除く）、日本標準時（東京）午前 9:00 ～午後 6:00 • アジア太平洋（日本および韓国を除く）: 月曜～金曜（休日を除く）、午前 8 時～午後 6 時 （シンガポール） ラテン アメリカ メール :[email protected] Web:https://resource.microstrategy.com/support 電話 : • 中南米（ブラジルおよびアルゼンチンを除く）:+54 11 5222 9360、FAX: +54 11 5222 9355 • アルゼンチン :0 800 444 MSTR、FAX: +54 11 5222 9355 • ブラジル :+55 11 3054 1010、FAX: +55 11 3044 4088 時間 : 月曜～金曜（休日を除く）、ブラジル標準時（サンパウロ）の午前 9:00 ～午後 7:00 xxx リソース © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド はじめに サポート連絡担当者は、MicroStrategy ソフトウェアのライ センスを取得したテクニカル サポート センタ、または指定 を受けたテクニカル サポート センタに連絡していただく必 要があります。 お電話の際に必要な情報 MicroStrategy テクニカル サポートに連絡する際には、次の 情報をお知らせください。 • 個人の情報 : 氏名（姓および名） 会社名およびお客様のサイト（会社と異なる場合） 連絡先情報（電話番号および FAX 番号、電子メール アドレス） • ケースの詳細 : MicroStrategy ソフトウェア製品およびバージョンを含 む、構成情報 現象、エラー メッセージ、およびそのケースに対し これまで実行したトラブルシューティングの手順を含 むケースの詳しい説明 • ビジネス上 / システム上の影響 サポート連絡担当者が初めて電話される場合には、次の情報 もお知らせください。 • 住所 • 電話番号 • FAX 番号 • メール アドレス テクニカル サポート担当者が問題に迅速かつ効率的に問題 に対処できるよう、次の追加情報も準備しておいてくださ い。 • © 2010 MicroStrategy, Inc. ケース番号 :MicroStrategy テクニカル サポートに記録さ れているケースごとに割り当てられている番号をメモし、 既存の問題に関するお問い合せの際にお知らせください。 リソース xxxi はじめに プロジェクト デザイン ガイド • ご使用の MicroStrategy ソフトウェア製品のソフトウェア バージョンと製品登録番号。 • ケースの説明 : 問題状況の発生原因 問題状況は散発的に発生するか、または特定の操作を 実行するたびに発生するか 問題状況はすべてのコンピュータで発生するか、また は 1 台でのみ発生するか 問題状況が最初に発生した時期 問題状況が最初に発生する直前に発生したイベント （たとえば、大きなデータベース負荷、データベース の移動、またはソフトウェアのアップグレードなど） エラー メッセージが表示された場合、その正確な表 現 問題を特定および解決するために実行した手順と、そ の結果 • システム構成（必要な情報は問題の性質によって異なり、 次にリストされているすべての項目に関する情報が必要 なわけではありません）: コンピュータ ハードウェアの仕様（プロセッサ速度、 RAM、ディスク容量など） 使用しているネットワーク プロトコル ODBC ドライバの製造業者とバージョン データベース ゲートウェイ ソフトウェアのバー ジョン （MicroStrategy Web 関連の問題の場合）ブラウザの製 造業者とバージョン （MicroStrategy Web 関連の問題の場合）Web サーバの 製造業者とバージョン 問題に追加の調査またはテストが必要な場合、サポート連絡 担当者と MicroStrategy テクニカル サポート担当者との間で、 特定の作業項目の実行について合意が必要です。サポート連 絡担当者は、問題について MicroStrategy テクニカル サポー トに再び問い合せる前に、合意した作業を実行していただく xxxii リソース © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド はじめに 必要があります。テクニカル サポート担当者が作業項目を 実行する場合は、サポート連絡担当者は問題の状況を MicroStrategy テクニカル サポートに随時問い合せることが できます。 ご意見 MicroStrategy 製品のユーザ ドキュメンテーションに関する ご意見またはご提案は、次の宛先にお寄せください。 [email protected] 製品の機能向上に関するご提案は、次の宛先にお寄せくださ い。 [email protected] ご意見をお寄せくださる場合は、現在使用している製品名と バージョンを記載してください。皆様のご意見は、今後のリ リースの参考とさせていただきます。 © 2010 MicroStrategy, Inc. ご意見 xxxiii はじめに xxxiv ご意見 プロジェクト デザイン ガイド © 2010 MicroStrategy, Inc. 1 1. MICROSTRATEGY プラット フォームの BI アーキテクチャ はじめに MicroStrategy でプロジェクトの計画と作成を行う前に、ビジ ネス インテリジェンス システムの機能のしくみ、特に MicroStrategy プラットフォームがビジネス データとどのよ うに関わることで、多様な機能が提供されるのかを理解する ことが重要です。 ビジネス インテリジェンス（BI）システム は、データを複 数の観点から見る機能を提供することにより、大量にある複 雑なデータの分析を容易にします。最適なビジネス インテ リジェンス アプリケーションの条件は次のとおりです。 • ユーザがさまざまな詳細レベルでデータにアクセスでき る • ユーザが情報を要求し、正確かつ迅速に応答が得られる • システムの購読者に情報を事前配信するための基盤を提 供する この章では、BI システムの基本的なアーキテクチャを紹介 します。ビジネス インテリジェンスの作成と分析を可能に © 2010 MicroStrategy, Inc. 1 1 MicroStrategy プラットフォームの BI アーキテクチャ プロジェクト デザイン ガイド する MicroStrategy プラットフォームの一部のコンポーネン トについても紹介しています。 ビジネス インテリジェンスのアーキテクチャ BI のアーキテクチャには、次のコンポーネントが含まれま す。 • ソース システム。通常はオンライン トランザクション処 理（OLTP）システムですが、代わりに他のシステムや ファイルを使用して、特定のデータを取得または保持す ることもできます。 • 抽出、変換、およびロード（ETL）のプロセス。 • データ ウェアハウス。通常はオンライン分析処理 （OLAP）システムです。 • MicroStrategy などのビジネス インテリジェンス プラット フォーム。 システムからデータを取得して正 上の図は、ソース 規化し、MicroStrategy に転送するための一般的なセッ トアップを示しています。MicroStrategy は、テキスト ファイル、Excel ファイル、SAP BI、Hyperion Essbase、Microsoft Analysis Services、およびその他の データ ソースのデータにアクセスすることもできま す。MicroStrategy でデータ ソースにアクセスする方 法の詳細は、「データ ウェアハウスのデータ格納とリ レーショナル設計」（5 ページ）を参照してください。 2 ビジネス インテリジェンスのアーキテクチャ © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド MicroStrategy プラットフォームの BI アーキテクチャ 1 データ収集のソース システム ソース システム とは、対象となるデータを取得または保持 するシステムやファイルのことです。銀行は、多数のソース システムを運用している企業の一例です。平均的な銀行は、 口座入出金の更新、貸付実行などさまざまなサービスを提供 しており、それらのサービスをいくつものソース システム で支えています。たとえば、ソース システムの 1 つとして、 銀行のサーバ上のデータベース ファイルが預入と引き出し を随時記録する一方で、サーバ上の他のファイルが別のソー ス システムとして、顧客の連絡先情報を追跡します。 ソース システムは通常、オンライン トランザクション処理 （OLTP）の最も重要な部分です。トランザクション処理に は、トランザクションやその他のビジネス データ（売上、 在庫、電子商取引、口座への入金、Web サイト利用状況、 受注処理など）の単純な記録が含まれます。医療、通信、製 造などほぼすべての業界が、この処理に日常的に依存してい ます。 OLTP システムは、リアルタイムで処理されるデータを格納 するデータベースまたはメインフレームで、以下の特徴があ ります。 © 2010 MicroStrategy, Inc. • システムで日常的に膨大な量のデータを記録する必要が あるため、データ アクセスは頻繁な読み取りと書き込み 用に最適化されています。この種の最適化が効果を発揮 するデータとしては、OLTP システムが 1 日に記録する クレジット カード決済の件数などがあります。これは データ ウェアハウスとは対照的です。データ ウェアハウ スは通常、分析用のデータ読み取りを最優先し、更新、 挿入、および削除を最小限に抑えるように設計されます。 データ ウェアハウスの設計の詳細は、「データ ウェアハ ウスのデータ格納とリレーショナル設計」（5 ページ）を 参照してください。 • データは用途（業務活動とワークフロー）によって配置 されます。 • データ形式は、システムごとに必ずしも共通ではありま せん。 • データ履歴は最近または最新のものに限定されます。 ビジネス インテリジェンスのアーキテクチャ 3 1 MicroStrategy プラットフォームの BI アーキテクチャ プロジェクト デザイン ガイド 前述の銀行の例では、銀行が提供しているさまざまなサービ スに関連するデータが、複数のソース システムに格納され ていました。これらのビジネス サービスのワークフローは、 それぞれのサービス特有であり、互いに異なっています。 銀行の ATM では、現金の引き出し、預け入れ、および残高 照会を行うことができます。一方、為替を現金化するには、 銀行の窓口まで行き、所定の手続を行う必要があります。こ れは、これらのサービスをサポートする運用システムが特定 のタスク専用に設計されており、それぞれのサービスに異な る運用システムが必要なためです。 ATM 利用状況、貸付状況、口座残高、MMA（マネー マー ケットアカウント）情報など、特定顧客のすべての情報を一 括確認するには、これらの各システムに格納されている顧客 情報を統合する必要があります。この統合は、抽出、変換、 およびロード（ETL）のプロセスによって実現されます。 ETL プロセスはデータを統合し、データ ウェアハウスに格 納できるようにします。 抽出、変換、およびロードのプロセス 抽出、変換、およびロード（ETL）のプロセスは、複数の異 なるソース システムからデータを抽出して統合し、データ ウェアハウスに移動するために必要なすべてのステップの総 称です。 ETL プロセスには次のステップが含まれます。 1 さまざまなソース システムからデータが収集されます。 2 データが変換（トランスフォーメーション）され、デー タ ウェアハウスにロードする準備が整います。トランス フォーメーション プロシージャでは、データ タイプや名 前の変換、不要なデータの削除、入力ミスの修正、不完 全なデータの補完、および同様なプロセスを通じて、 データの形式と構造が正規化されます。 3 データがデータ ウェアハウスにロードされます。 このプロセスは、銀行で ATM 利用状況、貸付状況、口座残 高など、特定顧客のさまざまな情報を統合する状況を例に考 えれば、より良く理解できます。これらのデータは通常、そ 4 ビジネス インテリジェンスのアーキテクチャ © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド MicroStrategy プラットフォームの BI アーキテクチャ 1 れぞれ異なるソース システムから収集されます。各ソース システムにはそれぞれ固有の命名規則があるため、ソース システムから取得されるデータは、他のソース システムか ら得られたデータと互換性があるとは限りません。 その場合、データは ETL プロセスによって各ソース システ ムから抽出され、正規化され整合性が得られるまで変換され た後、データ ウェアハウスにロードされます。 データ ウェアハウスのデータ格納とリレーショナル設計 設計に優れ、堅牢なデータ ウェアハウスが、意思決定支援 システムやビジネス インテリジェンス システムのデータの ソースになります。そのようなデータ ウェアハウスは、ビ ジネス インテリジェンスの優位性を活用するために役立ち ます。データ ウェアハウスは通常、リレーショナル データ ベースか、なんらかのリレーショナル データベース管理シ ステム（RDBMS）のプラットフォームに基づきます。これ らのリレーショナル データベースには、RDBMS ソフトウェ アとの連携専用に開発された構造化照会言語（SQL）で直 接、クエリを実行できます。ただし、MicroStrategy にはリ レーショナル データベースにデータを格納する必要はあり ません。MicroStrategy ではテキスト ファイル、Excel ファイ ル、MDX キューブなど、種類の異なるデータ ソースを統合 できます。代替データ ソースに格納されているデータへの アクセス方法の詳細は、「代替データ ソースによるデータの 格納と分析」（6 ページ）を参照してください。 OLTP システムなどの前述したソース システムは通常、ト ランザクション処理用に設計され最適化されていますが、 データ ウェアハウスは多くの場合、分析処理用にデザイン され、最適化されます。MicroStrategy のツールおよび製品と 組み合わせることで、データ ウェアハウスは堅牢なオンラ イン分析処理（OLAP）システムの構築基盤にもなります。 分析処理には、月次売上データの表示を選択し、売上傾向、 成長パターン、全体に占める貢献率、傾向レポート、および 利益分析の計算に使用するメトリックを選択するアクティビ ティなどが含まれます。 ほとんどのデータ ウェアハウスには、以下の特徴がありま す。 © 2010 MicroStrategy, Inc. ビジネス インテリジェンスのアーキテクチャ 5 1 MicroStrategy プラットフォームの BI アーキテクチャ プロジェクト デザイン ガイド • データ アクセスは通常、読み取り専用。最も一般的な操 作は、分析するデータの選択です。データの挿入、更新、 削除はほとんど行ないません。これは、データの収集に 伴い頻繁に更新処理を実行できる必要のある大部分の OLTP ソース システムとは対照的です。ソース システム の詳細は、「データ収集のソース システム」（3 ページ） を参照してください。 • データはビジネスのテーマ別に配置されます。 • データ形式は ETL 処理を使用して均一に統合されます （「抽出、変換、およびロードのプロセス」（4 ページ）を 参照） 。 • データ履歴は長期間（通常は 2 ～ 5 年）にわたります。 • データ ウェアハウスには、既存の運用システムから ETL プロセスを使用してデータが移入されます（「抽出、変 換、およびロードのプロセス」（4 ページ）を参照）。 ウェアハウス内のデータの構造、およびデー データ タ構造と MicroStrategy 環境との関係は、論理データ モデルと物理ウェアハウス スキーマを通じて定義し、 理解できます。プロジェクトの論理データ モデルと 物理ウェアハウス スキーマを定義することは、 MicroStrategy プロジェクト用のデータを用意するため の重要なステップです。プロジェクト デザイン プロ セスのステップの詳細は、2 章、「論理データ モデル」 および 3 章、「論理データ モデルのウェアハウスの構 造」を参照してください。 代替データ ソースによるデータの格納と分析 データ ウェアハウスとして一般的なリレーショナル データ ベースとの統合に加え、MicroStrategy はさまざまな代替デー タ ソースとも統合できます。代替データ ソース としては、 MicroStrategy でクエリ、レポーティング、および分析に使用 されるデータを格納するファイル、システム、または格納場 所が使用可能です。データ ウェアハウスはデータ ソースの 一種と考えることができますが、より具体的に、データ ソースとして使用されるデータベースを意味します。 MicroStrategy と統合できる各種の代替データ ソースを次に 示します。 6 ビジネス インテリジェンスのアーキテクチャ © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド MicroStrategy プラットフォームの BI アーキテクチャ 1 • MDX キューブ ソース :MicroStrategy は、SAP BW、 Microsoft Analysis Services、および Hyperion Essbase の データ セットと統合できます。これらのデータ ソースは MDX キューブ ソースと総称されます。MicroStrategy は、 リレーショナル データベースに効果的にアクセスしなが ら、同時にこれらのデータ ソースと統合できます。 MicroStrategy で MDX キューブ ソースに接続し、統合す る方法の詳細は、『MicroStrategy MDX Cube Reporting Guide』を参照してください。 • テキスト ファイルと Excel ファイル :MicroStrategys のフ リーフォーム SQL 機能とクエリ ビルダ機能によって、 テキスト ファイルや Excel ファイルに格納されている データを対象に、クエリ、分析、およびレポートを実行 できます。上記の MDX キューブ ソースの場合と同様、 MicroStrategy はこれらの代替データ ソースに関するレ ポートを作成しながら、並行してリレーショナル データ ベースにアクセスし、すべてのデータを 1 つのプロジェ クトに完全に統合できます。フリーフォーム SQL 機能と クエリ ビルダ機能でテキスト ファイルと Excel ファイル を使用する方法の詳細は、『MicroStrategy 上級レポー ティング ガイド』を参照してください。 MicroStrategy プラットフォーム ビジネス インテリジェンス プラットフォームは、ビジネス インテリジェンス アプリケーションを作成、配布、サポー ト、および保守するために必要なすべてのツールを提供しま す。MicroStrategy プラットフォームの主要コンポーネントの いくつかを次に示します。 • 「MicroStrategy メタデータ」（9 ページ）- MicroStrategy オ ブジェクトの定義と、データ ウェアハウスに関する情報 を格納するリポジトリ。 • 「MicroStrategy Intelligence Server」（11 ページ）- エンター プライズ クエリ、レポーティング、および OLAP 分析に 最適化された分析サーバ ° • 「MicroStrategy Desktop」（12 ページ）- レポートの配布を 円滑化するように設計された分析関数を幅広く網羅した、 高度な Windows ベースの環境。 © 2010 MicroStrategy, Inc. MicroStrategy プラットフォーム 7 1 MicroStrategy プラットフォームの BI アーキテクチャ プロジェクト デザイン ガイド • 「MicroStrategy Web および MicroStrategy Web Universal」 （13 ページ）- レポーティングと分析のための高度な対話 型ユーザ環境。保守の必要性を抑えたインタフェースで す。 • 「MicroStrategy プロジェクト」 （14 ページ）- MicroStrategy 環境のレポートなどのアプリケーション オブジェクトを 作成するために必要なすべてのスキーマ オブジェクトと 情報を作成し、格納する場所です。MicroStrategy 環境と の組み合わせで、柔軟性に優れたレポーティング環境が 提供されます。 • 「MicroStrategy Architect」（16 ページ）- 一元管理された インタフェースからプロジェクトに必要なすべてのコン ポーネントを定義できるプロジェクト デザイン ツール。 MicroStrategy プラットフォームの各コンポーネントは、次の 図に示すように互いに連携して機能し、分析とレポーティン グのための環境をユーザ コミュニティに提供します。 以下の項では、これらの各コンポーネントの概要を簡単に示 します。これらのコンポーネントなど、MicroStrategy プラッ トフォームを構成しているコンポーネントの詳細は、 『MicroStrategy 導入と構成ガイド』を参照してください。 8 MicroStrategy プラットフォーム © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド MicroStrategy プラットフォームの BI アーキテクチャ 1 MicroStrategy プラットフォームを管理および調整する方法を 学ぶには、『MicroStrategy システム管理ガイド』を参照して ください。 MicroStrategy メタデータ MicroStrategy メタデータ は、MicroStrategy オブジェクトの 定義と、データ ウェアハウスに関する情報を格納するリポ ジトリです。情報はリレーショナル データベースに独自形 式で格納されます。メタデータは、レポートの作成とデータ 分析に使用される MicroStrategy オブジェクトを、データ ウェアハウスの構造とデータにマップします。メタデータに は、テンプレート、レポート、メトリック、ファクトなど、 MicroStrategy Desktop および MicroStrategy Web で作成された すべてのオブジェクトの定義も格納されます。 通常、MicroStrategy でのレポート作成では、データを表すさ まざまな種類のオブジェクトを、レポートの構築ブロックと して使用します。MicroStrategy では、基本的に種類が異なる 複数のオブジェクトを作成して操作できます。それらのオブ ジェクトについて、以下に説明します。いずれのオブジェク トもメタデータ リポジトリ内に作成され、格納されます。 • 構成オブジェクト - 接続、ユーザ権限、およびプロジェ クト管理に関する重要情報や適用パラメーターを提供す るオブジェクト。データベース インスタンス、ユーザ、 グループなど。これらのオブジェクトは、レポーティン グに直接使用されることはありませんが、プロジェクト の設計者や管理者によってプラットフォームの構成と管 理のために作成されます。基本的なルールとして、構成 オブジェクトは MicroStrategy Desktop で、[ 管理 ] アイ コン内にあるマネージャによって作成され、保守されま す。構成オブジェクトの作成と管理の詳細は、 『MicroStrategy システム管理ガイド』を参照してくださ い。 • スキーマ オブジェクト - アプリケーションで、テーブ ル、ビュー、列などのデータベース オブジェクトに対応 するために作成されるオブジェクト。スキーマ オブジェ クトには、ファクト、アトリビュート、階層、その他 MicroStrategy Desktop のフォルダ リスト内の [ スキーマ オブジェクト ] フォルダに格納されるオブジェクトが含 まれます。ファクトとアトリビュート、および階層は、 © 2010 MicroStrategy, Inc. MicroStrategy プラットフォーム 9 1 MicroStrategy プラットフォームの BI アーキテクチャ プロジェクト デザイン ガイド すべてのビジネス インテリジェンス アプリケーションに 不可欠な要素です。これらのスキーマ オブジェクトは通 常、MicroStrategy の設計者によって作成、管理されます。 ファクト : データ ウェアハウスから得られた数値デー タを、MicroStrategy のレポーティング環境に関連付け ます。ファクトはメトリック（レポートに表示される 分析計算）の作成に使用されます。売上数量はファク トの一例です。ファクトの詳細は、6 章、「ビジネス データの構築ブロック : ファクト」で説明します。 アトリビュート : ファクト データに関連するビジネス コンテキストを表します。たとえば、南東部の地域売 上では、南東部が売上データのアトリビュート（コン テキスト）になります。アトリビュートは、レポート の数値データを表示するレベルの定義に使用されま す。アトリビュートの詳細は、7 章、「ビジネス デー タのコンテキスト : アトリビュート」で説明します。 階層 : 表示にアトリビュート間の関係が反映されるよ うに、複数のアトリビュートをグループ化したオブ ジェクト。このグループ化は、データのレポーティン グと分析の際に、アトリビュート間の論理接続を作成 するために役立ちます。階層の最も一般的な例として は、" 年 "、" 月 "、" 四半期 " などのアトリビュート を含む時間階層があります。階層の詳細は、8 章、 「アトリビュートの構成とブラウズを行うための階層 の作成」で説明します。 • アプリケーション オブジェクト - 関連データの分析と考 察に使用されるオブジェクト。アプリケーション オブ ジェクトには、レポート、ドキュメント、フィルタ、 テンプレート、カスタム グループ、メトリック、および プロンプトがあります。アプリケーション オブジェクト は、スキーマ オブジェクトを構築ブロックとして使用し て作成されます。すべてのアプリケーション オブジェク トの作成と保守は、MicroStrategy Desktop で行います。 レポートとドキュメントは、MicroStrategy Web でも作成 および管理できます。アプリケーション オブジェクトの 作成については、 『基本レポーティング ガイド』および 『MicroStrategy 上級レポーティング ガイド』を参照してく ださい。 Web の詳細は、 「MicroStrategy Web お MicroStrategy よび MicroStrategy Web Universal」（13 ページ）を 参照してください。 10 MicroStrategy プラットフォーム © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド MicroStrategy プラットフォームの BI アーキテクチャ 1 メタデータはすべてのオブジェクト定義の一元的なリポジト リとして、複数の MicroStrategy アプリケーション間でのオ ブジェクトの共有を可能にします。MicroStrategy Intelligence Server が最も効率的なデータ呼び出しのシナリオを評価し、 優れたクエリのパフォーマンスを実現します。 MicroStrategy のメタデータは、MicroStrategy アプリケー ション使用時のデータ ウェアハウスからのデータ呼び出し も円滑化します。ユーザ要求はメタデータによって SQL ク エリに変換され、SQL クエリの結果も、分析と理解が容易 になるように、メタデータによってレポートやドキュメント などの MicroStrategy オブジェクトに変換されます。 MicroStrategy Intelligence Server MicroStrategy Intelligence Server は、エンタープライズ クエ リ、レポーティング、および OLAP 分析に最適化された分 析サーバです °MicroStrategy Intelligence Server の重要な機能 には、以下のものがあります。 • オブジェクトの共有 • データの共有 • 管理されたセキュアな環境でのデータとオブジェクトの 管理および共有 • メタデータ内の情報の保護 MicroStrategy Intelligence Server は、150 個を超える複雑な数 学関数と統計関数を含むライブラリも備えています。また、 独自の関数を追加および定義することもできます。これらの 関数の詳細は、『MicroStrategy Functions Reference』を参照し てください。 MicroStrategy Intelligence Server のインストール方法および構 成方法は、『MicroStrategy 導入と構成ガイド』を参照してく ださい。MicroStrategy Intelligence Server の機能と推奨される 調整の詳細は、『MicroStrategy システム管理ガイド』を参照 してください。 © 2010 MicroStrategy, Inc. MicroStrategy プラットフォーム 11 1 MicroStrategy プラットフォームの BI アーキテクチャ プロジェクト デザイン ガイド MicroStrategy Desktop MicroStrategy Desktop は、レポートの配布を円滑化するよう に設計された分析関数を幅広く網羅した、高度な Windows ベースの環境です。MicroStrategy Desktop はプロジェクト デ ザイナに、MicroStrategy Desktop、MicroStrategy Web の両方 のユーザ コミュニティに役立つスキーマ オブジェクトとア プリケーション オブジェクトを作成するために必須の機能 を提供します。 MicroStrategy Desktop では、直感的なグラフィカル インタ フェースを使用してアプリケーションをモデル化できます。 また、ビジネス インテリジェンス プロジェクトを作成およ び保守するための統合環境が提供されます。ビジネス情報の 表示やデータのモデル化の方法を変更する必要があるとき、 Desktop ではアプリケーションの一面を、その他の面に影響 を与えることなく変更することができます。 Desktop では、レポート、フィルタ、メトリックなどのアプ リケーション オブジェクトを管理できます。ただし、アプ リケーション オブジェクトを作成する前に、スキーマ オブ ジェクトを先に作成する必要があります。スキーマ オブ ジェクトによって、アプリケーション オブジェクトはデー タ ウェアハウスと連携し、分析するデータにアクセスでき るようになります。ファクト、アトリビュート、階層、およ びその他のスキーマ オブジェクトは、レポートやドキュ メントなどのアプリケーション オブジェクトの構築ブロッ クです。たとえば、ファクトはメトリックの作成に使用さ れ、メトリックはレポートのデザインに使用されます。レ ポートなどのアプリケーション オブジェクトは、関連デー タの分析と考察のために使用されます。 そのほかにも MicroStrategy Desktop では、機能の 1 つとして プロジェクトを作成できます。プロジェクトについては、4 章、「プロジェクトの作成および構成」で説明します。 MicroStrategy Desktop でビジネス インテリジェンス アプリ ケーションをモデル化する方法を、次に例を通じて示しま す。 • 12 MicroStrategy プラットフォーム すべてのレポートやクエリは、アプリケーションに含め るテーブルのメリットを自動的に享受します。 MicroStrategy 内のテーブルはデータ ウェアハウス内の テーブルへの参照であるため、MicroStrategy 内のテーブ ルにアクセスすることでデータにアクセスできます。 © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド MicroStrategy プラットフォームの BI アーキテクチャ • 1 ビジネス階層の構造は、並び替えによって変更できます。 そのような変更は、階層に新しいレベルのデータを追加 したり、特定のデータ レベルを削除する要件が生じたと きに必要になります。この変更はアプリケーション内で、 データベースにはいっさい変更を加えることなく、自動 的に有効になります。 レポートの作成後、レポートのデザイナとアナリストは MicroStrategy Desktop、MicroStrategy Web、MicroStrategy Office など、異なるインタフェースを通じて、作成したレ ポートを配布できます。 MicroStrategy Desktop を構成している各種のコンポーネント については、『MicroStrategy 導入と構成ガイド』を参照して ください。 MicroStrategy Desktop でレポートなどのアプリケーション を 作成する方法の詳細は、『MicroStrategy 基本レポーティング ガイド』を参照してください。より高度な Desktop の機能に ついては、『MicroStrategy 上級レポーティング ガイド』を参 照してください。 MicroStrategy Web および MicroStrategy Web Universal ユーザは、MicroStrategy Web から提供された高度な対話型 環境および保守作業の少ないインタフェースを使用してレ ポート作成および分析を行えます。Web インタフェースに より、ユーザはさまざまなオペレーティング システムで任 意の Web ブラウザを使用して、データへのアクセス、分析、 および共有を行うことができます。MicroStrategy Web では、 アドホックなクエリ、業界最先端の分析、短時間での配布、 および迅速なカスタマイズが可能であるため、ユーザは情報 に基づくビジネス上の意思決定を簡単に実現できます。 MicroStrategy Web Universal は、以下の項目をサポートする ように拡張された MicroStrategy Web のバージョンです。 © 2010 MicroStrategy, Inc. • オペレーティング システム（Sun Solaris™、IBM AIX®、 Red Hat® Linux®、HP-UX など） • アプリケーション サーバ（BEA WebLogic™、IBM WebSphere®、Sun ONE®、Oracle®、Apache Tomcat など） MicroStrategy プラットフォーム 13 1 MicroStrategy プラットフォームの BI アーキテクチャ • プロジェクト デザイン ガイド MicroStrategy Web でサポートされているすべての Web サーバおよびブラウザ Web 製品を使用してデータ ウェアハ MicroStrategy ウスから情報を取得するには、MicroStrategy Intelligence Server が動作している必要があります。 MicroStrategy Web の配布の詳細は、 『MicroStrategy 導入と構成ガイド』を参照してください。 プロジェクト関連の用語を含む、その他の MicroStrategy の 「プロジェクトの接続コンポーネント」 （74 定義については、 ページ）で説明します。 MicroStrategy プロジェクト プロジェクト とは、MicroStrategy 環境のレポートなどのア プリケーション オブジェクトを作成するために必要なすべ てのスキーマ オブジェクトと情報を作成し、格納する場所 です。プロジェクトと MicroStrategy 環境を組み合わせるこ とでで、柔軟性に優れたレポーティング環境が提供されま す。プロジェクトは、データ ソース、メタデータ リポジト リ、およびユーザ コミュニティが交差する部分でもありま す。MicroStrategy Desktop では、プロジェクトはフォルダ リ スト内でプロジェクト ソースの 1 レベル下に表示されます。 プロジェクトは、以下の特徴があります。 • 使用されるデータ ウェアハウス テーブルを決定します。 したがって、分析できる範囲を決定します。 • これらのテーブルのデータの解釈に使用される、すべて のスキーマ オブジェクトを含みます。スキーマ オブジェ クトには、ファクト、アトリビュート、階層などがあり ます。スキーマ オブジェクトについては、このガイドの 次章以降で説明します。 • レポートの作成およびデータ分析に使用されるすべての レポーティング オブジェクトを含みます。レポーティン グ オブジェクトには、メトリック、フィルタ、レポート などがあります。レポート オブジェクトについては、 『MicroStrategy 既存レポーティング ガイド』および 『MicroStrategy 上級レポーティング ガイド』で説明してい ます。 14 MicroStrategy プラットフォーム © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド MicroStrategy プラットフォームの BI アーキテクチャ • 1 これらのオブジェクトにアクセスするユーザ コミュニ ティのセキュリティ スキーマを定義します。セキュリ ティ オブジェクトには、セキュリティ フィルタ、セキュ リティ ロール、権限、アクセス コントロールなどがあり ます。セキュリティおよびその他のプロジェクト レベル の管理機能については、『MicroStrategy システム管理ガイ ド』で説明しています。 プロジェクトには任意の数のレポートのほか、シンプルなレ ポーティングおよび高度なレポーティングの要件をサポート するその他多数のオブジェクトを含めることができます。概 念的には、プロジェクトはすべての関連レポートが実行され る環境です。プロジェクトには、アトリビュートやファクト などのスキーマ オブジェクトで作成できるフィルタ、プ ロンプト、メトリック、レポートといったアプリケーション オブジェクトなど、さまざまな種類のオブジェクトを含める ことができます。 プロジェクトは通常、データ ウェアハウスから得られた データを、ユーザ要件に合致する関連データの集まりに分割 する手段として使用されます。たとえば、1 つのプロジェク ト ソースは、人事、販売流通、在庫、顧客満足度という 4 つの分析領域に応じて、4 つの異なるプロジェクトに分割す ることができます。これにより、人事部門の全ユーザは人事 プロジェクトを使用し、興味の対象外である在庫データを見 る必要がなくなります。 プロジェクトの作成に着手する前に理解すべき、いくつかの 主な概念を次に示します。 • プロジェクトは指定されたメタデータ リポジトリ内に作 成されます。このメタデータ リポジトリは、プロジェク トの作成に使用するプロジェクト ソースによって決定さ れます。 • プロジェクトのウェアハウスの場所は、プロジェクトを 該当するデータベース インスタンスと関連付けることに よって指定します。 これらの概念に関連する手順は、 「プロジェクトの作成」 （81 ページ）で説明します。 © 2010 MicroStrategy, Inc. MicroStrategy プラットフォーム 15 1 MicroStrategy プラットフォームの BI アーキテクチャ プロジェクト デザイン ガイド MicroStrategy Architect MicroStrategy 9.0 では、Architect と呼ばれる新しいプロジェ クト デザイン ツールが導入されました。Architect を使用す ると、一元管理されたインタフェースからプロジェクトの必 須コンポーネントをすべて定義できます。また、Architect を 使用すると、プロジェクトを作成しながらそのプロジェクト を視覚的に表現できるため、ワークフローを直感的に捉える ことができます。Architect によるプロジェクトの作成と変更 は、4 章、「プロジェクトの作成および構成」および 5 章、 「Architect によるプロジェクトの作成」で説明します。 プロジェクトのデザイン プロセス MicroStrategy Desktop でプロジェクトを作成するときには複 数の接続を作成します。その 1 つがプロジェクトとデータ ウェアハウス間の接続です。この接続を作成すると、ウェア ハウス内の列とテーブルを基に、プロジェクト内にスキーマ オブジェクトを作成できます。次の図は、データのモデリン グ、スキーマのデザインと実装、およびプロジェクトの作成 16 プロジェクトのデザイン プロセス © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド MicroStrategy プラットフォームの BI アーキテクチャ 1 の概要を示しています。これらのステップについては、次章 以降で説明します。 プロジェクトのデザイン プロセスにフィードバック ループ が含まれていることに注意してください。プロジェクトのデ ザインが、1 本の直線的なプロセスになることは、まずあり ません。プロジェクトが配布され、テストされるに伴い、 ユーザから新しい要求が寄せられ、プロジェクトを拡張する ために、プロジェクトの初期デザインに変更が必要になりま す。プロジェクトのデザインでは、このことに留意して、次 の開発フェーズの計画を立てることが重要です。 © 2010 MicroStrategy, Inc. プロジェクトのデザイン プロセス 17 1 MicroStrategy プラットフォームの BI アーキテクチャ 18 プロジェクトのデザイン プロセス プロジェクト デザイン ガイド © 2010 MicroStrategy, Inc. 2 2. 論理データ モデル ビジネス モデルとレポート対象データの概 念化 はじめに ビジネス データのモデルを考案することは、データの構造 と、そのさまざまな部分の相互関係を分析するうえで役立 ち、さらにデータから何を得るかを決定するためにも役立ち ます。 この章では、データ モデリングの主要コンポーネントの 1 つである論理データ モデルについて説明します。論理デー タ モデル とは、一般のユーザやビジネス アナリストの観点 に立ったデータの論理的な配置のことです。これは、データ ベースを効率的に使用できるようにデータを配置する物理 データ モデルやウェアハウス スキーマとは異なります。論 理データ モデルは、ビジネス環境でのデータのフローと構 造を視覚的に表し、データを異なるビジネス上の観点から分 析できるように構成する手段を提供します。 © 2010 MicroStrategy, Inc. 19 2 論理データ モデル プロジェクト デザイン ガイド 論理データ モデルの概要 論理データ モデルは概念的には、地図と日程表を持って旅 に出ることに似ています。目的地がどこであり、どのように して目的地に行くかを知る必要があります。また、計画を視 覚的な計画として、正しくレイアウトすることも必要です。 たとえば、小売業者の簡単な論理データ モデルでは、小売 業界関連の最も一般的なビジネス上の観点である店舗、製 品、および時間ごとに、必要なすべてのファクトを編成でき ます。 論理データ モデルは、物理的なデータ格納デバイスに依存 しません。これは論理データ モデルのもっとも重要な概念 です。論理データ モデルをテクノロジに依存させてはなら ない理由は、テクノロジが急速に変化しているからです。論 理データ モデルの下で生起することがニーズやテクノロジ によって変わることがあっても、骨子は変化しないため、完 全に最初からやり直す必要はありません。 データ モデリングに詳しい方 マルチディメンション には、論理データ モデリングはマルチディメン ション データ モデリングに似ているとも言うことが できます。MicroStrategy プラットフォームではディ メンションを明示的に定義する必要がないため、「論 理的」の方が「マルチディメンション」より表現とし ては的確です。マルチディメンション データ モデル には少なくとも 1 つのディメンションが必要ですが、 論理データ モデルには、明示的に定義されたディ メンションは特に必要ではありません。 論理データ モデルの範囲と複雑さは、ユーザ コミュニティ が必要とするレポートの要件と、利用可能なソース データ に左右されます。レポート要件とソース データが複雑で高 度になるほど、論理データ モデルも複雑になります。 20 論理データ モデルの概要 © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド 論理データ モデル 2 論理データ モデリングのプロセスでは、次に示すような図 が作成されます。 論理データ モデルは、技術的または概念的な、あるいはビ ジネス環境におけるデータの定義と特性、および関係を表し たものです。このプロセスは、企業のビジネス データを構 成しているさまざまなエレメントと、それらの間の関係を考 えるうえで役立ちます。 ビジネス インテリジェンス環境の論理データ モデルを考案 することで、ビジネス データをデータ ウェアハウスに物理 的に格納するさまざまな方法を考えることができます。これ © 2010 MicroStrategy, Inc. 論理データ モデルの概要 21 2 論理データ モデル プロジェクト デザイン ガイド は通常、次の図に示すようにプロジェクト デザインの最初 のステップの 1 つです。 この章では、論理データ モデルとその中に存在するエレ メントの概念的情報を提供し、論理データ モデルを作成す るための一般的な手順とガイドラインを示します。 論理データ モデルは、次の概念の視覚的表現です。 • 「ファクト : ビジネスのデータと測定値」（22 ページ） • 「アトリビュート : データのレベルを表すコンテキスト」 （24 ページ） • 「階層 : データ関係の組織化」（26 ページ） ファクト : ビジネスのデータと測定値 論理データ モデルを作成するときに最初に行うべきことの 1 つは、ファクトの特定です。概念的には、ファクトは通常、 数値として集計に適しているビジネスの測定値、データ、ま たは変数と考えることができます。たとえば、売上や在庫、 22 ファクト : ビジネスのデータと測定値 © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド 論理データ モデル 2 口座残高は、ビジネスの測定値として使用できるファクトで す。 ファクトによって、データ ウェアハウス内のデータへのア クセスが可能になります。ユーザが必要とする分析やレポー トの大部分は、ファクトがその土台を形成します。 MicroStrategy では、ファクトはデータ ウェアハウスから MicroStrategy のレポーティング環境にデータ値（通常は数値 データ）を関連付けるスキーマ オブジェクトです。 ファクトは、データへの洞察を得る元になるビジネスの測定 値やメトリックの作成に使用される構築ブロックです。デー タ モデルの残りの大部分は、ファクトによってアクセス可 能になるデータのコンテキストを提供します。 データ ウェアハウス内では、ファクトはファクト テーブル の列として存在します。これらの列の値は、複数の異なる ソース システムから取得されたり、詳細レベルが互いに異 なる場合があります。たとえば、1 つのシステムから売上 データを取得して毎日記録する一方で、株式と在庫のデータ は別のシステムから取得し、週 1 回ずつ記録する場合などで す。 の観点では、ファクトは通常、SQL 集計（SUM、 SQL AVG など）を実行するデータベース テーブル内の数 値列です。 たとえば、次の SQL ステートメントでは、ウェアハ ウス内の ORDER_AMT 列は、MicroStrategy 環境の " 注 文金額 " ファクトに相当します。 SELECT sum(a21.ORDER_AMT) EMP_NAME FROM ORDER_FACT a21 JOIN LU_EMPLOYEE a22 ON (a21.EMP_ID = a22.EMP_ID) WHERE a22.CALL_CTR_ID in (5, 9, 12) 付け加えれば、ORDER_AMT はファクトですが、 sum(a21.ORDER_AMT) はメトリックです。メト リックは通常、ファクトを使用して構築されるビジネ ス計算です。メトリックの詳細は、『MicroStrategy 基 本レポーティング ガイド』を参照してください。 ファクトについては、6 章、「ビジネス データの構築ブロッ ク : ファクト」で、より詳しく説明しています。 © 2010 MicroStrategy, Inc. ファクト : ビジネスのデータと測定値 23 2 論理データ モデル プロジェクト デザイン ガイド アトリビュート : データのレベルを表す コンテキスト ファクトの決定後は、アトリビュートを特定します。アトリ ビュートとは、ファクトに関する質問に答えることを可能に するものであり、ファクトのレポーティングや分析のための コンテキストを提供します。 たとえば、会社の売上額について考えてみましょう。会社の 売上が 10,000 ドルだと知らされても、それ自体はほとんど 有用ではありません。この値を意味あるものにするには、次 のような売上額のソースについて、より良く知る必要があり ます。 • 売上に要した期間 • 売上総額に誰が、および何人が貢献したか • どの部門のどの製品が売れたか • 売上の範囲（国内、地域、地区、店舗など） アトリビュートは、データを容易に要約して条件付けするた めのコンテキストとレベルを提供し、上記のような質問に答 えやすくします。アトリビュートは、ファクトに関するビジ ネス上の質問に、さまざまな詳細レベルで答えるために使用 されます。たとえば、売上データを日単位で格納している場 合、" 月 " アトリビュートを使用すれば、同じ売上データを 月単位で要約して見ることができます。 の観点では、アトリビュートは通常、データ SQL ベース テーブル内の数値以外の、集計不能な列に相 当します。そのような列は、ファクト データへの条 件付けとグループ化に使用されます。 たとえば、次の SQL ステートメントでは、ウェアハ ウス内の MONTH_ID 列は、MicroStrategy 環境の " 月 " アトリビュートに相当します。 SELECT a11.MONTH_ID MONTH_ID, max(a12.MONTH_DESC) MONTH_DESC, sum(a11.TOT_DOLLAR_SALES) DLRSALES FROM MNTH_CATEGORY_SLS a11 join LU_MONTH a12 on (a11.MONTH_ID = a12.MONTH_ID) 24 アトリビュート : データのレベルを表すコンテキスト © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド 論理データ モデル 2 WHERE a11.MONTH_ID in (200201,200202,200203) GROUP BY al1.MONTH_ID アトリビュート フォームには、特定のアトリビュートに関 する追加説明情報が含まれています。アトリビュート フォームについては、「アトリビュート フォーム」（38 ペー ジ）で論理データ モデルの観点から説明します。 アトリビュートについての詳細は、7 章、「ビジネス データ のコンテキスト : アトリビュート」を参照してください。 アトリビュート エレメント : データのレベル値 アトリビュート エレメント とは、1 つのアトリビュートを 構成する一意の値または内容です。たとえば、"2005" およ び "2006" は " 年 " アトリビュートのエレメントであり、 "New York" および "London" は " 都市 " アトリビュートのエ レメントです。レポートでは、レポートを作成するためにア トリビュートが使用され、アトリビュート エレメントは実 行されたレポートの行または列に表示されます。 アトリビュート エレメントは、データに条件を適用し、特 定の結果を得るためにも使用できます。たとえば、" 顧客 " アトリビュートでは売上データを顧客単位で見ることができ ますが、" 顧客 " アトリビュートのエレメントで条件付けれ ば、姓が「h」で始まる顧客グループの売上データを見るこ とが可能です。 次の図に、アトリビュートとアトリビュート エレメントの いくつかの例を示します。 © 2010 MicroStrategy, Inc. アトリビュート : データのレベルを表すコンテキスト 25 2 論理データ モデル プロジェクト デザイン ガイド アトリビュートのエレメントを認識して理解すれば、データ モデルとプロジェクトをより適切にデザインできます。アト リビュート エレメントは論理データ モデルには含まれま せんが、アトリビュート関係を理解するうえで必要です。 アトリビュート エレメントの詳細は、「アトリビュート情報 の一意のセット : アトリビュート エレメント」（242 ページ） で説明します。 アトリビュート関係 MicroStrategy で効果的なプロジェクトを作成するには、プロ ジェクトに含めるすべてのアトリビュートと、それらのアト リビュート間の関係を確実に理解する必要があります。 アトリビュート関係 とは、アトリビュート間の関係と、ア トリビュート間の接続情報の指定であり、論理データ モデ ルに欠かせないものです。アトリビュート関係がなければ データ間の連携は存在せず、論理構造も存在しません。アト リビュート関係は、ビジネス ルールに基づくアトリビュー ト間の論理関係を提供することにより、データに意味を付与 します。 アトリビュート間の直接的な関係には、常に親と子という 2 つの部分が存在します。子は常に 1 つの親を持ち、親は複数 の子を持つ場合があります。親アトリビュートは、子より上 位の論理レベルに位置します。たとえば、" 年 " と " 四半期 " の関係では、" 年 " が親アトリビュート、" 四半期 " が子ア トリビュートになります。 アトリビュート間には関係がある場合と、関係がない場合が あります。関係のあるアトリビュートと関係のないアトリ ビュートの例、およびアトリビュート関係の詳細について は、「アトリビュート関係」（265 ページ）を参照してくださ い。 階層 : データ関係の組織化 論理データ モデル内の階層は、アトリビュート間の関係を 反映するように配置され、秩序付けられたアトリビュートの グループのことです。通常、論理的なビジネス領域に合わせ 26 階層 : データ関係の組織化 © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド 論理データ モデル 2 てアトリビュートを配置またはグループ化すると、最適なデ ザインの階層が得られます。たとえば、" 年 "、" 月 "、" 日 " の各アトリビュートをグループにして、" 時間 " 階層を形成 できます。 論理データ モデルの階層には、直接的な相互関係があるア トリビュートが含まれます。1 つの階層内のアトリビュート と、他の階層内のアトリビュートの間には、直接的な関係は 存在しません。 たとえば、" 年 " アトリビュートと " 四半期 " アトリビュー トは通常、相互に直接関係しています。1 年間には複数の四 半期があり、どちらのアトリビュートも " 時間 " 階層に含ま れます。 " 年 " アトリビュートと " 顧客 " アトリビュートは通常、同 じ階層には含まれず、直接的な相互関係もありません。ただ し、特定の年における顧客の購入に関する情報を示すレポー トを作成する場合は、これら 2 つのアトリビュートを何らか の方法で関連付ける必要があります。" 年 " と " 顧客 " は ファクトを通じて関係します。" 時間 " 階層を " 顧客 " 階層 に関連付けるのは、ファクトの存在です。この場合は、顧客 の購入がファクトになります。 したがって、ファクトは階層間の交差部に存在します。ファ クトは複数のアトリビュートによって識別され、それらのア トリビュートが、ファクトが格納されるレベルを表します。 ファクト、アトリビュート、および階層がどのように関係し て、論理データ モデルの全体を形成しているかを示す図が、 次の「データ モデルの一例」（27 ページ）にあります。 階層については、8 章、「アトリビュートの構成とブラウズ を行うための階層の作成」で詳しく説明します。 データ モデルの一例 すべてのコンポーネント（ファクト、アトリビュート、関 係、および階層）を 1 つの図に配置すると、論理データ モ デルが大まかに形成されます。 © 2010 MicroStrategy, Inc. データ モデルの一例 27 2 論理データ モデル プロジェクト デザイン ガイド 次の図は、論理データ モデルの一例です。 論理データ モデルの作成 論理データ モデルを作成する前に、デザインに影響を与え るファクタについて検討する必要があります。論理データ モデルを作成する際に考慮すべきファクタとして、たとえば 次の項目が挙げられます。 • 「ユーザのニーズ」 • 「既存のソース システム」 • 「ソース データから分析データへの変換」 ユーザのニーズ 論理データ モデルを作成する主目標は、ユーザのレポート ニーズに応えることです。そのようなモデルの作成では、次 の活動を行います。 28 論理データ モデルの作成 • ユーザのニーズの特定 • ソリューションのデザイン © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド 論理データ モデル • 2 ソリューションの評価 論理データ モデルの作成には繰り返しが伴います。論理 データ モデルの草案ができるたびに、新しい疑問と懸念点 が生まれるからです。 ユーザ コミュニティに属する人々のニーズはさまざまに異 なっています。たとえば、一般に企業の経営陣は全般的な傾 向に関心を持ち、企業全体にわたって集計された長期的な データのレポートを必要とします。一方、管理職は自分の責 任範囲のデータに興味を持つ傾向があります。そのような管 理職は、担当している特定地域のレポートを必要としている かもしれません。レポートの対象期間も、短期の場合もあれ ば、長期にわたる場合も考えられます。 論理データ モデルを作成するときには、ユーザの多様性を 考慮し、さまざまに異なるニーズにどのように対応するかを 考えなければなりません。ソース システム内のデータが不 十分で、対応できるユーザのニーズが限られる場合もありま す。ユーザのニーズに広く応えるため、「既存のソース シス テム」（29 ページ）で説明するように、ソース システム内に 存在しない追加データを得ることもできます。 ユーザのニーズは、プロジェクト デザインの初期プロセス における重要な要素です。ただし、プロジェクトの配布後に ユーザが拡張領域を見るにつれ、ユーザのニーズが新たに判 明することもあります。新たに判明したニーズによっては、 ユーザが必要とする種類のデータの分析や呼び出しにより良 く対応するため、論理データ モデルの変更が必要になる場 合もあります。 既存のソース システム 利用可能なデータを把握することは、論理データ モデルの 作成における重要なステップです。通常は、多数のファクト とアトリビュートで構成される十分な量のデータが存在し、 ユーザ コミュニティの意思決定を支援するうえで、既存 データ内のどのファクトとアトリビュートが必要であるかを 特定する必要があります。 データの確認は、最初に論理データ モデルのコンポーネン トを識別するときに役立ちますが、ニーズに対応するために 必要なすべてのファクトとアトリビュートがデータ内に常に 存在しているとは限りません。既存のデータから多くのファ © 2010 MicroStrategy, Inc. 論理データ モデルの作成 29 2 論理データ モデル プロジェクト デザイン ガイド クト、アトリビュート、および関係が示唆されますが、適切 な論理データ モデルを作成する作業のかなりの部分は、 ユーザ コミュニティのニーズを満たすために必要な追加 コンポーネントの特定に充てられます。 たとえば、保険会社のトランザクション システムに顧客お よび都市の単位でデータが記録されているとき、ビジネス アナリストは州や地域ごとのデータを見たいと考えるかもし れません。この場合、既存のソース データ内に州と地域が 存在しないため、他のソースから抽出する必要があります。 また、ソース システム内に日単位のデータが格納されてい るときに、月や年単位のデータも見たいと望むユーザがいる かもしれません。この場合には、データ モデル内にアトリ ビュートを追加することによって、ファクトを分析するレベ ルを追加することが可能です。 ソース システム内に存在しないデータがあっても、それを データ モデルに含めてはならない理由にはなりません。逆 に、ソース データ内のデータを、論理データ モデルにすべ て含める必要もありません。何を含め、何を含めないかは、 ユーザのニーズに基づいて決定します。 ソース データから分析データへの変換 システムがまだ存在しておらず、データ ウェアハウスの計 画に着手したばかりの段階であれば、現在のユーザ ニーズ を大幅に反映した論理データ モデルを作成することが可能 です。ただし、既存のシステムの開発と実装がいったん完了 すれば、ほとんどの論理モデルの作成は、ソース データの 確認から開始することになります。ソース データには通常、 なんらかの文書化された物理構造が存在します。たとえば、 ほとんどの OLTP システムにはエンティティ関係図（ERD） があります。ERD とは、ソース システム内のデータの物理 構造を視覚的に表現したものであり、これによりテーブルと 列、および列に含まれるデータを容易に識別できます。 モデルは、概念的には ERD に似ていま 論理データ す。ただし、このガイドで言及している論理データ モデルには、データを MicroStrategy に統合して、ビ ジネス インテリジェンス ソリューションを開発する ための方法も勘案されます。 30 論理データ モデルの作成 © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド 論理データ モデル 2 既存のソース システムが存在しない場合、既存のソース シ ステムを使用する場合のどちらでも、論理データ モデルは 次の手順で作成します。 • 「ステップ 1: ファクトの特定」（31 ページ） • 「ステップ 2: アトリビュートの特定」（32 ページ） • 「ステップ 3: アトリビュート関係の特定」（33 ページ） • 「ステップ 4: 階層の定義」（34 ページ） システム これらのステップの詳細は、既存のソース の使用に左右されます。 ステップ 1: ファクトの特定 既存のデータを使用して、MicroStrategy でファクトとして表 現できるすべてのデータのリストを作成します。ファクトは 計算可能で、売上や利益など、通常は集計可能な数値である ことに留意してください。すべてのファクトのリストを作成 した後、それぞれのファクトを記録するビジネス レベルを 決定します。たとえば、小売モデルの売上ファクトは通常、 店舗、品目、または日付のレベルで格納されます。これらの レベルは、それぞれ特定の店舗、品目、または日付の売上を 意味します。一方、製品在庫ファクトは、地域、品目、また は週のレベルで格納できます。これらのビジネス レベルが、 論理データ モデル内のアトリビュートになります（「ステッ プ 2: アトリビュートの特定」（32 ページ）を参照）。 © 2010 MicroStrategy, Inc. 論理データ モデルの作成 31 2 論理データ モデル プロジェクト デザイン ガイド ステップ 2: アトリビュートの特定 レポートに表示するファクトのレベルを考慮して、アトリ ビュートを特定します。各ファクトをどのレベルで記録する かを検討し、そこから構築に着手します。 たとえば、既存データ内に日単位だけで記録されるファクト が存在しているとします。ところが、ユーザは日以外のレベ ルでデータを分析することにも興味を持っており、年、月、 および週単位でデータを見ることも望んでいます。この事実 はプロジェクトの配布後に、ようやく表面化するかもしれま せん。しかも、ユーザの多くが売上データを年単位で見てい ることが判明したとします。この分析を行うには、 MicroStrategy で日レベルの売上データを年レベルに集計する 必要があります。パフォーマンスを改善しながら大部分の ユーザのニーズに応える手段として、年レベルの売上データ を格納する集計テーブルを追加する方法があります（「要約 テーブルを使用するデータの保存 : 集計テーブル」（368 ページ）を参照）。その後、プロジェクトの " 年 " アトリ ビュートをデザインします。場合によっては、プロジェクト 配置後に確認されたユーザ要件に対する処置として、この方 法が取られることがありますが、このような事項は、プロ ジェクト デザインの初期段階で考慮に入れておく必要があ ります。 必要以上のファクトとアトリビュートを含めないよう に注意してください。通常、ソース システム内のす べてのデータを分析環境に取り込む必要はありま せん。ユーザ コミュニティに役立つファクトとアト リビュートだけを含めるようにしてください。論理 データ モデルの作成は繰り返しを伴なうプロセスで 32 論理データ モデルの作成 © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド 論理データ モデル 2 あり、必要になったらいつでもアトリビュートとファ クトを追加することができます。 ステップ 3: アトリビュート関係の特定 MicroStrategy でアトリビュートとして定義するデータを特定 したら、続いてアトリビュート間の関係を特定する必要があ ります。たとえば、Sales Force Analysis Module では、商談情 報が " 商談 " アトリビュートと共に格納されますが、このア トリビュートは " 商談終了日 "、" 商談開始日 "、" 主な競合 会社 " などのアトリビュートと直接関係しています。これら のアトリビュートは、いずれも商談情報に関する質問に答え るものであり、すべて " 商談 " アトリビュートに関係してい ます。 さらに、関係の種類も決定する必要があります。たとえば、 以下の図では "Year"（年）と "Month"（月）の間に 1 対多関 係があり、"Month"（月）は "Day"（日）との間に 1 対多関 係があります。この 1 対多関係は、すべての年に複数の月が 存在し、すべての月に複数の日が存在することを示していま す。視点を逆にすると、この関係は（12/01/2005 のような形 式の）複数の日付に対応する（Dec 2005 のような形式の） 月が 1 つだけ存在し、複数の月に対応する年が 1 つだけ存在 することを示します。 この例は、作業対象のプロジェクトでの時間情報の保 存方法を正確に定義していない可能性があります。た とえば、"Year"（年）アトリビュートと "Month"（月） アトリビュート間の関係について考えてみましょう。 © 2010 MicroStrategy, Inc. 論理データ モデルの作成 33 2 論理データ モデル プロジェクト デザイン ガイド 仮に "Month" アトリビュートを単なる月の名前 （Dec、Jan など）として定義して、年（Dec 2005、Jan 2006 など）に直接接続しなければ、両者の関係は 1 対多ではなく、多対多になります。 既存データに関するドキュメント（ERD など）をお持ちで あれば、データの特徴と固有の関係について、ドキュメント で詳しい情報が得られる場合があります。 アトリビュート関係については、 「アトリビュート関係」 （26 ページ）で詳しく説明します。 ステップ 4: 階層の定義 階層はデータの構造を提供し、ユーザが関連するアトリ ビュートを容易かつ直感的にブラウズして、レポートに含め るために役立ちます。論理データ モデルのコンテキストで は、階層はアトリビュートをビジネス領域ごとに論理的に配 置したものと考えることができます。たとえば、時間に関係 するすべてのアトリビュートは、"Time"（時間）階層に編成 できます。同様に、顧客関連のすべてのアトリビュートは " 顧客 " 階層に、仕入先データに関連するすべてのアトリ ビュートは " サプライヤ " 階層に、それぞれ含めることがで きます。 作成する階層の数は、データの複雑さとビジネスの特 徴によって非常に少ない場合もあれば、多くなる場合 もあります。すべてのデータが直接関係しており、1 つの大きな階層だけになることもありえます。必要な 34 論理データ モデルの作成 © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド 論理データ モデル 2 階層を決める場合も、ユーザ コミュニティのニーズ が判断材料になります。 論理データ モデルの表記法 論理データ モデルの作成時には、さまざまな表記法を使っ て論理データ モデルの効果を高めることができます。表記 法には、次のものが含まれます。 • 「一意の識別子」 • 「カーディナリティと比率」 • 「アトリビュート フォーム」 これらの論理モデルの表記法は、システムの最適化機会の手 がかりとなり、システムの保守に役立ち、論理データ モデ ルの堅牢性を高めます。十分に最適化され、保守されたシス テムから最大の恩恵を受けるのはユーザ コミュニティです が、これらの表記法は主にプロジェクトのデザイナ、管理 者、および熟練したレポート デザイナを対象としています。 それぞれの表記法が、データに関する追加情報を論理データ モデルに付与します。この追加情報は、システムについて学 ぶときに特に役立ちます。 © 2010 MicroStrategy, Inc. 論理データ モデルの表記法 35 2 論理データ モデル プロジェクト デザイン ガイド 一意の識別子 論理データ モデルの表記法の 1 つは、個々のアトリビュー トとファクトに対する一意の識別子の付与です。該当する場 合、一意の識別子によって、アトリビュートをソース シス テム内のソース データにマップするキーが表されます。こ の情報は、物理ウェアハウス スキーマ内で主キーを定義す るときに役立ちます（「キー構造によるテーブル内のデータ の一意な識別」（44 ページ）を参照）。 ファクトは通常、複数のアトリビュートによって識別される ため、一意の識別子を複数持つことに注意してください。次 の図は、一意の識別子を付与した論理データ モデルを示し ています。アトリビュートによっては、そのエレメントの識 別に複数の ID 列を必要とする場合もあります。たとえば、 "Item"（品目）アトリビュートのエレメントを一意に識別す るには、Item_ID 列と Class_ID 列の両方が必要です。 36 論理データ モデルの表記法 © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド 論理データ モデル 2 カーディナリティと比率 論理データ モデルのもう 1 つの表記法が、各アトリビュー トへのカーディナリティと比率の付与です。カーディナリ ティは、1 つのアトリビュート内の一意なエレメントの数を 意味します。比率は、互いに関係するアトリビュート間の カーディナリティの比率です。 カーディナリティは、データベース管理者がデータ ウェア ハウスのサイズを予測するときに役立ちます。また、 MicroStrategy でユーザが階層内のデータをナビゲートする場 合の最適な経路を、プロジェクト デザイナが決定する際に も利用できます（8 章、「アトリビュートの構成とブラウズ を行うための階層の作成」を参照）。比率は、どこで集計 テーブルを作成すれば最も効果的であるかを決定するとき に、特に役立ちます。データベース管理者とプロジェクト デザイナは、この追加情報を極めて効果的に利用できます。 次の図は、カーディナリティと比率を含む論理データ モデ ルを示しています。カーディナリティはアトリビュートを示 す長方形の右上、比率は一部のアトリビュート関係の横に示 されています。"Date of Birth"（誕生日）など一部のアトリ ビュートのカーディナリティが不明になっていることにも着 目してください。これは、情報が不定で予測できないためで © 2010 MicroStrategy, Inc. 論理データ モデルの表記法 37 2 論理データ モデル プロジェクト デザイン ガイド す。たとえば、誕生日の異なる顧客が何名、ウェアハウスに 含まれているかを特定することは不可能です。 アトリビュート フォーム 論理データ モデルにアトリビュート フォームを含めると、 プロジェクトで利用可能なすべての情報を、より包括的に把 握することができます。 アトリビュート フォーム には、特定のアトリビュートを説 明する追加情報が含まれます。たとえば、システム内の顧客 を表すアトリビュートとして " 顧客 " を作成し、それを " 顧 客 " 階層に含めたとします。" 顧客 " アトリビュート内の 個々のエレメントが、それぞれ異なる顧客を表します。さら に、データには顧客に関する次の情報を格納します。 38 論理データ モデルの表記法 • 顧客番号（顧客の一意な識別に使用される数値コード） • 名 © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド 論理データ モデル • 姓 • 住所 • メール アドレス 2 これらの情報は、いずれも "Customer"（顧客）アトリビュー トと 1 対 1 関係にある別のアトリビュートとして、論理デー タ モデルに含めることが可能です。ところが実際には、こ れらのアトリビュートは "Customer"（顧客）アトリビュート に関する追加情報を提供するものに過ぎず、"Customer"（顧 客）階層内で異なるレベルを構成するものではありません。 アトリビュートとその説明の間に 1 対 1 関係が存在する場 合、それらの説明情報はアトリビュート フォームとしてモ デル化できます。次の図は、アトリビュート フォームを追 加した論理データ モデルを示しています。 フォームについては、「列データの説 アトリビュート 明と識別子 : アトリビュート フォーム」（248 ページ） で、MicroStrategy におけるロールの観点から説明しま す。 © 2010 MicroStrategy, Inc. 論理データ モデルの表記法 39 2 論理データ モデル 40 論理データ モデルの表記法 プロジェクト デザイン ガイド © 2010 MicroStrategy, Inc. 3 3. 論理データ モデルのウェア ハウスの構造 物理ウェアハウス スキーマ はじめに 直前の章で説明したように、論理データ モデルはビジネス データの論理構造と、その情報の中に存在する多くの関係に ついて考察するときに役立ちます。 物理ウェアハウス スキーマ とは、論理データ モデルに基づ き、データ ウェアハウスに格納されているビジネス データ を詳しく、かつ視覚的に表現したものです。物理ウェアハウ ス スキーマは、データベースの観点から意味のある方法で 論理データ モデルを編成します。 モデルは、一般的なユーザ これに対して論理データ やビジネス アナリストの視点からデータを論理的に 配置したものです。論理データ モデルとその作成方 法についての詳細は、2 章、「論理データ モデル」を 参照してください。 論理データ モデルは、"Day"（日）、"Item"（品目）、"Store" （店舗）、"Account"（口座）など、ビジネス モデルの論理オ ブジェクトだけを対象としています。物理ウェアハウス ス キーマは、1 つの論理データ モデルから複数、得られる場合 があります。スキーマの構造は、論理オブジェクトを表して © 2010 MicroStrategy, Inc. 41 3 論理データ モデルのウェアハウスの構造 プロジェクト デザイン ガイド いるデータが、ウェアハウス内にどのように格納されるかに 左右されます。たとえば、複数の論理オブジェクトは、すべ て同じテーブルに格納したり、それぞれ別のテーブルに格納 したり、あるいは複数のテーブルに複製して格納できるほ か、それ以外の配置で格納することもできます。 論理データ モデルは作成すべきファクトとアトリビュート を示しますが、物理ウェアハウス スキーマは、それらのオ ブジェクトに対応するデータをどこに格納するかを示しま す。物理ウェアハウス スキーマは、データがデータ ウェア ハウス内に格納される方法と、格納されたデータを分析用に 呼び出す方法を示します。 次に示すように、物理ウェアハウス スキーマの作成は、プ ロジェクト作成前に行うビジネス データの編成の第 2 ス テップです。 物理ウェアハウス スキーマを構成する主要なコンポーネン トは、列とテーブルです。 物理ウェアハウス スキーマ内の列とテーブルは、それぞれ 論理データ モデルのファクトとアトリビュートに基づいて います。テーブル内の行は、アトリビュートのエレメントと ファクトのデータを表します。 42 © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド 論理データ モデルのウェアハウスの構造 3 列 : データの識別子と値 ウェアハウス内の列 には、アトリビュートとファクトの データが含まれます。列には以下の種類があります。 • ID 列 には、アトリビュート エレメントの識別コードが 含まれます。通常、これらのコードは数値です。コン ピュータが数値を文字列より速く処理できるからです。 すべてのアトリビュートには ID 列が 1 つ必要です。 • 説明列 には、アトリビュート エレメントの説明（文字列 または数値）が含まれます。説明列は省略可能です。 ID 列は ID と説明の両方の用途に使用できます。たとえ ば、"Date"（日付）アトリビュートには通常、説明列は ありません。 通常、大部分のアトリビュートには ID 列が 1 つ、説明列 が少なくとも 1 つ存在します。アトリビュートに多数の アトリビュート フォーム（特定アトリビュートに関する 追加説明情報）がある場合、それらは追加された説明列 として表されます。 • ファクト列 にはファクト データが含まれます。 テーブル : 関連するデータの物理的なグ ループ化 テーブルには次の種類があります。 • 「ルックアップ テーブル : アトリビュートの格納場所」 （45 ページ） • 「関係テーブル : アトリビュート間の関係付けの特殊な ケース」（47 ページ） • 「ファクト テーブル : ファクト データと集計レベル」 （48 ページ） データ ウェアハウス内でのテーブルの機能は種類ごとに異 なりますが、どの種類のテーブルにも、テーブル内のエレ メントを一意に識別する主キーを割り当てることができま す。 © 2010 MicroStrategy, Inc. 列 : データの識別子と値 43 3 論理データ モデルのウェアハウスの構造 プロジェクト デザイン ガイド キー構造によるテーブル内のデータの一意な識別 リレーショナル データベースでは、すべてのテーブルに主 キーが 1 つ存在しており、このキーによってデータ レコー ドや行を識別する一意の値が作成されます。これはデータ ウェアハウス内のすべてのテーブルに、テーブルの種類に関 係なく当てはまります。 テーブルには次の種類のキーを割り当てることができます。 • シンプル キー : 1 つの列だけでテーブル内のレコードを 一意に識別します。 • 複合キー : 複数の列を使用してレコードを一意に識別し ます。 テーブル内のアトリビュートを一意に識別するために使用す るキーの構造は、データとビジネス ニーズの性質によって 決まります。次の図は、それぞれのキー構造によるコール センタの識別のしくみを示しています。 シンプル キーの場合は、Call_Ctr_id だけでコール セン タが識別されています。これは、すべてのコール センタに 一意の ID があることを意味します。 複合キーの場合は、Call_Ctr_id と Region_id でコール センタが識別されています。これは、違う地域にあるコール センタ間で Call_Ctr_id の値が同じになる場合があるこ とを意味します。たとえば、A 地域のコール センタと B 地 域のコール センタの ID がどちらも 1 のような場合です。そ の場合は Call_Ctr_id と Region_id の両方を知らなけれ ば、コール センタを一意に識別することはできません。 通常、データ ウェアハウス内での取り扱いはシンプル キー の方が複合キーよりも容易です。使用する格納領域がより少 なく、より簡単な SQL で操作できるからです。複合キーは SQL クエリを複雑化し、クエリ時間が長くなり、必要な格 納領域も大きくなる傾向があります。ただし、複合キーの方 が ETL プロセスの効率は向上します。 44 テーブル : 関連するデータの物理的なグループ化 © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド 論理データ モデルのウェアハウスの構造 3 特定のアトリビュートにどちらのキー構造を使用するかは、 完全にデータとシステムの性質によって決まります。物理 ウェアハウス スキーマでルックアップ テーブルを作成する ときには、どちらのキー構造が適しているかを考慮してくだ さい。 ルックアップ テーブル : アトリビュートの格納場所 ルックアップ テーブル は、アトリビュートの物理的表現で す。ルックアップ テーブルによって、データをさまざまな レベルで集計することが可能になります。ルックアップ 「列 : テーブルは、アトリビュートの情報を ID 列と説明列（ データの識別子と値」（43 ページ）を参照）に格納します。 物理スキーマの編成方法により、ルックアップ テーブルに は 1 つのアトリビュート、または複数の関連するアトリ ビュートの情報を格納できます。1 つのアトリビュートの データだけを格納するテーブルは、正規化 テーブルと呼ば れます。複数のアトリビュートのデータを格納するテーブル は、非正規化 テーブルと呼ばれます。 次の図は、同じアトリビュート情報の編成が、テーブルの種 類によってどのように異なるかを示しています。非正規化 テーブルに格納されているデータと、正規化テーブルに格納 されているデータが、完全に同じであることに着目してくだ さい。非正規化テーブルではアトリビュートに関するすべて 情報が 1 つのテーブルに格納されているのに対し、正規化 © 2010 MicroStrategy, Inc. テーブル : 関連するデータの物理的なグループ化 45 3 論理データ モデルのウェアハウスの構造 プロジェクト デザイン ガイド テーブルではアトリビュートに関するすべての情報のサブ セットが、各テーブルに格納されています。 どちらの構造も、ウェアハウス スキーマ内のすべてのテー ブルに使用できますが、それぞれの構造には以下の項および 表「各種スキーマの比較」（62 ページ）に示す長所と欠点が あります。 アトリビュート関係とルックアップ テーブルの構 造 アトリビュート関係は、物理ウェアハウス スキーマ内の ルックアップ テーブルの構造を決定する主要ファクタの 1 つです。アトリビュート関係の一般的なガイドラインを次に 示します。 • 1 対 1 関係は通常、アトリビュート フォームが存在して いることを示します。アトリビュート フォームの説明列 は、そのアトリビュートのルックアップ テーブルにその まま列として追加します。 • 多対多関係は通常、どのアトリビュートのルックアップ テーブルとも別の関係テーブルを使用する必要がありま す。関係テーブルには、関係する 2 つのアトリビュート の ID 列を含めます。関係テーブルの使用方法の詳細は、 「関係テーブル : アトリビュート間の関係付けの特殊な ケース」（47 ページ）を参照してください。 46 テーブル : 関連するデータの物理的なグループ化 © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド 論理データ モデルのウェアハウスの構造 3 関係テーブル : アトリビュート間の関係付けの特殊な ケース アトリビュートに関する情報を格納するルックアップ テー ブルに対し、関係テーブルには 2 つのアトリビュート間の関 係に関する情報が格納されます。関係テーブルは 2 つ以上の アトリビュートの ID 列を含み、それらのアトリビュート間 の関係を定義します。関係テーブルは通常、多対多関係にあ るアトリビュート間の関係の作成に使用されます。 アトリビュート間に直接的な 1 対多関係があり、親アトリ ビュートの各エレメントと、子アトリビュートの複数のエレ メントの間に関係が存在しうる場合は、親アトリビュートの ID 列を子アトリビュートのルックアップ テーブル内に配置 して親子関係を定義します。子テーブル内の親の ID 列は外 部キーと呼ばれます。この手法によって、アトリビュートの ルックアップ テーブル内でアトリビュート間の関係を定義 できるため、次の図に示すようにルックアップ テーブルが 関係テーブルの機能も兼ねるようになります。 多対多関係の場合（親アトリビュートの複数のエレメント と、子アトリビュートの複数のエレメントとの間に関係が存 在する場合）は、次の図に示すように関係テーブルを別に作 成する必要があります。 © 2010 MicroStrategy, Inc. テーブル : 関連するデータの物理的なグループ化 47 3 論理データ モデルのウェアハウスの構造 プロジェクト デザイン ガイド ファクト テーブル : ファクト データと集計レベル ファクト テーブル は、ファクト データの格納に使用されま す。ファクト値にはアトリビュートによってコンテキストが 付与されるため、ファクト テーブルにはファクト列とアト リビュート ID 列の両方が含まれています。ファクトは、間 接的に関係しているアトリビュート間の関連付けに役立ちま す。ファクト テーブルに含まれているアトリビュート ID 列 は、そのテーブル内のファクトが格納されているレベルを表 します。 たとえば、売上と在庫のデータを含むファクト テーブルは、 次の図のテーブルのようになります。 ファクト データの集計レベルの詳細は、「ファクト テーブル のレベル : データのコンテキスト」（50 ページ）を参照して ください。 48 テーブル : 関連するデータの物理的なグループ化 © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド 論理データ モデルのウェアハウスの構造 3 基本ファクト列と派生ファクト列 ファクト列には、基本ファクト列と派生ファクト列という 2 つの種類があります。 • 基本ファクト列は、ファクト テーブル内で 1 つの列とし て表されます。次の図は、基本ファクト列を含むファク ト テーブルを示しています。 • 派生ファクト列は、他の既存ファクト列を数学的に組み 合わせて作成されます。次の図はファクト テーブルの一 例と、基本ファクト列から派生ファクト列を作成する方 法を示しています。 この例の派生ファクト "Tot_Dollar_Sales" は、ファクト 列 Qty_Sold、Unit_Price、および Discount を使用し て作成されます。また、派生ファクトは複数のテーブル （Item_Mnth_Sls および City_Ctr_Sls）内に存在してい ます。 © 2010 MicroStrategy, Inc. テーブル : 関連するデータの物理的なグループ化 49 3 論理データ モデルのウェアハウスの構造 プロジェクト デザイン ガイド ファクト テーブルが異なれば、その中に格納されている ファクトのレベルも通常は異なるため、派生ファクト列に含 めることができるファクト列は、同じファクト テーブルか ら得られたものだけです。 派生ファクト列を作成すべきかどうか検討する際には、長所 と欠点を考慮すべきです。派生ファクト列をウェアハウスに 格納すると、データの計算があらかじめ実行され、データと は別に格納されます。その結果、より簡単な SQL で操作で きるため、レポート実行時のクエリが高速化されます。ただ し、派生ファクト列は ETL プロセスで、より多くの格納領 域と処理時間を要します。 同様のデータ分析は、MicroStrategy でメトリックを使用して 作成できます。メトリックを使用すれば、1 つ以上のファク ト列から得られたファクト データの計算と集計を実行でき ます。メトリックの説明と作成方法については、 『MicroStrategy 上級レポーティング ガイド』を参照してくだ さい。 MicroStrategy の各種ファクトの詳細と定義方法については、 「ファクトの定義」（198 ページ）を参照してください。 ファクト テーブルのレベル : データのコンテキスト ファクトとファクト テーブルには、ファクト テーブル内の アトリビュート ID 列に基づいて関連付けられたレベルがあ ります。次の図は、品目、日、およびコール センタのレベ ルを持つ 2 つのファクトを示しています。 このテーブルの列 Item_id、Day_id、および Call_Ctr_id は、売上と在庫のデータをレポートで実用的 に分析できるレベルを表しています。"Sales"（打ち上げ） ファクトと "Inventory"（在庫）ファクトは、ファクト テー ブル内の ID 列に存在するレベル（品目、日、コール セン タ）で分析できます。 50 テーブル : 関連するデータの物理的なグループ化 © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド 論理データ モデルのウェアハウスの構造 3 ファクト テーブルには、必要以上のルックアップ列 ID を含 める必要はありません。たとえば、上図のテーブルには、 Customer_id 列は含まれていません。これは、在庫データ を顧客レベルで分析しても、実用的なビジネス計算にならな いからです。ファクト テーブルには、特定のファクト デー タの分析に使用するレベルを表すアトリビュート ID 列だけ を含めるべきです。 ファクトが格納されるレベルは、複数のテーブル内に互いに 異なるレベルで格納されている複数のファクトに対し、複雑 なクエリを実行するようになったとき、およびレポート要求 に異なるレベルが含まれる場合に、特に重要になります。 ファクト レポートは、ユーザが必要とするビジネス レベル で作成されなければなりません。 異種の列名と同種の列名 データ ウェアハウスに 2 つのソース システムから取り込ま れた情報が含まれており、次の図に示すように一方のソース システムでは Region_id 列で地域が識別され、もう一方の ソース システムでは Reg_id 列で識別されるとします。こ のような名前の不一致は、ソース システムで収集したデー タに名前を付ける規則が異なっているからです。 Region_id 列と Reg_id 列は、名前は異なっていますが、 格納するデータはどちらも地域に関する情報です。このよう な列名は、異種の列名 と呼ばれます。 © 2010 MicroStrategy, Inc. テーブル : 関連するデータの物理的なグループ化 51 3 論理データ モデルのウェアハウスの構造 プロジェクト デザイン ガイド Lookup_Region テーブルと Lookup_Call_Ctr テーブル のデータは互いに異なるソース システムから得られており、 これらのソース システムは互いに異なる名前付け規則を使 用しています。この理由により、地域に関する同じ情報が、 名前の異なる 2 つの列で表されています。 MicroStrategy Desktop でファクトとアトリビュートを定義す るときには、異種の列名がソース システムに存在する可能 性を考慮してください。正確で不足のないレポートの結果を 得るためには、異種の列名を対応するファクトとアトリ ビュートにマップする必要があります。 たとえば、上の例のテーブルに "Region"（地域）アトリ ビュートを作成する場合には、このアトリビュートが使用さ れるときに、地域に関するすべての情報が正しく計算され、 レポートに表示されるように、Region_id 列と Reg_id 列 の両方を "Region" アトリビュートにマップする必要があり ます。 整合性を確保するためにも、複数の列が同じデータを格納す る場合には、それらの列に同じ名前を付けるのが適切です。 そのような列名は、同種の列名と呼ばれます。この場合は次 の図に示すように、両方のテーブルの列名を「Region_ID」 にします。 同じアトリビュート データが複数の異なるルックアップ テーブル内に存在することがあるように、同じファクト データが複数の異なるファクト テーブル内に存在すること 52 テーブル : 関連するデータの物理的なグループ化 © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド 論理データ モデルのウェアハウスの構造 3 もありえます。次の図に示すように、同じファクト列の名前 がテーブルごとに異なる可能性もあります。 スキーマの種類 : データ呼び出しのパ フォーマンスと冗長格納 データ ウェアハウスの構造はさまざまな方法で構築可能で あり、絶対的に正しい（または正しくない）方法というもの は存在しません。適切なウェアハウスの構造は、データの性 質、利用可能な格納領域、およびユーザ コミュニティの ニーズに左右されます。通常は、許容限度以上のデータ格納 領域を確保しながらクエリのパフォーマンスを高めるため に、いずれかの種類のスキーマか、それらの組み合わせが使 用されます。スキーマには次の種類があります。 • 「高度に正規化されたスキーマ : 最小限の格納領域」 • 「中度正規化スキーマ : 格納領域とクエリ パフォーマン スのバランス」 • 「高度に非正規化されたスキーマ : 高いクエリ パフォー マンス」 どの種類のスキーマでも、1 つの基本ファクト テーブルと任 意の数の集計ファクト テーブルが使用されます（集計ファ クト テーブルの詳細は、「要約テーブルを使用するデータの © 2010 MicroStrategy, Inc. スキーマの種類 : データ呼び出しのパフォーマンスと冗長格納 53 3 論理データ モデルのウェアハウスの構造 プロジェクト デザイン ガイド 保存 : 集計テーブル」（368 ページ）を参照）。ファクト テー ブルのキーは、そのテーブルに格納されているデータのレベ ルに対応するアトリビュート キーで構成されます。以下の スキーマ例は、品目、コール センタ、および日付のレベル でデータを表示します。 種類が異なるスキーマを比較するときには、次の概念を留意 してください。 • データの重複は、いくつかの欠点の原因になります。最 も明らかな欠点は、データの重複のないシステムに比べ、 同じ量のデータを保持するために必要な格納領域が大き くなることです。 また、重複するデータが複数の場所に存在するため、 データの更新がより負荷の大きい、困難なプロセスにな ります。データに重複がなければ、1 つの場所にある データを更新するだけです。 • 結合は、2 つのテーブルを結合してデータを呼び出すた めに必要な SQL 操作です。この操作は必要ですが、デー タ ウェアハウスに対して実行する他の処理と同様、クエ リに含める結合の数は、クエリのパフォーマンスに影響 を与えます。 • 以下の項では、すべての種類のスキーマが網羅されてい るわけではありません。これらの項は、物理ウェアハウ ス スキーマの開発で、最も一般的に使用されるスキーマ の種類について説明しています。 高度に正規化されたスキーマ : 最小限の格納領域 次の図は、高度に正規化されたスキーマ の一例です。高度 に正規化されたスキーマでは、次の図の Call_Ctr_id、 Dist_Ctr_id、および Region_id のように、ルックアッ プ テーブルに開発者がデザインした一意のアトリビュート キーが含まれます。また、Call_Ctr_desc、 Dist_Ctr_desc、および Region_desc のようなアトリ ビュートの説明列も含まれます。アトリビュートのルック アップ テーブルには、さらに親アトリビュートの ID 列 54 スキーマの種類 : データ呼び出しのパフォーマンスと冗長格納 © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド 論理データ モデルのウェアハウスの構造 3 （Lookup_Call_Ctr テーブルの Dist_Ctr_id など）も含 まれています。 © 2010 MicroStrategy, Inc. スキーマの種類 : データ呼び出しのパフォーマンスと冗長格納 55 3 論理データ モデルのウェアハウスの構造 プロジェクト デザイン ガイド 次の図は、物理ルックアップ テーブルがウェアハウス内で どのように見えるかを示しています。 高度に正規化されたスキーマを使用する利点の 1 つは、使用 するルックアップ テーブルが他の種類のスキーマに比べ小 さいため、ウェアハウス内に必要な格納領域が最低限で済む ことです。 ただし、データ ウェアハウス内で小さなテーブルだけを使 用する方法には欠点もあります。上図の Lookup_Region のような上位レベルのルックアップ テーブルにアクセスす るときには、情報を呼び出すために多数の結合操作が必要に なります。各テーブルには、特定のアトリビュートに関する 限られた情報しか格納されていないため、必要な列が見つか るまで複数のテーブルを結合する必要があるからです。 中度正規化スキーマ : 格納領域とクエリ パフォーマンス のバランス 次の図は、中度正規化スキーマの一例を示しています。この スキーマの基本的な構造は、高度に正規化されたスキーマと 同じです。ただし、このスキーマでは、関連するアトリ 56 スキーマの種類 : データ呼び出しのパフォーマンスと冗長格納 © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド 論理データ モデルのウェアハウスの構造 3 ビュートの各テーブルに、上位レベルのアトリビュートの ID 列が存在しています。たとえば、Lookup_Call_Ctr テーブルには、Region_id が含まれています。 中度正規化スキーマのファクト テーブルの構造は、高度に 正規化されたスキーマのものと同じです。次の図は、物理 © 2010 MicroStrategy, Inc. スキーマの種類 : データ呼び出しのパフォーマンスと冗長格納 57 3 論理データ モデルのウェアハウスの構造 プロジェクト デザイン ガイド ルックアップ テーブルがウェアハウス内でどのように見え るかを示しています。 中度正規化スキーマは、正規化スキーマと非正規化スキーマ の長所と短所のバランスが取れたスキーマです。アトリ ビュートの親とその親の両方の ID 列が複数のテーブル内に 存在するため、アトリビュートの情報の呼び出しに必要な結 合操作の数が少なくなります。 ただし、一部のテーブルは同じ ID 列を含む（上の例では Region_ID 列）ため、このスキーマのテーブルはウェアハ ウス内で、ある程度の格納領域を冗長に使用します。 高度に非正規化されたスキーマ : 高いクエリ パフォー マンス 次の図は、高度に非正規化されたスキーマ の一例です。高 度に非正規化されたスキーマも、基本的な構造は他の 2 種類 のスキーマと同じです。このスキーマでは、上位レベル ア トリビュートの ID 列が、関係するすべてのテーブルに存在 するだけでなく、説明列も存在します。たとえば、 58 スキーマの種類 : データ呼び出しのパフォーマンスと冗長格納 © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド 論理データ モデルのウェアハウスの構造 3 Lookup_Call_Ctr テーブルには、Region_desc が含ま れています。 高度に非正規化されたスキーマを使用すると、アトリビュー トの説明を呼び出すために必要な結合の数がさらに少なくな ります。たとえば、コール センタ、配送センタ、地域、およ びドル単位での売上を 1 つのレポートに含めても、結合する のは Lookup_Call_CTR テーブルと Fact_Sales テーブル だけです。これは、Lookup_Call_CTR 列にコール センタ、 配送センタ、および地域に必要なすべてのデータ（説明デー タを含む）が格納されているからです。 ただし、高度に非正規化されたスキーマではルックアップ テーブルが大きいため、ウェアハウス内に必要な格納領域が 最も大きくなります。さらに、このスキーマではデータの重 複度も最も高くなります。 © 2010 MicroStrategy, Inc. スキーマの種類 : データ呼び出しのパフォーマンスと冗長格納 59 3 論理データ モデルのウェアハウスの構造 プロジェクト デザイン ガイド スター スキーマ : ルックアップ テーブルの統合 高度に非正規化されたスキーマでは、以下の図に示すよう に、ルックアップ テーブルが非常に少なくなる場合があり ます。この方法でウェアハウス スキーマを編成したのが、 スター スキーマです。スター スキーマでは、特定階層のア トリビュート ID と説明列がすべて 1 つのテーブル内に存在 するようにルックアップ テーブルが統合されます。 高度に非正規化されたスキーマでは、各階層（"Geography" など）は複数のルックアップ テーブルから構成されます。 それに対してスター スキーマでは、次に示すように、特定 階層のすべてのアトリビュート ID 列と説明列が 1 つのルッ クアップ テーブルに含まれます。 他のスキーマと同様、スター スキーマにも長所と欠点があ ります。スター スキーマでは、高度に非正規化されたス キーマと同じように結合操作の数が少なくなります。さら に、高度に非正規化されたスキーマに比べ、必要な格納領域 を減らすことができる場合もあります。ただし、スター ス キーマには通常、大きなルックアップ テーブルが必要なた め、より小さいテーブルを使用する他のスキーマに比べ、検 索時間が長くなる可能性があります。 60 スキーマの種類 : データ呼び出しのパフォーマンスと冗長格納 © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド 論理データ モデルのウェアハウスの構造 3 デザインのバランス 論理データ モデルと物理ウェアハウス スキーマの作成は、 見直しを繰り返し、長所と短所のバランスを探るプロセスで す。次の図は、効果的なシステムを作成するためにバランス を取るべき主な 3 つのファクタを示しています。 いずれのファクタも、残りのファクタに影響を与えます。 ユーザのニーズを簡単なものから複雑なものまで完全に満た そうとすると、多方面を包括するデータ モードとスキーマ を作成しなければなりません。そうするとウェアハウスの負 荷が増大し、クエリのパフォーマンスが低下し、データベー ス管理者の保守の手間も大きくなってしまいます。ご自身の 環境でどのファクタが最も重要であるかを見極め、そのファ クタと他のファクタの比重を決定する必要があります。 たとえば、スター スキーマでデータを収容するために十分 な格納領域がある場合は、正規化スキーマを採用しようとは 思わないかもしれません。ところが、1 つに統合されたテー ブルに対する SQL クエリには DISTINCT 演算子を使用する 必要があり、そのようなクエリはデータベース リソースへ の負荷と処理時間の面で、非常にコストが大きくなります。 リソース負荷の大きい DISTINCT クエリを使用すると、上 位レベルのルックアップ テーブル間の結合が少ないという 利点は打ち消されます。 © 2010 MicroStrategy, Inc. デザインのバランス 61 3 論理データ モデルのウェアハウスの構造 プロジェクト デザイン ガイド 上記の点に加え、上位レベルのルックアップ テーブルで集 計テーブルを活用する必要があるかもしれません（集計テー ブルについては、「要約テーブルを使用するデータの保存 : 集計テーブル」（368 ページ）を参照）。 この章で説明した各種スキーマ間の比較については、「各種 スキーマの比較」（62 ページ）で詳しく説明します。 各種スキーマの比較 スキーマ デザインでさまざまな長所と欠点のバランスを取 る方法の 1 つとして、物理ウェアハウス スキーマで各種の スキーマを併存させるやり方があります。たとえば、いずれ か 1 つの階層を高度に正規化し、他の 1 つを高度に非正規化 します。1 つの階層内で複数の異なるスキーマを使用するこ ともできます。次の表に、各種のスキーマの比較を示しま す。 スキーマの種類 ルックアップ テーブ メリット ルの構造 デメリット 高度に 正規化されたス キーマ • アトリビュート ID • アトリビュート の説明列 • 親の ID 列 必要な格納領域が最小限。 データの重複も最小限である ため、データ更新の負荷が他 のスキーマより小さい。 上位レベルのルックアップ テーブルから情報を呼び出す には多数の結合が必要。 中度正規化ス キーマ • アトリビュート ID • アトリビュート の説明列 • 親の ID 列 • 親の親の ID 列 高度に正規化されたスキーマ に比べ、アトリビュートを親 の親に関連付けるために必要 な結合の数が大幅に少ない。 ある程度の冗長格納が必要。 62 各種スキーマの比較 © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド スキーマの種類 論理データ モデルのウェアハウスの構造 ルックアップ テーブ メリット ルの構造 高度に非正規化 されたスキーマ • アトリビュート ID • アトリビュート の説明列 • 親の ID 列 • 親の説明列 • 親の親の ID 列 • 親の親の説明列 スター スキー マ • 階層全体を 1 つ のルックアップ テーブルに統合 する。 中度正規化スキーマに比べ、 アトリビュートの説明を呼び 出すために必要な結合の数が さらに少ない。 • 中度正規化スキーマに比 べ、アトリビュートの説明 を呼び出すために必要な結 合の数がさらに少ない。 • 必要な格納領域とデータの 重複は、高度に非正規化さ れたスキーマに比べれば少 ないため、データの更新も 比較的容易。 3 デメリット 必要な格納領域が最も大きく、 データが重複しているため、 より負荷の大きい更新処理が 必要。 ルックアップ テーブルのサイ ズが大きいため、テーブルの 検索時と DISTINCT 操作が必 要なときに、クエリのパ フォーマンスが低下する場合 がある。 データのモデル化とファクトおよびアトリビュートの役割に ついては、すでに学んでいただきました。ここでは、同じス キーマ オブジェクトについて、MicroStrategy 環境でどのよ うに存在するか、という視点から説明します。ファクトとア トリビュートは MicroStrategy を使用して作成するレポート の基礎であり、プロジェクトの作成前に、これらの各スキー マ オブジェクトの構造を理解することが不可欠です。 データの国際化のサポート MicroStrategy は、データをユーザに必要な言語にする国際化 をサポートしています。これにより、ユーザの言語ニーズに 応じて、データをさまざまな言語で表示できます。 データをさまざま言語で提供するには、翻訳したデータを データベース内に含める必要があります。翻訳したデータを データベースに含める戦略は、多くのファクタに左右されま す。国際化が MicroStrategy プロジェクトでサポートされ、 容易にプロジェクトに統合できるような戦略を定義するに は、次のガイドラインが役立ちます。 • 「テーブルと列またはデータベースを通じた国際化」（64 ページ） © 2010 MicroStrategy, Inc. データの国際化のサポート 63 3 論理データ モデルのウェアハウスの構造 プロジェクト デザイン ガイド • 「データベース内のさまざまな文字セットのサポート」 （69 ページ） MicroStrategy での国際化全般の概要については、『システム 管理ガイド』を参照してください。 テーブルと列またはデータベースを通じた国際化 MicroStrategy は、2 種類の手法による国際化をサポートして います。翻訳したデータを、テーブルと列を追加して提供す る手法と、個別のデータベースに格納する手法です。それぞ れの手法について、以下に説明します。 • 「テーブルと列を使用した国際化」（64 ページ） • 「個別のデータベースによる国際化」（67 ページ） テーブルと列を使用した国際化 データベース内のデータの国際化は、テーブルと列を新たに 作成して、その中に翻訳データを格納することでサポートで きます。データベース内の翻訳データをサポートおよび識別 するために、テーブルと列をさまざまに組み合わせて使用で きます。 たとえば、MicroStrategy Tutorial プロジェクトには、次に示 す LU_MONTH_OF_YEAR テーブルから主情報を呼び出す "Month of Year"（カレンダ月）アトリビュートがあります。 月の名前を複数の言語で表示できるようにするには、翻訳し た月の名前を言語ごとに同じテーブル内の別の列に格納しま す。それぞれの列の名前には、特定の言語に翻訳データを識 64 データの国際化のサポート © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド 論理データ モデルのウェアハウスの構造 3 別する接尾語を付けることができます。同じ LU_MONTH_OF_YEAR テーブルにスペイン語とドイツ語の翻 訳を追加した例を次に示します。 スペイン語のデータは接尾語 _ES が付いた MONTH_OF_YEAR_NAME 列に、ドイツ語のデータは接尾語 _DE が付いた MONTH_OF_YEAR_NAME 列に、それぞれ格納 されています。 同じテーブル内に翻訳用の列を追加する代わりに、翻訳用の テーブルを個別に追加することもできます。この場合は、そ れぞれのテーブルに 1 つの言語のデータを同じ列名で格納で きます。次の図は、スパン語とドイツ語のデータをそれぞれ 別のテーブルに格納した状態を示しています。 © 2010 MicroStrategy, Inc. データの国際化のサポート 65 3 論理データ モデルのウェアハウスの構造 プロジェクト デザイン ガイド スペイン語のデータは接尾語 _ES が付いた LU_MONTH_OF_YEAR テーブルに格納されていますが、 MONTH_OF_YEAR 列の名前は英語の LU_MONTH_OF_YEAR テーブルと同じです。ドイツ語のデータも同じ手法で、接尾 語 _DE が付いた LU_MONTH_OF_YEAR テーブルに格納され ています。 翻訳データを格納および識別するために両方の手法（別の テーブルと列の追加）を併用することもできます。この方法 は、個々のテーブルと列に使用されている言語の識別に役立 ちます。また、主言語を 1 つのテーブルに格納し、その他の すべての言語を 1 つの国際化テーブルに格納することもでき ます。たとえば、スペイン語とドイツ語のデータを、次に示 すように同じ国際化テーブルに格納できます。 この例では、LU_MONTH_OF_YEAR_LANG テーブルに、主言 語を除くすべての言語による MONTH_OF_YEAR_NAME 列の 翻訳が含まれています。それぞれの列の名前には、翻訳デー タの言語を表す接尾語が付けられています。 下記に注意してください。 • 66 データの国際化のサポート 上記の例では、翻訳データの言語の識別にテーブ ルと列の接尾語が使用されています。識別に接尾 語を使用するのは必須ではありませんが、 © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド 論理データ モデルのウェアハウスの構造 3 MicroStrategy で定義およびサポートする方法とし ては最も容易です。接頭語やその他の命名法を使 用する場合は、翻訳データの場所を認識させるた めに、いくつかの関数を使用する必要があります。 • データの国際化をサポートするプロジェクトでは、 翻訳データを使用するアトリビュートのルック アップ テーブルとして論理表示を使用することは できません。論理表示の詳細は、「論理テーブル」 （415 ページ）を参照してください。 テーブルや列を使用してデータの国際化を有効にするように プロジェクトを定義する方法の詳細は、「SQL クエリによる データ国際化の有効化」（94 ページ）を参照してください。 個別のデータベースによる国際化 データベース内のデータの国際化は、対応する言語ごとに別 のデータベースを使用してサポートすることもできます。そ の後、接続マッピングを通じて、望ましい言語を含むデータ ベースへのアクセスをユーザに許可します。 たとえば、MicroStrategy Tutorial プロジェクトには、次に示 す LU_MONTH_OF_YEAR テーブルから主情報を呼び出す "Month of Year"（カレンダ月）アトリビュートがあります。 このデータが "Tutorial (English)" という名前のデータベース に格納されているものと想定します。このプロジェクトをス ペイン語とドイツ語でも提供するには、スペイン語のデータ ベースとドイツ語のデータベースも用意する必要がありま © 2010 MicroStrategy, Inc. データの国際化のサポート 67 3 論理データ モデルのウェアハウスの構造 プロジェクト デザイン ガイド す。これらのデータベースのテーブルと列の構造、および命 名法は、次に示すように共通にします。 この方法でデータを国際化するには、どの国際化データベー スでも同じデータが利用できる状態にする必要があります。 データの国際化をサポートするプロジェクトでは、翻 訳データを使用するアトリビュートのルックアップ テーブルとして論理表示を使用することはできま せん。論理表示の詳細は、「論理テーブル」（415 ペー ジ）を参照してください。 個別のデータベースを使用してデータの国際化を有効にする ようにプロジェクトを定義する方法の詳細は、「接続マッ ピングによるデータ国際化の有効化」（96 ページ）を参照し てください。 68 データの国際化のサポート © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド 論理データ モデルのウェアハウスの構造 3 データベース内のさまざまな文字セットのサポート 言語には、データを表す多様な文字セットが必要です。 MicroStrategy プロジェクトでの使用を計画している言語をサ ポートするには、必要な文字セットをサポートし、それに応 じて構成されたデータベースを使用する必要があります。サ ポートする言語に必要な文字セットをデータベースがサポー トしているかどうかを判断するには、サードパーティ デー タベースのドキュメンテーションを参照してください。 MicroStrategy で国際化をサポートする際のベスト プラク ティスについては、『システム管理ガイド』 © 2010 MicroStrategy, Inc. データの国際化のサポート 69 3 論理データ モデルのウェアハウスの構造 70 データの国際化のサポート プロジェクト デザイン ガイド © 2010 MicroStrategy, Inc. 4 4. プロジェクトの作成および 構成 はじめに ビジネス データの論理モデルを作成し、データ ウェアハウ ス内にデータを配置したら、MicroStrategy でプロジェクトの 作成に着手できます。 この章では、MicroStrategy でプロジェクトを作成する際に、 最初に実行するいくつかの主なステップを紹介します。ビジ ネス インテリジェンス アプリケーションを作成して分析す るために必要な MicroStrategy プラットフォームのコンポー ネントの定義と説明は、1 章、「MicroStrategy プラット フォームの BI アーキテクチャ」を参照してください。 プラットフォームには、サンプル プロ MicroStrategy ジェクトとして MicroStrategy Tutorial が用意されてい ます。この Tutorial は、MicroStrategy のさまざまな機 能を学習するために使用できるサンプル データ ウェ アハウスおよびデモ プロジェクトです。Tutorial プロ ジェクトは、追加構成タスクなしで、ただちに使用で きます。Tutorial の詳細は、『基本レポーティング ガ イド』を参照してください。MicroStrategy Tutorial の © 2010 MicroStrategy, Inc. 71 4 プロジェクトの作成および構成 プロジェクト デザイン ガイド 構造は、「MicroStrategy Tutorial」（397 ページ）で示し ます。 プロジェクト作成の概要 MicroStrategy プロジェクトの作成手順の主なステップを以下 に示します。これらのステップにより、プロジェクトの作成 プロセスの概要を知ることができます。このガイドの残りの 部分を読み進むときには、これらのプロセスを念頭に置いて ください。 （74 ページ） 「プロジェクトの接続コンポーネント」 では、MicroStrategy Desktop でのプロジェクト作成で 使用される基本的な用語の一部について、その定義を 示します。このガイドで使用している一部の用語を理 解していただくことが、この項の目的です。 1 「メタデータ リポジトリの作成」 メタデータ リポジトリには、プロジェクトに関連するオ ブジェクトと定義が含まれています。このリポジトリは、 ビジネス データとレポーティング環境の中継点として機 72 プロジェクト作成の概要 © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド プロジェクトの作成および構成 4 能します。したがって、プロジェクト作成プロセスの最 初のステップでは、メタデータ リポジトリを作成しま す。詳しい操作手順は、「メタデータ リポジトリの作成」 （78 ページ）を参照してください。 2 「メタデータ リポジトリとデータ ソースへの接続」 メタデータ リポジトリを作成して初期データを組み込ん だら、メタデータ リポジトリとデータ ソースの両方への 接続を確立する必要があります。詳しい手順については、 「メタデータ リポジトリとデータ ソースへの接続」（79 ページ）を参照してください。 3 「プロジェクトの作成」 メタデータ リポジトリを作成し、MicroStrategy 環境のさ まざまな部分の間で必要な接続を確立したら、プロジェ クトの基本的な定義を作成できます。詳しい手順につい ては、 「プロジェクトの作成」（81 ページ）を参照してく ださい。 4 「ファクトとアトリビュートの作成」 ファクトやアトリビュートなどのスキーマ オブジェクト は、プロジェクトの論理構造の基本コンポーネントです。 ユーザ コミュニティがレポートしたいと望んでいるビジ ネス データは、MicroStrategy ではスキーマ オブジェクト によって表されます。したがって、レポートを作成する 前にスキーマ オブジェクトをセットアップする必要があ ります。このステップについては、この章の「ファクト とアトリビュートの作成」（99 ページ）で説明します。 オブジェクトを作 レポートのデザインでスキーマ 成するには、クエリ ビルダまたはフリーフォーム SQL を使用します。これらの機能の詳細は、 『MicroStrategy 上級レポーティング ガイド』を参 照してください。 5 「他のスキーマレベル設定の構成」 最初のスキーマ オブジェクトを作成したら、追加のス キーマ レベルを設定します。これにより、プロジェクト 内のオブジェクトおよびプロジェクト全体に、複雑さと 奥行きを追加できます。たとえば、特定の結果セットを 呼び出す高度なファクトとアトリビュートを作成できま す。アトリビュートを使用して、トランスフォーメー ションと呼ばれる時系列分析スキーマ オブジェクトを作 © 2010 MicroStrategy, Inc. プロジェクト作成の概要 73 4 プロジェクトの作成および構成 プロジェクト デザイン ガイド 成し、さまざまなツールを実装して、プロジェクトを継 続的に最適化し、保守することもできます。関連する各 トピックと、その説明の記載場所は次のとおりです。 • 高度なファクトの作成については、「単純なファクト と高度なファクトの作成および変更」（191 ページ） を参照してください。 • 高度なアトリビュートの作成については、「アトリ ビュートの追加と変更」（235 ページ）を参照してく ださい。 • 階層とその作成については、8 章、「アトリビュート の構成とブラウズを行うための階層の作成」を参照し てください。 • トランスフォーメーションとその作成については、10 章、「時間ベースの比較やその他の比較を定義するた めのトランスフォーメーションの作成」を参照してく ださい。 • プロジェクトの最適化と保守については、9 章、「プ ロジェクトの最適化と管理」を参照してください。 上記のステップは、データベースやその他のデータ ソース（テキスト ファイル、Excel ファイルなど）に 接続するプロジェクトの作成プロセスに関係していま す。MicroStrategy は、SAP BI、Microsoft Analysis Services 2000/2005、および Hyperion Essbase の各シス テムに格納されているデータへの接続もサポートして います。MicroStrategy と統合されたとき、これらのシ ステムは MDX キューブ ソースと呼ばれます。どの MDX キューブ ソースにも、データベースに接続して いるプロジェクトから接続し、データのレポートと分 析を並行して実行できます。MDX キューブ ソースへ のスタンドアロン接続を作成することもできます （『MicroStrategy MDX Cube Reporting Guide』を参照）。 プロジェクトの接続コンポーネント この項では、MicroStrategy Desktop でのプロジェクト作成で 使用される基本的な用語の一部について、その定義を示しま す。このガイドで使用している一部の用語を理解していただ くことが、この項の目的です。 74 プロジェクトの接続コンポーネント © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド プロジェクトの作成および構成 4 MicroStrategy メタデータ スキーマ オブジェクト、アプリケーション オブジェクト、 構成オブジェクト、およびプロジェクト設定は、すべて MicroStrategy メタデータに格納されます。メタデータは、あ らかじめ定義された構造を持つリレーショナル データベー スに格納されます。メタデータとウェアハウスに、同じ RDBMS を使用する必要はありません。 RDBMS プラットフォームは、 サポートされている MicroStrategy 製品と共にインストールされる readme ファイルに一覧されています。readme ファイルを表 示するには、[ スタート ] メニューで [ プログラム ]、 [MicroStrategy] の順に選択し、[ReadMe] を選択し ます。 メタデータ シェル メタデータ リポジトリにデータを組み込むには、データを 格納するテーブルが存在している必要があります。メタデー タ シェル とは、MicroStrategy ビジネス インテリジェンス環 境を最初に実装したときに作成される一連の空のテーブルで す。 メタデータ シェルは MicroStrategy Configuration Wizard で作 成します。一連の空きテーブルが作成され、一部のテーブル に基本的な初期データが格納されます。 このプロジェクト作成プロセスの第 1 ステップについては、 「メタデータ リポジトリの作成」（78 ページ）で概要を示し ます。 プロジェクト ソース プロジェクト ソース とは、メタデータ リポジトリへの接続 を表す構成オブジェクトです。MicroStrategy Desktop では、 プロジェクト ソースはフォルダ リスト内のアイコンとして 表示されます。このアイコンは接続の種類によって変わりま © 2010 MicroStrategy, Inc. プロジェクトの接続コンポーネント 75 4 プロジェクトの作成および構成 プロジェクト デザイン ガイド す。メタデータ リポジトリには、次のどちらかの方法で接 続します。 • 直接または 2 層モード（ ）:DSN、メタデータ リポジ トリへのログイン、およびパスワードを指定してメタ データに接続します。 実稼働環境では、直接モードでの接続はいっさい 使用しないことを推奨します。メタデータへの接 続では、高度なセキュリティとスケーラビリティ を提供する MicroStrategy Intelligence Server を経由 することを強く推奨します。プロトタイプ環境の 実装時を除き、メタデータには直接接続しないで ください。 • サーバまたは 3 層モード（ ）:Intelligence Server の定義 を指定してメタデータに接続し、Intelligence Server でメ タデータへの接続を管理、検証します。プロジェクト メ タデータが第 1 層、MicroStrategy Desktop が第 2 層、 Intelligence Server が第 3 層です。Intelligence Server がす べてのデータベース接続を管理し、セキュリティを適用 し、メタデータの整合性を確保します。この理由により、 すべての実稼働環境で Intelligence Server は不可欠です。 層接続では、サーバ（3 層）接続を Web サーバ 4上に配備した MicroStrategy Web との組み合わせで 使用します。 次の図は、MicroStrategy メタデータ リポジトリ、Intelligence Server、および MicroStrategy Desktop 間のサーバ接続を示し ています。MicroStrategy で実稼働可能なプロジェクトを作成 するときには、このタイプの接続を使用します。 76 プロジェクトの接続コンポーネント © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド プロジェクトの作成および構成 4 メタデータへの接続を確立すると、プロジェクト ソース内 で作成するすべてのオブジェクト定義が、そのメタデータに 格納されます。これには、同じプロジェクト ソース内で定 義したすべてのプロジェクトのアプリケーション オブジェ クト、スキーマ オブジェクト、および構成オブジェクトが 含まれます（これらの種類のオブジェクトの定義について は、「MicroStrategy メタデータ」（9 ページ）を参照。） プロジェクト ソースは 1 つのメタデータ リポジトリに接続 します。一方、1 つのメタデータ リポジトリは、複数のプロ ジェクト ソースからアクセスされる場合があります。プロ ジェクト ソースには、任意の数のプロジェクトを含めるこ とができます。 データベース インスタンス データベース インスタンス とは、1 つのデータ ソースへの 接続を表す構成オブジェクトです。プロジェクトの定義時 に、適切な接続パラメーターを持つデータベース インス タンスを作成し、それを選択することによってデータソース の場所を指定します。 データベース インスタンスの詳細については、 『MicroStrategy 導入と構成ガイド』を参照してください。 データベース インスタンスを介したデータ ソースへの接続 については、「データ ソースへの接続」（80 ページ）で詳し く説明します。 プロジェクト プロジェクトとは、レポートなどのアプリケーション オブ ジェクトを MicroStrategy 環境で作成するために必要な、す べてのスキーマ オブジェクトと情報を作成し、格納する場 所です。プロジェクトは、データ ソース、メタデータ リポ ジトリ、およびユーザ コミュニティが交差する部分でもあ ります。MicroStrategy におけるプロジェクトの詳細について は、「MicroStrategy プロジェクト」（14 ページ）を参照して ください。 © 2010 MicroStrategy, Inc. プロジェクトの接続コンポーネント 77 4 プロジェクトの作成および構成 プロジェクト デザイン ガイド プロジェクト接続の要約 MicroStrategy のメタデータ、プロジェクト ソース、データ ベース インスタンス、およびプロジェクトを十分に理解し たら、それらの要素をどのように組み合わせ、統合ビジネス インテリジェンス環境を形成するかについて、次の図のよう な構想の立案に着手できます。 メタデータ リポジトリの作成 プロジェクトの作成では、最初のステップとしてメタデータ リポジトリを作成します。プロジェクトをサポートするため に必要なすべてのオブジェクトが、このリポジトリに格納さ れます。 78 メタデータ リポジトリの作成 © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド プロジェクトの作成および構成 4 空のメタデータ リポジトリをデータベース内の任意の場所 に作成するには、Configuration Wizard で [ メタデータ テー ブルを作成 ] オプションを使用します。 リポジトリが 次の項に進む前に、メタデータ Microsoft Access 以外のデータベース内に存在してい ることを確認してください。Access データベースは 実稼働プロジェクトには適していません。 『MicroStrategy 導入と構成ガイド』の「Intelligence Server の 構成および接続」の章に示されているガイドラインに従って メタデータ リポジトリを作成します。 メタデータ リポジトリを作成すると、MicroStrategy によっ てリポジトリ内にデフォルト構成が作成されます。このデ フォルト構成により、デフォルトのプロジェクト フォルダ 構造や基本接続情報など、メタデータに必要な基本データが テーブルに組み込まれます。 これらのテーブルには、「プロジェクトの作成」（81 ページ） で説明するプロジェクト作成アシスタントでのプロジェクト 作成ステップ中に、プロジェクト情報が移入されます。 リポジトリを作成する データベース内にメタデータ 方法については、『MicroStrategy 導入と構成ガイド』 を参照してください。 メタデータ リポジトリとデータ ソースへ の接続 メタデータ リポジトリを作成したら、次のステップとして、 MicroStrategy Desktop をメタデータ リポジトリおよびデータ ソースに接続します。 メタデータ リポジトリへの接続 MicroStrategy Desktop または MicroStrategy Web 内のメタデー タ リポジトリには、プロジェクト ソースを介して接続しま す。前述したように、プロジェクト ソースはメタデータ リ ポジトリを指す一種のポインタです。プロジェクト ソース © 2010 MicroStrategy, Inc. メタデータ リポジトリとデータ ソースへの接続 79 4 プロジェクトの作成および構成 プロジェクト デザイン ガイド は、適切なデータベースの場所を指す DSN を介して、また は Intelligence Server のインスタンスを指定することによっ て接続します（指定されたインスタンスがメタデータ リポ ジトリの場所を指します）。 Intelligence Server を構成し、メタデータ、Intelligence Server、 および MicroStrategy Desktop 間のサーバ接続を確立するに は、『MicroStrategy 導入と構成ガイド』に記載されているス テップに従ってください。 データ ソースへの接続 データ ソースには、分析と考察の対象となるビジネス デー タが含まれます。Intelligence Server 経由でメタデータ リポ ジトリに接続すると、次のステップとしてプロジェクトから 接続可能なデータ ソースへの接続を作成します。データ ソースに接続するには、MicroStrategy Desktop でデータベー ス インスタンスを作成します。 『MicroStrategy 導入と構成ガイド』の「Intelligence Server の 構成および接続」の章に示されている手順に従ってデータ ベース インスタンスを作成します。 MicroStrategy 9.0 では、複数ソース オプションと呼ばれる新 しい拡張機能が Intelligence Server に導入されました。この 機能を使用すると、1 つのプロジェクトを複数のデータ ソー スに接続できます。これにより、さまざまなデータベースや 他のリレーショナル データ ソースからの情報をすべて単一 の MicroStrategy プロジェクトに統合し、レポート作成およ び分析を行うことができます。プロジェクトを複数のデータ ソースに接続する方法については、「プロジェクト内の複数 のデータ ソースへのアクセス」（355 ページ）を参照してく ださい。 以下の点に注意してください。 • 複数ソース オプションのライセンスをお持ちでな い場合、プロジェクトが接続できるデータ ソース は 1 つだけです。 80 メタデータ リポジトリとデータ ソースへの接続 © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド プロジェクトの作成および構成 • 4 MicroStrategy では、SAP BI、Microsoft Analysis Services、および Hyperion Essbase のデータ ソース にも接続できます。これらの MDX キューブ ソー スに接続する方法については、『MicroStrategy MDX Cube Reporting Guide』を参照してください。 プロジェクトの作成 この時点で、メタデータ リポジトリとデータ ソースに接続 する MicroStrategy プロジェクトの作成に着手できます。プ ロジェクトの作成では、基本的なプロジェクト定義を作成 し、プロジェクトの最初のスキーマ オブジェクトを作成し ます。 プロジェクトの作成と編集は、次のようないくつかの方法で 実行できます。 • 「実稼働プロジェクトの作成」 この項では、プロジェクト作成アシスタントまたは Architect を使用して、実稼働可能な MicroStrategy プロ ジェクトを作成する手順を示します。 • 「Project Builder によるテスト / プロトタイプ プロジェク トの作成」 Project Builder では、実際のデータを使用したプルーフ オブ - コンセプト テスト用に、プロジェクトのプロトタ イプを作成できます。Project Builder はテスト プロジェ クトの作成に最適ですが、実稼働プロジェクトを作成す るようには意図されていません。 次の表は、プロジェクト作成アシスタントまたは Architect を使用した実稼働プロジェクトの作成と、Project Builder を 使用したプロトタイプ プロジェクトの作成の比較を示して います。この表を参考にして、用途に適したプロジェクト作 © 2010 MicroStrategy, Inc. プロジェクトの作成 81 4 プロジェクトの作成および構成 プロジェクト デザイン ガイド 成ツールを決定してください。プロジェクト作成アシスタン トと Architect の違いについては、「Architect とプロジェクト 作成アシスタント」（84 ページ）を参照してください。 機能 プロジェクト作成アシスタントまたは Architect による実稼働プロジェクト の作成 Project Builder によるプロトタイプ プロジェクトの作成 対象ユーザ 上級ユーザ 初級～中級ユーザ プロジェクトの種類 実稼働可能 / その他の大規模プロジェ クト向け テスト用 / 基本的なプロジェクト 機能が多方面にわたり、プロジェクト デザインに関するより多くの知識が必 要 容易に使用できるが機能は少ない 複雑さ 機能 高度な機能により、次のオブジェクト などが作成可能 : • 複数のテーブル、アトリビュート、 およびファクトを一度に作成 • 多対多関係および結合子関係を持 つアトリビュート 限定的で、複数のスキーマ オブジェ クトを一度に作成することはできな い。基本的な階層とメトリックの作成 は可能 メタデータ リポジト リの種類 さまざまなデータベースとその他の データ ソース Microsoft Access メトリックとレポート プロジェクト作成後のみ の作成 基本的なメトリックとレポートのみ 実稼働プロジェクトの作成 この項では、実稼働環境向けのサーバ接続（3 層）プロジェ クトを MicroStrategy Desktop で作成する方法について説明し ます。 （2ここでは、プロジェクトに接続する手段として直接 層）接続は使用せず、ビジネス インテリジェンス 環境に Intelligence Server を実装する場合を想定しま す。直接接続を作成する方法は、『MicroStrategy 導入 と構成ガイド』を参照してください。 MicroStrategy Desktop でプロジェクト作成アシスタントまた は Architect を使用すれば、Project Builder を使用する場合に 比べ、より機能的に高度で複雑なプロジェクトを作成できま す。これにより、新規プロジェクトを作成して次のオブジェ クトを追加したり、これらのオブジェクトを既存プロジェク トに追加することができます。 82 プロジェクトの作成 © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド プロジェクトの作成および構成 • テーブル • ファクト • アトリビュート 4 プロジェクト作成アシスタントや Architect では、プロジェ クトと、その中に含める一部の基本スキーマ オブジェクト を作成して構成します。これらのツールの対象ユーザは、す べてのファクト、アトリビュート、およびデータ関係の計画 を作成した、経験豊かなプロジェクト作成者です。これに関 する情報は、このガイドの他の部分で説明します。各章で取 り上げている情報については、以下の「プロジェクトの計 画」に一覧があります。 Project Builder と比べた場合のプロジェクト作成アシスタン トと Architect の主な利点は、複数のスキーマ オブジェクト を一度に作成できることです。効率的に複数のテーブルを追 加して多数のアトリビュートとファクトを作成できるため、 多くのテーブルとスキーマ オブジェクトを含む大規模プロ ジェクトに特に適しています。プロジェクト作成アシスタン トや Architect では、多対多関係を持つアトリビュートも作 成できます。 プロジェクトの計画 プロジェクト作成アシスタントや Architect を使用する前に、 プロジェクトの計画を立て、次の点を考慮する必要がありま す。 • 作成するプロジェクトに使用する論理データ モデル。論 理データ モデルについては、2 章、「論理データ モデル」 で説明しています。 • プロジェクトに使用するテーブル。物理ウェアハウス ス キーマ モデルについては、3 章、「論理データ モデルの ウェアハウスの構造」で説明しています。 • プロジェクトに含めるファクトと、その識別に使用され る各種のデータ。ファクトについては、6 章、「ビジネス データの構築ブロック : ファクト」で説明します。 • プロジェクト内に作成するアトリビュートと、その識別 に使用される次のようなデータ。 説明列の名前 © 2010 MicroStrategy, Inc. プロジェクトの作成 83 4 プロジェクトの作成および構成 プロジェクト デザイン ガイド 他のアトリビュート フォーム 子アトリビュート アトリビュートについては、7 章、「ビジネス データの コンテキスト : アトリビュート」で説明します。 • プロジェクト作成アシスタントとグラフィカルな Architect のどちらを使用するか。これらのプロジェクト 作成ツールについては、次の「Architect とプロジェクト 作成アシスタント」で比較しています。 Architect とプロジェクト作成アシスタント MicroStrategy には、独自の方法でプロジェクトを作成する手 段として、プロジェクト作成アシスタントと Architect とい う 2 つのツールが用意されています。 プロジェクト作成アシスタントは、ウィザード式の直線的 ワークフローを通じてプロジェクトを作成します。これによ り、プロジェクト作成に必要なさまざまなステップを論理的 順序に従って進めることができます。プロジェクト作成アシ スタントでは通常、プロジェクトに必要なオブジェクトの追 加や定義は、別のステップを通じて実行します。 プロジェクトには複数のテーブル、ファクト、およびアトリ ビュートを追加および定義できますが、これらのタスクはプ ロジェクト作成フロー中の別のステップになっています。 プロジェクト作成アシスタントは、プロジェクトの新規作成 を意図して設計されており、既存プロジェクトの変更には使 用できません。作成したプロジェクトに変更を加えるには、 Architect を使用するか、適切なスキーマ エディタやウィ ザードを使用する必要があります。 Architect では、プロジェクトに必要なすべてのコンポーネン トの定義と、プロジェクト作成のさまざまなタスクを、すべ て 1 つのインタフェースで実行できます。 Architect を使用してプロジェクトを作成するときには、プロ ジェクトに情報を含める最初のステップとして、複数のテー ブルをプロジェクトに追加します。Architect では、いったん プロジェクトにテーブルを追加すれば、プロジェクトを柔軟 な順序で作成できるようになります。Architect でのプロジェ クト作成中に、テーブルの追加、ファクトの作成、アトリ 84 プロジェクトの作成 © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド プロジェクトの作成および構成 4 ビュートの作成、アトリビュート間の関係の定義、ユーザ階 層の作成、およびその他プロジェクトの作成に必要なタスク を容易に切り替えて実行できます。これらのタスクの実行中 には、Architect にプロジェクトの視覚的表現が表示されるた め、ワークフローを直感的に把握できます。 どちらのツールにも、データ ソース内の列とデータに基づ いて、ファクトとアトリビュートを自動作成するオプション があります。ファクトとアトリビュートの自動作成を利用す れば、プロジェクトの作成時間を大幅に短縮することが可能 です。 上に要約したように、プロジェクト作成アシスタントと Architect は、それぞれ異なるワークフローを通じてプロジェ クトの作成を支援します。プロジェクトの作成にどちらの ツールを使用すべきか判断する材料として、次の表に 2 つの ツールの比較を示します。 プロジェクト作成タス プロジェクト作成アシスタント ク / 機能 Architect ウィザード式の直線的ワークフローを 通じて、テーブル、アトリビュート、 およびファクトをプロジェクトに追加 1 つのインタフェースから一元的に、 必要に応じた順序でオブジェクトを柔 軟にプロジェクトに追加できる プロジェクトの新規作成のみ プロジェクトの作成のほか、プロジェ クトのライフ サイクルのどの時点で も、プロジェクトに随時変更を加える ことができる ユーザ階層の作成 ユーザ階層の作成は不可 ユーザ階層を作成できる ファクトとアトリ ビュートの自動作成 規則に基づいてファクトとアトリ ビュートを自動作成できる 規則に基づいてファクトとアトリ ビュートを自動作成できる 新規プロジェクト オブジェクトを作 成可能 Architect を使用する前に、プロジェク ト作成アシスタントを使用して新規プ ロジェクト オブジェクトを作成する 必要がある プロジェクト作成の ワークフロー 既存プロジェクトへの 変更 新規プロジェクト オ ブジェクトの作成 プロジェクト作成アシスタントによる新規プロジェ クトの作成 プロジェクトの計画を作成し、前提条件を満たしたら、プロ ジェクト作成アシスタントでプロジェクトを作成し、データ ウェアハウス内のデータ構造に基づいてメタデータを組み込 むことができます。 © 2010 MicroStrategy, Inc. プロジェクトの作成 85 4 プロジェクトの作成および構成 プロジェクト デザイン ガイド プロジェクト作成アシスタントは次の手順で使用します。 1 プロジェクトを初期化 / 作成します。 プロジェクトの初期化とは、プロジェクトに名前を付け、 作成するプロジェクトを含めるメタデータ リポジトリ （プロジェクト ソース）を選択することです。メタデー タ オブジェクト情報を国際化するために、プロジェクト で利用可能な言語を定義するタスクも含まれます。 これらの設定を行うと、プロジェクトのシェルがメタ データ内に作成されます。その結果、フォルダ構造と接 続のデフォルト設定が構成されます。この処理は完了ま でに、ある程度の時間を要することに注意してください。 2 ウェアハウス カタログからテーブルを選択します。 このステップでは、ウェアハウス カタログを使用して、 プロジェクトに含めるデータ ウェアハウス テーブルを指 定します。 3 ファクトを作成します。 4 アトリビュートを作成します。 プロジェクト作成アシスタントでは、すべてのステッ プを一度に済ませる必要があります。不完全なプロ ジェクト定義も保存できますが、後でプロジェクト作 成アシスタントを使用して、プロジェクトの作成を完 了することはできません。不完全なプロジェクトの作 成を完了するには、ウェアハウス カタログ、ファク ト作成アシスタント、アトリビュート作成アシスタン トなど、適切なインタフェースを使用する必要があり ます。 プロジェクト作成アシスタントで新規プロジェクトを作成するには 1 MicroStrategy Desktop で、プロジェクト ソースにログ インします。 Intelligence Server 経由でデータに接続するプロジェクト ソースを作成する方法については、『MicroStrategy 導入と 構成ガイド』の「Intelligence Server の構成および接続」 の章を参照してください。 86 プロジェクトの作成 © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド プロジェクトの作成および構成 4 2 [ スキーマ ] メニューで、[ 新規プロジェクトを作成 ] を選 択します。次に示すプロジェクト作成アシスタントが開 きます。 3 [ プロジェクトの作成 ] をクリックします。[ 新規プロジェ クト ] ページが開きます。 4 次のプロジェクト構成を定義します。 © 2010 MicroStrategy, Inc. • 名前 : プロジェクトの名前。この名前は、プロジェク ト ソース内のプロジェクトの識別に使用されます。 • 説明 : プロジェクトの説明（省略可）。プロジェクト の用途を、他のプロジェクトと比較して簡潔に説明し ます。 • デフォルト ドキュメント ディレクトリ : プロジェク トのデフォルト ドキュメント ディレクトリとは、す べての HTML ドキュメントを格納するディレクトリ の場所です。プロジェクトの HTML ドキュメントを セットアップする方法の詳細は、 『MicroStrategy 導入 と構成ガイド』を参照してください。 • このプロジェクトに Web ゲスト ユーザ アカウント を有効化 : ユーザ認証情報なしのログインをユーザに 許可する場合、このチェック ボックスを選択します。 プロジェクトの作成 87 4 プロジェクトの作成および構成 プロジェクト デザイン ガイド 選択した場合、ユーザは（Public グループで定義され た）限られた権限と許可だけで Intelligence Server に 接続できます。 • このプロジェクトに変更履歴を有効化 : プロジェクト の変更履歴を有効にする場合、このチェック ボック スを選択します。プロジェクト内のオブジェクトに変 更が加えられるたびに、履歴に自動的にエントリが追 加されます。これにより、プロジェクトの変更の追跡 が可能になります。変更履歴の詳細は、『システム管 理ガイド』を参照してください。 • 言語 : このプロジェクト内のメタデータ オブジェク トで利用可能な言語を定義する場合は、このボタンを クリックします。ここで選択する言語は、メタデータ オブジェクトの国際化に利用可能な言語でもありま す。プロジェクトで利用可能な言語を指定すると、オ ブジェクト名、説明、その他の情報を、複数の言語で 提供することが可能になります。たとえば、プロジェ クト内でアトリビュート、メトリック、フォルダ、そ の他のオブジェクトの名前を、複数の言語で提供でき ます。アトリビュート、メトリック、フォルダ、その 他のメタデータ オブジェクト用に、翻訳した文字列 を用意する方法については、『システム管理ガイド』 を参照してください。 MicroStrategy には、デフォルトで利用可能な言語のリ ストに含まれる各言語に翻訳した、一般的なメタデー タ オブジェクト用の文字列が含まれています。たと えば、" パブリック オブジェクト " フォルダや、その 他の一般的なオブジェクトの名前と説明を、デフォル トで利用可能な言語のリストに含まれる各言語に翻訳 した文字列が用意されています。リストに含まれない 言語を追加する場合は、一般的なメタデータ オブ ジェクトのすべての翻訳文字列を、お客様側で用意す る必要があります。 下記に注意してください。 – 88 プロジェクトの作成 新規プロジェクトの作成時には言語チェックが実 行され、ローカル マシンのユーザ プロファイル （CURRENT_USER レジストリ キー）の言語設定、 ローカル マシン（LOCAL_MACHINE レジストリ キー）の言語、およびプロジェクトのロケール プ ロパティが一致しているかどうかが検証されます。 これらのプロパティが一致しないと、言語表示の © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド プロジェクトの作成および構成 4 不整合の原因になります。言語チェックによって、 そのような不整合がなくなり、言語表示がプロ ジェクト全体で一貫している状態が確保されます。 – これらの言語オプションは、データ ソースから MicroStrategy に渡される翻訳データの整合性とは 関係ありません。データの国際化をサポートする ようにデータ ソースを定義する方法については、 「データの国際化のサポート」（63 ページ）を参照 してください。 データ ソースから得られた翻訳済みデータをプロ ジェクト内のアトリビュートで使用するには、 データの国際化を有効にする方法を、アトリ ビュートの作成前に定義する必要があります。 データの国際化を有効にする方法については、「プ ロジェクトのデータの国際化」（92 ページ）を参 照してください。 5 [OK] をクリックすると、プロジェクト オブジェクトが 作成されます。 6 次の項（「ウェアハウス カタログによるテーブルの追 加」）に進み、プロジェクトで使用するテーブルを決定 します。 ウェアハウス カタログによるテーブルの追加 プロジェクトのウェアハウス テーブルは、プロジェクトで 分析可能なデータ セットを決定します。プロジェクトに ウェアハウス テーブルを追加するには、ウェアハウス カタ ログを使用します。ウェアハウス カタログには、データ ベース インスタンスを通じて接続され、データベース ログ インが読み取り権限を持っているデータ ソース内のすべて のテーブルが一覧されます。 ウェアハウス カタログは、データ ソースへのクエリを実行 し、その中に存在するテーブルと列をリストします。このリ ストから、新規プロジェクトに使用するルックアップ テー ブル、ファクト テーブル、および関係テーブルを選択しま す。さらに、トランスフォーメーション テーブル、集計 テーブル、パーティション マッピング テーブルなど、プロ ジェクトを完成させるために必要な、その他すべてのテーブ ルを含めます。 © 2010 MicroStrategy, Inc. プロジェクトの作成 89 4 プロジェクトの作成および構成 プロジェクト デザイン ガイド アトリビュート、ファクト、テーブルなどの MicroStrategy スキーマ オブジェクトは、データ ソース内のテーブルと列 に基づいて抽象化された項目です。データ ソースからテー ブルを選択してプロジェクトに追加すると、そのテーブルは MicroStrategy で論理テーブルと呼ばれるスキーマ オブジェ クトになります。論理テーブルは、データ ウェアハウス内 の利用可能なテーブルを表しています。論理テーブルについ ては、「論理テーブル」（415 ページ）で詳しく説明します。 ログインには、選択したウェ 使用するデータベース アハウス内のテーブルを表示できるように、読み取り 権限が必要です。データベース インスタンスとデー タベース ログインは、プロジェクトが接続するウェ アハウスを決定する MicroStrategy オブジェクトです。 これらのオブジェクトの詳細については、 『MicroStrategy 導入と構成ガイド』を参照してくださ い。 ウェアハウス カタログを使用して、プロジェクトでテーブルを追 加または削除するには 1 プロジェクト作成アシスタントで、[ ウェアハウス カタ ログからテーブルを選択 ] を選択します。[ ウェアハウス データベース インスタンス ] ダイアログ ボックスが開き ます。 2 ドロップダウン リストからデータベース インスタンスを 選択し、[OK] を選択します。このダイアログ ボックス で選択したデータベース インスタンスによって、アクセ ス先のデータ ソースが決まります。ウェアハウス カタロ グが開きます。 複数ソース オプションのライセンスをお持ちの場合は、 複数のデータ ソースからテーブルをプロジェクトに追加 できます。ウェアハウス カタログを使用して、複数の データ ソースからテーブルをプロジェクトに追加する方 法については、「プロジェクト内の複数のデータ ソース へのアクセス」（355 ページ）を参照してください。 インスタンスは、[ 編集 ] をクリック データベース して編集できます。 3 ウェアハウス カタログの左側には、利用可能なすべての テーブルと、各テーブルに含まれる行の数がリストされ 90 プロジェクトの作成 © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド プロジェクトの作成および構成 4 ます。プロジェクトで現在使用されているテーブルがあ れば、それらのテーブルが右側のリストに表示されます。 4 プロジェクトに追加するテーブルを左側のリストから選 択し、[>] をクリックしてテーブルを追加します。[>>] をクリックすると、リストに含まれるすべてのテーブル が一括して追加されます。 5 プロジェクトからテーブルを削除するには、右側のリス トで削除するテーブルを選択して [<] をクリックします。 [<<] をクリックすると、プロジェクト内のすべてのテー ブルが削除されます。 ウェアハウス カタログのオプション 6 いずれかのテーブルを右クリックすると、ウェアハウス カタログの追加機能を使用できます。 追加機能には、テーブル内の行の表示、テーブルの接頭 語の指定、テーブルのコピー、テーブルのデータベース インスタンスの指定などがあります。これらの機能と使 用方法の詳細は、「ウェアハウスとプロジェクトのテーブ ルの管理」（332 ページ）を参照してください。 7 詳細オプションを設定するには、ウェアハウス カタログ のツールバーで [ オプション ] をクリックします。 たとえば、データベース インスタンスの変更、データ ベース システム カタログからテーブルと列を読み取る方 法のカスタマイズ、テーブルと行の追加情報の表示、ス © 2010 MicroStrategy, Inc. プロジェクトの作成 91 4 プロジェクトの作成および構成 プロジェクト デザイン ガイド キーマ オブジェクトを自動、手動のどちらでマッピング するかの選択などを実行できます。これらの機能と使用 方法の詳細は、「データ ウェアハウス接続と動作のデ フォルトの変更」（339 ページ）を参照してください。 8 ツールバーの [ 保存して閉じる ] をクリックし、ウェアハ ウス カタログへの変更を保存します。テーブル定義がメ タデータに書き込まれます。この処理は、完了までしば らく時間がかかる場合があります。 プロジェクト作成アシストを終了した後も、ウェアハウス カタログにアクセスしてテーブルを追加できます。ウェアハ ウス カタログにアクセスしてプロジェクトにテーブルを追 加するステップについては、「プロジェクトのテーブルの追 加および削除」（330 ページ）を参照してください。 プロジェクト作成ウィザードの次のステップでは、ファクト とアトリビュートという 2 種類のスキーマ オブジェクトを 作成します。これらのスキーマ オブジェクトの作成方法と、 これらのオブジェクトにスキーマレベルで追加設定を行う方 法については、「ファクトとアトリビュートの作成」（99 ページ）および「他のスキーマレベル設定の構成」（99 ペー ジ）で紹介されている手順を参照してください。 Architect による新規プロジェクトの作成 プロジェクト作成アシスタントではウィザード式のプロセス を通じてプロジェクトを作成しますが、その代わりに Architect を使用して、プロジェクトに必要な全コンポーネン トを一元的なインタフェースから定義することもできます。 Architect では、作成中のプロジェクトが視覚的に表示される ため、ワークフローを直感的に捉えることができます。 Architect を使用して実稼働プロジェクトを作成する方法につ いては、「Architect によるプロジェクトの作成」（116 ペー ジ）を参照してください。 プロジェクトのデータの国際化 MicroStrategy は、データをユーザに必要な言語にする国際化 をサポートしています。したがって、翻訳済みのデータを データ ソースから取り込み、MicroStrategy プロジェクトに 統合することが可能です。データはユーザの言語ニーズに応 じて、さまざまな言語で表示できます。 92 プロジェクトの作成 © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド プロジェクトの作成および構成 4 より具体的に言えば、データの国際化によって、アトリ ビュート エレメントをさまざまな言語で表示することが可 能になります。たとえば、次のレポートに示す "Month of Year"（カレンダ月）アトリビュート エレメントのデータを、 英語の代わりにドイツ語で表示できます。 この "Month of Year" アトリビュートのエレメントを、デー タの国際化を通じて、別の言語で表示することが可能になり ます。たとえば、アトリビュート エレメントの January、 February、March は、ドイツ語でデータを見るように定義さ れているユーザには Januar、Februar、Mrz と表示されます。 データの国際化は、メタデータの国際化とは異なりま す。メタデータの国際化では、MicroStrategy のさまざ まなメタデータ オブジェクトの名前、説明、その他 の文字列を多言語で表示可能にします。たとえば、プ ロジェクト内でアトリビュート、メトリック、フォル ダ、その他のオブジェクトの名前を、複数の言語で提 供できます。アトリビュート、メトリック、フォル ダ、その他のメタデータ オブジェクト用に、翻訳し た文字列を用意する方法については、『システム管理 ガイド』を参照してください。 MicroStrategy は、2 種類の手法による国際化をサポートして います。翻訳したデータを、テーブルと列を追加して提供す る手法と、個別のデータベースに格納する手法です。これら の方法の詳細については、 「データの国際化のサポート」 （63 ページ）を参照してください。 国際化されたデータをアトリビュートで使用するには、デー タの国際化を有効にする方法を、アトリビュートの作成前に 定義する必要があります。国際化されたデータがデータ © 2010 MicroStrategy, Inc. プロジェクトの作成 93 4 プロジェクトの作成および構成 プロジェクト デザイン ガイド ソース内でどのように表現されるかを定義することによっ て、Architect、アトリビュート作成ウィザード、およびファ クト作成ウィザードが、アトリビュートの自動作成時に国際 化データを認識できるようになります。その結果、国際化 データを認識して使用するようにアトリビュートを変更する ために、作業を遡る手間と時間が省けます。 どちらの方法でデータを国際化するかに応じて、次の該当す る手順に従ってください。 • 「SQL クエリによるデータ国際化の有効化」（94 ページ） • 「接続マッピングによるデータ国際化の有効化」（96 ペー ジ） SQL クエリによるデータ国際化の有効化 テーブルと列を使用して国際化データを識別するようにデー タ ソースを構成した場合は、必要な言語のデータを返す SQL クエリを作成するように MicroStrategy プロジェクトを 定義できます。SQL クエリは自動的に生成され、翻訳デー タの格納場所として指定したテーブルと列に基づき、ユーザ が選択した言語で情報を返します。 テーブルと列を使用して翻訳データを識別するようにデータ ソースを構成する方法については、「テーブルと列を使用し た国際化」（64 ページ）を参照してください。 SQL クエリを通じてデータの国際化を有効にするには、以 下の手順に示すように、国際化されたデータに使用するテー ブルと列を定義する必要があります。 前提条件 • プロジェクトが作成済みであること。 SQL クエリを通じてデータの国際化を有効にするには 1 MicroStrategy Desktop でプロジェクトにログインします。 2 プロジェクトを右クリックし、[ プロジェクト構成 ] を選 択します。プロジェクト構成エディタが開きます。 94 プロジェクトの作成 © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド プロジェクトの作成および構成 4 3 [ カテゴリ ] リストで [ 言語 ] を展開し、[ データ ] を選択し ます。 4 [ データ インターナショナリゼーションを有効化 ] チェッ ク ボックスを選択して [SQL に基づくデータ インターナ ショナリゼーション ] オプションを選択します。 5 翻訳データを使用可能にする言語の横にあるチェック ボックスを選択します。 データの国際化を有効にする言語を追加するには、次の 手順に従います。 a [ 追加 ] をクリックします。[ 使用可能な言語 ] ダイアロ グ ボックスが開きます。 b [ メタデータ言語のみ表示 ] チェック ボックスをクリ アします。 c データの国際化を有効にする言語のチェック ボック スを選択して、[OK] をクリックし、プロジェクト構 成エディタに戻ります。 6 翻訳データを格納する列とテーブルの接尾語を、言語ご とに入力します。 言語の [ 列パターン ] 内で [...] をクリックし、列の接尾語 を入力します。言語の [ テーブル パターン ] 内で [...] をク リックし、テーブルの接尾語を入力します。たとえば、 データ ソース内の末尾が _ES の列にスペイン語データを 含める場合は、[ 列パターン ] に _ES と入力します。 [ 列パターン ] オプションと [ テーブル パターン ] オプ ションには、国際化された列とテーブルを識別するため の接尾語を入力します。接頭語やその他の命名法を使用 する場合は、次の関数を使用することで、翻訳データを 含む列とテーブルを識別できます。 © 2010 MicroStrategy, Inc. • LStrCut(string s, integer x): 文字列 s の先頭 から x 文字を削除し、残った文字列を返します。た とえば、LStrCut(“Apple”,2) は ple を返します。 • RStrCut(string s, integer x): 文字列 s の末尾 から x 文字を削除し、残った文字列を返します。た とえば、RStrCut(“Apple”,2) は App を返します。 • Concat(string s1, string s2): 文字列 s1 の末 尾に文字列 s2 を連結した結果を返します。たとえ ば、Concat(“App”,“le”) は Apple を返します。 プロジェクトの作成 95 4 プロジェクトの作成および構成 プロジェクト デザイン ガイド これらの関数を組み合わせることで、列とテーブルのさ まざまな表記法に対応できます。#0 パラメーターを使用 すれば、列またはテーブルの名前を関数に渡すことがで きます。接尾語の代わりに接頭語を使用する場合は、次 の構文で対応できます。 Concat(“Prefix”,#0) たとえば、スペイン語のデータを含む列を接頭語 ES_ で 識別するには、次の関数を使用できます。 Concat(“ES_”,#0) 7 [OK] をクリックして変更を保存し、プロジェクト構成エ ディタを閉じます。 接続マッピングによるデータ国際化の有効化 データベース内のデータの国際化は、翻訳言語ごとに個別の データベースを使用してサポートすることもできます。その 後、接続マッピングを通じて、望ましい言語を含むデータ ベースへのアクセスをユーザに許可します。 国際化されたデータを個別のテーブルと接続マッピングを使 用して識別するようにデータ ソースを構成する方法につい ては、「個別のデータベースによる国際化」（67 ページ）を 参照してください。 個別のデータベースと接続マッピングを通じてデータの国際 化を有効にするには、以下の手順で各言語に使用するデータ ベースを定義する必要があります。 前提条件 • プロジェクトが作成済みであること。 個別のデータベースと接続マッピングを通じてデータの国際化を 有効にするには 1 MicroStrategy Desktop でプロジェクトにログインします。 2 プロジェクトを右クリックし、[ プロジェクト構成 ] を選 択します。プロジェクト構成エディタが開きます。 96 プロジェクトの作成 © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド プロジェクトの作成および構成 4 3 [ カテゴリ ] リストで [ 言語 ] を展開し、[ データ ] を選択し ます。 4 [ データ インターナショナリゼーションを有効化 ] チェッ ク ボックスを選択して [ 接続マップに基づくデータ イン ターナショナリゼーション ] オプションを選択します。 5 翻訳データを使用可能にする言語の横にあるチェック ボックスを選択します。 データの国際化を有効にする言語を追加するには、次の 手順に従います。 a [ 追加 ] をクリックします。[ 使用可能な言語 ] ダイアロ グ ボックスが開きます。 b [ メタデータ言語のみ表示 ] チェック ボックスをクリ アします。 c データの国際化を有効にする言語のチェック ボック スを選択して、[OK] をクリックし、プロジェクト構 成エディタに戻ります。 6 言語ごとに [データベース接続] ドロップダウン リストか ら、言語用のデータベースを選択します。 データ ソースの作成方法の詳細は、『MicroStrategy 導入 と構成ガイド』を参照してください。 7 [OK] をクリックして変更を保存し、プロジェクト構成エ ディタを閉じます。 Project Builder によるテスト / プロトタイプ プロジェクト の作成 Project Builder は、単純な MicroStrategy プロジェクトを迅速 かつ効率的に作成できるウィザードです。Project Builder は 速度を重視して設計されています。したがって、機能はプロ ジェクト作成アシスタントのサブセットに過ぎませんが、 ユーザ階層と、単純なメトリックおよびレポートを迅速に作 成できます。Project Builder では、実際のデータを使用して プルーフ - オブ - コンセプト テストを行うためのプロジェク トのプロトタイプや、単純でありながら機能的なプロジェク トを作成できます。 © 2010 MicroStrategy, Inc. プロジェクトの作成 97 4 プロジェクトの作成および構成 プロジェクト デザイン ガイド 実稼働環境向けのプロジェクトを作成する場合は、「実稼働 プロジェクトの作成」（82 ページ）に示した手順に従うこと を強く推奨します。プロジェクト作成アシスタントと Architect では、より高度な機能と処理能力を備えたプロジェ クトを、実稼働環境向けに作成できます。 Project Builder の詳細を知るには、この項を読み進んでくだ さい。『Introduction to MicroStrategy: Evaluation Guide』と （Project Builder で F1 キーを押すと表示される）Project Builder オンライン ヘルプも参照できます。 Project Builder の使用 デフォルトでは、Project Builder はメタデータ リポジトリと して Microsoft Access データベースを使用します。Microsoft Access データベースはプロトタイプ プロジェクトのメタ データ リポジトリの作成には適していますが、実稼働環境 には不適です。Microsoft Access は、プルーフ - オブ - コンセ プトやデモ以外の用途には使用しないでください。 Mover を使用すれば デモ用のプロジェクトは、Project 実稼働可能なデータベースに移行できます（『システ ム管理ガイド』を参照）。 Project Builder には、プロトタイプ プロジェクトの作成を支 援する次のオプションがあります。 • マイ データベース : プロジェクトに名前を付け、作成す るプロジェクトで分析するビジネス情報を含んでいる データベースを選択できます。 • マイ ビジネス モデル : データベース内のビジネス情報を 定義する関係を識別できます。Project Builder は、この構 造を使用してデータ分析を支援します。 • マイ レポート : [ マイ ビジネス モデル ] で定義したアトリ ビュートとメトリックを使用して、さまざまなレポート を作成できます。これらのレポートは、あらかじめ定義 されたテンプレートに基づいており、レポートをプレ ビューしたり実行することも可能です。 『MicroStrategy レポートの作成とデザインの詳細は、 基本レポーティング ガイド』を参照してください。 98 プロジェクトの作成 © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド プロジェクトの作成および構成 4 Project Builder を開くには、[ スタート ] メニューから [ プログ ラム ]、[MicroStrategy]、[Desktop] の順に選択し、 [Project Builder] を選択します。 ファクトとアトリビュートの作成 この段階のプロジェクト作成プロセスでは、プロジェクト作 成アシスタントまたは Architect を使用して、ファクトとア トリビュートという 2 種類のスキーマ オブジェクトを作成 します。 ただし、ファクトとアトリビュートを作成する前に、ファク トとアトリビュートとは何であり、どのような特性によって 定義されるのかを理解することが重要です。この情報は、6 章、「ビジネス データの構築ブロック : ファクト」および 7 章、「ビジネス データのコンテキスト : アトリビュート」で 説明します。 他のスキーマレベル設定の構成 プロジェクト作成プロセスの最後のステップでは、他のス キーマレベルの設定を構成してスキーマ オブジェクトの分 析に奥行きを与え、プロジェクト全体を最適化します。この 設定には、次のものが含まれます。 • ファクト定義 : ファクト エディタでファクトを一度に 1 つずつ作成、編集、および構成できます。これについて は、「単純なファクトと高度なファクトの作成および変 更」（191 ページ）で説明します。 Architect でも、プロジェクトのいずれか、またはすべて のファクトを作成、編集、および構成できます。これに ついては、「ファクトの作成と変更」（136 ページ）で説 明します。 • © 2010 MicroStrategy, Inc. アトリビュート定義 : アトリビュート エディタで、アト リビュート、アトリビュート関係、アトリビュート フォーム、およびアトリビュート フォーム式を一度に 1 つずつ作成、編集、および構成できます。これについて は、「アトリビュートの追加と変更」（235 ページ）で説 明します。 ファクトとアトリビュートの作成 99 4 プロジェクトの作成および構成 プロジェクト デザイン ガイド Architect でも、プロジェクトのいずれか、またはすべて のアトリビュート、アトリビュート関係、アトリビュー ト フォーム、およびアトリビュート フォーム式を作成 し、編集することができます。これについては、「アトリ ビュートの作成と変更」（149 ページ）および「アトリ ビュート関係の定義」（173 ページ）で説明します。 • ユーザ階層 : 階層エディタでユーザ階層を作成できます。 ユーザ階層によって、アトリビュートとエレメントのブ ラウズやドリルが容易になります。これについては、8 章、「アトリビュートの構成とブラウズを行うための階層 の作成」で説明します。 Architect でも、プロジェクトのいずれか、またはすべて のユーザ階層を作成できます。これについては、「ユーザ 階層の作成と変更」（181 ページ）で説明します。 • 詳細構成 : 該当するオブジェクトには、トランスフォー メーション、集計テーブル、およびパーティションとそ のマッピングがあります。 トランスフォーメーション エディタではトランス フォーメーションを作成できます。トランスフォー メーションは、時系列分析に使用されるスキーマ オ ブジェクトです。トランスフォーメーションについて は、10 章、「時間ベースの比較やその他の比較を定義 するためのトランスフォーメーションの作成」で説明 します。 集計テーブルとパーティションの作成には、ウェアハ ウス カタログ、メタデータ パーティション マッピン グ エディタ、およびウェアハウス パーティション マッピング エディタを使用します。このトピックに ついては、9 章、「プロジェクトの最適化と管理」で 説明します。 この時点で、新規プロジェクト作成の主なステップの大部分 が完了しました。続いて、上記の該当する章に進み、プロ ジェクト作成プロセスの次のステップを実行してください。 プロジェクトの配備とレポートの作成 プロジェクトの作成が完了すると、MicroStrategy Web を使 用して、作成したプロジェクトをユーザ コミュニティに配 100 プロジェクトの配備とレポートの作成 © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド プロジェクトの作成および構成 4 備できます。なお、この章で説明したステップだけを完了し ても、プロジェクトには基本的なファクトとアトリビュート が含まれているに過ぎません。前述した適切な章に進んで、 プロジェクトに分析の奥行きと機能を追加してください。 ファクトとアトリビュートは、レポート デザイナが作成す るレポートとドキュメントの土台になります。ファクトはメ トリックの作成に使用されます。メトリックとアトリビュー トは、レポートに欠かせないコンポーネントです。 メトリックとその他のレポート オブジェクト（フィルタ、 カスタム グループ、プロンプトなど）は、このガイドの対 象には含まれません。メトリック、フィルタ、レポート、お よびその他のレポート オブジェクトの詳細は、 『MicroStrategy 基本レポーティング ガイド』と 『MicroStrategy 上級基本レポーティング ガイド』を参照して ください。 MicroStrategy Web を使用してプロジェクトを配備する方法 の詳細は、『MicroStrategy 導入と構成ガイド』の 「MicroStrategy Web によるプロジェクトの配布」の章を参照 してください。 レポートの作成には、MicroStrategy Desktop と MicroStrategy Web を使用できます。MicroStrategy Desktop でのプロジェク トの作成については、『MicroStrategy 基本レポーティング ガ イド』を、MicroStrategy Web でのレポートの作成について は MicroStrategy Web のオンライン ヘルプを、それぞれ参照 してください。 以下の点に注意してください。 © 2010 MicroStrategy, Inc. • MicroStrategy では、SAP BI、Microsoft Analysis Services、および Hyperion Essbase のデータ ソース に接続できます。MDX キューブ ソースへの接続 の詳細については、『MicroStrategy MDX Cube Reporting Guide』を参照してください。 • レポートの作成に、カスタマイズした SQL ステー トメントを使用する方法については、 『MicroStrategy 上級レポーティング ガイド』の 「Custom SQL Queries: Freeform SQL and Query Builder」の章を参照してください。 プロジェクトの配備とレポートの作成 101 4 プロジェクトの作成および構成 102 プロジェクトの配備とレポートの作成 プロジェクト デザイン ガイド © 2010 MicroStrategy, Inc. 5 5. ARCHITECT によるプロジェ クトの作成 はじめに MicroStrategy には、Architect というプロジェクト デザイン ツールがあります。Architect を使用すると、一元管理された インタフェースからプロジェクトの必須コンポーネントをす べて定義できます。Architect では、作成中のプロジェクトが 視覚的に表示されるため、ワークフローを直感的に捉えるこ とができます。 Architect はプロジェクト作成アシスタントと共に提供されま す。プロジェクト作成アシスタントは、プロジェクト作成プ ロセスを段階的に実行できるウィザード型のツールです。 Architect では、プロジェクト作成プロセスを段階的に進める 代わりに、プロジェクトを作成しながら、その変化を視覚的 に確認できます。Architect とプロジェクト作成アシスタント の違いについては、「Architect とプロジェクト作成アシス タント」（84 ページ）を参照してください。 Architect では、多岐にわたるプロジェクトの作成および変更 タスクが実行できます。この章では、これらのタスクについ て、以下の項で説明しています。 • 「プロジェクトの作成と変更」（104 ページ） © 2010 MicroStrategy, Inc. 103 5 Architect によるプロジェクトの作成 プロジェクト デザイン ガイド • 「テーブルの追加、削除、および管理」（122 ページ） • 「ファクトの作成と変更」（136 ページ） • 「アトリビュートの作成と変更」（149 ページ） • 「アトリビュート関係の定義」（173 ページ） • 「ユーザ階層の作成と変更」（181 ページ） プロジェクトの作成と変更 Architect では、新規プロジェクトの作成に関連するすべての タスクと、プロジェクトのライフ サイクルを通じて必要に なる変更を行うことができます。実行できるタスクは、次の とおりです。 • 「プロジェクト作成 / 表示オプションの定義」（104 ペー ジ） • 「Architect によるプロジェクトの作成」（116 ページ） • 「Architect によるプロジェクトへの変更」（120 ページ） プロジェクト作成 / 表示オプションの定義 Architect では、プロジェクトの作成および変更方法を、さま ざまなオプションを通じて決定できます。Architect を使用す る前に、これらのオプションを確認して定義すれば、プロ ジェクトの作成と変更に要する時間を短縮できます。 これらのオプションを定義することによって、Architect がど のようにしてデータを表示し、スキーマ オブジェクトを自 動的に作成してマップし、ウェアハウス カタログをロード し、プロジェクト スキーマを更新するかが決まります。こ れらのオプションは、[MicroStrategy Architect 設定 ] ダイアロ グ ボックスにあります。このダイアログ ボックスを表示す る手順については、「Architect のオプションへのアクセス」 （105 ページ）を参照してください。次に示す項で、定義で きる各オプションを説明します。 • 「Architect 起動時の表示内容の選択」（105 ページ） 104 プロジェクトの作成と変更 © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド Architect によるプロジェクトの作成 5 • 「ファクトとアトリビュートの作成の自動化」（106 ペー ジ） • 「既存のアトリビュート フォームおよびファクトへの列 の自動マッピング」（108 ページ） • 「テーブル内の列とアトリビュート フォームの表示」 （109 ページ） • 「テーブルの追加の無効化」（112 ページ） • 「プロジェクト スキーマの自動更新」（113 ページ） • 「プロジェクトのファクトに基づくメトリックの作成」 （113 ページ） • 「アトリビュート関係の自動定義」（114 ページ） Architect のオプションへのアクセス [MicroStrategy Architect 設定 ] ダイアログ ボックスは、 Architect から開くことができます。Architect で [ オプション] メニューから [ 設定 ] を選択します。[MicroStrategy Architect 設定 ] ダイアログ ボックスが開きます。 Architect 起動時の表示内容の選択 Architect の起動時にプロジェクト テーブル ビューと階層表 示のどちらを表示するか選択できます。この選択には [ デ フォルト表示を選択 ] ドロップダウン リストを使用します。 このドロップダウン リストは、[MicroStrategy Architect 設定 ] ダイアログ ボックスの [ 構成 ] タブにあります。Architect が 開いたときに表示される内容を、次のオプションから選択で きます。 © 2010 MicroStrategy, Inc. • 最後に使用した表示 : Architect を前回使用したときに、 最後に使用されていた表示を選択します。 • プロジェクト テーブル ビュー : プロジェクト テーブル ビューを表示します。 • 階層表示 : 階層表示を選択します。 プロジェクトの作成と変更 105 5 Architect によるプロジェクトの作成 プロジェクト デザイン ガイド ファクトとアトリビュートの作成の自動化 プロジェクトのデザインでは、Architect にアトリビュートと ファクトを自動作成させることによって、スキーマ作成プロ セスに要する時間を短縮できます。Architect は、プロジェク トにテーブルが追加されたときに、アトリビュートとファク トを自動的に作成できます。アトリビュートとファクトは、 データ型、データベースの列名、主キーと外部キー、および その他のスキーマ作成ヒューリスティックに基づいて作成さ れます。 プロジェクトにテーブルを追加したときにアトリビュートと ファクトが作成される方法は、自動列認識の規則を定義する ことによって指定できます。これらの規則は、 [MicroStrategy Architect 設定 ] ダイアログ ボックスの [ 自動 ヒューリスティック ] タブにあります。 • 自動認識しない : Architect でプロジェクトにテーブルを 追加したときに、アトリビュートとファクトが自動作成 されないようにするオプションです。 このオプションは、既存プロジェクトを更新しており、 すでに多数のプロジェクト スキーマが定義済みの場合に 適しています。このオプションを選択すると、Architect はプロジェクトに必要でない可能性があるアトリビュー トとファクトを自動定義しません。プロジェクトにその 他のテーブルを追加した後、現在のプロジェクト スキー マに適した方法で、必要なアトリビュートとファクトを 作成できます。 • 自動認識 : Architect でプロジェクトにテーブルを追加し たときに、アトリビュートとファクトが自動作されるよ うにするオプションです。 このオプションで Architect にアトリビュートとファクト を自動作成させることによって、プロジェクト デザイン のスキーマ作成プロセスに要する時間を短縮できます。 このオプションを選択すると、数値データ型を使用し、 アトリビュート フォームに使用されないデータベース列 にファクトが作成されます。アトリビュートとアトリ ビュート フォームは、さまざまなスキーマ作成ヒューリ スティックと、以下に示す [ 高度なオプション ] で定義し た規則に基づいて作成されます。 106 プロジェクトの作成と変更 © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド Architect によるプロジェクトの作成 5 区切り : データベース列名の区切りとして使用する文 字を入力します。たとえば、USER_ID のようなデー タベース列名では、下線（_）が区切りになります。 アトリビュート名付け規則 : 新しいアトリビュートに ID フォームとしてマップすべき列を示すデータベー ス列名の接尾語を入力します。通常、アトリビュート に ID フォームとしてマップされるデータベース列に は、接尾語として ID が使用されます。 新規アトリビュートにマップすべき接尾語の区切りに は、セミコロン（;）を使用してください。 アトリビュート名の作成方法も定義できます。接尾語 を他の文字列で置き換えてアトリビュート名を作成す るには、縦線（|）を使用します。縦線（|）の左側 に接尾語を指定し、作成されるアトリビュート名の中 で接尾語を置き換える文字列を | の右側に指定しま す。 たとえば、ID|; と指定すると、接尾語 ID を持つす べてのデータベース列に新規アトリビュートが作成さ れ、接尾語 ID がアトリビュート名から削除されま す。したがって、USER_ID のような列を含むテーブ ルがプロジェクトにインポートされると、User とい う名前の新規アトリビュートが作成されます。 DT|DATE; と指定すると、接尾語 DT を持つすべての データベース列に新規アトリビュートが作成され、 DT を DATE で置き換えたアトリビュート名が付けら れます。したがって、YEAR_DT のような列を含む テーブルがプロジェクトにインポートされると、Year Date という名前の新規アトリビュートが作成されま す。 アトリビュート フォーム名付け規則 : 新しいアトリ ビュート フォームにマップすべき列を示すデータ ベース列名の接尾語を入力します。通常、説明アトリ ビュート フォームにマップされるデータベース列に は、接尾語として DESC が使用されます。 新規アトリビュート フォームにマップすべき接尾語 の区切りには、セミコロン（;）を使用してくださ い。 アトリビュート フォーム名の作成方法も定義できま す。接尾語を他の文字列で置き換えてアトリビュート フォーム名を作成するには、縦線（|）を使用しま © 2010 MicroStrategy, Inc. プロジェクトの作成と変更 107 5 Architect によるプロジェクトの作成 プロジェクト デザイン ガイド す。縦線（|）の左側に接尾語を指定し、作成される アトリビュート フォーム名の中で接尾語を置き換え る文字列を | の右側に指定します。 DSC|DESC; と指定すると、接尾語 DSC を持つすべて のデータベース列に新規アトリビュート フォームが 作成され、DSC を DESC で置き換えたアトリビュート フォーム名が付けられます。したがって、 PRODUCT_DSC のような列を含むテーブルがプロジェ クトにインポートされると、Product Desc という名前 の新規アトリビュート フォームが作成されます。 これらの規則を使用したアトリビュートとアトリ ビュート フォームの定義に加え、[ 自動認識 ] オプ ションでは他のスキーマ作成ヒューリスティックも使 用されます。 – 「既存のアトリビュート フォームおよびファクト への列の自動マッピング」（108 ページ）で説明す る自動列マッピング規則によって、列はそれを定 義で使用している既存アトリビュート フォームに マップされます。 – 主キーまたは外部キーとして定義されているすべ ての列にアトリビュートが作成され、主キーの列 名に基づくアトリビュート名が付けられます。主 キーの列名は、プロジェクトに主キーの列が含ま れていない場合でも、アトリビュート名の定義に 使用されます。 – すべての列が 1 つのファクトまたはアトリビュー トにマップされる必要があります。スキーマ作成 ヒューリスティック、ユーザ定義の規則のいずれ でも、ファクトとアトリビュートのどちらを列に 作成すべきか判定できない場合には、アトリ ビュートが作成されます。 既存のアトリビュート フォームおよびファクトへ の列の自動マッピング Architect を使用して、プロジェクト内の定義済みのアトリ ビュート フォームとファクトに列を自動的にマップさせる ことによって、プロジェクト デザインのスキーマ作成プロ セスに要する時間を短縮できます。Architect は、プロジェク トにテーブルが追加されたときに、既存のアトリビュート フォームとファクトに列を自動的にマップできます。 108 プロジェクトの作成と変更 © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド Architect によるプロジェクトの作成 5 テーブルをプロジェクトに追加したときに、列をアトリ ビュート フォームとファクトに自動的にマップさせるには、 [ 自動列マップを使用 ] チェック ボックスを選択します。こ のオプションは、[MicroStrategy Architect 設定 ] ダイアログ ボックスの [ 自動ヒューリスティック ] タブにあります。 このオプションが有効なときにプロジェクトにテーブルを追 加すると、テーブルに含まれる列式が、アトリビュート フォームとファクトで使用されている列式と比較されます。 列式が一致するアトリビュート フォームまたはファクトが 見つかると、列はそのアトリビュート フォームまたはファ クトにマップされます。たとえば、MicroStrategy Tutorial プ ロジェクトでは、"Revenue"（売上）ファクトが TOT_DOLLAR_SALES 列にマップされます。自動列マッピン グが有効なときに、Architect を使用して TOT_DOLLAR_SALES 列を含むテーブルをプロジェクトに追 加すると、このテーブルの TOT_DOLLAR_SALES 列は "Revenue" ファクトに自動的にマップされます。 [ 自動列マップを使用 ] オプションは、新しく追加されたテー ブル内の列を、ファクトやアトリビュートを新たに作成する ことなく、既存のファクトやアトリビュートに自動的にマッ プする手段として、特に効果的です。新しく追加されたテー ブル内の列を既存のファクトとアトリビュートにマップし、 同時にさまざまな規則に基づいて新規のファクトとアトリ ビュートを作成するには、[ 自動認識 ] オプションを有効にす る必要があります（「ファクトとアトリビュートの作成の自 動化」（106 ページ）を参照）。 テーブル内の列とアトリビュート フォームの表示 Architect を使用してテーブルをプロジェクトに追加する際に は、そのテーブルに含まれているさまざまなスキーマ オブ ジェクトと、スキーマ オブジェクトの定義に使用されてい る列を見ることができます。 プロジェクト内のテーブルに含まれているデータの表示は、 以下のオプションで設定できます。このオプションは、 [MicroStrategy Architect 設定 ] ダイアログ ボックスの [ 設定を 表示 ] タブにあります。 • © 2010 MicroStrategy, Inc. テーブルを物理表示で表示 : テーブルに含まれる列を表 示するオプションです。列は「列の名前 : 列のデータ 型」の形式で表示されます。たとえば、MicroStrategy プロジェクトの作成と変更 109 5 Architect によるプロジェクトの作成 プロジェクト デザイン ガイド Tutorial プロジェクトの YR_CATEGORY_SLS は、物理表 示では次のように表示されます。 • テーブルを論理表示で表示 : テーブルに含まれる列と、 MicroStrategy スキーマ オブジェクトと列の関係を表示す るオプションです。MicroStrategy Tutorial プロジェクトの LU_YEAR テーブルと LU_REGION テーブルの論理表示を 次に示します。テーブル内の列とアトリビュート フォー ムの表示に使用できるさまざまな論理表示オプションに ついて、これらのテーブルを使用して説明します。 論理表示には、以下に説明する表示オプションがありま す。これらのオプションは、[ 高度なオプション ] をク リックすると利用できます。 論理テーブルに使用可能な列を表示 : テーブル内の列 のうち、プロジェクト内のスキーマ オブジェクトで 使用されていない列を表示する論理表示オプションで 110 プロジェクトの作成と変更 © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド Architect によるプロジェクトの作成 5 す。列は「列の名前 : 列のデータ型」の形式で表示 されます。 このオプションを選択すると、上に示した LU_YEAR テーブルに、スキーマ オブジェクトにマップされて いない PREV_YEAR_ID : INTEGER 列が表示されま す。 この情報は、1 つのテーブルを対象に表示することも できます。テーブルを右クリックして [ プロパティ ]、 [ 論理表示 ] を順に選択し、[ 利用可能な列を表示 ] を選 択します。 このオプションを選択すると、以下のオプションも選 択可能になります。 – データ インターナショナリゼーションに使用した 列を表示 : テーブル内でデータの国際化に使用で きる列を表示するオプションです。列は「列の名 前 : 列のデータ型」の形式で表示されます。 このオプションを選択すると、上に示した LU_REGION テーブル内に、地域名をさまざまな 言語に翻訳するために使用される複数の REGION_NAME 列が表示されます。 データ ソース内で国際化されたデータをサポート する方法については、「データの国際化のサポー ト」（63 ページ）を参照してください。 使用した論理テーブルの列を表示 : プロジェクト内の スキーマ オブジェクトで使用されている列（および 列のデータ型）を表示するオプションです。列は「列 の名前 : 列のデータ型」の形式で表示されます。 このオプションを選択すると、上に示した LU_YEAR テーブルに、"Year"（年）アトリビュートの ID フォームとして使用されている YEAR_ID : INTEGER 列が表示されます。このオプションを LU_YEAR テーブルを対象に選択すると、"Year" アト リビュートの日付フォームにマップされている YEAR_DATE : TimeStamp 列と、"Year Duration" （年の長さ）ファクトにマップされている YEAR_DURATION : INTEGER 列が表示されます。 © 2010 MicroStrategy, Inc. プロジェクトの作成と変更 111 5 Architect によるプロジェクトの作成 プロジェクト デザイン ガイド この情報は、1 つのテーブルを対象に表示することも できます。テーブルを右クリックして [ プロパティ ]、 [ 論理表示 ] を順に選択し、[ 使用した列を表示 ] を選択 します。 論理テーブルにアトリビュート フォームを表示 : テーブルの列にマップされているアトリビュート フォームを表示するオプションです。アトリビュート フォームは、「アトリビュート フォームの名前 : ア トリビュート フォームのカテゴリ （列の名前）」の形 式で表示されます。 このオプションを選択すると、上に示した LU_YEAR テーブルに、"Year" アトリビュートに対応する ID フォームと Date フォームが表示されます。 この情報は、1 つのテーブルを対象に表示することも できます。テーブルを右クリックして [ プロパティ ]、 [ 論理表示 ] を順に選択し、[ アトリビュート フォーム を表示 ] を選択します。 • 各テーブル行の最大表示リンク数 : テーブル内の列、 ファクト、アトリビュート、またはアトリビュート フォームを選択したときに表示されるリンク直線の数を 定義します。これらのオブジェクトのいずれかをテーブ ル内で選択すると、プロジェクト内の他のテーブルに存 在するすべての同じオブジェクトとの間に直線が表示さ れます。たとえば、[LU_YEAR] テーブル内で "Year" アト リビュートを選択すると、他のテーブル内に存在するす べての "Year" アトリビュートにつながる直線が表示され ます。 テーブルの追加の無効化 Architect のデフォルトでは、ウェアハウス カタログをブラ ウズしてプロジェクトに新しいテーブルを柔軟に追加できま す。ただし、必要なすべてのテーブルがすでにプロジェクト に含まれている場合は、プロジェクトにテーブルを追加する 機能を無効にすることもできます。これにより、不要なテー ブルがプロジェクトに追加され、不要なスキーマ オブジェ クトの作成を引き起こす事態を回避できます。また、ウェア ハウス カタログ内のすべてのテーブルを利用可能にする必 要がないため、Architect のパフォーマンスも向上します。 112 プロジェクトの作成と変更 © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド Architect によるプロジェクトの作成 5 Architect でプロジェクトに新しいテーブルを追加する機能を 無効にするには、[ ウェアハウス カタログ ロードを無効化 ] チェック ボックスを選択します。このオプションは、 [MicroStrategy Architect 設定 ] ダイアログ ボックスの [ 構成 ] タブにあります。プロジェクトに含まれていないテーブル は、すべて Architect の表示から隠されます。 プロジェクト スキーマの自動更新 Architect で加えた変更は、プロジェクトのスキーマに影響を 与えます。デフォルトでは、プロジェクトのスキーマは、変 更を保存して Architect を終了するときに更新されます。こ れにより、変更がプロジェクトに確実に反映されます。 Architect を終了するたびにプロジェクト スキーマを更新す る機能は、無効にすることができます。スキーマの更新は Intelligence Server に大きな処理負荷をかけ、完了までにかな りの時間を要する場合があります。Architect の使用後に、他 のプロジェクトの更新予定が控えているケースも考えられま す。そのような場合には、プロジェクト スキーマの自動更 新を無効化して、スキーマの更新を手動で適宜、実行するこ とができます。Architect を閉じるときにプロジェクト ス キーマが更新されないようにするには、[MicroStrategy Architect を閉じてから § スキーマを更新 ] チェック ボック スをクリアします。このオプションは、[MicroStrategy Architect 設定 ] ダイアログ ボックスの [ 構成 ] タブにありま す。 プロジェクトのファクトに基づくメトリックの作成 Architect では、プロジェクト用に作成したファクトを基にメ トリックを作成することができます。これにより、プロジェ クトの基本的なメトリックの作成に要する時間を短縮できま す。 プロジェクトのファクトを基にメトリックを作成するオプ ションは、[MicroStrategy Architect 設定 ] ダイアログ ボック スの [ メトリック作成 ] タブにあります。このタブで、以下 の集計関数を使用してメトリックを自動作成することができ ます。 • © 2010 MicroStrategy, Inc. Avg: ファクト式に平均値計算を実行するメトリックを作 成します。 プロジェクトの作成と変更 113 5 Architect によるプロジェクトの作成 プロジェクト デザイン ガイド • Sum: ファクト式に合計計算を実行するメトリックを作 成します。 • Count: ファクト式に回数計算を実行するメトリックを作 成します。 • Min: ファクト式に最小値計算を実行するメトリックを作 成します。 • Max: ファクト式に最大値計算を実行するメトリックを作 成します。 • Var: ファクト式に差異計算を実行するメトリックを作成 します。 プロジェクトのファクトが作成されるときに、選択した集計 関数を使用して、そのファクトからメトリックが自動的に作 成されます。ファクトの集計ごとに、対応するメトリックが 個別に作成されます。メトリックが作成される場所は、 MicroStrategy プロジェクトの Public Objects/Metrics フォルダ内です。 アトリビュート関係の自動定義 Architect では、データ ソース内のデータのデザインに基づ いて、アトリビュート関係を作成できます。これにより、プ ロジェクト内のアトリビュート間の関係作成に要する時間を 短縮できます。 プロジェクト内のアトリビュート間のアトリビュート関係を 自動的に作成するオプションは、[MicroStrategy Architect 設 定] ダイアログ ボックスの [自動ヒューリスティック] タブに あります。このタブで以下のオプションを選択して、アトリ ビュート関係を自動的に作成できます。 114 プロジェクトの作成と変更 • 自動作成を使用しない : データ ソース内のデータのデザ インに基づくアトリビュート関係の自動作成を無効にし ます。Architect でアトリビュート関係を手動で定義する 方法については、「アトリビュート関係の定義」（173 ページ）を参照してください。 • 自動作成を使用 : プロジェクトにテーブルを追加すると きに、データ ソース内のデータのデザインを基にアトリ ビュート関係が自動的に作成されます。アトリビュート 関係の自動定義アクションを実行するには、「アトリ © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド Architect によるプロジェクトの作成 5 ビュート関係の自動定義」（179 ページ）で説明している ように [ システム階層 ] ダイアログ ボックスを使用しま す。 アトリビュート関係は、[ 高度なオプション ] で選択した 規則に基づいて作成されます。以下の規則があります。 主キー / 外部キーに基づく : テーブル内で定義されて いる主キーと外部キーを基にアトリビュート関係を作 成します。テーブルの外部キーとして機能する各アト リビュートは、同じテーブルの主キーとして機能する 各アトリビュートの親アトリビュートです。アトリ ビュート関係は、外部キー アトリビュート（親アト リビュート）から主キー アトリビュート（子アトリ ビュート）への 1 対多関係として定義されます。 ルックアップ テーブルに基づく : 主キーや外部キー 情報を含まないルックアップ テーブルを基にアトリ ビュート関係を作成します。テーブルをアトリビュー トのルックアップ テーブルとして定義する方法につ いては、「アトリビュートの作成」（150 ページ）を参 照してください。ルックアップ テーブルとして定義 されたテーブルを持つ各アトリビュートが、同じテー ブル内の他の全アトリビュート（ルックアップ テー ブルとして定義されたテーブルを持たないアトリ ビュート）の子アトリビュートになります。各アトリ ビュート関係は、親アトリビュートから子アトリ ビュートへの 1 対多関係として定義されます。 テーブルからのサンプル データに基づく : 同じルッ クアップ テーブルを共有する複数のアトリビュート のアトリビュート関係を作成します。テーブルをアト リビュートのルックアップ テーブルとして定義する 方法については、「アトリビュートの作成」（150 ペー ジ）を参照してください。 Architect がテーブルのサンプル データを分析します。 固有値の少ないアトリビュートが、親アトリビュート から子アトリビュートへの 1 対多関係を使用して、固 有値の多いアトリビュートの親になります。たとえ ば、4 行のデータを含むルックアップ テーブルに、年 と四半期に関連するデータが含まれているとします。 各行には同じ年（2009 など）が含まれていますが、 四半期は行ごとに異なっています（Q1、Q2、Q3、 Q4）。この場合、"Year"（年）アトリビュートが "Quarter"（四半期）アトリビュートの親として作成さ れます。 © 2010 MicroStrategy, Inc. プロジェクトの作成と変更 115 5 Architect によるプロジェクトの作成 プロジェクト デザイン ガイド 選択した規則によってすべての関係が決定されると、そ れらのアトリビュート関係に対して Architect が最終分析 を実行します。その結果、冗長と判定されたアトリ ビュート関係は作成されません。これにより、データ ソース内のデータのデザインを適切に反映したアトリ ビュート関係が作成されます。作成されたアトリビュー ト関係を変更する方法については、「アトリビュート関係 の定義」（173 ページ）を参照してください。 Architect によるプロジェクトの作成 プロジェクト作成アシスタントでは、段階的なプロセスを通 じてプロジェクトを作成しますが、Architect を使用すれば新 規プロジェクトを視覚的に作成できます。ただし、Architect を使用する前に、プロジェクト作成アシスタントでプロジェ クト オブジェクトを作成し、さまざまな Architect プロジェ クト作成オプションを定義する必要があります。 前提条件 • プロジェクトを作成する前に、次に示す項の説明に従っ てメタデータ リポジトリとデータ ソースに接続する必要 があります。 「メタデータ リポジトリへの接続」（79 ページ） 「データ ソースへの接続」（80 ページ） さらに、Architect でプロジェクトを作成する前に、4 章、 「プロジェクトの作成および構成」に記載されている情報 を再確認してください。 Architect を使用して新規プロジェクトを作成するには 1 MicroStrategy Desktop で、プロジェクト ソースにログ インします。 Intelligence Server 経由でデータに接続するプロジェクト ソースを作成する方法については、『MicroStrategy 導入お よび構成ガイド』の「Intelligence Server の構成および接 続」の章を参照してください。 116 プロジェクトの作成と変更 © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド Architect によるプロジェクトの作成 5 2 [ スキーマ ] メニューで、[ 新規プロジェクトを作成 ] を選 択します。次に示すプロジェクト作成アシスタントが開 きます。 3 [ プロジェクトの作成 ] をクリックします。[ 新規プロジェ クト ] ページが開きます。 4 次のプロジェクト構成を定義します。 © 2010 MicroStrategy, Inc. • 名前 : プロジェクトの名前。この名前は、プロジェク ト ソース内のプロジェクトの識別に使用されます。 • 説明 : プロジェクトの説明（省略可） 。プロジェクト の用途を、他のプロジェクトと比較して簡潔に説明し ます。 • デフォルト ドキュメント ディレクトリ : すべての HTML ドキュメントを格納するディレクトリの場所。 プロジェクトの HTML ドキュメントをセットアップ する方法の詳細は、『導入および構成ガイド』を参照 してください。 • このプロジェクトにゲスト ユーザ アカウントを有効 化 : ユーザ認証情報なしのログインをユーザに許可す る場合、このチェック ボックスを選択します。選択 プロジェクトの作成と変更 117 5 Architect によるプロジェクトの作成 プロジェクト デザイン ガイド した場合、ユーザは（Public グループで定義された） 限られた権限と許可だけで Intelligence Server に接続 できます。 • このプロジェクトに変更履歴を有効化 : プロジェクト の変更履歴を有効にする場合、このチェック ボック スを選択します。プロジェクト内のオブジェクトに変 更が加えられるたびに、履歴に自動的にエントリが追 加されます。これにより、プロジェクトの変更の追跡 が可能になります。変更履歴の詳細は、『システム管 理ガイド』を参照してください。 • 言語 : このプロジェクト内のメタデータ オブジェクト で利用可能な言語を定義する場合は、このボタンをク リックします。ここで選択する言語は、メタデータ オブジェクトの国際化に利用可能な言語でもありま す。プロジェクトで利用可能な言語を指定すると、オ ブジェクト名、説明、その他の情報を、複数の言語で 提供することが可能になります。たとえば、プロジェ クト内でアトリビュート、メトリック、フォルダ、そ の他のオブジェクトの名前を、複数の言語で提供でき ます。アトリビュート、メトリック、フォルダ、その 他のメタデータ オブジェクト用に、国際化された データを用意する方法については、『システム管理ガ イド』を参照してください。 MicroStrategy には、利用可能なデフォルト言語のリス トに含まれる各言語に翻訳した、共通メタデータ オ ブジェクト用の国際化データが含まれています。たと えば、" パブリック オブジェクト " フォルダや、その 他の共通オブジェクトの名前と説明を、デフォルトで 利用可能な言語リストに含まれる各言語に翻訳した データが用意されています。その他の言語を追加する 場合は、共通メタデータ オブジェクトのすべての国 際化データを用意する必要があります。 下記に注意してください。 – 118 プロジェクトの作成と変更 新規プロジェクトの作成時には言語チェックが実 行され、ローカル マシンのユーザ プロファイル （CURRENT_USER レジストリ キー）の言語設定、 ローカル マシン（LOCAL_MACHINE レジストリ キー）の言語、およびプロジェクトのロケール プ ロパティが一致しているかどうかが検証されます。 これらのプロパティが一致しないと、言語表示の © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド Architect によるプロジェクトの作成 5 不整合の原因になります。言語チェックによって、 そのような不整合がなくなり、言語表示がプロ ジェクト全体で一貫している状態が確保されます。 – これらの言語オプションは、データ ソースから MicroStrategy に渡される国際化データの整合性と は関係ありません。データの国際化をサポートす るようにデータ ソースを定義する方法について は、「データの国際化のサポート」（63 ページ）を 参照してください。 データ ソースから得られた国際化データをプロ ジェクト内のアトリビュートで使用するには、 データの国際化を有効にする方法を、アトリ ビュートの作成前に定義する必要があります。 データの国際化を有効にする方法については、「プ ロジェクトのデータの国際化」（92 ページ）を参 照してください。 5 [OK] をクリックすると、プロジェクト オブジェクトが 作成されます。 6 [Architect] を指す矢印をクリックします。[ ウェアハウ ス データベース インスタンス ] ダイアログ ボックスが開 きます。 プロジェクト作成アシスタントでプロジェクト作 成を継続する場合は、「プロジェクト作成アシス タントによる新規プロジェクトの作成」（85 ペー ジ）を参照してください。 7 ドロップダウン リストからデータベース インスタンスを 選択します。このダイアログ ボックスで選択したデータ ベース インスタンスによって、アクセス先のデータ ソー スが決まります。 8 [OK] をクリックします。MicroStrategy Architect が開きま す。 9 [ オプション ] メニューから [ 設定 ] を選択します。 [MicroStrategy Architect 設定 ] ダイアログ ボックスが開き ます。 10 Architect がどのようにしてデータを表示し、スキーマ オ ブジェクトを自動的に作成してマップし、ウェアハウス カタログをロードし、プロジェクト スキーマを更新する かを、さまざまなオプションで定義します。 © 2010 MicroStrategy, Inc. プロジェクトの作成と変更 119 5 Architect によるプロジェクトの作成 プロジェクト デザイン ガイド Architect を使用する前に、これらのオプションを確認し て定義すれば、プロジェクトの作成と変更に要する時間 を大幅に短縮できます。利用可能なすべてのオプション については、「プロジェクト作成 / 表示オプションの定 義」（104 ページ）を参照してください。 11 [OK] をクリックします。この時点で、プロジェクトへの テーブルの追加を開始し、アトリビュート、ファクト、 ユーザ階層などを作成できます。これらのタスクを以下 に示します。 a 「テーブルの追加」（124 ページ） b 「ファクトの作成」（137 ページ） c 「アトリビュートの作成」（150 ページ） d 「アトリビュート関係の定義」（173 ページ） e 「ユーザ階層の作成」（182 ページ） Architect によるプロジェクトへの変更 プロジェクトの作成後にスキーマ オブジェクトに変更を加 えるには、ファクト エディタ、アトリビュート エディタ、 階層エディタなど、個別のエディタを使用します。これらの エディタは、単純なものから高度なものまで、スキーマ オ ブジェクトのすべての機能を備えており、スキーマ オブ ジェクトを一度に 1 つずつ作成し、変更を加えることができ ます。 Architect では、プロジェクト全体に適用する変更や、個々の スキーマ オブジェクトの作成または変更を、1 つの統合され た環境で実行できます。スキーマ オブジェクトを 1 つずつ 作成または変更する代わりに、プロジェクトの複数のスキー マ オブジェクトを一括して作成したり、それらに変更を加 えることができます。さらに Architect では、プロジェクト へのテーブルの追加と、アトリビュート、ファクト、および ユーザ階層の作成や変更を、すべて同じインタフェースで実 行できます。 120 プロジェクトの作成と変更 © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド Architect によるプロジェクトの作成 5 Architect でプロジェクトに変更を加えるときには、プロジェ クトのスキーマをロックすることが可能です。これにより、 予定されたプロジェクトの保守作業中に、ユーザがレポート の問題に直面したり、古くなったデータが返される事態を回 避できます。 Architect を使用してプロジェクトに変更を加える手順を次に 示します。 前提条件 • プロジェクトが作成済みであること。 Architect を使用してプロジェクトに変更を加える手順 1 MicroStrategy Desktop でプロジェクトにログインします。 2 [ スキーマ ] メニューで [Architect] を選択します。 MicroStrategy Architect が開きます。 3 [ オプション ] メニューから [ 設定 ] を選択します。 [MicroStrategy Architect 設定 ] ダイアログ ボックスが開き ます。 4 Architect がどのようにしてデータを表示し、スキーマ オ ブジェクトを自動的に作成してマップし、ウェアハウス カタログをロードし、プロジェクト スキーマを更新する かを、さまざまなオプションで定義します。 Architect を使用する前に、これらの Architect のオプ ションを確認して定義すれば、プロジェクトの作成と変 更に要する時間を大幅に短縮できます。利用可能なすべ てのオプションについては、「プロジェクト作成 / 表示オ プションの定義」（104 ページ）を参照してください。 5 [OK] をクリックして Architect に戻ります。この時点で、 テーブルのプロジェクトへの追加やプロジェクトからの 削除に着手し、アトリビュート、ファクト、ユーザ階層 などを作成および変更できます。 • 「テーブルの追加、削除、および管理」（122 ページ） • 「ファクトの作成と変更」（136 ページ） • 「アトリビュートの作成と変更」（149 ページ） © 2010 MicroStrategy, Inc. プロジェクトの作成と変更 121 5 Architect によるプロジェクトの作成 プロジェクト デザイン ガイド • 「アトリビュート関係の定義」（173 ページ） • 「ユーザ階層の作成と変更」（181 ページ） テーブルの追加、削除、および管理 プロジェクトのウェアハウス テーブルは、プロジェクトで 分析可能なデータ セットを決定します。プロジェクトの テーブルは、Architect を使用して追加、削除、更新、および 管理できます。 カタログは、「ウェアハウス カタログに ウェアハウス よるテーブルの追加」（89 ページ）で説明したよう に、テーブルのプロジェクトへの追加やプロジェクト からの削除にも使用できます。 Architect は次の図に示すように、プロジェクトに利用可能な すべてのデータ ソースを [ ウェアハウス テーブル ] ペインに 表示します。 ウェアハウス テーブル ] ペインが Architect に表示さ [れていない場合は、 [ 表示 ] メニューから [ ウェアハウ ス テーブルを表示 ] を選択します。[Warehouse Tables] 122 テーブルの追加、削除、および管理 © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド Architect によるプロジェクトの作成 5 ペインを利用できるのは、Architect のプロジェクト テーブル ビューだけです。 各データ ソース内には、データベース インスタンスを介し て接続しているデータ ソース内のすべてのテーブルがリス トされます。このリストから、新規プロジェクトに使用する ルックアップ テーブル、ファクト テーブル、および関係 テーブルを選択します。さらに、トランスフォーメーション テーブル、集計テーブル、パーティション マッピング テー ブルなど、プロジェクトを完成させるために必要な、その他 すべてのテーブルを含めます。 ログインには、選択したデー 使用するデータベース タ ソース内のテーブルを表示できるように、読み取 り権限が必要です。データベース インスタンスと データベース ログインは、プロジェクトが接続する データ ソースを決定する MicroStrategy オブジェクト です。これらのオブジェクトの詳細については、 『MicroStrategy 導入および構成ガイド』を参照してく ださい。 Architect を使用して次のタスクを実行することで、プロジェ クトのテーブルの追加、削除、更新、および管理を行うこと ができます。 • 「Architect でのデータ ソースの表示」（123 ページ） • 「テーブルの追加」（124 ページ） • 「テーブルの削除」（126 ページ） • 「テーブルの更新、変更、および管理」（128 ページ） • 「プロジェクト内のテーブルの編成 : レイヤー」（135 ページ） Architect でのデータ ソースの表示 システム内のどのデータ ソースを Architect に表示するかを 定義できます。データ ソースが表示されると、そのデータ ソースからテーブルをプロジェクトに追加できます。 © 2010 MicroStrategy, Inc. テーブルの追加、削除、および管理 123 5 Architect によるプロジェクトの作成 プロジェクト デザイン ガイド 前提条件 • データ ソースのデータベース インスタンスが作成済みで あること。データベース インスタンスに関する情報と作 成例については、『導入と構成ガイド』を参照してくださ い。 • Architect を使用してプロジェクトを作成または変更して いること。手順は、「プロジェクトの作成と変更」（104 ページ）を参照してください。 Architect にデータ ソースを表示するには 1 Architect でプロジェクトを開いている状態で、[ オプ ション ] メニューから [ データベース インスタンスを選 択 ] を選択します。[ データベース インスタンスを選択 ] ダイアログ ボックスが開きます。 2 データ ソースのリストで、データ ソースの表示、非表示 を指定します。 • Architect に表示するデータ ソースのチェック ボック スを選択します。データ ソースが表示されると、そ のデータ ソースからテーブルをプロジェクトに追加 できます。 • Architect に表示しないデータ ソースのチェック ボッ クスをクリアします。プロジェクトで使用されている データ ソースを非表示にすることはできません。 3 [OK] をクリックして変更を保存し、Architect に戻りま す。 テーブルの追加 プロジェクトのアトリビュート、ファクト、および階層を作 成するには、その前にプロジェクトにテーブルを追加する必 要があります。 プロジェクトにテーブルを追加すると、プロジェクトでデー タが利用可能になるだけでなく、アトリビュートとファクト の作成、およびアトリビュートとファクトへの列のマッピン グが可能になります。プロジェクトにテーブルを追加すると 124 テーブルの追加、削除、および管理 © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド Architect によるプロジェクトの作成 5 きに、アトリビュートとファクトがどのように作成され、 マップされるかを定義する方法については、「ファクトとア トリビュートの作成の自動化」（106 ページ）および「既存 のアトリビュート フォームおよびファクトへの列の自動 マッピング」（108 ページ）を参照してください。 ソースからテーブルを選択してプロジェクト データ に追加すると、そのテーブルは MicroStrategy で論理 テーブルと呼ばれるスキーマ オブジェクトになりま す。論理テーブルは、データ ウェアハウス内の利用 可能なテーブルを表しています。論理テーブルについ ては、「論理テーブル」（415 ページ）で詳しく説明し ます。 Architect を使用してプロジェクトにテーブルを追加する手順 を次に示します。 前提条件 • Architect を使用してプロジェクトを作成または変更して いること。手順は、「プロジェクトの作成と変更」（104 ページ）を参照してください。 • Architect でテーブルを追加する機能が有効になっている こと。Architect を使用してテーブルを追加する機能の有 効化 / 無効化については、「テーブルの追加の無効化」 （112 ページ）を参照してください。 Architect を使用してプロジェクトにテーブルを追加するには 1 Architect でプロジェクトを開き、[ プロジェクト テーブ ル ビュー ] を選択します。 2 [ウェアハウス テーブル] ペインでデータ ソースを展開し ます。 複数ソース オプション機能のライセンスをお持ちの場合 は、複数のデータ ソースからテーブルをプロジェクトに 追加できます。ウェアハウス カタログまたは Architect を 使用して、複数のデータ ソースからテーブルをプロジェ クトに追加する方法については、「プロジェクト内の複数 のデータ ソースへのアクセス」（355 ページ）を参照して ください。 © 2010 MicroStrategy, Inc. テーブルの追加、削除、および管理 125 5 Architect によるプロジェクトの作成 プロジェクト デザイン ガイド 3 追加するテーブルを右クリックし、[ テーブルをプロジェ クトへ追加 ] を選択します。テーブルがプロジェクトに 追加され、Architect のプロジェクト テーブル ビューに表 示されます。 データを表示するには、 テーブル内のサンプル テーブルを右クリックして [ サンプル データを表 示 ] を選択します。 4 プロジェクトのテーブルのインポートが完了したら、次 のようなプロジェクト デザインの他のタスクを実行でき ます。 a 「ファクトの作成と変更」（136 ページ） b 「アトリビュートの作成と変更」（149 ページ） c 「アトリビュート関係の定義」（173 ページ） d 「ユーザ階層の作成と変更」（181 ページ） テーブルの削除 不要になったテーブルが残ってプロジェクトが無秩序になら ないように、そのようなテーブルはプロジェクトから削除で きます。プロジェクトからテーブルを削除するには、 Architect のプロジェクト テーブル ビューでテーブルを右ク リックし、[ 削除 ] を選択します。 ただし、プロジェクト内のスキーマ オブジェクトが依存し ているテーブルは、プロジェクトから削除できません。たと えば、ルックアップ テーブルとして設定されたテーブルを 持つアトリビュートは、そのテーブルに依存します。 依存関係にあるオブジェクトを持つテーブルを削除する際に は、そのテーブルに依存しているオブジェクトのリストを表 示できます。テーブルを削除する前に、それらの依存してい るオブジェクトを、すべてプロジェクトから削除する必要が あります。 126 テーブルの追加、削除、および管理 © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド Architect によるプロジェクトの作成 5 データ ソースから削除されたテーブルのプロジェ クトからの削除 プロジェクトに含まれるテーブルがデータ ソースから削除 され、利用不能になった場合は、Architect を使用して、その テーブルをプロジェクトから削除できます。これにより、選 択したデータ ソースからプロジェクトに追加されたテーブ ルのリストが、プロジェクトに正しく表示されます。 このタスクを Architect を使用して実行する手順を次に示し ます。これらのテーブルをウェアハウス カタログで削除す る方法については、「データ ソースから削除済みのテーブル のウェアハウス カタログからの削除」（336 ページ）を参照 してください。 プロジェクトに含まれていないテーブルがデータ ソースから削除されると、該当するテーブルは Architect の利用可能なテーブルの表示から自動的に削 除されます。 データ ソースから削除されたテーブルをプロジェクトから削除す るには 1 MicroStrategy Desktop でプロジェクトにログインします。 2 [ スキーマ ] メニューで [Architect] を選択します。 MicroStrategy Architect が開きます。 3 [ ウェアハウス テーブル ] ペインが表示されていない場合 は、[ 表示 ] メニューから [ ウェアハウス テーブルを表示 ] を選択します。 4 [ ウェアハウス テーブル ] ペインで、テーブルが削除され たデータ ソースのデータベース インスタンスを展開しま す。[ ウェアハウス カタログ ] ダイアログ ボックスが開き ます。このダイアログ ボックスが開かない場合、プロ ジェクトから削除すべきテーブルはありません。 5 プロジェクトから削除するテーブルのチェック ボックス を選択します。 6 削除するすべてのテーブルを選択した後、[OK] をクリッ クします。選択したテーブルが削除され、Architect に戻 ります。 © 2010 MicroStrategy, Inc. テーブルの追加、削除、および管理 127 5 Architect によるプロジェクトの作成 プロジェクト デザイン ガイド 7 依存関係にあるオブジェクトが存在するためテーブルを 削除できないことを通知するメッセージが返された場合 は、[Yes] をクリックして依存しているオブジェクトの リストを表示します。依存しているオブジェクトをすべ て削除すると、テーブルが削除可能になります。 8 [ ファイル ] メニューから [ スキーマを保存して更新 ] を選 択し、変更を保存します。 テーブルの更新、変更、および管理 Architect では、プロジェクト内のテーブルを更新および管理 して、プロジェクト内のデータを最新かつ正確な状態に保つ ことができます。次に示す各項で、その方法を説明します。 • 「テーブルの更新」（128 ページ） • 「テーブル定義の変更と表示」（129 ページ） • 「データ ウェアハウスの接続および操作のデフォルトの 変更」（134 ページ） テーブルの更新 Architect では、テーブルを個別に更新できるほか、データ ソースが共通のすべてのテーブルを一括して更新することも できます。これによりプロジェクト内のデータが、データ ソース内のテーブルに加えられたすべての変更を反映した最 新状態になります。Architect を使用してテーブルを更新する 手順を以下に示します。 前提条件 • Architect を使用してプロジェクトを作成または変更して いること。手順は、「プロジェクトの作成と変更」（104 ページ）を参照してください。 Architect を使用してテーブルを更新するには 1 Architect でプロジェクトを開き、[ プロジェクト テーブ ル ビュー ] を選択します。 128 テーブルの追加、削除、および管理 © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド Architect によるプロジェクトの作成 5 2 [ ウェアハウス テーブル ] ペインで、データ ソースが同じ すべてのテーブルを一括して更新するか、個々のテーブ ルを更新することができます。次に手順を示します。 • データ ソースが同じテーブルをすべて更新するには、 データ ソースを右クリックして [更新] を選択します。 そのデータ ソースの全テーブルが更新され、データ ソース内の定義が反映されます。 • 特定のテーブルを更新するには、データ ソースを展 開してテーブルを右クリックし、[ 構造を更新 ] を選択 します。テーブルが更新され、データ ソース内の定 義が反映されます。 テーブル定義の変更と表示 テーブルをプロジェクトに追加すると、Architect の [ プロパ ティ ] ペインを使用して、テーブル定義を変更および表示す ることができます。Architect でテーブルの各種プロパティと 内容を表示するには、[ プロパティ ] ペインの [ テーブル ] タ ブで、ドロップダウン リストから対象のテーブルを選択し ます。次に示す MicroStrategy Tutorial プロジェクトの © 2010 MicroStrategy, Inc. テーブルの追加、削除、および管理 129 5 Architect によるプロジェクトの作成 プロジェクト デザイン ガイド YR_CATEGORY_SLS テーブルを通じて、Architect でテーブ ル定義を変更および表示する方法を説明します。 Architect でテーブルを選択すると、[ プロパティ ] ペインで テーブル定義を変更および表示できます。その方法を以下に 説明します。 プロパティ ] ペインでプロパティを選択すれば、その [プロパティの説明を表示できます。説明は [ プロパ ティ ] ペインの最下部に表示されます。 • 「テーブル定義の変更と表示 : [ 定義 ] セクション」（131 ページ） • 「テーブル内のアトリビュートの変更 : [ マップ済アトリ ビュート ] セクション」（133 ページ） 130 テーブルの追加、削除、および管理 © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド Architect によるプロジェクトの作成 5 • 「テーブル内のファクトの変更 : [ マップ済ファクト ] セク ション」（133 ページ） • 「テーブル内の列の名前とデータ型の変更 : [ メンバー列 ] セクション」（133 ページ） テーブル定義の変更と表示 : [ 定義 ] セクション Architect でテーブルを選択すると、[ プロパティ ] ペインの [ 定義 ] セクションに、そのテーブルの各種プロパティが表示 されます。これらのプロパティと、その使用方法を次に示し ます。 • ID: テーブルの識別子。この値は変更できません。 • 名前 : MicroStrategy プロジェクト内のテーブルの名前。 デフォルトでは、データ ソース内の対応するテーブルか ら継承した名前になります。 • 説明 : テーブルの説明。説明は、プロジェクト内での テーブルの用途を知るために役立ちます。 • 非表示 : テーブルが非表示として定義されるかどうかを 指定します。テーブルを非表示として定義するには、ド ロップダウン リストから [ 真 ] を選択します。 非表示のオブジェクトは、ユーザが Desktop 基本設定を 変更して [隠しオブジェクトを表示] チェック ボックスを 選択しない限り表示されません。したがって、オブジェ クトを非表示として定義しても、ユーザによるオブジェ クトの表示やアクセスを確実に防止できるわけではあり ません。ユーザによるオブジェクトの表示やアクセスを 防ぐ最善の方法は、そのオブジェクトに対するユーザ権 限を制限することです。 © 2010 MicroStrategy, Inc. • 位置 : プロジェクト内でのテーブルの位置。 • データベース名 : データ ソース内でのテーブルの名前。 データ ソース内でテーブル名が変更された場合は、この プロパティにテーブルの新しい名前を入力できます。こ れにより、データ ソース内で名前が変更されたテーブル を、MicroStrategy プロジェクトで確実に特定できます。 テーブルの追加、削除、および管理 131 5 Architect によるプロジェクトの作成 • プロジェクト デザイン ガイド 行数 : テーブル内の行の数。テーブルの行数を計算する には、テーブルを右クリックして [ 行数を計算 ] を選択し ます。 行数を計算 ] オプションが表示されるのは、テー [ブルのデータ ソースが [ ウェアハウス テーブル ] ペインで展開されている場合だけです。 • テーブル名スペース : データ ソース内のテーブルのテー ブル名スペース。テーブル名スペースについては、「テー ブル移行時のテーブル ネーム スペースの無視」（346 ページ）を参照してください。 • 論理サイズ : テーブルの論理サイズ。この値は、テーブ ル内のアトリビュート列の数と、それぞれの階層内でア トリビュート列が存在するレベルを考慮したアルゴリズ ムに基づきます。論理サイズを手動で入力し、テーブル の論理サイズを変更することもできます。論理テーブル のサイズは、MicroStrategy SQL Engine がクエリで使用す るテーブルを決定する方法に大きく影響します。 • ロックした論理サイズ : テーブルの論理サイズが変更可 能かどうかを指定します。テーブルの論理サイズをロッ クするには、ドロップダウン リストから [ 真 ] を選択しま す。 • 第一データベース インスタンス : テーブルの第一データ ベース インスタンス。 プロジェクト内のテーブルを複数のデータ ソース内の テーブルにマップできる場合は、[ 第一データベース インスタンス ] を選択して [...]（ブラウズ）ボタンをク リックすると、[ 使用可能なデータベース インスタンス ] ダイアログ ボックスが表示されます。このダイアログ ボックスでテーブルのデータ ソースを確認できます。 テーブルの第一データベース インスタンスとして使用さ れているデータベース インスタンス（および関連付けら れているデータ ソース）を変更することもできます。 ウェアハウス カタログまたは Architect を使用して、複数 のデータ ソースからテーブルをプロジェクトに追加する 「プロジェクト内の複数のデータ ソー 方法については、 スへのアクセス」（355 ページ）を参照してください。 132 テーブルの追加、削除、および管理 © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド Architect によるプロジェクトの作成 5 テーブル内のアトリビュートの変更 : [ マップ済アトリ ビュート ] セクション Architect でテーブルを選択すると、[ プロパティ ] ペインの [ マップ済アトリビュート ] セクションに、そのテーブル内の 列にマップされているアトリビュートが表示されます。[ プ ロパティ ] ペインでアトリビュート フォームにマップされて いる列を選択し、[...] ボタンをクリックすると、[ フォーム 式を変更 ] ダイアログ ボックスが表示されます。このダイア ログ ボックスで、アトリビュート フォーム式を変更できま す。 Architect でアトリビュート フォームを作成および変更する 方法については、「アトリビュートの作成と変更」（149 ペー ジ）を参照してください。アトリビュート フォームに関す る情報と、アトリビュート エディタでアトリビュート フォームを作成および変更する方法については、「列データ の説明と識別子 : アトリビュート フォーム」（248 ページ） を参照してください。 テーブル内のファクトの変更 : [ マップ済ファクト ] セク ション Architect でテーブルを選択すると、[ プロパティ ] ペインの [ マップ済ファクト ] セクションに、そのテーブル内の列に マップされているファクトが表示されます。[ プロパティ ] ペ インでファクトにマップされている列を選択し、[...] ボタン をクリックすると、[ ファクト式の変更 ] ダイアログ ボック スが表示されます。このダイアログ ボックスで、ファクト 式を変更できます。 Architect でファクトを作成および変更する方法については、 「ファクトの作成と変更」（136 ページ）を参照してくださ い。ファクトに関する情報と、ファクト エディタでファク トを作成および変更する方法については、6 章、「ビジネス データの構築ブロック : ファクト」を参照してください。 テーブル内の列の名前とデータ型の変更 : [ メンバー列 ] セクション Architect でテーブルを選択すると、[ プロパティ ] ペインの [ メンバー列 ] セクションに、そのテーブル内で利用可能な列 が表示されます。[ プロパティ ] ペインで列を選択して [...] ボ © 2010 MicroStrategy, Inc. テーブルの追加、削除、および管理 133 5 Architect によるプロジェクトの作成 プロジェクト デザイン ガイド タンをクリックすると、[ 列エディタ ] ダイアログ ボックス が表示されます。このダイアログ ボックスで、列の名前と データ型を変更できます。 列の名前とデータ型を変更できるのは、データ ソース内の 対応する情報が変更された場合だけです。これにより MicroStrategy プロジェクトは、データ ソース内で名前が変 更された列も確実に特定できます。 データ ウェアハウスの接続および操作のデフォル トの変更 Architect では、データ ウェアハウスの接続および操作のさ まざまなデフォルト設定を指定できます。これらの設定は、 「データ ウェアハウス接続と動作のデフォルトの変更」（339 ページ）で説明されているウェアハウス カタログ オプ ションの一部です。 Architect からウェアハウス カタログ オプションのサブセッ トにアクセスする手順を、以下に示します。 前提条件 • Architect を使用してプロジェクトを作成または変更して いること。手順は、「プロジェクトの作成と変更」（104 ページ）を参照してください。 データ ウェアハウスの接続および操作のデフォルトを変更するに は 1 Architect でプロジェクトを開き、[ プロジェクト テーブ ル ビュー ] を選択します。 2 [ ウェアハウス テーブル ] ペインでデータ ソースを右ク リックし、[ ウェアハウス カタログ オプション] を選択し ます。[ ウェアハウス カタログ オプション ] ダイアログ ボックスが開きます。 3 Architect からアクセスしている場合は、次の項目を含む ウェアハウス カタログ設定のサブセットだけが表示され ます。 134 テーブルの追加、削除、および管理 © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド Architect によるプロジェクトの作成 5 • ウェアハウス接続 : データ ウェアハウスをプロジェク トに接続するために使用されるデータベース インス タンスとデータベース ログインを変更できます。こ れらのオプションの詳細は、「データ ウェアハウス接 続と読み取り動作」（339 ページ）を参照してくださ い。 • 読み取り設定 : Microsoft Access 以外の各プラット フォームのウェアハウス カタログを読み取る SQL を カスタマイズできます。これらのオプションの詳細 は、「データ ウェアハウス接続と読み取り動作」（339 ページ）を参照してください。 • テーブル接頭語 : テーブルの接頭語をテーブル名の表 示に含めるかどうか、およびプロジェクトに追加した テーブルの接頭語がどのようにして自動定義されるか を指定できます。これらのオプションの詳細は、 「テーブル接頭語、行数、およびネーム スペースの表 示」（344 ページ）を参照してください。 4 ウェアハウス カタログ オプションの設定が完了したら、 [OK] をクリックして変更を保存し、Architect に戻りま す。 プロジェクト内のテーブルの編成 : レイヤー Architect では、テーブルをグループ化してアクセスを容易化 し、焦点を絞りやすくすることで、プロジェクトの編成と分 かりやすさを高めることができます。テーブルのグループは レイヤー と呼ばれ、多数のテーブルが必要な MicroStrategy プロジェクトの編成に役立ちます。 Architect のプロジェクト テーブル ビューで 1 つ以上のテー ブルを選択し、レイヤーとしてテーブルのグループを定義で きます。このレイヤーには [ レイヤー ] ドロップダウン リス トからアクセスし、レイヤーに含まれているテーブルだけに 焦点を絞ることができます。レイヤーの表示中に加えた変更 は、すべてプロジェクト全体に適用されます。 たとえば、プロジェクト内のすべてのファクト テーブルを 選択し、「ファクト テーブル」という名前の新しいレイヤー を作成することができます。これにより、プロジェクトに含 まれるファクト テーブルだけに容易に焦点を絞ることがで きます。 © 2010 MicroStrategy, Inc. テーブルの追加、削除、および管理 135 5 Architect によるプロジェクトの作成 プロジェクト デザイン ガイド [ すべてのプロジェクト テーブル ] レイヤーがデフォルトの レイヤーで、プロジェクト内のすべてのテーブルを含んでい ます。このレイヤーは削除できません。 Architect でレイヤーを作成する手順を次に示します。 Architect でレイヤーを作成するには 1 MicroStrategy Desktop でプロジェクトにログインします。 2 [ スキーマ ] メニューで [Architect] を選択します。 MicroStrategy Architect が開きます。 3 [ プロジェクト テーブル ビュー] で、レイヤーに含めるす べてのテーブルを選択します。 レイヤーからテーブルを削除するには、そのテー ブルを右クリックして [ レイヤーから削除 ] を選択 します。 4 ツールバーの [ 新規レイヤーを作成 ] オプション（ ）を クリックします。レイヤーに名前を付けるダイアログ ボックスが表示されます。 5 [ レイヤー名を入力してください ] フィールドにレイヤー 名を入力し、[OK] をクリックします。Architect に戻り、 プロジェクト テーブル ビューに新しいレイヤーが表示さ れます。 6 レイヤー間を切り替えるには、[ レイヤー ] ドロップダ ウン リストを使用します。 ファクトの作成と変更 ファクトは、ビジネス データ モデルに不可欠な要素の 1 つ です。データ ウェアハウスから得られた数値データは、 ファクトによって MicroStrategy のレポーティング環境に関 連付けられます。ファクトは通常、ユーザがレポートに含め るビジネス上の質問への答えを表します。ファクトの概念に ついては、6 章、「ビジネス データの構築ブロック : ファク ト」を参照してください。 136 ファクトの作成と変更 © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド Architect によるプロジェクトの作成 5 ここでは、Architect を使用してファクトを作成および変更す る方法を、次の 2 つの項を通じて説明します。 • 「ファクトの作成」（137 ページ） • 「複数のファクトの作成と変更」（140 ページ） プロジェクトのファクトを作成する前に、ファクトが 作成されるときに自動作成されるメトリックの種類を 選択できます。これにより、プロジェクトの基本的な メトリックの作成に要する時間を短縮できます。基本 的なメトリックを自動作成するように Architect を構 成する方法については、「プロジェクトのファクトに 基づくメトリックの作成」（113 ページ）を参照して ください。 ファクトの作成 Architect ではファクトを、最初のプロジェクト デザインの 一部として作成できるほか、プロジェクトのライフ サイク ルを通じて随時、作成することもできます。 プロジェクトに必要なすべてのファクトの作成に要する時間 を短縮するため、テーブルをプロジェクトに追加したときに Architect にファクトを自動作成させることができます。 Architect を使用してプロジェクトにテーブルを追加すると、 テーブル内で数値データ型を使用し、アトリビュート フォームに使用されていない列にファクトが作成されます。 ファクトの自動作成を有効にする方法については、「ファク トとアトリビュートの作成の自動化」（106 ページ）を参照 してください。 Architect でファクトを作成する手順を次に示します。 前提条件 プロジェクト オブジェクトをすでに作成し、プロジェクト にテーブルを追加していること。Architect でプロジェクトを 作成する方法については、「Architect によるプロジェクトの 作成」（116 ページ）を参照してください。 © 2010 MicroStrategy, Inc. ファクトの作成と変更 137 5 Architect によるプロジェクトの作成 プロジェクト デザイン ガイド Architect でファクトを作成するには 1 MicroStrategy Desktop でプロジェクトにログインします。 2 [ スキーマ ] メニューで [Architect] を選択します。 MicroStrategy Architect が開きます。 3 [ プロジェクト テーブル ビュー] で、ファクト定義に使用 する 1 つ以上の列を含むテーブルを見つけ、それを選択 します。 4 テーブルを右クリックして [ ファクトを作成 ] を選択しま す。ファクトに名前を付けるダイアログ ボックスが開き ます。 ファクト式を手動で作成してファクトを作成する代わり に、1 つの列で定義される単純なファクトを Architect で 自動的に作成することもできます。そのためには、テー ブルを右クリックして [ 認識 ] をポイントし、[ ファクト ] を選択します。数値データ型を使用し、アトリビュート フォームに使用されていない列を対象に、ファクトが作 成されます。このオプションを使用して単純なファクト を作成する場合は、以下の手順をスキップして「ファク ト式と列別名を定義するには」（140 ページ）に進んでく ださい。 5 ファクトの名前を入力して [OK] をクリックします。 ファクト式を作成する [ 新規フォーム式を作成 ] ダイアロ グ ボックスが開きます。 6 [ 利用可能な列 ] ペインから列をドラッグし、[ フォーム 式 ] ペインにドロップします。 複数の列を含めることが可能で、数値定数、数学演算子、 および関数を使用してファクト式を作成できます。さま ざまな種類のファクト式の作成方法については、「物理列 のファクトへのマッピング : ファクト式」（199 ページ） を参照してください。 7 [ マッピング ] 領域で [ 自動 ] または [ 手動 ] を選択します。 138 ファクトの作成と変更 © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド Architect によるプロジェクトの作成 5 • 自動マッピングでは、ファクト式で列が使用されてい るプロジェクト内の全テーブルが、ファクトの利用可 能なソース テーブルとして選択されます。その後、 自動マッピングされたすべてのテーブルを削除し、他 のテーブルを選択することもできます。 • 手動マッピングでも、ファクト式で列が使用されてい るプロジェクト内の全テーブルが見つけられますが、 ファクトの利用可能なソース テーブルとして自動選 択されることはありません。その後、ファクトのソー ス テーブルとして使用するテーブルを手動で選択し ます。手動マッピングは、次のような状況で使用しま す。 – プロジェクト テーブル内の物理列に基づかない定 数式を作成している場合。定数式を適用するテー ブルを手動で選択する必要があります。 – 複数のテーブルに存在する同じ名前の列に含まれ るデータが共通でない場合。ファクトごとに適切 なソース テーブルを手動で選択する必要がありま す。 たとえば、Sales という名前の列が Fact_Sales テーブルと Fact_Discount テーブルの両方に存 在するとします。Fact_Sales テーブル内の Sales 列には売上データが格納されています。一 方、Fact_Discount テーブル内の Sales 列には ディスカウント売上データが格納されています。 言い換えれば、どちらのテーブルでも列の名前は 同じ（Sales）ですが、これらの列にはテーブル ごとに異なるファクト データが格納されていま す。"Revenue"（売上）ファクトを作成するときに は、"Revenue" ファクトのソース テーブルとして Fact_Sales テーブルを選択するために手動マッ ピングを使用する必要があります。"Discount" （ディスカウント売上）ファクトを作成するときに も、"Discount" ファクトのソース テーブルとして Fact_Discount を選択できるように、手動マッ ピングを使用しなければなりません。どちらの場 合も自動マッピングを使用すると、MicroStrategy SQL Engine が正しくない列をファクトに使用する 可能性があります。 © 2010 MicroStrategy, Inc. ファクトの作成と変更 139 5 Architect によるプロジェクトの作成 プロジェクト デザイン ガイド 8 [OK ] をクリックして [ 新規フォーム式を作成 ] ダイアロ グ ボックスを閉じ、ファクトを作成します。ファクトの 作成に使用されたテーブル内に、作成したファクトが表 示されます。 ファクト式と列別名を定義するには 9 ファクトの定義を続行するには、ファクトを右クリック して [ 編集 ] を選択します。ファクト エディタが開きま す。次に説明するように、ファクト エディタのタブを使 用してファクト式を定義し、列別名を作成します。 • 定義 : このタブでファクト式を定義します。ファクト の定義については、「ファクトの定義」（198 ページ） で説明します。 • 列別名 : このタブでファクトの列別名を作成します。 列別名については、「ファクト列の名前とデータ タイ プ : 列別名」（206 ページ）で説明します。 以下の点に注意してください。 – ファクト エディタの各タブにあるオプションの詳 細については、MicroStrategy Desktop オンライン ヘルプを参照してください。 – Architect ではファクト レベル拡張は作成できま せん。ファクト レベル拡張の作成方法について 「ファクトがレポートされるレベルの変更 : レ は、 ベル拡張」（208 ページ）を参照してください。 10 変更が完了したら [OK] をクリックし、Architect に戻り ます。 11 [ ファイル ] メニューから [ 保存 ] を選択し、変更を保存し ます。 複数のファクトの作成と変更 Architect では、プロジェクト内の複数のファクトを、統合 インタフェースから迅速に作成および変更できます。 Architect でファクトを作成、変更する方法は、ファクト エ ディタとほぼ同じです。 ではファクト レベル拡張は作成できません。 Architect ファクト レベル拡張の作成方法については、「ファク 140 ファクトの作成と変更 © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド Architect によるプロジェクトの作成 5 トがレポートされるレベルの変更 : レベル拡張」 （208 ページ）を参照してください。 ファクトの概念および詳しい例は、6 章、「ビジネス データ の構築ブロック : ファクト」を参照してください。次に示す 各トピックを通じて、Architect でさまざまなファクト定義を 行う手順を示します。 • 「[ プロパティ ] ペインでのファクトの変更」 （141 ページ） • 「ファクト式の作成」（144 ページ） • 「ファクトの列名とデータ型の作成および変更 : 列別名」 （148 ページ） [ プロパティ ] ペインでのファクトの変更 ファクトを作成すると、Architect の [ プロパティ ] ペインを 使用してファクト定義を変更および表示できます。Architect でファクトの各種プロパティを表示するには、[ プロパティ ] ペインの [ ファクト ] タブで、ドロップダウン リストから ファクトを選択します。次に示す MicroStrategy Tutorial プロ © 2010 MicroStrategy, Inc. ファクトの作成と変更 141 5 Architect によるプロジェクトの作成 プロジェクト デザイン ガイド ジェクトの "Cost"（経費）ファクトを通じて、Architect で ファクトを変更および表示する方法を説明します。 Architect でファクトを選択すると、[ プロパティ ] ペインで ファクトを変更および表示できます。その方法を以下に説明 します。 プロパティ ] ペインでプロパティを選択すれば、その [プロパティの説明を表示できます。説明は [ プロパ ティ ] ペインの最下部に表示されます。 • 「アトリビュート定義の変更と表示 : [ 定義 ] セクション」 （155 ページ） • 「アトリビュート フォームの変更 : [ フォーム ] セク ション」（157 ページ） ファクト定義の変更と表示 : [ 定義 ] セクション Architect でファクトを選択すると、[ プロパティ ] ペインの [ 定義 ] セクションに、そのファクトの各種プロパティが表示 142 ファクトの作成と変更 © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド Architect によるプロジェクトの作成 5 されます。これらのプロパティと、その使用方法を次に示し ます。 • ID: ファクトの識別子。この値は変更できません。 • 名前 : MicroStrategy プロジェクト内のファクトの名前。 • 説明 : ファクトの説明。説明は、プロジェクト内での ファクトの用途を知るために役立ちます。 • 非表示 : ファクトが非表示として定義されるかどうかを 指定します。ファクトを非表示として定義するには、ド ロップダウン リストから [ 真 ] を選択します。 非表示のオブジェクトは、ユーザが Desktop 基本設定を 変更して [隠しオブジェクトを表示] チェック ボックスを 選択しない限り表示されません。したがって、オブジェ クトを非表示として定義しても、ユーザによるオブジェ クトの表示やアクセスを確実に防止できるわけではあり ません。ユーザによるオブジェクトの表示やアクセスを 防ぐ最善の方法は、そのオブジェクトに対するユーザ権 限を制限することです。 • 位置 : プロジェクト内でのファクトの位置。 ファクト式の変更 : [ ファクト式 ] セクション Architect でファクトを選択すると、[ プロパティ ] ペインの [ ファクト式 ] セクションに、そのファクトを含む各テーブル と、それらのテーブル内でファクトに使用されるファクト式 が表示されます。 「[ プロパティ ] ペインでのファクトの変更」 （141 ページ）に 示した "Cost" ファクトの例では、ほとんどのテーブルの ファクト式として TOT_COST が表示されています。ただし、 ORDER_DETAIL テーブルでは、"Cost" ファクトは派生ファ クト式を使用します（派生ファクト式については、「派生 ファクトとファクト式の作成」（144 ページ）を参照）。ま た、ORDER_FACT テーブルでは、"Cost" ファクトは異なる 列名を使用します（異種の列名については、「名前の異なる 列を使用したファクトの作成 : 異種の列名」（146 ページ） を参照）。 [ プロパティ] ペインでファクトにマップされている列を選択 し、[...]（ブラウズ）ボタンをクリックすると、[ ファクト式 の変更 ] ダイアログ ボックスが表示されます。このダイアロ グ ボックスで、ファクト式を変更できます。 © 2010 MicroStrategy, Inc. ファクトの作成と変更 143 5 Architect によるプロジェクトの作成 プロジェクト デザイン ガイド ファクト式の作成 ファクト式は、データ ソース内の特定のファクト情報への マッピングを表します。ファクト式の概念については、「物 理列のファクトへのマッピング : ファクト式」（199 ページ） を参照してください。 「ファクトの作成」（137 ページ）で説明したように、ファク ト式は通常、列をファクトにマップすることによって作成さ れます。Architect では、次に示すようにファクトを作成し、 定義することもできます。 • 「派生ファクトとファクト式の作成」（144 ページ） • 「名前の異なる列を使用したファクトの作成 : 異種の列 名」（146 ページ） 派生ファクトとファクト式の作成 派生ファクトとは、テーブル内の 1 つの列より多くの要素を 含む式によって値が決定されるファクトのことです。定数の 追加、他の列の値の追加、式の絶対値設定など、列に対する あらゆる操作が派生ファクトを生成します。言い換えれば、 データ ウェアハウス内で利用可能な情報からファクトを作 成することです。 派生ファクトと派生ファクト式の詳細は、「派生ファクトと 派生ファクト式」（200 ページ）を参照してください。 Architect を使用して派生ファクトを作成する手順を次に示し ます。この手順は、「例 : 派生ファクトの作成」（201 ペー ジ）のシナリオ例に基づいています。 Architect で派生ファクトを作成するには 1 MicroStrategy Desktop でプロジェクトにログインします。 シナリオの例に従い、MicroStrategy Tutorial プロジェクト にログインします。 2 [ スキーマ ] メニューで [Architect] を選択します。 MicroStrategy Architect が開きます。 144 ファクトの作成と変更 © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド Architect によるプロジェクトの作成 5 3 [ プロジェクト テーブル ビュー] で、ファクト定義に使用 する 1 つ以上の列を含むテーブルを見つけ、それを選択 します。 シナリオの例に従い、ORDER_DETAIL テーブルを選択 します。 4 テーブルを右クリックして [ ファクトを作成 ] を選択しま す。ファクトに名前を付けるダイアログ ボックスが開き ます。 5 ファクトの名前を入力して [OK] をクリックします。[ 新 規フォーム式を作成 ] ダイアログ ボックスが開きます。 6 [ 利用可能な列 ] ペインから列をドラッグし、[ フォーム 式 ] ペインにドロップします。 シナリオの例に従い、QTY_SOLD 列をドラッグ アンド ドロップして [ フォーム式 ] ペインに追加します。 派生ファクト式を完成させるには 派生ファクト式には、列、数値定数、および数学演算子 の組み合わせが含まれます。以下のステップではシナリ オの例に従って、派生ファクト式の作成方法のガイドラ インを示します。 7 カーソルを [ フォーム式 ] ペイン内に置いた状態で、[*] （乗算演算子）をクリックして、その演算子を式に追加し ます。 8 [ 使用可能な列 ] ペインで UNIT_PRICE 列をダブルクリッ クし、ファクト式の末尾に追加します。 9 [ マップ方法 ] で [ 自動 ] を選択します。 10 [ 検証 ] をクリックし、式の構文が正しいかどうかを チェックします。式は次のように表示されるはずです。 © 2010 MicroStrategy, Inc. ファクトの作成と変更 145 5 Architect によるプロジェクトの作成 プロジェクト デザイン ガイド 11 [OK] をクリックします。Architect に戻り、派生ファクト が ORDER_DETAIL テーブル内に表示されます。 12 [ ファイル ] メニューから [ 保存 ] を選択し、変更を保存し ます。 名前の異なる列を使用したファクトの作成 : 異種の列名 ウェアハウス内では、1 つのファクトが名前の異なる複数の 列にアクセスする場合があります。MicroStrategy では、ファ クトごとに異種のファクト列名を識別することができます。 異種の列名により、複数のテーブルに存在し、名前が異な り、量的に同じ値を含む複数の列を 1 つのファクトから参照 できます。 異種の列名の詳細は、「名前の異なる列を使用するファク ト : 異種の列名」（203 ページ）を参照してください。 Architect を使用して、異種の列名を持つファクトを作成する 手順を次に示します。この手順は、「例 : 異種のファクト列 のマッピング」（204 ページ）のシナリオ例に基づいていま す。 Architect を使用して異種の列名を持つファクトを作成するには 1 MicroStrategy Desktop でプロジェクトにログインします。 シナリオの例に従い、MicroStrategy Tutorial プロジェクト にログインします。 2 [ スキーマ ] メニューで [Architect] を選択します。 MicroStrategy Architect が開きます。 3 [ プロジェクト テーブル ビュー] で、ファクト定義に使用 する 1 つ以上の列を含むテーブルを見つけ、それを選択 します。 シナリオの例に従い、ORDER_FACT テーブルを選択し ます。これは、"Units Sold"（売上数量）ファクトの異種 のファクト列を含むテーブルの 1 つです。 4 テーブルを右クリックして [ ファクトを作成 ] を選択しま す。ファクトに名前を付けるダイアログ ボックスが開き ます。 146 ファクトの作成と変更 © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド Architect によるプロジェクトの作成 5 5 ファクトの名前を入力して [OK] をクリックします。[ 新 規フォーム式を作成 ] ダイアログ ボックスが開きます。 6 [ 利用可能な列 ] ペインから列をドラッグし、[ フォーム 式 ] ペインにドロップします。 シナリオの例に従い、QTY_SOLD 列をドラッグ アンド ドロップして [ フォーム式 ] ペインに追加します。 7 [ マップ方法 ] 領域で [ 自動 ] を選択します。 8 [OK] をクリックします。Architect に戻り、派生ファクト が ORDER_FACT テーブル内に表示されます。 9 新しいファクトを右クリックし、[ 編集 ] を選択します。 ファクト エディタが開き、作成したファクト式が [ 式 ] ペ インに表示されます。 ファクトに異種の列を追加するには 続いて、異種のファクト列をファクトの別の式として追 加する必要があります。 10 [ 新規作成 ] をクリックします。[ 新規ファクト式の作成 ] ダイアログ ボックスが開きます。 11 [ ソース テーブル ] ドロップダウン リストから CITY_CTR_SALES テーブルを選択します。これも、 "Units Sold" ファクトの異種のファクト列を含むテーブル の 1 つです。 12 [ 使用可能な列 ] ペインで TOT_UNIT_SALES 列をダブル クリックし、右側の [ ファクト式 ] ペインに追加します。 13 [ マップ方法 ] 領域で [ 自動 ] を選択します。 14 [OK] をクリックします。ファクト エディタに戻り、作 成したファクト式が [ 式 ] ペインに表示されます。これ で、作成しているファクトが異種のファクト列に正しく マップされます。 15 [OK] をクリックします。Architect に戻ります。 16 [ ファイル ] メニューから [ 保存 ] を選択し、変更を保存し ます。 © 2010 MicroStrategy, Inc. ファクトの作成と変更 147 5 Architect によるプロジェクトの作成 プロジェクト デザイン ガイド ファクトの列名とデータ型の作成および変更 : 列別 名 列別名は、一時テーブル内で使用される列の名前と、ファク トに使用されるデータ型の両方を指定します。デフォルトで は、ファクトのデータ型は、データ ウェアハウス内でその ファクトが定義されている列のデータ型を継承します。 列別名については、「ファクト列の名前とデータ タイプ : 列 別名」（206 ページ）を参照してください。Architect で列別 名を作成する手順を次に示します。 前提条件 この手順は、すでにファクトを有効なファクト式で作成して いることが前提です。 Architect でファクトの列別名を作成するには 1 MicroStrategy Desktop で、新しい列別名を作成するファ クトを含むプロジェクト ソースにログインします。 2 [ スキーマ ] メニューで [Architect] を選択します。 MicroStrategy Architect が開きます。 3 [ プロジェクト テーブル ビュー] でファクトを含むテーブ ルを見つけ、それを選択します。 4 ファクトを右クリックし、[ 編集 ] を選択します。ファク ト エディタが開きます。 5 [ 列別名 ] タブを選択します。 6 [ 列別名 ] 領域で [ 選択 ] をクリックします。[ 列エディタ 列を選択 ] ダイアログ ボックスが開きます。 7 [ 新規作成 ] を選択して新しい列別名を作成します。[ 列エ ディタ - 定義 ] ダイアログ ボックスが開きます。 8 列別名の次のプロパティを変更できます。 • 148 ファクトの作成と変更 列名 : 列別名の名前。この名前は、選択したファクト の列を含むすべての SQL ステートメントで使用され ます。 © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド Architect によるプロジェクトの作成 5 • データ タイプ : ファクトのデータ型。MicroStrategy で サポートされているデータ型については、「データ タ イプ」（441 ページ）を参照してください。 • 選択するデータ型によっては、列別名のバイト長、 ビット長、精度、スケール、またはタイム スケール を指定できます。これらの各プロパティの詳細につい ては、MicroStrategy Desktop オンライン ヘルプを参照 してください。 9 [OK] をクリックして変更を保存し、[ 列エディタ - 列を 選択 ] ダイアログ ボックスに戻ります。 10 [OK] をクリックします。ファクト エディタに戻ります。 11 [OK] をクリックします。Architect に戻ります。 12 [ ファイル ] メニューから [ 保存 ] を選択し、変更を保存し ます。 アトリビュートの作成と変更 ファクトで表されるビジネス データは、ビジネスの概念と コンテキストがなければ、さほど意義深いものにはなりま せん。MicroStrategy でビジネスの概念とコンテキストを表す のがアトリビュートです。アトリビュートはビジネス モデ ルに、ファクトをレポートおよび分析するためのコンテキス トを提供します。会社の総売上を知ることが有益である一方 で、その売上がいつどこで発生したものかがわかれば、ユー ザは必要な詳細分析を日々行うことができます。アトリ ビュートの概念については、7 章、「ビジネス データのコン テキスト : アトリビュート」を参照してください。 ここでは、Architect を使用してアトリビュートを作成および 変更する方法を、次の 2 つの項を通じて説明します。 • 「アトリビュートの作成」（150 ページ） • 「複数のアトリビュートの作成と変更」（153 ページ） これらの項では、アトリビュートとアトリビュート フォー ムの作成に焦点を当てています。Architect の階層表示でアト リビュート関係を作成し、定義する方法については、「アト リビュート関係の定義」（173 ページ）を参照してください。 © 2010 MicroStrategy, Inc. アトリビュートの作成と変更 149 5 Architect によるプロジェクトの作成 プロジェクト デザイン ガイド アトリビュートの作成 Architect ではアトリビュートを、最初のプロジェクト デザ インの一部として作成できるほか、プロジェクトのライフ サイクルを通じて随時、作成することもできます。 プロジェクトに必要なすべてのアトリビュートの作成に要す る時間を短縮するため、テーブルをプロジェクトに追加した ときに Architect にアトリビュートを自動作成させることが できます。Architect を使用してプロジェクトにテーブルを追 加すると、Architect で定義した自動列認識の規則に基づいて アトリビュートが作成されます。アトリビュートの自動作成 を有効化し、定義する方法については、「ファクトとアトリ ビュートの作成の自動化」（106 ページ）を参照してくださ い。 Architect でアトリビュートを作成する手順を次に示します。 前提条件 プロジェクト オブジェクトをすでに作成し、プロジェクト にテーブルを追加していること。Architect でプロジェクトを 作成する方法については、「Architect によるプロジェクトの 作成」（116 ページ）を参照してください。 Architect でアトリビュートを作成するには 1 MicroStrategy Desktop でプロジェクトにログインします。 2 [ スキーマ ] メニューで [Architect] を選択します。 MicroStrategy Architect が開きます。 3 [ プロジェクト テーブル ビュー] で、アトリビュート定義 に使用する 1 つ以上の列を含むテーブルを見つけ、それ を選択します。 4 テーブルを右クリックして [ アトリビュートを作成 ] を選 択します。アトリビュートに名前を付けるダイアログ ボックスが開きます。 アトリビュート式を手動で作成してアトリビュートを作 成する代わりに、1 つの列で定義される単純なアトリ ビュートを Architect で自動的に作成することもできま す。そのためには、テーブルを右クリックして [ 認識 ] を 150 アトリビュートの作成と変更 © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド Architect によるプロジェクトの作成 5 ポイントし、[ アトリビュート ] を選択します。Architect で定義した自動列認識の規則に基づいてアトリビュート が作成されます（「ファクトとアトリビュートの作成の自 動化」（106 ページ）を参照）。このオプションを使用し て単純なアトリビュートを作成する場合は、以下の手順 をスキップして「アトリビュートのルックアップ テーブ ル、フォーム式、および列別名を定義するには」（152 ページ）に進んでください。 5 アトリビュートの名前を入力して [OK] をクリックしま す。[ 新規フォーム式を作成 ] ダイアログ ボックスが開き ます。 6 作成しているアトリビュートの IF フォーム用のフォーム 式を、次に説明する方法で作成します。 • 単純なアトリビュート フォーム式（「アトリビュート フォーム式」（253 ページ））を作成するには、[ 利用 可能な列 ] ペインから列をドラッグし、[ フォーム式 ] ペインにドロップします。 • より高度なアトリビュート フォーム式を作成する場 合は、次の手法を適切に組み合わせます。 – 定数を二重引用符で囲んで入力します。 – 関数を挿入ウィザードを使用して関数を作成する には、フォーム式ツールバーの [f(x)] をクリック します。 – 式に演算子を挿入するには、フォーム式ツール バーにある必要な演算子をクリックします。 7 式が有効であることを確認するために、[ 検証 ] をクリッ クします。 8 [ マップ方法 ] で [ 自動 ] または [ 手動 ] を選択します。 © 2010 MicroStrategy, Inc. • 自動マッピングでは、アトリビュート フォーム式で 列が使用されているプロジェクト内の全テーブルが、 アトリビュート フォームの利用可能なソース テーブ ルとして選択されます。その後、自動マッピングされ たすべてのテーブルを消去し、他のテーブルを選択す ることもできます。 • 手動マッピングでも、アトリビュート フォーム式で 列が使用されているプロジェクト内の全テーブルが見 つけられますが、アトリビュート フォームの利用可 アトリビュートの作成と変更 151 5 Architect によるプロジェクトの作成 プロジェクト デザイン ガイド 能なソース テーブルとして自動選択されることはあ りません。その後、アトリビュート フォームのソー ス テーブルとして使用するテーブルを手動で選択し ます。 以下の点に注意してください。 – 最初に作成するアトリビュートやアトリビュート フォーム式には、デフォルトでは自動マッピング が使用されます。式がシステムによって、各ソー ス テーブルにマップされます。2 番目以降のアト リビュートでは、手動マッピングがデフォルトに なります。 – 定数値だけを使用する式には、自動マッピングは 使用できません。 9 [OK ] をクリックして [ 新規フォーム式を作成 ] ダイアロ グ ボックスを閉じ、アトリビュートを作成します。アト リビュートの作成に使用されたテーブル内に、作成した アトリビュートが表示されます。 アトリビュートのルックアップ テーブル、フォーム式、およ び列別名を定義するには 10 アトリビュートの定義を続行するには、アトリビュート の ID フォームを右クリックして [ 編集 ] を選択します。 [アトリビュート フォームを変更] ダイアログ ボックスが 開きます。 11 [ ソース テーブル ] ペインでテーブルを選択して [ ルック アップとして設定 ] をクリックし、そのテーブルをアト リビュートのルックアップ テーブルに設定します。ルッ クアップ テーブルは、1 つのアトリビュートの情報を保 持する主要テーブルとして機能します。手動マッピング を選択した場合は、アトリビュート フォームにマップす るテーブルのチェック ボックスを選択します。 12 次に説明するように、[ アトリビュート フォームを変更 ] ダイアログ ボックスのタブを使用して、アトリビュート フォーム式を定義し、列別名を作成します。 • 152 アトリビュートの作成と変更 定義 : このタブでアトリビュート フォーム式を定義し ます。アトリビュート フォームについては、「列デー タの説明と識別子 : アトリビュート フォーム」（248 ページ）で説明します。 © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド Architect によるプロジェクトの作成 • 5 列別名 : このタブでファクトの列別名を作成します。 列別名については、「アトリビュートのデータ タイプ の変更 : 列別名」（261 ページ）で説明します。 フォームを変更] ダイアログ ボッ [アトリビュート クスの各タブにあるオプションの詳細については、 MicroStrategy Desktop オンライン ヘルプを参照し てください。 13 変更が完了したら [OK] をクリックし、Architect に戻り ます。 14 [ ファイル ] メニューから [ 保存 ] を選択し、変更を保存し ます。 複数のアトリビュートの作成と変更 Architect では、プロジェクト内の複数のアトリビュートを、 統合インタフェースから迅速に作成および変更できます。 Architect でアトリビュートを作成、変更する方法は、アトリ ビュート エディタとほぼ同じです。 アトリビュートの概念および詳しい例は、7 章、「ビジネス データのコンテキスト : アトリビュート」を参照してくださ い。次に示す各トピックを通じて、Architect でさまざまなア トリビュート定義を行う手順を示します。 • 「[ プロパティ ] ペインでのアトリビュートの変更」（154 ページ） • 「アトリビュート フォーム式の作成」（159 ページ） • 「アトリビュートのデータ型の作成と変更 : 列別名」 （163 ページ） • 「複数の ID 列を持つアトリビュートの作成 : 複合アトリ ビュート」（165 ページ） • 「アトリビュートを使用してデータのブラウズおよびレ ポートを行う方法の変更」（167 ページ） • 「アトリビュート ロールの指定 : 同じルックアップを使 用する複数のアトリビュート」（169 ページ） • 「アトリビュート エレメントのデータ国際化のサポート」 （171 ページ） © 2010 MicroStrategy, Inc. アトリビュートの作成と変更 153 5 Architect によるプロジェクトの作成 プロジェクト デザイン ガイド [ プロパティ ] ペインでのアトリビュートの変更 アトリビュートを作成すると、Architect の [ プロパティ ] ペ インを使用してアトリビュート定義を変更および表示できま す。Architect でアトリビュートの各種プロパティを表示する には、[ プロパティ ] ペインの [ アトリビュート ] タブで、ド ロップダウン リストからアトリビュート フォームを選択し ます。次に示す MicroStrategy Tutorial プロジェクトの Category アトリビュートを通じて、Architect でアトリビュー トを変更および表示する方法を説明します。 154 アトリビュートの作成と変更 © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド Architect によるプロジェクトの作成 5 Architect でアトリビュートを選択すると、[ プロパティ ] ペ インでアトリビュートを変更および表示できます。その方法 を以下に説明します。 プロパティ ] ペインでプロパティを選択すれば、その [プロパティの説明を表示できます。説明は [ プロパ ティ ] ペインの最下部に表示されます。 • 「アトリビュート定義の変更と表示 : [ 定義 ] セクション」 （155 ページ） • 「アトリビュート フォームの変更 : [ フォーム ] セク ション」（157 ページ） アトリビュート定義の変更と表示 : [ 定義 ] セクション Architect でアトリビュートを選択すると、[ プロパティ ] ペ インの [ 定義 ] セクションに、そのアトリビュートの各種プ ロパティが表示されます。これらのプロパティと、その使用 方法を次に示します。 • ID: アトリビュートの識別子。この値は変更できません。 • 名前 : MicroStrategy プロジェクト内のアトリビュートの 名前。 • 説明 : アトリビュートの説明。説明は、プロジェクト内 でのアトリビュートの用途を知るために役立ちます。 • 非表示 : アトリビュートが非表示として定義されるかど うかを指定します。アトリビュートを非表示として定義 するには、ドロップダウン リストから [ 真 ] を選択しま す。 非表示のオブジェクトは、ユーザが Desktop 基本設定を 変更して [隠しオブジェクトを表示] チェック ボックスを 選択しない限り表示されません。したがって、オブジェ クトを非表示として定義しても、ユーザによるオブジェ クトの表示やアクセスを確実に防止できるわけではあり ません。ユーザによるオブジェクトの表示やアクセスを 防ぐ最善の方法は、そのオブジェクトに対するユーザ権 限を制限することです。 • © 2010 MicroStrategy, Inc. 位置 : プロジェクト内でのアトリビュートの位置。 アトリビュートの作成と変更 155 5 Architect によるプロジェクトの作成 • プロジェクト デザイン ガイド ロック タイプ : データ エクスプローラのシステム階層内 で、アトリビュート エレメントをブラウズする方法を指 定します。次のオプションがあります。 ロック済 : アトリビュートのエレメントをデータ エク スプローラのシステム階層内に表示しません。たとえ ば、"Year"（年）アトリビュートをロックすると、 "Year" をシステム階層で展開しても、そのエレメント はデータ エクスプローラに表示されません。 ロック解除済 : アトリビュートのすべてのエレメント を、データ エクスプローラのシステム階層内に表示 します。たとえば、"Year" アトリビュートをロック解 除すると、"Year" をシステム階層で展開したときに、 そのすべてのエレメント（2005、2006、2007 など） がデータ エクスプローラに表示されます。 制限 : アトリビュートに設定されているエレメント数 ずつ呼び出します。たとえば、"Year" アトリビュート の制限が 1 に設定されている場合には、エレメントが 要求されるたびに 2005、2006、2007 が 1 つずつ呼び 出されます。 • ロック制限 : ロック タイプとして上記の [ 制限 ] を選択し た場合は、データ エクスプローラのシステム階層に一度 に呼び出して表示するエレメント数を定義できます。 • セキュリティ フィルターを適用 : エレメント要求でセ キュリティ フィルタを使用するかどうかを指定します。 この設定は、エレメント キャッシュの作成にセキュリ ティ フィルタを使用するかどうかの決定にも適用されま す。 この設定によって、エレメント要求に対するセキュリ ティ フィルタの適用が、一部のアトリビュートに限り必 要になる状況に対処できます。たとえば、外部の仕入先 向けにデータ ウェアハウスを運用している場合は、どの 仕入先も他の仕入先の製品を見ることができないように、 セキュリティ フィルタを製品ディメンションのアトリ ビュートに適用します。一方、時間ディメンションのア トリビュートには、セキュリティ フィルタを適用する必 要はありません。したがって、セキュリティ フィルタは 適用せず、エレメント キャッシュを共有できます。 • 156 アトリビュートの作成と変更 エレメント キャッシュを有効化 : アトリビュートのレベ ルでエレメント キャッシュを有効または無効にします。 アトリビュートのエレメントをキャッシュに入れること により、アトリビュート エレメントのブラウズ時に、 © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド Architect によるプロジェクトの作成 5 キャッシュから高速にエレメントが返されます。これは、 エレメントへの変更が稀であるか、あるいはエレメント がまったく変更されないアトリビュートに、特に有効で す。エレメントが変更される頻度は、アトリビュートに より大幅に異なります。たとえば、"Order Number"（注 文番号）アトリビュートのエレメントは（在庫状況によ り）毎日変更されるかもしれません。一方、"Product Number"（製品番号）アトリビュートのエレメントが変 更されるのは通常、1 週間または 1 か月に一度程度です。 アトリビュート フォームの変更 : [ フォーム ] セクション Architect でアトリビュートを選択すると、[ プロパティ ] ペ インの [ フォーム ] セクションに、そのアトリビュートのア トリビュート フォームに関する情報が表示されます。アト リビュート フォームのプロパティと、その使用方法を次に 示します。 • アトリビュート フォーム : アトリビュート フォームの 1 番目のプロパティには、そのアトリビュート フォームに 使用されているカテゴリが反映されます。 「[ プロパティ ] ペインでのアトリビュートの変更」（154 ページ）に示し た例では、"Category" の最初のプロパティとして ID が表 示されています。アトリビュート フォームのプロパティ を選択して [...] ボタンをクリックすると、アトリビュー ト フォームを変更できます。 フォームが複数のアトリビュート アトリビュート フォームを組み合わせたフォーム グループの場 合、そのフォーム グループに含まれる各アトリ ビュート フォームを変更できます。Architect で フォーム グループを作成する方法については、 「複数の ID 列を持つアトリビュートの作成 : 複合 アトリビュート」（165 ページ）を参照してくださ い。 © 2010 MicroStrategy, Inc. • 名前 : MicroStrategy プロジェクト内のアトリビュート フォームの名前。 • カテゴリ : アトリビュート フォームに使用されるカテゴ リ。アトリビュート フォームのグループ化や識別に役立 ちます。ドロップダウン リストから、アトリビュート フォームに使用するカテゴリを選択します。アトリ ビュート フォームのグループ化でのカテゴリの利用方法 については、「アトリビュート フォーム式」（253 ページ） を参照してください。 アトリビュートの作成と変更 157 5 Architect によるプロジェクトの作成 158 アトリビュートの作成と変更 プロジェクト デザイン ガイド • 書式 : アトリビュート フォームの書式。アトリビュート フォームの表示方法とフィルタの定義方法は、この書式 で制御されます。ドロップダウン リストから、アトリ ビュート フォームに使用する書式を選択します。アトリ ビュート フォームの書式については、「アトリビュート フォーム式」（253 ページ）を参照してください。 • レポートの並べ替え : アトリビュート フォームをレポー トに含めるときのデフォルトの並べ替え順序。ドロップ ダウン リストから [ 昇順 ]、[ 降順 ]、[ なし ] のいずれかを 選択します。1 つのアトリビュートの複数のアトリ ビュート フォームでデフォルトの並べ替え順序が定義さ れている場合のアトリビュート フォームの並べ替え順序 については、「複数のアトリビュート フォームのレポー トでのデフォルト並べ替え順序」（252 ページ）を参照し てください。 • ブラウズ並べ替え : アトリビュート フォームがデータ エ クスプローラに表示されるときのデフォルトの並べ替え 順序。ドロップダウン リストから [ 昇順 ]、[ 降順 ]、[ なし ] のいずれかを選択します。データ エクスプローラについ 「レポートでの階層ブラウズの有効化 : データ エ ては、 クスプローラ」（318 ページ）で説明します。 • ブラウズ フォームを使用 : データ エクスプローラにアト リビュート フォームが表示されるかどうかを指定しま す。アトリビュート フォームをデータ エクスプローラに 表示するには、ドロップダウン リストから [ 真 ] を選択し ます。データ エクスプローラについては、「レポートで の階層ブラウズの有効化 : データ エクスプローラ」（318 ページ）で説明します。 • レポート フォームを使用 : アトリビュート フォームがレ ポートにデフォルトで表示されるかどうかを指定します。 アトリビュート フォームをレポートにデフォルトで表示 するには、ドロップダウン リストから [ 真 ] を選択しま す。 • 複数言語をサポート : アトリビュート フォームの情報が、 データの国際化を使用して複数言語で表示できるかどう かを指定します。アトリビュート フォームがデータを複 数言語で表示できるように指定するには、[ 真 ] を選択し ます。 © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド Architect によるプロジェクトの作成 5 アトリビュート フォームのデータの国際化を有効にする 方法は、「アトリビュート エレメントのデータ国際化の サポート」（171 ページ）で説明します。 ID フォームは識別用途だけに アトリビュートの 限られるため、このオプションは ID フォームに はありません。 • 列別名 : アトリビュート フォームの列別名。列別名を使 用することで、アトリビュート フォームのデフォルトの データ型の代わりに、新たにデータ型を定義できます。 [ 列別名 ] プロパティを選択して [...] ボタンをクリックす ると、アトリビュート フォームの列別名を変更できま す。アトリビュート フォームの列別名については、「ア トリビュートのデータ タイプの変更 : 列別名」（261 ペー ジ）を参照してください。 • アトリビュート式 : アトリビュート フォームに使用され る式。アトリビュート式を選択して [...] ボタンをクリッ クすると、アトリビュート フォーム式を変更できます。 アトリビュート フォーム式の作成 アトリビュート式は、データ ソース内の特定のアトリ ビュート情報へのマッピングを表します。アトリビュート フォームとアトリビュート フォーム式の概念については、 「列データの説明と識別子 : アトリビュート フォーム」（248 ページ）および「アトリビュート フォーム式」（253 ページ） を参照してください。 「アトリビュートの作成」（150 ページ）で説明したように、 アトリビュート フォーム式は通常、列をアトリビュートに マップすることによって作成されます。Architect では、次に 示すようにアトリビュートを作成し、定義することもできま す。 • 「派生アトリビュート フォーム式の作成」（159 ページ） • 「異なる列名の結合 : 異種マッピング」（161 ページ） 派生アトリビュート フォーム式の作成 派生式は、ウェアハウス内の列、数学演算子、関数、および 定数を組み合わせて作成されます。単純な式はウェアハウス テーブル内の 1 つの列だけで値が決まりますが、派生式は 1 © 2010 MicroStrategy, Inc. アトリビュートの作成と変更 159 5 Architect によるプロジェクトの作成 プロジェクト デザイン ガイド つ以上の列と演算子、および値を使用して定義されます。定 数の追加、他の列の追加、式の絶対値設定など、列に対する あらゆる操作が派生式を生成します。 派生アトリビュート フォーム式の詳細は、「派生式」（256 ページ）を参照してください。Architect を使用して派生アト リビュート フォーム式を作成する手順を次に示します。こ の手順は、「例 : 派生式によるアトリビュート フォームの作 成」（256 ページ）のシナリオ例に基づいています。 Architect を使用して派生式を持つアトリビュート フォームを作 成するには 1 MicroStrategy Desktop でプロジェクトにログインします。 シナリオの例に従い、MicroStrategy Tutorial プロジェクト にログインします。 2 [ スキーマ ] メニューで [Architect] を選択します。 MicroStrategy Architect が開きます。 3 [ プロジェクト テーブル ビュー] で、アトリビュート定義 に使用する 1 つ以上の列を含むテーブルを見つけ、それ を選択します。 シナリオの例に従い、LU_CUSTOMER テーブルを選択 します。 4 "Customer" アトリビュートを右クリックして [新規アトリ ビュート フォーム ] を選択します。[ 新規フォーム式を作 成 ] ダイアログ ボックスが開きます。 5 CUST_LAST_NAME 列をダブルクリックして右側の [ フォーム式 ] ペインに追加します。 6 [ フォーム式 ] ペインで、カーソルを [CUST_LAST_NAME] の右側に置き、「+ ", " +」と入力します。 160 アトリビュートの作成と変更 © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド Architect によるプロジェクトの作成 5 7 CUST_FIRST_NAME 列をダブルクリックして右側の [ フォーム式 ] ペインに追加します。式が次のように定義 されます。 8 マッピング方法として [ 手動 ] を選択します。 9 [OK] をクリックして Architect に戻ります。新しいアト リビュート フォーム式が "Customer" アトリビュートの一 部として LU_CUSTOMER テーブル内に表示されます。 10 [ プロパティ] ペインで新しいアトリビュート フォームを 見つけます。 11 [ 名前 ] フィールドに「Last Name, First Name」と入力 します。 12「Last Name, First Name」は "Customer" の ID フォームでも 第一説明フォームでもないため、[ カテゴリ ] ドロップダ ウン リストから [ なし ] を選択します。 13 これは例に過ぎないため、変更を保存せずに Architect を 閉じることができます。 異なる列名の結合 : 異種マッピング 異種マッピングにより、Intelligence Server は異なる複数の列 名を結合できます。特定のフォームに複数の式を定義した場 合、テーブルと列名によって必要とされるときに、異種マッ ピングが自動的に実行されます。 アトリビュートの異種マッピングの詳細は、「異なる列名の 結合 : 異種マッピング」（258 ページ）を参照してください。 Architect を使用して、異種列マッピングを持つアトリビュー トを作成する手順を次に示します。この手順は、「異なる列 名の結合 : 異種マッピング」（258 ページ）のシナリオ例に 基づいています。 © 2010 MicroStrategy, Inc. アトリビュートの作成と変更 161 5 Architect によるプロジェクトの作成 プロジェクト デザイン ガイド Architect を使用して異種列マッピングを持つアトリビュート フォームを作成するには 1 MicroStrategy Desktop でプロジェクトにログインします。 シナリオの例に従い、MicroStrategy Tutorial プロジェクト にログインします。 2 [ スキーマ ] メニューで [Architect] を選択します。 MicroStrategy Architect が開きます。 3 [ プロジェクト テーブル ビュー] で、アトリビュート定義 に使用する 1 つ以上の列を含むテーブルを見つけ、それ を選択します。 シナリオの例に従い、LU_DAY テーブルを選択します。 4 "Customer" アトリビュートを右クリックして [新規アトリ ビュート フォーム ] を選択します。[ 新規フォーム式を作 成 ] ダイアログ ボックスが開きます。 5 DAY_DATE 列をダブルクリックして右側の [フォーム式] ペインに追加します。 6 マッピング方法として [ 自動 ] を選択します。 7 [OK] をクリックして Architect に戻ります。新しいアト リビュート フォームが "Day" アトリビュートの一部とし て LU_DAY テーブル内に表示されます。 8 新しいアトリビュート フォームを右クリックして [編集] を選択します。[ アトリビュート フォームを変更 ] ダイア ログ ボックスが開きます。 9 [ 新規作成 ] をクリックします。[ 新規フォーム式を作成 ] ダイアログ ボックスが開きます。 10 [ ソース テーブル ] ドロップダウン リストから ORDER_DETAIL テーブルを選択します。 11 ORDER_DATE 列をダブルクリックして右側の [ フォー ム式 ] ペインに追加します。 12 マッピング方法として [ 自動 ] を選択します。 162 アトリビュートの作成と変更 © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド Architect によるプロジェクトの作成 5 13 [OK] をクリックします。[ 新規アトリビュート フォーム を作成 ] ダイアログ ボックスが開きます。 これで 1 つのアトリビュート フォーム定義に 2 つの式が 追加されました。これらの式は互いに異なるテーブルを 情報のソースとして使用します。この手順を繰り返して、 異種の列を必要な数だけアトリビュート フォームに追加 できます。 14 [OK] をクリックして Architect に戻ります。 15 [ プロパティ] ペインで新しいアトリビュート フォームを 見つけます。 16 [ 名前 ] フィールドに Date Example と入力します。 17 これは例であるため、[ カテゴリ ] ドロップダウン リスト から [ なし ] を選択します。 18 これはひとつの例ですので、変更を保存せずに Architect を閉じることができます。 アトリビュートのデータ型の作成と変更 : 列別名 列別名を使用すると、特定のアトリビュート フォームに、 デフォルトのデータ型の代わりに使用するデータ型を指定で きます。列別名でより適切なデータ型を指定すれば、SQL のエラーを回避しやすくなります。また、データ ウェアハ ウス内のデータも、より効果的に利用できます。 アトリビュートの列別名については、「アトリビュートの データ タイプの変更 : 列別名」（261 ページ）を参照してく ださい。Architect を使用して列別名を作成する手順を次に示 します。この手順は、「アトリビュートのデータ タイプの変 更 : 列別名」（261 ページ）のシナリオ例に基づいています。 前提条件 この手順は、有効なアトリビュート式を持つアトリビュート が作成済みで、そのアトリビュートに列別名を新規作成する 場合を想定しています。 © 2010 MicroStrategy, Inc. アトリビュートの作成と変更 163 5 Architect によるプロジェクトの作成 プロジェクト デザイン ガイド Architect でアトリビュートの列別名を作成するには 1 MicroStrategy Desktop でプロジェクトにログインします。 シナリオの例に従い、MicroStrategy Tutorial プロジェクト にログインします。 2 [ スキーマ ] メニューで [Architect] を選択します。 MicroStrategy Architect が開きます。 3 [ プロジェクト テーブル ビュー] で、列別名を作成するア トリビュートを含むテーブルを見つけ、それを選択しま す。 4 列別名を作成するアトリビュート フォームを右クリック して、[ 編集 ] を選択します。[ アトリビュート フォームを 変更 ] ダイアログ ボックスが開きます。 5 [ 列別名 ] タブを選択します。 6 [ 列別名 ] 領域で [ 選択 ] をクリックします。[ 列エディタ 列を選択 ] ダイアログ ボックスが開きます。 7 [ 新規作成 ] を選択して新しい列別名を作成します。[ 列エ ディタ - 定義 ] ダイアログ ボックスが開きます。 8 列別名の次のプロパティを変更できます。 • 列名 : 列別名の名前。この名前は、選択したファクト の列を含むすべての SQL ステートメントで使用され ます。 • データ タイプ : ファクトのデータ型。MicroStrategy で サポートされているデータ型については、「データ タ イプ」（441 ページ）を参照してください。 • 選択するデータ型によっては、列別名のバイト長、 ビット長、精度、スケール、またはタイム スケール を指定できます。これらの各プロパティの詳細につい ては、MicroStrategy Desktop オンライン ヘルプを参照 してください。 9 [OK] をクリックして変更を保存し、[ 列エディタ - 列を 選択 ] ダイアログ ボックスに戻ります。 164 アトリビュートの作成と変更 © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド Architect によるプロジェクトの作成 5 10 [OK] をクリックして変更を保存し、[ アトリビュート フォームを変更 ] ダイアログ ボックスに戻ります。 11 [OK] をクリックして Architect に戻ります。 12 [ ファイル ] メニューから [ 保存 ] を選択し、変更を保存し ます。 複数の ID 列を持つアトリビュートの作成 : 複合ア トリビュート 複合アトリビュートとは、ID 列として指定されている列を 複数持つアトリビュートのことです。これは、そのようなア トリビュートを一意に識別するために、複数の ID 列が必要 であることを意味します。通常、複合アトリビュートを作成 するのは、論理データ モデルに複合キー関係の存在が反映 されている場合です。リレーショナル データベース内の複 合キーは、データベースの複数の列から構成される主キーで す。 複合アトリビュートについては、「複数の ID 列を持つアト リビュート : 複合アトリビュート」（291 ページ）を参照し てください。Architect を使用して複合アトリビュートを作成 する手順を次に示します。この手順は、「例 : 複合アトリ ビュートの作成」（291 ページ）のシナリオ例に基づいてい ます。 Architect で複合アトリビュートを作成するには 1 MicroStrategy Desktop でプロジェクトにログインします。 シナリオの例に従い、MicroStrategy Tutorial プロジェクト にログインします。 2 [ スキーマ ] メニューで [Architect] を選択します。 MicroStrategy Architect が開きます。 3 [ プロジェクト テーブル ビュー] で、複合アトリビュート に使用する列を含むテーブルを見つけ、それを選択しま す。 シナリオの例に従い、LU_DIST_CTR テーブルを選択し ます。 © 2010 MicroStrategy, Inc. アトリビュートの作成と変更 165 5 Architect によるプロジェクトの作成 プロジェクト デザイン ガイド 4 テーブルを右クリックして [ アトリビュートを作成 ] を選 択します。アトリビュートに名前を付けるダイアログ ボックスが開きます。 5 アトリビュートの名前を入力して [OK] をクリックしま す。[ 新規フォーム式を作成 ] ダイアログ ボックスが開き ます。 6 COUNTRY_ID 列をダブルクリックして右側の [ フォーム 式 ] ペインに追加します。 7 マッピング方法として [ 自動 ] を選択します。 8 [OK] をクリックして Architect に戻ります。新しいアト リビュートが LU_DIST_CTR テーブル内に表示されま す。 アトリビュートの名前を変更するには、アトリ ビュートを右クリックして [ 名前の変更 ] を選択し ます。 9 [ プロパティ] ペインで新しいアトリビュート フォームを 見つけます。 10 [ 名前 ] フィールドに ID 1 と入力します。 11 アトリビュートを右クリックして [ 新規アトリビュート フォーム ] をクリックし、アトリビュート ID フォームを もう 1 つ作成します。[ 新規フォーム式を作成 ] ダイアロ グ ボックスが開きます。 12 DIST_CTR_ID 列をダブルクリックして右側の [ フォーム 式 ] ペインに追加します。 13 マッピング方法として [ 自動 ] を選択します。 14 [OK] をクリックして Architect に戻ります。新しいアト リビュート フォームが LU_DIST_CTR テーブル内に表示 されます。 15 [ プロパティ] ペインで新しいアトリビュート フォームを 見つけます。 16 [ 名前 ] フィールドに ID 2 と入力します。 166 アトリビュートの作成と変更 © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド Architect によるプロジェクトの作成 5 17 [ カテゴリ ] ドロップダウン リストから [ID] を選択しま す。フォーム グループを作成していることを通知する メッセージが表示されます。 フォームをドラッグし、同じアト アトリビュート リビュートの別のアトリビュート フォームにド ロップする方法でも、フォーム グループを作成で きます。 18 [ はい ] をクリックしてフォーム グループを作成します。 2 つのアトリビュート フォームが 1 つのフォーム グルー プに含まれます。 グループを使用して複合アトリビュート フォーム を作成する方法の詳細は、「複数の ID 列を持つア トリビュート : 複合アトリビュート」（291 ペー ジ）を参照してください。 19 アトリビュート フォームの 1 番目の [名前] フィールドに ID と入力します。 20 これはひとつの例ですので、変更を保存せずに Architect を閉じることができます。 アトリビュートを使用してデータのブラウズおよび レポートを行う方法の変更 作成したアトリビュートは、主にブラウズとレポートという 2 つの用途に使用します。ユーザはアトリビュートを手がか りにブラウズし、レポートで使用するアトリビュートを見つ けるとレポートに配置します。これにより、配置したアトリ ビュートの詳細と、そのアトリビュートがファクト データ にどのように関係しているかをレポートに表示できます。ア トリビュートはさまざまな形で表示できるため、プロジェク ト内の各アトリビュートのデフォルト表示を指定する必要が あります。このタスクはレポート単位で実行できますが、プ ロジェクト全体にグローバルに適用される各アトリビュート のデフォルトも指定しなければなりません。 レポートとブラウズに使用するアトリビュート フォームを 変更する方法については、「アトリビュートを使用したデー タのブラウズとレポート」（294 ページ）を参照してくださ い。Architect でアトリビュート フォームの表示を定義する © 2010 MicroStrategy, Inc. アトリビュートの作成と変更 167 5 Architect によるプロジェクトの作成 プロジェクト デザイン ガイド 手順を次に示します。この手順は、「アトリビュート フォー ムのデフォルト表示の定義」（295 ページ）のシナリオ例に 基づいています。 Architect を使用してアトリビュート フォームをレポートおよび データ エクスプローラに表示するには 1 MicroStrategy Desktop でプロジェクトにログインします。 シナリオの例に従い、MicroStrategy Tutorial プロジェクト にログインします。 2 [ スキーマ ] メニューで [Architect] を選択します。 MicroStrategy Architect が開きます。 3 [ プロジェクト テーブル ビュー ] で、アトリビュート フォームのデフォルト表示を定義するアトリビュートを 含んでいるテーブルを見つけ、それを選択します。 シナリオの例に従い、LU_DIST_CTR テーブルを選択し ます。このテーブルには "Distribution Center"（配送セン タ）アトリビュートが含まれています。 4 アトリビュートを選択します。 シナリオの例に従い、"Distribution Center" アトリ ビュートを選択します。 5 [ プロパティ] ペインでアトリビュート フォームを見つけ ます。 この Tutorial の例では、"ID 2" アトリビュート フォーム を見つけます。 6 以下の表示オプションを指定できます。 • レポートの並べ替え : アトリビュート フォームをレ ポートに含めるときのデフォルトの並べ替え順序。ド ロップダウン リストから [ 昇順 ]、[ 降順 ]、[ なし ] のい ずれかを選択します。1 つのアトリビュートの複数の アトリビュート フォームでデフォルトの並べ替え順 序が定義されている場合のアトリビュート フォーム の並べ替え順序については、「複数のアトリビュート フォームのレポートでのデフォルト並べ替え順序」 （252 ページ）を参照してください。 168 アトリビュートの作成と変更 © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド Architect によるプロジェクトの作成 5 • ブラウズ並べ替え: アトリビュート フォームがデータ エクスプローラに表示されるときのデフォルトの並べ 替え順序。ドロップダウン リストから [ 昇順 ]、[ 降 順 ]、[ なし ] のいずれかを選択します。データ エクス プローラについては、 「レポートでの階層ブラウズの 有効化 : データ エクスプローラ」（318 ページ）で説 明します。 • ブラウズ フォームを使用 : データ エクスプローラに アトリビュート フォームが表示されるかどうかを指 定します。アトリビュート フォームをデータ エクス プローラに表示するには、ドロップダウン リストか ら [ 真 ] を選択します。データ エクスプローラについ ては、「レポートでの階層ブラウズの有効化 : データ エクスプローラ」（318 ページ）で説明します。 • レポート フォームを使用 : アトリビュート フォーム がレポートにデフォルトで表示されるかどうかを指定 します。アトリビュート フォームをレポートにデ フォルトで表示するには、ドロップダウン リストか ら [ 真 ] を選択します。 7 レポートおよびデータ エクスプローラに表示するアトリ ビュートのデフォルトの並べ替え順序も指定できます。 アトリビュート フォームの並べ替えオプションの詳細 は、「フォームの表示 : アトリビュート フォームのプロ パティ」（250 ページ）を参照してください。 8 これはひとつの例ですので、変更を保存せずに Architect を閉じることができます。 アトリビュート ロールの指定 : 同じルックアップを 使用する複数のアトリビュート アトリビュート ロールを使用すれば、同じデータで 2 つの アトリビュートを定義し、サポートできます。1 つのアトリ ビュートに複数のロール（役割）があると判断した場合は、 それらのロールごとに 1 つのアトリビュートを論理モデル内 で作成する必要があります。これにより、複数のロールを持 つアトリビュートを含むレポートが、正しいデータを返すよ うになります。 アトリビュート ロールについては、「同じルックアップ テー ブルを使用する複数のアトリビュート : アトリビュート ロール」（281 ページ）を参照してください。明示的テーブ © 2010 MicroStrategy, Inc. アトリビュートの作成と変更 169 5 Architect によるプロジェクトの作成 プロジェクト デザイン ガイド ル別名を使用して、アトリビュート ロールを指定する方法 を以下に示します。この手順は、「明示的テーブル別名によ るアトリビュート ロールの指定」（287 ページ）のシナリオ 例に基づいています。 ロールは、自動ロール認識を使用し アトリビュート て定義することもできます。自動ロール認識では、 MicroStrategy の VLDB プロパティが利用されます。 自動ロール認識については、「自動アトリビュート ロール認識の使用」（286 ページ）を参照してくださ い。 Architect で明示的テーブル別名を使用してアトリビュート ロー ルを作成するには この手順では、このガイドで後述する明示的テーブル別名の 例を作成するステップを示します。MicroStrategy Tutorial プ ロジェクトには LU_STATE テーブルは含まれていません。 それでも、大まかな手順と概念を把握すれば、それをガイド ラインとして、プロジェクトにアトリビュート ロールを作 成できます。 1 MicroStrategy Desktop で、明示的テーブル別名を使用し てアトリビュート ロールを作成するプロジェクトにログ インします。 2 [ スキーマ ] メニューで [Architect] を選択します。 MicroStrategy Architect が開きます。 3 [ プロジェクト テーブル ビュー ] で、アトリビュート ロールの定義対象となるアトリビュートを含むテーブル LU_STATE を見つけ、それを選択します。 4 LU_STATE テーブルを右クリックして [ テーブル別名を 作成 ] を選択します。LU_STATE(1) テーブルが作成され ます。 5 LU_STATE(1) を右クリックして [ 名前の変更 ] を選択し、 LU_STATE_STORE と入力します。 6 LU_STATE テーブルを右クリックして [ テーブル別名を 作成 ] を選択します。LU_STATE(1) テーブルが作成され ます。 170 アトリビュートの作成と変更 © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド Architect によるプロジェクトの作成 5 7 LU_STATE(1) を右クリックして [ 名前の変更 ] を選択し、 LU_STATE_VENDOR と入力します。 アトリビュートを作成します。 8 LU_STATE_STORE テーブルを右クリックして [ アトリ ビュートを作成 ] を選択します。[ 新規フォーム式を作成 ] ダイアログ ボックスが開きます。 9 [ 使用可能な列 ] ペインで、アトリビュート ロールを識別 する STATE_ID をダブルクリックします。 10 [ 手動 ] を選択して [OK] をクリックします。Architect に戻 ります。LU_STATE_STORE テーブル内に新しいアトリ ビュートが作成されています。 11 新しいアトリビュートを右クリックして [ 名前の変更 ] を 選択し、State Store と入力します。 12 "State Store"（州の店舗）アトリビュート テーブルを右 クリックして [新規アトリビュート フォーム] を選択しま す。[ 新規フォーム式を作成 ] ダイアログ ボックスが開き ます。 13 "State Store" アトリビュートのアトリビュート フォーム に、他のすべての列をマップします。すべての "State Store" アトリビュート フォームを LU_STATE_STORE テーブル内の列にマップしてください。 14 [OK] をクリックして "State Store" アトリビュートを保存 します。 15 上記の "State Store" の作成と同じ下位手順（「アトリ ビュートを作成します。」（171 ページ））で "Vendor State" （ベンダの州）アトリビュートを作成します。ただし、 LU_STATE_STORE テーブルの代わりに LU_STATE_VENDOR テーブルを使用してください。 アトリビュート エレメントのデータ国際化のサ ポート MicroStrategy は、データをユーザに必要な言語にする国際化 をサポートしています。これにより、ユーザの言語ニーズに 応じて、アトリビュート エレメントのデータをさまざまな 言語で表示できます。 © 2010 MicroStrategy, Inc. アトリビュートの作成と変更 171 5 Architect によるプロジェクトの作成 プロジェクト デザイン ガイド アトリビュート エレメントのデータ国際化を有効にする方 法については、「アトリビュート エレメントのデータ国際化 のサポート」（245 ページ）を参照してください。Architect を使用してアトリビュート エレメントのデータ国際化を有 効にする手順を以下に示します。 前提条件 • 国際化データがデータ ソースに格納されていること （「データの国際化のサポート」（63 ページ）を参照）。 • プロジェクトのデータ国際化が有効になっていること （「プロジェクトのデータの国際化」（92 ページ）を参 照）。 • アトリビュートが作成済みであること。 Architect を使用してアトリビュート フォームのデータ国際化を 有効または無効にするには 1 Desktop でプロジェクトにログインします。 2 [ スキーマ ] メニューで [Architect] を選択します。 MicroStrategy Architect が開きます。 3 [ プロジェクト テーブル ビュー] でアトリビュートを見つ けます。 4 [ プロパティ] ペインでアトリビュート フォームを見つけ ます。 5 [複数言語をサポート] ドロップダウン リストから [真] を 選択し、アトリビュート フォームのデータ国際化を有効 にします。[ 偽 ] を選択すると、アトリビュート フォーム のデータ国際化が無効になります。 ID フォームは識別用途だけに アトリビュートの 限られるため、このオプションは ID フォームに はありません。 6 [ 保存して閉じる ] をクリックして変更を保存し、 Architect を閉じます。 172 アトリビュートの作成と変更 © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド Architect によるプロジェクトの作成 5 アトリビュート関係の定義 プロジェクトのアトリビュートを作成すると、エンジンが SQL を生成する方法、テーブルと列の結合 / 使用方法、およ びテーブル間の関係を、アトリビュート関係を定義して決定 できます。 親子関係を定義することによって、直接的な関係がある複数 のアトリビュートを相互にリンクできます。アトリビュート 間に定義する関係は、アトリビュート エレメント（アトリ ビュートの実際のデータ値）によって決まります。 作成する親子関係によって、プロジェクト内のシステ ム階層が決定されます。 アトリビュート間の関係には、1 対 1、1 対多、多対 1、多対 多という 4 つの種類があります。これらの直接的関係に関す る情報と、これらの関係をアトリビュート エディタで定義 する手順については、「アトリビュート関係」（265 ページ） を参照してください。 アトリビュート間の関係は Architect でも定義できます。 Architect では、より直感的で親切なワークフローによって、 アトリビュート関係を定義しながら、複数のアトリビュート を表示して変更できます。 たとえば、MicroStrategy Tutorial プロジェクトの "Time"（時 間）階層には、"Year"（年）、"Quarter"（四半期）、"Month of Year"（カレンダ月）、"Month"（月）、"Day"（日）の各アト リビュート間の関係が含まれています。Architect では、親子 関係をアトリビュートごとに 1 つずつ定義する代わりに、視 覚的な環境で複数のアトリビュート間の関係を一度に定義で きます。 アトリビュート間の親子関係を手動で定義する手順を以下に 示します。さらに、MicroStrategy Tutorial プロジェクトで "Year"、"Quarter"、"Month of Year"、"Month"、"Day" の各ア トリビュート間に関係を作成するシナリオの一例も示しま す。 Architect では、「アトリビュート関係の自動定義」（179 ペー ジ）で説明するように、データのデザインに基づいてアトリ ビュート関係を自動的に定義することも可能です。 前提条件 © 2010 MicroStrategy, Inc. アトリビュート関係の定義 173 5 Architect によるプロジェクトの作成 • プロジェクト デザイン ガイド プロジェクトに複数のアトリビュートをすでに作成して いること。 アトリビュート関係を定義するには 1 MicroStrategy Desktop でプロジェクトにログインします。 シナリオの例に従い、MicroStrategy Tutorial プロジェクト にログインします。 2 [ スキーマ ] メニューで [Architect] を選択します。 MicroStrategy Architect が開きます。 の階層表示に加え、アトリビュート関係の定 Architect 義にはシステム ディメンション エディタも使用でき ます。アトリビュート関係の定義に使用するツールの 決定方法は、「システム ディメンション エディタの使 用」（178 ページ）を参照してください。 3 [ 階層表示 ] で、ツールバーの [ 階層 ] ドロップダウン リス トから [ システム階層ビュー ] を選択します。システム階 層が表示されます。 4 関係を定義する前に、Architect の階層表示内の同じ領域 に、相互に関係付けるアトリビュートを集める必要があ ります。たとえば、MicroStrategy Tutorial プロジェクトの "Year"、"Quarter"、"Month of Year"、"Month"、"Day" の各 174 アトリビュート関係の定義 © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド Architect によるプロジェクトの作成 5 アトリビュートは、次に示すように階層表示内で互いに 近い位置に集められています。 アトリビュート関係の作成手順 5 アトリビュート関係で親アトリビュートになるアトリ ビュートを選択します。そのアトリビュートの中央をク リックし、そのまま選択した親アトリビュートの子にな るアトリビュートまでドラッグします。2 つのアトリ ビュート間に 1 対多関係を示す線が表示されます。 © 2010 MicroStrategy, Inc. アトリビュート関係の定義 175 5 Architect によるプロジェクトの作成 プロジェクト デザイン ガイド たとえば次の図では、"Year" アトリビュートと "Quarter" アトリビュート間に関係が作成されており、"Year" が "Quarter" の親アトリビュートになっています。 この関係線上には、親アトリビュートから子アトリ ビュートへの方向を指す三角形の矢印が作成されます。 上図では、矢印は "Year" アトリビュートから "Quarter" ア トリビュートを指しており、"Year" が "Quarter" の親アト リビュートであることを示しています。 6 この方法で作成されたアトリビュート関係は、デフォル トで 1 対多関係になります。関係の種類を変更するには、 関係線を右クリックして、次に示すいずれかの関係の種 類を選択します。 • 一対一 • 1 対多 • 多対 1 • 多対多 各種の関係については、「アトリビュート関係」（265 ページ）を参照してください。 7 両方のアトリビュートが存在しているテーブルが、アト リビュート関係をサポートする関係テーブルとして選択 されます。関係テーブルを変更するには、関係線を右ク リックして [ 関係テーブル ] をポイントし、テーブルを選 択します。 その他の手法でアトリビュート関係を定義するには アトリビュート関係の定義が完了したら、変更を保存し て Architect を閉じることができます。残りの手順では、 176 アトリビュート関係の定義 © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド Architect によるプロジェクトの作成 5 他の手法でアトリビュート関係を定義する方法を示し、 シナリオ例を完了します。 8 "Quarter" アトリビュートを右クリックして [ 子の関係を 編集 ] を選択します。[ 子の関係 ] ダイアログ ボックスが 開き、"Quarter" アトリビュートに関係付けることが可能 なアトリビュートのリストが表示されます。 9 "Month" アトリビュートの場合、[ 関係タイプ ] ドロップ ダウン リストから [1 対多 ] を選択します。[ 関係タイプ ] ドロップダウン リストでは、必要な関係を作成するため に適した関係を、利用可能な関係の中から選択します。 10 "Month" アトリビュートの場合、[ 関係テーブル ] ドロッ プダウン リストは、デフォルトの [LU_MONTH] から変 更しません。 11 リストに含まれている他の各アトリビュートについては、 [関係タイプ] ドロップダウン リストは [なし] のままにし ておきます。"Quarter" は、これらのアトリビュートのい ずれとも直接関係しないからです。 12 [OK] をクリックして [ 子の関係 ] ダイアログ ボックスを 閉じ、"Quarter" と "Month" 間にアトリビュート関係を作 成します。 13 "Month of Year" アトリビュートの中央をクリックして、 そのまま "Month" アトリビュートまでドラッグします。 これら 2 つのアトリビュート間に 1 対多関係を示す線が 表示されます。 14 "Month" アトリビュートの中央をクリックして、そのま ま "Day" アトリビュートまでドラッグします。これら 2 つのアトリビュート間に 1 対多関係を示す線が表示され ます。 © 2010 MicroStrategy, Inc. アトリビュート関係の定義 177 5 Architect によるプロジェクトの作成 プロジェクト デザイン ガイド これで必要なアトリビュート関係の定義は完了です。表 示は次のようになります。 システム ディメンション エディタの使用 Architect の階層表示に加え、アトリビュート関係の定義には システム ディメンション エディタも使用できます。 システム ディメンション エディタでは、「アトリビュート関 係を定義するには」（174 ページ）で説明した Architect の場 合と同じワークフローでアトリビュート関係を定義できま す。システム ディメンション エディタを開く手順について は、「システム ディメンション エディタにアクセスするに は」（179 ページ）を参照してください。 178 アトリビュート関係の定義 © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド Architect によるプロジェクトの作成 5 アトリビュート関係の定義にどちらのツールを使用するか判 断する材料として、次の表に各ツールのさまざまな機能と特 長を示します。 機能 システム ディメンション エディタ Architect アトリビュート関係の Architect とシステム ディメンション エディタは、どちらも同じワークフロー 定義 でアトリビュート関係を定義する（このワークフローについては、「アトリ ビュート関係を定義するには」（174 ページ）を参照）。 アトリビュートの変更 Architect を通じて利用できるさまざま な手法とツールを使用してアトリ ビュートを変更できる（「アトリ ビュートの作成と変更」（149 ページ） を参照）。 システム ディメンション エディタ内 でアトリビュートを右クリックし、 [ 編集 ] を選択することで、アトリ ビュート エディタを使用してアトリ ビュートを変更できる。 アトリビュートに依存 アトリビュートに依存しているプロ しているオブジェクト ジェクト内のオブジェクトは検索でき の検索 ない。 アトリビュートに依存しているプロ ジェクト内のオブジェクトを検索でき る。このタイプの検索は、アトリ ビュートに依存しているレポート、プ ロンプト、フィルタなどのオブジェク トを返す。 システム ディメンション エディタにアクセスするには 1 MicroStrategy Desktop でプロジェクトにログインします。 2 [ スキーマ ] メニューから [ システム ディメンションを編 集 ] を選択します。システム ディメンション エディタが 開きます。 アトリビュート関係を定義するには、「アトリビュート関 係を定義するには」（174 ページ）で説明しているワーク フローに従います。 アトリビュート関係の自動定義 アトリビュート関係を手動で定義する方法（「アトリビュー ト関係の定義」（173 ページ）を参照）以外に、データ ソー ス内のデータのデサインに基づいて、Architect に自動的にア トリビュート関係を定義させることもできます。 データ ソース内のデータのデサインに基づいて、アトリ ビュート関係を自動定義する手順を以下に示します。 © 2010 MicroStrategy, Inc. アトリビュート関係の定義 179 5 Architect によるプロジェクトの作成 プロジェクト デザイン ガイド 前提条件 • プロジェクトに複数のアトリビュートをすでに作成して いること（「アトリビュートの作成と変更」（149 ページ） を参照）。 アトリビュート関係を自動定義するには 1 MicroStrategy Desktop でプロジェクトにログインします。 2 [ スキーマ ] メニューで [Architect] を選択します。 MicroStrategy Architect が開きます。 3 [ 階層表示 ] で、ツールバーの [ 階層 ] ドロップダウン リス トから [ システム階層ビュー ] を選択します。システム階 層が表示されます。 4 プロジェクトのアトリビュートを表示している領域内を 右クリックし、[ 関係自動作成 ] を選択します。[ システム 階層 ] ダイアログ ボックスが開きます。 5 アトリビュート関係の自動定義に適用する規則を、以下 のオプションから選択します。 主キー / 外部キーに基づく : テーブル内で定義されて いる主キーと外部キーを基にアトリビュート関係を作 成します。テーブルの外部キーとして機能する各アト リビュートは、同じテーブルの主キーとして機能する 各アトリビュートの親アトリビュートです。アトリ ビュート関係は、外部キー アトリビュート（親アト リビュート）から主キー アトリビュート（子アトリ ビュート）への 1 対多関係として定義されます。 ルックアップ テーブルに基づく : 主キーや外部キー を含まないルックアップ テーブルを基にアトリ ビュート関係を作成します。テーブルをアトリビュー トのルックアップ テーブルとして定義する方法につ いては、「アトリビュートの作成」（150 ページ）を参 照してください。ルックアップ テーブルとして定義 されたテーブルを持つ各アトリビュートが、同じテー ブル内の他の全アトリビュート（ルックアップ テー ブルとして定義されたテーブルを持たないアトリ ビュート）の子アトリビュートになります。各アトリ ビュート関係は、親アトリビュートから子アトリ ビュートへの 1 対多関係として定義されます。 180 アトリビュート関係の定義 © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド Architect によるプロジェクトの作成 5 テーブルからのサンプル データに基づく : 同じルッ クアップ テーブルを共有する複数のアトリビュート のアトリビュート関係を作成します。テーブルをアト リビュートのルックアップ テーブルとして定義する 方法については、「アトリビュートの作成」（150 ペー ジ）を参照してください。 Architect がテーブルのサンプル データを分析します。 固有値の少ないアトリビュートが、親アトリビュート から子アトリビュートへの 1 対多関係を使用して、固 有値の多いアトリビュートの親になります。たとえ ば、4 行のデータを含むルックアップ テーブルに、年 と四半期に関連するデータが含まれているとします。 各行には同じ年（2009 など）が含まれていますが、 四半期は行ごとに異なっています（Q1、Q2、Q3、 Q4）。この場合、"Year"（年）アトリビュートが "Quarter"（四半期）アトリビュートの親として作成さ れます。 6 適切なオプションを選択したら、[OK] をクリックすれば Architect が自動的にアトリビュート関係を定義します。 選択した規則によってすべての関係が決定されると、そ れらのアトリビュート関係に対して Architect が最終分析 を実行します。その結果、冗長と判定されたアトリ ビュート関係は作成されません。これにより、データ ソース内のデータのデザインを適切に反映したアトリ ビュート関係が作成されます。作成されたアトリビュー ト関係を変更する方法については、「アトリビュート関係 の定義」（173 ページ）を参照してください。 ユーザ階層の作成と変更 ユーザ階層によって、エレメントのブラウズとレポートのド リルが柔軟に行えるようになります。ユーザ階層とは、アト リビュートのグループとそれらの間の関係を、ビジネス組織 にとって意味のある方法で配置したものです。ビジネス インテリジェンス システムの構造が進化するに伴って、 ユーザ階層のデザインも、より多くのアトリビュートを含む ように、あるいはユーザのアクセスを特定アトリビュートに 制限するように変更できます。 © 2010 MicroStrategy, Inc. ユーザ階層の作成と変更 181 5 Architect によるプロジェクトの作成 プロジェクト デザイン ガイド ユーザ階層の概念については、8 章、「アトリビュートの構 成とブラウズを行うための階層の作成」を参照してくださ い。 ここでは、Architect を使用してユーザ階層を作成および変更 する方法を説明します。 ユーザ階層の作成 Architect では階層を、最初のプロジェクト デザインの一部 として作成できるほか、プロジェクトのライフ サイクルを 通じて随時、作成することもできます。 この項では、アトリビュートのブラウズとドリルに役 立つユーザ階層の作成について説明します。システム 階層は、プロジェクト内のアトリビュート間で定義さ れている関係に基づいて作成されます。システム階層 は「アトリビュート関係の定義」（173 ページ）で説 明したように、定義したアトリビュート関係を基に自 動的に作成されます。 Architect でユーザ階層を作成する手順を以下に示します。 前提条件 プロジェクト オブジェクトをすでに作成し、プロジェクト にテーブルを追加していること。Architect でプロジェクトを 作成する方法については、「Architect によるプロジェクトの 作成」（116 ページ）を参照してください。 Architect を使用してユーザ階層を作成するには 1 MicroStrategy Desktop でプロジェクトにログインします。 2 [ スキーマ ] メニューで [Architect] を選択します。 MicroStrategy Architect が開きます。 3 [ 階層表示 ] で階層に含めるアトリビュートを選択し、 ツールバーの [ 新規階層 ] オプション（ ）をクリックし ます。階層に名前を付けるダイアログ ボックスが表示さ れます。 182 ユーザ階層の作成と変更 © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド Architect によるプロジェクトの作成 5 4 [ 階層名を入力してください ] フィールドに階層の名前を 入力し、[OK] をクリックします。階層表示に戻ります。 階層には、選択したアトリビュートが含まれています。 5 階層にアトリビュートを追加するには、[ 階層表示 ] 内を 右クリックして [ アトリビュートを階層へ追加 ] を選択し ます。[ オブジェクトを選択 ] ダイアログ ボックスが開き ます。 6 [ 使用可能なオブジェクト ] ペインで階層内で使用するア トリビュートを選択し、矢印をクリックして [ 選択した オブジェクト ] ペインに追加します。 7 [OK] をクリックして [ アトリビュートを選択 ] ダイアロ グ ボックスを閉じ、Architect に戻ります。選択したアト リビュートが階層表示に表示されます。 8 ブラウズ関係やドリル関係を作成するには、他のアトリ ビュートにブラウズ / ドリル可能なアトリビュートを見 つけます。そのアトリビュートの中央をクリックし、そ のまま他のアトリビュートまでドラッグします。2 つの アトリビュート間にブラウズ / ドリル関係が作成されま す。 9 階層をドリル階層として使用するには、[ 階層表示 ] 内を 右クリックし、[ ドリル階層として使用 ] を選択します。 このチェック ボックスをクリアすると、階層はブラウズ だけに使用されます。 ドリル階層は、ブラウズとドリルの両方に使用できます。 ドリル階層については、「階層を使用するドリル」（319 ページ）で説明します。 10 ユーザ階層内の各アトリビュートには、そのアトリ ビュートが階層内で表示され、アクセスされる方法を制 御するプロパティがあります。アトリビュートを右ク リックして、以下のプロパティを構成できます。 © 2010 MicroStrategy, Inc. • ブラウズ アトリビュートを定義 : 選択したアトリ ビュートからユーザがブラウズ / ドリルできるアトリ ビュートを定義します。これらの関係も、この手順で 前述した 1 つのアトリビュートから他のアトリビュー トへのドラッグ アンド ドロップ操作で定義できます。 • アトリビュート フィルタを定義 : 呼び出されたデー タをすべて表示するか、特定の基準でフィルタリング するかを指定します。階層に対するフィルタの機能 ユーザ階層の作成と変更 183 5 Architect によるプロジェクトの作成 プロジェクト デザイン ガイド は、レポート内のフィルタと同様です。フィルタの基 準を満たすデータだけが表示されます（「階層内のア トリビュートのフィルタ処理」（312 ページ）を参 照）。 • エントリー ポイントに設定 : この階層のブラウズを、 このアトリビュートから開始できるかどうかを指定し ます（「エントリ ポイント」（313 ページ）を参照）。 • エレメント表示 : ユーザに表示されるエレメントを決 定します。エレメントの表示には、[ ロック済 ]、[ ロッ ク解除済 ]、[ 制限 ] の 3 種類があります（「アトリ ビュート エレメントの表示制御」（308 ページ）を参 照）。 11 [ 保存して閉じる ] をクリックします。 12 ユーザ階層は、どのフォルダにも保存できます。ただし、 データ エクスプローラでユーザ階層のエレメントをブラ ウズできるようにするには、ユーザ階層を階層フォルダ 内のデータ エクスプローラのサブフォルダに置く必要が あります。これについては、「レポートでの階層ブラウズ の有効化 : データ エクスプローラ」（318 ページ）で説明 します。 13 [ スキーマ ] メニューで、[ スキーマを更新 ] を選択します。 184 ユーザ階層の作成と変更 © 2010 MicroStrategy, Inc. 6 6. ビジネス データの構築ブ ロック : ファクト はじめに ファクトは、ビジネス データ モデルに不可欠な要素の 1 つ です。データ ウェアハウスから得られた数値データは、 ファクトによって MicroStrategy のレポーティング環境に関 連付けられます。ファクトは通常、ユーザがレポートに含め るビジネス上の質問への答えを表します。 MicroStrategy 環境におけるファクトは、MicroStrategy ユーザ によって作成され、共有されるスキーマ オブジェクトです。 MicroStrategy で作成するファクトによって、ユーザはデータ ウェアハウスに格納されているデータにアクセスします。 ファクトはメトリックの土台となります。メトリックは、 ユーザが MicroStrategy で作成できる大部分の分析とレポー トで使用されます。 ファクトとアトリビュートは、プロジェクトの定義に必要で す。MicroStrategy プロジェクトでは、ファクトは数値デー タ、アトリビュートはファクトのコンテキストに関するデー タです。たとえば、特定の店舗の 1 月の売上額を分析する場 合には、売上額がファクト、店舗と月がアトリビュートにな ります。プロジェクト デザイナは、プロジェクトをファク トとアトリビュートを含む形で作成する必要があります。そ © 2010 MicroStrategy, Inc. 185 6 ビジネス データの構築ブロック : ファクト プロジェクト デザイン ガイド れにより、ユーザはファクトとアトリビュートを、メトリッ クとレポートの構築ブロックとして使用できるようになりま す。 ファクトは、データ ウェアハウス内のファクト テーブル に 格納されます。ファクト テーブルは複数の異なる列から構 成されており、これらの列の個々のセルが特定の情報を表し ます。MicroStrategy でレポートのためにファクト情報が要求 されると、これらの列から必要な情報が取り込まれます。こ のデータは、ビジネスの評価基準となるメトリック（利益な ど）の作成に使用されます。 ファクトは次に示すように、データ ウェアハウス内の物理 列に基づいています。 186 © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド ビジネス データの構築ブロック : ファクト 6 アトリビュートなど他のスキーマ オブジェクトと同様、 ファクトは対応する物理的な列とテーブルを持つ MicroStrategy の論理オブジェクトです。アトリビュートとは 異なり、ファクトにはデータの説明はありません。ファクト は、特定のファクト レベルで格納されている実際のデータ 値です。ファクトの エントリ レベル とは、ファクトが格納 されている最低レベルのアトリビュート群のことです。 ファクトの作成はプロジェクトの新規作成の重要なステップ ですが、通常はプロジェクトのライフ サイクルの間にも、 ファクトの変更や作成が必要になります。これらのタスクの 実行手順については、この章の最初の項（「ファクトの作成」 （187 ページ））で説明します。第 2 項以降では、ファクトの 概念と、より高度ないくつかのファクト デザインの手法と 手順について説明します。 ファクトの作成 ファクトに対応する列には 2 つの特徴があります。1 つのは 数値であること、もう 1 つは集計可能であることです。ファ クトには、たとえば売上、販売台数、利益、経費などがあり ます。 データ ウェアハウスには、データの用途によって種類の異 なるファクトが含まれます。たとえば、"Tenure"（在職期 間）と "Compensation Cost"（報酬コスト）は、人事データを 格納したデータ ウェアハウスに含まれ、"Quantity"（数量） と "Item Cost"（品目原価）は、販売と流通のデータを格納し たデータ ウェアハウスに含まれます。 ファクトは、ほとんどすべてのメトリックの土台となるた め、ファクトの定義方法を理解することは重要です。ファク トによって、高度なメトリックの作成も可能になります。高 度なメトリックのデータはウェアハウスには格納されず、 ファクトを拡張することで呼び出し可能です。 この項では、プロジェクトのデザイン プロセスの複数の異 なる段階で、複数の異なる手法および MicroStrategy インタ フェースを使用して、ファクトを作成する手順を説明しま す。 © 2010 MicroStrategy, Inc. ファクトの作成 187 6 ビジネス データの構築ブロック : ファクト プロジェクト デザイン ガイド • 「複数の単純なファクトの同時作成」（188 ページ）では、 ファクト作成ウィザードを使用して、新規プロジェクト のデザイン段階およびプロジェクトのライフ サイクルの 途中で、複数の単純なファクトを作成する手順を示しま す。 新規プロジェクトのデザイン段階で Architect を使用し て、複数の単純な、または高度なファクトを作成するこ ともできます。これに関しては、「Architect による単純な ファクトと高度なファクトの作成および変更」（196 ペー ジ）で説明します。 • 「単純なファクトと高度なファクトの作成および変更」 （191 ページ）では、既存プロジェクトに単純なファクト や高度なファクトを追加する手順、および既存プロジェ クト内のこれらのファクトに変更を加える手順を説明し ます。 複数の単純なファクトの同時作成 新規プロジェクトのデザイン段階では、プロジェクト作成ア シスタント、ファクト作成ウィザード、および Architect を 使用して、複数の単純なファクトを作成できます。ただし、 ファクトの作成と変更は、プロジェクトのライフ サイクル のどの時点でも実行できます。ファクトは、MicroStrategy の 以下のツールを含む、さまざまな手法で作成および変更でき ます。 • ファクト作成ウィザード : 手順を段階的に実行するイン タフェース。通常、新規プロジェクトの作成時に使用し ます。このツールでは、一度の作成プロセスで複数の ファクトを作成できます。 プロジェクト作成アシスタントでは、新規プロ ジェクトの作成中に容易にファクトを作成できる ように、ファクト作成ウィザードを使用します。 ファクト作成ウィザードは、MicroStrategy Desktop の [ スキーマ ] メニューから開くこともできます。 • 188 ファクトの作成 ファクト エディタ : 既存のファクトに高度な機能を追加 したり、プロジェクトの進化に応じて単純なファクトや 高度なファクトを新規作成するために使用します。詳細 は、「単純なファクトと高度なファクトの作成および変 更」（191 ページ）で説明します。 © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド ビジネス データの構築ブロック : ファクト • 6 Architect: 単純なファクトや高度なファクトを、統合され た環境で視覚的に作成および変更できます。詳細は、 「Architect による単純なファクトと高度なファクトの作成 および変更」（196 ページ）で説明します。 ファクト作成ウィザードでファクトを作成するには この手順は、プロジェクト作成アシスタントで新規プロジェ クトを作成する際に、その一部として実行します。プロジェ クト作成アシスタントからファイル作成ウィザードを開き、 ファクト作成タスクを完了させます。プロジェクト作成ウィ ザードを開く方法については、「プロジェクト作成アシス タントで新規プロジェクトを作成するには」（86 ページ）を 参照してください。ファクト作成ウィザードは、 MicroStrategy Desktop の [ スキーマ ] メニューから開くことも できます。 1 プロジェクト作成ウィザードで [ ファクトを作成 ] を選択 します。次に示すファクト作成ウィザードが開きます。 2 [ 規則定義 ] をクリックし、ファクト作成の基本的な規則 をいくつか設定します。[ ファクト作成規則 ] ページが開 きます。 規則は、ファクト作成プロセスの自動化と管理に役立ち ます。ウェアハウス内の名前付け規則が [ ファクト作成 規則 ] ページのデフォルトに適合しない場合は、これら の規則を変更する必要があります。 © 2010 MicroStrategy, Inc. ファクトの作成 189 6 ビジネス データの構築ブロック : ファクト プロジェクト デザイン ガイド 3 [ 列データ タイプ ] 領域では、ファクト ID 列に使用可能 なデータ タイプを選択します。ウィザードがデータ ウェ アハウス内で利用可能な列を検索する際の検索対象に含 めるデータ タイプのチェック ボックスを選択します。 たとえば、[ 文字 ] と [ 数値 ] を選択し、残りのチェック ボックスをクリアすると、データ タイプが数値または文 字の列だけが、ファクトに使用できる列としてファクト 作成ウィザードに表示されます。 複数の説明情報列にアクセスできる大部分のアト リビュートとは異なり、ファクトには説明情報は ありません。したがって、ファクト ID 列のデー タ タイプだけを選択します。 4 [ ファクト名 ] 領域では、デフォルトのファクト名の作成 方法を指定できます。具体的には、ファクト名に含まれ る下線をスペースで置き換えるかどうか、および先頭文 字を大文字にするかどうかを指定します。適切なチェッ ク ボックスを選択して、デフォルトのファクト名の作成 方法を決定します。 5 [OK] をクリックして規則の変更を保存し、ファクト作成 ウィザードに戻ります。 ファクト列の選択 6 [ 次へ ] をクリックします。[ 列を選択 ] ページが開きます。 プロジェクトで現在使用されていない列のリストが、[ 利 用可能な列 ] ペインに表示されます。 7 [利用可能な列] ペインでファクトに使用する列を選択し、 [>] をクリックしてプロジェクトに追加します。[>>] を クリックすると、リストに含まれるすべての列を一度に 追加できます。 以下の点に注意してください。 190 ファクトの作成 – ファクトを右クリックして [ 名前の変更 ] を選択す れば、そのファクトの名前を、より分かりやすい ものに変更できます。 – ファクト作成ウィザードでは、同じ情報を保持し ている、名前の異なる複数の列（異種の列）には 対応できません。ファクトを異種の列にマップす る方法の詳細は、「名前の異なる列を使用するファ クト : 異種の列名」（203 ページ）を参照してくだ さい。 © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド ビジネス データの構築ブロック : ファクト 6 8 ファクト列をプロジェクトから削除するには、対象の各 ファクトを [ ファクト ] ペインで選択して [<] をクリック します。選択したすべてのファクトが左側のペインに移 動します。[<<] をクリックすると、プロジェクト内のす べてのファクトを一度に削除できます。 9 [ 次へ ] をクリックします。[ 終了 ] ページが開きます。 10 [ 終了 ] ページの要約情報を確認し、問題がなければ [ 終 了 ] をクリックしてファクトを作成します。 選択したファクトの定義がメタデータに格納されます。プロ ジェクト作成アシスタントでプロジェクト作成を継続するに は、「複数のアトリビュートの同時作成」（229 ページ）を参 照してください。 単純なファクトと高度なファクトの作成および変更 プロジェクトの作成後は、ファクト作成ウィザード、ファク ト エディタ、または Architect を使用して、そのプロジェク ト内にファクトを作成したり、プロジェクト内の既存ファク トに変更を加えることができます。 • Architect では、次のタスクを実行できます。 単純なファクトの作成 複数のファクトの迅速な作成 プロジェクトの作成中に多数のファクトを追加する 単純なファクトと高度なファクトの作成 既存のファクトの編集、その他のスキーマ レベルの 設定 Architect では、ファクト エディタで利用可能な、単純な ファクトおよび高度なファクトに関する全機能をサポー トしています。一度に 1 つのファクトを対象とするファ クト エディタとは異なり、Architect では 1 つのプロジェ クトを対象に、一度に複数のファクトを作成および変更 できます。Architect の使用方法の詳細は、「Architect によ る単純なファクトと高度なファクトの作成および変更」 （196 ページ）を参照してください。 © 2010 MicroStrategy, Inc. ファクトの作成 191 6 ビジネス データの構築ブロック : ファクト • プロジェクト デザイン ガイド ファクト作成ウィザードでは、次のタスクを実行できま す。 単純なファクトの作成 複数のファクトの迅速な作成 プロジェクトの作成中に多数のファクトを追加する ファクト作成ウィザードでは、複数のファクトを迅速か つ容易に作成できます。ただし、このウィザードの機能 は単純なファクトの作成に限定され、既存のファクトを 編集することはできません。通常、ファクト作成ウィ ザードを使用するのは、新規プロジェクトの作成中だけ であり、その際にプロジェクトの大部分のファクトを作 成します。ファイル作成ウィザードの使用手順は、「ファ クト作成ウィザードでの 1 つまたは複数の単純なファク トの作成」（192 ページ）を参照してください。 • ファクト エディタでは、次のタスクを実行できます。 単純なファクトと高度なファクトの作成 既存のファクトの編集、その他のスキーマ レベルの 設定 ファクト エディタでは、既存ファクトの編集、ファクト 式と列別名の作成、レベル拡張、複数の（または異種の） 列へのマッピング、およびその他の設定を行うことがで きます。ファクト エディタでは一度に 1 つのファクトを 編集します。これは、プロジェクト内で変更が必要な ファクト数が限られているときに役立ちます。ファクト エディタの使用手順については、「ファクト エディタで の単純なファクトと高度なファクトの作成」（193 ペー ジ）および「ファクト エディタでの単純なファクトと高 度なファクトの変更」（196 ページ）を参照してくださ い。 ファクト作成ウィザードでの 1 つまたは複数の単純 なファクトの作成 ファクト作成ウィザードは主に、新規プロジェクトの作成中 に大部分のファクトを作成するために使用されますが、プロ ジェクト作成後に適宜、1 つまたは複数の単純なファクトを 作成するためにも使用できます。 192 ファクトの作成 © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド ビジネス データの構築ブロック : ファクト 6 ファクト作成ウィザードでファクトを作成するには 1 MicroStrategy Desktop で、対象のプロジェクトを含むプ ロジェクト ソースにログインし、そのプロジェクトを展 開します。 権限があるログインを使用する必要があ Architect ります。権限の詳細については、『MicroStrategy シ ステム管理ガイド』の「許可と権限」を参照して ください。 2 MicroStrategy Desktop のフォルダ リストで、ファクトを 追加するプロジェクトを選択します。 3 [ スキーマ ] メニューで、[ ファクト作成ウィザード ] を選 択します。ファクト作成ウィザードが開きます。 ファクト作成ウィザードでファクトを追加するには、 「ファクト作成ウィザードでファクトを作成するには」 （189 ページ）に示す手順に従います。 ファクト エディタでの単純なファクトと高度な ファクトの作成 ファクト エディタでは、プロジェクトの拡張に合わせて ファクトを追加したり、既存のファクトに変更を加えること ができます。ファクト エディタでは、ファクトに拡張を追 加したり、ファクトの追加設定を行うことも可能で、さまざ まな分析上のニーズに対応できます。 テーブル内の 1 つのファクト列を基に、ファクト エディタ で単純なファクトを作成する手順を次に示します。 ファクト エディタで単純なファクトを作成するには 1 MicroStrategy Desktop で、対象のプロジェクトを含むプ ロジェクト ソースにログインし、そのプロジェクトを展 開します。 権限があるログインを使用する必要があ Architect ります。権限の詳細については、『MicroStrategy シ © 2010 MicroStrategy, Inc. ファクトの作成 193 6 ビジネス データの構築ブロック : ファクト プロジェクト デザイン ガイド ステム管理ガイド』の「許可と権限」を参照して ください。 2 MicroStrategy Desktop のフォルダ リストで、ファクトを 追加するプロジェクトを選択します。 3 [ ファイル ] メニューから [ 新規作成 ]、[ ファクト ] の順に 選択します。ファクト エディタが開き、[ 新規ファクト 式の作成] ダイアログ ボックスが最前面に表示されます。 4 [ ソース テーブル ] ドロップダウン リストから、作成する ファクトのソース テーブルを選択します。 テーブルとは、作成するファクトの元にな ソース るファクト列を含むテーブルまたは論理表示のこ とです。 5 [ 利用可能な列 ] ペインから列をドラッグし、[ ファクト 式 ] ペインにドロップします。 複数の列を含めることが可能で、数値定数、数学演算子、 および関数を使用してファクト式を作成できます。さま ざまな種類のファクト式の作成方法については、「物理列 のファクトへのマッピング : ファクト式」（199 ページ） を参照してください。 6 [ マッピング ] 領域で [ 自動 ] または [ 手動 ] を選択します。 194 ファクトの作成 • 自動マッピングでは、ファクト式で列が使用されてい るプロジェクト内の全テーブルが、ファクトの利用可 能なソース テーブルとして選択されます。その後、 自動マッピングされたすべてのテーブルを削除し、他 のテーブルを選択することもできます。 • 手動マッピングでも、ファクト式で列が使用されてい るプロジェクト内の全テーブルが見つけられますが、 ファクトの利用可能なソース テーブルとして自動選 択されることはありません。その後、ファクトのソー ス テーブルとして使用するテーブルを手動で選択し ます。手動マッピングは、次のような状況で使用しま す。 – プロジェクト テーブル内の物理列に基づかない定 数式を作成している場合は、定数式を適用する テーブルを手動で選択する必要があります。 – 複数のテーブルに存在する同じ名前の列に含まれ るデータが共通でない場合。ファクトごとに適切 © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド ビジネス データの構築ブロック : ファクト 6 なソース テーブルを手動で選択する必要がありま す。 たとえば、Sales という名前の列が Fact_Sales テーブルと Fact_Discount テーブルの両方に存 在するとします。Fact_Sales テーブル内の Sales 列には売上データが格納されています。一 方、Fact_Discount テーブル内の Sales 列には ディスカウント売上データが格納されています。 言い換えれば、どちらのテーブルでも列の名前は 同じ（Sales）ですが、これらの列にはテーブル ごとに異なるファクト データが格納されていま す。"Revenue"（売上）ファクトを作成するときに は、"Revenue" ファクトのソース テーブルとして Fact_Sales テーブルを選択するために手動マッ ピングを使用する必要があります。"Discount" （ディスカウント売上）ファクトを作成するときに も、"Discount" ファクトのソース テーブルとして Fact_Discount を選択できるように、手動マッ ピングを使用しなければなりません。どちらの場 合も自動マッピングを使用すると、MicroStrategy SQL Engine が正しくない列をファクトに使用する 可能性があります。 7 [OK] をクリックして [ 新規ファクト式の作成 ] ダイアロ グ ボックスを閉じます。 8 次に説明するように、ファクト エディタのタブを使用し てファクト式を定義し、列別名を作成して拡張を作成し ます。 エディタの各タブにあるオプションの詳 ファクト 細については、MicroStrategy Desktop オンライン ヘルプを参照してください。 © 2010 MicroStrategy, Inc. • 定義 : このタブでファクト式を定義します。ファクト の定義については、「ファクトの定義」（198 ページ） で説明します。 • 列別名 : このタブでファクトの列別名を作成します。 列別名については、「ファクト列の名前とデータ タイ プ : 列別名」（206 ページ）で説明します。 • 拡張 : このタブでファクト レベル拡張を作成します。 ファクトの拡張については、「ファクトがレポートさ れるレベルの変更 : レベル拡張」（208 ページ）で説 明します。 ファクトの作成 195 6 ビジネス データの構築ブロック : ファクト プロジェクト デザイン ガイド 9 必要な変更が完了したら、[ 保存して閉じる ] をクリック します。 10 [ 名前を付けて保存 ] ダイアログ ボックスで、ファクトを 保存する場所まで移動します。ファクトの名前を入力し、 [ 保存 ] をクリックします。ファクトが保存され、ファク ト エディタが閉じます。 11 [ スキーマ ] メニューで [ スキーマを更新 ] を選択し、プロ ジェクト スキーマを更新します。 ファクト エディタでの単純なファクトと高度な ファクトの変更 ファクト エディタで既存のファクトを変更するには 1 MicroStrategy Desktop で、変更するファクトを含んでい るフォルダを開きます。 2 ファクトをダブルクリックしてファクト エディタを開 き、ファクトを編集します。 より高度なファクトの作成方法については、以下の複数の項 で説明します。 Architect による単純なファクトと高度なファクト の作成および変更 Architect では、単純なファクトや高度なファクトを、統合さ れた環境で視覚的に作成および変更できます。テーブル、ア トリビュート、アトリビュート関係、ファクト、ユーザ階 層、およびその他のプロジェクト オブジェクトを、プロ ジェクトをデザインしながら視覚的に確認できます。 Architect では、ファクト エディタで利用可能な、単純な ファクトおよび高度なファクトに関する全機能をサポートし ています。一度に 1 つのファクトを対象とするファクト エ ディタとは異なり、Architect では 1 つのプロジェクトを対象 に、一度に複数のファクトを作成および変更できます。 Architect に関する情報と、Architect でファクトを作成および 変更する手順については、次の章と項を参照してください。 196 ファクトの作成 © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド ビジネス データの構築ブロック : ファクト • 6 5 章、 「Architect によるプロジェクトの作成」 • 「プロジェクトの作成と変更」（104 ページ） • 「ファクトの作成と変更」（136 ページ） ファクトの構造 次の図に示すように、ファクトは以下のコンポーネントから 構成されています。 © 2010 MicroStrategy, Inc. • ファクト定義 : 1 つ以上のファクト式から構成されます。 すべてのファクトに式が 1 つ以上必要です。ファクト定 義の詳細は、「ファクトの定義」（198 ページ）で説明し ます。 • 列別名 : ファクトに関係する一時テーブルの作成時に、 MicroStrategy によって SQL ステートメントの生成に使用 される列名を格納します。すべてのファクトに、列別名 が 1 つ必要です。列名を新規作成しない場合は、ファク トの種類に基づき、デフォルトの列別名が MicroStrategy によって選択されます。列別名については、「ファクト列 の名前とデータ タイプ : 列別名」（206 ページ）で詳しく 説明します。 ファクトの構造 197 6 ビジネス データの構築ブロック : ファクト • プロジェクト デザイン ガイド ファクト レベル拡張 : データ ウェアハウス内の特定レベ ルに格納されているファクトを、無関係なレベルのレ ポートに含めることができます。また、特定レベルに格 納されているファクトを、そのレベルのレポートから除 外することもできます。レベル拡張は、高度なデータ モ デルのシナリオで非常に効果的です。レベル拡張につい ては、 「ファクトがレポートされるレベルの変更 : レベル 拡張」（208 ページ）で詳しく説明します。 MicroStrategy Desktop では、ファクトの作成にはファクト作 成とファクト エディタを使用します。ファイル作成ウィ ザードでのファクトの作成中に、ファクトの表現に使用され る数値列を選択すると、ファクト定義と列別名が自動的に定 義されます。レベル拡張はオプションです。 ファクトの作成に使用されるツールとその使用手順について は、「ファクトの作成」（187 ページ）を参照してください。 ファクトの定義 ファクト定義には、ファクトとそのコンポーネントを定義す るプロパティが含まれています。ファクト定義は、少なくと も 1 つのファクト式と、ファクトに関する基本情報（ファク ト名、式、使用するソース テーブルなど）から構成されま す。 次の表にファクト定義の一例を示します。この定義には、 ファクト名、式、およびソース テーブルが含まれています。 ファクト名 式 Unit Price （単価） All_Sales ソース テーブル LU_ITEM ORDER_DETAIL この例では、ファクト式によってファクトがウェアハウス内 の LU_ITEM テーブルと ORDER_DETAIL テーブルにある All_Sales 列にマップされます。この定義に含まれるファ クト式は、ファクトが MicroStrategy でどのように計算され るかを表します。この例のファクト式は、データのデータを 格納している列の名前です。ただし、ファクトによっては、 複数の列のデータを対象に計算を実行して 1 つのファクトを 返す、より高度な式が使用されることもあります。 198 ファクトの定義 © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド ビジネス データの構築ブロック : ファクト 6 ファクトはウェアハウス スキーマ内の複数のテーブルに存 在する場合があり、通常はテーブルごとに計算も異なりま す。"Unit Price" ファクトの式は 1 つだけですが、1 つのファ クト定義には複数の式を含めることができます。 以下の点に注意してください。 • 個々のファクト式は、ファクトを含む 1 つ以上の 関連するテーブルを対象とします。 • ファクト式は、ファクトがどのように計算される かをテーブルごとに定義します。 物理列のファクトへのマッピング : ファクト式 ファクト式 は、ファクトをウェアハウス内の物理列にマッ プします。ファクト式はウェアハウスから取り込んだファク ト列の名前のように単純な場合もあれば、複数のファクト列 名と数値定数を含む式のように複雑な場合もあります。ファ クト式は、その定義に関わらず、ウェアハウス内の特定の ファクト情報へのマッピングを表します。ファクト定義に は、1 つまたは複数のファクト式が必要です。 次の図は、ファクト テーブル内の列と、関連するファクト 式を示しています。 有効なファクト式は、常にファクト列を含み、数値定数や数 学演算子を含む場合もあります。ファクト式では次の数学演 算子が使用可能です。 © 2010 MicroStrategy, Inc. • 加算（+） • 減算（-） • 乗算（*） • 除算（/） ファクトの定義 199 6 ビジネス データの構築ブロック : ファクト プロジェクト デザイン ガイド ファクト式の作成には、ファクト エディタを使用します。 この手順は、「単純なファクトと高度なファクトの作成およ び変更」（191 ページ）で説明しています。 ApplySimple 関数を使用して定義できま ファクトは す。各種の Apply 関数は、『MicroStrategy 上級レポー ティング ガイド』の付録「パススルー式」で説明さ れています。 ファクトの多くは、データ ウェアハウス内の物理列を表し ます。ただし、ウェアハウス内に存在せず、以下の項で説明 するように、別の方法で定義されるファクトもあります。 暗黙のファクトと暗黙のファクト式 暗黙のファクトとは、データベース内に物理的に存在しな い、仮想のまたは一定のファクトのことです。暗黙のファク トは、データの呼び出し先のファクト テーブルを示します。 暗黙のファクトは式を定数値として定義できますが、テーブ ル列には何も保存されません。 たとえば、暗黙のファクト式を使用して、すべての行の値が 「1」の「一時列」をデータベース内に作成すれば、特定のア トリビュートで返される行数を知ることができます。暗黙の ファクトはメトリックの作成時に、定数列の値を合計して回 数を計算する手段としても役立ちます。たとえば、Sum(1) として定義されるメトリックを作成する場合は、定数「1」 と等しいファクトを定義できます。メトリックの詳細につい ては、『MicroStrategy 上級レポーティング ガイド』を参照し てください。 派生ファクトと派生ファクト式 派生ファクトとは、テーブル内の 1 つの列より多くの要素を 含む式によって値が決定されるファクトのことです。定数の 追加、他の列の値の追加、式の絶対値設定など、列に対する あらゆる操作が派生ファクトを生成します。言い換えれば、 データ ウェアハウス内で利用可能な情報からファクトを作 200 ファクトの定義 © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド ビジネス データの構築ブロック : ファクト 6 成することです。たとえば、データ ウェアハウス内のテー ブルに、次の要素が含まれているとします。 Fact Table 1 Item Quarter Quantity_Sold Price この場合、次の派生ファクトを作成することにより、新しい ファクト "Sales"（売上）が得られます。 Sales = Quantity_Sold * Price 派生ファクトを作成する利点の 1 つは、複数のテーブルから 中間的なファクトを複数呼び出す代わりに、1 つのファクト をプロジェクト内に一貫して保持できることです。1 つの ファクトを使用することで格納領域が節約され、クエリで使 用される SQL の受け渡し回数も少なくなります。 派生ファクトを作成する代わりに、MicroStrategy でメトリッ クを使用して同様の分析を作成することもできます。メト リックでは、ファクト データの計算と集計を実行できます。 メトリックの説明と作成方法については、『MicroStrategy 上 級レポーティング ガイド』を参照してください。 例 : 派生ファクトの作成 MicroStrategy Tutorial の "Cost"（経費）ファクトには、派生 ファクト式 Qty_Sold * Unit_Cost が含まれています。 この式は、商品の販売数量に関するデータと、単位原価に関 するデータを含む列を掛け合わせることで、ビジネスに役立 つ計算ができることを示唆しています。この例では、「顧客 への販売数量に占める合計原価はいくらになるのか」という ビジネス上の計算に答えるために、これらの列が使用されま す。 上記の派生ファクト式を使用する派生ファクトの作成手順を 以下に示します。派生ファクト式を使用する派生ファクトは Architect でも作成できます。手順については、「派生ファク トとファクト式の作成」（144 ページ）で説明します。 © 2010 MicroStrategy, Inc. ファクトの定義 201 6 ビジネス データの構築ブロック : ファクト プロジェクト デザイン ガイド 派生ファクトを作成するには 1 MicroStrategy Desktop で MicroStrategy Tutorial プロジェク トにログインします。 2 [My Personal Objects] フォルダに移動し、[My Objects] フォルダを開きます。 3 [ ファイル ] メニューから [ 新規作成 ] を選択し、[ ファク ト ] を選択します。ファクト エディタが開き、[ 新規ファ クト式の作成 ] ダイアログ ボックスが最前面に表示され ます。 4 [ ソース テーブル ] ドロップダウン リストから ORDER_DETAIL テーブルを選択します。 5 [ 使用可能な列 ] ペインで QTY_SOLD 列をダブルクリッ クし、右側の [ ファクト式 ] ペインに追加します。 派生ファクト式を完成させるには 派生ファクト式には、列、数値定数、および数学演算子 の組み合わせが含まれます。以下のステップではシナリ オの例に従って、派生ファクト式の作成方法のガイドラ インを示します。 6 カーソルを [ ファクト式 ] ペイン内に置いた状態で、[*] （乗算演算子）をクリックして、その演算子を式に追加し ます。 7 [ 使用可能な列 ] ペインで UNIT_PRICE 列をダブルクリッ クし、ファクト式の末尾に追加します。 8 [ マップ方法 ] で [ 自動 ] を選択します。 9 [ 検証 ] をクリックし、式の構文が正しいかどうかを チェックします。式は次のように表示されるはずです。 202 ファクトの定義 © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド ビジネス データの構築ブロック : ファクト 6 10 [OK] をクリックします。派生ファクト式がファクト エ ディタの [ ファクト式 ] ペインに表示されます。 11 [ ファイル ] メニューから、[ 名前を付けて保存 ] を選択し ます。[ 名前を付けて保存 ] ダイアログ ボックスが開きま す。 12 派生ファクトの名前を入力して [ 保存 ] をクリックしま す。 13 プロジェクトのファクトを作成している場合は、この時 点でプロジェクト スキーマを更新する必要があります。 この手順の場合は例に過ぎないため、スキーマの更新は 必要ありません。 名前の異なる列を使用するファクト : 異種の列名 ウェアハウス内では、1 つのファクトが名前の異なる複数の 列にアクセスする場合があります。次の例では、ウェアハウ ス内の 2 つのファクト テーブルに、ドル単位の売上額を含 む列があります。テーブル 1 には "Dollar_Sales" ファク トが含まれており、テーブル 2 には "Dollar_Sls" ファク トが含まれています。これらの項目は、どちらも同じ情報を 表しています。 Table 1 Table 2 Year Dollar_Sales Month Dollar_Sls MicroStrategy では、ファクトごとに異種のファクト列名を識 別することができます。異種の列名により、複数のテーブル に存在し、名前が異なり、量的に同じ値を含む複数の列を 1 つのファクトから参照できます。 上の例では、ドル単位の売上額の異種のファクト列名を作成 することで、Dollar_Sales 列と Dollar_Sls 列が同じ ファクトを表していることをシステムに通知します。この情 報をメトリックを使用してレポート内で呼び出すと、両方の ファクト列が SQL で使用され、ファクトがレポートに正し く表示されます。 © 2010 MicroStrategy, Inc. ファクトの定義 203 6 ビジネス データの構築ブロック : ファクト プロジェクト デザイン ガイド 例 : 異種のファクト列のマッピング MicroStrategy Tutorial の "Units Sold"（売上数量）ファクト は、ウェアハウス内の 2 つのファクト列（Qty_Sold、 Tot_Unit_Sales）から構成されています。これらのファ クト列は互いに異なる名前で、異なるテーブル内に存在して いますが、どちらも同じデータを表しているため、両方が "Unit Sold" ファクトにマップされます。 正確で欠落のないデータがレポートに表示されるように、異 種のファクト列は対応するファクトにマップする必要があり ます。 MicroStrategy Tutorial に含まれている "Units Sold" ファクトの 作成手順を以下に示します。この手順では、"Units Sold" ファクトを作成して、それを対応する異種のファクト列に マップします。異種のファクト列名を持つファクトは Architect でも作成できます。この手順は、「名前の異なる列 を使用したファクトの作成 : 異種の列名」（146 ページ）で 説明しています。 異種の列名を持つファクトを作成するには 1 MicroStrategy Desktop で MicroStrategy Tutorial プロジェク トにログインします。 2 [My Personal Objects] フォルダに移動し、[My Objects] フォルダを開きます。 3 [ ファイル ] メニューから [ 新規作成 ] を選択し、[ ファク ト ] を選択します。ファクト エディタが開き、[ 新規ファ クト式の作成 ] ダイアログ ボックスが最前面に表示され ます。 4 [ ソース テーブル ] ドロップダウン リストから ORDER_FACT テーブルを選択します。これは、"Units Sold" ファクトの異種のファクト列を含むテーブルの 1 つ です。 5 [ 使用可能な列 ] ペインで QTY_SOLD 列をダブルクリッ クし、右側の [ ファクト式 ] ペインに追加します。 6 [ マップ方法 ] 領域で [ 自動 ] を選択します。 204 ファクトの定義 © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド ビジネス データの構築ブロック : ファクト 6 7 [OK] をクリックします。ファクト エディタが開き、作 成したファクト式が [ ファクト式 ] ペインに表示されま す。 続いて、異種のファクト列を "Units Sold" ファクトの別の 式として追加する必要があります。 8 [ 新規作成 ] をクリックします。[ 新規ファクト式の作成 ] ダイアログ ボックスが開きます。 9 [ ソース テーブル ] ドロップダウン リストから CITY_CTR_SALES テーブルを選択します。これは、 "Units Sold" ファクトの異種のファクト列を含む、もう 1 つのテーブルです。 10 [ 使用可能な列 ] ペインで TOT_UNIT_SALES 列をダブル クリックし、右側の [ ファクト式 ] ペインに追加します。 11 [ マップ方法 ] 領域で [ 自動 ] を選択します。 12 [OK] をクリックします。ファクト エディタが開き、作 成したファクト式が [ ファクト式 ] ペインに表示されま す。これで、作成している "Units Sold" ファクトが、異種 のファクト列に正しくマップされます。 13 [ ファイル ] メニューから、[ 名前を付けて保存 ] を選択し ます。[ 名前を付けて保存 ] ダイアログ ボックスが開きま す。 14 新しいファクトの名前を入力し、[ 保存 ] をクリックしま す。 15 プロジェクトのファクトを作成している場合は、この時 点でプロジェクト スキーマを更新する必要があります。 この手順の場合は例に過ぎないため、スキーマの更新は 必要ありません。 © 2010 MicroStrategy, Inc. ファクトの定義 205 6 ビジネス データの構築ブロック : ファクト プロジェクト デザイン ガイド ファクト列の名前とデータ タイプ : 列別名 列別名 は、一時テーブル内で使用される列の名前と、ファ クトに使用されるデータ タイプの両方を指定します。 デフォルトでは、ファクトのデータ タイプは、データ ウェ アハウス内でそのファクトが定義されている列のデータ タ イプを継承します。ただし、これには変更が必要になる場合 もあります。 たとえば、2 つの日付間の日数をファクトとして定義して、 開始日から終了日までの平均日数を計算する場合、このファ クトは次の式で作成できます。 ApplySimple("DateDiff(day,#0, #1)", [Start_Date_Id], [End_Date_Id]) 式の構文は、データベースの種類により異なります。 これは Microsoft SQL Server 特有の構文であり、実際 に作成する SQL とは異なる場合があります。 このファクトのデータ タイプは、Start_Date_ID と End_Date_ID が Date データ タイプであるため、自動的に Date に設定されます。ところが、計算結果は 2 つの日付間 の日数であり、整数になります。 206 ファクト列の名前とデータ タイプ : 列別名 © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド ビジネス データの構築ブロック : ファクト 6 これは、計算のために一時 SQL テーブルを作成する必要が ある場合に使用されます。列別名のデータ タイプを変更し ないと、システムは Date データ タイプを使用し、この列に 整数データを挿入しようとします。その結果、データベース プラットフォームによってはエラーになることがあります。 データ タイプの不一致によるエラーを回避するには、この ファクトの列別名のデータ タイプを、デフォルトの Date か ら Integer に変更する必要があります。 ファクト エディタを使用して列別名を作成する手順を以下 に示します。列別名は Architect で作成することもできます。 手順は「ファクトの列名とデータ型の作成および変更 : 列別 名」（148 ページ）で説明しています。 前提条件 この手順は、有効なファクト式を持つファクトが作成済み で、そのファクトに列別名を新規作成する場合を想定してい ます。 ファクトの列別名を作成するには 1 MicroStrategy Desktop で、新しい列の別名を作成する ファクトを含むプロジェクト ソースにログインします。 2 ファクトを右クリックし、[ 編集 ] を選択します。ファク ト エディタが開きます。 3 [ 列別名 ] タブを選択します。 4 [ 列別名 ] 領域で [ 変更 ] をクリックします。[ 列エディタ 列を選択 ] ダイアログ ボックスが開きます。 5 [ 新規作成 ] を選択して新しい列別名を作成します。[ 列エ ディタ - 定義 ] ダイアログ ボックスが開きます。 6 列別名の次のプロパティを変更できます。 © 2010 MicroStrategy, Inc. • 列名 : このファクト列を含む SQL ステートメントで 使用される列の別名。 • データ タイプ : ファクトのデータ タイプ。 MicroStrategy でサポートされているデータ タイプに ついては、「データ タイプ」（441 ページ）を参照して ください。 ファクト列の名前とデータ タイプ : 列別名 207 6 ビジネス データの構築ブロック : ファクト • プロジェクト デザイン ガイド 選択するデータ タイプによっては、列別名のバイト 長、ビット長、精度、スケール、またはタイム ス ケールを指定できます。これらの各プロパティの詳細 については、MicroStrategy Desktop オンライン ヘルプ を参照してください。 7 [OK] をクリックして変更を保存し、[ 列エディタ - 列を 選択 ] ダイアログ ボックスに戻ります。 8 [OK] をクリックして変更を保存し、ファクト エディタ に戻ります。 9 [ 保存して閉じる ] を選択して変更を保存します。 ファクトがレポートされるレベルの変更 : レベル拡張 ファクトは、ウェアハウス内の特定のビジネス レベルに格 納されます。ファクトのレベルは、テーブル内に存在するア トリビュート ID によって定義されます。たとえば、次に示 すファクト テーブルには、"Item"（商品）、"Quarter"（四半 期）など複数のアトリビュート ID が含まれています。これ らのアトリビュート ID は、ファクトがデフォルトでは商品 や四半期のレベルでレポートされることを示唆しています。 Fact Table 1 Item Quarter Quantity_Sold Price レベル拡張は、データ ウェアハウス内の特定レベルに格納 されているファクトを、別のレベルでレポートするときに必 要になります。すべてのファクトは複数のアトリビュートに 関連付けられていますが、それらのアトリビュートでユーザ のレポート ニーズがすべて満たされるとは限りません。 ファクト拡張が必要になるのは、レポートに含まれるアトリ 208 ファクトがレポートされるレベルの変更 : レベル拡張 © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド ビジネス データの構築ブロック : ファクト 6 ビュートとファクトとの間に、直接的にも間接的にも関係が 存在しない場合です。 ファクトのエントリ レベルが階層の最下位レベルの場合は、 その階層内で上位の特定レベルにある全アトリビュートが、 レベル拡張なしで利用可能です。たとえば、" 時間 " 階層内 の " 日 " アトリビュート レベルに " 経費 " ファクトがある場 合、MicroStrategy では " 年 " アトリビュート レベルの " 経費 " ファクトのデータを集計できます。これは " 年 " アトリ ビュートが " 日 " アトリビュートと同じ階層内で、より上位 レベルにあるからです。ただし、ファクトのエントリ レベ ルと同じ階層内で、より下位のレベルにあるアトリビュート とファクトを関連付ける場合は、ファクトのレベル拡張が必 「ファクト データのレベルの低下 : ファクト 要になります（ 分解」（219 ページ）を参照）。 レベル拡張は、ファクトのレベルを変更し、完全に異なる階 層内のレベルにファクト レベルを拡張するために使用でき ます。たとえば、" ディスカウント " ファクトを " 商品 / 日 " レベルでレポートする場合、ディスカウントは特定の日に特 定商品に適用されます。ディスカウント販売している商品数 が特に多いコール センタがないかどうかを確認するには、" ディスカウント " ファクトのレベルを、別の階層内のアトリ ビュートである " コール センタ " のレベルに拡張する必要が あります。 © 2010 MicroStrategy, Inc. ファクトがレポートされるレベルの変更 : レベル拡張 209 6 ビジネス データの構築ブロック : ファクト プロジェクト デザイン ガイド レベル拡張は、ファクトをどのように拡張し、下位レベルに 関連付け、スキーマ内の他のアトリビュートへの関連付けを 禁止するかを定義します。レベル拡張を作成することによ り、特定のレベルで取得されたファクトやアトリビュート を、レポート ニーズに応じて他のレベルに拡張できます。 レベル拡張は、ファクト定義や列別名のように必須ではな く、特定のケースだけで使用される傾向があります。 ファクトを含むメトリックで、アトリビュートのエントリ レベルとは異なる（または関係しない）レベルにあるアトリ ビュートを扱うには、そのファクトのレベル拡張を定義する 必要があります。ファクトが格納されているレベルと、レ ポート内のアトリビュートとの間に関係がない場合、ファク トのデータをそのアトリビュートに関連付けるには、レベル 拡張が不可欠です。レベル拡張が存在しないと、ファクトの データとアトリビュートを関連付ける手段がありません。 ファクト レベル拡張は、次に挙げるいずれかの方法で作成 できます。 • 「テーブル関係を使用したファクト テーブル上の結合の 定義」（211 ページ） • 「ファクト関係を使用したファクト テーブル上の結合の 定義」（215 ページ） • 「ファクトの強制的なアトリビュートへの関連付け : 直積 結合」（217 ページ） • 「ファクト データのレベルの低下 : ファクト分解」（219 ページ） • 「特定レベルでのファクトのレポート禁止」（223 ページ） これらの方法については、ファクト エディタのレベル拡張 ウィザードのオンライン ヘルプで詳しく説明されています。 ファクト レベル拡張の作成には、ファクト エディタを使用 します。 210 ファクトがレポートされるレベルの変更 : レベル拡張 © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド ビジネス データの構築ブロック : ファクト 6 テーブル関係を使用したファクト テーブル上の結合の定義 テーブル関係は、テーブル上に結合を定義します。ファクト と結合するテーブルを指定すると、ファクトを拡張するテー ブル関係が作成されます。ファクト拡張は、ファクト テー ブルによってファクトをアトリビュートに関連付けるために 使用できます。テーブルにはエントリ レベルのアトリ ビュートと、拡張先のアトリビュートが含まれるため、この 結合が重要になります。 たとえば、MicroStrategy Tutorial プロジェクトに含まれてい る "Freight"（運送費）メトリックには、"Item"（商品）アト リビュートへのテーブル関係ファクト拡張があります。運送 費を定義している ORDER_FACT テーブルには "Item" アトリ ビュートの ID 列が存在しないため、"Freight" ファクトを "Item" のレベルでレポートすることはできません。注文に含 まれる商品別の運送費をレポートに表示するには、ファクト 拡張が必要です。この例では次の理由により、"Freight" ファ クトの "Item" への拡張に ORDER_DETAIL テーブルを使用し ます。 1 ORDER_FACT テーブルと ORDER_DETAIL テーブルは、 どちらも互いを結合する "Order"（注文）アトリビュート の ID 列を含んでおり、さらに ORDER_DETAIL にはファ クトを "Item" に拡張する "Item" アトリビュートの ID 列 が含まれています。 2 "Freight" ファクトを "Item" 情報を含むテーブルに単純に 結合して、商品別の正しい運送費を得ることはできま せん。"Freight" を "Item" レベルに拡張するには割り当て 式が必要です。ORDER_FACT テーブルと ORDER_DETAIL テーブルには、"Order" レベルの "Units Sold"（売上数量）列と "Item" レベルの "Units Sold" 列が それぞれ含まれていることに着目してください。以下の 手順では、これら 2 つの列を使用してファクト式を割り 当てます。 以下の手順では、Tutorial プロジェクトの "Freight" ファクト 用に作成されたファクト拡張の作成方法を、順を追って説明 します。さらに、プロジェクトのファクトに使用できるファ クト拡張の作成の全般的なガイドラインも示します。 © 2010 MicroStrategy, Inc. ファクトがレポートされるレベルの変更 : レベル拡張 211 6 ビジネス データの構築ブロック : ファクト プロジェクト デザイン ガイド テーブル関係を使用してファクト拡張を定義するには 1 Desktop で MicroStrategy Tutorial プロジェクトにログイン します。 2 Facts フォルダに移動して "Freight" ファクトをダブルク リックします。ファクト エディタが開きます。 3 [ 拡張 ] タブをクリックします。 4 [ 商品の拡張 ] を選択して [ 変更 ] をクリックします。レベ ル拡張ウィザードが開きます。 [ 新規作 ファクト拡張を新規作成する場合は通常 成 ] をクリックしますが、この例では [ 商品の拡張 ] で "Freight" ファクト拡張がどのように作成された かを、順を追って示します。 5 [ ようこそ ] のメッセージを確認してから、[ 次へ ] をク リックします。[ 概要 ] ページが開きます。 ファクト エントリ レベルを低下、拡張、または禁止するには 6 ファクト拡張の名前と説明を入力します（この例では入 力済みです）。続いて、次のいずれかの操作を選択しま す。 • ファクト エントリ レベルを下げる : ファクト分解を 定義します（「ファクト データのレベルの低下 : ファ クト分解」（219 ページ）を参照）。 • ファクト エントリ レベルを拡張 : テーブル関係、動 的ファクト関係、または直積結合を使用してファクト 拡張を定義します。 • ファクト エントリ レベルを部分的または完全に禁 止 : 特定レベルでのファクトのレポートを禁止する ファクト拡張を定義します（「特定レベルでのファク トのレポート禁止」（223 ページ）を参照）。 この例ではテーブル関係を使用してファクト拡張を作成 するため、[ ファクト エントリ レベルを拡張 ] を選択して [ 次へ ] をクリックします。[ 拡張したアトリビュート ] ページが開きます。 212 ファクトがレポートされるレベルの変更 : レベル拡張 © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド ビジネス データの構築ブロック : ファクト 6 ファクトの拡張先アトリビュートを選択するには 7 ファクトを別のレベルでレポートできるように、ファク トの拡張先アトリビュートを選択します。この例では "Item" が選択されています。[ 次へ ] をクリックします。 [ 拡張タイプ ] ページが開きます。 階層内のどのレベルでもレポートできるように ファクトを拡張するには、階層の最下位レベルに あるアトリビュートを選択します。 ファクト拡張の種類を選択するには 8 次のいずれかのファクト拡張方法を選択します。 • ファクト拡張に使用する関係テーブルを指定 : 関係 テーブルを選択してアトリビュートを結合します。 • 関係テーブルを動的に選択 : ファクトを選択してアト リビュートを結合します。このオプションでは MicroStrategy Engine によってファクトを含むテーブ ルが選択され、指定したアトリビュートが自動的に結 合されてファクト拡張が作成されます（「ファクト関 係を使用したファクト テーブル上の結合の定義」 （215 ページ）を参照）。 • 直積拡張を実行 : 直積結合を適用します（「ファクト の強制的なアトリビュートへの関連付け : 直積結合」 （217 ページ）を参照）。 この例では [ ファクト拡張に使用する関係テーブルを指 定 ] を選択し、[ 次へ ] をクリックして、テーブル関係を使 用したファクト拡張の定義を続行します。[ テーブル選 択 ] ページが開きます。 テーブルを選択し、アトリビュートを結合して割り当て式を 定義するには 9 ファクトを新しいレベルに拡張するために使用するテー ブルを選択します。この例では、ORDER_DETAIL テーブ ルが選択されています。[ 次へ ] をクリックします。[ 結合 タイプ ] ページが開きます。 © 2010 MicroStrategy, Inc. ファクトがレポートされるレベルの変更 : レベル拡張 213 6 ビジネス データの構築ブロック : ファクト プロジェクト デザイン ガイド 10 結合に使用するアトリビュートを Intelligence Server に動 的に選択させるか、手動で選択するかを指定します。こ の例では ORDER_FACT テーブルと ORDER_DETAIL テー ブルを "Order" アトリビュートを使用して結合するため、 "Order" を選択して [ 次へ ] をクリックします。[ 結合アト リビュートの方向 ] ページが開きます。 11 選択したアトリビュートを使用して結合するか、アトリ ビュートとその子を使用して結合するかを選択できます。 この例では "Order" は子を持たないため、矢印に対する [ 結合 ] をクリックしてデフォルトを変更する必要はあり ません。[ 次へ ] をクリックします。[ 割り当て ] ページが 開きます。 12 ファクトを新しいレベルで計算する割り当て式を入力し ます。この例では、割り当て式として ((Freight * [Item-level Units Sold]) / [Order-level Units Sold]) がすでに入力されています。 割り当て式を確認し、処理内容を把握してくださ い。この式は、注文の商品別の平均運送費を返し ます。したがって、"Freight" の拡張で得られるの は注文に含まれる商品別の運送費の概算値であり、 正確な計算値ではありません。この理由について は、この手順の後でより詳しく説明します。 13 [ 終了 ] をクリックしてファクト拡張を作成します。 "Order"、"Item"、および "Freight" を含むレポートを処理する とき、MicroStrategy Engine は ORDER_FACT と ORDER_DETAIL を結合し、結果として得られたテーブルを、 "Item"、"Day"、"Order"、"Employee"（従業員）、"Promotion" （販促）のレベルにある 1 つの論理ファクト テーブルと見な します。"Order"、"Item"、および "Freight" を含むレポート用 に生成される SQL（メトリックを "Freight" ファクトにマッ ピング）は次のとおりです。 select a11.[ORDER_ID] AS ORDER_ID, max(a11.[ORDER_DATE]) AS ORDER_DATE, a12.[ITEM_ID] AS ITEM_ID, max(a13.[ITEM_NAME]) AS ITEM_NAME, sum(((a11.[FREIGHT] * a12.[QTY_SOLD]) / a11.[QTY_SOLD])) AS WJXBFS1 from [ORDER_FACT] a11, [ORDER_DETAIL] a12, [LU_ITEM] a13 where a11.[ORDER_ID] = a12.[ORDER_ID] and a12.[ITEM_ID] = a13.[ITEM_ID] 214 ファクトがレポートされるレベルの変更 : レベル拡張 © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド ビジネス データの構築ブロック : ファクト 6 group by a11.[ORDER_ID], a12.[ITEM_ID] SQL ステートメントは Access データベース用で この す。レポート用に生成される SQL は、使用している DBMS の種類により異なる場合があります。 ファクト拡張がどのようにして注文に含まれる商品別の運送 費の概算値になるのかを確認するには、注文に含まれる商品 別の数量を計算するメトリックを追加した、次に示す最初の 注文をご覧ください。 "Freight" メトリックは注文に含まれる商品別に運送費の平均 額を示していますが、比較的大きな運送費がいくつか表示さ れています。これは、いくつかの商品が複数、注文されてい るためです。この例は、ファクト拡張が正確な計算値ではな く、異なるレベルでの概算値を提供する場合が多いことを示 しています。特定レベルの正確な値を得たい場合は、通常は 該当するデータを取得して、データ ソースに格納する必要 があります。 ファクト関係を使用したファクト テーブル上の結合の定義 ファクト拡張は、テーブル関係の代わりにファクト関係に よって定義することもできます。ファクト関係では、その ファクトを含むどのテーブルでもテーブル結合を実行できま す。その結果、テーブルを手動で選択する代わりに MicroStrategy Engine によって結合に適したテーブルが選択 されるため、より柔軟に関係を定義できます。 © 2010 MicroStrategy, Inc. ファクトがレポートされるレベルの変更 : レベル拡張 215 6 ビジネス データの構築ブロック : ファクト プロジェクト デザイン ガイド 次の図は、「テーブル関係を使用したファクト テーブル上の 結合の定義」（211 ページ）に示した例に 2 つの要約テーブ ルを追加した後のスキーマを示しています。 "Freight" ファクトのエントリ レベルを "Customer"（顧客） に拡張するには、"Order Unit Sales"（注文レベルの売上数量） ファクトを使用してファクト関係を作成します。 MicroStrategy Engine が、"Freight" を含むテーブルの "Order Unit Sales" を含むテーブルへの結合を試みます。指定された 結合アトリビュートによって、次の結合が作成されます。 • Table 1 と Table 2（結合アトリビュートが "Distribution Center" と "Order" の場合） • Table 1 と Table 4（"Distribution Center" の場合） • Table 2 と Table 3（"Distribution Center" の場合） • Table 3 と Table 4（"Distribution Center" の場合） これらの結合は、結合アトリビュートが "Distribution Center" と "Order" の場合と、"Distribution Center" だけの場合の違い を示しています。 ファクト関係は、ファクト エディタのレベル拡張ウィザー ドで定義できます。"Order Unit Sales" ファクトを開き、 "Distribution Center" と "Order" の両方、または "Distribution Center" に拡張します。次に [ 関係テーブルを動的に選択 ] オ プションを選択し、拡張に使用するテーブルを指定します。 このオプションは、 「ファクト拡張の種類を選択するには」 （213 ページ）で前述した手順の直後のステップで設定されま 216 ファクトがレポートされるレベルの変更 : レベル拡張 © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド ビジネス データの構築ブロック : ファクト 6 す。上に示したように、このウィザードで指定するテーブル とアトリビュートによって、作成される結合の種類も異なり ます。 結合アトリビュートとして "Distribution Center" だけを指定し た場合に、"Distribution Center"、"Customer"、および "Freight" を含むレポート用に生成される SQL を次に示しま す。 select a1.DIST_CENTER, a2.CUSTOMER, sum(a1.Freight) from TABLE3 a1, TABLE4 a2 where a1.DIST_CENTER = a2.DIST_CENTER group by a1.DIST_CENTER, a2.CUSTOMER SQL ステートメントは Access データベース用で この す。レポート用に生成される SQL は、使用している DBMS の種類により異なる場合があります。 テーブル関係の場合と同様、最適な組み合わせを指定して、 エンジンに結合を計算させることができます。最適な結合で は、左側のファクト テーブル（上の SQL 例では Table 3）の すべてのキーが、使用する結合アトリビュートに含まれてい なければなりません。 ファクトの強制的なアトリビュートへの関連付け : 直積 結合 結合が存在せず、ファクトを拡張して強制的にファクトをア トリビュートに関連付ける必要がある場合は、直積結合を使 用できます。直積結合とは、1 つのファクト値を関係のない アトリビュートの全エレメントに関連付けることが可能な結 合です。この方法では、データの繰り返しや二重カウントが 発生する場合があるため、正しくないデータが生成される可 能性があります。 直積結合は、他にファクトを拡張する方法がない場合 のみ使用してください。直積結合を指定してファクト をアトリビュートに関連付ける際には、ルックアップ アトリビュートのデカルト積が作成されます。この方 法では効率が悪くなる場合があるため、直接結合を使 用するのは極力避けてください。 © 2010 MicroStrategy, Inc. ファクトがレポートされるレベルの変更 : レベル拡張 217 6 ビジネス データの構築ブロック : ファクト プロジェクト デザイン ガイド たとえば、次のスキーマでは "Distribution Center" と "Dollar Sales" の間に関係は存在しません。 Table 1 Table 2 Distribution Center Order Customer Dollar Sales 配送センタ別にドル単位の売上額をレポートするには、直積 結合を使用する必要があります。 この直積結合は、ファクト エディタのレベル拡張ウィザー ドで定義できます。"Dollar Sales" ファクトを開いて "Distribution Center" アトリビュートまで拡張します。次に [ 直積拡張を実行 ] オプションを選択します。このオプション は、「ファクト拡張の種類を選択するには」（213 ページ）で 前述した手順の直後のステップで設定されます。この例で は、割り当て式を指定する必要はありません。 結合アトリビュートが指定されていないことに注目してくだ さい。この拡張に含まれるアトリビュートのルックアップ テーブルは、常に MicroStrategy Engine によって直積（クロ ス結合）されます。 "Customer"、"Distribution Center"、および "Dollar Sales" を含 むレポート用に生成される SQL を次に示します。 select a1.DIST_CENTER, a2.CUSTOMER, sum(a2.DOLLAR_SALES) from TABLE1 a1, TABLE2 a2 group by a1.DIST_CENTER SQL ステートメントは Access データベース用で この す。レポート用に生成される SQL は、使用している DBMS の種類により異なる場合があります。 218 ファクトがレポートされるレベルの変更 : レベル拡張 © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド ビジネス データの構築ブロック : ファクト 6 ファクト データのレベルの低下 : ファクト分解 分解 とはファクト レベルを低下させることであり、論理的 に集計の逆の処理です。ファクト データを、ファクトが格 納されているレベルより下位の論理レベルで表示するには、 ファクトをそのレベルまで分解する必要があります。この処 理が必要になるのは、レポートで最も一般的に使用されるレ ベルにファクトを格納した後、そのファクトのデータをより 低い論理レベルで表示および分析するユーザ ニーズが生じ たときです。 たとえば、人事分析モジュールには "Department"（部門）レ ベルに格納されている "Planned Compensation"（予定報酬） ファクトが含まれており、"Employee"（従業員）レベルに ファクト分解されています（この例で使用されているアトリ ビュート、ファクト、およびメトリックは、この分析モ ジュールにすべて含まれています）。このファクト拡張では、 割り当て式を使用せずに "Planned Compensation" を "Employee" レベルに分解しているため、次に示すように、 リストに表示される全従業員の予定報酬が、所属部門と同じ 値になります。 このファクト分解の分析値は、この状態ではあまり意味があ りません。ただし、"Planned Compensation" が "Employee" レ ベルで利用可能になったため、"Employee" レベルに格納さ © 2010 MicroStrategy, Inc. ファクトがレポートされるレベルの変更 : レベル拡張 219 6 ビジネス データの構築ブロック : ファクト プロジェクト デザイン ガイド れている他のファクトを使用することで、より意味のある分 析を行うことができます。たとえば、"Employee" レベルに 格納されている "Compensation Cost"（報酬コスト）ファクト を使用して、"Actual as % Planned Compensation" メトリック が作成されています。これは、特定の従業員に支払われた報 酬が、部門全体の予定報酬に占める割合（％）を計算するメ トリックです。メトリック定義は ([Compensation Cost]/[Planned Compensation]) で、"Compensation Cost" ファクトと "Planned Compensation" ファクトからそれぞ れ定義されるメトリックを除算します。この結果、次に示す ように、各従業員に支払われた報酬が、部門全体の予定報酬 に占める割合を見ることができます。 "Planned Compensation" を "Employee" まで分解しないと、 "Department" と "Employee" をこれらのメトリックと共にレ ポートに含め、正しい値を返すことはできません。 以下の手順では、人事分析モジュールの "Planned Compensation" ファクト用に作成されたファクト分解の作成 方法を、順を追って説明します。さらに、プロジェクトの ファクトに使用できるファクト分解の作成の全般的なガイド ラインも示します。 ファクト分解を定義するには 1 Desktop で人事分析モジュールにログインします。 2 Facts /Compensation/Planning フォルダに移動して "Planned Compensation" ファクトをダブルクリックし ます。ファクト エディタが開きます。 220 ファクトがレポートされるレベルの変更 : レベル拡張 © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド ビジネス データの構築ブロック : ファクト 6 3 [ 拡張 ] タブをクリックします。 4 [Degradation to Employee]（従業員への低下）を選択 して [ 変更 ] をクリックします。レベル拡張ウィザードが 開きます。 [ 新規作成 ] を ファクト分解を新規作成する場合は クリックしますが、この例では [Degradation to Employee] で "Planned Compensation" ファクト分解 がどのように作成されたかを、順を追って示しま す。 5 [ ようこそ ] のメッセージを確認してから、[ 次へ ] をク リックします。[ 概要 ] ページが開きます。 6 ファクト拡張の名前と説明を入力します（この例では入 力済みです）。続いて、次のいずれかの操作を選択しま す。 • ファクト エントリ レベルを下げる : ファクト分解を 定義します。 • ファクト エントリ レベルを拡張 : テーブル関係、動 的ファクト関係、または直積結合を使用してファクト 拡張を定義します（「テーブル関係を使用したファク ト テーブル上の結合の定義」（211 ページ）および 「ファクト関係を使用したファクト テーブル上の結合 の定義」（215 ページ）を参照）。 • ファクト エントリ レベルを部分的または完全に禁 止 : 特定レベルでのファクトのレポートを禁止する ファクト拡張を定義します（「特定レベルでのファク トのレポート禁止」（223 ページ）を参照）。 この例ではファクト分解を作成しているため、[ ファクト エントリ レベルを下げる ] を選択して [ 次へ ] をクリック します。[ 拡張したアトリビュート ] ページが開きます。 7 ファクトを別のレベルでレポートできるように、ファク トの分解先アトリビュートを選択します。この例では "Employee" が選択されています。[ 次へ ] をクリックしま す。[ 結合タイプ ] ページが開きます。 階層内のどのレベルでもレポートできるように ファクトを拡張するには、階層の最下位レベルに あるアトリビュートを選択します。 © 2010 MicroStrategy, Inc. ファクトがレポートされるレベルの変更 : レベル拡張 221 6 ビジネス データの構築ブロック : ファクト プロジェクト デザイン ガイド 8 結合に使用するアトリビュートを選択します。この例で は、"Department" アトリビュートが選択されています。 [ 次へ ] をクリックします。[ 結合アトリビュートの方向 ] ページが開きます。 9 選択したアトリビュートを使用して結合するか、アトリ ビュートとその子を使用して結合するかを選択できます。 この例では、"Department" アトリビュートとその子に結 合を実行します。[ 次へ ] をクリックします。[ 割り当て ] ページが開きます。 10 ファクトを新しいレベルで計算する割り当て式を入力し ます。この例では、割り当て式を含める必要はありま せん。ファクト分解で割り当て式を使用する方法につい ては、 「割り当て式を使用するファクト分解」（222 ペー ジ）の例を参照してください。 11 [ 終了 ] をクリックしてファクト分解を作成します。 割り当て式を使用するファクト分解 ファクト分解では、レベルをただちに下げることができると は限りません。通常は、割り当て式を追加する必要がありま す。これにより、指定した計算に従って値を分配し、レベル 拡張でファクトの定義を変更することが可能になります。 これは概念的には、データを上位レベルで集計すると きに集計関数（Sum、Avg など）を選択するタスクに 似ています。 たとえば、ファクトが年のレベルに格納されており、その データを月レベルでレポートする場合は、ファクトに分解を 作成して月レベルに関連付けます。分解先のアトリビュート として "Month" を選択します。その後、割り当て式として fact/12 を指定します。 割り当て式を作成することにより、上位レベルのファクトを 下位レベルのアトリビュートにどのように分解するかを定義 します。割り当て式は、ファクト エディタのレベル拡張 ウィザードでアトリビュートとファクトに設定する操作に よって定義されます。 ファクト分解で得られる値は通常、低い論理レベルのファク ト データの正確な値ではなく、データの概算値です。たと えば、"Year" から "Month" への分解用の割り当て式 222 ファクトがレポートされるレベルの変更 : レベル拡張 © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド ビジネス データの構築ブロック : ファクト 6 fact/12 は、1 年のファクト データを 12 カ月に均等に分割 します。1 年間のすべての月のファクト データが同じになる ことは不可能ではありませんが、通常、その可能性は限られ ます。そのようなファクト分解を使用するのは、ファクト データが低い論理レベルに格納されておらず、ファクト データを低い論理レベルに直接関連付ける方法がない場合に 限定すべきです。 特定レベルでのファクトのレポート禁止 ファクト エディタの [ ファクト エントリ レベルを部分的ま たは完全に禁止 ] の設定は、特定レベルでファクトがレポー トされることを禁止する一種のロック機能です。この設定に より、ルックアップ テーブルへの不要な結合が回避されま す。ファクト エントリ レベルの禁止が役立つ状況について、 以下に例を通じて説明します。 この機能は通常、ファクトのエントリ レベルより下位のレ ベルにおけるファクト データの複雑さと分析負荷を回避す るために、そのような低いレベルへのファクト拡張を禁止す るために使用されます。ファクトが "Minute"（分）や "Second"（秒）など、クエリの処理負荷が大きくなるレベル に格納されている場合、そのような下位レベルのクエリを禁 止することができます。たとえば、3 年分のデータが存在す る場合に "Minute" や "Second" レベルでクエリを実行すると、 非常に多くのリソースが消費され、過剰に詳しいデータが返 されます。これらのレベルでのクエリを禁止した場合、 "Minute" や "Second" レベルのファクトを含むレポートの作 成を試みると、それらのレベルでレポートを実行できないこ とを通知するエラーが返されます。 ここでは一例として、地理、時間、製品という 3 つのディ メンションを含むスキーマを想定します。製品ディメン ションの "Item"（商品）レベルで "Sales"（売上）ファクト を作成し、"Sales" ファクトを集計する "Sales" メトリックを 作成したとします。"Month" アトリビュートと "Sales" メト リックを含むレポートを作成するとき、分析エンジンは動的 にクロス結合を実行してレポートを評価します。"Sales" ファクトの時間ディメンションへの拡張を明示的に禁止する には、[ ファクト エントリ レベルを部分的または完全に禁 止 ] 設定を使用し、時間ディメンションの最下位アトリ ビュート（"Day" など）を選択します。このオプションは、 「ファクト エントリ レベルを低下、拡張、または禁止するに は」（212 ページ）で前述したファクト拡張手順の直後のス © 2010 MicroStrategy, Inc. ファクトがレポートされるレベルの変更 : レベル拡張 223 6 ビジネス データの構築ブロック : ファクト プロジェクト デザイン ガイド テップで設定されます。その後、スキーマを更新してレポー トを再実行すると、ルックアップ テーブルとファクト テー ブル間のクロス結合が禁止されているため、このレポートの 実行は失敗します。一方、この設定は通常の結合には影響を 与えません。 ファクトを対象に "Month" アト 上記の例で、"Sales" リビュートへの拡張を指定し、"Month" の親アトリ ビュートである "Year" への拡張を禁止した後、"Year" アトリビュートと "Sales" メトリックを含むレポート を実行すると、レポートは正常に実行されます。この 場合、分析エンジンは何らかの順序で指定された拡張 条件を並べ替え、並べ替えた拡張の順序に基づいてレ ポートを計算します。その結果、エンジンは有効な SQL を返しますが、これはデザインで意図した状態 とは異なっています。相互に矛盾する拡張定義を含む ファクト定義は使用しないことを推奨します。 ファクト エントリ レベルの禁止設定が適用されるのは、拡 張アトリビュートとして解釈可能なアトリビュートだけで す。たとえば、"Subcategory"（サブカテゴリ）アトリビュー トと "Item" アトリビュート、および "Revenue"（収入）ファ クトを集計する "Revenue" メトリックを含むレポートを作成 したとします。その後、"Revenue" ファクトの "Item" アトリ ビュートへの拡張を禁止し、スキーマを更新しました。この 場合、レポートを再実行しても商品別の収入は表示されま す。言い換えれば、ファクト拡張の禁止が機能していま せん。これは、MicroStrategy Tutorial プロジェクト内で "Revenue" が "Item" と同じレベルに存在するためです。した がって、通常の結合が行われるだけで、拡張は実行されま せん。特定レベルでのファクトのレポートを禁止するには、 有効な理由が必要です。この例では、データ ウェアハウス 内で "Revenue" ファクトが格納されているレベルでレポート を禁止しており、これは論理的に無意味です。 224 ファクトがレポートされるレベルの変更 : レベル拡張 © 2010 MicroStrategy, Inc. 7 7. ビジネス データのコンテキ スト : アトリビュート はじめに ファクトで表されるビジネス データは、ビジネスの概念と コンテキストがなければ、さほど意義深いものにはなりま せん。MicroStrategy でビジネスの概念とコンテキストを形に するのがアトリビュートです。アトリビュートはビジネス モデルに、ファクトをレポートおよび分析するためのコンテ キストを提供します。会社の総売上を知ることが有益である 一方で、その売上がいつどこで発生したものかがわかれば、 ユーザは必要な詳細分析を日々行うことができます。 たとえば、"Month"（月）、"Year"（年）、"Region"（地域）の 各アトリビュートをテンプレートに持ち、さらに "Revenue" （売上）ファクトに基づく "Revenue"（売上）メトリックを 持つレポートがあるとします。このレポートを実行すると、 会社の売上が地域、月、および年の各レベルで表示されま す。レポートのアトリビュートによって、売上が最も少な かった地域や売上が最も伸びた年など、かなりの量の情報が 得られます。レポートからアトリビュートを取り除いてしま うと、わかるのは会社の売上合計だけです。 © 2010 MicroStrategy, Inc. 225 7 ビジネス データのコンテキスト : アトリビュート プロジェクト デザイン ガイド アトリビュートの概要 アトリビュートの作成は、プロジェクト デザインの初期段 階で重要な 1 つのステップであり、プロジェクト作成アシス タントでファクトを作成した後に行います。ユーザとアプリ ケーションに関する要件は、プロジェクトの途中でも新たに 発生するため、アトリビュートの作成と変更は、プロジェク トのライフ サイクル全体にわたって重要な位置を占めます。 データ ウェアハウス内では、アトリビュートは通常、ルッ クアップ テーブル内の一意の ID 列によって識別されます。 MicroStrategy のレポートでは、アトリビュートはレポートの 列ヘッダーによって識別されます。 レポート デザイナは、レポートの作成タスクの一環として、 これらのレポートの列ヘッダーを決定します。Intelligence Server は、このレポート定義を使用して、レポートの SQL の作成方法をエンジンに指示します。レポート内のアトリ ビュートとファクトの式によって、SQL コマンドの SELECT 句が定義されます。 226 アトリビュートの概要 © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド ビジネス データのコンテキスト : アトリビュート 7 次の例をご覧ください。 Select Store_ID, Date, sum(Sales) From Store_Fact Group By Store_ID, Date この SQL は、売上情報を店舗別および日付別に取得します。 レポート内のアトリビュートとメトリックが、データ ウェ アハウス内のどこに必要な情報が存在し、その情報を取得す る SQL をどのように作成するかを Intelligence Server に指示 します。このプロセスによって、データ ウェアハウスから 情報を抽出する SQL を知らなくても、ユーザはレポート分 析を行うことができます。 レポートに含めることが可能な最下位レベルのアトリビュー ト（"Day"（日）など）が、レポートの最下位レベルの詳細 情報になります。上位レベルのレポート、たとえば " 年 " レ ベルのレポートには "Year"（年）アトリビュートが含まれて います。このレポートに表示される情報は、"Month"（月） や "Week"（週）など低位レベルのアトリビュートを含む同 様のレポートほど詳細ではありません。データ自体は同じも のであり、単に集計されていないだけであることを理解して おくことが重要です。 メトリック、フィルタ、およびレポートの説明は、こ のガイドの対象範囲に含まれていません。これらにつ いては、『MicroStrategy 上級レポーティング ガイド』 で説明しています。 アトリビュートは以下のプロパティで定義されます。 © 2010 MicroStrategy, Inc. • アトリビュート フォーム : アトリビュートの識別子また は記述子を含みます。1 つのアトリビュートが複数のア トリビュート フォームを持つこともあります。たとえ ば、"Customer"（顧客）アトリビュートの場合、アトリ ビュート フォームとして、"Customer Email"（顧客メー ル アドレス）、"Customer First Name"（顧客の名）、 "Customer Last Name"（顧客の姓）などを持つことがあり ます。 「列データの説明と識別子 : アトリビュート フォーム」（248 ページ）を参照してください。 • アトリビュート式 :MicroStrategy のアトリビュート フォームを、ウェアハウス内の 1 つ以上の列にマップし ます。 「アトリビュート フォーム式」（253 ページ）を参 照してください。 アトリビュートの概要 227 7 ビジネス データのコンテキスト : アトリビュート • プロジェクト デザイン ガイド アトリビュート関係 : 概念レベルが異なるデータ間の連 携を可能にして、プロジェクト内のデータ間の関係を示 します。「アトリビュート関係」（265 ページ）を参照し てください。 次の図は、上記のアトリビュート プロパティ間の関係を示 しています。 アトリビュートの作成は、プロジェクトの初期段階で重要な 1 つのステップですが、プロジェクトのライフ サイクル全体 を通じて、アトリビュートの変更や作成が必要になることも 多くあります。これらのタスクの実行手順については、この 章の最初の項（「アトリビュートの作成」（229 ページ））で 説明しています。以降の項では、アトリビュートの概念と、 さらに高度なアトリビュート デザインの方法と手順につい てもいくつか説明します。 228 アトリビュートの概要 © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド ビジネス データのコンテキスト : アトリビュート 7 アトリビュートの作成 アトリビュートは主に、ファクト データをグループ化およ び集計して、ファクト データにビジネス コンテキストを追 加するために使用されます。データのレポートや分析を行う には、データにビジネス コンテキストが必要です。このこ とから、アトリビュートの作成は、プロジェクト デザイン で常に重要なステップとなります。 この項では、プロジェクト デザイン プロセスの異なる段階 で、異なる方法と MicroStrategy インタフェースを使用して、 アトリビュートを作成する手順について説明します。 • 「複数のアトリビュートの同時作成」（229 ページ）では、 プロジェクト デザインの初期段階、あるいはその後のプ ロジェクトのライフ サイクルで、アトリビュート作成 ウィザードを使用して複数のアトリビュートを作成する 手順を示します。 • 「アトリビュートの追加と変更」（235 ページ）では、既 存のプロジェクトにアトリビュートを追加し、変更する 手順を示します。この説明には、既存のアトリビュート へのアトリビュート フォームの追加やプロジェクトの拡 張に応じた新規アトリビュートの追加などの高度な機能 の追加手順も含まれています。 プロジェクト デザインのどの段階においても、Architect を 使用してアトリビュートを作成および変更することができま す。Architect でアトリビュートを作成および変更する方法に ついては、「Architect による単純なアトリビュートと高度な アトリビュートの追加および変更」（241 ページ）を参照し てください。 複数のアトリビュートの同時作成 プロジェクト デザインの初期段階やそれ以降のプロジェク トのライフ サイクルにおいて、アトリビュート作成ウィ ザードを使用して複数のアトリビュートを作成できます。 を使用して、複数のアトリビュートを作成す Architect ることもできます。この手順は 7 章、「Architect によ る単純なアトリビュートと高度なアトリビュートの追 加および変更」で説明します。 © 2010 MicroStrategy, Inc. アトリビュートの作成 229 7 ビジネス データのコンテキスト : アトリビュート プロジェクト デザイン ガイド アトリビュート作成ウィザードでアトリビュートを作成するには これは、プロジェクト デザインの初期段階における手順で す。プロジェクト作成アシスタントを使用して、アトリ ビュート作成ウィザードを起動し、アトリビュート作成タス クを完了します。プロジェクト作成ウィザードを開く方法に ついては、「プロジェクト作成アシスタントで新規プロジェ クトを作成するには」（86 ページ）を参照してください。ま た、アトリビュート作成ウィザードは、プロジェクトの開発 中に MicroStrategy Desktop の [スキーマ] メニューからいつで も開くことができます。 1 プロジェクト作成ウィザードで [ アトリビュートを作成 ] をクリックします。次に示すアトリビュート作成ウィ ザードが開きます。 2 表示されるイントロダクション ページの内容を確認しま す。 アトリビュートの作成規則を定義します。 作成規則を定義することで、アトリビュート列の選択と アトリビュートの命名がかなり容易になります。データ ウェアハウス内の命名規則とデータ タイプに一貫性があ る場合は特に効果的です。アトリビュート作成ウィザー ドは、以下の規則を使用して、アトリビュート作成プロ セスの自動化に役立ちます。ウェアハウス内の命名規則 やデータ タイプの規則が、デフォルトに準拠しない場合 は、これらの規則を変更します。 230 アトリビュートの作成 © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド ビジネス データのコンテキスト : アトリビュート 7 3 [ 規則定義 ] をクリックし、アトリビュート作成の基本的 ないくつかの規則を設定します。[ アトリビュート作成規 則 ] ページが開きます。 4 [ 列データ タイプ ] 領域では、アトリビュート ID 列に使 用可能な列データ タイプを選択します。含めるデータ タ イプのチェック ボックスを選択します。ここで指定した データ タイプのアトリビュート ID 列が、ウィザードに よってデータ ウェアハウス内で検索されます。 5 [ アトリビュート名 ] 領域では、デフォルトのアトリ ビュート名の作成方法を指定できます。該当するチェッ ク ボックスを選択して、次に示すアトリビュート名のデ フォルトの作成方法を設定します。 • アトリビュート名に含まれる下線をスペースで置き換 える • 名前から「ID」という文字列を削除する • 先頭文字を大文字にする 6 [ ウェアハウス検索 ] 領域では、ウェアハウス オブジェク トの位置を特定するのに役立つ命名規則を指定します。 デフォルトでは、ID 列は ID、説明列は DESC、ルック アップ テーブルは LOOKUP となっています。 7 [OK] をクリックして規則の変更を保存し、アトリビュー ト作成ウィザードに戻ります。 ID 列の選択 ID 列は、アトリビュートの各エレメントを一意に識別す る列または列のグループです。 8 [ 次へ ] をクリックします。[ID 列を選択 ] ページが開きま す。 ID 列を選択するときは、列の アトリビュートの すべての値が一意であること、および NULL 値が 含まれていないことを確認してください。NULL 値や重複する値を含む列は、アトリビュートの ID 列として使用しないでください。これらを使用す ると、予期しない動作を引き起こしエラーが発生 します。 © 2010 MicroStrategy, Inc. アトリビュートの作成 231 7 ビジネス データのコンテキスト : アトリビュート プロジェクト デザイン ガイド [ID 列を選択 ] ページには、前述のステップで定義した規 則に合致するデータ タイプの列だけが表示されます。 ウェアハウス内で設定している識別子の命名規則に合致 する列の名前が、自動的に強調表示されます。 9 [使用可能な列] ペインでアトリビュート ID に使用する列 を選択し、[>] をクリックしてプロジェクトに追加しま す。[>>] をクリックすると、リストに含まれるすべての 列を一度に追加できます。 以下の点に注意してください。 – アトリビュートを右クリックして [ 名前の変更 ] を 選択し、アトリビュートの名前をもっとわかりや すい名前に変更できます。 – プロジェクトからアトリビュート ID 列を削除す るには、[ アトリビュート ] ペインで削除するアト リビュート ID を選択し、[<] をクリックして [ 使 用可能な列 ] ペインに移動します。 – アトリビュート作成ウィザードでは、同じ情報を 保持していても名前の異なる複数の列（異種の列） には対応できません。アトリビュートを異種の列 にマップする方法の詳細は、「異なる列名の結合 : 異種マッピング」（258 ページ）を参照してくださ い。 複合アトリビュートの作成 複合アトリビュートとは、ID 列として複数の列を指定し たアトリビュートのことです。これは、アトリビュート のエレメントを一意に識別するために、複数の ID 列が 必要であることを意味します（「複数の ID 列を持つアト リビュート : 複合アトリビュート」（291 ページ）を参 照）。 10 複合アトリビュートを作成するには、次のステップを最 後まで実行します。 232 アトリビュートの作成 • [ 複合アトリビュート ] をクリックし、さらに [ 追加 ] をクリックします。[ 新規複合アトリビュート ] ダイア ログ ボックスが開きます。 • アトリビュートの名前を入力します。 © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド ビジネス データのコンテキスト : アトリビュート • 7 複合アトリビュートを一意に識別するために必要な列 を選択し、[OK] をクリックします。アトリビュート 作成ウィザードに戻ります。 説明列の選択 説明列には、アトリビュートにコンテキストと意味を付 与するデータが含まれます。 11 必要なアトリビュート ID 列をすべて追加した後、[ 次へ ] をクリックします。[ 説明列を選択 ] ページが開きます。 12 アトリビュートの説明として ID 列を使用するか、その 他の列を使用するかを選択します。ウェアハウス内で設 定している説明の命名規則に合致する列が自動的に選択 されます。 以下の点に注意してください。 – 通常は、各アトリビュートのデフォルトの説明列 を使用してください。ただし、ID 列が適切な説明 列として使用できる場合（" 年 " 列など）もあり ます。 – その他のアトリビュート フォームは、プロジェク ト作成アシスタントで手順を完了した後、アトリ ビュート エディタで作成する必要があります。ア トリビュート フォームの詳細は、「アトリビュー ト エディタによるアトリビュートの追加」（238 ページ）を参照してください。 ルックアップ テーブルの選択 ルックアップ テーブルは、アトリビュートの物理的表現 であり、ID 列と説明列に格納されているデータを通じ て、アトリビュートに関する情報を提供します。 13 アトリビュートの説明列の選択が完了した後、[ 次へ ] を クリックします。[ ルックアップ テーブルを選択 ] ページ が開きます。 14 各アトリビュートのルックアップ テーブルを選択しま す。 ウェアハウス内で設定しているルックアップの命名規則 に合致するテーブルが自動的に選択されます。通常は、 各アトリビュートのデフォルトのルックアップ テーブル を選択します。 © 2010 MicroStrategy, Inc. アトリビュートの作成 233 7 ビジネス データのコンテキスト : アトリビュート プロジェクト デザイン ガイド 15 [ 次へ ] をクリックします。 • 複合アトリビュートを作成した場合は、[ 複合アトリ ビュート定義 ] ページが開きます。複合アトリビュー トのルックアップ テーブルと説明列を選択し、[ 次へ ] をクリックします。[ 関係定義 ] ページが開きます。 • 複合アトリビュートを作成しなかった場合は、[ 関係 定義 ] ページが開きます。 関係の定義 アトリビュートごとに、子と関係の種類（1 対 1、1 対 多、または多対多）を指定します。アトリビュート間の 関係は、プロジェクトのローカル データ モデルのデザ イン（2 章、「論理データ モデル」を参照）時に明確にし なければなりません。"City"（都市）、"State"（州）、 "Region"（地域）などの互いに関係のあるアトリビュー トは、通常 1 つのグループとして同じ階層（" 場所 " な ど）内にまとめて置かれます。論理データ モデルでは、 同じ階層に属するアトリビュート間には互いに関係がな ければなりません。一方、異なる階層のアトリビュート 間には関係が存在してはなりません。 16 アトリビュートごとに、次の手順で子アトリビュートを 定義します。 • [ アトリビュート ] ペインでアトリビュートを選択し、 [ 追加 ] をクリックします。[ 子アトリビュートを選択 ] ダイアログ ボックスが開きます。 • 使用可能な子アトリビュートのリストから子アトリ ビュートを選択し、[OK] をクリックします。アトリ ビュート作成ウィザードに戻ります。 • [ 次の親の子 : アトリビュート名 ] ペインで、アトリ ビュートとその子の間に定義する関係の種類を選択し ます。各種のアトリビュート関係の詳細については、 「アトリビュート関係」（265 ページ）を参照してくだ さい。 17 子を必要とするすべてのアトリビュートに対して子を定 義したら、[ 次へ ] をクリックします。[ 終了 ] ページが開 きます。 18 [ 終了 ] ページの要約情報を確認し、問題がなければ [ 終 了 ] をクリックしてアトリビュートを作成します。 234 アトリビュートの作成 © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド ビジネス データのコンテキスト : アトリビュート 7 アトリビュート作成ウィザードのすべてのステップを完了す ると、アトリビュートが作成されます。これで、プロジェク ト作成アシスタントによる、プロジェクト作成の初期段階が 完了します。 アトリビュートの追加と変更 作成済みのプロジェクトにファクトを追加できるのと同様 に、アトリビュートも必要に応じて作成し、追加することが できます。企業の成長とともにレポートのニーズも変化しま す。その結果、データ ウェアハウスや MicroStrategy プロ ジェクト内のスキーマへの変更が必要になることがありま す。 たとえば、米国の医療分野で事業展開してきた企業が、欧州 とアジアの市場への参入を決定したとします。この企業は新 規参入に先立ち、参入先各国に関する情報を含むルックアッ プ テーブルを、自社のデータ ウェアハウス内に持っていま せん。 そのため、欧州とアジアに支社を開設した後、これらの支社 に関する情報を含むルックアップ テーブルをデータ ウェア ハウスに追加する必要があります。さらに、それらのテーブ ルを MicroStrategy のプロジェクトに追加し、レポート ユー ザがそれぞれの国でビジネス データを分析できるように、 適切なアトリビュートを作成します。 アトリビュートは、アトリビュート作成ウィザードまたはア トリビュート エディタで作成できます。アトリビュート作 成ウィザードは、プロジェクトで初めてアトリビュートを作 成するときに使用します。アトリビュート エディタでは、 アトリビュート、アトリビュート フォーム、およびアトリ ビュート フォーム式を定義できます。 • アトリビュート作成ウィザードでは、次のタスクが実行 できます。 単純なアトリビュートを作成する 複数のアトリビュートを迅速に作成する プロジェクトの作成中に多数のアトリビュートを追加 する © 2010 MicroStrategy, Inc. アトリビュートの作成 235 7 ビジネス データのコンテキスト : アトリビュート プロジェクト デザイン ガイド アトリビュート作成ウィザードは、多数のアトリビュー トを最初に作成する手段として効果的ですが、既存のア トリビュートに変更を加えたり、さらに高度なアトリ ビュートを定義するアプリケーションには不向きです。 通常、アトリビュート作成ウィザードを使用するのは、 プロジェクト作成の初期段階だけで、このときにプロ ジェクトのほとんどのアトリビュートが作成されます。 アトリビュート作成ウィザードの使用手順については、 「複数のアトリビュートの同時作成」（229 ページ）およ び「アトリビュート作成ウィザードによるアトリビュー トの追加」（237 ページ）を参照してください。 • アトリビュート エディタでは、次のタスクを実行できま す。 単純なアトリビュートおよび高度なアトリビュートの 作成 既存のアトリビュートの編集およびその他のスキーマ レベルの設定 アトリビュート エディタでは、既存のアトリビュートの 編集、アトリビュート フォームの追加作成、異種の列名 のマッピング、高度な式の定義、追加設定などを行うこ とができます。アトリビュート エディタでは一度に 1 つ のアトリビュートを編集します。これは、プロジェクト 内で変更が必要なアトリビュート数が限られているとき に役立ちます。アトリビュート エディタの使用手順につ いては、「アトリビュート エディタによるアトリビュー トの追加」（238 ページ）および「アトリビュートの変 更」（241 ページ）を参照してください。 • Architect では次のタスクを実行できます。 単純なアトリビュートを作成する 複数のアトリビュートを迅速に作成する プロジェクトの作成中に多数のアトリビュートを追加 する 単純なアトリビュートおよび高度なアトリビュートの 作成 既存のアトリビュートの編集およびその他のスキーマ レベルの設定 236 アトリビュートの作成 © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド ビジネス データのコンテキスト : アトリビュート 7 Architect は、アトリビュート エディタで使用可能な、単 純なアトリビュートおよび高度なアトリビュートに関す る全機能をサポートしています。一度に 1 つのアトリ ビュートを対象とするアトリビュート エディタとは異な り、Architect では 1 つのプロジェクトを対象に、一度に 複数のアトリビュートを作成および変更できます。 Architect の使用方法の詳細は、「Architect による単純なア トリビュートと高度なアトリビュートの追加および変更」 （241 ページ）を参照してください。 アトリビュート作成ウィザードによるアトリビュー トの追加 アトリビュート作成ウィザードは主に、プロジェクト作成の 初期段階でプロジェクトのほとんどのアトリビュートを作成 するために使用しますが、ウェアハウス内の残りのルック アップ列から複数のアトリビュートを作成する必要がある場 合にも役立ちます。 アトリビュート作成ウィザードを使用して単純なアトリ ビュートを複数、一括作成する手順を次に示します。 アトリビュート作成ウィザードで単純なアトリビュートを複数、 一括して作成するには 1 MicroStrategy Desktop で、対象のプロジェクトを含むプ ロジェクト ソースにログインし、そのプロジェクトを展 開します。 権限があるログインを使用する必要があ Architect ります。詳細は、『MicroStrategy システム管理ガイ ド』の付録「許可と権限」を参照してください。 2 フォルダ リストで、アトリビュートを新しく追加するプ ロジェクトを選択します。 3 [ スキーマ ] メニューで、[ アトリビュート作成ウィザー ド ] を選択します。アトリビュート作成ウィザードが開 きます。 4 アトリビュート作成ウィザードでアトリビュートを作成 するには、「複数のアトリビュートの同時作成」（229 ページ）に示した手順に従ってください。 © 2010 MicroStrategy, Inc. アトリビュートの作成 237 7 ビジネス データのコンテキスト : アトリビュート プロジェクト デザイン ガイド アトリビュート エディタによるアトリビュートの 追加 アトリビュート エディタは、アトリビュート フォームなど の高度な機能を、既存のアトリビュートに追加するために使 用します。プロジェクトに新規アトリビュートを追加するこ ともできます。 アトリビュート エディタでアトリビュートを作成するには 1 MicroStrategy Desktop で、対象のプロジェクトを含むプ ロジェクト ソースにログインし、そのプロジェクトを展 開します。 2 [ ファイル ] メニューから [ 新規作成 ]、[ アトリビュート ] の順に選択します。アトリビュート エディタが開き、 [ 新規アトリビュート式の作成 ] ダイアログ ボックスが最 前面に表示されます。 3 [ ソース テーブル ] ドロップダウン リストから、作成する アトリビュートのデータ列を含むテーブルを選択します。 選択したテーブル内の列が [ 使用可能な列 ] ペインにリス トされます。 4 作成しているアトリビュートの ID フォーム用のフォー ム式を作成します。 • 単純なアトリビュート フォーム式（「アトリビュート フォーム式」（253 ページ））を作成するには、[ 使用 可能な列 ] ペインから列をドラッグし、[ フォーム式 ] ペインにドロップします。 • より高度なアトリビュート フォーム式を作成する場 合は、次の手法を適切に組み合わせます。 – 定数を二重引用符で囲んで入力します。 – フォーム式ツールバーの [f(x)] をクリックし、関 数を挿入ウィザードを使用して関数を作成します。 – フォーム式ツールバーで演算子をクリックして式 に挿入します。 5 式が有効であることを確認するために、[ 検証 ] をクリッ クします。 238 アトリビュートの作成 © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド ビジネス データのコンテキスト : アトリビュート 7 6 [ マップ方法 ] で [ 自動 ] または [ 手動 ] を選択します。 • 自動マッピングでは、アトリビュート フォーム式で 列が使用されているプロジェクト内の全テーブルが、 アトリビュート フォームの使用可能なソース テーブ ルとして選択されます。その後、自動マッピングされ たすべてのテーブルを消去し、他のテーブルを選択す ることもできます。 • 手動マッピングでも、アトリビュート フォーム式で 列が使用されているプロジェクト内の全テーブルを見 つけられますが、アトリビュート フォームの使用可 能なソース テーブルとして自動選択されることはあ りません。その後、アトリビュート フォームのソー ス テーブルとして使用するテーブルを手動で選択し ます。 以下の点に注意してください。 – 最初に作成するアトリビュートやアトリビュート フォーム式には、デフォルトでは自動マッピング が使用されます。式がシステムによって、各ソー ス テーブルにマップされます。2 番目以降のアト リビュートでは、手動マッピングがデフォルトに なります。 – 定数値だけを使用する式には、自動マッピングは 使用できません。 7 [OK] をクリックします。[ 新規アトリビュート フォーム を作成 ] ダイアログ ボックスが開きます。このダイアロ グ ボックスでアトリビュートのアトリビュート フォーム を作成します（「列データの説明と識別子 : アトリビュー ト フォーム」（248 ページ）を参照）。 8 [ ソース テーブル ] ペインでテーブルを選択して [ ルック アップとして設定 ] をクリックし、そのテーブルをアト リビュートのルックアップ テーブルに設定します。ルッ クアップ テーブルは、1 つのアトリビュートの情報を保 持する主要テーブルとして機能します。手動マッピング を選択した場合は、アトリビュート フォームにマップす るテーブルのチェック ボックスを選択します。 9 [ フォーム概要 ] 領域で、アトリビュート フォームの名前 と説明を該当するフィールドに入力します。 © 2010 MicroStrategy, Inc. アトリビュートの作成 239 7 ビジネス データのコンテキスト : アトリビュート プロジェクト デザイン ガイド 10 [ 使用するカテゴリ ] ドロップダウン リストで、次のいず れかを行います。 • ドロップダウン リストからフォームのカテゴリを選 択する（フォーム カテゴリの詳細は、「フォームの表 示 : アトリビュート フォームのプロパティ」（250 ページ）を参照）。 • [ 変更 ] をクリックして新しいフォーム カテゴリを作 成する。 ID 列として数値以外のデータ アトリビュートの タイプの列を使用すると、SQL 生成で問題が発生 することがあります。したがって、数値型以外の データ タイプの列を ID 列として選択すると、[ 新 規アトリビュート フォームを作成 ] ダイアログ ボックスで [OK] をクリックしたときに、デフォ ルトでは警告メッセージが表示されます。 11 [ フォーム フォーマット ] 領域で、表示の種類とデフォル トの並べ替えオプションを、それぞれのドロップダウン リストから選択します。 グループの並べ替えには、[ レポート表 カスタム 示フォーム ] の先頭に表示されるフォームのデ フォルトの並べ替えが使用されます。カスタム グ ループの詳細は、『MicroStrategy 上級レポーティン グ ガイド』を参照してください。 12 [OK] をクリックします。アトリビュート エディタが開 きます。 13 [ ファイル ] メニューから、[ 名前を付けて保存 ] を選択し ます。[ 保存 ] ダイアログ ボックスが開きます。 14 ファイルの保存先フォルダまでナビゲートします。派生 ファクトの名前を入力します。[ 保存 ] をクリックします。 15 [ スキーマ ] メニューで [ スキーマを更新 ] を選択し、プロ ジェクト スキーマを更新します。これによりプロジェク トが更新されて、新しいアトリビュート定義が認識され るようになります。 240 アトリビュートの作成 © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド ビジネス データのコンテキスト : アトリビュート 7 アトリビュートの変更 アトリビュート エディタを使用すれば、作成したアトリ ビュートに、必要に応じて、いつでも変更を加えることがで きます。アトリビュート作成ウィザードでは、既存のアトリ ビュートに変更を加えることはできません。 既存のアトリビュートを変更するには 1 MicroStrategy Desktop で、変更するアトリビュートが含 まれるフォルダを開きます。 2 編集対象のアトリビュートをダブルクリックします。ア トリビュート エディタが開きます。 アトリビュート エディタでアトリビュートを作成すると きに使用可能なすべてのオプションを変更できます。ア トリビュート作成時に使用可能なオプションについては、 「アトリビュート エディタでアトリビュートを作成する には」（238 ページ）で説明しています。 さらに高度なアトリビュートの作成方法については、この章 のいくつかの項で説明しています。 Architect による単純なアトリビュートと高度なア トリビュートの追加および変更 Architect では、単純なアトリビュートや高度なアトリビュー トを、統合された環境で視覚的に作成および変更できます。 テーブル、アトリビュート、アトリビュート関係、アトリ ビュート、ユーザ階層、およびその他のプロジェクト オブ ジェクトを、プロジェクトをデザインしながら視覚的に確認 できます。 Architect は、アトリビュート エディタで使用可能な、単純 なアトリビュートおよび高度なアトリビュートに関する全機 能をサポートしています。一度に 1 つのアトリビュートを対 象とするアトリビュート エディタとは異なり、Architect で は 1 つのプロジェクトを対象に、一度に複数のアトリビュー トを作成および変更できます。Architect に関する情報と、 Architect を使用してアトリビュートを作成および変更する手 順については、以下の章および項を参照してください。 © 2010 MicroStrategy, Inc. アトリビュートの作成 241 7 ビジネス データのコンテキスト : アトリビュート • プロジェクト デザイン ガイド 5 章、 「Architect によるプロジェクトの作成」 • 「プロジェクトの作成と変更」（104 ページ） • 「アトリビュートの作成と変更」（149 ページ） アトリビュート情報の一意のセット : アト リビュート エレメント アトリビュート エレメント とは、1 つのアトリビュートを 構成する情報と値の一意のセットです。たとえば、次の図で は "Customer"（顧客）がアトリビュートで、"New York NY"、 "Baltimore BA"、および "Boston BN" は "City"（都市）アトリ ビュートのエレメントです。 次の例は、"Customer"（顧客）アトリビュートのエレメント とデータを格納する物理ウェアハウス内のテーブルを示して います。次に示すように、各アトリビュート エレメントが、 データ ウェアハウス内ではアトリビュート ルックアップ テーブル内の 1 行になっています。 この例の "Customer"（顧客）アトリビュートは、アトリ ビュートのコンポーネントと、アトリビュート エレメント 242 アトリビュート情報の一意のセット : アトリビュート エレメント © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド ビジネス データのコンテキスト : アトリビュート 7 の概念を理解する上で効果的です。"Customer"（顧客）アト リビュートの場合、アトリビュート エレメントは個々の顧 客です。顧客（アトリビュート エレメント）ごとに、アト リビュート フォームで定義された姓、名、メール アドレス など、それぞれの情報セットがあります（「列データの説明 と識別子 : アトリビュート フォーム」（248 ページ）を参 照）。 この図に示すように、アトリビュート エレメントは、アト リビュートのアトリビュート フォームで定義された情報の 一意のセットです。アトリビュート エレメントは、ブラウ ズ フォームによって識別されます。ブラウズ フォームとは、 アトリビュート エレメントの一般的な説明を提供する フォームのことです。たとえば上図では、"First Name"（名） フォームと "Last Name"（姓）フォームがアトリビュート エ レメントの識別に使用されています。顧客を住所で参照しな いように、"Address"（住所）フォームは通常、"Customer" （顧客）アトリビュート エレメントの識別には使用しま せん。アトリビュート エレメントの識別に使用されるアト リビュート フォームの選択方法の詳細は、「アトリビュート を使用したデータのブラウズとレポート」（294 ページ）を 参照してください。 アトリビュート エレメントは、論理データ モデル内で識別 できます。次の図では、"Division"（事業部）アトリビュー トに "Men’s Clothing"（男性衣料）、"Shoes"（靴）、"Sporting © 2010 MicroStrategy, Inc. アトリビュート情報の一意のセット : アトリビュート エレメント 243 7 ビジネス データのコンテキスト : アトリビュート プロジェクト デザイン ガイド Goods"（スポーツ用品）など複数のアトリビュート エレ メントがあります。 MicroStrategy レポート内のアトリビュート エレメントの表 示は、関連するアトリビュート キーの位置よって決まりま す。たとえば、Sales and Distribution Analysis Module （SDAM: 販売分析モジュール）から作成された次のレポート には、"Sales Organization"（販売組織）と "Year"（年）とい う 2 つのアトリビュートがあります。"Sales Organization" は そのアトリビュート エレメント（"USA Central"（米国中部） など）と共にレポートの行を構成しており、"Year" がそのア 244 アトリビュート情報の一意のセット : アトリビュート エレメント © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド ビジネス データのコンテキスト : アトリビュート 7 トリビュート エレメント（"2005" など）と共にレポートの 列を構成しています。 アトリビュートとアトリビュート エレメントの表示は、レ ポート内のメトリックの位置にも影響されます。上のレポー トでは、メトリック（"Sales Orders Quantity (Base Units)"（発 注数量（基本ユニット））と "Cost Sales Orders"（受注コス ト））は通常的な慣習に従い、レポートの列に使用されてい ます。 アトリビュート エレメントのデータ国際化のサポート MicroStrategy は、データをユーザに必要な言語にする国際化 をサポートしています。これにより、ユーザの言語ニーズに 応じて、アトリビュート エレメントのデータをさまざまな 言語で表示できます。 たとえば、年間の利益を月別に表示する、次の単純なレポー トについて考えてみましょう。 © 2010 MicroStrategy, Inc. アトリビュート情報の一意のセット : アトリビュート エレメント 245 7 ビジネス データのコンテキスト : アトリビュート プロジェクト デザイン ガイド これは、地域設定を英語（English）にしているユーザが、 レポートを実行したときに表示されます。国際化データをサ ポートすることで、地域設定をドイツ語（German）にして いるユーザには、同じレポートは次のデータを返します。 アトリビュート エレメントのデータがドイツ語で表示され ています。たとえば、アトリビュート エレメント January、 February、March は、それぞれ Januar、Februar、M 較 z に なっています。 データ国際化は、さまざまな言語に翻訳されたデータ ソー ス内のデータを、アトリビュート エレメントのデータとし て提供します。アトリビュート名（上のレポートの "Month of Year"、"Monat im Jahr" など）、説明、およびその他のオブ ジェクト情報を国際化するには、メタデータの国際化を使用 し、設定する必要があります。メタデータの国際化の設定方 法は、『システム管理ガイド』を参照してください。 アトリビュート エレメントのデータの国際化は、アトリ ビュート フォームごとに有効または無効にできます。アト リビュート フォームの国際化を有効または無効にする手順 を、以下に説明します。 アトリビュート エレメントのデータの国際化は、Architect で有効または無効にすることもできます。詳細は、「アトリ ビュート エレメントのデータ国際化のサポート」（171 ペー ジ）を参照してください。 前提条件 • 翻訳データがデータ ソースに格納されていること （「データの国際化のサポート」（63 ページ）を参照）。 246 アトリビュート情報の一意のセット : アトリビュート エレメント © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド ビジネス データのコンテキスト : アトリビュート • • 7 プロジェクトのデータ国際化が有効になっていること （「プロジェクトのデータの国際化」（92 ページ）を参 照）。 アトリビュートが作成済みであること。 アトリビュート フォームのデータ国際化を有効または無効にする には 1 Desktop でプロジェクトにログインします。 2 [ スキーマ オブジェクト ] フォルダまでナビゲートして [ アトリビュート ] フォルダを開き、続いてデータ国際化 を有効または無効にするアトリビュートを含むフォルダ を開きます。 3 アトリビュートを右クリックして [ 編集 ] を選択します。 アトリビュート エディタが開きます。 4 [ アトリビュート フォーム ] ペインでアトリビュート フォームを選択し、[ 変更 ] をクリックします。[ アトリ ビュート フォームを変更 ] ダイアログ ボックスが開きま す。 5 選択したアトリビュート フォームのデータ国際化を有効 にするには、[ 複数言語をサポート ] チェック ボックスを 選択します。アトリビュート フォームの国際化を無効に するには、このチェック ボックスをクリアします。 ID フォームは識別用途だけに アトリビュートの 限られるため、このオプションは ID フォームに はありません。 6 [OK] をクリックしてアトリビュート エディタに戻りま す。 7 [ 保存して閉じる ] をクリックして変更を保存し、Desktop に戻ります。 © 2010 MicroStrategy, Inc. アトリビュート情報の一意のセット : アトリビュート エレメント 247 7 ビジネス データのコンテキスト : アトリビュート プロジェクト デザイン ガイド 列データの説明と識別子 : アトリビュート フォーム アトリビュート フォームは、アトリビュートの識別子また は記述子です（「論理データ モデルの表記法」（35 ページ） を参照）。 すべてのアトリビュートには 1 つ以上のフォームが必要で す。大部分のフォームは次の必須フォームを 1 つとその他の フォームを 1 つ以上持っています。 • ID フォーム（必須） • 説明フォーム ID フォーム（識別フォーム）は、すべてのアトリビュート に必須です。同じアトリビュートの他のエレメントからの各 アトリビュート エレメントは、ID フォームによって一意に 識別されます。たとえば、"Customer"（顧客）アトリビュー トの ID フォーム Customer_ID が顧客を一意に識別する数 値列だとします。この場合、John Smith、Fred Black など顧 客個人を識別するために、Customer_ID 列の値は John Smith は 1、Fred Black は 2 というように、顧客ごとに異なる 値を設定する必要があります。 アトリビュートには、説明フォームが存在する場合もありま す。MicroStrategy Tutorial の "Customer" アトリビュートに は、"Customer Name"、"Address" などさまざまなフォームが あります。これら各種の説明フォームは、"Customer" アトリ ビュートに関するコンテキストおよび情報を提供します。 アトリビュートによっては、主説明フォーム以外に主説明 フォームにとしては機能しない追加説明フォームが存在する 248 列データの説明と識別子 : アトリビュート フォーム © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド ビジネス データのコンテキスト : アトリビュート 7 場合もあります。次の図に示すように、"Customer" アトリ ビュートには追加説明フォームとして EMAIL が含まれてい ます。 このデータ ウェアハウスでは、次に示すようにルックアッ プ テーブル内の 3 つの列に、それぞれ異なるフォームが格 納されています。 • Customer_ID: 顧客を識別する一意の数字（ID フォー ム） • Customer_Full_Name: 顧客の名前（説明フォーム） • EMAIL: 顧客のメール アドレス（追加説明フォーム） この例では、LU_CUSTOMER テーブルに "Customer" アトリ ビュートのすべてのフォームのデータが記録されています。 アトリビュートには少なくとも 1 つの ID フォームが必要で す。アトリビュートは ID フォームによって一意に識別され ます。作成するフォームには、1 つのルックアップ テーブル © 2010 MicroStrategy, Inc. 列データの説明と識別子 : アトリビュート フォーム 249 7 ビジネス データのコンテキスト : アトリビュート プロジェクト デザイン ガイド への参照を含める必要があります。また、フォームには複数 の式を含めることができます。各テーブルには 1 つの ID フォームが必須です。ID フォームはテーブルの結合に使用 されます。アトリビュート フォームを作成するとき、プロ ジェクト内のテーブルのリストから、アトリビュート エ ディタでルックアップ テーブルを選択できます。ウェアハ ウス内にある名前の異なる 2 列が、同じアトリビュートに関 する情報を表す場合があります。レポートでアトリビュート を使用するときに完全で正確な結果を得るためには、これら の名前の異なる 2 列を同じアトリビュートにマップする必要 があります。異種の列名については、「異なる列名の結合 : 異種マッピング」（258 ページ）で説明します。 たとえば、Customer_ID、Name、SSN という 3 つのフォー ムを含むテーブルと、Customer _ID、Email という 2 つ のテーブルを含むルックアップ テーブルがあるとします。 この場合、アトリビュートは Customer_ID、Name、SSN、 Email という 4 つのフォームを持ち、2 つのテーブルは共通 する列（ID 列）によって結合されます。 フォームの表示 : アトリビュート フォームのプロパティ アトリビュート フォームのプロパティは、フォームの表示 に影響を与える設定です。MicroStrategy Desktop でアトリ ビュート エディタまたは Architect を使用してフォームを作 成するときに、フォームごとにプロパティを選択する必要が あります。アトリビュート エディタでは、新規アトリ ビュート フォームの作成時、または既存アトリビュート フォームの変更時に、これらのプロパティを利用できます。 Architect では、これらのプロパティは [ プロパティ ] ペイン で変更できます（「[ プロパティ ] ペインでのアトリビュート の変更」を参照）。 アトリビュート フォームのプロパティには次のものがあり ます。 • カテゴリ : 各種フォームをグループ化する際に役立ちま す。標準のカテゴリは「ID」、「DESC」、「なし」です。 アトリビュート エディタで新規フォーム カテゴリを作成 できます。 複数の説明フォームを必要とするアトリビュートがある 場合は、最も使用頻度が高いか、最も重要度の高い説明 フォームをアトリビュートの DESC フォームにマップす 250 列データの説明と識別子 : アトリビュート フォーム © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド ビジネス データのコンテキスト : アトリビュート 7 るのが賢明です。各アトリビュートに DESC フォームは 1 つだけです。その他の説明フォームは「なし」フォー ムにマップする必要があります。DESC アトリビュート フォームと「なし」アトリビュート フォームは MicroStrategy では区別しないで使用されますが、使用頻 度の高い説明フォームや最も重要度が高い説明フォーム をマップすれば、プロジェクト デザイナがそのアトリ ビュート フォームをその他の副次的なアトリビュート フォームから識別しやすくなります。 © 2010 MicroStrategy, Inc. • 書式タイプ : どのようにフォームが表示され、フィルタ が定義されるかを制御します。たとえば、書式タイプと して [Big Decimal] を指定すると、桁数が 15 桁を超える フォームに条件を適用するときに精度を維持できます。 Big Decimal については、 「データ タイプ」（441 ページ） で詳しく説明します。 • レポートの並べ替え : レポートに含めるアトリビュート フォームのデフォルトの並べ替え順序を指定します。ド ロップダウン リストから [ 昇順 ]、[ 降順 ]、[ なし ] のいず れかを選択します。1 つのアトリビュートの複数のアト リビュート フォームでデフォルトの並べ替え順序が定義 されている場合のアトリビュート フォームの並べ替え順 序については、以下の「複数のアトリビュート フォーム のレポートでのデフォルト並べ替え順序」を参照してく ださい。 • ブラウズ並べ替え : アトリビュート フォームをデータ エ クスプローラで表示するときの、デフォルトの並べ替え 順序を指定します。ドロップダウン リストから [ 昇順 ]、 [ 降順 ]、[ なし ] のいずれかを選択します。データ エクス 「レポートでの階層ブラウズの有効 プローラについては、 化 : データ エクスプローラ」（318 ページ）で説明しま す。 • 複数言語をサポート : アトリビュート フォームの情報 が、データの国際化を使用して複数言語で表示できるか どうかを指定します。データを複数言語で表示できるよ うにアトリビュート フォームを定義する方法について は、「アトリビュート エレメントのデータ国際化のサ ポート」（245 ページ）を参照してください。 列データの説明と識別子 : アトリビュート フォーム 251 7 ビジネス データのコンテキスト : アトリビュート プロジェクト デザイン ガイド 複数のアトリビュート フォームのレポートでのデ フォルト並べ替え順序 アトリビュート フォームの作成時には、「フォームの表示 : アトリビュート フォームのプロパティ」で説明した、[ レ ポートの並べ替え ] オプションを選択することにより、レ ポートでの並べ替え順序をアトリビュート フォームごとに 指定できます。 同じアトリビュートの複数のアトリビュート フォームで昇 順または降順の並べ替え順序を指定した場合は、デフォルト の並べ替え順序で先頭にくるアトリビュート フォームが、 レポートでのアトリビュートの並べ替えに使用されます。デ フォルトの並べ替え順序で先頭にくるアトリビュート フォームがレポートに含まれない場合は 2 番目、2 番目も含 まれない場合は 3 番目のアトリビュート フォームが使用さ れます。 たとえば、MicroStrategy Tutorial プロジェクトの "Customer" アトリビュートには、次に示す 5 つのアトリビュート フォームが含まれています。 5 つのアトリビュート フォームのうち、"Last Name" だけに レポートのデフォルトの並べ替え順序が定義されています。 ここで "Address" フォームに降順の並べ替え順序が指定され るように変更します。"Customer" を含むレポートで "Last Name" と "Address" の両方を使用すると、顧客は "Last Name" の昇順に並べ替えられます。これは、"Last Name" フォーム が "Address" フォームより先に作成されたため、並べ替えで も先に使用されるからです。レポートから "Last Name" フォームを削除すると、顧客は「住所」の降順で並べ替えら れます。 これは、レポート内のアトリビュートをアトリビュート フォームによって並べ替える機能のデフォルトの動作です。 レポート内でアトリビュート フォームを並べ替える方法は 変更できることに注意してください。レポートで高度な並べ 替えを使用して、アトリビュート フォーム、メトリック、 およびその他のレポート オブジェクトの並べ替えを指定で 252 列データの説明と識別子 : アトリビュート フォーム © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド ビジネス データのコンテキスト : アトリビュート 7 きます。レポートで定義された並べ替えは、アトリビュート フォームで定義されているデフォルトの並べ替えよりも優先 されます。高度な並べ替えの詳細は、『MicroStrategy 上級レ ポーティング ガイド』を参照してください。 アトリビュート フォーム式 アトリビュートは一種の情報の入れ物として機能し、ファク ト データにコンテキストを提供します。たとえば、 "Customer" アトリビュートは顧客に関する情報（名前、住所 など）を保持します。これらの情報をまとめたものを、アト リビュート フォームと呼びます。アトリビュート フォーム 式 は 、ウェアハウス内のどの列が、SQL 内でアトリビュー ト フォームの表現として使用されるかを定義します。すべ てのアトリビュートには、少なくとも 1 つの式が必要です。 たとえば、"Customer First Name" アトリビュート フォームの フォーム式は CUST_FIRST_NAME、"Customer Last Name" ア トリビュート フォームのフォーム式は CUST_LAST_NAME です。この場合、ウェアハウス内の CUST_FIRST_NAME 列 と CUST_LAST_NAME 列によって、名前と姓の情報がそれぞ れ提供されます。 複数の式をそれぞれ異なるテーブルに持つことは可能です が、1 つのフォームで 1 つのソース テーブルに 2 つの異なる 式を持つことはできません。 式はアトリビュート列と定数を使用して作成し、数学演算子 （+、-、/、* など）を使用できます。ただし、暗黙のアトリ ビュートの式は列を含みません。暗黙のアトリビュートは宣 言された定数だけを使用するからです。 フォーム式は Apply 関数でも作成できます。各種の Apply 関 数は、『MicroStrategy 上級レポーティング ガイド』の付録 「パススルー式」で説明しています。 アトリビュート フォーム式には次の種類があります。 • 「シンプル式」（254 ページ）: シンプルなフォーム式は、 データ ウェアハウス内の列を通じてデータにアクセスし ます。 © 2010 MicroStrategy, Inc. 列データの説明と識別子 : アトリビュート フォーム 253 7 ビジネス データのコンテキスト : アトリビュート プロジェクト デザイン ガイド • 「派生式」 （256 ページ）: 派生フォーム式は、データ ウェ アハウス内の列に何らかの数学計算を実行することで、 アトリビュート フォームを作成します。 • 「異なる列名の結合 : 異種マッピング」（258 ページ）: 異 種のマッピングによって、データ ウェアハウス内の名前 が異なる複数の列を、1 つのアトリビュート フォームと して使用できます。 • 「暗黙の式」 （261 ページ）: 暗黙のフォーム式は、データ ウェアハウス内に格納されているデータとは、直接的に は関係がありません。この種のフォーム式は、複数の列 を結合または使用してデータを生成し、仮想データを作 成します。 シンプル式 シンプル式は、ウェアハウス内の 1 列に基づいて生成されま す。シンプル式の定義には、対象の列が存在するテーブルが 含まれます。 たとえば、MicroStrategy Tutorial プロジェクトに含まれてい る "Category" アトリビュートには、シンプル式で定義される ID、Description という 2 つのフォームがあります。ID フォームの式は CATEGORY_ID 列、Description フォームの式 は CATEGORY_DESC 列です。どちらの列も LU_CATEGORY テーブルに含まれています。 例 : シンプル式によるアトリビュート フォームの作成 ある小売業者が、自社 Web サイトにあるフィードバック アンケートに協力することを条件に、顧客の購入額から 20 ％ 割引するキャンペーンを開始しました。この小売業者は、 アンケートで集めたデータを分析して、将来の製品マーケ ティングの向上に役立てたいと考えています。 顧客はアンケートを通じて、生年月日などさまざまな情報を 提供します。データが収集されると、生年月日データは最終 的に小売業者のデータ ウェアハウスに格納され、適切な ルックアップ テーブルが MicroStrategy プロジェクトに追加 されます。 254 列データの説明と識別子 : アトリビュート フォーム © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド ビジネス データのコンテキスト : アトリビュート 7 この時点でプロジェクト デザイナは、顧客の生年月日を含 む列を "Customer"（顧客）アトリビュートのアトリビュート フォームとして追加する必要があります。これにより、レ ポート デザイナは、レポートの顧客名の横に生年月日を表 示できるようになります。 "Customer" アトリビュートにアトリビュート フォームとし て "Customer Birth Date"（顧客の生年月日）を作成するには、 次の手順に従います。 シンプル式によるアトリビュート フォームの作成は、 Architect でも実行できます（「アトリビュートの作成」（150 ページ）を参照）。 シンプル式でアトリビュート フォームを作成するには 1 MicroStrategy Desktop で MicroStrategy Tutorial プロジェク トを含むプロジェクト ソースにログインし、さらに MicroStrategy Tutorial にログインします。 2 [ スキーマ オブジェクト ] フォルダまでナビゲートして [ アトリビュート ] フォルダを開き、さらに [ 顧客 ] フォル ダを開きます。 3 "Customer" アトリビュートをダブルクリックします。 アトリビュート エディタが開きます。 4 [ 新規作成 ] をクリックします。[ 新規アトリビュート フォームを作成 ] ダイアログ ボックスが開きます。 5 [ ソース テーブル ] ドロップダウン リストから LU_CUSTOMER テーブルを選択します。このテーブル に顧客の生年月日データが格納されています。 6 CUST_BIRTHDATE 列をダブルクリックして右側の [ フォーム式 ] ペインに追加します。マッピング方法は、 デフォルトの [ 自動 ] のまま変更しません。 7 [OK] をクリックします。[ 新規アトリビュート フォーム を作成 ] ダイアログ ボックスが開きます。 8 [ フォーム概要 ] 領域で、[ 名前 ] フィールドに「Customer Birth Date」と入力します。 © 2010 MicroStrategy, Inc. 列データの説明と識別子 : アトリビュート フォーム 255 7 ビジネス データのコンテキスト : アトリビュート プロジェクト デザイン ガイド 9 「Customer Birth Date」は "Customer" の ID フォームでも主 説明フォームでもないため、[ 使用するカテゴリ ] ドロッ プダウン リストから [DATE] を選択します。 10 [OK] をクリックします。アトリビュート エディタの [ ア トリビュート フォーム ] ペインに、"Customer Birth Date" アトリビュート フォームが新たに追加されます。 11 これは例に過ぎず、変更を保存しなくてもアトリビュー ト エディタを閉じることができます。 派生式 派生式は、ウェアハウス内の列、数学演算子、関数、および 定数を組み合わせて作成されます。単純な式はウェアハウス テーブル内の 1 つの列だけで値が決まりますが、派生式は 1 つ以上の列と演算子、および値を使用して定義されます。定 数の追加、他の列の追加、式の絶対値設定など、列に対する あらゆる操作が派生式を生成します。 たとえば、年齢や誕生日を計算する派生アトリビュート を 作成できます。Date of Birth（生年月日）列と Current Date （現在日付）列の差を計算することにより、2 つの列から派 生させた、顧客や社員の年齢を保持するアトリビュートを作 成できます。この方法で年齢を計算するアトリビュートを作 成しておけば、年齢が変わってもアトリビュートの値が自動 的に更新されます。年齢を表すアトリビュートを作成する場 合に定数を組み込むと、顧客や社員が誕生日を迎えるたびに アトリビュートの更新する必要があります。 例 : 派生式によるアトリビュート フォームの作成 顧客名をデータベース内の 2 列（CUST_FIRST_NAME、 CUST_LAST_NAME）に格納しており、レポートでは顧客の 名前と姓を組み合わせて、1 つのエントリとして表示する場 合を想定します。この場合は、2 つの文字列から構成される 派生フォーム式 Name を使用します。"Customer" アトリ ビュートを使用して、Name の派生式を次のように定義しま す。 CUST_FIRST_NAME + “ “ + CUST_LAST_NAME 256 列データの説明と識別子 : アトリビュート フォーム © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド ビジネス データのコンテキスト : アトリビュート 7 レポートでは、この情報は Name 列の下に Mary Jones の ように表示されます。Name の派生式を次のように Last Name, First Name の表記で作成することもできます。 CUST_LAST_NAME + “, “ + CUST_FIRST_NAME この式を使用すると、Name 列の下に Jones, Mary という 表記で名前が表示されます。 派生式で使用する計算と関数は、データベースから データを取得するために役立ちますが、使用している データベース特有の SQL 構文に式を適合させる必要 があります。データベースやその他のデータ ソース でサポートされていない構文を使用すると、SQL ク エリと結果レポートが正しくないことがあります。 シンプル式によるアトリビュート フォームの作成は、 Architect でも実行できます（「派生アトリビュート フォーム 式の作成」（159 ページ）を参照）。 派生式でアトリビュート フォームを作成するには 1 MicroStrategy Desktop で MicroStrategy Tutorial プロジェク トを含むプロジェクト ソースにログインし、さらに MicroStrategy Tutorial にログインします。 2 [ スキーマ オブジェクト ] フォルダまでナビゲートして [ アトリビュート ] フォルダを開き、さらに [ 顧客 ] フォル ダを開きます。 3 "Customer" アトリビュートをダブルクリックします。 アトリビュート エディタが開きます。 4 [ 新規作成 ] をクリックします。[ 新規アトリビュート フォームを作成 ] ダイアログ ボックスが開きます。 5 [ ソース テーブル ] ドロップダウン リストから LU_CUSTOMER テーブルを選択します。このテーブル には、顧客の名前と姓が格納されています。 6 CUST_LAST_NAME 列をダブルクリックして右側の [ フォーム式 ] ペインに追加します。 © 2010 MicroStrategy, Inc. 列データの説明と識別子 : アトリビュート フォーム 257 7 ビジネス データのコンテキスト : アトリビュート プロジェクト デザイン ガイド 7 [ フォーム式 ] ペインで、カーソルを [CUST_LAST_NAME] の右側に置き、「+ “, “ +」と入 力します。 8 CUST_FIRST_NAME 列をダブルクリックして右側の [ フォーム式 ] ペインに追加します。式が次のように定義 されます。 9 マッピング方法として [ 自動 ] を選択します。 10 [OK] をクリックします。[ 新規アトリビュート フォーム を作成 ] ダイアログ ボックスが開きます。 11 [ フォーム概要 ] 領域で、[ 名前 ] フィールドに「Last Name, First Name」と入力します。 12「Last Name, First Name」は "Customer" の ID フォームでも 主説明フォームでもないため、[ 使用するカテゴリ ] ド ロップダウン リストから [ なし ] を選択します。 13 [OK] をクリックします。アトリビュート エディタの [ ア トリビュート フォーム ] ペインに、新しいアトリビュー ト フォームが追加されます。 14 これは例に過ぎず、変更を保存しなくてもアトリビュー ト エディタを閉じることができます。 異なる列名の結合 : 異種マッピング 異種マッピングにより、Intelligence Server は異なる複数の列 名を結合できます。特定のフォームに複数の式を定義した場 合、テーブルと列名によって必要とされるときに、異種マッ ピングが自動的に実行されます。 ソース システムが異なると、情報が格納されるコンテキス トも一様ではないため、同じビジネス概念を表す複数の列 が、さまざまなテーブルに分散している可能性があります。 258 列データの説明と識別子 : アトリビュート フォーム © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド ビジネス データのコンテキスト : アトリビュート 7 たとえば、MicroStrategy Tutorial の "Day"（日）アトリ ビュートの ID フォームには 2 つの式が含まれています。 Day_Date 列は LU_DATE テーブルに、Order_Date 列は ORDER_DETAIL テーブルと ORDER_FACT テーブルにありま す。 上の例で異種マッピングを使用すれば、"Day" アトリビュー トを、データ ウェアハウス内で同じ "Day" の概念を表して いるすべての列にマップできます。Order_Date と Day_Date を "Day" アトリビュートにマップすると、"Day" アトリビュートに関する情報をレポートに表示するときに、 両方の列が使用されます。 式は、その中で使用している列を含む複数のソース テーブ ルにリンクされます。それらの列を含むテーブルのうち、ア トリビュート定義の一部として使用する列を、必要な数だけ 選択できます。 エディタの 選択したテーブルは、アトリビュート [ フォーム式 ] 領域の右側にある [ ソース テーブル ] 領 域に表示されます。 同じアトリビュートに異種マッピングする各列は同じ データ タイプであるか、使用している RDBMS で適 切に結合できる、一意または類似したデータ タイプ でなければなりません。たとえば、ほとんどのデータ ベースでは Text 型のデータと Number 型データを結合 することはできません。ただし、Number データ タイ プの列は、データベース プラットフォームによって は Integer データ タイプの列と結合できる場合があり ます。 異種列マッピングによるアトリビュート フォームの作成は、 Architect でも実行できます（「異なる列名の結合 : 異種マッ ピング」（161 ページ）を参照）。 異種列マッピングを使用してアトリビュート フォームを作成する には 1 MicroStrategy Desktop で MicroStrategy Tutorial プロジェク トを含むプロジェクト ソースにログインし、さらに MicroStrategy Tutorial にログインします。 © 2010 MicroStrategy, Inc. 列データの説明と識別子 : アトリビュート フォーム 259 7 ビジネス データのコンテキスト : アトリビュート プロジェクト デザイン ガイド 2 [ スキーマ オブジェクト ] フォルダまでナビゲートして [ アトリビュート ] フォルダを開き、さらに [ 時間 ] フォル ダを開きます。 3 "Day" アトリビュートをダブルクリックします。アトリ ビュート エディタが開きます。 4 [ 新規作成 ] をクリックします。[ 新規フォーム式を作成 ] ダイアログ ボックスが開きます。 5 [ ソース テーブル ] ドロップダウン リストから LU_DAY テーブルを選択します。 6 DAY_DATE 列をダブルクリックして右側の [フォーム式] ペインに追加します。マッピング方法は、デフォルトの [ 自動 ] のまま変更しません。 7 [OK] をクリックします。[ 新規アトリビュート フォーム を作成 ] ダイアログ ボックスが開きます。 8 [ 新規作成 ] をクリックします。[ 新規フォーム式を作成 ] ダイアログ ボックスが開きます。 9 [ ソース テーブル ] ドロップダウン リストから ORDER_DETAIL テーブルを選択します。 10 ORDER_DATE 列をダブルクリックして右側の [ フォー ム式 ] ペインに追加します。マッピング方法は、デフォ ルトの [ 自動 ] のまま変更しません。 11 [OK] をクリックします。[ 新規アトリビュート フォーム を作成 ] ダイアログ ボックスが開きます。 これで 1 つのアトリビュート フォーム定義に 2 つの式が 追加されました。これらの式は互いに異なるテーブルを 情報のソースとして使用します。この手順を繰り返して、 異種の列を必要な数だけアトリビュート フォームに追加 できます。 12 [ フォーム概要 ] 領域で、[ 名前 ] フィールドに「Date Example」と入力します。 13 これは例であるため、[ 使用するカテゴリ ] ドロップダ ウン リストから [ なし ] を選択します。 260 列データの説明と識別子 : アトリビュート フォーム © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド ビジネス データのコンテキスト : アトリビュート 7 14 [OK] をクリックします。アトリビュート エディタの [ ア トリビュート フォーム ] ペインに、Date Example アトリ ビュート フォームが新たに追加されます。 15 これは例に過ぎず、変更を保存しなくてもアトリビュー ト エディタを閉じることができます。 暗黙の式 ほとんどのアトリビュートはウェアハウス内の 1 列以上の物 理列に直接マップされますが、暗黙のアトリビュート は ウェアハウス内に実際には存在しない仮想的な（または一定 の）アトリビュートです。そのようなアトリビュートは暗黙 の式を持ちます。暗黙の式は定数で、実際の列には保存され ません。暗黙の式は列の名前では定義されず、指定する定数 で定義されます。どのような定数も使用可能で、たとえば RushOrder=‘Yes’ のように指定します。一部のアトリビュー ト定義は、列の代わりに特定テーブル内の 1 つの行の有無に よって示唆することもできます。暗黙のアトリビュートは、 情報の分析と取得に役立ちます。 MicroStrategy Tutorial に含まれている "Rush Order"（特急注 文）は暗黙のアトリビュートの一例です。より確実に出荷記 録を管理するため、どの注文が特急注文であるかをレポート に示す場合は、"Rush Order" のような暗黙のアトリビュート が役立ちます。 "Rush Order" アトリビュートは 2 つの式で定義されます。1 つは Order_Fact テーブル内の Rush_Order 列、もう 1 つは暗 黙の式 "Y"（YES の意味）です。この暗黙の式によって緊急 注文が識別されます。"Order" アトリビュートと "Rush Order" アトリビュートをテンプレートに持つレポートでは、 緊急注文の Rush Order 列に "Y " と表示されます。 暗黙のアトリビュートは通常は使用しませんが、上記 のような特殊なケースで役立ちます。 アトリビュートのデータ タイプの変更 : 列別名 列別名を使用すると、特定のアトリビュート フォームに、 デフォルトのデータ タイプの代わりに使用するデータ タイ プを指定できます。列別名でさらに適切なデータ タイプを 指定すれば、SQL のエラーを回避しやすくなります。 © 2010 MicroStrategy, Inc. 列データの説明と識別子 : アトリビュート フォーム 261 7 ビジネス データのコンテキスト : アトリビュート プロジェクト デザイン ガイド また、データ ウェアハウス内のデータも、より効果的に利 用できます。アトリビュートの場合も、列別名の機能はファ クトの場合と同様です。デフォルトでは、アトリビュート フォームのデータ タイプは、フォームの定義に使用された 列のデータ タイプを継承します。この継承は MicroStrategy によって管理され、データベースまたはその他のデータ ソース内でのデータ タイプに可能な限り近いデータ タイプ の使用が試みられます（MicroStrategy による合致データ タ イプの選択方法については、「データ タイプ」（441 ページ） を参照）。ただし、状況によってはデータ タイプの変更が必 要になることもあります。以下に、そのような状況のいくつ かの例を示します。 データ ウェアハウス内に "Accounts"（口座）アトリビュー トのルックアップ テーブルがあり、ID 列は口座番号で、 データベース内に DECIMAL(18, 0) の値として格納されてい るとします。この列は高精度であるため、アトリビュート フォームの列別名を変更し、特殊なデータ タイプ Big Decimal にマップする必要があります。これにより、 "Account"（口座）アトリビュートにフィルタリングやドリ ル、またはページバイを実行しても精度を維持できます。 もう 1 つの例として、年情報のルックアップ テーブルが ウェアハウス内に存在しないときに "Year" アトリビュート を作成する場合を考えます。たいていのデータベース プ ラットフォームには、Date データ タイプから日付情報の一 部分を抽出する関数があります。たとえば、SQL Server には 日付から年だけを抽出する Year 関数があります。そのよう な場合は、次のフォーム式で "Year" アトリビュートを作成 できます。 ApplySimple("Year(#0)",[Date_Id]) ApplySimple 式の構文は SQL Server 向けです。 この 使用しているデータベースやデータ ソースのタイプ によっては、構文を変更しなければならない場合もあ ります。 このアトリビュートのデータ タイプは、自動的に Date に設 定されます。これは Date_ID のデータ タイプが Date だか らです。ところが、計算結果は 2002 などの年となり、これ は整数です。 列別名のデータ タイプを変更しないと、システムは一時 SQL テーブルを作成するときに Date データ タイプを使用 し、この列に整数データを挿入しようとします。これはすべ 262 列データの説明と識別子 : アトリビュート フォーム © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド ビジネス データのコンテキスト : アトリビュート 7 てのデータベース プラットフォームで問題になるとは限り ませんが、データベースによってはエラーを返します。デー タ タイプの不一致によるエラーを回避するには、アトリ ビュート フォームの列別名のデータ タイプを、デフォルト の Date から Integer に変更する必要があります。 列別名によって、アトリビュート フォームで使用される データ タイプを指定できるほか、MicroStrategy が生成する SQL で使用される列別名を指定することもできます。カス タム式や複数の列を使用してフォーム式を作成（「アトリ ビュート フォーム式」（253 ページ）の説明を参照）する場 合、アトリビュート フォームの列別名はデフォルトで CustCol（2 番目以降は CustCol_1、CustCol_2）になり ます。次に示す SQL 例では、太字部分が列別名です。 SELECT Year(a12.Date_Id) CustCol_1, sum(a11.Tot_Dollar_Sales) WJXBFS1 FROM YR_CATEGORY_SLS a11 cross join TRANS_DATE_LW_LY a12 GROUP BY Year(a12.Date_Id) 列別名自体は、実際の結果やレポートには影響しませんが、 もっとわかりやすい名前に変更できます。上の例は単純です が、列別名がわかりやすい名前だと、特に複雑なレポートの SQL のトラブルシューティングのときに役立つ場合があり ます。 列別名はアトリビュート エディタで作成します。Architect を使用して列別名を作成することもできます（「アトリ ビュートのデータ型の作成と変更 : 列別名」（163 ページ） を参照）。 前提条件 • この手順は、有効なアトリビュート式を持つアトリ ビュートが作成済みで、そのアトリビュートに列別名を 新規作成する場合を想定しています。 アトリビュートの列別名を作成するには 1 MicroStrategy Desktop で、新しい列の別名を作成するア トリビュートを含むプロジェクト ソースにログインしま す。 2 アトリビュートを右クリックし、[ 編集 ] を選択します。 アトリビュート エディタが開きます。 © 2010 MicroStrategy, Inc. 列データの説明と識別子 : アトリビュート フォーム 263 7 ビジネス データのコンテキスト : アトリビュート プロジェクト デザイン ガイド 3 アトリビュート フォームを選択して [変更] をクリックし ます。[ アトリビュート フォームを変更 ] ダイアログ ボッ クスが開きます。 4 [ 列別名 ] タブを選択します。 5 [ 列別名 ] 領域で [ 変更 ] をクリックします。[ 列エディタ 列を選択 ] ダイアログ ボックスが開きます。 6 [ 新規作成 ] を選択して新しい列別名を作成します。[ 列エ ディタ - 定義 ] ダイアログ ボックスが開きます。 7 列別名の次のプロパティを変更できます。 • 列名 : このアトリビュート列を含む SQL ステート メントで使用される列の別名。 • データ タイプ : ファクトのデータ タイプ。 MicroStrategy でサポートされているデータ タイプに ついては、「データ タイプ」（441 ページ）を参照して ください。 • 選択するデータ タイプによっては、列別名のバイト 長、ビット長、精度、スケール、またはタイム ス ケールを指定できます。これらの各プロパティの詳細 については、MicroStrategy Desktop オンライン ヘルプ を参照してください。 8 [OK] をクリックして変更を保存し、[ 列エディタ - 列を 選択 ] ダイアログ ボックスに戻ります。 9 [OK] をクリックして変更を保存し、アトリビュート エ ディタに戻ります。 10 [ 保存して閉じる ] を選択して変更を保存します。 アトリビュート フォームと個別のアトリビュート アトリビュート フォームは、アトリビュートへの一種の追 加説明です。一方、個別のアトリビュートは互いに 1 対多、 または多対多の関係にあるレポート エレメントまたはグ ループバイ エレメントと見なすことができます。アトリ ビュートにマップするデータは、別のアトリビュート、また はアトリビュートのアトリビュート フォームとして表現で きます。 264 列データの説明と識別子 : アトリビュート フォーム © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド ビジネス データのコンテキスト : アトリビュート 7 次に該当する場合、データはアトリビュートではなくアトリ ビュート フォームにマップしてください。 • アトリビュートとデータの間に 1 対 1 関係が存在する。 • データをグループ分けしない。 データを特定のアトリビュートのアトリビュート フォーム にするか、あるいは単独のアトリビュートにするかは、通 常、プロジェクト デザインの論理データ モデリング段階で 決定します。データをアトリビュート フォームとしてモデ ル化するか、単独のアトリビュートとしてモデル化するかの 判断の詳細は、「アトリビュート フォーム」（38 ページ）を 参照してください。 アトリビュート関係 プロジェクトのアトリビュートを作成すると、エンジンが SQL を生成する方法、テーブルと列の結合 / 使用方法、およ びテーブル間の関係を、アトリビュート関係を定義して決定 できます。 親子関係を定義することによって、直接的な関係がある複数 のアトリビュートを相互にリンクできます（「アトリビュー ト関係」（26 ページ）を参照）。アトリビュート間に定義す る関係は、アトリビュート エレメント（アトリビュートの 実際のデータ値）によって決まります。 作成する親子関係によって、プロジェクト内のシステ ム階層が決定されます。 アトリビュート関係の有無は、レポートの作成に影響を与え ます。"Country"（国）と "City"（都市）など、互いに関係の ある 2 つのアトリビュートを含むレポートは、問題なく実行 できます。一方、互いに関係のない 2 つのアトリビュートを 含むレポートには、2 つのアトリビュートと同じか、より下 位のレベルのファクトに基づくメトリックが必要です。その ようなメトリックがないとデカルト結合が行われますが、こ れは通常、望ましくありません。デカルト結合（直積結合） では、テーブル内のすべての行が他のテーブル内のすべての 行に結合されるため、データベース負荷が非常に大きくなり ます。 © 2010 MicroStrategy, Inc. アトリビュート関係 265 7 ビジネス データのコンテキスト : アトリビュート プロジェクト デザイン ガイド プロジェクト内のアトリビュートの関係は、MicroStrategy Desktop で定義できます。アトリビュートの関係を定義する 方法について、プロジェクト デザインの初期段階で行う場 合は、「複数のアトリビュートの同時作成」（229 ページ） で、プロジェクト作成後に行う場合は、「親アトリビュート と子アトリビュートの表示および編集」（268 ページ）でそ れぞれ説明しています。 複数のアトリビュート間には、関係が存在する場合と存在し ない場合があります。 • 関係が存在する場合 : 互いに関係する 2 つ以上のアトリ ビュート間に親子関係が定義されます。この関係は、ア トリビュートのルックアップ テーブルまたは関係テーブ ルを通じて定義されます。 アトリビュート間には 4 種類の関係があります。これら の関係は、関連するアトリビュート内のアトリビュート エレメントによって定義されます。それぞれの種類の関 係について、以下に説明します。 1 対 1 : 親アトリビュートの各エレメントが子アトリ ビュートの 1 つのエレメントだけに対応し、すべての 子アトリビュートが親アトリビュートの 1 つのエレ メントだけに対応する関係。1 対 1 関係の一般的な例 としては、市民と納税者 ID の関係があります。一人 の市民が保有できる納税者 ID は 1 つだけで、1 つの 納税者 ID は一人の市民だけに割り当てられます。 1 対多 : 親アトリビュートの各エレメントが子アトリ ビュートの 1 つ以上のエレメントに対応し、すべての 子アトリビュートが親アトリビュートの 1 つのエレ メントだけに対応する関係。これが最も一般的なアト リビュート関係です。たとえば、年と四半期の間には 1 対多関係があります。1 年には複数の四半期があり、 どの四半期も 1 つの年だけに属します（この場合の四 半期は、2006 年第 4 四半期、2007 年第 1 四半期など、 年を伴う形で定義されているものとします）。 多対 1 : 親アトリビュートの各エレメントが子アトリ ビュートの 1 つのエレメントだけに対応し、すべての 子アトリビュートが親アトリビュートの 1 つ以上のエ レメントに対応する関係。多対 1 関係は 1 対多関係と 同種の関係を、異なる視点から定義したものです。た とえば、前述したように年と四半期との間には 1 対多 関係がありますが、これは四半期と年との間で多対 1 関係があることを意味します。 266 アトリビュート関係 © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド ビジネス データのコンテキスト : アトリビュート 7 多対多 : 親アトリビュートの各エレメントが複数の子 を持つことがあり、子アトリビュートの各エレメント も複数の親を持ちうる関係。銀行の顧客と口座は多対 多関係の一例です。一人の顧客が複数の口座を持つこ とが可能で、口座は複数の顧客に関連する場合があり ます（行動名義の口座など）。 アトリビュートも、アトリビュート関係の連鎖を通じて 他のアトリビュートと関係を持つ場合があります。この ようなアトリビュートは通常、同じ階層に属します。た とえば、顧客分析モジュール（Customer Analysis Module） の "Geography"（地理）階層には、アトリビュート "Customer Region"（顧客地域）、"Customer State"（顧客 州）、および "Customer City"（顧客都市）が含まれていま す。 この場合、"Customer Region" と "Customer State" は直接の 関係があり、"Customer State" と "Customer City" の間にも 直接の関係があります。"Customer City" と "Customer Region" には直接の関係はありませんが、両者は "Customer State" によって関連付けられています。これに より、"Customer Region" と "Customer City" を同じレポー トに含めて、顧客地域別に顧客の都市を表示できます。 • © 2010 MicroStrategy, Inc. 関係が存在しない場合 : アトリビュート間に親子関係が 何も定義されておらず、アトリビュート関係の連鎖によ る関係も存在しません。これらのアトリビュートの場合、 ルックアップ テーブルにも関係テーブルにも関係は存在 しません。関係が存在しない複数のアトリビュートも、 同じファクト テーブルに共存して、ファクトにコンテキ ストを付与できます。たとえば、"Customer" アトリ ビュートと "Day" アトリビュートには互いに関係があり ません。特定の顧客と日の組み合わせが意味を持つのは、 ファクトが関連付けられた場合だけです。たとえば、あ る医療関係の会社に勤めている Don Addison さんが、 2003 年 1 月 5 日に社用で 2500 ドルの支払いを行ったと します。この場合、1 つのレポートで関係のない複数の アトリビュートを使用するときに注意が必要です。ただ し、プロジェクト デザインでは、これらのアトリビュー トは通常、比較的容易に扱えます。 アトリビュート関係 267 7 ビジネス データのコンテキスト : アトリビュート プロジェクト デザイン ガイド 親アトリビュートと子アトリビュートの表示および編集 アトリビュート間の関係は、アトリビュートに割り当てる親 子の指定によって決まります。アトリビュート間にどのよう な関係があり、どの種類の関係を共有するかによって、SQL の生成に使用されるシステム階層が定義されます。さらに、 生成される SQL によってレポートの出力内容が決定されま す。 親子関係は、新規プロジェクトのアトリビュートを選択した ときに指定されます。ただし、プロジェクトの作成後も、ア トリビュート間の関係は必要に応じて適宜変更できます。 たとえば、"Distribution Center" アトリビュートは "Call Center" アトリビュートの親であり、"Distribution Center" と "Call Center" の間には 1 対 1 関係が存在します。これは、1 つの配送センタ内に設置されているコール センタが 1 つだ けであることを意味します。一方、"Country" は "Distribution Center" の親であり、1 つの国には複数の配送センタがあり ます。したがって、これらのアトリビュートの間にあるのは 1 対多関係です。 アトリビュートに親子関係を割り当てると、ユーザ階層内で アトリビュートを互いに接続することが可能になります （「アトリビュートの構成とブラウズを行うための階層の作 成」（299 ページ）を参照）。また、レポートに不正な SQL と結果が生成された場合のトラブルシューティングでは、親 子関係の表示と変更が必要になる場合があります。 "Distribution Center" アトリビュートの親子関係を表示して編 集するには、以下の手順に従います。 アトリビュート間の関係は Architect でも定義できます。 Architect では、より直感的で親切なワークフローによって、 アトリビュート関係を定義しながら、複数のアトリビュート を表示して変更できます（「アトリビュート関係の定義」 （173 ページ）を参照）。 アトリビュートの親子関係を表示および編集するには 1 MicroStrategy Desktop で MicroStrategy Tutorial プロジェク トを含むプロジェクト ソースにログインし、さらに MicroStrategy Tutorial にログインします。 268 アトリビュート関係 © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド ビジネス データのコンテキスト : アトリビュート 7 2 [ スキーマ オブジェクト ] フォルダまでナビゲートして [ アトリビュート ] フォルダを開き、さらに [ 地域 ] フォル ダを開きます。 3 "Distribution Center" アトリビュートをダブルクリック します。アトリビュート エディタが開きます。 4 [ 子 ] タブをクリックします。"Call Center" アトリビュート のリストが、"Distribution Center" と共有している関係の 種類、および関係が属している関係テーブルと共に表示 されます。 配送センタ内に複数のコール センタが設置され、関係が 1 対 1 ではなくなったとします。この場合、"Call Center" と "Distribution Center" 間の関係の種類を変更する必要が あります。 5 関係の種類を変更するには、[ 関係タイプ ] ドロップダ ウン リストから [1 対多 ] を選択します。 6 この 2 つのアトリビュート間の関係は LU_Call_Ctr テーブル内で定義されていますが、LU_Employee テー ブルで定義するように変更します。関係テーブルを変更 するには、[ 関係テーブル ] ドロップダウン リストから LU_Employee テーブルを選択します。 7 これは例に過ぎず、変更を保存しなくても "Distribution Center" アトリビュートを閉じることができます。 多対多関係および結合子関係のサポート 多対多関係と結合子関係という 2 種類のアトリビュート関係 を適用すると、スキーマとウェアハウスのデザイン プロセ スがさらに複雑なものになる可能性があります。以下の項で は、これらの関係特有の特長を勘案し、ウェアハウスを効果 的にデザインするために考慮すべきポイントについて説明し ます。 説明する内容は主に論理モデル デザインに関連するもので すが、これらの内容に関係のある問題に直面したときには、 物理スキーマに関する実用レベルの知識が役立ちます。 © 2010 MicroStrategy, Inc. アトリビュート関係 269 7 ビジネス データのコンテキスト : アトリビュート プロジェクト デザイン ガイド 以下の項に進む前に、論理データ モデルと物理ウェアハウ ス スキーマとは何であり、どのようにして読み取って解釈 するかを理解している必要があります。論理データ モデル と物理ウェアハウス スキーマについては、2 章、「論理デー タ モデル」および 3 章、「論理データ モデルのウェアハウス の構造」でそれぞれ説明しています。これらの章では、ビジ ネス インテリジェンス データの概念的枠組みを計画し、作 成する方法が説明されています。 多対多関係 多対多関係を適用すると、ウェアハウスのデザイン プロセ スがさらに複雑になります。多対多関係が存在する場合に、 デザインを効果的に計画するには、いくつかの点に考慮する 必要があります。 以下に、多対多関係の現実的な例をいくつか示します。これ らの関係は、データ モデルとスキーマで注意して扱う必要 があります。 • 組織によっては各販売員が複数のコール センタを掛け持 ちしている場合があります。同様に、1 つのコール セン タには多数の販売員が所属しています。 • 製造プラントではいくつもの型の自動車が製造され、車 両の色もさまざまです。つまり、型が同じで色が異なる 自動車がある一方で、色は同じで型が異なる自動車もあ ります。 以下の項では、商品と色の例を通じて多対多関係を示し、こ の関係に対応するために取りうる選択肢について説明しま す。同じ商品で色が違う場合（赤、青、緑の帽子など）もあ れば、異なる商品の色が同じ場合（赤いドレス、帽子、靴、 ソックスなど）もあります。 通常、多対多関係に伴って起こり得る問題は次の 2 つです。 これらはどちらも、関係を正しくモデル化することで回避す ることが可能です。 270 アトリビュート関係 • 分析機能の喪失 • 重複カウント © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド ビジネス データのコンテキスト : アトリビュート 7 分析機能の喪失 色と商品の多対多関係で、ユーザが答えを求めるビジネス上 の質問は通常、次の 2 点です。 1 特定の商品にはどの色があるか 2 何通りの商品と色の組み合わせが販売されているか 最初の質問に答えるには、商品と色の可能なすべての組み合 わせをリストしたテーブルが必要です。1 対多関係は通常、 子のルックアップ テーブル内で定義されることを思い出し てください。 多対多関係では、その方法は使えません。代わりに、ウェア ハウス内に別の関係テーブルを確保する必要があります。次 の図は、商品と色のルックアップ テーブルと関係テーブル を示すものです。 Rel_Color_Item テーブルの各行が、商品と色の組み合わせを 表します。 © 2010 MicroStrategy, Inc. アトリビュート関係 271 7 ビジネス データのコンテキスト : アトリビュート プロジェクト デザイン ガイド 2 番目の質問に答えるには、色と商品の情報に加え、売上情 報を含むファクト テーブルが必要になります。次の図は、 上図と同じシナリオに、商品、色、および日付のキーを含む 売上情報のシンプルなテーブルを追加したものです。 テーブルだけでは、最初の質問に この図のファクト 答えるには不十分です。このファクト テーブルから 呼び出せるのは、実際に売上が記録された商品と色の 組み合わせだけです。このファクト テーブルでは、 商品と色の可能なすべての組み合わせのリストが得ら れるわけではなく、購入可能であっても、実際に販売 されたことのない商品と色の組み合わせは得られない ため、最初の質問に答えられないことになります。 つまり、アトリビュートの多対多関係で分析の柔軟性を維持 するためには、次の条件を満たす必要があります。 • アトリビュート間で可能なすべてのアトリビュート エレ メントの組み合わせを識別する、独立した関係テーブル を用意すること。 • 両方のアトリビュートの ID 列をファクト テーブルに含 めること。 これらの条件はいくつかの異なる方法で実装できま す。これらの方法については、「多対多関係の扱い」 （275 ページ）で説明します。 272 アトリビュート関係 © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド ビジネス データのコンテキスト : アトリビュート 7 重複カウント 分析機能の喪失は、多対多関係を扱うときの問題のひとつに 過ぎません。これと同様に重要な問題が、重複カウントで す。重複カウントは、次のすべての条件がそろったときに発 生します。 • 多対多関係にあるアトリビュートのどちらかのレベルと 同じか、それより上位のレベルでデータ集計を試みた。 • 関係が独立した関係テーブル内にある。 • 多対多関係にあるすべてのアトリビュートが、ファクト テーブルに含まれていない。 ここでは、上に示した例のファクト テーブルから色を取り 除いた場合を考えます。 © 2010 MicroStrategy, Inc. アトリビュート関係 273 7 ビジネス データのコンテキスト : アトリビュート プロジェクト デザイン ガイド 帽子、ドレス、ソックスという 3 つの商品があり、帽子とド レスは赤、青、緑の 3 色、ソックスには緑と青の 2 色がある とします。次の図は、このデータを含むルックアップ テー ブルと、簡単な売上データの一部を示しています。 複数カウントが発生する可能性があるのは、色別の売上を要 求するクエリを実行し、実質的には多対多関係の "Item" ア トリビュート レベルで集計する場合です。商品別の売上情 報を含むファクト テーブルには色が記録されていないため、 このクエリにはファクト テーブルと関係テーブルの両方が 必要です。 ファクト テーブルに色が含まれていないことが問題の原因 になります。ファクト テーブル内の特定商品の売上を、そ の商品の色と直接的に関連付ける手段がないからです。たと えば、色が赤の商品の売上を計算する代わりに、クエリで色 が赤のすべての商品の売上を、関係テーブルに基づいて集計 したとします。その場合、合計には青と緑の帽子とドレスも 含まれるため、色が赤の商品の実際の売上より大きな数字に なってしまいます。 以上のデータでは、たとえば以下の質問すべてに正確に答え ることはできません。 • 帽子の売上総額は ? 答えは 35 ドルで、これはファクト テーブルから直接計 算できます。 • 274 アトリビュート関係 色が赤の商品の売上総額は ? © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド ビジネス データのコンテキスト : アトリビュート 7 正確な答えは出せません。得られる値は 85 ドルですが、 これは赤いソックスがないため、帽子とドレスの売上総 額になります。購入されたドレスがすべて緑である可能 性もゼロではありませんが、ファクト テーブルに色が記 録されていないため、これを確認する手段はありません。 • 色が赤のドレスの売上総額は ? これについても、正確な答えは出せません。購入された ドレスがすべて本当に緑であれば 0 ドルですが、ファク ト テーブル内のデータに基づいて得られる値は 50 ドル です。 次の項では、多対多関係を扱うときに複数カウントを回避す るいくつかの方法を説明します。 多対多関係の扱い すでに説明しているように、多対多関係に関連するケースで は、一見単純な質問でも、答えを得るまでにいくつものス テップを経る必要があります。 多対多関係が存在する場合に、正確な回答が得られない質問 に具体的に対処するには、3 種類の方法を利用できます。こ れらの 3 種類の方法はいずれも柔軟性のレベルが異なってお り、柔軟性が高いほど複雑になります。いずれの場合も、次 の 2 つの基本的コンポーネントが存在していることが前提に なります。 • アトリビュート関係を定義する関係テーブル • 両方のアトリビュートの ID 列を含むファクト テーブル SQL Engine がレポート要求に応じて MicroStrategy SQL を生成するときに使用する規則は、MicroStrategy によって作成されます。上記の両方のテーブルを物理 的に実装しておけば、レポートにメトリックが含まれ ていない場合、SQL Engine は関係テーブルを使用し ます。レポートにメトリックが含まれている場合は、 クエリに回答するためにファクト テーブルを使用し ます。 テーブルに追加 以下のすべての手法で、ファクト データが必要です。つまり、ソース システム内で追 加データを取得しなければなりません。たとえば、購 入された各品目の色に関するデータが、ソース シス テム内に存在する必要があります。追加データがソー © 2010 MicroStrategy, Inc. アトリビュート関係 275 7 ビジネス データのコンテキスト : アトリビュート プロジェクト デザイン ガイド ス システム内で取得されないと、多対多関係を完全 には解決されず、特定の色の商品の売上を計算するこ とはできません。 方法 1 これは、多対多関係を効果的に管理するためには最もわかり やすい方法です。 この方法では、関係テーブルを別に作成（この例では Rel_Color_Item）し、次に示すように両方のアトリビュート の ID をファクト テーブルに含める必要があります。 方法 2 方法 2 では多対多関係を解消します。関係テーブルを別に作 成する必要もありません。 多対多関係から変換した複合アトリビュート関係を次に示し ます。1 つのアトリビュートをもう 1 つのアトリビュートの 子として扱い、最下位レベルのアトリビュートの複合キーを 276 アトリビュート関係 © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド ビジネス データのコンテキスト : アトリビュート 7 作成します。さらに、両方のアトリビュートの ID（この例 では Item_ID と Color_ID）をファクト テーブルに追加して います。 この方法では関係テーブルを別に作成する必要がない代わり に、商品の情報を色に関係なく表示したり、あるいはその逆 の表示を行うことができません。 方法 3 方法 3 は最も実用的なソリューションであり、次のような特 長があります。 • 方法 2 の複合アトリビュート関係を単純なアトリビュー ト関係に簡素化する。 • 商品と色の情報を個別にまたは組み合わせて表示できる。 • ファクト テーブルに必要なアトリビュート列が 1 列だけ で、2 列の場合より柔軟性が高い。 この方法では、"Color" または "Item" より下位のレベルに新 しいアトリビュートを作成する必要があります。このアトリ ビュートは基本的に "Color" と "Item" を連結したものであ り、これらの親アトリビュートとの間には 1 対多関係があり ます。これが "SKU" アトリビュートであり、小売データ モ デルや小売データ関係の状況で特に一般的に用いられます。 © 2010 MicroStrategy, Inc. アトリビュート関係 277 7 ビジネス データのコンテキスト : アトリビュート プロジェクト デザイン ガイド 最後に、"Color" と "Item" をファクト テーブルに追加する代 わりに、次の図のように新しい子アトリビュート "SKU" だ けを追加します。 この方法は、方法 1 とよく似ています。主な違いは、方法 1 で別に作成した関係テーブルに "SKU" 列が追加されている ことです。これにより、商品と色の個々の組み合わせの関係 が 1 つの値に展開されます。その結果、この単一の値をファ クト テーブルで使用できます。 方法 3 の主な問題点は、ビジネス モデルですでに同様な構 造が使用されている場合を除いて新規アトリビュートの作成 が必要になること、および ETL プロセスがさらに複雑にな る可能性があることです。 結合子関係 一部のアトリビュートは、他の間接的に関連する複数のアト リビュートの交点に存在します。そのようなアトリビュート は、結合子 と呼ばれます。 結合子関係は、クロスディメンション アトリビュート、テ キスト ファクト、あるいは品質とも呼ばれる特殊なアトリ ビュート同士を結合するものです。この関係は、これまでに 説明したモデル化スキームにはほとんど合致しません。結合 子関係はこれまでのアトリビュートと同様にモデル化するこ とで概念化できますが、ファクトと同じように複数のアトリ ビュート レベルの交点に存在します。 システムでは、この特殊なアトリ 多くのソース ビュートはフラグと呼ばれます。したがって、ソース システムのマニュアルでフラグに言及されている場 278 アトリビュート関係 © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド ビジネス データのコンテキスト : アトリビュート 7 合、それは結合子関係を指している可能性が高いと考 えることができます。 結合子関係は、実際には多対多関係の一種であり、1 つのア トリビュートが他の 2 つの、本来なら関連しないアトリ ビュートとの多対多関係を持ちます。" 販促 "、" 商品 "、 " 四半期 " という 3 つのアトリビュート間の関係がその一例 です。この場合、次の図に示すように、" 販促 " は " 商品 " および " 四半期 " の両方と多対多関係にあります。 販促の例としては、赤い色の商品を安く販売する「Red Sale」などがあります。この販促は通常、バレンタイン デー の前後やクリスマス シーズンに実施されます。 結合子関係のサポート 多対多関係の解決策の 1 つは、多対多関係に含まれるアトリ ビュートの関係テーブルを用意する方法です。この例では 2 つの関係テーブルを作成できます。1 つは "Promotion"（販 促）と "Item"（商品）の関係テーブルです。もう 1 つは © 2010 MicroStrategy, Inc. アトリビュート関係 279 7 ビジネス データのコンテキスト : アトリビュート プロジェクト デザイン ガイド "Promotion" と "Quarter"（四半期）の関係テーブルです（下 図参照）。 この 2 つのテーブルによって、次のような質問に答えること ができます。 • どの商品が、どの販促の対象になったか • どの四半期に、どの販促が実施されたか 一方、これらのテーブルだけでは、より詳しい分析が必要と なる以下の質問に答えることはできません。 • 特定の四半期で、どの商品がどの販促の対象になったか • 特定商品が、特定の種類の販促対象になったのは、どの 四半期であるか これらの質問に答えるには 2 つの関係テーブルを結合して、 3 つのアトリビュートすべての関係を定義するテーブルを 1 つ作成する必要があります。 結合子関係が正しく定義されるためには、この関係 テーブル内に関係が存在しなければなりません。ただ し、必ずしも専用の関係テーブルを、別に作成する必 要があるとは限りません。結合子の親（この例では "Promotion"）のルックアップ テーブル内で、関係を 直接定義することも可能です。また、ファクト テー ブル内で直接、関係を作成することもできます。 この例では、3 つのアトリビュート間の関係に着目すること が重要です。"Promotion" アトリビュートは、"Item" と "Quarter" の特定の組み合わせと関係していますが、これら 280 アトリビュート関係 © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド ビジネス データのコンテキスト : アトリビュート 7 のアトリビュートとの直接的な関係はありません。これが結 合子関係の本質部分です。次の図は、この関係を示していま す。 対多、多対多のどちらの場合もあ 結合子関係には、1 ることに注意してください。多対多関係の問題点であ る分析機能の喪失と重複カウントは、多対多の結合子 関係にも当てはまります。 データに結合子関係がある場合は、結合子アトリビュートで 親アトリビュートを使用するレポートのデータが正しく取得 されるように、MicroStrategy で結合子関係を定義することが 重要です。これにより、結合子関係の親アトリビュートに ファクト テーブルを結合するとき（販促別の売上を見る場 合など）に、常にどちらか一方ではなく両方の結合子が結合 に使用されます。 同じルックアップ テーブルを使用する複数 のアトリビュート : アトリビュート ロール アトリビュート ロールを使用すれば、同じデータで 2 つの アトリビュートを定義し、サポートできます。同じデータ定 義を持ち、ビジネス モデル内での役割が異なる 2 つのアト リビュートを定義したと仮定します。たとえば、次の図中の "Origin Airport"（出発点空港）と "Destination Airport"（到着 © 2010 MicroStrategy, Inc. 同じルックアップ テーブルを使用する複数のアトリビュート : アトリビュート ロール 281 7 ビジネス データのコンテキスト : アトリビュート プロジェクト デザイン ガイド 点空港）は、同じルックアップ テーブル（LU_AIRPORT） と列（AIRPORT_ID）を使用して定義されています。 レポートで出発点としての JFK 空港と、到着点としての JFK 空港を区別することに意味があるのは、到着点空港の データが出発点空港のデータと異なっていることが前提で す。出発点空港と到着点空港の論理的概念に対応する必要は あっても、同じデータを持つ 2 つのルックアップ テーブル を作成するのは望ましいことではありません。2 つのルック アップ テーブルを作成するとデータに重複が生じ、格納ス ペースが増え、保守も面倒になるからです。 同じルックアップ テーブルと列を使用して複数のアトリ ビュートが定義される場合、それらのアトリビュートは基本 的に異なるアトリビュート ロールを持ちます。1 つのアトリ ビュートがどのようにして複数のロールを兼ねるかは、アト リビュートごとに異なります。 "Origin Airport" アトリビュートと "Destination Airport" アトリ ビュートは、同じアトリビュート フォーム（または説明、 場所などアトリビュート フォームのさまざまな側面）を共 有しています。一方、ファクト テーブル内にはロールごと に列が存在しています。次の図では ORIGIN_AIRPORT_ID 282 同じルックアップ テーブルを使用する複数のアトリビュート : アトリビュート ロール © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド ビジネス データのコンテキスト : アトリビュート 7 と DESTINATION_AIRPORT_ID が、これらのファクト列で す。 レポート デザイナが MIA 空港の出発便数と LGA 空港の到 着便数を取得するため、"Origin Airport" アトリビュートと "Destination Airport" アトリビュートの両方を同じレポートに 含めると、空の結果セットが返されます。これが起きるの は、SQL ステートメントが、MIA であると同時に LGA でも ある空港（Airport_ID = "MIA" AND Airport_ID = "LGA"）の 説明を取得しにいこうとするからです。 1 つのアトリビュートに複数のロールがあると判断した場合 は、論理モデル内でロールごとに 1 つずつアトリビュートを 作成する必要があります（「アトリビュート ロールの指定」 （284 ページ）を参照）。これにより、複数のロールを持つア トリビュートを含むレポートが、正しいデータを返すように なります。 次の図中の "State"（州）も、2 つのロールを持つアトリ ビュートの一例です。このアトリビュートは "Vendor"（ベン ダ）アトリビュートと "Store"（店舗）アトリビュートの両 方に関係しており、一方でベンダの所在地を参照し、他方で © 2010 MicroStrategy, Inc. 同じルックアップ テーブルを使用する複数のアトリビュート : アトリビュート ロール 283 7 ビジネス データのコンテキスト : アトリビュート プロジェクト デザイン ガイド 店舗所在地を参照します。したがって、"State" アトリ ビュートには 2 つのロールがあるということになります。 OLTP システムでは通常、ロールは上図のような 1 つのテー ブルとして実装されます。データ ウェアハウス内では、 "Vendor State"（ベンダの州）と "Store State"（店舗の州）の 両方を含むクエリは、一度の実行で State テーブルを 2 回使 用する必要があります。たとえば、所在地がアーカンソー州 で、ニューヨーク州の店舗に販売しているベンダを表示する レポートを作成したとします。このレポートの結果は、デー タ ウェアハウスの構造が正しく設定されていないと空にな る場合があります。同時に Arkansas であり New York である 州の説明を SQL ステートメントが取得しようと試み、空の 結果セットが生成されます。 アトリビュート ロールの指定 2 つのロールを同じレポートに表示するには、それらのロー ルを異なるアトリビュートとして扱う必要があります。言い 換えれば、ロールごとに異なるアトリビュート名が必要にな るわけです。一意のアトリビュートの作成方法には、次のオ プションがあります。 • 自動アトリビュート ロール認識 : 同じルックアップ テー ブルを持つ複数のアトリビュートを作成し、複数のロー ルを MicroStrategy に自動認識させます。自動認識は、 VLDB プロパティの [Engine Attribute Role Options] によっ 284 同じルックアップ テーブルを使用する複数のアトリビュート : アトリビュート ロール © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド ビジネス データのコンテキスト : アトリビュート 7 て、データベース インスタンスのレベルで有効になりま す。詳細は、『MicroStrategy システム管理ガイド』を参照 してください。 • 明示的テーブル別名 : 同じ物理テーブルを指す論理テー ブルを 2 つ作成し、それらの論理テーブルを 2 つのアト リビュートのルックアップ テーブルとして定義します。 ロール認識が有効になってい 自動アトリビュート る（データベース インスタンス レベルの VLDB プロパティである [Engine Attribute Role Options] が 有効になっている）MicroStrategy プロジェクトで は、1 つのルックアップ テーブル内の同じ列に対 して、最大 99 個のアトリビュートを定義できま す。これを上回る数のアトリビュートを作成する とエラーになり、プロジェクト スキーマの更新や Intelligence Server の再起動が無効になります。 テーブルの別名は上級ユーザの制御の幅を広げます。スキー マを更新しているか、スキーマが非常に複雑な場合には、こ の方法が適しています。MicroStrategy に十分に習熟しないう ちは、自動アトリビュート ロール認識の方が容易に使用で きます。モデル化のロジックやデータベースの詳細を理解す るまでは、自動アトリビュート ロール認識を利用すること を推奨します。 自動認識は、対象のアトリビュートがすべて同じ階層 に属している（子アトリビュートを共有している）場 合には機能しません。たとえば、上に示した例では、 2 つの "State" アトリビュートには共通の子アトリ ビュートはありません。 つまり、いずれか 1 つのアトリビュートに複数のロールがあ ると判断した場合は、論理モデル内でロールごとに 1 つずつ アトリビュートを作成する必要があります。アトリビュート ロールを識別するときには次の点に留意してください。同じ アトリビュートをレポートで（「出荷月」、「注文月」のよう な形で）複数回、表示する必要がある場合、そのアトリ ビュートには複数のロールがあります。この場合は、 "Month"（月）が複数のロールを持つアトリビュートです。 アトリビュート ロールは、自動アトリビュート ロール認識、 明示的テーブル別名のどちらでも作成できます。 © 2010 MicroStrategy, Inc. 同じルックアップ テーブルを使用する複数のアトリビュート : アトリビュート ロール 285 7 ビジネス データのコンテキスト : アトリビュート プロジェクト デザイン ガイド 自動アトリビュート ロール認識の使用 データ ウェアハウス内で "Vendor State"（ベンダの州）と "Store State"（店舗の州）の両方を含むクエリが正しい結果 を得るためには、そのクエリ内で State テーブルを 2 回使用 する必要があります。この場合、同じルックアップ テーブ ルを使用する 2 つのアトリビュート "Store State" と "Vendor State" を作成できます。その結果、LU_State テーブルとの 自己結合を含む SQL コードが生成されます。論理モデルは 次のようになります。 "State" アトリビュートの 2 つのロールがどちらも論理モデル に含まれているため、"State" は 2 通りの視点から捉えること ができます。ベンダの所在地がある州と、店舗が位置してい る州は互いに異なる事象であり、それを論理モデルに反映す る必要があります。自動認識では、この 2 つのアトリビュー ト（"Vendor State" と "Store State"）が、同じ式に異なるアト リビュート名を使用して、同じルックアップ テーブルにア クセスできます。 自動ロール認識が機能するのは、アトリビュートで使 用される式が完全に同じ場合だけです。ほとんどの場 合、式はルックアップ テーブル内の 1 つまたは複数 の列を表します。 次にレポートの見出し部分の一例を示します。 Vendor_State_ID=15 (Arkansas) Metrics Vendor State Vendor Store Dollar Sales Store State この場合の要求は「アーカンソー州（Store State ID = 15）に ある当社の全ベンダを対象に、店舗の州別に売上総額を表 示」です。アトリビュート ロールが使用されている場合、 286 同じルックアップ テーブルを使用する複数のアトリビュート : アトリビュート ロール © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド ビジネス データのコンテキスト : アトリビュート 7 "Vendor State" と "Store State" の両方のアトリビュートに同じ ルックアップ テーブル（LU_State）を使用できます。2 つ のアトリビュートは、このテーブル内の同じ列を参照しま す。 自動アトリビュート ロール認識を使用するには、[ クエリ最 適化] の下にあるデータベース インスタンス レベルの VLDB プロパティで [Engine Attribute Role Options] を選択する必要 があります。この VLDB プロパティを設定する手順につい ては、MicroStrategy Desktop のオンライン ヘルプか、 『MicroStrategy システム管理ガイド』を参照してください。 明示的テーブル別名によるアトリビュート ロール の指定 明示的テーブル別名の機能は自動認識より強力で、上級ユー ザに推奨されるソリューションです。 "State" のようなアトリビュートはデータ ウェアハウス内で 複数のロールを持つ場合があります。たとえば、"State" は "Vendor State" と "Store State" を表すことができます。この場 合、"State" アトリビュートには 2 つのロールがあります。1 つはベンダ所在地の参照、もう 1 つは店舗所在地の参照で す。 明示的テーブル別名を使用して複数のロールを持つアトリ ビュートを指定すると、"State" アトリビュートの両方の ロールが論理データ モデルに含まれ、"State" を 2 通りの視 点から捉えることができます。論理データ モデルは次のよ うになります。これは自動認識を使用した場合と同様です。 自動認識と明示的テーブル別名の違いは、明示的テーブル別 名を使用すると、スキーマ内に同じ物理テーブルを指すルッ クアップ テーブルが個別に作成されることです。 © 2010 MicroStrategy, Inc. 同じルックアップ テーブルを使用する複数のアトリビュート : アトリビュート ロール 287 7 ビジネス データのコンテキスト : アトリビュート プロジェクト デザイン ガイド "Store" アトリビュートに明示的テーブル別名を使用すると、 "Store State" アトリビュートを含むテーブル （LU_STATE_STORE）と、"Vendor State" アトリビュートを 含むテーブル（LU_STATE_VENDOR）が次の図のように作成 されます。 次にレポートの見出し部分の一例を示します。このレポート は、アーカンソー州（Store State ID = 15）にある全ベンダを 対象に、店舗の州別に売上総額のデータを提供します。 Vendor_State_ID=15 (Arkansas) Metrics Vendor State Vendor Store Dollar Sales Store State 明示的テーブル別名を使用すると、2 つのルックアップ テー ブル（LU_STATE_STORE および LU_STATE_VENDOR）が使 用されます。これらは同じ物理テーブルの別名に過ぎないた め、次の SQL 例に示すように、どちらの州名についてもレ ポートは同じ物理テーブル（LU_STATE）にアクセスしま す。 SELECT a12.State_Desc as State_Desc SELECT a13.State_Desc as State_Desc FROM LU_STATE a12 LU_STATE a13 テーブル別名の作成時には選択したテーブルがコピーされ、 このコピーの名前を変更できます。上に説明した例で、新し いアトリビュートを作成する準備が整ったら、適切なテーブ ルを各アトリビュートにマップできます。上の例では "Store 288 同じルックアップ テーブルを使用する複数のアトリビュート : アトリビュート ロール © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド ビジネス データのコンテキスト : アトリビュート 7 State" アトリビュートに LU_STATE_STORE テーブル、 "Vendor State" アトリビュートに LU_STATE_VENDOR テーブ ルをそれぞれ選択します。 テーブル別名は、一種の論理テーブルです。論理テー ブルについては、「論理テーブル」（415 ページ）を参 照してください。 明示的テーブル別名によるアトリビュート ロールの作成は、 Architect でも実行できます（「アトリビュート ロールの指 定 : 同じルックアップを使用する複数のアトリビュート」 （169 ページ）を参照）。 明示的テーブル別名を使用してアトリビュート ロールを作成する には この手順では、このガイドで後述する明示的テーブル別名の 例を作成するステップを示します。MicroStrategy Tutorial プ ロジェクトには LU_STATE テーブルは含まれていません。 それでも、大まかな手順と概念を把握すれば、それをガイド ラインとして、プロジェクトにアトリビュート ロールを作 成できます。 1 MicroStrategy Desktop で、明示的テーブル別名を使用し てアトリビュート ロールを作成するプロジェクトにログ インします。 2 [ スキーマ オブジェクト ] フォルダまでナビゲートして [ テーブル ] フォルダを選択します。 3 LU_STATE テーブルを右クリックして [ テーブル別名を 作成 ] を選択します。LU_STATE(1) テーブルが作成され ます。 4 LU_STATE(1) を右クリックして [ 名前の変更 ] を選択し、 テーブル名を LU_STATE_STORE に変更します。 5 LU_STATE テーブルを右クリックして [ テーブル別名を 作成 ] を選択します。LU_STATE(1) テーブルが作成され ます。 6 LU_STATE(1) を右クリックして [ 名前の変更 ] を選択し、 テーブル名を LU_STATE_VENDOR に変更します。 © 2010 MicroStrategy, Inc. 同じルックアップ テーブルを使用する複数のアトリビュート : アトリビュート ロール 289 7 ビジネス データのコンテキスト : アトリビュート プロジェクト デザイン ガイド アトリビュートを作成します。 7 [ アトリビュート ] フォルダを選択します。 8 [ ファイル ] メニューから [ 新規作成 ]、[ アトリビュート ] の順に選択します。[ 新規フォーム式を作成 ] ダイアログ ボックスが開きます。 9 [ ソース テーブル ] ドロップダウン リストから LU_STATE_STORE テーブルを選択します。 10 [ 使用可能な列 ] ペインで、アトリビュート ロールを識別 する STATE_ID をダブルクリックします。 11 [ 手動 ] を選択して [OK] をクリックします。[ 新規アトリ ビュート フォームを作成 ] ダイアログ ボックスが開きま す。 12 [ ソース テーブル ] ドロップダウン リストから、同じ LU_STATE_STORE テーブルを選択します。 13 [OK] をクリックします。アトリビュート エディタが開 きます。 14 [ 新規作成 ] をクリックし、"State Store" アトリビュートの アトリビュート フォームに他のすべての列をマップしま す。すべての "State Store" アトリビュート フォームを LU_STATE_STORE テーブル内の列にマップしてくださ い。 15 LU_STATE_STORE テーブルの列にアトリビュート フォームをマップする作業が完了したら、"State Store" ア トリビュートを保存します。 16 上記の "State Store" の作成と同じ手順（「アトリビュート を作成します。」（290 ページ））で "Vendor State"（ベンダ の州）アトリビュートを作成します。ただし、 LU_STATE_STORE テーブルの代わりに LU_STATE_VENDOR テーブルを使用してください。 290 同じルックアップ テーブルを使用する複数のアトリビュート : アトリビュート ロール © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド ビジネス データのコンテキスト : アトリビュート 7 複数の ID 列を持つアトリビュート : 複合ア トリビュート 複合アトリビュート とは、ID 列として指定されている列を 複数持つアトリビュートのことです。これは、そのようなア トリビュートを一意に識別するために、複数の ID 列が必要 であることを意味します。通常、複合アトリビュートを作成 するのは、論理データ モデルに複合キー関係の存在が反映 されている場合です。リレーショナル データベース内の複 合キー は、データベースの複数の列から構成される主キー です。 たとえば、ある小売プロジェクトに "Class"（類別）と "Item"（商品）という 2 つのアトリビュートが含まれている とします。"Class" は "Item" の親で、"Item" との間に 1 対多 関係があります。Item_ID 列の値は、商品を一意に識別す るものではありません。商品「シャツ」の Item_ID は 1 で すが、シャツには類別（男性用、女性用、子供用）により複 数の種類があります。したがって、男性用シャツを一意に識 別するには、Item_ID と Class_ID をグループ化して複合 アトリビュートを作成する必要があります。 複合アトリビュートのすべての ID フォームは、同じ ルックアップ テーブルに含まれていなければなりま せん。 例 : 複合アトリビュートの作成 複合アトリビュートを作成するのは、アトリビュートのエレ メントを一意に識別するために 2 つ以上の列が必要な場合で す。MicroStrategy Tutorial プロジェクトの "Distribution Center" は複合アトリビュートの一例です。配送センタを一 意に識別するには、配送センタに関する 2 つの詳細情報が必 要です。1 つは配送センタの ID、もう 1 つは配送センタの所 在する国です。これらのデータは、Dist_Ctr_ID 列と Country_ID 列でそれぞれ表されます。配送センタの ID 番 号は重複することがありますが、国内に限れば、各配送セン タの ID 番号は一意です。 したがって、Country_ID 列と Dist_Ctr_ID 列を、 "Distribution Center" アトリビュートとしてグループ化する必 要があります。これにより配送センタの正しいデータが、レ © 2010 MicroStrategy, Inc. 複数の ID 列を持つアトリビュート : 複合アトリビュート 291 7 ビジネス データのコンテキスト : アトリビュート プロジェクト デザイン ガイド ポートに完全に表示されます。この機能を使用するには、 フォーム グループの作成が必要です。フォーム グループ と は、複合アトリビュートを作成するためにグループ化したア トリビュート フォームの集まりです。 複合アトリビュート "Distribution Center" を作成する手順を以 下に示します。 複合アトリビュートは、Architect を使用して作成することも できます（「複数の ID 列を持つアトリビュートの作成 : 複合 アトリビュート」（165 ページ）を参照）。 複合アトリビュート "Distribution Center" を作成するには 1 MicroStrategy Desktop で MicroStrategy Tutorial プロジェク トを含むプロジェクト ソースにログインし、さらに MicroStrategy Tutorial にログインします。 2 [ マイ オブジェクト ] フォルダまでナビゲートして [My Objects] フォルダを開きます。 3 [ ファイル ] メニューから [ 新規作成 ]、[ アトリビュート ] の順に選択します。アトリビュート エディタが開き、 [ 新規アトリビュート式の作成 ] ダイアログ ボックスが最 前面に表示されます。 4 [ ソース テーブル ] ドロップダウン リストから LU_DIST_CTR テーブルを選択します。このテーブル内 に "Distribution Center" の 2 つの ID 列が存在します。 5 COUNTRY_ID 列をダブルクリックして右側の [ フォーム 式 ] ペインに追加します。 6 [ 自動 ] を選択して [OK] をクリックします。[ 新規アトリ ビュート フォームを作成 ] ダイアログ ボックスが開きま す。 7 [ フォーム概要 ] 領域で、[ 名前 ] フィールドに Country ID と入力します。 8 その他の設定はデフォルトのままで、[OK] をクリックし ます。 292 複数の ID 列を持つアトリビュート : 複合アトリビュート © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド ビジネス データのコンテキスト : アトリビュート 7 9 アトリビュート エディタで [ 新規作成 ] をクリックし、ア トリビュート ID フォームをもう 1 つ作成します。このア トリビュート フォームは、"Distribution Center" アトリ ビュートの定義を完成するために必要な配送センタの ID 列にマップします。 10 DIST_CTR_ID 列をダブルクリックして右側の [ フォーム 式 ] ペインに追加します。 11 [ 自動 ] を選択して [OK] をクリックします。[ 新規アトリ ビュート フォームを作成 ] ダイアログ ボックスが開きま す。 12 [ フォーム概要 ] 領域で、[ 名前 ] フィールドに Distribution Center ID と入力します。 13 [ フォーム カテゴリ ] 領域で、[ 使用するカテゴリ ] ドロッ プダウン リストから [ID] を選択します。[OK] をクリッ クします。 このアトリビュート フォームは ID 列として指定しなけ ればなりません。そうすることで Country_ID フォーム と組み合わせて、"Distribution Center" アトリビュートの 一意な ID を作成できるようになります。 フォーム グループの作成 14 他のフォーム（この例では COUNTRY_ID）がすでに ID フォーム カテゴリを使用しており、フォーム グループを 作成して 2 つの ID 列を結合する必要があることを通知す るダイアログ ボックスが表示されます。[ はい ] をクリッ クします。[ 新規アトリビュート フォームを作成 ] ダイア ログ ボックスが開きます。 15 [ 名前 ] フィールドに Distribution Center と入力して [OK] をクリックします。アトリビュート エディタが開 き、作成したフォーム グループが [ アトリビュート フォーム ] ペインに表示されます。 16 これは例に過ぎず、変更を保存しなくても "Distribution Center" アトリビュートを閉じることができます。 複合アトリビュートを作成したら、スキーマを更新して プロジェクトに変更を反映する必要があります。すべて のエディタを閉じます。[ スキーマ ] メニューから [ スキー マを更新 ] を選択します。 © 2010 MicroStrategy, Inc. 複数の ID 列を持つアトリビュート : 複合アトリビュート 293 7 ビジネス データのコンテキスト : アトリビュート プロジェクト デザイン ガイド アトリビュートを使用したデータのブラウ ズとレポート 作成したアトリビュートは、主にブラウズとレポートという 2 つの用途に使用します。ユーザはアトリビュートを手がか りにブラウズし、レポートで使用するアトリビュートを見つ けるとレポートに配置します。これにより、配置したアトリ ビュートの詳細と、そのアトリビュートがファクト データ にどのように関係しているかをレポートに表示できます。ア トリビュートはさまざまな形で表示できるため、プロジェク ト内の各アトリビュートのデフォルト表示を指定する必要が あります。このタスクはレポート単位で実行できますが、プ ロジェクト全体にグローバルに適用される各アトリビュート のデフォルトも指定しなければなりません。 デフォルトのアトリビュート表示を、ブラウズ用とレポート 用にそれぞれ選択する必要があります。レポート表示フォー ムは、完成したレポート内に列として表示されるアトリ ビュート フォームです。ブラウズ フォーム は、データ エク スプローラを使用してプロジェクト内のアトリビュートのエ レメント リストをブラウズするときに表示されるアトリ ビュート フォームです。したがって、ブラウズ フォームは アトリビュート エレメントを識別します。このように分け られているため、用途に応じて柔軟にアトリビュートを表示 できます。 アトリビュートのブラウズ フォームは、Report Services ド キュメントのプロンプト詳細オート テキスト コードでアト リビュート エレメントを表示するためにも使用されます。 Report Services ドキュメントについては、『MicroStrategy ド キュメント作成ガイド』を参照してください。 アトリビュートの作成時には、すべてのフォームがデ フォルトで、レポート表示フォームおよびブラウズ フォームとして追加されます。ただし、複数のアトリ ビュート フォームを作成する場合は例外です。その 場合、最初に作成するフォームは、レポート表示 フォームやブラウズ フォームとしては追加されま せん。 アトリビュートのレポート表示フォームは、レポートが実行 されたときにデフォルトで表示されるアトリビュート フォームを決定します。アトリビュートに複数の異なる フォームを選択すれば、表示する値セットを選択できます。 294 アトリビュートを使用したデータのブラウズとレポート © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド ビジネス データのコンテキスト : アトリビュート 7 たとえば、"Region"（地域）アトリビュートを含むレポート で、アトリビュート フォームとして ID を選択すると、1 つ の数字（4 など）が表示されます。アトリビュート フォーム として Description（説明）を選択すると、表示は名前 （Northwest など）になります。店舗を展開している都市のリ ストを表示するレポートでは、Long Description（長い説明） フォーム（Chicago など）や URL アトリビュート フォーム （www.chicago.com など）の表示を選択できます。 レポート結果で呼び出され、グリッドには表示されないアト リビュート フォームも選択できます。これらのブラウズ フォームは [レポート オブジェクト] ペインで確認できます。 グリッド表示では、レポートを再実行しなくても、[ レポー ト オブジェクト ] 内のアトリビュート フォームをレポート に追加できます。たとえば、都市の URL アトリビュート フォームをブラウズ フォームとして追加すれば、その フォームをユーザが選択してレポートに表示できます。 表示されるアトリビュート フォームは、次の方法で変更で きます。 • レポートまたはテンプレートでアトリビュートを右ク リックし、必要なアトリビュート フォームを選択する。 • [ データ ] メニューから [ アトリビュート表示 ] を選択し、 [ アトリビュート表示 ] ダイアログ ボックスを開く。 レポートやテンプレートにアトリビュート フォームを表示 する手順については、オンライン ヘルプと以下の項を参照 してください。 アトリビュート フォームのデフォルト表示の定義 アトリビュート フォームはさまざまな方法で表示できます。 たとえば、MicroStrategy Tutorial の "Distribution Center" アト リビュートには、ID フォーム グループと説明フォームが含 まれており、ID フォーム グループは 2 つの ID 列 （Country_ID および Dist_Ctr_ID）から構成されていま す。 レポートには Dist_Ctr_ID フォームが、データ ウェアハ ウス内の特定配送センタの ID 番号が表示されます。一方、 "Distribution Center" の説明フォームには、配送センタの実際 の名前（「San Diego」など）が表示されます。 © 2010 MicroStrategy, Inc. アトリビュートを使用したデータのブラウズとレポート 295 7 ビジネス データのコンテキスト : アトリビュート プロジェクト デザイン ガイド アトリビュート フォームがレポートでどのように表示され るかを指定するには、アトリビュート エディタを使用しま す。"Distribution Center" アトリビュートの場合は、各配送 センタの ID 番号、配送センタの名前、またはその両方を表 示するかどうか指定できます。また、データ エクスプロー ラでプロジェクトをブラウズするときに表示されるアトリ ビュート フォームも指定できます。 "Distribution Center" アトリビュートのフォームの 1 つを、レ ポート内および MicroStrategy Tutorial プロジェクトのブラウ ズ中に表示されるように設定する手順を以下に示します。 レポートでのアトリビュート フォームの表示方法は、 Architect を使用して定義することもできます（「アトリ ビュートを使用してデータのブラウズおよびレポートを行う 方法の変更」（167 ページ）を参照）。 アトリビュート フォームをレポートおよびデータ エクスプロー ラに表示するには 1 MicroStrategy Tutorial で [ スキーマ オブジェクト ] フォル ダまでナビゲートして [ アトリビュート ] フォルダを開 き、さらに [ 地域 ] フォルダを開きます。 2 "Distribution Center" アトリビュートをダブルクリック します。アトリビュート エディタが開きます。 3 [ 表示 ] タブをクリックします。 右側の [ レポート表示フォーム ] ペイン内で、"Distribution Center" の説明フォームが唯一の表示フォームとして設定 されています。これは、"Distribution Center" アトリ ビュートをレポートで使用すると、配送センタの実際の 名前が表示されることを意味しています。[ 使用可能な フォーム ] ペイン内の ID 2 フォームは、配送センタの識 別番号を表しています。 4 ID 2 フォームは、次の方法で表示されるように設定でき ます。 • ID 2 フォームをレポートにデフォルトで表示される フォームとして設定する場合 :[ 使用可能なフォーム ] ペインで ID 2 を選択し、最上部の [>] ボタンをクリッ クして右側の [ レポート表示フォーム ] ペインに追加 します。 296 アトリビュートを使用したデータのブラウズとレポート © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド ビジネス データのコンテキスト : アトリビュート • 7 ユーザが "Distribution Center" アトリビュートをブラウ ズするときに、データ エクスプローラに ID 2 フォー ムが表示されるように設定する場合 :[ 使用可能な フォーム ] ペインで ID 2 を選択し、最下部の [>] ボ タンをクリックして右側の [ ブラウズ フォーム ] ペ インに追加します。 データ エクスプローラでは階層を利用して、レポー トにオブジェクトを効率的に配置できます。データ エクスプローラについては、「レポートでの階層ブラ ウズの有効化 : データ エクスプローラ」（318 ページ） で説明します。 5 レポートおよびデータ エクスプローラに表示するアトリ ビュートのデフォルトの並べ替え順序も指定できます。 アトリビュート フォームの並べ替えオプションの詳細 は、「フォームの表示 : アトリビュート フォームのプロ パティ」（250 ページ）を参照してください。 6 これは例に過ぎず、変更を保存しなくてもアトリビュー ト エディタを閉じることができます。 ユーザがレポートを編集および表示するときに、アトリ ビュートがどのように表示されるかを設定することもできま す。詳細は、『MicroStrategy 基本レポーティング ガイド』を 参照してください。 © 2010 MicroStrategy, Inc. アトリビュートを使用したデータのブラウズとレポート 297 7 ビジネス データのコンテキスト : アトリビュート 298 アトリビュートを使用したデータのブラウズとレポート プロジェクト デザイン ガイド © 2010 MicroStrategy, Inc. 8 8. アトリビュートの構成とブ ラウズを行うための階層の 作成 はじめに 階層とは、プロジェクト内にあるアトリビュートの関係を表 すようにアトリビュートをグループ化したもので、アトリ ビュートの並べ替えを行わずに、または並べ替えを行ってか ら表示できます。 2 章、「論理データ モデル」では、階層を使用して実際のビ ジネス分野の関連アトリビュートをグループ化する方法を説 明しました。たとえば、" 日 "、" 週 "、" 月 "、および " 年 " のアトリビュートで構成される時間階層をモデルに含めるこ とができます。 この章では、MicroStrategy の環境に存在する階層について説 明し、MicroStrategy の 2 つの異なるタイプの階層の情報を示 します。これらのタイプの階層は、システム階層とユーザ階 層です。システム階層は、プロジェクトの作成時に自動的に 作成され、プロジェクト内にあるスキーマ プロジェクトの © 2010 MicroStrategy, Inc. 299 8 アトリビュートの構成とブラウズを行うための階層の作成 プロジェクト デザイン ガイド 関係により維持されます。ユーザ階層は、レポート デザイ ナ専用に作成する階層です。 この章では、MicroStrategy でユーザ階層を作成して構成する 方法を説明し、さらに MicroStrategy Desktop の階層機能の追 加情報を示します。 ユーザ階層の作成 MicroStrategy Desktop では、階層エディタまたは Architect を 使用してユーザ階層を作成します。ユーザ階層とシステム階 層の概要は、「階層のタイプ」（303 ページ）を参照してくだ さい。 階層エディタでユーザ階層を作成するには、次の手順に従い ます。Architect の使用方法の詳細は、「Architect によるユー ザ階層の作成」（303 ページ）を参照してください。 300 ユーザ階層の作成 © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド アトリビュートの構成とブラウズを行うための階層の作成 8 新しいユーザ階層を作成するには 1 MicroStrategy Desktop でお使いのプロジェクトを含むプ ロジェクト ソースにログインし、プロジェクトを開きま す。 2 [ フォルダ リスト ] で、[Schema Objects]（スキーマ プ ロジェクト）フォルダに移動して開きます。 3 [Hierarchies]（階層）フォルダ、[Data Explorer]（デー タ エクスプローラ）フォルダの順に開きます。 4 [ ファイル ] メニューの [ 新規作成 ]、[ ドキュメント ] を順 に選択します。階層エディタが開き、その後すぐに [ ア トリビュートを選択 ] ダイアログ ボックスが開きます。 5 [ 使用可能なオブジェクト ] ペインから階層内で使用する アトリビュートを選択し、矢印をクリックして [ 選択し たオブジェクト ] ペインに追加します。[OK] をクリック して、[ 選択したオブジェクト ] ダイアログ ボックスを閉 じます。選択したアトリビュートが、階層ビュアーに表 示されます。 6 特定のアトリビュートに接続する矢印は、接続する複数 のアトリビュートの関係を示します。これらの関係を階 層のブラウズ関係やドリル関係として使用することも、 独自の関係を作成することもできます。 ブラウズ関係やドリル関係を作成するには、別のアトリ ビュートへのブラウズやドリルダウンを有効にするアト リビュートの中央を選択します。アトリビュートの中央 から、関連アトリビュートまでドラッグします。2 つの アトリビュート間に、ブラウズ関係またはドリル関係が 作成されます。 7 階層をドリル階層として使用するには、階層エディタの 下部にある [ドリル階層として使用] チェック ボックスを 選択します。このチェック ボックスをクリアすると、階 層はブラウズにのみ使用されます。 ドリル階層は、ドリルだけでなくブラウズにも使用でき ます。ドリル階層の詳細は、「階層を使用するドリル」 （319 ページ）を参照してください。 © 2010 MicroStrategy, Inc. ユーザ階層の作成 301 8 アトリビュートの構成とブラウズを行うための階層の作成 プロジェクト デザイン ガイド 8 ユーザ階層の各アトリビュートには、階層でのアトリ ビュートの表示方法やアクセス方法に影響するプロパ ティがあります。アトリビュートを右クリックして、次 のプロパティを設定できます。 • ブラウズ アトリビュートを定義 : 選択したアトリ ビュートから、ユーザがブラウズやドリルできる先の アトリビュートを定義します。また、これらの関係 は、この手順で前述した方法で、あるアトリビュート から別のアトリビュートにドラッグ アンド ドロップ しても定義できます。 • アトリビュート フィルタを定義 : 取得するデータま たは表示するデータに対して、任意の指定条件により 補完やフィルタ処理を行うかどうかを指定します。階 層のフィルタは、レポートのフィルタと同様に動作し ます。フィルタ条件を満たすデータのみが表示されま す（「階層内のアトリビュートのフィルタ処理」（312 ページ）を参照）。 • エントリ ポイントに設定 : このアトリビュートを使 用してこの階層内のブラウズをユーザが開始できるか どうかを指定します（「エントリ ポイント」（313 ペー ジ）を参照）。 • エレメント表示 : ユーザが表示できるエレメントを指 定します。エレメント表示は、[ ロック済 ]、[ ロック解 除済 ]、または [ 制限 ] にできます（「アトリビュート エレメントの表示制御」（308 ページ）を参照）。 9 [ 保存して閉じる ] をクリックします。[ 名前を付けて保 存 ] ダイアログ ボックスが開きます。 10 階層の名前を入力します。次に、階層を保存する場所に ナビゲートします。 ユーザ階層は、任意のフォルダに保存できます。ただし、 データ エクスプローラでユーザ階層のエレメント ブラウ ズができるように、[Hierarchies]（階層）フォルダの [Data Explorer]（データ エクスプローラ）サブフォルダに 入れる必要があります。詳細は、「レポートでの階層ブラ ウズの有効化 : データ エクスプローラ」（318 ページ）を 参照してください。 11 [ スキーマ ] メニューの [ スキーマを更新 ] を選択します。 302 ユーザ階層の作成 © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド アトリビュートの構成とブラウズを行うための階層の作成 8 Architect によるユーザ階層の作成 Architect を使用して、視覚的な統合環境でユーザ階層の作成 や変更ができます。Architect では、テーブル、アトリビュー ト、アトリビュート関係、ファクト、ユーザ階層、およびプ ロジェクトのデザイン時に含めたその他のプロジェクト オ ブジェクトを表示できます。 Architect は、階層エディタで使用可能なすべての機能をサ ポートできます。階層エディタで一度に 1 つの階層に着目す るのではなく、Architect を使用してプロジェクトの複数の階 層を一度に作成したり変更できます。Architect、および Architect を使用してユーザ階層の作成や変更を行う手順の詳 細は、次に示す章や節を参照してください。 • 5 章、 「Architect によるプロジェクトの作成」 • 「プロジェクトの作成と変更」（104 ページ） • 「ユーザ階層の作成と変更」（181 ページ） 階層のタイプ MicroStrategy には、次の 2 つのタイプの階層があります。 © 2010 MicroStrategy, Inc. • システム階層 : システム階層は、プロジェクト内のアト リビュート間に定義された関係に従って作成されます。 ユーザがシステム階層を作成する必要はありません。プ ロジェクトの作成時に、Desktop に自動的に作成されま す。システム階層は、プロジェクト内のすべてのアトリ ビュートについて順序付きセットを指定しますが、アト リビュートの並べ替えやグループ化は定義しません。ア トリビュートの並べ替えやグループ化は、他の設定と共 にユーザ階層に定義されます。 • ユーザ階層 : ユーザ階層は、アトリビュートおよびアト リビュート関係のグループで、ビジネス組織にとって意 味を持つように構成されます。ユーザ階層はユーザ定義 であり、論理データ モデルに従う必要はありません。お 使いのビジネス インテリジェンス システムの構造が進化 するに従って、ユーザ階層のデザインを変更して、追加 のアトリビュートを含めたり、特定アトリビュートへの ユーザ アクセスを制限したりできます。このタイプの階 層は、エレメント ブラウズやレポート ドリルの柔軟性が 階層のタイプ 303 8 アトリビュートの構成とブラウズを行うための階層の作成 プロジェクト デザイン ガイド 得られるように作成します。ユーザ階層の作成手順は、 次の節を参照してください。 「ユーザ階層の作成」（300 ページ）- 階層エディタを 使用してユーザ階層を作成する方法を説明していま す。 「ユーザ階層の作成と変更」 （181 ページ）- Architect を 使用してユーザ階層を作成する方法を説明していま す。 システム階層 : プロジェクト スキーマ定義 システム階層 は、ユーザがプロジェクトを作成するたびに MicroStrategy により設定されるデフォルトの階層です。シス テム階層には、プロジェクトのアトリビュートがすべて含ま れ、スキーマ定義の一部を実際に構成します。はじめにプロ ジェクトを作成するときにプロジェクトに唯一含まれる階層 が、システム階層です。 システム階層は、プロジェクト内のアトリビュート関係の情 報を保持します。システム階層は編集できませんが、アトリ ビュート エディタ でアトリビュートの親 / 子の追加や削除 を行うたび、または プロジェクト作成アシスタントでアト リビュートの子を定義するときに、システム階層が更新され ます。 システム階層は、プロジェクト内にあるすべてのオブジェク ト間の関係を決定するのに便利です。システム階層のアトリ ビュートは、明示的に定義されたユーザ階層の一部である必 要はありません。ユーザ階層に割り当てられないアトリ ビュートは、レポート オブジェクト、フィルタ条件、およ びコンソリデーションの構成要素としてシステムが使用でき ます。これらのレポート オブジェクトの詳細は、 『MicroStrategy 上級レポーティング ガイド』を参照してくだ さい。 システム階層は、データ エクスプローラまたは階層ビュ アーで表示できますが、階層エディタでは表示できません。 階層ビュアーには、[ スキーマ ] メニューの [ グラフィック表 示 ] からアクセスできます。階層ビュアーの詳細は、「階層 ビュアーの使用」（321 ページ）を参照してください。 304 階層のタイプ © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド アトリビュートの構成とブラウズを行うための階層の作成 8 ユーザ階層 : 論理ビジネス関係 ユーザ階層 は、アトリビュート セットおよびその関係であ り、論理的なビジネス組織用に特定の順序で並べられます。 アトリビュート間のブラウズやドリルの関係を定義するに は、ユーザ階層を作成します。たとえば、時間階層には、" 年 "、" 四半期 "、" 月 "、および " 日 " のアトリビュートを 含む時間階層を作成できます。データ エクスプローラでア トリビュートをブラウズするときには、" 年 " をダブルク リックすると " 四半期 " に移動し、" 四半期 " をダブルク リックすると " 月 " に移動するというようになります。 ブラウズはデータ エクスプローラから実行されますが、ド リルでは、レポート内の上下のレベルへの移動、または異な る階層内のレベルへの移動をユーザが実際に選択します。た とえば、レポート内の " 四半期 " アトリビュートをドリルす る場合、下の " 月 "、上の " 年 "、または別の階層内のアト リビュートにドリルできます。 システム階層内のアトリビュートを 1 つ以上使用して、階層 エディタでユーザ階層を作成できます。 ユーザ階層は、ユーザが定義できる唯一のタイプの階層であ り、各プロジェクトに任意の個数のユーザ階層を作成できま す。ユーザは、所属する会社のビジネス モデルの特定分野、 およびデータ ウェアハウス スキーマに対応するユーザ階層 を定義する必要があります。 階層の構成 ユーザ階層の最良のデザインは、アトリビュートを複数の論 理ビジネス分野に構成、つまりグループ化することです。こ れにより、ユーザはプロジェクト内のアトリビュートをより 簡単に見つけることができ、あるアトリビュートから別のア トリビュートにナビゲートできます。たとえば、関連する複 数のアトリビュートをそのレベル別に階層内に配置できま す。 次の例は、"Location"（所在地）と "Customer"（顧客）の階 層を示します。"Location"（所在地）階層には、相互の関係 に従って "State"（県 / 州）、"City"（市区町村）、および "Store"（店舗）が構成されます。また、"Customer"（顧客） © 2010 MicroStrategy, Inc. 階層の構成 305 8 アトリビュートの構成とブラウズを行うための階層の作成 プロジェクト デザイン ガイド 階層は、"Company"（会社）、"Contact"（連絡先）、および "Customer"（顧客）のアトリビュートをグループ化します。 ユーザ階層を作成するときには、複数の階層を相互に分離す る必要がないこと、また、お使いの論理データ モデルの ディメンション構造に必ずしも従う必要がないことに注意し てください。 階層の構造 システム階層とユーザ階層の両方でプロジェクト内のアトリ ビュートにナビゲートできますが、アトリビュート グルー プの論理的な定義や並べ替えができるのはユーザ階層のみで す。 この章のここからは、ユーザ階層、およびプロジェクトでの ユーザ階層の作成方法や構成方法を説明します。 ユーザ階層内でアトリビュートをグループ化するときには、 アトリビュートの表示機能やブラウズ機能が効果的に動作す るデザインを設計します。次の例には、"Region"（地域）階 層のインスタンスが 2 つあります。一方の階層は、"Region" （地域）に複数の "States"（県 / 州）があり、"States"（県 / 州）に複数の "Stores"（店舗）があることを示します。 この階層では、レポートの "Region"（地域） 、"States"（県 / 州）、および "Stores"（店舗）を表示する、下のレベルへの ドリルやブラウザのオプションを作成できます。ただし、右 側の例のように "Region"（地域）階層に "Stores"（店舗）の 306 階層の構成 © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド アトリビュートの構成とブラウズを行うための階層の作成 8 みを含めた場合、ドリルやブラウズのオプションは、 "Region"（地域）および "Stores"（店舗）のレベルのみです。 階層の表示 : 階層ビュアー 階層ビュアーは、ユーザ階層とシステム階層を視覚的に表示 します。システム階層では、アトリビュート間の接続は親子 関係を表します。ユーザ階層では、この接続はアトリビュー ト間のブラウズ パスを示します。エアリアル パースペク ティブにより、階層の概要が示されます。スケールを小さく するとプロジェクト全体をナビゲートできます。 階層ビュアーには、[ スキーマ ] メニューの [ グラフィック表 示 ] からアクセスします。階層ビュアーの詳細は、「階層 ビュアーの使用」（321 ページ）を参照してください。 階層表示オプションの設定 ユーザ階層の各アトリビュートには、階層でのアトリビュー トの表示方法やアクセス方法に影響するプロパティがありま す。次の手順に示すように、階層エディタを使用してこれら の各プロパティを設定できます。 • © 2010 MicroStrategy, Inc. エレメント表示 : ユーザが表示できるエレメントを指定 します。エレメント表示は、[ ロック済 ]、[ ロック解除 済 ]、または [ 制限 ] にできます（「アトリビュート エレ メントの表示制御」（308 ページ）を参照）。 階層表示オプションの設定 307 8 アトリビュートの構成とブラウズを行うための階層の作成 プロジェクト デザイン ガイド • アトリビュート フィルタ : 取得するデータまたは表示す るデータに対して、任意の指定条件により補完やフィル タ処理を行うかどうかを指定します。階層のフィルタは、 レポートのフィルタと同様に動作します。フィルタ条件 を満たすデータのみが表示されます（「階層内のアトリ ビュートのフィルタ処理」（312 ページ）を参照）。 • エントリ ポイント / エントリ ポイントではありません : このアトリビュートを使用してこの階層内のブラウズを ユーザが開始できるかどうかを指定します（「エントリ ポイント」（313 ページ）を参照）。 • アトリビュートをブラウズ : 特定のアトリビュートから ユーザがブラウズできる先のアトリビュートを表示しま す。あるアトリビュートと別のアトリビュートを接続す る線で表されます（「階層ブラウズ」（315 ページ）を参 照）。 次の複数の節で、これらのプロパティ、および階層エディタ を使用して各プロパティを設定する方法を説明します。 アトリビュート エレメントの表示制御 この節では、アトリビュート エレメントの表示を制御する さまざまな手法を説明します。 • 「ロック済 / ロック解除済のアトリビュート エレメント」 （308 ページ） • 「制限付きのアトリビュート エレメント」（310 ページ） ロック済 / ロック解除済のアトリビュート エレメント 階層をロックすると、特定のアトリビュートのエレメント、 およびその下のレベルにあるすべてのエレメントをユーザが 表示できなくなります。その階層にある 1 つ以上のアトリ ビュートについて [ エレメント表示 ] オプションが [ ロック 済 ] に設定された場合、その階層はロック済 であるといいま す。階層内で、それより高いレベルにあるものはすべて表示 されます。 セキュリティ上の理由から、または長い階層をよりよく管理 するために、階層をロックして、エレメントおよびそれより 下のレベルにあるアトリビュートのユーザに対する表示を制 308 階層表示オプションの設定 © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド アトリビュートの構成とブラウズを行うための階層の作成 8 限できます。データ エクスプローラで、アトリビュート エ レメント、およびそれより下のレベルにあるアトリビュート の表示を制限することにより、システム リソースを消費す る可能性がある長いアトリビュート エレメント リストの展 開を防ぐことができます。エレメント表示をロック済に設定 すると、アトリビュート名の横に南京錠アイコンが表示され ます。 一例として、データ エクスプローラでアトリビュート "Order "（注文）をロックした例を示します。 ユーザは、"Customer Region"（顧客地域）と "Customer City" （顧客都市）のアトリビュート エレメントを表示できます が、各顧客の注文情報を表示することはできません。権限の ないユーザが顧客の注文に関する機密情報にアクセスするこ とを防ぐために、"Order "（注文）アトリビュートをロック できます。 前提条件 • 階層が作成済みであること。 階層内のアトリビュートのロック / ロック解除を行うには 1 MicroStrategy Desktop で、次に示す手順に従って、階層 エディタまたは Architect を使用して階層を開きます。 • [ フォルダ リスト ] から階層を見つけて右クリックし、 [ 編集 ] を選択します。階層エディタが開きます。 • [ スキーマ ] メニューの [Architect] を選択します。 MicroStrategy Architect が開きます。 [ 階層表示 ] の [ 階層 ] ドロップダウン リストから、階 層を選択します。 © 2010 MicroStrategy, Inc. 階層表示オプションの設定 309 8 アトリビュートの構成とブラウズを行うための階層の作成 プロジェクト デザイン ガイド 2 次に示すオプションを使用して、アトリビュートのロッ クまたはロック解除を行います。 • アトリビュートをロックするには、アトリビュートを 右クリックし、[ エレメント表示 ]、[ ロック済 ] の順に 選択します。ロックしたアトリビュートの横に南京錠 アイコンが表示され、ユーザはこのアトリビュートの エレメントを表示できなくなります。 • ロック済のアトリビュートをロック解除するには、ア トリビュートを右クリックし、[ エレメント表示 ]、 [ ロック解除済 ] の順に選択します。アトリビュートか ら南京錠アイコンの表示が消え、ユーザはこのアトリ ビュートのエレメントを表示できるようになります。 3 階層エディタまたは Architect の [ 保存して閉じる ] をク リックして、変更内容を保存して Desktop に戻ります。 4 [ スキーマ ] メニューの [ スキーマを更新 ] を選択します。 また、アトリビュートを編集するときに、アトリビュート エディタの [ 表示 ] タブで、アトリビュートのロック / ロック 解除ができます。ただし、この操作は、システム階層内のア トリビュートのロック / ロック解除を行うもので、アトリ ビュートを含むユーザ階層には機能しません。たとえば、ア トリビュート エディタでアトリビュート " 年 " をロックした 場合、データ エクスプローラで " 年 " を展開したときには " 年 " のエレメントは表示されません。 制限付きのアトリビュート エレメント データ エクスプローラでユーザが表示するアトリビュート エレメントを制限する別の方法は、一度に表示されるエレ メント数を制限することです。この方法は、1 つの階層に膨 大な数のアトリビュート エレメントが存在するときに便利 です。一度にすべてのアトリビュート エレメントをロード するのではなく、一度にロードする数の制限を 5 件、または 10 件に設定できます。また、一度に多数のエレメントを取 得すると、システム パフォーマンスに悪影響を及ぼすこと があります。この場合、ユーザは矢印をクリックして、その アトリビュートの次のエレメント セットを表示できます。 たとえば、次に示す "Chocolate"（チョコレート）サブカテ ゴリには、多くの項目があります。一度にこれらの項目をす べて表示してユーザを圧倒するのではなく、項目 5 件の制限 310 階層表示オプションの設定 © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド アトリビュートの構成とブラウズを行うための階層の作成 8 が設定されています。次の図に、この データ エクスプロー ラの表示を示します。 前提条件 • 階層が作成済みであること。 階層に表示されるアトリビュートの数を制限するには 1 MicroStrategy Desktop で、次に示す手順に従って、階層 エディタまたは Architect を使用して階層を開きます。 • [ フォルダ リスト ] から階層を見つけて右クリックし、 [ 編集 ] を選択します。階層エディタが開きます。 • [ スキーマ ] メニューの [Architect] を選択します。 MicroStrategy Architect が開きます。 [ 階層表示 ] の [ 階層 ] ドロップダウン リストから、階 層を選択します。 2 制限するアトリビュートを右クリックし、[ エレメント表 示 ]、[ 制限 ] の順に選択します。[ 制限 ] ダイアログ ボック スが開きます。 3 一度に表示するエレメント数を入力して、[OK] をクリッ クします。 4 階層エディタまたは Architect の [ 保存して閉じる ] をク リックして、変更内容を保存して Desktop に戻ります。 5 [ スキーマ ] メニューの [ スキーマを更新 ] を選択します。 © 2010 MicroStrategy, Inc. 階層表示オプションの設定 311 8 アトリビュートの構成とブラウズを行うための階層の作成 プロジェクト デザイン ガイド 階層内のアトリビュートのフィルタ処理 この節を読む前に、『MicroStrategy 上級レポーティング ガイ ド』の「フィルタ」の章を参照して、フィルタとは何か、お よび MicroStrategy でのフィルタの作成方法を理解してくだ さい。 階層にフィルタを追加して、データの取得方法と表示方法を 制御できます。フィルタを使用することで、階層内に表示す るアトリビュート エレメントを厳密に選択できます。たと えば、1 四半期のみのデータ、または 1 四半期内の数日のみ のデータを表示するように階層をフィルタ処理できます。 フィルタは、特定のデータのみの表示を許可することによ り、データの取得時間を短縮します。 ベースのフィルタを使用して階層をフィ プロンプト ルタ処理することはできません。 階層内の各アトリビュートに、複数のフィルタを適用できま す。階層内のアトリビュートをフィルタ処理することは、 データ エクスプローラでブラウズするときに返されるデー タのエレメント数を制限することです。制限付き階層を作成 すると、一度に表示されるエレメント数が減少します。ただ し、フィルタは、ユーザが表示できるエレメント数を制限す るので、あるタイプのセキュリティを実行します。 フィルタを使用すると、データ取得時の効率が上昇します。 この理由は、フィルタをアトリビュートに適用すると、階層 内でユーザがアクセスする部分を制限できるからです。フィ ルタを使用すると、データ エクスプローラは、ユーザが選 択した条件のみを表示でき、階層内のその他のデータをユー ザが表示することはできません。 たとえば、30 才未満の顧客のみを表示するとします。はじ めに、" 顧客年齢 " が 30 未満のフィルタを作成します。階層 エディタで、このフィルタを " 顧客 " アトリビュートに追加 します。プロジェクト スキーマを更新し、データ エクスプ ローラで " 顧客 " 階層を表示します。30 才未満の顧客のみが 表示されます。 階層内のアトリビュートにフィルタを追加するときに は、各フィルタがアトリビュートの情報に関連してい ることを確認する必要があります。MicroStrategy は、 関連付けたフィルタがアトリビュートに対して妥当か どうかを検証しません。 312 階層表示オプションの設定 © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド アトリビュートの構成とブラウズを行うための階層の作成 8 前提条件 • フィルタが作成済みであること。 • 階層が作成済みであること。 階層内のアトリビュートにフィルタを適用するには 1 MicroStrategy Desktop で、次に示す手順に従って、階層 エディタまたは Architect を使用して階層を開きます。 • [ フォルダ リスト ] から階層を見つけて右クリックし、 [ 編集 ] を選択します。階層エディタが開きます。 • [ スキーマ ] メニューの [Architect] を選択します。 MicroStrategy Architect が開きます。 [ 階層表示 ] の [ 階層 ] ドロップダウン リストから、階 層を選択します。 2 フィルタ処理するアトリビュートを右クリックして、[ ア トリビュート フィルタを定義 ] を選択します。 3 フィルタ処理に関するヒントが開いた場合は、[OK] をク リックします。[ オブジェクトを選択 ] ダイアログ ボック スが開きます。 4 [ 使用可能なオブジェクト ] ペインから適用するフィルタ を選択し、[>] をクリックして、それらのフィルタを [ 選 択したオブジェクト ] ペインに追加します。 5 [OK] をクリックして [ オブジェクトを選択 ] ダイアログ ボックスを閉じます。フィルタを適用したアトリビュー トが、フィルタ アイコンと共に階層内に表示されます。 6 階層エディタまたは Architect の [ 保存して閉じる ] をク リックして、変更内容を保存して Desktop に戻ります。 エントリ ポイント エントリ ポイント は、データ エクスプローラのアトリ ビュートへのショートカットです。エントリ ポイントを作 成すると、階層のさまざまなレベルに到達するために複数の © 2010 MicroStrategy, Inc. 階層表示オプションの設定 313 8 アトリビュートの構成とブラウズを行うための階層の作成 プロジェクト デザイン ガイド アトリビュートをブラウズすることなく、目的のアトリ ビュートに即座にアクセスできます。これは特に、頻繁に使 用するアトリビュートにアクセスするときに便利です。 ユーザ階層を作成すると、階層、アトリビュート、およびそ のエレメントがデータ エクスプローラに表示されます。ア トリビュートをエントリ ポイントとして設定することは、 そのアトリビュートにアクセスするさらに短い経路を作成す ることです。たとえば、典型的な階層は " 時間 " です。" 時 間 " をクリックすると、"2007"、"2006"、"2005" など、各年 のエレメントが開きます。"2006" をクリックすると、"Q1"、 "Q2"、"Q3"、"Q4" など、各四半期のエレメントが開きます。 " 第 24 週 " を探している場合、正しいデータ レベルである " 週 " に到達するには、複数のアトリビュートのレベルを開く 必要があります。アトリビュート " 週 " をエントリ ポイント として設定した場合、データ エクスプローラでは、" 年 " と 同じレベルにアトリビュート " 週 " が表示されます。エント リ ポイントとして設定しないアトリビュートは、階層構造 の通常の位置に表示されます。 ロック済アトリビュートをエントリ ポイントとして設定し た場合、このアトリビュートは階層内に表示されますが、南 京錠アイコンが付いています。ロック済アトリビュートの表 示はできますが、そのレベルの下にあるエレメントやアトリ ビュートにアクセスすることはできません。 前提条件 • 階層が作成済みであること。 階層内にエントリ ポイントを作成するには 1 MicroStrategy Desktop で、次に示す手順に従って、階層 エディタまたは Architect を使用して階層を開きます。 • [ フォルダ リスト ] から階層を見つけて右クリックし、 [ 編集 ] を選択します。階層エディタが開きます。 • [ スキーマ ] メニューの [Architect] を選択します。 MicroStrategy Architect が開きます。 [ 階層表示 ] の [ 階層 ] ドロップダウン リストから、階 層を選択します。 314 階層表示オプションの設定 © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド アトリビュートの構成とブラウズを行うための階層の作成 8 2 エントリ ポイントとして設定するアトリビュートを右ク リックして、[ エントリ ポイントに設定 ] を選択します。 アトリビュートに、エントリ ポイントであることを示す 緑のチェック マークが付きます。 アトリビュートからエントリ ポイントを削除するには、 アトリビュートを右クリックして [ エントリ ポイントを 削除 ] を選択します。 3 階層エディタまたは Architect の [ 保存して閉じる ] をク リックして、変更内容を保存して Desktop に戻ります。 4 [ スキーマ ] メニューの [ スキーマを更新 ] を選択します。 階層ブラウズ 階層に配置するアトリビュートを選択した後、それらのアト リビュート間の関係を定義できます。これらの関係は、 [Hierarchies]（階層）フォルダからユーザがどのようにアト リビュートをブラウズできるかを決定します。 たとえば、"Catalog"（カタログ）、"Category"（カテゴリ）、 "Subcategory"（サブカテゴリ）、および "Item"（商品）が、 ユーザ階層 "Catalog Items"（カタログ商品）を構成するアト リビュートである場合、この階層は次の図のようにアトリ ビュート間の親子関係を示します。たとえば、次の階層で © 2010 MicroStrategy, Inc. 階層表示オプションの設定 315 8 アトリビュートの構成とブラウズを行うための階層の作成 プロジェクト デザイン ガイド は、"Category"（カテゴリ）は "Subcategory"（サブカテゴ リ）の親アトリビュートであり、"Category"（カテゴリ）は "Catalog"（カタログ）の子アトリビュートです。 ユーザ階層には、これらの直接関係を定義する必要は ありません。ユーザ階層は単に、アトリビュートの集 合です。 階層内のアトリビュート間には、ブラウズ関係とドリル関係 の両方があります。ブラウズ アトリビュート とは、ユーザ 階層内の特定のアトリビュートから直接ブラウズできるよう に指定したアトリビュートです。階層内のアトリビュートに ブラウズ アトリビュートを適用するときには、データ エク スプローラでブラウズするときに表示される詳細レベルを指 定します。データ エクスプローラに階層を含めると、プロ ジェクトでレポートやユーザがその階層を使用できるように なります。データ エクスプローラで階層を含める方法の詳 「レポートでの階層ブラウズの有効化 : データ エクス 細は、 プローラ」（318 ページ）を参照してください。 階層の各アトリビュートに、ブラウズ アトリビュートを 1 つ以上割り当てることができます。前述の例を使用して、こ れらのアトリビュートのいくつかがブラウズ アトリビュー トに割り当てられています。具体的には、次のようになりま す。 316 階層表示オプションの設定 © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド アトリビュートの構成とブラウズを行うための階層の作成 階層アトリビュート 8 ブラウズ アトリビュー ト Catalog（カタログ） Category（カテゴリ）、 Subcategory（サブカテ ゴリ） Category（カテゴリ） Subcategory（サブカテ ゴリ） Subcategory（サブカテ ゴリ） Catalog（カテゴリ）、 Item（商品） Item（商品） これらのブラウズ アトリビュートを追加することにより、 "Subcategory"（サブカテゴリ）に到達するためにはじめに "Category"（カテゴリ）をブラウズ ダウンせずに、ユーザは "Category"（カテゴリ）アトリビュートから直接 "Subcategory"（サブカテゴリ）のエレメントを表示できま す。より直接的に階層内をブラウズする機能は、次の図のよ うに表すことができます。 © 2010 MicroStrategy, Inc. 階層表示オプションの設定 317 8 アトリビュートの構成とブラウズを行うための階層の作成 プロジェクト デザイン ガイド データ エクスプローラでは、前述の階層は、次の例のよう になります。 これにより、はじめに "Category"（カテゴリ）をブラウズせ ずに、ユーザは "Catalog"（カタログ）内の "Subcategory" （サブカテゴリ）を表示できます。 レポートでの階層ブラウズの有効化 : データ エクス プローラ [Data Explorer]（データ エクスプローラ）に階層を保存する ことにより、階層をブラウズしたり、レポートに含めること ができます。また、このフォルダの内外に階層を移動するこ とにより、ユーザに対して一部の階層を表示し、残りの階層 を非表示にすることができます。データ エクスプローラ は オブジェクト ブラウザのツールの 1 つで、システム階層と ユーザ階層を保持します。プロジェクトを作成すると、その プロジェクトのシステム階層が自動的にデータ エクスプ ローラに配置されます。 ユーザ階層は、任意のフォルダに保存できます。ただし、 データ エクスプローラでユーザ階層のブラウズができるよ うに、[Data Explorer]（データ エクスプローラ）サブフォル ダにユーザ階層を入れる必要があります。このフォルダは、 [Schema Objects]（スキーマ オブジェクト）フォルダ内にあ る [Hierarchies]（階層）フォルダのサブフォルダです。 318 階層表示オプションの設定 © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド アトリビュートの構成とブラウズを行うための階層の作成 8 階層を使用するドリル ドリルは MicroStrategy レポートの機能であり、指定したパ スに沿ってアトリビュートのさまざまなレベルをブラウズで きます。ドリルの指定に含めたアトリビュートのレベルに 従って、ユーザは上下、または横方向の異なる詳細レベルに ドリルできます。 レポート内のドリル パスを選択すると、レポートが更新さ れ、選択した詳細レベルが表示されます。たとえば、" 年 " アトリビュートと " 売上 " メトリックを持つレポートでは、 " 年 " アトリビュートを、" 月 " アトリビュートのような下 のレベルにドリル ダウンできます。新しいレポートが自動 的に実行されます。新しいレポートでは、" 月 " レベルで " 売上 " データがレポートされます。 ユーザ階層をドリル可能にすることができます。このオプ ションにより、他のアトリビュートからユーザがプロジェク ト レベルでドリルできる先のアトリビュートを決定できま す。" 年 " と " 月 " のアトリビュートの例では、この 2 つの アトリビュートを含む時間階層でのドリルが有効になりま す。これにより、ユーザは " 年 " から " 月 " にドリル ダウン でき、必要な場合は " 月 " から " 年 " にドリル アップできま す。 ドリル パスとしてユーザ階層を有効にするには、階層エ ディタで、ドリル階層として使用するユーザ階層を有効にす る必要があります。ユーザ階層を有効にしない場合、システ ム階層によりデフォルトのドリル パスが定義されます。 このため、ユーザ階層のブラウズ パスを、潜在的なドリル パスとして考えることができます。たとえば、次の階層で は、"Subcategory"（サブカテゴリ）は "Catalog"（カタログ） のブラウズ アトリビュートです。これはつまり、データ エ クスプローラで、"Catalog"（カタログ）のエレメントにアク セスせずに、"Subcategory"（サブカテゴリ）のエレメントに アクセスできるということです。この階層でのドリルを有効 にすると、レポートで、"Catalog"（カタログ）から "Subcategory"（サブカテゴリ）、および "Catalog"（カタログ） © 2010 MicroStrategy, Inc. 階層表示オプションの設定 319 8 アトリビュートの構成とブラウズを行うための階層の作成 プロジェクト デザイン ガイド のその他のブラウズ アトリビュートにドリル ダウンできま す。 ドリル階層は、ドリルだけでなくブラウズにも使用できま す。ただし、アトリビュートをブラウズする方法は、レポー トでアトリビュートをドリルする方法と同じではないことが あります。アトリビュート間のドリル パスとブラウズ パス が異なる場合、個別にドリル階層とブラウズ階層を作成する 必要があります。 前提条件 • 階層が作成済みであること。 ユーザ階層をドリル階層として定義するには 1 MicroStrategy Desktop で、次に示す手順に従って、階層 エディタまたは Architect を使用して階層を開きます。 • [ フォルダ リスト ] から階層を見つけて右クリックし、 [ 編集 ] を選択します。階層エディタが開きます。 • [ スキーマ ] メニューの [Architect] を選択します。 MicroStrategy Architect が開きます。 [ 階層表示 ] の [ 階層 ] ドロップダウン リストから、階 層を選択します。 2 ユーザ階層をドリル階層として定義するには : 320 階層表示オプションの設定 © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド アトリビュートの構成とブラウズを行うための階層の作成 8 • 階層エディタを使用して、その下部にある [ ドリル階 層として使用 ] チェック ボックスを選択します。 • Architect で、[ 階層表示 ] 内を右クリックして、[ ドリ ル階層として使用 ] を選択します。 3 階層エディタまたは Architect の [ 保存して閉じる ] をク リックして、変更内容を保存して Desktop に戻ります。 4 [ スキーマ ] メニューの [ スキーマを更新 ] を選択します。 ユーザ階層のドリルを有効にすると、その階層は、その中に あるアトリビュートのドリル パスに寄与します。ドリルの 追加情報は、『MicroStrategy 上級レポーティング ガイド』を 参照してください。 階層ビュアーとテーブル ビュアーの使用 階層ビュアーを介して、MicroStrategy Architect により、シス テム階層、およびお使いのユーザ階層のすべてを 1 か所に表 示できます。テーブル ビュアーは、MicroStrategy Architect のもう 1 つのツールで、プロジェクト内にある一部の情報の 鳥瞰図を表示します。テーブル ビュアーは、プロジェクト 内のすべてのテーブルを視覚的に表示するために使用しま す。 階層ビュアーの使用 階層ビュアーでは、調べる階層を選択でき、その階層を構成 するアトリビュートに直接アクセスできます。階層ビュアー を使用して、システム階層、または任意のユーザ階層を表示 できます。 © 2010 MicroStrategy, Inc. • システム階層を表示すると、プロジェクトの作成時にシ ステムが定義した、アトリビュート間の実際の関係が表 示できます。 • ユーザ階層を表示するときには、実際のアトリビュート の関係は表示されませんが、プロジェクト デザイナが定 義したユーザ階層の構造が表示され、ユーザによるブラ ウズやレポート開発が促進されます。 階層ビュアーとテーブル ビュアーの使用 321 8 アトリビュートの構成とブラウズを行うための階層の作成 プロジェクト デザイン ガイド 階層ビュアーには、特定の階層を一度にどの程度表示するか をユーザが選択できる柔軟性があります。階層のエントリ ポイントを一度にすべて表示することも、一度に 1 つのみ選 択することもできます。エントリ ポイントの詳細は、「エン トリ ポイント」（313 ページ）を参照してください。 また、階層ビュアーでは、表示するようにユーザが選択した 階層内の任意のアトリビュートに直接アクセスできます。階 層のアトリビュートに直接アクセスするときに、アトリ ビュートをエントリ ポイントとして定義できます。エント リ ポイントを作成する方法の詳細は、「エントリ ポイント」 （313 ページ）を参照してください。 階層ビュアーでシステム階層を表示するには 1 MicroStrategy Desktop で、[ スキーマ ] メニューの [ グラ フィック表示 ] を選択します。 2 [ 階層 ] を選択します。 階層ビュアーでユーザ階層を表示するには 1 階層ビュアーで、[ 階層 ] メニューから表示する階層を選 択します。 2 横に緑のチェック マークが付いているアトリビュートが エントリ ポイントです。エントリ ポイントを作成する方 法の詳細は、「エントリ ポイント」（313 ページ）を参照 してください。 階層ビュアーからアトリビュートを編集するには 1 階層ビュアーで、編集するアトリビュートを右クリック します。 2 [ 編集 ] を選択します。 階層ビュアーのエアリアル パースペクティブにより、プロ ジェクト内の階層の概要が得られます。スケールを小さくす ると、プロジェクト全体をナビゲートできます。 322 階層ビュアーとテーブル ビュアーの使用 © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド アトリビュートの構成とブラウズを行うための階層の作成 8 階層ビュアーのエアリアル パースペクティブ モードにアクセス するには 1 階層ビュアーで、[ 表示 ] メニューの [ エアリアル パース ペクティブ ] を選択します。現在表示している階層のエ アリアル ビューが表示されます。緑の四角は、エントリ ポイントであるアトリビュートを示します。 2 エアリアル ビュー内でナビゲートする場所に合わせて、 階層ビュアー内の階層がシフトします。エアリアル ビューのセクションをクリックすると、階層のビューが そのセクションにシフトします。 テーブル ビュアーの使用 テーブル ビュアーを使用すると、プロジェクト内のすべて のテーブル、これらのテーブル間の結合や関係、および各 テーブルの個々の列名が表示できます。 テーブル ビュアーに表示されるテーブルは、論理テーブル です。これらのテーブルは、プロジェクトの作成時に取り込 まれたテーブルを Architect がどのように認識するかを示し ます。 ウェアハウス内の実際のテーブルを変更する データ 場合、論理テーブル構造を更新する必要があります。 論理テーブル構造を更新する方法の詳細は、「プロ ジェクト内のテーブル サイズ : 論理テーブル サイズ」 （376 ページ）を参照してください。 また、Architect を使用して、この情報をすべて表示すること もできます。この方法の詳細は、5 章、「Architect によるプ ロジェクトの作成」を参照してください。 テーブル ビュアーでプロジェクトのテーブルを表示するには 1 MicroStrategy Desktop で、[ スキーマ ] メニューの [ グラ フィック表示 ] を選択します。 2 [ テーブル ] を選択します。 © 2010 MicroStrategy, Inc. 階層ビュアーとテーブル ビュアーの使用 323 8 アトリビュートの構成とブラウズを行うための階層の作成 プロジェクト デザイン ガイド プロジェクト内の各テーブルについて表示される情報を増減する には 1 前述の方法で、テーブル ビュアーを開きます。 2 テーブル ビュアーの [ オプション ] を選択します。 3 テーブル ビュアーに表示する項目に合わせて、[ オプ ション ] メニューにある次のオプションを選択またはク リアします。 • 結合を表示 • 循環結合を使用 • 関係を表示 • 関係タイプを表示 • 列を表示 324 階層ビュアーとテーブル ビュアーの使用 © 2010 MicroStrategy, Inc. 9 9. プロジェクトの最適化と管理 はじめに お使いの MicroStrategy プロジェクトを設定してスキーマ オ ブジェクトを組み込んだら、プロジェクトの良好な管理方 法、および短期と長期の両方についてプロジェクトを最適化 する方法を検討できます。 この章では、お使いのデータ ウェアハウスとプロジェクト との相互作用のチューニング、集計テーブルの作成、パー ティション マッピングなどのメンテナンスと最適化の概念 を紹介し、これらの方法を使用してプロジェクトを拡張する 方法を説明します。これらの情報は、次に示す項に記載され ています。 • 「MicroStrategy プロジェクト スキーマの更新」（326 ペー ジ）— お使いのプロジェクトのデザインと機能を継続し て拡張するときに、スキーマのさまざまな変更が必要で す。プロジェクト スキーマの拡張内容や変更内容を確認 するには、プロジェクト スキーマを更新する必要があり ます。 • 「データ ウェアハウスとプロジェクトとの相互作用 : ウェアハウス カタログ」（328 ページ）— データ記録に © 2010 MicroStrategy, Inc. 325 9 プロジェクトの最適化と管理 プロジェクト デザイン ガイド 関する新しい要件に合わせてお使いのデータ ウェアハウ スが変化するので、お使いのプロジェクトにそれらの変 更内容を反映する必要があります。この反映方法として、 プロジェクトへの新しいテーブルの追加、または使用し ないテーブルの削除があります。また、お使いのデータ ウェアハウスと MicroStrategy プロジェクトとの相互作用 をチューニングして、要件に合わせた方法でデータを MicroStrategy に取り込むこともできます。 • 「プロジェクト内の複数のデータ ソースへのアクセス」 （355 ページ）— Intelligence Server の MultiSource Option 機能を使用して、１ つのプロジェクトを複数のリレー ショナル データ ソースに接続できます。これにより、さ まざまなデータベースや他のリレーショナル データ ソー スからの情報をすべて、1 つの MicroStrategy プロジェク トに統合し、レポート作成および分析ができます。 • 「データベースの挿入パフォーマンスの向上 : パラメー ター化したクエリ」（366 ページ）— MicroStrategy のパラ メーター化したクエリのサポートにより、情報をデータ ベースに挿入する必要があるシナリオでパフォーマンス を向上できます。 • 「要約テーブルを使用するデータの保存 : 集計テーブル」 （368 ページ）— 集計テーブルは、当初データがデータ ウェアハウスに収集されたレベルよりも高いレベルに データを格納します。これらの要約テーブルでは、頻繁 に使用するデータに一層速くアクセスでき、入出力やそ の他のリソース要件を低減し、実行時に集計や並べ替え が必要なデータの量を削減します。 • 「パフォーマンスを向上させるためのテーブルの分割 : パーティション マッピング」（377 ページ）— パーティ ション マッピングは、大きい論理テーブルを小さい物理 テーブルに分割します。パーティションにより、ウェア ハウスに対して発行されたクエリに答えるために読み込 むテーブル数およびテーブル内で読み込むレコード数が 低減され、クエリのパフォーマンスが向上します。 MicroStrategy プロジェクト スキーマの更新 プロジェクト内のファクト、アトリビュート、階層、トラン スフォーメーションなど、すべてのスキーマ プロジェクト を使用して、プロジェクトのスキーマが構成されます。 326 MicroStrategy プロジェクト スキーマの更新 © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド プロジェクトの最適化と管理 9 概念は似ていますが、プロジェクト スキーマは、物理ウェ アハウス スキーマと同じではありません。プロジェクト ス キーマとは、プロジェクト内のアトリビュートの関係、ファ クト レベル、テーブル サイズなどを追跡するために MicroStrategy が使用する内部マップを指します。 スキーマ プロジェクトを変更するときはいつでも、新しい スキーマ プロジェクト定義が追加されたこと、およびこれ らの定義をメモリーにロードする必要があることを MicroStrategy に指示する必要があります。 プロジェクト スキーマを更新するには、次のいずれかの手 順を実行します。 • サーバ接続（3 層）モードになっている場合は、 MicroStrategy Intelligence Server を停止して、再起動しま す。 • 直接（2 層）モードになっている場合は、プロジェクト またはプロジェクト ソースを切断して、再接続します。 • スキーマを手動で更新します。 スキーマの手動更新では、スキーマで更新する特定の エレメントを指定できます。 スキーマを手動で更新するには 1 MicroStrategy Desktop で、[ スキーマ ] メニューの [ スキー マを更新 ] を選択します。 2 [ スキーマを更新 ] ダイアログ ボックスにある次のチェッ ク ボックスを選択またはクリアします。 © 2010 MicroStrategy, Inc. • スキーマ論理情報を更新 : スキーマ プロジェクトの 追加、変更、または削除を行った場合は、このチェッ ク ボックスを選択します。 • テーブル キーおよびファクト エントリ レベルを再計 算 : テーブルのキー構造を変更した場合、またはファ クトが格納されるレベルを変更した場合、このチェッ ク ボックスを選択します。 • テーブル論理サイズを再計算 :MicroStrategy Desktop のアルゴリズムを使用して、論理テーブル サイズを 再計算し、論理テーブル サイズに対してこれまで MicroStrategy プロジェクト スキーマの更新 327 9 プロジェクトの最適化と管理 プロジェクト デザイン ガイド 行った変更を上書きするには、このチェック ボック スを選択します。 サイズは、MicroStrategy SQL エン 論理テーブル ジンがクエリで使用するテーブルを決定する方法 に大きく影響します。 • プロジェクト クライアント オブジェクト キャッシュ サイズを再計算 : プロジェクトのオブジェクト キャッシュサイズを更新するには、このチェック ボックスを選択します。 3 [ 更新 ] をクリックします。 [ スキーマを更新 ] をクリック また、ツールバーの して、最後に保存した設定でスキーマを更新する こともできます。 データ ウェアハウスとプロジェクトとの 相互作用 : ウェアハウス カタログ この節では、データ ウェアハウスとプロジェクトのデータ ベース インスタンスとの相互作用をウェアハウス カタログ で制御する方法説明します。ウェアハウス カタログは、 データ ウェアハウスに対してクエリを実行し、そのデータ ウェアハウスに存在するテーブルと列をリストします。この リストから、プロジェクトに追加するテーブルを選択できま す。各プロジェクトは、ウェアハウス テーブルの一意の セットを持つことができます。 プロジェクトにウェアハウス テーブルを追加するには、 ウェアハウス カタログ、MicroStrategy Project Builder、また は Architect を使用できます。既存のプロジェクトに使用す るウェアハウス テーブルを管理するには、ウェアハウス カ タログが Project Builder よりも優れています。Project Builder でのテーブルの追加は、プロジェクトを最初に作成するとき にのみ便利です。その後、Project Builder でプロジェクトに テーブルを追加する方法は、複雑なプロセスになる場合があ ります。Architect の詳細は、5 章、「Architect によるプロ ジェクトの作成」を参照してください。 328 データ ウェアハウスとプロジェクトとの相互作用 : ウェアハウス カタログ © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド プロジェクトの最適化と管理 9 この節では、カタログの SQL ステートメントのカスタマイ ズ、SQL カタログの構造、および各データベースに使用さ れるデフォルトの SQL ステートメントについても説明しま す。 この項では、次のトピックについて説明します。 • 「ウェアハウス カタログの使用を開始する前の準備」 （329 ページ） • 「ウェアハウス カタログへのアクセス」（330 ページ） • 「プロジェクトのテーブルの追加および削除」（330 ペー ジ） • 「ウェアハウスとプロジェクトのテーブルの管理」（332 ページ） • 「データ ウェアハウス接続と動作のデフォルトの変更」 （339 ページ） • 「カタログ SQL ステートメントのカスタマイズ」（347 ページ） • 「テーブルと列のメッセージのトラブルシューティング」 （354 ページ） 次の点に注意してください。 • MicroStrategy クエリ ビルダを使用してプロジェク トにテーブルを追加することもできます。クエリ ビルダの詳細は、『MicroStrategy 上級レポーティン グ ガイド』を参照してください。 • リレーショナル データベースの代わりに、MDX キューブ ソース（SAP BW、Hyperion Essbase、 Microsoft Analysis Services など）に接続できます。 この場合、MDX キューブ カタログは、ウェアハ ウス カタログと同様なタスクを処理します。詳細 は、『MicroStrategy MDX Cube Reporting Guide』を 参照してください。 ウェアハウス カタログの使用を開始する前の準備 ウェアハウス カタログの使用を開始する前に、次のことを 理解しておく必要があります。 © 2010 MicroStrategy, Inc. データ ウェアハウスとプロジェクトとの相互作用 : ウェアハウス カタログ 329 9 プロジェクトの最適化と管理 プロジェクト デザイン ガイド • お使いのスキーマ。お使いのデータ ウェアハウスの情報 を MicroStrategy にどのように取り込む必要があるかが分 かります。 • プロジェクトの作成方法。 ウェアハウス カタログへのアクセス ウェアハウス カタログにアクセスするには 1 Windows の [ スタート ] メニューの [ すべてのプログラ ム ]、[MicroStrategy]、[Desktop]、[Desktop] を順に選 択します。 2 MicroStrategy Desktop で、お使いのプロジェクトを含む プロジェクト ソースにログインし、プロジェクトを展開 します。 の権限があるログインを使用する必要が Architect あります。権限の詳細は、『MicroStrategy システム 管理ガイド』の付録「許可と権限」を参照してくだ さい。 3 プロジェクトを選択し、[ スキーマ ] メニューの [ ウェアハ ウス カタログ ] を選択します。ウェアハウス データベー スからテーブル情報を取得した後に、ウェアハウス カタ ログが開きます。 プロジェクトのテーブルの追加および削除 レポート デザイナやユーザからの追加ニーズに気付いたと きに、データ ウェアハウスからテーブルをプロジェクトに 追加する必要が発生することがあります。また、プロジェク トを作成してから時間が経ったときに、使用せずにメタデー タのスペースを占めているテーブルを削除する必要が発生す ることもあります。 いつでもウェアハウス カタログにアクセスして、データ ウェアハウスからテーブルを追加したり、プロジェクトから テーブルを削除することができます。 330 データ ウェアハウスとプロジェクトとの相互作用 : ウェアハウス カタログ © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド プロジェクトの最適化と管理 9 データ ソースから削除したプロジェクトからテーブルを削 除する方法の詳細は、「データ ソースから削除済みのテーブ ルのウェアハウス カタログからの削除」（336 ページ）を参 照してください。 プロジェクトの作成後にテーブルの追加や削除を行うには 1 プロジェクトのウェアハウス カタログにアクセスします （「ウェアハウス カタログにアクセスするには」（330 ペー ジ）を参照）。MicroStrategy Desktop で、お使いのプロ ジェクトを含むプロジェクト ソースにログインし、プロ ジェクトを展開します。 2 ウェアハウス カタログの左側には、使用可能なすべての テーブル、および各テーブルの行数がリストされます。 右側には、プロジェクトで既に使用されているテーブル がすべてリストされます。 • テーブルを追加するには : 左側で、ウェアハウス カ タログに追加するテーブルを選択し、[>] をクリック して選択したテーブルを追加します。リストされた テーブルをすべて追加するには、[>>] をクリックし ます。 • テーブルを削除するには : 右側で、ウェアハウス カ タログから削除するテーブルを選択し、[<] をクリッ クして選択したテーブルを削除します。リストされた テーブルをすべて削除するには、[<<] をクリックし ます。 • MultiSource Option のライセンスを所有している場合 は、複数のデータ ソースからテーブルをプロジェク トに追加できます。ウェアハウス カタログを使用し て複数のデータ ソースからテーブルをプロジェクト に追加する方法の詳細は、「プロジェクト内の複数の データ ソースへのアクセス」（355 ページ）を参照し てください。 3 ツールバーの [ 保存して閉じる ] をクリックして、変更内 容をウェアハウス カタログに保存します。テーブル定義 がメタデータに書き込まれます。このプロセスが完了す るまで、時間がかかることがあります。 4 [ スキーマ ] メニューの [ スキーマを更新 ] を選択して、プ ロジェクト スキーマを更新します。 © 2010 MicroStrategy, Inc. データ ウェアハウスとプロジェクトとの相互作用 : ウェアハウス カタログ 331 9 プロジェクトの最適化と管理 プロジェクト デザイン ガイド ウェアハウスとプロジェクトのテーブルの管理 ウェアハウス カタログでは、プロジェクトに含まれるテー ブル、およびプロジェクトにはまだ含まれていない、ウェア ハウス内の使用可能なテーブルを表示できます。プロジェク トのウェアハウス カタログにアクセスする方法は、「ウェア ハウス カタログへのアクセス」（330 ページ）を参照してく ださい。 ウェアハウス内のテーブルを変更する場合、更新内容を定期 的にウェアハウス カタログにロードする必要があります。 更新するには、[ 操作 ] メニューの [ ウェアハウス カタログの 読み取り ] を選択します。 ウェアハウス カタログには次のセクションがあります。 • 現データベース インスタンスを選択 : ドロップダウン リ ストから、テーブルを表示する、データ ソースのデータ ベース インスタンスを選択します。このオプションは MicroStrategy MultiSource Option の一部として使用でき、 これにより、1 つのプロジェクト内の複数のデータ ソー スにアクセスできます（「プロジェクト内の複数のデータ ソースへのアクセス」（355 ページ）を参照）。 • データベース インスタンスで使用可能なテーブル : 選択 したデータベース インスタンスのデータ ソース内にある が、プロジェクトに含まれていないテーブルを表示しま す。プロジェクトにテーブルを追加するには、そのテー ブルをダブルクリックするか、テーブルを選択して [>] をクリックします。 • プロジェクトで使用中のテーブル : プロジェクトの一部 として選択されたテーブルを表示します。プロジェクト からテーブルを削除するには、そのテーブルをダブルク リックするか、テーブルを選択して [<] をクリックしま す。 一方のセクションからもう一方のセクションにすべて のテーブルを追加するには [<<] ボタン、削除するに は [>>] ボタンをクリックします。 332 データ ウェアハウスとプロジェクトとの相互作用 : ウェアハウス カタログ © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド プロジェクトの最適化と管理 9 ウェアハウス カタログには、次のメニュー オプションがあ ります。 メニュー 説明 ファイル • 保存 ウェアハウス カタログの現在の設定およびステータスを保存します。 • 終了 ウェアハウス カタログを終了します。 ツール • パーティションを表示 選択したパーティション マッピング テーブルが参照するテーブルのリスト を、[ テーブル パーティション ] ダイアログ ボックスに表示します。このオ プションは、パーティション マッピング テーブルが選択されている場合に 有効になります。 • テーブル構造 ウェアハウス カタログで選択したテーブルの構造を表示します。 • テーブル行数を計算 選択したテーブルの行数を計算します。 • テーブル接頭語 選択したテーブルのテーブル接頭語の追加または削除ができます。 • テーブル データベー ス インスタンス このオプションを使用して、次のいずれかをサポートできます。 • MicroStrategy では、テーブルの第二データベース インスタンスを指定 できます。この第二データベース インスタンスは、データベース ゲー トウェイをサポートするために使用されます。データベース ゲートウェ イをサポートする方法の詳細は、「データベース ゲートウェイをサポー トする第二データベースの指定」（338 ページ）を参照してください。 • MultiSource Option のライセンスを所有している場合は、複数のデータ ソースからテーブルをプロジェクトに追加できます。ウェアハウス カタ ログを使用して複数のデータ ソースからテーブルをプロジェクトに追加 する方法の詳細は、「プロジェクト内の複数のデータ ソースへのアクセ ス」（355 ページ）を参照してください。 • 接頭語をインポート ウェアハウスのテーブル ネーム スペースから接頭語をインポートできま す。 • オプション データベース インスタンスの変更、デフォルトのテーブル接頭語とテーブ ル構造の変更または割り当て、自動マッピング、行計算など、ウェアハウ ス カタログのさまざまな設定を指定できます。 操作 • ウェアハウス カタロ グの読み取り ヘルプ ウェアハウス内のテーブルに対する変更の更新および反映ができます。 MicroStrategy のオンライン ヘルプのオプションを表示します。 これらのオプションの一部には、ツールバーのボタンや右ク リック メニューからも簡単にアクセスできます。 © 2010 MicroStrategy, Inc. データ ウェアハウスとプロジェクトとの相互作用 : ウェアハウス カタログ 333 9 プロジェクトの最適化と管理 プロジェクト デザイン ガイド テーブル構造の表示 テーブル構造を表示するには、ウェアハウス カタログ内の テーブルを右クリックして（「ウェアハウス カタログへのア クセス」 （330 ページ）を参照）、ショートカット メニューの [ テーブル構造 ] を選択します。また、[ ツール ] メニューの [ テーブル構造 ] を選択することもできます。選択したテーブ ルのテーブル構造が、ダイアログ ボックスに表示されます。 ダイアログ ボックスには、選択したテーブルで使用可能な 列、および各列のデータ タイプが表示されます。[ 構造を更 新 ] をクリックして、そのテーブルに対する最近の変更を反 映することもできます（「テーブル構造の更新」（334 ペー ジ）を参照）。 1 つ以上の列のデータ タイプが変更された場合は、この変更 について警告メッセージが表示され、次のオプションを選択 できます。 • この列が含まれるすべてのテーブルに変更内容を適用す るには、[OK] をクリックします。 • データ タイプの変更をすべて元に戻すには、[ キャンセ ル ] をクリックします。この操作を行うと、テーブルま たは列には変更内容が適用されません。 ウェアハウス カタログ オプ 警告メッセージは、[ ション ] ダイアログ ボックスの [ テーブル構造を更新 中に列データ タイプが変更された場合、警告を表示 ] チェック ボックスを選択した場合にのみ表示されま す。このチェック ボックスは、デフォルトでは選択 されています。 テーブル構造の更新 ウェアハウス テーブルの構造が変化したときはいつでも、 変更内容が MicroStrategy システムで反映されるように、 ウェアハウス カタログのテーブル構造を更新する必要があ ります。このようなタイプの変更の例として、プロジェクト に関連付けられたテーブル内の列の追加、列の削除、および 列名の変更があります。 334 データ ウェアハウスとプロジェクトとの相互作用 : ウェアハウス カタログ © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド プロジェクトの最適化と管理 9 テーブル構造を更新するには 1 プロジェクトのウェアハウス カタログにアクセスします （「ウェアハウス カタログへのアクセス」（330 ページ）を 参照） 。ウェアハウス カタログが開きます。 2 [ プロジェクトで使用中のテーブル ] リストで、変更され たテーブルを右クリックし、[ 構造を更新 ] をクリックし ます。 1 つ以上の列のデータ タイプが変更された場合、この変 更の警告メッセージが表示されます。開いた情報ダイア ログ ボックスで変更内容を確認し、[OK] をクリックし て、この列の変更内容を、この列が含まれるすべての テーブルに適用します。 3 [ 保存して閉じる ] をクリックして、 [ ウェアハウス カタロ グ ] ダイアログ ボックスを閉じます。 • オブジェクト定義が変更されていない場合、[ 構造を 更新 ] コマンドでウェアハウスの構造がすべて更新さ れます。たとえば、これは、テーブルの列の名前を変 更し、その列がファクト式で使用されていない場合で す。 • オブジェクト定義が変更された場合は、[ 構造を更新 ] コマンドではテーブル構造の一部のみが更新されま す。この場合、古い構造に依存するスキーマ オブ ジェクトを手動で更新する必要があります。 たとえば、テーブル内の列の名前を変更した場合、こ の列を使用するファクトを手動で更新する必要があり ます。ファクトを手動で更新する手順は、次のとおり です。 © 2010 MicroStrategy, Inc. a ファクトを右クリックし、[ 編集 ] を選択します。ファ クト エディタが開きます。 b ファクト式を選択し、[ 変更 ] をクリックします。 [ファクト式の変更] ダイアログ ボックスが開きます。 c ソース テーブルのリストから、ファクトの作成元の ソース テーブルを選択します。ファクト式を編集し、 [OK] をクリックします。ファクト エディタに戻りま す。 データ ウェアハウスとプロジェクトとの相互作用 : ウェアハウス カタログ 335 9 プロジェクトの最適化と管理 プロジェクト デザイン ガイド d [ 保存して閉じる ] をクリックし、変更内容を保存して ファクト エディタを閉じます。 e [ スキーマ ] メニューの [ スキーマを更新 ] を選択しま す。[ スキーマを更新 ] ダイアログ ボックスが開きま す。 f [ 更新 ] をクリックします。 g この手順のステップ 1、2 を繰り返して、ウェアハウ ス カタログを開いてテーブル構造を更新します。 h [ 保存して閉じる ] をクリックして、変更内容を保存 し、[ ウェアハウス カタログ ] ダイアログ ボックスを 閉じます。 サンプル データの表示 テーブルのサンプル データを表示するには、ウェアハウス カタログ内のテーブルを右クリックし（「ウェアハウス カタ ログへのアクセス」（330 ページ）を参照）、ショートカット メニューの [ サンプル データを表示 ] を選択します。[ ツー ル] メニューの [サンプル データを表示] を選択することもで きます。テーブルの最初の 100 行が、サンプル データとし て [ 値 ] ダイアログ ボックスに表示されます。 テーブル データを更新するには、[ テーブル値を再ロード ] をクリックします。 データ ソースから削除済みのテーブルのウェアハ ウス カタログからの削除 プロジェクトに含まれているテーブルが、使用可能だった データ ソースから削除された場合、ウェアハウス カタログ を使用して、プロジェクトに含まれるテーブルのリストから これらのテーブルを削除できます。これにより、選択した データ ソースからプロジェクトに含められたテーブルの正 確なリストを表示できます。 336 データ ウェアハウスとプロジェクトとの相互作用 : ウェアハウス カタログ © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド プロジェクトの最適化と管理 9 次の手順は、ウェアハウス カタログを使用してこのタスク を実行する方法です。MicroStrategy Architect を使用してこれ らのテーブルを削除する方法の詳細は、「データ ソースから 削除されたテーブルのプロジェクトからの削除」（127 ペー ジ）を参照してください。 プロジェクトに含まれていないテーブルがデータ ソースから削除された場合、これらのテーブルは、使 用可能なテーブルを示すウェアハウス カタログの表 示から自動的に削除されます。 データ ソースから削除済みのプロジェクト テーブルの表示を削 除するには 1 MicroStrategy Desktop でプロジェクトにログインします。 2 [スキーマ] メニューの [ウェアハウス カタログ] を選択し ます。ウェアハウス カタログが開きます。 3 ウェアハウス カタログのツールバーにある [ 削除したカ タログ テーブルを確認 ] をクリックします。[ 削除したカ タログ テーブル ] ダイアログ ボックスが開きます。 4 [ プロジェクトで使用中のテーブル ] ペインから削除する テーブルの [ 削除 ] チェック ボックスを選択します。 5 削除するテーブルをすべて選択した後、[OK] をクリック してウェアハウス カタログに戻ります。 6 [操作] メニューの [ウェアハウス カタログの読み取り] を 選択します。[ 削除したカタログ テーブル ] ダイアログ ボックスで削除するように選択したテーブルがすべて、 [ プロジェクトで使用中のテーブル ] ペインから削除され ます。 7 [ 保存して閉じる ] をクリックし、変更内容を保存して ウェアハウス カタログを閉じます。 © 2010 MicroStrategy, Inc. データ ウェアハウスとプロジェクトとの相互作用 : ウェアハウス カタログ 337 9 プロジェクトの最適化と管理 プロジェクト デザイン ガイド データベース ゲートウェイをサポートする第二 データベースの指定 MicroStrategy では、テーブルの第二データベース インス タンスを指定できます。この第二データベース インスタン スは、データベース ゲートウェイをサポートするために使 用されます。たとえば、お使いの環境で、Oracle データベー スと DB2 データベースなどの 2 つのデータベースの間に ゲートウェイがある場合があります。そのうちの一方が第一 データベース、もう一方が第二データベースです。第一デー タベースは、すべての SQL 要求を受け取り、正しいデータ ベースに渡します。この環境内にある MicroStrategy 製品の 観点では、第一データベースと第二データベースに 1 つず つ、合わせて 2 つのデータベース インスタンスを定義する 必要があります。プロジェクトのデフォルトのデータベース インスタンスが、第一データベースに設定されます。第二 データベースから検出されるテーブルについて、ウェアハウ ス カタログで第二データベース インスタンスを設定する必 要があります。これにより、MicroStrategy 製品は各テーブル についてどのように SQL を生成するかが分かります。 データベース ゲートウェイ サポートを使用する場合は、 MultiSource Option の機能を使用して複数のデータ ソースか らテーブルをプロジェクトに追加することはできません。 ウェアハウス カタログを使用して複数のデータ ソースから テーブルをプロジェクトに追加する方法の詳細は、「プロ ジェクト内の複数のデータ ソースへのアクセス」（355 ペー ジ）を参照してください。 テーブルの第二データベースを指定するには 1 プロジェクトのウェアハウス カタログにアクセスします （「ウェアハウス カタログへのアクセス」（330 ページ）を 参照） 。ウェアハウス カタログが開きます。 2 プロジェクトで使用中のテーブルを右クリックして(右側 のペイン )、[ テーブル データベース インスタンス ] を選 択します。[ 使用可能なデータベース インスタンス ] ダイ アログ ボックスが開きます。 3 [第一データベース インスタンス] ドロップダウン リスト から、テーブルの第一データベース インスタンスを選択 します。 338 データ ウェアハウスとプロジェクトとの相互作用 : ウェアハウス カタログ © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド プロジェクトの最適化と管理 9 4 第二データベース インスタンスを 1 つ以上選択します。 インスタンスを第二データベー 第一データベース ス インスタンスとして選択することはできま せん。 5 [OK] をクリックし、変更内容を適用してウェアハウス カタログに戻ります。 6 ツールバーの [ 保存して閉じる ] を選択して、変更内容を ウェアハウス カタログに保存して閉じます。 データ ウェアハウス接続と動作のデフォルトの変更 ウェアハウス カタログを使用して、データベース ウェアハ ウス接続、および動作のデフォルトのさまざまな設定を指定 できます。設定の例として、データベース インスタンスの 変更、デフォルトのテーブル接頭語とテーブル構造の変更ま たは割り当て、自動マッピング、行計算などがあります。 [ ツール ] メニューの [ オプション ] を選択して、設定をウェ アハウス カタログから使用できます（ウェアハウス カタロ グにアクセスする方法は、「ウェアハウス カタログへのアク セス」（330 ページ）を参照）。ウェアハウス カタログの [ オ プション ] ダイアログ ボックスが開き、次のタスクを実行で きます。 • 「データ ウェアハウス接続と読み取り動作」 • 「テーブル接頭語、行数、およびネーム スペースの表示」 • 「スキーマ オブジェクトのマッピング、およびテーブル の論理サイズの計算」 データ ウェアハウス接続と読み取り動作 データ ウェアハウスとプロジェクトとの接続に使用される データベース インスタンス、およびデータベース ログイン を変更できます。また、データベース カタログ テーブルの © 2010 MicroStrategy, Inc. データ ウェアハウスとプロジェクトとの相互作用 : ウェアハウス カタログ 339 9 プロジェクトの最適化と管理 プロジェクト デザイン ガイド 読み取り方法も変更できます。このタイプの変更は [ カタロ グ ] カテゴリから実行でき、[ カタログ ] カテゴリは次のサブ カテゴリに分かれています。 • データベース接続 : プロジェクトに使用するデータベー ス インスタンス、およびカスタム データベース ログ インを選択します。 データベース インスタンス : ドロップダウン リスト から、ウェアハウス カタログの第一データベース インスタンスを選択できます。 第一データベース インスタンスはプロジェクトの主 要データ ソースとして機能し、プロジェクトに追加 されたテーブルのデフォルト データベース インス タンスとして使用されます。データベースに関連しな い VLDB プロパティの設定も、第一データベース インスタンスから継承されます。 目的のデータベース インスタンスが [ データベース インスタンス ] ボックスに表示されない場合、または 表示されていても変更の必要がない場合は、次の操作 を選択できます。 – 選択したデータベース インスタンスを変更するに は、[ 編集 ] をクリックします。[ データベース イン スタンス ] ダイアログ ボックスの [ 一般 ] タブが開 きます。 – 新しいデータベース インスタンスを作成するに は、[ 新規作成 ] をクリックします。データベース インスタンス ウィザードが開きます。 ボックスの詳細は、 『これらのダイアログ MicroStrategy システム管理ガイド』を参照してく ださい。 カスタム データベース ログイン : データベース ログ インを選択するか、またはデータベース ログインに 使用しない場合はログインをクリアすることができま す。 ログインの詳細は、オンライン ヘル データベース プを参照してください。 • 読み取り設定 :Microsoft Access を除くすべてのプラット フォームで、ウェアハウス カタログを読み取る SQL を カスタマイズできます。[ 設定 ] をクリックすると、ウェ アハウス カタログの使用可能なテーブルおよび選択した 340 データ ウェアハウスとプロジェクトとの相互作用 : ウェアハウス カタログ © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド プロジェクトの最適化と管理 9 テーブルの列のリストを取得するために使用されるカタ ログ SQL ステートメントを直接編集できます。Microsoft Access データ ソースに接続したときには、[ 設定 ] オプ ションは無効になります。デフォルトのカタログ SQL は、すべてのユーザのテーブルおよび列の DISTINCT リ ストを取得します。たとえば、特定の条件およびテーブ ル所有者を指定することにより、返される情報を限定で きます（「カタログ SQL ステートメントのカスタマイズ」 （347 ページ）を参照）。また、次のチェック ボックスを 選択することできます。 テーブル主キーおよび外部キーを読み取る : データ ソースで、主キーまたは外部キーとして定義されてい る列を MicroStrategy で表示するには、このチェック ボックスを選択します。主キーと外部キーは、テーブ ルの結合を容易にしてクエリ ビルダ レポートの作成 に役立ちます（『上級レポーティング ガイド』を参 照）。 MicroStrategy に主キーまたは外部キーの情報を表示す ることにより、プロジェクトのデザイン時に、アトリ ビュートの識別列として適切に機能するデータ列を指 定する役に立ちます。 データベース カタログ読み取り時に、すべてのテー ブルの行数をカウント : データ ウェアハウスからの ロード時に、各テーブルの行数をウェアハウス カタ ログで取得する必要があるかどうかを制御する場合 に、このチェック ボックスを選択します。この チェック ボックスを選択すると、ファクト テーブル および集計テーブルを識別する場合に役立ちます。パ フォーマンスが低下するため、行数の取得よりもパ フォーマンスが重要な場合は選択しないでください。 ウェアハウス カタログをはじめて開いたときには、 デフォルトでこのチェック ボックスが選択されてい ます。 データベース カタログの読み取り時に現在のテーブ ル スペースを無視し、新規テーブル名スペースを利 用し更新 : このチェック ボックスを選択すると、異 なるデータベース ネーム スペースにある複数のウェ アハウス間の切り替えができます。詳細は、この付録 の「テーブル移行時のテーブル ネーム スペースの無 視」（346 ページ）を参照してください。デフォルトで は、このチェック ボックスは選択されています。 © 2010 MicroStrategy, Inc. データ ウェアハウスとプロジェクトとの相互作用 : ウェアハウス カタログ 341 9 プロジェクトの最適化と管理 プロジェクト デザイン ガイド テーブル構造を更新中に列データ タイプが変更され た場合、警告を表示 : プロジェクトに格納されている 列のデータ タイプがデータ ウェアハウスから読み取 られた列のデータ タイプと異なるときに警告を行う 場合に、このチェック ボックスを選択します。デー タ タイプの変更のチェックは、テーブル構造の更新 時にのみ実行されます。デフォルトでは、このチェッ ク ボックスは選択されています。 データベース カタログ読み取り時に、すべてのパー ティション マップ テーブルの情報を自動的に更新 : 現在プロジェクトに存在するパーティション マッ ピング テーブル（PMT）の最新情報を読み取る場合 に、このチェック ボックスを選択します。プロジェ クト内の PMT の数が多いために、構造の読み取りに よりウェアハウス カタログを開くときにパフォー マンスの問題が発生する場合は、このチェック ボッ クスをクリアする必要があります。デフォルトでは、 このチェック ボックスは選択されています。 列結合オプション : データ ウェアハウスに新しい テーブルを追加するときに、プロジェクトに含まれる 列のデータ タイプを再定義できます。たとえば、名 前が Table1、データ タイプが char(1) の列 C1 を持つ テーブルがプロジェクトに存在するとします。次に、 名前が Table2 で、C1 列のデータ タイプが char(4) の テーブルを追加します。この例は、次に示すオプ ションの説明に使用します。テーブル構造を更新する ときに、選択したオプションに従って、3 つの方法の いずれかでスキーマの整合性を維持するように列の データ タイプが変更されます。 タイプが互換性のないデータ タイプに変更 データ された場合、次のオプションは結合を処理しま せん。たとえば、列のデータ タイプが char から整 数に変更されたとします。データ タイプが互換性 のないデータ タイプに変更された場合、警告が表 示され、新しいデータ タイプを使用するかどうか が尋ねられます。 – 最新のデータ タイプを使用 : このオプションは、 最新の列定義を使用するように列データ タイプを 更新します。前述の例では、C1 列のデータ タイ プが char(4) に変更されます。これは、Table2 が Table1 の後に追加されたからです。 342 データ ウェアハウスとプロジェクトとの相互作用 : ウェアハウス カタログ © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド プロジェクトの最適化と管理 • 9 – 最大分母のデータ タイプを使用 : このオプション は、精度またはスケールが最大のデータ タイプを 使用するように列データ タイプを更新します。前 述の例では、C1 列のデータ タイプが、Table2 に 定義されている char(4) に変更されます。この理由 は、char(4) の精度が、Table1 に定義されている char(1) の精度よりも高いからです。データ タイプ が互換性のある別のデータ タイプに変更された場 合、次の図に示すように、精度またはスケールが 最大のデータ タイプが使用されます。 – 結合しない : このオプションは、新しく追加した テーブル内の列の名前を変更します。これにより、 列は異なるデータ タイプを持つことができます。 前述の例では、Table1 の列 C1 は、char(1) のデー タ タイプを使用します。Table2 の列 C1 は C1 の別 のコピーとして定義され、char(4) のデータ タイプ を使用します。このオプションにより、意図しな いスキーマの変更が発生することがあるので、必 要な場合にのみ使用してください。 読み取りモード : ウェアハウス カタログは、開いたとき に自動的に読み取りを実行することも、読み取りを手動 で要求したときにのみ実行するように制限することもで きます。 自動 : このオプションは、カタログ ブラウザをロー ドした直後にウェアハウス カタログのテーブルが読 み取られるように設定します。 手動 : このオプションは、カタログの読み取り動作を 選択した場合にのみウェアハウス カタログが読み取 られるように設定します。 © 2010 MicroStrategy, Inc. データ ウェアハウスとプロジェクトとの相互作用 : ウェアハウス カタログ 343 9 プロジェクトの最適化と管理 プロジェクト デザイン ガイド テーブル接頭語、行数、およびネーム スペースの 表示 [ 表示 ] カテゴリを使用して、テーブル接頭語、行数、および ネーム スペースの表示 / 非表示を選択できます。このカテ ゴリは、次のサブカテゴリに分かれています。 • テーブル接頭語 : テーブル接頭語をテーブル名に表示す るかどうか、およびプロジェクトに追加したテーブルに 接頭語を自動的に定義する方法を指定できます。次のオ プションがあります。 メイン ダイアログにテーブル接頭語を表示 : プロ ジェクトに追加される新規テーブルを含めて、テーブ ル名のすべての接頭語を表示するには、このオプ ションを選択します。デフォルトでは、このオプ ションが選択されています。 プロジェクトに追加したすべてのテーブルの接頭語を 自動的に定義 : この設定は、次のオプションを有効 / 無効にします。 – ウェアハウス テーブル名スペースまたは所有者に 基づく接頭語を設定（接頭語をインポート）: この オプションが選択されている場合、ウェアハウス カタログは、追加される各テーブルのネーム ス ペースを読み取り、ネーム スペースと同じテキス トを持つ接頭語を作成して、追加されるテーブル にその接頭語を関連付けます。 – デフォルト接頭語を設定 : プロジェクトへの追加 時にテーブルに接頭語を追加するには、このオプ ションを選択します。このオプションは、データ ベースが接頭語をサポートしている場合にのみア クティブになります。[ デフォルト接頭語 ] ボック スのドロップダウン リストからデフォルト接頭語 を選択することも、[ 接頭語リストを変更 ] をク リックして新しいテーブル接頭語を作成すること もできます。 – 接頭語リストを変更 : このオプションを選択する と、新しいテーブル接頭語の作成、または既存の 接頭語の削除ができます。[ テーブル接頭語 ] ダイ 344 データ ウェアハウスとプロジェクトとの相互作用 : ウェアハウス カタログ © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド プロジェクトの最適化と管理 9 アログ ボックスが開きます。接頭語リストを変更 する方法の詳細は、オンライン ヘルプを参照して ください。 • テーブル行数 : このチェック ボックスを使用して、各 テーブルの行数の表示 / 非表示を切り替えることができ ます。 各テーブルの行数を表示 : テーブルの行数について計 算値の表示 / 非表示を切り替えることができます。デ フォルトでは、このオプションが選択されており、行 数が表示されます。 • テーブル名スペース : このチェック ボックスを使用し て、各テーブルのネーム スペースの表示 / 非表示を切り 替えることができます。 必要ならば各テーブルに名前スペースを表示 : ウェア ハウスにあるテーブルの所有者、またはそのテーブル が存在するテーブル ネーム スペースの表示 / 非表示 を切り替えることができます。デフォルトでは、この オプションは選択されており、ネーム スペースが表 示されます。 スキーマ オブジェクトのマッピング、およびテー ブルの論理サイズの計算 [ スキーマ ] カテゴリは、次のサブカテゴリに分かれていま す。 • 自動マッピング : 新しいテーブルをウェアハウス カタロ グに追加するときに、次のオプションを使用して、プロ ジェクト内の既存のスキーマ プロジェクトをこれらの新 しいテーブルに自動的にマップするかどうかを指定でき ます。 スキーマ プロジェクトを新規テーブルに自動的に マッピング : スキーマ内の既存のオブジェクトが、プ ロジェクトに追加したテーブルに自動的にマップされ ます。 スキーマ プロジェクトを新規テーブルにマッピング しない : スキーマ内のオブジェクトは、プロジェクト に追加したテーブルに自動的にはマップされません。 © 2010 MicroStrategy, Inc. データ ウェアハウスとプロジェクトとの相互作用 : ウェアハウス カタログ 345 9 プロジェクトの最適化と管理 プロジェクト デザイン ガイド これらの自動マッピング方法は、テーブルがウェアハウ ス カタログに追加されたときに、既存のスキーマ プロ ジェクトについてのみ適用されます。たとえば、アトリ ビュート フォームが YEAR_ID にマップされているアト リビュート " 年 " がプロジェクトに含まれているとしま す。次に、YEAR_ID 列を含む新しいテーブルが、ウェア ハウス カタログに追加されます。[ スキーマ プロジェク トを新規テーブルに自動的にマッピング ] オプションを 選択している場合、新しいテーブルを追加するときに " 年 " アトリビュートが自動的にマップされます。 カタログにテーブルが追加 はじめにウェアハウス され、その後にアトリビュートが作成された場合、 ウェアハウス カタログの自動マッピング設定は、 アトリビュートとテーブルを自動的にマップする かどうかを決定しません。プロジェクトにアトリ ビュートやファクトが追加されたときのスキーマ プロジェクトへのテーブルの自動マッピングは、 アトリビュート エディタ、およびファクト エディ タでそれぞれ制御されます。 • テーブル論理サイズ : 次のいずれかのオプションを使用 して、ウェアハウス カタログが新しいテーブルの論理サ イズを計算するかどうかを選択できます。 テーブル論理サイズの自動計算 : プロジェクトに追加 したテーブルについて、論理サイズが自動的に計算さ れます。 テーブル論理サイズを計算しない : プロジェクトに追 加したテーブルの論理サイズは計算されません。 テーブル移行時のテーブル ネーム スペースの無視 開発およびテスト用として、第一ウェアハウスよりも情報量 の少ない第二ウェアハウスを設定することは、一般的な手法 です。実稼働システムに移行する前に、第一ウェアハウスを ポイントするようにプロジェクトを変更します。 ほとんどのデータベース管理システム（Oracle、DB2 など） は、テーブル ネーム スペース の概念をサポートしていま す。テーブル ネーム スペースは、データベース テーブルを さまざまな格納領域に編成する方法です。この方法により、 同じテーブル名を異なるテーブル ネーム スペースで繰り返 し使用できます。たとえば、テーブル ネーム スペース dbo に LU_STORE を持ち、admin という別のテーブル ネーム ス 346 データ ウェアハウスとプロジェクトとの相互作用 : ウェアハウス カタログ © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド プロジェクトの最適化と管理 9 ペースに別のテーブル LU_STORE を持つことができます。 これにより、dbo.LU_STORE および admin.LU_STORE と いう 2 つのテーブルを持つことになります。テーブル ネー ム スペースは、テーブルを一意に識別するための追加情報 を提供します。 プロジェクトにテーブルを追加すると、ウェアハウス カタ ログは、適切なテーブル ネーム スペースに情報を保存しま す。これにより、あるネーム スペースに存在するウェアハ ウスから別のテーブル ネーム スペースにある別のウェアハ ウスに移行するときに、問題が発生することがあります。 ウェアハウス カタログは、テーブルが既にプロジェクトに 存在し、新しいウェアハウスから検出されないと解釈しま す。これは、ウェアハウス カタログが dbo.LU_STORE とい う名前のテーブルを検索したが、新しい実稼働ウェアハウス ではテーブルが実際には admin.LU_STORE として格納され ていることが原因です。 この問題を解決するには、[ データベース カタログの読み取 り時に現在のテーブル スペースを無視し、新規テーブル名 スペースを利用し更新 ] チェック ボックスを選択します。こ のチェック ボックスは、[ ウェアハウス カタログ オプ ション] ダイアログ ボックスの [ カタログ - 読み取り設定 ] オ プション サブカテゴリにあります。このチェック ボックス を選択した場合、ウェアハウス カタログは、カタログ情報 を読み取るときに現在のテーブル ネーム スペースを無視し ます。このため、ウェアハウス カタログは、2 つのテーブル を同じテーブルとして認識し、新しいテーブル ネーム ス ペース情報を保存します。この設定により、ウェアハウス間 での移行がより簡単になります。このチェック ボックスを クリアした場合、ウェアハウス カタログは、デフォルトで テーブル ネーム スペースとテーブル名の両方を使用して テーブルを識別します。 カタログ SQL ステートメントのカスタマイズ Microsoft Access を除く、サポートするすべてのウェアハウ ス プラットフォームで、MicroStrategy は SQL ステートメン トを使用してリレーショナル データベース管理システム (RDBMS) のカタログ テーブルにクエリを実行し、ウェアハ ウス カタログ情報を取得します。この情報として、カタロ グ テーブル、列、および列データ タイプがあります。 © 2010 MicroStrategy, Inc. データ ウェアハウスとプロジェクトとの相互作用 : ウェアハウス カタログ 347 9 プロジェクトの最適化と管理 プロジェクト デザイン ガイド これらのカタログ SQL ステートメントはプラットフォーム ごとに異なり、特定のウェアハウスの特徴に合わせてカスタ マイズできます。 Access にはカタログ テーブルがないので、 Microsoft Access のテーブルや列に関する情報を取得するには、 ODBC 呼び出しを使用する必要があります。デフォ ルトでは、汎用 DBMS データベース タイプには同様 の ODBC 呼び出しが使用されますが、必要に応じて、 汎用タイプのカスタム カタログ SQL を使用すること もできます。 単一パスまたは 2 パスの SQL モードでカタログ情報を読み 取るように、MicroStrategy のウェアハウス カタログを設定 できます。2 パスの SQL モードでは、はじめにデータベー スからテーブルのみを読み取ります。テーブルを選択したと きには、各テーブルの構造は読み取り専用です。これは、対 話型のウェアハウス カタログを作成するときの推奨オプ ションです。この理由は、データベースから不要なカタログ 情報が読み取られず、処理速度が上昇するからです。一方、 単一パスの SQL モードは、1 つの SQL ステートメントです べてのテーブルと列を読み取ります。このオプションは、返 すデータ量を制限するようにカタログ SQL が適切にカスタ マイズされている場合にのみ推奨されます。 2 つの取得オプションは異なるカタログ SQL を使用します が、両方とも、[ ウェアハウス カタログ オプション ] ダイア ログ ボックスでカスタマイズできます。後続の節では、カ タログ テーブル SQL という名前は、ウェアハウスのテーブ ルを取得するカタログ SQL、つまり 2 パスのカタログ取得 で使用される最初の SQL を指します。 フル カタログ SQL という名前は、単一パスでテーブルと列 をすべて読み取るために使用される SQL を指します。 348 データ ウェアハウスとプロジェクトとの相互作用 : ウェアハウス カタログ © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド プロジェクトの最適化と管理 9 カタログ SQL をカスタマイズするには、いくつかの重要な 概念と手順を理解する必要があります。 • 「テーブル ネーム スペース」（349 ページ） • 「SQL のプレースホルダ文字列と不完全なカタログ SQL」 （349 ページ） • 「カタログ テーブル SQL の構造」（350 ページ） • 「フル カタログ SQL の構造」（350 ページ） • 「カタログ SQL の変更」（351 ページ） • 「デフォルトのカタログ SQL」（352 ページ） テーブル ネーム スペース 典型的な RDBMS プラットフォームでは、特定のデータベー ス内でテーブル名は一意に特定されません。テーブル ネー ム スペースはデータベースのパーティションで、その内部 ではテーブル名は一意です。RDBMS のタイプによっては、 このネーム スペースは、データベースの名前、テーブル所 有者、およびデータベースと所有者の組み合わせのいずれに なります。カタログ テーブル SQL とフル カタログ SQL の 両方で、ネーム スペースにより各テーブルに一意の名前が 決まります。これにより、同じテーブル名を持つ複数のテー ブルを混同することが防止されます。 テーブル ネーム スペースはオプションです。重複するテー ブル名によりウェアハウス データベースで問題が発生しな い場合は、カスタマイズしたカタログ SQL でネーム スペー スを省略できます。 SQL のプレースホルダ文字列と不完全なカタログ SQL デフォルトのシステム カタログ SQL には特定のプレースホ ルダ文字列を含めることができ、このプレースホルダ文字列 は、実行時に解決できるか、ユーザが手動で補完する必要が あります。このようなプレースホルダを示します。 • © 2010 MicroStrategy, Inc. #LOGIN_NAME#— 実行時に、データベースへの接続に使 用されたログイン名に自動的に置換されます。使用する ウェアハウスのログインに合わせてカタログ SQL から異 データ ウェアハウスとプロジェクトとの相互作用 : ウェアハウス カタログ 349 9 プロジェクトの最適化と管理 プロジェクト デザイン ガイド なる結果を得る場合は、このテンプレートをカスタム SQL に残すことができます。それ以外の場合は、この テンプレートは、目的のウェアハウス テーブルを所有す るデータベース ユーザの名前に置換されます。 • #?Database_Name?#、#?Schema_Name?#— このカタ ログ SQL のプレースホルダは、実行する前にユーザが入 力する必要がある不完全な SQL 文字列です。文字列は #? で始まり、?# で終わります。Teradata で使用されるコ マンド #?Database_Name?# は、データベース テーブ ルを含むデータベースの名前に置換する必要があります。 DB2 AS/400 および MySQL で使用される #?Schema_Name?# は、プロジェクトのデータベース テーブルが存在するスキーマの名前に置換する必要があ ります。 カタログ テーブル SQL の構造 カタログ テーブル SQL は、テーブルのネーム スペースを示 す列、およびテーブル名を示す列の 2 列を返します。ネーム スペースを指定しない場合、テーブル名の列のみが必要で す。SQL の結果の各行は、テーブルを一意に示す必要があ ります。重複することはできません。テーブル ネーム ス ペースを示す列は、SQL 列別名 NAME_SPACE を使用しま す。テーブル名を示す列は、別名 TAB_NAME を使用します。 次の例は、Oracle 8.0 のデフォルトのカタログ テーブル SQL です。 SELECT DISTINCT OWNER NAME_SPACE, TABLE_NAME TAB_NAME FROM ALL_TAB_COLUMNS WHERE OWNER = '#LOGIN_NAME#' フル カタログ SQL の構造 フル カタログ SQL は、RDBMS プラットフォームとカスタ マイズ内容により、5 ～ 7 列を返します。 次の別名が、返される各列を示します。 • NAME_SPACE（オプション）: テーブル ネーム スペース • TAB_NAME（必須）: テーブル名 • COL_NAME（必須）: 列名 350 データ ウェアハウスとプロジェクトとの相互作用 : ウェアハウス カタログ © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド プロジェクトの最適化と管理 9 • DATA_TYPE（必須）: 列の主要データ タイプを示す文字 列または数値 • DATA_LEN（必須）: 列データの長さまたはサイズを表す 数値 • DATA_PREC（オプション）: 列データの精度を表す数値 • DATA_SCALE（オプション）: 浮動小数点数の列データの スケールを表す数値 フル カタログ SQL は、行を NAME_SPACE（使用できる場 合）、TAB_NAME の順序で返します。 次の例は、Microsoft SQL Server 7.0 のデフォルトのフル カタ ログ SQL です。 SELECT U.name NAME_SPACE, T.name TAB_NAME, C.name COL_NAME, C.type DATA_TYPE, C.length DATA_LEN, C.prec DATA_PREC, C.scale DATA_SCALE FROM sysobjects T, syscolumns C, sysusers WHERE T.id = C.id and T.type in ('U', 'V') AND T.uid = U.uid ORDER BY 1, 2 カタログ SQL の変更 各プロジェクトのデータベースに対して実行するカタログ SQL のカスタマイズや変更ができます。カタログ SQL は、 プロジェクトのウェアハウス カタログ オプションで変更で きます。 プロジェクトのカタログ SQL を変更するには 1 プロジェクトのウェアハウス カタログにアクセスします （「ウェアハウス カタログへのアクセス」（330 ページ）を 参照） 。ウェアハウス カタログが開きます。 2 [ ツール ] メニューの [ オプション] を選択します。[ ウェア ハウス カタログ オプション ] ダイアログ ボックスが開き ます。 © 2010 MicroStrategy, Inc. データ ウェアハウスとプロジェクトとの相互作用 : ウェアハウス カタログ 351 9 プロジェクトの最適化と管理 プロジェクト デザイン ガイド 3 [ カタログ ] カテゴリを展開し、[ 読み取り設定 ] を選択し ます。[Catalog - Read Settings] オプションが表示されま す。 4 [ 設定 ] ボタンをクリックします。次のカタログ SQL のオ プションが表示されます。 Microsoft Access データベースに接 プロジェクトが 続している場合、カタログ SQL の設定は使用でき ません。 上側のペインはカタログ テーブル SQL を制御し、下側のペ インはフル カタログ SQL を制御します。 デフォルトのカタログ SQL お使いのデータベースに対して実行するカタログ SQL をカ スタマイズするときには、さまざまなデータベース プラッ トフォームをサポートするために MicroStrategy が使用する デフォルトのカタログ SQL を調べることを推奨します。お 使いのプロジェクトが接続するデータベースについて、 MicroStrategy でデフォルト カタログ SQL を生成できます。 352 データ ウェアハウスとプロジェクトとの相互作用 : ウェアハウス カタログ © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド プロジェクトの最適化と管理 9 デフォルトのカタログ SQL を生成して表示するには 1 プロジェクトのカタログ SQL のオプションにアクセスし ます（ 「カタログ SQL の変更」（351 ページ）を参照）。カ タログ SQL のオプションを持つダイアログ ボックスが 開きます。 • 上側のペインは、ウェアハウス カタログで使用でき るテーブルのリストを取得するカタログ テーブル SQL を制御します。 • 下側のペインは、選択したテーブルの列情報を取得す るフル カタログ SQL を制御します。 つのペインの SQL 次のステップを実行する前に、2 ステートメントを切り取ってテキスト エディタに貼 り付けてください。これにより、カタログ SQL ス テートメントに対して以前行った変更内容を保存し、 その後、生成するデフォルトのステートメントと比較 できます。 2 お使いのデータベース プラットフォームに対応するデ フォルトのカタログ SQL を生成して表示します。両方の ペインのテキストが、デフォルトのカタログ SQL ステー トメントで上書きされます。 • お使いのデータベース プラットフォームに対応する デフォルトのカタログ テーブル SQL を生成して表示 するには、最上部にある [ デフォルトを使用 ] ボタン をクリックします。 • お使いのデータベース プラットフォームに対応する デフォルトのフル カタログ SQL を生成して表示する には、最下部にある [ デフォルトを使用 ] ボタンをク リックします。 デフォルトのカタログ SQL ステートメントを使用すること も、独自にカスタマイズしたカタログ SQL ステートメント と比較したり組み合わせることもできます。 © 2010 MicroStrategy, Inc. データ ウェアハウスとプロジェクトとの相互作用 : ウェアハウス カタログ 353 9 プロジェクトの最適化と管理 プロジェクト デザイン ガイド テーブルと列のメッセージのトラブルシューティング ウェアハウス カタログを使用しているときに、次のメッ セージが表示されることがあります。 • 「テーブルが見つかりません」 • 「変更した列のデータ タイプ」 • 「テーブルの列が見つかりません」 テーブルが見つかりません これは、プロジェクト内に既に存在する 1 つ以上のテーブル がデータ ウェアハウスから削除された場合に発生します。 次の 2 つのケースがあります。 • ウェアハウス カタログが起動してデータ ウェアハウスか らテーブル情報を取得するときに、プロジェクト内に既 に存在する 1 つ以上のテーブルが存在しないことを検出 した場合は、エラー メッセージが表示されます。次のオ プションから処理を選択できます。 プロジェクトのテーブルを残す : このオプションで は、プロジェクト メタデータ内のすべての情報がそ のまま残されます。ただし、プロジェクトの定義が、 ウェアハウス内の実際の物理構造と矛盾する場合があ ります。これにより、存在しないテーブルのデータを 必要とするレポートを実行するときに、SQL エラー が発生することがあります。 テーブルをプロジェクトから削除 : この場合、変更内 容を保存するまでウェアハウス カタログは依存関係 をチェックしません。依存関係がある場合はそれが表 示され、先に進むか操作をキャンセルするかを選択で きます。 • ウェアハウス カタログが、ウェアハウスにないテーブル 構造の更新を試行すると、テーブルがウェアハウスから 検出されないためにテーブル構造の更新を実行できない ことを示すメッセージが表示されます。この場合、変更 は行われず、元のテーブル構造のままになります。 354 データ ウェアハウスとプロジェクトとの相互作用 : ウェアハウス カタログ © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド プロジェクトの最適化と管理 9 変更した列のデータ タイプ 1 つ以上のテーブルのテーブル構造が更新され、かつその列 データ タイプが変更されている場合は、テーブル名、列名、 元のデータ タイプ、および新しいデータ タイプを示す警告 メッセージが表示されます。[ キャンセル ] をクリックして、 いつでもデータ タイプの変更をすべて元に戻すことができ ます。この結果、変更内容はテーブルおよび列に適用されま せん。 テーブルの列が見つかりません [ 構造を更新 ] を実行したときに、列が存在しないことが検出 されます。この状況が発生した場合、ウェアハウス カタロ グでは次のことがチェックされます。 • 列がスキーマ オブジェクトにマップされていない : この 場合は、エラー メッセージが表示されません。 • 列がスキーマ オブジェクトにマップされている : この場 合は、存在しない列にマップされているオブジェクトの 詳細を示すメッセージが表示され、構造の更新操作が キャンセルされます。構造の更新を続行する前に、マッ ピングを削除するように求められ、元のテーブル構造が 復元されます。 プロジェクト内の複数のデータ ソースへ のアクセス MicroStrategy は、MultiSource Option と呼ばれる Intelligence Server の拡張機能を装備しています。この機能を使用する と、1 つのプロジェクトを複数のリレーショナル データ ソースに接続できます。これにより、さまざまなデータベー スや他のリレーショナル データ ソースからの情報をすべて、 1 つの MicroStrategy プロジェクトに統合し、レポート作成お よび分析ができます。MultiSource Option を使用して取り込 まれたすべてのデータ ソースは、同じリレーショナル ス キーマの一部としてプロジェクトに統合されます。 © 2010 MicroStrategy, Inc. プロジェクト内の複数のデータ ソースへのアクセス 355 9 プロジェクトの最適化と管理 プロジェクト デザイン ガイド 1 つのプロジェクトに含まれる複数のリレーショナル データ ソースにアクセスすることで、多くのメリットとレポート作 成のソリューションが得られます。さまざまなデータ ソー スの情報を 1 つのプロジェクトに統合できることには、明ら かなメリットがあります。中央サーバが提供するデータ ソースのデータにアクセスするだけでなく、個人のリレー ショナル データ ソースにもアクセスできます。 たとえば、営業マネージャが、営業担当者のローカル コン ピュータに保存されているスプレッドシートの予測データを 含めるとします。リレーショナル データ ソースとしてスプ レッドシートに接続することにより、中央データベースから の実際の売上データと共に、予測データを表示できます。 また、MultiSource Option では、標準レポートのフィルタと して第二データソースにアクセスするフリーフォーム SQL、 クエリ ビルダ、および MDX キューブのレポートを使用で きます。フリーフォーム SQL レポートおよびクエリ ビルダ レポートの詳細は、『MicroStrategy 上級レポーティング ガイ ド』を参照してください。MDX キューブ レポートの詳細 は、『MDX Cube Reporting Guide』を参照してください。 MultiSource Option のライセンスを所有している場合は、次 に示す方法で、プロジェクトの複数のデータ ソースにアク セスできます。 • 「データ ソースとプロジェクトとの接続」（356 ページ） • 「プロジェクトへのデータの追加」（358 ページ） データ ソースとプロジェクトとの接続 データベース インスタンスを使用して、プロジェクトを データ ソースに接続できます。データベース インスタンス は、ウェアハウスの接続情報を指定します。たとえば、デー タ ソース名、ログイン ID とパスワード、その他のデータ ソースに固有の情報などです。データベース インスタンス の作成方法の詳細は、『導入と構成ガイド』を参照してくだ さい。 データ ソースのデータベース インスタンスを作成した後、 そのデータベース インスタンスをプロジェクトに接続でき ます。ただし、複数のデータ ソースを 1 つのプロジェクト に含めた場合、すべてのデータ ソースが、プロジェクト用 356 プロジェクト内の複数のデータ ソースへのアクセス © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド プロジェクトの最適化と管理 9 に計画した同じ論理データ モデルおよびウェアハウス構造 に適合する必要があります。論理データ モデルと物理ウェ アハウス構造を計画する方法の詳細は、2 章、「論理データ モデル」、および 3 章、「論理データ モデルのウェアハウス の構造」を参照してください。 次の手順は、複数のデータ ソースを 1 つのプロジェクトに 含める方法を示します。 前提条件 • プロジェクトが作成済みであること。 • プロジェクトに含めるデータ ソースについて、データ ベース インスタンスが作成済みであること。 • 複数のデータ ソースをプロジェクトに接続するには、 MultiSource Option のライセンスが必要です。 プロジェクトに複数のデータ ソースを含めるには 1 Desktop でプロジェクトにログインします。 2 プロジェクトを右クリックし、[ プロジェクト構成 ] を選 択します。プロジェクト構成エディタが開きます。 3 [カテゴリ] リストの [データベース インスタンス] を展開 し、[SQL データ ウェアハウス ] を選択します。 4 [ データベース データ ソース ] ペインで、プロジェクトに 含めるデータ ソースのデータベース インスタンスの横に あるチェック ボックスを選択します。 データベース インスタンスのチェック ボックスを選択す ると、そのデータ ソースがクエリ ビルダやフリーフォー ム SQL でも使用できるようになります。クエリ ビルダ やフリーフォーム SQL で複数のデータ ソースを使用す るには、MultiSource Option のライセンスは不要です。た だし、クエリ ビルダ レポートやフリーフォーム SQL レ ポートで使用できるデータ ソースは一度に 1 つのみで す。クエリ ビルダおよびフリーフォーム SQL の詳細は、 『上級レポーティング ガイド』を参照してください。 © 2010 MicroStrategy, Inc. プロジェクト内の複数のデータ ソースへのアクセス 357 9 プロジェクトの最適化と管理 プロジェクト デザイン ガイド 5 上部近くにあるドロップダウン リストから、第一データ ベース インスタンスとして機能するデータベース インス タンスを選択します。 第一データベース インスタンスはプロジェクトの主要 データ ソースとして機能し、プロジェクトに追加された テーブルのデフォルト データベース インスタンスとして 使用されます。データベースに関連しない VLDB プロパ ティの設定も、第一データベース インスタンスから継承 されます。 6 [OK] をクリックして変更内容を保存し、プロジェクト構 成エディタを閉じます。 7 MultiSource Option で使用するデータ ソースがパラメー ター化したクエリをサポートする場合は、パラメーター 化したクエリの使用を有効にして、MultiSource Option の パフォーマンスを向上できます。パラメーター化したク エリの使用を有効にする方法の詳細は、「データベースの 挿入パフォーマンスの向上 : パラメーター化したクエリ」 （366 ページ）を参照してください。 これで、プロジェクトに含めたデータ ソースにウェアハウ ス カタログや Architect からアクセスして、テーブルをプロ ジェクトにインポートできます（「プロジェクトへのデータ の追加」を参照）。 プロジェクトへのデータの追加 データ ソースをプロジェクトに接続した後、これらのデー タ ソースからデータをプロジェクトに追加できます。これ は、データ ソースからテーブルをプロジェクトにインポー トすることで行います。 ウェアハウス カタログや Architect を使用して、テーブルを プロジェクトにインポートできます。ウェアハウス カタロ グでは、次に示す [ 現データベース インスタンスを選択 ] ド 358 プロジェクト内の複数のデータ ソースへのアクセス © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド プロジェクトの最適化と管理 9 ロップダウン リストを使用して、テーブルのインポート元 のデータ ソースを切り替えることができます。 Architect では、次に示す [ ウェアハウス テーブル ] ペインを 使用して、テーブルのインポート元のデータ ソースを切り 替えることができます。 さまざまなソースからインポートするテーブルがすべて、異 なるテーブル名を使用している場合は、1 つのデータ ソース を使用しているときとまったく同様にテーブルがインポート されます。また、同じ名前を持つ複数のテーブルを異なる データ ソースからインポートすることもできます（「複数の データ ソースにある重複テーブルのサポート」を参照）。 複数のデータ ソースにある重複テーブルのサポート MultiSource Option を使用して、複数のデータ ソースにある 重複テーブルの統合をサポートできます。これにより、 MicroStrategy SQL エンジンは、情報が格納されたデータ © 2010 MicroStrategy, Inc. プロジェクト内の複数のデータ ソースへのアクセス 359 9 プロジェクトの最適化と管理 プロジェクト デザイン ガイド ソースから必要なアトリビュート情報を取得できます。レ ポートやドキュメントのデザイナが追加の検討やタスクを行 うことなく、このプロセスは、この情報をレポートやドキュ メントに返すことができます。 さまざまなデータ ソースから重複するテーブルのコピーを 含めることにより、MicroStrategy は特定タイプのクエリを 1 つのデータ ソース内で実行できます。 たとえば、データ ソースが 2 つあるとします。一方のデー タ ソースは、会社の履歴データを格納しています。他方の データ ソースは、同じビジネス分野の予測データを格納し ています。各データ ソースには、データのコンテキストを 表すアトリビュート情報を格納する、テーブルの重複コピー が含まれています。各データ ソースは、履歴データと予測 データのいずれが使用できるかという点で異なりますが、 ファクトとメトリックを使用することで、これらのデータが お使いの MicroStrategy プロジェクトに統合されます。 このシナリオでは、両方のデータ ソースからアトリビュー ト情報を持つテーブルの各コピーを含めることにより、1 つ のデータ ソース内で一部のクエリを処理できます。これら の重複コピーを含めることにより、履歴データの表示のみが 必要なユーザは、一方のデータ ソース内でそのクエリを解 決できます。同様に、予測データの表示のみが必要なユーザ は、他方のデータ ソース内でそのクエリをすべて解決でき ます。これにより、これらのタイプのクエリに必要な時間と システム リソースが低減されます。これは、1 つのデータ ソース内での動作は、複数のデータ ソースにわたるクエリ の実行よりも効率が高いからです。 Option を使用するこ このシナリオでは、MultiSource とにより、これらの異なるデータ ソースから 1 つの レポートに履歴データと予測データの両方を含めるこ ともできます。ただし、履歴データと予測データは個 別のデータ ソースからのみ使用できるため、このク エリには両方のデータ ソースを含める必要がありま す。 異なるデータ ソースから同じテーブルの複数コピーをプロ ジェクトにインポートするには、次の要件を満たす必要があ ります。 • テーブル名と列名が厳密に一致する必要があります。 360 プロジェクト内の複数のデータ ソースへのアクセス © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド プロジェクトの最適化と管理 9 • テーブルのコピーの 1 つが、プロジェクトで使用する第 一テーブルとして機能する必要があります。このテーブ ルのすべての列が、他のデータ ソースにあるテーブルの もう 1 つのコピーに存在する必要があります。第二テー ブルとして使用されるテーブルのもう 1 つのコピーには、 追加の情報を持つ列を含めることができます。ただし、 追加したこれらの列は、テーブルの追加時にはプロジェ クトに含められません。 • 複数のデータ ソースからテーブルの複数のコピーをイン ポートするときには、はじめに、第一テーブルとして機 能するテーブルをインポートします。第一テーブルを インポートした後に、他方のデータ ソースから第二テー ブルのインポートを開始できます。 第一テーブルをはじめにインポートしない場合、一部の テーブルを削除して、第一テーブルをインポートした後 に、プロジェクトにそれらのテーブルを追加する必要が 発生することがあります。以前 MultiSource Option を使用 していなかった既存のプロジェクトを更新するには、こ のワークフローが必要になることがあります。 • 一致する列のデータ タイプには互換性が必要です。列 データ タイプの互換性について、説明します。 スケールが 0 の 10 進数データ タイプは、整数データ タイプと互換性があります。 スケールが 0 の 数値データ タイプは、整数のデータ タイプと互換性があります。 10 進数データ タイプは、数値データ タイプと互換性 があります。 倍精度浮動小数点型、浮動小数点型、および実数の データ タイプはすべて、相互に互換性があります。 日付データ タイプは、タイムスタンプ データ タイプ と互換性があります。 時間データ タイプは、タイムスタンプ データ タイプ と互換性があります。 Char データ タイプは、VarChar データ タイプと互換 性があります。 その他のデータ タイプは、同じデータ タイプとのみ 互換性があります。 © 2010 MicroStrategy, Inc. プロジェクト内の複数のデータ ソースへのアクセス 361 9 プロジェクトの最適化と管理 プロジェクト デザイン ガイド 日付データ タイプは時間データ タイプとは互換性が なく、NVarChar と NChar のデータ タイプは、VarChar や Char のデータ タイプとは互換性がないことに注意 してください。 次の手順は、ウェアハウス カタログまたは Architect を使用 して、同じテーブルの複数コピーを MicroStrategy にイン ポートする方法を示します。 • 「ウェアハウス カタログを使用する、複数のデータ ソー スからプロジェクトへのテーブルのインポート」（362 ページ） • 「Architect を使用する、複数のデータ ソースからプロ ジェクトへのテーブルのインポート」（364 ページ） ウェアハウス カタログを使用する、複数のデータ ソー スからプロジェクトへのテーブルのインポート 前提条件 • 複数のデータ ソースをプロジェクトに接続するには、 MultiSource Option のライセンスが必要です。 ウェアハウス カタログを使用して、複数のデータ ソースからプ ロジェクトにテーブルをインポートするには 1 Desktop でプロジェクトにログインします。 2 [スキーマ] メニューの [ウェアハウス カタログ] を選択し ます。ウェアハウス カタログが開きます。 3 [現データベース インスタンスを選択] ドロップダウン リ ストから、テーブルが存在するいずれかのデータ ソース のデータベース インスタンスを選択します。テーブルの インポートに使用する最初のデータ ソースは、テーブル の第一データ ソースとして使用するものである必要があ ります。 4 [ データベース インスタンスで使用可能なテーブル ] ペ インから、プロジェクトに追加するテーブルを選択して [>] ボタンをクリックします。テーブルの最初のコピーが プロジェクトに追加され、[ プロジェクトで使用中のテー ブル ] ペインに表示されます。 362 プロジェクト内の複数のデータ ソースへのアクセス © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド プロジェクトの最適化と管理 9 他のデータベース インスタンスからテーブルのコピーを追加 するには 5 [現データベース インスタンスを選択] ドロップダウン リ ストから、テーブルを含む別のデータ ソースのデータ ベース インスタンスを選択します。 6 [ データベース インスタンスで使用可能なテーブル ] ペ インから、プロジェクトに追加するテーブルを選択して [>] ボタンをクリックします。 テーブルの複数のコピーをインポートするために必要な 「複数のデータ ソースにある重複テーブルのサ 条件（ ポート」（359 ページ）を参照）がすべて満たされている 場合、[ ウェアハウス カタログ ブラウザ ] ダイアログ ボックスが開きます。テーブルのコピーをプロジェクト に含めるには、[TABLE_NAME は現データベース インス タンスからも使用可能なことを § 指定 ] を選択して、 [OK] をクリックします。テーブルのコピーがプロジェク トに追加され、[ プロジェクトで使用中のテーブル ] ペ インに表示されます。 別のデータ ソースからテーブルのコピーのインポートを 試行するときに表示されるメッセージを確認します。 他のテーブルを追加して、プロジェクトに含まれるテーブル を設定するには 7 他のデータ ソースからテーブルを追加するには、前述の 「他のデータベース インスタンスからテーブルのコピー を追加するには」の手順を繰り返します。 8 [ プロジェクトで使用中のテーブル ] ペインにあるテーブ ルを右クリックし、[ テーブル データベース インスタン ス ] を選択します。[ 使用可能なデータベース インスタン ス ] ダイアログ ボックスが開きます。 9 [第一データベース インスタンス] ドロップダウン リスト から、プロジェクトの第一テーブルを格納するデータ ソースのデータベース インスタンスを選択します。この 第一テーブルのすべての列が、他のデータ ソースにある テーブルのもう 1 つのコピーに存在する必要があります。 第二テーブルとして使用されるテーブルのもう 1 つのコ ピーにある追加の列は、MicroStrategy プロジェクトには 含まれません。 © 2010 MicroStrategy, Inc. プロジェクト内の複数のデータ ソースへのアクセス 363 9 プロジェクトの最適化と管理 プロジェクト デザイン ガイド 10 [ 第二データベース インスタンス ] ペインには、プロジェ クトで使用できるテーブルの他のデータ ソースがリスト されます。プロジェクトからテーブルのコピーを削除す るには、データ ソースの横にあるチェック ボックスをク リアします。 11 [OK] をクリックします。ウェアハウス カタログに戻り ます。 12 [ 保存して閉じる ] をクリックし、変更内容を保存して ウェアハウス カタログを閉じます。 Architect を使用する、複数のデータ ソースからプロ ジェクトへのテーブルのインポート 前提条件 • 複数のデータ ソースをプロジェクトに接続するには、 MultiSource Option のライセンスが必要です。 Architect を使用して、複数のデータ ソースからテーブルをプロ ジェクトにインポートするには 1 Desktop でプロジェクトにログインします。 2 [ スキーマ ] メニューの [Architect] を選択します。 MicroStrategy Architect が開きます。 3 [ ウェアハウス テーブル ] ペインの [ プロジェクト テーブ ル ビュー ] で、テーブルが存在するいずれかのデータ ソースのデータベース インスタンスを展開します。テー ブルのインポートに使用する最初のデータ ソースは、 テーブルの第一データ ソースとして使用するものである 必要があります。 4 [ ウェアハウス テーブル ] ペインで、プロジェクトに追加 するテーブルを右クリックし、[ テーブルをプロジェクト へ追加 ] を選択します。テーブルの最初のコピーがプロ ジェクトに追加され、Architect の [ プロジェクト テーブ ル ビュー ] に表示されます。 364 プロジェクト内の複数のデータ ソースへのアクセス © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド プロジェクトの最適化と管理 9 他のデータベース インスタンスからテーブルのコピーを追加 するには 5 [ ウェアハウス テーブル ] ペインで、テーブルを含む別の データ ソースのデータベース インスタンスを展開しま す。 6 [ ウェアハウス テーブル ] ペインで、プロジェクトに追加 するテーブルを右クリックし、[ テーブルをプロジェクト へ追加 ] を選択します。 テーブルの複数のコピーをインポートするために必要な 「複数のデータ ソースにある重複テーブルのサ 条件（ ポート」（359 ページ）を参照）がすべて満たされている 場合、[ オプション ] ダイアログ ボックスが開きます。 テーブルのコピーをプロジェクトに含めるには、 [TABLE_NAME は現データベース インスタンスからも使 用可能なことを § 指定 ] を選択して、[OK] をクリックし ます。テーブルのコピーがプロジェクトに追加され、 Architect の [ プロジェクト テーブル ビュー ] に表示され ます。 別のデータ ソースからテーブルのコピーのインポートを 試行するときに表示されるメッセージを確認します。 他のテーブルを追加して、プロジェクトに含まれるテーブル を設定するには 7 他のデータ ソースからテーブルを追加するには、前述の 「他のデータベース インスタンスからテーブルのコピー を追加するには」の手順を繰り返します。 8 [ プロジェクト テーブル ビュー] からテーブルを選択しま す。テーブルの情報が、[ プロパティ ] ペインに表示され ます。 9 [プロパティ] ペインの [第一データベース インスタンス] オプションを選択し、[...]（ブラウズ）をクリックしま す。[ 使用可能なデータベース インスタンス ] ダイアログ ボックスが開きます。 © 2010 MicroStrategy, Inc. プロジェクト内の複数のデータ ソースへのアクセス 365 9 プロジェクトの最適化と管理 プロジェクト デザイン ガイド 10 [第一データベース インスタンス] ドロップダウン リスト から、プロジェクトの第一テーブルを格納するデータ ソースのデータベース インスタンスを選択します。この 第一テーブルのすべての列が、他のデータ ソースにある テーブルのもう 1 つのコピーに存在する必要があります。 第二テーブルとして使用されるテーブルのもう 1 つのコ ピーにある追加の列は、MicroStrategy プロジェクトには 含まれません。 11 [ 第二データベース インスタンス ] ペインには、プロジェ クトで使用できるテーブルの他のデータ ソースがリスト されます。プロジェクトからテーブルのコピーを削除す るには、データ ソースの横にあるチェック ボックスをク リアします。 12 [OK] をクリックします。Architect に戻ります。 13 [ 保存して閉じる ] をクリックし、変更内容を保存して ウェアハウス カタログを閉じます。 データベースの挿入パフォーマンスの向 上 : パラメーター化したクエリ MicroStrategy のパラメーター化したクエリのサポートによ り、情報をデータベースに挿入する必要があるシナリオで、 パフォーマンスを向上できます。パラメーター化したクエリ を使用することでメリットがあるシナリオとして、次の場合 があります。 • MicroStrategy の MultiSource Option を使用して、複数の データ ソースのデータを組み合わせるレポート。 MultiSource Option の詳細は、 「プロジェクト内の複数の データ ソースへのアクセス」（355 ページ）を参照してく ださい。 • 主要なデータ ウェアハウス用のデータベースとは別の データベースに格納された MicroStrategy データ マート。 データ マートの作成方法と使用方法の詳細は、『上級レ ポーティング ガイド』を参照してください。 • 分析エンジンが評価する関数を使用するメトリック。関 数の詳細は、『Functions Reference』を参照してください。 366 データベースの挿入パフォーマンスの向上 : パラメーター化したクエリ © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド プロジェクトの最適化と管理 • 9 通常の計算式として評価されるバンド条件を使用するカ スタム グループ。カスタム グループの詳細は、『上級レ ポーティング ガイド』を参照してください。 パラメーター化したクエリは、データのプレースホルダを使 用できる SQL クエリです。プレースホルダを使用すること により、これらのクエリを再使用できます。このような再使 用の一般的な用途は、データベースへのデータ挿入を複数組 み合わせて 1 つのクエリにすることです。パラメーター化し たクエリの例を示します。 INSERT INTO DMTABLE (Customer_ID, Customer_Name) VALUES (?, ?) 複数の INSERT ステートメントを組み合わせて 1 つのクエリ にすることにより、データベースへのデータ挿入のパフォー マンスを向上できます。次の手順は、MicroStrategy でパラ メーター化されたクエリの使用を有効にする方法を示しま す。 前提条件 • パラメーター化したクエリは、特定のデータベースでの みサポートされています。お使いのサード パーティ デー タベースのドキュメントを参照して、パラメーター化し たクエリをデータベースがサポートできるかどうかを確 認してください。 • プロジェクトが作成済みであること。パラメーター化し たクエリのサポートを有効にするには、このデータベー ス インスタンスがデータベースに接続している必要があ ります。 パラメーター化したクエリの使用を有効にするには 1 MicroStrategy Desktop から、管理者権限のあるユーザ ア カウントを使用してプロジェクト ソースにログインしま す。 2 [ フォルダ リスト ] で、[ 管理 ]、[ 構成マネージャ] の順に 展開し、[ データベース インスタンス ] を選択します。プ ロジェクト ソースのデータベース インスタンスが表示さ れます。 © 2010 MicroStrategy, Inc. データベースの挿入パフォーマンスの向上 : パラメーター化したクエリ 367 9 プロジェクトの最適化と管理 プロジェクト デザイン ガイド 3 データベース インスタンスを右クリックし、[ 編集 ] を選 択します。データベース インスタンス エディタが開きま す。 4 [ データベース接続 ] 領域の右側にある [ 変更 ] をクリック します。[ データベース接続 ] ダイアログ ボックスが開き ます。 5 [ 上級 ] タブの [ パラメーター化したクエリを使用 ] チェッ ク ボックスを選択します。 6 次に示すデータベースのいずれかについてパラメーター 化したクエリを有効にする場合は、次のパラメーターも 含める必要があります。 • Oracle 10g、Oracle 10gR2、Oracle 11g、Oracle 9i、 Sybase Adaptive Server 12.x、または Sybase ASE 15.x に ついてパラメーター化したクエリを有効にするには、 次のパラメーターを [接続の追加文字列パラメーター] フィールドに入力します。 EnableDescribeParam=1 • Teradata 12.0 または Teradata V2R6.2 についてパラメー ター化したクエリを有効にするには、次のパラメー ターを [ 接続の追加文字列パラメーター ] フィールド に入力します。 EnableExtendedStmtInfo=Yes 7 [OK] をクリックして、変更内容を確定して [ データベー ス接続 ] ダイアログ ボックスを閉じます。 8 [OK] をクリックし、データベース インスタンス エディ タを閉じます。 要約テーブルを使用するデータの保存 : 集 計テーブル 集計テーブル とは、データを当初収集して保存するときに 格納したレベルよりも、高いレベルでデータを格納する要約 テーブルです。集計テーブルは頻繁に要求される情報に短時 間でアクセスする一方、データベースにクエリを直接実行し 368 要約テーブルを使用するデータの保存 : 集計テーブル © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド プロジェクトの最適化と管理 9 て質問に答える従来の ROLAP の能力を保持しています。こ の節では、集計テーブルを使用する理由と方法について説明 します。 MicroStrategy では、ファクト テーブルについてのみ集計が 作成されます。この理由は、ルックアップ テーブルと関係 テーブルは通常、非常に小さいからです。集計テーブルにつ いて理解するには、データ モデリングとデータ ウェアハウ スの観点からファクト テーブルについて詳しく知る必要が あります。これらのトピックの詳細は、2 章、「論理データ モデル」、3 章、「論理データ モデルのウェアハウスの構造」、 および 6 章、「ビジネス データの構築ブロック : ファクト」 を参照してください。 集計テーブルを使用する状況 MicroStrategy では、ユーザの質問に答えるために、最適化し た SQL を使用して、リレーショナル データベースに直接ク エリを実行します。ユーザは、ウェアハウスに含まれるデー タがサポートする質問を行い、その後、正確な回答が得られ るまでその結果を分析できます。 このリレーショナル OLAP（ROLAP）手法のデメリットは、 膨大なファクト テーブルにアクセスすると時間がかかる可 能性があることです。マルチディメンション OLAP （MOLAP）が、この問題を解決すると考える人もいます。た だし、MOLAP は、集計のあらゆる組み合わせを多数のアト リビュートとして管理することが困難で、データ量が増加す るので、大型プロジェクトではスケーラブルでありません。 MicroStrategy のソリューションは、集計テーブルを使用し て、頻繁にアクセスするデータに短時間でアクセスできるだ けでなく、ユーザのクエリを処理する能力を保持していま す。 集計テーブルにメリットがある理由は次のとおりです。 © 2010 MicroStrategy, Inc. • 入出力、CPU、RAM、およびスワップの要件が低減され ます。 • 動的計算の実行が不要になります。 • 物理ディスクの読み取り数、およびクエリに回答するた めに読み取る必要があるレコード数が減少します。 要約テーブルを使用するデータの保存 : 集計テーブル 369 9 プロジェクトの最適化と管理 プロジェクト デザイン ガイド • 実行時に集計と並べ替えが必要なデータ量が低減されま す。 • 複雑な論理や膨大な演算を持ち時間がかかる計算が、レ ポートの実行時に実行される動的 SQL から、バッチ ルーチンに移動されます。 つまり、MicroStrategy SQL エンジン、および集計テーブル とキャッシュを組み合わせることにより、MOLAP とほぼ同 じ処理速度で結果が得られます。この組み合わせによるソ リューションでは、質問に対して即座に回答が得られ、また 大型データベースのスケーラビリティも得られます。 集計と事前集計の違い レポートのデータを、データを当初収集したレベルとは別の レベルで表示する必要がある場合は常に、集計、つまりデー タの合算を実行する必要があります。デフォルトでは、集計 はレポートの実行時に SQL ステートメントを使用して動的 に実行されます。 たとえば、売上データが毎日ファクト テーブルに保存され るとします。月次レベルのデータを要求するレポートを実行 します。次の図に示すように、ファクト テーブルの日次の 値の選択、並べ替え、および追加が行われ、月次合計が得ら れます。 370 要約テーブルを使用するデータの保存 : 集計テーブル © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド プロジェクトの最適化と管理 9 また、レポートを実行する前に、集計を完了することもでき ます。集計結果は、集計テーブルに格納されます。このプロ セスは、事前集計 と呼ばれます。ETL プロセスの一部とし て、これらの事前集計テーブル、または集計テーブルを作成 できます。前述の例に示すように、月次レベルの売上データ が頻繁に要求されるときには、売上データを月次レベルにま とめる集計テーブルが便利です。 前述の例に示すように、事前集計により、実行時に大型の低 いレベルのファクト テーブルにある多数のデータベース行 からのデータの読み取り、並べ替え、および計算が不要にな ります。 日次売上のファクト テーブルが最低レベルのファクト テー ブルであり、かつアトミック レベルのデータを含む場合、 このファクト テーブルはベース テーブル と呼ばれます。こ のような関係では、集計テーブルは、既存のベース テーブ ルの集計データから派生したデータを持つファクト テーブ ルです。 © 2010 MicroStrategy, Inc. 要約テーブルを使用するデータの保存 : 集計テーブル 371 9 プロジェクトの最適化と管理 プロジェクト デザイン ガイド 集計の程度 MOLAP は、質問に答えるときに高速のパフォーマンスを発 揮できますが、大部分の質問に回答するにはフルに集計した スキーマが必要です。つまり、マルチディメンション キューブが作成されるときに、集計の関連付けのあらゆる組 み合わせを生成する必要があります。これにより、すべての 質問に確実に回答できます。アトリビュートの個数とデータ 量が増加し、このためあまりスケーラブルではないので、こ のシナリオを維持することは非常に困難になります。 ROLAP 環境では、集計の程度はユーザに合わせて疎と密の いずれにもできます。密集計されたウェアハウスには多数の 集計テーブルがあり、疎集計されたウェアハウスには少ない 数の集計テーブルがあります。疎集計とは、あるプロジェク トでユーザに役立つ個数だけ、ファクト テーブルを集計す る必要があることを指します。 このため、ROLAP は、MOLAP よりも柔軟性が非常に高く なります。有用と判断した集計の組み合わせのみを作成する 必要があります。つまり、集計テーブルが頻繁に実行するク エリへの回答に役立つ場合、集計テーブルが存在することに より、MOLAP システムが提供できるものと同等の速度で応 答できます。ただし、ある集計の組み合わせをまったく、ま たはほとんど使用しない場合、RDBMS のスペースを使用す る必要はなく、バッチ プロセスでそのテーブルを作成する ためのリソースを使用する必要がありません。 すべてのアトリビュート レベルや階層の交差が、事前集計 に適するわけではありません。ユーザに有用な集計テーブル のみを作成します。この理由は、集計テーブルの作成やメン テナンスには、データベース アドミニストレータの追加作 業が必要だからです。また、使用しないテーブルに、データ ベース領域を無駄に使用しないでください。 集計テーブルを作成するかどうかを決定するときには、次の 要件を考慮してください。 • そのレベルのクエリの頻度 —「特定レベルにおけるクエ リの頻度の決定」（373 ページ） • 親と子の関係 —「関連する親子関係の検討」（373 ペー ジ） • 圧縮率 —「圧縮率」（374 ページ） 372 要約テーブルを使用するデータの保存 : 集計テーブル © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド プロジェクトの最適化と管理 9 特定レベルにおけるクエリの頻度の決定 ユーザに役立つ可能性がある場合にのみ、集計テーブルを作 成します。決してアクセスされない集計テーブルは、ディス ク領域を消費し、抽出、翻訳、およびロードのプロセス、さ らにデータベースのバックアップ ルーチンで不要な負荷が 発生します。 ただし、有用性を容易に定量化できないときがあります。た とえば、次の階層について考えてください。 部門レベルにおけるデータの要約は、集計テーブルの優れた 候補と考えられます。ただし、ユーザが非アクティブな商品 を頻繁に除外する場合、クエリでは商品レベルのデータを使 用し、部門データを動的に要約する必要があります。このた め、部門の集計テーブルは、この状況では使用されない可能 性があります。 お使いのウェアハウスを実稼働にした後、集計テーブルの使 用状況を追跡して、毎日のビジネス環境で集計テーブルが使 用される頻度を調べます。使用されないテーブルは、ウェア ハウスから除外します。 MicroStrategy Enterprise Manager では、テーブルの使用状況 を簡単に追跡できます。Enterprise Manager の詳細は、 『MicroStrategy システム管理ガイド』を参照してください。 関連する親子関係の検討 集計テーブルを作成すると、子レコードは通常、関係テーブ ルのキーの組み合わせに基づいて親レコードに要約されま す。階層の関係では、親子関係を変更すると、その関係また は関係に関連するデータを持つすべてのテーブルを更新する 必要があります。これらの関係が動的か静的かにより、テー ブルへの集計方法が異なります。 © 2010 MicroStrategy, Inc. 要約テーブルを使用するデータの保存 : 集計テーブル 373 9 プロジェクトの最適化と管理 プロジェクト デザイン ガイド 動的関係 親エレメントと子エレメントの関係が変化する場合、この関 係は動的 と呼ばれます。このような変化は多くの場合、組 織的または地理的な再編成、商品やサービスの追加、再分 類、廃止により発生します。たとえば、店舗で商品が属する 部門を再分類するように決定することがあります。 動的関係を含む集計テーブルは、関係が変化するたびに再計 算する必要があります。テーブルが大きい場合、このプロセ スには長い時間がかかり、リソースを消費し、バッチ プロ セスが複雑になることがあります。頻繁に変化する場合、集 計テーブルがこの状況に合わせて最適化されていないことを 意味します。変化の頻度、テーブル サイズ、およびバッチ プロセスへの影響を検討して、集計テーブルを持つことのメ リットとデメリットの釣り合いを調整します。 また、階層全体を集計することにより、関係の変化による多 くの問題を防ぐことができます。たとえば、テーブルには、 すべての店舗の合計である 1 つの値が含まれるとします。こ れは、地域階層内の再構成の影響を受けません。 静的関係 エレメントの関係がまったく、またはめったに変化しない場 合、これらのエレメントは静的関係 を構成します。このよ うな場合、集計テーブルの管理は非常に簡単です。たとえ ば、時間階層が動的になることはめったにありません。日付 は別の週に移行することはなく、会計週は、別の月に移動し ません。 圧縮率 データ集計のプロセスは、合計や平均などの集計関数 を子 レコード セットに適用し、親レコードを 1 つ生成します。1 つの親レコードを計算するために組み合わせる子レコードの 平均数は、圧縮率 と呼ばれます。集計テーブルの効果を表 す 1 つの尺度は、この数値から概算できます。圧縮率は、そ のレベルにおけるクエリに応答するために、読み取る必要が あるレコード数を表すからです。 374 要約テーブルを使用するデータの保存 : 集計テーブル © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド プロジェクトの最適化と管理 9 集計テーブルを作成する理由として、ディスクの入出力、お よび動的に並べ替えや集計が必要なレコード数の削減があり ます。このため、事前集計データは、圧縮率が大きい場合に のみ効果があります。たとえば、圧縮率が 3:2 の場合、集計 テーブルにはベース テーブルの格納領域の 2/3 が必要です が、レコード数は 1/3 のみ減少します。反対に、圧縮率が 4:1 の場合、集計テーブルはレコード数を 3/4 削減し、格納 領域は 1/4 のみ使用します。 同じ階層にある 2 つのアトリビュート間でエレメント数の差 が大きい場合、圧縮率は、集計テーブルを使用することによ り一層効率的なクエリを提供できることを示します。また、 小型のベース テーブルでは、動的集計によるデータベース サーバに対するリソースの要件が低減し、同様に事前集計の 効果も同様に低減します。お使いのシステムで事前集計が有 用な状況を判断するには、クエリ応答時間の速さの重要性 と、スキーマを管理するために使用できるディスク容量やリ ソースのバランスをとる必要があります。 圧縮率の詳細は、「カーディナリティと比率」（37 ページ）を 参照してください。 集計テーブルの作成 MicroStrategy Desktop のウェアハウス カタログを使用して、 お使いのプロジェクトに集計テーブルを統合するには、次の 大まかな手順に従います。 既存のプロジェクトで集計テーブルを使用するには 1 ウェアハウス カタログを使用して、テーブルをプロジェ クトに追加します。ウェアハウス カタログを使用して テーブルを追加する手順は、「プロジェクトのテーブルの 追加および削除」（330 ページ）を参照してください。 2 目的のファクト式およびアトリビュート フォーム式で新 しいテーブルを使用します。 お使いの集計テーブル構造と基本ファクト テーブルの構造 に矛盾がない場合は、Architect により、既存のアトリビュー トとファクトの定義に集計テーブルが追加されます。つま り、Architect は、集計を認識します。集計テーブルと基本 © 2010 MicroStrategy, Inc. 要約テーブルを使用するデータの保存 : 集計テーブル 375 9 プロジェクトの最適化と管理 プロジェクト デザイン ガイド ファクト テーブルのいずれでもクエリに回答できるときに、 Architect どのようにして、基本ファクト テーブルではなく 集計テーブルを使用することを知るのでしょうか。この答え は、論理テーブルのサイズです。 プロジェクト内のテーブル サイズ : 論理テーブル サイズ プロジェクトにはじめてテーブルを追加するときに、 MicroStrategy Desktop はプロジェクト内の各テーブルにサイ ズを割り当てます。これらのサイズ割り当てはメタデータに 格納され、テーブルの列、および列に対応するアトリビュー トに基づいて計算されます。Desktop はサイズを割り当てる ときに、概念的なアトリビュート定義、つまり論理アトリ ビュート定義を使用するので、この計算値は、論理テーブル サイズ と呼ばれます。 レポートの実行時に、分析エンジンは、論理テーブル サイ ズに基づいて、クエリに回答できる十分なデータを持つすべ てのテーブルのうちで最も小さいテーブルを選択します。 論理テーブル サイズの変更 論理テーブル サイズの初期値は、アトリビュート列数、お よび対応する階層に論理テーブルが存在するさまざまなレベ ルに基づきます。基本ファクト テーブルに、取引レベルの 詳細が数百万行あると仮定します。一方、他のテーブルに は、それより高いレベルのデータ、つまり要約データのみが あります。アトリビュート レベルは基本ファクト テーブル 内の下の方なので、テーブル全体には、高いレベルのアトリ ビュートを持つ要約テーブルよりも大きい論理テーブル サ イズが割り当てられます。 論理的に、テーブルに含まれるアトリビュートのレベルが高 くなるほど、テーブル サイズは小さくなります。当然、実 際のウェアハウスでは、これは必ずしも正しくはありま せん。このため、論理テーブル エディタでは、実際の相対 サイズに基づいて、論理テーブル サイズを変更できます。 論理テーブル エディタを使用する手順は、MicroStrategy Desktop のオンライン ヘルプを参照してください。論理テー ブルの詳細は、「論理テーブル」（415 ページ）を参照してく ださい。 376 要約テーブルを使用するデータの保存 : 集計テーブル © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド プロジェクトの最適化と管理 9 パフォーマンスを向上させるためのテーブ ルの分割 : パーティション マッピング パーティション マッピング では、月や部門などの定義可能 なデータ レベルに基づいて、大きい論理テーブルをより小 さい物理テーブルに分割します。パーティションにより、 ウェアハウスに対して発行されたクエリに答えるために読み 込むテーブル数およびテーブル内で読み込むレコード数が低 減され、クエリのパフォーマンスが向上します。複数のテー ブルに処理を分散することにより、パーティションはデータ ベース クエリの処理速度と効率を向上します。 時間は、データベースのパーティションを作成するための一 般的なカテゴリです。時間別のパーティションにより、デー タベース テーブルの増加が制限され、安定性が上昇します。 サーバによるパーティションとアプリケーションによる パーティションの違い パーティションの作成は、データベース サーバ、または MicroStrategy アプリケーションにより管理できます。いずれ の場合でも、テーブルにはデータベースのレベルでパーティ ションが作成されます。「アプリケーション」と「サーバ」 の用語は、パーティションが作成されたテーブルの管理を行 うものを指します。テーブルが分割された場所を指している わけではありません。 サーバ レベル パーティション MicroStrategy ではなく、データベース サーバが、RDBMS の サーバレベルのパーティション 内のパーティション化され たテーブルを管理します。元のファクト テーブルが、物理 的に小さいテーブルに分割されるわけではありません。デー タベース アドミニストレータが指定したパラメーターに 従って、データベース サーバによりテーブルが論理的に パーティションに分けられます。パーティションをサポート するために、MicroStrategy でのユーザの操作は不要です。 エンド ユーザに対しては論理テーブルのみが表示されるた め、パーティションは MicroStrategy に対して透過的です。 © 2010 MicroStrategy, Inc. パフォーマンスを向上させるためのテーブルの分割 : パーティション マッピング 377 9 プロジェクトの最適化と管理 プロジェクト デザイン ガイド 一方、アプリケーション レベルでパーティションを作成し た場合、リレーショナル データベースはパーティションで 分割されたテーブルを認識しません。 お使いのプラットフォームのサーバ パーティションの詳細 は、お使いのデータベースのドキュメンテーションを参照し てください。 アプリケーション レベル パーティション アプリケーション レベル パーティション では、RDBMS サーバではなく、アプリケーションがパーティション テー ブルを管理します。パーティション ベース テーブル（PBT） とは、大型のデータ セットの一部を含むウェアハウス テー ブルです。パーティション テーブルは通常、時間や地域な どの論理的なラインに沿って分割されます。MicroStrategy は、次の 2 つのタイプのパーティションをサポートします。 • 「メタデータ パーティション マッピング」（378 ペー ジ）— マッピング情報をプロジェクト メタデータに格納 します。 • 「ウェアハウス パーティション マッピング」（381 ペー ジ）— 特殊なウェアハウス テーブルを使用して、アクセ スするテーブルを決定します。 メタデータ パーティション マッピング メタデータ パーティション マッピング とは、パーティ ション マッピングが実行され、アプリケーション（この場 合は MicroStrategy）がプロジェクト メタデータ内で管理す るパーティション マッピングです。MicroStrategy が、論理 テーブルと物理テーブルとの間のマッピングを管理します。 この手法により、柔軟なパーティション スキーマをより簡 単に指定できます。 メタデータ パーティション マッピングでは、メタデータ パーティション マッピング エディタでパーティション アト リビュートを 1 つ以上指定します。次に、これらのアトリ ビュート内のどのアトリビュート エレメントがどの PBT を ポイントするかを定義します。ここで、適切な PBT を選択 するルールをすべて作成します。これらのルールは、 MicroStrategy のメタデータに格納されます。 378 パフォーマンスを向上させるためのテーブルの分割 : パーティション マッピング © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド プロジェクトの最適化と管理 9 メタデータ パーティション マッピングを作成する手順は、 MicroStrategy Desktop のオンライン ヘルプを参照してくださ い。 同種および異種のパーティション メタデータ パーティションは、同種にも、異種にもできま す。異種パーティションでは、PBT は、異なるレベルに異 なる量のデータを格納できます。たとえば、あるテーブルに は 6 か月分の売上データがあり、別のテーブルには 1 年間の 売上データがあります。PBT のレベル、つまりキーは、 データの格納方法を指します。たとえば、現在の年の売上 データは日次レベルで保存できますが、履歴の売上データは 月別でのみ保存されます。このため、異種パーティションに は追加の長期メンテナンスと構成が必要です。この理由は、 これらのパーティションに含まれるデータは、パーティ ション内のさまざまなレベルに保存されるからです。 MicroStrategy は、各パーティションについて PBT の 1 つの レベルを格納します。あるパーティション内のすべての PBT が同じレベルに格納されていない場合、PBT の最高レ ベルが、パーティションの PBT レベルとして使用されます。 たとえば、前述の例の売上データはすべて、1 つのパーティ ションに格納されます。日次レベルで現在の売上にアクセス することはできません。この理由は、そのパーティションの PBT レベルが月次であり、日次より上位であるからです。 現在のデータを日次レベルのパーティションに格納し、履歴 データを月次レベルの別のパーティションに格納すると、 データにフルにアクセスできます。 一方、同種パーティションでは、同じ PBT レベルに同じ量 のデータを格納する必要があります。PBT の論理構造は同 一にする必要があり、つまり、同じファクトとアトリビュー トが定義される必要があります。前述の例を続けると、各 テーブルの月次レベルに 1 年間のデータを格納する必要があ ります。同種パーティションは、前年の情報など、頻繁にア クセスされるデータで良好に機能します。 アトリビュートのリンク先である特定の PBT を MicroStrategy で定義するときには、PBT が同種と異種のい ずれであるかを指定する必要はありません。PBT にデータ がどのように格納されているかに一部基づいて、 MicroStrategy が自動的に区別します。 © 2010 MicroStrategy, Inc. パフォーマンスを向上させるためのテーブルの分割 : パーティション マッピング 379 9 プロジェクトの最適化と管理 プロジェクト デザイン ガイド データ スライス PBT を作成した後、データ スライスを定義します。データ スライス は、パーティション テーブルにデータのどの部分 を配置するかを表すフィルタとして機能します。このデータ スライスに基づき、MicroStrategy エンジンは、SQL の生成 時にどのテーブルからデータを取得するかが分かります。 データ スライスは、パーティションの元になるパラメー ター（Month=January など）を保持します。すべての月の データを取得するのではなく、サーバは、1 月のみのデータ を持つ特定のテーブルにアクセスすることが分かります。 データ スライスとパーティションを作成することにより、 時間がかかる結合や検索を行うことなく、即座に特定のデー タを取得できます。 MicroStrategy はデータ スライスの正確さや関連を検証でき ないので、妥当で有効なデータ スライスを作成することが 重要です。データ スライスは、データが意味を持つような ものにする必要があります。データ スライスが適切に作成 されていない場合、間違った SQL の生成や間違ったデータ の取得によりエラーが発生することがあります。 データ スライスは、メタデータ パーティションについての み表示され、変更可能です。各パーティション マッピング テーブルには、データ スライスを 1 つ以上含める必要があ ります。異種マッピングでは、データ スライスはさまざま なレベルに存在することができ、さまざまなキーで構成でき ます。 アトリビュート条件 データ スライスを作成するには、アトリビュート条件を使 用します。アトリビュート条件 とは、アトリビュート フォームに適用されるフィルタのタイプです。これらの条件 を使用することで、レポートに返すデータのタイプと量を制 限できます。たとえば、アトリビュート " 国 " を含むレポー トを作成したが、フランスのデータのみを返すようにする場 合、アトリビュート " 国 " について条件を作成し、レポート に表示するエレメントとして " フランス " を選択します。 データ スライスを作成する手順は、MicroStrategy Desktop の オンライン ヘルプを参照してください。 380 パフォーマンスを向上させるためのテーブルの分割 : パーティション マッピング © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド プロジェクトの最適化と管理 9 ウェアハウス パーティション マッピング ウェアハウス パーティション マッピング とは、パーティ ション マッピングの実行と管理が行われる、データ ウェア ハウス内のパーティション マッピングです。MicroStrategy のウェアハウス カタログを使用して、ウェアハウス パー ティションを定義し、特殊な構造を持つテーブルを追加でき ます。このテーブルにはパーティションのマップがあり、こ のテーブルはウェアハウスに格納されます。ウェアハウス パーティションは、任意のアトリビュート数でテーブルを物 理的に分割しますが、これはユーザには表示されません。 ウェアハウス パーティションは、メタデータ パーティ ションとは異なり同種にする必要があります。これにより、 同じ量のデータが同じ PBT レベルに格納され、同じファク トとアトリビュートが定義されます。同種パーティション は、1 月や 2 月のように、同じレベルでデータを分割しま す。月のファクト テーブルおよびウェアハウス パーティ ションの例を示します。同じ年の異なる月など、同じレベル にどのようにデータが存在するかに注意してください。 データをすべて含む元のファクト テーブルは、プロジェク トには取り込まれません。データベース アドミニストレー タが、データ ウェアハウス内に小さい物理テーブルを複数 作成します。各テーブルには、元のファクト テーブルの データのサブセットが含まれます。パーティションに矛盾が なく、最新に維持するのは、データベース アドミニスト レータの責任です。また、データベース アドミニストレー タは、パーティション マッピング テーブル（PMT）の作成 と管理を行います。PMT は、論理全体の一部としてパー ティション ベース テーブルを識別し、追跡するために使用 されます。 © 2010 MicroStrategy, Inc. パフォーマンスを向上させるためのテーブルの分割 : パーティション マッピング 381 9 プロジェクトの最適化と管理 プロジェクト デザイン ガイド PMT の作成後、Desktop または Web で、いずれかの PBT か らの情報を必要とするレポートを実行すると、クエリ エン ジンははじめに PMT に対してプレクエリを実行し、データ をレポートに取り込むためにアクセスする PBT を決定しま す。プレクエリは、フィルタ条件から、アトリビュート ID に関連する PBT 名を要求します。PBT の名前が検出される と、SQL エンジンを呼び出してウェアハウス用の適切な SQL を書き込みます。 パーティション マッピングを使用する ウェアハウス ときには通常、各 PBT テーブルをプロジェクトに取 り込む必要はありません。取り込みを行うと、このよ うなテーブルが間違ってスキーマ プロジェクトに直 接マップされている場合、エラーが発生することがあ ります。プロジェクトには PMT テーブルのみを含め る必要があります。この方法により、関連するすべて のスキーマ プロジェクトを PMT にマップできます。 これにより、PMT はウェアハウス内の正しい PBT に アクセスします。 次の点に注意してください。 • ウェアハウス パーティション内には、データ スラ イスはありません。 • MicroStrategy は、アップグレードしたプロジェク ト、および新規作成したプロジェクトの両方で、 ウェアハウス パーティションをサポートします。 これらのプロジェクトは、ウェアハウス カタログ ブラウザーを使用して追加します。ウェアハウス パーティションを追加する手順は、MicroStrategy Desktop のオンライン ヘルプを参照してください。 メタデータ パーティション マッピングとウェアハウス パーティション マッピングの違い メタデータ パーティション マッピングでは、ウェアハウス に追加のテーブルは不要です。MicroStrategy では通常、ウェ アハウス パーティション マッピングよりもメタデータ パー ティション マッピングが推奨されます。ただし、ウェアハ ウス パーティション テーブルを既に設定済みであり、新 バージョンの MicroStrategy に移行する予定である場合は、 382 パフォーマンスを向上させるためのテーブルの分割 : パーティション マッピング © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド プロジェクトの最適化と管理 9 ウェアハウス パーティションの使用を続行できます。ただ し、はじめてパーティションを作成する場合は、メタデータ パーティション マッピングを実行することを推奨します。 メタデータ パーティション マッピングが推奨される理由は、 レポートを実行するために SQL の生成にクエリ エンジンが 使用するルールを MicroStrategy で作成するからです。メタ データ内に直接パーティションを作成するので、管理が一層 容易になります。 また、ウェアハウス パーティション マッピングとは異なり、 メタデータ パーティション マッピングでは同種と異種の両 方のパーティションを使用できます。異種パーティションで は、PBT は、異なるレベルに異なる量のデータを格納でき ます。ウェアハウス パーティション マッピングでは、同種 のパーティションのみを使用できます。パーティション マッピングの手順は、MicroStrategy Desktop のオンライン ヘ ルプを参照してください。 © 2010 MicroStrategy, Inc. パフォーマンスを向上させるためのテーブルの分割 : パーティション マッピング 383 9 プロジェクトの最適化と管理 プロジェクト デザイン ガイド 384 パフォーマンスを向上させるためのテーブルの分割 : パーティション マッピング © 2010 MicroStrategy, Inc. 10 時間ベースの比較やその他の 比較を定義するためのトラン スフォーメーションの作成 10. はじめに 自社の昨年の売上の増加と、今年の売上の増加を比較する場 合を考えます。このタイプの分析は TY/LY（当年 / 前年）比 較と呼ばれ、時系列で一般的に使用されるフォームであり、 小売、バンキング、および電気通信を含む多くのさまざまな 業種に関連します。 トランスフォーメーションは、プロジェクト内のアトリ ビュートを使用して作成できるスキーマ オブジェクトであ り、時系列分析を実行するために使用される多数の MicroStrategy の手法のうちの 1 つです。 たとえば、昨年の売上対今年ののような差異や増加率の計算 には、トランスフォーメーションを使用することが非常に便 利な方法です。多くの場合、トランスフォーメーションは最 も汎用的な手法であり、再使用や他の時系列分析への適用も できます。トランスフォーメーションを使用するには、レ ポート デザイナがメトリックを作成し、そのメトリックに トランスフォーメーションを適用します。 © 2010 MicroStrategy, Inc. 385 10 時間ベースの比較やその他の比較を定義するためのトランスフォーメーションの作成 プロジェクト デザイン ガイド MicroStrategy に含まれる Lag および Lead の関数を使用し て、トランスフォーメーション的分析をサポートすることも できます。これらの関数を使用することにより、トランス フォーメーションを使用せずに、異なる期間の値を比較する メトリックを定義できます。これらの関数を使用してトラン スフォーメーション的分析をサポートする方法の詳細は、 『Functions Reference』を参照してください。 この章では、さまざまなタイプのトランスフォーメーション とその作成方法を説明します。メトリックについてある程度 理解していることを前提にして、この章ではトランスフォー メーション メトリックについて説明します。メトリック、 およびメトリックやレポートでトランスフォーメーションを 使用する方法の詳細は、『MicroStrategy 上級レポーティング ガイド』の「メトリック」の章を参照してください。 トランスフォーメーションの作成 トランスフォーメーション とはスキーマ オブジェクトであ り、典型的な用途は、オフセット値を適用して（現在の月か ら 1 か月差し引く、など）、指定した期間を別の期間にマッ プすることです。 トランスフォーメーションは通常、プロジェクト デザイナ が定義し、メトリックの定義で使用してそのメトリックの動 作を変更します。そのようなメトリックは、トランスフォー メーション メトリック と呼ばれます。たとえば、時間関連 のトランスフォーメーションは一般的にメトリックで使用さ れ、今年と昨年、現在の日付と月初からの現在の日付まで、 などの異なる時点における値を比較します。メトリックの定 義の一部として任意のトランスフォーメーションを含めるこ とができ、複数のトランスフォーメーションを 1 つのメト リックに適用できます。トランスフォーメーション メト リックはこのガイドの範囲を超えています。トランスフォー メーション メトリックの詳細は、『MicroStrategy 上級レポー ティング ガイド』を参照してください。 「はじめに」で使用した TY/LY 比較の例を思い出してくださ い。今年の売上を計算するには、" 売上 " メトリックを今年 のフィルタと組み合わせて使用します。同様に、昨年の売上 を計算するには、" 売上 " メトリックを昨年のフィルタと組 み合わせて使用します。ただし、これに代わるより柔軟な方 法として、事前に作成された " 前年 " トランスフォーメー 386 トランスフォーメーションの作成 © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド 時間ベースの比較やその他の比較を定義するためのトランスフォーメーションの作成 10 ションを、" 前年売上 " という新規メトリックの定義で使用 する方法があります。たとえば 2003 年に関する 1 つのフィ ルタと、" 売上 " および " 前年売上 " という 2 つのメトリッ クを使用すると、それぞれ 2003 年と 2002 年の売上結果が返 されます。 トランスフォーメーションはルールを表し、さまざまなレベ ルでのそのルールによる影響を記述できます。たとえば " 前 年 " トランスフォーメーションは、特定の年とその前年との 関係を直観的に表します。さらに、ある年の各月が前年の月 とどのように対応するかも表すことができます。同様に、あ る年の各日が前年の各日にどのようにマップされるかも記述 できます。この情報により、トランスフォーメーションが定 義され、すべてのケースが一般的な概念に抽象化されます。 つまり、レポートに含まれる時間アトリビュートに関係な く、1 つのメトリックに " 前年 " トランスフォーメーション を使用できます。 多くの場合、トランスフォーメーションはデータの時間的な 傾向の検出と分析に使用されますが、トランスフォーメー ションは必ずしも時間ベースにする必要はありません。時間 ベース以外のトランスフォーメーションの例として、 Catalog_ID-1 を使用してトランスフォーメーションを実 行する " 今号カタログ / 前号カタログ " があります。 式ベースのトランスフォーメーションとテーブル ベース のトランスフォーメーションの違い 元の値とトランスフォーメーション後の値との関係を表す定 義は、ウェアハウスの列、定数、算術演算子、および数学関 数を使用する式で表すことができます。これは、式ベースの トランスフォーメーションと呼ばれます。ただし、これらの 値を事前計算し、得られた値をトランスフォーメーション用 に設計されたテーブルに保存することが望ましい場合があり ます。この方法は、テーブル ベースのトランスフォーメー ションと呼ばれることがあります。 テーブル ベースのトランスフォーメーションのメリットは、 インデックスを使用してクエリの処理時間を短縮できること です。テーブル ベースのトランスフォーメーションが持つ もう 1 つのメリットは、式よりも柔軟性があることです。こ のようなタイプのトランスフォーメーションのデメリット は、ウェアハウス内に追加テーブルを作成して管理する必要 © 2010 MicroStrategy, Inc. トランスフォーメーションの作成 387 10 時間ベースの比較やその他の比較を定義するためのトランスフォーメーションの作成 プロジェクト デザイン ガイド があることです。ただし、テーブルを一度作成すると、クエ リの処理時間が大幅に短縮されます。TY/LY の例に戻って 説明すると、トランスフォーメーションの定義で Year_ID - 1 のような単純な式を使用することも、データを事前計算 して得られた値をテーブルの列に保存することもできます。 ベースのトランスフォーメーションは、多 テーブル 対多のトランスフォーメーションを実行するときに必 要です。その例は、年次累計の計算です。 式ベースのトランスフォーメーションの動的計算を行うとき の大きなメリットは、データベース アドミニストレータが トランスフォーメーション テーブルの作成と管理を行う必 要がないことです。デメリットは、システムが計算をその度 に実行する必要があることです。 1 つのトランスフォーメーションで、テーブル ベースのト ランスフォーメーションと式ベースのトランスフォーメー ションを組み合わせて使用できます。たとえば、" 年 " と " 月 " に基づいて、前年のトランスフォーメーションを作成 できます。" 年 " アトリビュートの ID のフォーマットは YYYY なので、トランスフォーメーションでは式 Year_ID - 1 を使用できます。" 月 " アトリビュートの ID のフォー マットは「MonthName」なので、トランスフォーメー ションでは数式を簡単には使用できません。その代わりに テーブルを使用する必要があります ° 次の節では、テーブル ベースのトランスフォーメーションと式ベースのトランス フォーメーションの両方を作成する手順を詳しく説明しま す。 テーブル ベースのトランスフォーメーションの作成 次の例は、各年と前年を対応させる MicroStrategy Tutorial の ルックアップ テーブルに基づいて、前年のトランスフォー メーションを作成する方法を示します。このトランスフォー 388 トランスフォーメーションの作成 © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド 時間ベースの比較やその他の比較を定義するためのトランスフォーメーションの作成 10 メーションは次に示すレポートで使用され、今年の売上を前 年の売上と比較します。 メトリック、およレポー トランスフォーメーション トの作成方法の詳細は、『MicroStrategy 上級レポー ティング ガイド』の「メトリック」の章にある「ト ランスフォーメーション メトリック」を参照してくだ さい。 テーブルに基づいて前年のトランスフォーメーションを作成する には 1 MicroStrategy Desktop でお使いのプロジェクトを含むプ ロジェクト ソースにログインし、プロジェクトを展開し ます。 2 [ ファイル ] メニューの [ 新規作成 ]、[ トランスフォーメー ション ] を順に選択します。トランスフォーメーション エディタが開き、[ メンバー アトリビュートの選択 ] ダイ アログ ボックスが表示されます。 3 [ 時間 ] フォルダをダブルクリックして開き、次に [ 年 ] を ダブルクリックします。[ 年 - 新規メンバー アトリビュー ト式を定義 ] ダイアログ ボックスが開きます。 4 [ テーブル ] ドロップダウン リストから [LU_Year] テーブ ルを選択します。[ 使用可能な列 ] リストにテーブルの列 が表示されます。このテーブルには、今年を前年にマッ プする前年の列が含まれていることに注意してください。 © 2010 MicroStrategy, Inc. トランスフォーメーションの作成 389 10 時間ベースの比較やその他の比較を定義するためのトランスフォーメーションの作成 プロジェクト デザイン ガイド 5 [PREV_YEAR_ID] 列をダブルクリックして、この列を式 のボックスに入れます。 6 [OK] をクリックします。 7 ツールバーの [ 保存して閉じる ] をクリックします。ト ランスフォーメーションに " 前年 ( テーブル）" の名前を 付けます。 これで、トランスフォーメーションが作成されました。これ で、レポート デザイナは売上メトリックのトランスフォー メーションを使用して前年の売上を計算でき、次にそのト ランスフォーメーション メトリックを使用して前年の売上 を取得するレポートを作成できます。 式ベースのトランスフォーメーションの作成 この例では、テーブルではなく、式を使用して前年のトラン スフォーメーションを作成する方法を示します。Year_ID の フォーマットは YYYY なので、前年は単純に「Year_ID - 1」 で表されます。たとえば、2005 年から 1 を差し引くと、そ の前の年である 2004 年が得られます。 前述したテーブル ベースのトランスフォーメーションの例 に示したレポートに、このトランスフォーメーションを追加 します。その結果のレポートは、次のようになります。 次の点に注意してください。 390 トランスフォーメーションの作成 © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド 時間ベースの比較やその他の比較を定義するためのトランスフォーメーションの作成 10 • トランスフォーメーション メトリック、およレ ポートの作成方法の詳細は、『MicroStrategy 上級レ ポーティング ガイド』の「メトリック」の章にあ る「トランスフォーメーション メトリック」を参 照してください。 • 式ベースのトランスフォーメーションを使用する レポートのパフォーマンスは、トランスフォー メーションの最適化の VLDB プロパティを使用す る特定のシナリオで向上することがあります。 VLDB プロパティ、およびレポートのパフォー マンスを向上させる方法の詳細は、『システム管理 ガイド』を参照してください。 式に基づいて前年のトランスフォーメーションを作成するには 1 MicroStrategy Desktop の [ ファイル ] メニューから、[ 新規 作成 ]、[ トランスフォーメーション ] を順に選択します。 トランスフォーメーション エディタが開き、[ メンバー アトリビュートの選択 ] ダイアログ ボックスが表示され ます。 2 [ 時間 ] フォルダをダブルクリックして開き、次に [ 年 ] を ダブルクリックします。[ 年 - 新規メンバー アトリビュー ト式を定義 ] ダイアログ ボックスが開きます。 3 [ テーブル ] ドロップダウン リストから [LU_Year] テーブ ルを選択します。[ 使用可能な列 ] リストにテーブルの列 が表示されます。 4 [YEAR_ID] 列をダブルクリックして、この列を式のボッ クスに入れます。 5 式ボックスに -1 を入力します。トランスフォーメー ションにより Year ID から 1 を差し引いて、前年の ID が 計算されます。. 6 [ 検証 ] をクリックします。メッセージ「有効な式です。」 と緑のチェック マークが表示されます。 7 [OK] をクリックします。 8 ツールバーの [ 保存して閉じる ] をクリックします。ト ランスフォーメーションに " 前年 ( 式）" の名前を付けま す。 © 2010 MicroStrategy, Inc. トランスフォーメーションの作成 391 10 時間ベースの比較やその他の比較を定義するためのトランスフォーメーションの作成 プロジェクト デザイン ガイド これで、前年のトランスフォーメーションが作成されまし た。これで、レポート デザイナは売上メトリックのトラン スフォーメーションを使用して前年の売上を計算でき、次に 前の例で作成したレポートにこのトランスフォーメーション を追加できます。 トランスフォーメーションの構成要素 すべてのトランスフォーメーションには、次の構成要素があ ります。 • メンバー アトリビュート : この構成要素には、トランス フォーメーションが適用されるアトリビュート、つまり ルールが適用されるさまざまなレベルが含まれます。 たとえば、MicroStrategy Tutorial の " 前年 " トランス フォーメーションでは、メンバー アトリビュートは " 年 "、" 四半期 "、" 月 "、および " 日 " です。 • メンバー テーブル : これらのテーブルは、メンバー アト リビュートのデータを格納します。 式ベースのトランスフォーメーションでは、各メン バー式は、特定のテーブル（通常は変換されるアトリ ビュートに対応するルックアップ テーブル）に基づ きます。 テーブル ベースのトランスフォーメーションの場合、 これは関係を定義するトランスフォーメーション テーブルです。たとえば、" 前年 " トランスフォー メーションでは、メンバー テーブルは LU_YEAR、 LU_QUARTER、LU_MONTH、および LU_DAY であ り、それぞれメンバー アトリビュート " 年 "、" 四半 期 "、" 月 "、および " 日 " に対応します。 • メンバー式 : 各メンバー アトリビュートに、対応する式 があります。 式ベースのトランスフォーメーションでは、これは数 式です。最も一般的なケースでは、この式では、定 数、算術演算子、数学関数、およびウェアハウスの列 （通常はアトリビュートの ID の列）が使用されます。 たとえば、式として「Year_ID-1」を使用して、" 前年 " トランスフォーメーションを作成できます。ただ 392 トランスフォーメーションの構成要素 © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド 時間ベースの比較やその他の比較を定義するためのトランスフォーメーションの作成 10 し、データをこのような計算に使用できない多くの場 合があります。たとえば、月を 200001（2000 年 1 月） として格納した場合、1 を引いても結果として 1999 年 12 月は得られません。 テーブル ベースのトランスフォーメーションでは、 これは単純に、トランスフォーメーションをサポート するデータを組み込んだ特定のウェアハウス テーブ ルの列です。この場合、ルールは式に組み込まれず、 列のデータに直接組み込まれます。データがルールを 定義するので、この手法ではトランスフォーメー ションの定義で大きな柔軟性が得られます。これは、 簡単な式でルールを表すことができない場合に、特に 効果的です。実際、多対多のトランスフォーメー ションの場合、別のテーブルが必要です。 たとえば、" 前年 " トランスフォーメーションのメン バー式は、LY_DAY_DATE、LY_MONTH_ID、 LY_QUARTER_ID、および PREV_YEAR_ID です。こ れらは、メンバー テーブルのフィールドに設定され たルックアップ テーブルのすべての列です。 • マップ タイプ : この構成要素は、データの特性に基づい てトランスフォーメーションを作成する方法を決定しま す。マッピングは、次のいずれかになります。 1 対 1: 典型的な 1 対 1 の関係は、 「前年と当年」です。 当年のある日またはある月が、前年のある日またはあ る月に厳密にマップされます。 多対多 : 典型的な多対多の関係は、年次累計です。年 次累計の計算では、ある日付について、その他多くの 日付が含まれます。 重カウン 多対多のトランスフォーメーションでは、2 トが発生することがあります。たとえば、多対多のト ランスフォーメーションとして "YearToDate"、トラン スフォーメーション メトリックとして " 売上（YTD） " を定義した場合を考えます。このメトリックが、 テンプレートのメンバー アトリビュートである " 日 " アトリビュートを含まないレポートで使用されると仮 定します。このレポートでは、日付範囲がフィルタに 指定されます。この場合、" 売上（YTD）" メトリッ クは 2 重にカウントされません。 © 2010 MicroStrategy, Inc. トランスフォーメーションの構成要素 393 10 時間ベースの比較やその他の比較を定義するためのトランスフォーメーションの作成 プロジェクト デザイン ガイド トランスフォーメーション メトリックお よび結合子アトリビュート 「結合子関係」（278 ペー この節の内容に進む前に、 ジ）の結合子アトリビュートと関係の説明を参照して ください。 レポートのトランスフォーメーション メトリックは、変換 したデータ（トランスフォーメーションの値）を持つ現在の アトリビュートを表示します。たとえば、レポートに "Quarter"（四半期）、およびトランスフォーメーション メト リック "Last Year’s Revenue"（前年売上）が含まれます。次 に示すように、各四半期、および前年の売上が表示されま す。 結合子アトリビュート（他の間接的に関係するアトリビュー トの交差部に存在するアトリビュート）を追加すると、矛盾 が発生します。 結合子アトリビュートの詳細は、「結合子関係」（278 ペー ジ）を参照してください。 たとえば、結合子アトリビュート "Promotion"（販促）を前 述のレポートに追加します。結合子 "Quarter"（四半期）と "Item"（商品）には、時間に関連しないものがあるので、こ の結合子アトリビュートを変換することはできません。レ 394 トランスフォーメーション メトリックおよび結合子アトリビュート © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド 時間ベースの比較やその他の比較を定義するためのトランスフォーメーションの作成 10 ポートには、四半期、特定の四半期に関連する販促、および 日付と販促の組み合わせによる 1 年前の売上データが表示さ れます。サンプル レポートは次のようになります。 表示されるアトリビュートは現在のものであり、変換後の データを示します。ただし、結合子アトリビュート "Promotion"（販促）は、本質的に、時間ディメンションと 非時間ディメンションの両方に存在するので、トランス フォーメーションをどのように実行するかは、直観的ではあ りません。 バレンタイン デイの販促が 2003 年にあるが、2002 年にはな いことに注意してください。. この販促を 2002 年に表示しよ うと考えた場合でも、メトリック値のみが変換され、アトリ ビュートは変換されないことに注意してください。つまり、 バレンタイン デイの販促は 2002 年には実施されていないの で、バレンタイン デイと 2002 年第 1 四半期の組み合わせを レポートに表示することはできません。つまり、前年のト ランスフォーメーションが存在しているにもかかわらず、 2002 年第 1 四半期について、バレンタイン デイの販促は表 示されません。これは、トランスフォーメーションが、 "Revenue"（売上）のようなメトリック値を「変換」し、 "Promotion"（販促）のようなアトリビュートを変換しない からです。 © 2010 MicroStrategy, Inc. トランスフォーメーション メトリックおよび結合子アトリビュート 395 10 時間ベースの比較やその他の比較を定義するためのトランスフォーメーションの作成 396 トランスフォーメーション メトリックおよび結合子アトリビュート プロジェクト デザイン ガイド © 2010 MicroStrategy, Inc. A MICROSTRATEGY TUTORIAL A. はじめに この付録では、データ モデルや物理ウェアハウス スキーマ も含めて、MicroStrategy Tutorial について説明します。 MicroStrategy Tutorial とは MicroStrategy Tutorial は MicroStrategy のプロジェクトの 1 つ で、MicroStrategy プラットフォームの機能を説明するために デザインされたメタデータ、ウェアハウス、および一連のデ モ アプリケーションが含まれています。 プロジェクトとは、データ ウェアハウス、メタデータ リポ ジトリ、およびユーザ コミュニティが交わる最上位のオブ ジェクトです。概念的に、プロジェクトとは、すべての関連 レポートが実行される環境です。一般的なプロジェクトに は、レポート、フィルタ、メトリック、および関数が含まれ ます。レポートを実行するためにユーザがアクセスするプロ ジェクトを作成します。 © 2010 MicroStrategy, Inc. MicroStrategy Tutorial とは 397 A プロジェクト デザイン ガイド MicroStrategy Tutorial MicroStrategy Tutorial のプロジェクトでは、電子機器、書籍、 映画、および音楽製品を販売する小売店舗の 2006 ～ 2008 年 の期間を扱います。MicroStrategy Tutorial のプロジェクトに は、次の主要な機能があります。 • " 顧客 "、" 地域 "、" 製品 "、および " 時間 " などの階層 があります。各階層は、MicroStrategy Desktop および MicroStrategy Web からグラフィカルに表示できます。 • 多数の顧客と販売商品があります。 • " 顧客分析 "、" エンタープライズ パフォーマンス マネー ジメント "、" 人事分析 "、" 在庫および物流サプライ チェーン分析 "、" 売上高と収益性分析 "、および " サプ ライヤ分析 " のレポート領域があります。 • " 顧客 "、" 在庫 "、" 時間 "、" 製品 "、" 従業員 "、" コー ル センタ " などの特定の分析領域に着目して、 MicroStrategy Desktop や MicroStrategy Web からレポート を作成するオプションがあります。 MicroStrategy Tutorial のレポート領域 MicroStrategy Tutorial のレポートやドキュメントは、 MicroStrategy Tutorial のプロジェクトの Public Objects\Reports フォルダ内にあるさまざまなフォルダ にまとめられています。これらのレポートやドキュメント は、次のフォルダにまとめられています。 • ビジネス ロール : このフォルダには、請求マネージャ、 ブランド マネージャ、カテゴリ マネージャ、経営者、地 区営業マネージャ、運用管理者、地域営業マネージャ、 サプライヤなど、組織内のさまざまなタイプのビジネス インテリジェンス ユーザ向けのサブフォルダがありま す。 各サブフォルダには、サブフォルダの名前となっている ビジネス ユーザの関心を引くレポートが用意されていま す。たとえば、[ 請求マネージャ ] フォルダには、インボ イス レポートや顧客レベルの取引明細レポートがありま す。[ サプライヤ ] フォルダにはサプライヤ売上レポート、 [ ブランド マネージャ ] サブフォルダには、地域別のブ ランド パフォーマンスのレポートが格納されています。 • 398 MicroStrategy Tutorial とは ダッシュボードとスコアカード : このフォルダには、異 なるタイプのスコアカードやダッシュボードのさまざま な例があります。MicroStrategy の Report Services ドキュ © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド MicroStrategy Tutorial A メントを使用して、スコアカードやダッシュボードを作 成できます。このタイプの Report Services ドキュメント は、状況を簡単に確認できるように、主要なビジネス指 標をまとめたデータを視覚的にわかりやすく表示します。 ダッシュボードは通常、対話型の機能を備えており、 ユーザはこの機能を使用してダッシュボードのデータの 表示方法を変更できます。ダッシュボード、スコアカー ド、その他の Report Services ドキュメントの作成および 使用方法の詳細は、『Report Services ドキュメント作成ガ イド』を参照してください。 • エンタープライズ レポート ドキュメント : このフォルダ には、スコアカードとダッシュボード、管理メトリック レポート、実動と運用のレポート、請求書と明細書、ビ ジネス レポートなど、さまざまなタイプの標準的なエン タープライズ レポート ドキュメントの例が含まれていま す。これらは、MicroStrategy Report Services を使用して 作成できるいくつかのレポート ドキュメントのサンプル です。 • MicroStrategy プラットフォーム機能 : このフォルダに は MicroStrategy プラットフォームに含まれるさまざまな 高機能のサンプルが含まれます。ソフトウェアの評価担 当者、および顧客は、これらの例を使用して多くのプ ラットフォーム機能に慣れることができます。顧客はこ れらの例を、独自の MicroStrategy アプリケーションを開 発するときの参考として使用できます。 これらのフォルダの下にあるサブフォルダには、その中 のレポートが持つ機能を表す名前が付けられています。 たとえば、[ グラフ スタイル ] フォルダには MicroStrategy で作成できる多くのグラフ タイプの例、 [MicroStrategy Data Mining Services] フォルダ には線形回帰モデル、および MicroStrategy で作成できる その他のデータ マイニング モデルの例が含まれていま す。 • サブジェクトエリア : このフォルダには、さらにトピッ ク別に分類できるレポートがあります。トピックには、" 顧客分析 "、" エンタープライズ パフォーマンス マネー ジメント "、" 人事分析 "、" 在庫および物流サプライ チェーン分析 "、" 売上高と収益性分析 "、および " サプ ライヤ分析 " があります。 顧客分析 : " 顧客の所得 "、" 顧客数 "、"1 顧客当たりの 売上 "、" 売上成長率 " などの領域を調査して、顧客 ベースを分析するレポートがあります。 © 2010 MicroStrategy, Inc. MicroStrategy Tutorial とは 399 A MicroStrategy Tutorial プロジェクト デザイン ガイド エンタープライズ パフォーマンス マネージメント : このレポートには、売上の合計、傾向と見通し、利 益、利益率、および利益見通しが含まれています。経 営者は、これらのレポートを見て、会社全体、または 地域、カテゴリ、およびサブカテゴリの任意のレベル で会社のパフォーマンスを容易に理解できます。 人事分析 : 従業員の人数、生年月日、勤続期間、売上 がトップ 5 の従業員など、従業員に関する情報を持つ レポートがあります。これらのレポートは、従業員、 時間、地域、および売上をベースにしています。" 人 事分析 " レポートにより人材に対する見識が得られる ので、マネージャは従業員の効率と効果を引き上げる ことができます。人事担当者は、パフォーマンスの低 い従業員、および不適切な人員配置を特定できます。 マネージャは、すべてのレベルで、従業員のパフォー マンスに着目して、各従業員の詳細レベルへのドリル ダウン、傾向の表示、および他の方法では明白になら なかったインテリジェンスの抽出ができます。 在庫とサプライチェーン分析 : " 在庫と売上数量 "、" 四 半期別サプライヤからの受取り在庫 " など、サプライ ヤ、製品、コスト、売上、利益に基づく情報を持つレ ポートがあります。" 在庫 " レポートは、社内、およ びサプライヤにいたるまでの在庫情報を追跡します。 基本的に、これらのレポートには、在庫商品数、特定 サプライヤからの入庫予定数、およびこれまでの販売 数が示されます。" 在庫 " レポートは、サプライ チェーンが可能な限り効率的であることの確認に使用 します。従業員は、これらのレポートを使用して、傾 向と詳細の分析、在庫と配送の短時間での調整、およ びベースとなるサプライ チェーンのコストや非効率 性について理解できます。 売上高と収益分析 : 複数の観点から売上と利益を分析 するレポートがあります。たとえば、" 地域別売上 "、 " 経時変化売上 "、" 地域別のブランド パフォーマン ス " などです。マネージャやアナリストは、" 製品売 上 " レポートを使用して、売上傾向のモニタと分析、 会社の売上目標の追跡、および店舗別のパフォーマン スの比較を行い、市場からのフィードバックに対して より短期間で正確に対応できます。また、経営者は、 売上の傾向と詳細の分析、価格と販売促進の短期間で の調整、製品の親和性や主要な事業部の特定、および コストと売上の傾向の理解ができます。 400 MicroStrategy Tutorial とは © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド MicroStrategy Tutorial A サプライヤ分析 : " サプライヤごとのブランド売上 "、" サプライヤごとの販売実績（%）"、" サプライヤ別ユ ニット単位の売上と収益 " など、サプライヤ、営業、 収益、および売上情報を持つレポートがあります。" サプライヤ " レポートにより、マネージャやアナリス トはベンダのパフォーマンスのモニタと分析ができる ので、パフォーマンス上の問題を即時に特定できま す。これらのレポートは、特定ベンダのブランドおよ び販売商品を追跡します。また、レポートは利益と売 上の情報を特定サプライヤと関連付けるので、主要 ベンダとの関係を強化できます。 MicroStrategy Tutorial のデータ モデル 論理データ モデルは、ビジネス環境でのデータの流れと構 造を視覚的に表します。論理データ モデルはファクトの編 成方法の 1 つで、さまざまなビジネス上の観点からファクト を分析できます。たとえば、小売会社の単純な論理データ モデルは、小売業務に通常、関連付けられる一般的なビジネ ス上の 3 つの観点である、店舗別、製品別、および時間別 に、必要なすべてのファクトを編成できます。 データ モデリングの詳細は、2 章、「論理データ モデル」を 参照してください。 MicroStrategy Tutorial では、前述した分析領域である " 顧客 分析 "、" 人事分析 " などが、次の階層グループに編成され ています。 • 「地域階層」（402 ページ） • 「製品階層」（404 ページ） • 「顧客階層」（405 ページ） • 「時間階層」（408 ページ） © 2010 MicroStrategy, Inc. MicroStrategy Tutorial のデータ モデル 401 A プロジェクト デザイン ガイド MicroStrategy Tutorial データ モデリングの表記 階層を視覚的に表す場合、次の表記を使用します。 記号 意味 定義 エントリ ポ イント エントリ ポイントは、データ エクスプローラのアトリビュート エレ メントへのショートカットです。エントリ ポイントを作成すると、階 層のさまざまなレベルに到達するために複数のアトリビュートをブラ ウズしなくても、目的のアトリビュートに即座にアクセスできます。 アトリビュー ト システム設計者により定義され、データ ウェアハウス ルックアップ テーブル内の 1 つ以上の列と関連付けられるデータ レベル。アトリ ビュートには、" 地域 "、" 注文番号 "、" 顧客 "、" 年齢 "、" 商品 "、" 都市 "、" 年 " などのデータ分類が含まれます。アトリビュートを使用 して、特定のレベルで集計とフィルタリングを行うことができます。 1 対多関係 親アトリビュートの各エレメントが子アトリビュートの複数のエレ メントに関連し、子アトリビュートの各エレメントが親アトリビュー トの 1 つのエレメントにのみ関連するアトリビュートの関係。アトリ ビュートの 1 対多関係は、データ モデルで最も一般的です。 地域階層 地域階層には、" 国 " や " 地域 "、" 配送センタ "、" コール センタ " などのアトリビュート、および従業員に固有のアト リビュートがあります。" 国 " や " 地域 " が地域階層に含ま れることは簡単にわかりますが、" 配送センタ "、" コール センタ " および従業員に関連するアトリビュートはどうで しょうか。 MicroStrategy Tutorial で使用されるデータは、電子機器、映 画、音楽製品、書籍を販売する架空の会社をベースにしてい ます。この会社には物理的な店舗はありませんが、その代わ りにカタログと Web での販売事業を行っています。顧客は 印刷カタログやオンライン カタログで商品を調べて、電話 で注文します。この注文は、いずれかのコール センタにい る従業員が処理します。次に、この注文は、該当商品の在庫 がある配送センタによって処理され、いずれかの配送会社に より注文商品が送付されます。 402 MicroStrategy Tutorial のデータ モデル © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド A MicroStrategy Tutorial 地域階層には、次のアトリビュートがあります。 アトリビュート 説明 例 コール センタ 電話注文を受けるところです。コール センタは、さまざまな 市区町村にあります。 アトランタ、ボス トン、チャールス トン。 国 会社が現在事業を行っている国、または将来、事業展開を希 望している国。また、従業員が勤務している国を指すことも あります。 米国、スペイン、フ ランス。 配送センタ 商品注文を顧客に配送する配送元。現在、各配送センタは、 対応するコール センタと同じ市町村にあります。 マイアミ、ニューオー リンズ、ファーゴ。 従業員 地域階層で最も下のレベルであり、各注文を担当する個人を 表します。 Jennifer Lee、Laura Kelly。 従業員年齢 各従業員の年齢。 29, 36, 52. 従業員生年月日 各従業員の生年月日。 5/6/66, 1/1/77. 従業員勤続年数 従業員が組織に勤務している年数。 3, 5, 6. 入社日 特定の従業員が入社した日付。 2/16/97, 3/15/99. マネージャ 特定のコール センタの責任者。 Peter Rose、Alice Cooper。 地域 それぞれの国は、複数の地域に分割されます。 中部、北西部、南西 部。 給与 従業員に 1 年間に支給する金額。 24,000, 35,000. 上の表に示したアトリビュートは、最もよく使用されるアト リビュートの一部であり、地域階層の論理定義に組み込まれ © 2010 MicroStrategy, Inc. MicroStrategy Tutorial のデータ モデル 403 A プロジェクト デザイン ガイド MicroStrategy Tutorial ています。地域階層にあるすべてのアトリビュートの論理関 係を詳細に理解するには、次の図を参照してください。 製品階層 製品階層には、" カテゴリ "、" ブランド "、" カタログ "、" サプライヤ " などのアトリビュートがあります。 製品階層には、次のアトリビュートがあります。 アトリビュート 説明 例 Brand（ブラン ド） 特定の商品の製造元またはアーティスト。 Ayn Rand、3Com、ソ ニー。 Catalog（カタ ログ） 商品の販売に使用する媒体。 2006 年春号、2007 年 秋号。 Category（カ テゴリ） 商品は、最高レベルのカテゴリに分類されます。 電子機器、音楽。 404 MicroStrategy Tutorial のデータ モデル © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド A MicroStrategy Tutorial アトリビュート 説明 例 Discontinued Code（廃止 コード） 0 = 廃止された商品、1 = 廃止されていない商品。 0, 1. Item（商品） 販売する個々の商品。 The Great Gatsby、 Sony Discman。 Subcategory カテゴリ内で商品のサブセットをさらに分類するために使 （サブカテゴリ） 用します。 ビジネス、カメラ、ド ラマ。 Supplier（サプ ライヤ） ブランド セットの供給者。 McGraw Hill、Disney Studios。 Warranty（保 証） 故障した商品を製造元が修理する期間の月数（Narrowcast Server に固有）。 3, 5. 上の表に示したアトリビュートは、最もよく使用されるアト リビュートの一部であり、製品階層の論理定義に組み込まれ ています。製品階層にあるすべてのアトリビュートの論理関 係を詳細に理解するには、次の図を参照してください。 顧客階層 顧客階層には、顧客年齢、所得階層、支払方法、発送日な ど、顧客が属する層や購入に関する情報があります。 © 2010 MicroStrategy, Inc. MicroStrategy Tutorial のデータ モデル 405 A プロジェクト デザイン ガイド MicroStrategy Tutorial 顧客階層には、次のアトリビュートがあります。 アトリビュート 説明 例 Customer（顧 客） 各顧客の名前。 Selene Allen、Chad Laurie。 特定顧客の現時点での年齢。 26, 38, 59. 顧客の生年月日。 8/4/50, 4/30/72. 各顧客の州（県）は、複数の市区町村に分割されま す。 アルバニー、シカゴ、メン フィス。 顧客が住んでいる国。 米国、スペイン、フランス。 Customer Age （顧客年齢） Customer Birth Date（顧客生年 月日） Customer City （顧客都市） Customer Country（顧客 の国） Customer 顧客が住んでいる地域。 Region（顧客地 域） 北東部、南部、フランス。 Customer State （顧客州） 個々の顧客地域は、複数の州（県）に分割されま す。 メイン、ノースダコタ。 Income Bracket （所得階層） 顧客が通知した所得範囲。 $31,000 - 40,000, $61,000 70,000. Order（注文番 号） 購入商品の特定グループに関連付けられた追跡番 号。 167, 2635. Payment Method（支払 方法） 注文に対して顧客が支払う方法。 Amex、小切手。 Promotion（販 促） 商品が販売される特定のディスカウント期間の日付 範囲（セールス日付）。 9/1/06 - 9/4/06, 2/16/07 2/19/07. Promotion Type （販促タイプ） ディスカウント期間の提供タイプ（セール タイプ）。 クリスマス セール、新学期 セール Rush Order（特 顧客が注文の特急配送を選択したかどうかを示しま 急注文） す。 1（特急注文）、0（特急注文で はない）。 Ship Date（発 送日） 配送センタから注文が発送された日付。 9/15/06, 3/26/07. Shipper（発送 会社） 製品を顧客に発送するために使用したベンダ。 Pronto Packages、MailFast。 Zip Code（郵便 番号） 顧客の所在地を区別するための最下位レベル。 07026, 36303. 406 MicroStrategy Tutorial のデータ モデル © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド MicroStrategy Tutorial A 上の表に示したアトリビュートは、最もよく使用されるアト リビュートの一部であり、顧客階層の論理定義に組み込まれ ています。顧客階層にあるすべてのアトリビュートの論理関 係を詳細に理解するには、次の図を参照してください。 © 2010 MicroStrategy, Inc. MicroStrategy Tutorial のデータ モデル 407 A プロジェクト デザイン ガイド MicroStrategy Tutorial 時間階層 時間階層には、"Year"（年）、"Quarter"（四半期）、"Month" （月）、"Day"（日）などの時間に固有のアトリビュートがあ ります。 時間階層には、次のアトリビュートがあります。 アトリビュート 説明 例 Day（日） 購入日のカレンダ上の日付。 5/14/06, 12/26/07. Month（月） 購入を行った月。 2006 年 7 月、2007 年 8 月。 Month of Year（カ レンダ月） 購入を行ったカレンダ上の月。 1 月、11 月。 Quarter（四半期） 購入を行ったカレンダ上の四半期。 2006 年第 2 四半期、2007 年第 3 四半期。 Year（年） 購入を行ったカレンダ上の年。 2006, 2007, 2008. 時間階層にあるすべてのアトリビュートの論理関係を詳細に 理解するには、次の画像を参照してください。 408 MicroStrategy Tutorial のデータ モデル © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド A MicroStrategy Tutorial MicroStrategy Tutorial のデータ モデルの表示 MicroStrategy Tutorial のデータ モデルは前のページに示しま したが、MicroStrategy Architect を使用して、直接表示するこ ともできます。 Architect を使用して MicroStrategy Tutorial のデータ モデルを 表示するには 1 MicroStrategy Tutorial を現在使用していない場合は、 MicroStrategy Tutorial を含むプロジェクト ソースにログ インして、[MicroStrategy Tutorial] プロジェクトを展開 します。管理者権限を持つユーザとしてログインする必 要があります。 2 [MicroStrategy Tutorial] プロジェクトを右クリックし て、[Architect] をクリックします。MicroStrategy Architect が開きます。 3 [ 階層表示 ] の [ 階層 ] ドロップダウン リストにある [ シス テム階層 ] をクリックします。システム階層が表示され ます。 プロジェクトのシステム階層は、プロジェクト内にある すべてのアトリビュートの関係を定義します。アトリ ビュートの関係は、エンジンが SQL を生成する方法、 テーブルと列の結合方法と使用方法、およびテーブル間 の関係の有無を規定します。Architect を使用してアトリ ビュートの関係を定義する方法の詳細は、「アトリビュー ト関係の定義」（173 ページ）を参照してください。 4 階層のドロップダウン リストから、[ 顧客 ]、[ 地域 ]、[ 製 品 ]、[ 時間 ] など、さまざまな階層を選択できます。これ らの階層は、アトリビュート間のブラウズやドリルの機 能を定義するユーザ階層です。Architect を使用してユー ザ階層を作成する方法の詳細は、「ユーザ階層の作成と変 更」（181 ページ）を参照してください。 5 階層のレイアウト表示を保存するには、[ ファイル ] メ ニューの [ イメージをエクスポート ] をクリックします。 名前を入力し、イメージを保存する種類を選択して、[ 保 存 ] をクリックします。 © 2010 MicroStrategy, Inc. MicroStrategy Tutorial のデータ モデル 409 A プロジェクト デザイン ガイド MicroStrategy Tutorial MicroStrategy Tutorial のスキーマ スキーマとは、論理データ モデルから派生した、ウェアハ ウスのデータ エレメント、物理特性、および関係の論理的 かつ物理的な定義です。 論理データ モデルは、データ、およびデータがビジネスに どのように関係するかを理解するために必要な情報の全体像 を示します。論理データ モデルの作成はグラフィックを多 用する手法で、ビジネス、技術、または概念の各環境でデー タの定義、特性、および関係を表します。 物理ウェアハウス スキーマは、" 日 "、" 商品 "、" 店舗 "、" アカウント " などの論理データ モデルに基づきます。単一 の論理データ モデルから、複数の物理ウェアハウス スキー マを派生させることができます。論理データ モデルは作成 するファクトやアトリビュートを示しますが、物理ウェアハ ウス スキーマはそれらのオブジェクトの基礎となるデータ の保存場所を示しますす。物理ウェアハウス スキーマは、 データがデータ ウェアハウスにどのように保存されるかを 表します。 MicroStrategy Tutorial スキーマの探索 MicroStrategy Architect には、MicroStrategy Tutorial のスキー マを探索するための直感的な方法が用意されています。 Architect を使用して Tutorial のスキーマの探索を開始する前 に、Tutorial のスキーマ全体の理解に役立つ表記規則とファ クトの情報をいくつか示します。 次の接頭語と接尾語を使用して、さまざまなタイプのテーブ ルを示します。 記号 意味 定義 LU_ ルックアップ テーブル アトリビュート エレメントを一意に識別するデータベース テーブ ル。データベース テーブルは通常、ディメンションの説明で構成さ れます。ルックアップ テーブルは通常、ファクト テーブルと結合さ れ、ルックアップ テーブル内のディメンション アトリビュート別 に、ファクト テーブル内の数値ファクトをグループ化します。 410 MicroStrategy Tutorial のスキーマ © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド MicroStrategy Tutorial A 記号 意味 定義 REL_ 関係テーブル ルックアップ テーブルは 1 つ以上のアトリビュートに関する情報を 保存しますが、関係テーブルは 2 つのアトリビュート間の関係に関 する情報を保存します。関係テーブルには 2 つ以上のアトリビュー トの ID 列があり、それらのアトリビュートの関係を定義します。 _SLS 営業情報を持 つテーブル 複数の論理レベルで営業データ（売上、利益、コストなど）を保存 するデータベース テーブル。これらのテーブルには、アトリビュー トとファクトの定義の組み合わせがあります。たとえば、 YR_CATEGORY_SLS テーブルには、" 年 " および " カテゴリ " のアト リビュート、および " 売上 "、" コスト "、" 収益 " などのファクトが あります。これらのファクトをこのテーブルに保存することにより、 " 年 " と " カテゴリ " のレベルでデータを使用できるようになります。 多くのテーブルには、アトリビュートとファクトの定義の組 み合わせがあります。MicroStrategy Tutorial で作成されたメ トリックの元になっている基本ファクトを次の表に示しま す。 ファクト 説明 当初在庫 月初時での各商品の在庫個数。 コスト サプライヤが会社に課金する総額。 ディスカウン ト 通常価格からの減額。 末在庫 月末時での各商品の在庫個数。 運送料 商品の運送に支払った金額。 利益 商品の売価とコストの差額。 売上 特定のソース会計について、全製品の売上額からディスカウント額を差し引いて得ら れた合計収入。 特急料金 特急配送サービスに課金する金額。 単品コスト 購入した商品ごとに、サプライヤが会社に課金する金額。 単価 販売した商品ごとに、会社が顧客に課金する金額。 単品利益 単価から単品コストを差し引いた額。 入荷数 サプライヤから受け取った各商品の数量。 売上数量 顧客が購入した各商品の個数。 次の手順は、Architect を使用して MicroStrategy Tutorial のス キーマを探索する方法を示します。 © 2010 MicroStrategy, Inc. MicroStrategy Tutorial のスキーマ 411 A プロジェクト デザイン ガイド MicroStrategy Tutorial Architect を使用して MicroStrategy Tutorial のスキーマを探索 するには 1 MicroStrategy Tutorial を現在使用していない場合は、 MicroStrategy Tutorial を含むプロジェクト ソースにログ インして、[MicroStrategy Tutorial] プロジェクトを展開 します。管理者権限を持つユーザとしてログインする必 要があります。 2 [MicroStrategy Tutorial] プロジェクトを右クリックし て、[Architect] をクリックします。MicroStrategy Architect が開きます。 3 [ プロジェクト テーブル ビュー ] をクリックします。 MicroStrategy Tutorial のプロジェクトに含まれるテーブル がすべて表示されます。 4 各テーブルの物理的な列を表示するには : a [ オプション ] メニューから [ 設定 ] を選択します。 [MicroStrategy Architect 設定 ] ダイアログ ボックスが 開きます。 b [ 設定を表示 ] タブから [ テーブルを物理表示で表示 ] を選択します。 c [OK] をクリックして Architect に戻ります。 各テーブルに列、および列名とデータ タイプが表示 されます。 412 MicroStrategy Tutorial のスキーマ © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド MicroStrategy Tutorial A 5 各テーブルの物理的な列、および列で定義する MicroStrategy のスキーマ オブジェクトを表示するには : a [ オプション ] メニューから [ 設定 ] を選択します。 [MicroStrategy Architect 設定 ] ダイアログ ボックスが 開きます。 b [ 設定を表示 ] タブから [ テーブルを論理表示で表示 ] を選択します。 c [ 高度なオプション ] をクリックします。 d [ テーブルを論理表示で表示 ] オプションのチェック ボックスをすべて選択します。各オプションの説明 は、「テーブル内の列とアトリビュート フォームの表 示」（109 ページ）を参照してください。 e [OK] をクリックします。 f [OK] をクリックして Architect に戻ります。 テーブルに、スキーマ オブジェクト、およびスキー マ オブジェクトの定義に使用した列が表示されます。 6 [ プロジェクト テーブル ビュー] にアトリビュートの関係 を表示するには、[ 表示 ] メニューから [ 関係を表示 ] を選 択します。 7 [ プロパティ] ペインの [ アトリビュート ]、[ ファクト ]、お よび [ テーブル ] の各タブを使用して、Tutorial project の さまざまなテーブルやスキーマ オブジェクトをブラウズ できます。 8 Tutorial プロジェクトをさらに詳細に調べられるような テーブルを編成するには、レイヤを作成します。 Architect を使用してレイヤを作成する方法の詳細は、「プ ロジェクト内のテーブルの編成 : レイヤー」（135 ペー ジ）を参照してください。 9 Tutorial プロジェクト スキーマのレイアウト表示を保存 するには、[ ファイル ] メニューから [ イメージをエクス ポート ] を選択します。名前を入力し、イメージを保存 する種類を選択して、[ 保存 ] をクリックします。 © 2010 MicroStrategy, Inc. MicroStrategy Tutorial のスキーマ 413 A MicroStrategy Tutorial 414 MicroStrategy Tutorial のスキーマ プロジェクト デザイン ガイド © 2010 MicroStrategy, Inc. B B. 論理テーブル はじめに 論理テーブルとは、データ ウェアハウス内にあるテーブル です。MicroStrategy 環境には、論理テーブル、テーブル別 名、および論理表示という 3 つのタイプの論理テーブルがあ ります。論理テーブルは、ウェアハウス カタログを使用し てプロジェクト内に設定されますが、論理表示はテーブル エディタで作成されます。データ ウェアハウス内の物理 テーブルをポイントする論理テーブルとは異なり、論理表示 は、データ ウェアハウスに対して SQL クエリを使用するこ とにより定義されます。 この章では、さまざまなタイプの論理テーブルを紹介し、論 理表示機能を使用して、MicroStrategy の拡張スキーマのサ ポートを活用する方法を詳しく説明します。 論理テーブル 論理テーブルとは、あるスキーマの基礎を構成する MicroStrategy のオブジェクトです。データ ウェアハウス内 © 2010 MicroStrategy, Inc. 論理テーブル 415 B 論理テーブル プロジェクト デザイン ガイド の物理テーブルは複数の列で構成されますが、MicroStrategy スキーマの論理テーブルは、複数のアトリビュートとファク トで構成されます。これらのアトリビュートとファクトは、 レポートの実行時に MicroStrategy のエンジンが参照するレ ポート定義の一部です。 論理テーブルには次の 3 つのタイプがあります。 1 論理テーブル : SQL を生成するためにエンジンが使用す る、テーブルの論理表現です。論理テーブルは、プロ ジェクトにインポートされる物理テーブルごとに、ウェ アハウス カタログを使用して作成されます。このタイプ の論理テーブルは、データ ウェアハウス内の物理テーブ ルに直接マップされます。これらの物理テーブルは、レ ポート用に生成される SQL で参照されます。 2 テーブル別名 : 既存の物理テーブルを直接ポイントする、 追加の論理テーブルです。テーブル別名は、ウェアハウ ス カタログの外部で作成されます。テーブル別名には、 物理テーブルとは別の名前を付けることができます。1 つの物理テーブルに複数のテーブル別名を付けることが できます。テーブル別名は、アトリビュート ロールの作 成に使用されます（「同じルックアップ テーブルを使用 する複数のアトリビュート : アトリビュート ロール」 （281 ページ）を参照）。 3 論理表示 : 物理テーブルを直接ポイントするのではなく、 SQL ステートメントをポイントする論理テーブルです。 物理テーブルを直接ポイントするのではなく、データ ウェアハウスに対して SQL クエリを使用して定義されま す。作成した論理表示は、定義できるアトリビュート、 ファクト、その他のスキーマ オブジェクトに基づいて、 タイプ 1 の論理テーブルと同様に使用できます。また、 論理表示は、レポート用に生成される SQL で参照されま す。タイプ 1 の論理テーブルの場合、SQL クエリ全体が 物理テーブルの位置に表示されます。論理表示は、テー ブル エディタを使用して作成されます。 お使いのプロジェクトがデータの国際化をサポー トしている場合、翻訳データを使用するアトリ ビュートについては、論理表示をルックアップ テーブルとして使用することはできません。デー タの国際化をサポートする方法の詳細は、「データ の国際化のサポート」（63 ページ）を参照してく ださい。 416 論理テーブル © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド 論理テーブル B MicroStrategy Tutorial では、論理テーブルやその他すべての スキーマ オブジェクトは、[ スキーマ オブジェクト ] フォル ダに保存されます。論理テーブル エディタで、SQL ステー トメントを使用して論理表示を定義したり、すべての論理 テーブルおよび関連するウェアハウス テーブルを表示でき ます。 論理テーブルの使用方法 最も一般的な論理テーブルは、ウェアハウス カタログを使 用してデータからプロジェクトにインポートした論理テーブ ルで、[ スキーマ ] メニューからアクセスします。これらの テーブルに基づいて、アトリビュートやファクトなどの MicroStrategy スキーマ オブジェクトを作成できます。ウェ アハウス カタログの使用方法の詳細は、MicroStrategy の オンライン ヘルプを参照してください（「Warehouse Catalog」（ウェアハウス カタログ）で検索）。 1 つのアトリビュートが複数のロールを持つ場合、ロールご とにアトリビュートを論理モデル内に作成する必要がありま す。この方法の 1 つは、明示的テーブル別名を作成すること です。基本的には、同一の物理テーブルをポイントする論理 テーブルを複数作成し、これらの論理テーブルを、異なる ロールを持つアトリビュートのルックアップ テーブルとし て定義します。 たとえば、" 顧客 " テーブルを使用して配送先顧客と請求先 顧客の両方を表す場合、テーブル別名を作成して、2 重に使 用するケースを解決できます。はじめに、既存の論理テーブ ルをコピーしてテーブル別名を作成し、新しい、つまり別の 名前を指定します。次に、適切なテーブルを使用して、新し いテーブルを定義します。 アトリビュート ロールの詳細は、「同じルックアップ テーブ ルを使用する複数のアトリビュート : アトリビュート ロー ル」（281 ページ）を参照してください。テーブル別名を作 成するには、論理テーブル名を右クリックして、[ テーブル 別名を作成 ] を選択します。手順のステップごとの説明は、 MicroStrategy のオンライン ヘルプを参照してください （「Create a table alias」（テーブル別名を作成）で検索）。 © 2010 MicroStrategy, Inc. 論理テーブルの使用方法 417 B 論理テーブル プロジェクト デザイン ガイド 論理表示は、次の理由により、前述の論理テーブルやテーブ ル別名とは少し異なります。 • 論理表示は、データ ウェアハウス内の物理テーブルに直 接マップされません。 • 論理表示は、SQL クエリを使用して定義されます。 • 論理表示は、データ ウェアハウスからインポートしたり 既存の論理テーブルを複製したりするのではなく、何も ないところから作成されます。 ただし、一度作成した論理表示は、通常の論理テーブルと同 様に使用できます（ウェアハウス カタログを使用してプロ ジェクトに取り込む）。これはつまり、論理表示を使用して アトリビュートやファクトを作成できること、および論理表 示用にテーブル別名を作成できることを意味します。 論理表示を使用する最大のメリットは、ウェアハウス内の物 理テーブル構造のみではサポートできない MicroStrategy ス キーマをモデル化できることです。論理表示を使用すること で管理が一層容易になる一般的なモデリング シナリオが多 数あり、そのいくつかを示します。 • 緩やかに変化するディメンション • 複数のテーブルからのアトリビュート フォーム式 • ディメンション テーブルの連結 • 再帰的階層 一般的な使用例は、「論理表示の例」（422 ページ）を参照し てください。 論理テーブル、テーブル別名、または論理表示を作成 したり、プロジェクトに追加したりするときにはいつ でも、スキーマを更新する必要があります。[ スキー マを更新 ] オプションには、[ スキーマ ] メニューから アクセスできます。 418 論理テーブルの使用方法 © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド 論理テーブル B 論理テーブルの作成 多くの論理テーブルはウェアハウス カタログを使用してプ ロジェクト内に取り込まれ、テーブル別名は既存の論理テー ブルを複製して作成されます。これらを作成する方法の詳し い手順は、オンライン ヘルプを参照してください（「Tables」 （テーブル）で検索）。 一方、論理表示は、テーブル エディタを使用して MicroStrategy Desktop で作成されます。テーブル エディタに アクセスする方法の 1 つは、[ ファイル ] メニューの [ 新規作 成 ]、[ 論理テーブル ] を順に選択することです。 次のスクリーン ショットに示すように、オブジェクト ブラ ウザには、プロジェクトにインポートしたテーブルと列がす べて一覧表示されます。プロジェクト データベース インス タンス内の物理テーブルは、SELECT ステートメントで使用 できます。[SQL ステートメント ] パネルは SQL クエリを入 力する場所ですが、[ マッピング ] パネルは、SQL クエリが 返す列のマッピングを行う場所です。 論理表示の作成では、独自の SQL ステートメントを指定し、 さらにステートメントの列を正しいデータ タイプにマッ ピングするという単純な手順をいくつか実行する必要があり © 2010 MicroStrategy, Inc. 論理テーブルの作成 419 B 論理テーブル プロジェクト デザイン ガイド ます（次の情報を参照）。手順の詳しい説明は、オンライン ヘルプを参照してください（「Creating logical views」（論理表 示の作成）で検索）。 テーブル エディタで論理テーブルを作成するには 1 [ ファイル ] メニューの [ 新規作成 ]、[ 論理テーブル ] を順 に選択します。デフォルトでは、[ 物理表示 ] タブが選択 された状態で、テーブル エディタが表示されます。 2 [SQL ステートメント ] パネルに、SQL ステートメントを 入力します。オブジェクト ブラウザから列をドラッグ アンド ドロップして、ステートメントに挿入できます。 論理表示の定義には、派生テーブルを使用するこ とを推奨します。この理由は、エンジンが生成す る SQL ステートメント内で、論理表示の SQL 構 文がネストされるからです。一部のデータベース では共通テーブル式（CTE）もサポートされてい ますが、SQL 構文が不正になるために SQL 内でこ れらの式をネストすることができません。最良の 使用方法については、お使いのデータベースを確 認してください。 3 [ 追加 ] をクリックして、SQL ステートメントが返す列を マップします。 4 [ 列オブジェクト ] に列の名前を入力します。新しい列が 作成されます。 別の方法として、オブジェクト ブラウザから列を [ 列オ ブジェクト ] セルにドラッグ アンド ドロップすることも できます。これにより、既存の列が論理表示にマップさ れます。 ステートメントで定義した列別名と 列名は、SQL 正確に一致する必要があります。ただし、列名の 順序は、SQL ステートメントに列別名が現れる順 序と一致しなくてもかまいません。 5 ドロップダウン リストを使用して、列のデータ タイプを 選択します。 5 のマッピングに既存の列を使用した場 ステップ 合は、その列のデータ タイプが継承されます。 420 論理テーブルの作成 © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド 論理テーブル B データ タイプを変更した場合、その列を持つすべ てのテーブルに影響することに注意してください。 6 必要に応じて、列の精度とスケールを変更します。 7 論理テーブルを保存して閉じます。 8 [ スキーマ ] メニューの [ スキーマを更新 ] を選択して、新 しい論理テーブルをプロジェクトに確実にロードします。 論理表示のための SQL の使用 SQL クエリは論理表示を作成するときの重要なポイントな ので、論理表示の機能を使用する前に、SQL の使用方法に 慣れておく必要があります。SQL ステートメントの正確さ と妥当性を確認するのは、ユーザの責任です。さらに、論理 表示用として入力した SQL クエリを MicroStrategy がまった く変更しないことも理解する必要があります。このため、作 成したクエリが答えを返すように、お使いの RDBMS が最適 化されていることを確認してください。 MicroStrategy エンジンは SQL 構文を解析しないので、アク セスされた実際の物理テーブルに関する情報は、統計ログに は記録されません。その代わりに、論理表示が記録されま す。これは、データベースで表示を使用した場合にも当ては まります。この場合も、アクセスされたテーブル オブジェ クトは記録されません。 レポート用に生成された SQL では、使用するデータベース のタイプに従って、論理表示は派生テーブルまたは共通テー ブル式（CTE）として生成されます。一部のデータベースで は CTE もサポートされていますが、論理表示の定義には、 派生テーブルを使用することを推奨します。派生テーブル は、エンジンが生成する SQL 内でネストされるので、メ リットがあります。一方、CTE はネストすると SQL 構文が 不正になるので、ネストされません。最良の使用方法につい ては、お使いのデータベースを確認してください。 エンジンで、物理データベース テーブルに直接マップされ る論理テーブルを使用する必要がある場合、テーブル名が FROM 句に挿入されます。SQL ステートメントにマップさ © 2010 MicroStrategy, Inc. 論理テーブルの作成 421 B 論理テーブル プロジェクト デザイン ガイド れる論理表示の場合は、SQL 構文が FROM 句に挿入されま す。エンジンは派生テーブルの構文を生成して、論理表示を 表します。 論理表示は 論理表示の結果はキャッシュされません。 MicroStrategy が生成するレポート SQL の追加構文と して単純に表示されます。 論理表示の例 次に示すビジネス ケースは、お使いのアプリケーションで 論理表示機能をどのように使用できるかを理解するための参 考として用意されています。 ビジネス ケース 1: 重複しないアトリビュートのルック アップ テーブル 多くのスター スキーマの特長は、1 つのルックアップ テー ブルを、あるディメンションのすべてのアトリビュートが共 有することです（次の例を参照）。このようなディメン ション テーブルを持つスキーマをモデル化することは可能 ですが、多くの場合、次の 2 つの問題が発生します。 • キー以外のアトリビュートのレベルにあるファクト テー ブルを、モデルがサポートできません。この制限は、要 約テーブル、および SQL エンジンが生成する中間結果に 適用されます。 通常、1 パスの SQL レポートでは、MicroStrategy エン ジンは、ファクト テーブルを 1 つのルックアップ テーブ ルと結合し、集計を行いません。アトリビュート エレ メントの重複しないリストが存在せず、そのアトリ ビュートがキーの一部であるテーブルに結合する必要が ある場合、2 重にカウントしてしまう可能性があります。 • 422 論理表示の例 ディメンション テーブルの行数が多すぎる場合、 SELECT DISTINCT クエリの処理速度が低下することが あり、プロンプトのピック リストにデータを組み込むと きなど、アトリビュート エレメントのリストを表示する エレメント ブラウズ要求に影響することがあります。 © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド 論理テーブル B " 店舗 "、" 市場 "、および " 地域 " のルックアップ テーブル の例を示します。 Lookup_store Store_ID Store_Name Market_ID Market_Name Region_ID Region_Name Level このテーブルでは、" 市場 " と " 地域 " はキーではありま せん。このため、要求したファクト テーブルが " 市場 " また は " 地域 " のレベルにある場合、ファクト テーブルと前述の ルックアップ テーブルを直接結合すると 2 重にカウントさ れることがあります。これを防ぐには、次に示すように、論 理表示機能を使用して別の論理テーブル Lookup_Market を定 義します。 Select Market_ID, Market_Name,Region_ID From Lookup_store Where level=1 次に、このテーブルを " 市場 " のルックアップ テーブルとし て使用します。このテーブルが " 市場 " レベルのファクト テーブル（Market_Sales) と結合されると、次のレポート SQL が生成されます。 Select a11.Market_ID,a11.Market_Desc, SUM(a12.Sales) From (select Market_ID, Market_Name,Region_ID from Lookup_Store where level=1) a11, Market_Sales a12 Where a11.Market_ID = a12.Market_ID Group by a11.Market_ID, a11.Market_Name ビジネス ケース 2: 複数のテーブルにわたるアトリビュー ト フォーム式 お客様から複数のテーブルにわたるアトリビュート フォー ム式の生成機能を要求されることがよくあります。通常、こ れは " 日付 " 列です。たとえば、次に示す方法で、2 つの異 © 2010 MicroStrategy, Inc. 論理表示の例 423 B 論理テーブル プロジェクト デザイン ガイド なるテーブルにある 2 つの " 日付 " 列（Ship_Date と Order_Date）の日付の差に基づくアトリビュートを定義でき ます。 F_Table1 Ship_Date Order_ID Fact1 Order_ID Fact2 F_Table2 Order_Date 論理表示機能を使用することで、次の SQL クエリを使用し て日付の差を計算する論理テーブルを作成し、次にその新し い列にアトリビュートを定義できます。 Select Ship_Date-Order_Date Cycle_time, F_table1.Order_ID, Fact1,Fact2 From F_table1, F_table2 Where F_table1.Order_ID=F_table2.Order_ID 新しい論理テーブル(論理表示)は次に示すテーブルのように なり、新しいアトリビュートを Cycle_Time 列に定義できま す。 論理表示 Cycle_Time Order_ID Fact1 Fact2 ビジネス ケース 3: 緩やかに変化するディメンション 緩やかに変化するディメンション（SCD）は、多くのビジネ ス インテリジェンス環境に共通の特性です。通常、ディ メンションの階層は、時間に依存しないものとして表されま す。たとえば、会社は年ごとに営業組織を再構築したり、小 売シーズンごとに製品階層を再構成したりすることがありま 424 論理表示の例 © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド 論理テーブル B す。「緩やかに」とは通常、数か月後、または数年後という ことを意味します。実際、ディメンションの関係がもっと頻 繁に変化する場合は、別のディメンションをモデル化するほ うがよいことがあります。 SCD は、データ ウェアハウスの文献に詳しく説明されてい ます。Ralph Kimball 氏は、SCD のディメンション モデリン グ手法を説明することで、特に大きな影響を与えました（た とえば、『データ ウェアハウス ツールキット』を参照）。 Kimball 氏はさらに、ディメンション モデルで SCD を扱う 方法を、異なる特徴を持つ複数の方法に分類しました。たと えば、タイプ 1 の SCD は現在のディメンションの関係のみ を表し、タイプ 2 の SCD はディメンションの関係の履歴を 保持する、というようなものです。 次の説明は、時間の経過と共に販売地域が再構成される（営 業担当者の受け持ち地区が変わるなど）ことにより、緩やか に変化する営業組織の例を元にしています。 現状分析と過去分析の違い 緩やかに変化するディメンションに使用できる機能の 1 つと して、「現状」分析または「過去」分析を実行する機能があ ります。 • 「現状」分析は、緩やかに変化する関係の現在の状態を示 します。たとえば、現在の地区の構成方法に従って、地 区別の売上を表示します。 • 「過去」分析は、緩やかに変化する関係の履歴を示しま す。たとえば、売上取引が発生した時点における地区の 構成方法に従って、地区別の売上を表示します。 ここで説明する手法により、各タイプの分析を柔軟に実行で きます。また、実行する分析のタイプを簡単に指定できま す。 © 2010 MicroStrategy, Inc. 論理表示の例 425 B 論理テーブル プロジェクト デザイン ガイド 例 1: 発効日と失効日を持つ複合キー SCD を物理的に保存する方法の 1 つは、" 発効日 " と " 失効 日 " の列を使用して、各エレメントの関係が存在する期間を 捕捉することです。次の例では、営業担当者 Rep Jones が、 2004 年 1 月 1 日に地区 37 から地区 39 に異動し、Kelly が 2004 年 7 月 1 日に地区 38 から地区 39 に異動しています。 「ルックアップ テーブル : アトリ 複合キーの詳細は、 ビュートの格納場所」（45 ページ）を参照してくださ い。 LU_SALES_REP Sales_Rep_ID Sales_Rep_Name District_ID Eff_Dt End_Dt 1 Jones 37 1/1/1900 12/31/2003 2 Smith 37 1/1/1900 12/31/2099 3 Kelly 38 1/1/1900 6/30/2004 4 Madison 38 1/1/1900 12/31/2099 1 Jones 39 1/1/2004 12/31/2099 3 Kelly 39 7/1/2004 12/31/2099 このタイプのディメンション ルックアップ テーブルを使用 するときには、ファクト テーブルに取引日などの日付 フィールドを含める必要があります。 FACT_TABLE 426 論理表示の例 Sales_Rep_ID Trans_Dt Sales 1 9/1/2003 100 2 9/10/2003 200 3 9/15/2003 150 1 3/1/2004 200 2 3/10/2004 250 3 3/15/2004 300 2 9/5/2004 125 3 9/15/2004 275 4 9/20/2004 150 © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド 論理テーブル B MicroStrategy スキーマを指定するには 1 現在の地区と営業担当者の関係のみを表す論理表示を作 成します。 LVW_CURRENT_ORG select Sales_Rep_ID, District_ID from LU_SALES_REP where End_Dt = '12/31/2099' 2 ルックアップ テーブルとファクト テーブルを「過去」結 合して " 地区 " レベルにファクト表示を作成する、別の 論理表示を作成します。 得られる表示は「過去」表示、つまり履歴表示で、取 引の発生時点に存在した営業担当者と地区の関係を捕 捉します。 LVW_HIST_DISTRICT_SALES select District_ID, Trans_Dt, sum(sales) sales from LU_SALES_REP L join FACT_TABLE F on(L.Sales_Rep_ID = F.Sales_Rep_ID) where F.Trans_Dt between L.Eff_Dt and L.End_Dt group by District_ID, Trans_Dt 3 LU_DISTRICT のテーブル別名 LU_CURRENT_DISTRICT を作成します。 4 次のアトリビュートを定義します。 • • 営業担当者 : – @ID = sales_rep_id; @Desc = sales_rep_name – テーブル : LU_SALES_REP（ルックアップ）、 LVW_CURRENT_ORG、FACT_TABLE 現在の地区 : – @ID = district_id; @Desc = district_name © 2010 MicroStrategy, Inc. 論理表示の例 427 B 論理テーブル プロジェクト デザイン ガイド • – テーブル : LU_CURRENT_DISTRICT（ルックアッ プ）、LVW_CURRENT_ORG – 子 : 営業担当者 過去の地区 : – @ID = district_id; @Desc = district_name • • – テーブル : LU_DISTRICT（ルックアップ）、 LU_SALES_REP、LVW_HIST_DISTRICT_SALES – 子 : 営業担当者 日付 : – @ID = date_id, trans_dt – テーブル : LU_TIME（ルックアップ）、 FACT_TABLE、LVW_HIST_DISTRICT_SALES 月: – @ID = MONTH_ID – テーブル : LU_TIME（ルックアップ） 5 " 売上 " ファクトを定義します。 • 式 : sales • テーブル : FACT_TABLE、 LVW_HIST_DISTRICT_SALES 6 必要に応じてメトリックを定義します。 • 428 論理表示の例 売上 : SUM(sales) © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド 論理テーブル B この結果、次に示すような論理スキーマが得られます。 LU_CURRENT_DISTRICT LU_CURRENT_ORG LU_SALES_REP FACT_TABLE 現在の地区 営業担当者 営業担当者 営業担当者 現在の地区 過去の地区 日付 売上 LU_TIME 日付 LVW_HISTORICAL_ DISTRICT_SALES 月 過去の地区 日付 売上 過去分析 レポートで " 過去の地区 " アトリビュートを使用して、「過 去」分析を指定します。 • レポート定義 : " 過去の地区 "、" 月 "、" 売上 " • 得られる SQL Select a11.District_ID District_ID, max(a13.District_Name) District_Name, a12.Month_ID Month_ID, sum(a11.SALES) WJXBFS1 From (select District_ID, Trans_dt,sum(sales) sales from LU_SALES_REP L join FACT_TABLE F on (L.Sales_rep_ID = F.Sales_rep_ID) where F.trans_dt between L.EFF_DT and L.END_DT group by District_ID, Trans_dt) a11 join LU_TIME a12 on (a11.Trans_dt = a12.Date_ID) join LU_DISTRICT a13 on (a11.District_ID =a13.District_ID) group by a11.Distrcit_ID, a12.Month_ID © 2010 MicroStrategy, Inc. 論理表示の例 429 B 論理テーブル プロジェクト デザイン ガイド • レポート結果 現状分析 レポートで " 現在の地区 " アトリビュートを使用して、「現 状」分析を指定します。 • レポート定義 : " 現在の地区 "、" 月 "、" 売上 " • 得られる SQL select a12.District_ID District_ID, max (a14.District_Name) District_Name, a13.Month_ID Month_ID, sum(a11.SALES) WJXBFS1 from FACT_TABLE a11 join (select Sales_rep_ID, District_ID from LU_SALES_REP where END_DT = '12/31/2099')a12 on (a11.Sales_Rep_ID = a12.Sales_Rep_ID) join LU_TIME a13 on (a11.Trans_dt = a13.Date_ID) join LU_DISTRICT a14 on (a12.District_ID = a14.District_ID) group by a12.District_ID, a13.Month_ID • 430 論理表示の例 レポート結果 © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド 論理テーブル B 例 2: 変化する各エレメント用の代理キー SCD を物理的に保存するための一層柔軟的な方法は、代理 キーを使用して、ディメンションの関係が変化したときに ディメンション テーブルに新しい行を導入することです。 もう 1 つの一般的な特徴は、現在の関係レコードを示すイン ジケータのフィールドを含めることです。レコード セット の例を示します。 LU_SALES_REP Sales_Rep_CD Sales_Rep_ID Sales_Rep_Name District_ID Current_Flag 1 1 Jones 37 0 2 2 Smith 37 1 3 3 Kelly 38 0 4 4 Madison 38 1 5 1 Jones 39 1 6 3 Kelly 39 1 このタイプのディメンション ルックアップ テーブルを使用 するときには、ファクト テーブルにも代理キーを含める必 要があります。トランザクションの日付フィールドはあって もなくてもかまいません。 FACT_TABLE © 2010 MicroStrategy, Inc. Sale-Rep_CD Sale 1 100 2 200 3 150 5 200 2 250 3 300 2 125 6 275 4 150 論理表示の例 431 B 論理テーブル プロジェクト デザイン ガイド MicroStrategy スキーマの指定 1 現在の地区と営業担当者の関係のみを表す論理表示を作 成します。 LVW_CURRENT_ORG select Sales_rep_ID, District_ID from LU_SALES_REP where Current_flag = 1 2 LU_DISTRICT のテーブル別名 LU_CURRENT_DISTRICT を作成します。 3 次のアトリビュートを定義します。 • • • 営業担当者の代理 : – @ID = sales_rep_cd – テーブル : LU_SALES_REP（ルックアップ）、 FACT_TABLE 営業担当者 : – @ID = sales_rep_id; @Desc = sales_rep_name – テーブル : LU_SALES_REP（ルックアップ）、 LVW_CURRENT_ORG – 子 : 営業担当者の代理 現在の地区 : – @ID = district_id; @Desc = district_name • – テーブル : LU_CURRENT_DISTRICT（ルックアッ プ）、LVW_CURRENT_ORG – 子 : 営業担当者 過去の地区 : – @ID = district_id; @Desc = district_name 432 論理表示の例 – テーブル : LU_DISTRICT（ルックアップ）、 LU_SALES_REP – 子 : 営業担当者 © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド 論理テーブル • • B 日付 : – @ID = date_id, trans_dt – テーブル : LU_TIME（ルックアップ）、 FACT_TABLE 月: – @ID = MONTH_ID – テーブル : LU_TIME（ルックアップ） – 子 : 日付 4 " 売上 " ファクトを定義します。 • 式 : sales • テーブル : FACT_TABLE、 LVW_HIST_DISTRICT_SALES 5 必要に応じてメトリックを定義します。 • 売上 : SUM(sales) 論理スキーマの結果は次のようになります。 LU_CURRENT_DISTRICT LU_CURRENT_ORG LU_SALES_REP FACT_TABLE LU_TIME 現在の地区 営業担当者 営業担当者の代 理 営業担当者の代理 日付 現在の地区 営業担当者 日付 月 過去の地区 売上 LVW_HISTORICAL_ DISTRICT_SALES 過去の地区 過去分析 レポートで " 過去の地区 " アトリビュートを使用して、「過 去」分析を指定します。 • © 2010 MicroStrategy, Inc. レポート定義 : " 過去の地区 "、" 月 "、" 売上 " 論理表示の例 433 B 論理テーブル プロジェクト デザイン ガイド • 得られる SQL select a12.District_ID District_ID, max(a14.Distrcit_Name) Distrcit_Name, a13.Month_ID Month_ID, sum(a11.SALES) WJXBFS1 from FACT_TABLE a11 join LU_SALES_REP a12 on (a11.Sales_Rep_CD = a12.Sales_Rep_CD) join LU_TIME a13 on (a11.Trans_dt = a13.Date_ID) join LU_DISTRICT a14 on (a12.District_ID = a14.District_ID) group by a12.District_ID, a13.Month_ID • レポート結果 現状分析 レポートで " 現在の地区 " アトリビュートを使用して、「現 状」分析を指定します。 • レポート定義 : " 現在の地区 "、" 月 "、" 売上 " • 得られる SQL: select a13.District_ID District_ID, max(a15.Distrcit_Name) District_Name, a14.Month_ID Month_ID, sum(a11.SALES) WJXBFS1 from FACT_TABLE a11 join LU_SALES_REP a12 on (a11.Sales_Rep_CD = a12.Sales_Rep_CD) join (select Sales_rep_ID, District_ID 434 論理表示の例 © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド 論理テーブル B from LU_SALES_REP where current_flag = 1) a13 on (a12.Sales_Rep_ID = a13.Sales_Rep_ID) join LU_TIME a14 on (a11.Trans_dt = a14.Date_ID) join LU_DISTRICT a15 on (a13.District_ID = a15.District_ID) group by a13.District_ID, a14.Month_ID • レポート結果 ビジネス ケース 4: 1 対多のトランスフォーメーション テーブル 月次累計および年次累計の計算などの時系列分析をサポート するには、トランスフォーメーションを定義する必要があり ます。前月のような 1 対 1 のトランスフォーメーションは式 で定義できますが、1 対多のトランスフォーメーションの場 合は、それぞれの日付を、「月次累計」を構成するその日よ り前のすべての日付にマップするテーブルがデータベース内 に必要です。 ウェアハウスにこのようなテーブルが存在せず、かつデータ ベースにテーブルを追加できない状況である場合は、" 日 " アトリビュートのルックアップ テーブルが既に存在してい る限り、論理表示の手法を使用してこの問題に対処できま す。 次の SQL を使用して、" 日 " アトリビュートを含む論理テー ブル MTD_DATE を定義できます。次に、MTD_DATE 列を 使用して、MTD のトランスフォーメーションを定義できま す。 © 2010 MicroStrategy, Inc. 論理表示の例 435 B 論理テーブル プロジェクト デザイン ガイド Select day_date day_date, B.day_date mtd_date From lu_day A, lu_day B Where A.day_date >= B.day_date And MONTH(A.day_date)= MONTH(B.day_date) 同じ手法を使用して、年から日付へのトランスフォーメー ションを定義できます。 Select A.day_date day_date, B.day_date ytd_date From lu_day A, lu_day B Where A.day_date >= B.day_date And YEAR(A.day_date) = YEAR(B.day_date) ビジネス ケース 5: 複数のアトリビュート ルックアップ テーブルの外部結合 一般的に要求される機能として、アトリビュートのみを含む （メトリックのない）レポートを実行するために、アトリ ビュート ルックアップ テーブルの外部結合を生成する機能 があります。たとえば、 次のテーブルを見てください。 従業員 緊急連絡先 部署 EMP_ID EMP_ID DEPT_ID FIRST_NAME CONTACT_FIRST_NAME DEPT_NAME LAST_NAME CONTACT_LAST_NAME BUS_UNIT_ID HIRE_DATE CONTACT_PHONE_NUMBER DEPT_ID この構造の場合、アトリビュート階層を次のようにモデル化 できます。 436 論理表示の例 • 事業単位 -< 部署 -< 従業員 • 入社日 -< 従業員 • 緊急連絡先 -< 従業員 © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド 論理テーブル B さらに、従業員と緊急連絡先との関係は、各従業員が持つ連 絡先が最大 1 つである関係であり、レコードに連絡先を持た ない従業員も含まれていることを意味します。作成するレ ポートの 1 つは、次のようになります。 従業員 部署 緊急連絡先 電話番号 Gonzalez, James マーケティング Dawson, John 財務 Dawson, Jane 555-1212 Larkins, Abraham 研究開発 Taylor, Mary 555-3456 Walker, George 財務 Walker, Martha 555-9876 ... ... ... ... が表示 緊急連絡先を持たない従業員の場合は、NULL されます。 ただし、次に示すようにアトリビュートをモデル化すると、 目的の出力が得られないことがあります。 • 従業員 : @ID = EMP_ID, @[First Name] = FIRST_NAME, @[Last Name] = LAST_NAME テーブル : EMPLOYEE（ルックアップ）、 EMERGENCY_CONTACT • 部署 : @ID = DEPT_ID テーブル : DEPARTMENT（ルックアップ）、 EMPLOYEE 子 : 従業員 • 入社日 : @ID = HIRE_DATE テーブル : EMPLOYEE（ルックアップ） 子 : 従業員 • © 2010 MicroStrategy, Inc. 緊急連絡先 : 論理表示の例 437 B 論理テーブル プロジェクト デザイン ガイド @ID = CONTACT_PHONE_NUMBER, @[First Name] = CONTACT_FIRST_NAME, @[Last Name] = CONTACT_LAST_NAME テーブル : EMERGENCY_CONTACT（ルックアップ） 子 : 従業員 このモデルを使用すると、生成される SQL は EMPLOYEE テーブルと EMERGENCY_CONTACT テーブルを結合し、緊 急連絡先を持つ従業員のみが最終的な結果に表示されます。 すべての従業員を表示するには、次に示す論理表示を使用し て、外部結合を実行します。 外部結合の論理表示の使用 前述のケースで外部結合を実行するには、次の SQL と列の リストを使用して、表示にマップします。 select E.EMP_ID, E.FIRST_NAME, E.LAST_NAME, E.HIRE_DATE, E.DEPT_ID, C.CONTACT_FIRST_NAME, C.CONTACT_LAST_NAME, C.CONTACT_PHONE_NUMBER from EMPLOYEE E left outer join EMERGENCY_CONTACT C on (E.EMP_ID = C.EMP_ID) LVW_EMERGENCY_CONTACT EMP_ID FIRST_NAME LAST_NAME HIRE_DATE DEPT_ID CONTACT_FIRST_NAME CONTACT_LAST_NAME CONTACT_PHONE_NUMBER 438 論理表示の例 © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド 論理テーブル B 元の子テーブル（EMPLOYEE など）のすべての列を必ず含 めてください。これにより、新しい論理テーブル LVW_EMERGENCY_CONTACT を使用して、次のようにア トリビュートを定義できます。 • 従業員 : @ID = EMP_ID, @[First Name] = FIRST_NAME, @[Last Name] = LAST_NAME テーブル : EMPLOYEE（ルックアップ）、 LVW_EMERGENCY_CONTACT • 部署 : @ID = DEPT_ID テーブル : DEPARTMENT（ルックアップ）、 EMPLOYEE、LVW_EMERGENCY_CONTACT 子 : 従業員 • 入社日 : @ID = HIRE_DATE テーブル : EMPLOYEE（ルックアップ）、 LVW_EMERGENCY_CONTACT 子 : 従業員 • 緊急連絡先 : @ID = CONTACT_PHONE_NUMBER, @[First Name] = CONTACT_FIRST_NAME, @[Last Name] = CONTACT_LAST_NAME テーブル : EMERGENCY_CONTACT（ルックアッ プ）、LVW_EMERGENCY_CONTACT 子 : 従業員 従業員 " アトリビュートは元の "EMERGENCY_CONTACT テーブルには示されず、 EMPLOYEE テーブルに示されるアトリビュートはす べて、LVW_EMERGENCY_CONTACT テーブルにも 示されます。 ここで、" 従業員 " と " 緊急連絡先 " のアトリビュートを含 むレポートを実行すると、EMPLOYEE テーブルが EMERGENCY_CONTACT テーブルに外部結合され、緊急連 © 2010 MicroStrategy, Inc. 論理表示の例 439 B 論理テーブル プロジェクト デザイン ガイド 絡先を持たない従業員には、NULL が返されます。また、" 従業員 " アトリビュートのみを含むレポートを実行すると、 EMPLOYEE テーブルに対してレポートが実行されることに も注意してください。EMERGENCY_CONTACT テーブルは 必要なときにのみ結合されます。 この手法は、ルックアップ テーブルを常に外部結合する必 要があるときはいつでも使用できます。この手法は、ルック アップ テーブルをあるときには外部結合し、別のときには 内部結合する必要がある場合には使用できません。 440 論理表示の例 © 2010 MicroStrategy, Inc. C C. データ タイプ はじめに SQL の生成、またはデータ ソースからのデータの取得を行 うには、お使いのデータベースに存在するデータ タイプを MicroStrategy で認識する必要があります。各 RDBMS がさま ざまなデータ タイプのセットをサポートしているので、 MicroStrategy ではそれらのデータ タイプを MicroStrategy に 固有のデータ タイプのセットに一般化しています。 外部データ タイプから MicroStrategy の データ タイプへのマッピング プロジェクトを作成し、お使いのデータ ウェアハウスから MicroStrategy のウェアハウス カタログにテーブルを追加す るときに、MicroStrategy は、お使いのテーブルにある列を MicroStrategy に固有のデータ タイプに自動的にマップしま す。お使いのデータベースの各列が、MicroStrategy のデータ タイプに関連付けられます。 © 2010 MicroStrategy, Inc. 外部データ タイプから MicroStrategy のデータ タイプへのマッピング 441 C データ タイプ プロジェクト デザイン ガイド データベースのデータ タイプから MicroStrategy のデータ タ イプへのマッピングが必要な理由の 1 つは、各データベース でデータ タイプの名前が異なるからです。概念的には同一 のデータ タイプが、異なる名前を持つことがあります。こ のため、MicroStrategy は、プロジェクト スキーマに取り込 む各列を、内部データ タイプにマップする必要があります。 ウェアハウス カタログにテーブルを追加すると仮定します。 お使いのリレーショナル データベースで、そのテーブルに ある特定の列のデータ タイプが「SMALLINT」であるとし ます。MicroStrategy は、この列を MicroStrategy に固有の データ タイプ、たとえば「整数」にマップします。これに より、MicroStrategy は一貫した SQL 生成プロセスを維持で きます。 MicroStrategy のデータ タイプはデータ値を内部およびメタ データ リポジトリに格納し、後で、中間テーブルやデータ マート テーブルを定義するときやリテラルの正しい構文を 生成するときの SQL 生成でデータ タイプが使用されます。 また、データ タイプは、カスタム グループと同様に、複数 パスの SQL を使用するときにはいつでも使用されます。 データ マートやカスタム グループの詳細は、『MicroStrategy 上級レポーティング ガイド』を参照してください。 次の表に、サポートするデータベースのデータ タイプ、お よび MicroStrategy でデータを定義するときに使用される MicroStrategy のデータ タイプを示します。MicroStrategy の データ タイプの詳細は、「MicroStrategy のデータ タイプ」 （461 ページ）を参照してください。この表に含まれるデー タベースは次のとおりです。 • 「Access」（444 ページ） • 「Composite」（445 ページ） • 「DB2」（446 ページ） • 「Generic」（447 ページ） • 「HP Neoview」（448 ページ） • 「Informix」（449 ページ） • 「MetaMatrix」（450 ページ） • 「MySQL」（451 ページ） • 「Netezza」（452 ページ） 442 外部データ タイプから MicroStrategy のデータ タイプへのマッピング © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド データ タイプ C • 「Oracle」（453 ページ） • 「PostgreSQL」（454 ページ） • 「Red Brick」（455 ページ） • 「SQL Server」（456 ページ） • 「Sybase」（457 ページ） • 「Sybase IQ」（458 ページ） • 「Tandem」（459 ページ） • 「Teradata」（460 ページ） © 2010 MicroStrategy, Inc. 外部データ タイプから MicroStrategy のデータ タイプへのマッピング 443 C データ タイプ プロジェクト デザイン ガイド データベース サポートするデータベースのデー タ タイプ MicroStrategy のデータ タイプ Access BINARY 2 進数 BOOLEAN 整数 BYTE 整数 CURRENCY 数値 DATE タイムスタンプ DATETIME タイムスタンプ DOUBLE 倍精度浮動小数点型 FLOAT 倍精度浮動小数点型 INT 整数 INTEGER 整数 INTEGER2 整数 INTEGER4 整数 LONG 整数 LONG BINARY LongVarBin LONGTEXT LongVarChar MEMO LongVarChar NUMBER 倍精度浮動小数点型 NUMERIC 倍精度浮動小数点型 REAL 実数 SHORT 整数 SINGLE 実数 SMALLINT 整数 TEXT Char TIME 時間 TIMESTAMP タイムスタンプ 444 外部データ タイプから MicroStrategy のデータ タイプへのマッピング © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド データ タイプ C データベース サポートするデータベースのデー タ タイプ MicroStrategy のデータ タイプ Composite BIT 2 進数 BIT VARYING VarBin CHAR Char CHAR VARYING （DTMAPPING.PDS から追加） CHARACTER（DTMAPPING.PDS から追加） CHARACTER VARYING （DTMAPPING.PDS から追加） VarChar Char VarChar DATE 日付 DECIMAL 10 進数 DOUBLE PRECISION （DTMAPPING.PDS から追加） 浮動小数点型 FLOAT 浮動小数点型 INT（DTMAPPING.PDS から追 加） 整数 INTEGER 整数 NUMERIC 数値 REAL 実数 SMALLINT（DTMAPPING.PDS か 整数 ら追加） © 2010 MicroStrategy, Inc. TIME 時間 TIMESTAMP タイムスタンプ VARBIT（DTMAPPING.PDS から 追加） VarBin VARCHAR VarChar 外部データ タイプから MicroStrategy のデータ タイプへのマッピング 445 C データ タイプ プロジェクト デザイン ガイド データベース サポートするデータベースのデー タ タイプ MicroStrategy のデータ タイプ DB2 BIGINT Big Decimal BLOB LongVarBin CHAR Char CHARACTER Char CLOB LongVarChar DATE 日付 DEC 数値 DECIMAL 数値 DOUBLE 倍精度浮動小数点型 DOUBLE PRECISION 倍精度浮動小数点型 FLOAT 倍精度浮動小数点型 GRAPHIC NChar INT 整数 INTEGER 整数 LABEL VarChar LONG VarChar LONG VARCHAR VarChar LONGVAR VarChar NUM 数値 NUMERIC 数値 RAW VarBin REAL 実数 SMALLINT 整数 TIME 時間 TIMESTAMP タイムスタンプ TIMESTMP タイムスタンプ VARCHAR VarChar VARGRAPHIC NVarChar 446 外部データ タイプから MicroStrategy のデータ タイプへのマッピング © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド © 2010 MicroStrategy, Inc. データ タイプ C データベース サポートするデータベースのデー タ タイプ MicroStrategy のデータ タイプ Generic BIT 2 進数 BIT VARYING VarBin CHAR Char CHAR VARYING VarChar CHARACTER Char CHARACTER VARYING VarChar DATE 日付 DECIMAL 10 進数 DOUBLE PRECISION 浮動小数点型 FLOAT 浮動小数点型 INT 整数 INTEGER 整数 NUMERIC 数値 REAL 実数 SMALLINT 整数 VARBIT VarBin VARCHAR VarChar 外部データ タイプから MicroStrategy のデータ タイプへのマッピング 447 C データ タイプ プロジェクト デザイン ガイド データベース HP Neoview サポートするデータベースのデー タ タイプ MicroStrategy のデータ タイプ BIGINT（DTMAPPING.PDS から 追加） Big Decimal BINARY（DTMAPPING.PDS から 追加） 2 進数 BIT 整数 BIT VARYING CHAR Char DATE 日付 DECIMAL（DTMAPPING.PDS か ら追加） 10 進数 DOUBLE（DTMAPPING.PDS か ら追加） 倍精度浮動小数点型 FLOAT 浮動小数点型 INTEGER 整数 LONGVARCHAR （DTMAPPING.PDS から追加） LongVarChar NCHAR NChar NCHAR VARYING NVarChar NLONGVARCHAR （DTMAPPING.PDS から追加） LongVarChar NUMERIC 数値 REAL 実数 SMALLINT（DTMAPPING.PDS か 整数 ら追加） TIME 時間 TIMESTAMP タイムスタンプ TINYINT（DTMAPPING.PDS から 整数 追加） VARBINARY（DTMAPPING.PDS から追加） LONGVARBINARY （DTMAPPING.PDS から追加） VARCHAR 448 外部データ タイプから MicroStrategy のデータ タイプへのマッピング LongVarBin LongVarBin VarChar © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド © 2010 MicroStrategy, Inc. データ タイプ C データベース サポートするデータベースのデー タ タイプ MicroStrategy のデータ タイプ Informix BOOLEAN Char BYTE LongVarBin CHAR Char CHARACTER Char DATE 日付 DATETIME タイムスタンプ DATETIME HOUR TO SECOND （DTMAPPING.PDS にない） タイムスタンプ DATETIME YEAR TO SECOND （DTMAPPING.PDS にない） タイムスタンプ DEC 10 進数 DECIMAL 10 進数 DOUBLE PRECISION 倍精度浮動小数点型 FLOAT 倍精度浮動小数点型 INT 整数 INT8（DTMAPPING.PDS から変 更） Big Decimal INTEGER 整数 LVARCHAR LongVarChar MONEY 数値 NCHAR NChar NUMERIC 10 進数 NVARCHAR NVarChar REAL 実数 SERIAL 整数 SERIAL8 整数 SMALLFLOAT 実数 SMALLINT 整数 TEXT LongVarChar VARCHAR VarChar 外部データ タイプから MicroStrategy のデータ タイプへのマッピング 449 C データ タイプ プロジェクト デザイン ガイド データベース サポートするデータベースのデー タ タイプ MicroStrategy のデータ タイプ MetaMatrix BIGDECIMAL 数値 BIGINTEGER 整数 BLOB VarBin BOOLEAN 2 進数 BYTE 整数 CHAR Char CLOB VarChar DATE 日付 DOUBLE（DTMAPPING.PDS か ら追加） 倍精度浮動小数点型 FLOAT 浮動小数点型 INTEGER 整数 LONG 整数 SHORT 整数 STRING VarChar TIME 時間 TIMESTAMP タイムスタンプ 450 外部データ タイプから MicroStrategy のデータ タイプへのマッピング © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド © 2010 MicroStrategy, Inc. データ タイプ C データベース サポートするデータベースのデー タ タイプ MicroStrategy のデータ タイプ MySQL BIGINT 整数 BINARY 2 進数 BIT 符号なし整数 BLOB LongVarBin CHAR Char DATE 日付 DATETIME タイムスタンプ DECIMAL 10 進数 DOUBLE 倍精度浮動小数点型 ENUM Char FLOAT 浮動小数点型 INT 整数 LONGBLOB LongVarBin LONGTEXT LongVarChar MEDIUMBLOB LongVarBin MEDIUMINT 整数 MEDIUMTEXT LongVarChar NCHAR NChar NVARCHAR NVarChar SET Char SMALLINT 整数 TEXT LongVarChar TIME 時間 TIMESTAMP タイムスタンプ TINYBLOB LongVarBin TINYINT 整数 TINYTEXT LongVarChar VARBINARY VarBin VARCHAR VarChar YEAR 整数 外部データ タイプから MicroStrategy のデータ タイプへのマッピング 451 C データ タイプ プロジェクト デザイン ガイド データベース サポートするデータベースのデー タ タイプ MicroStrategy のデータ タイプ Netezza BIGINT Big Decimal BIT 2 進数 BIT VARYING VarBin BYTEINT 整数 CHAR Char CHAR VARYING VarChar CHARACTER Char CHARACTER VARYING VarChar DATE 日付 DATETIME タイムスタンプ DEC 数値 DECIMAL 数値 DOUBLE 浮動小数点型 DOUBLE PRECISION 浮動小数点型 FLOAT 浮動小数点型 FLOAT4 浮動小数点型 FLOAT8 浮動小数点型 INT 整数 INT1 整数 INT2 整数 INT4 整数 INT8 Big Decimal INTEGER 整数 NCHAR NChar NUMERIC 数値 NVARCHAR NVarChar REAL 実数 SMALLINT 整数 TIME 時間 TIMESTAMP タイムスタンプ VARCHAR VarChar 452 外部データ タイプから MicroStrategy のデータ タイプへのマッピング © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド © 2010 MicroStrategy, Inc. データ タイプ C データベース サポートするデータベースのデー タ タイプ MicroStrategy のデータ タイプ Oracle BLOB LongVarBin CHAR Char CLOB LongVarChar DATE タイムスタンプ DECIMAL 数値 FLOAT 浮動小数点型 INTEGER 数値 LONG LongVarChar LONG RAW LongVarBin LONG VARCHAR LongVarChar NCHAR NChar NUMBER 数値 NVARCHAR NVarChar RAW VarBin REAL 浮動小数点型 SMALLINT 数値 TIMESTAMP(6) タイムスタンプ VARCHAR VarChar VARCHAR2 VarChar 外部データ タイプから MicroStrategy のデータ タイプへのマッピング 453 C データ タイプ プロジェクト デザイン ガイド データベース サポートするデータベースのデー タ タイプ MicroStrategy のデータ タイプ PostgreSQL BOOL 整数 BIT 2 進数 CHAR Char DATE 日付 DECIMAL 10 進数 FLOAT4 実数 FLOAT8 倍精度浮動小数点型 INT2 整数 INT4 整数 INT8 整数 NUMERIC 10 進数 TEXT LongVarChar TIME 時間 TIMESTAMP タイムスタンプ VARBIT VarBin VARCHAR VarChar 454 外部データ タイプから MicroStrategy のデータ タイプへのマッピング © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド © 2010 MicroStrategy, Inc. データ タイプ C データベース サポートするデータベースのデー タ タイプ MicroStrategy のデータ タイプ Red Brick CHAR Char CHAR VARYING VarChar CHARACTER Char CHARACTER VARYING VarChar DATE 日付 DEC 数値 DECIMAL 数値 DOUBLE 倍精度浮動小数点型 DOUBLE PRECISION 倍精度浮動小数点型 FLOAT 倍精度浮動小数点型 INT 整数 INTEGER 整数 NUM 数値 NUMERIC 数値 REAL 実数 SERIAL 整数 SMALLINT 整数 TIME 時間 TIMESTAMP タイムスタンプ TINYINT 整数 VARCHAR VarChar 外部データ タイプから MicroStrategy のデータ タイプへのマッピング 455 C データ タイプ プロジェクト デザイン ガイド データベース サポートするデータベースのデー タ タイプ MicroStrategy のデータ タイプ SQL Server BIGINT 数値 BINARY VarBin BIT 2 進数 CHAR VarChar CHARACTER VarChar DATETIME タイムスタンプ DEC 数値 DECIMAL 数値 DOUBLE 浮動小数点型 DOUBLE PRECISION 浮動小数点型 FLOAT 浮動小数点型 IMAGE LongVarBin INT 整数 INTEGER 整数 MONEY 数値 NCHAR NChar NUMERIC 数値 NVARCHAR NVarChar REAL 浮動小数点型 SMALLDATETIME タイムスタンプ SMALLINT 整数 SMALLMONEY 数値 TEXT LongVarChar TIMESTAMP VarBin TINYINT 符号なし整数 VARBINARY VarBin VARCHAR VarChar 456 外部データ タイプから MicroStrategy のデータ タイプへのマッピング © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド © 2010 MicroStrategy, Inc. データ タイプ C データベース サポートするデータベースのデー タ タイプ MicroStrategy のデータ タイプ Sybase BINARY 2 進数 BIT 2 進数 CHAR Char DATETIME タイムスタンプ DECIMAL 数値 FLOAT 浮動小数点型 IMAGE LongVarBin INT 整数 INTEGER 整数 LONG VARCHAR LongVarChar MONEY 数値 REAL 実数 SMALL DATETIME タイムスタンプ SMALLINT 整数 SMALLMONEY 数値 TEXT LongVarChar TINYINT 符号なし整数 UNICHAR NChar UNIVARCHAR NVarChar VARBINARY VarBin VARCHAR VarChar 外部データ タイプから MicroStrategy のデータ タイプへのマッピング 457 C データ タイプ プロジェクト デザイン ガイド データベース サポートするデータベースのデー タ タイプ MicroStrategy のデータ タイプ Sybase IQ BIGINT Big Decimal BINARY 2 進数 BIT 2 進数 CHAR Char DATE 日付 DATETIME タイムスタンプ DECIMAL 数値 DOUBLE 倍精度浮動小数点型 FLOAT 浮動小数点型 INT 整数 INTEGER 整数 LONG BINARY LongVarBin LONG VARCHAR LongVarChar MONEY 数値 NUMERIC 数値 REAL 実数 SMALLDATETIME タイムスタンプ SMALLINT 整数 SMALLMONEY 数値 TIME 時間 TIMESTAMP タイムスタンプ TINYINT 符号なし整数 UNSIGNED BIGINT 符号なし整数 UNSIGNED INT 符号なし整数 UNSIGNED SMALLINT 符号なし整数 VARBINARY VarBin VARCHAR VarChar 458 外部データ タイプから MicroStrategy のデータ タイプへのマッピング © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド データ タイプ C データベース サポートするデータベースのデー タ タイプ MicroStrategy のデータ タイプ Tandem BIGINT Big Decimal BIT 整数 CHAR Char DATE 日付 DATETIME タイムスタンプ DECIMAL 10 進数 DOUBLE PRECISION 倍精度浮動小数点型 FLOAT 倍精度浮動小数点型 INT 整数 INTEGER 整数 MONEY 倍精度浮動小数点型 NUMERIC 10 進数 REAL 浮動小数点型 SMALLDATETIME タイムスタンプ SMALLINT 整数 SMALLMONEY 倍精度浮動小数点型 TEXT Char TIMESTAMP タイムスタンプ TINYINT 整数 VARBYTE VARCHAR © 2010 MicroStrategy, Inc. VarChar 外部データ タイプから MicroStrategy のデータ タイプへのマッピング 459 C データ タイプ プロジェクト デザイン ガイド データベース サポートするデータベースのデー タ タイプ MicroStrategy のデータ タイプ Teradata BLOB LongVarBin BYTE 2 進数 BYTEINT 整数 BYTEINTEGER 整数 BYTES 2 進数 CHAR Char CHARACTER Char CHARACTERS Char CHARS Char CLOB LongVarChar DATE 日付 DEC 10 進数 DECIMAL 10 進数 DOUBLE PRECISION 倍精度浮動小数点型 FLOAT 倍精度浮動小数点型 INT 整数 INTEGER 整数 LONG VARCHAR VarChar NCHAR NChar NVARCHAR NVarChar NUMERIC 10 進数 REAL 倍精度浮動小数点型 SMALLINT 整数 TIME 時間 TIMESTAMP タイムスタンプ VARBYTE VarBin VARCHAR VarChar 460 外部データ タイプから MicroStrategy のデータ タイプへのマッピング © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド データ タイプ C MicroStrategy のデータ タイプ ウェアハウス カタログからデータ ウェアハウス カタログを 読み取るときに、データベースのすべての列が、次に示す MicroStrategy のデータ タイプのいずれかに自動的にマップ されます。 データ タイプ 説明 Big Decimal 高精度の固定小数点数。 2 進数 固定長のビット文字列。 ANSI の BIT と同様。 Char 固定長の文字列。 ANSI の CHAR と同様。 日付 カレンダ上の日付。 ANSI の DATE と同様。 10 進数 精度が最大 15 桁の固定小数点数。 ANSI の DECIMAL と同様。 倍精度浮動小 数点型 8 バイトの浮動小数点数。 浮動小数点型 4 バイトの浮動小数点数。 ANSI の DOUBLE PRECISION と同様。 ANSI の FLOAT と同様。 整数 符号付き整数値。 ANSI の INTEGER と同様。 LongVarBin 長いビット文字列。 ANSI の BLOB と同様。 LongVarChar 長い文字列。 ANSI の CLOB と同様。 NChar さまざまな文字セットのサポートに使用される固定長 の文字列。 数値 精度が最大 15 桁の固定小数点数。 ANSI の NUMERIC と同様。 NVarChar さまざまな文字セットのサポートに使用される可変長 の文字列。 実数 4 バイトの浮動小数点数。 ANSI の REAL と同様。 時間 時刻。 ANSI の TIME と同様。 © 2010 MicroStrategy, Inc. MicroStrategy のデータ タイプ 461 C データ タイプ プロジェクト デザイン ガイド データ タイプ 説明 タイムスタン プ カレンダ上の日付と時刻の組み合わせ。 符号なし整数 符号なし整数値。 VarBin 可変長のビット文字列。 ANSI の TIMESTAMP と同様。 ANSI の BIT VARYING と同様。 VarChar 可変長の文字列。 ANSI の VARCHAR と同様。 ウェアハウス カタログのある列のデータ タイプが 「不明」として表示された場合、データベースのデー タ タイプが MicroStrategy のデータ タイプにマップさ れなかったことを意味します。 フォーマット タイプ アトリビュート フォームは、MicroStrategy のインター フェースにアトリビュート フォームの値をどのように表示 するかを指定する MicroStrategy のフォーマット タイプとも 関連付けられています。アトリビュート フォームのフォー マット タイプは、アトリビュート エディタの [ フォーム フォーマット : タイプ ] ドロップダウン メニューで指定しま す。 アトリビュート フォームのフォーマット タイプを次の表に 示します。 フォーマット タイプ 説明 Big Decimal 高精度の固定小数点数を表す Big Decimal の形式で、情報が格納および表示されます。 Big Decimal の詳細は、「Big Decimal」（465 ページ）を参照してください。 2 進数 2 進数データ タイプの情報は、文字列として格納および表示されます。2 進数データ タイプのサポートの詳細は、「MicroStrategy の 2 進数データ タイプのサポート」（467 ページ）を参照してください。 日付 日付の計算を実行するために、日付として連続する形式で情報が格納および表示され ます。日付を MM/DD/YYYY のフォーマットで表します。 462 フォーマット タイプ © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド フォーマット タイプ データ タイプ C 説明 日時 情報は、データに固有のフォーマットで、日付と時刻の両方として格納および表示さ れます。日付は MM/DD/YYYY のフォーマット、時刻は HH:MM:SS のフォーマットに 従います。 メール メール アドレスの形式で、情報が格納および表示されます。 HTML タグ HTML タグとして情報が格納および表示されます。 番号 数値フォーマットで、情報が格納および表示されます。 図 ビットマップ、JPG、GIF などのイメージ ファイルの形式で格納および表示されます。 テキスト テキストのフォーマットで、情報が格納および表示されます。 時間 HH:MM:SS のフォーマットで、情報が格納および表示されます。これは時刻のみを表 示し、日付は表示しません。 URL 絶対または相対のユニバーサル リソース ロケータとして、情報が格納および表示され ます。 データ タイプとフォーマット タイプの互 換性 たとえば、列別名を使用して、プロジェクト内にあるいずれ かの列の MicroStrategy のデータ タイプを変更する場合、ア トリビュートのフォーマット タイプも変更する必要があり ます。列のデータ タイプと、選択したフォーマット タイプ には互換性がある必要があります。この理由は、フォーマッ ト タイプとデータ タイプに互換性がない場合、SQL 生成で 問題が発生する可能性があるからです。列のデータ タイプ と互換性のないフォーマット タイプを選択すると、アトリ ビュート エディタに警告が表示されます。 たとえば、アトリビュート エディタで " 年 " アトリビュート の ID フォームを編集するとします。[ 列別名 ] タブで、" 年 " アトリビュートに「整数」データ タイプが割り当てられて いることがわかります。ここで、新しい列別名を作成して、 「日付」データ タイプを割り当てます。 アトリビュート エディタの [ 定義 ] ペインに戻った後、 [ フォーム フォーマット : タイプ ] ドロップダウン メニュー から適切なフォーマット タイプを選択する必要があります。 このフォーマット タイプは、[ 列別名 ] タブで割り当てた データ タイプと互換性がある必要があります。データ タイ © 2010 MicroStrategy, Inc. データ タイプとフォーマット タイプの互換性 463 C データ タイプ プロジェクト デザイン ガイド プと互換性のないフォーマット タイプを選択し、[OK] をク リックしてアトリビュート エディタを終了すると、互換性 がないことを通知する警告メッセージが表示されます。[ は い ] をクリックして続行することもできますが、SQL 生成の 問題が発生する可能性があります。 次の表は、列に割り当てたデータ タイプと互換性がある フォーマット タイプを割り当てるときの参考として作成さ れています。 タイ 列の特定のデータによって、あるフォーマット プについて互換性があるデータ タイプは異なります。 このため、次の表に示すデータ タイプとフォーマッ ト タイプの一部の組み合わせは、お使いの特定デー タには当てはまらないことがあります。 データ タイプ 互換性のあるフォーマット タイプ Big Decimal Big Decimal 2 進数 番号、テキスト、図 Char テキスト、URL、メール、HTML タグ 日付 日付、日時 10 進数 番号 倍精度浮動小 数点型 番号 浮動小数点型 番号 整数 番号 LongVarBin 図、テキスト（データによる） LongVarChar 番号、テキスト 数値 番号 実数 番号 時間 時間、日時 タイムスタン プ 日時、日付、または時間（データによる） 符号なし整数 番号 VarBin 番号、テキスト Varchar テキスト、URL、メール、HTML タグ、図 464 データ タイプとフォーマット タイプの互換性 © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド データ タイプ C Big Decimal Big Decimal は MicroStrategy に固有のデータ タイプであり、 BIGINT や DECIMAL（精度、スケール）のデータ タイプな ど、精度が 15 桁を超える高精度のアトリビュート ID 値をサ ポートできます。これらのアトリビュート ID 値の例とし て、アカウント番号、クレジット カード番号、長整数があ ります。 Big Decimal データ タイプの使用 Big Decimal のデータ タイプの場合、MicroStrategy は ID 表示 やフィルタ処理、ドリル、ページバイなどの動作を実行する ときに、アトリビュート ID 値とアトリビュート ID フォー ムの精度を保持します。これらの動作の詳細は、 『MicroStrategy 基本レポーティング ガイド』を参照してくだ さい。 データベースの数値列で指定されるアトリビュートを定義で きます。これらの数値列には、アカウント番号やその他の長 い整数など、精度が 15 桁を超える数値を入れることができ ます。これらの値を扱うには、Big Decimal のデータ タイプ を使用する必要があります。この理由は、これらのデータ値 は精度が高く、通常の数値のデータ タイプで格納できない からです。 高精度のデータベース フィールドに Big Decimal の データ タイプを関連付けない場合、16 桁目以降が切 り捨てられて表示されることがあります。ドリル レ ポートの SQL ステートメントの WHERE 句が数値の 16 桁目以降を切り捨てたり、ページバイが結果を返 さないことがあります。 Big Decimal のデータ タイプを使用するときには、次に示す 規則に従ってください。 • © 2010 MicroStrategy, Inc. 定数 : 定数をハッシュ記号で囲むことにより、強制的に Big Decimal 値として格納できます。たとえば、フィルタ を「Customer@ID exactly #12345678#」と定義できます。 ただし、12345678 は必ずしも Big Decimal のデータ タイ プを必要とするわけではありません。 Big Decimal 465 C データ タイプ プロジェクト デザイン ガイド • アトリビュート フォーム : アトリビュート エディタの [ 列別名 ] タブで列のデータ タイプを [Big Decimal] に変 更した場合、[ 定義 ] タブの [ フォーム フォーマット : タ イプ ] ドロップダウン メニューでフォームのフォーマッ ト タイプとして [Big Decimal] を選択する必要もありま す。 • アトリビュート ID: MicroStrategy Desktop のオンライン ヘルプにあるトピック「Defining attributes with high-precision ID forms」（高精度 ID フォームでのアトリ ビュートの定義）の手順に従ってください。 • メトリック : メトリック値のデータ タイプとして Big Decimal を定義できますが、次の欠点を考慮してくださ い。 分析エンジンで計算を実行するとき、ドキュメントの データ フィールドでメトリックを使用するとき、メ トリックを小計するとき、またはメトリック値をグラ フ表示するときに、精度が失われます。 数値フォーマットの文字列は、Web ではサポートさ れません。 一部の数値フォーマットの文字列は、MicroStrategy Desktop ではサポートされません。 Big Decimal のメトリックに条件を設定するときに、 値をハッシュ（#）記号で囲んで明示的に高精度定数 を指定する必要があります。その例は、 #1234567890123456# です。 精度が 15 桁を超える場合でも、ウェアハウス カタログは、 DECIMAL(p, s) や NUMERIC(p, s) の列を MicroStrategy の Big Decimal のデータ タイプには自動的にマップしないことに注 意してください。Big Decimal を使用する必要があるのは、 アトリビュート ID フォームとして列を使用するときに限ら れるためです。 466 Big Decimal © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド データ タイプ C MicroStrategy の 2 進数データ タイプのサ ポート MicroStrategy は、データベースの 2 進数データ タイプを、 MicroStrategy の 2 進数または Varbin のいずれかのデータ タ イプにマップします。例として、一部のデータベースについ て、その 2 進数データ タイプ、および MicroStrategy のマッ プ先のデータ タイプを次の表に示します。 データベース 2 進数にマップされるデータ タイプ Varbin にマップされるデータ タイプ Oracle 適用不可 Raw Teradata Byte Varbyte SQL Server 2 進数 Varbinary Sybase IQ 2 進数 Varbinary Sybase ASE 2 進数 Varbinary MySQL 2 進数 Varbinary PostgreSQL Bit Bit Varying MicroStrategy で 2 進数データ タイプを使用する場合とその 方法を決定するために、2 進数データ タイプについて、次の MicroStrategy の機能がサポートされています。 • MicroStrategy は、ID フォームが 2 進数データ タイプに マップされるアトリビュートについて、次の機能をサ ポートしています。 エレメント リストの条件。 ドリル。 エレメント ブラウズ。 ページバイ。 並べ替え。 エクスポート。2 進数データを文字列としてエクス ポートします。 © 2010 MicroStrategy, Inc. MicroStrategy の 2 進数データ タイプのサポート 467 C データ タイプ プロジェクト デザイン ガイド • MicroStrategy は、ID 以外のアトリビュート フォームが 2 進数データ タイプにマップされるアトリビュートについ て、次の機能をサポートしています。 データ マートのインクルード（SQL Server のみ） アトリビュート フォーム条件。Like や Contains など の文字の比較演算子を使用する条件を除きます。 468 MicroStrategy の 2 進数データ タイプのサポート © 2010 MicroStrategy, Inc. 用語集 1 対 1 親アトリビュートの各エレメントが子アトリビュートの 1 つ のエレメントにのみ関連し、子アトリビュートの各エレメン トが親アトリビュートの 1 つのエレメントにのみ関連するア トリビュート関係。 関連項目 : • 1 対多 • 多対 1 • 多対多 • 関係 1 対多（one-to-many） 親アトリビュートの各エレメントが子アトリビュートの複数 のエレメントに関連し、子アトリビュートの各エレメントが 親アトリビュートの 1 つのエレメントにのみ関連するアトリ ビュートの関係。1 対多アトリビュート関係は、データ モデ ルで最も一般的である。 関連項目 : © 2010 MicroStrategy, Inc. • 1対1 • 多対多 • 多対 1 • 関係 用語集 : 1 対 1 469 用語集 プロジェクト デザイン ガイド ID 列（ID column） アトリビュート エレメントの識別コードを含む列。すべて のアトリビュートには ID 列が 1 つ必要である。 MDX キューブ（MDX MDX キューブ ソースから取得したデータの集合またはセッ cube） ト。データのクエリ、レポート、および分析のために MicroStrategy にインポートされ、さまざまなオブジェクトに マッピングされる。 「MDX キューブ ソース」も参照。 MDX キューブ ソース サード パーティのツールである SAP BW や Microsoft （MDX cube source） Analysis Services、Hyperion Essbase は、MicroStrategy と統合 されると、MDX キューブ ソースと呼ばれる。これらの MDX キューブ ソースから MicroStrategy にデータをインポー トしてマッピングし、MicroStrategy でデータのクエリ、レ ポート、および分析を行うことができる。 MicroStrategy は MDX キューブ データと統合できるほか、リ レーショナル データベースのデータに並行アクセスするこ ともできる。 関連項目 : • MDX キューブ • データ ソース MOLAP マルチディメンション オンライン分析処理 （Multidimensional Online Analytical Processing）。 圧縮率（compression 1 つの親レコードを計算するために結合される子レコードの ratio） 平均数。たとえば、月別データと年別データの圧縮率は 12:1 である。圧縮率は、集計テーブルにおいて影響が最大 となる場所を判断するために使用される。2 つのアトリ ビュート間の圧縮率が大きいほど、上位レベルのデータを事 前に計算する集計テーブルを作成した場合のメリットが大き くなる。 470 用語集 : ID 列（ID column） © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド 用語集 アトリビュート システム設計者により定義され、データ ウェアハウス ルッ （attribute） クアップ テーブル内の 1 つ以上の列と関連付けられるデー タ レベル。アトリビュートには、" 地域 "、" 注文番号 "、" 顧客 "、" 年齢 "、" 商品 "、" 都市 "、" 年 " などのデータ分 類が含まれる。アトリビュートを使用して、特定のレベルで 集計とフィルタリングを行うことができる。 関連項目 : • アトリビュート エレメント • アトリビュート フォーム • 子アトリビュート • 定数アトリビュート • 派生アトリビュート • 親アトリビュート アトリビュート エレ 1 つのアトリビュートを表す一意の情報セット。アトリ メント（attribute ビュート フォームで定義される。たとえば、"New York" と element） "Dallas" はアトリビュート " 都市 " のエレメントで、"1 月 "、 "2 月 " および "3 月 " はアトリビュート " 月 " のエレメント である。 アトリビュート関係 「関係」を参照。 （attribute relationship） アトリビュート フォー 同じ項目の異なる側面を表す、アトリビュートに関連付けら ム（attribute form） れている複数の列の 1 つ。たとえば、アトリビュート " 顧客 " のフォームには "ID"、" 名前 "、" 姓 "、" 説明 " および " 住 所 " などがある。各アトリビュートには、独自のフォームが 含まれる。 アトリビュート フォー ウェアハウス内の列へのマッピング。SQL で特定のアトリ ム式（attribute form ビュート フォームの表現に使用される。 expression） © 2010 MicroStrategy, Inc. 用語集 : アトリビュート（attribute） 471 用語集 プロジェクト デザイン ガイド アトリビュート ロール 複数のアトリビュートの定義に使用されるデータベース列。 （attribute role） たとえば、" 請求先都市 " と " 出荷先都市 " は、ルックアッ プ テーブルとして同じテーブルと列が定義されている 2 つ のアトリビュートである。 アプリケーション オブ 関連データの分析と考察に使用されるオブジェクト。レポー ジェクト（application ト、ドキュメント、フィルタ、テンプレート、カスタム グ object） ループ、メトリック、プロンプトなどのアプリケーション オブジェクトの定義は、スキーマ オブジェクトから派生さ れる。これらのオブジェクトはいずれも、MicroStrategy Desktop で構築および操作できる。レポートとドキュメント は、MicroStrategy Web でも作成および操作できる。 アプリケーション レベ アプリケーション レベルのパーティション化では、データ ル パーティション ベース サーバではなく、アプリケーションがパーティ （application-level ション テーブルを管理する。MicroStrategy では、メタデー partition） タ パーティション マッピングおよびウェアハウス パーティ ション マッピングという 2 つのアプリケーション レベルの パーティション化がサポートされる。 「データベース レベル パーティション」と比較。 暗黙のアトリビュート アプリケーション レベルで作成されるため、データベース （implicit attribute） には物理的に存在しないアトリビュート。このようなアトリ ビュートには、定数値として式が定義されているが、列には 何も保存されていない。たとえば、各行の値が 1 である列を データベースに作成して、COUNT 制限を迂回できる。ただ し、アトリビュート エディタで式に「1」と入力するだけで 個数を作成できるため、実際に列を作成する必要はない。暗 黙のアトリビュートは、情報の分析および取得に役立つ。 データを分析する際に、定数アトリビュートを使用して COUNT を作成し、返される行数を追跡できる。また、メト リックの作成時に定数アトリビュートを使用し、定数を保持 する列を合計して COUNT を作成することもできる。また、 任意の定数を使用できる。 「派生アトリビュート」と比較。 異種の列名 同じデータベース内の複数のテーブルに存在する、同じデー （heterogeneous タを含み、名前が異なる列。たとえば、" 顧客 " 列と " 顧客 column naming） 名 " 列が互いに異なるテーブル内にあり、どちらも顧客名を 含んでいる場合など。 472 用語集 : アトリビュート ロール（attribute role） © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド 用語集 エレメント ブラウズ アトリビュート エレメントの階層のナビゲート。たとえば、 （element browsing） 1 年間の月のリストを閲覧する操作。 エンティティ関係図 ソース システム内のデータの物理構造をグラフィカルに表 （entity relationship した図。テーブルと列、および列に含まれるデータを容易に diagram（ERD）） 認識できる。 エントリ ポイント ユーザ階層内で、データ エクスプローラ内のアトリビュー （entry point） トへのショートカット。ユーザはエントリ ポイントを使用 することで、データ エクスプローラ内の使用頻度が高いア トリビュートにより容易にアクセスできる。 エントリ レベル（entry 分析にファクトを使用できる最下位レベルのアトリビュート level） セット。 オブジェクト（object） 概念的には、オブジェクトとは、ある概念に関する情報の最 上位のグループ化レベルであり、指定したデータ分析を実行 するためにユーザにより使用される。より具体的に言えば、 オブジェクトとは選択および操作できる任意の項目であり、 フォルダ、レポート、ファクト、メトリックなどである。 親アトリビュート 1 つ以上の子を持つアトリビュート関係における上位レベル （parent attribute） のアトリビュート。 関連項目 : • 子アトリビュート • 関係 オンライン トランザク 一般にトランザクション データを格納するデータベースま ション処理（online たはメインフレーム。トランザクション処理には、売上、在 transaction processing 庫、口座からの出金、入金などのトランザクションの単純な （OTLP）） 記録も含まれる。 オンライン分析処理 トランザクション レコードを操作して売上傾向、成長パ （online analytical ターン、全体に占める貢献率、傾向レポート、および利益分 processing（OLAP）） 析を計算するアクティビティなどを含む分析処理を行うシス テム。 © 2010 MicroStrategy, Inc. 用語集 : エレメント ブラウズ（element browsing） 473 用語集 プロジェクト デザイン ガイド カーディナリティ アトリビュートの中の一意のエレメントの数。 （cardinality） 階層（hierarchy） エレメントのブラウズまたはドリルに有効なパスを定義す る、一連のアトリビュート。通常、アトリビュートの順序 は、上位のアトリビュートが子アトリビュートと 1 対多関係 になるよう定義されるが、例外もある。 仮想キューブ（virtual 1）OLAP データ モデルにおけるデータの概念的なマルチ cube） ディメンション表現。仮想キューブはデータ呼び出しを実行 しないため、物理キューブとは異なり、パフォーマンスの問 題やサイズ制限が存在しない。仮想キューブは階層やメト リックなどの MicroStrategy オブジェクトを OLAP OLE DB オブジェクトにマッピングする。 2）プロジェクトから階層とメトリックを選択した後、論理 データ モデルを OLAP OLE DB マルチディメンション モデ ルにマッピングした結果。物理キューブは作成されず、ロー ドされることもないが、仮想キューブ構造の定義が MicroStrategy メタデータに格納される。 関係（relationship） あるアトリビュート（親）と 1 つ以上の他のアトリビュート （子）とのつながりを指定する関連。たとえば、" 都市 " は " 州 " の子である。 関連項目 : • 親アトリビュート • 子アトリビュート • 部分関係 • クオリティ関係 • 1対1 • 1 対多 • 多対 1 • 多対多 関係テーブル（relate 2 つ以上のアトリビュートの ID 列を含み、それらの間の関 table） 係を定義しているテーブル。 474 用語集 : カーディナリティ（cardinality） © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド 用語集 管理オブジェクト プロジェクト スキーマには関係のないスキーマ オブジェク （managed object） ト。システムによって作成され、別のシステム フォルダに 保存される。管理オブジェクトは、アトリビュート、メト リック、階層、および、フリーフォーム SQL、クエリ ビル ダ、MDX キューブ レポートに対する他のスキーマ オブ ジェクトへデータをマップするために使用される。 基本ファクト列（base ファクト テーブル内の 1 つの列で表されるファクト列。 fact column） キャッシュ（cache） 最近アクセスされた情報を保持し、この情報への高速アクセ スを可能にする特殊なデータ ストア。通常は、頻繁に要求 されるレポートに対して使用される。これにより、レポート をデータベースに対して実行する必要がなくなるため、高速 な実行が可能になる。データ ウェアハウスからの結果は個 別に格納され、同じデータを必要とする新しいジョブ要求で 使用される。MicroStrategy 環境では、ユーザがレポートを初 めて実行したときには、ジョブがデータベースに発行され、 処理される。ただし、このレポートの結果がキャッシュに格 納された場合、次にレポートが実行されるときには、データ ベースでのジョブの処理を待たずに結果がすぐに返される。 行（row） レポートの横方向の軸。 関連項目 : • 軸 • 列 クオリティ関係（quality 親アトリビュートと 2 つ以上の「結合子」アトリビュート間 relationship） の関係。親アトリビュートは結合子の交差部でのみ定義され るため、「クオリティ」とも呼ばれる。 結合子（joint children） 結合子関係は、多対多関係の一種で、1 つのアトリビュート と他の 2 つの関連しないアトリビュートが多対多関係にあ る。これらの関係は、従来のアトリビュートと同様にモデル 化および概念化できるが、ファクトと同様に複数のアトリ ビュート レベルの交差部に存在する。たとえば、" 販促 "、" 商品 "、および " 四半期 " という 3 つのアトリビュートの関 © 2010 MicroStrategy, Inc. 用語集 : 管理オブジェクト（managed object） 475 用語集 プロジェクト デザイン ガイド 係を考えてみる。この場合、" 販促 " は " 商品 " と " 四半期 " の両方と多対多の関係にある。販促の例としては、赤い色の 商品を安く販売する「Red Sale」がある。このような販売促 進は、バレンタイン デー（Q1（第 1 四半期））の前後や、ク リスマス シーズン（Q4（第 4 四半期） ）に行われることが多 い。 子アトリビュート アトリビュート関係における下位レベルのアトリビュート。 （child attribute） 関連項目 : • 親アトリビュート • 関係 構成オブジェクト システム レイヤに存在し、複数のプロジェクトで使用でき （configuration object） る MicroStrategy オブジェクト。構成オブジェクトのオブ ジェクト タイプには、ユーザ、データベース インスタンス、 データベース ログイン ID、スケジュールがある。 構造化クエリ言語 1986 年に米国規格協会（ANSI: American National Standards （Structured Query Institute）によって標準化されたクエリ言語。リレーショナ Language: SQL） ル データベース内のテーブルの情報の要求やテーブルの構 造およびデータの操作に使用される。 高度に正規化されたス ルックアップ テーブルに開発者がデザインした一意のアト キーマ（highly リビュート キーを含むタイプのスキーマ。 normalized schema） 高度に非正規化されたス 関連するすべてのテーブルに上位レベルのアトリビュート キーマ（highly ID 列が存在するだけでなく、説明列も存在するタイプのス denormalized schema） キーマ。 サーバ インスタンス 特定のサーバ定義と実行されている MicroStrategy Intelligence （server instance） Server の組み合せ。 サーバ定義（server メタデータに格納されている MicroStrategy オブジェクト。 definition） MicroStrategy Intelligence Server の構成に関する情報が含まれ る。 476 用語集 : 子アトリビュート（child attribute） © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド 用語集 サーフ フィルタ、アトリビュート、アトリビュート エレメント、 メトリックおよび関数を既存の分析オブジェクトに追加する こと。 関連項目 : • ドリル • ページバイ • ピボット • 並べ替え • 小計 しきい値（threshold） メトリック値の条件付き書式設定の作成に使用される。たと えば、200 ドルを超える売上を含むセルの書式について、背 景を青に、文字を太字に設定する。 軸（axis） データが表示されるベクトル。行、列、およびページという 3 つの軸がある。レポートのテンプレートを定義するとき、 ユーザは各軸に沿ってテンプレート ユニット（アトリ ビュート、ディメンション、メトリック、コンソリデー ション、カスタム グループ）を配置する。 関連項目 : • 列 • 行 システム階層（system プロジェクト内のすべてのアトリビュートを含むスーパー hierarchy） セット階層。ブラウズ階層とは異なり、明示的には作成され ない。MicroStrategy プラットフォームにより、使用可能な情 報から自動的に導出される。 「ユーザ階層」と比較。 © 2010 MicroStrategy, Inc. 用語集 : サーフ 477 用語集 プロジェクト デザイン ガイド 事前集計 レポートの実行前に完了した、特定のアトリビュート レベ （pre-aggregation） ルでの数値データの計算または集計。結果は集計テーブルに 格納される。 関連項目 : • 集計テーブル • 集計 集計関数（aggregate データの列に対して実行され、単一の結果を生成する数値関 function） 数。例として、SUM、COUNT、MAX、MIN および AVG が ある。 集計テーブル 1 つ以上のディメンションについて集計されたデータを格納 （aggregate table） するファクト テーブル。 「事前集計」を参照。 ショートカット オブ レポート、フィルタ、メトリックなど、他の MicroStrategy ジェクト（shortcut オブジェクトへのリンクを表す MicroStrategy オブジェクト。 object） 小計（subtotal） 結果セットの一部に対して実行される集計演算。 関連項目 : • ドリル • ページバイ • ピボット • 並べ替え • サーフ 条件（conditionality） メトリックの条件によって、フィルタ条件を満たすデータの みが計算に含まれるように、既存のフィルタ オブジェクト をメトリックに関連付けることができる。 478 用語集 : 事前集計（pre-aggregation） © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド 用語集 条件（qualification） データがレポートに含まれるために満たす必要のある実際の 条件。たとえば、「地域 = 北東部」または「売上 > $1,000,000」のように指定する。条件はフィルタおよびカス タム グループで使用される。1 つのフィルタやカスタム グ ループに複数の条件を作成することが可能で、それらの条件 を組み合わせる方法を論理演算子（AND、AND NOT、OR、 または OR NOT）で設定できる。 シンプル キー（simple リレーショナル データベースで、テーブル内のレコードを 1 key） つの列だけで一意に識別できる主キー。 スキーマ（schema） 1）論理データ モデルに関連付けられた、データ ウェアハウ ス内のテーブルのセット。テーブル内のアトリビュートおよ びファクト列は、スキーマの一部とみなされる。 2）データベース システムのレイアウトまたは構造。リレー ショナル データベースでは、スキーマはテーブル、各テー ブル内のフィールド、フィールドとテーブル間の関係を定義 する。 スキーマ オブジェクト 通常はプロジェクト デザイナにより作成される （schema object） MicroStrategy オブジェクトであり、論理データ モデルおよ び物理ウェアハウス スキーマ内の情報を MicroStrategy 環境 に関連付ける。これらのオブジェクトは、MicroStrategy Desktop からアクセスできる MicroStrategy Architect で作成さ れる。スキーマ オブジェクトには、ウェアハウス構造が直 接反映される。スキーマ オブジェクトには、アトリビュー ト、ファクト、関数、階層、演算子、パーティション マッ ピング、テーブルおよびトランスフォーメーションがある。 スター スキーマ（star 高度に非正規化された物理ウェアハウス スキーマの 1 つ。 schema） 特定の階層の属性 ID と説明列がすべて 1 つのテーブル内に 存在するように複数のルックアップ テーブルが統合される。 © 2010 MicroStrategy, Inc. 用語集 : 条件（qualification） 479 用語集 プロジェクト デザイン ガイド 接頭語（prefix） 接頭語は、1 つまたは複数のテーブルに関連付けられている プロジェクト メタデータに格納され、SQL を生成するため にエンジンにより使用される。また、カタログ サーバは、 接頭語を使用してテーブルのサンプル値と行数を取得する。 ほとんどの場合、接頭語は特定の所有者またはネーム ス ペースに属す特定のテーブルの条件設定に使用されるため、 ネーム スペース フィールドと一致する。接頭語は、ウェア ハウス カタログ インタフェースから定義および変更できる。 「テーブル ネーム スペース（table name space）」も参照。 説明列（description アトリビュート エレメントを説明するテキストを含むオプ column） ションの列。 ソース システム 対象となるデータを取得または保持するシステムやファイ （source system） ル。 多対 1（many-to-one）（1）親アトリビュートの複数のエレメントが子アトリビュー トの 1 つのエレメントにのみ関連し、（2）子アトリビュート の各エレメントが親アトリビュートの複数のエレメントに関 連するアトリビュート関係。 関連項目 : 480 用語集 : 接頭語（prefix） • 1対1 • 1 対多 • 多対多 • 関係 © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド 用語集 多対多 親アトリビュートの複数のエレメントが子アトリビュートの （many-to-many） 複数のエレメントに関連し、子アトリビュートの複数のエレ メントが親アトリビュートの複数のエレメントに関連するア トリビュート関係。 関連項目 : • 1対1 • 1 対多 • 多対 1 • 関係 抽出、変換およびロード 1）既存の異なるデータベース システムからデータ ウェアハ （extraction, ウスにデータを移入するために使用されるプロセス。 transformation, and loading（ETL）） 2）このプロセスを容易に実行するために使用されるサード パーティ製ソフトウェア。 中度正規化スキーマ 高度な正規化スキーマと基本構造は同じだが、関連するすべ （moderately てのテーブルに上位レベルのアトリビュート ID 列を含むタ normalized schema） イプのスキーマ。 データ ウェアハウス 1）企業の履歴データが格納される、通常は非常に大規模な （data warehouse） データベース。意思決定支援またはビジネス インテリ ジェンスに使用され、データを整理し、更新およびロードの 調整を可能にする。 2）クエリ、レポートおよび分析の目的で構成されたトラン ザクション データのコピー。 「データ ソース」を参照。 データ エクスプローラ ウェアハウスに含まれるデータのブラウズに使用されるイン （Data Explorer） タフェース。ユーザは、アドミニストレータにより定義され たアトリビュートの階層をナビゲートし、必要なデータを探 すことができる。 © 2010 MicroStrategy, Inc. 用語集 : 多対多（many-to-many） 481 用語集 プロジェクト デザイン ガイド データ ソース（data MicroStrategy でクエリ、レポーティング、および分析に使用 source） されるデータを格納するファイル、システム、または格納場 所。 データ ウェアハウスはデータ ソースの一種と考えることが できるが、より具体的に、データ ソースとして使用される データベースを意味する。その他のデータ ソースには、テ キスト ファイル、Excel ファイル、および SAP BW、 Microsoft Analysis Services 2000/2005、Hyperion Essbase など の MDX キューブ ソースがある。 関連項目 : • データ ウェアハウス • MDX キューブ ソース データベース インス 1. MicroStrategy Desktop で作成される MicroStrategy オブジェ タンス（database クトで、ウェアハウスへの接続を表す。データベース イン instance） スタンスは、データ ウェアハウス DSN、ログイン ID とパス ワード、および他のデータ ウェアハウス固有の情報などの ウェアハウス接続情報を指定する。 2. 特定のマシン上で実行されるデータベース サーバ ソフト ウェア。1 台のマシンで複数のインスタンスを実行すること は技術的には可能であるが、通常はマシンごとに 1 つだけ実 行される。 テーブル サイズ（table 行数で見積もられたデータベース テーブルのサイズ。 size） テーブル ネーム スペー ウェアハウス カタログから読み取られ、データベースの編 ス（table name space） 成に使用されるフィールド。このフィールドはウェアハウス 内に実際に格納されているため、MicroStrategy 製品で変更す ることはできない。メタデータ内の各テーブル オブジェク トには、ネーム スペースか、その取得元の所有者が格納さ れている。これは、メタデータ内のテーブル情報をウェアハ ウス内の実際のテーブルに比較するときに、プロジェクトに 保存されている各テーブルを一意に識別するために必要であ る。 定数アトリビュート 「暗黙のアトリビュート」を参照。 （constant attribute） 482 用語集 : データ ソース（data source） © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド 用語集 テンプレート 結果セットに含めるデータの列を定義するオブジェクト（ア （template） トリビュート、メトリック、カスタム グループなど）のグ ループで構成されるテンプレートのデータ定義部。これらの オブジェクトのレイアウトと書式は、テンプレートの表示定 義で定義される。 統計テーブル MicroStrategy システムの使用法とパフォーマンスに関する各 （statistics tables） 種統計情報を記録するために使用されるテーブル。 同種の列名 同じデータベース内の複数のテーブルに存在する、同じデー （homogeneous column タを含み、名前も同じ列。 naming） 動的関係（dynamic 親アトリビュートと子アトリビュートのエレメント間の関係 relationship） が変化する場合。こうした変更は、多くの場合、組織的また は地理的な再編成、商品やサービスの追加、再分類、廃止に より発生する。たとえば店舗で、商品が属す部門の再分類が 行われるような場合である。 トランスフォーメー オフセット値を適用して（現在の月から 1 カ月引く、など）、 ション 指定した時期を別の時期にマップするスキーマ オブジェク （transformation） ト。ほとんどは時系列のマップだが、現在使用されていない 製品コードを新しいコードにマップするなど、さまざまなオ ブジェクトのマップも可能。 時間トランスフォーメーションはメトリックで使用され、今 年と昨年、または該当日と月初から該当日までなど、異なる 時点で値を比較する。 トランスフォーメー 適用されているトランスフォーメーションのプロパティを取 ション メトリック 得する単純なメトリック。たとえば、総売上を計算するメト （transformation リックがあるとする。前年のトランスフォーメーションを追 metric） 加すると、メトリックは前年の合計売上を計算する。 ドリル（drill） レポートの実行後に補足情報を取得する方法。新規データ は、アトリビュートまたはファクト レベルで、インテリ ジェント キューブまたはデータベースへのクエリを再実行 することにより取得される。 関連項目 : © 2010 MicroStrategy, Inc. 用語集 : テンプレート（template） 483 用語集 プロジェクト デザイン ガイド • ページバイ • ピボット • 並べ替え • 小計 • サーフ 並べ替え（sort） データ自体の特性（アルファベットの降順、数値の昇順な ど）に従ってデータを配置すること。 関連項目 : • ドリル • ページバイ • ピボット • 小計 • サーフ ナローキャスト アプリ ビジネス インテリジェンス環境で、購読ユーザごとにパー ケーション ソナライズしたビジネス情報を配信できるアプリケー （narrowcast ション。MicroStrategy では Narrowcast Server を情報事前配信 application） サーバとして、電子メール、プリンタ、ファイル サービス、 SMS、およびモバイル デバイスを通じて、パーソナライズ されたビジネス情報を配信できる。 パーティション ベース 大きなデータ セットの一部を含むウェアハウス テーブル。 テーブル（partition パーティション テーブルは、通常は時間や地域などの論理 base table） 的なラインに従って分割される。PBT とも呼ばれる。 「パーティション マッピング」も参照。 パーティション マッ 月や部門など定義可能なデータ レベルに基づいて、大きな ピング（partition 論理テーブルをより小さな物理テーブルに分割すること。 mapping） パーティションにより、ウェアハウスに対して発行されたク エリを満たすために読み込むテーブル数およびテーブル内の レコード数が最小化される。複数のテーブルに処理を分散す ることにより、パーティションはデータベース クエリの速 度と効率を改善する。 484 用語集 : 並べ替え（sort） © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド 用語集 パーティション マッ パーティション化されたベース テーブルを論理テーブル全 ピング テーブル 体の一部として識別するために使用される情報を含むウェア （partition mapping ハウス テーブル。PMT とも呼ばれる。 table） 関連項目 : • パーティション ベース テーブル • パーティション マッピング 派生アトリビュート ウェアハウス テーブルの列での数学演算により算出された （derived attribute） アトリビュート。たとえば、" 年齢 " は次の式で計算され る。 Current DateBirth Date 「暗黙のアトリビュート」を参照。 派生ファクト列 他の既存ファクト列を数学的に組み合わせて作成されたファ （derived fact column） クト列。 派生メトリック レポートですでに使用可能なデータに基づくメトリック。 （derived metric） データベースではなく MicroStrategy Intelligence Server で計算 される。派生メトリックを使用し、データベースから返され たレポート データの列計算（他のメトリックに対する計算） を実行する。 ビジネス インテリ 複数の観点からデータを表示する機能を提供することによ ジェンス（BI）システム り、大量の複雑なデータの分析を容易にするシステム。 （business intelligence （BI）system） © 2010 MicroStrategy, Inc. 用語集 : パーティション マッピング テーブル（partition mapping table） 485 用語集 プロジェクト デザイン ガイド ピボット（pivot） レポート オブジェクト（アトリビュート、メトリック、 コンソリデーション）を別の軸に配置することにより、グ リッド レポートのデータを再構成すること。また、行ヘッ ダーと列ヘッダーを交換して関連データを入れ替えることに より、グリッド レポートを再構成すること。クロス集計の サブセット。 関連項目 : • ドリル • ページバイ • 並べ替え • 小計 • サーフ 比率（ratio） 関連するアトリビュートのカーディナリティ間の数量、金 額、またはサイズの関係。 「カーディナリティ」も参照。 ファクト（fact） 1）データ ウェアハウスに格納される測定値。数値である場 合がほとんどで、通常は集計が可能。 2）データ ウェアハウス テーブル内の列を表し、基本または 集計済みの数値を含むスキーマ オブジェクト。通常は、価 格、売上金額、棚卸数量など。 「メトリック」も参照。 ファクト式（fact ファクトからウェアハウス内の物理列へのマッピング。ファ expression） クト式はウェアハウスのファクト列の名前のように単純な場 合もあれば、ファクト列と定数を含む式のように複雑な場合 もある。ファクトには複数のファクト式を含めることができ る。 ファクト テーブル（fact 1 つ以上のディメンションについて集計が可能な数値データ table） を含むデータベース テーブル。ファクト テーブルには、ア トミック データまたは要約データを含めることができる。 486 用語集 : ピボット（pivot） © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド 用語集 ファクト列（fact データベース テーブル内でファクト データを含む列。 column） フィルタ（filter） データがレポート結果に含まれるために満たす必要のある条 件を指定する MicroStrategy オブジェクト。レポートはデー タ ウェアハウスに格納されたすべてのデータを対象として データベースに照会するため、レポート上でフィルタを使用 すると、ビジネスの問いへの答えに関連する情報のみに検討 対象のデータを絞ることができる。 フィルタは、データがレポートに含まれるために満たす必要 のある実際の条件の少なくとも 1 つから構成される。1 つの フィルタに複数の条件を含める場合は、論理演算子を使用し て組み合わせる。たとえば、「地域 = 北東部」または「売上 > $1,000,000」のように指定する。 フィルタは通常、SQL WHERE 句で実装される。 フォーム グループ 1 つの複合アトリビュートを作成するためのアトリビュート （form group） フォームのグループ。フォーム グループの作成は複合キー の作成に必要である。複合キーによって、アトリビュート フォームのエレメントの一意な識別に、複数の ID 列が必要 であることが示される。 「複合キー」も参照。 複合アトリビュート 複数のキー（ID）フォームを持つアトリビュート。 （compound attribute） 複合キー（compound リレーショナル データベースで、複数のデータベース列か key） ら構成される主キー。 物理ウェアハウス ス データ ウェアハウスに格納されているビジネス データの状 キーマ（physical 態を詳細かつグラフィカルに表現したもの。データベースの warehouse schema） 観点から意味のある方法で論理データ モデルを編成する。 「スキーマ」も参照。 © 2010 MicroStrategy, Inc. 用語集 : ファクト列（fact column） 487 用語集 プロジェクト デザイン ガイド 部分関係（partial あるアトリビュートのエレメントが別のアトリビュートのエ relationship） レメントに関連するが、その逆は必ずしも正しくないアトリ ビュート関係。 関連項目 : • 関係 • 1 対多 • 多対 1 • 多対多 ブラウズ アトリビュー ユーザ階層内にある 1 つの特定アトリビュートから、ユーザ ト（browse attribute） が直接ブラウズできるアトリビュート。 プロジェクト（project） 1）データ ウェアハウス、メタデータ リポジトリ、および ユーザ コミュニティの最上位レベルの交差部。レポート、 フィルタ、メトリック、関数を含む。 2）（1）で定義されているようなプロジェクトの定義を含む オブジェクト。プロジェクト オブジェクトは、セッション の確立を要求するときに指定される。 プロジェクト ソース メタデータ リポジトリへの接続を定義し、プロジェクトへ （project source） のアクセスのために各種の MicroStrategy 製品によって使用 される。直接プロジェクト ソースは、メタデータ リポジト リに直接つながる 2 層接続である。サーバ プロジェクト ソースは MicroStrategy Intelligence Server への 3 層接続であ る。1 つのプロジェクト ソースは多くのプロジェクトを含む ことができ、プロジェクト ソース レベルにある管理ツール を使用して、プロジェクト ソース内のすべてのプロジェク トをモニタおよび管理できる。 プロセス（process） 1 つまたは複数のスレッドから構成される実行中のアプリ ケーション。プロセスは、一時的なプライベート アドレス 領域を使用し、ファイル、動的なメモリ割り当て、パイプ、 同期オブジェクトなどのオペレーティング システム リソー スを制御する。 488 用語集 : 部分関係（partial relationship） © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド 用語集 プロンプト（prompt） 1）デザイン段階では不完全な、レポート定義内の MicroStrategy オブジェクト。ユーザは、レポート実行の解決 フェーズで、情報を完成させるための回答の入力を求められ る。フィルタを使用した典型的な例としては、条件を設定す る特定のアトリビュートの選択がある。 2）「プロンプトでログイン ID とパスワードを入力する」と いうように、一般に、ユーザ入力を要求するウィンドウ。 分解（degradation） ある集計レベルの値を、これよりも下位のアトリビュート レベルでレポートするファクト拡張機能のタイプ。 「割り当て」と比較。 ページバイ（page-by） 使用可能なアトリビュート、コンソリデーションおよびメト リックを、ページ軸と呼ばれる軸に配置することにより、グ リッド レポート内のデータをセグメント化すること。グ リッドは 2 次元であるため、キューブのスライスを一度に 1 つだけ表示できる。スライスは、ページ軸のエレメントの選 択により指定される。エレメントの選択を変えると、ユーザ はキューブのさまざまなページを参照できる。 関連項目 : • ドリル • ピボット • 並べ替え • 小計 • サーフ ポート番号（port サーバ プロセスは、このポート番号に基づいて、現在稼働 number） 中のマシンで自身を識別する。たとえば、MicroStrategy Intelligence Server マシンがクライアント（Desktop、Web、 Narrowcast Server、Command Manager など）からネットワー ク呼び出しを受信すると、そのマシンは、呼び出しで指定さ れている MicroStrategy Intelligence Server のポート番号に呼び 出しを転送する。 © 2010 MicroStrategy, Inc. 用語集 : プロンプト（prompt） 489 用語集 プロジェクト デザイン ガイド マルチスレッド 複数のスレッドを同時実行できるプロセスの特性。起動コー （multithreaded） ドが main 関数のアドレスをオペレーティング システムに渡 したときにプロセスのプライマリ スレッドが開始され、プ ライマリ スレッドが終了するとプロセスも終了する。 メタデータ（metadata） 基礎となるデータベース構造にビジネス ビュー、条件、お よびニーズをマッピングできるように、データ ウェアハウ スのテーブルと列をユーザ定義のアトリビュートとファクト に関連付けるデータを持つリポジトリ。メタデータは、デー タ ウェアハウスと同じサーバまたは別のデータベース サー バに置くことができる。また、別の RDBMS でも保持でき る。 「メタデータ シェル」も参照。 メタデータ シェル MicroStrategy ビジネス インテリジェンス環境を最初に実装 （metadata shell） したときに作成される一連の空のテーブル。 「メタデータ」も参照。 メトリック（metric） 1）関数、ファクト、アトリビュートまたは他のメトリック で作成された式により定義されるビジネス計算。たとえば、 sum(dollar_sales)、[Sales] - [Cost] など。 2）メトリック定義を含む MicroStrategy オブジェクト。 「ファクト」も参照。 ユーザ階層（user アトリビュートとその関係に名前を付け、論理的なビジネス hierarchy） 組織用に特定の順序で並べたセット。ユーザによって定義さ れ、アトリビュート間のブラウズおよびドリル関係の定義に 使用される。 490 用語集 : マルチスレッド（multithreaded） © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド 用語集 リレーショナル データ リレーショナル データベース管理システム（RDBMS）と ベース管理システム は、リレーショナル データベースの作成、更新、および管 （relational database 理に使用するプログラムである。リレーショナル データ management system） ベースとは、正式に定義されている複数のテーブルのセット として編成されたデータ項目の集合であり、データベース内 のテーブルを再構成することなく、さまざまな方法でデータ にアクセスしたり、データの組み立てを変えることができ る。 主要な RDBMS 製品としては、Oracle、IBM DB2、および Microsoft SQL Server がある。 ルックアップ テーブル アトリビュート エレメントの一意な識別に使用されるデー （lookup table） タベース テーブル。通常、ルックアップテーブルはディ メンションの説明から構成され、内部のディメンション ア トリビュートによってファクト テーブルと結合されて、 ファクト テーブル内の数値ファクトをグループ化する。 レイヤ（layer） Architect で作成できるテーブルのグループ。レイヤは、多数 のテーブルを必要とする MicroStrategy プロジェクトの編成 に役立つ。 列（column） 1）テーブル内の縦方向の値の 1 次元配列。 2）1 つのテーブル内のすべての行に含まれる、特定の名前 とデータ型のフィールドのセット。 3）スキーマ レイヤ内の MicroStrategy オブジェクトで、物理 テーブル内の 1 つ以上の列、または列がないことを表す。 関連項目 : • 軸 • 行 列別名（column alias） ファクト定義で、一時テーブルや一時的な SQL ステート メントに使用するための列の具体名。列別名には、定義して いるファクトに使用するデータ型も含まれる。列別名を使用 することで、既存メトリックの名前をデータ マート レポー トで使用できるように、元のメトリックに影響を与えずに変 更できる。 © 2010 MicroStrategy, Inc. 用語集 : リレーショナル データベース管理システム（relational database management system） 491 用語集 プロジェクト デザイン ガイド レポート（report） 意思決定支援ツールの中心的な存在であるレポートにより、 ユーザは、データのクエリを実行して分析し、見やすい方法 で表示できる。 関連項目 : • フィルタ • テンプレート レポート作成（report MicroStrategy Desktop または MicroStrategy Web 内の既存の定 creation） 義済レポートからレポートを作成するプロセス。 レポート デザイン MicroStrategy Desktop または MicroStrategy Web でレポート エ （report design） ディタを使用して基本的なレポート コンポーネントからレ ポートを作成するプロセス。 ロックされた階層 エンド ユーザがブラウズできないアトリビュートが少なく （locked hierarchy） とも 1 つ含まれる階層。一般に階層がロックされるのは、ア トリビュート エレメント数が非常に多く、エレメントのブ ラウズが効果的でない場合である。 論理データ モデル データベースを効率的に使用できるようにデータが配置され （logical data model） る物理データ モデルやウェアハウス スキーマとは対照的に、 一般ユーザのために論理的に並べられたデータのグラフィカ ルな表現。 492 用語集 : レポート（report） © 2010 MicroStrategy, Inc. 索引 数字 D 1 対 1 関係 定義は 266 ルックアップ テーブル 46 1 対多関係 定義は 266 関係テーブル 47 例 33 Desktop,「MicroStrategy Desktop」を参照 E ERD,「エンティティ関連図」を参照 ETL,「抽出、変換、およびロードのプロ セス」を参照 A Architect 定義は 16, 103 更新、テーブルを 128 削除、テーブルの 126 追加、テーブルの 124 表示、データ ソースの 123 変更、テーブルの 129 B BI のアーキテクチャ 2 C Configuration Wizard 79 M MicroStrategy Desktop 12 MicroStrategy Project Builder, 「Project Builder」を参照 MicroStrategy Tutorial 397 スキーマ 410 データ モデル 409 データ モデルの表示 409 物理ウェアハウス スキーマ 410 物理スキーマ 410 物理スキーマの表示 410 論理データ モデル 401, 410 MicroStrategy Web Universal 13 MicroStrategy メタデータ ,「メタデータ」 を参照 MOLAP 定義は 369 © 2010 MicroStrategy, Inc. 493 索引 O OLTP 3 P PBT, 「パーティション ベース テーブル」 を参照 PMT, 「パーティション マッピング テー ブル」を参照 Project Builder 97 R RDBMS 定義は 5 サーバ レベル パーティション 377 S SQL 定義は 5 カタログ 347 デフォルトのカタログ SQL 352 におけるアトリビュートと列 24 におけるファクトと列 23 あ アクセス ウェアハウス カタログ 330 プロジェクト作成アシスタント 86 圧縮率 定義は 374 アトミック 定義は 371 アトリビュート 定義は 10 1 対 1 関係 266 1 対多関係 266 アトリビュート エディタ 236 アトリビュート作成ウィザード 229 暗黙の 261 異種マッピング 161, 258 エレメント , 「アトリビュート エレメ ント」を参照 494 プロジェクト デザイン ガイド 親 26 カーディナリティ 37 階層内の 27 階層内のフィルタ処理 312 概要 24 仮想 261 関係 , 「アトリビュート関係」を参照 クロスディメンション ,「結合子関係」 を参照 結合子関係 278 子 26 コンポーネント ,「レポート表示 フォーム」および「ブラウズ フォーム」を参照 作成、アトリビュート エディタを使 用 238 作成、プロジェクト作成ウィザードで の 230 式 227 システム階層 173, 265 条件 380 シンプル式 254 互いに関係のない 267 多対 1 関係 266 多対多関係 267, 270 定数 261 特定 32 派生アトリビュート 256 派生式 159, 256 表示 167, 294 比率 37 フォーム , 「アトリビュート フォー ム」を参照 複合 165, 291 複合キー 165, 291 複数カウント、関係での 273 ブラウズ フォーム 294 プロパティ 227, 228 例 24 © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド 列別名 262 レポート表示フォーム 294 ロール ,「アトリビュート ロール」を 参照 アトリビュート エディタ 236 階層の更新 304 作成、アトリビュート 238 作成、アトリビュート フォーム 250 アトリビュート エレメント 定義は 25, 242 概要 25 例 25 アトリビュート関係 定義は 26, 173, 265 概要 26 特定 33 プロパティとして、アトリビュート の 228 ルックアップ テーブル内の 46 例 26 アトリビュート作成ウィザード 229 使用 230 アトリビュートのカーディナリティ 37 アトリビュートのコンポーネント ,「レ ポート表示フォーム」および「ブ ラウズ フォーム」を参照 アトリビュートの比率 37 アトリビュート フォーム 定義は 38 グループ 292 作成、アトリビュート エディタで 250 式 253 条件 380 表示 167, 294 例 38 アトリビュート フォームの条件 380 アトリビュート ロール 定義は 282 自動認識 284, 286 明示的テーブル別名 285, 287 アプリケーション レベル パーティショ ン 定義は 378 © 2010 MicroStrategy, Inc. 索引 暗黙のアトリビュート 定義は 261 暗黙のファクト 200 い 異種 アトリビュート マッピング 161, 258 パーティション マッピング 379 ファクト列 146, 203 列名 定義は 51 一意の識別子 36 う ウェアハウス カタログ アクセス 330 管理 332 使用法と設定 328 情報の表示 344 スキーマ オブジェクトのマッピン グ 345 接続動作 340 データ タイプ 355 データベース ゲートウェイ サポー ト 338 テーブル構造の更新 335 テーブル構造の表示 334 テーブルの列が見つかりません 355 デフォルトのカタログ SQL 352 トラブルシューティング 354 読み取り動作 340 ウェアハウスの物理スキーマ 41 ウェアハウス パーティション マッピン グ 381 パーティション マッピング テーブ ル 381 パーティション ベース テーブル 382 メタデータ パーティション マッピン グとの違い 383 ウェアハウス、物理スキーマ 410 495 索引 プロジェクト デザイン ガイド え 内のファクト 27 表示 308 ブラウズ 316, 318 ブラウズ アトリビュート 316 ブラウズの有効化 318 プロジェクト作成アシスタント 304 ユーザ階層 305 例 305, 373 ロック済 308 論理データ モデルと 26 階層エディタ 305, 307, 319 階層のエアリアル パースペクティブ 307, 322 エレメント、アトリビュート 242 エンティティ , 「階層」を参照 エンティティ関係図（ERD）定義は 30 エントリ ポイント 313 エントリ レベル 定義は 187 お オブジェクト、ユーザ 10 親アトリビュート 26 親子関係 26, 373 静的 374 動的 374 オンライン トランザクション処理 , 「OLTP」を参照 オンライン分析処理 ,「OLAP」を参照 か 階層 299 アトリビュート エディタ 304 アトリビュートのフィルタ処理 312 アトリビュート フィルタ 312 エアリアル パースペクティブ 322 エントリ ポイント 313 階層エディタ 305, 307, 319 階層ビュアー 307 構成 305 構造 306 作成 300 システム階層 304 制限 310 データ エクスプローラおよび 302, 318 データ エクスプローラと 184 定義 34 ドリル 319 内のアトリビュート 27 496 階層ビュアー 307 階層を使用するドリル 319 拡張、レベル 208 仮想アトリビュート 261 カタログ SQL 348 カタログﾞ SQL のカスタマイズ 347 カテゴリ , 「階層」を参照 関係 親子 373 関係テーブル 47 静的 374 多対多 270 動的 374 関係テーブル 47 関係、ファクト 215 関連するアトリビュート ,「アトリビュー ト関係」を参照 き キー シンプル 44 複合 44 基本ファクト列 49 禁止、ファクト エントリ レベル 223 © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド く クエリの頻度 373 クラス , 「階層」を参照 クロスディメンション アトリビュート , 「結合子関係」を参照 け 計算 差異 385 増加率 385 論理テーブル サイズ 345 結合子 定義は 278 結合子関係 278 結合子アトリビュートとトランスフォー メーション メトリック 394 結合、直積 217 こ 子アトリビュート 26 更新 テーブル構造 335 プロジェクト スキーマ 327 構造 階層の 306 テーブルの 334 構造化照会言語 ,「SQL」を参照 高度に正規化されたスキーマ 54 高度に非正規化されたスキーマ 59 上位レベルのルックアップ テーブ ル 60 国際化 92 アトリビュート エレメント 171 およびアトリビュート フォーム 172 言語の定義 88 説明 63 表示、の列 111 文字セット 69 © 2010 MicroStrategy, Inc. 索引 有効化 92 例 245 国際テクニカル サポート xxvii さ サーバ レベル パーティション 377 差異の計算 385 削除 テーブル、プロジェクトからの 90 作成 アトリビュート 238 階層 300 ファクト 187 複合アトリビュート 291 プロジェクト 82 ユーザ階層 300 論理データ モデル 28 サポート ,「テクニカル サポート」を参照 サポートするデータ タイプ 442 し 式のマップ 199 式ベースのトランスフォーメーショ ン 387 作成 390 メンバー式 392 メンバー テーブル 392 時系列分析 385 システム階層 173, 265, 定義は 304 事前集計 定義は 371 圧縮率 374 親子関係 373 クエリの頻度 373 集計テーブル 368 集計テーブルの統合 375 ベース テーブル 371 論理テーブル サイズ 376 497 索引 自動アトリビュート ロール認識 284 集計 定義は 370 疎 372 程度 372 動的 370 密 372 集計関数 定義は 374 集計テーブル 定義は 368 圧縮率 374 親子関係 373 クエリの頻度 373 効果 374 事前集計 371 プロジェクトへの統合 375 ベース テーブル 371 メリット 369 論理テーブル サイズ 376 集計の認識 375 使用する、アトリビュート フォームと特 性アトリビュート 264 シンプル キー 44 式 253 す スキーマ MicroStrategy Tutorial プロジェク ト 410 オブジェクト 14 更新 327 高度に正規化された 55 高度に非正規化された 59 作成ヒューリスティック 106 種類 ,「スキーマの種類」を参照 スター 60 中度正規化 57 物理ウェアハウス 41 プロジェクト 326 498 プロジェクト デザイン ガイド スキーマの種類 53 比較 62 スター スキーマ 60 せ 正規化されたスキーマ 55, 57 制限付き階層 310 静的関係 定義は 374 接続 データベースへの 340 接頭語 344 説明列 定義は 43 そ ソース システム 定義は 3, 5, 29 増加率の計算 385 疎集計 372 た 互いに関係のないアトリビュート 267 多対 1 関係 定義は 266 多対多関係 定義は 267 関係テーブル 47 デザイン上の考慮点 270 ルックアップ テーブル 46 例 34 多対多のトランスフォーメーション 2 重カウント 393 テーブル ベースのトランスフォーメー ションおよび 388 ち 抽出、変換、およびロード（ETL）のプ ロセス 定義は 4, 6 中度正規化スキーマ 56 重複カウント 270 © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド 直積結合 217 つ 追加 テーブル、プロジェクトへの 90 追加、テーブルのプロジェクトへの 89, 122 て データ ウェアハウス 定義は 5 ウェアハウス カタログ 328 構造 53 スキーマの種類 53 接続先 80 物理スキーマと 41 変更、デフォルト オプションの 134 データ エクスプローラ 定義は 318, 318 階層ブラウズの有効化 184, 302, 318 データ スライス 380 データ ソース 定義は 6 表示、Architect に 123 データ タイプ Big Decimal 465 ウェアハウス カタログ 461 高精度 465 マッピングおよび 441 例 442 列内の変更 355 データ プロバイダ ,「プロジェクト ソー ス」を参照 データベース カスタム ログイン 340 ゲートウェイ サポート 338 接続動作 340 第二 338 読み取り動作 340 データベース インスタンス 定義は 77 © 2010 MicroStrategy, Inc. 索引 データベース管理システム 346 データベース ゲートウェイ サポート 338 データベース ゲートウェイ、例 338 データベースの読み取り動作 339 データ モデル , 「論理データ モデル」を 参照 テーブル 移行 346 関係 211 キー 44 行数 344 更新 128 構造の更新 335 構造の表示 334 サイズ 定義は 376 サイズの計算 345 削除、プロジェクトからの 126 サンプル データ 336 集計 368 主キー 44 シンプル キー 44 接頭語 344 追加、プロジェクトへの 89, 122, 124 トランスフォーメーション 387 ネーム スペース 333, 341, 344 ファクト テーブル 186 複合キー 44 物理ウェアハウス スキーマ 42 プロジェクト作成アシスタントでの ウェアハウス テーブル 89 プロジェクトの管理 332 別名 285, 287 変更 129 要約 368 ルックアップ 45, 46 論理サイズの計算 345 論理テーブル エディタ 376 テーブルの移行 346 499 索引 テーブルの行数 344 テーブル ファクト テーブル 定義は 48 テーブル ベースのトランスフォーメー ション 387 作成 388 メンバー テーブル 392 テーブル ベースのメンバー式 393 定数アトリビュート 261 ディメンション 「階層」も参照 デカルト結合 265 テキスト ファクト ,「結合子関係」を参照 テクニカル サポート xxvii 国際 xxvii と 同種 パーティション マッピング 379, 381 列名 52 動的関係 定義は 374 動的集計 370 トラブルシューティング データ ウェアハウス接続 354 テーブルが見つからない 354 テーブルの列が見つかりません 355 変更した列データ タイプ 355 トランスフォーメーション 定義は 386 1 対 1 のマップ タイプ 393 2 重カウント 393 構成要素 392 式ベース 387, 390 多対多 388 テーブル ベース 387, 388 マップ タイプ 393 メトリック 386 メトリック , 「トランスフォーメー ション メトリック」を参照 500 プロジェクト デザイン ガイド メンバー アトリビュート 392 メンバー式 392 メンバー テーブル 392 例 386 トランスフォーメーション メトリック 定 義は 386 結合子アトリビュート 394 は パーティション マッピング テーブル 定義 は 381 パーティション ベース テーブル 定義 は 378, 382 パーティション マッピング 定義は 377 アトリビュート条件 380 アプリケーション レベル 378 異種 379 ウェアハウス 381, 383 サーバ レベル 377 タイプ 378 データ スライス 380 テーブル 333, 381 同種 379, 381 パーティション ベース テーブル 382 メタデータ 378, 383 例 379 派生 アトリビュート 256 ファクト 144, 200 ファクト列 49 派生ファクトの例 201 ひ ビジネス インテリジェンス（BI）システ ム 定義は 1 ヒューリスティック スキーマの作成 106 © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド 表示 サンプル ウェアハウス スキーマ 410 サンプル データ モデル 409 サンプルのテーブル データ 336 テーブル構造 334 開く ウェアハウス カタログ 330 プロジェクト作成アシスタント 86 品質 ,「結合子関係」を参照 ふ ファクト 22, 定義は 185 暗黙の 200 異種のファクト列 146, 203 階層と 27 拡張 208 基本ファクト列 49 禁止 223 作成 187 直積結合 217 テーブル 48 テーブル , 「ファクト テーブル」を参 照 テーブル関係 211 特定 31 派生 144, 200 派生ファクト列 49 ファクト エディタ 188, 193 ファクト関係 215 ファクト作成ウィザード 188 ファクト定義 197, 198 ファクトのエントリ レベル 187 列 ,「ファクト列」を参照 列別名 148, 197, 206 レベル拡張 198, 208 割り当て式 222 ファクト エディタ 188, 194 ファクト作成ウィザード 188 © 2010 MicroStrategy, Inc. 索引 ファクト式 定義は 199 ファクト テーブル 定義は 186 ウェアハウスと 48 概要 23 列名 52 レベル 50 ファクト分解 定義は 219 ファクト列 定義は 43 異種 146, 203 基本 49 派生 49 フィルタ処理された階層 312 フォーム アトリビュート 248 グループ 292 式 253 フォーム グループ 定義は 292 複合アトリビュート 165, 定義は 291 作成 291 複合キー 定義は 44 複合アトリビュートと 165, 291 物理ウェアハウス スキーマ 定義は 41 MicroStrategy Tutorial 410 サンプル 410 デザインのファクタ 61 例 42 ブラウズ 316 アトリビュート 316 階層内での有効化 318 フォーム 294 フラグ 278 プロジェクト 定義は 14 Project Builder 97 ウェアハウス カタログ 89 計画 83 更新、Architect によるテーブルの 128, 129 削除、Architect によるテーブルの 126 501 索引 削除、からのテーブルの 90 作成 82 サンプル プロジェクト 397 集計テーブル 375 集計テーブルの統合 375 スキーマ 326 ソース , 「プロジェクト ソース」を参 照 追加、Architect によるテーブルの 124 追加、テーブルの 89, 90, 122 データ ウェアハウス 89 テーブルの管理 330 内のウェアハウス テーブル 89, 122 プロジェクト作成アシスタント 87, 90, 117 プロジェクト作成アシスタント 85, 304 プロジェクト作成アシスタントでのウェ アハウス テーブル 89 プロジェクト ソース 定義は 75 作成 86 接続先 79 プロジェクトの計画 83 分解 定義は 219 分析、時系列 385 へ ベース テーブル 定義は 371 事前集計 371 別名 アトリビュート列 262 テーブル 285, 287 ファクト列 148, 197, 206 ま マッピング ウェアハウス カタログのスキーマ プ ロジェクト 345 502 プロジェクト デザイン ガイド マップ タイプ 393 1 対 1 393 多対多 393 マルチディメンション データ モデル , 「論理データ モデル」を参照 み 密集計 372 め 明示的テーブル別名 285, 287 メタデータ 定義は 9 シェル 75 接続先 79 テーブル 79 メタデータ シェル 定義は 75 メタデータ パーティション マッピン グ 378 アトリビュート条件 380 ウェアハウス パーティション マッピ ングとの違い 382 データ スライス 380 メトリック トランスフォーメーション 386 メンバー アトリビュート 392 式 392 テーブル 392 ゆ ユーザ オブジェクト 10 ユーザ階層 定義は 305 アトリビュートのフィルタ処理 312 エントリ ポイント 313 構造 306 作成 300 制限 310 © 2010 MicroStrategy, Inc. プロジェクト デザイン ガイド ドリル 319 表示 308 ブラウズ 316 ブラウズ アトリビュート 316 ブラウズの有効化 318 ロック済 308 ユーザ定義オブジェクト ,「ファクト式」 を参照 よ 要約テーブル 368 り リレーショナル データベース管理システ ム ,「RDBMS」を参照 る ルックアップ テーブル 定義は 45 1 対 1 関係 46 アトリビュート関係と 46 多対多関係 46 統合 60 ルックアップ テーブルの統合 60 れ 例 ETL 4 アトリビュート 24 アトリビュート、異種マッピング 259 アトリビュート エレメント 25, 242 アトリビュート関係 26, 265 アトリビュート条件 380 アトリビュート表示、ブラウズ用 の 295 アトリビュート フォーム 38, 227 アトリビュート フォーム式 253 © 2010 MicroStrategy, Inc. 索引 アトリビュート ロール 281 異種の列名 203 一意の識別子 36 親子関係 268 階層 305, 373 階層を使用するドリル 319 構成オブジェクト 9 国際化 245 シンプル キーと複合キー 44 ダッシュボードとスコアカード 398 データ タイプ 442 データベース ゲートウェイ 338 データ モデルの例 27 データを取得するソース システム 3 テーブル関係 211 テーブルのデータ サンプル 336 ドキュメント 399 トランスフォーメーション 386 並べ替え順 252 パーティション 379 派生ファクト 201 ファクト分解 219 ファクト、レポートの禁止 223 複合アトリビュート 291 複数のデータ ソース 356 物理スキーマ 42, 410 プロジェクト 397 列の別名 206 論理データ モデル 20, 28, 401 論理テーブル 417 論理表示 422 レイヤー 定義は 135 列 定義は 43, 334 ID 43 異種の名前 51 基本ファクト列 49 説明 43 データ タイプ , 「列のデータ タイプ」 503 索引 プロジェクト デザイン ガイド を参照 同種の名前 52 派生ファクト 49 ファクト 43 物理ウェアハウス スキーマ 42, 43 列データ タイプ 変更された 355 列別名 定義は 206 アトリビュート 262 ファクト 148, 197, 206 レベル 拡張 208 レポート表示フォーム 294 ろ ログイン、カスタム 340 ロック済の階層 定義は 308 論理データ モデル 定義は 19 MicroStrategy Tutorial 401, 410 一意の識別子 36 カーディナリティ 37 構造のソース 31 作成 28 サンプル 27 スキーマの種類 53 デザインのファクタ 61 内のアトリビュート 26 表記法 35 比率 37 例 20, 28 論理データ モデルの作成 28 論理テーブル エディタ 376 論理テーブル サイズ 376 論理表示、例 422 わ 割り当て式 222 504 © 2010 MicroStrategy, Inc.