Oracle Business Components for Java用語集

A B C D E F H I J M N O P Q R S T U V W X

A

「別名」属性の設定(Alias attribute setting)

この設定は、ビュー・オブジェクト・ウィザードおよびビュー・オブジェクト・エディタ「属性の設定」ページ、ならびにエンティティ属性エディタに表示される。ビュー・オブジェクト属性の場合、別名が属性と異なる(デフォルト)場合、別名はビュー・オブジェクトのSQL文の一部になる。たとえば、myEnameを「Ename」属性の別名として入力した場合、SQL文には句Emp.Ename as myEnameが含まれる。別名は、結合での主キーと外部キーのように2つの同一属性名があり、それらの名前を一意にする必要がある場合に役立つ。

アプリケーション・モジュール(application module)

ビジネス・ロジック層には、他の層(クライアントおよびデータベース)が対話する1つ以上のアプリケーション・モジュールがある。アプリケーション・モジュールは、オンライン注文の処理や昇給の処理などの特定のアプリケーション・タスクを実行する。アプリケーション・モジュールには、次の主要な特性がある。

ビジネス・ロジック層をプログラミングする際に、ビジネス・ロジックは、ビジネス・コンポーネントの再利用を簡単にするために様々なレベルに配置される。

アプリケーション・モジュールでは、クライアント・インタフェース(フォームなど)に合せてデータを収集するため、複数回ではなく1回のネットワーク・ラウンドトリップでデータを取得できる。リモート・アクセス可能なメソッドを介してビジネス・ロジック層で計算を実行し、クライアントのオーバーヘッドを削減することもできる。アプリケーション・データのバルク操作の場合、すべてのデータをクライアントにダウンロードするのではなく、ビジネス・ロジック層で操作を行う。クライアントが現在表示しているデータへの変更は、自動的に同期化される。

アプリケーション・モジュールを設計時に作成および編集するには、アプリケーション・モジュール・ウィザードおよびアプリケーション・モジュール・エディタを使用する。また、ビジネス・コンポーネント・プロジェクト・ウィザードおよびビジネス・コンポーネント・パッケージ・ウィザードを使用することにより、デフォルトのアプリケーション・モジュールも作成できる。

実行時、クライアントは使用するアプリケーション・モジュールのインスタンスを作成する。作成できるのは、設計時に作成したアプリケーション・モジュールのインスタンス、または汎用アプリケーション・モジュールと呼ばれるベース・アプリケーション・モジュール・クラスのインスタンスである。汎用アプリケーション・モジュールは、動的に作成されたビュー・オブジェクト、ビュー・リンクおよびアプリケーション・モジュールのコンテナが必要な場合に使用できる。たとえば、クライアント・メニューに多数のタスクが含まれた、複雑なアプリケーションがある場合、メニューでの選択に基づいて、同じトランザクション内で、アプリケーション・モジュールを必要に応じてインスタンス化する汎用アプリケーション・モジュールを作成できる。

クライアントは、プール内のアプリケーション・モジュール・インスタンスを使用できる。たとえば、あるWebアプリケーションを最大1000人のユーザーが使用できる場合に、特定のアプリケーション・モジュールは同時に100人のユーザーしか使用しないとする。この場合、プール内に100個のアプリケーション・モジュール・インスタンスを保持する。あるクライアントでアプリケーション・モジュール・インスタンスが必要になると、そのクライアントは、プール内の空きインスタンスを取得し、トランザクションをコミットまたはロールバックした後で、プールに解放する。インスタンスはあらかじめ作成されているため、エンド・ユーザーは、タスクを実行する際にアプリケーション・モジュールをインスタンス化する時間が短縮される。通常は、WebベースのJSPクライアントでプールを使用する。

アプリケーション・モジュール・クラス(application module class)

oracle.jbo.server.ApplicationModuleImplから直接的または間接的に拡張されるJavaクラス。アプリケーション・モジュール・ウィザードビジネス・コンポーネント・プロジェクト・ウィザードまたはビジネス・コンポーネント・パッケージ・ウィザードでこのクラスを生成できる。アプリケーション・モジュール・タスクに固有で、ビュー・オブジェクトまたはエンティティ・オブジェクト・クラスに含めるのには適していないメソッドなどのカスタム・コードを、ソース・ファイルに追加できる。

このクラスは、オプションでカスタム・クラスから拡張するよう指定できる(カスタム・クラスは、ApplicationModuleImplクラスを直接的または間接的に拡張し、プロジェクト・クラスパス内にあることが必要)。たとえば、すでに記述されているコードを再利用する場合、または特別なニーズに合せてビジネス・コンポーネントのフレームワークをカスタマイズするよう決定した場合には、このように指定する。

アプリケーション・モジュール・ウィザードおよびアプリケーション・モジュール・エディタ(Application Module Wizard and Editor)

これらのツールは、アプリケーション・モジュールの作成および編集に使用する。また、ビジネス・コンポーネント・プロジェクト・ウィザードおよびビジネス・コンポーネント・パッケージ・ウィザードを使用することにより、デフォルトのアプリケーション・モジュールも作成できる。

アプリケーション・モジュール・ウィザードでアプリケーション・モジュールを作成するには、ビジネス・コンポーネント・プロジェクトが開いている状態で、次のいずれかを行う。

アプリケーション・モジュールを編集するには、ナビゲータの「ワークスペース」ノードの下にあるアプリケーション・モジュールを右クリックし、「moduleの編集」を選択する。

アプリケーション・モジュールを作成する場合、ウィザードを使用して次の情報を指定できる。ここでは、ページごとに説明する。

アプリケーション・モジュールを編集する場合、エディタを使用して、これまでのページ(「名前」ページ以外)に加え、次の情報を指定する。

Association

共通の属性に基づいて、2つのエンティティ・オブジェクト間の関係を定義する。この関係には、1対1または1対多がある。1対多のAssociationを2つ使用し、多対多の関係を実装できる。エンティティ・オブジェクトは、Associationを利用して永続的な参照を行い、他のエンティティ・オブジェクトのデータにアクセスできる。外部キー関係またはオブジェクトREFにより、同じタイプの関係が表レベルで存在することもあるが、エンティティ・オブジェクトが他のエンティティ・オブジェクトのデータにアクセスするために必要なのは、Associationのみである。Associationは、データベースに対応する参照整合性制約が定義されているかどうかにかかわらず、作成できる。

関係の例として、部門と従業員の間の1対多のAssociationがある。この関係では、Deptエンティティ・オブジェクトのDeptno属性と、Empエンティティ・オブジェクトのDeptNo属性が関連付けられている。

Associationは、AssociationウィザードおよびAssociationエディタで定義および編集できる。既存の表の参照整合性制約に基づき、ビジネス・コンポーネント・プロジェクト・ウィザードおよびビジネス・コンポーネント・パッケージ・ウィザードを使用して、デフォルトのAssociationを生成(逆方向生成)することもできる。順方向生成では、Associationの作成時に、生成する表に対してオプションで外部キー制約を設定できる。エンティティ・オブジェクトを生成した後で、表に対して参照整合性制約を追加するには、単にエンティティ・オブジェクト・エディタにアクセスし、「終了」をクリックして新しいAssociationを作成するだけである。

エンティティ・オブジェクト内のオプションのAssociationアクセッサにより、Associationの他方のデータにアクセスできる。たとえばDeptエンティティ・オブジェクト内でgetEmpsメソッドをコールし、現在の部門で働いている従業員を表すEmpエンティティ・オブジェクトの行セットを取得できる。次にgetEmpsをコールすると、同じ行セットが返される。記述したコードは、(マスターからディテールへ、およびディテールからマスターへの)いずれの方向でもAssociationを横断できる。エンティティ・オブジェクトは、複数のAssociationを横断し、必要なデータを取得できる。

Associationとしてコンポジットを使用できる。この場合、関連元エンティティ・オブジェクトが関連先エンティティ・オブジェクトを所有する。つまり、所有側であるエンティティ・オブジェクトがまず存在していなければ、関連先エンティティ・オブジェクトを作成できない。

ビジネス・コンポーネントのAssociationは、UMLのAssociationの概念を実装したものである。

AssociationウィザードおよびAssociationエディタ(Association Wizard and Editor)

これらのツールは、Associationの作成および編集に使用する。既存の表の参照整合性制約に基づき、ビジネス・コンポーネント・プロジェクト・ウィザードおよびビジネス・コンポーネント・パッケージ・ウィザードを使用して、デフォルトのAssociationを作成(逆方向生成)することもできる。

順方向生成では、Associationを作成する際にオプションで、生成する表に関係を追加できる。たとえば、(Business Components for Javaを使用しない)他のアプリケーションに対して同じ関係へのアクセス権を付与できる。エンティティ・オブジェクトから表を作成するには、「データベース・オブジェクトの作成」ツールを使用する。

AssociationウィザードでAssociationを作成するには、ビジネス・コンポーネント・プロジェクトが開いている状態で、次のいずれかを行う。

Associationを編集するには、ナビゲータの「ワークスペース」ノードの下にあるAssociationを右クリックし、「associationの編集」を選択する。

Associationを作成する場合、ウィザードを使用して次の情報を指定できる。ここでは、ページごとに説明する。

Associationを編集する場合、エディタを使用して、同じ情報(「名前」ページ以外)を指定できる。

エンティティ・オブジェクトを生成した後で、表に対して参照整合性制約を追加するには、単にエンティティ・オブジェクト・エディタにアクセスし、「終了」をクリックして新しいAssociationを作成するだけである。

属性(attribute)

エンティティ・オブジェクトまたはビュー・オブジェクトの特性で、オブジェクト・クラスのJavaBeansプロパティとして実装される。属性は、データベース列に対応付けることも、データベース列に依存しないことも可能である。属性には、次の5つの種類がある。

属性の種類

定義される場所

データベース問合せから導出された値か

データベースに永続的に存在するか

永続

エンティティまたはビュー・オブジェクト・レベル

はい

はい(値は、作成したクラスよりも長く存在)

一時

エンティティまたはビュー・オブジェクト・レベル

いいえ

いいえ

エンティティ導出

ビュー・オブジェクト・レベル

いいえ

いいえ

SQL導出

ビュー・オブジェクト・レベル

はい

いいえ

動的

ビュー・オブジェクト・レベル、実行時

いいえ

いいえ

エンティティ・オブジェクトの属性には、次の種類がある。

