ビジネス・オブジェクトの構造の判別

ビジネス・オブジェクトは、ビジネス・インテグレーション・システムのコンポーネントと、そのシステムによって統合されるアプリケーションとの間でのデータ移送を目的としたものです。その理由から、移送しなければならないデータは、ビジネス・オブジェクトによってモデル化する必要があります。このデータは通常、ビジネス・インテグレーション・システムによって統合されるアプリケーション、またはテクノロジーのエンティティーに関連付けられます。ビジネス・オブジェクトの構造は、以下のどちらかです。

このセクションでは、さらに "複数エンティティーを設計する上での考慮事項"についても取り上げます。

単一エンティティーの表現

最も単純なビジネス・オブジェクトの設計は、1 つのエンティティーを表すフラット・ビジネス・オブジェクトです。

フラット・ビジネス・オブジェクトの属性はいずれも単純であり、各属性が 1 つの値 (例えば StringIntegerDate など) を表します。詳しくは、"フラット・ビジネス・オブジェクト"を参照してください。

アプリケーション固有のビジネス・オブジェクトの場合、フラット・ビジネス・オブジェクトは、アプリケーションまたはテクノロジーの規格に含まれる 1 つのエンティティーを表します。ここで例として、レコードを記述するデータベース表を持つアプリケーションを考えます。また、この表には ObjectID (オブジェクト ID)、 UserName (ユーザー名)、TimeStamp (タイム・スタンプ)、Detail (詳細)、および Status (状況) という 5 つの列 (図 8 を参照) があるとします。ObjectID は各行の基本キーとなっていて、その値はアプリケーションによって生成されます。この表は、他の表との関係はありません。

図 8. 単一のエンティティーを表すフラット・ビジネス・オブジェクト


図 8 に示すように、表を表す目的に Record ビジネス・オブジェクトを設計する場合、各列に 1 つずつ合計で 5 つの属性を与え、そのキー属性を ObjectID 列に対応させます。

フラット・ビジネス・オブジェクトを使用することにより、対応するコネクターの設計を以下のように簡略化できます。

このタイプのビジネス・オブジェクトは、設計も、処理に必要なコネクター・ロジックも単純です。しかし、一般にアプリケーション・エンティティーはより複雑で、他のオブジェクトに格納されている情報が組み込まれます。

複数エンティティーの表現

ビジネス・オブジェクトは、表 3 に示す方法の 1 つを使用して、他のエンティティーからのデータを組み込むアプリケーション・エンティティーを表現できます。

表 3. 複数エンティティーの表現
ビジネス・オブジェクトの構造 データ編成のタイプ 親子関係のタイプ
親ビジネス・オブジェクトは、他のエンティティーを表す子ビジネス・オブジェクトを 1 つ以上持つことができます。 1 対 1

1 対多

構造的
親ビジネス・オブジェクトは、他のエンティティーを表す他のトップレベルのビジネス・オブジェクトを参照する外部キー属性を 1 つ以上持つことができます。 1 対 1

1 対多
多対多
多対 1

意味的
アプリケーションおよびそのインターフェースによって許可される場合、フラット・ビジネス・オブジェクトは、他のエンティティーを直接参照する属性を持つことができます。 1 対 1 なし

複数のエンティティーを表すビジネス・オブジェクトを構造化する方法を決定する場合は、次の指針に基づいて検討してください。

これらの各表現については、以降のセクションで詳しく説明します。

構造的関係

構造的関係では、親ビジネス・オブジェクトはその子ビジネス・オブジェクトを物理的に含めることができます。そのようなビジネス・オブジェクトは、複合属性が少なくとも 1 つはある (属性に子ビジネス・オブジェクトまたはその配列のどちらかが含まれる) という点では、階層型ビジネス・オブジェクトであるといえます。

この属性の Relationship 属性プロパティーは、包含関係を示す containment です。この属性のタイプは、その属性によって表される子ビジネス・オブジェクト (またはオブジェクト) のタイプとなっています。詳しくは、"階層型ビジネス・オブジェクト"を参照してください。

以下の階層型ビジネス・オブジェクトは、構造的関係を表します。

いずれの場合も、親ビジネス・オブジェクトは子または子の配列を持つため、その関係は構造的に定義されます。

構造的な関係の場合、親ビジネス・オブジェクトは子オブジェクト内のデータを所有することが前提となります。したがって、社員を新規に作成した場合、その従業員の住所が保持されるように、住所表に新規の行が挿入されます。同様に、従業員を削除すると、その従業員の住所も住所表から削除されます。

意味的関係

