JPH10207751A

JPH10207751A - データ管理システム

Info

Publication number: JPH10207751A
Application number: JP9334746A
Authority: JP
Inventors: Tejwansh Singh Anand; シンアナンドテジュワンシュ; Glenn Keith Wikle; キースウィクルグレン; Marshall Paul Lindsay; ポールリンドセイマーシャル; Richard Neal Schubert; ニールシューベルトリチャード; Drew Thomas Lettington; トーマスレティントンドゥルー; Jeffrey Paul Ludwig; ポールラドウィグジェフレイ; James Foster Knutson; フォスタークナッソンジェイムズ; Soheila Toheri; トヘリソヘイラ; Scott Dale Coulter; デイルコウルタースコット; Kevin Wayne Copas; ワインコパスケヴィン
Original assignee: NCR International Inc
Current assignee: NCR International Inc
Priority date: 1996-10-31
Filing date: 1997-10-29
Publication date: 1998-08-07
Also published as: EP0840240A3; EP0840240A2

Abstract

(57)【要約】【課題】グラフィック・データを、サーバ・コンピュ
ータからクライアント・コンピュータに送信し、ユーザ
に表示するハイパーテキスト・データ処理システムに関
する。【解決手段】ハイパーテキスト・マークアップ言語
（ＨＴＭＬ）への拡張を使用して、図形的データがサー
バ・コンピュータバからクライアント・コンピュータヘ
送られるハイパーテキスト・データ処理システム。クラ
イアント・コンピュータは、図形的データの文法関係を
解析し、表示対象のグラフを表す対象物を作成する。上
記対象物は、グラフを表示するグラフ・サーバヘ送られ
る。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明はエキスパート・シス
テムおよびレポート・システムに関し、特にコンピュー
タのデータベースを分析してセグメント化するため、お
よびレポートを作成するためのデータベース管理システ
ムに関する。

【０００２】

【従来の技術、及び、発明が解決しようとする課題】多
くのアプリケーションにおいて、大量のトランザクショ
ン・レベルのデータが後で分析するために格納されてい
る（データ・ウェアハウス）。データ・ウェアハウスを
使うためには、そのデータが検索され、編成されてか
ら、理解できる形式で示されなければならない。データ
・ウェアハウスからデータを検索し、分析し、そして提
示するために発見ツールが使われる。これらのツールと
しては、非常に複雑なモデリング・ツールから、ユーザ
からＳＱＬデータベース・プログラミング言語の複雑性
をマスクする以外には何もしないように設計されている
比較的単純なエンド・ユーザ問合わせツールまでの範囲
のものがあり得る。傾向または関係を求めてデータをサ
ーチする自動化されたツールも発見ツールと考えられ
る。

【０００３】市場には各種のツール・ベンダがあり、そ
れらのベンダの製品は知識発見プロセス全体のうちの一
部に対するソリューションを提供する。したがって、そ
れらのデータを効果的に利用するためには、ユーザ・コ
ミュニティは複数の分離されたツールを使うことを余儀
なくされている。さらに、これらのツールはそのツール
の中に実装されているデータおよびデータベースのフォ
ーマットまたは各種の分析方法についての深い知識を有
する専門家のユーザを対象として作られている。また、
既存の製品はユーザに明示的にそして繰返し的に知識を
表現させない。最後に、既存のツールの出力はユーザが
分析して解釈しなければならない複数のテーブルから構
成されている。

【０００４】データ・ウェアハウス、そして一般にデー
タベースは、データの検索を効率化するために複雑な構
造を有しており、それらをエンド・ユーザが使うのは簡
単ではない。ユーザはデータベースの言葉ではなく、ユ
ーザの言葉でのレポートを望んでいる。市場にあるいく
つかのツールによって、ユーザは新しい用語を定義して
それらの用語をデータベースにマップすることができる
が、新しい用語の関連付けられた集合の管理はサポート
されない。すなわち、既存の用語に対する新しい用語の
関係は自動的にはユーザに対しては検出されない。これ
らの問題点の他に、レポートの内容についてユーザが別
の、同様なレポートを要求することになるのが普通であ
る。関連付けられたレポートの集合の記憶および再使用
（新しいデータの集合についてそのレポートを再生成す
ること）も望まれる。新しいデータについての関連付け
られたレポートの生成およびそのレポートの再生成は市
場では十分には利用できない。

【０００５】ユーザがデータベースの底流にあるデータ
構造についての、あるいはデータベースのプログラミン
グ言語についての知識を必要とせずに、１つのツールで
データを検索して分析することができ、ユーザが新しい
用語を定義して用語間の関係を検出して管理することが
でき、ユーザが簡単に関連のレポートを生成することが
でき、そして新しいデータについての関連付けられたレ
ポートの集合を再生成できるような、コンピュータ・デ
ータベースからのレポートを生成するためのシステムを
提供することが１つの望ましい目的である。本発明のも
う１つの目的はユーザがデータベースの中のデータに関
連付けられている属性に基づいてデータベースをセグメ
ント化して区画化することができるシステムを提供する
ことである。

【０００６】

【課題を解決するための手段】本発明の第１の態様によ
れば、次のものを特徴とするデータベース管理システム
が提供される。（１）関連付けられた属性を有するデータ・エンティテ
ィを含んでいるデータベースと、（２）前記データベースに結合されているサーバと、（３）前記サーバに結合されているクライアント・コン
ピュータとを備え、前記データ・エンティティは第１階
層の中で並べられていて、前記第１階層の各レベルが少
なくとも１つの属性に関連付けられていて、前記サーバ
・コンピュータが、（ａ）選択された属性を制限するための属性制限値を受
信するための受信手段と、（ｂ）前記データベースをセグメント化するためのセグ
メント化手段とを含み、その中で第２階層が生成され、
前記第２階層は前記属性制限値と関連付けられていて、
前記クライアント・コンピュータが、（ａ）前記属性制
限値を前記クライアント・コンピュータのユーザから入
力するための手段と、（ｂ）前記属性制限値を前記受信
手段に対して送信するための手段とを含んでいる。

【０００７】本発明の第２の態様によれば、次のことを
特徴とするデータベース管理システムが提供される。（１）１つの組織を示しているデータを含んでいるデー
タベースと、（２）前記データベースに対して結合されているサーバ
・コンピュータと、（３）前記サーバに対して結合されているクライアント
・コンピュータとを備え、前記サーバ・コンピュータ
が、（ａ）定義されたトリガ・イベントの発生に応答して、
あるいは前記データベースの中の前記データを分析する
ための要求に応答して、前記データベースに対して問い
合わせるための問合わせ手段と、（ｂ）前記問合わせ手段に対して応答するレポートを作
成するためのレポート作成手段とを含み、前記クライア
ント・コンピュータが、（ａ）前記レポート作成手段に
よって作成される前記レポートを受信するための手段
と、（ｂ）前記クライアント・コンピュータのユーザに
対して前記レポートを表示するための手段とを含んでい
る。

【０００８】本発明のさらにもう１つの態様によれば、
次のものを含むデータベース管理システムが提供され
る。（１）１つの組織を示すデータ・エンティティを含んで
いるデータベースと、（２）前記データベースに対して結合されているサーバ
・コンピュータと、（３）前記サーバに対して結合されているクライアント
・コンピュータとを備え、前記データ・エンティティが
第１階層の中に並べられていて、前記第１階層の各レベ
ルが少なくとも１つの属性に関連付けられており、前記
サーバ・コンピュータが、（ａ）定義されたトリガ・イベントの発生に応答して、
あるいは前記データベースの中の前記データを分析する
ための要求に応答して、前記データベースに対して問い
合わせるための問合わせ手段と、（ｂ）前記問合わせ手段に対する応答のレポートを作成
するためのレポート作成手段と、（ｃ）選択された属性を制限するための属性制限値を受
信するための受信手段と、（ｄ）前記属性制限値に関連付けられている第２階層を
生成するために前記データベースをセグメント化するた
めのセグメント化手段とを含み、前記クライアント・コ
ンピュータが、（ａ）前記属性制限値を前記クライアン
ト・コンピュータのユーザから入力するための手段と、
（ｂ）前記属性制限値を前記受信手段に対して送信する
ための手段と、（ｃ）前記レポート作成手段によって作
成された前記レポートを受信するための手段と、（ｄ）
前記レポートを前記クライアント・コンピュータのユー
ザに対して表示するための手段とを含んでいる。

【０００９】

【発明の実施の形態】ここで図１を参照すると、システ
ム１０が４つの主要サブシステム、すなわち、クライア
ント・サブシステム１２、データ抽象化インテリジェン
ス（ＤＡＩ）サブシステム１４、データおよびスキーマ
操作（ＤＳＭ）サブシステム１６、およびスケジューラ
・サブシステム１８を含んでいる。システム１０の説明
に関連して、次の定義が用意されている。「アラート条
件（ＡｌｅｒｔＣｏｎｄｉｔｉｏｎ）」はその条件が
満足された時にアラート・メッセージを返すユーザ定義
の１つの条件または一組の条件である。例えば、アラー
ト条件はブランドＡのシャツの在庫量が、ある週におい
て２００ユニット以下に落ちた時、システム１０はアラ
ート・メッセージ、ＩｎｆｏＦｒａｍｅ^ＴＭを作成する
か、あるいは別の分析を行う。

【００１０】「アラート・メッセージ（ＡｌｅｒｔＭ
ｅｓｓａｇｅ）」はアラート条件が満足されたことをユ
ーザに通知するメッセージである。アラート・メッセー
ジから、ユーザは作成されるべき対応している情報レポ
ート（ＩｎｆｏＦｒａｍｅ^ＴＭ）を選択することができ
る。アラート・メッセージの一例は「警告：ブランドＡ
のシャツの在庫が２００以下になっています（Ａｌｅｒ
ｔ：ｔｈｅｉｎｖｅｎｔｏｒｙｏｆｂｒａｎｄ
Ａｓｈｉｒｔｓｉｓｂｅｌｏｗ２００）」であ
る。「アラート情報レポート（ＡｌｅｒｔＩｎｆｏＦ
ｒａｍｅ^ＴＭ）」はアラート・メッセージを詳細に記述
している一種のステータス・レポートである。Ａｌｅｒ
ｔＩｎｆｏＦｒａｍｅ^ＴＭは何が起こったか、いつ起
こったか、そしてそれが何故起こったかの理由であると
考えられることを記述している。「アナリスト（Ａｎａ
ｌｙｓｔ）」はアラートをトリガしなければならないデ
ータの中の１つのイベントを規定する。あるいは、１つ
のＩｎｆｏＦｒａｍｅ^ＴＭの中でレポートされるべき分
析および測定項目およびセグメントのタイプを規定し、
そしてオプションとしてこのＩｎｆｏＦｒａｍｅ^ＴＭが
作成されるスケジュール、あるいはＩｎｆｏＦｒａｍｅ
^ＴＭをトリガしなければならないデータの中のそのイベ
ントのタイプを規定する。

【００１１】「属性（ａｔｔｒｉｂｕｔｅ）」はウェア
ハウスの中で表される１つのエンティティの特性または
特徴である。例えば、色（Ｃｏｌｏｒ）、製造者（Ｍａ
ｎｕｆａｃｔｕｒｅｒ）、またはサイズ（Ｓｉｚｅ）は
衣類（Ｃｌｏｔｈｉｎｇ）の製品カテゴリーのすべての
属性である。「属性の制限（ａｔｔｒｉｂｕｔｅｒｅ
ｓｔｒｉｃｔｉｏｎ）」は属性が持ち得る値を制限する
表現である。例えば、「価格が＄１０．００より安い」
の中での「＄１０．００より安い」は「価格」属性につ
いての１つの制限である。もう１つの例は「女性用の衣
類または男性用の衣類」は「部門」属性における制限で
ある。「青（Ｂｌｕｅ）」や「男性用の衣類」などの単
独の属性値も１つの属性制限である。

【００１２】データ・ウェアハウスの中の特定のエンテ
ィティ（製品など）は一組の「属性」および「値」とし
て表される。例えば、製品「デザイナーＸ男性用シャ
ツ、サイズ４２、色は青」は「製品：部門：男性用衣
類；製造者：デザイナーＸ；サイズ：４２；色：青」と
して表される。これらの値は各属性に対する特定のドメ
インのメンバである（下記参照）。

【００１３】「インジケータ（Ｉｎｄｉｃａｔｏｒ
ｓ）」は通常は数値に関連付けられる概念についての分
類（例えば、売上げ数量、在庫、価格）である。インジ
ケータはそれぞれの計算に関係する方法および式（例え
ば、総売上高）およびインジケータ間の因果関係（例え
ば、価格が増加した場合、売上げ数量が減少する筈であ
る）を有する。１つのインジケータの中でセグメントを
定義することができ、それは対象とする特定のグループ
のインジケータ（例えば、年配の顧客、Ａ社の製品）を
記述する。

【００１４】「変動分析レポート（ＣｈａｎｇｅＡｎ
ａｌｙｓｉｓＲｅｐｏｒｔ）」は２つの期間にわたっ
てインジケータを説明している複合ドキュメントであ
る。システム１０の内部では、２つの期間を指定し、そ
の期間に対する選定されたインジケータの差を見ること
ができる（例えば、「今年の繊維製品の売上げは去年の
売上げに比べてどうか？」）。変動分析レポートは日、
週、月、四半期、年、または他の定義された期間に対す
る結果をレポートすることができる。

【００１５】「比較分析（ＣｏｍｐａｒｉｓｏｎＡｎ
ａｌｙｓｉｓ）ＩｎｆｏＦｒａｍｅ^ＴＭ」は、同じ期間
にわたっての２つのインジケータの値をユーザが比較す
ること、あるいは同じ期間にわたっての２つの兄弟セグ
メントについての同じインジケータの値をユーザが比較
するのを支援する一種のステータス・レポートである。
「複合インジケータ（ＣｏｍｐｏｕｎｄＩｎｄｉｃａ
ｔｏｒ）」はプリミティブのインジケータを算術および
集合演算で組み合わせることによって作られるユーザ定
義のインジケータである。

【００１６】「データ・ウェアハウス（ＤａｔａＷａ
ｒｅｈｏｕｓｅ）」は１つまたはそれ以上のデータベー
スの中に収容されるデータの非常に大きな集合である。
これらのデータベースは普通はデータベースのサーバ・
コンピュータ上にあり、１つのロケーションまたは地理
的に分散された場所のいずれかに存在する可能性があ
る。「ディメンション（Ｄｉｍｅｎｓｉｏｎ）」はエン
ティティの高レベルのカテゴリーである。例えば、「小
売り」のドメインにおいて、ディメンションは「製
品」、「マーケット」および「時間」（時間は任意のド
メインに対して適用可能な汎用のディメンションであ
る）などがある。ディメンションはそのエンティティを
記述するために使うことができる一組の属性に関連付け
られている。例えば、「ブランド」、「製造者」および
「サイズ」は１つの製品のディメンションを記述する。

【００１７】すべての属性は値の暗黙の、あるいは明示
的な「ドメイン」を持っている。例えば、「部門」属性
に対する値のドメインはその企業に対する正式な部門の
符号化であり、「サイズ」属性に対する値のドメインは
規定された単位でそのサイズを表している非ゼロの数値
である。

【００１８】「ドリル・ダウン・ヒューリスティッタ
（ＤｒｉｌｌＤｏｗｎＨｅｕｒｉｓｔｉｃ）」はユ
ーザに対してレポートされなければならないセグメント
のフリー属性セグメントの測定項目値間の何らかの関係
を規定する。「エンド・ユーザ（ＥｎｄＵｓｅｒ
ｓ）」はシステム１０が特にそのユーザを対象として設
計されているユーザである。エンド・ユーザはユーザの
操作についての知識を普通に有し、そしてこの例の場合
はＭｉｃｒｏｓｏｆｔＷｉｎｄｏｗｓ^ＴＭ（Ｗｉｎｄ
ｏｗｓ３．１^ＴＭ、ＷｉｎｄｏｗｓＮＴ^ＴＭおよび
Ｗｉｎｄｏｗｓ９５^ＴＭなど）を使っている。エンド
・ユーザは普通は自分がアクセスしたいデータベースの
詳しいデータ構造またはＳＱＬのコード作成についての
専門性を持たない。

【００１９】「ＥｎｔｅｒｐｒｉｓｅＩｎｆｏｒｍａ
ｔｉｏｎＦａｃｔｏｒｙ^ＴＭ（企業情報ファクト
リ）」（ＥＩＦ）は代表的なユーザがデータ・ウェアハ
ウスのそれぞれのデータにアクセスすることができる商
用のソフトウェア・パッケージである。データ・ウェア
ハウスは本質的に受動的な環境であり、普通はデータに
アクセスするためのＳＱＬコードの使用およびデータベ
ースの構造についての知識を必要とする。ＥＩＦはユー
ザがＳＱＬまたはデータベースの知識なしに、それぞれ
のデータベースからデータを取り出すことができるよう
にするツールを提供するための基礎を提供しているとい
う点でデータ・ウェアハウスとは異なっている。

【００２０】「例外アナリスト（Ｅｘｃｃｐｔｉｏｎ
Ａｎａｌｙｓｔ）」はトリガ条件をテストするために定
期的に実行されるアナリストであり、そしてそのトリガ
条件が発生した時にアラートまたはレポートを返す。属
性のドメインが有限の集合（上記の「部門」のような）
であった場合、それは有限ドメインと呼ばれる。それに
対するものは価格（Ｐｒｉｃｅ）などの無限または連続
のドメインである。

【００２１】「自由属性（ＦｒｅｅＡｔｔｒｉｂｕｔ
ｅ）」は１つのセグメントの属性であって、そのセグメ
ントを定義するように制限されていない属性である。色
（Ｃｏｌｏｒ）、コスト（ｃｏｓｔ）、および重量（Ｗ
ｅｉｇｈｔ）はすべてセグメント「高価なシャツ（Ｅｘ
ｐｅｎｓｉｖｅＳｈｉｒｔｓ）」の自由属性となり得
る。「ヒューリスティック・ルール（Ｈｅｕｒｉｓｔｉ
ｃＲｕｌｅ）」はアナリストによって見つけられたい
くつかのデータの条件、そのセグメントの測定項目値間
のいくつかの関係を規定し、それは完成されたＩｎｆｏ
Ｆｒａｍｅ^ＴＭの中でユーザに対してレポートされ得る
必要がある。

【００２２】「ハイパーテキスト・マークアップ言語
（ＨｙｐｅｒＴｅｘｔＭａｒｋｕｐＬａｎｇｕａｇ
ｅ）」（ＨＴＭＬ）はテキスト・ドキュメントの中にハ
イパーリンクおよびグラフィッタ（絵、グラフ、表）を
含めることができるソフトウェア・ドキュメントのため
の、最近使われるようになってきた標準フォーマットで
ある。ハイパーリンクはそのドキュメントの中の「ホッ
ト」領域（普通はその回りのテキストとは異なる色のテ
キスト）であり、その上でクリックされると、元のＨＴ
ＭＬドキュメントに関連付けられているか、あるいはリ
ンクされている別のドキュメントを表示する。

【００２３】「ＩｎｆｏＦｒａｍｅ^ＴＭ定義（Ｄｃｆｉ
ｎｉｔｉｏｎｓ）は」は特定の概念、インジケータ、時
間間隔、分析タイプ、およびセグメントを含めるために
カスタマイズされているシステム・テンプレートであ
る。ＩｎｆｏＦｒａｍｅ定義は１つの「ＩｎｆｏＦｒａ
ｍｅ^ＴＭ」を作るためにただちに「実行する」ことがで
き、後で実行されるために保存されるか、あるいは後で
実行されるために保存されてスケジュールされるか、あ
るいは別のアナリストによってトリガされる。

【００２４】「知識作業者（ＫｎｏｗｌｅｄｇｅＷｏ
ｒｋｅｒ）」はデータ・ウェアハウスの構造を知ってい
て、分析のバックグラウンドを有する、ＳＱＬについて
よく知っている人である。さらに、知識作業者は統計的
およびデータ分析のパッケージおよびデータ・モデリン
グ・ツールを使うことができる。「Ｍａｎａｇａｍｅｎ
ｔＤｉｓｃｏｖｅｒｙＴｏｏｌ^ＴＭ（管理発見ツー
ル）（ＭＤＴ）」は本発明の総合的なシステムを指す。

【００２５】「Ｍｅｔａｄａｔａ^ＴＭ（メタデータ）」
はエンド・ユーザの特定の操作に関する情報の集まりで
あり、コア、パブリックまたはプライベートの３種類の
うちの１つであり得る。インストレーションの後、この
情報はそのエンド・ユーザのデータベースの中に格納さ
れ、そしてそのエンド・ユーザの特定のニーズに合わせ
てレポートを作成するために使われる。Ｍｅｔａｄａｔ
ａ^ＴＭは概念、インジケータ、セグメント、属性、属性
の値および測定項目間の関係を含むが、それらに限定さ
れるわけではない。

【００２６】Ｍｅｔａｄａｔａ^ＴＭのコア・セットは専
門のサービス員およびＭＤＴアドミニストレータによっ
てインストレーション時にセットアップされるのが普通
である。コアのＭｅｔａｄａｔａ^ＴＭはディメンショ
ン、属性、基本測定項目、セグメントおよび年の定義か
ら構成される。パブリックのＭｅｔａｄａｔａ^ＴＭはＭ
ＤＴアドミニストレータおよび知識作業者のユーザ・タ
イプによってのみ変更可能であり、インストレーション
後に定義されて修正される。パブリックのＭｅｔａｄａ
ｔａ^ＴＭはパブリックの複合測定項目、パブリックの測
定項目間の関係およびパブリックのセグメントを含む。

【００２７】プライベートのＭｅｔａｄａｔａ^ＴＭは各
ユーザに所属しており、エンド・ユーザ（エグゼクティ
ブ・ユーザ）のユーザ・タイプによってのみ変更可能で
ある。プライベートのＭｅｔａｄａｔａ^ＴＭはプライベ
ートの複合測定項目、プライベートの測定項目間の関係
およびプライベートのセグメントを含む。属性のドメイ
ンが有限である場合、「自然パーティション（Ｎａｔｕ
ｒａｌＰａｒｔｉｔｉｏｎ）」は各セグメントがそのド
メインの各要素に対応するようなパーティションであ
る。例えば、部門の属性の自然パーティションはセグメ
ント「男性用の衣類」、「婦人の衣類」などの集合であ
る。

【００２８】「オブジェクト・リンキングおよびエンベ
ッディング（ＯｂｊｅｃｔＬｉｎｋｉｎｇａｎｄ
Ｅｍｂｅｄｄｉｎｇ）（ＯＬＥ）」はコンピュータのド
キュメントの中のオブジェクト（例えば、グラフ、表）
が、その上でクリックされた時にそのオブジェクト（グ
ラフ、表、ドキュメント）を生成したソフトウェア・ア
プリケーションを立ち上げることができるコンピュータ
・フォーマットである。与えられたパーティションに対
するユーザ定義のセグメントがそのドメインをカバーし
ない場合、「その他（Ｏｔｈｅｒ）」のセグメントがそ
のパーティションの残りの部分を代表することになる。

【００２９】「パーティション（Ｐａｒｔｉｔｉｏ
ｎ）」は単独の属性の制限によるディメンションの暗黙
の、あるいは明示的な分割である。例えば、価格の属
性、およびその「＄１０．００より安い」という制限を
取り上げると、これは２つの集合またはセグメント、す
なわち、価格が１０ドルより安い製品、および価格が１
０ドルより高いか、あるいはそれに等しい製品に、製品
を区画化することを定義する。パーティションの集合ま
たはセグメントは元の集合をカバーしなければならなら
ず、そしてオーバラップしてはならないことに留意され
たい。すなわち、「価格＜＄１０．００」および「価格
＜＄１５．００」はパーティションを定義しない。

【００３０】「プリミティブ・インジケータ（Ｐｒｉｍ
ｉｔｉｖｅＩｎｄｉｃａｔｏｒｓ）」はデータ・ウェ
アハウスの中のデータに対して直接マップ可能なインジ
ケータである。それらは本発明のインストレーション時
にセットアップされ、そしてエンド・ユーザが変更する
ことはできない。「レポート（Ｒｅｐｏｒｔｓ）」また
は「ＩｎｆｏＦｒａｍｅ^ＴＭ」はテキストおよびグラフ
ィック（例えば、グラフ、表）の形でデータベースから
のデータを表示する複合ドキュメントである。レポート
はＩｎｆｏＦｒａｍｅ^ＴＭの定義が実行された結果作成
するものである。ＩｎｆｏＦｒａｍｅ^ＴＭはＨＴＭＬフ
ォーマットとすることができ、そしてＯＬＥ２．０に適
合することができる。

【００３１】「制限された属性（Ｒｅｓｔｒｉｃｔｅｄ
Ａｔｔｒｉｂｕｔｅ）」はそのセグメントを定義する
時に制限されたセグメントの属性である。製品および価
格は「高価なシャツ」の制限された属性であり得る。
「セグメント（Ｓｅｇｍｅｎｔｓ）」は意味のある属性
または複数の属性を共通に持っているコンセプトの内部
で定義されるユーザ定義のグループである。例えば、セ
グメント「年配の顧客」はその年令が６５才を超えてい
る顧客とすることができる。

【００３２】セグメントはパーティションの一部であ
る。実際に、セグメントは１つまたはいくつかの属性に
ついての制限によって定義されるデータのサブセットで
ある。セグメントがいくつかの属性に定義されている場
合、それはいくつかのパーティションの一部である可能
性があり、制限された各属性に対して１つある（直ぐ後
で示されるように、これは、孤立しているセグメントが
あったとして、それがどのセグメントに属する「べきで
あるか」を判定することができず、したがって、その自
然の親を階層の中で決定することができないことを意味
する）。セグメントの集合はサブセットの関係の下に
「セグメント階層」を形成し、そのルートはディメンシ
ョンのメンバのすべてのを含んでいる「トップレベル・
セグメント」である。

【００３３】「構造化問合わせ言語（Ｓｔｒｕｃｔｕｒ
ｅｄＱｕｅｒｙＬａｎｇｕａｇｅ（ＳＱＬ）」は関
係データベースの内容を見るための構造化された言語で
ある。「要約化ＩｎｆｏＦｒａｍｅ^ＴＭ（Ｓｕｍｍａｒ
ｉｚａｔｉｏｎＩｎｆｏＦｒａｍｅ^ＴＭ）」は１つま
たはそれ以上指定されたセグメントにわたる指定された
インジケータのロールアップ、すなわち、要約を示す１
つのタイプのＩｎｆｏＦｒａｍｅ^ＴＭである。このレポ
ートの中で特定のインジケータを選択することによっ
て、指定された期間の間の「勝者」および「敗者」を示
しているＩｎｆｏＦｒａｍｅ^ＴＭを自動的に作成するこ
とができる。

【００３４】「システム・アドミニストレータ（Ｓｙｓ
ｔｅｍＡｄｍｉｎｉｓｔｒａｔｏｒｓ」（ＭＤＴアド
ミニストレータ、またはＭＤＴＡ）はデータベースにつ
いて、および１つの組織のデータ構造についてよく知っ
ているシステム１０のユーザである。システム・アドミ
ニストレータの肩書きは「データベース・アドミニスト
レータ（ｄａｔａｂａｓｅａｄｍｉｎｉｓｔｒａｔｏ
ｒ）」（ＤＢＡ）であることが多い。「テキスト生成規
則（ＴｅｘｔＧｅｎｅｒａｔｉｏｎＲｕｌｅ）はい
くつかのヒューリスティックなルールが満足されている
時にＩｎｆｏＦｒａｍｅ^ＴＭの中に挿入されなければな
らないテキストを指定する。

【００３５】「トレンド分析（ＴｒｃｎｄＡｎａｌｙ
ｓｉｓ）ＩｎｆｏＦｒａｍｅ^ＴＭ」は、定義された時、
指定の期間にわたる特定のインジケータまたは複数のイ
ンジケータに対する傾向を示す一種のＩｎｆｏＦｒａｍ
ｅ^ＴＭである。この分析は過去のアクティビティによる
パターンを識別することによって、将来を予測するため
の支援となり得る。クライアントのサブシステム１２は
グラフィカル・ユーザ・インターフェース（ＧＵＩ）４
０を備えていて、ユーザがＩｎｆｏＦｒａｍｅ^ＴＭに対
して選択してパラメータを指定し、ＩｎｆｏＦｒａｍｅ
^ＴＭを表示し、ＩｎｆｏＦｒａｍｅ^ＴＭをプリントし、
そしてＩｎｆｏＦｒａｍｅ^ＴＭを保存することができる
単独のアプリケーション・プログラムである。最後に、
ユーザは複合のインジケータおよびセグメントを定義
し、アナリストを生成し、測定項目間の関係を定義し、
あるいはアナリストのスケジュールを変更することがで
きる。

【００３６】ＤＡＩサブシステム１４はグラフィカルな
ユーザ要求を変換し、システムのテンプレートを選択
し、データ・ビューを操作し、そしてデータ・ウェアハ
ウス２４からデータを検索するためのディメンション的
な問合わせを生成するためのインテリジェントなミドル
ウェアを提供する。また、それはデフォールトのパラメ
ータを選定するため、レイアウトおよびディスプレイの
フォーマットを選定するため、およびデータからテキス
トを生成するためのルールも含んでいる。ＤＡＩサブシ
ステム１４はユーザが選択したＩｎｆｏＦｒａｍｅ^ＴＭ
をインスタンシエートするため、およびこのインスタン
シエーションの中で使われるいくつかの種類のＭｅｔａ
ｄａｔａ^ＴＭ２５を管理することを担当する。このＭｅ
ｔａｄａｔａ^ＴＭ２５はデータ・ウェアハウス２４の中
の関係データのカスタマイズ可能な「ディメンション化
（ｄｉｍｅｎｓｉｏｎａｌｉｚａｔｉｏｎ）」を提供す
るコンセプトおよびインジケータを表す。また、ＤＡＩ
サブシステム１４はクライアント・サブシステム１２の
中で作成するＭｅｔａｄａｔａ^ＴＭ２５に対する更新を
処理する。それは主としてＤＳＭサブシステム１６へそ
れらを渡すことによって行なわれる。

【００３７】ＤＳＭサブシステム１６はデータ・ウェア
ハウス２４からスキーマを読み出し、データ・ビューを
生成し、そしてその２つの間のマッピングを生成する。
また、それはＤＡＩサブシステム１４から受信されたデ
ィメンション的な問合わせを、ＳＱＬおよびパッケージ
に変換するマッピングを行い、そしてその結果を返す。
スケジューラ・サブシステム１８はスケジュールされた
時刻において、あるいは規則的なスケジュールにおいて
実行されるアナリスト、あるいはデータベースの中でト
リガ条件を規則的にテストしなければならない例外アナ
リストを開始することを担当する。要求された時間間隔
が発生すると、スケジューラが立ち上がり、ＤＡＩサブ
システム１４からスケジュールされたＩｎｆｏＦｒａｍ
ｅ^ＴＭの要求のリストを要求する。これらのリストか
ら、スケジューラ・サブシステム１８はその時点の時間
間隔においてどれを実行するべきかを判定し、そしてそ
れらの要求をそれらがクライアント・サブシステム１２
から送信されたかのようにＤＡＩサブシステム１４へ送
る。

【００３８】このようにサブシステム１０は３階層のア
ーキテクチャとして実装されている。クライアント・コ
ンピュータ３０はクライアント・サブシステム１２を実
行する。クライアント・コンピュータ３０はＷｉｎｄｏ
ｗｓＮＴ^ＴＭ、またはＷｉｎｄｏｗｓ９５^ＴＭを稼
動することが好ましいが、他のオペレーティング・シス
テムも考えられる。クライアント・サブシステム１２
（図６〜１２）はこれらのオペレーティング・システム
で使うのに適している。ディスブレイ２２および入力装
置２１によって、ユーザはＧＵＩ４０を表示することが
でき、そしてアナリストを生成する際に使われるＭｅｔ
ａｄａｔａ^ＴＭ２５の選択を入力することができる。入
力装置２１はキーボード、マウス、あるいは他のポイン
ティング・デバイスであってよい。プリンタ２３によっ
てユーザはＩｎｆｏＦｒａｍｅ^ＴＭをプリントすること
ができる。記憶媒体２６によってユーザはＩｎｆｏＦｒ
ａｍｅ^ＴＭまたはアラート・メッセージを格納すること
ができる。

【００３９】サーバ・コンピュータ３２はＤＡＩサブシ
ステム１４、ＤＳＭサブシステム１６およびスケジュー
ラ・サブシステム１８を実行する。これらの３つのサブ
システムは組み合わさってデータ・ウェアハウス２４か
らの情報を使ってクライアント・サブシステム１２から
のユーザ要求を満たす。サーバ・コンピュータ３２はマ
ルチプロセッサ・コンピュータであること、そしてＵＮ
ＩＸ^ＴＭオペレーティング・システムまたはＷｉｎｄｏ
ｗｓＮＴ^ＴＭを実行することが好ましいが、他のコン
ピュータおよびオペレーティング・システム構成も本発
明によって考えられる。

【００４０】クライアントおよびサーバのコンピュータ
３０および３２はレポート要求に対して非同期に結合さ
れていることが好ましい。すべての他の要求は同期的に
満足される。クライアントとサーバのコンピュータ３０
および３２の間の通信は、伝送制御プロトコル（ｔｒａ
ｎｓｍｉｓｓｉｏｎｃｏｎｔｒｏｌｐｒｏｔｏｃｌ
／インターネット・プロトコル（ｉｎｔｅｒｎｅｔｐ
ｒｏｔｏｃｏｌ）（ＴＣＰ／ＩＰ）を通じて行なわれる
のが好ましいが、他の伝送プロトコルも本発明によって
考えられる。