逆方向生成を使用して初めてエンティティ・オブジェクトを作成するとき、表の各列に対応する永続エンティティ属性が作成される。その後で表を変更した場合は、属性を手動で変更する必要がある。

ビュー・オブジェクトの属性には、次の種類がある。

SQL導出属性の値は、SQL文の結果である。たとえば、YearsOfService属性は、データベースにおける従業員の入社日と現行の日付との差異である。また、一時属性を作成し、Javaファイルで値を設定するための計算を行うコードも記述できる。通常、SQL導出属性を使用する方が、Javaでデータ集約型計算を行うよりも効率的である。

Business Components for Javaでは、属性という語はXMLの定義ではなく、UMLの定義に基づくものである。UMLでは、属性は、クラスの名前付きプロパティで、そのクラスのインスタンスが保持する値の範囲を記述する。

エンティティ属性エディタ(Attribute Editor)

エンティティ属性エディタでは、エンティティを編集し、属性を表示できる。エディタにアクセスするには、ナビゲータの「ワークスペース」ノードの下にあるエンティティ・オブジェクトまたはビュー・オブジェクトを選択し、構造ペインで属性を右クリックして「attributeの編集」を選択する。エンティティ属性エディタでは、属性レベルのプロパティを指定する。

属性を編集する場合、ウィザードを使用して次の情報を指定できる。ここでは、ページごとに説明する。

属性の設定(attribute settings)

属性には、次の設定がある。エンティティ・オブジェクトの属性の場合、設定は順方向生成に影響を与える。また、この設定を既存の表から導出する(逆方向生成)こともできる。

属性の設定

順方向生成

逆方向生成

永続属性
(エンティティ・レベル)

一時属性
(エンティティ・レベル)

永続属性(ビュー・レベル)

一時属性
(ビュー・レベル)

SQL導出属性
(ビュー・レベル)

エンティティ導出属性
(ビュー・レベル)

名前

N/A

デフォルトは列名に基づく。これを任意のJava識別名に変更できる。

必須。

必須。

デフォルトはエンティティ属性名に基づく。

必須。

必須。

デフォルトはエンティティ属性名に基づく。

N/A

デフォルトは列データ型に基づく。リストから別の型を選択できる。

必須。

必須。

変更不可。エンティティ属性設定を使用する。

必須。

必須。

変更不可。エンティティ属性設定を使用する。

デフォルト

N/A

N/A

オプション。

オプション。

N/A

N/A

N/A

N/A

主キー

表の主キーになる。表に複数の主キー(コンポジット・キー)を指定した場合は、表の主キーの一部になる。

表から。表と一致している必要がある。

選択可能。

選択可能。ただし、ほとんどの場合、選択解除。

N/A(エンティティ属性の設定が適用される)

N/A

N/A

N/A(エンティティ属性の設定が適用される)

問合せで選択済 N/A N/A N/A N/A 選択されている場合、この属性はビュー・オブジェクトのSQL SELECT文に表示される。 選択されている場合、この属性はビュー・オブジェクトのSQL SELECT文に表示される。 選択済。 選択されている場合、この属性はビュー・オブジェクトのSQL SELECT文に表示される。
多相化識別子 N/A N/A 選択可能。 選択可能。 選択可能。 選択可能。 選択可能。 選択可能。

必須

表内の必須列になる(表内のその列に対してNOT NULL制約が生成される)。

表から。この値は表と一致している必要がある。一致していない場合、実行時に正常に動作しなかったり、例外がスローされることがある。

選択可能。

選択可能。

N/A(エンティティ属性の設定が適用される)

N/A

N/A

N/A(エンティティ属性の設定が適用される)

永続的

永続属性のみが表に追加される。

表から導出される属性はすべて永続属性。これを変更した場合、この列はビジネス・コンポーネント・フレームワークを介して値は移入されない。

選択済。

選択解除。

N/A(エンティティ属性の設定が適用される)

N/A

N/A

N/A(エンティティ属性の設定が適用される)

問合せで選択済

N/A

N/A

N/A

N/A

選択されている場合、この属性はビュー・オブジェクトのSQL SELECT文に表示される。

選択されている場合、この属性はビュー・オブジェクトのSQL SELECT文に表示される。

選択されている場合、この属性はビュー・オブジェクトのSQL SELECT文に表示される。

選択されている場合、この属性はビュー・オブジェクトのSQL SELECT文に表示される。

更新可能

N/A

N/A

選択可能。

選択可能。

エンティティ属性の設定に基づく。設定をさらに制限できる。

選択可能。

選択可能。

エンティティ属性の設定に基づく。設定をさらに制限できる。

リフレッシュ

N/A

N/A(ただし、この属性のjava.sql.typeがCHARの場合は例外で、すべての「リフレッシュ」チェックボックスがチェックされる)

選択可能。

N/A

N/A(エンティティ属性の設定が適用される)

N/A

N/A

N/A

「データベース列」の「名前」

表の列名になる。

表から。表と一致している必要がある。

必須。表と一致している必要がある。

N/A

N/A(エンティティ属性の設定が適用される)

N/A

N/A

N/A

データベース列の型

表の列データ型になる。

表から。表と一致している必要がある。

必須。表と一致している必要がある。

N/A

N/A(エンティティ属性の設定が適用される)

N/A

N/A

N/A

問合せ可能

N/A

N/A

選択可能。

N/A

選択可能。

N/A

選択可能。

N/A

一意

チェックした場合、列は一意の制約を持つ。

表から。表と一致している必要がある。

選択可能。

N/A

N/A(エンティティ属性の設定が適用される)

N/A

N/A

N/A

更新識別子

N/A

N/A

選択可能。

N/A

N/A

N/A

N/A

N/A

別名

N/A

N/A

N/A

N/A

デフォルトはエンティティ属性名に基づく。オプション。名前の競合を防ぐために使用できる。

オプション。

オプション。名前の競合を防ぐために使用できる。

オプション。

N/A

N/A

N/A

N/A

N/A

N/A

必須。

オプション。

 

B

ビジネス・コンポーネント(business component)

ビジネス・コンポーネント・フレームワークから導出されるアプリケーション固有のコンポーネントには、次のものがある。

ビジネス・コンポーネントは、XML メタデータ・ファイルとして、あるいはXMLメタデータ・ファイルと1つ以上のJavaファイルとして実装される。

XMLファイルには、メタデータが格納される。メタデータは、設計時にBusiness Components for Javaウィザードを使用して宣言できるアプリケーションの機能および設定に関する説明的な情報である。メタデータの例として、属性の名前と型、SQL問合せおよび検証規則がある。Javaファイルは、コンポーネントのカスタム・コードを格納する。このコードは、アプリケーション固有の動作を実装する。説明的な情報はXMLとして格納されるのに対し、プログラム情報はJavaで格納される。

ビジネス・コンポーネントは、標準のJavaパッケージ構造に編成される。たとえば、DeptViewという名前のビュー・オブジェクトがパッケージMyDeptにある場合、MyDeptディレクトリにファイルDeptView.xmlおよびDeptViewImpl.javaが含まれる。ウィザードでコンポーネントを作成する際にパッケージを指定すると、ウィザードによってファイルが適切な場所に置かれる。

次に、XMLの記述の例を示す。

<ViewObject
Name="DeptView"
...
ComponentClass="MyDept.DeptViewImpl">

次に、Javaコードの例を示す。

package MyDept;
...
public class DeptViewImpl extends
oracle.jbo.server.ViewObjectImpl {
...
}

Business Components for Java

JavaおよびXMLで実装されるプログラミング・フレームワーク。再利用可能なビジネス・コンポーネントを基に、多層構造のデータベース関連アプリケーションの効率的な開発、デプロイメント、および柔軟なカスタマイズを可能にする。これらの3層アプリケーションは、クライアントビジネス・ロジックとデータベース・ビューを含むビジネス・ロジック層、およびアプリケーションが使用するデータの表を含むデータベース・サーバーから構成される。Business Components for Javaのウィザードとエディタを使用すると、指定に基づいてビジネス・ロジック層が構築される。JDeveloperの開発環境を使用することで、JavaとJSPの両方のクライアントを作成できる。Oracle9i またはOracle9i Liteは、データベース・サーバーとして機能する。ビジネス・ルール、ビューおよびカスタム・コードが別の層に格納されるため、クライアントをThinにでき、インストールおよびメンテナンスが容易になる。ビジネス・ロジック層を変更しても、多くの場合、それを使用するクライアントの変更は不要である。

ビジネス・ロジック層は1つ以上のアプリケーション・モジュールで構成され、アプリケーション・モジュールには、データのビューを表し、オプションで計算を含むビュー・オブジェクトが含まれる。ビュー・オブジェクトでは、ビジネス・エンティティを表し、データベース表にマップされるエンティティ・オブジェクトを使用して、ビジネス・ロジックを実行できる。ビュー・リンクは、ビュー・オブジェクト間のマスター/ディテール関係を表し、アプリケーション・モジュールに含まれる。Associationは、エンティティ・オブジェクト間の双方向の関係を表す。これらのモジュール・コンポーネントは、容易にカスタマイズ、メンテナンス、他のアプリケーションでの再利用が可能である。コンポーネント・ベースのフレームワークでは、マスター/ディテールの整合、ロック、トランザクション管理(ビジネス・ロジック層のデータ・キャッシュの変更、およびデータベースへの変更のポスト)など、繰返しのコーディング作業が多く処理される。

Business Components for Javaの設計時のウィザードとエディタを使用し、コンポーネントの特性(属性、関係およびビジネス・ルール)を定義することにより、ビジネス・ロジック層を構築できる。Business Components for Javaでは、指定した動作を実装する、Javaソース・コードとXMLメタデータを生成する。コードはフレームワークから継承されるため、Javaソース・ファイルは複雑にならない。また、ソース・ファイルに含まれるコードも多くないため、カスタム・コードの追加場所を容易に判断できる。JDeveloperを使用することで、デプロイメント・プラットフォームとは無関係に、動作を強化または変更するJavaコードを追加し、容易にアプリケーション・サービスをテストできる。Business Components for Javaは、アプリケーション・モジュールを変更せずに、VisiBroker CORBAサーバー・オブジェクト(物理的に3層)、EJBセッションBean(物理的に3層)、またはローカル・モード(物理的に1層あるいは2層)でデプロイする際に役立つ。

ビジネス・コンポーネント・プロジェクト・ウィザードおよびビジネス・コンポーネント・プロジェクト・エディタ(Business Components Project Wizard and Editor)