意味的な関係では、親ビジネス・オブジェクトがその子を参照するか、子が親を参照します。1 つのビジネス・オブジェクトが別のビジネス・オブジェクトを参照する場合、参照する側のオブジェクトは参照先のオブジェクトを一意に識別する値を格納しますが、オブジェクト自身は格納しません。この場合、ビジネス・オブジェクトを処理するコンポーネントは、この関係を意味的に導き出します。

一般に、意味的な関係は、外部キー として機能する単純属性によって定義されます。外部キー属性は、一方のビジネス・オブジェクト内に位置し、他のビジネス・オブジェクトの固有 ID (基本キー と呼ばれる) を保持しています。

つまり、両方のビジネス・オブジェクトとも固有な ID を保持する基本キー属性を持っています。また、ビジネス・オブジェクトの 1 つは、他のビジネス・オブジェクトの基本キーの値を保持するための、外部キー属性を備えています。この外部キーにより、親と子の間に意味的にリンクが確立されます。

意味的な関係は、エンティティー間に多に対する多または多対 1 の関係がある場合、言い換えれば複数の親が同じ子との関係を持っている場合に重要になります。エンティティーを構造的にではなく意味的に関連付けると、子のデータが分離されるため、この意味的な関連付けはデータの整合性維持には重要であるといえます。

意味的に定義された関係では親に子が包含されないため、この親子に対する要求を処理するコネクターは、親に対する要求と子に対する要求をそれぞれ別個の操作で受け取ることになります。つまり、コネクターは、要求がそれぞれ別個に送られてくるため、親と子をそれぞれ別個の操作で処理します。詳しくは、"関係におけるデータの所有権" および "意味的関係と構造的関係からの選択"を参照してください。

意味的関係を指定するために、表 4 の設計オプションを考えてみましょう。

表 4. 意味的関係のための設計オプション
設計オプション 関係のタイプ
親オブジェクトへの外部キーの格納 1 対 1

多対 1

子オブジェクトへの外部キーの格納 1 対多
子オブジェクト配列への外部キーの格納 1 対多
多対多
ビジネス・オブジェクト・ツリーへの外部キーの格納 1 対 1

親オブジェクトへの外部キーの格納

外部キーの使い方がごく単純な場合は、関係を確立するための外部キーが親に格納されます。この場合、親が格納できるのは、指定されたタイプの 1 つの子への参照のみです。親と子の間の関係は、親の内部で明確に定義されます。そのため、この構造は 1 対 1 の関係を表します。ただし、複数の親ビジネス・オブジェクトから同じ子ビジネス・オブジェクトを参照すると、多対 1 の関係を実装できます。

注:
関係を確立するための外部キーを親に格納する場合、親はそれぞれ 1 つの子への参照を持つ複数の属性を格納できますが、これらの属性は一般にそれぞれ異なるタイプの子を参照します。

図 9 では、Customer ビジネス・オブジェクトに 2 つの属性 (AddressId および CustInfo) があり、各属性には子ビジネス・オブジェクトへの参照が含まれています。Customer ビジネス・オブジェクト内の外部キー属性から、親と 2 つの子との関係が即座にわかります。

図 9. 1 対 1: 親ビジネス・オブジェクトに格納された複数の外部キー属性


注:
図 9 では、頭字語「PK」を使用して基本キーを表し、「FK」を使用して外部キーを表しています。また、これらのビジネス・オブジェクトは、基本キー属性に ObjectId という名前を付けることにより、汎用ビジネス・オブジェクト用の命名規則に従っています。アプリケーション固有のビジネス・オブジェクトでは、一般的には、アプリケーション内の対応するフィールドまたは列に名前を付けてから、属性に名前を付けるのが望ましいといえます。

InterChange Server Express を使用して、別のオブジェクトへの外部キー参照を格納する親オブジェクトの例として、付属の汎用 Order ビジネス・オブジェクトを調べることができます。このビジネス・オブジェクトには、トップレベルの汎用 Customer ビジネス・オブジェクトを参照先とする CustomerId 属性が含まれています。Order ビジネス・オブジェクトの図については、図 11 を参照してください。

子オブジェクトへの外部キーの格納

もう 1 つの選択肢として、関係を確立するための外部キーを子に格納する方法があります。この場合、1 対多の関係を表します。つまり、複数の子が同じ親を参照できるということです。ただし、親と子の間の関係は子の内部で定義されているため、親のみを調べた場合には、この関係が存在することがわかりません。その理由から、親ビジネス・オブジェクトによって統合のフローが起動された場合に、それらの子を検索できないため、システム全体を移動する親ビジネス・オブジェクトには、それらの子への参照は含まれません。