【００４１】データベース・コンピュータ３４はデータ
・ウェアハウス２４を含んでいる１つまたはそれ以上の
記憶媒体３６を含む。データベース・コンピュータ３４
は大規模な並列プロセッサ・コンピュータであって、Ｕ
ＮＩＸオペレーティング・システムまたはＷｉｎｄｏｗ
ｓＮＴ^ＴＭを実行することが好ましいが、他のコンピ
ュータおよびオペレーティング・システムの構成も本発
明によって考えられる。データ・ウェアハウス２４はデ
ータ・ウェアハウス２４に対するオープン・データベー
ス・コネタト（ＯｐｅｎＤａｔａｂａｓｅＣｏｎｎ
ｅｃｔ）（ＯＤＢＣ）インターフェースをサポートする
任意のコンピュータで稼働するのに適している。サーバ
・コンピュータ３２とデータベース・コンピュータ３４
との間の通信はＯＤＢＣを経由するのが好ましいが、他
のデータベース・インターフェースも本発明によって考
慮されている。

【００４２】ここで図２を参照すると、クライアント・
サブシステム１２はユーザがシステム１０を制御するア
ブリケーション・プログラムであり、Ｗｉｎｄｏｗｓ
ＮＴ^ＴＭまたはＷｉｎｄｏｗｓ９５^ＴＭのオペレーテ
ィング・システムのトップで実行されるのに適してい
る。クライアント・サブシステム１２はログイン・モジ
ュール５０、フォルダ管理サブシステム５４、セグメン
ト・ビルダ５５Ａ、測定項目ビルダ５５Ｂおよび測定項
目間の関係ビルダ５５Ｃ、アナリスト定義サブシステム
５６、サブシステム５３を表示するＩｎｆｏＦｒａｍｅ
^ＴＭおよびＭＤＴアドミニストレータ用インターフェー
ス５７を含む。

【００４３】ログイン・モジュール５０はクライアント
・サブシステム１２の１つのコピーだけがコンピュータ
３０上で稼働しているかどうかをチェックし、コンピュ
ータ３０のローカル化をチェックし、コンピュータ３２
に対して接続し、そしてユーザと対話してクライアント
・サブシステム１２上にユーザをログオンさせる。ログ
オン時に、ログイン・モジュール５０はユーザの名前お
よびパスワードをチェックし、以前に定義されていた可
能性のあるユーザ・プリファレンスを呼び出す。ログイ
ン・モジュール５０によって扱われるユーザからの唯一
つの要求はクライアント・サブシステム１２にログ・オ
ンするための要求である。ログ・イン・モジュール５０
は次の要求を発行する。

【００４４】

【００４５】ユーザがシステム・アドミニストレータで
あった場合、ログイン・モジュール５０はＭＤＴアドミ
ニストレータ用インターフェース５７の「セットアッ
プ」メニュー項目を表示する。ユーザがエンド・ユーザ
であるか、あるいは知識作業者であった場合、メイン・
メニューおよびツールバー・インターフェース５１がサ
ブシステム５３〜５５に関係付けられているインターフ
ェースとして表示される。ＭＤＴアドミニストレータ用
インターフェース５７はグローバルに利用できるユーザ
定義のセグメントの作成およびコンセプトの生成と編集
などの、システム管理タスクを実行するためにシステム
・アドミニストレータによって使われる。インターフェ
ース６２はシステム・インストレーション時にシステム
・アドミニストレータに対してのみ提供されることが好
ましい。

【００４６】フォルダ管理システム５４はフォルダの階
層を操作し、格納し、そしてそれらのフォルダの中に格
納されるＩｎｆｏＦｒａｍｅｓ^ＴＭおよびエージェント
に関連したすべての機能を扱う。また、クライアント・
サブシステム１２のスタートアップ時、およびそれ以降
定期的に、新しく完成したＩｎｆｏＦｒａｍｅ^ＴＭに対
するＤＡＩサブシステム１４からの問合わせを処理す
る。また、フォルダ管理サブシステム５４は次のものに
ついての動作に対するユーザ要求を処理する。

【００４７】・フォルダ（新規作成、削除、名称変更）・エージェント（編集、削除、即時実行、プリント）・ＩｎｆｏＦｒａｍｅ^ＴＭ（ビュー、削除、アノテー
ト、プリント［ＩｎｆｏＦｒａｍｅ^ＴＭのビュー・ウィ
ンドウと協調して］）各フォルダは１つのフォルダ・オブジェクトによって表
される。フォルダはチャイルド・フォルダのリスト、Ｉ
ｎｆｏＦｒａｍｅ^ＴＭのリスト、およびエージェントの
リストを格納する。フォルダ・オブジェクトはユーザ要
求に応答してフォルダ管理サブシステム５４によって生
成／削除される。

【００４８】サブシステム５５Ｂは新しい測定項目の生
成、測定項目の更新、または既存の測定項目の削除を行
う機能をユーザに提供する。この情報はＭｅｔａｄａｔ
ａ^ＴＭのＡＰＩ６０へ送られ、そしてその後、ユーザの
Ｍｅｔａｄａｔａ^ＴＭ２５を更新するためにＤＡＩサブ
システム１４へ送られる。サブシステム５５Ａはユーザ
に新しいセグメントの生成、セグメントの更新または既
存のセグメントの削除を行う機能を提供する。この情報
はＭｅｔａｄａｔａ^ＴＭのＡＰＩ６０へ送られ、その
後、そのユーザのＭｅｔａｄａｔａ^ＴＭ２５を更新する
ためにＤＡＩサブシステム１４へ送られる。

【００４９】最後に、サブシステム５５Ｃはユーザに測
定項目間の関係の変更、および測定項目間の関係の制約
を行うためのインターフェースを提供する。ユーザは現
在の測定項目を選択し、それが増加または減少する時に
その測定項目間の関係を評価するかどうかを選択する。
ユーザは他の測定項目のリストから選択することがで
き、そして現在の測定項目に対するそれぞれの関係を定
義することができる。これらの関係は「減少する」、
「増加する」、または「現在の測定項目には関連付けら
れていない」の形式である。また、２つの測定項目間の
すべての関係に制約を付けることができる。測定項目と
その測定項目に課せられた制約との関係がＩｎｆｏＦｒ
ａｍｅｓ^ＴＭの中で使うためにコンピュータ３２上に保
存される。

【００５０】アナリスト定義サブシステム５６は特定の
レポートを作成するために必要なパラメータのユーザ選
択に関連したすべての機能を処理する。また、ユーザが
スケジュールされたレポートに対してアラートを定義
し、そしてスケジュールできるようにする。ユーザは既
存のアナリストの呼出し、フォルダ管理サブシステム５
４の内部からのアナリストの削除、または新しいアナリ
ストの生成を行うことができる。次の５種類のアナリス
トがある。

【００５１】・要約化・セグメントの比較・測定項目の比較・変動分析・トレンド分析要約化のアナリストは次のユーザ選択の要求を必要とす
る。・アナリスト名・一次測定項目、他のオプションの測定項目・一次セグメント、他のセグメント・時間間隔・オプションのスケジュール・オプションのトリガ・使用される年のタイプ・オプションのトリガ・イベント（アラート・メッセー
ジ、ＩｎｆｏＦｒａｍｅ^ＴＭ、別のアナリストの実行）

【００５２】セグメント比較アナリストは次のユーザ選
択要求を必要とする。・アナリスト名・一次測定項目、・一次セグメント、比較セグメント・時間間隔・オプションのスケジュール・オプションのトリガ・使用される年のタイプ・オプションのトリガ・イベント（アラート・メッセー
ジ、ＩｎｆｏＦｒａｍｅ^ＴＭ、別のアナリストの実行）

【００５３】測定項目評価アナリストは次のユーザ選択
要求を必要とする。・アナリスト名・一次測定項目、比較測定項目・一次セグメント、他のオプションのセグメント・基本期間、比較期間・オプションのスケジュール・オプションのトリガ・使用される年のタイプ・オブションのトリガ・イベント（アラート・メッセー
ジ、ＩｎｆｏＦｒａｍｅ^ＴＭ、別のアナリストの実行）

【００５４】変動分析アナリストは次のユーザ選択要求
を必要とする。・アナリスト名・一次測定項目・一次セグメント、他のオプションのセグメント・基本期間、比較期間・オプションのスケジュール・オプションのトリガ・使用される年のタイプ・オプションのトリガ・イベント（アラート・メッセー
ジ、ＩｎｆｏＦｒａｍｅ^ＴＭ、別のアナリストの実行）

【００５５】トレンド分析アナリストは次のユーザ選択
要求を必要とする。・アナリスト名・一次測定項目・一次セグメント、他のオプションのセグメント．期間、時間間隔・オプションのスケジュール・オプションのトリガ・使用される年のタイプ・オプションのトリガ・イベント（アラート・メッセー
ジ、ＩｎｆｏＦｒａｍｅ^ＴＭ、別のアナリストの実行）

【００５６】ユーザはアナリスト定義を保存または実行
することができる。ユーザは各コンセプトの内部から１
つのセグメントを選定するように制限され、ただし、タ
ーゲット・セグメントの場合は例外であり、その場合は
１つのセグメントだけを選択することができ、そしてそ
の選択されたセグメントの２つ以上のチャイルド・パー
ティションを選択することができる。ユーザは１つのア
ナリストをスケジュールするために選択することがで
き、あるいは既存のスケジュールを変更または削除する
ことができる。スケジュールされていないアナリストは
そのユーザが指令した時に実行される。スケジュールさ
れているアナリストは後日または定期的に実行するため
にサーバに対してサブミットされる。

【００５７】ユーザは例外アナリストを指定するために
そのアナリストに対するトリガ条件を指定することがで
きる。サーバにサブミットされた時、それはそのトリガ
条件をテストするために定期的に実行され、そしてその
トリガ条件が発生した時は常に、アラートまたはＩｎｆ
ｏＦｒａｍｅｓ^ＴＭを返す。アナリスト定義サブシステ
ム５６はフォルダ管理サブシステム５４に対して次の要
求を行う。

【００５８】

【００５９】また、アナリスト定義サブシステムは次の
要求をＭｅｔａｄａｔａ^ＴＭのＡＰＩ６０に対して行
う。

【００６０】

【００６１】ＩｎｆｏＦｒａｍｅ^ＴＭビューイング・サ
ブシステム５３はＷＹＳＩＷＹＧブラウザを含み、それ
はＩｎｆｏＦｒａｍｅ^ＴＭ５３がＩｎｆｏＦｒａｍｅ
^ＴＭを見るためにフォルダ管理サブシステム５４から通
知を受けた時に、選択されたＩｎｆｏＦｒａｍｅ^ＴＭを
画面に表示する。ユーザが現在のＩｎｆｏＦｒａｍｅ
^ＴＭからドリル・ダウンすることを決定した場合、Ｉｎ
ｆｏＦｒａｍｅ^ＴＭビューイング・サブシステム５３は
新しいレポート要求を送るためにフォルダ管理サブシス
テム５４へ知らせる。

【００６２】ユーザがＩｎｆｏＦｒａｍｃ^ＴＭ上でダブ
ルクリックするか、あるいはファイル・メニュー・フォ
ルダから「ｍｅｎｕｉｔｅｍ−Ｖｉｅｗ（メニュー・
アイテムの表示）」を選択した場合、フォルダ管理サブ
システム５４はそのＩｎｆｏＦｒａｍｅ^ＴＭを見るため
にＩｎｆｏＦｒａｍｅ^ＴＭビューイング・サブシステム
へ通知する。ユーザが現在のＩｎｆｏＦｒａｍｅ^ＴＭか
らドリル・ダウンするためにハイパーテキスト上でクリ
ックした時、ＩｎｆｏＦｒａｍｅ^ＴＭビューイング・サ
ブシステム５３はそのドリル・ダウン情報をホルダー管
理サブシステム５４に渡して、ＤＡＩサブシステム１４
に対する新しいレポート要求を送る。

【００６３】ＩｎｆｏＦｒａｍｅ^ＴＭビューイング・サ
ブシステム５３はパーサを含み、そのパーサはＩｎｆｏ
Ｆｒａｍｅ^ＴＭをパースして、ＨＴＭＬで書かれている
完全なレポートを抽出する。ＨＴＭＬファイルの中で、
ＨＴＭＬタグは他のドキュメントまたはリソースに対し
てリンクしているドキュメント要素、構造、フォーマッ
ティング、およびハイパーテキストを示す。次に、パー
サは表示のためのすべての情報を出力する。本発明にお
いては、そのハイパーリンクは新しいアナリストおよび
ＩｎｆｏＦｒａｍｅ^ＴＭであってよい。

【００６４】ＩｎｆｏＦｒａｍｅ^ＴＭビューイング・サ
ブシステム５３によって、ユーザはパーサによって収集
された情報に基づいてディスプレイ２２によってテキス
ト、表、およびグラフを表示およびフォーマットするこ
とができる。ユーザはその表示されたＩｎｆｏＦｒａｍ
ｅ^ＴＭを保存することができる。また、ユーザは１つの
ＩｎｆｏＦｒａｍｅ^ＴＭをＵＮＩＣＯＤＥまたはＡＳＣ
ＩＩコードのフォーマットでＨＴＭＬファイルとして保
存することもできる。保存されたＨＴＭＬＩｎｆｏＦｒ
ａｍｅ^ＴＭはｅメールに付加してメールで送り出すこと
ができる。バージョン３．０のＨＴＭＬブラウザ、また
はそれと等価な任意のブラウザがＨＴＭＬのＩｎｆｏＦ
ｒａｍｅ^ＴＭを読むことができる。

【００６５】Ｍｅｔａｄａｔａ^ＴＭのＡＰＩ６０はクラ
イアント・サブシステム１２とＤＡＩサブシステム１４
との間のほとんどの通信を処理する。これらの通信は４
種類の基本データ、すなわち、Ｍｅｔａｄａｔａ^ＴＭ２
５、ＩｎｆｏＦｒａｍｅ^ＴＭ、ユーザ・プロファイル、
およびデータ・ウェアハウスのスキーマに関係する。Ｍ
ｅｔａｄａｔａ^ＴＭの通信の場合、Ｍｅｔａｄａｔａ
^ＴＭのＡＰＩ６０はＭｅｔａｄａｔａ^ＴＭ２５を追加、
削除および更新する機能を提供する。ＩｎｆｏＦｒａｍ
ｅ^ＴＭの場合、Ｍｅｔａｄａｔａ^ＴＭのＡＰ１６０はレ
ポートのステータスを獲得し、レポートを検索し、そし
てレポート要求を取り消すための機能を提供する。ユー
ザ・プロファイルの場合、Ｍｅｔａｄａｔａ^ＴＭのＡＰ
Ｉ６０はユーザの追加、ユーザの認証およびユーザの削
除機能を提供する。データ・ウェアハウス・スキーマの
ための通信はそれを検索することである。

【００６６】ＭｅｔａｄａｔａのＡＰＩ６０によって、
ユーザは操作を眺める新しい方法を定義することができ
る。ユーザはパブリック・セグメント、基本測定項目ま
たはパブリックな測定項目を変更することはできない。
しかし、ユーザは新しいインジケータおよび新しいセグ
メントを生成することができる。ユーザとシステム・ア
ドミニストレータの代表的な組織において、システム・
アドミニストレータだけが基本の操作測定項目を生成ま
たは変更することができる。アドミニストレータおよび
知識作業者はパブリックの複合測定項目、パブリック・
セグメントおよびパブリック測定項目間の関係を生成、
編集または削除することができる。Ｍｅｔａｄａｔａ
^ＴＭのＡＰＩ６０は他のクライアント・サブシステムか
らの次の要求を処理する。

【００６７】

【００６８】Ｍｅｔａｄａｔａ^ＴＭのＡＰＩ６０は次の
要求を直接にＤＡＩサブシステム１４に対して送る・コンピュータ３２から切り離す・ＤＡＩサブシステム１４に対してデータを送信する・ＤＡＩサブシステム１４からデータを受信するここで図３を参照すると、ＤＡＩサブシステム１４はリ
ターン・エリア・マネージャ７０、ＩｎｆｏＦｒａｍｅ
^ＴＭゼネレータ７２、Ｍｅｔａｄａｔａ^ＴＭ要求モジュ
ール７４、Ｍｅｔａｄａｔａ^ＴＭリポジトリ７６、およ
びＭｅｔａｄａｔａ^ＴＭロードおよび更新モジュール７
８を含む。

【００６９】Ｍｅｔａｄａｔａ^ＴＭリポジトリ７６はデ
ータ・ウェアハウス２４の中のＭｅｔａｄａｔａ^ＴＭ２
５の表現を含む。このＭｅｔａｄａｔａ^ＴＭ２５はシス
テム１０のコアである。それはウェアハウス２４の中の
関係データについてのカスタマイズ可能なビューを提供
し、そしてＩｎｆｏＦｒａｍｅｓ^ＴＭの仕様に対する主
要ボキャブラリである。Ｍｅｔａｄａｔａ^ＴＭリポジト
リ７６はデータ・ウェアハウス２４の中の永続的なＭｅ
ｔａｄａｔａ^ＴＭ表現からＤＳＭサブシステム１６によ
ってスタートアップ時に移植される。Ｍｅｔａｄａｔａ
^ＴＭのリポジトリ７６の中には下記の４種類の基本的な
Ｍｅｔａｄａｔａ^ＴＭ２５がある。

【００７０】・「コンセプト（Ｃｏｎｃｅｐｔｓ）」：
コンセプトはデータをそれに沿って眺めることができる
ディメンションを表す。各ディメンションはその底流の
データの上に階層を強制的に作り、そしてディメンショ
ンを組み合わせて「ドリル・ダウン」または「ドリル・
アップ」操作をドライブすることができる。例えば、単
純な小売り業のアプリケーションには２つのコンセプ
ト、すなわち、市場および製品がある。市場の階層は販
売地域から構成されており、各販売地域がいくつかの州
から構成されており、各州は一組の店舗から構成されて
いる。製品の階層は一組の部門（家庭用電子製品、男性
用衣類、ハードウェア）から構成され、各部門は製品カ
テゴリー（シャツ、靴、スラックス）から構成され、そ
して各カテゴリーは個々の製造者の製品系列から構成さ
れている。時間はすべてのアプリケーションにおいて重
要なディメンションであり、そしてシステム１０の中で
表現される。ユーザは新しいコンセプトを追加すること
ができる（下記参照）。これらはＭｅｔａｄａｔａ^ＴＭ
リポジトリ７６の中のＭｅｔａｄａｔａ^ＴＭ２５のすべ
てと同様に、データ・ウェアハウス２４に実際に問い合
わせするために、関係の形式（すなわち、ＳＱＬ）にマ
ップされなければならない。マッピングはディメンショ
ン的なクエリを処理するプロセスの間にＤＳＭサブシス
テム１６によって行なわれる（下記参照）。

【００７１】・「インジケータ（Ｉｎｄｉｃａｔｏｒ
ｓ）」：インジケータは対象とするデータの重要な測定
項目である。例えば、製品の数量、価格または現在のス
トックはすべてインジケータである。クエリの中で時間
を使うことによって、インジケータの概念がさらにリフ
ァインされる。例えば、「数量における変化」は２つの
期間の間に適用される。・「アラート（Ａｌｅｒｔｓ）」：アラートは本質的に
データについてのテストであるが、それらはＭｅｔａｄ
ａｔａ^ＴＭの一部ではない。それらはＭｅｔａｄａｔａ
^ＴＭの条件でアナリストの中で規定される。例えば、ユ
ーザは製品の利用できるストックが或るパーセンテージ
だけ落ちた場合、適切なＩｎｆｏＦｒａｍｅ^ＴＭを生成
することを指定することができる。また、ユーザはその
トリガ条件をチェックする頻度を指定することもでき
る。アラートのリストはＤＡＩサブシステム１４によっ
て維持され、スケジューラ・サブシステム１８によって
実行される。また、このＭｅｔａｄａｔａ^ＴＭ２５はＤ
ＡＩサブシステム１４に対しても利用可能であり、そし
てＩｎｆｏＦｒａｍｅ^ＴＭ情報を作成するために使われ
る。

【００７２】・「測定項目間の関係（Ｍｅａｓｕｒｅ
Ｒｅｌａｔｉｏｎｓｈｉｐｓ）」：測定項目間の関係は
偶発性の単純な表現である。例えば、「売上げの増加は
利益の増加を意味する」。この種のＭｅｔａｄａｔａ
^ＴＭ２５はＩｎｆｏＦｒａｍｅ^ＴＭに対するサポート情
報を生成するため、あるいは代わりに、測定項目間の関
係の集合に対して反対方向に進む傾向をユーザに対して
警告するために使われる。Ｍｅｔａｄａｔａ^ＴＭ２５は
最初に顧客のサイトにおいて本発明のインストレーショ
ン時に生成される。Ｍｅｔａｄａｔａ^ＴＭ２５の生成の
プロセスは図７〜図１１の中でより詳細に示されてい
る。Ｍｅｔａｄａｔａ^ＴＭ２５の中に含まれるものはそ
の産業によって変わり（或るＭｅｔａｄａｔａ^ＴＭ２５
は業界特有であり、そしてその業界におけるすべての企
業によって使われる）、本発明の特定の顧客、そしてそ
の顧客のデータ・ウェアハウス２４の構造によって変わ
る。インストレーション時に、いくつかの業界固有のＭ
ｅｔａｄａｔａ^ＴＭ２５が使われ、いくつかの企業固有
のＭｅｔａｄａｔａ^ＴＭ２５が生成される可能性があ
り、そしてＭｅｔａｄａｔａ^ＴＭ２５をデータ・ウェア
ハウス２４に対してマップする必要があるマッピング情
報が生成される。すべてのＭｅｔａｄａｔａ^ＴＭ２５
は、マッピング情報を含めて、一組の関係テーブルの中
に格納される。これらの関係テーブルはデータ・ウェア
ハウス２４の中でキープされ、そして本発明によってそ
のユーザに対するレポートを生成するために使われる。

【００７３】Ｍｅｔａｄａｔａ^ＴＭ要求モジュール７４
はクライアント・サブシステム１２又はＤＡＩサブシス
テム１４のいずれかからの、Ｍｅｔａｄａｔａ^ＴＭ２５
に対するすべての要求を処理する。クライアント・サブ
システム１２はエンド・ユーザに対して定義されるべき
Ｍｅｔａｄａｔａ^ＴＭ２５をＤＡＩサブシステム１４か
ら要求する．ＩｎｆｏＦｒａｍｅ^ＴＭゼネレータ７２は
ユーザに対するＩｎｆｏＦｒａｍｅ^ＴＭをインスタンシ
エートすることの一部として、ディメンション的なクエ
リーを生成するためにＭｅｔａｄａｔａ^ＴＭ２５を要求
する。Ｍｅｔａｄａｔａ^ＴＭ２５に対する要求は、例え
ば、特定のコンセプトのすべてのサブコンセプトに対す
る要求である可能性がある．

【００７４】また、Ｍｅｔａｄａｔａ^ＴＭ要求モジュー
ル７４はクライアント・サブシステム１２からのＭｃｔ
ａｄａｔａ^ＴＭの更新も処理する．ユーザはそのデータ
をグループ化するための新しいディメンションを指定す
ることによって、新しいセグメントを追加する．このデ
ィメンションはそのウェアハウスのデータの中の既存の
データ属性によってサポートされなければならない。例
えば、製品は定価および割引価格を含むことができる．
ユーザはその割引価格と定価との間の差のパーセントを
使って指定された「割引ファクター」と呼ばれる新しい
ディメンションを指定することができ、そしてそれを３
つの新しいセグメント、すなわち、大幅値引き製品、小
幅値引き製品、および非値引き製品を生成するために使
う．これらの新しいセグメントをそれ以降のＩｎｆｏＦ
ｒａｍｅ^ＴＭ要求の中で使うことができ、そして、ユー
ザによって示された場合、Ｍｅｔａｄａｔａ^ＴＭのロー
ドおよび更新モジュール７８によってデータ・ウェアハ
ウス２４の中にそれらを書き戻すことによって継続性が
保たれる．

【００７５】１つのサブシステムが別のサブシステムか
らの処理および結果を要求するとき、その１つのサブシ
ステムから別のサブシステムに対して要求構造が渡され
る。要求構造は送られる要求のタイプに従って変わる。
しかし、ほとんどの要求には、識別フィールド、所有
者、名前および要求の記述などのいくつかの共通の属性
がある。コンセプト更新要求がクライアント・サブシス
テム１２からＤＡＩサブシステム１４に対して送られ
る。それはシステム・アドミニストレータによってのみ
発行されることが好ましい。コンセプト更新要求はＭｅ
ｔａｄａｔａ^ＴＭ２５に対して新しいコンセプトを追加
するための要求である。その要求のフォーマットは次の
通りである。

【００７６】

【００７７】インジケータ更新要求はクライアント・サ
ブシステム１２からＤＡＩサブシステム１４に対して送
られる。インジケータ更新要求はＭｅｔａｄａｔａ^ＴＭ
２５に対して新しいインジケータを追加するための要求
である。インジケータ更新要求は主としてプリミティブ
および複合の要求を含む。プリミティブの要求のフォー
マットは次の通りである。

【００７８】

【００７９】複合要求のフォーマットは次の通りであ
る。

【００８０】

【００８１】因果関係インジケータ更新要求はクライア
ント・サブシステム１２からＤＡＩサブシステム１４に
対して送られる。因果関係インジケータ更新要求はＭｅ
ｔａｄａｔａ^ＴＭ２５に対して新しい因果関係インジケ
ータを迫加する。その要求のフォーマットは次の通りで
ある。

【００８２】

【００８３】スキーマ要求はクライアント・サブシステ
ム１２からＤＡＩサブシステム１４に対して送られ、そ
してシステム・アドミニストレータによってのみ発行さ
れる。スキーマ要求はデータ・ウエアハウス２４からデ
ータの基本スキーマを検索するための要求である。この
タイプの要求はＤＡＩサブシステム１４に対する単純な
フォーマットされていないメッセージだけである。セグ
メント更新要求はクライアント・サブシステム１２から
ＤＡＩサブシステム１４に対して送られる。セグメント
更新要求はＭｅｔａｄａｔａ^ＴＭ２５に対して新しいセ
グメントを追加するための要求である。セグメント更新
要求のフォーマットは次の通りである。

【００８４】

【００８５】ＩｎｆｏＦｒａｍｅ^ＴＭ要求はクライアン
ト・サブシステムからＤＡＩサブシステムへ送られる。
このタイプの要求はユーザ指定のセクションに基づいて
新しいＩｎｆｏＦｒａｍｅ^ＴＭを生成することである。
この要求のフォーマットは次の通りである。

【００８６】

【００８７】ディメンション的なクエリーはＤＡＩサブ
システム１４からＤＳＭサブシステム１６へ送られる。
ディメンション的なクエリーはデータ・ウエアハウス２
４からのデータに対する要求を公式化する。ＤＳＭサブ
システム１６はディメンション的クエリーをＳＱＬ文に
変換する。ＤＡＩサブシステム１４はディメンション的
なクエリーをＭｅｔａｄａｔａ^ＴＭのセグメント定義ま
たはパーティション定義のリスト、Ｍｅｔａｄａｔａ
^ＴＭ２５の測定項目定義のリストおよび測定項目値テー
ブルとしてＤＳＭサブシステムに対して通信する。ＤＳ
Ｍサブシステム１６はこれらをＳＱＬクエリーに変換
し、それらをデータ・ウェアハウス２４に対してサブミ
ットする。ＤＳＭに対してデータ・ウェアハウスから戻
された結果は測定項目値テーブルの中に入れてＤＡＩに
対して戻される。

【００８８】クライアント・サブシステム１２はＤＡＩ
サブシステム１４に対して次の出力を作り出す。・コンセプト更新要求・インジケータ更新要求・因果関係インジケータ更新要求・スキーマ要求・セグメント更新要求・ＩｎｆｏＦｒａｍｅ^ＴＭ要求・キャンセル要求

【００８９】ＤＡＩサブシステム１４はクライアント・
サブシステム１２に対して次の出力を提供する。・コンセプトの構造・インジケータの構造・因果関係インジケータの構造・スキーマの構造・セグメントの構造・ＩｎｆｏＦｒａｍｅ^ＴＭ・エラー／ステータス・コード

【００９０】ＤＡＩサブシステム１４はスケジューラ・
サブシステム１８に対して次の出力を提供する。・アナリストのスケジュール要求・アナリストの削除要求ＤＡＩサブシステム１４はＤＳＭサブシステム１６に対
して次の出力を提供する。・ディメンション的クエリー・Ｍｅｔａｄａｔａ^ＴＭ検索要求・スキーマ要求

【００９１】ＤＳＭサブシステム１６はＤＡＩサブシス
テム１４に対して次の出力を提供する。・更新されたＭｅｔａｄａｔａ^ＴＭ・データ・ウエアハウスからのデータ・データベース・スキーマＤＳＭサブシステム１６はデータ・ウェアハウス２４に
対して次の出力を提供する。・ＳＱＬ文ＤＳＭサブシステム１６はデータ・ウエアハウス２４か
ら次の入力を受け取る。・Ｍｅｔａｄａｔａ^ＴＭ・データベース・スキーマ・ウェアハウス・データスキーマ１８はＤＡＩサブシステム１４に対して次の出
力を提供する。・アナリストの定義

【００９２】Ｍｅｔａｄａｔａ^ＴＭのロードおよび更新
モジュール７８はシステムのスタートアップ時にＭｅｔ
ａｄａｔａ^ＴＭのリポジトリー７６をデータ・ウェアハ
ウス２４の中に格納されている永続的なＭｅｔａｄａｔ
ａ^ＴＭで埋める。さらに、ユーザが新しいコンセプトを
規定し、そしてそれらを保存したいことを示すとき、Ｍ
ｅｔａｄａｔａ^ＴＭのロードおよび更新モジュール７８
はそれらを将来の使用のためにデータ・ウェアハウス２
４の中に書き戻す。

【００９３】ＩｎｆｏＦｒａｍｅ^ＴＭゼネレータ７２は
ＤＡＩサブシステム１４の主要目的を実現する。Ｉｎｆ
ｏＦｒａｍｅ^ＴＭの定義を含んでいるユーザのアナリス
トがＤＡＩによって受信されたとき、レポートの作成が
開始される。ＤＡＩの中に実装されているセットから適
切なドリル・ダウン・ヒューリスティックおよびテキス
ト作成ルールを選択するためにアナリストのタイプが使
われる。ドリル・ダウン・ヒューリスティックはレポー
トされなければならないターゲット・セグメントの自由
属性のセグメント間にデータ関係があるかどうかを判定
するために使われる。テキスト作成ルールはそのターゲ
ット・セグメントのどの機能がレポートされるべきか、
および兄弟セグメント、すなわち、そのターゲット・セ
グメントの制限された属性の中の他のセグメントに対し
てどの関係がレポートされるべきかを判定するために、
テキスト作成ルールが使われる。テキスト作成ルールは
適切な出力としてローカライズ可能なテキスト、グラフ
またはテーブルを指定することができる。レポート作成
プロセスの出力はポータブルな複合ドキュメントを作る
ために広く使われている標準であるハイパー・テキスト
・マークアップ言語（ＨＴＭＬ）の形式でクライアント
・サブシステム１２に対して返される、完全にインスタ
ンシエートされたＩｎｆｏＦｒａｍｅ^ＴＭである。

【００９４】ＩｎｆｏＦｒａｍｅ^ＴＭゼネレータ７２は
次のいくつかの種類の知識を備えている。・アブストラクト・クエリーをディメンション的なクエ
リーにマップする方法についての知識・デフォールトの選択フォーム（ＩｎｆｏＦｒａｍｅ
^ＴＭ要求の中でユーザによっては作られない選択項目）
を作成するためにＭｅｔａｄａｔａ^ＴＭ２５を使う方法
についての知識・Ｍｅｔａｄａｔａ^ＴＭ２５とウェアハウスから戻され
たデータの両方を使って両方のテキストのコンポーネン
トの選択をガイドするための方法についての知識・異なるタイプのグラフィック表現の選択をガイドする
ために、Ｍｅｔａｄａｔａ^ＴＭ２５とウェアハウスから
戻されたデータの両方を使う方法についての知識

【００９５】例えば、要約のＩｎｆｏＦｒａｍｅ^ＴＭは
式数としてコンセプト、インジケータ、および期間をと
ることができる。レポート作成モジュールはユーザ選択
のパラメータ、例えば、コンセプト「製品」、コンセプ
ト・セグメント「男性用シャツ」、インジケータ「数
量」および期間「１９９４年１２月」を使ってディメン
ション的なクエリーを生成する。このディメンション的
なクエリーはデータおよびスキーマの操作サブシステム
に対して送られ、そのサブシステムはこのクエリーをＳ
ＱＬに変換し、実際にそれを実行する。それは計算され
たデータをＤＡＩサブシステム１４に対して返し、そこ
で他のアブストラクト・クエリーがバレットの中に実際
の数値を埋め込むことができる。

【００９６】他のアブストラクト・クエリーには条件文
が関連付けられている。前の例を作りあげるために、要
約システム・テンプレートの別の部分によってグラフの
生成を規定することがででき、ターゲット・ビジネス・
インジケータ（数量）がターゲット・ビジネス・コンセ
プト（シャツ）のセグメントの間にどのように配分され
るかを示している。この場合、レポート・ゼネレータ７
２はセグメントの集合（この例においては、シャツの製
造者を規定するディメンション）を返すためのＭｅｔａ
ｄａｔａ^ＴＭ要求を作る。すべての数量情報がシャツの
各製造者に対して要求される。ここで、追加の情報がグ
ラフの種類の選択においてレポート・ゼネレータ７２を
ガイドする。例えば、セグメント（この場合は製造者）
の数が少ない（例えば、７以下）場合、パイ・グラフが
適切であり、それ以外の場合は棒グラフが好ましい。セ
グメントの数が非常に多い場合、ボトムの２０％（その
インジケータ、この場合は数量に関しての）を集約し、
その集約したものにグラフの中で「その他（Ｏｔｈｅ
ｒ）」を付けて使う。