このウィザードは、プロジェクト・ウィザードでビジネス・コンポーネント・プロジェクトの作成が終わると、自動的に表示される。また、プロジェクトを右クリックして「新規ビジネス・コンポーネント・パッケージ」を選択しても、表示される。ウィザードは、次の項目の指定に役立つ。

エンティティ・オブジェクト、Association、ビュー・オブジェクトおよびビュー・リンクは、エンティティ・オブジェクト・ウィザードAssociationウィザードビュー・オブジェクト・ウィザードおよびビュー・リンク・ウィザードを使用して作成および編集することもできる。

既存のビジネス・コンポーネント・プロジェクトを編集するには、ビジネス・コンポーネント・プロジェクトを右クリックし、「projectの編集」を選択してビジネス・コンポーネント・プロジェクト・エディタにアクセスする。このエディタでは、接続の表示と指定、JavaおよびXMLコードを生成するか、XMLコードのみ生成するかの指定、および登録済検証規則の指定を行う。Javaコードを生成すると、オブジェクトを返す汎用的なgetAttributeおよびsetAttributeメソッドを使用するかわりに、強い型指定のアクセッサにアクセスできるようになり、セッター・メソッドにコードを記述できるという利点がある。

ナビゲータでビジネス・コンポーネント・プロジェクトを右クリックし、「新規ビジネス・コンポーネント・パッケージ」を選択した場合に表示されるウィザードは、ビジネス・コンポーネント・パッケージ・ウィザードと呼ばれる。このウィザードの機能は、「接続」ページがないことを除いてビジネス・コンポーネント・プロジェクト・ウィザードと同じである。

ビジネス・ロジック(business logic)

ビジネス・ロジックには、検証ロジック、デフォルト値ロジック、削除ロジックおよび計算がある。ビジネス・ロジックは、エンティティ・オブジェクト・レベルで実装する必要がある。ビジネス・ロジックの例として、顧客の返品理由の記録や、最善の取引を行うための仕入先間の入札規則がある。

ビジネス・ロジック層(business logic tier)

基本的なビジネス・ロジック層には、それぞれエンティティ・オブジェクトおよびAssociationに依存するビュー・オブジェクトおよびビュー・リンクへのアクセスを可能にする1つ以上のアプリケーション・モジュールが含まれる。ビジネス・ロジック層はBusiness Component Browserでテストできる。

 

C

キャッシュ(cache)

ビジネス・ロジック層では、データベースおよびクライアントから受信したデータを、エンティティ・キャッシュおよびビュー・キャッシュの2つのタイプのキャッシュに格納する。

カーディナリティ設定(cardinality setting)

Associationで関連付けるオブジェクトの最小数と最大数を設定することで、オブジェクト間の関係の定義に役立つ。

「更新識別子」属性の設定(Change Indicator attribute setting)

この設定は、エンティティ・オブジェクト・ウィザードおよびエンティティ・オブジェクト・エディタ「属性の設定」ページ、およびエンティティ属性エディタに表示される。永続エンティティ・オブジェクト属性の場合は、この設定を選択すると、エンティティ・オブジェクトの永続属性が変更されたかどうかがその属性によって判別される。ユーザーが行の属性値に初めて変更を加える際、ビジネス・ロジック層では、行のロック(即時ロック・モード)またはコミット(コミット時ロック・モード)が試行される。このとき、キャッシュ内のデータ値がデータベースと一致するかどうかがチェックされる。「更新識別子」属性の設定により、ビジネス・ロジック層で単一の属性をチェックするか、複数の属性をチェックするかが決定される(複数の属性をチェックすると、オーバーヘッドが増加する)。したがって、キャッシュ内のエンティティ・オブジェクト・インスタンスにデータが初めて挿入されてから、そのデータが初めて変更されるまでの間に属性値が変更されている場合は、他のユーザーによって行全体が変更されていることを表す。この設定は、エンティティ・オブジェクトの1つの属性にのみ定義できる。通常、属性はタイム・スタンプ列または順序番号である。

クライアント(client)

ローカルまたはリモート・コンピュータにあるサービス、データまたは別のアプリケーションの処理を要求するソフトウェア・アプリケーション。「Thinクライアント(thin client)」も参照。

コンポジット(composition)

エンティティ・オブジェクトが子エンティティ・オブジェクトを所有するAssociation。親オブジェクトは、1つ以上の子オブジェクトのコンテナとなる。子エンティティ・オブジェクトが変更された場合には、子エンティティ・オブジェクトが検証される。また、この関係は親エンティティ・オブジェクトの検証を起動する。

挿入、更新および削除の場合、子エンティティ・オブジェクトは親エンティティ・オブジェクトの一部とみなされる。有効な子エンティティ・オブジェクトを持つ親エンティティ・オブジェクトは、これに包まれるエンティティ・オブジェクトがすべて削除されるまで、削除できない。子エンティティ・オブジェクトを変更しようとすると、ビジネス・ロジック層は親エンティティ・オブジェクトをロックしようとする。所有側である親エンティティ・オブジェクトが正常にロックされないかぎり、子エンティティ・オブジェクトは変更できない。たとえば航空券を予約する場合、自分の名前ですでに予約があると座席を予約できない。

子エンティティ・オブジェクトは、親がないと作成できない。子エンティティ・オブジェクトを作成すると、外部キーが割り当てられる。親エンティティ・オブジェクトは主キーの値にNULL以外の値を持つ必要がある。実行時に子エンティティ・オブジェクトが変更された場合、その親には検証が必要であるというマークが付けられる。コミットの際に親エンティティ・オブジェクトが検証され、次に子エンティティ・オブジェクトが検証される。

接続(connection)

別のデータベースを使用して開発した場合は、デプロイの準備ができた段階でデプロイメント・データベースに切り替えることができる。

接続プール(connection pooling)

Business Components for Javaバージョン3.2から、接続プールがデフォルトの動作になった。以前は各アプリケーション・モジュール・インスタンスに対して1つのJDBC接続を作成し、この接続をインスタンスの切断時に破棄していたが、アプリケーション・モジュールで接続のプールを再利用できるようになった。JDBC接続URLごとに1つの接続プールが用意される。この中には、ユーザー名とパスワードが定義されている。

データベース接続の作成は時間のかかる処理で、データそのものの取得よりも時間がかかる場合がある。接続プールを使用すると、データベース接続を作成する必要がなくなり、クライアントの応答時間が短縮される。クライアントは、接続を作成するかわりに、他のアプリケーション・モジュール・インスタンスで作成された接続を再利用できる。

デフォルトの接続プール機能の他に、次のオプションがある。

CORBA

Common Object Request Broker Architecture(CORBA)は、Object Management Group(OMG)の仕様。CORBAは、静的および動的起動インタフェース、インタフェース・リポジトリおよびObject Request Broker(ORB)を含む、分散オブジェクト・コンピューティング・システムの作成に使用されるフレームワークを定義する。

「データベース・オブジェクトの作成」ツール(Create Database Objects Tool)

エンティティ・オブジェクトの情報に基づいてデータベース表の作成に使用する。エンティティ制約ウィザードで指定した場合はデータベースの制約も作成できる。これは順方向生成と呼ばれる。このツールにアクセスするには、ナビゲータの「ワークスペース」ノードの下にある、ビジネス・コンポーネント・パッケージを右クリックし、「データベース・オブジェクトの作成」を選択する。

 

D

「デフォルト」属性の設定(Default Value attribute setting)

この設定は、エンティティ・オブジェクト・ウィザードおよびエンティティ・オブジェクト・エディタと、ドメイン・ウィザードおよびドメイン・エディタ「属性の設定」ページ、ならびにエンティティ属性エディタに表示される。

エンティティ・オブジェクト属性の場合、この設定はオプションのデフォルト値となる。ビジネス・ロジック層で、属性を含む新しい行が作成された場合は、属性には、デフォルトでこの値が設定される。

ドメインの場合、このデフォルト値はドメイン型のすべての属性に継承され、エンティティ・オブジェクト・ウィザード、エンティティ・オブジェクト・エディタ、またはエンティティ属性エディタでオーバーライドできない。

ドメイン(domain)

ドメインは、属性として使用できる値の型を定義する。ドメイン・オブジェクトは開発者が定義するデータ型で、ドメインのコンストラクタに簡易検証が組み込まれた、スカラー値または構造をカプセル化した不変のJavaクラスである。ドメイン型のオブジェクトが作成されると、検証が行われる。ドメインの作成には次の利点がある。

JDeveloperには、ドメインを定義するためのドメイン・ウィザードおよびドメイン・エディタが用意されている。社会保障番号などの特定の型の値を保持できるように、ビジネス・ロジック層同様Thinクライアントでもドメインのクラスを使用できる。また、(すべてのコンストラクタでコールされる)ドメインの検証メソッドで、入力文字列を初期化または検証するコードを記述できる。ドメイン・クラスは、フォーム内の各フィールドと関連付けできる。フォームでは、フィールドの入力文字列によりドメイン・クラスのインスタンスを直接作成できる。

ドメイン・ウィザードおよびドメイン・エディタでは、設定を指定し、ドメイン型のすべての属性にこの設定を継承させることができる。属性によりドメインの設定がさらに制限されることはあるが、制限が緩和されることはない。たとえば、あるドメイン型に一時属性を含めない場合は、そのドメインを永続的としてマークする。

ドメイン・オブジェクトは、作成後、属性のデータ型として使用できる。たとえば、SSNumberという名前のドメインを作成し、結果のデータ型が9文字の文字列であることを確認する検証コードをこのドメインに記述する。

ドメインは常にシリアライズ可能なJavaオブジェクトである。ビジネス・コンポーネント・フレームワークでは、String、byte[]、IntegerなどのネイティブのJava型を少なくとも1つ受け入れるコンストラクタをドメインに含めることが推奨されている。

ビジネス・コンポーネント・フレームワークでは、事前定義済のドメインもいくつか提供される。

ドメイン・ウィザードおよびドメイン・エディタ(Domain Wizard and Editor)

これらのツールは、ドメインの作成および編集に使用する。

ドメイン・ウィザードでドメインを作成するには、ビジネス・コンポーネント・プロジェクトが開いている状態で、次のいずれかを行う。

ドメインを編集するには、ナビゲータの「ワークスペース」ノードの下にあるドメインを右クリックし、「domainの編集」を選択する。