図 10 では、外部キー属性は、親ビジネス・オブジェクトではなく、それぞれの子ビジネス・オブジェクトに格納されています。この構造の場合、複数の子が同じ親と意味的に関係を持つことが可能です。ただし、この場合、親ビジネス・オブジェクトが子ビジネス・オブジェクトへの参照を格納した属性を持たないため、親とその子との関係を識別したり、指定された親に対して関連するすべての子を検出することはできません。

図 10. 多対 1: 外部キーが複数の子ビジネスに格納されている場合


注:
図 10 では、頭字語「PK」を使用して基本キーを表し、「FK」を使用して外部キーを表しています。

子オブジェクト配列への外部キーの格納

1 対多の関係を表す場合、その関係を実際に確立するための外部キーを子ビジネス・オブジェクト内の単純属性に格納します。これらの子の配列は、親ビジネス・オブジェクト内に構造的に格納されます。言い換えると、親には子ビジネス・オブジェクトの配列が格納され、これらの子ビジネス・オブジェクトの配列にはそれぞれ、別のトップレベルのビジネス・オブジェクトへの外部キー参照が格納されるということです。さらに、子ビジネス・オブジェクト配列内にある同じ子ビジネス・オブジェクトが、複数の親ビジネス・オブジェクトから参照できることから、多対多の関係が実装されているといえます。

注:
InterChange Server Express では、このタイプの親子関係の例として考察できるビジネス・オブジェクトがいくつか存在します。このオプションの例としては、汎用的な Order および ContactRef ビジネス・オブジェクトがあります。Order オブジェクトの OrderContactRef 属性には、汎用的な ContactRef ビジネス・オブジェクトの配列が格納されています。各 ContactRef ビジネス・オブジェクトは、トップレベルの汎用 Contact ビジネス・オブジェクトへの参照を保持した ContactId 属性を格納しています。

図 11 では、Order ビジネス・オブジェクトは、1 つの Customer ビジネス・オブジェクトへの参照を格納しており、同時に、構造的に ContactRef ビジネス・オブジェクトの配列を格納しています。各 ContactRef ビジネス・オブジェクトは、1 つの Contact ビジネス・オブジェクトへの参照を格納しています。

図 11. ビジネス・オブジェクトが外部キーが格納された子ビジネス・オブジェクトを格納している場合


注:
図 11 では、頭字語「PK」を使用して基本キーを表し、「FK」を使用して外部キーを表しています。

ビジネス・オブジェクト・ツリーへの外部キーの格納

この設計では、関係を確立するための外部キーが、同じタイプの別のビジネス・オブジェクトを親とする「子」ビジネス・オブジェクトに格納されます。InterChange Server Express では、この設計の例として汎用 InstalledProduct ビジネス・オブジェクトを考察できます。このビジネス・オブジェクトの ParentId 属性には、現在のビジネス・オブジェクトの直接の親である別の InstalledProduct ビジネス・オブジェクトへの参照を格納できます。

図 12 では、1 つの InstalledProduct ビジネス・オブジェクトの ParentId 属性に、その直接の親 InstalledProduct ビジネス・オブジェクトの基本キー (ObjectId) 属性への参照が格納されています。階層のヘッドにあたるのは、値が格納されていない ParentId 属性を持つビジネス・オブジェクトです。

図 12. ビジネス・オブジェクトが同じタイプの親ビジネス・オブジェクトに外部キーを格納している場合


注:
図 12 では、頭字語 「PK」を使用して基本キーを表し、「FK」を使用して外部キーを表しています。

InstalledProduct ビジネス・オブジェクトにはその親ビジネス・オブジェクトへの参照を格納できるため、ビジネス・インテグレーション・システムでは、巨大な階層の一部となっているインストール済み製品を同期化できます。ビジネス・インテグレーション・システムでは、インストール済み製品の複雑な階層のコンポーネントを、個々の InstalledProduct ビジネス・オブジェクトとして管理できます。InterChange Server Express では、詳しくは「InstalledProductSync」のコラボレーション・テンプレートの資料を参照できます。

関連エンティティーを表すフラット・ビジネス・オブジェクト

複数のアプリケーション・エンティティーを結合して 1 つのビジネス・オブジェクトにする機能をアプリケーション・インターフェースが持っていると、基本エンティティーと関連エンティティーを参照する属性を格納したフラット・ビジネス・オブジェクトを定義できる場合があります。エンティティー間の関係が 1 対 1 の関係の場合、つまり基本エンティティーの 1 つのインスタンスが各関連エンティティーの 1 つのインスタンスに対応している場合、複数のエンティティーの属性を 1 つのビジネス・オブジェクトに組み込むことができます。