【００９７】リターン・エリア・マネージャ７０はクラ
イアント・サブシステム１２に対する配送を待っている
ユーザによる肯定的な結果によって、ＩｎｆｏＦｒａｍ
ｅ^ＴＭおよびアラート評価を追跡管理する。ユーザがシ
ステム１０にログインしたとき、クライアント・サブシ
ステム１２はＤＡＩサブシステム１４にそのリターン・
エリアの中にそのユーザに対するすべてのデータを返す
よう要求を発行する。リターン・エリア・マネージャ７
０はサーバ・コンピュータ３２上のそのリターン・エリ
アから情報を検索し、それをＤＡＩサブシステム１４経
由でクライアント・コンピュータ３０へ送り返す。

【００９８】ここで図４を参照すると、ＤＳＭサブシス
テム１６はＳＱＬゼネレータ８０およびＭｅｔａｄａｔ
ａ^ＴＭクエリー・モジュール８２を含んでいる。ＳＱＬ
ゼネレータ８０はＤＡＩサブシステム１４から受信され
たディメンション的なクエリーを、データ・ウェアハウ
ス２４からデータを検索するために使われるＳＱＬ文に
変換する。コンセプトからデータベースのエンティティ
ーへのマッピングはＭｅｔａｄａｔａ^ＴＭ２５の中に格
納され、ＳＱＬ文のフォーマッティングにおいて使われ
る。ＳＱＬゼネレータ８０はＩｎｆｏＦｒａｍｅ^ＴＭを
生成する際に使うために、ＤＡＩサブシステム１４に対
して提供する。

【００９９】Ｍｅｔａｄａｔａ^ＴＭクエリー・ゼネレー
タ８２はＤＡＩサブシステム１４がサブミットされたＭ
ｅｔａｄａｔａ^ＴＭ２５に対する要求を処理する。シス
テムのスタートアップ時にＤＡＩサブシステム１４は知
識ベースを初期化するために、すべてのＭｅｔａｄａｔ
ａ^ＴＭ２５を要求する。また、ユーザが自分のセグメン
トを変更するときは常にＭｅｔａｄａｔａ^ＴＭクエリー
・ゼネレータ８２が呼び出され、ＤＡＩサブシステム１
４にＭｅｔａｄａｔａ^ＴＭの更新要求を発行させる。

【０１００】ここで図５を参照すると、スケジューラ・
サブシステム１８はアラートおよびレポートのスケジュ
ーラ９０を含んでいる。スケジューラは待ち行列に入っ
ているスケジュールされたアナリストを定期的にテスト
し、実行の時期が来ているものをＤＡＩサブシステム１
４に対してディスパッチする。スケジューラはサブミッ
トされたすべての例外アナリストをＤＡＩサブシステム
１４に対してディスパッチし、それらがトリガ条件をテ
ストできるようにする。スケジュールおよびトリガの期
間はＭＤＴアドミニストレータによって独立に構成する
ことができる。スケジューラはディスパッチャ２５１３
の方法によって、ＣＤＡＩ１４Ｂに対してアナリスト
を渡す（図３４）。

【０１０１】ここで図６〜図１９を参照すると、クライ
アント・サブシステム１２およびその動作が詳細に示さ
れている。クライアント・サブシステム１２はクライア
ント・サブシステム１２が実行されるときに現れる一次
オーバーレイ９８を含む。オーバーレイ９８は３つのデ
ィスプレイ・エリア１００〜１０４を共通のフォルダ・
ウィンドウ、プルダウン・メニュー１０６、およびボタ
ン１１０〜１２０の中に含む。フォルダのウィンドウは
最大化されて（図６の中に示されているように）その境
界をなくすこと、サイズを変更すること、あるいはアイ
コンとしてクライアント・サブシステム１２の中に最小
化することができる。このフォルダのウィンドウを閉じ
ることはできない。

【０１０２】ディスプレイ・エリア１００はフォルダの
リストを含んでいる。それはＩｎｆｏＦｒａｍｅ^ＴＭお
よびそれらを生成するアナリストを編成する際にクライ
アント・サブシステム１２によって使われるメタファー
を表わす。フォルダは入力装置２１によってそれを強調
表示させてから、それを選択することによって開かれ
る。リストの中の最初のフォルダはクライアント・サブ
システム１２が実行されるときにデフォールトで開かれ
る。

【０１０３】ディスプレイ・エリア１０２は選択された
フォルダの中にあるＩｎｆｏＦｒａｍｅ^ＴＭのリストを
含む。ＩｎｆｏＦｒａｍｅ^ＴＭはそれを強調表示させて
から、それを入力装置２１によって選択して表示するこ
とができる。そのＩｎｆｏＦｒａｍｅ^ＴＭを含んでいる
分析ウィンドウ１３６が現れる。そのウィンドウのタイ
トル・バーは、実行されたあらかじめ選択されている分
析のタイプを示す。例えば、図１９において、「変動
（ｃｈａｎｇｅ）」分析は実行する分析のタイプとして
ユーザによってあらかじめ選択されたものである。分析
ウィンドウ１３６は最大化して（図１９に示されている
ように）その境界をなくすこと、サイズを変更するこ
と、あるいはクライアント・サブシステム１２の中で１
つのアイコンとして最小化することができる。分析ウィ
ンドウ１３６はボタン１２２（図１９）を選択すること
によって、あるいはＷｉｎｄｏｗｓ３．１^ＴＭ、Ｗｉ
ｎｄｏｗｓ９５^ＴＭ、および他のＷｉｎｄｏｗｓの動
作環境のユーザにとって良く知られている方法によって
閉じることができる。

【０１０４】ディスプレイ・エリア１０４は選択された
フォルダの中にあるアナリストのリストを含む。アナリ
ストはＩｎｆｏＦｒａｍｅ^ＴＭを生成する目的のために
あらかじめ選択されたデータについて実行される、あら
かじめ選択された操作の擬人化である。アナリストはそ
れを強調表示させ、入力装置２１によってそれを選択す
ることによって表示することができる。アナリスト・ビ
ルダのウィンドウ１３０（図７〜図１１）がそのアナリ
ストの内部に保存されているあらかじめ選択された設定
を含んで現れる。そしてディスプレイ・エリア１０２の
中にリストされている対応しているＩｎｆｏＦｒａｍｅ
^ＴＭを生成するために使われる（ディスプレイ・エリア
１０２の中にリストされているＩｎｆｏＦｒａｍｅ^ＴＭ
はディスプレイ・エリア１０４の中にリストされている
アナリストと同じ順序に配列されており、そしてそのタ
イトルは対応しているアナリストのタイトルと同じであ
る）。アナリスト・ビルダのウィンドウ１３０は最大化
したり、サイズ変更したり、あるいはアイコンとして最
小化することはできない。それはＷｉｎｄｏｗｓ３．１
^ＴＭ、Ｗｉｎｄｏｗｓ９５^ＴＭ、および他のＷｉｎｄ
ｏｗｓの動作環境のユーザにとって良く知られている方
法によってのみ閉じることができる。

【０１０５】ボタン１１０〜１２２（図６）はプルダウ
ン・メニュー１０６の内部の一次操作コマンドを実装
し、そしてポインティング・デバイスを使って活性化さ
れる。ボタン１１０はアナリスト・ビルダのウィンドウ
１３０（図７〜図１１）を呼び出す。ボタン１１２は情
報セットアップ・ウィンドウ１３２（図１２）の中にセ
グメント・ディバイダを呼び出す。ボタン１１６はディ
スプレイ・エリア１００〜１０４の内部の選択されたフ
ァイルまたはフォルダを削除する。ボタン１１８は新し
いフォルダを生成する。ボタン１２０はディスプレイ・
エリア１０２から選択されたＩｎｆｏＦｒａｍｅ^ＴＭに
よって分析ウィンドウ１３６を呼び出す。ボタン１２２
はクライアント・サブシステム１２を閉じる。ボタン１
５０はプリント・ボタンであり、ボタン１５１によって
ユーザが測定項目を生成することができ、そしてボタン
１５２によってユーザが測定項目間の関係を生成または
編集することができる。

【０１０６】図７〜図１１を参照すると、アナリスト・
ビルダのウィンドウ１３０によってユーザは選択された
データが分析される方法を定義することができる。アナ
リストの名前はアナリスト名（ＡｎａｌｙｓｔＮａｍ
ｅ）のフィールドの下に付けられる。分析のタイプは
「分析のタイプ（ＴｙｐｅｏｆＡｎａｌｙｓｉ
ｓ）」フィールドの中で選ばれる。その分析を実装する
のに使われる主要な測定項目が「主要測定項目（Ｐｒｉ
ｍａｒｙＭｅａｓｕｒｅ）」フィールドの中で選定さ
れる。レポートされるべきセグメントは定義されたセグ
メント（ＤｅｆｉｎｅＳｅｇｍｅｎｔｓ）のリストから
選定される。最後に、そのＩｎｆｏＦｒａｍｅ^ＴＭに対
する期間が「考慮されるタイム・スライス（Ｔｉｍｅ
ＳｌｉｃｅＣｏｎｓｉｄｅｒｅｄ）」フィールドの中で
定義される。ＩｎｆｏＦｒａｍｅ^ＴＭは「即時レポート
（ＲｅｐｏｒｔＮｏｗ）」ボタンを選択することによ
ってただちに生成することができるか、あるいは「スケ
ジュール・アナリスト（ＳｃｈｅｄｕｌｅＡｎａｌｙ
ｓｔ）」ボタンを選択することによってＩｎｆｏＦｒａ
ｍｅ^ＴＭのバッチの一部としてスケジュールすることが
できる。

【０１０７】図１２を参照すると、情報セットアップ・
ウィンドウ１３２の中のセグメント・ディバイダによっ
てセグメントが生成され、変更され、あるいは削除され
るようにすることができる。セグメントの説明が「説明
（Ｄｅｓｃｒｉｐｔｉｏｎ）」フィールドの中に現れ
る。ユーザによってボタン８０１が活性化された時、図
１３のウィンドウ１３２が立ち上げられ、ユーザがセグ
メント定義を編集することができる。

【０１０８】図１４を参照すると、情報の測定項目を情
報セットアップ・ウィンドウ１３２の測定項目ディバイ
ダの中で生成および修正することができる。各メッセー
ジに対する名前が「測定項目名（ＭｅａｓｕｒｅＮａ
ｍｅ）」フィールドの中に現れる。測定項目の定義は
「定義（Ｄｅｆｉｎｉｔｉｏｎ）」フィールドの中に現
れる。算術演算子、タイム・スライスの制約、セグメン
トの制約、および他の測定項目からの制約を定義フィー
ルドの下の対応しているボタンを使ってその定義の中に
挿入することができる。図１５および図１６を参照する
と、ウィンドウ１３２は測定項目を選択するため、およ
びセグメントを選択するためにそれぞれ表示することが
できる。

【０１０９】図１７を参照すると、測定項目間の関係を
情報セットアップ・ウィンドウ１３２の測定項目間の関
係ディバイダの中で定義して変更することができる。測
定項目間の関係は「Ｉｆ−Ｔｈｅｎ」文の形で定義され
る。主要な測定項目およびそれが増加するか減少するか
が測定項目フィールドの中で選択され、それは「Ｉｆ−
Ｔｈｅｎ」文の「Ｉｆ」の部分を表わす。関係付けられ
ていないフィールドの中の測定項目はＩｆ−Ｔｈｅｎ文
の「Ｔｈｅｎ」の部分を形成するために減少フィールド
または増加フィールドのいずれかへ移動させることがで
きる。図１８を参照すると、測定項目間の関係をその図
のウィンドウ１３２の手段によって制限することができ
る。

【０１１０】ＩｎｆｏＦｒａｍｅ^ＴＭのバッチを自動生
産のために個々にスケジュールすることができる。Ｉｎ
ｆｏＦｒａｍｅ^ＴＭのスケジューリングは定期的なＩｎ
ｆｏＦｒａｍｅ^ＴＭを必要とするユーザにとって特に有
用である。ＩｎｆｏＦｒａｍｅ^ＴＭの時間間隔は「時間
間隔（ＴｉｍｅＩｎｔｅｒｖａｌ）」フィールドの中
で選択することができ、それは毎日、毎週、毎月のレポ
ートオプションを提供する。図１９を参照すると、Ｉｎ
ｆｏＦｒａｍｅ^ＴＭの一例が分析ウィンドウ１３６の中
に示されている。実行される分析のタイプはＩｎｆｏＦ
ｒａｍｅ^ＴＭの中で示されており、タイトル・バーの中
で「変動分析（ＣｈａｎｇｅＡｎａｌｙｓｉｓ）」と
して示されている。セグメント（情報セットアップ・ウ
ィンドウ１３２のセグメント・ディバイダの中で以前に
定義された）は「４歳以上の年齢を格納する（Ｓｔｏｒ
ｅＡｇｅｓＧｒｅａｔｅｒＴｈａｎ３Ｙｅａ
ｒｓ）」である。その測定項目（情報セットアップ・ウ
ィンドウ１３２の測定項目ディバイダの中で以前に定義
された）は「同じ店舗の売上高」である。そのタイム・
スライス（アナリスト・ビルダ・ウィンドウ１３０の
「考慮されるタイム・スライス」フィールドの中で以前
に定義された）は「１９９５年度対昨年度」である。

【０１１１】ＩｎｆｏＦｒａｍｅ^ＴＭは主要測定項目、
同じ店舗の売上高の中で発生した変化の簡潔なステート
メントを提供し、そして同じ店舗の売上高、再モデル化
された店舗に関連した測定項目、および情報セットアッ
プ・ウィンドウ１３２の測定項目間の関係ディバイダの
中で以前に定義された測定項目の中で発生した変化につ
いての簡潔なステートメントを提供する。次に、Ｉｎｆ
ｏＦｒａｍｅ^ＴＭは主要測定項目、同じ店舗の売上高に
おける変化に対してグラフを含んだ説明を含んでいる。
ＩｎｆｏＦｒａｍｅ^ＴＭはその測定項目の結果を表わし
ているテキスト・データまたはグラフィック・データに
対するハイパーリンクを表わしている、測定項目に関連
付けられたＨＴＭＬの複数のインスタンスを含むことが
できる。

【０１１２】ここで図２０を参照すると、クライアント
・サブシステム１２を使ってＭｅｔａｄａｔａ^ＴＭ２５
を生成するための方法が「開始（ＳＴＡＲＴ）」１４０
から開始されて示されている。ステップ１４１において
ユーザがコンセプトを指定するステップ１４２において、ユーザはそのコンセプトに対
する１つまたはそれ以上の属性を指定する。

【０１１３】ステップ１４４において、クライアント・
サブシステム１２はデータ２４の中のテーブルのカラム
のリストをユーザに提供する。ステップ１４６におい
て、ユーザはすべての属性を１つのカラムに対してマッ
プする。ユーザはそのコンセプトおよび属性についての
テキストによる記述を提供することができる。ステップ
１４８において、ユーザはデータ・ウエアハウス２４の
内部のテーブルの中の１つのカラムに対して１つのイン
ジケータを「マッピング」することによって、１つまた
はそれ以上のインジケータを指定する。

【０１１４】ステップ１５０において、クライアント・
サブシステム１２は同様にインジケータをマップする目
的のために、カラムのリストをユーザに提供する。ステ
ップ１５２において、ユーザはマップされたインジケー
タに対する「メソッドのまとめ」を選択する。それはそ
のインジケータに対する値が集計される方法を指定す
る。システムは次の集計メソッドをサポートする。・加算・平均・最小値・最大値・カウント値・最後に入った期間・最初に入った期間

【０１１５】ステップ１５４において、ユーザは測定項
目の単位を選択し、そのインジケータが通貨であるかど
うかを指定する。ユーザはオプションとしてそのインジ
ケータについての複数のフォーム、そのインジケータの
値の変化を記述するための動詞（ｖｅｒｂ）、そのイン
ジケータをレポートするための精度およびそのインジケ
ータのテキストによる説明を指定することができる。ス
テップ１５６において、クライアント・サブシステム１
２はインジケータのカラムを備えているテーブルを属性
のカラムを備えているテーブルと結合させることができ
る。

【０１１６】ステップ１５８において、クライアント・
サブシステム１２はユーザが追加のコンセプトを入力し
たいかどうかを判定する。入力したい場合はステップ１
４２へ戻る。入力したくない場合はステップ１６０にお
いて終了する。前記の説明は本発明の概要である。以降
のセクションではさらにセクションに分割して本発明を
さらに詳しく説明する。

【０１１７】＜２．クライアント・サブシステム１２＞
クライアント・サブシステム１２が以下にさらに詳しく
説明される。図２１はクライアント・サブシステム１２
のさらに詳細のブロック図を示している。クライアント
・サブシステム１２は３つのサブシステムを含む。それ
らはユーザ・インターフェース（ＵＩ）１４０１、マネ
ージャ１４０２、およびサーバのＡＰＩ１４０３であ
る。その名前が意味するように、ユーザ・インターフェ
ースのサブシステム１４０１によってユーザ１４０５は
クライアント１２と対話することができる。この詳細の
レベルにおいては、ユーザ・インターフェース・サブシ
ステム１４０１はマネージャ１４０２とＡＰＩ１４０３
の両方のサービスを使うことがわかる。マネージャ１４
０２もサーバのＡＰＩ１４０３からのサービスを使用す
る。サーバのＡＰＩサブシステム１４０３はすべてのク
ライアント１２がＤＡＩサブシステム１４と行う対話を
要約する高レベルのＡＰＩを提供する。クライアント１
２をＤＡＩサブシステム１４との間のすべての通信はク
ライアント・サーバ・モジュール（ＣＳＭ）１４０４を
通じて送られる。このモジュールについては以下にさら
に説明される。

【０１１８】図２２は図２１のブロック図をさらに詳し
くしたレベルでの、クライアント・サブシステム１２の
ブロック図を示している。ユーザ・インターフェース・
サブシステム１４０１はユーザ１４０５に対して見える
プログラムの部分をすべて含んでいる。このサブシステ
ムは標準のＭＳ−Ｗｉｎｄｏｗｓスタイルのプログラム
として実装することができるので、そのインターフェー
スの内部のほとんどのユニットはウィンドウかあるいは
ダイアログ・ボックスのいずれかである。そのインター
フェースの中の各ウィンドウまたはダイアログ・ボック
スは１つのメイン・クラスを持ち、その挙動を以下に詳
細に示されるように定義する。いくつかのウィンドウま
たは対話クラスも他のユーティリティー・クラスを使用
する。それは適宜以下で定義される。

【０１１９】クライアント・サブシステム１２の中のコ
ントロールの「トップ・レベル」はアプリケーション・
オブジェクト１５１１である。アプリケーション・オブ
ジェクト１５１１はＭｉｃｒｏｓｏｆｔＦｏｕｎｄａ
ｔｉｏｎＣｌａｓｓ（ＭＦＣ）ライブラリのスタート
アップ・コードによって自動的に作られる。アプリケー
ション・オブジェクトは２つの主要な事項、すなわち、
ログインの検証およびメイン・フレームのウィンドウ表
示の機能を有する。複数ドキュメント・インターフェー
ス（ＭＤＩ）のアプリケーションの中のフレーム・ウィ
ンドウはメニュー、ツールバー、およびステータスバー
を所有し、そして子ウィンドウのオブジェクトを生成す
る。

【０１２０】ユーザ・ログイン・プロセスは２つのステ
ップから構成されている。それらはユーザからユーザ名
およびパスワードを得るステップと、それらをサーバの
ＡＰＩサブシステム１４０３のＣｏｎｎｅｃｔ関数に対
して送るステップである。サーバ３２に対して試みられ
た接続から、４つの可能な結果がある。・ログイン成功・ログイン失敗・ログインの失敗が多すぎる・サーバ３２から応答がない；ネットワーク・ダウン

【０１２１】ログインに失敗すると、ログイン・ダイア
ログが再表示され、そしてユーザ１４０５は自分の名前
および／またはパスワードを入力し直すことができる。
ある回数（クライアント１２でなく、サーバ３２によっ
て決められた回数）だけ失敗した後、サーバ３２は「失
敗が多すぎる」の結果を返し、クライアント１２のプロ
グラムはこの結果についてユーザ１４０５へ通知してか
ら脱出する。ネットワークまたはサーバがダウンした場
合、クライアント１２は「オフ・ライン」モードで立ち
上がり、それによってユーザ１４０５は保存されたＩｎ
ｆｏＦｒａｍｅ^ＴＭを見ることができるが、アナリスト
を生成または編集すること、あるいはＩｎｆｏＦｒａｍ
ｅ^ＴＭの作成要求を送ることはできない。

【０１２２】接続に成功したとき、アプリケーションは
メイン・フレームのウィンドウを表示する。接続に成功
した結果、ユーザ１４０５がアドミニストレータ（ＭＤ
ＴＡ）の特権を有するかどうかの指示が追加して返さ
れ、そうであった場合、そのフレーム・ウィンドウに通
知されて、特別のメニュー・アイテムがイネーブルされ
るようになる。アプリケーション・オブジェクト１５１
１は他のサブシステムの次の要求を行うことができる。

【０１２３】

【０１２４】アプリケーション・オブジェタト１５１１
はｃｌｎｔＡｐｐクラスのインスタンスである。それ
はｃｌｎｔＵｓｅｒＬｏｇｉｎＤｌｇおよびｃｌｎｔ
ＭａｉｎＦｒａｍｅのそれぞれについて１つのインス
タンスを生成する。クラスｃｌｎｔＡｐｐはＭＦＣの
クラスＣＷｉｎＡｐｐのサブクラスである。本発明はＣ
ＷｉｎＡｐｐの標準の挙動のほとんどを継承するが、Ｉ
ｎｉｔｌｎｓｔａｎｃｅ機能にオーバーライドし、その
中でユーザ・ログイン・プロセスを実行し、成功した場
合、自分のメイン・ウィンドウ、ｃｌｎｔＭａｉｎＦ
ｒａｍｅのインスタンスを作る。

【０１２５】ｃｌｎｔＭａｉｎＦｒａｍｅはＭＦＣの
クラスＣＭＤＩＦｒａｍｅＷｎｄのサブクラスである。
ツールバー、およびメニューを初期化するため、そして
初期マネージャ・ウインドウのインスタンス１５１２を
生成するために、ＯｎＣｒｅａｔｅ機能をオーバーライ
ドする。ｃｌｎｔＭａｉｎＦｒａｍｅインスタンスは
いくつかのメニューおよびツールバーの要求を扱い、一
方、他の要求はアクティブであるどれかの子ウィンドウ
（下記のように、４つのマネージャ・ウィンドウ１５１
２のうちの１つまたはＩｎｆｏＦｒａｍｅ^ＴＭのビュー
ワ・ウィンドウ１５１７）によって処理される。ｃｌｎ
ｔＭａｉｎＦｒａｍｅのインスタンスはどの子ウィン
ドウがアクティブであるかによって変わるメニュー・ア
イテムをイネーブル／ディスエーブルすることも担当す
る。

【０１２６】ユーザ・ログインのダイアログは、ＭＦＣ
のクラスＣＤｉａｌｏｇのサブクラスであるｃｌｎｔ
ＵｓｅｒＬｏｇｉｎＤｌｇクラスのインスタンスによっ
て制御される。ｃｌｎｔＵｓｅｒＬｏｇｉｎＤｌｇの
インスタンスはユーザに名前とパスワードを入力するよ
う求めるダイアログを表示する。その名前およびパスワ
ードの文字列はユーザが「ＯＫ」ボタンをクリックする
と、呼び出している関数へ返される。

【０１２７】Ｔｏｏｌｂａｒは、ＭＦＣのＣＴｏｏｌＢ
ａｒのサブクラスであるクラスｃｌｎｔＴｏｏ１Ｂａ
ｒのインスタンスによって制御される。ｌｎｔＴｏｏ
ｌＢａｒはＣＴｏｏｌＢａｒからのすべての機能を継承
し、そしてドラッグ・アンド・ドロップに対するサポー
トを追加する。ＣＴｏｏｌＢａｒのインスタンスは１つ
のフォルダのドロップ（Ｔｒａｓｈボタンの上への）、
１つまたはそれ以上のアナリスト（「ごみ箱（Ｔｒａｓ
ｈ）」、「即時実行（ＲｕｎＮｏｗ）」、または「表示
（Ｖｉｅｗ）」ボタンの上への）、および１つまたはそ
れ以上のＩｎｆｏＦｒａｍｅ^ＴＭ（「ごみ箱（Ｔｒａｓ
ｈ）、「表示（Ｖｉｅｗ）、および「プリント（Ｐｒｉ
ｎｔ）」ボタンの上への）を受け入れる。

【０１２８】情報定義１５１５はセグメント、測定項
目、および測定項目間の関係の追加、変更、または削除
に関連したすべての機能を含む。情報定義１５１５プロ
セスの中で３つのダイアログ・ボックスが使われる。そ
れは編集される情報の各タイプごとに１つずつある。そ
のダイアログはｃｌｎｔＭａｉｎＦｒａｍｅによってイ
ンスタンシエートされる次のクラスのインスタンスによ
って制御される（メニューまたはツールバーによるユー
ザ要求に応答して）。

【０１２９】ｃｌｎｔＢｕｉｌｄＭｅａｓｕｒｅＤｌ
ｇ。このダイアログによってユーザは既存の測定項目を
更新または削除すること、あるいは新しい測定項目を生
成することができる。ｃｌｎｔＢｕｉｌｄＳｅｇｍｅｎｔＤｌｇ。このダイ
アログによってユーザは既存のセグメントを更新または
削除するか、あるいは属性の制限を定義することによっ
て新しいセグメントを生成することができる。ｃｌｎｔＢｕｉｌｄＲｅｌａｔｉｏｎＤｌｇ。このダ
イアログによってユーザは既存のＭｅａｓｕｒｅＲｅ１
ａｔｉｏｎを更新または削除するか、あるいは新しい関
係を定義することができる。測定項目間の関係のダイアログは他のサブシステムから
の次のサービスを使用する。

【０１３０】

【０１３１】測定項目ダイアログは次のサービスを使用
する。

【０１３２】

【０１３３】セグメント・ダイアログは次のサービスを
使用する。

【０１３４】

【０１３５】情報セットアップのセクション１５１５は
次のクラス、すなわち、ｃｌｎｔＢｕｉｌｄＲｅｌａｔ
ｉｏｎｓｈｉｐＤｌｇ、同じくｃｌｎｔＢｕｉｌｄＭ
ｅａｓｕｒｅＤｌｇ、ｃｌｎｔＢｕｉｌｄＳｅｇｍｅ
ｎｔＤｌｇおよびｃｌｎｔＢｕｉｌｄＲｅｓｔｒｉｃｔ
Ｄｌｇ（すべてＭＦＣのＣＤｉａｌｏｇのサブクラス）
のインスタンスによって制御される。ユーザ１４０５が
プライベート・セグメントまたは測定項目を変更するこ
とを選択した場合、ｃｌｎｔＭｅａｓｕｒｅＤｅｆＤ
ｌｇおよびｃｌｎｔＳｅｇｍｅｎｔＤｅｆＤｌｇオブ
ジェクトは既存のアナリストおよびＩｎｆｏＦｒａｍｅ
^ＴＭのリストの中を縦覧することを担当し、そしてその
セグメントまたは測定項目が見つかった場合、そのオブ
ジェクトは次のアクションをとる。

【０１３６】削除の場合：・その削除によっていくつかのアナリストが正しく実行
されなくなることを示すメッセージがユーザ１４０５に
対して表示される。ユーザ１４０５にはこの削除によっ
て影響されるアナリストのリストが提示される。削除さ
れたセグメントまたは測定項目についてアナリストが実
行されると、エラー・メッセージが返される。Ｍｏｄｉｆｙ（変更）の場合：・最新のセグメント／測定項目定義が常に使われる。古
い定義は置き換えられる。ユーザの変更要求はＭｅｔａ
ｄａｔａ^ＴＭの即時更新のためにＤＡＩへ転送される
（サーバのＡＰＩサブシステムを通じて）。

【０１３７】アナリスト・ビルダのダイアログ・ボック
ス１５１３によってユーザ１４０５は特定のＩｎｆｏＦ
ｒａｍｅ^ＴＭを生成するのに必要なパラメータを選択す
る（下記参照）。また、それによってユーザ１４０５は
１つのアナリストに対するスケジューリングおよび／ま
たはトリガ条件の定義のオプションが可能となる。この
ことが起こるようにするために、メインのアナリスト・
ダイアログはユーザ１４０５がサブダイアログ、すなわ
ち、Ｍｃａｓｕｒｃ（測定項目）、Ｓｅｇｍｅｎｔｓ
（セグメント）ＴｉｍｅＳｌｉｃｅ（タイムスライ
ス）、Ｓｃｈｅｄｕｌｅ（スケジュール）、およびＴｒ
ｉｇｇｅｒ（トリガ）を完了するよう催促する。ユーザ
・インターフェース・サブシステム１４０１の他の部分
（すなわち、メニュー、ツールバー、またはマネージャ
・ウィンドウ）はアナリスト・ビルダのダイアログ１５
１３を呼出す。それはビュー／編集のために既存のアナ
リスト・オブジェクトをそれに渡すか、あるいはＮＵＬ
Ｌパラメータを渡して新しいアナリストが生成されるべ
きであることを示すかのいずれかによって行われる。

【０１３８】ユーザ１４０５が新しいアナリストを「Ｓ
ａｖｅ（保存）」または「ＳａｖｅＡｓ（名前をつけて
保存）」を既存のアナリストの上で要求するとき、ｃｌ
ｎｔＡｎａｌｙｓｔＳｈｅｅｔダイアログはｃｌｎｔ
ＩｎｆｏＦｒａｍｅＲｅｑｕｅｓｔオブジェクトをイ
ンスタンシエートする。ｃｌｎｔＡｎａｌｙｓｔＳｈ
ｅｅｔダイアログは次の要求を他のサブシステムに対し
て行う。

【０１３９】

【０１４０】ｃｌｎｔＡｎａｌｙｓｔＳｈｅｅｔクラ
スは次のクラス、すなわち、ｃｌｎｔＡｎａｌｙｓｔ
ＭｅａｓｕｒｅＰａｇｅ、ｃｌｎｔＡｎａｌｙｓｔＳ
ｅｇｍｅｎｔＰａｇｅ、ｃｌｎｔＡｎａｌｙｓｔＴｉ
ｍｅＳｌｉｃｅＰａｇｅ、ｃｌｎｔＡｎａｌｙｓｔＳ
ｃｈｅｄｕｌｅＰａｇｅ、ｃｌｎｔＡｎａｌｙｓｔＴ
ｒｉｇｇｅｒＰａｇｅ（すべてＭＦＣのＣＰｒｏｐｅｒ
ｔｙＰａｇｅのサブクラス）のサブダイアログをインス
タンシエートする。これらはユーザ１４０５が順番に導
かれるメイン・ダイアログ・ボックスの中の５つのパネ
ルに対応する。また、アナリスト・サブシステム１５１
３はｃｌｎｔＭｅｔａＴｒｅｅクラスおよびｃｌｎｔ
ＭｅａｓｕｒｅＭａｐクラスを使用する。それらはＭ
ｅｔａｄａｔａ^ＴＭのＡＰＩを通してＭｅｔａｄａｔｅ
テーブルに対するアクセスを提供する。

【０１４１】ｃｌｎｔＡｎａｌｙｓｔＳｈｅｅｔサブ
ダイアログはユーザ１４０５のアナリスト・タイプの選
択にしたがって適切なコントロールで動的に埋められ
る。このダイアログ・インターフェースからのユーザ入
力はｃｌｎｔＩｎｆｏＦｒａｍｅＲｅｑｕｅｓｔオブ
ジェクトの中に保存され、そして保存されるべきマネー
ジャ・サブシステムへ返される（また、スケジュールが
存在する場合は、スケジューリングに対してサブミット
される − スケジューラ・サブシステム１８のさらに
詳細に関しては下記参照）。ｃｌｎｔＡｎａｌｙｓｔ
ＭｅａｓｕｒｅＰａｇｅは次の要求を他のサブシステム
に対して行う。

【０１４２】

【０１４３】ｃｌｎｔＡｎａｌｙｓｔＳｃｇｍｅｎｔ
Ｐａｇｅは次の要求を他のサブシステムに対して行う。

【０１４４】

【０１４５】ｃｌｎｔＡｎａｌｙｓｔＴｉｍｅＳｌｉ
ｃｅＰａｇｅは次の要求を他のサブシステムに対して行
う。

【０１４６】

【０１４７】ｃｌｎｔＡｎａｌｙｓｔＳｃｈｅｄｕ１
ｅＰａｇｅは次の要求を他のサブシステムに対して行
う。

【０１４８】

【０１４９】ｃｌｎｔ＿ＡｎａｌｙｓｔＴｒｉｇｇｅｒ
Ｐａｇｅは次の要求を他のサブシステムに対して行う。

【０１５０】

【０１５１】次は各ＩｎｆｏＦｒａｍｅ^ＴＭのタイプに
対するユーザ入力条件のリストである。（Ｒ＝必要、Ｏ
＝オプション）ｃｌｎｔ＿ＭｅａｓｕｒｅＤｌｇ：

【０１５２】

【０１５３】ｃｌｎｔ＿ＳｅｇｍｅｎｔＤｌｇ：

【０１５４】

【０１５５】ｃｌｎｔ＿ＴｉｍｅＳｌｉｃｅＤｌｇ：

