10gリリース2（10.1.2.0.0）
B15623-01
 目次 |
 索引 |
| Oracle Business Intelligence Discoverer 管理ガイド 10gリリース2（10.1.2.0.0） B15623-01 |
|
この章では、Discoverer Administratorを使用した条件の適用方法について説明します。項目は次のとおりです。
条件によりワークシート・データがフィルタ処理されるため、Discovererエンド・ユーザーは必要なデータのみを分析できます。たとえば、Discovererエンド・ユーザーに1999年や2000年のデータは除いて2001年のデータのみへのアクセスを提供する場合などです。
また、機密性のあるデータへのアクセスを制限するためにも条件を使用します。必須条件を適用することで、機密性のないデータのみがDiscovererユーザーに使用可能になります（詳細は、「異なるタイプの条件」を参照してください）。Discovererエンド・ユーザーに、必要なデータのみを表示させることができます。
Discovererマネージャは、一般的に使用される条件を予測し、Discovererエンド・ユーザーがその条件をワークシートに適用できるように条件を使用可能にします。これにより、Discovererエンド・ユーザーは効率的に作業ができます。
条件には、次のカテゴリがあります。
display data where year = 2001 AND quarter = 1 AND region = south
display data where year = 2001 AND (region = north OR region = south)
この例では、OR句はAND句の中にネストされています。
display data where year = 2001 AND quarter = 1 AND region = south AND (region = north OR region = south)
この例では、ネストされた条件の例のように、OR句はAND句の中にネストされています。
拡張された条件を作成するかわりに、2つ以上の単一条件を作成し、同時に適用する場合があります。これにより、Discovererのユーザーは条件のどの部分を使用するかを選択できます。
注意: 拡張された条件の適用と同等の複数の単一条件の適用には微妙な違いがあります（詳細は『Oracle Business Intelligence Discoverer Plusユーザーズ・ガイド』を参照してください）。
Discovererで条件を使用すると、ワークシート・データに対して条件文を一致させます。
たとえば、データの表示を過去2年間の売上に限定する場合があります。または、2種類の販売品目のみのデータを表示する場合があります。これらの各作業では、データをフィルタ処理して条件に一致する情報を検索します。
条件には2つのタイプがあります。
必須条件とオプション条件は同じ方法で作成します。ただし、次のことに注意してください。
たとえば、必須条件を地域販売担当者の売上データに割り当てて、売上の表示内容をそれぞれの担当する地域に制限する場合などです。
たとえば、全販売地域を担当する副社長は、すべての売上データを確認でき、条件を適用して特定の販売地域に関連する販売データも確認できる必要があります。
次の表は、必須条件とオプションの条件の違いについて詳細を示しています。
Discovererエンド・ユーザーが新しい方法でワークシートのフィルタ処理をできるようにするには、単一条件を作成します。Discovererエンド・ユーザーが、フォルダに基づくワークブックを使用するときに新しい条件を適用できるように、フォルダに条件を追加します。
たとえば、Discovererエンド・ユーザーが今年のデータのみが必要なため、データをフィルタ処理してその年の結果を表示するオプション条件を作成する場合があります。または、データの特定のエリアに必須条件を設定して、機密性のあるデータへのアクセスを制限する場合があります（詳細は、「異なるタイプの条件」を参照してください）。
単一条件を作成する手順は、次のとおりです。
注意: 最初にフォルダまたはアイテムを選択しないで「挿入」→「条件」を選択した場合、ダイアログが表示される前にフォルダまたはアイテムを選択するように要求されます。
注意: デフォルトで、Discoverer Administratorは条件に基づいて条件名を作成します。ただし、条件にユーザー独自の名前を指定できます。
ここに入力したテキストは、Discoverer Administratorで条件が編集される場合またはエンド・ユーザーが条件を強調表示する場合に表示されます。
新規条件は、ワークエリア: 「データ」タブに表示されます。Discovererのユーザーがこのビジネスエリアにアクセスする場合、この条件アイテムはフォルダに表示されます。フォルダに条件が表示されていても、フォルダがフィルタ処理されているわけではないので注意してください。エンド・ユーザーは、ワークブックの条件を選択して使用する必要があります。
拡張された条件とは、2つ以上の条件文を含む条件のことをいいます。たとえば、都市New Yorkの1999年または2000年のデータに絞り込む場合は、City = New York AND (Year = 1999 or 2000)のような条件を作成します。さらに、既存の条件を既存の拡張された条件にネストすることがあります。たとえば、「Department = Video AND Rental Profit > $100」などのようにします。Discovererでは、必要なだけ条件文を追加して、強力な条件アイテムを容易に作成できます。
拡張された条件を作成する手順は、次のとおりです。
「追加」、「削除」、「AND」、「OR」および「NOT」ボタンが追加されます。これらのボタンを使用して、拡張された条件を作成します。
注意: 各条件文の隣のハンドルを使用して条件文を強調表示し、次のアクションを実行できます。
注意: 条件文の移動は、拡張された条件内での条件文の適用順序に影響を与えます（ネストされた条件文は最初に適用されます）。
新規条件は、ワークエリア: 「データ」タブに表示されます。Discovererのユーザーがこのビジネスエリアにアクセスする場合、この条件アイテムはビジネスエリア・フォルダに表示されます。
条件を編集して、その動作を変更します。たとえば、次の操作を行うことができます。
条件を編集する手順は、次のとおりです。
更新された条件は、ワークエリア: 「データ」タブに表示されます。
条件プロパティを編集して、条件の動作や識別子を変更します（詳細は、「識別子」を参照してください）。識別子は、Discovererの一意な識別ラベルです。また、条件自体を編集して、条件が動作する方法を変更することもできます（詳細は、「条件の編集方法」を参照してください）。
条件プロパティを編集する手順は、次のとおりです。
ワークエリア: 「データ」タブは更新され、条件に加えた変更が反映されます。
ビジネスエリアから条件を永続的に削除するときは、条件を削除します。たとえば、以前は2000年のデータがフィルタ処理されていて、今回は使用可能なすべての年のデータにアクセスできるようにする場合があります。
条件を削除する手順は、次のとおりです。
条件はビジネスエリアから削除されます。
次の例は、Discoverer Administratorで条件がどのように使用されるかを示しています。
2002年のデータのみを返す条件を作成するには、「新規条件」ダイアログの「計算式」エリアに次のように入力します。
| アイテム | 条件 | 値 |
|---|---|---|
|
Year |
= |
2002 |
過去7日間の売上のみを返す条件（ユーザー定義アイテム「Transaction Age (in Days)」を使用）を作成するには、「新規条件」ダイアログの「計算式」エリアに次のように入力します。
| アイテム | 条件 | 値 |
|---|---|---|
|
Transaction Age (in days) |
< |
7 |
ユーザー定義アイテム「Transaction Age」は、次の式を含んでいることに注意してください。
FLOOR (SYSDATE - Transaction Date)
このタイプの条件は、条件が返す行のウィンドウが日によって変わるため、ローリング・ウィンドウ条件ともいいます。
年にかかわらず第3四半期（Q3）の出荷のみを返す条件（ユーザー定義アイテム「Ship Quarter」を使用）を作成するには、「新規条件」ダイアログの「計算式」エリアに次のように入力します。
| アイテム | 条件 | 値 |
|---|---|---|
|
Ship Quarter |
= |
'Q3' |
ユーザー定義アイテム「Ship Quarter」は、次の式を含んでいることに注意してください。
EUL_DATE_TRUNC(Ship Date, "Q")
2つのテーブルの間で外部結合を定義する場合は、条件（フィルタ）とDisableAutoOuterJoinsOnFiltersのDiscovererレジストリ設定の組合せが、エンド・ユーザーのクエリーで返されるデータの行にどのように影響するかを理解している必要があります。
2つのテーブル間で外部結合を定義し、次のものを表示します。
たとえば、次を表示する場合があります。
SQLでは、外部結合はプラス記号（+）で示します。
Discovererは、次の場合にSQLに外部結合を含みます。
詳細は、「結合の編集」ダイアログ: 「オプション」タブを参照してください。
たとえば、Discovererは条件を含むエンド・ユーザーのクエリーに対して、SQLに外部結合を自動的に作成します。
条件を含むクエリーを実行している場合、ユーザーは結果を次のようにする場合があります。
DisableAutoOuterJoinsOnFiltersレジストリ設定により、エンド・ユーザーのクエリーで条件が使用されるときに、自動的に生成された外部結合の使用を無効にできます。次の表は、その後に示す例を要約したものです。
| 例番号 | 条件の適用 | DisableAutoOuterJoinsOnFiltersの値 | すべての値を表示 |
|---|---|---|---|
|
例1 |
いいえ |
0または1 |
する |
|
例2 |
する |
0 |
いいえ |
|
例3 |
する |
1 |
する |
次の例は、外部結合、条件およびDisableAutoOuterJoinsOnFiltersレジストリ設定の値が、エンド・ユーザーのクエリーから返されたデータの行にどのように影響を与えるかを示しています。
Discovererレジストリ設定の詳細は、第21章「Discovererのレジストリ設定」を参照してください。
この例は、2つのテーブルに対してクエリーを実行したときに返された結果を示しています。マスター・テーブルとディテール・テーブルは外部結合で結合されています。
Discovererが表示するのは、次のとおりです。
クエリーは、次のSQL文を使用して定義されます。外部結合はプラス記号（+）で示されます。
select dname, ename, job from dept, emp where dept.deptno = emp.deptno(+);
| DNAME | ENAME | JOB |
|---|---|---|
|
SALES |
GRIMES |
DIRECTOR |
|
SALES |
PETERS |
MANAGER |
|
SALES |
SCOTT |
CLERK |
|
SUPPORT |
MAJOR |
MANAGER |
|
SUPPORT |
SCOTT |
CLERK |
|
ADMIN |
|
|
|
MARKETING |
|
|
|
DISTRIBUTION |
|
|
前述のクエリーから返された結果は、DisableAutoOuterJoinsOnFiltersレジストリ設定をオンまたはオフに切り替えても変わりません。
この例では、例1のクエリーに条件を適用し、DisableAutoOuterJoinsOnFiltersレジストリ設定をオフに切り替えています。
Discovererが表示するのは、次のとおりです。
Discovererが表示しないのは、次のとおりです。
次のSQL文が使用されます。外部結合はプラス記号（+）で示されます。
select dname, ename, job from dept, emp where dept.deptno = emp.deptno(+) and job = 'CLERK';
| DNAME | ENAME | JOB |
|---|---|---|
|
SALES |
SCOTT |
CLERK |
|
SUPPORT |
SCOTT |
CLERK |
この例では、例1のクエリーに条件を適用し、DisableAutoOuterJoinsOnFiltersレジストリ設定をオンに切り替えています。
Discovererが表示するのは、次のとおりです。
次のSQL文が使用されます。外部結合はプラス記号（+）で示されます。
select dname, ename, job from dept, emp where dept.depno = emp.deptno(+) and job = 'CLERK';
| DNAME | ENAME | JOB |
|---|---|---|
|
SALES |
SCOTT |
CLERK |
|
SUPPORT |
SCOTT |
CLERK |
|
ADMIN |
|
|
|
MARKETING |
|
|
|
DISTRIBUTION |
|
|
エンド・ユーザーに対し、Discovererワークブックで表示できるデータを制限する場合があります。
たとえば、すべての地域の利益データを含む1つのテーブルを持っているとします。利益データの各行は、1つの地域のトランザクションに適用されています。西地域のマネージャが西地域の利益データを含む行のみにアクセスできるようにするとします。
| REGION | PROFIT | DATE |
|---|---|---|
|
East |
$100 |
8/7 |
|
West |
$50 |
8/7 |
|
South |
$65 |
8/10 |
|
North |
$100 |
8/6 |
行レベルのセキュリティを作成するには、次の作業を完了する必要があります。
この作業により、すべてのデータベース・ユーザーのリストを取得し、条件を適用して行レベルのセキュリティを達成できます。
行レベルのセキュリティを適用するビジネスエリアにALL_USERSテーブルをロードする手順は、次のとおりです。
SYSユーザーは、すべてのデータベース・ユーザーの名前を保持するビューを含んでいます。
これにより、ALL_USERSビューは現行のビジネスエリアにロードされます。ALL_USERSビューは、すべてのデータベース・ユーザー・アカウントの名前を含んでいます。
これにより、すべてのデータベース・ユーザーの名前の値リストが作成されます。
これにより、SYSテーブルから現行のビジネスエリアにALL_USERSビューがロードされます。
これにより、ALL_USERSフォルダはエンド・ユーザーに表示されなくなります。
ユーザー定義アイテムを作成すると、それ以降のSYSテーブルからすべてのデータベース・ユーザーの値リストのアイテム・クラスを適用できます。
行レベルのセキュリティを適用するフォルダにユーザー定義アイテムを作成する手順は、次のとおりです。
前述の作業で作成したユーザー定義アイテムに値リストのアイテム・クラスを適用する手順は、次のとおりです。
拡張された必須条件を作成します。これにより、データの条件を指定されたデータベース・ユーザーに適用できます。
次の両方を含む拡張された必須条件を作成する必要があります。
拡張された必須条件を作成し、指定したデータベース・ユーザーの行レベルのセキュリティを定義する手順は、次のとおりです。
タイプ「必須」を指定すると、条件が常にエンド・ユーザーに適用されます。
Discovererは、「値」フィールドに選択したデータベース・ユーザーを表示します。
注意: これで、1人以上のデータベース・ユーザーの名前を指定する必須単一条件が作成できました。ただし、現行フォルダのデータベース・ユーザーに行レベルのセキュリティを適用する前に、指定したデータベース・ユーザーに適用するデータ条件を指定する必要があります。
残りの手順では、指定したデータベース・ユーザーに行レベルのセキュリティを適用する方法について説明します。これにより、データベース・ユーザーは西地域からのデータのみを表示できるようになります。
これにより、新規条件文を現行の条件に追加し、データ条件を指定したデータベース・ユーザーに適用できます。
このデータ条件は、指定したデータベース・ユーザーに適用されます。
注意: データベース・ユーザー（Username）をデータ条件（Region）に関連付けるには、Username条件文とRegion条件文を、AND句を使用してグループ化する必要があります。
各Username条件文とデータ条件文は、AND句を使用してグループ化する必要があります。Username条件文とデータ条件文のペアは、OR句を使用して他のペアと互いにグループ化する必要があります。OR句を使用してUsername条件文とデータ条件文のペアをグループ化し、各条件文のペアを適用できます（次の図を参照してください）。
これにより、（'West'または'East'地域にユーザーのグループをバインドして）指定したデータベース・ユーザーに行レベルのセキュリティを適用する、拡張された必須条件が作成されます。前述の例では、データベース・ユーザーADMTESTは'West'地域のデータのみを表示できます。
これにより、Discovererはエンド・ユーザーに条件を表示しませんが、この条件は常に適用されます。
フォルダに必須条件を作成した場合、データベース・ユーザーのクエリーには必須条件を含むフォルダに基づくサマリー・フォルダを使用しないようにしてください。これは、サマリー・テーブルのデータが、サマリー・フォルダを作成したデータベース・ユーザーに対するデータのみになるためです。
ソース・フォルダが（行レベルのセキュリティを適用するなどの）必須条件を使用していても、そのサマリー・フォルダをデータベース・ユーザーが使用できるようにするには、必須条件を作成する前に次の手順を実行する必要があります。
ソース・フォルダに必須条件を含むサマリー・フォルダを、データベース・ユーザーのクエリーで有効にする手順は、次のとおりです。
サマリー・フォルダの作成方法の詳細は、第14章「サマリー・フォルダの管理」および第15章「手動によるサマリー・フォルダの作成」を参照してください。
このサマリー・フォルダは、サマリー・フォルダを作成したデータベース・ユーザーのデータを参照します。エンド・ユーザーのクエリーがこのサマリー・フォルダにアクセスしないように、このプロパティを「いいえ」に設定します。
詳細は、「サマリー・プロパティ」ダイアログを参照してください。
この作業は、Discovererの外部で実施されるので、詳細はデータベース管理者に問い合せてください。
作成したビューに（行レベルのセキュリティなどの）必須条件を適用するには、WHERE句を使用します。
たとえば、次のようになります。
SQL> WHERE Userid='SMITH' AND Region='WEST'
詳細は、「外部サマリー・テーブルに基づくサマリー・フォルダの作成方法」を参照してください。
データベース・ユーザーがこのサマリー・フォルダにアクセスできるようにするには、このプロパティを「はい」に設定します。
Discovererで、「次回のリフレッシュ」とリフレッシュ間隔のサマリー・フォルダ・プロパティを「無期限」に設定する必要があります。
詳細は、「サマリー・プロパティ」ダイアログを参照してください。
これで、必須条件のないデータ・フォルダに基づくフォルダと、ビューに基づくフォルダの2つのサマリー・フォルダが用意されました。 最初のサマリー・フォルダの作成後に必須条件をフォルダに追加することで、後続するクエリーは、フォルダに基づくサマリー・フォルダではなく、ビューに基づくサマリー・フォルダを使用するようにリライトされます。 サマリー・リライトの詳細は、第16章「サマリー・フォルダに関する追加情報」を参照してください。
|
 Copyright © 2004 Oracle Corporation. All Rights Reserved. |
|