このタイプのアプリケーション固有のビジネス・オブジェクトを設計する場合、状況によっては、コネクターがデータを正しく検出して処理できるよう、アプリケーション固有の情報を使用して、アプリケーション内での属性データの位置を指定する必要があります。

図 13 に、2 つのエンティティー内のデータを表すフラット WebSphere Business Integration システムのビジネス・オブジェクトの例を示します。2 つのエンティティーのうち、一方は住所データを格納した表で、もう一方は州または地域および国の省略語の検索データを格納した表です。

図 13. 2 つのエンティティーを表すフラット・ビジネス・オブジェクト


この例では、アプリケーション固有の情報を使用して、エンティティー間の外部キー関係を確立します。この場合、コネクターは 1 つの表を表す属性内の値から検索を実行し、別の表を表す属性の値を提供します。このデータを検出するため、コネクターは表の読み取りを 2 回行います。

フラット・ビジネス・オブジェクトは、複数のアプリケーション・エンティティーからの情報や、複数のアプリケーション・エンティティーに格納されている情報をカプセル化することができます。しかし、アプリケーション相互の統合の問題のために、フラット・ビジネス・オブジェクトでは表せない、より複雑な統合ロジックおよびデータ構造が必要とされることもあります。より複雑なアプリケーション・エンティティーおよび統合要件を扱えるように、WebSphere では階層型ビジネス・オブジェクトが提供されています。

複数エンティティーを設計する上での考慮事項

このセクションでは、複数エンティティーに対応したビジネス・オブジェクトを設計する際の考慮事項として、以下を取り上げます。

関係におけるデータの所有権

ビジネス・オブジェクトを複数のエンティティーが表現するように設計にすると、データの所有権に以下のような影響が及びます。

この違いは、複数のビジネス・オブジェクトによって共有されるエンティティーのデータ整合性を考慮する場合に重要です。

ここで例として、ある顧客とある連絡先が同じ住所を共有している場合を考えます。Customer ビジネス・オブジェクトと Contact ビジネス・オブジェクトが、該当する Address ビジネス・オブジェクトそのものを含める (構造的な関係) のではなく、該当する Address ビジネス・オブジェクトへの参照を格納している (意味的な関係) 場合、この Address の変更は、Customer や Contact の変更と無関係に実行できます。

一方、Customer ビジネス・オブジェクトおよび Contact ビジネス・オブジェクトがそれぞれ Address ビジネス・オブジェクト自体を含めている場合は、Customer が Address を変更すると、Contact による変更が上書きされる可能性があります。この場合、2 つの異なるコラボレーション・オブジェクト (CustomerSync および ContactSync) が同じ住所データを同時に更新する可能性があるため、データの不整合が発生するおそれがあります。

Customer および Contact が Address ビジネス・オブジェクトと構造的な関係ではなく意味的な関係を持っている場合は、第 3 のインターフェースのみが Address データを変更できるように制限できます。例えば、Contact および Customer ビジネス・オブジェクトごとにそれぞれ 1 つずつインターフェースを持つことができます。その場合、それらのインターフェースの両方が、Address ビジネス・オブジェクトの管理を第 3 のインターフェースに委任できます。InterChange Server Express で、この委任を行うには、CustomerSync および ContactSync コラボレーション・オブジェクトに直接変更を行わせるのではなく、ラッパー・コラボレーション・オブジェクトを介して AddressSync を呼び出させます。InterChange Server Express の統合シナリオでのデータ整合性維持を目的としたビジネス・オブジェクトの設計について詳しくは、「コラボレーション開発ガイド」の『並列実行の設計』を参照してください。

図 14 に、子ビジネス・オブジェクトとの関係を意味的に定義する場合と構造的に定義する場合の違いを示します。

図 14. 意味的な関係と構造的な関係の比較


上の図では、子のデータとの関係が 2 種類存在しています。

意味的関係と構造的関係からの選択

表 3 に示すように、1 対 1 の関係および 1 対多の関係は、構造的関係と意味的関係のどちらでも表現できます。これらの構造的表現および意味的表現を 表 5 にまとめます。

表 5. 1 対 1 の関係および 1 対多の関係の表現
関係のタイプ 構造的表現 意味的表現
1 対 1 (単一カーディナリティー) 親ビジネス・オブジェクトの属性は、1 つの子ビジネス・オブジェクトを表す。 親ビジネス・オブジェクト内の属性は単純であり、この属性には 1 つの子ビジネス・オブジェクトを参照する外部キーが含まれている。
1 対多 (複数カーディナリティー) 親ビジネス・オブジェクト内の属性が、1 つの子ビジネス・オブジェクトの配列を表す。 複数の子ビジネス・オブジェクトにそれぞれ、親の基本キーを格納する外部キー属性が含まれている。

