|
|
BEA Aqualogic Data Services Platform を使用して、企業のデータ サービスのモデルを作成および管理できます。 モデルには、データ、データ オブジェクト間の関係、データのセマンティクス、および一貫性の制約が表現されます。
さらに、物理データ サービス、論理データ サービス、またはその組み合わせの間の関係もモデルに表示されます。 DSP ではすべてのモデル関係はバイナリです。モデル ダイアグラムでは、各バイナリ関係が 2 つのデータ サービス間の 1 本または複数の線として示されます。
| 注意 : | データ サービスのモデル化の概念については、AquaLogic Data Services Platform の『コンセプト ガイド』にある「モデリングとサービス指向アーキテクチャ」を参照してください。 |
モデル ダイアグラムは、DSP によってサポートされるデータ モデルのグラフィカルな表現です。 モデル ダイアグラムでは、データ サービスの集合やデータ サービス間の関係を表示するだけでなく、関係の各終端のロール、方向、およびカーディナリティの情報を識別することもできます。 デフォルトではモデル ダイアグラムに表示される型は XML スキーマ型ですが、物理データ サービスの場合には、ネイティブのデータ ソース型を表示するように変更することもできます。
大企業では、モデル化はデータ サービス レイヤ開発の初期に行うべきタスクです。 物理データ リソースをグラフィカルに表現することから始めることで、データ リソースのグローバルな表示がより簡単になり、既存の情報を有効に活用できます。 さらに、追加のビジネス ロジックを論理サービスの形式で作成する時機も簡単に判断できます。
モデル ダイアグラムは柔軟性に富んでおり、既存のデータ サービス (および対応する基底のデータ ソース)、予定されているデータ サービス、またはその組み合わせに基づくことができます。 また、モデル ダイアグラム内で直接、データ サービスやデータ サービスの XML 型を作成および変更することもできます。
DSP におけるモデル関係とは、2 つのデータ サービス間の論理的な接続です。 接続には、以下の情報を記述できます。
関係には 1 つまたは複数のナビゲーション関数を割り当てることができます。ナビゲーション関数では、一方のデータ サービス (Customer など) に関連付けられたデータを、関連するデータ サービス (Orders など) に対する複合パラメータとして使用できます。
リレーショナル データ サービス間の関係など、主キーおよび外部キーを参照することで自動的に推測される関係もあります。 詳細については、「リレーショナル テーブルおよびビューのメタデータのインポート」を参照してください。
モデルでは、論理データ サービスと物理データ サービスの任意の組み合わせを表現できます。
物理データ サービスは、企業内に物理的に存在するデータを表します (「エンタープライズ メタデータの取得」を参照)。 ソースの提供元は、リレーショナル データベース、Web サービス、XML データ ストリームまたはドキュメント、スプレッドシートなどのフラット ファイル、またはカスタム関数を含んだ Java ファイルになります。
論理データ モデルは、物理データまたは別の論理データに基づいて DSP で開発されます。
つまり、各物理データ モデル エンティティは単一のデータ ソースを表し、論理データ モデル エンティティは物理モデルまたは論理モデル (あるいはその組み合わせ) の複合ビューを表します。
| 注意 : | 新しい関係を作成するなど、データ サービスに影響を与える変更をモデル ダイアグラムで行った場合、その変更は [ファイル｜すべて保存] を選択することで WebLogic Workshop で永続化されます。 |
データ モデルを作成するには、DSP ベースのプロジェクトを選択してから、次のように選択します。
[ファイル｜新規作成｜モデル ダイアグラム]
次の例では、物理データに基づいてモデルを作成する方法を示します。
![[ファイル] メニューを使用したデータ モデルの作成](wwimages/newDataModel.gif)
この例では、DSP のデモ用プログラム RTLApp を使用することを前提としています。
この例で使用されるデータ サービスは、PRODUCT、CUSTOMER_ORDER、および CUSTOMER_ORDER_LINE_ITEM です。 メタデータのインポートの詳細については、「エンタープライズ メタデータの取得」を参照してください。
単純なモデルの作成とデータの設定に必要な手順は、次のとおりです。
この例では、データ サービスはリレーショナル ソースの表現であるため、多くのメタデータを使用できます。 たとえば、主キーはデータから識別され、キー アイコン (
) としてデータ サービスの型に表示されます。
この場合は、CUSTOMER と CUSTOMER_ORDER_LINE_ITEM という 2 つの関係がすでに存在していることが表示されます (図 5-5)。
この操作を行うと、3 つのデータ サービス間の関係が自動的に表示されます (図 5-6)。 表示されない場合は、ADDRESS データ サービスの [関係の表示] コマンドを選択してください。
前述したように、関係の線は、関係宣言とナビゲーション関数のグラフィカルな表現です。
関係の各終端にはロールがあります。 最初は、ロール名は単にそれぞれのデータ サービスを反映しています。 表 5-7 に、図 5-1 で表示されているモデル ダイアグラムのサービス、ロール、およびカーディナリティの詳細を示します。
[アプリケーション] ペインでは複数のデータ サービスを選択できます。連続する複数のサービスを選択するには〔Shift〕を押しながらクリックし、個別の複数のサービスを選択するには〔Ctrl〕を押しながらクリックします。 一連のデータ サービスをモデル ダイアグラムにドラッグすると、モデル内にある他のデータ サービスとの既存の関係が自動的に作成されます。
上記の例で示されている関係は、それぞれの物理データ サービスにあるナビゲーション関数に基づいて自動的に作成されます (表 5-8 を参照)。
基底のソースに示されるナビゲーション関数の例を、次に示します。
(::pragma function <f:function xmlns:f="urn:annotations.ld.bea.com" kind="navigate" roleName="ADDRESS"/>::)
ここでは、Customer データ サービスから Address データ サービスへの関係が指定されています。
データ サービスには関係の特性を示す宣言も含まれます。この情報は、モデル ダイアグラムに表示されるロール名およびカーディナリティ値のソースになります。
たとえば、Address データ サービスには次の関係宣言が含まれます。
<relationshipTarget roleName="CUSTOMER" roleNumber="1" XDS="ld:DataServices/CustomerDB/CUSTOMER.ds" opposite="ADDRESS"/>
ロール名、カーディナリティ、反対側のデータ サービス、および (そのデータ サービス内で) ユニークなロール番号が指定された関係が、データ サービスごとに作成されます。
上記の例では、customerID に基づいて顧客情報を取得するナビゲーション関数が自動的に作成されます。 Customer データ サービスの getAddress( ) 関数をコード リスト 5-1 に示します。
import schema namespace t2 = "ld:DataServices/CustomerDB/ADDRESS" at "ld:DataServices/CustomerDB/schemas/ADDRESS.xsd";
(::pragma function <f:function xmlns:f="urn:annotations.ld.bea.com" kind="navigate" roleName="ADDRESS"/>::)
declare function f1:getADDRESS($pk as element(t1:CUSTOMER)) as element(t2:ADDRESS)*
{
for $fk in f2:ADDRESS()
where $pk/CUSTOMER_ID eq $fk/CUSTOMER_ID
return $fk
};
Customer と Address の間の関係の場合、CustomerID に基づく Address ロールに対する関係は 0 ～ n (任意の回数出現する場合もまったく出現しない場合もある) です。CustomerID はそれぞれのデータ サービスにおいて基底のリレーショナル データ ソースですが、Address データ サービスでは外部キーであり、Customer データ サービスでは主キーです。
この関係は双方向なので、Customer の反対側のデータ サービスは Address となり、Address の反対側のデータ サービスは Customer となります。 プロパティ エディタでは次のように表示されます (図 5-9)。
論理モデルと物理モデルの主要な相違点は、論理モデルには物理データ サービスに加えて少なくとも 1 つの論理データ サービスの表現が含まれていることです。 実際には、物理データ サービスと論理データ サービス (それ自体が論理データ サービスで構成されているデータ サービスを含む) が混在するモデルの作成に制約はありません。
データ モデルが物理データ サービスと論理データ サービスの両方で構成されている場合には、基底の物理データ サービスでメタデータが更新されると、更新されたデータ サービスに関連した作成済みの関係が削除されるので注意してください。 詳細については、「データ ソースのメタデータの更新」を参照してください。
モデル ダイアグラムでは、一方のデータ サービスからもう一方のデータ サービスへ線を描く動作をすることで、関係を作成できます (図 5-1 を参照)。 リレーショナル データ サービスなどでは、関係および関係を表す線が自動的に推測される場合があります。 それ以外の場合は、関係の作成が必要になります。
ナビゲーション関数は、バイナリ関係では各データ サービスのプロパティとして表示されます。 また、各データ サービスのソース ビューで詳細を調べることができます。 関係の線の各エンドポイントをマウスでポイントすると、ナビゲーション関数がテキストとして表示されます。
モデル ダイアグラムでは、関係の各側は関連するデータ サービスによって果たされるロールを表します。 たとえば ADDRESS と CUSTOMER の関係では、顧客の側にある線の終端には、デフォルトでは CUSTOMER と表示されます。 ロール名をマウスでポイントすると、反対側のロール名がナビゲーション関数の名前とともに表示されます (図 5-10)。
図 5-10 に示されているモデル ダイアグラムでは、ADDRESS ロールは主キー ADDR_ID を通じて CUSTOMER からアクセスされます。 CUSTOMER データ サービスにおける ADDRESS 関係には自動的に作成された getADDRESS() 関数があります。 そのロールは、特定のクレジット カードの所有者に関する ADDRESS 型の情報を返すことです。
図 5-11 に示されている関数では、ナビゲーション関数 getADDRESS(pk) は主キー CUSTOMER_ID を含む任意の CUSTOMER 入力パラメータを取り、顧客の住所情報を返します。
図 5-10 に示されている関係のもう一方の終端は CUSTOMER ロールです。このロールは、ユニークな顧客 ID に基づく顧客情報を ADDRESS データ サービスに提供します。
図 5-10 の表記矢印には、カーディナリティの表記も示されています。 データ ソースには住所情報のない顧客が存在することもあるため、ADDRESS ロールは CUSTOMER に対して 0 対 1 のカーディナリティを持ちます。 各 ADDRESS は 1 人の顧客に対応していなければならないため、ADDRESS ロールは CUSTOMER に対して 1 対 1 のカーディナリティを持ちます。
2 つのデータ サービス間の関係をより適切に表現するように、ロール名を変更できます。 名前の変更は、2 つのデータ サービス間に複数の関係が存在している場合に特に便利です。
例として、Customers と Orders の関係を取り上げます。 これら 2 つのデータ サービス間の 1 つの関係は、通常 1 対 n の関係になります。これはこの関係に関する、以下のような 2 つの事実を表します。
デフォルトでは、ロール名は Customers と Orders になります。 ただし、関係の各側のロールをより正確に表現するように、ロール名をそれぞれ Supplies_Customer_Info と Orders_Array に変更できます。
2 番目の関係の線は、異なる関数 getMostRecentOrder( ) を表します。 この関係は 1 対 1 の関係になり、ロール名は CustInfo および getOrder と表現できます。
関係の線の終端をマウスでポイントすると、特定のロールに対して定義されたナビゲーション関数 (図 5-12)、またはナビゲーション関数が定義されていないことを示すメッセージのいずれかが表示されます。
モデル ダイアグラムで 2 つのデータ サービス間に線を描く動作をすると、関係ウィザードが開きます。
ウィザードを完了すると、豊富な機能を備えたナビゲーション関数が作成されます。
詳細と例については、「データ サービスへの関係の追加」を参照してください。 若干の例外はありますが、関係ウィザードは、モデル ダイアグラム内で呼び出された場合でも、既存のデータ サービスに関係を追加するときに呼び出される場合と同様に機能します。
この節では、モデル ダイアグラムを操作する場合の一般的な操作方法について説明します。
右クリック メニュー オプションとプロパティ エディタを組み合わせて使用することで、モデルを編集できます。 表 5-14 に、モデル ダイアグラムの対象機能領域で表示される右クリック オプションを示します。
|
|
||||
|
||||
モデル ダイアグラムでの関係の表記の作成には、以下のような数種類の方法があります。
上記のオプション 1 および 2 では、関係ウィザードが表示されます。 ウィザードの詳細については、「データ サービスへの関係の追加」を参照してください。 モデル ダイアグラムでは関係の各側の名前を変更するオプションは表示されません。2 つのデータ サービスを接続する線によって定義済みであるためです。
モデル ダイアグラム内で右クリックすると表示される [データ サービスの検索] オプションを使用して、モデル ダイアグラムにあるデータ サービスを検索できます。 モデル ダイアグラムが選択されているときに〔Ctrl〕+〔F〕を押して検索することもできます。
![[データ サービスの検索] ダイアログ ボックス](wwimages/find_dataservice.gif)
[ワイルドカード (* および ?) を使用して検索する] も使用できます。
検索条件に一致するノードが強調表示され、最初の一致ノードを示すようにモデル ダイアグラムの表示が変化します。
現在のセッションで行われた検索を、入力フィールドとドロップダウン リストが組み合わされたボックスから取得できます。
モデル ダイアグラム内で右クリックすると表示される [レポートの生成] オプションを使用して、現在のモデルに関する概要レポートまたは詳細レポートを生成できます。 レポートは [概要] と [詳細] の 2 種類から選択できます。
[レポートの作成] 右クリック オプションを選択すると、生成される HTML ドキュメントの名前の選択を要求されます。 概要レポートのデフォルト名は、次のようになります。
<model_name>_md_summary.html<model_name>_md_detail.html
レポートはアプリケーション内の任意の場所 (新しいフォルダを含む) に保存できます (図 5-16)。
モデル レポートは HTML 形式です。 レポートを生成すると、WebLogic Workshop ペインに HTML 形式で表示されます。 [ソース ビュー] タブも使用できます (図 5-17)。
| 注意 : | レポートの出力は、HTML 出力をサポートしているブラウザまたはアプリケーションで行ってください。 |
大きなモデルの場合は、モデル ダイアグラムの右下隅にある表示専用のズーム オプションを使用できます (図 5-19)。 ズーム オプションに表示される「施錠」アイコンは、ズーム モードがアクティブであり、モデルが読み込み専用になっていることを示します。
モデル ダイアグラムに表示されているデータ サービスの XML 型を編集できます。 XML 型のオプションについては、「XML 型を編集する」を参照してください。
プロパティは、モデル ダイアグラムで作成された関係を反映し、定義します。 表 5-18 に、対象 (データ サービス、関係、ナビゲーション関数、および XML 型) ごとに表示されるデータ モデルのプロパティの詳細を示します。
モデル ダイアグラムは、物理データ、論理データ、関係などのコンポーネントによって変わります。また、これらのコンポーネントは、モデルの外側で変更される可能性があります。
修飾名を変更したり、データ サービスを削除したり、基底のデータを変更したりすると、データ モデルにおけるデータ サービスやそれらの関係の表現が不正な状態になる可能性があります。
プロパティ エディタを使用して、修飾名参照を修正したり、古くなった参照を削除したりすることもできます。 詳細については、「モデル ダイアグラムのプロパティ」を参照してください。
メタデータを更新すると、影響を受けるデータ サービス間に手動で作成した関係がすべて削除されます。 モデル ダイアグラムでは、こうした変更は関係の線を赤色で表示することで示されます。 この場合、新しく更新されたデータ サービスを使用して関係を再作成する必要があります。
  
|
