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

多くの場合、コネクターはすべての個別ビジネス・オブジェクトが 1 つ のデータベース表またはビューによって表され、オブジェクト内部のそれ ぞれの単純属性 (つまり、String または Integer または Date などの単一値を表す属性) はそのテーブルまたはビュー内の列によって表さ れると想定します。そのため、同一の個々のビジネス・オブジェクト内の属性は、異なるデータベース表に格納することはできません。ただし、次の状態は可能です。

注:
ビジネス・オブジェクトがストアード・プロシージャーを基にしている場合には、それぞれの基本属性 (特殊な SP 属性を除く) は、アプリケーション固有の情報を持つ場合と、持たない場合があります。詳細については、ストアード・プロシージャーを参照してください。

ビジネス・オブジェクトには、フラットなものと階層のものがあります。フラットなビジネス・オブジェクトの属性はすべて、単純で、単一値を表します。

階層ビジネス・オブジェクトには、1 つの子ビジネス・オブジェクト、子ビジネス・オブジェクトの配列、またはその両方の組み合わせを表す属性が あります。そのため、それぞれの子ビジネス・オブジェクトには、1 つの子ビジネス・オブジェクト、またはビジネス・オブジェクトの配列など、いろいろと含めることができます。単一カーディナリティー関係は、親ビジネス・オブジェクト内の属性が単一の子ビジネス・オブジェクトを表すときに発生します。このケースでは、属性は子ビジネス・オブジェクトと同じタイプのものです。

複数カーディナリティー関係は、親ビジネス・オブジェクト内の属性が子ビジネス・オブジェクトの配列を表すときに発生します。この場合、属性は、子ビジネス・オブジェクトと同じタイプの配列です。

注:
階層ビジネス・オブジェクトという用語は、その任意のレベルに格納されているすべての子ビジネス・オブジェクトを含めた、ビジネス・オブジェクトの全体のことを表します。個別ビジネス・オブジェクトという用語は、それが格納している、あるいはそれが格納されている子ビジネス・オブジェクトにはかかわりなく、単一のビジネス・オブジェクトのことを表します。トップレベルのビジネス・オブジェクトという用語は、階層のトップレベルにあって、それ自身は親ビジネス・オブジェクトを持たない個別ビジネス・オブジェクトのことを表します。

コネクターは、ビジネス・オブジェクト間の次の関係をサポートします。

各タイプのカーディナリティーで、親ビジネス・オブジェクトと子ビジネス・オブジェクト間の関係は、その関係を格納するビジネス・オブジェクトのキー属性の、アプリケーション固有の情報によって記述されます。

単一カーディナリティー関係

通常、単一カーディナリティーの子ビジネス・オブジェクトが含まれているビジネス・オブジェクトには、関係を表す属性が少なくとも 2 つあります。1 つの属性のタイプは、子のタイプと同じです。もう一方の属性は、子の基本キーが親の外部キーとして含まれている、基本属性です。親には、子に存在する基本キー属性と同数の外部キーがあります。

上記の関係を設定する外部キーは親に格納されます。したがって、それぞれの親には、指定のタイプの単一カーディナリティー子が 1 つだけ含まれています。

図 2 に、標準的な単一カーディナリティー関係を示します。この例で、fk1 は子の基本キーが含まれている 基本属性であり、child[1] は子ビジネス・オブジェクトを表す属性です。

図 2. 典型的な単一カーディナリティー関係

単一カーディナリティー関係および所有権のないデータ

通常、それぞれの親ビジネス・オブジェクトは、それに含まれている子ビジネス・オブジェクトにデータを所有します。例えば、それぞれの Customer ビジネス・オブジェクトに単一の Address ビジネス・オブジェクトが含まれている場合に、新規のカスタマーが作成されると、カスタマーおよびアドレスの両方のテーブルに新規の行が挿入されます。この新規のアドレスは、新規のカスタマーに固有のものです。同様に、カスタマー・テーブルからカスタマーを削除すると、そのカスタマーのアドレスもアドレス・テーブルから削除されます。

ただし、複数の階層ビジネス・オブジェクトに同じデータが含まれていて、いずれのビジネス・オブジェクトもそのデータを所有しないという状態があります。例えば、ある Address ビジネス・オブジェクトに、単一カーディナリティーを持つ StateProvince 参照表を表す StateProvince[1] 属性があると想定します。ルックアップ・テーブルはほとんど更新されず、アドレス・データとは別個に保守されるため、アドレス・データを作成または変更しても、参照表のデータには影響しません。コネクターは、既存の都道府県名を検索するか、または失敗するかのいずれかです。参照表内のデータを 追加または変更することはありません。

同一の単一カーディナリティーの子ビジネス・オブジェクトが複数のビジネス・オブジェクトに含まれているときは、それぞれの親ビジネス・オブジェクト内の外部キー属性はその関係を NO_OWNERSHIP として 指定する必要があります。ビジネス・プロセスが Create、Delete、または Update 要求を使ってコネクターに階層ビジネス・オブジェクトを送信するとき、コネクターは所有権を持たないで含まれている単一カーディナリティーの子を無視します。コネクターは、これらのビジネス・オブジェクトには検索のみを行います。コネクターがそのような単一カーディナリティーのビジネス・オブジェクトの 検索に失敗した場合には、エラーを戻し、処理を停止します。