【０１５６】

【０１５７】ＩｎｆｏＦｒａｍｅ^ＴＭのビューワ・ウィ
ンドウ１５１７は画面上にＩｎｆｏＦｒａｍｅ^ＴＭを表
示する（下記参照）。ＩｎｆｏＦｒａｍｅ^ＴＭのデータ
を表示すること以外に、ビューワ１５１７はユーザ１４
０５に対して「ホット・スポット」を提示することによ
って「ドリル・ダウン」機能をサポートし、そしてホッ
ト・スポットが選択されたときに適切な要求を発生す
る。また、ＩｎｆｏＦｒａｍｅ^ＴＭのビューワはＩｎｆ
ｏＦｒａｍｅ^ＴＭをアノテートするための機能をユーザ
に提供する。ＩｎｆｏＦｒａｍｅ^ＴＭビューワ１５１７
が生成されると、それはＩｎｆｏＦｒａｍｅ^ＴＭのファ
イルの名前およびそのＩｎｆｏＦｒａｍｅ^ＴＭのオブジ
ェクトに対するポインタを受け取る。このデータはパー
スされ（さらに、埋め込まれたデータからグラフを作成
するなどの処理も行われ）、その後、表示される。

【０１５８】ＩｎｆｏＦｒａｍｅ^ＴＭのビューワ・モジ
ュール１５１７の中のパーサの機能はＳａｖｅＡｓ要求
に対しても使われる。生のＩｎｆｏＦｒａｍｅ^ＴＭデー
タが標準のＨＴＭＬデータに変換され（すなわち、ＭＤ
Ｔ固有のグラフ・データが標準フォーマットのグラフィ
ック・イメージに変換される）、そしてＡＳＣＩＩまた
はユニコード文字のいずれかでファイルに書き込まれ
る。ＩｎｆｏＦｒａｍｅ^ＴＭのビューワ・ウィンドウ１
５１７はＩｎｆｏＦｒａｍｅ^ＴＭのプリント機能もサポ
ートする。この機能はＭＦＣのＣＤｏｃｕｍｅｎｔおよ
びＣＳｃｒｏｌｌＶｉｅｗクラスによって提供される機
能に基づいて作られる。ＩｎｆｏＦｒａｍｅ^ＴＭのビュ
ーワ・サブシステム１５１７は次の要求を他のサブシス
テムに対して行う。

【０１５９】

【０１６０】パーサ（Ｐｅｒｓｅｒ）：ｃｌｎｔ＿Ｐａ
ｒｓｅｒクラスは次の３つの機能によってクライアント
１２に対してＨＴＭＬのパース機能を提供する。

【０１６１】

【０１６２】ビューワ（Ｖｉｅｗｅｒ）：ビューワはＭ
ＦＣのドキュメント／ビューのアーキテクチャーを使っ
て実装される。クラスｃｌｎｔ＿ＶｉｅｗｅｒはＣＳｃ
ｒｏｌｌＶｉｅｗ（ＭＦＣ）のサブクラスである。この
クラスは自動スクロールを提供する。クラスｃｌｎｔ＿
ＰａｒｓｅｒＤｏｃはＣＤｏｃｕｍｅｎｔのサブクラス
である。生成時に、それはｃｌｎｔ＿Ｐａｒｓｅｒオブ
ジェクトをインスタンシエートしてそのＨＴＭＬデータ
をパースする。次に、ｃｌｎｔ＿Ｖｉｅｗｅｒはその返
されたｃｌｎｔ＿Ｔａｇオブジェクトのリストを縦覧
し、それぞれの視覚表現をウィンドウの中に置く。

【０１６３】次のコントロールの集合がユーザ・インタ
ーフェース・サブシステム１４０１によって使われる。ｃｌｎｔ＿ＴｒｅｅＣｔｒｌＭＦＣのＣＴｒｅｅＣｔ
ｒｌからではなく、このクラスからのセグメントおよび
／パーティションの継承を表わしているすべてのダイア
ログ・コントロール。また、ｃｌｎｔ＿ＭｅｔａＴｒｅ
ｅコントロールもこのクラスから継承する。ｃｌｎｔ＿ＭｅｔａＴｒｅｅこのコントロールは階層
的なフォーマットでＭｅｔａｄａｔａ^ＴＭのセグメント
およびパーティションを表わすために使われる。次のダ
イアログはこのコントロールのサブクラスである。：ｃ
ｌｎｔＡｎａｌｙｓｔＳｅｇｍｅｎｔＰａｇｅ、ｃｌ
ｎｔ＿ＢｕｉｌｄＳｅｇｍｅｎｔＤｌｇ、ｃｌｎｔ＿Ｒ
ｅｓｔｒｉｃｔＭｅａｓｕｒｅＤｌｇ。

【０１６４】ｃｌｎｔ＿ＴｏｐＬｅｖｅｌＳｅｇｍｅｎ
ｔＣｏｍｂｏこのコントロールはドロップダウン・コ
ンボボックスの中のすべてのＭｅｔａｄａｔａ^ＴＭのト
ップ・レベルのセグメントを表わすために使われる。次
のダイアログはこのコントロールのサブクラスであ
る。：ｃｌｎｔ＿ＡｎａｌｙｓｔＳｅｇｍｅｎｔＰａｇ
ｃ、ｃｌｎｔ＿ＢｕｉｌｄＳｅｇｍｅｎｔＤｌｇ、ｃｌ
ｎｔ＿ＲｅｓｔｒｉｃｔＭｅａｓｕｒｅＤｌｇ。ｃｌｎｔ＿ＤｕｒａｔｉｏｎＣｏｍｂｏこのコントロ
ールはドロップダウン・コンボボックスのフォーマット
でのユーザの条件付き演算子の選択項目を表わす。次の
ダイアログはこのコントロールのサブクラスである。：
ｃｌｎｔ＿ＡｎａｌｙｓｔＰｅｒｉｏｄＰａｇｅ、ｃｌ
ｎｔ＿ＡｎａｌｙｓｔＳｃｈｅｄｕｌｅＰａｇｅ。

【０１６５】ｃｌｎｔ＿ＯｐｅｒａｔｏｒＣｏｍｂｏ
このコントロールはドロップダウン・コンボボックスの
フォーマットでのユーザの条件付き演算子の選択項目を
表わす。次のダイアログはこのコントロールのサブクラ
スである。：ｃｌｎｔ＿ＡｎａｌｙｓｔＰｅｒｉｏｄＰ
ａｇｅ、ｃｌｎｔ＿ＡｎａｌｙｓｔＳｃｈｅｄｕｌｅＰ
ａｇｅ。ｃｌｎｔ＿ＤａｔｅＥｄｉｔこのコントロールはロー
カルの日付を表わすために使われる。それはユーザの入
力をチェックし、その日付をそのローカルに適切な日付
にフォーマットする。次のダイアログはこのコントロー
ルのサブクラスである。：ｃｌｎｔ＿ＡｎａｌｙｓｔＰ
ｅｒｉｏｄＰａｇｅ、ｃｌｎｔ＿ＡｎａｌｙｓｔＳｃｈ
ｅｄｕｌｅＰａｇｅ。ｃｌｎｔ＿ＲｅａｄＯｎｌｙＬｉｓｔＢｏｘこのコン
トロールは非選択のリストボックスのために使われる。
他のサブクラスからの依存性はない。次のダイアログは
このこのコントロールのサブクラスである。：ｃｌｎｔ
＿Ｂｕｉ１ｄＳｅｇｍｅｎｔＤｌｇ。ｃｌｎｔ＿ＭｅｔａＴｒｅｅコントロールは他のサブシ
ステムからの次のサービスを使用する。

【０１６６】

【０１６７】ｃｌｎｔ＿ＴｏｐＬｅｂｅｌＳｅｇｍｅｎ
ｔＣｏｍｂｏは他のサブシステムからの次のサービスを
使用する。

【０１６８】

【０１６９】ｃｌｎｔ＿ＭｅａｓｕｒｅＣｏｍｂｏは他
のサブシステムからの次のサービスを使用する。

【０１７０】

【０１７１】アドミニストレータ用インターフェース１
５１６は２つのタスク、すなわち、ユーザ・アカウント
・セットアップ、およびＭｅｔａｄａｔａ^ＴＭビルダか
ら構成される。ユーザ・アカウント・セットアップのダ
イアログによって、ＭＤＴＡ（アドミニストレータ）は
ログイン名、パスワード、およびユーザ・タイプを含む
ユーザ・アカウントを生成して管理することができる。
Ｍｅｔａｄａｔａ^ＴＭビルダによって、ＭＤＴＡはディ
メンション、属性、および基本測定項目を定義するこ
と、セグメントを生成すること、時刻値に対してカラム
をマップすること、および年のタイプを定義することが
できる。ユーザ・アカウントの画面はサーバのＡＰＩサ
ブシステムからのｃｌｎｔ＿ＵｓｅｒＬｏｇｉｎクラス
を利用する。Ｍｅｔａｄａｔａ^ＴＭビルダの画面はサー
バのＡＰＩサブシステム１４０３によって提供されるほ
とんどすべてのＭｅｔａｄａｔａ^ＴＭ機能を利用する。
これはｃｌｎｔ＿Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ、Ｃｌ
ｎｔ＿Ｄｉｍｅｎｓｉｏｎ、ｃｌｎｔ＿Ａｔｔｒｉｂｕ
ｔｅ、ｃｌｎｔ＿ＢａｓｉｃＭｅａｓｕｒｅおよびｃｌ
ｎｔ＿Ｓｅｇｍｅｎｔの各クラスのサービスを含む。ま
た、それはデータ・ウェアハウスのスキーマにアクセス
するためにｃｌｎｔ＿Ｓｃｈｅｍａクラスも使う。

【０１７２】ユーザ・アカウント・ダイアログはＭＦＣ
のサブクラスである、ｃｌｎｔ＿ＵｓｅｒＡｃｃｏｕｎ
ｔＤｌｇのインスタンスによって制御される。ｃｌｎｔ
＿ＵｓｅｒＡｃｃｏｕｎｔＤｌｇがシステムの他の部分
に対して提示するインターフェースは、ＣＤｉａｌｏｇ
オブジェクトに対する標準である。そのインターフェー
スが構築された後、ＤｏＭｏｄａｌ（）が呼び出されて
そのダイアログを表示する。ＤｏＭｏｄａｌに対する呼
出しは、ユーザ１４０５が「キャンセル」または「クロ
ーズ」のボタンを押したときだけ戻る。

【０１７３】Ｍｅｔａｄａｔａ^ＴＭビルダのダイアログ
は「ウイザード」スタイルのダイアログである。これ
は、それが所定の順序での一連のサブダイアログを提示
することを意味する。ユーザ１４０５は「次へ」および
「戻る」のボタンを押してサブダイアログのリストを縦
覧することができ、「キャンセル」を押してＭｅｔａｄ
ａｔａ^ＴＭビルダから脱出することができる。そのウィ
ザードの「フレーム」はＭＦＣのＣＰｒｏｐｅｒｔｙＳ
ｈｅｅｔのサブクラスである、クラスｃｌｎｔ＿Ｍａｓ
ｔｅｒＳｅｔｕｐによって実装される。ｃｌｎｔ＿Ｍａ
ｓｔｅｒＳｅｔｕｐのコンストラクタは各ダイアログ
「ページ」（ｃｌｎｔ＿ＡｔｔｒｉｂｕｔｅＤｅｆｉｎ
ｉｔｉｏｎ、ｃｌｎｔ＿ＡｔｔｒｉｂｕｔｅＭａｐｐｉ
ｎｇ、ｃｌｎｔ＿ＡｔｔｒｉｂｕｔｃＶａｌｕｅＤｅｆ
ｉｎｉｔｉｏｎ、ｃｌｎｔ＿ＡｕｔｏｍａｔｉｃＳｅｇ
ｍｅｎｔｓ、ｃｌｎｔ＿ＢａｓｉｃＭｅａｓｕｒｅＤｅ
ｆｉｎｉｔｉｏｎ、ｃｌｎｔ＿ＢａｓｉｃＭｅａｓｕｒ
Ｍａｐ、ｃｌｎｔ＿ＤｉｍｅｎｓｉｏｎＤｅｆｉｎｉｔ
ｉｏｎ、ｃｌｎｔ＿Ｊｏｉｎｓ、ｃｌｎｔ＿ＴｉｍｅＤ
ｉｍｅｎｓｉｏｎ、ｃｌｎｔ＿ＹｅａｒＤｅｆｉｎｉｔ
ｉｏｎ）ごとに１つずつインスタンスを生成する。その
ページはそれが表示される時に「ウイザード」の中にロ
ードされる。これはＭｅｔａｄａｔａ^ＴＭビルダを単純
にコンストラクトしてそのインスタンス上でＤｏＭｏｄ
ａｌ（）を呼び出す他のクライアント・アプリケーショ
ン１２に対してはトランスペアレントである。

【０１７４】各「ページ」はサーバのＡＰＩ１４０３の
Ｍｅｔａｄａｔａ^ＴＭクラスに対する呼出しを通して、
その初期表示データをロードし、各ページはサーバのＡ
ＰＩ１４０３を通してそのデータを更新することによっ
て「保存」ボタンに対して応答する。ｃｌｎｔ＿Ｍａｓ
ｔｅｒＳｅｔｕｐは使用される各タイプのＭｅｔａｄａ
ｔａ^ＴＭに対する１つのリンク・リストを有している。
各リストは０個以上のｃｌｎｔ＿ＳｅｔｕｐＯｂｊｅｃ
ｔオブジェクトを含んでいる。ｃｌｎｔ＿ＳｅｔｕｐＯ
ｂｊｅｃｔオブジェクトは２つのデータ・メンバを含ん
でいる。１つはＣＯｂｊｅｃｔに対するポインタであ
り、もう１つはｃｌｎｔ＿ＯｂｊｅｃｔＳｔａｔｅエニ
ュメレーション（ｅｎｕｍｅｒａｔｉｏｎ）である。ｃ
ｌｎｔ＿Ｏｂｊｅｃｔｓｔａｔｅは４つの値、すなわ
ち、ＳＴＡＴＥ＿ＥＸＩＳＴＩＮＧ、ＳＴＡＴＥ＿ＮＥ
Ｗ、ＳＴＡＴＥ＿ＤＥＬＥＴＥＤ、ＳＴＡＴＥ＿ＭＯＤ
ＩＦＩＥＤのうちの１つを取ることができる。これらの
リンク・リストはすべての「ウィザード」で利用でき
る。ユーザ１４０５がＭｅｔａｄａｔａ^ＴＭオブジェク
トを追加、削除、または変更するたびに、そのオブジェ
クトは適切なリンク・リストに追加される。これらのリ
ンク・リストはどのオブジェクトをユーザ１４０５に対
して表示するか、そしてどのオブジェクトをユーザ１４
０５から隠すかを決定するために使われる。また、その
リンク・リストは「キャンセル」および「保存」のボタ
ンによっても使われる。ユーザ１４０５が「キャンセ
ル」ボタンを押すと、そのリンク・リストの中のすべて
のオブジェクトが削除される。ユーザ１４０５が「保
存」ボタンを押すと、そのリンク・リストの中のすべて
のオブジェクトがアクセスされる。エニュメレーション
の値がＳＴＡＴＥ＿ＥＸＩＳＴＩＮＧであった場合、そ
のオブジェクトはそのリストから削除される。その値が
ＳＴＡＴＥ＿ＮＥＷであった場合、そのオブジェクトは
サーバ上のＭｅｔａｄａｔａ^ＴＭに対して追加され、そ
してそのリストからは削除される。その値がＳＴＡＴＥ
＿ＤＥＬＥＴＥＤであった場合、そのオブジェクトはサ
ーバ上のＭｅｔａｄａｔａ^ＴＭから削除され、そしてリ
ストからも削除される。その値がＳＴＡＴＥ＿ＭＯＤＩ
ＦＩＥＤであった場合、そのオブジェクトはサーバ上の
Ｍｅｔａｄａｔａ^ＴＭの中で更新され、そしてそのオブ
ジェクトはリストから削除される。

【０１７５】「ウイザード」ページ上の「保存」ボタン
はオブジェクトをある順序で追加、削除、および変更す
る。オブジェクトを削除する場合、次の表は削除される
べきオブジェクトを左のカラムに、そして存在していた
場合にはクライアント１２上のリンク・リストから削除
される関連付けられたオブジェクトを右のカラムに示し
ている。左のカラムの中の行の順序はどのオブジェクト
が最初に削除、追加、または変更されるかを定義する。
ディメンションが最初に追加され、年の定義が最後に追
加される。オブジェクト関連付けられたオブジェクト

【０１７６】

【０１７７】ユーザがサーバ３４上のＭｅｔａｄａｔａ
^ＴＭ２５の中に既に存在するオブジェクトを削除する
と、そのオブジェクトだけが削除される。そのオブジェ
クトに対する「関係付けられたオブジェクト」はＤＡＩ
サブシステム１４によって削除される。マネージャ・ウ
ィンドウ１５１２はマネージャ・サブシステム１４０２
によって記憶されているすべてのタイプのデータ（すな
わち、ペンディングのＩｎｆｏＦｒａｍｅ^ＴＭに関する
情報以外に、フォルダ、アナリスト、およびＩｎｆｏＦ
ｒａｍｅ^ＴＭに対するアクセスを、ユーザ１４０５に提
供する。

【０１７８】４種類のマネージャ・ウィンドウ１５１２
があり、それぞれが次のように、このデータの異なるビ
ューを提供している。・アナリスト・リスト（すべてのアナリストのフラット
なリスト）・ＩｎｆｏＦｒａｍｅ^ＴＭのリスト（すべてのＩｎｆｏ
Ｆｒａｍｅ^ＴＭのフラットなリスト）・フォルダ・ビュー（フォルダの階層を含む；現在のフ
ォルダの中のＩｎｆｏＦｒａｍｅ^ＴＭおよびアナリスト
を示す）・ペンディングのキュー（ＤＡＩ１４の中で現在ペンデ
ィングになっているＩｎｆｏＦｒａｍｅ^ＴＭのフラット
なリスト）

【０１７９】ペンディングのキュー・ウィンドウは他の
３つのマネージャ・ウィンドウと一緒に含まれているこ
とに留意されたい。というのはコンストラクションおよ
びインターフェースの挙動が類似しているからである。
それが表示するデータは実際には他の３つのウィンドウ
のデータとはかなり異っている。ドラッグ・アンド・ド
ロップの機能もマネージャ・ウィンドウ１５１２によっ
てサポートされる。アナリストのリスト、ＩｎｆｏＦｒ
ａｍｅ^ＴＭのリスト、およびフォルダ・ビューも「ドラ
ッグ」操作のソースとなり得る（ユーザは１つのフォル
ダ、１つまたはそれ以上のアナリスト、あるいは１つま
たはそれ以上のＩｎｆｏＦｒａｍｅ^ＴＭをドラッグする
ことができる）。フォルダ・ビューは「ドラッグ」操作
のデスティネーションともなり得る。

【０１８０】最初の３つのマネージャ・ウィンドウ・タ
イプ（アナリストのリスト、ＩｎｆｏＦｒａｍｅ^ＴＭの
リスト、フォルダ・ビュー）は他のサブシステムからの
次のサービスを使用する。

【０１８１】

【０１８２】第４のマネージャ・ウィンドウ、「ペンデ
ィング・キュー」は他のサブシステムからの次のサービ
スを使用する。

【０１８３】

【０１８４】４つの各マネージャ・ウィンドウ１５１２
は１つの「フレーム」オブジェクトとその「フレーム」
の内部に置かれた１つまたはそれ以上の「コントロー
ル」オブジェクトによって制御される。４つのすべての
ケースにおいて、「フレーム」は１つだけのクラス、ｃ
ｌｎｔ＿ＭａｎａｇｅｒＷｎｄ（ＭＦＣからのＣＭＤＩ
ＣｈｉｌｄＷｎｄのサブクラス）によって表される。ｃ
ｌｎｔ＿ＭａｎａｇｅｒＷｎｄオブジェクトはそれがど
の「コントロール」オブジェクトを構築すべきかを示す
ために、インスタンシエーション時にパラメータ化され
る。そのサブクラスが示唆するように、それは標準のＭ
ＤＩの子ウィンドウとして振る舞う。

【０１８５】フレーム・ウィンドウの中の「コントロー
ル」オブジェクトはＭＦＣのクラスから継承し、それは
また、標準のＭＳ−Ｗｉｎｄｏｗｓのコントロールに対
するラッパー（ｗｒａｐｐｅｒ）である。クラスｃｌｎ
ｔ＿ＡｎａｌｙｓｔＣｔｒｌ、ｃｌｎｔ＿ＩｎｆｏＦｒ
ａｍｅＣｔｒｌ、ｃｌｎｔ＿ＰｅｎｄｉｎｇＣｔｒｌは
それぞれＣＬｉｓｔＣｔｒｌから継承し、「カラム型
の」リストの中のそれぞれのデータを表示する。クラス
ｃｌｎｔ＿ＦｏｌｄｅｒＣｔｒｌはＣＴｒｅｅＣｔｒｌ
から継承してＭＤＴフォルダのツリー状の階層を表示す
る。これらのクラスはそれが受け取る「ｓｔｙｌｅ（ス
タイル）」フラグに依存して、ｃｌｎｔ＿Ｍａｎａｇｅ
ｒＷｎｄによって、必要に応じて、インスタンシエート
される。すなわち、ｃｌｎｔ＿ＡｎａｌｙｓｔＣｔｒｌ
はＡＮＡＬＹＳＴＳモードおよびＦＯＬＤＥＲＳモード
において使われ、ｃｌｎｔ＿ＩｎｆｏＦｒａｍｅＣｔｒ
ｌはＩＮＦＯＦＲＡＭＥＳおよびＦＯＬＤＥＲのモード
において使われ、ｃｌｎｔ＿ＦｏｌｄｅｒＣｔｒｌはＦ
ＯＬＤＥＲＳモードにおいて、そしてｃｌｎｔ＿Ｓａｖ
ｅＡｓダイアログ・ボックス（アナリスト・ビルダの一
部）によって使われ、ｃｌｎｔ＿ＰｅｎｄｉｎｇＣｔｒ
ｌはＰＥＮＤＩＮＧモードにおいて使われる。ユーザ１
４０５がドラッグ・アンド・ドロップ操作を開始する
と、そのドラッグのソース・ウィンドウがｃｌｎｔ＿Ｄ
ｒａｇＷｎｄのインスタンスを構築する。その後、その
インスタンスがドラッグ・アンド・ドロップの残りを制
御する。ｃｌｎｔ＿ＤｒａｇＷｎｄにはドラッグ中のオ
ブジェクトまたはオブジェクトのリストに対するポイン
タおよび、ドラッグ中のオブジェクトのタイプを示す情
報が与えられる。次に、それはカーソルが通過する任意
のウィンドウに対して、そのウィンドウ上にそのオブジ
ェクトをドロップしてもよいかどうかを尋ねるメッセー
ジを送信する。ドロップをサポートするウィンドウはｃ
ｌｎｔ＿ＦｏｌｄｅｒＣｔｒｌおよびｃｌｎｔ＿Ｔｏｏ
ｌｂａｒである（セクション３．２．３参照）。ユーザ
１４０５がマウス２１のボタンを解放すると、ｃｌｎｔ
＿ＤｒａｇＷｎｄはドロップされるアイテムを受け入れ
るよう要求するメッセージをデスティネーション・ウィ
ンドウに対して送信し、また、ドロップが完了したこと
を示すメッセージをソース・ウィンドウに対して送信す
る。

【０１８６】マネージャ・サブシステム１４０２はフォ
ルダ１００の階層の操作、格納、および検索、そしてそ
れらのフォルダの中に格納されているＩｎｆｏＦｒａｍ
ｅ^ＴＭおよびアナリストに関連したすべての機能を処理
する。このデータを格納および検索することに関連した
すべての機能がマネージャ・サブシステム１４０２の中
にカプセル化されているので、本発明の代替実施形態に
おいてフォルダ／ＩｎｆｏＦｒａｍｅ^ＴＭ／アナリスト
のデータ記憶がサーバ階層３２上に移動した場合でも、
他のクライアント・サブシステム上でのインパクトは最
小限で済む。

【０１８７】図２２から分かるように、マネージャ１４
０２は４つのＡＰＩ、すなわち、マネージャ１５２１、
フォルダ１５２２、アナリスト１５２３、およびＩｎｆ
ｏＦｒａｍｅ^ＴＭ１５２４を提供する。これらのＡＰＩ
は次のセクションで説明される４つのクラスに対応す
る。マネージャ・サブシステム１５２１の中のメイン・
クラスはｃｌｎｔ＿Ｍａｎａｇｅｒクラスである。３つ
のデータ・オブジェクト・クラス、すなわち、ｃｌｎｔ
＿Ｆｏｌｄｅｒ、ｃｌｎｔ＿ＩｎｆｏＦｒａｍｅＲｅｑ
ｕｅｓｔ、およびｃｌｎｔ＿ＩｎｆｏＦｒａｍｅ^ＴＭは
ｃｌｎｔ＿Ｍａｎａｇｅｒによって、そして他のサブシ
ステムによって使われる。マネージャの機能に対するア
クセスは普通は、フォルダ、アナリスト、またはＩｎｆ
ｏＦｒａｍｅ^ＴＭのリストを要求する、ｃｌｎｔ＿Ｍａ
ｎａｇｅｒ自身に対する呼出しから開始される。これら
のクエリーによって返されたオブジェクトは、次に、見
るためおよび／または操作するためにユーザ１４０５に
対して表示されるようにすることができる。そのデータ
・オブジェクトのどれかに対する変更の要求はｃｌｎｔ
＿Ｍａｎａｇｅｒを通過する。ｃｌｎｔ＿Ｍａｎａｇｅ
ｒはディスク上へのその変更の格納を扱い、そして適用
される場合はサーバのＡＰＩサブシステム１４０３に対
するその変更の送信を処理する。

【０１８８】また、マネージャ・サブシステム１４０２
は「ＴｒａｓｈＢｉｎ（ごみ箱）」の機能も提供する。
すなわち、アナリストまたはＩｎｆｏＦｒａｍｅ^ＴＭを
削除する要求が受信されると、そのオブジェクトはごみ
箱の中に置かれ、次のＥｍｐｔｙＴｒａｓｈ（ごみ箱を
空にする）コマンドが受信されるまでは実際には削除さ
れない。ＴｒａｓｈＢｉｎはクライアント１２のセッシ
ョン間で継続性がある。ＴｒａｓｈＢｉｎはｃｌｎｔ＿
Ｆｏｌｄｅｒクラスの１つのインスタンスとして実装さ
れている。

【０１８９】クライアント・アプリケーションの中には
ｃｌｎｔ＿Ｍａｎａｇｅｒクラスのインスタンス１５２
１が正確に１つだけある。インスタンスが必ず１つだけ
生成されるようにするために、そしてそれがグローバル
に安全に利用できるようにするために、このクラスは
「シングルトン（Ｓｉｎｇｌｅｔｏｎ）」設計パターン
（ガンマ（Ｇａｍｍａ）ほかによる「設計パターン：再
使用可能なオブジェクト指向のソフトウェアの要素」Ａ
ｄｄｉｓｎ−Ｗｅｓｌｅｙ、１９９５、ＩＳＢＮ０−２
０１−６３３６１−２の中で説明されているような）を
使用する。この設計パターンの中で、そのクラスは自分
自身の１つのインスタンスに対するポインタを返すスタ
ティック・メンバー関数を提供する。その関数は初めて
それが呼び出されたときに、そのインスタンスを自動的
に生成する。そのクラスのコンストラクタはプロテクト
されるので、そのクラスがどこか他の場所では決してイ
ンスタンシエートされないことが保証される。

【０１９０】ｃｌｎｔ＿Ｍａｎａｇｅｒクラスは他のサ
ブシステムからの次の要求を処理する。

【０１９１】

【０１９２】ｃｌｎｔ＿Ｍａｎａｇｅｒオブジェクトは
他のサブシステムからの次のサービスを使用する。

【０１９３】

【０１９４】クラスｃｌｎｔ＿Ｆｏｌｄｅｒのインスタ
ンス１５２２はｃｌｎｔ＿Ｍａｎａｇｅｒオブジェクト
によってのみインスタンシエートおよび削除される。他
のサブシステムはｃｌｎｔ＿ＭａｎａｇｅｒのＧｅｔＲ
ｏｏｔＦｏｌｄｅｒ（）またはＧｅｔＴｒａｓｈＢｉｎ
（）関数から開始してｃｌｎｔ＿Ｆｏｌｄｅｒインスタ
ンスに対するアクセスを得る。ｃｌｎｔ＿Ｆｏｌｄｅｒ
オブジェクトは他のサブシステムからの次の要求を処理
する。

【０１９５】

【０１９６】クラスｃｌｎｔＩｎｆｏＦｒａｍｅＲｅ
ｑｕｅｓｔのインスタンス１５２３がｃｌｎｔ＿Ｍａｎ
ａｇｅｒオブジェクトによって（保存されたアナリスト
をディスクから復元するとき）、そしてｃｌｎｔ＿Ａｎ
ａｌｙｓｔＢｕｉｌｄｅｒダイアログ・クラスによって
（新しいアナリストを生成する時または、現在のアナリ
ストにおいてＳａｖｅＡｓを実行する時）生成される。
他のサブシステムは普通はアナリスト・オブジェクトを
それぞれのフォルダ（ｃｌｎｔ＿Ｆｏｌｄｅｒ：：Ｇｅ
ｔＡｎａｌｙｓｔｓ（））から検索することによって、
アナリスト・オブジェクトにアクセスする。ｃｌｎｔ＿
ＩｎｆｏＦｒａｍｅＲｅｑｕｅｓｔのインスタンスはｃ
ｌｎｔ＿Ｍａｎａｇｅｒオブジェクトによってのみ削除
される。ｃｌｎｔ＿ＩｎｆｏＦｒａｍｅＲｅｑｕｅｓｔ
クラスは他のサブシステムからの次の要求を処理する。

【０１９７】

【０１９８】ｃｌｎｔ＿ＩｎｆｏＦｒａｍｅＲｅｑｕｅ
ｓｔクラスは３つのヘルパー・クラスを通じてその仕事
のほとんどを行う。ｃｌｎｔ＿ＦｒａｍｅＤｅｆｉｎｉ
ｔｉｏｎクラスはこのアナリストが実行される（あるい
はスケジュールされる）時に送信されるＩｎｆｏＦｒａ
ｍｅ^ＴＭ作成要求の記述を格納する。ｃｌｎｔ＿Ｆｒａ
ｍｅＤｅｆｉｎｉｔｉｏｎクラスは他のサブシステムか
らの次の要求を処理する。

【０１９９】

【０２００】ｃｌｎｔＩｎｆｏＦｒａｍｅＴｉｍｅＳ
ｌｉｃｅクラスは他のサブシステムからの次の要求を処
理する。

【０２０１】

【０２０２】ｃｌｎｔＩｎｆｏＦｒａｍｅＳｃｈｅｄ
ｕｌｅクラスはそのアナリストに対するスケジュールの
定義を格納する。ｃｌｎｔＩｎｆｏＦｒａｍｅＳｃｈ
ｅｄｕｌｅクラスは他のサブシステムからの次の要求を
処理する。

【０２０３】

【０２０４】ｃｌｎｔＩｎｆｏＦｒａｍｅＴｒｉｇｇ
ｅｒクラスはその分析が実行される前にチェックされる
べき条件の定義を処理する。ｃｌｎｔＩｎｆｏＦｒａ
ｍｅＴｒｉｇｇｅｒクラスは他のサブシステムからの次
の要求を処理する。

【０２０５】

【０２０６】クラスｃｌｎｔｔｒｉｇｇｅｒは単独の
トリガ条件を含んでいる。ｃｌｎｔｔｒｉｇｇｅｒオブ
ジェクトのリストはＡＮＤが取られ、単独のトリガとし
て定義される。ｃｌｎｔｔｒｉｇｇｅｒクラスは他の
サブシステムからの次の要求を処理する。

【０２０７】

【０２０８】ｃｌｎｔＩｎｆｏＦｒａｍｅＲｅｑｕｅ
ｓｔの各インスタンス１５２３は１つのｃｌｎｔＩｎ
ｆｏＦｒａｍｅＤｅｆｉｎｉｔｉｏｎオブジェクトを持
っていなければならない。ｃｌｎｔＩｎｆｏＦｒａｍ
ｅＳｃｈｅｄｕｌｅおよびｃｌｎｔＴｒｉｇｇｅｒの
オブジェクトはオプションである。クラスｃｌｎｔＩ
ｎｆｏＦｒａｍｅ^ＴＭのインスタンス１５２４はｃｌｎ
ｔＭａｎａｇｅｒオブジェクトによってインスタンシエ
ートされる（保存されたアナリストをディスクから復元
する時、または新しいフレームをサーバのＡＰＩから受
け取った時）。他のサブシステムは普通はそれぞれのフ
ォルダからそれらを検索することによって（ｃｌｎｔ
Ｆｏｌｄｅｒ：：ＧｅｔＩｎｆｏＦｒａｍ
ｅ^ＴＭ（））、ＩｎｆｏＦｒａｍｅ^ＴＭオブジェクトに
アクセスする。ｃｌｎｔＩｎｆｏＦｒａｍｅ^ＴＭのイン
スタンスはｃｌｎｔＭａｎａｇｅｒオブジェクトによ
ってのみ削除される。ｃｌｎｔＩｎｆｏＦｒａｍｅ
^ＴＭクラスは他のサブシステムからの次の要求を処理す
る。

【０２０９】