ドメインを作成する場合、ウィザードを使用して次の情報を指定できる。ここでは、ページごとに説明する。

ドメインを編集する場合は、エディタを使用して「設定」ページの情報を指定できる。また、エディタには次のページもある。

ドメインのJavaファイル(ウィザードで作成されたもの)に検証コードを記述できる。たとえば、データ型が9文字の文字列であることを確認できる。

 

E

EJB

Enterprise JavaBeans標準は、複数層、分散、スケーラブル、オブジェクト指向のJavaアプリケーションの開発およびデプロイメントのためのクロス・プラットフォーム・コンポーネント・アーキテクチャを規定する。サーバーBeanとも呼ばれる。

エンティティ(entity)

UML用語では、顧客、注文、品目などのドメイン固有の名詞。

エンティティ制約ウィザード(Entity Constraint Wizard)

「データベース・オブジェクトの作成」ツールで表を生成(順方向生成)する際に使用される制約を追加できる。ウィザードにアクセスするには、ナビゲータの「ワークスペース」ノードの下にあるエンティティ・オブジェクトを右クリックし、「新規エンティティ制約」を選択する。

また、Associationの定義時に制約を作成することもできる。Associationに基づいて自動的に制約を作成する場合は、AssociationウィザードおよびAssociationエディタの「Associationプロパティ」ページで、「データベース・キー制約の使用」を選択する。

エンティティ制約とは、データベース内のキー制約を表すビジネス・ロジック層オブジェクトである。エンティティ制約は、エンティティ・オブジェクトおよび属性に関して、表と列の間のデータベース・レベルの関係を表す。エンティティ・オブジェクトの属性を選択し、主キー、外部キー、チェックまたは一意などのデータベース整合性制約に対応する制約を定義する。エンティティ・オブジェクトに基づいてデータベース・オブジェクトを作成した場合、表間のAssociationの検出、指定されたキー制約のデータベースでの作成、およびデータベース内のデータが有効でキー制約に合致しているかの確認に、エンティティ制約の定義が使用される。

エンティティ定義クラス(entity definition class)

これは、oracle.jbo.server.EntityDefImplから直接的または間接的に拡張したクラスである。このクラスには、属性、イベント、ValidatorAssociationプロパティを含むエンティティ・オブジェクトに関する実行時のメタデータが格納される。このクラスをインスタンス化すると、エンティティ・オブジェクト・クラスのすべてのインスタンスが表される。クライアントはメソッドをコールして、エンティティ・オブジェクトに関する情報(属性名、型、データベース・ソースなど)を検索できる。エンティティのXMLファイルごとに1つのエンティティ定義クラス・インスタンスがある。

独自のcreateメソッドおよびfindメソッドが必要な場合、エンティティ・オブジェクト・ウィザードおよびエンティティ・オブジェクト・エディタを使用して、エンティティ・オブジェクトに対してこのJavaクラスを生成できる。このクラスは、すべてのエンティティ・オブジェクト・インスタンスで使用されるメソッドをグループ化する場合に適している。たとえば、エンティティ定義をインスタンス化する場合に、オプションでcreateDefメソッドを変更し、他のソース(XML以外に別のソース、またはXMLのかわりのソース)のプロパティを使用できる。

エンティティ・オブジェクトが(エンティティ・オブジェクト・ウィザードおよびエンティティ・オブジェクト・エディタの「イベント発行」ページおよび「イベント受信」ページに指定されているように)イベントを発行または受信する場合、発行および受信するエンティティ・オブジェクトの定義ファイルの中にほとんどのイベント・コードが生成される。

このクラスは、カスタム・クラスから拡張するよう指定できる(カスタム・クラスは、EntityDefImplクラスを直接的または間接的に拡張し、プロジェクト・クラスパス内にあることが必要)。たとえば、すでに記述されているコードを再利用する場合、または特別なニーズに合せてビジネス・コンポーネントのフレームワークをカスタマイズするように組織で決定した場合には、このように指定できる。

エンティティ・オブジェクト(entity object)

一般に、エンティティ・オブジェクトは、次のようなビジネス・ポリシーとデータをカプセル化する。

具体的には、エンティティ・オブジェクトにはビジネス・ロジックおよびデータベース表(またはビューシノニムあるいはスナップショット)の列情報を格納する。エンティティ・オブジェクトを既存のデータベース表から作成する(逆方向生成)ことも、エンティティ・オブジェクトを定義し、それを使用してデータベース表を作成する(順方向生成)こともできる。

Business Components for Javaのウィザードを使用して既存の表からエンティティ・オブジェクトを作成する場合、データベース表の各列がエンティティ属性になる。この属性は、列と同じ名前にすることも、ビジネス・アプリケーションの意味を表すような別の名前にすることもできる。エンティティ・オブジェクトには各列の属性を定義できる。また、1つの表に複数のエンティティの情報が含まれている場合は、サブセットを使用することもできる。エンティティ・オブジェクトの属性には、主キーおよび外部キー関係、最大文字数、精度、スケールの仕様、オブジェクトREFの情報などの、導出元のデータベース表で指定されているデータ型情報が格納される。

エンティティ・オブジェクト・ウィザードおよびエンティティ・オブジェクト・エディタを使用して、エンティティ・オブジェクトを作成および編集できる。通常は、表ごとに1つのエンティティ・オブジェクトがある。1つの表に複数のエンティティ・オブジェクトがある場合は、更新可能な属性はそれぞれ1つのエンティティ・オブジェクトにのみ示されるようにする。このようにしない場合は、行を変更しても、その変更は他のエンティティ・オブジェクトに反映されない。

実行時、各エンティティ・オブジェクト・インスタンスは、データベース表の1行を表し、そのデータを格納する。行ごとに1つのインスタンスのみが定義され、同じエンティティ・クラスのすべてのインスタンスは、まとめてキャッシュされる。同じ行を返す複数のビュー・オブジェクトの問合せでは、同じエンティティ・オブジェクト・インスタンスが参照される。このため、更新はすべてのビュー・オブジェクトで参照できるようになり、1つのエンティティ・オブジェクトを複数のビュー・オブジェクトで使用できる。

エンティティ・オブジェクトは、クライアントには公開されていない。かわりに、クライアントは1つ以上のビュー・オブジェクトを介してエンティティ・オブジェクトのデータにアクセスする。ビュー行クラスでは、公開するメソッドをコールするビュー・オブジェクト・メソッドを記述することにより、エンティティ・オブジェクト・メソッドをクライアントに公開できる。

エンティティ・オブジェクト間の関係は、Associationにより表現される。関連元および関連先のエンティティ・オブジェクトの属性(通常はキー・フィールド)は一致している必要がある。Associationを介して行および行セットを返すメソッドは、エンティティ・オブジェクト・クラスで使用できる。

ビジネス・ロジックの大部分は、エンティティ・オブジェクトで実装される。たとえば検証規則(sal > 700など)を使用すると、問合せで無効な値が返されることや、ユーザーが無効な値を表に入力することを回避できる。ビジネス・ロジックは1箇所で定義され更新される。これには、複数のクライアントでビジネス・ロジックを使用し、変更が必要な場合に簡単に更新できるという利点がある。

アプリケーションで必要なエンティティ・オブジェクトを決定するには、通常、UMLオブジェクト指向モデリングの技法を使用する。

エンティティ・オブジェクト・クラス(entity object class)

これは、oracle.jbo.server.EntityImplから直接または間接的に拡張したクラスである。このクラスをインスタンス化すると、1つの行になる。validateEntityメソッドや属性のセッター・メソッドにカスタム検証ロジック・コードを追加したり、ゲッター・メソッドで属性値を計算するなど、メソッドをカスタマイズする場合がある。このような場合、ビジネス・コンポーネント・プロジェクト・ウィザードビジネス・コンポーネント・パッケージ・ウィザードまたはパッケージ・エディタ、あるいはエンティティ・オブジェクト・ウィザードまたはエンティティ・オブジェクト・エディタを使用して、エンティティ・オブジェクトに対してこのJavaクラスを生成できる。このクラスは、カスタム・クラスから拡張するよう指定できる(カスタム・クラスは、EntityImplクラスを直接的または間接的に拡張したもので、プロジェクト・クラスパス内にあることが必要)。たとえば、すでに記述されているコードを再利用する場合、または特別なニーズに合せてビジネス・コンポーネントのフレームワークをカスタマイズするように組織で決定した場合には、このように指定できる。ウィザードでは、オプションで次のものを生成できる。

エンティティ・オブジェクト・ウィザードおよびエンティティ・オブジェクト・エディタ(Entity Object Wizard and Editor)

これらのツールは、エンティティ・オブジェクトの作成および編集に使用する。また、ビジネス・コンポーネント・プロジェクト・ウィザードおよびビジネス・コンポーネント・パッケージ・ウィザードまたはパッケージ・エディタでデフォルトのエンティティ・オブジェクトも作成できる。エンティティ・オブジェクトは、既存の表に基づいて作成(逆方向生成)することも、データベース表の作成に使用(順方向生成)することもできる。

エンティティ・オブジェクト・ウィザードでエンティティ・オブジェクトを作成するには、ビジネス・コンポーネント・プロジェクトが開いている状態で、次のいずれかを行う。

エンティティ・オブジェクトを編集するには、ナビゲータの「ワークスペース」ノードの下にあるエンティティ・オブジェクトを右クリックし、「objectの編集」を選択する。

エンティティ・オブジェクトを作成する場合、ウィザードを使用して次の情報を指定できる。ここでは、ページごとに説明する。

エンティティ・オブジェクトを編集する場合、エディタを使用して次の情報を指定する。

エンティティ・オブジェクトを生成した後で、表に対して参照整合性制約を追加するには、単にエンティティ・オブジェクト・エディタにアクセスし、「終了」をクリックして新しいAssociationを作成するだけである。データベース表のその他の変更は、エンティティ・オブジェクト・エディタで手動で行うことができる。たとえば、新しい列に対応する属性を追加できる。

「式」属性の設定(Expression attribute setting)

この設定は、ビュー・オブジェクト・ウィザードおよびビュー・オブジェクト・エディタ「属性の設定」ページ、ならびにエンティティ属性エディタに表示される。SQL導出ビュー属性では、有効なSQL式を使用して属性の値を定義する。

 

F

フォルトイン・メカニズム(fault-in mechanism)

