JDBC テーブル間の関係の定義

もっとも単純な場合、JDBC オブジェクトクラスにはテーブルが 1 つ (一次) しか含まれません。二次テーブルはなく、このため、テーブル間の関係を定義する必要はありません。

オブジェクトクラスに複数のテーブルが含まれる場合、これらのテーブル間の関係を明確に定義します。テーブル間の関係は、常に二次テーブル上で定義されます。二次テーブルの次のプロパティーによって、これらの関係を定義できます。

• is-single-row-table は、テーブルで LDAP エントリに一致する行が 1 つだけであると指定します。

• contains-shared-entries は、二次テーブルの行が一次テーブルの複数の行に使用されることを指定します。

• filter-join-rule は、エントリが一次テーブルに基づいて二次テーブルから取得される方法を示します。

次の例は、最初の 2 つのプロパティーの値に基づいて、フィルタ結合ルールがどのように定義されるかを示しています。以降の例では、オブジェクトクラスに一次テーブルと二次テーブルが 1 つずつあることを前提としています。

例 23–1 is-single-row-table:true と contains-shared-entries:true

それぞれプロパティーのデフォルト値が指定されています。この場合、一次テーブルと二次テーブルの関係は、n->1 です。つまり、一次テーブルの n 行は二次テーブルの共有行の 1 つを参照します。

リレーショナルデータベースで、外部キー (FK) が一次テーブルで定義され、二次テーブルの列をポイントします。

たとえば、複数の従業員が同じマネージャーを共有できる組織の場合を考えてみます。2 つのリレーショナルデータベーステーブルは、次の構造で定義されます。

primary table : EMPLOYEE [ID, NAME, FK_MANAGER_ID]
secondary table : MANAGER  [ID, NAME]

次のオブジェクトクラスと属性が定義されます。

object-class : employee
attr : name (from primary EMPLOYEE.NAME)
attr : manager (from secondary MANAGER.NAME)

次のフィルタ結合ルールが、二次テーブルで定義されます。

"${ID}=${EMPLOYEE.FK_MANAGER_ID}"

この設定の場合、LDAP 操作で次の動作が行われます。

• 従業員エントリの追加。従業員エントリのマネージャーがテーブルに存在しない場合、新しい行が作成されます。マネージャーが存在する場合は、既存の行が使用されます。

• エントリ内の「manager」属性の値の置き換え。MANAGER.NAME 行の値が変更されます。

• 従業員エントリの削除。マネージャーエントリが共有されているため、二次テーブルの行は削除されません。

• エントリから「manager」 属性の削除。二次テーブルの行が削除され、外部キー (EMPLOYEE.FK_MANAGER_ID) が NULL に設定されます。

例 23–2 is-single-row-table:true と contains-shared-entries:false

この場合、一次テーブルと二次テーブルの関係は、1->1 または 1<-1 です。つまり、一次テーブルの 1 行が二次テーブルの 1 行で参照されます。

リレーショナルデータベースで、外部キー (FK) が一次テーブルまたは二次テーブルで定義されることがあります。

たとえば、従業員の UID が 1 つのテーブルに保存され、従業員の姓が二次テーブルに保存されている組織の場合を考えてみます。2 つのリレーショナルデータベーステーブルは、次の構造で定義されます。

primary table : UID [ID, VALUE, FK_SN_ID]
secondary table : SN [ID, VALUE]

次のオブジェクトクラスと属性が定義されます。

object-class : employee
attr : uid (from primary UID.VALUE)
attr : sn (from secondary ID.VALUE)

次のフィルタ結合ルールが、二次テーブルで定義されます。

"${ID}=${UID.FK_SN_ID}"

別の方法として、二次テーブルに保存されている外部キー FK_UID_ID を UID.ID にポイントさせることでも同等の設定が可能です。

例 23–3 is-single-row-table:false と contains-shared-entries:false

この場合、一次テーブルと二次テーブルの関係は、1->n です。つまり、一次テーブルの 1 行が二次テーブルの n 行で参照されます。この例は、複数値属性の場合を示しています。複数値属性は、属性値ごとに 1 行で表され、それぞれ二次テーブル内の行のセットと対応します。

リレーショナルデータベースで、外部キーが二次テーブルで定義され、一次テーブルの列をポイントします。

たとえば、従業員が複数の電話番号を持っている可能性のある組織の場合を考えてみます。2 つのリレーショナルデータベーステーブルは、次の構造で定義されます。

primary table : EMPLOYEE [ID, NAME]
secondary table : PHONE [ID, VALUE, USER_ID]

次のオブジェクトクラスと属性が定義されます。

object-class : employee
attr : cn (from primary EMPLOYEE.NAME)
attr : telephoneNumber (from secondary PHONE.VALUE)

次のフィルタ結合ルールが、二次テーブルで定義されます。

"${USER_ID}=${EMPLOYEE.ID}"

例 23–4 is-single-row-table:false と contains-shared-entries:true

これは、現在 Directory Proxy Server でサポートされていません。