【０２１０】サーバのＡＰＩサブシステム１４０３はＭ
ＤＴサーバ３２（ＤＡＩ１４）との通信を必要とするす
べての関数をカプセル化する。これはユーザ・インター
フェース１４０１およびフォルダ・マネージャ１４０２
をクライアント−サーバ・インターフェースについての
知識から隔離し、それらが小変更によっては影響されな
いようにする。図２２から分かるように、サーバのＡＰ
Ｉ１４０３は４つのＡＰＩモジュール、すなわち、Ｍｅ
ｔａｄａｔａ^ＴＭ１５３１、ＩｎｆｏＦｒａｍｅ^ＴＭ作
成１５３２、データ・ウェアハウス１５３３、およびセ
ッション・マネージメント１４０３に分けることができ
る。また、サーバのＡＰＩサブシステム１４０３はＣＳ
Ｍ１４０４に対して通信するための一組の内部ルーチン
も含んでいる。それらは４つのＡＰＩによって共有され
ている。各モジュールについて以下に説明する。

【０２１１】Ｍｅｔａｄａｔａ^ＴＭのＡＰＩ１５３１は
ＭＤＴのＭｅｔａｄａｔａ^ＴＭ２５の一部分を表示した
り変更したりするためのクライアント１２のすべての要
求を処理する。この場合もＭｅｔａｄａｔａ^ＴＭ２５は
サーバ３４上に常駐し、クライアント１２は必要に応じ
てＤＡＩ１４経由で、Ｍｅｔａｄａｔａ^ＴＭ２５の部分
を検索する。Ｍｅｔａｄａｔａ^ＴＭのＡＰＩ１５３１は
他のクライアント・サブシステムに対して次のサービス
を提供する。

【０２１２】

【０２１３】Ｍｅｔａｄａｔａ^ＴＭのＡＰＩはＣＳＭ１
４０４と通信するために通信サービス・モジュール（下
記参照）を使用する。いくつかのクラスが共同して上記
の表にリストされているサービスのセットを提供する。
クラスｃｌｎｔＤｉｍｅｎｓｉｏｎはパブリック・メ
ソッド、すなわち、ＧｅｔＤｉｍｅｎｓｉｏｎｓ（スタ
ティックなクラス・メソッド）、ＡｄｄＤｉｍｅｎｓｉ
ｏｎ、ＵｐｄａｔｅＤｉｍｅｎｓｉｏｎ、Ｄｅｌｅｔｅ
Ｄｉｍｅｎｓｉｏｎ、およびＧｅｔＤｉｍｅｎｓｉｏｎ
Ｐａｒｔｉｔｉｏｎｓ、ＡｄｄＤｉｍｅｎｓｉｏｎＰａ
ｒｔｉｔｉｏｎ、ＤｅｌｅｔｅＤｉｍｅｎｓｉｏｎＰａ
ｒｔｉｔｉｏｎを有している。クラスｃｌｎｔＰａｒ
ｔｉｔｉｏｎはパブリック・メソッド、すなわち、Ｇｅ
ｔＳｅｇｍｅｎｔｓ、ＡｄｄＳｅｇｍｅｎｔ、Ｄｅｌｅ
ｔｅＳｅｇｍｅｎｔ、ＵｐｄａｔｅＰａｒｔｉｔｉｏｎ
を有している。クラスｃｌｎｔＳｅｇｍｅｎｔはパブ
リッタ・セグメント、すなわち、ＧｅｔＰａｒｔｉｔｉ
ｏｎｓ、ＡｄｄＰａｒｔｉｔｉｏｎ、ＤｅｌｅｔｅＰａ
ｒｔｉｔｉｏｎ、ＵｐｄａｔｅＳｅｇｍｅｎｔを有して
いる。測定項目関数は２つのクラス、すなわち、ｃｌｎ
ｔＢａｓｉｃＭｅａｓｕｒｅおよびｃｌｎｔＣｏｍ
ｐｏｓｉｔｅＭｅａｓｕｒｅによって表される。

【０２１４】ＩｎｆｏＦｒａｍｅ^ＴＭ作成ＡＰＩ１５３
２はＤＡＩ１４が１つのアナリストを実行またはスケジ
ュールすることを要求すること、およびＤＡＩ１４から
ステータスおよび完了したＩｎｆｏＦｒａｍｅ^ＴＭを呼
び出すことに関連したすべての関数を含んでいる。この
ＡＰＩ１５３２の中の関数はマネージャ・サブシステム
１４０２およびユーザ・インターフェースサブシステム
１４０１によって使われる。ＩｎｆｏＦｒａｍｅ^ＴＭ作
成ＡＰＩ１５３２は次のサービスを他のクライアント・
サブシステムに対して提供する。

【０２１５】

【０２１６】ＩｎｆｏＦｒａｍｅ^ＴＭのＡＰＩ１５３２
もＣＳＭ１４０４と通信するために通信サービス・モジ
ュールを使用する。上記のＩｎｆｏＦｒａｍｅ^ＴＭ作成
要求ＡＰＩ１５３２関数はｃｌｎｔＩｎｆｏＦｒａｍ
ｅＧｅｎｅｒａｔｉｏｎクラスのパブリック・メンバー
である。ｃｌｎｔＩｎｆｏＦｒａｍｅＧｅｎｅｒａｔ
ｉｏｎクラスは「シングルトン」パターン（前に説明さ
れた）を使って、一度だけインスタンシエートされる。
データ・ウェアハウスのＡＰＩ１５３３はデータ・ウェ
アハウス２４のスキーマに関する情報にＭＤＴＡ（アド
ミニストレータ）がアクセスする必要がある時点で、Ｍ
ｅｔａｄａｔａ^ＴＭ２５のセットアップに関連したサー
ビスを提供する。このＡＰＩ１５３３はｃｌｎｔＳｃ
ｈｅｍａクラスの中にカプセル化されている。データ・
ウェアハウスのＡＰＩ１５３３は他のＭＤＴクライアン
ト・サブシステムに対して次のサービスを提供する。

【０２１７】

【０２１８】データ・ウェアハウスのＡＰＩ１５３３も
ＣＳＭ１４０４と通信するために通信サービス・モジュ
ールを使用する。データ・ウェアハウスのＡＰＩ１５３
３はｃｌｎｔＳｃｈｅｍａクラスの中にカプセル化さ
れている。ｃｌｎｔＳｃｈｅｍａクラスは上記の表の
中に記載されたＡＰＩ呼出しに直接対応するパブリック
・メンバー関数を備えている。ＬｏａｄＳｃｈｅｍａ関
数は他のＡＰＩ関数がアクセスするためにデータ・ウェ
アハウスのスキーマのすべてをクライアント上にロード
する。そのスキーマは使用のたびに捨てられる。

【０２１９】セッション・マネジメントＡＰＩ１５３４
はＭＤＴサーバとのセッションを確立すること（および
脱出時にそのコネクションを閉じること）に関連する関
数を含んでいる。これはユーザおよびパスワードのマネ
ージメントに関連する関数を含む。セッション・マネジ
メントＡＰＩは他のＭＤＴクライアント・サブシステム
に対して次のサービスを提供する。

【０２２０】

【０２２１】セッション・マネジメントＡＰＩ１５３４
もＣＳＭ１４０４と通信するために通信サービス・モジ
ュールを使用する。上記のセッション・マネジメント関
数はｃｌｎｔＳｅｓｓｉｏｎＭａｎａｇｅｒのパブリ
ック・メンバー関数である。クラスｃｌｎｔＳｅｓｓ
ｉｏｎＭａｎａｇｅｒは「シングルトン」パターンを使
って、一度、そしてただ一度だけインスタンシエートさ
れる。

【０２２２】通信サービスはＣＳＭ１４０４経由でＤＡ
Ｉ１４に対して通信するための関数をカプセル化してい
る。これらの関数はサーバのＡＰＩサブシステム１４０
３の中の４つのＡＰＩ１５３１、１５３２、１５３３
および１５３４によって共有されている。その通信サー
ビスの機能はサーバのＡＰＩサブシステム１４０３の中
の他のすべてのクラスに対するプライベートのスーパー
クラスとなる、クラスｃｌｎｔＣｏｍｍｕｎｉｃａｔ
ｉｏｎｓの中にカプセル化されている。

【０２２３】＜３．データ抽象化インテリジェンス（Ｄ
ＡＩ）サブシステム１４＞データ抽象化インテリジェン
ス・サブシステム１４が、以下にさらに詳しく説明され
る。本発明（ＭａｎａｇｅｍｅｎｔＤｉｓｃｏｖｅｒ
ｙＴｏｏｌ^ＴＭまたはＭＤＴとも呼ばれる）の重要な
特徴は、それによってユーザ１４０５が問題のオブジェ
クトのビューイングおよび理解における詳細のレベルを
容易に選定できること、そしてＭＤＴによって作成され
るＩｎｆｏＦｒａｍｅ^ＴＭの中に反映されるこれらの異
なるレベルを有することである。例えば、ユーザ１４０
５が「製品」の概念について考える時、その人はその企
業全体によって販売されているすべての製品を意味する
場合もあり、あるいは、全製品のうちの関心のあるいく
つかのサブセットを意味する場合もある。このサブセッ
トは製品の属性についての制限、すなわち、例えば、
「男性用の衣類」などの単独の制限（「製品部門＝男性
用衣類」のように定義される）、あるいは「デザイナー
Ｙによって作られた高価な男性用スーツ」などの複数の
制限（部門、価格、および製造者についての制限によっ
て同様に定義される）のいずれかによって定義すること
ができる。

【０２２４】本発明の設計における洞察の１つはそのよ
うなサブセットは階層を形成すること、そしてこれらの
階層は、ユーザがＩｎｆｏＦｒａｍｅ^ＴＭの製品に対す
る関連の粒度レベルについて考え、選択することの両方
のために、便利で強力な方法を提供することができると
いう考えである。１つの重要な技術的ポイントである
が、ユーザ１４０５からは部分的に隠されている点は、
関連付けられているセグメントがどのようにパーティシ
ョンを形成するかということである。

【０２２５】本発明のＭａｎａｇｅｍｅｎｔＤｉｓｃ
ｏｖｅｒｙＴｏｏｌ^ＴＭ（管理発見ツール）は単独の
論理的な企業データの首尾一貫したビューであるデータ
・ウェアハウス２４のトップにある。普通、データを格
納するには多くの異なった方法がある。すなわち、与え
られたデータの集合に対して異なるテーブル構造または
スキーマがある。すべてではないにしても、ほとんどの
企業において、一組の基本的なデータ・タイプの小集合
があり、それは最低レベルの粒度であって、代表的なも
のは製品、顧客、トランザクションなどの特定のエンテ
ィティである。これらのエンティティには一組の属性が
付随しており、そしてそれらの属性には値があると考え
ることができる。リレーショナル・モデルにおいては、
これは属性がカラムにマップされている、エンティティ
のテーブルに対応する。この場合も、物理的には、それ
らをいくつかのテーブルとして格納することができる。
しかし、概念的には、これがＭＤＴが作業対象である。

【０２２６】図２３は部門属性１６０１を選んでいるユ
ーザ１４０５によって形成された階層を示している。ユ
ーザは「部門」属性１６０１を選んでいて、次に属性の
セグメント「男性用の衣類部門」１６０２を選択し、
「製品のタイプ」属性１６０３を選び、次にその属性の
セグメント「シャツ」１６０４を選択し、「製造者」属
性１６０５、次に「デザイナーＸ」１６０６、そして最
後に、「サイズ」属性１６０７、および特定のパーティ
ション１６０８／１６０９を選んでいる。対象とする最
終「セグメント」は「デザイナーＸの男性用シャツ」で
ある。このセグメントに到達するにはいくつかの方法が
あり、特に関連の属性の順序は任意でよいことに留意さ
れたい。

【０２２７】このスキームによってＭＤＴの他の部分に
対するいくつかの要求条件が生成される。まず第１に、
各ディメンションの属性が利用できなければならない。
第２に、各属性の合法の値も利用できなければならな
い。有限のドメインに対して、これらはユーザ１４０５
に対してリストされなければならない。有限のドメイン
に対して、その時点での最小値および最大値が役に立つ
可能性がある。ここで最初におそらく回避できる微妙な
問題がある。可能な属性値は、実際には、すべてのケー
スにおいて適切であるとは限らない。上記の例の中で、
すべての製造者が「男性用のシャツ」を作っているとは
限らない。合法の値についてデータベースに問い合わせ
るか、あるいはこの情報を追加のＭｅｔａｄａｔａ^ＴＭ
として格納することは可能である。

【０２２８】本発明の重要な条件はユーザ定義のセグメ
ントを保存および再使用する機能を提供することであ
る。「デザイナーＸの男性用シャツ」がユーザ１４０５
にとって重要なカテゴリーである場合、そのユーザはそ
のカテゴリーを保存し、それをＩｎｆｏＦｒａｍｅ^ＴＭ
の作成において再使用できる必要がある。この方式によ
ってユーザはセグメントを定義し、そしてこれらのセグ
メントを階層の中に自動的にキープしておくことができ
る。下記の表は一組の名前付きセグメントおよびそれら
の定義、すなわち、それらの属性についての制限を提供
している。すべてのセグメントはディメンション「製
品」上にある。

【０２２９】

【０２３０】上記のセグメントによって図２４に示され
ているセグメント階層が発生する。この構造には本来的
な曖昧さがあることに留意されたい。与えられたセグメ
ントはいくつかの異なる階層に属する可能性があり、そ
してその下に子があってそれらがいくつかの異なるパー
ティションの中にある。例えば、セグメント「デザイナ
ーＸ−男性用シャツ」は２つのパーティションに属して
いる。最初のパーティションは「デザイナーＸ−シャ
ツ」の上にあり、さらに区別するために「男性用」とい
う値を使う（「その他」のセグメントはここでは「デザ
イナーＸのシャツであるが、男性用のシャツではない」
という意味になることに留意されたい）。このセグメン
トは「男性用のシャツ」の中のパーティションの一部で
もあり、製造者の属性がデザイナーＸであると制限す
る。ここで、「その他」のセグメントは「デザイナーＸ
以外の製造者によって作られた男性用シャツ」を意味す
る。

【０２３１】曖昧さを解消するために、パーティション
の概念が明確にされなければならない。したがって、図
２４を図２５に示されているように書き直してパーティ
ション（暗い境界の）および「その他」のセグメントを
含める。これで図２５から「パーティション」の概念が
「セグメント」の概念と同様に重要であることが分か
る。実際、この２つの概念は分離できない。

【０２３２】図１に戻ると、ＭＤＴデータ抽象化インテ
リジェンス（ＤＡＩ）サブシステム１４はクライアント
・サブシステム１２と「データおよびスキーマ操作」
（ＤＳＭ）サブシステム１６との間に入っている。ＤＡ
Ｉ１４（およびＤＳＭ１６）はアプリケーション・サー
バ３２上でデスクトップ３０とデータ・ウェアハウス２
４との間にある。ＤＡＩ１４はユーザが選択したＩｎｆ
ｏＦｒａｍｅ^ＴＭをインスタンシエートすること、そし
てこのインスタンシエーションにおいて使われる数種類
のＭｅｔａｄａｔａ^ＴＭを管理することを担当する。こ
のＭｅｔａｄａｔａ^ＴＭは、（１）データ・ウェアハウ
スの中のリレーショナル・データのカスタマイズ可能な
「ディメンション化」を提供するディメンションおよび
測定項目、（２）ＩｎｆｏＦｒａｍｅ^ＴＭの中に説明的
なテキストを提供する測定項目間の関係、および（３）
時間に関連付けられたＭｅｔａｄａｔａ^ＴＭを表す。ま
た、ＤＡＩ１４はクライアント層１２から発生したこの
Ｍｅｔａｄａｔａ^ＴＭに対する更新を処理し、また、い
くつかの他の種類の更新を、主としてそれらをＤＳＭ１
６サブシステムへ通して渡すことによって処理する。最
後に、ＤＡＩ１４はクライアント１２またはスケジュー
ラ・サブシステム１８からのアラート要求を実行する。

【０２３３】総合的なクライアント／サーバの設計は、
２種類のＤＡＩサブシステム１４を想定する。第１の種
類のＤＡＩ１４はクライアント１２からの情報に対する
連続的な、同期要求を処理するために必要である。例え
ば、クライアント１２はアクティブなＭＤＴセッション
の間に情報に対する多くの要求を行う可能性がある。Ｓ
−ＤＡＩ（シリアルＤＡＩの場合）がこれらの要求を処
理する。第２の種類のＤＡＩ１４はトリガの定義または
ＩｎｆｏＦｒａｍｅ^ＴＭの定義を含む可能性のあるアナ
リストを実行する。この実行は比較的長い時間（例え
ば、数時間）掛かる可能性があり、そして同時並行的
（コンカレント）に実行される。このタイプのＤＡＩ１
４はコンカレントＤＡＩという意味でＣ−ＤＡＩと呼ば
れることがある。Ｃ−ＤＡＩはＩｎｆｏＦｒａｍｅ^ＴＭ
要求に応答してＳ−ＤＡＩによってスポーン（ｓｐａｗ
ｎ）され、それに必要なすべての情報が与えられる。終
了すると、それはその結果のＩｎｆｏＦｒａｍｅ^ＴＭを
サーバのディスク・ファイルに書き込む。

【０２３４】図２６はＤＡＩ１４および他のサブシステ
ムと本発明のＭＤＴのコンポーネントとの間の、一般的
な、高レベルのデータ・フローを示している。ユーザが
本発明のシステムにログオンすると、シリアルＤＡＩ
（Ｓ−ＤＡＩ）１４Ａが各種の要求をサービスするため
に生成される。クライアント１２からのすべてのユーザ
要求はクライアント／サーバ・モジュール（ＣＳＭ）１
４０４を通して流れ、このＣＳＭはクライアント１２と
サーバ３２との間の通信を制御する。Ｍｅｔａｄａｔａ
^ＴＭに対する要求は、読出しおよび更新（書込み）要求
の両方とも、Ｓ−ＤＡＩによって処理される。読出し要
求によって、Ｓ−ＤＡＩはＭＤＴのＭｅｔａｄａｔａ
^ＴＭのテーブルの中に含まれているＭｅｔａｄａｔａ
^ＴＭに対するデータおよびスキーマ操作（ＤＳＭ）モジ
ュール１６に問い合わせる。Ｓ−ＤＡＩはＬｕｃｅｎｔ
Ｔｅｃｈｎｏｌｏｇｉｅｓ社のＢｅｌｌＬａｂｏｒ
ａｔｏｒｉｅｓから入手できる、階層データ構造を管理
するためのシステムである「Ｃｌａｓｓｉｃサブシステ
ム」を使うことによって更新要求を処理する。Ｃｌａｓ
ｓｉｃサブシステムはセグメント階層の中の新しいユー
ザ・セグメントをチェックして適切に配置するために使
うことができる。また、シリアルＤＡＩは以前に作成さ
れたＩｎｆｏＦｒａｍｅ^ＴＭに対する要求を、サーバの
ディスクからフェッチすることによって処理する。

【０２３５】アナリストを生成することをユーザが要求
すると、コンカレントＤＡＩ１４Ｂがディスパッチャに
よって生成され（リソースが許す場合）、そしてそのコ
ンカレントＤＡＩ１４Ｂにアナリストの定義の中ですべ
ての情報が渡される。コンカレントＤＡＩ１４Ｂは次に
その組込みアルゴリズムおよびＣＳＭ１４０４から要求
されたＭｅｔａｄａｔａ^ＴＭを使ってＩｎｆｏＦｒａｍ
ｅ^ＴＭを作成し、次にそれはサーバのディスク上に格納
される。ＣＳＭモジュール１４０４はメッセージを１つ
のプロセスから別のプロセスへ渡す低レベルのサービス
を提供する。或るクラスは使い易くするために、以下で
さらに詳しく説明されるように、ＣＳＭ１４０４のトッ
プに構築される。

【０２３６】このメッセージ・パッシングの設計は５つ
のクラスおよび１つの列挙型のｍｄｔＭｅｓｓａｇｅ
Ｔｙｐｅから構成される。列挙型はＭＤＴの中の各タイ
プのためのユニークな値を持つ。ｍｄｔＴＩｎＳｔｒ
ｅａｍＨａｎｄｌｅおよびｍｄｔＴＯｕｔＳｔｒｅａ
ｍＨａｎｄｌｅはそれぞれ入力および出力のメッセージ
・ストリームのハンドルである。ｍｄｔＭｅｓｓａｇ
ｅはすべてのＭＤＴメッセージに対する抽象ベース・ク
ラスである。ｄａｉＭａｓｓａｇｅＨａｎｄｌｅｒは
メッセージを処理することができるオブジェクトに対す
る抽象ベース・クラスである。最後に、ｄａｉＭｅｓ
ｓａｇｅＲｅｇｉｓｔｒｙはメッセージ・ハンドラのレ
ジストリである。

【０２３７】ｍｄｔＭｅｓｓａｇｅＴｙｐｅは以下に
定義される。ｅｎｕｍｍｄｔＭｅｓｓａｇｅＴｙｐｅ｛ＵＮＤＥＦＩＮＥＤ，ＣＳＬＯＧＩＮ，ＳＣＬＯＧＩＮＲＥＳＰＯＮＳＥ，ＣＳＧＥＮＥＲＡＴＥＩＮＦＯＦＲＡＭＥ，ＣＳＧＥＴＩＮＦＯＦＲＡＭＥＳＴＡＴＵＳ，ＳＣＩＮＦＯＦＲＡＭＥＳＴＡＴＵＳ，ＣＳＧＥＴＩＮＦＯＦＲＡＭＥ，ＳＣＩＮＦＯＦＲＡＭＥ，ＥＮＤＯＦＥＮＵＭ｝；

【０２３８】ｍｄｔＭｅｓｓａｇｅＴｙｐｅはＭＤＴ
によって理解されるすべてのメッセージ・タイプを定義
するｅｎｕｍである。ｍｄｔＭｅｓｓａｇｅから導か
れる各クラスに対して、ｍｄｔＭｅｓｓａｇｅＴｙｐ
ｅの中に少なくとも１つの値がなければならない。この
ｍｄｔＭｅｓｓａｇｅＴｙｐｅの宣言はＭＤＴのすべ
てのコンポーネントによって使われる。示されているメ
ッセージ・タイプは一例に過ぎない。以下に現在定義さ
れているメッセージ・タイプは単なる１つの例である。
この定義はＭＤＴコードが書かれているように見える。

【０２３９】ｍｄｔＴＩｎＳｔｒｅａｍＨａｎｄｌｅ
は以下のように定義される。ｃｌａｓｓｍｄｔＴＩｎＳｔｒｅａｍＨａｎｄｌｅ：ｐｕｂｌｉｃｃｓｍＩｎＳｔｒｅａｍＨａｎｄｌｅ｛ｐｕｂｌｉｃ：ｍｄｔＴＩｎＳｔｒｅａｍＨａｎｄｌｅ（）：ｄｍｔｙｐｅ（ＵＮＤＥＦＩＮＥＤ）｛｝ｖｉｒｔｕａｌｖｏｉｄＣｏｎｎｅｃｔ（ＲＷｖｉｓｔｒｅａｍ^＊）；ｍｄｔＭｅｓｓａｇｅＴｙｐｅＧｅｔＭｅｓｓａｇｅＴｙｐｅ（）ｃｏｎｓｔ；ｐｒｉｖａｔｅ：ｍｄｔＭｅｓｓａｇｅＴｙｐｅｄｍｔｙｐｅ；｝；

【０２４０】ｍｄｔＴＩｎＳｔｒｅａｍＨａｎｄｌｅ
は入って来る（受信される）メッセージ・ストリームに
対する、タイプが決められたハンドルである。ｍｄｔ
ＴＩｎＳｔｒｅａｍＨａｎｄｌｅはＣＳＭモジュール１
４０４から入って来るメッセージ・ストリームをピック
アップするために使われる。ｍｄｔＴＩｎＳｔｒｅａ
ｍＨａｎｄｌｅは入って来るメッセージ・ストリームか
らそのメッセージのタイプを自動的に読み、そのメッセ
ージ・タイプを得るためのメンバー関数を提供する。ｍ
ｄｔＭｅｓｓａｇｅＲｅｇｉｓｔｒｙのユーザはこの
クラスを使う必要はない。

【０２４１】ｍｄｔＴＯｕｔＳｔｒｅａｍＨａｎｄｌ
ｅは以下に定義される。ｃｌａｓｓｍｄｔＴＯｕｔＳｔｒｅａｍＨａｎｄｌｅ：ｐｕｂｌｉｃｃｓｍＯｕｔＳｔｒｅａｍＨａｎｄｌｅ｛ｐｕｂｌｉｃ：ｍｄｔＴＯｕｔＳｔｒｅａｍＨａｎｄｌｅ（ｍｄｔＭｅｓｓａｇｅＴｙｐｅｔ）：ｄｍｔｙｐｅ（ｔ）｛｝ｖｉｒｔｕａｌｖｏｉｄＣｏｎｎｅｃｔ（ＲＷｖｏｓｔｒｅａｍ^＊）；ｍｄｔＭｅｓｓａｇｅＴｙｐｅＧｅｔＭｅｓｓａｇｅＴｙｐｅ（）ｃｏｎｓｔ；ｐｒｉｖａｔｅ：ｍｄｔＴＯｕｔＳｔｒｅａｍＨａｎｄｌｅ（）；ｍｄｔＭｅｓｓａｇｅＴｙｐｅｄｍｔｙｐｅ；｝；

【０２４２】ｍｄｔＴＯｕｔＳｔｒｅａｍＨａｎｄｌ
ｅは出て行くストリームに対する、タイプの決められた
ハンドルである。ｍｄｔＴＯｕｔＳｔｒｅａｍＨａｎ
ｄｌｅはＣＳＭ１４０４を経由してストリーム型のメッ
セージを送信するために使われる。そのｍｄｔＴＯｕ
ｔＳｔｒｅａｍＨａｎｄｌｅはメッセージ・タイプを有
し、受信端においてｍｄｔＴＩｎＳｔｒｅａｍＨａｎ
ｄｌｅがそのメッセージ・タイプを解読できるようにそ
のストリームに対して自分のメッセージ・タイプを自動
的に書き込む。

【０２４３】ｍｄｔＭｅｓｓａｇｅは以下に定義され
る。ｃｌａｓｓｍｄｔＭｅｓｓａｇｅ｛ｐｕｂｌｉｃ：ｍｄｔＭｅｓｓａｇｅ（）：ｄｒｅｓｔｏｒｅＶｅｒｓｉｏｎ（０），ｄｒｅｓｔｏｒｅＦｌａｇ（ｆａｌｓｅ）｛｝ｍｄｔＭｅｓｓａｇｅ（ｃｏｎｓｔｍｄｔＭｅｓｓａｇｅ＆）；ｖｉｒｔｕａｌｍｄｔＭｅｓｓａｇｅＴｙｐｅＧｅｔＭｅｓｓａｇｅＴｙｐｅ（）ｃｏｎｓｔ；ｖｉｒｔｕａｌｉｎｔＧｅｔＬａｓｔＶｅｒｓｉｏｎ（）ｃｏｎｓｔ＝０；ｖｉｒｔｕａｌｖｏｉｄＳｅｔＲｅｓｔｏｒｅＶｅｒｓｉｏｎ（ｉｎｔｒｅｓｔｏｒｅＶｅｒｓｉｏｎ）；ｖｉｒｔｕａｌｉｎｔＧｅｔＲｅｓｔｏｒｅＶｅｒｓｉｏｎ（）ｃｏｎｓｔ；ｖｉｒｔｕａｌｖｏｉｄｓａｖｅＧｕｔｓ（ＲＷｖｏｓｔｒｅａｍ＆）ｃｏｎｓｔ；ｖｉｒｔｕａｌｖｏｉｄＲｅｓｔｏｒｅＧｕｔｓ（ＲＷｖｉｓｔｒｅａｍ＆）；ｖｉｒｔｕａｌｂｏｏｌＩｓＲｅｓｔｏｒｅｄ（）ｃｏｎｓｔ；ｐｒｏｔｅｃｔｅｄ：ｖｉｒｔｕａｌｖｏｉｄＳｅｔＲｅｓｔｏｒｅｄＦｌａｇ（ｂｏｏｌ）；ｐｒｉｖａｔｅ：ｂｏｏｌｄｒｅｓｔｏｒｅＦｌａｇ；ｉｎｔｄｒｅｓｔｏｒｅＶｅｒｓｉｏｎ；｝；

【０２４４】要求および応答はクライアント１２、シリ
アルＤＡＩ１４Ａ、コンカレントＤＡＩ１４Ｂ、スケジ
ューラ１８と、ディスパッチ２５１３との間で、クライ
アント／サーバ・モジュール（ＣＳＭ）１４０４によっ
て通信される。ＣＳＭ１４０４は要求または応答を送信
または受信するために使われるｍｄｔＭｅｓｓａｇｅク
ラスを実装する。受信のｍｄｔＭｅｓｓａｇｅは入力
ストリームを含んでいる。送信のｍｄｔＭｅｓｓａｇ
ｅは出力ストリームを含んでいる。ストリームはよく知
られているＣ＋＋の構造体であり、これによってユーザ
は長いメッセージの要素をバッファの中に「ストリー
ム」するか、あるいは、メッセージの要素をバッファか
らストリームとして出すことができる。

【０２４５】このＭＤＴの発明のために実装される各要
求および応答は、ｍｄｔＭｅｓｓａｇｅの基本クラス
から導かれるメッセージによって表され、そして自分自
身をストリーム・インまたはストリーム・アウトするた
めの適切な関数を有している。ＣＳＭ１４０４はｃｓｍ
ＳｉｍｐｌｅＳｏｃｋｅｔおよびｃｓｍＳｅｒｖｅ
ｒＳｏｃｋｅｔクラスを実装する。各タイプのソケット
はＴＣＰ／ＩＰソケットを含んでいる。ＴＣＰ／ＩＰソ
ケットはＴＣＰ／ＩＰネットワークに対するよく知られ
たＡＰＩである。他の実装が考えられる。各タイプのソ
ケットはメッセージからそのストリーム・バッファを抽
出することができ、そしてそれをソケット経由で受信の
ｃｓｍＳｉｍｐｌｅまたはｃｓｍＳｅｒｖｅｒＳｏ
ｃｋｅｔへ送るか、あるいは、送信のｃｓｍＳｉｍｐ
ｌｅＳｏｃｋｅｔからストリーム・バッファを受取り、
それをメッセージの中にインストールすることができ
る。

【０２４６】ｃｓｍＳｉｍｐｌｅＳｏｃｋｅｔはＭＤ
Ｔサブシステム間で約束された１対１の関係でメッセー
ジを通信するために使われる。ｃｓｍＳｅｒｖｅｒＳ
ｏｃｋｅｔはＭＤＴサブシステムが他の多くのサブシス
テムからメッセージを受け付けることができるようにす
るために使われる。図３２において、クライアント・サ
ブシステム１２はｃｓｍＳｉｍｐｌｅＳｏｃｋｅｔを
維持し、それを使ってマスタ・サブシステム２５１１か
らＳＤＡＩサブシステム２５１２を要求し、またその
後、それを使ってそのＳＤＡＩサブシステムとメッセー
ジを交換する。クライアント１２は、クライアント１２
に対するユーザの入力がサーバとの交換を必要とする時
はいつでもこのソケットを使用する。

【０２４７】図３２において、マスタ・サブシステム２
５１１はＳＤＡＩサブシステム１４Ａを要求したい任意
のクライアント・サブシステム１２からのメッセージを
受信するために、ｃｓｍＳｅｒｖｅｒＳｏｃｋｅｔを
維持する。マスタがアクティブにＳＤＡＩを開始する
か、さもなければＳＤＡＩに対して面倒をみている時以
外は、それはｃｓｍＳｅｒｖｅｒＳｏｃｋｅｔを聴取
している。ＳＤＡＩサブシステム２５１１はクライアン
ト・サブシステム１２とメッセージを交換するために、
ｃｓｍＳｉｍｐｌｅＳｏｃｋｅｔを維持する。それが
クライアントの要求を実際に実装している時を除いて、
ＳＤＡＩ１４ＡはそのｃｓｍＳｉｍｐｌｅＳｏｃｋｅ
ｔを聴取している。

【０２４８】ユーザ１４０５がただちに実行するために
アナリストをサブミットしたとき、ＳＤＡＩサブシステ
ム１４Ａはそのアナリストをディスパッチャ２５０１へ
通信するために新しいｃｓｍＳｉｍｐｌｅＳｏｃｋｅ
ｔを構築する。ユーザがスケジュール型の、あるいはト
リガ型のアナリストをサブミットすると、ＳＤＡＩはそ
のアナリストをスケジューラ１８に対して通信するため
に１つのｃｓｍＳｉｍｐｌｅＳｏｃｋｅｔを構築す
る。スケジューラ１８は任意の、またはすべてのＳＤＡ
Ｉサブシステム２５１１からスケジュール型の、あるい
はトリガ型のアナリストを収集するために、ｃｓｍＳ
ｅｒｖｅｒＳｏｃｋｅｔを維持する。スケジューラがス
ケジュール型の、あるいはトリガ型のアナリストを立ち
上げるべき時が来たと判断すると、スケジューラはｃｓ
ｍＳｉｍｐｌｅＳｏｃｋｅｔを１つ構築してそのアナ
リストをディスパッチャ・サブシステム２５１３に対し
て通信する。スケジューラがそのスケジュール型の、あ
るいはトリガ型のアナリストのリストをテストしている
時、またはそれらをディスパッチしている時を除いて、
スケジューラはそのｃｓｍＳｉｍｐｌｅＳｏｃｋｅｔ
を聴取している。

