A B C D E F H I J M N O P Q R S T U V W X
A |
この設定は、ビュー・オブジェクト・ウィザードおよびビュー・オブジェクト・エディタの「属性の設定」ページ、ならびにエンティティ属性エディタに表示される。ビュー・オブジェクト属性の場合、別名が属性名と異なる(デフォルト)場合、別名はビュー・オブジェクトのSQL文の一部になる。たとえば、myEnameを「Ename」属性の別名として入力した場合、SQL文には句Emp.Ename as myEname
が含まれる。別名は、結合での主キーと外部キーのように2つの同一属性名があり、それらの名前を一意にする必要がある場合に役立つ。
ビジネス・ロジック層には、他の層(クライアントおよびデータベース)が対話する1つ以上のアプリケーション・モジュールがある。アプリケーション・モジュールは、オンライン注文の処理や昇給の処理などの特定のアプリケーション・タスクを実行する。アプリケーション・モジュールには、次の主要な特性がある。
クライアントが使用するデータ・モデルを表す。データ・モデルを作成するために、アプリケーション・モジュールには、ビュー・オブジェクトおよびビュー・リンクのインスタンスなどのビジネス・コンポーネントが含まれる。(これは、Javaフレームにリスト・ボックスやグリッド・コントロールなどのコンポーネントのインスタンスを含めることと同じである。)
ネストしたアプリケーション・モジュールと呼ばれる他のアプリケーション・モジュールを含むことができる。1つのアプリケーション・モジュールに、様々な基本的アプリケーション・モジュールを含め、これを組み合せて複雑な機能を提供できる。たとえば、OnlineOrdersアプリケーション・モジュールには、AddNewCustomerアプリケーション・モジュールを含めることができる。
データベース内のデータに影響するすべての変更を管理する。最上位レベルのアプリケーション・モジュールは、その中に含まれるビュー・オブジェクト・インスタンスのトランザクション・コンテキストを提供する。これには、ネストされたすべてのアプリケーション・モジュール内のインスタンスも含まれる。これは、アプリケーションに必要なアプリケーション・モジュールを決定する際に考慮すべき重要な事項である。たとえば、注文の作成と顧客の追加を同じトランザクションに含めることができる。
リモートでアクセス可能なメソッドを提供する。このメソッドは、アプリケーション・モジュールの動作を実装する。カスタム・メソッドを追加し、クライアントで使用するこれらのpublicメソッドを選択的にエクスポートできる。たとえば、従業員の昇給を処理するアプリケーション・モジュールは、従業員の給与情報を検索して昇給額を加算するメソッドをエクスポートできる。
最上位レベルのアプリケーション・モジュールには、データベースへの接続が1つある。
コードを変更せずに、同じアプリケーション・モジュールをCORBA、EJB、ローカルなどの複数の構成でデプロイできる。また、コードを変更せずに、同じアプリケーション・モジュールを(層が1台、2台または3台のコンピュータにある)物理的に1層、2層または3層のアプリケーションで使用できる。開発の完了後に、特定のデプロイメント・プラットフォームに依存することはない。
アプリケーション・モジュールは個別の単位であるため、他のアプリケーションのビジネス・ロジック層で簡単に再利用できる。
ビジネス・ロジック層をプログラミングする際に、ビジネス・ロジックは、ビジネス・コンポーネントの再利用を簡単にするために様々なレベルに配置される。
エンティティ・オブジェクトには、単一のビジネス・エンティティに関連するビジネス・ロジックが含まれる。エンティティ・オブジェクトに基づくすべてのビュー・オブジェクトは、ロジックを共有する。エンティティ・レベルでは、計算はJavaコードで実行される。
ビュー・オブジェクトには、SQLのSELECT文で定義される、ビューに関連するロジックが含まれる。これには、SQLの計算式、結合、UNION、ネストした副問合せなどが含まれる。Javaソースにコードを追加することもできる。たとえば、UIにイベントを伝播したり、このビューで公開するエンティティ・メソッドをコールするメソッドを作成できる。
アプリケーション・モジュールのソース・ファイルには、実行するタスクに固有のロジックを含めることができる。これは、エンティティ・オブジェクトまたはビュー・オブジェクトに含めるのには適していないロジックで、異なるタスクを実行する複数のアプリケーション・モジュールで使用できる。2つのアプリケーションで同じビューを使用する場合、一方のアプリケーションに固有のロジックは、エンティティまたはビュー・オブジェクトのソース・ファイルではなく、そのアプリケーション・モジュールのソース・ファイルに含める。一般的なガイドラインとしては、タスクごとに1つのフォームがある場合、フォームごとに1つのアプリケーション・モジュールが存在するようアプリケーションを作成できる。アプリケーション・モジュールは、1つのトランザクション内で完了するタスクのデータ・モデルを表す。
アプリケーション・モジュールでは、クライアント・インタフェース(フォームなど)に合せてデータを収集するため、複数回ではなく1回のネットワーク・ラウンドトリップでデータを取得できる。リモート・アクセス可能なメソッドを介してビジネス・ロジック層で計算を実行し、クライアントのオーバーヘッドを削減することもできる。アプリケーション・データのバルク操作の場合、すべてのデータをクライアントにダウンロードするのではなく、ビジネス・ロジック層で操作を行う。クライアントが現在表示しているデータへの変更は、自動的に同期化される。
アプリケーション・モジュールを設計時に作成および編集するには、アプリケーション・モジュール・ウィザードおよびアプリケーション・モジュール・エディタを使用する。また、ビジネス・コンポーネント・プロジェクト・ウィザードおよびビジネス・コンポーネント・パッケージ・ウィザードを使用することにより、デフォルトのアプリケーション・モジュールも作成できる。
実行時、クライアントは使用するアプリケーション・モジュールのインスタンスを作成する。作成できるのは、設計時に作成したアプリケーション・モジュールのインスタンス、または汎用アプリケーション・モジュールと呼ばれるベース・アプリケーション・モジュール・クラスのインスタンスである。汎用アプリケーション・モジュールは、動的に作成されたビュー・オブジェクト、ビュー・リンクおよびアプリケーション・モジュールのコンテナが必要な場合に使用できる。たとえば、クライアント・メニューに多数のタスクが含まれた、複雑なアプリケーションがある場合、メニューでの選択に基づいて、同じトランザクション内で、アプリケーション・モジュールを必要に応じてインスタンス化する汎用アプリケーション・モジュールを作成できる。
クライアントは、プール内のアプリケーション・モジュール・インスタンスを使用できる。たとえば、あるWebアプリケーションを最大1000人のユーザーが使用できる場合に、特定のアプリケーション・モジュールは同時に100人のユーザーしか使用しないとする。この場合、プール内に100個のアプリケーション・モジュール・インスタンスを保持する。あるクライアントでアプリケーション・モジュール・インスタンスが必要になると、そのクライアントは、プール内の空きインスタンスを取得し、トランザクションをコミットまたはロールバックした後で、プールに解放する。インスタンスはあらかじめ作成されているため、エンド・ユーザーは、タスクを実行する際にアプリケーション・モジュールをインスタンス化する時間が短縮される。通常は、WebベースのJSPクライアントでプールを使用する。
oracle.jbo.server.ApplicationModuleImplから直接的または間接的に拡張されるJavaクラス。アプリケーション・モジュール・ウィザード、ビジネス・コンポーネント・プロジェクト・ウィザードまたはビジネス・コンポーネント・パッケージ・ウィザードでこのクラスを生成できる。アプリケーション・モジュール・タスクに固有で、ビュー・オブジェクトまたはエンティティ・オブジェクト・クラスに含めるのには適していないメソッドなどのカスタム・コードを、ソース・ファイルに追加できる。
このクラスは、オプションでカスタム・クラスから拡張するよう指定できる(カスタム・クラスは、ApplicationModuleImplクラスを直接的または間接的に拡張し、プロジェクト・クラスパス内にあることが必要)。たとえば、すでに記述されているコードを再利用する場合、または特別なニーズに合せてビジネス・コンポーネントのフレームワークをカスタマイズするよう決定した場合には、このように指定する。
これらのツールは、アプリケーション・モジュールの作成および編集に使用する。また、ビジネス・コンポーネント・プロジェクト・ウィザードおよびビジネス・コンポーネント・パッケージ・ウィザードを使用することにより、デフォルトのアプリケーション・モジュールも作成できる。
アプリケーション・モジュール・ウィザードでアプリケーション・モジュールを作成するには、ビジネス・コンポーネント・プロジェクトが開いている状態で、次のいずれかを行う。
「ファイル」->「新規」を選択し、「Business Tier」->「Business Components(BC4J)」を選択して「アプリケーション・モジュール」をダブルクリック
ナビゲータの「ワークスペース」ノードの下にある、ビジネス・コンポーネント・パッケージを右クリックし、「新規アプリケーション・モジュール」を選択
アプリケーション・モジュールを編集するには、ナビゲータの「ワークスペース」ノードの下にあるアプリケーション・モジュールを右クリックし、「moduleの編集」を選択する。
アプリケーション・モジュールを作成する場合、ウィザードを使用して次の情報を指定できる。ここでは、ページごとに説明する。
「名前」ページ。アプリケーション・モジュール名(通常、末尾がModuleという文字列)、アプリケーション・モジュールを含めるパッケージ、およびオプションとしてアプリケーション・モジュールが拡張するクラス(このクラスはoracle.jbo.server.ApplicationModuleImplから直接的または間接的に拡張する必要がある)を指定する。
「データ・モデル」ページ。アプリケーション・モジュールに含めるビュー・オブジェクトおよびビュー・リンクを指定する。アプリケーション・モジュール・プロジェクトのビュー・オブジェクトが「使用可能」リストに表示される。マスター・ビューはパッケージのすぐ下に、(ビュー・リンクで関連付けられている)ディテール・ビューはマスター・ビューの下に表示される。マスター・ビューを含めるには、「データ・モデル」リストでアプリケーション・モジュールを選択し、「使用可能」リストから「データ・モデル」リストへビュー・オブジェクトを移動する。ディテール・ビューを含めるには、「データ・モデル」リストでマスターが選択されている状態で、「使用可能」リストからディテール・ビューを移動する。ビュー・オブジェクトがデータ・モデルで複数回使用されている場合は、名前の競合が発生しないよう異なるインスタンス名にする必要がある。
「アプリケーション・モジュール」ページ。アプリケーション・モジュールがネストしている場合、最も外側(最上位レベル)のアプリケーション・モジュールが他のモジュールのトランザクション・コンテキストを提供する。「使用可能」リストには、プロジェクト内のアプリケーション・モジュールがすべて表示される。アプリケーション・モジュールを「選択済」リストに移動すると、ウィザードで定義しているアプリケーション・モジュールにネストされる。オプションとして、アプリケーション・モジュールのインスタンスを識別するためのメンバー名を指定できる。1つのアプリケーション・モジュールが複数回使用されている場合は、メンバー名によりインスタンスを区別できる。アプリケーション・モジュールを別のアプリケーション・モジュールにネストすると、親のアプリケーション・モジュールは子のアプリケーション・モジュールのオブジェクトおよびコードを使用できる。
「Java」ページ。コードを追加してアプリケーション・モジュールの動作をカスタマイズする場合は、ウィザードで、アプリケーション・モジュール・クラスに対するJavaファイルを生成するよう指定できる。
アプリケーション・モジュールを編集する場合、エディタを使用して、これまでのページ(「名前」ページ以外)に加え、次の情報を指定する。
「リモート」ページ。デプロイの準備ができたら、「リモート対応のアプリケーション・モジュール」を選択してプロキシ、スタブおよびスケルトン・クラスを生成する。(各層が別のコンピュータに存在する)物理的に3層のアプリケーションを作成する場合は、必ずこのオプションを選択する。選択する分散オブジェクトのデプロイメント・タイプとして、ファイルを生成するクライアントのプロジェクトを指定できる。対象プラットフォームでは、3つのタイプのファイルが作成される。具体的には、(サーバー・サブパッケージ内の)ビジネス・ロジック層でのみ使用されるファイル、(共通のサブパッケージ内の)ビジネス・ロジック層とクライアント層の両方で使用されるファイル、(クライアント・サブパッケージ内の)クライアント層でのみ使用されるファイルである。
「カスタム・メソッド」ページ。エクスポートするメソッドを選択する。クライアントは、これらのメソッドを層に依存せずに使用できる。アプリケーション・モジュールのクラス・ファイルに記述したメソッドは、「使用可能」リストに表示される。リストには、シリアライズ可能インタフェースを実装するデータ型のもののみが表示される。メソッドをエクスポートするには、「選択済」リストへ移動する。このページを使用する前に、「Java」ページで「Javaファイルの生成」を選択しておく必要がある。「OK」をクリックすると、oracle.jbo.ApplicationModuleを直接または間接的に拡張するエクスポート・インタフェース・ファイルが作成される。クライアントでメソッドを使用する前に、クライアント・コードにインタフェースをインポートする、クライアント・コード内でメソッドをコールするなどの処理が必要である。これについては、Business Components for Javaのオンライン・ヘルプで説明している。
「プロパティ」ページ。プロパティを追加するには、プロパティ名と値を指定し、「追加」をクリックする。また、既存のプロパティ値の追加および編集、プロパティの削除が可能である。
共通の属性に基づいて、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を作成する際にオプションで、生成する表に関係を追加できる。たとえば、(Business Components for Javaを使用しない)他のアプリケーションに対して同じ関係へのアクセス権を付与できる。エンティティ・オブジェクトから表を作成するには、「データベース・オブジェクトの作成」ツールを使用する。
AssociationウィザードでAssociationを作成するには、ビジネス・コンポーネント・プロジェクトが開いている状態で、次のいずれかを行う。
「ファイル」->「新規」を選択し、「Business Tier」->「Business Components(BC4J)」を選択して「Association」をダブルクリック
ナビゲータの「ワークスペース」ノードの下にある、ビジネス・コンポーネント・パッケージを右クリックし、「新規Association」を選択
Associationを編集するには、ナビゲータの「ワークスペース」ノードの下にあるAssociationを右クリックし、「associationの編集」を選択する。
Associationを作成する場合、ウィザードを使用して次の情報を指定できる。ここでは、ページごとに説明する。
「名前」ページ。Association名(識別しやすいように末尾をAssocという文字列などにし、関係を説明するような名前を指定)と、Associationを格納するパッケージ。Associationはその関連先のエンティティ・オブジェクトと同じパッケージに含めることが理想的であるが、必須ではない。
「エンティティ・オブジェクト」ページ。関連付けるエンティティ・オブジェクトを選択する。Associationを定義すると、エンティティ・オブジェクトではそのAssociationを使用し、事前に定義した方法でAssociationのもう一方に透過的にアクセスできる。
「Associationプロパティ」ページ。カーディナリティ、Associationのもう一方の側からデータを返すAssociationアクセッサを公開するかどうか、アクセッサの名前、順方向生成時にキー制約を生成するかどうか、Associationがコンポジットかどうかなど、Associationの動作を指定する。アクセッサは、エンティティ・オブジェクト・クラスにある。
Associationを編集する場合、エディタを使用して、同じ情報(「名前」ページ以外)を指定できる。
エンティティ・オブジェクトを生成した後で、表に対して参照整合性制約を追加するには、単にエンティティ・オブジェクト・エディタにアクセスし、「終了」をクリックして新しいAssociationを作成するだけである。
エンティティ・オブジェクトまたはビュー・オブジェクトの特性で、オブジェクト・クラスのJavaBeansプロパティとして実装される。属性は、データベース列に対応付けることも、データベース列に依存しないことも可能である。属性には、次の5つの種類がある。
属性の種類 |
定義される場所 |
データベース問合せから導出された値か |
データベースに永続的に存在するか |
---|---|---|---|
永続 |
エンティティまたはビュー・オブジェクト・レベル |
はい |
はい(値は、作成したクラスよりも長く存在) |
一時 |
エンティティまたはビュー・オブジェクト・レベル |
いいえ |
いいえ |
エンティティ導出 |
ビュー・オブジェクト・レベル |
いいえ |
いいえ |
SQL導出 |
ビュー・オブジェクト・レベル |
はい |
いいえ |
動的 |
ビュー・オブジェクト・レベル、実行時 |
いいえ |
いいえ |
エンティティ・オブジェクトの属性には、次の種類がある。
永続: データベースに永続的に存在するエンティティ属性(「永続的」属性の設定が選択されている)。
一時: データベースに永続的には存在しないエンティティ属性(「永続的」属性の設定は解除されている)。
逆方向生成を使用して初めてエンティティ・オブジェクトを作成するとき、表の各列に対応する永続エンティティ属性が作成される。その後で表を変更した場合は、属性を手動で変更する必要がある。
ビュー・オブジェクトの属性には、次の種類がある。
永続: 永続エンティティ属性に基づいたビュー属性。データはエンティティ・オブジェクト・レベルでキャッシュされる。
エンティティ導出: 一時エンティティ属性に基づいたビュー属性。データはエンティティ・オブジェクト・レベルでキャッシュされる。
一時: エンティティ属性に基づいていないビュー属性で、SQL式を含まない属性。データはビュー・オブジェクト・レベルでキャッシュされる。
SQL導出: エンティティ属性に基づいていないビュー属性で、SQL式を含む属性。データはビュー・オブジェクト・レベルでキャッシュされる。
動的: addDynamicAttributeメソッドにより作成されるビュー属性。この属性を使用して、実行時に作成された情報を行データとともに格納できる。この属性は、それ自体を作成したビュー・オブジェクトでのみ使用される。動的属性は、設計時の属性と同様に処理される。属性は、任意のシリアライズ可能オブジェクトである。データはビュー・オブジェクト・レベルでキャッシュされる。
SQL導出属性の値は、SQL文の結果である。たとえば、YearsOfService属性は、データベースにおける従業員の入社日と現行の日付との差異である。また、一時属性を作成し、Javaファイルで値を設定するための計算を行うコードも記述できる。通常、SQL導出属性を使用する方が、Javaでデータ集約型計算を行うよりも効率的である。
Business Components for Javaでは、属性という語はXMLの定義ではなく、UMLの定義に基づくものである。UMLでは、属性は、クラスの名前付きプロパティで、そのクラスのインスタンスが保持する値の範囲を記述する。
エンティティ属性エディタでは、エンティティを編集し、属性を表示できる。エディタにアクセスするには、ナビゲータの「ワークスペース」ノードの下にあるエンティティ・オブジェクトまたはビュー・オブジェクトを選択し、構造ペインで属性を右クリックして「attributeの編集」を選択する。エンティティ属性エディタでは、属性レベルのプロパティを指定する。
属性を編集する場合、ウィザードを使用して次の情報を指定できる。ここでは、ページごとに説明する。
「エンティティ属性」ページ。設定では、属性と列の名前、属性と列の型、デフォルト、更新可能かどうか(常に、新規の間、なしのいずれか)、更新または挿入の後にリフレッシュされるかどうか、行が変更されたことを示すために使用されるかどうか、主キーかどうか、必須かどうか、永続かどうか、問合せ可能かどうか、および一意かどうかを指定する。一般に、逆方向生成を実行する場合、表から受け取られた「主キー」、「必須」、「データベース列」の「名前」、「データベース列の型」および「一意」の設定は変更しない。順方向生成の場合、「主キー」、「必須」、「永続的」、「データベース列」の「名前」、「データベース列の型」および「一意」の設定が表の生成に使用される。
「ビュー属性」ページ。設定では、属性名と別名、属性の型、デフォルト、SQL式、更新可能かどうか(常に、新規の間、なしのいずれか)、および問合せ可能かどうかを指定する。(ビュー属性のみ)
「検証」ページ。検証規則を追加、編集または削除する。エンティティ・オブジェクト・レベルまたは属性レベル、あるいはその両方で、新しい規則を適用できる。レベル内で規則の順序を変更できる。これは、1つの属性に複数の検証規則が定義されており、規則の起動順序を制御する場合に便利である。(エンティティ属性のみ)
「プロパティ」ページ。プロパティを追加するには、プロパティ名と値を指定し、「追加」をクリックする。また、既存のプロパティ値の追加および編集、プロパティの削除が可能である。
属性には、次の設定がある。エンティティ・オブジェクトの属性の場合、設定は順方向生成に影響を与える。また、この設定を既存の表から導出する(逆方向生成)こともできる。
属性の設定 |
順方向生成 |
逆方向生成 |
永続属性 |
一時属性 |
永続属性(ビュー・レベル) |
一時属性 |
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 |
ビジネス・コンポーネント・フレームワークから導出されるアプリケーション固有のコンポーネントには、次のものがある。
ビジネス・コンポーネントは、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 {
...
}
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層)でデプロイする際に役立つ。
このウィザードは、プロジェクト・ウィザードでビジネス・コンポーネント・プロジェクトの作成が終わると、自動的に表示される。また、プロジェクトを右クリックして「新規ビジネス・コンポーネント・パッケージ」を選択しても、表示される。ウィザードは、次の項目の指定に役立つ。
開発のためのデータベースへの接続
逆方向生成の場合、デフォルトのエンティティ・オブジェクトの作成に使用する表(およびビュー、シノニムおよびスナップショット)、およびこれらの表内にすでに存在している参照整合性制約に基づくAssociation(オプション)
エンティティ・オブジェクトに基づくデフォルトのビュー・オブジェクト、およびAssociationに基づくビュー・リンク(オプション)
デフォルトのアプリケーション・モジュール(オプション)
エンティティ・オブジェクト、Association、ビュー・オブジェクトおよびビュー・リンクは、エンティティ・オブジェクト・ウィザード、Associationウィザード、ビュー・オブジェクト・ウィザードおよびビュー・リンク・ウィザードを使用して作成および編集することもできる。
既存のビジネス・コンポーネント・プロジェクトを編集するには、ビジネス・コンポーネント・プロジェクトを右クリックし、「projectの編集」を選択してビジネス・コンポーネント・プロジェクト・エディタにアクセスする。このエディタでは、接続の表示と指定、JavaおよびXMLコードを生成するか、XMLコードのみ生成するかの指定、および登録済検証規則の指定を行う。Javaコードを生成すると、オブジェクトを返す汎用的なgetAttributeおよびsetAttributeメソッドを使用するかわりに、強い型指定のアクセッサにアクセスできるようになり、セッター・メソッドにコードを記述できるという利点がある。
ナビゲータでビジネス・コンポーネント・プロジェクトを右クリックし、「新規ビジネス・コンポーネント・パッケージ」を選択した場合に表示されるウィザードは、ビジネス・コンポーネント・パッケージ・ウィザードと呼ばれる。このウィザードの機能は、「接続」ページがないことを除いてビジネス・コンポーネント・プロジェクト・ウィザードと同じである。
ビジネス・ロジックには、検証ロジック、デフォルト値ロジック、削除ロジックおよび計算がある。ビジネス・ロジックは、エンティティ・オブジェクト・レベルで実装する必要がある。ビジネス・ロジックの例として、顧客の返品理由の記録や、最善の取引を行うための仕入先間の入札規則がある。
基本的なビジネス・ロジック層には、それぞれエンティティ・オブジェクトおよびAssociationに依存するビュー・オブジェクトおよびビュー・リンクへのアクセスを可能にする1つ以上のアプリケーション・モジュールが含まれる。ビジネス・ロジック層はBusiness Component Browserでテストできる。
C |
ビジネス・ロジック層では、データベースおよびクライアントから受信したデータを、エンティティ・キャッシュおよびビュー・キャッシュの2つのタイプのキャッシュに格納する。
Associationで関連付けるオブジェクトの最小数と最大数を設定することで、オブジェクト間の関係の定義に役立つ。
0..1: 値を1つ指定できるが、必須ではない。
1: 値を必ず1つ指定する。
*: 値を複数指定できるが、必須ではない。
1..*: 少なくとも値を1つ指定する必要があるが、複数指定することもできる。
この設定は、エンティティ・オブジェクト・ウィザードおよびエンティティ・オブジェクト・エディタの「属性の設定」ページ、およびエンティティ属性エディタに表示される。永続エンティティ・オブジェクト属性の場合は、この設定を選択すると、エンティティ・オブジェクトの永続属性が変更されたかどうかがその属性によって判別される。ユーザーが行の属性値に初めて変更を加える際、ビジネス・ロジック層では、行のロック(即時ロック・モード)またはコミット(コミット時ロック・モード)が試行される。このとき、キャッシュ内のデータ値がデータベースと一致するかどうかがチェックされる。「更新識別子」属性の設定により、ビジネス・ロジック層で単一の属性をチェックするか、複数の属性をチェックするかが決定される(複数の属性をチェックすると、オーバーヘッドが増加する)。したがって、キャッシュ内のエンティティ・オブジェクト・インスタンスにデータが初めて挿入されてから、そのデータが初めて変更されるまでの間に属性値が変更されている場合は、他のユーザーによって行全体が変更されていることを表す。この設定は、エンティティ・オブジェクトの1つの属性にのみ定義できる。通常、属性はタイム・スタンプ列または順序番号である。
ローカルまたはリモート・コンピュータにあるサービス、データまたは別のアプリケーションの処理を要求するソフトウェア・アプリケーション。「Thinクライアント(thin client)」も参照。
親エンティティ・オブジェクトが子エンティティ・オブジェクトを所有するAssociation。親オブジェクトは、1つ以上の子オブジェクトのコンテナとなる。子エンティティ・オブジェクトが変更された場合には、子エンティティ・オブジェクトが検証される。また、この関係は親エンティティ・オブジェクトの検証を起動する。
挿入、更新および削除の場合、子エンティティ・オブジェクトは親エンティティ・オブジェクトの一部とみなされる。有効な子エンティティ・オブジェクトを持つ親エンティティ・オブジェクトは、これに包まれるエンティティ・オブジェクトがすべて削除されるまで、削除できない。子エンティティ・オブジェクトを変更しようとすると、ビジネス・ロジック層は親エンティティ・オブジェクトをロックしようとする。所有側である親エンティティ・オブジェクトが正常にロックされないかぎり、子エンティティ・オブジェクトは変更できない。たとえば航空券を予約する場合、自分の名前ですでに予約があると座席を予約できない。
子エンティティ・オブジェクトは、親がないと作成できない。子エンティティ・オブジェクトを作成すると、外部キーが割り当てられる。親エンティティ・オブジェクトは主キーの値にNULL以外の値を持つ必要がある。実行時に子エンティティ・オブジェクトが変更された場合、その親には検証が必要であるというマークが付けられる。コミットの際に親エンティティ・オブジェクトが検証され、次に子エンティティ・オブジェクトが検証される。
別のデータベースを使用して開発した場合は、デプロイの準備ができた段階でデプロイメント・データベースに切り替えることができる。
Business Components for Javaバージョン3.2から、接続プールがデフォルトの動作になった。以前は各アプリケーション・モジュール・インスタンスに対して1つのJDBC接続を作成し、この接続をインスタンスの切断時に破棄していたが、アプリケーション・モジュールで接続のプールを再利用できるようになった。JDBC接続URLごとに1つの接続プールが用意される。この中には、ユーザー名とパスワードが定義されている。
データベース接続の作成は時間のかかる処理で、データそのものの取得よりも時間がかかる場合がある。接続プールを使用すると、データベース接続を作成する必要がなくなり、クライアントの応答時間が短縮される。クライアントは、接続を作成するかわりに、他のアプリケーション・モジュール・インスタンスで作成された接続を再利用できる。
デフォルトの接続プール機能の他に、次のオプションがある。
プール内の最大接続数を設定できる。
接続プールを無効にできる。
カスタム接続プール・マネージャを作成し、使用できる。
Common Object Request Broker Architecture(CORBA)は、Object Management Group(OMG)の仕様。CORBAは、静的および動的起動インタフェース、インタフェース・リポジトリおよびObject Request Broker(ORB)を含む、分散オブジェクト・コンピューティング・システムの作成に使用されるフレームワークを定義する。
エンティティ・オブジェクトの情報に基づいてデータベース表の作成に使用する。エンティティ制約ウィザードで指定した場合はデータベースの制約も作成できる。これは順方向生成と呼ばれる。このツールにアクセスするには、ナビゲータの「ワークスペース」ノードの下にある、ビジネス・コンポーネント・パッケージを右クリックし、「データベース・オブジェクトの作成」を選択する。
D |
この設定は、エンティティ・オブジェクト・ウィザードおよびエンティティ・オブジェクト・エディタと、ドメイン・ウィザードおよびドメイン・エディタの「属性の設定」ページ、ならびにエンティティ属性エディタに表示される。
エンティティ・オブジェクト属性の場合、この設定はオプションのデフォルト値となる。ビジネス・ロジック層で、属性を含む新しい行が作成された場合は、属性には、デフォルトでこの値が設定される。
ドメインの場合、このデフォルト値はドメイン型のすべての属性に継承され、エンティティ・オブジェクト・ウィザード、エンティティ・オブジェクト・エディタ、またはエンティティ属性エディタでオーバーライドできない。
ドメインは、属性として使用できる値の型を定義する。ドメイン・オブジェクトは開発者が定義するデータ型で、ドメインのコンストラクタに簡易検証が組み込まれた、スカラー値または構造をカプセル化した不変のJavaクラスである。ドメイン型のオブジェクトが作成されると、検証が行われる。ドメインの作成には次の利点がある。
データ作成時に、ドメイン定義に対して簡易検証が1回実行される。これにより、再構成または再検証なしで、異なる層の間でデータ・オブジェクトの受渡しを行うことができる。
設定を定義し、特定のドメインに基づくすべての属性で共有できる。
JDeveloperには、ドメインを定義するためのドメイン・ウィザードおよびドメイン・エディタが用意されている。社会保障番号などの特定の型の値を保持できるように、ビジネス・ロジック層同様Thinクライアントでもドメインのクラスを使用できる。また、(すべてのコンストラクタでコールされる)ドメインの検証メソッドで、入力文字列を初期化または検証するコードを記述できる。ドメイン・クラスは、フォーム内の各フィールドと関連付けできる。フォームでは、フィールドの入力文字列によりドメイン・クラスのインスタンスを直接作成できる。
ドメイン・ウィザードおよびドメイン・エディタでは、設定を指定し、ドメイン型のすべての属性にこの設定を継承させることができる。属性によりドメインの設定がさらに制限されることはあるが、制限が緩和されることはない。たとえば、あるドメイン型に一時属性を含めない場合は、そのドメインを永続的としてマークする。
ドメイン・オブジェクトは、作成後、属性のデータ型として使用できる。たとえば、SSNumberという名前のドメインを作成し、結果のデータ型が9文字の文字列であることを確認する検証コードをこのドメインに記述する。
ドメインは常にシリアライズ可能なJavaオブジェクトである。ビジネス・コンポーネント・フレームワークでは、String、byte[]、IntegerなどのネイティブのJava型を少なくとも1つ受け入れるコンストラクタをドメインに含めることが推奨されている。
ビジネス・コンポーネント・フレームワークでは、事前定義済のドメインもいくつか提供される。
これらのツールは、ドメインの作成および編集に使用する。
ドメイン・ウィザードでドメインを作成するには、ビジネス・コンポーネント・プロジェクトが開いている状態で、次のいずれかを行う。
「ファイル」->「新規」を選択し、「Business Tier」->「Business Components(BC4J)」を選択して、「ドメイン」をダブルクリック
ナビゲータの「ワークスペース」ノードの下にある、ビジネス・コンポーネント・パッケージを右クリックし、「新規ドメイン」を選択
ドメインを編集するには、ナビゲータの「ワークスペース」ノードの下にあるドメインを右クリックし、「domainの編集」を選択する。
ドメインを作成する場合、ウィザードを使用して次の情報を指定できる。ここでは、ページごとに説明する。
「名前」ページ。ドメイン名(関係を説明するような名前にし、多くの場合、ウィザードでデータ型を選択する際にわかりやすいよう、Domainという文字列で終わる名前とする)およびドメインを格納する場所であるパッケージ。
「設定」ページ。属性の設定を指定する。具体的には属性および列の型、デフォルト、更新可能かどうか(常に、新規の間、なしのいずれか)、リフレッシュするタイミング(更新後または挿入後)、およびこの属性が主キー、必須、永続、問合せ可能および一意であるかどうかを指定する。
ドメインを編集する場合は、エディタを使用して「設定」ページの情報を指定できる。また、エディタには次のページもある。
「プロパティ」ページ。プロパティを追加するには、プロパティ名と値を指定し、「追加」をクリックする。また、既存のプロパティ値の追加および編集、プロパティの削除が可能である。
ドメインのJavaファイル(ウィザードで作成されたもの)に検証コードを記述できる。たとえば、データ型が9文字の文字列であることを確認できる。
E |
Enterprise JavaBeans標準は、複数層、分散、スケーラブル、オブジェクト指向のJavaアプリケーションの開発およびデプロイメントのためのクロス・プラットフォーム・コンポーネント・アーキテクチャを規定する。サーバーBeanとも呼ばれる。
UML用語では、顧客、注文、品目などのドメイン固有の名詞。
「データベース・オブジェクトの作成」ツールで表を生成(順方向生成)する際に使用される制約を追加できる。ウィザードにアクセスするには、ナビゲータの「ワークスペース」ノードの下にあるエンティティ・オブジェクトを右クリックし、「新規エンティティ制約」を選択する。
また、Associationの定義時に制約を作成することもできる。Associationに基づいて自動的に制約を作成する場合は、AssociationウィザードおよびAssociationエディタの「Associationプロパティ」ページで、「データベース・キー制約の使用」を選択する。
エンティティ制約とは、データベース内のキー制約を表すビジネス・ロジック層オブジェクトである。エンティティ制約は、エンティティ・オブジェクトおよび属性に関して、表と列の間のデータベース・レベルの関係を表す。エンティティ・オブジェクトの属性を選択し、主キー、外部キー、チェックまたは一意などのデータベース整合性制約に対応する制約を定義する。エンティティ・オブジェクトに基づいてデータベース・オブジェクトを作成した場合、表間のAssociationの検出、指定されたキー制約のデータベースでの作成、およびデータベース内のデータが有効でキー制約に合致しているかの確認に、エンティティ制約の定義が使用される。
これは、oracle.jbo.server.EntityDefImplから直接的または間接的に拡張したクラスである。このクラスには、属性、イベント、Validator、Association、プロパティを含むエンティティ・オブジェクトに関する実行時のメタデータが格納される。このクラスをインスタンス化すると、エンティティ・オブジェクト・クラスのすべてのインスタンスが表される。クライアントはメソッドをコールして、エンティティ・オブジェクトに関する情報(属性名、型、データベース・ソースなど)を検索できる。エンティティのXMLファイルごとに1つのエンティティ定義クラス・インスタンスがある。
独自のcreateメソッドおよびfindメソッドが必要な場合、エンティティ・オブジェクト・ウィザードおよびエンティティ・オブジェクト・エディタを使用して、エンティティ・オブジェクトに対してこのJavaクラスを生成できる。このクラスは、すべてのエンティティ・オブジェクト・インスタンスで使用されるメソッドをグループ化する場合に適している。たとえば、エンティティ定義をインスタンス化する場合に、オプションでcreateDefメソッドを変更し、他のソース(XML以外に別のソース、またはXMLのかわりのソース)のプロパティを使用できる。
エンティティ・オブジェクトが(エンティティ・オブジェクト・ウィザードおよびエンティティ・オブジェクト・エディタの「イベント発行」ページおよび「イベント受信」ページに指定されているように)イベントを発行または受信する場合、発行および受信するエンティティ・オブジェクトの定義ファイルの中にほとんどのイベント・コードが生成される。
このクラスは、カスタム・クラスから拡張するよう指定できる(カスタム・クラスは、EntityDefImplクラスを直接的または間接的に拡張し、プロジェクト・クラスパス内にあることが必要)。たとえば、すでに記述されているコードを再利用する場合、または特別なニーズに合せてビジネス・コンポーネントのフレームワークをカスタマイズするように組織で決定した場合には、このように指定できる。
一般に、エンティティ・オブジェクトは、次のようなビジネス・ポリシーとデータをカプセル化する。
ビジネスの論理構造(製品ライン、部門、売上、地域など)
ビジネス文書(請求書、注文変更書、サービス要求など)
物理的な項目(倉庫、従業員、設備など)
具体的には、エンティティ・オブジェクトにはビジネス・ロジックおよびデータベース表(またはビュー、シノニムあるいはスナップショット)の列情報を格納する。エンティティ・オブジェクトを既存のデータベース表から作成する(逆方向生成)ことも、エンティティ・オブジェクトを定義し、それを使用してデータベース表を作成する(順方向生成)こともできる。
Business Components for Javaのウィザードを使用して既存の表からエンティティ・オブジェクトを作成する場合、データベース表の各列がエンティティ属性になる。この属性は、列と同じ名前にすることも、ビジネス・アプリケーションの意味を表すような別の名前にすることもできる。エンティティ・オブジェクトには各列の属性を定義できる。また、1つの表に複数のエンティティの情報が含まれている場合は、サブセットを使用することもできる。エンティティ・オブジェクトの属性には、主キーおよび外部キー関係、最大文字数、精度、スケールの仕様、オブジェクトREFの情報などの、導出元のデータベース表で指定されているデータ型情報が格納される。
エンティティ・オブジェクト・ウィザードおよびエンティティ・オブジェクト・エディタを使用して、エンティティ・オブジェクトを作成および編集できる。通常は、表ごとに1つのエンティティ・オブジェクトがある。1つの表に複数のエンティティ・オブジェクトがある場合は、更新可能な属性はそれぞれ1つのエンティティ・オブジェクトにのみ示されるようにする。このようにしない場合は、行を変更しても、その変更は他のエンティティ・オブジェクトに反映されない。
実行時、各エンティティ・オブジェクト・インスタンスは、データベース表の1行を表し、そのデータを格納する。行ごとに1つのインスタンスのみが定義され、同じエンティティ・クラスのすべてのインスタンスは、まとめてキャッシュされる。同じ行を返す複数のビュー・オブジェクトの問合せでは、同じエンティティ・オブジェクト・インスタンスが参照される。このため、更新はすべてのビュー・オブジェクトで参照できるようになり、1つのエンティティ・オブジェクトを複数のビュー・オブジェクトで使用できる。
エンティティ・オブジェクトは、クライアントには公開されていない。かわりに、クライアントは1つ以上のビュー・オブジェクトを介してエンティティ・オブジェクトのデータにアクセスする。ビュー行クラスでは、公開するメソッドをコールするビュー・オブジェクト・メソッドを記述することにより、エンティティ・オブジェクト・メソッドをクライアントに公開できる。
エンティティ・オブジェクト間の関係は、Associationにより表現される。関連元および関連先のエンティティ・オブジェクトの属性(通常はキー・フィールド)は一致している必要がある。Associationを介して行および行セットを返すメソッドは、エンティティ・オブジェクト・クラスで使用できる。
ビジネス・ロジックの大部分は、エンティティ・オブジェクトで実装される。たとえば検証規則(sal > 700など)を使用すると、問合せで無効な値が返されることや、ユーザーが無効な値を表に入力することを回避できる。ビジネス・ロジックは1箇所で定義され更新される。これには、複数のクライアントでビジネス・ロジックを使用し、変更が必要な場合に簡単に更新できるという利点がある。
アプリケーションで必要なエンティティ・オブジェクトを決定するには、通常、UMLオブジェクト指向モデリングの技法を使用する。
これは、oracle.jbo.server.EntityImplから直接または間接的に拡張したクラスである。このクラスをインスタンス化すると、1つの行になる。validateEntityメソッドや属性のセッター・メソッドにカスタム検証ロジック・コードを追加したり、ゲッター・メソッドで属性値を計算するなど、メソッドをカスタマイズする場合がある。このような場合、ビジネス・コンポーネント・プロジェクト・ウィザード、ビジネス・コンポーネント・パッケージ・ウィザードまたはパッケージ・エディタ、あるいはエンティティ・オブジェクト・ウィザードまたはエンティティ・オブジェクト・エディタを使用して、エンティティ・オブジェクトに対してこのJavaクラスを生成できる。このクラスは、カスタム・クラスから拡張するよう指定できる(カスタム・クラスは、EntityImplクラスを直接的または間接的に拡張したもので、プロジェクト・クラスパス内にあることが必要)。たとえば、すでに記述されているコードを再利用する場合、または特別なニーズに合せてビジネス・コンポーネントのフレームワークをカスタマイズするように組織で決定した場合には、このように指定できる。ウィザードでは、オプションで次のものを生成できる。
アクセッサ・メソッド。たとえばgetJobやsetJobなどで、対応する属性フィールドに対してタイプ・セーフなアクセスを提供し、検証のための独自のカスタム・コードを追加する場所を提供する。
データ操作メソッド。たとえばlockメソッドやdoDMLメソッドで、lockメソッドは、変更して、エンティティ・オブジェクトのロック動作をカスタマイズできる。doDMLメソッドは、変更して、更新、挿入および削除ロジックをカスタマイズできる。lockメソッドは、データベース内のエンティティの行が変更のためにロックされるたびに、フレームワークによってコールされる。doDMLメソッドは、トランザクション・コミット・サイクル中にエンティティ・インスタンスに対応する行の挿入、更新または削除を行うために、フレームワークにより適切なDMLコマンドとともにコールされる。このメソッドをオーバーライドして、更新動作を変更できる。たとえば、フレームワークのようにSQL文を介して直接更新するかわりに、データベースへのプロシージャ・コールを介して更新できる。
createメソッド。このメソッドを変更することにより、エンティティ・オブジェクトの作成ロジックに対する初期化機能をカスタマイズまたは追加できる。属性にデフォルト値を設定する場合などに使用する。
removeメソッド。このメソッドを変更することにより、エンティティ・オブジェクトの削除ロジックに対するクリーンアップ・コードをカスタマイズまたは追加できる。コンポジット内の子オブジェクトを削除する必要がある場合などに使用する。
これらのツールは、エンティティ・オブジェクトの作成および編集に使用する。また、ビジネス・コンポーネント・プロジェクト・ウィザードおよびビジネス・コンポーネント・パッケージ・ウィザードまたはパッケージ・エディタでデフォルトのエンティティ・オブジェクトも作成できる。エンティティ・オブジェクトは、既存の表に基づいて作成(逆方向生成)することも、データベース表の作成に使用(順方向生成)することもできる。
エンティティ・オブジェクト・ウィザードでエンティティ・オブジェクトを作成するには、ビジネス・コンポーネント・プロジェクトが開いている状態で、次のいずれかを行う。
「ファイル」->「新規」を選択し、「Business Tier」->「Business Components(BC4J)」を選択して「エンティティ・オブジェクト」をダブルクリック
ナビゲータの「ワークスペース」ノードの下にある、ビジネス・コンポーネント・パッケージを右クリックし、「新規エンティティ・オブジェクト」を選択
エンティティ・オブジェクトを編集するには、ナビゲータの「ワークスペース」ノードの下にあるエンティティ・オブジェクトを右クリックし、「objectの編集」を選択する。
エンティティ・オブジェクトを作成する場合、ウィザードを使用して次の情報を指定できる。ここでは、ページごとに説明する。
「名前」ページ。エンティティ・オブジェクトの名前(この名前は、表名と同じ名前にするか、表名がエンティティ・オブジェクトの用途に合わない場合や、別の言語を使用する場合などは、別の名前を使用できる)、エンティティ・オブジェクトを含めるパッケージ、およびエンティティ・オブジェクトが拡張するクラス(このクラスはoracle.jbo.server.EntityImplから直接または間接的に拡張する必要がある)。オプションとして、エンティティ・オブジェクトの作成に使用するデータベース表(あるいは、ビュー、シノニムまたはスナップショット)、およびこれらの表内にすでに存在している結合に基づくAssociationを指定する。
「属性」ページおよび「属性の設定」ページ。エンティティ・オブジェクトから除外する属性(たとえば、データベース表にあってもエンティティ・オブジェクトに含めない場合)の削除、属性順序の変更(順方向生成に役立つ。属性の順序は表内の列の順序となる)、および新規属性の定義(たとえば、Javaファイルで計算した値を入れる一時属性、または順方向生成の列を定義する場合)を行う。通常は1つの表に対し、1つのエンティティ・オブジェクトを作成する。複数のエンティティ・オブジェクトがある場合は、更新可能な各属性は1つのエンティティ・オブジェクトにのみ含まれるようにする。設定では、属性と列の名前、属性と列の型、デフォルト、更新可能かどうか(常に、新規の間、なしのいずれか)、更新または挿入の後にリフレッシュされるかどうか、行が変更されたことを示すために使用されるかどうか、主キーかどうか、必須かどうか、永続かどうか、問合せ可能かどうか、および一意かどうかを指定する。一般に、逆方向生成を実行する場合、表から受け取られた「主キー」、「必須」、「データベース列」の「名前」、「データベース列の型」および「一意」の設定は変更しない。順方向生成の場合、「主キー」、「必須」、「永続的」、「データベース列」の「名前」、「データベース列の型」および「一意」の設定が表の生成に使用される。
「Java」ページ。エンティティ・オブジェクトをカスタマイズする場合は、ウィザードでエンティティ定義クラス、エンティティ・オブジェクト・クラス(あるいはその両方)に対してJavaファイルを生成するよう指定できる。デフォルトではエンティティ・オブジェクト・クラスは生成されるが、エンティティ定義クラスは生成されない。
「終了」ページ。オプションで、エンティティ・オブジェクトに指定した属性を含むデフォルト・ビュー・オブジェクトを作成する。ビュー・オブジェクト・エディタでビュー・オブジェクトを編集できる。
エンティティ・オブジェクトを編集する場合、エディタを使用して次の情報を指定する。
「属性」ページ、「属性の設定」ページおよび「Java」ページ。エンティティ・オブジェクトを作成する場合と同じように指定する。
「検証」ページ。検証規則を追加、編集または削除する。エンティティ・オブジェクト・レベルまたは属性レベル、あるいはその両方で、新しい規則を適用できる。レベル内で規則の順序を変更できる。これは、1つの属性に複数の検証規則が定義されており、規則の起動順序を制御する場合に便利である。
「イベント発行」および「イベント受信」ページ。「イベント発行」ページは、エンティティ・オブジェクトにより発行されるイベントを定義、編集または削除する場合に使用する。ウィザードでは、エンティティ・オブジェクト・クラスおよびエンティティ定義クラスのイベント・コードがJavaファイルに生成される。イベントとともに配信する属性を指定できる。イベントを送信するには、同じ名前のメソッドをコールする。「イベント受信」ページは、エンティティ・オブジェクトがリスニングするイベント(プロジェクトで定義されたもの)を選択する場合に使用する。イベントが起動されると、エンティティ・オブジェクトが、指定されたメソッドをコールすることにより応答する。イベントの配信方法を指定できる。イベントは、プログラム・ロジック(addListener)で受信されているエンティティ・オブジェクトのインスタンスに配信するか、選択されたAssociationを使用することにより、発行側に関連付けられているエンティティ・オブジェクトに配信できる。
「プロパティ」ページ。プロパティを追加するには、プロパティ名と値を指定し、「追加」をクリックする。また、既存のプロパティ値の追加および編集、プロパティの削除が可能である。
エンティティ・オブジェクトを生成した後で、表に対して参照整合性制約を追加するには、単にエンティティ・オブジェクト・エディタにアクセスし、「終了」をクリックして新しいAssociationを作成するだけである。データベース表のその他の変更は、エンティティ・オブジェクト・エディタで手動で行うことができる。たとえば、新しい列に対応する属性を追加できる。
この設定は、ビュー・オブジェクト・ウィザードおよびビュー・オブジェクト・エディタの「属性の設定」ページ、ならびにエンティティ属性エディタに表示される。SQL導出ビュー属性では、有効なSQL式を使用して属性の値を定義する。
F |
クライアント上のユーザーが指定した値によって、ビュー・オブジェクトから除外されている属性の値がビジネス・ロジックにより要求されると、ビジネス・ロジック層では、データベースに移動し、主キー値を使用して行のすべての属性(除外されている属性を含む)を取得する。これはフォルトインと呼ばれる。クライアントがビューに含まれていないエンティティ・オブジェクト属性へのアクセスを試行すると、エンティティ・オブジェクトは残りの属性をすべて取得する。フォルトインは、エンティティ・オブジェクト・インスタンス・レベルで行われる。影響を受けた行のみがフォルトインされる。フォルトイン後キャッシュには、フォルトインの結果である完全に移入された1行が含まれる。このオンデマンド・フォルトインにより、要求の失敗が回避される。
たとえば、従業員のレベルおよび名前を含むビュー・オブジェクトがあるとする。エンティティ・オブジェクトによる給与のチェックのレベルを4から3に変更すると、ビューに含まれていない属性の読込みを試行していることになる。フォルトインおよびデータベースへの2回のアクセスを回避するには、給与をビューに含める。
ビュー・オブジェクトを設計する際は、次のことを考慮する必要がある。
フォルトインは、エンティティ・ビジネス・ロジックにより参照される属性がビュー・オブジェクトに必ず含まれているようにすることで回避できる。このことは、大量の行を問合せおよび変更する場合に特に重要である。
パフォーマンスを最適化する際には、フォルトインによるメモリーとパフォーマンスへの影響に注意する。フォルトインが何度も発生すると、パフォーマンスが著しく低下する。多数の属性を含むエンティティ・オブジェクトについては特に、ビュー属性リストの調整が重要である。
まずエンティティ・オブジェクト・ウィザードおよびエンティティ・オブジェクト・エディタでエンティティ・オブジェクトを定義し、次にこれらのエンティティ・オブジェクトを使用してデータベース表を作成し、オプションで「データベース・オブジェクトの作成」ツールを使用して制約を定義する。「逆方向生成(reverse generation)」も参照。
ビュー・オブジェクトでsetForwardOnlyメソッドを使用して、データをエンティティ・キャッシュに挿入しないようにできる。この方法では、同時に1行しか処理できず、データは変更できない。データを変更する必要がなく、繰り返しデータが少ない場合には、順方向のみのモードを使用すると、オブジェクトがほとんど生成されないため、メモリー・リソースおよび時間が節約される。順方向のみのモードは、データをフェッチしていったん読み込む場合(Webページ用のデータの書式設定、または線形的に処理を行うバッチ処理などの場合)に使用すると便利である。
ビルトイン・アプリケーション機能を持つクラス・ライブラリ。フレームワークを使用すると、アプリケーション固有の動作が組み込まれるようベース・クラスが特化され、フレームワークで、オブジェクト間の基本的な対話を調整できる。
ビジネス・コンポーネント・フレームワークの場合、クラスはoracle. jbo.*内にある。
H |
Hypertext Markup Languageは、WWW上でハイパー・テキストを公開するための非プロプライエタリな言語。これはSGMLに基づいている。HTMLは、タグを使用してテキストをヘッダー、段落、リスト、ハイパー・テキスト・リンクなどに構造化する。これらはWebブラウザに表示できる。
I |
Internet Inter-ORB Protocol(IIOP)は、Object Request Broker(ORB)クライアントとサーバーの間の通信に使用されるプロトコル。CORBAで使用される。
各ビュー・オブジェクトは、クライアントが結果セット内の移動に使用できるデフォルトのイテレータ(oracle.jbo.RowIteratorインタフェースを介して)を提供する。ビュー・オブジェクトは、イテレータによりデータが要求されるまで、問合せを実行しない。イテレータを使用して、前方および後方への移動、次および前への移動なども含め、行セットの内容を順に取り出すことができる。行イテレータをRangeとともに使用し、Range内での相対移動など、UIの行のRangeの反復をより簡単にすることができる。Rangeに対応する行イテレータは、グリッド・コントロールに役立つ。
J |
JavaServer Pagesテクノロジは、XMLに似たタグおよびJavaで記述されたスクリプトレットを使用することにより、動的Webページを高速に作成する方法を提供する。サーバーまたはプラットフォームに依存しないWebベース・アプリケーションを容易に開発できる。JavaServer Pagesは、JavaサーブレットAPIの拡張である。
Java Database Connectivityは、Javaコードからのデータベース内のデータの取得および操作に関するAPI仕様。要求はSQLで行われる。JDBC-ODBCブリッジでは、ODBCを介してデータベースにアクセスする。
M |
この設定は、エンティティ・オブジェクト・ウィザードおよびエンティティ・オブジェクト・エディタと、ドメイン・ウィザードおよびドメイン・エディタの「属性の設定」ページ、ならびにエンティティ属性エディタに表示される。
この設定を選択すると、各エンティティ・オブジェクトの行に、この属性に対して必ずNULL以外の値が設定される。NULL値が設定されている場合は、その行の処理が終了する際またはコミットする際に無効であるとみなされる。
エンティティ属性がドメイン型で、「必須」属性の設定がドメインで設定されている場合は、エンティティ・オブジェクト・ウィザード、エンティティ・オブジェクト・エディタ、またはエンティティ属性エディタで設定をオーバーライドすることはできない。
書式設定の方法など、別のデータ・セット(アプリケーション・データ)に関するデータ。Business Components for Javaは、メタデータを、ビジネス・コンポーネントの構造および動作に関する情報を含むXML定義ファイルとして表す。XML定義ファイルには、設計時にBusiness Components for Javaのウィザードを使用して宣言できるアプリケーションの機能および設定に関する説明的な情報が格納される。メタデータの例として、属性の名前と型、SQL問合せおよび検証規則がある。説明的な情報はXMLとして格納されるのに対し、プログラム情報はJavaで格納される。
N |
この設定は、ビュー・オブジェクト・ウィザードおよびビュー・オブジェクト・エディタと、エンティティ・オブジェクト・ウィザードおよびエンティティ・オブジェクト・エディタの「属性の設定」ページ、ならびにエンティティ属性エディタに表示される。
必須の属性名の設定では、Business Components for Javaのウィザード、Javaソース・コードおよびXMLファイルでの属性の参照に使用される名前を指定する。
O |
Open Database Connectivityは、データベースにアクセスするための標準API。アプリケーションはSQLリクエストを使用してデータベースにアクセスし、ODBCがそのリクエストをこのデータベースが理解できるリクエストに変換する。ODBCは、SQL Access Groupにより作成された。JDBC-ODBCブリッジでは、JDBCを使用しているアプリケーションが、ODBCからアクセス可能なデータベースにアクセスできる。
エンティティ・オブジェクトがコミット時ロックを使用する場合、コミット時に、エンティティ・オブジェクトはデータベース内の対応する行のロックを試行する。エンティティ・オブジェクトがコンポジットの一部である場合、フレームワークは、親エンティティ・オブジェクトを最初にロックしようとする。このロックの試行に失敗した場合は、例外がスローされる。「即時ロック(pessimistic locking)」も参照。ロックは、oracle.jbo.TransactionインタフェースのsetLockingModeメソッドにより定義される。
P |
ビジネス・コンポーネント・プロジェクトでは、パッケージのprivateメソッドおよび変数にアクセスできるように、同じパッケージにグループ化するビジネス・コンポーネント、および異なるパッケージにグループ化するビジネス・コンポーネントを決定する必要がある。別のパッケージのビジネス・コンポーネント間は、publicメソッドおよび変数を介して対話を行う。必要に応じて、他のプロジェクト内でパッケージを再利用することもできる。一般的なガイドラインとして、各アプリケーションに対して、ビジネス・コンポーネント・プロジェクト内に次のパッケージを作成できる。
ビジネス・ロジック・パッケージ(エンティティ・オブジェクト、Association、およびフィルタリングと検証で使用するビュー・オブジェクト)
プレゼンテーション・パッケージ(アプリケーション・モジュール、UIのデータを表示およびフィルタリングするビュー・オブジェクトおよびビュー・リンク)
クライアント・パッケージ
インタフェースおよびドメイン・パッケージ(2つの層に共通のもので、個別にアップグレード可能)
どのメソッドを内部のチーム・メンバーで使用し、どのメソッドを外部のチームで使用するかに応じて、パッケージ内でグループ化するオブジェクトを機能面から決定する必要がある。1つのコンポーネントとして一緒に配布されるものは、1つのパッケージに入れる。異なるアプリケーション機能を開発しているチームは、それぞれに独立して作業する必要がある。
これらのツールは、パッケージの作成および編集に使用する。このウィザードおよびエディタには、ビジネス・コンポーネント・プロジェクト・ウィザードと同じ機能の一部が備わっている。
ビジネス・コンポーネント・パッケージ・ウィザードでパッケージを作成するには、ビジネス・コンポーネント・プロジェクトが開いている状態で、次のいずれかを行う。
「ファイル」->「新規」を選択し、「Business Tier」->「Business Components(BC4J)」を選択して「ビジネス・コンポーネント・パッケージ」をダブルクリック
ナビゲータの「ワークスペース」ノードの下にある、ビジネス・コンポーネント・プロジェクトを右クリックし、「新規ビジネス・コンポーネント・パッケージ」を選択
パッケージを編集するには、ナビゲータの「ワークスペース」ノードの下にあるパッケージを右クリックし、「packageの編集」を選択する。
ウィザードおよびエディタでは、次の項目を指定できる。
デフォルトのエンティティ・オブジェクトの作成に使用する表(またビュー、シノニムおよびスナップショット)、およびこれらの表内にすでに存在している参照整合性制約に基づくAssociation(オプション)
エンティティ・オブジェクトに基づくデフォルトのビュー・オブジェクト、およびAssociationに基づくビュー・リンク(オプション)
デフォルトのアプリケーション・モジュール(オプション)
エンティティ・オブジェクト、Association、ビュー・オブジェクトおよびビュー・リンクは、エンティティ・オブジェクト・ウィザードとエンティティ・オブジェクト・エディタ、ビュー・オブジェクト・ウィザードとビュー・オブジェクト・エディタ、AssociationウィザードとAssociationエディタおよびビュー・リンク・ウィザードとビュー・リンク・エディタを使用して作成および編集できる。
この設定は、エンティティ・オブジェクト・ウィザードおよびエンティティ・オブジェクト・エディタと、ドメイン・ウィザードおよびドメイン・エディタの「属性の設定」ページ、ならびにエンティティ属性エディタに表示される。
エンティティ属性の場合、属性を永続属性とするにはこの設定を選択する(エンティティにより属性が永続的な記憶域(データベース)に保存される)。一時属性には選択しない。
属性がドメイン型で、「永続的」属性の設定がドメインで設定されている場合は、エンティティ・オブジェクト・ウィザード、エンティティ・オブジェクト・エディタ、またはエンティティ属性エディタで設定をオーバーライドすることはできない。したがって、一時属性に対しては、ドメインで「永続的」を選択しない。
エンティティ・オブジェクトが即時ロックを使用する場合、その属性の1つが最初に正常に変更された際に(検証の正常終了を含む)、エンティティ・オブジェクトはデータベース内の対応する行のロックを試行する。エンティティ・オブジェクトがコンポジットの一部である場合、フレームワークは、親エンティティ・オブジェクトの行を最初にロックしようとする。このロックの試行に失敗した場合は、例外がスローされる。「コミット時ロック(optimistic locking)」も参照。ロックは、oracle.jbo.TransactionインタフェースのsetLockingModeメソッドにより定義される。
この設定は、エンティティ・オブジェクト・ウィザードおよびエンティティ・オブジェクト・エディタと、ドメイン・ウィザードおよびドメイン・エディタの「属性の設定」ページ、ならびにエンティティ属性エディタに表示される。エンティティ・オブジェクト属性の場合は、この設定を選択すると、属性がエンティティ・オブジェクトの主キー(またはその一部)になる。(主キーは複数の属性で構成される場合がある。)
属性がドメイン型で、「主キー」属性の設定がドメインで設定されている場合は、エンティティ・オブジェクト・エディタで設定をオーバーライドすることはできない。
「ファイル」->「新規プロジェクト」を選択した後で、プロジェクト・ウィザードが表示され、新規プロジェクトを作成できる。次のことを指定する。
プロジェクト・ファイル(JPR)の名前
プロジェクトのタイプ(ビジネス・コンポーネントを含むプロジェクトなど)
プロジェクトのデフォルト・パッケージ
すべてのソース・ファイルを置く必要のあるソースパス
JDeveloperがコンパイル済ファイルを出力するディレクトリ
ビジネス・コンポーネント・プロジェクトを作成する場合は、「終了」をクリックした後でビジネス・コンポーネント・プロジェクト・ウィザードが表示される。
ビジネス・コンポーネント・プロジェクトでは、プロパティはString型の名前と値のペア。メタデータとして実行時の動作の決定に使用できる。(JavaBeansプロパティと混同しないように。まったく別のものである。)プロパティを持つことができるのは、ドメイン、エンティティ・オブジェクト、ビュー・オブジェクト、アプリケーション・モジュールおよびエンティティとビューの属性である。プロパティはコンポーネントのXMLファイルに保存される。
エンティティ・オブジェクト・ウィザードやエンティティ属性エディタなどのウィザードまたはエディタの適切な「プロパティ」ページで、必要なプロパティを定義できる。プロパティには次のような使用方法がある。
アプリケーション・モジュールで、使用する汎用ユーザー・インタフェース・テンプレートのスタイルを指定する。実行時のヒント情報を提供し、アプリケーション・モジュールの情報の表示スタイルを制御する。
ドメインで、特定の属性の型に、デフォルトの表示スタイル・ヒントおよび書式マスクをグローバルに設定する。
エンティティ・オブジェクトとビュー・オブジェクトで、必要に応じて、ドメインにより提供されたデフォルトのヒントをオーバーライドするため。
たとえば、属性はLabelプロパティを持つことができる。このプロパティは、属性がUIに表示される場合のラベルを指定する。その他の例としては、表示領域をレイアウトする際マスク(またはピクチャ文字列)を使用する場合がある。社会保障番号を表す文字列のプロパティを定義するには、値000-00-0000のSSN-MASKプロパティを作成する。実行時に、プロパティ名が評価され、適切な形式が必要に応じて適用される。
属性プロパティおよびドメイン・プロパティは、より制限の厳しいプロパティでオーバーライドできる。次に、階層を制限の緩いものから順に示す。
ドメイン・プロパティ
エンティティ属性プロパティ
ビュー属性プロパティ
次に例を示す。
nameLengthドメイン |
Deptエンティティ・オブジェクト |
DeptViewビュー・オブジェクト |
---|---|---|
文字列型 長さのプロパティの値が20 部門名の長さを20文字の文字列に制限するよう設計 |
nameLength型のDname属性 属性の長さのプロパティの値が15 |
nameLength型のDname属性 属性の長さのプロパティの値が10 |
エンティティ・オブジェクトのDname属性の長さのプロパティは、20文字のドメインの文字制限をオーバーライドする。したがって、部門名は15文字にすることができる。ビュー・オブジェクトのDname属性の長さのプロパティは、部門名の制限をオーバーライドする。したがって、部門名は10文字にすることができる。
NamedObjectImplクラスで定義されたgetProperty、setProperty、getProperties、getPropertiesAsStringsなどのメソッドを使用し、実行時にプロパティを取得および設定できる。EntityDefImpl、ViewObjectImpl、ApplicationModuleDefImpl、AttributeDefImplなどのその他のクラスは、このクラスを拡張する。クライアントはプロパティの問合せやプロパティ値に基づく決定はできるが、プロパティの設定はできない。
Q |
この設定は、ビュー・オブジェクト・ウィザードおよびビュー・オブジェクト・エディタ、エンティティ・オブジェクト・ウィザードおよびエンティティ・オブジェクト・エディタと、ドメイン・ウィザードおよびドメイン・エディタの「属性の設定」ページ、ならびにエンティティ属性エディタに表示される。
エンティティ・オブジェクト属性の場合、この設定を選択すると、属性をビュー・オブジェクトの問合せ条件に指定できる。設定を選択しない場合は、情報の問合せはできない(BLOB型など)。
ビュー属性の場合、この設定を選択すると、属性を問合せ条件に使用できる。永続属性では、列(この型の属性のマップ先)が問合せフィルタ(WHERE句)の一部として使用できる場合は、この設定を選択する。たとえば、列の型がNUMBERの場合はこのプロパティを選択するが、BLOB型の場合は選択しない。この属性は、BC4J JSPなどで生成された問合せフォームで使用される。
属性がドメイン型で、「問合せ可能」属性の設定がドメインで設定されている場合は、設定はビュー・オブジェクト・ウィザードまたはビュー・オブジェクト・エディタでオーバーライドできるが、エンティティ・オブジェクト・ウィザードまたはエンティティ・オブジェクト・エディタではオーバーライドできない。
R |
この設定は、エンティティ・オブジェクト・ウィザードおよびエンティティ・オブジェクト・エディタと、ドメイン・ウィザードおよびドメイン・エディタの「属性の設定」ページ、ならびにエンティティ属性エディタに表示される。
永続エンティティ・オブジェクト属性には、任意で次の設定のいずれか(または両方)を設定できる。
「リフレッシュ」の「更新後」: エンティティ・オブジェクトは、更新を実行した後で、対応するデータベース・フィールドの属性値を取得する(エンティティ・オブジェクト・インスタンスのデータは、データベースの現在の行に格納されている)。つまり、データベースのトリガーの影響が、エンティティ・キャッシュに反映される。たとえば、「Date Updated」フィールドでは、行の更新後にデータベースよりそのフィールドに対して新しい更新日付が追加されるため、エンティティ・オブジェクト・インスタンスに新しい値が必要になる。
「リフレッシュ」の「挿入後」: エンティティ・オブジェクトは、データベースに新しい行を挿入した後で、対応するデータベース・フィールドから属性値を取得する。たとえば、この機能を使用して主キーの値にデータベース・トリガーの順序を割り当てることができる(挿入後、データベースでは順序番号が生成され、エンティティ・オブジェクトで新しい属性値が取得される)。
属性がドメイン型で、「リフレッシュ」属性の設定がドメインで設定されている場合は、エンティティ・オブジェクト・ウィザードまたはエンティティ・オブジェクト・エディタで設定をオーバーライドすることはできない。
最初に、データベース表(また、ビュー、シノニムおよびスナップショット)を定義し、次にそのデータベース表を使用してエンティティ・オブジェクト・ウィザードまたはエンティティ・オブジェクト・エディタ、ビジネス・コンポーネント・プロジェクト・ウィザードおよびビジネス・コンポーネント・パッケージ・ウィザードまたはパッケージ・エディタでエンティティ・オブジェクトを作成する。「順方向生成(forward generation)」も参照。
現在のトランザクションに対して行われた変更を取り消す。リカバリ処理の後半部分。ロールフォワードの後、コミットされていない変更を元に戻す必要がある。REDOログ・ファイルが適用された後、ロールバック・セグメントを使用し、コミットされていないがREDOログに記録されたトランザクションを特定して取り消す。Oracleでは、この手順を自動的に完了する。
oracle.jbo.Rowインタフェースを実装するオブジェクト。ビュー・オブジェクト問合せで1行以上の結果の行がフェッチされると、各行がRowオブジェクトで表される。結果の行の各列値には、行インタフェースの属性を使用してアクセスする。行インタフェースには、getAttributeやsetAttributeなどのメソッドがある。
S |
この設定は、ビュー・オブジェクト・ウィザードおよびビュー・オブジェクト・エディタの「属性の設定」ページに表示される。選択されている場合、この属性はビュー・オブジェクトのSQL SELECT文に表示される。選択されていない場合は表示されない。
クライアントにより要求されたサービスを提供する。ソフトウェア構成によっては、1台のマシンをクライアントとサーバーの両方として設定できる。
Oracleデータベース・インスタンスの一意の名前。データベースへの接続を指定するには、ユーザーがSIDを指定する必要がある。
リモート・ノードにあるマスター表の読取り専用コピー。スナップショットには問合せはできるが、更新はできない。マスター表のみを更新する必要がある。スナップショットは、マスター表に対する変更を反映するために定期的にリフレッシュされる。この意味においては、スナップショットは実際には周期性のあるビューである。
DBMSに格納されたコード・モジュールであり、データベースに対する操作を実行する。多くの場合、SQLで記述される。
表、ビュー、スナップショット、順序、プロシージャ、ファンクションまたはパッケージの別名。識別を簡単にするために表に割り当てられた別の名前である。たとえば、他のアカウントまたはデータベースに存在する表を参照する場合は、長い識別文字列のシノニムを定義すると便利な場合がある。表名が変更された場合は、関連する問合せを書きなおすかわりにシノニムを再定義するだけですむ。シノニムは、オブジェクトの実際の名前と所有者のマスク、オブジェクトへのパブリック・アクセスの提供、リモート・データベースの表、ビューまたはプログラム単位の位置の透過性の提供、およびデータベース・ユーザーのSQL文の簡略化に使用される。シノニムは、パブリックにもプライベートにもできる。
T |
Business Component Browser(Business Component Testerとも呼ばれる)にアクセスするには、ナビゲータの「ワークスペース」ノードの下にある、アプリケーション・モジュールを右クリックし、「テスト」を選択する。
Oracle Business Component Browserは、Thin Javaクライアントの汎用アプリケーションである。これは、フレームワークのクライアントAPIの動的な機能を使用して、使用するアプリケーション・モジュールの実行時のメタデータを問い合せ、現行のアプリケーション・モジュールに含まれているビュー・オブジェクトおよびビュー・リンクのディレクトリを示す。Business Component Browserは、参照する各ビュー・オブジェクトに対してSwingベースの動的なフォームを作成し、テストする各ビュー・リンクに対して動的なマスター/ディテール・フォームを作成する。
Oracle Business Component Browserは、フレームワークの次のような実行時の特性をすべて視覚的に表す。
ビュー・オブジェクト。問合せ実行および表示範囲のスクロールが可能。
エンティティ・オブジェクトのビジネス・ロジック。ドメインが正しく設定されていること、デフォルト値のロジックが正しく機能していること、検証コードが機能していること、およびAssociationで目的のものが参照されることを確認できるように、関連するビュー・オブジェクトの列が変更された際に実行される。
複数のビュー・オブジェクト。同じエンティティ属性を含み、そのいずれかが変更された場合でも同期化される。
ビュー・オブジェクトにリンクされたビューは、マスター・レコードから任意の階層レベルにスクロールした際に、自動的にマスター/ディテール形式になる。
アプリケーション・モジュールは、サポートされている任意のデプロイメント構成(ローカル、物理ビジネス・ロジック層のリモートCORBA/EJB)で1つのアプリケーションからテストできる。
コミットを行うと、キャッシュ内の基になるエンティティ・オブジェクトにより、保留中のすべての変更がデータベースに送られる。
表示に必要なデータのみを取得するクライアント。ビジネス・ロジックは別の層で実行される。
トランザクションは、データベース操作を管理するためのインタフェースである。トランザクション内のデータ変更の操作がすべて成功していない場合、その変更はサーバーに受け入れられない。これらの操作には、属性値や標準のSQLコール(INSERT、UPDATE、DELETEなど)を設定するメソッド、またはJavaストアド・プロシージャやSQLパッケージのコールなどの特殊なコールを設定するメソッドが含まれる。トランザクションは最小の単位である。つまり、1つのトランザクション内の操作の結果は、すべてコミット(データベースに保存)されるか、すべてロールバック(元に戻される)される。
たとえば、銀行サービスを使用するクライアントが普通預金口座から当座預金口座へ振替を行う場合、トランザクションは、普通預金口座の減額、当座預金口座の増額、取引記録への取引の記録という3つの異なる操作から構成される。3つの操作すべてが実行されて口座の残高が適切であれば、トランザクションはコミットされ、操作の結果がデータベースに適用される。しかし、(残高の不足、無効な口座番号、ハードウェア障害などの)なんらかの理由で操作のいずれかが完了されない場合、すべての口座の残高が正しくなるようトランザクション全体をロールバックする必要がある。
また、トランザクションにより、複数ユーザーが共有するデータ・ストアの一貫性が保たれる。あるクライアントがデータを変更する場合、ロックが行われ、最初のクライアントが操作を完了するまで他のクライアントは他の変更を行えなくなる。トランザクションがコミットまたはロールバックされた場合、ロックが解放される。
Business Components for Javaのアプリケーション・モジュールでは、デフォルトのトランザクションおよび同時実行サポートが提供されている。デフォルトの動作をカスタマイズする場合以外は、コーディングの必要はない。
ビジネス・コンポーネントを使用してプログラミングする場合、トランザクション管理の原則はビジネス・ロジック層でもクライアントでも同じである。
データベースに接続するアプリケーション・モジュールを作成し、トランザクションのコンテキストを確立する。
問合せを実行する。
結果セットを操作する(属性を設定し、値を検証する)。
変更をデータベースにコミットする(新規データを他のアプリケーション・モジュールに対して使用可能にする)か、ロールバックする。
ビジネス・コンポーネント・フレームワークでは、キャッシュとデータベースで変更の同期をとるため、(変更指向の方法ではなく)バッチ指向の方法が使用される。この方法には、次のような利点がある。
変更内容は、メモリー内キャッシュにバッファリングされる。
キャッシュ内の変更内容は、一連のデータベース操作処理を使用してデータベースと同期化される。この一連の操作を、ポストと呼ぶ。(Business Components for Javaでは、ポストはコミット・サイクルで実行されるか、TransactionインタフェースでpostChangesをコールして実行する。)
いくつかの状態変更が行われた場合、個々の変更によりキャッシュが無効なデータベース状態になっている可能性があるため、ポストの直前に検証が実行される。
この設定は、ビュー・オブジェクト・ウィザードおよびビュー・オブジェクト・エディタ、エンティティ・オブジェクト・ウィザードおよびエンティティ・オブジェクト・エディタと、ドメイン・ウィザードおよびドメイン・エディタの「属性の設定」ページ、ならびにエンティティ属性エディタに表示される。すべてのJava変数には型が定義されており、この型によって、割当てが可能なオブジェクトの種類が制限される。
エンティティ・オブジェクト属性の場合、この設定は属性のJavaデータ型またはドメイン型となる。「データベース列」の「型」も指定する。これはデータベース列のSQLデータ型で、実行時にデフォルトのJava JDBC型を導出する際に使用する。SQLデータ型はJavaデータ型と一致している必要がある。一致していない場合は、文字列の変換などで実行時にランタイム例外が発生することがある。順方向生成の際には、「データベース列」の「型」がデータベースの列の型となる。
ビュー・オブジェクト属性の場合、この設定は属性のJavaデータ型またはドメイン型となる。永続属性、およびエンティティ導出属性では、対応するエンティティ属性で指定した型はオーバーライドできない。
ドメインの場合、この設定は、ドメインのメタデータ・フィールドのJava型となる。
属性がドメイン型で、「データベース列」の「型」属性の設定がドメインで設定されている場合は、エンティティ・オブジェクト・ウィザードまたはエンティティ・オブジェクト・エディタで設定をオーバーライドすることはできない。
U |
Object Management Group(OMG)のUnified Modeling Languageは、複雑なソフトウェアの仕様を明確にし、視覚化するための、Booch法、OMT法、OOSE法などの以前からの標準に基づく一般的な表記言語。この言語は、大規模なオブジェクト指向プロジェクトでの使用に適している。
この設定は、エンティティ・オブジェクト・ウィザードおよびエンティティ・オブジェクト・エディタと、ドメイン・ウィザードおよびドメイン・エディタの「属性の設定」ページ、ならびにエンティティ属性エディタに表示される。
永続エンティティ・オブジェクト属性の場合、この設定を選択すると、特定の値を持つ行は1行のみとなる(この列の各行には一意の値が定義される)。順方向生成の場合は、データベースの対応するNOT NULL制約が作成される。
属性がドメイン型で、「一意」属性の設定がドメインで設定されている場合は、エンティティ・オブジェクト・ウィザードまたはエンティティ・オブジェクト・エディタで設定をオーバーライドすることはできない。
この設定は、ビュー・オブジェクト・ウィザードおよびビュー・オブジェクト・エディタ、エンティティ・オブジェクト・ウィザードおよびエンティティ・オブジェクト・エディタと、ドメイン・ウィザードおよびドメイン・エディタの「属性の設定」ページ、ならびにエンティティ属性エディタに表示される。この設定により、属性に対してsetAttributeメソッドをコールできるかどうかが定義される。属性には、「更新可能」設定として次のいずれかを定義する必要がある。
常に: 属性は、ビジネス・ロジック層のキャッシュ内で更新される。
新規の間: 属性は、オブジェクトが新規の間のみ、つまりオブジェクトが初めてコミットされるまで更新できる。データベースにコミットされた後は、この属性は読取り専用になる。
なし: 属性は、フレームワークでは更新できない。ヒント: セッター・メソッドの削除の検討が必要な場合もある。
永続ビュー属性またはエンティティ導出ビュー属性では、属性を更新可能にするかどうかの設定を対応するエンティティ属性よりさらに制限することはできるが、緩和することはできない。したがって、エンティティ属性の設定が「なし」でビュー属性の設定が「常に」の場合、設定は「なし」になる。属性がドメイン型の場合も、同様である。
V |
Business Components for Javaには、ビジネス・ロジック層で検証ロジックを定義、実装および実行するためのフレームワークが用意されている。検証フレームワークでは、内部の実装の詳細が隠された、一貫したプログラミング・モデルが提供される。これにより、ユーザーが無効な値をデータベースに入力できないようにする規則に集中できる。
検証は、整合性(またはデータベースの)制約とは異なる。整合性制約は、表の列にビジネス・ルールを定義する宣言である。整合性制約は、表で定義され、表定義の一部として、データベースのデータ・ディクショナリに主として保存される。これによって、すべてのデータベース・アプリケーションに同じ規則が適用される。Business Components for Javaを使用しないクライアントには、(検証の他に)整合性制約を使用できる。
次のプログラムによる手法(Java)または宣言による手法(XML)を使用し、検証ロジックを定義および適用できる。検証に様々なレベルが定義されている場合は、その検証は一貫してこの順序で起動される。
エンティティ・オブジェクト属性およびビュー・オブジェクト属性のデータ型としてのドメインの使用。(プログラムによる手法)ドメイン・オブジェクトは、コンストラクタ内のデータを検証する。また、ドメイン・オブジェクトの検証メソッドに規則を適用したり、コードを追加して、ビジネス・ロジックを修正できる。ドメインを使用すると、エンティティ、ビュー(またはその両方)の全体で属性レベルの検証を共有できる。クライアントのプログラミング方法に応じて、検証はクライアントまたはビジネス・ロジック層で起動される。たとえば、ドメイン型CurrencyでPrice属性を作成するとする。クライアントにドメインがダウンロードされている場合は、ユーザーが適切な通貨を入力していないと、フィールドから移動した時点で、そのことが通知される。ドメインは、属性間で再利用できる。たとえば、CreditCardドメインが頻繁に再利用される場合、検証が必要なすべてのエンティティ・オブジェクトにコードを追加する必要はなく、更新も一度に行える。
エンティティ検証メソッドの編集。(プログラムによる手法)ビジネス・コンポーネント・フレームワークでは、エンティティ・オブジェクトのsetAttribute メソッド(Dept.setLocなど)を作成できる。この場合、属性を設定する前または後に起動される検証を追加できる。セッター・メソッドには、属性値によってのみ影響を受け、頻繁に再利用する必要のない規則を追加する。
validateEntityメソッドへのコードの追加。(プログラムによる手法)ベースのEntityクラスにより、エンティティ・オブジェクトでオーバーライドできるvalidateEntityメソッドが提供される。エンティティ検証は、ある行から別の行へ移動する前に起動される。エンティティ検証は、複数の属性値を検証する場合に便利である。行全体の値が入力されるまで個別のフィールドの検証を行わない場合や、関連付けられているエンティティ・オブジェクトの値を検証する場合などである。たとえば、Salary属性では、役職名、通貨などの別のフィールド値のチェックが必要な場合がある。また、開始日として終了日よりも前の日付を設定する必要がある場合など、日付の範囲をチェックする場合もある。
エンティティ・オブジェクトおよびエンティティ属性に対する検証規則の適用。(宣言による手法)検証規則では、検証の再利用パターンがカプセル化され、適切なパラメータ値を指定することにより、これを使用できる。エンティティ・オブジェクト・ウィザードおよびエンティティ・オブジェクト・エディタ、ならびにエンティティ属性エディタを使用して、コードを記述せずに単純な規則を定義し、適用できる。すべてのコードを記述するのではなく、ウィザードを使用すると、XMLが生成され、Javaコードを再コンパイルせずに規則をカスタマイズできる。定義済のValidatorタイプを使用することも、独自に定義することもできる。独自のカスタム検証クラスでは、より複雑な規則も実装できる。この場合、クラスをValidatorタイプとして登録し、定義済の規則と同様に適用できる。
コンポジットの定義。(プログラムによる手法)コンポジットによって、ビュー・オブジェクト・レベルでの親子階層の検証が提供される。親のvalidateEntityメソッドが、子を検証する。たとえば、注文がなければ明細品目は発生しない。
ビジネス・コンポーネント・フレームワークは、様々な検証レベルをサポートする。属性、エンティティおよび論理ビジネス・オブジェクトを検証できる。JDeveloperは、データが作成または変更された際に適切なレベルで検証ロジックをコールするが、表にすでに存在しているデータは有効であると仮定する。問合せにより、無効な値(たとえば、検証ロジックが適用される前に入力されたレガシー・データからの値)が含まれた結果セットが返されることがあるが、ユーザーが表に無効な値を入力することはできない。フレームワークでは、最上位レベルのオブジェクトで規則が起動される前に、これに含まれるオブジェクトで規則が起動される。
エンティティ・オブジェクトでは、検証規則を使用し、問合せで有効な値が返されること、またはユーザーが無効な値を表に入力しないことを保証する(たとえば、従業員の給与が700を超えてはならないなど)。検証規則は、エンティティ・オブジェクト全体で使用する再利用可能な検証コードをカプセル化するJavaBeansである。
エンティティ・オブジェクト・ウィザードおよびエンティティ・オブジェクト・エディタ、ならびにエンティティ属性エディタの「検証」ページでは、検証規則と検証レベル、および同じレベル内での実行順序を指定できる。検証レベルは、選択内容に応じて規則が属性レベルとエンティティ・オブジェクト・レベルのいずれに適用されるかを示す。検証規則を適用するには、XMLメタデータをエンティティ・オブジェクトに結び付ける。すべてを記述するのではなく、ウィザードを使用すると、XMLが生成され、Javaコードを再コンパイルせずに規則をカスタマイズできる。
実行時に、属性レベルの検証規則は、生成されたセッター・メソッドを介して属性値が変更された場合、またはエンティティ・オブジェクトでコールされたsetAttributeメソッドにより属性値が変更された場合に起動される。エンティティ・レベルの検証規則は、クライアントのイテレータ内の現在の行が、あるエンティティ・オブジェクトから次のエンティティ・オブジェクトに変わった場合、エンティティ・オブジェクトが無効であればコミット・サイクル中、またはエンティティ・オブジェクトでvalidateメソッドが明示的にコールされた場合に起動される。
Business Components for Javaには定義済の規則が用意されているが、独自の規則も作成できる。
ビジネス・コンポーネント・プロジェクト・エディタの「登録済の規則」ページでは、プロジェクト内にある検証クラスで実装されたカスタム検証規則を作成および登録できる。「新規」をクリックして新規クラスを作成し、カスタマイズするか、すでにカスタマイズされているクラスを登録する。登録済の検証規則は、プロジェクトのXML定義(JPXファイル)とともにリストとして保存される。登録済の規則は、定義済の検証規則の1つで行う場合と同じように、エンティティ・オブジェクトまたは属性に適用できる。
1つ以上のデータベース表の列から構成され、1つの論理表に結合されているデータソース。1つ以上の表のデータのカスタム調整された表示形式。ストアド・クエリーとも呼ばれる。ビューは仮想表の一種である。つまり、問合せを実行する際には表のように動作するが、実際には表のサブセット、表の組合せまたは2つ以上の表の結合へのポインタとして機能するオブジェクトである。
UMLでは、ビューはモデルの投影である。投影は、要素のセットからそのサブセットへのマップである。モデルの投影は、特定の観点または視点から見たものであり、この観点に関連しないエンティティを除外する。
表のビューを表すビュー・オブジェクト間の関係を定義する。関係は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のインスタンス。
これらのツールは、ビュー・リンクの作成および編集に使用する。また、ビジネス・コンポーネント・プロジェクト・ウィザード、ビジネス・コンポーネント・パッケージ・ウィザードおよびエンティティ・オブジェクト・ウィザードを使用することにより、既存のAssociationに基づいて、デフォルトのビュー・リンクを作成することもできる。
ビュー・リンク・ウィザードでビュー・リンクを作成するには、ビジネス・コンポーネント・プロジェクトが開いている状態で、次のいずれかを行う。
「ファイル」->「新規」を選択し、「Business Tier」->「Business Components(BC4J)」を選択して「ビュー・リンク」をダブルクリック
ナビゲータの「ワークスペース」ノードの下にある、ビジネス・コンポーネント・パッケージを右クリックし、「新規ビュー・リンク」を選択
ビュー・リンクを編集するには、ナビゲータの「ワークスペース」ノードの下にあるビュー・リンクを右クリックし、「linkの編集」を選択する。
ビュー・リンクを作成する場合、ウィザードを使用して次の情報を指定できる。ここでは、ページごとに説明する。
「名前」ページ。ビュー・リンク名(識別しやすいように末尾をLinkという文字列などにし、関係を説明するような名前を指定)、およびビュー・リンクを格納するパッケージ。
「ビュー・オブジェクト」ページ。リンク元(マスター)ビュー・オブジェクトとリンク先(ディテール)ビュー・オブジェクトを選択し、リンク先ビュー・リンク・アクセッサの名前を指定する。また、コード内の関係にアクセスする場合は、オプションでアクセッサを生成する。いったんリンクが定義されると、リンク元ビュー・オブジェクトは、リンク・アクセッサを使用することにより、リンクのリンク先にアクセスできる。たとえば、getEmpsメソッドをコールすることにより、ある部門の従業員に部門からアクセスできる。(デフォルトのビュー・リンクの場合、リンク元ビュー・オブジェクトには主キーが、リンク先ビュー・オブジェクトには外部キーが含まれる。)
「リンク元の属性」ページおよび「リンク先の属性」ページ。リンクのリンク元ビュー・オブジェクトとリンク先ビュー・オブジェクトの関係を定義する属性を選択する。(リンク元とリンク先は別々のページである。各ページには同じ数の属性を順に指定する必要がある。)オプションで、Associationを定義するすべての属性を指定できる。「選択済の属性」リストにAssociationを移動すると、そのAssocationに関連付けられた属性が自動的に表示される。また、リンク元でAssociationを選択した場合、一致する属性(該当する場合)が、デフォルトでリンク先のページに含められる。これらの属性はSQL Snippetの作成に使用されるもので、必要な場合は変更できる。
「SQL設定」ページ。ビュー・リンクのリンク先でレコードのフィルタリングに使用されるデフォルトのSQL文を調べ、オプションで、追加の有効なSQL制約が実施されるようにその文を変更する。「テスト」をクリックすると、SQL文が有効であることを確認できる。
ビュー・リンクを編集する際に、エディタを使用して同じ情報を指定できる。
ビュー・オブジェクトを作成した後にAssociationを追加する場合は、ウィザードでリンクを手動で追加できる。
SQL問合せを使用して、エンティティ・オブジェクトからフィルタリングされる属性のサブセットを指定する。データのビューは、SQLに基づいているが、基礎となるエンティティ・オブジェクトとは別であるため、必要なUIをサポートする柔軟性の高いデータ取得が実現する。つまり、画面に表示する必要のあるデータのセットを問い合せることができる。ビュー・オブジェクトにより、クライアントには、基礎となるエンティティ・オブジェクトを意識せずに、またはこれらに関する知識がない場合でも、スクロールして更新ができる行セットが提供される。クライアントは結果セット内を移動し、属性値を取得および設定することにより、データを操作する。トランザクションがコミットされると、基礎となるデータベース内のデータが変更される。ビュー・オブジェクト間の関係は、ビュー・リンクを使用して表される。各ビュー・オブジェクトは、結果セット内の移動に使用できるデフォルトのイテレータを提供する。
ビュー・オブジェクトは、通常、次の場合に使用される。
定義済の行および列のセットへのアクセスを制限することにより、さらに高度なセキュリティを追加する場合。たとえば、(給与などの)機密性の高いデータを含む列を除外したビュー・オブジェクトを作成できる。
データの複雑性を隠す場合。たとえば、1つのビュー・オブジェクトに、複数のエンティティ・オブジェクトの列または行を表示できる。このようなビュー・オブジェクトでは、データが複数の表から取得されたものであるという事実が隠される。
表示形式をカスタマイズする場合。ビュー・オブジェクトを使用することにより、ビュー・オブジェクトの基礎となっているエンティティ・オブジェクトに影響を与えずに、列の名前を変更できる。
複雑な問合せを保存する場合。問合せにより、表データに関する大量の計算を実行できる。この問合せをビュー・オブジェクトに保存すると、ビュー・オブジェクトの問合せが実行されたときのみ計算が実行される。計算が実行されてから、データがデータベースから取得される。
最適化され、実行にかかる時間の短いSQLを使用し、必要なデータのみを選択することにより、アプリケーションの効率を高める場合。
1つのエンティティ・オブジェクトに対して複数のビュー・オブジェクトを定義できる。また、1つのビュー・オブジェクトは複数のエンティティ・オブジェクトからデータを選択できる。データはエンティティ・オブジェクト・レベルでキャッシュされ、同じトランザクション内のすべてのビュー・オブジェクト参照でそのキャッシュを共有するため、あるビュー・オブジェクトを介して行われた変更は、同じトランザクション内の他のビュー・オブジェクトでただちに使用可能になる。
ビュー・オブジェクトを定義する場合、どの基礎エンティティ・オブジェクトを読取り専用にするか、およびどのエンティティ・オブジェクトでビュー・オブジェクトの属性リスト内の属性に対する読み書き操作を可能にするかを指定できる。
アプリケーション・モジュール・ウィザードおよびアプリケーション・モジュール・エディタでは、マスター/ディテール関係でビュー・オブジェクトをリンクするために使用するビュー・リンクを選択できる。ビュー・リンクは、実行時に実行されるコード内でも指定できる。ディテール・ビュー・オブジェクトは、自動的に、対応するマスター・ビュー・オブジェクトと同期化される。
アプリケーション・モジュールは、無制限ビューやディテール・ビューなど同じビュー・オブジェクトを何回も使用できる。別名を指定して、所定のビュー・オブジェクトの様々な使用方法を表すことができる。
oracle.jbo.server.ViewObjectImplを直接的または間接的に拡張するクラス。メソッドをカスタマイズする(ビュー・オブジェクト・インスタンスのビュー定義の一部を動的に変更できるようにcreateメソッドをオーバーライドする場合など)には、ビジネス・コンポーネント・プロジェクト・ウィザード、ビジネス・コンポーネント・パッケージ・ウィザードまたはパッケージ・エディタまたはビュー・オブジェクト・ウィザードおよびビュー・オブジェクト・エディタを使用して、このJavaクラスを作成できる。たとえば、WHERE句へのバインド変数の自動的な設定や、セキュリティやフィルタリングのためのWHERE句条件の自動的な追加などを行う場合がある。また、クライアントが、複数クライアント表から自身の情報のみを問合せできるようにするには、そのためのWHERE句を各フォームで追加するかわりに、クライアントIDを確認できる。デフォルトの行セットを操作し、行ではなく、ビュー・オブジェクトに固有である場合、メソッドは、ビュー行クラスにではなく、ビュー・オブジェクト・クラスに置く。
このクラスは、カスタム・クラスから拡張するよう指定できる(カスタム・クラスは、ViewObjectImplクラスを直接的または間接的に拡張したもので、プロジェクト・クラスパス内にあることが必要)。たとえば、すでに記述されているコードを再利用する場合、または特別なニーズに合せてビジネス・コンポーネントのフレームワークをカスタマイズするよう決定した場合には、このように指定する。
これらのツールは、ビュー・オブジェクトの作成および編集に使用する。デフォルトのビュー・オブジェクトは、ビジネス・コンポーネント・プロジェクト・ウィザード、エンティティ・オブジェクト・ウィザードまたはエンティティ・オブジェクト・エディタおよびビジネス・コンポーネント・パッケージ・ウィザードまたはパッケージ・エディタでも作成できる。
デフォルトのビュー・オブジェクトの定義内容は非常に単純である。このため、ビュー・オブジェクト・ウィザードおよびビュー・オブジェクト・エディタを使用してビュー・オブジェクトを作成し、ニーズに合せて編集する。ここでは、次のものを使用するビュー・オブジェクトを対象とする。
エンティティ・オブジェクトの属性のサブセット
複数のエンティティ・オブジェクトの属性
特殊なSQL導出属性または一時属性
デフォルト以外の記憶領域および更新機能
1つのビュー・オブジェクトで複数の更新可能エンティティ・オブジェクトを使用できることにより、Business Components for Javaの主要な機能の1つが可能になる。この機能は、1つのビュー・オブジェクトで複数のエンティティ・オブジェクトを更新できることである。
ビュー・オブジェクト・ウィザードでビュー・オブジェクトを作成するには、ビジネス・コンポーネント・プロジェクトが開いている状態で、次のいずれかを行う。
「ファイル」->「新規」を選択し、「Business Tier」->「Business Components(BC4J)」を選択して「ビュー・オブジェクト」をダブルクリック
ナビゲータの「ワークスペース」ノードの下にある、ビジネス・コンポーネント・パッケージを右クリックし、「新規ビュー・オブジェクト」を選択
ビュー・オブジェクトを編集するには、ナビゲータの「ワークスペース」ノードの下にあるビュー・オブジェクトを右クリックし、「objectの編集」を選択する。
ビュー・オブジェクトを作成する場合、ウィザードを使用して次の情報を指定できる。ここでは、ページごとに説明する。
「名前」ページ。ビュー・オブジェクトを作成するために使用されるエンティティ・オブジェクト(該当する場合)、ビュー・オブジェクトの名前(たとえばentityView)、ビュー・オブジェクトの別名(たとえば名前の競合を避けたりディテール・ビューを無制限ビューと区別したりするため)、各エンティティ・オブジェクトの属性をこのビュー・オブジェクトに対して読取り専用にするかどうか、外部キーを変更したときに外部キーが別のフィールドを参照するようにするかそのフィールド値を更新するか(たとえば、注文入力アプリケーションで、品目IDの変更が、別の在庫品目の注文と在庫品目の品目IDの変更のどちらを意味するか)、ビュー・オブジェクトを配置するパッケージ。更新を実行する場合は、エンティティ・オブジェクトを指定する必要がある。また、情報の結合を取得する場合は、エンティティ・オブジェクトの指定が推奨される。ただし、読込み目的のみでデータを問い合せる場合は、エンティティ・オブジェクトは必要ない。エンティティ・オブジェクトを使用すると更新と検証が可能になり、メモリーにおいて行が一意に保たれる。
「属性」ページおよび「属性の設定」ページ。エンティティ・オブジェクトから含める属性を指定し、新しい属性(一時属性またはSQL導出属性)を定義して属性の設定を指定する。設定では、属性の名前、属性の型、別名、SQL式、更新可能かどうか(常に、新規の間、なしのいずれか)、およびビュー・オブジェクトの問合せで選択されているかどうか、問合せ可能かどうか、を指定する。メモリーを節約してパフォーマンスを向上させると同時に、フォルトインを回避するには、クライアントUIのフォームに必要な属性のみを組み込む。基礎となるエンティティ・オブジェクトが更新可能な場合は主キーを組み込む必要がある。これはウィザードによって行われる。
「問合せ」ページ。オプションで、ビュー・オブジェクトのSQL文をカスタマイズする。WHERE句およびORDER BY句を追加できる。「参照」をクリックし、問合せ結果の順序を決定する属性を選択する。(自動的に生成されたSELECT句およびFROM句など)他の方法で問合せを変更する場合は、「エキスパート・モード」を選択できる。SQL文が文法的に正しいかどうかを検証するには、「テスト」をクリックする。
「属性マッピング」ページ。「エキスパート・モード」を選択した場合は、問合せ結果列をビュー属性にマップできる。カスタムSQL問合せで列の位置を削除、追加、または変更した場合は、以前のマップは不適切であるため、これらの項目をマップしなおす必要がある。
「Java」ページ。ビュー・オブジェクトをカスタマイズする場合は、ウィザードで、ビュー・オブジェクト・クラスまたはビュー行クラス(あるいはその両方)に対してJavaファイルを生成するよう指定できる。デフォルトでは、ウィザードはビュー・オブジェクト・クラスを生成し、ビュー行クラスを生成しない。
ビュー・オブジェクトを編集する場合、これまでのページの情報の他に、エディタを使用して次の情報を指定できる。
「カスタム・メソッド」ページおよび「カスタム行メソッド」ページ。エクスポートするメソッドを選択する。クライアントは、これらのメソッドをリモートで使用できる。ビュー・オブジェクトのクラス・ファイルに記述したメソッドは、「使用可能」リストに表示される。リストには、シリアライズ可能インタフェースを実装するデータ型のもののみが表示される。メソッドをエクスポートするには、「選択済」リストへ移動する。このページを使用する前に、「Java」ページで、ビュー・オブジェクト・クラスに対して「Javaファイルの生成」を選択する必要がある。クライアントでメソッドを使用する前に、アプリケーション・モジュールをリモート対応にする、クライアント・コードにパッケージをインポートする、クライアント・コード内でメソッドをコールするなどの処理が必要である。これについては、Business Components for Javaのオンライン・ヘルプで説明している。
「プロパティ」ページ。プロパティを追加するには、プロパティ名と値を指定し、「追加」をクリックする。また、既存のプロパティ値の追加および編集、プロパティの削除が可能である。
ビュー・オブジェクトを作成した後でデータベース表を変更し、ビュー・オブジェクトを変更する必要がある場合には、ビュー・オブジェクト・エディタで手動で変更できる。たとえば、エンティティ・オブジェクト内の新しい列に対応する属性をエンティティ・オブジェクトに追加できる。
oracle.jbo.server.ViewRowImplを直接的または間接的に拡張するクラス。メソッドをカスタマイズするときは、ビュー・オブジェクト・ウィザードまたはビュー・オブジェクト・エディタを使用してこのJavaクラスを作成できる。たとえば(属性のゲッター・メソッドに)このビューの値を計算するカスタム・ロジックを実装する場合がある。このクラスでは、行を操作するメソッド、つまり操作に1行のデータが必要なメソッドを持つことができる。ビュー・オブジェクト・クラスに、行セットに対して機能するメソッドを追加できる。また、エンティティ・オブジェクトのメソッドをコールする行クラス・メソッドを作成することにより、エンティティ・オブジェクト・メソッドをクライアントに公開できる。
このクラスは、カスタム・クラスから拡張するよう指定できる(カスタム・クラスは、ViewRowImplクラスを直接的または間接的に拡張したもので、プロジェクト・クラスパス内にあることが必要)。たとえば、すでに記述されているコードを再利用する場合、または特別なニーズに合せてビジネス・コンポーネントのフレームワークをカスタマイズするよう決定した場合には、このように指定する。ウィザードでは、オプションとしてアクセッサ・メソッド(たとえばgetJobやsetJobなど)の生成を選択できる。これによって、対応する属性フィールドに対するタイプ・セーフなアクセスが提供され、ここに検証のための独自のカスタム・コードを追加できる。
W |
Business Components for Javaでは、次のウィザード、エディタおよびツールが提供される。
デプロイ・ツール
X |
eXtensible Markup Languageは、電子的データ交換の標準を定義する。XMLでは、データの作成および解釈を明確に実行できるように、データ固有の構造を表す厳密なテキストベースの方法が指定される。単純なタグベースの方法により、開発者のHTMLの知識を利用する一方で、高度な構造のデータベース・レコードから体系化されていない文書にいたる、あらゆるデジタル資産を処理できる柔軟性が高く充実した機能を提供する。