所有権を持たない関係を指定する方法の詳細については、単一カーディナリティーの子ビジネス・オブジェクトを表す属性を参照して ください。外部キー関係の指定の詳細については、属性の外部キーの指定を参照してください。

非正規化データおよび所有権のないデータ

所有権を持たない格納は、静的参照表の使用を簡素化するほかに、もう 1 つの能力、すなわち、正規化および非正規化データの同期化を提供します。

正規化データから非正規化データへの同期化

関係を NO_OWNERSHIP として指定すると、正規化アプリケーションから非正規化アプリケーションに同期化するときに データを作成または変更することができます。例えば、正規化ソース・アプリケーションで 2 つのテーブル A および B にデータが 格納されていると想定します。さらに、非正規化宛先アプリケーションで すべてのデータが単一のテーブルに格納されて、それぞれのエンティティー A には B データが冗長的に格納されていると想定します。

上記の例で、テーブル B データの変更をソース・アプリケーションから宛先アプリケーションに同期化するには、テーブル B データが変更されるたびにテーブル A イベントを起動する必要があります。さらに、テーブル B データはテーブル A に冗長的に格納されているため、テーブル A にあって、テーブル B からの変更データを含むそれぞれの行ごとに、ビジネス・オブジェクトを送信する必要があります。

非正規化データから正規化データへの同期化

データを非正規化ソース・アプリケーションから正規化宛先アプリケーションに同期化するときに、コネクターは、正規化アプリケーションで所有権を持たずに含まれているデータを作成、削除、または 更新しません。

データを正規化ソース・アプリケーションに同期化するときに、コネクターは、所有権を持たずに含まれているすべての単一カーディナリティーの子を 無視します。そのような子データを作成、除去、または変更するには、データを手動で処理する必要があります。

複数カーディナリティー関係

通常、子ビジネス・オブジェクトの配列が含まれているビジネス・オブジェクトには、関係を表す属性は 1 つだけあります。属性のタイプは、子ビジネス・オブジェクトと同じタイプの配列です。親に複数の子を含めさせるため、関係を設定する外部キーは、それぞれの子に保管されます。

したがって、それぞれの子には、親の基本キーが外部キーとして含まれている基本属性が 少なくとも 1 つあります。子には、親に存在する基本キー属性と同数の外部キーがあります。

上記の関係を設定する外部キーは子に格納されます。したがって、それぞれの親には、ゼロ以上の子が含まれています。

図 3 に、複数カーディナリティー関係を示します。この例で、parentId は親の基本キーが含まれている 基本属性であり、child[n] は子ビジネス・オブジェクトの配列を表す属性です。

図 3. 複数カーディナリティー・ビジネス・オブジェクト関係

関係を子に格納する単一カーディナリティー関係

一部のアプリケーションでは、関係の格納が親にではなく子に行われるように、単一の子エンティティーを格納します。すなわち、親の基本キーに格納された値と同一の値を持つ外部キーが 子に含まれます。

図 4 に、上記のタイプの単一カーディナリティー関係を示します。

図 4. 関係を子に格納している単一のカーディナリティー関係

子データがその親とは別個に存在せず、その親を介してのみアクセスできるとき、アプリケーションはこのタイプの単一カーディナリティー関係を使用します。そのような子データは、複数の親によって所有されることはありません。そのため、子およびその外部キー値が作成できるようになる前に、親およびその基本キー値が存在することが要求されます。

上記のようなアプリケーションに対応するため、コネクターは、単一カーディナリティーを持つ子が含まれる階層ビジネス・オブジェクトもサポートしますが、関係は、親にではなく、子に格納します。

単一カーディナリティーが上記の特殊な方法で親ビジネス・オブジェクトに含まれることを指定するには、子が含まれる属性のアプリケーション固有の情報を指定するときに、CONTAINMENT パラメーターを 組み込まないでください。詳細については、単一カーディナリティーの子ビジネス・オブジェクトを表す属性を参照してください。

ラッパー・オブジェクト

ラッパー・オブジェクトは、どのデータベース表またはビュ ーにも対応しないトップレベルのビジネス・オブジェクトです。ラッパー・オブジェクトは、true の値 を持つトップレベル・ビジネス・オブジェクト・プロパティー WRAPPER によっ て示されます。ラッパー・オブジェクトは関連のない子のコンテナーとして使用される ダミーの親です。ラッパー・オブジェクトの処理中、コネクターはトップレベルのビジネス・オブ ジェクトを無視し、子のみを処理します。ラッパー・オブジェクトには N のカーディナリティーを持つエンティティーまたは N-1 のカーデ ィナリティーを持つエンティティー、あるいはその両方を含めることができます。

N のカーディナリティーを持つエンティティーは、最低でも 1 つの固有属性が 基本キーとしてマークされ、最低でも 1 つの属性が外部キーとしてマークされ ている必要があります。この外部キーは、次に基本キーとしてラッパー・オブジェクトに追 加されます。エンティティーの外部キーは、ここで追加されたラッパー・オブジェクトの基 本キーを参照します。

N-1 のカーディナリティーを持つエンティティーの場合、基本キーは基本 キーとしてマークされると同時に、ラッパーの基本キーを参照する外部キー (N-1 のエンティティーの基本キーと同じ) としてマークされる必要があります。

Copyright IBM Corp. 2004, 2005