【０２４９】ディスパッチャ・サブシステム２５１３は
準備完了状態の任意のＳＤＡＩサブシステム２５１１か
ら、またはスケジューラ・サブシステム１８から実行の
ためのアナリストを収集するため、あるいは、ＣＤＡＩ
サブシステム１４Ｂからのアナリスト要求を収集するた
めに、１つのｃｓｍＳｅｒｖｅｒＳｏｃｋｅｔを維持
する。１つのＳＤＡＩまたはそのスケジューラが１つの
アナリストを提示すると、ディスパッチャはその実行の
ためのリソースが利用できるようになるまで、それを保
持する。リソースが利用できるようになると、ＳＤＡＩ
はＣＤＡＩ１４Ｂを開始させる。ＣＤＡＩがそのアナリ
ストに対する要求を返すと、ＳＤＡＩは１つのｃｓｍ
ＳｉｍｐｌｅＳｏｃｋｅｔを生成して、そのアナリスト
をＣＤＡＩに対して通信する。ＣＤＡＩの管理を開始し
ている時を除いて、ＳＤＡＩサブシステム２５１３はそ
のｃｓｍＳｅｒｖｅｒＳｏｃｋｅｔを聴取している。
ＣＤＡＩサブシステム１４Ｂはディスパッチャ・サブシ
ステム２５１３からそのアナリストを収集するために始
動された後すぐに、ｃｓｍＳｉｍｐｌｅＳｏｃｋｅｔ
を１つ構築する。このメッセージを収集した後、そのｃ
ｓｍＳｉｍｐｌｅＳｏｃｋｅｔを捨てる。ＣＤＡＩサ
ブシステム１４Ｂは本発明の他のサブシステムとはメッ
セージを交換しない。

【０２５０】ｍｄｔＭｅｓｓａｇｅ抽象基本クラスは
ＭＤＴのプロセス間メッセージの内容を保持するオブジ
ェクトを定義する。各メッセージはメッセージ・タイ
プ、メッセージ・バージョン、およびメッセージ・デー
タのストリームとの間でそのデータを読み書きする機能
を有する。各タイプのメッセージに対して、ｍｄｔＭ
ｅｓｓａｇｅから導かれたクラスの具体的な実装があ
る。各メッセージ・クラスはＧｅｔＬａｔｅｓｔＶｅｒ
ｓｉｏｎを実装して、そのバージョンを返さなければな
らず、そしてＧｅｔＭｅｓｓａｇｅＴｙｐｅを実装して
そのｍｄｔＭｅｓｓａｇｅＴｙｐｅを返さなければな
らない。また、ＲｏｇｕｅＷａｖｅｓａｖｅＧｕｔ
ｓおよびｒｅｓｔｏｒｅＧｕｔｓメソッドを実装してそ
の永続的なメンバー・データをストリームへ書込み、そ
してそのメンバー・データをストリームから読み戻さな
ければならない。アンパッキングの順序は「先入れ先出
し」である。メッセージ・タイプあたりに導かれたメッ
セージ・クラスが１つだけあるが、導かれたメッセージ
・クラスによって使われるメッセージ・タイプはいくつ
かあり得る。同じメッセージ・コードが送信と受信の両
方のプロセスにリンクされる必要がある。送信のプロセ
スと受信のプロセスにおけるコードのバージョン間のミ
スマッチを誤りなく確実に処理するために、バージョン
・チェックが使われる。そのメッセージ・バージョンは
到来するメッセージ・ストリームを復元できることを保
証するため、そして、そのクラスの古いバージョンによ
って保存されたストリームをマイグレートするために、
ｒｅｓｔｏｒｅＧｕｔｓによって使われる。ｍｄｔＭ
ｅｓｓａｇｅｓは上記で定義されたｍｄｔＴＯｕｔＳ
ｔｒｅａｍＨａｎｄｌｅ／ｍｄｔＴＩｎＳｔｒｅａｍ
Ｈａｎｄｌｅによってポイントされるストリームとの間
で、その中身を保存／復元することによって、ＣＳＭモ
ジュール１４０４からｍｄｔＭｅｓｓａｇｅが送信／
受信される。

【０２５１】ｄａｉＭｅｓｓａｇｅＨａｎｄｌｅｒは
以下に定義される。ｃｌａｓｓｄａｉＭｅｓｓａｇｅＨａｎｄｌｅｒ｛ｐｕｂｌｉｃ：ｖｉｒｔｕａｌｂｏｏｌＨａｎｄｌｅＭｅｓｓａｇｅ（ｃｏｎｓｔｍｄｔ＿Ｍｅｓｓａｇｅ＆）＝０；｝；

【０２５２】ｄａｉＭｅｓｓａｇｅＨａｎｄｌｅｒは
メッセージ・ハンドラ・クラスに対する抽象基本クラス
である。プロセスが受信したメッセージをディスパッチ
するためにメッセージ・レジストリを使う場合、少なく
とも１つの具体的なメッセージ・ハンドラ・クラスが実
装されなければならない。登録されたメッセージあたり
１つ程度の数のメッセージ・ハンドラが実装される可能
性がある。

【０２５３】ｄａｉＭｅｓｓａｇｅＲｅｇｉｓｔｒｙ
は以下に定義される。ｃｌａｓｓｄａｉＭｅｓｓａｇｅＲｅｇｉｓｔｒｙ｛ｐｕｂｌｉｃ：ｄａｉＭｅｓｓａｇｅＲｅｇｉｓｔｒｙ（ｃｓｍＣｏｎｎｅｃｔ＆）；ｖｏｉｄＤｉｓｐａｔｃｈＭｅｓｓａｇｅ（）；ｖｏｉｄＲｅｇｉｓｔｅｒＭｅｓｓａｇｅ（ｍｄｔ＿ＭｅｓｓａｇｅＴｙｐｅ，ｄａｉＭｅｓｓａｇｅＣｒｅａｔｅＦｕｎｃ，ｄａｉＭｅｓｓａｇｅＨａｎｄｌｅｒ＆）；ｐｒｉｖａｔｅ：ｄａｉＭｅｓｓａｇｅＣｒｅａｔｅＦｕｎｃｄｃｒｅａｔｅＦｕｎｃ；ｄａｉＭｅｓｓａｇｅＨａｎｄｌｅｒ ^＊ｄｈａｎｄｌｅｒ；ｃｓｍＣｏｎｎｅｃｔ ^＊ｄｃｏｎｎｅｃｔ；｝；

【０２５４】ｄａｉＭｅｓｓａｇｅＲｅｇｉｓｔｒｙ
はそれを使う各プロセスの中で一度だけインスタンシエ
ートされることを意味するクラスである。そのメッセー
ジ・レジストリは各メッセージ・タイプごとにハンドラ
を登録するためのメソッド、および到来するすべてのメ
ソッドをディスパッチするためのメソッドを提供する。
そのディスパッチ・メソッドはそのアプリケーションの
メイン・ループのように働く。そのハンドラのＨａｎｄ
ｌｅＭｅｓｓａｇｅメソッドの戻り値は、メッセージが
処理された後でＤｉｓｐａｔｃｈＭｅｓｓａｇｅがブロ
ックするか戻るかどうかを決定する。戻り値が「真」
（ｔｒｕｅ）であった場合、それはブロックする。

【０２５５】次は、ＭＤＴのタイプのストリーム・ハン
ドルおよびメッセージ・レジストリを使って１つのプロ
セスから別のプロセスへメッセージが送信されるときに
発生するイベントのセットである。１．送信側のプロセスは具体的なメッセージ・クラス
のインスタンス（ｍｄｔ＿Ｍｅｓｓａｇｅから導かれ
る）、ＭＳを構築し、そしてそれを適切なメッセージ・
データと一緒にロードする。２．送信側のプロセスはそのメッセージと同じメッセ
ージ・タイプのｍｄｔＴＯｕｔＳｔｒｅａｍＨａｎｄｌ
ｅオブジェクトを生成する。このｍｄｔＴＯｕｔＳｔ
ｒｅａｍＨａｎｄｌｃオブジェクトはそのメッセージ・
タイプをそのストリームへ書き込む。

【０２５６】３．送信側のプロセスはそのメッセージ
のｓａｖｅＧｕｔｓメンバー関数を使ってそのメッセー
ジをメッセージ・ストリームへ書き込む。４．メッセージのｓａｖｅＧｕｔｓメソッドは最初に
そのメッセージのバージョン番号をそのストリームに対
して書き込む基本のクラス・メソッドを呼び出す。次
に、そのメッセージの永続的なメンバーのデータ・フィ
ールドをそのストリームへ保存する。５．送信側のプロセスはｃｓｍＳｅｎｄＰｒｏｃｅ
ｓｓＣｏｎｎｅｃｔ：：Ｓｅｎｄ（）を呼び出して、そ
のメッセージ・ストリームを送る。

【０２５７】６．ＣＳＭはそのストリーム・オブジェ
クトからバイトを抽出し、そのバイトを受信側のプロセ
スへ送る。７．ｍｄｔＴＯｕｔＳｔｒｅａｍＨａｎｄｌｅオブ
ジェタトが破壊されると、それは自分が接続されていた
ストリーム・オブジェクトを破壊する。８．受信側のプロセスはｃｓｍＲｅｃｅｉｖｅＰｒ
ｏｃｅｓｓ：：Ｒｅｃｅｉｖｅ（）に対する呼出しにお
いて待っている必要がある。内部的には、おそらくいく
つかのキューが存在している。９．受信側のプロセスの中のＣＳＭはキューの中の最
も古いメッセージを得る。次にそれはそのバイトをスト
リーム・オブジェクトに変換し、そしてそのストリーム
をｃｓｍＲｅｃｅｉｖｅＰｒｏｃｅｓｓ：：Ｒｅｃｅ
ｉｖｅ（）に対して渡されたｍｄｔＴＩｎＳｔｒｅａ
ｍＨａｎｄｌｅオブジェクトに接続する。１０．ストリームがそのハンドルに接続されると、そ
のハンドルはそのメッセージ・タイプをそのストリーム
から読み、それを覚える。

【０２５８】１１．最後に、制御がｃｓｍＲｅｃｅ
ｉｖｅＰｒｏｃｅｓｓ：：Ｒｅｃｅｉｖｅ（）から呼出
し側へ戻る。１２．受信側のプロセスはそのメッセージ・タイプを
ｍｄｔＴＩｎＳｔｒｃａｍＨａｎｄｌｅから取得し、
そのメッセージ・タイプに対するメッセージ・クラスの
正しいタイプの空のインスタンスを構築する。メッセー
ジ・ディスパッチャが使用中の場合、これはｄａｉＭ
ｅｓｓａｇｅＲｅｇｉｓｔｒｙ：：ＤｉｓｐａｔｃｈＭ
ｅｓｓａｇｅｓ（）によって処理される。１３．受信側のプロセスはそのメッセージのｒｅｓｔ
ｒｅＧｕｔｓ関数を呼び出す。メッセージ・ディスパッ
チャが使用中の場合、これはｄａｉＭｅｓｓａｇｅＲ
ｅｇｉｓｔｒｙ：：ＤｉｓｐａｔｃｈＭｅｓｓａｇｅｓ
（）によって処理される。

【０２５９】１４．そのメッセージのｒｅｓｔｏｒｅ
Ｇｕｔｓメソッドはまず最初に、バージョン番号を読ん
でそれをＲｅｓｔｏｒｅＶｅｒｓｉｏｎメンバーとして
保存する自分の基本クラス（普通はｍｄｔ＿Ｍｅｓｓａ
ｇｅ）のｒｅｓｔｏｒｅＧｕｔｓメソッドを呼び出す。
次に、制御は導かれたバージョンのｒｅｓｔｏｒｅＧｕ
ｔｓへ戻る。それはＧｅｔＲｅｓｔｏｒｅＶｅｒｓｉｏ
ｎを呼び出し、その結果のバージョン番号を使ってどの
データ・メンバーをそのストリームから読み出すか、そ
してどんな順序でそれらを読み込むかを決定する。次
に、そのメッセージ・クラスのデータ・フィールドがそ
のストリームから読み戻される。

【０２６０】１５．受信されたメッセージはここでは
その最終のフォームになっている。ディスパッチャが使
用中の場合、それはレジストリの中でこのメッセージ・
タイプを探してそのハンドラをルックアップし、そして
そのＨａｎｄｌｅＭｅｓｓａｇｅメソッドを呼び出す。１６．そのメッセージを受信するために使われたｍｄ
ｔＴＩｎＳｔｒｅａｍＨａｎｄｌｅオブジェクトが破
壊されている場合（あるいは、ｃｓｍＲｅｃｅｉｖｅ
Ｐｒｏｃｅｓｓ：：Ｒｅｃｅｉｖｅ（）に対する別の呼
出しによって再接続されていた場合）、それがポイント
していたストリームは削除される。

【０２６１】このＭＤＴの発明によって、アナリストと
呼ばれる強力なレポート作成オブジェクトを定義するこ
とにより、他のユーザがそれぞれのデータ・ウェアハウ
ス２４を監視することができる。アナリストは一般のタ
イプの分析のカプセル化されたものであり、一組のパラ
メータ、スケジュール、およびトリガ条件を提供するこ
とにより、ユーザ１４０５によってカスタマイズされた
ものである。そのアナリストはトリガ条件が成立してい
るかどうかについてそのトリガ条件を定期的にチェック
しするか、あるいは、トリガ条件が成立している場合は
そのスケジュール上で定期的に実行する。それ以外の場
合、それはただちに実行する。ＩｎｆｏＦｒａｍｅ^ＴＭ
は他のアナリストを実行するために使うことができ、関
連付けられたＩｎｆｏＦｒａｍｅ^ＴＭを作成することが
できる各種のデータおよびハイパーリンクを含んでい
る。アナリストの定義およびＩｎｆｏＦｒａｍｅ^ＴＭの
作成を含めて、ＭＤＴの機能は、「ＭＤＴのＭｅｔａｄ
ａｔａ^ＴＭ２５」と呼ぶデータ・ウェアハウスの「ＭＤ
Ｔビュー」を必要とする。

【０２６２】「Ｍｅｔａｄａｔａ^ＴＭ」という言葉は一
般に、データベースまたはデータ・ウェアハウス２４
（図１）の中の各種の「データに関するデータ」のこと
をいう。ＭＤＴのＭｅｔａｄａｔａ^ＴＭ２５はそのデー
タベースの関係構造によって制限されていないデータの
カスタマイズ可能なビューを提供する。ＭＤＴのＭｅｔ
ａｄａｔａ^ＴＭ２５は一組のテーブルとしてデータ・ウ
エアハウス２４の中に格納されており、スタートアップ
時に本発明のＭＤＴによって読み出される。データ・ウ
ェアハウス２４の中にＭｅｔａｄａｔａ^ＴＭ２５を埋め
て置くことはＭＤＴのインストレーション・プロセスの
１つの重要な部分であり、そしてＭＤＴアドミニストレ
ータはデータ・ウェアハウス２４の構造の知識を使って
ＭＤＴのＭｅｔａｄａｔａ^ＴＭを拡張して維持すること
が一般に必要となる。

【０２６３】ＭＤＴのＭｅｔａｄａｔａ^ＴＭには主な種
類が４つある。それらは（１）ディメンションおよび属
性、（２）セグメントおよびパーティション、（３）測
定項目、（４）測定項目間の関係である。本発明の仕様
は一連のテーブルによってそれぞれの種類のＭｅｔａｄ
ａｔａ^ＴＭを記述する。各テーブルはカラム名およびそ
のカラムの中のデータ値のタイプ（括弧内）を示す。い
くつかのカラムはＭＤＴ指向のエンティティまたはオブ
ジェクトを定義し、そして他のカラムはＭＤＴのＭｅｔ
ａｄａｔａ^ＴＭとウェアハウスの関係スキーマとの間の
情報のマッピングを提供する。各テーブルの一次キーは
斜体文字で書かれている（２つ以上のカラム名が斜体文
字になっていた場合、それらのカラム名の組合わせがそ
のキーを形成する）。

【０２６４】ＭＤＴのＭｅｔａｄａｔａ^ＴＭ２５は、或
るデータ属性は値の有限集合を持ち得るという明示的な
概念を含む。これらは「列挙型（ｅｎｕｍｅｒａｔｅ
ｄ）の属性」と呼ばれる。例えば、本発明は属性「州
（Ｓｔａｔｅ）」は値の有限集合に限定される（すなわ
ち、米国の５０の各州、そのデータ・ウェアハウスがど
んな符号化を使うとしても）という事実を表すことがで
きる。また、ＭＤＴのＭｅｔａｄａｔａ^ＴＭのテーブル
は、便宜的に、ソース・コードのヘッダ・ファイルの中
で列挙型で表される値の集合を指す。「ｅｎｕｍ］とい
う語はこのタイプのカラムの値を指す。

【０２６５】ＭＤＴのＭｅｔａｄａｔａ^ＴＭ２５のテー
ブル表現はまず最初に、主な種類の各Ｍｅｔａｄａｔａ
^ＴＭごとに１つの、４つのセクションの中で記述され
る。次に以下のこと、すなわち、ＭＤＴにおける時間の
表現、ソース・コードのヘッダ・ファイルの中に格納さ
れるべきＭｅｔａｄａｔａ^ＴＭの種類、およびインスト
レーション時にＭｅｔａｄａｔａ^ＴＭのテーブルを埋め
る問題が記述される。ディメンションはドメインに対す
る開始のボキャブラリ（ｖｏｃａｂｕｌａｒｙ）であ
る。それらは高レベルのカテゴリーのエンティティを定
義する。例えば、小売り業のドメインにおいて、そのデ
ィメンションは製品、マーケット、および時間（時間は
ほとんどのドメインに対して適用できる汎用のドメイン
である）であり得る。各ディメンションには一組の属性
があり、それを使ってそのエンティティを記述すること
ができる。例えば、部門、価格、スタイル、製造者など
の、製品に対する各種の属性がある。

【０２６６】このセクションの中のすべてのテーブルは
インストレーション時にセットアップされ、あまり変わ
る可能性はない。というのは、それらはすべてデータ・
ウェアハウス２４の構造および業界特有のデータのビュ
ーに大きく依存しているからである。このセクションの
中のどのテーブルも、一般にエンド・ユーザが変更する
ことはできない。ただし、ＭＤＴアドミニストレータに
よってＭＤＴのＭｅｔａｄａｔａ^ＴＭを拡張するため、
またはデータ・ウェアハウスの関係スキーマにおける変
化に応答してときどき変更が必要となる可能性がある。
次の表に示されているように、ディメンションはそれぞ
れの名前および関連付けられたＩｄによって表される。
そのＩｄは他のテーブルとより効率的に結合するために
使われる。Ｓｅｇ−Ｉｄはこのディメンションのトップ
レベルのセグメントのＩｄであり、Ｃｏｍｍｅｎｔはコ
メントである。

【０２６７】

【０２６８】次の表は各ディメンションに対するすべて
の属性を表わしている。各属性はユニークなＩｄ（Ａｔ
ｔｒ−Ｉｄ）、名前、およびそれらが属しているディメ
ンションのＩＤ（Ｄｉｍ−Ｉｄ）を有する。異なるディ
メンションに対する属性の名前は同じであってよい（し
かし、それらのＩＤは異なっている）。ＭＤＴ−Ｔｙｐ
ｅはその属性のＭＤＴタイプを示す。各属性は単独のテ
ーブルおよびカラムにマップされ、各属性がマップする
データベースの中のフィールド（Ｃｏｌｕｍｎ−Ｔｙｐ
ｅ）の中のフィールドのデータ・タイプを符号化する。
Ｄｉｍ−Ｉｄフィールドを使ってこのテーブルから与え
られたディメンションに対するすべての属性を抽出する
ことができる。ＭＤＴ−Ｔｙｐｅに対するｅｎｕｍ値
は、列挙型（ｅｎｕｍ）、整数（ｉｎｔ）、浮動小数点
数（ｆｌｏａｔ）、制限された整数（ｒｅｓｔｒｉｃｔ
ｅｄ−ｉｎｔ）、制限された浮動小数点数（ｒｅｓｔｒ
ｉｃｔｅｄ−ｆｌｏａｔ）、文字列（ｓｔｒｉｎｇ）で
ある。Ｃｏｌｕｍｎ−Ｔｙｐｅに対するｅｎｕｍ値はす
べてそのデータ・ウェアハウスによってサポートされて
いるタイプである。

【０２６９】

【０２７０】列挙型の属性に関して次の表はこれらの属
性に対する合法的な値を表わしている。これらの値は
「男性用衣類」などのユーザ名および「Ｄｅｐｔ−０１
７」などの実際のデータ値の名前の両方を含む。これら
のテーブルの中の情報はその属性に対する「Ｓｅｌｅｃ
ｔ…Ｄｉｓｔｉｎｃｔ…」クエリーによって部分的に作
成される。

【０２７１】

【０２７２】整数型のタイプの属性の場合、次の表が値
の適切な範囲および、これがユーザに対して定義される
のに便利である場合に「代表値」を定義する。その整数
属性の範囲および代表値が自然な値でない場合、この表
の中にすべての整数属性が現われる必要はない。

【０２７３】

【０２７４】浮動小数点数型のタイプの属性の場合、次
の表が値の適切な範囲およびこれがユーザに対して定義
されるのに便利である場合に「代表値」を定義する。そ
の整数属性の範囲および代表値が自然な値でない場合、
この表の中にすべての整数属性が現われる必要はない。

【０２７５】

【０２７６】ＭＤＴのＭｅｔａｄａｔａ^ＴＭ２５の主要
部分は各ディメンションに対する一組のセグメントおよ
びパーティションである。セグメントは問題のオブジェ
クトのクラスを定義する一組の属性制限である。例え
ば、「過去１年以内に改装された店舗」、あるいは「季
節的でない店舗全体での販売促進」、あるいは「サイズ
が１４以上であるデザイナーＸのシャツ」などである。
セグメントは各ディメンションに対して１つの階層の中
に配列される。階層はさらにパーティションの概念を使
って編成されている。パーティションは単独の属性につ
いての制限によってのみ異なっている一組の関連付けら
れたセグメントである。セグメントおよびパーティショ
ンは各ディメンションに対するセグメント／パーティシ
ョンの階層を捕捉する一組のテーブルによって表わさ
れ、そして各テーブルに対する属性の制限を定義する。

【０２７７】次の表は各セグメントおよびそれがその一
部であるディメンションを示し、そのセグメントの名前
および所有者を提供する。グローバルに所有されている
セグメントに対する所有者の文字列はヘッダ・ファイル
の中で定義される。それはここおよび他の場所で「ＡＬ
Ｌ（すべて）」として示されている。各ディメンション
に対して名前が「ＡＬＬＸ（すべてのＸ）」である、
いわゆる「トップレベル」のセグメントがある。ここで
Ｘはそのディメンションの名前である。Ｎｕｍ−Ａｔｔ
ｒｓフィールドはこのセグメントを制限するために使わ
れる属性の数を含んでいる。「トップレベル・セグメン
ト」では、Ｎｕｍ−Ａｔｔｒｓは０に等しくなる。

【０２７８】

【０２７９】次の表は次の時間間隔表記で表わされてい
る各セグメントに対するすべての数値属性の制限を表わ
す。上記の最初の行の中で、Ａｔｔｒ−Ｉｄ０１７が
属性「サイズ」を表わす場合、この行は「０＜＝サイズ
＜＝１００」を示すことになる。すなわち、「サイズが
０より大きく、そして１００より小さい」である。値は
文字列として表わされているので、他のタイプ（浮動小
数点数または通貨型など）の属性の制限も表わすことが
できる。Ｏｐｅｒａｔｏｒ−１（演算子１）のｅｎｕｍ
値はｇｒｅａｔｅｒｔｈａｎ（より大きい）、ｌｅｓ
ｓｔｈａｎ（より小さい）、ｇｒｅａｔｅｒｏｒ
ｉｓ（より大きいかまたは等しい）、ｌｅｓｓｔｈａ
ｎｏｒｉｓ（より小さいかまたは等しい）、ｉｓ
（等しい）、ｉｓｎｏｔ（等しくない）、ｉｓｂｅ
ｔｗｅｅｎ（間にある）である。

【０２８０】

【０２８１】次の表は各セグメントに対する列挙型の属
性の制限のすべての集合を表わしている。「Ｄａｔａ
Ｎａｍｅ（データ名）」のカラムは前と同じである。例
えば、セグメント（東海岸の都市）を表わす場合、それ
を集合［ニューヨーク、ボストン、ワシントン…］とし
て定義することができる。このためには、各都市に対し
て１つづづのいくつかのエンティティーがこのテーブル
の中に現われる。このテーブルは文字列の属性制限を表
わすためにも使うことができる。Ｏｐｅｒａｔｏｒに対
するｅｎｕｍ値は、ｉｓ（である）、ｉｓｎｏｔ（で
ない）、ｉｓｉｎｌｉｓｔ（リスト内にある）、ｎｏ
ｔｉｎｌｉｓｔ（リスト内にない）である。

【０２８２】

【０２８３】次の表は各パーティションおよびそれにつ
いて定義されている属性を定義している。デフォールト
のパーティション名は上で定義されている属性のパーテ
ィション名と同じである。この場合、ユーザ・インター
フェースはプリフィックスとして「ｂｙ−」を付加する
ことによってそのパーティション名を表わす。その名前
はユーザ１４０５によって更新される可能性がある。

【０２８４】

【０２８５】次の表およびその次の表はセグメント／パ
ーティションの階層を定義する。この表は各セグメント
の子パーティションを表わす。この表は与えられたパー
ティションに対する親セグメントを見つけるためにも使
うことができる。

【０２８６】

【０２８７】次の表は各パーティションに対する子セグ
メントを表わす。この表は各セグメントに対する親のパ
ーティションを見つけるためにも使うことができる。

【０２８８】

【０２８９】測定項目はデータについて測定できるデー
タ・ウェアハウス２４の中の値である。例えば、売上
高、価格、および市場占有率はすべて小売業のドメイン
における測定項目である。異なる測定項目は「ロールア
ップ」される方法が違っている。例えば、いくつかの市
場にわたる売上高は加算され、一方、市場占有率は平均
化される。本発明のＭＤＴはインストレーション時に一
組の基本測定項目を提供し、ユーザはそれらを組み合わ
せた数式を使って、より複雑な組み合わせの測定項目を
形成することができる。次の表は測定項目を示し、この
ロールアップ機構を定義し、そして測定項目をテーブル
およびカラムにマップする。ＤｉｓｐｌａｙＵｎｉｔ
（表示単位）カラムはＩｎｆｏＦｒａｍｅ^ＴＭの作成の
みに対するものである。Ｐｒｅｃｉｓｉｏｎ（精度）は
小数点の右側に必要な桁数である。Ｒｏｌｌｕｐ（ロー
ルアップ）に対するｅｎｕｍ値はａｄｄ（加算）、ａｖ
ｅｒａｇｅ（平均）、ｃｏｕｎｔ（カウント）である。

【０２９０】

【０２９１】基本の測定項目、ある種の二項および単項
の演算を組み合わせることによって複合測定項目、およ
びそれが示す特殊キーワードが作られる。例えば、ター
ゲット・セグメント、パーティションの子セグメント、
あるいは、ターゲット・セグメントの兄弟セグメントが
作られる。さらに、次の表を使って、１つの測定項目を
制限するために１組のセグメントを符号化することがで
きる。Ｌｅｆｔ−Ａｒｇ（左の引数）およびＲｉｇｈｔ
−Ａｒｇ（右の引数）はここに示されているように「Ｌ
ｅｆｔ−Ｍ（左のＭ）」または「Ｒｉｇｈｔ−Ｍ（右の
Ｍ）」の中の引数の種類を符号化する。１．基本測定項目２．複合測定項目３．「ターゲット・セグメント」４．「親セグメント」５．セグメント・リスト：２ｄの引数はＳｌｉｓｔのイ
ンデックス（次の表参照）である。６．兄弟セグメント７．子セグメント

【０２９２】Ｏｐの中の演算子が単項演算子「ｃｏｕｎ
ｔ（カウント）、ｓｕｍ（合計）、ａｖｅｒａｇｅ（平
均）」である場合、Ｌｅｆｔ−Ｍだけが使われる。Ｏｐ
の中の演算子が二項演算子（＋、−など）である場合
は、Ｌｅｆｔ−ＭおよびＲｉｇｈｔ−Ｍの両方が使われ
る。

【０２９３】

【０２９４】複合測定項目がセグメントのリストを指す
場合、そのリストの要素は次の表で表わされる。

【０２９５】

【０２９６】次の表はディメンション的なクエリーを評
価するために基本の測定項目と１つの属性を結合するた
めに使われる。その考えは、各属性（１つのテーブルお
よび１つのカラムにマップする）および各測定項目（こ
れも１つのテーブルおよび１つのカラムにマップする）
に対して、それらの２つのテーブルを結合（ｊｏｉｎ）
できる必要があるということである。この表は結合にお
いて使うことができる２つの等価カラム（キー）に対す
るカラム名を示す。

【０２９７】

【０２９８】次の表はディメンション的はクエリーを評
価するために２つの属性を一緒に結合するために使われ
る。すなわち、前の表（上記）がその測定項目に対する
ディメンション的なクエリーの中のすべての属性を結合
するのに不十分であった場合、この表をサーチして、こ
の表はすべての属性テーブルをすべての測定項目テーブ
ルと組み合わせるために複数の結合を生成するために使
うことができる属性の径路を見つけることができる。

【０２９９】

【０３００】測定項目間の関係は測定項目間の因果関係
の定性的な記述である。例えば、一般に、１つの製品に
対する「棚の空間」が増えた場合、「売上高」も同様に
増えると予測される。この例では、「棚のスペース」は
独立測定項目であり、「売上高」は従属測定項目であ
る。しかし、測定項目間の関係は因果関係および方向の
単純な文よりは複雑である。上記の例では「棚のスペー
ス」のすべての値について成立するのではなく、ある範
囲の値だけに成立すると期待される。同様に、「棚のス
ペース」がある程よいパーセントだけ増加した場合にの
み、その関係が成立すると期待することができる。ま
た、測定項目間の関係はあるセグメントに対してのみ成
立し、他のセグメントに対しては成立しないと期待され
る場合もある。

【０３０１】次の表は基本の測定項目間の関係を次のよ
うに定義する。カラムＩ−Ｄｉｒｅｃｔｉｏｎ（Ｉの方
向）はヘッダ・ファイルの中に定義されている１つの列
挙型の「ｄｉｒｅｃｔ（正方向）」または「ｉｎｖｅｒ
ｓｅ（逆方向）」のいずれかである。その値が「ｄｉｒ
ｅｃｔ」であった場合、その独立測定項目が上昇する
と、従属測定項目が上昇する筈である。その値が「ｉｎ
ｖｅｒｓｅ」であった場合、その独立測定項目が上昇す
ると、従属測定項目は下降する筈である。Ｉ−Ｄｉｒｅ
ｃｔｉｏｎに対するｅｎｕｍ値はｄｉｒｅｃｔ（正方
向）、ｉｎｖｅｒｓｅ（逆方向）である。

【０３０２】

【０３０３】次の表は測定項目間の関係を独立測定項目
の値のある範囲に制限する。演算は＞、＜、＞＝、＜
＝、＝、ｎｏｔ＝、またはｂｅｔｗｅｅｎである。ｂｅ
ｔｗｅｅｎの場合、Ｖａｌｕｅｌ（値１）とＶａｌｕｅ
２（値２）との両方が使われる。演算に対するｅｎｕｍ
値は、ｉｓｌｅｓｓｔｈａｎ（より小さい）、ｉｓ
ｇｒｅａｔｅｒｔｈａｎ（より大きい）、ｉｓｌｅ
ｓｓｔｈａｎｏｒ＝（より小さいかまたは等し
い）、ｉｓｇｒｅａｔｅｒｔｈａｎ（より大きいか
または等しい）、ｉｓ（等しい）、ｉｓｎｏｔ（等し
くない）、ｂｅｔｗｅｅｎ（間にある）、ｎｏｔｂｅ
ｔｗｅｅｎ（間にない）である。

【０３０４】

【０３０５】次の表は変動分析のアナリスト定義付きの
測定項目間の関係に対してのみ適用される。それは変動
分析の期間にわたって適切に従属測定項目が変化すると
きのみ測定項目間の関係が適用されるように制限する。
ｄｉｒｅｃｔｉｏｎ（方向）のｅｎｕｍ値は、ｉｎｃｒ
ｅａｓｅｓ（増加する）、ｄｅｃｒｅａｓｅｓ（減少す
る）である。

【０３０６】

【０３０７】次の表はセグメントごとに測定項目間の関
係の適用可能性を制限する。測定項目間の関係が与えら
れたセグメントに対して適用される場合、それはすべて
の子セグメントに対しても適用される。

【０３０８】

【０３０９】（ａ）時間はＭＤＴのＭｅｔａｄａｔａ
^ＴＭ２５の１つの重要な部分である。１つのレベルにお
いて、ユーザが別のディメンションとして時間のことを
考えることが望ましいが、しかし、時間のセグメントは
オン・ザ・フライで生成される可能性があるので（例え
ば、セグメント「年から日付へ」）、それらは異なって
表示される。この表示をテーブルの集合として示す。た
だし、その情報のいくつかはソース・コードのヘッダ・
ファイルの中で定義することができる。次の表はデータ
・ウェアハウス２４の中で表現される時間の細かさの最
低単位を定義する。ここでデータ・ウェアハウスの中の
時間のすべての表現はこの単独の時間の単位を使うこと
を仮定している。ＢａｓｅＵｎｉｔ（基本単位）に対
するｅｎｕｍ値は、ｄａｙ（日）、ｗｅｅｋ（週）、ｍ
ｏｎｔｈ（月）、ｙｅａｒ（年）である。

【０３１０】

【０３１１】データベースのテーブルが測定項目によっ
て使われる場合、そのテーブルはその中に時間に対する
１つのカラムを備えていなければならない。次の表は各
基本測定項目に対する時刻を表わす各テーブルに対する
カラムをリストしている。