クライアント上のユーザーが指定した値によって、ビュー・オブジェクトから除外されている属性の値がビジネス・ロジックにより要求されると、ビジネス・ロジック層では、データベースに移動し、主キー値を使用して行のすべての属性(除外されている属性を含む)を取得する。これはフォルトインと呼ばれる。クライアントがビューに含まれていないエンティティ・オブジェクト属性へのアクセスを試行すると、エンティティ・オブジェクトは残りの属性をすべて取得する。フォルトインは、エンティティ・オブジェクト・インスタンス・レベルで行われる。影響を受けた行のみがフォルトインされる。フォルトイン後キャッシュには、フォルトインの結果である完全に移入された1行が含まれる。このオンデマンド・フォルトインにより、要求の失敗が回避される。

たとえば、従業員のレベルおよび名前を含むビュー・オブジェクトがあるとする。エンティティ・オブジェクトによる給与のチェックのレベルを4から3に変更すると、ビューに含まれていない属性の読込みを試行していることになる。フォルトインおよびデータベースへの2回のアクセスを回避するには、給与をビューに含める。

ビュー・オブジェクトを設計する際は、次のことを考慮する必要がある。

順方向生成(forward generation)

まずエンティティ・オブジェクト・ウィザードおよびエンティティ・オブジェクト・エディタでエンティティ・オブジェクトを定義し、次にこれらのエンティティ・オブジェクトを使用してデータベース表を作成し、オプションで「データベース・オブジェクトの作成」ツールを使用して制約を定義する。「逆方向生成(reverse generation)」も参照。

順方向のみのモード(forward only mode)

ビュー・オブジェクトでsetForwardOnlyメソッドを使用して、データをエンティティ・キャッシュに挿入しないようにできる。この方法では、同時に1行しか処理できず、データは変更できない。データを変更する必要がなく、繰り返しデータが少ない場合には、順方向のみのモードを使用すると、オブジェクトがほとんど生成されないため、メモリー・リソースおよび時間が節約される。順方向のみのモードは、データをフェッチしていったん読み込む場合(Webページ用のデータの書式設定、または線形的に処理を行うバッチ処理などの場合)に使用すると便利である。

フレームワーク(framework)

ビルトイン・アプリケーション機能を持つクラス・ライブラリ。フレームワークを使用すると、アプリケーション固有の動作が組み込まれるようベース・クラスが特化され、フレームワークで、オブジェクト間の基本的な対話を調整できる。

ビジネス・コンポーネント・フレームワークの場合、クラスはoracle. jbo.*内にある。

 

H

HTML

Hypertext Markup Languageは、WWW上でハイパー・テキストを公開するための非プロプライエタリな言語。これはSGMLに基づいている。HTMLは、タグを使用してテキストをヘッダー、段落、リスト、ハイパー・テキスト・リンクなどに構造化する。これらはWebブラウザに表示できる。

 

I

IIOP

Internet Inter-ORB Protocol(IIOP)は、Object Request Broker(ORB)クライアントとサーバーの間の通信に使用されるプロトコル。CORBAで使用される。

イテレータ(iterator)

ビュー・オブジェクトは、クライアントが結果セット内の移動に使用できるデフォルトのイテレータ(oracle.jbo.RowIteratorインタフェースを介して)を提供する。ビュー・オブジェクトは、イテレータによりデータが要求されるまで、問合せを実行しない。イテレータを使用して、前方および後方への移動、次および前への移動なども含め、行セットの内容を順に取り出すことができる。行イテレータをRangeとともに使用し、Range内での相対移動など、UIの行のRangeの反復をより簡単にすることができる。Rangeに対応する行イテレータは、グリッド・コントロールに役立つ。

 

J

JSP

JavaServer Pagesテクノロジは、XMLに似たタグおよびJavaで記述されたスクリプトレットを使用することにより、動的Webページを高速に作成する方法を提供する。サーバーまたはプラットフォームに依存しないWebベース・アプリケーションを容易に開発できる。JavaServer Pagesは、JavaサーブレットAPIの拡張である。

JDBC

Java Database Connectivityは、Javaコードからのデータベース内のデータの取得および操作に関するAPI仕様。要求はSQLで行われる。JDBC-ODBCブリッジでは、ODBCを介してデータベースにアクセスする。

 

M

「必須」属性の設定(Mandatory attribute setting)

この設定は、エンティティ・オブジェクト・ウィザードおよびエンティティ・オブジェクト・エディタと、ドメイン・ウィザードおよびドメイン・エディタ「属性の設定」ページ、ならびにエンティティ属性エディタに表示される。

この設定を選択すると、各エンティティ・オブジェクトの行に、この属性に対して必ずNULL以外の値が設定される。NULL値が設定されている場合は、その行の処理が終了する際またはコミットする際に無効であるとみなされる。

エンティティ属性がドメインで、「必須」属性の設定がドメインで設定されている場合は、エンティティ・オブジェクト・ウィザード、エンティティ・オブジェクト・エディタ、またはエンティティ属性エディタで設定をオーバーライドすることはできない。

メタデータ(metadata)

書式設定の方法など、別のデータ・セット(アプリケーション・データ)に関するデータ。Business Components for Javaは、メタデータを、ビジネス・コンポーネントの構造および動作に関する情報を含むXML定義ファイルとして表す。XML定義ファイルには、設計時にBusiness Components for Javaのウィザードを使用して宣言できるアプリケーションの機能および設定に関する説明的な情報が格納される。メタデータの例として、属性の名前と型、SQL問合せおよび検証規則がある。説明的な情報はXMLとして格納されるのに対し、プログラム情報はJavaで格納される。

 

N

「名前」属性の設定(Name attribute setting)

この設定は、ビュー・オブジェクト・ウィザードおよびビュー・オブジェクト・エディタと、エンティティ・オブジェクト・ウィザードおよびエンティティ・オブジェクト・エディタ「属性の設定」ページ、ならびにエンティティ属性エディタに表示される。

必須の属性名の設定では、Business Components for Javaウィザード、Javaソース・コードおよびXMLファイルでの属性の参照に使用される名前を指定する。

 

O

ODBC

Open Database Connectivityは、データベースにアクセスするための標準API。アプリケーションはSQLリクエストを使用してデータベースにアクセスし、ODBCがそのリクエストをこのデータベースが理解できるリクエストに変換する。ODBCは、SQL Access Groupにより作成された。JDBC-ODBCブリッジでは、JDBCを使用しているアプリケーションが、ODBCからアクセス可能なデータベースにアクセスできる。

コミット時ロック(optimistic locking)

エンティティ・オブジェクトがコミット時ロックを使用する場合、コミット時に、エンティティ・オブジェクトはデータベース内の対応する行のロックを試行する。エンティティ・オブジェクトがコンポジットの一部である場合、フレームワークは、親エンティティ・オブジェクトを最初にロックしようとする。このロックの試行に失敗した場合は、例外がスローされる。「即時ロック(pessimistic locking)」も参照。ロックは、oracle.jbo.TransactionインタフェースのsetLockingModeメソッドにより定義される。

 

P

パッケージ(packages)

ビジネス・コンポーネント・プロジェクトでは、パッケージのprivateメソッドおよび変数にアクセスできるように、同じパッケージにグループ化するビジネス・コンポーネント、および異なるパッケージにグループ化するビジネス・コンポーネントを決定する必要がある。別のパッケージのビジネス・コンポーネント間は、publicメソッドおよび変数を介して対話を行う。必要に応じて、他のプロジェクト内でパッケージを再利用することもできる。一般的なガイドラインとして、各アプリケーションに対して、ビジネス・コンポーネント・プロジェクト内に次のパッケージを作成できる。

どのメソッドを内部のチーム・メンバーで使用し、どのメソッドを外部のチームで使用するかに応じて、パッケージ内でグループ化するオブジェクトを機能面から決定する必要がある。1つのコンポーネントとして一緒に配布されるものは、1つのパッケージに入れる。異なるアプリケーション機能を開発しているチームは、それぞれに独立して作業する必要がある。

ビジネス・コンポーネント・パッケージ・ウィザードおよびパッケージ・エディタ(Package Wizard and Editor)

これらのツールは、パッケージの作成および編集に使用する。このウィザードおよびエディタには、ビジネス・コンポーネント・プロジェクト・ウィザードと同じ機能の一部が備わっている。

ビジネス・コンポーネント・パッケージ・ウィザードでパッケージを作成するには、ビジネス・コンポーネント・プロジェクトが開いている状態で、次のいずれかを行う。

パッケージを編集するには、ナビゲータの「ワークスペース」ノードの下にあるパッケージを右クリックし、「packageの編集」を選択する。

ウィザードおよびエディタでは、次の項目を指定できる。

エンティティ・オブジェクト、Association、ビュー・オブジェクトおよびビュー・リンクは、エンティティ・オブジェクト・ウィザードとエンティティ・オブジェクト・エディタビュー・オブジェクト・ウィザードとビュー・オブジェクト・エディタAssociationウィザードとAssociationエディタおよびビュー・リンク・ウィザードとビュー・リンク・エディタを使用して作成および編集できる。

「永続的」属性の設定(Persistent attribute setting)

この設定は、エンティティ・オブジェクト・ウィザードおよびエンティティ・オブジェクト・エディタと、ドメイン・ウィザードおよびドメイン・エディタ「属性の設定」ページ、ならびにエンティティ属性エディタに表示される。

エンティティ属性の場合、属性を永続属性とするにはこの設定を選択する(エンティティにより属性が永続的な記憶域(データベース)に保存される)。一時属性には選択しない。

属性がドメインで、「永続的」属性の設定がドメインで設定されている場合は、エンティティ・オブジェクト・ウィザード、エンティティ・オブジェクト・エディタ、またはエンティティ属性エディタで設定をオーバーライドすることはできない。したがって、一時属性に対しては、ドメインで「永続的」を選択しない。

即時ロック(pessimistic locking)

エンティティ・オブジェクトが即時ロックを使用する場合、その属性の1つが最初に正常に変更された際に(検証の正常終了を含む)、エンティティ・オブジェクトはデータベース内の対応する行のロックを試行する。エンティティ・オブジェクトがコンポジットの一部である場合、フレームワークは、親エンティティ・オブジェクトの行を最初にロックしようとする。このロックの試行に失敗した場合は、例外がスローされる。「コミット時ロック(optimistic locking)」も参照。ロックは、oracle.jbo.TransactionインタフェースのsetLockingModeメソッドにより定義される。

「主キー」属性の設定(Primary Key attribute setting)