図 9 および図 10 は、単一カーディナリティーおよび複数カーディナリティーの関係が意味的に定義されているビジネス・オブジェクトを示したものです。これらのビジネス・オブジェクトは、データベース内に格納されたデータを表すと考えることもできます。このようなデータを表すビジネス・オブジェクト間の関係は、意味的かつ構造的に定義することができます。この種のデータの場合、親子関係は、同じ 2 つのビジネス・オブジェクト間で、意味的かつ構造的に定義することができます。

意味的関係の選択

意味的関係を実装するには、その基礎となるアプリケーションによって外部キーがサポートされていなければなりません。例えば、あるビジネス・オブジェクトがデータベース・データを表す場合、このビジネス・オブジェクトは、エンティティー間の関係を意味的かつ構造的に確立することができます。このようなビジネス・オブジェクトは冗長な設計となります。言い換えると、これらのビジネス・オブジェクトを処理するコンポーネントは、親を介して子を見つけることができ、同時に個々の子を介して親を見つけることができます。

ここで例として、購入注文を表す表を持つアプリケーションを考えます。この表は、外部キーにより、1 つの購入注文に対応する明細を格納した表に関係付けられています。この明細表内の複数の行が、購入注文表内の 1 つの行を参照します。図 15 に、これらの表を示します。

図 15. 1 対多の意味的関係を持つアプリケーション表の例


図 16 は、ビジネス・オブジェクトがこれらの表に対応している例を示したものです。この図は、トップレベルの PurchaseOrder ビジネス・オブジェクトと 3 つの子 LineItem ビジネス・オブジェクトが存在しています。

図 16. 複数カーディナリティーの意味的および構造的関係を持つビジネス・オブジェクトの例


図の PurchaseOrder ビジネス・オブジェクトは、その子ビジネス・オブジェクト LineItem に対して意味的かつ構造的な関係を持ちます。それぞれの子の PurchaseOrderId 属性は、親からその子への、外部キーによる意味的リンクを作成します。親の LineItem 属性は、カーディナリティー n で定義され、親から子への構造的リンクを作成します。

注:
外部キーを子に格納させているビジネス・オブジェクトは、IBM からは提供されていません。上記の例は、親と子のデータをリンクする方法の違いを示すために、参考として紹介しました。

構造的関係の選択

基礎となるアプリケーションによって外部キーがサポートされていない場合は、構造的関係を実装する必要があると考えられます。例えば、1 つの XML 文書を表す DTD は外部キー情報をサポートしません。その理由から、1 対 1 の関係または 1 対多の関係をすべて構造的に定義する必要があります。次の図に、1 つの Order アプリケーション・エンティティーに対応する要素を格納した Order DTD を示します。この DTD は単一カーディナリティーおよび複数カーディナリティーの関係を表しています。

<!--Order -->
 <!-- Element Declarations -->
 <!ELEMENT Order (Unit+)>
 <!ELEMENT Unit (PartNumber?, Quantity, Price, Accessory*)>
 <!ELEMENT PartNumber (#PCDATA)>
 <!ELEMENT Quantity (#PCDATA)>
 <!ELEMENT Price (#PCDATA)>
 <!ELEMENT Accessory (Quantity, Type)>
 <!ATTLIST Accessory
 Name CDATA >
 <!ELEMENT Type (#PCDATA)>
 

図 17 に、Order DTD を表すビジネス・オブジェクトを示します。トップレベルのビジネス・オブジェクトは単一カーディナリティーの関係を持つ Order ビジネス・オブジェクトを格納し、この Order オブジェクトは複数カーディナリティーの関係を持つ Unit 子ビジネス・オブジェクトを格納しています。さらに、この子 Unit オブジェクトは、複数カーディナリティーの関係を持つ Accessory ビジネス・オブジェクトを格納しています。

図 17. 単一カーディナリティーおよび複数カーディナリティーの構造的な関係


図 17 に示したビジネス・オブジェクトの関係は構造的に定義されています。つまり、それぞれの親ビジネス・オブジェクトには、子と同じタイプで関係が containment として指定されている属性が格納されています。

重要:
XML データ・ハンドラーの場合、DTD を表すトップレベルのビジネス・オブジェクトに関して固有の要件があります。要件については、「データ・ハンドラー・ガイド」を参照してください。

Copyright IBM Corp. 2004