【０３１２】

【０３１３】次の表はユーザ１４０５に対して重要であ
る可能性のある、年の異なる表記を定義する。Ｗｅｅｋ
ＳｔａｒｔＤａｙ（週の開始日）に対するｅｎｕｍ
値は、Ｓｕｎｄａｙ（日曜日）、Ｍｏｎｄａｙ（月曜
日）、Ｔｕｅｓｄａｙ（火曜日）…、Ｓａｔｕｒｄａｙ
（土曜日）である。

【０３１４】

【０３１５】

【０３１６】

【０３１７】シリアルＤＡＩ（Ｓ−ＤＡＩ）１４Ａ（図
２６）は各クライアント１２に対してＭＤＴのＭｅｔａ
ｄａｔａ^ＴＭ２５に対するアクセスを提供することを担
当する。クライアント１２がＭＤＴにログインすると
き、シリアルＤＡＩ１４Ａが生成され、そのクライアン
トのセッションに接続される。更新要求などの、Ｍｅｔ
ａｄａｔａ^ＴＭに対するすべてのクライアント要求はシ
リアルのＤＡＩ１４Ａによって処理される。さらに、そ
のＳ−ＤＡＩ１４ＡはＭＤＴアドミニストレータに対す
るアクセスを提供し、セットアップ画面を使ってＭＤＴ
を構成できるようにする。

【０３１８】シリアルＤＡＩのアーキテクチャーが図２
７に示されている。シリアルＤＡＩ１４Ａはクライアン
ト１２からＭＤＴメッセージの形式で要求を受け取る。
各ＭＤＴメッセージはＳ−ＤＡＩ１４Ａの中にそれ自身
の「応答クラス」を持っている。Ｍｅｔａｄａｔａ^ＴＭ
のアクセスおよび単純な更新のためのメッセージはＤＳ
Ｍ１６のＭｅｔａｄａｔａ^ＴＭテーブル・インターフェ
ースを通じて処理される（すなわち、Ｃｌａｓｓｉｃの
コンポーネント１４ＡＡを使わずに−下記に詳細に定義
される）。セグメントを追加または削除するための要求
はＣｌａｓｓｉｃのコンポーネント１４ＡＡを使ってそ
の要求を有効化し、そしてその階層を必要に応じて更新
する。

【０３１９】Ｍｅｔａｄａｔａ^ＴＭのアクセスおよび単
純な更新のサービスはＣｌａｓｓｉｃのコンポーネント
１４ＡＡを使わずに、シリアルＤＡＩ１４Ａによってク
ライアント１２に対して提供される。クライアント１２
が特定のＭｅｔａｄａｔａ^ＴＭを必要とするときは常
に、普通はユーザ・インターフェースの中で提示するた
めに、クライアント１２は要求メッセージをＳ−ＤＡＩ
１４Ａに対して送信する。Ｓ−ＤＡＩ１４Ａは適切なＭ
ｅｔａｄａｔａ^ＴＭのテーブル２５にアクセスして適切
なＭｅｔａｄａｔａ^ＴＭを抽出する。次に、それをパッ
ケージ化して１つまたはそれ以上のメッセージの中に入
れてクライアント１２に対して返す。Ｍｅｔａｄａｔａ
^ＴＭのインターフェースはパブリックのＭｅｔａｄａｔ
ａ^ＴＭおよびこの特定のユーザに対するＭｅｔａｄａｔ
ａ^ＴＭに対するアクセスを自動的に提供する。

【０３２０】データおよび制御の一般的な流れが図２８
に示されており、以下に説明される。・「ステップ２１０１」クライアント１２がＭｅｔａｄ
ａｔａ^ＴＭの要求メッセージをＳ−ＤＡＩ１４ＡＡに対
して送信する。このメッセージはそのメッセージ・タイ
プおよび必要なパラメータを含む。・ステップ２１０２」シリアルＤＡＩ１４Ａはそのメッ
セージ・タイプを調べ、どのＭｅｔａｄａｔａ^ＴＭテー
ブル２５が必要であるかを決定する。・「ステップ２１０３」そのパラメータを使って、Ｓ−
ＤＡＩは正しいＭｅｔａｄａｔａ^ＴＭを求めてＭｅｔａ
ｄａｔａ^ＴＭテーブル２５を走査する。・「ステップ２１０４」シリアルのＤＡＩ１４Ａはその
Ｍｅｔａｄａｔａ^ＴＭをパッケージ化する。・「ステップ２１０５」シリアルのＤＡＩ１４Ａは１つ
のＭｅｔａｄａｔａ^ＴＭメッセージをクライアント１２
に対して送り返す。

【０３２１】可能性は少ないが、エラーのイベントが発
生した場合、Ｓ−ＤＡＩ１４Ａはサーバのエラー・ログ
の中にそのエラーをログし、クライアント１２に対して
エラー・コードを返す。各種の重要度の各種のエラーが
あり得る。ユーザ・インターフェースを使ってクライア
ント１２から新しい複合測定項目が追加される。そこで
任意の構文チェックまたは意味チェックが行われる。複
合測定項目に対する構文は上で示されている。新しい複
合測定項目が生成されたことをクライアント１２が示す
と、シリアルＤＡＩはその情報を前記の適切なＭｅｔａ
ｄａｔａ^ＴＭテーブルに対して追加する。

【０３２２】測定項目ビルダ画面の中で既存の測定項目
をプルアップし、それを編集し、そしてＳａｖｃ（保
存）ボタンを押すことによって、既存の複合測定項目を
更新することができる。編集された複合測定項目は同じ
複合測定項目のＩｄを使ってＭｅｔａｄａｔａ^ＴＭテー
ブルー２５に対して保存される。クライアント１２はユ
ーザ１４０５に対する警告メッセージを表示してこの測
定項目が１つのアナリストの中で使われている場合、そ
れ以降のＩｎｆｏＦｒａｍｅ^ＴＭの中に示される結果の
意味が異なることになる。複合の測定項目がユーザによ
って所有されている場合、それを削除することができ
る。複合測定項目およびその式のエントリは前記の該当
のテーブルから削除される。警告メッセージがユーザ１
４０５へ提示され、この複合測定項目がどれかのアナリ
ストによって、あるいは他の複合測定項目によって使わ
れている可能性があることを警告し、それ以降のＩｎｆ
ｏＦｒａｍｅ^ＴＭは正しく作成されず、「アナリスト−
時間」のエラーが発生する。

【０３２３】新しい測定項目間の関係を追加すること
は、新しい複合測定項目を追加するのと類似している。
すべてのチェック（ある場合）はクライアント１２の中
で発生する。クライアントが、新しい測定項目間の関係
が生成されたことを示すと、シリアルＤＡＩ１４Ａはそ
の情報を該当のＭｅｔａｄａｔａ^ＴＭテーブルに追加す
る。測定項目間の関係を変更することは簡単である。該
当のテーブルが更新され、そしてその測定項目間の関係
のＩｄが保存される。測定項目間の関係はそれがユーザ
１４０５によって所有されている場合に削除することが
できる。その測定項目間の関係およびそのテーブルのエ
ントリは該当のテーブルから削除される。警告メッセー
ジがユーザに対して提示され、この測定項目間の関係が
アナリストによって使われている場合、それ以降のＩｎ
ｆｏＦｒａｍｅ^ＴＭは完了せず、そして「アナリスト・
タイム」のエラーが発生することを警告する。

【０３２４】また、シリアルＤＡＩ１４ＡはＭＤＴアド
ミニストレータからの要求も処理する。これらの要求は
ＭＤＴをインストールするため、およびパブリックのＭ
ｅｔａｄａｔａ^ＴＭに対する時々の変更を行うために使
われる。シリアルＤＡＩ１４Ａはデータ・ウェアハウス
２４からクライアント１２（データ・ウェアハウスのス
キーマ情報およびＭｅｔａｄａｔａ^ＴＭの両方を送信し
ている）に対する情報、およびクライアント１２からデ
ータ・ウェアハウス２４への情報（この場合にはＭｅｔ
ａｄａｔａ^ＴＭに対してのみ）の流れを処理しなければ
ならない。シリアルＤＡＩ１４Ａはデータそのものにつ
いての何らかの処理を行うこと、すなわち、完全性また
は例外のチェックを追加して行うことは期待されていな
い。

【０３２５】データ・ウェアハウスのスキーマは１つの
解釈されないハンドルでクライアント１２に対して渡さ
れ、クライアント１２がそれを解釈する。ＭＤＴをセッ
トアップあるいはインストールするためのステップが８
ステップある。各ステップはクライアント１２がアドミ
ニストレータからの情報をユーザ・インターフェースを
通じて受け取り、情報をＳ−ＤＡＩ１４Ａに対して渡す
ことに関係する。Ｓ−ＤＡＩ１４ＡはＤＳＭインターフ
ェースを通してＭｅｔａｄａｔａ^ＴＭのテーブルを更新
する。これらのステップは次のとおりである。１．ディメンションを定義する２．データベースのカラムに対して属性を定義し、そし
てマップする３．符号化された属性値をリネームする４．基本のセグメントを生成する５．基本の測定項目をデータベースのカラムに対して定
義し、そしてマップする６．データベース・テーブル間の結合を再チェックする７．データベースのカラムを時間のマーカとして割り当
てる８．年のタイプを定義する

【０３２６】前に説明されているように、ユーザのセグ
メントおよびパーティションの階層を表わすためにＣｌ
ａｓｓｉｃのコンポーネント１４ＡＡが使われる、ユー
ザが１つのセグメントを追加、変更、または削除すると
き、Ｃｌａｓｓｉｃのコンポーネント１４ＡＡはそのセ
グメント／パーティションの階層に対して行われる必要
がある任意の、そしてすべての変更を決定し、あるいは
いくつかの可能な種類のエラーの１つを検出する。エラ
ーがなかった場合、これらの変更は次にクライアントの
インターフェースおよびこの永続的なＭｅｔａｄａｔａ
^ＴＭテーブルを更新するために使われる。これは図２９
に示されている。・「ステップ２２０１」クライアント１２はセグメント
・メッセージの追加、削除、または変更のいずれかであ
るセグメント更新要求を送信する。・「ステップ２２０２」Ｓ−ＤＡＩはその要求を受信す
る・「ステップ２２０３」次にＳ−ＤＡＩはＣｌａｓｓｉ
ｃのモジュールの中の適切な関数を呼出す。その関数は
Ｃｌａｓｓｉｃを使ってその要求によって誘導されるセ
グメント／パーティションの変更のすべてを決定する。・「ステップ２００４」これらの変更（または適切なエ
ラー状態）が返される。エラーがあった場合、これはＭ
ｅｔａｄａｔａ^ＴＭのテーブルを変更せずにクライアン
トに対して戻される。・「ステップ２２０５」エラーがなかった場合、すべて
の変更がＭｅｔａｄａｔａ^ＴＭのテーブルへ渡される。・「ステップ２２０６」ふたたび、エラーがなかったと
仮定して、アクノレッジ・メッセージがクライアントに
対して送られる。・「ステップ２２０７」知識ベースが変更された場合、
該当の知識ベースのファイルが更新される。

【０３２７】ユーザのセグメントの階層はサーバのディ
スク上の知識ベース・ファイルの中に永続的に保管され
る。これはそれをＭｅｔａｄａｔａ^ＴＭのテーブルから
常にそれをそれぞれ再生成するには時間が掛かりすぎる
からである。各ディメンションおよび各ユーザに対して
１つの知識ベース・ファイルがある。各ファイルはサー
バのディスク上のあるエリア内にあり、「ｄｉｍｅｎｓ
ｉｏｎ．ｕｓｅｒ」と命名されている。

【０３２８】ユーザ１４０５は既存のセグメント（おそ
らくトップ・レベルのセグメント）を選択することによ
って、そして一連の属性および制限事項を選択すること
によって、新しいセグメントを追加する。このシーケン
スはパーティションおよび属性のシーケンスを定義す
る。［年齢＞６５、収入＞１００Ｋ］の属性および制限
事項の集合を考える。このセグメントは「裕福な年配者
（ＷｅａｌｔｈｙＳｅｎｉｏｒｓ）」と呼ばれる。こ
れはそのセグメントがトップ・レベルにおいて定義され
たと仮定して、次のシーケンスを表示させる。

【３０２９】すべての顧客［Ｂｙ−Ａｇｅ（年齢別）］＜＝その属性によって命
名されたパーティション年齢＞６５＜＝自動的に命名された中間セグメント［Ｂｙ−Ｉｎｃｏｍｅ（収入別）］裕福な年配者＜＝ユーザ定義のそしてユーザ命名のセグ
メント

【０３３０】属性の順序は非常に重要である。すなわ
ち、最終セグメント「裕福な年配者」は収入によって、
そして次に年齢によって定義され、同じ結果の最終セグ
メントとなる。しかし、自動的に生成された中間セグメ
ントおよび２つの自動的に生成されたパーティションは
異なることになる（この場合、第一のパーティションは
「Ｂｙ−Ｉｎｃｏｍｅ（収入別）」であり、中間セグメ
ントは「収入＞１００」となり、そして第２のパーティ
ションは「年齢別」となる。）。

【０３３１】次のガイドラインが新しいセグメントの生
成に対してサポートされる。１．最終のユーザ命名型のセグメントが生成される２．「サポートしている」パーティションおよびセグメ
ントは自動的に生成されて命名されるが、それはユーザ
１４０５によって作成された属性の順序でのみ行われ
る。３．最終セグメントが既存のどれかのパーティション
の子であった場合、それは同様に「そこに現われる」。４．最終セグメントが既存のセグメントと単独の属性
だけ違っている場合、中間のサポート・パーティション
が１つ生成される。５．どれかのセグメントが新しいセグメントの下に分
類され、そして１つの属性だけが違っている場合、その
該当するパーティションが生成される。上記のガイドライン４を説明するために、顧客の階層が
次のようになっていると仮定する。

【０３３２】すべての顧客［収入別］中程度の収入高収入

【０３３３】そのユーザは上記のように「裕福な年配
者」を定義する。その階層はここでは次のように見え
る。

【０３３４】すべての顧客［年令別］年令＞６５［収入別］裕福な年配者［収入別］中程度の収入高収入［年令別］裕福な年配者＜＝セグメントおよびパーティションが
自動的に追加される。

【０３３５】同様に、ユーザ１４０５が新しいセグメン
トに追加する時、単独の属性によって異なるそのセグメ
ントの下に属している既存のセグメントがある場合、そ
の既存のセグメントは新しいセグメントの下に配置さ
れ、そして新しいパーティションが生成される。セグメ
ント／パーティションの階層はやや奇妙なものである。
それはそのディメンションに対する「トップレベルのセ
グメント」に根ざしている。そのディメンションは属性
の制限のない１つのセグメントである。それが「ＡＬＬ
−Ｘ」を表す理由である。ここでＸはディメンション
で、属性の制限のないセグメントである。（それが「Ａ
ＬＬ−Ｘ」を表す理由である。ここでＸは顧客または製
品などのディメンションである）。各セグメントはいく
つかの子パーティションを備えている。各パーティショ
ンは単独の属性によるセグメンテーションを表し、そし
ていくつかの子セグメントを持っている。１つのセグメ
ントはいくつかのパーティションに属することができ
る。１つのパーティションはただ１つの親セグメントを
持っている。

【０３３６】ユーザ１４０５は開始セグメントまたは親
セグメントを選択し、最終セグメントに対する名前を選
定し、そして次に一組の属性および制限事項をそのユー
ザのインターフェースの中に入力することによって、新
しいセグメントを生成する。属性の各制限に対して１つ
のセグメントが生成され（ユーザが選定した順序で）、
セグメント／パーティションの階層に追加される。１つ
のセグメントが追加される時、パーティションはその新
しいセグメントの上および下の両方に生成される必要が
ある可能性がある。

【０３３７】図３０はセグメントの追加（一般性を失わ
ずに、その親から１つの属性制限だけが違っているも
の）の追加を示している。先ず最初に、新しいセグメン
トはその指定された親の下にあるパーティションに「フ
ィットしなければならない。その新しいセグメントが既
存のパーティションまたは複数のパーティションにフィ
ットした場合、それはそれらのパーティションに対して
追加される（参照番号２３０１）。フィットしなかった
場合、新しいパーティションが生成される（参照番号２
３０２）。すべての新しいパーティションのように、他
のセグメントはフィットして追加される。その新しいセ
グメントの他のすべての親（Ｃｌａｓｓｉｃの場合はす
べての親）先ず最初にその新しいセグメントと親が１つ
の属性だけ違っていることを確認する。その場合、参照
番号２３０３における親において成立するように、ふた
たび既存のパーティション（参照番号２３０４）に対し
て追加するか、あるいは新しいものを生成する。（参照
番号２３０５における親は２つ以上の属性だけ異なる。
これは介在しているセグメントの順序を知らないことを
意味する。したがって、それを孤立させる。）最後に、
その新しいセグメントの子セグメント（参照番号２３０
６のような）（Ｃｌａｓｓｉｃの場合はセグメントの子
であるという）は新しいパーティション、あるいは参照
番号２３０７のような既存のパーティションにフィット
される。

【０３３８】次に、新しいセグメントをユーザの階層に
対して追加するためのアルゴリズムについてごく簡単に
説明する。Ｃｌａｓｓｉｃ１４ＡＡが使われる時、これ
は「アンダーラインを付けること」によって示される。入力：親セグメントおよび新しいセグメント（ＮＥ
Ｗ）。新しいセグメントは単独の属性制限が追加された
ものから構成される。ユーザ１４０５が２つ以上の属性
制限を入力すると、この基本のアルゴリズムは何回が呼
び出され、その中間のセグメントに対して名前が作成さ
れる。

【０３３９】ＮＥＷに対して一時的なＣｌａｓｓｉｃの
セグメントを生成する。ＮＥＷが既存のセグメントと同
一である場合は戻る。／^＊各親に対して：そのレベル差が１であることをチェックする。既存のパーティションに対してセグメントを追加するか、あるいはパーティションを生成し、セグメントを追加し、次に追加のセグメントを追加する。 ^＊／「ＮＥＷの親セグメントを得る」ｆｏｒ各親｛ｉｆ「レベル差＝＝１」｛ｆｉｔｓ＿ｌｆａｇ＝ＦＡＬＳＥ；ｆｏｒこのセグメントの各子パーティション｛Ｉｆそのセグメントがこのパーティション内にフィットする｝ｆｉｔｓ＿ｆｌａｇ＝ＴＲＵＥ；そのパーティションに対してそのセグメントを追加する｝｝ｉｆ（！ｆｉｔｓ＿ｆｌａｇ）｛その親の下に新しいパーティションを生成するそのパーティションに対してそのセグメントを追加するｆｏｒ現在の親の他のすべての子｛ｉｆ「その子がこの新しいパーティションにフィットする」それをそのパーティションに追加する｝｝｝｝／^＊ここでそのセグメントはそのすべての親に対して追加されている。Ｆｏｒその新しいセグメントのすべての子：そのレベル差が１であるかどうかチェックするそれを既存のパーティションに対して追加するか、あるいは１つ生成する ^＊／「セグメントＮＥＷの子を得る」Ｆｏｒ各子｛ｉｆ「レベル差＝＝１｛ｆｏｒＮＥＷの各子パーティション｛ｉｆ子がパーティションにフィットする｛それをそのパーティションに追加するｆｉｔｓ＿ｆｌａｇ＝ＴＲＵＥ｝ｅｌｓｅ｛ＮＥＷの下に新しいパーティションを１つ生成するそれに対してその子を追加する｝｝｝

【０３４０】セグメントの削除は非常に技巧的となる可
能性がある。それは単独のセグメントが削除される時に
は階層の中に各種の変化が発生する可能性があるためで
ある。設計によって削除されるセグメントの子は他のど
のパーティションもそれを参照していない場合にそれ自
身が削除される必要がある。

【０３４１】図３１を参照して：すべての親パーティションについて［２４０１］その親／セグメントのリンクを取り除く［２４０２］他のセグメントがない場合、そのパーティ
ションを削除する。その親セグメントのすべての子について［２４０４］それらがそのパーティションに現在「フィ
ットしている」かどうかを調べる。すべての親パーティションに対して［２４０５］それらが冗長であるかどうか、および「壊
されている」可能性があるかどうか調べる。すべての子パーティションについて［２４０６］そのセグメント／パーティションのリンク
を取り除く［２４０７］そのパーティションを削除するすべての子セグメントについて［２４０８］その子セグメントのリンクを削除する［２４０９］それらに親パーティションがない場合、削
除する［２４１０］そのセグメントを削除する

【０３４２】最終パーティションの中の明示的なセグメ
ントによって捕捉されないエンティティを表す「その他
の」セグメント（ここでは「ＯＳ」と呼ばれている）に
ついては以前に説明した。例えば、次のように見える階
層において

【０３４３】すべての顧客［年令別］年令＞６５［収入別］裕福な年配者

【０３４４】パーティション「収入別」の下のＯＳは６
５才より上の年齢の人であるが、その人の収入では裕福
な生活ができない人達を表すことになる。ＯＳは階層の
中で明示的には表されない。これはその定義がどんなセ
グメントが存在しているかによって変わるためである。
例えば、ユーザが「中間クラスの年配者」と呼ばれるセ
グメントを追加した場合、ＯＳの定義は変化することに
なる。むしろ、そのＯＳは暗黙になっていて、その属性
の制限がその兄弟セグメントの制限を取ってそれらをネ
ゲートすることによって計算することができる。

【０３４５】ユーザ１４０５が最初にログインする時、
あるいはセグメントの更新要求が受信された時のいずれ
かにおいて、Ｃｌａｓｓｉｃの知識ベースは永続的なＭ
ｅｔａｄａｔａ^ＴＭテーブル２５から初期化されなけれ
ばならない。各ディメンションおよびそのそれぞれのセ
グメントおよびパーティションを別々の知識ベースとし
て扱うことができる。その初期化は次の２つの方法で実
行できる。（１）Ｃｌａｓｓｉｃ１４ＡＡに対する直接
の呼出しを行うことによって、（２）Ｃｌａｓｓｉｃ１
４ＡＡが読むことができるＡＳＣＩＩのフラット・ファ
イルを生成することによって。前者がおそらくより効率
的であるが、デバッグおよびエラー時のキャンセルの場
合に有利である可能性がある。Ｃｌａｓｓｉｃの知識ベ
ースを生成するための一般的なステップは前に定義され
たテーブルを参照して次のように行なわれる。

【０３４６】・各ディメンションに対して、ディメン
ションの定義テーブルから読み出す。 ⇒ そのディメンションに対して個別にディメンション
・フィラーを定義する。 ⇒ 各数値属性または文字列属性に対して ◇ その属性の役割を定義する ⇒ 列挙型の各属性に対して ◇ その属性の役割を定義する ◇ プリミティブ「フィラー」を定義する ◇ 列挙型の各属性の値に対して^＊個々にその値を定義する ⇒ 各セグメント定義に対して ◇ すべての属性制限事項を得る ◇ そのセグメントを定義する ◇ そのセグメントを個々に定義する ⇒ すべてのパーティションに対して ◇ １つの個別パーティションを生成する ⇒ セグメントから子パーティションへのすべてのマッ
ピングに対して ◇ 個別のセグメントに対して個別のパーティションを
追加することによってマッピングを生成する ⇒ パーティションから子セグメントへのすべてのマッ
ピングに対して ◇ 個別のパーティションに対して個別のセグメントを
追加することによってマッピングを生成する

【０３４７】ＭＤＴのビジネス・レベルのユーザおよび
ＭＤＴアドミニストレータ（またはアナリスト・レベル
のユーザ）の両方によるＭｅｔａｄａｔａ^ＴＭの追加、
削除、および編集（変更）を含んでいる、Ｍｅｔａｄａ
ｔａ^ＴＭの修正について以下に説明する。Ｍｅｔａｄａ
ｔａ^ＴＭを修正することはそれを変更することを意味す
る。１つの実施形態においては、シリアルＤＡＩ１４Ａ
およびクライアント・インターフェースによってサポー
トされる３種類の変更、すなわち、追加、削除、および
編集がある。それにかかわるＭｅｔａｄａｔａ^ＴＭの種
類は通常はセグメント、複合測定項目、および測定項目
間の関係を含んでいる。Ｍｅｔａｄａｔａ^ＴＭを修正す
るユーザ１４０５の種類は、通常の（あるいは「レベ
ル」ユーザ）、およびＭＤＴアドミニストレータまたは
アナリスト・レベルのユーザの２種類があり、その両方
共この文章の中ではＭＤＴＡとして参照される。ＭＤＴ
ＡはパブリックなＭｅｔａｄａｔａ^ＴＭを編集する別の
ユーザとして考えられるのが普通であるが、必ずしも常
にそうではない。ここでは一般にマッピングおよび結合
の情報などのＭＤＴの他の種類のＭｅｔａｄａｔａ^ＴＭ
を変更するＭＤＴＡについては一般的には考えない。次
の表はこれらの組合せを要約している。

【０３４８】

【０３４９】Ｍｅｔａｄａｔａ^ＴＭの修正はセグメント
・ビルダ、測定項目ビルダ、測定項目間の関係ビルダお
よびいくつかのセットアップ画面を含んでいるクライア
ント・インターフェースを通じて行なわれる。制御の一
般的な流れはクライアント１２からシリアルＤＡＩ（Ｓ
−ＤＡＩ）１４Ａへ、セグメントが関与している場合は
Ｃｌａｓｓｉｃのコンポーネント１４ＡＡへ、そして次
にＭｅｔａｄａｔａ^ＴＭのテーブル２５への流れであ
る。各種のマッピングおよびエラーがユーザ１４０５に
対して適宜定義される。

【０３５０】Ｍｅｔａｄａｔａ^ＴＭの修正は２つの理由
のために事項的になる。先ず第１に、Ｍｅｔａｄａｔａ
^ＴＭの間に依存性が存在する。例えば、複数のセグメン
トと１つのセグメントを参照する複合測定項目との間の
依存性、あるいはＭＤＴＡによって管理されている「パ
ブリック」Ｍｅｔａｄａｔａ^ＴＭと、各種のユーザのプ
ライベートＭｅｔａｄａｔａ^ＴＭとの間の依存性であ
る。第２に、スケジュールされているかいないかにかか
わらず、定義されているアナリストは修正されたＭｅｔ
ａｄａｔａ^ＴＭに対して参照する可能性がある。いくつ
かの重要な問題点が対処されなければならない。例え
ば、

【０３５１】１．欠落しているＭｅｔａｄａｔ
ａ^ＴＭ、すなわち、削除されたＭｅｔａｄａｔａ^ＴＭに
対してアナリストが参照する時にどんなことが起こるか
？２．Ｍｅｔａｄａｔａ^ＴＭが削除され、他のＭｅｔａ
ｄａｔａ^ＴＭがそれを参照する時にどんなことが起こる
か？３．ＭＤＴＡがパブリック・セグメントを変更する
時、そのユーザのセグメント階層がどのように更新され
るか？４．ＭＤＴＡがディメンション、属性、または基本測
定項目を削除する時にどんなことが起こるか？

【０３５２】対策の範囲において２つの極端な方法を想
像することができる。１つは、まったく何もチェックし
ない（「ユーザまかせの」方式）であり、二つ目はすべ
ての潜在的な問題を捕捉して防止しようとする方式であ
る。１つの好ましい実施形態においては、本発明はスペ
クトルの「ユーザ任せ」側に近いように設計することが
できる。ただし、他の適切な設計も実装可能である。こ
のことを前提にして、利用できる時はユーザ１４０５に
警告および情報を与え、可能な限り警告、確認なしでユ
ーザ１４０５を驚かすようなことは何もしないようにす
ることが望ましい。

【０３５３】コンカレントＤＡＩ（ＣＤＡＩ）１４Ｂ
（図２６）はＩｎｆｏＦｒａｍｅ^ＴＭを作成するＭＤＴ
サブシステムである。それの入力はクライアント１２ま
たはスケジューラ・サブシステム１８からのＩｎｆｏＦ
ｒａｍｅ^ＴＭ要求であり、それの出力はユーザのリター
ン・エリア内のファイルの中に含まれている外部ＨＴＭ
Ｌテキスト・レポートを含んでいる１つのＩｎｆｏＦｒ
ａｍｅ^ＴＭである。それがどのように構造化されている
か、および結果のレポートのフォーマットを含めて、Ｃ
ＤＡＩサブシステム１４Ｂの動作を以下に説明する。

【０３５４】ＣＤＡＩ１４ＢはＵＮＩＸ^ＴＭまたはＮＴ
のサーバ・プラットフォーム上で実行している、ＵＮＩ
Ｘ^ＴＭまたはＮＴのプロセスである。それは次のような
コマンド行によるディスパッチャ・コンポーネントによ
って呼び出される。ｍｄｔｑｕｅｒｙｅｎｇｉｎｅ［−ｃ＜ｃｏｎｆｉｇ
＞］［−ｅ＜ｅｒｒｌｏｇ＞］ここでｃｏｎｆｉｇ名およびｅｒｒｌｏｇ名はそれぞ
れ、マスタがそれを呼び出す時にマスタのコマンド行か
らディスパッチャによって継承された、オプションのコ
ンフィギュレーション・ファイルおよびエラー・ログの
名前である。

【０３５５】ＣＤＡＩの１４Ｂ機能の或る特徴はコンフ
ィギュレーション・ファイルで定義されている属性の値
によって決定することができる。これらの属性値は関心
の度合のヒューリスティック、ローカライゼーション・
パラメータなどに対するしきい値を指定する。ＣＤＡＩ
１４Ｂはユーザに対するＩｎｆｏＦｒａｍｅ^ＴＭおよび
ＭＤＴアドミニストレータに対するエラー・ログをロー
カルのテキストの中に発生する。しかし、ユーザのロー
カル（および言語）はアドミニストレータのそれとは同
じではない可能性がある。この理由で、ＣＤＡＩ１４Ｂ
はローカライズされたテキストを収集するために２つの
メッセージ・カタログを参照することができる。ネイテ
ィブのカタログはＩｎｆｏＦｒａｍｅ^ＴＭに対するロー
カライズされたテキストに対するソースとして使われ
る。エラー・カタログはエラー・ログに対するローカラ
イズされたテキストのソースとして使われる。

【０３５６】作成されたＩｎｆｏＦｒａｍｅ^ＴＭのテキ
ストはローカライズ可能である。測定項目、セグメン
ト、および期間のローカライズされた名前はクライアン
ト１２によって提供されるか、あるいはＭｅｔａｄａｔ
ａから抽出される。他のテキストはＭＤＴのメッセージ
・カタログの中にパラメータ化された文字列として保管
される。これはネイティブ・カタログとして知られてい
る。ＣＤＡＩ１４Ｂはコンフィギュレーション・ファイ
ルに含まれているＭｓｇＣａｔａｌｏｇＰａｔｈ属性の
値、およびクライアントによって提供されているＩＳＯ
の言語名から、ネイティブ・カタログの名前を計算す
る。ＭＤＴアドミニストレータの言語でのエラー・ログ
を作成するために、別のカタログがキープされているこ
とが好ましい。

【０３５７】ＣＤＡＩ１４Ｂは１つのｍｄｔ＿Ｉｎｆｏ
ＦｒａｍｅＲｅｑｕｅｓｔオブジェクトをＲＵＮ＿ＡＮ
ＡＬＹＳＴ＿ＲＥＱＵＥＳＴメッセージの中に受け入れ
る。その要求は作成されるべきＩｎｆｏＦｒａｍｅ^ＴＭ
を記述している、１ｎｆｏＦｒａｍｅＤｅｆｉｎｉｔｉ
ｏｎ（ｍｄｔ＿ＩｎｆｏＦｒａｍｅＤｅｆｉｎｉｔｉｏ
ｎ）を含むことができる。それはＩｎｆｏＦｒａｍｅ
^ＴＭのタイプ、レポートされるべきセグメント、レポー
トされるべき測定項目、およびレポート対象の期間を指
定することができる。１つの実施形態においては、次の
５種類のレポートがある。

【０３５８】・「要約化（Ｓｕｍｍａｒｉｚａｔｉｏ
ｎ）」−１つのターゲット・セグメント上のターゲット
測定項目の基本分析・「変動分析（ＣｈａｎｇｅＡｎａｌｙｓｉｓ）」−
２つの別々の期間についての、および１つのターゲット
・セグメントについてのターゲット測定項目の違いの要
約化・測定項目比較（ＭｅａｓｕｒｅＣｏｍｐａｒｉｓｏ
ｎ）」−１つのターゲット・セグメントについての２つ
の期間の間の差の要約化・セグメント比較（ＳｅｇｍｅｎｔＣｏｍｐａｒｉｓ
ｏｎ）」−２つの別々のターゲット・セグメント上での
同じ測定項目の間の差の要約化・「トレンド分析（ＴｒｅｎｄＡｎａｌｙｓｉｓ）」
−ターゲット測定項目と関連の測定項目における、ター
ゲット・セグメントと関連のセグメントについての、時
間軸上での傾向のレポート

【０３５９】その要求はＩｎｆｏＦｒａｍｅ^ＴＭＴｒｉ
ｇｇｅｒ（ｍｄｔ＿ＩｎｆｏＦｒａｍｅＴｒｉｇｇｅ
ｒ）を含むことができる。そのトリガはデータ・ウェア
ハウス２４およびＡｌｅｒｔフラグの中のいくつかの条
件に対するテストを定義する。そして、「ネストされ
た」ＩｎｆｏＦｒａｍｅ^ＴＭ要求を含むことができ
る。その要求がトリガを含んでいる場合、ＣＤＡＩ１４
Ｂはその条件が「真」であればＩｎｆｏＦｒａｍｅ^ＴＭ
だけを実装しなければならない。その条件が「真」であ
る場合、ＣＤＡＩ１４Ｂは、Ａｌｅｒｔフラグが「真」
であれば、アラートを発生し、トリガがネストされた要
求を含んでいる場合は、そのネストされた要求を実行す
る。一般に、ＣＤＡＩ１４Ｂの出力はローカライズされ
て拡張されたＨＴＭＬのレポートを含んでいるＩｎｆｏ
Ｆｒａｍｅ^ＴＭオブジェクトとなる（図１９参照）。そ
のＩｎｆｏＦｒａｍｅ^ＴＭはユーザ・リターン・エリア
（下で定義される）の中のファイルに書き込まれる。