この設定は、エンティティ・オブジェクト・ウィザードおよびエンティティ・オブジェクト・エディタと、ドメイン・ウィザードおよびドメイン・エディタ「属性の設定」ページ、ならびにエンティティ属性エディタに表示される。エンティティ・オブジェクト属性の場合は、この設定を選択すると、属性がエンティティ・オブジェクトの主キー(またはその一部)になる。(主キーは複数の属性で構成される場合がある。)

属性がドメインで、「主キー」属性の設定がドメインで設定されている場合は、エンティティ・オブジェクト・エディタで設定をオーバーライドすることはできない。

プロジェクト・ウィザード(Project Wizard)

「ファイル」->「新規プロジェクト」を選択した後で、プロジェクト・ウィザードが表示され、新規プロジェクトを作成できる。次のことを指定する。

ビジネス・コンポーネント・プロジェクトを作成する場合は、「終了」をクリックした後でビジネス・コンポーネント・プロジェクト・ウィザードが表示される。

プロパティ(property)

ビジネス・コンポーネント・プロジェクトでは、プロパティはString型の名前と値のペア。メタデータとして実行時の動作の決定に使用できる。(JavaBeansプロパティと混同しないように。まったく別のものである。)プロパティを持つことができるのは、ドメインエンティティ・オブジェクトビュー・オブジェクトアプリケーション・モジュールおよびエンティティとビューの属性である。プロパティはコンポーネントのXMLファイルに保存される。

エンティティ・オブジェクト・ウィザードエンティティ属性エディタなどのウィザードまたはエディタの適切な「プロパティ」ページで、必要なプロパティを定義できる。プロパティには次のような使用方法がある。

たとえば、属性はLabelプロパティを持つことができる。このプロパティは、属性がUIに表示される場合のラベルを指定する。その他の例としては、表示領域をレイアウトする際マスク(またはピクチャ文字列)を使用する場合がある。社会保障番号を表す文字列のプロパティを定義するには、値000-00-0000のSSN-MASKプロパティを作成する。実行時に、プロパティ名が評価され、適切な形式が必要に応じて適用される。

属性プロパティおよびドメイン・プロパティは、より制限の厳しいプロパティでオーバーライドできる。次に、階層を制限の緩いものから順に示す。

次に例を示す。

エンティティ・オブジェクトのDname属性の長さのプロパティは、20文字のドメインの文字制限をオーバーライドする。したがって、部門名は15文字にすることができる。ビュー・オブジェクトのDname属性の長さのプロパティは、部門名の制限をオーバーライドする。したがって、部門名は10文字にすることができる。

NamedObjectImplクラスで定義されたgetProperty、setProperty、getProperties、getPropertiesAsStringsなどのメソッドを使用し、実行時にプロパティを取得および設定できる。EntityDefImpl、ViewObjectImpl、ApplicationModuleDefImpl、AttributeDefImplなどのその他のクラスは、このクラスを拡張する。クライアントはプロパティの問合せやプロパティ値に基づく決定はできるが、プロパティの設定はできない。

 

Q

「問合せ可能」属性の設定(Queriable attribute setting)

この設定は、ビュー・オブジェクト・ウィザードおよびビュー・オブジェクト・エディタエンティティ・オブジェクト・ウィザードおよびエンティティ・オブジェクト・エディタと、ドメイン・ウィザードおよびドメイン・エディタ「属性の設定」ページ、ならびにエンティティ属性エディタに表示される。

エンティティ・オブジェクト属性の場合、この設定を選択すると、属性をビュー・オブジェクトの問合せ条件に指定できる。設定を選択しない場合は、情報の問合せはできない(BLOB型など)。

ビュー属性の場合、この設定を選択すると、属性を問合せ条件に使用できる。永続属性では、列(この型の属性のマップ先)が問合せフィルタ(WHERE句)の一部として使用できる場合は、この設定を選択する。たとえば、列の型がNUMBERの場合はこのプロパティを選択するが、BLOB型の場合は選択しない。この属性は、BC4J JSPなどで生成された問合せフォームで使用される。

属性がドメインで、「問合せ可能」属性の設定がドメインで設定されている場合は、設定はビュー・オブジェクト・ウィザードまたはビュー・オブジェクト・エディタでオーバーライドできるが、エンティティ・オブジェクト・ウィザードまたはエンティティ・オブジェクト・エディタではオーバーライドできない。

 

R

「リフレッシュ」属性の設定(Refresh After attribute setting)

この設定は、エンティティ・オブジェクト・ウィザードおよびエンティティ・オブジェクト・エディタと、ドメイン・ウィザードおよびドメイン・エディタ「属性の設定」ページ、ならびにエンティティ属性エディタに表示される。

永続エンティティ・オブジェクト属性には、任意で次の設定のいずれか(または両方)を設定できる。

属性がドメインで、「リフレッシュ」属性の設定がドメインで設定されている場合は、エンティティ・オブジェクト・ウィザードまたはエンティティ・オブジェクト・エディタで設定をオーバーライドすることはできない。

逆方向生成(reverse generation)

最初に、データベース表(また、ビューシノニムおよびスナップショット)を定義し、次にそのデータベース表を使用してエンティティ・オブジェクト・ウィザードまたはエンティティ・オブジェクト・エディタビジネス・コンポーネント・プロジェクト・ウィザードおよびビジネス・コンポーネント・パッケージ・ウィザードまたはパッケージ・エディタエンティティ・オブジェクトを作成する。「順方向生成(forward generation)」も参照。

ロールバック(rollback)

現在のトランザクションに対して行われた変更を取り消す。リカバリ処理の後半部分。ロールフォワードの後、コミットされていない変更を元に戻す必要がある。REDOログ・ファイルが適用された後、ロールバック・セグメントを使用し、コミットされていないがREDOログに記録されたトランザクションを特定して取り消す。Oracleでは、この手順を自動的に完了する。

行オブジェクト(row object)

oracle.jbo.Rowインタフェースを実装するオブジェクト。ビュー・オブジェクト問合せで1行以上の結果の行がフェッチされると、各行がRowオブジェクトで表される。結果の行の各列値には、行インタフェースの属性を使用してアクセスする。行インタフェースには、getAttributeやsetAttributeなどのメソッドがある。

 

S

「問合せで選択済」属性の設定(Selected in Query attribute setting)

この設定は、ビュー・オブジェクト・ウィザードおよびビュー・オブジェクト・エディタ「属性の設定」ページに表示される。選択されている場合、この属性はビュー・オブジェクトのSQL SELECT文に表示される。選択されていない場合は表示されない。

サーバー(server)

クライアントにより要求されたサービスを提供する。ソフトウェア構成によっては、1台のマシンをクライアントとサーバーの両方として設定できる。

SID

Oracleデータベース・インスタンスの一意の名前。データベースへの接続を指定するには、ユーザーがSIDを指定する必要がある。

スナップショット(snapshot)

リモート・ノードにあるマスター表の読取り専用コピー。スナップショットには問合せはできるが、更新はできない。マスター表のみを更新する必要がある。スナップショットは、マスター表に対する変更を反映するために定期的にリフレッシュされる。この意味においては、スナップショットは実際には周期性のあるビューである。

ストアド・プロシージャ(stored procedure)

DBMSに格納されたコード・モジュールであり、データベースに対する操作を実行する。多くの場合、SQLで記述される。

シノニム(synonym)

表、ビュー、スナップショット、順序、プロシージャ、ファンクションまたはパッケージの別名。識別を簡単にするために表に割り当てられた別の名前である。たとえば、他のアカウントまたはデータベースに存在する表を参照する場合は、長い識別文字列のシノニムを定義すると便利な場合がある。表名が変更された場合は、関連する問合せを書きなおすかわりにシノニムを再定義するだけですむ。シノニムは、オブジェクトの実際の名前と所有者のマスク、オブジェクトへのパブリック・アクセスの提供、リモート・データベースの表、ビューまたはプログラム単位の位置の透過性の提供、およびデータベース・ユーザーのSQL文の簡略化に使用される。シノニムは、パブリックにもプライベートにもできる。

 

T

Business Component Browser

Business Component Browser(Business Component Testerとも呼ばれる)にアクセスするには、ナビゲータの「ワークスペース」ノードの下にある、アプリケーション・モジュールを右クリックし、「テスト」を選択する。

Oracle Business Component Browserは、Thin Javaクライアントの汎用アプリケーションである。これは、フレームワークのクライアントAPIの動的な機能を使用して、使用するアプリケーション・モジュールの実行時のメタデータを問い合せ、現行のアプリケーション・モジュールに含まれているビュー・オブジェクトおよびビュー・リンクのディレクトリを示す。Business Component Browserは、参照する各ビュー・オブジェクトに対してSwingベースの動的なフォームを作成し、テストする各ビュー・リンクに対して動的なマスター/ディテール・フォームを作成する。

Oracle Business Component Browserは、フレームワークの次のような実行時の特性をすべて視覚的に表す。

コミットを行うと、キャッシュ内の基になるエンティティ・オブジェクトにより、保留中のすべての変更がデータベースに送られる。

Thinクライアント(thin client)

表示に必要なデータのみを取得するクライアントビジネス・ロジックは別の層で実行される。

トランザクション(transactions)

トランザクションは、データベース操作を管理するためのインタフェースである。トランザクション内のデータ変更の操作がすべて成功していない場合、その変更はサーバーに受け入れられない。これらの操作には、属性値や標準のSQLコール(INSERT、UPDATE、DELETEなど)を設定するメソッド、またはJavaストアド・プロシージャやSQLパッケージのコールなどの特殊なコールを設定するメソッドが含まれる。トランザクションは最小の単位である。つまり、1つのトランザクション内の操作の結果は、すべてコミット(データベースに保存)されるか、すべてロールバック(元に戻される)される。

たとえば、銀行サービスを使用するクライアントが普通預金口座から当座預金口座へ振替を行う場合、トランザクションは、普通預金口座の減額、当座預金口座の増額、取引記録への取引の記録という3つの異なる操作から構成される。3つの操作すべてが実行されて口座の残高が適切であれば、トランザクションはコミットされ、操作の結果がデータベースに適用される。しかし、(残高の不足、無効な口座番号、ハードウェア障害などの)なんらかの理由で操作のいずれかが完了されない場合、すべての口座の残高が正しくなるようトランザクション全体をロールバックする必要がある。