【０３６０】ユーザ・リターン・エリアはコンフィギュ
レーション・ファイルのＵｓｅｒＲｅｔｕｒｎＡｒｅａ
Ｐａｔｈパラメータによってパスが与えられるディレク
トリである。ＩｎｆｏＦｒａｍｅ^ＴＭが正しく完了する
と、そのレポートはＩＮＦ．＜ＵＩＤ＞．＜ＵＮＱ＞と
名付けられる。ここでＵＩＤはユーザＩＤであり、ＵＮ
Ｑはこのファイル名がこのユーザに対して作成された他
のすべてのファイル名とは異なっている（ユニークであ
る）ことを保証する何らかの文字列である。

【０３６１】ユニークな識別子はディスパッチャがＣＤ
ＡＩ１４Ｂを立ち上げる時にディスパッチャによって発
生され、そしてＩｎｆｏＦｒａｍｅ^ＴＭ要求を伴うＣＤ
ＡＩ１４Ｂがそれを利用できるようにする。レポートご
とにユニークな名前が必要なので、ＣＤＡＩ１４Ｂのイ
ンスタンスはレポートを１つだけしか発生することがで
きない。ＩｎｆｏＦｒａｍｅ^ＴＭ要求が２つ以上のレポ
ートを指定した場合、トリガされた要求がアラート・レ
ポートおよび「その」レポート以外に「その他の」レポ
ートを必要とする時、その要求を受け付けているＣＤＡ
Ｉ１４Ｂはこの多重のレポートを処理するために新しい
ＣＤＡＩ１４Ｂをディスパッチする必要がある。

【０３６２】これらの拡張はクライアント・ビューワに
よって解釈される。そのレポートはＩｎｆｏＦｒａｍｅ
^ＴＭレポート、アラート・レポートまたはエラー・レポ
ートのいずれかを含む。ＩｎｆｏＦｒａｍｅ^ＴＭレポー
トはＣＤＡＩ１４ＢがＩｎｆｏＦｒａｍｅの定義を正し
く完成した時に作成される。それはｉｆｇｎ＿Ｒｅｐｏ
ｒｔクラスによって作成される。アラート・レポートは
ＩｎｆｏＦｒａｍｅ^ＴＭ要求がトリガを有していて、そ
のトリガが「真」に評価され、Ａｌｅｒｔフラグがセッ
トされている時に作成される。それはｉｆｇｎ＿Ａｌｅ
ｒｔＦｒａｍｅクラスによって作成される。エラー・フ
レームはＣＤＡＩ１４ＢがトリガまたはＩｎｆｏＦｒａ
ｍｅ^ＴＭの定義を評価できず、それについて知らせるた
めにある時に作成される。それはｉｆｇｎ＿Ｅｒｒｏｒ
Ｆｒａｍｅクラスによって作成される。

【０３６３】ＩｎｆｏＦｒａｍｅ^ＴＭレポート（図１９
参照）の内容は、要求される分析のタイプによってだけ
でなく、対象となった測定項目によっても大きく変化す
る可能性がある。そのレポートは例えば、ヘッディン
グ、４つの黒丸付きのパラグラフ、テーブルなど、各種
の方法で編成することができる。「ヘッディング」−アナリストが定義されてそのセグメ
ント、測定項目および分析される期間を命名する時、そ
してそのアナリストがトリガ、そのトリガの条件および
そのトリガ条件が満足された時刻を持っていた場合、ユ
ーザによって提供されたアナリスト記述を引用する。

【０３６４】・「ターゲット・セグメント・レポート」
−次のものを含む黒丸印付きのパラグラフ「ターゲット・セグメント」−アナリストの定義の中で
直接指定されているセグメントと期間についての測定項
目に対する結果を強調表示しているテキスト。追加のテ
キストはこのセクションではレポートされない。「親の貢献」−ターゲット・セグメントによってその親
セグメントに対してなされた重要な貢献を強調表示して
いる黒丸印付きのパラグラフ。そのターゲット・セグメ
ントがトップ・レベルのセグメントである場合、または
そのターゲット測定項目が１つの親セグメントに対する
参照を含んでいる時はこのセクションは含まれない。「兄弟比較」−ターゲット・セグメントの値のその兄弟
セグメントの値に対する興味深い比較を提供している、
黒丸印付きのパラグラフ。そのターゲット・セグメント
がトップ・レベルのセグメントである時は、このセクシ
ョンは含まれない。「兄弟グラフ」−兄弟セグメントの値を示しているバー
・チャートまたはパイ・チャート、あるいは傾向を示し
ている線グラフ。ドリル・ダウン・セグメントがある場
合は、このグラフは作られない。

【０３６５】・「ドリル・ダウン」−ドリル・ダウン・
パーティションの中の子セグメントの値とターゲット・
セグメントに対する値との間の興味深い関係を強調表示
している黒丸印付きのパラグラフ。ドリル・ダウン・パ
ーティションはユーザがアナリスト定義の中で指定する
ことができる。ユーザがドリル・ダウン・パーティショ
ンを何も指定しなかった場合、ＭＤＴは１つまたはそれ
以上の興味深いパーティションを自動的に選定する。そ
れらがどのように自動的に選定されるかを知るには、ド
リル・ダウン・パーティションの選定についての下記の
セクションを参照されたい。子パーティションが存在せ
ず、そして生成する制限の付いていない属性が存在しな
い時、あるいは興味深い既存の、または生成されたパー
ティションがない場合、このセクションは含まれない。

【０３６６】「ドリル・ダウン・グラフ」−ドリル・ダ
ウン・セグメントに対する値を示しているバー・チャー
トまたはパイ・チャート、あるいは傾向を示している線
グラフ。興味あるドリル・ダウン・セグメントがない場
合、このグラフは作られない。・「式の分解」−そのコンポーネント測定項目の複合測
定項目に対する興味深い貢献を強調表示している黒丸印
付きのパラグラフ。ターゲット測定項目が複合測定項目
である時だけ、このセクションが含まれる。・「測定項目間の関係」−ターゲット測定項目の２つの
値の間の差（あるいは、測定項目比較分析のためのター
ゲットと比較測定項目との間の差）のあり得る原因を記
述している黒丸印付きのパラグラフ。要約化分析は測定
項目間の関係のグラフを含んでいない。

【０３６７】「テーブル」−その分析の間にレポートさ
れたすべての測定項目値を示しているテーブル。親、タ
ーゲットまたは比較のセグメント以外のセグメントはハ
イパーリンクとしてマークすることができる（ふたた
び、例えば、図１９参照）。下線付きのＨＲＥＦはター
ゲット・セグメントとしてのこのセグメントを同じタイ
プの新しいアナリストに対して、同じ測定項目、比較、
および期間に対して置き換えるために必要な情報を含
む。

【０３６８】アラート・レポートはずっと簡単である。
その最も興味深い特性は、アナリスト名に対するハイパ
ーリンクである。ＩｎｆｏＦｒａｍｅ^ＴＭ要求が定義さ
れた時、そのイベントについてのより多くの情報をオプ
ションとして集めるために１つのアナリストを定義して
おくことができる。ハイパーリンクを選択することによ
って、ユーザはこのアナリストを立ち上げることができ
る。アラート・フレームのテキストは、例えば、次のよ
うに見える。

【０３６９】

【０３７０】エラー・レポートはより単純である可能性
がある。それはユーザ１４０５に対して正確に１つの文
（発生したエラーの説明）を通信することを意味する。
そのフォーマットは次のようになる。

【０３７１】

【０３７２】ＣＤＡＩ１４Ｂはエラーをサーバのエラー
・ログに対してレポートすることができる。そのエラー
・メッセージのテキストはパラメータ化されたローカラ
イズ可能な文字列として、エラー・メッセージのカタロ
グの中に維持される。

【０３７３】４．ＤＳＭサブシステム１６およびスケ
ジューラ・サブシステム１．８データおよびスキーマ操作サブシステム１６およびスケ
ジューラ・サブシステム１８が以下に詳細に説明され
る。ＭＤＴサーバ３２はユーザ１４０５に対して次の２
つのクラスの要求を実装することができる。

【０３７４】・対話型要求；Ｍｅｔａｄａｔａ^ＴＭのフ
ェッチ、Ｍｅｔａｄａｔａ^ＴＭの更新、ＩｎｆｏＦｒａ
ｍｅ^ＴＭのスケジューリング、ＩｎｆｏＦｒａｍｅ^ＴＭ
のステータスなど。サーバは各クライアントに対して一
度に一つの対話型要求を実装する。一度に一つの対話型
要求を実装することは、それらが対話型であるのとほと
んど同じくらい興味深いので、これらをシリアル要求と
も呼ぶ。・バッチ要求；トリガ要求およびＩｎｆｏＦｒａｍｅ
^ＴＭの作成。サーバは複数のバッチ要求を一度に実装す
ることができなければならない。複数のバッチ要求を一
度に実装することができなければならないということ
は、それらがバッチであるということとほとんど同様に
興味深いので、これらをコンカレント要求とも呼ぶ。

【０３７５】各コンカレント要求はデータベースに対し
て１つまたはそれ以上のクエリーを生じさせる。ＯＤＢ
Ｃ標準はデータベースに対する非同期のクエリーをサポ
ートするが、ＯＤＢＣの実装の多くはサポートしない。
これらの実装において、各コンカレント要求はそれ自身
のプロセスを必要とする。各要求をそれ自身のプロセス
の中に置くことによって、より多くのＯＤＢＣ実装で作
業することができ、複数の要求に対してメモリおよびデ
ータ構造を管理する責任をオペレーティング・システム
に負わせ、各コンカレント要求がそれ自身のプロセスを
得ることになる。このプロセスはコンカレント・インス
タンスとなる。

【０３７６】シリアルの要求および戻りの結果が非同期
のイベントであるようにされる場合、単独のサーバ・イ
ンスタンスがそのサーバのシリアル要求のすべてを処理
することができる。しかし、非同期的に実装すること
は、難し過ぎることはないにしても、各クライアント１
２が単純に新しいサーバのインスタンスを渡されること
ができる時は、むしろ無意味である。したがって、各ク
ライアント１２にはシリアルのインスタンスが割り当て
られ、その対話型の要求を処理する。

【０３７７】ＷｉｎｄｏｗｓＮＴ^ＴＭがスレッドを実
装すること、そして将来のＵＮＩＸ^ＴＭの将来の改訂版
のオペレーティング・システムも同様にそのようになる
ことに留意することが重要である。スレッドはオペレー
ティング・システムに対して非同期のイベントを処理す
るための責任を渡すための機会を提供し、一方、単独プ
ロセスの中のメモリを依然として管理している。また、
本発明の説明の目的のために、シリアルおよびコンカレ
ント・のインスタンスはその要求に対して適切な、完全
なサーバ機能のサブセットをそれぞれ実装しているユニ
ークな実行可能プログラムによって実装されることが仮
定される。

【０３７８】図３２を参照すると、サーバ３２は協働し
ているプロセスの集合として実装される。以下に説明さ
れるように、５つのクラスのプロセスがある。・マスタ・プロセス２５１１はサーバとのクライアント
のコネクションを受け入れることを担当し、そしてクラ
イアント１２にシリアル・インスタンスを割り当てる。・シリアル・インスタンス２５１２はこのクライアント
のシリアル要求のすべてを実行する責任がある。それら
はＭｅｔａｄａｔａ^ＴＭのフェッチおよび更新、Ｉｎｆ
ｏＦｒａｍｅ^ＴＭのスケジューリング要求などである。
シリアル・インスタンスはスケジュールされたＩｎｆｏ
Ｆｒａｍｅ^ＴＭの要求をスケジューラのキューの中に待
ち行列として入れる。シリアル・インスタンスはクライ
アントのＩｎｆｏＦｒａｍｅ^ＴＭ作成要求、コンカレン
ト要求も取得するが、それはこれをディスパッチャ上に
渡す。・ディスパッチャ・プロセス２５１３はシリアル・イン
スタンスまたはスケジューラによってそれに対して渡さ
れた各コンカレント要求に対するコンカレント・インス
タンスを割り当てること、およびペンディングおよび実
行中のコンカレント要求の状態を報告することを担当す
る。・コンカレント・インスタンス２５１４は単独のコンカ
レント要求の実行を担当する。・スケジューラ・プロセス１８はスケジュールされた時
刻においてディスパッチャに対してＩｎｆｏＦｒａｍｅ
^ＴＭ要求を渡すことを担当する。

【０３７９】関係の生成は親から子への白いポインタ２
５０１で示されている。要求の関係は送信側から受信側
への黒の矢印２５０２によって示されている。サーバの
プロセスは単独の状態をクライアントに対して提示する
ためにいくつかのリソースを共有する。それらはＭｅｔ
ａｄａｔａ^ＴＭ、スケジューラのキューおよびリターン
・エリアである。ユーザ１４０５がユーザのＭｅｔａｄ
ａｔａ^ＴＭに対する変更を行う時、その変更はそのユー
ザのそれ以降のＩｎｆｏＦｒａｍｅ^ＴＭ要求のすべてに
対して見えなければならない。ユーザ１４０５がＭＤＴ
Ａ（アドミニストレータ）であって、そのＭＤＴＡがグ
ローバルのＭｅｔａｄａｔａ^ＴＭに対する変更を指定す
る時、それらの変更はそれ以降のすべての要求に対して
見えなければならない。

【０３８０】ＭＤＴのＭｅｔａｄａｔａ^ＴＭは顧客のデ
ータ・ウェアハウス２４上に格納される。このＭｅｔａ
ｄａｔａ^ＴＭへのアクセスはＤＳＭ１６によって管理さ
れる。そのＭｅｔａｄａｔａ^ＴＭに対するアクセスを最
適化するために、ＤＳＭ１６は共有メモリ、ＭＤＴテー
ブルのライト・スルー・キャッシュを実装する。各ユー
ザ１４０５はＭｅｔａｄａｔａ^ＴＭのサブセットだけを
使い、そして実際的な理由のために、そのデータはデー
タベースのフラットなテーブルからアプリケーション固
有の構造に再編成される。そのユーザのシリアルおよび
コンカレント・インスタンス２５１２、２５１４の各々
がこのサブセットのコピーをキープする必要がある。こ
のイメージはＤＡＩ１４によって構築されて維持され
る。

【０３８１】ユーザ１４０５がＭｅｔａｄａｔａ^ＴＭの
アイテムを変更する時、ＤＡＩ１４はその変更をローカ
ル・イメージに対して有効にし、そしてＤＳＭ１６がデ
ータ・ウェアハウス２４を更新するよう指令する。ＤＳ
Ｍ１６はこの変更を共有メモリのキャッシュおよびウェ
アハウス２４に対してライト・スルー・キャッシュの中
に書き込む。Ｍｅｔａｄａｔａ^ＴＭについての関係およ
び操作が図３３の中に概略的に示されている。細い線の
矢印２６０１は共有されているメモリのＭｅｔａｄａｔ
ａ^ＴＭキャッシュ２６１０に対する付加を表している。
太い線の矢印２６０２はＭｅｔａｄａｔａ^ＴＭの径路を
表している。

【０３８２】本発明のＭＤＴは或る将来の時刻で実行さ
れるか、あるいは定期的に実行されるようにスケジュー
ルされているＩｎｆｏＦｒａｍｅ^ＴＭの要求のすべてを
リストする単独のスケジューラ・キューを維持する。ユ
ーザ１４０５がクライアント１２を通してＩｎｆｏＦｒ
ａｍｅ^ＴＭ要求をスケジュールする時、そのスケジュー
ル要求はシリアル・インスタンス２５１２を通してスケ
ジューラ１８に対して渡される。スケジューラ１８はそ
の要求を受け付け、その要求をスケジュール・キューの
中に置く。ユーザ１４０５がスケジュールされた要求を
削除すると、スケジューラ１８はその要求をスケジュー
ラのキューから削除する。また、ＤＡＩ１４はユーザの
スケジュール・ステータス要求も受け付ける。それはス
ケジューラのキューの検査によってそれらを満たす。

【０３８３】規則的な時間間隔で、スケジューラ１８は
スケジューラのキューを検査し、時期が来ている要求を
識別し、それらをディスパッチャ２５１３に対して渡
す。スケジューラ１８は次に非繰返し要求をスケジュー
ラのキューから取り除く。ディスパッチャ２５１３はそ
の要求を実行するためのコンカレント・インスタンス２
５１４を生成する。コンカレント・インスタンス２５１
４は１つのプロセスであり、プロセスがディスパッチャ
２５１３によって管理されなければならない制限された
リソースである筈であると期待する。このように、ディ
スパッチャ２５１３に対して渡されたＩｎｆｏＦｒａｍ
ｅ^ＴＭの要求は２つの状態のうちの１つの状態があり得
る。それらは（１）「ペンディング（プロセスに対して
待機している）」および（２）「実行中」である。ディ
スパッチャ２５１３はペンディングおよび実行中の要求
のリストをキープする。ユーザ１４０５があデータ・ス
テータス要求を行うと、クライアント１２はそれをシリ
アルのインスタンス２５１２に対して渡し、ＤＡＩ１４
がそれを実装する。それはそのステータス要求を完了す
るために、ディスパッチャ２５１３からユーザ要求のス
テータスのリストを収集する必要がある。

【０３８４】スケジューラのキュー２７１０上での関係
および動作が図３４の中に概略的に示されている。Ｉｎ
ｆｏＦｒａｍｅ^ＴＭの要求の径路が黒の矢印２７０１に
よって表されている。スケジュールされた要求およびペ
ンディングおよび実行中の要求に関するステータス情報
（それはクライアントのステータス要求に応答してシリ
アルのインスタンスによって収集されなければならな
い）は白の矢印２７０２によって表されている。

【０３８５】完成されたＩｎｆｏＦｒａｍｅ^ＴＭはそれ
らが完成された時と、クライアント１２がそれらを収集
するために呼び出す時との間、リターン・エリア内に駐
在している。リターン・エリアはファイル・システム上
の単なるディレクトリである。それは各ユーザ１４０５
に対するサブディレクトリを含む。コンカレント・イン
スタンス２５１４が１つのＩｎｆｏＦｒａｍｅ^ＴＭ要求
を完了すると、それはそのＩｎｆｏＦｒａｍｅ^ＴＭをリ
ターン・エリアのユーザのサブディレクトリの中にコピ
ーする。再帰型の要求はリターン・エリア内に多くのＩ
ｎｆｏＦｒａｍｅ^ＴＭを残す可能性がある。コンカレン
ト・インスタンス２５１４は各レポートに対してユニー
クな名前を作成しなければならない。

【０３８６】クライアント１２は時によってＩｎｆｏＦ
ｒａｍｅ^ＴＭのステータス要求をシリアル・インスタン
ス２５１２に対して渡す。ＤＡＩ１４はその要求を実装
する。ＤＡＩ１４はその完了されているＩｎｆｏＦｒａ
ｍｅ^ＴＭを識別するために、リターン・エリアのユーザ
のサブディレクトリを検査する必要がある。ＤＡＩ１４
はそのファイルメモリを「デコード」して、アナリスト
の名前および実行日付を作成してクライアント１２に対
してレポートすることができる。また、クライアント１
２は時によってＩｎｆｏＦｒａｍｅ^ＴＭの更新要求をシ
リアル・インスタンス２５１２に対して渡す。ＤＡＩ１
４はその要求を実装する。ＤＡＩ１４はリターン・エリ
アのユーザのサブディレクトリからそのＩｎｆｏＦｒａ
ｍｅ^ＴＭを収集する。それはそのＩｎｆｏＦｒａｍｅ
^ＴＭをクライアント１２に対して渡し、そしてクライア
ント１２がその受領をアクノレッジした時、リターン・
エリアからそのイメージを取り除く。

【０３８７】リターン・エリア２８１０上の関係および
動作が図３５の中に概略的に示されている。完成したＩ
ｎｆｏＦｒａｍｅ^ＴＭのフローが黒い矢印２８０１によ
って示されている。クライアントのステータス要求を満
足するためにシリアル・インスタンス２５１２によって
要求されるステータスの移動は、白の矢印２８０２によ
って示されている。

【０３８８】１．「ＤＳＭサブシステム１６」ＤＳＭサブシステム１６について以下に詳しく説明され
る。ＳＱＬゼネレータはＩｎｆｏＦｒａｍｅ^ＴＭからの
ディメンション的クエリを受信し、必要なデータベース
・クエリを作成し、そしてその結果をＩｎｆｏＦｒａｍ
ｅ^ＴＭゼネレータへ返す。データベースに対するインタ
ーフェースはＯＤＢＣを通して行なわれ、ＯＤＢＣはク
エリをＳＱＬ文字列の形式にする。ＳＱＬゼネレータは
データベース２４に問い合わせて各測定項目／セグメン
トのペアを評価しなければならない。その測定項目はｄ
ａｉ＿ＭｅｅａｓｕｒｅＬｉｓｔからのものであり得
る。ＱｕｅｒｙＤａｔａｂａｓｅ（）の第１の形式にお
いて、そのセグメントはｔａｒｇｅｔＰａｒｔｉｔｉｏ
ｎの子セグメントであり、第２の形式においては、各測
定項目は暗黙に決められたターゲット・セグメントに対
してのみ評価される。各測定項目は複合測定項目である
可能性があり、それはその複合測定項目を構成する測定
項目を評価するために複数のクエリを必要とする可能性
がある。標準のＳＱＬプログラミング技法を使ってＤＳ
Ｍサブシステム１６を実装することができる。

【０３８９】２．「スケジューラ・サブシステム１８」スケジューラ・サブシステム１８について以下に詳細に
説明される。スケジューラ・サブシステム１８は実行さ
れるスケジュール／またはトリガを伴うアナリストをサ
ブミットすることを担当する。また、それはスケジュー
ルされたおよび／またはトリガされたアナリストのリス
トを維持することも担当し、それらのリストに対する削
除、変更および追加も担当する。このセクションでは、
スケジュール、トリガ、またはスケジュールとトリガを
有するアナリストはその３つのタイプのアナリストの挙
動の方法に差がない限り、「スケジュールされた」アナ
リストと呼ばれる。

【０３９０】ＩｎｆｏＦｒａｍｅ^ＴＭの要求がＳ−ＤＡ
Ｉサブシステム１４Ａによって受信されると、それはそ
れがスケジュールされたアナリストに関連付けられてい
る場合は、スケジューラ・サブシステム１８に対して渡
される。スケジューラ１８はそのアナリストをディスパ
ッチする適切な期間を決定する。それが実行されるよう
にスケジュールされると、Ｓ−ＤＡＩサブシステム１４
Ａがスケジュールされていない要求を渡すのと同じ方法
で、ディスパッチャ２５１３に対して１つの要求が渡さ
れる。

【０３９１】図３６はこのプロセスのさらに詳細を示し
ている。Ｓ−ＤＡＩ１４Ａからスケジューラ１８はスケ
ジュールされたＩｎｆｏＦｒａｍｅ^ＴＭ要求を受信し、
ユーザ要求を削除およびディスエーブルし、スケジュー
ルされたアナリスト要求を削除する。要求をユニークに
識別するために、Ｓ−ＤＡＩ１４Ａはアナリストｉｄ
（ＩｎｆｏＦｒａｍｅ^ＴＭ要求オブジェクトの中に含ま
れている）およびユーザｉｄを提供しなければならな
い。

【０３９２】スケジュールされたＩｎｆｏＦｒａｍｅ
^ＴＭ要求が受信されると、そのアナリストはトリガを有
している場合はトリガ・リスト２９０１の中に入れら
れ、あるいはそれがスケジュールまたはスケジュールと
トリガのいずれかを有している場合はスケジュール・リ
スト２９０２の中に入れられる。トリガされたアナリス
トと、スケジュールされていてトリガされたアナリスト
との間の違いは前者が各トリガ期間において実行される
のに対し、後者はスケジュールされた時のみ実行される
ことである。スケジューラ１８は２つの実行期間を持っ
ている。１つはトリガされた要求に対するものであり、
もう１つはスケジュールされた要求に対するものであ
る。この２つの期間は各ＭＤＴサーバ３２において構成
可能であり、ＭＤＴアドミニストレータが変更すること
ができる。

【０３９３】トリガの期間が発生すると、スケジューラ
１８はトリガ型のイベントのリスト２９０１を縦覧す
る。そのタイム・スライスの間に実行するようにスケジ
ュールされているイベントでそのユーザ・アカウントが
イネーブルされているものの場合、トリガなしのＩｎｆ
ｏＦｒａｍｅ^ＴＭ要求のコピーがディスパッチャ２５１
３へ渡される。スケジュールの期間およびスケジュール
のリスト２９０２に対して同様なプロセスが行なわれ
る。ユーザ１４０５が削除された場合、スケジューラ１
８はその削除されたユーザによって所有されているリス
トからすべてのアナリストを取り除く。ユーザ１４０５
がディスエーブルされていた場合、そのリストの中のど
のアナリストも、ユーザ１４０５がふたたびイネーブル
されるまでは実行されない。アナリストが変更された場
合、ユーザ１４０５はすべての関連付けられたスケジュ
ール型要求をイメージ的に取り除かなければならない。
さもなければ、それらの古いアナリスト定義によって実
行され続ける。

【図面の簡単な説明】

【図１】本発明のシステムのブロック図である。

【図２】図１のシステムの内部のクライアント・サブシ
ステムのブロック図である。

【図３】図１のシステムの内部のデータ抽象化インテリ
ジェンス・サブシステムのブロック図である。

【図４】図１のシステムの内部のデータおよびスキーマ
操作サブシステムのブロック図である。

【図５】図１のシステムの内部のスケジューラ・サブシ
ステムのブロック図である。

【図６】グラフィック・ユーザ・インターフェースを採
用しているレポートを生成するためのツールのビューで
ある。

【図７】グラフィック・ユーザ・インターフェースを採
用しているレポートを生成するためのツールのビューで
ある。

【図８】グラフィック・ユーザ・インターフェースを採
用しているレポートを生成するためのツールのビューで
ある。

【図９】グラフィック・ユーザ・インターフェースを採
用しているレポートを生成するためのツールのビューで
ある。

【図１０】グラフィック・ユーザ・インターフェースを
採用しているレポートを生成するためのツールのビュー
である。

【図１１】グラフィック・ユーザ・インターフェースを
採用しているレポートを生成するためのツールのビュー
である。

【図１２】グラフィック・ユーザ・インターフェースを
採用しているレポートを生成するためのツールのビュー
である。

【図１３】グラフィック・ユーザ・インターフェースを
採用しているレポートを生成するためのツールのビュー
である。

【図１４】グラフィック・ユーザ・インターフェースを
採用しているレポートを生成するためのツールのビュー
である。

【図１５】グラフィック・ユーザ・インターフェースを
採用しているレポートを生成するためのツールのビュー
である。

【図１６】グラフィック・ユーザ・インターフェースを
採用しているレポートを生成するためのツールのビュー
である。

【図１７】グラフィック・ユーザ・インターフェースを
採用しているレポートを生成するためのツールのビュー
である。

【図１８】グラフィック・ユーザ・インターフェースを
採用しているレポートを生成するためのツールのビュー
である。

【図１９】グラフィック・ユーザ・インターフェースを
採用しているレポートを生成するためのツールのビュー
である。

【図２０】Ｍｅｔａｄａｔａ^ＴＭが生成される方法を説
明しているフロー・ダイアグラムである。

【図２１】図１のシステムの内部のクライアント・サブ
システムの他のブロック図である。

【図２２】図１のシステムの内部のクライアント・サブ
システムのさらに他のブロック図である。

【図２３】本発明の内容にしたがって生成され得るデー
タベースの階層である。

【図２４】本発明の内容にしたがって生成され得る別の
階層である。

【図２５】本発明の内容にしたがって生成され得るさら
に別の階層である。

【図２６】ＤＡＩおよび他のサブシステムと本発明のシ
ステムのコンポーネントとの間の一般的な高レベルのデ
ータ・フローである。

【図２７】図１のシリアルＤＡＩサブシステムのアーキ
テクチャである。

【図２８】図１のシリアルＤＡＩシステムのフロー・ダ
イアグラムである。

【図２９】図１のシリアル・ＤＡＩシステムに対する別
のフロー・ダイアグラムである。

【図３０】方法のシステムにおけるデータ・セグメント
の追加を示す図である。

【図３１】本発明のシステムにおけるデータベース・シ
ステムの削除について示す図である。

【図３２】図１のサーバによって実行されるプロセスを
示す図である。

【図３３】Ｍｅｔａｄａｔａ^ＴＭに関する関係および動
作を示す図である。

【図３４】スケジューラのキューについての関係および
動作を示す図である。

【図３５】リターン・エリアについての関係および動作
を示す図である。

【図３６】アナリストによって実行される要求を示す図
である。

フロントページの続き (72)発明者グレンキースウィクルアメリカ合衆国ニューメキシコ州 87505 サンタフェボニートロード３ (72)発明者マーシャルポールリンドセイアメリカ合衆国カリフォルニア州 92131 サンディエゴエルマロード、ナンバー 204、9949 (72)発明者リチャードニールシューベルトアメリカ合衆国カリフォルニア州 92131−1711 サンディエゴカミニトバンヨン 10542 (72)発明者ドゥルートーマスレティントンアメリカ合衆国カリフォルニア州 92116−3939サンディエゴノースアヴェニュー 4494 (72)発明者ジェフレイポールラドウィグアメリカ合衆国カリフォルニア州 92127 サンディエゴサニーデイルコート 11250 (72)発明者ジェイムズフォスタークナッソンアメリカ合衆国サウスダコタ州 57049 ダコタダンズコートヤードドライブ 230、アパートメント 207 (72)発明者ソヘイラトヘリアメリカ合衆国ジョージア州 30033 デカターエヌ．クロッシングウェイ 1610 (72)発明者スコットデイルコウルターアメリカ合衆国ジョージア州 30060 マリエッタアイボリートレイル 3193 (72)発明者ケヴィンワインコパスアメリカ合衆国ジョージア州 30045 ローレンスヴィレロックランドウェイ 326

Claims

【特許請求の範囲】

【請求項１】データベース管理システムであって、（１）関連付けられた属性を有するデータ・エンティテ
ィを含んでいるデータベースと、（２）前記データベースに結合されているサーバと、（３）前記サーバに結合されているクライアント・コン
ピュータとを備え、前記データ・エンティティが第１階層の中で並べられて
いて、前記第１階層の各レベルが少なくとも１つの属性
に関連付けられていて、前記サーバ・コンピュータが、（ａ）選択された属性を制限するための属性制限値を受
信するための受信手段と、（ｂ）前記データベースをセグメント化するためのセグ
メント化手段とを含み、その中で第２階層が生成され、
前記第２階層が前記属性制限値と関連付けられていて、前記クライアント・コンピュータが、（ａ）前記属性制
限値を前記クライアント・コンピュータのユーザから入
力するための手段と、（ｂ）前記属性制限値を前記受信
手段に対して送信するための手段とを含むことを特徴と
するデータベース管理システム。
【請求項２】データベース管理システムであって、（１）１つの組織を示しているデータを含んでいるデー
タベースと、（２）前記データベースに対して結合されているサーバ
・コンピュータと、（３）前記サーバに対して結合されているクライアント
・コンピュータとを含み、前記サーバ・コンピュータが、（ａ）定義されたトリガ・イベントの発生に応答して、
あるいは前記データベースの中の前記データを分析する
ための要求に応答して、前記データベースに対して問い
合わせるための問合わせ手段と、（ｂ）前記問合わせ手段に対して応答するレポートを作
成するためのレポート作成手段とを含み、前記クライアント・コンピュータが、（ａ）前記レポー
ト作成手段によって作成される前記レポートを受信する
ための手段と、（ｂ）前記クライアント・コンピュータ
のユーザに対して前記レポートを表示するための手段と
を含んでいることを特徴とするデータベース管理システ
ム。
【請求項３】データベース管理システムであって、（１）１つの組織を示すデータ・エンティティを含んで
いるデータベースと、（２）前記データベースに対して結合されているサーバ
・コンピュータと、（３）前記サーバに対して結合されているクライアント
・コンピュータとを含み、前記データ・エンティティが第１階層の中に並べられて
いて、前記第１階層の各レベルが少なくとも１つの属性
に関連付けられており、前記サーバ・コンピュータが、（ａ）定義されたトリガ・イベントの発生に応答して、
あるいは前記データベースの中の前記データを分析する
ための要求に応答して、前記データベースに対して問い
合わせるための問合わせ手段と、（ｂ）前記問合わせ手段に対する応答のレポートを作成
するためのレポート作成手段と、（ｃ）選択された属性を制限するための属性制限値を受
信するための受信手段と、（ｄ）前記属性制限値に関連付けられている第２階層を
生成するために前記データベースをセグメント化するた
めのセグメント化手段とを含み、前記クライアント・コンピュータが、（ａ）前記属性制
限値を前記クライアント・コンピュータのユーザから入
力するための手段と、（ｂ）前記属性制限値を前記受信
手段に対して送信するための手段と、（ｃ）前記レポー
ト作成手段によって作成された前記レポートを受信する
ための手段と、（ｄ）前記レポートを前記クライアント
・コンピュータのユーザに対して表示するための手段と
を含むことを特徴とするデータベース管理システム。