また、トランザクションにより、複数ユーザーが共有するデータ・ストアの一貫性が保たれる。あるクライアントがデータを変更する場合、ロックが行われ、最初のクライアントが操作を完了するまで他のクライアントは他の変更を行えなくなる。トランザクションがコミットまたはロールバックされた場合、ロックが解放される。

Business Components for Javaアプリケーション・モジュールでは、デフォルトのトランザクションおよび同時実行サポートが提供されている。デフォルトの動作をカスタマイズする場合以外は、コーディングの必要はない。

ビジネス・コンポーネントを使用してプログラミングする場合、トランザクション管理の原則はビジネス・ロジック層でもクライアントでも同じである。

  1. データベースに接続するアプリケーション・モジュールを作成し、トランザクションのコンテキストを確立する。

  2. 問合せを実行する。

  3. 結果セットを操作する(属性を設定し、値を検証する)。

  4. 変更をデータベースにコミットする(新規データを他のアプリケーション・モジュールに対して使用可能にする)か、ロールバックする。

ビジネス・コンポーネント・フレームワークでは、キャッシュとデータベースで変更の同期をとるため、(変更指向の方法ではなく)バッチ指向の方法が使用される。この方法には、次のような利点がある。

「型」属性の設定(Type attribute setting)

この設定は、ビュー・オブジェクト・ウィザードおよびビュー・オブジェクト・エディタエンティティ・オブジェクト・ウィザードおよびエンティティ・オブジェクト・エディタと、ドメイン・ウィザードおよびドメイン・エディタ「属性の設定」ページ、ならびにエンティティ属性エディタに表示される。すべてのJava変数には型が定義されており、この型によって、割当てが可能なオブジェクトの種類が制限される。

エンティティ・オブジェクト属性の場合、この設定は属性のJavaデータ型またはドメイン型となる。「データベース列」の「型」も指定する。これはデータベース列のSQLデータ型で、実行時にデフォルトのJava JDBC型を導出する際に使用する。SQLデータ型はJavaデータ型と一致している必要がある。一致していない場合は、文字列の変換などで実行時にランタイム例外が発生することがある。順方向生成の際には、「データベース列」の「型」がデータベースの列の型となる。

ビュー・オブジェクト属性の場合、この設定は属性のJavaデータ型またはドメイン型となる。永続属性、およびエンティティ導出属性では、対応するエンティティ属性で指定した型はオーバーライドできない。

ドメインの場合、この設定は、ドメインのメタデータ・フィールドのJava型となる。

属性がドメインで、「データベース列」の「型」属性の設定がドメインで設定されている場合は、エンティティ・オブジェクト・ウィザードまたはエンティティ・オブジェクト・エディタで設定をオーバーライドすることはできない。

 

U

UML

Object Management Group(OMG)のUnified Modeling Languageは、複雑なソフトウェアの仕様を明確にし、視覚化するための、Booch法、OMT法、OOSE法などの以前からの標準に基づく一般的な表記言語。この言語は、大規模なオブジェクト指向プロジェクトでの使用に適している。

「一意」属性の設定(Unique attribute setting)

この設定は、エンティティ・オブジェクト・ウィザードおよびエンティティ・オブジェクト・エディタと、ドメイン・ウィザードおよびドメイン・エディタ「属性の設定」ページ、ならびにエンティティ属性エディタに表示される。

永続エンティティ・オブジェクト属性の場合、この設定を選択すると、特定の値を持つ行は1行のみとなる(この列の各行には一意の値が定義される)。順方向生成の場合は、データベースの対応するNOT NULL制約が作成される。

属性がドメインで、「一意」属性の設定がドメインで設定されている場合は、エンティティ・オブジェクト・ウィザードまたはエンティティ・オブジェクト・エディタで設定をオーバーライドすることはできない。

「更新可能」属性の設定(Updateable attribute setting)

この設定は、ビュー・オブジェクト・ウィザードおよびビュー・オブジェクト・エディタエンティティ・オブジェクト・ウィザードおよびエンティティ・オブジェクト・エディタと、ドメイン・ウィザードおよびドメイン・エディタ「属性の設定」ページ、ならびにエンティティ属性エディタに表示される。この設定により、属性に対してsetAttributeメソッドをコールできるかどうかが定義される。属性には、「更新可能」設定として次のいずれかを定義する必要がある。

永続ビュー属性またはエンティティ導出ビュー属性では、属性を更新可能にするかどうかの設定を対応するエンティティ属性よりさらに制限することはできるが、緩和することはできない。したがって、エンティティ属性の設定が「なし」でビュー属性の設定が「常に」の場合、設定は「なし」になる。属性がドメインの場合も、同様である。

 

V

検証ロジック(validation logic)

Business Components for Javaには、ビジネス・ロジック層で検証ロジックを定義、実装および実行するためのフレームワークが用意されている。検証フレームワークでは、内部の実装の詳細が隠された、一貫したプログラミング・モデルが提供される。これにより、ユーザーが無効な値をデータベースに入力できないようにする規則に集中できる。

検証は、整合性(またはデータベースの)制約とは異なる。整合性制約は、表の列にビジネス・ルールを定義する宣言である。整合性制約は、表で定義され、表定義の一部として、データベースのデータ・ディクショナリに主として保存される。これによって、すべてのデータベース・アプリケーションに同じ規則が適用される。Business Components for Javaを使用しないクライアントには、(検証の他に)整合性制約を使用できる。

次のプログラムによる手法(Java)または宣言による手法(XML)を使用し、検証ロジックを定義および適用できる。検証に様々なレベルが定義されている場合は、その検証は一貫してこの順序で起動される。

ビジネス・コンポーネント・フレームワークは、様々な検証レベルをサポートする。属性、エンティティおよび論理ビジネス・オブジェクトを検証できる。JDeveloperは、データが作成または変更された際に適切なレベルで検証ロジックをコールするが、表にすでに存在しているデータは有効であると仮定する。問合せにより、無効な値(たとえば、検証ロジックが適用される前に入力されたレガシー・データからの値)が含まれた結果セットが返されることがあるが、ユーザーが表に無効な値を入力することはできない。フレームワークでは、最上位レベルのオブジェクトで規則が起動される前に、これに含まれるオブジェクトで規則が起動される。

検証規則(validation rule)

エンティティ・オブジェクトでは、検証規則を使用し、問合せで有効な値が返されること、またはユーザーが無効な値を表に入力しないことを保証する(たとえば、従業員の給与が700を超えてはならないなど)。検証規則は、エンティティ・オブジェクト全体で使用する再利用可能な検証コードをカプセル化するJavaBeansである。

エンティティ・オブジェクト・ウィザードおよびエンティティ・オブジェクト・エディタ、ならびにエンティティ属性エディタの「検証」ページでは、検証規則と検証レベル、および同じレベル内での実行順序を指定できる。検証レベルは、選択内容に応じて規則が属性レベルとエンティティ・オブジェクト・レベルのいずれに適用されるかを示す。検証規則を適用するには、XMLメタデータをエンティティ・オブジェクトに結び付ける。すべてを記述するのではなく、ウィザードを使用すると、XMLが生成され、Javaコードを再コンパイルせずに規則をカスタマイズできる。

実行時に、属性レベルの検証規則は、生成されたセッター・メソッドを介して属性値が変更された場合、またはエンティティ・オブジェクトでコールされたsetAttributeメソッドにより属性値が変更された場合に起動される。エンティティ・レベルの検証規則は、クライアントのイテレータ内の現在の行が、あるエンティティ・オブジェクトから次のエンティティ・オブジェクトに変わった場合、エンティティ・オブジェクトが無効であればコミット・サイクル中、またはエンティティ・オブジェクトでvalidateメソッドが明示的にコールされた場合に起動される。

Business Components for Javaには定義済の規則が用意されているが、独自の規則も作成できる。

ビジネス・コンポーネント・プロジェクト・エディタの「登録済の規則」ページでは、プロジェクト内にある検証クラスで実装されたカスタム検証規則を作成および登録できる。「新規」をクリックして新規クラスを作成し、カスタマイズするか、すでにカスタマイズされているクラスを登録する。登録済の検証規則は、プロジェクトのXML定義(JPXファイル)とともにリストとして保存される。登録済の規則は、定義済の検証規則の1つで行う場合と同じように、エンティティ・オブジェクトまたは属性に適用できる。

ビュー(view)

1つ以上のデータベース表の列から構成され、1つの論理表に結合されているデータソース。1つ以上の表のデータのカスタム調整された表示形式。ストアド・クエリーとも呼ばれる。ビューは仮想表の一種である。つまり、問合せを実行する際には表のように動作するが、実際には表のサブセット、表の組合せまたは2つ以上の表の結合へのポインタとして機能するオブジェクトである。

UMLでは、ビューはモデルの投影である。投影は、要素のセットからそのサブセットへのマップである。モデルの投影は、特定の観点または視点から見たものであり、この観点に関連しないエンティティを除外する。

ビュー・リンク(view link)

表のビューを表すビュー・オブジェクト間の関係を定義する。関係は1対1または1対多にすることができ、複数のビュー・リンクを使用して多対多関係を作成できる。ビュー・リンク・ウィザードおよびビュー・リンク・エディタでリンク元とリンク先のビュー・オブジェクトを指定すると、ビュー・オブジェクトから選択した属性を使用してビュー・オブジェクトがリンクされる。

1対多関係の例として、マスター/ディテール関係のEmployeeViewビュー・オブジェクトにリンクされたDepartmentViewビュー・オブジェクトがある。このビュー・リンクでは、特定の部門の従業員に関する情報を効率的に参照できる。

さらに複雑な1対多関係としては、マスター/ディテール関係でOrderViewビュー・オブジェクトにリンクしているCustomerViewビュー・オブジェクトや、マスター/ディテール関係でItemViewビュー・オブジェクトにリンクしているOrderViewビュー・オブジェクトがある。ユーザーは、特定の顧客の注文の品目を1つのフォームで簡単に調べられる。

ビュー・リンクは、Associationに基づいて作成できるが、ビュー・リンクを使用するためにはAssociationは必要ない。デフォルトの関係が適切な機能を提供しない場合は、ビュー・リンク・ウィザードまたはビュー・リンク・エディタの「SQL設定」ページを介して複合関係を作成できる。

ビュー・オブジェクトがリンクのディテール・ビューとして指定されている場合、ビュー・オブジェクトはディテール情報にデータを制限する(ビュー・オブジェクトを定義するSQL文へのWHERE句の追加など)。そうでない場合、ビュー・オブジェクトはすべてのデータが使用可能な無制限ビューを提供する。つまり、ビュー・リンクでは、マスター・ビューにより提供されているバインド値に基づき、これに関連するビューが選択される。

2つのビュー・オブジェクトがアプリケーション・モジュールでマスター/ディテール関係でリンクされている場合、マスター・ビュー・オブジェクトのデフォルトの(すなわち最初の)イテレータにより、ディテール・ビュー・オブジェクトをリフレッシュするためのイベントが起動される。ディテール・ビュー・オブジェクトが作成されると、ビジネス・コンポーネントのフレームワークにより、マスターのイテレータのイベント・リスナーとして登録される。このため、イテレータがマスター・ビュー・オブジェクト内の別の行に移動すると、ディテール・ビュー・オブジェクトの内容は自動的にリフレッシュされる。

アプリケーション・モジュールではビュー・リンクを再利用できる。ビジネス・コンポーネントAPIを使用し、実行時にビュー・リンクを動的に作成することもできる。

ビュー・リンクが既存のAssociationを基にしており、そのAssociationがコンポジットとして定義されている場合は、ディテール・ビュー行を作成する際にマスター・ビュー行が存在している必要があり、そのマスター・ビュー行にはnull以外のキー値が必要であることに注意する。Associationがコンポジットとして定義されていない場合は、このような制限は適用されない。

UMLでは、リンクは、2つ以上のオブジェクト間の接続を表すAssociationのインスタンス。

ビュー・リンク・ウィザードおよびビュー・リンク・エディタ(View Link Wizard and Editor)

これらのツールは、ビュー・リンクの作成および編集に使用する。また、ビジネス・コンポーネント・プロジェクト・ウィザードビジネス・コンポーネント・パッケージ・ウィザードおよびエンティティ・オブジェクト・ウィザードを使用することにより、既存のAssociationに基づいて、デフォルトのビュー・リンクを作成することもできる。

ビュー・リンク・ウィザードでビュー・リンクを作成するには、ビジネス・コンポーネント・プロジェクトが開いている状態で、次のいずれかを行う。

ビュー・リンクを編集するには、ナビゲータの「ワークスペース」ノードの下にあるビュー・リンクを右クリックし、「linkの編集」を選択する。

ビュー・リンクを作成する場合、ウィザードを使用して次の情報を指定できる。ここでは、ページごとに説明する。

ビュー・リンクを編集する際に、エディタを使用して同じ情報を指定できる。

ビュー・オブジェクトを作成した後にAssociationを追加する場合は、ウィザードでリンクを手動で追加できる。

ビュー・オブジェクト(view object)

SQL問合せを使用して、エンティティ・オブジェクトからフィルタリングされる属性のサブセットを指定する。データのビューは、SQLに基づいているが、基礎となるエンティティ・オブジェクトとは別であるため、必要なUIをサポートする柔軟性の高いデータ取得が実現する。つまり、画面に表示する必要のあるデータのセットを問い合せることができる。ビュー・オブジェクトにより、クライアントには、基礎となるエンティティ・オブジェクトを意識せずに、またはこれらに関する知識がない場合でも、スクロールして更新ができる行セットが提供される。クライアントは結果セット内を移動し、属性値を取得および設定することにより、データを操作する。トランザクションがコミットされると、基礎となるデータベース内のデータが変更される。ビュー・オブジェクト間の関係は、ビュー・リンクを使用して表される。各ビュー・オブジェクトは、結果セット内の移動に使用できるデフォルトのイテレータを提供する。

ビュー・オブジェクトは、通常、次の場合に使用される。

1つのエンティティ・オブジェクトに対して複数のビュー・オブジェクトを定義できる。また、1つのビュー・オブジェクトは複数のエンティティ・オブジェクトからデータを選択できる。データはエンティティ・オブジェクト・レベルでキャッシュされ、同じトランザクション内のすべてのビュー・オブジェクト参照でそのキャッシュを共有するため、あるビュー・オブジェクトを介して行われた変更は、同じトランザクション内の他のビュー・オブジェクトでただちに使用可能になる。

ビュー・オブジェクトを定義する場合、どの基礎エンティティ・オブジェクトを読取り専用にするか、およびどのエンティティ・オブジェクトでビュー・オブジェクトの属性リスト内の属性に対する読み書き操作を可能にするかを指定できる。

アプリケーション・モジュール・ウィザードおよびアプリケーション・モジュール・エディタでは、マスター/ディテール関係でビュー・オブジェクトをリンクするために使用するビュー・リンクを選択できる。ビュー・リンクは、実行時に実行されるコード内でも指定できる。ディテール・ビュー・オブジェクトは、自動的に、対応するマスター・ビュー・オブジェクトと同期化される。

アプリケーション・モジュールは、無制限ビューやディテール・ビューなど同じビュー・オブジェクトを何回も使用できる。別名を指定して、所定のビュー・オブジェクトの様々な使用方法を表すことができる。

ビュー・オブジェクト・クラス(view object class)

oracle.jbo.server.ViewObjectImplを直接的または間接的に拡張するクラス。メソッドをカスタマイズする(ビュー・オブジェクト・インスタンスのビュー定義の一部を動的に変更できるようにcreateメソッドをオーバーライドする場合など)には、ビジネス・コンポーネント・プロジェクト・ウィザードビジネス・コンポーネント・パッケージ・ウィザードまたはパッケージ・エディタまたはビュー・オブジェクト・ウィザードおよびビュー・オブジェクト・エディタを使用して、このJavaクラスを作成できる。たとえば、WHERE句へのバインド変数の自動的な設定や、セキュリティやフィルタリングのためのWHERE句条件の自動的な追加などを行う場合がある。また、クライアントが、複数クライアント表から自身の情報のみを問合せできるようにするには、そのためのWHERE句を各フォームで追加するかわりに、クライアントIDを確認できる。デフォルトの行セットを操作し、行ではなく、ビュー・オブジェクトに固有である場合、メソッドは、ビュー行クラスにではなく、ビュー・オブジェクト・クラスに置く。

このクラスは、カスタム・クラスから拡張するよう指定できる(カスタム・クラスは、ViewObjectImplクラスを直接的または間接的に拡張したもので、プロジェクト・クラスパス内にあることが必要)。たとえば、すでに記述されているコードを再利用する場合、または特別なニーズに合せてビジネス・コンポーネントのフレームワークをカスタマイズするよう決定した場合には、このように指定する。

ビュー・オブジェクト・ウィザードおよびビュー・オブジェクト・エディタ(View Object Wizard and Editor)

これらのツールは、ビュー・オブジェクトの作成および編集に使用する。デフォルトのビュー・オブジェクトは、ビジネス・コンポーネント・プロジェクト・ウィザードエンティティ・オブジェクト・ウィザードまたはエンティティ・オブジェクト・エディタおよびビジネス・コンポーネント・パッケージ・ウィザードまたはパッケージ・エディタでも作成できる。

デフォルトのビュー・オブジェクトの定義内容は非常に単純である。このため、ビュー・オブジェクト・ウィザードおよびビュー・オブジェクト・エディタを使用してビュー・オブジェクトを作成し、ニーズに合せて編集する。ここでは、次のものを使用するビュー・オブジェクトを対象とする。

1つのビュー・オブジェクトで複数の更新可能エンティティ・オブジェクトを使用できることにより、Business Components for Javaの主要な機能の1つが可能になる。この機能は、1つのビュー・オブジェクトで複数のエンティティ・オブジェクトを更新できることである。

ビュー・オブジェクト・ウィザードでビュー・オブジェクトを作成するには、ビジネス・コンポーネント・プロジェクトが開いている状態で、次のいずれかを行う。

ビュー・オブジェクトを編集するには、ナビゲータの「ワークスペース」ノードの下にあるビュー・オブジェクトを右クリックし、「objectの編集」を選択する。

ビュー・オブジェクトを作成する場合、ウィザードを使用して次の情報を指定できる。ここでは、ページごとに説明する。

ビュー・オブジェクトを編集する場合、これまでのページの情報の他に、エディタを使用して次の情報を指定できる。

ビュー・オブジェクトを作成した後でデータベース表を変更し、ビュー・オブジェクトを変更する必要がある場合には、ビュー・オブジェクト・エディタで手動で変更できる。たとえば、エンティティ・オブジェクト内の新しい列に対応する属性をエンティティ・オブジェクトに追加できる。

ビュー行クラス(view row class)

oracle.jbo.server.ViewRowImplを直接的または間接的に拡張するクラス。メソッドをカスタマイズするときは、ビュー・オブジェクト・ウィザードまたはビュー・オブジェクト・エディタを使用してこのJavaクラスを作成できる。たとえば(属性のゲッター・メソッドに)このビューの値を計算するカスタム・ロジックを実装する場合がある。このクラスでは、行を操作するメソッド、つまり操作に1行のデータが必要なメソッドを持つことができる。ビュー・オブジェクト・クラスに、行セットに対して機能するメソッドを追加できる。また、エンティティ・オブジェクトのメソッドをコールする行クラス・メソッドを作成することにより、エンティティ・オブジェクト・メソッドをクライアントに公開できる。

このクラスは、カスタム・クラスから拡張するよう指定できる(カスタム・クラスは、ViewRowImplクラスを直接的または間接的に拡張したもので、プロジェクト・クラスパス内にあることが必要)。たとえば、すでに記述されているコードを再利用する場合、または特別なニーズに合せてビジネス・コンポーネントのフレームワークをカスタマイズするよう決定した場合には、このように指定する。ウィザードでは、オプションとしてアクセッサ・メソッド(たとえばgetJobやsetJobなど)の生成を選択できる。これによって、対応する属性フィールドに対するタイプ・セーフなアクセスが提供され、ここに検証のための独自のカスタム・コードを追加できる。

 

W

ウィザード(wizards)

Business Components for Javaでは、次のウィザード、エディタおよびツールが提供される。

 

X

XML

eXtensible Markup Languageは、電子的データ交換の標準を定義する。XMLでは、データの作成および解釈を明確に実行できるように、データ固有の構造を表す厳密なテキストベースの方法が指定される。単純なタグベースの方法により、開発者のHTMLの知識を利用する一方で、高度な構造のデータベース・レコードから体系化されていない文書にいたる、あらゆるデジタル資産を処理できる柔軟性が高く充実した機能を提供する。