JDBC データビューを使用すると、LDAP クライアントアプリケーションがリレーショナルデータベースにアクセスできるようになります。JDBC データビューの機能方法については、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の「JDBC Data Views」を参照してください。
JDBC データビューの作成と設定の方法については、次の手順を参照してください。
DSCC を使用してこのタスクを実行することはできません。次の手順に示すように、コマンド行を使用します。
リレーショナルデータベース用の JDBC データソースを作成します。
$ dpconf create-jdbc-data-source -h host -p port -b db-name -B db-url -J driver-url \ [-J driver-url]... -S driver-class source-name |
現在、各 JDBC データビューでサポートされる JDBC データソースは 1 つだけです。つまり、JDBC データソースで負荷分散することはできません。複数の JDBC データソースにアクセスするには、各データソース用にデータビューを作成し、それらをすべて結合データビューに結合します。
JDBC データソースを作成する場合は、次のプロパティーを設定します。
リレーショナルデータベースの名前。たとえば、payrolldb などです。
データベースへの URL。形式は、jdbc: vendor:driver://dbhost: dbport です。
db-url には、データベース名が含まれていないため、JDBC データベース URL としては完全ではありません。(データベース名は、db-name プロパティーで指定されます。)
db-url の末尾には、MySQL、DB2、および Derby データベースの場合は /、Oracle データベースの場合は : を付けてください。
JDBC ドライバクラス。たとえば、org.hsqldb.jdbcDriver などです。
JDBC ドライバへのパス。たとえば、file:/// path/to/hsqldb/lib/hsqldb.jar などです。
driver-url プロパティーは複数値プロパティーです。そのため、driver-url で JDBC ドライバ用の複数の JAR ファイルを設定することにより、各種のプラットフォームで JDBC ソースに接続できます。
JDBC データソースプールを作成します。
$ dpconf create-jdbc-data-source-pool -h host -p port pool-name |
JDBC データソースを JDBC データソースプールに接続します。
$ dpconf attach-jdbc-data-source -h host -p port pool-name source-name |
JDBC データビューを作成します。
$ dpconf create-jdbc-data-view -h host -p port view-name pool-name suffix-DN |
(省略可能) データビューが正常に作成されたことを確認するために、JDBC データビューの一覧を表示します。
$ dpconf list-jdbc-data-views -h host -p port |
DSCC を使用してこのタスクを実行することはできません。次の手順に示すように、コマンド行を使用します。
JDBC データビューのプロパティーを表示します。
$ dpconf get-jdbc-data-view-prop -h host -p port view-name |
JDBC データビューのデフォルトプロパティーは次のとおりです。
alternate-search-base-dn : - attr-name-mappings : none base-dn : o=sql1 contains-shared-entries : - description : - distribution-algorithm : - dn-join-rule : - dn-mapping-attrs : none dn-mapping-source-base-dn : none excluded-subtrees : - filter-join-rule : - is-enabled : true is-read-only : false is-routable : true jdbc-data-source-pool : pool-name lexicographic-attrs : all lexicographic-lower-bound : none lexicographic-upper-bound : none non-viewable-attr : - non-writable-attr : - numeric-attrs : all numeric-default-data-view : false numeric-lower-bound : none numeric-upper-bound : none pattern-matching-base-object-search-filter : all pattern-matching-dn-regular-expression : all pattern-matching-one-level-search-filter : all pattern-matching-subtree-search-filter : all process-bind : - replication-role : master viewable-attr : all except non-viewable-attr writable-attr : all except non-writable-attr |
手順 1で一覧表示されるプロパティーの 1 つまたは複数を変更します。
$ dpconf set-jdbc-data-view-prop -h host -p port view-name property:value \ [property:value ... ] |
JDBC データビューを設定する場合、次のオブジェクトも設定する必要があります。
JDBC オブジェクトクラス。1 つまたは複数の JDBC テーブルを LDAP オブジェクトクラスにマップします。
JDBC テーブル。各リレーショナルデータベーステーブルに対して定義します。
JDBC 属性。JDBC テーブル内の指定された列の LDAP 属性を定義します。
リレーショナルデータベースの各テーブルの JDBC テーブルを作成します。
% dpconf create-jdbc-table jdbc-table-name db-table |
db-table の名前は大文字と小文字を区別します。リレーショナルデータベースで使用したのと同じ文字 (大文字または小文字) を使用してください。異なる文字を使用すると、そのテーブルをターゲットとする操作は失敗する場合があります。
各リレーショナルデータベーステーブル内で各列の JDBC 属性を作成します。
% dpconf add-jdbc-attr table-name attr-name sql-column |
JDBC 属性を作成すると、テーブル列が LDAP 属性にマップされます。
(省略可能) リレーショナルデータベース内の列が大文字と小文字を区別する場合、JDBC 属性の LDAP 構文を変更します。
% dpconf set-jdbc-attr-prop table-name attr-name ldap-syntax:ces |
ldap-syntax の値は、デフォルトで cis です。これは、jdbc-attr が大文字と小文字を区別しないことを意味します。リレーショナルデータベースが大文字と小文字を区別する場合、値を ces に変更します。
Oracle や DB2 など、特定のリレーショナルデータベースはデフォルトで大文字と小文字を区別します。LDAP はデフォルトで大文字と小文字を区別しません。Directory Proxy Server はリレーショナルデータベーステーブルの列が大文字と小文字を区別することを検出すると、フィルタ内の対応する属性の ldapsearch クエリーが UPPER 関数を使用して SQL クエリーに変換されます。
たとえば、クエリー ldapsearch -b "dc=mysuffix" "(attr=abc)" は次の SQL クエリーに変換されます。
SELECT * FROM mytable WHERE (UPPER(attr)='ABC') |
デフォルトで、この種類のクエリーはインデックスが生成されません。このため、このようなクエリーは、パフォーマンスに大きな影響を与える可能性があります。
次の 2 つの方法でパフォーマンスへの影響を緩和できます。
jdbc-attr の ldap-syntax プロパティーを ces に設定する。
LDAP フィルタで使用されている可能性のある各 jdbc-attr の UPPER 関数でインデックスを作成する。
リレーショナルデータベースが大文字と小文字を区別しない場合は、ldap-syntax をデフォルト値の cis に設定します。ldap-syntax:ces は、大文字と小文字を区別しないデータベースではサポートされません。
LDAP リレーショナルデータベーステーブルの JDBC オブジェクトクラスを作成します。
% dpconf create-jdbc-object-class view-name objectclass primary-table \ [secondary-table... ] DN-pattern |
JDBC オブジェクトクラスを作成すると、原則的にこれらのテーブルが関連付けられる LDAP オブジェクトクラスが指定されます。JDBC オブジェクトクラスは、一次テーブルと二次テーブルが存在する場合、これらも指定します。
JDBC オブジェクトクラスを作成する場合、DN パターンを指定します。DN パターンは、エントリの DN の構築にどの属性を使用するかを示します。たとえば、DN パターンを uid として指定すると、エントリの DN は、データビューの属性 uid とビューベースを使用して構築されます。たとえば、uid=bjensen,ou=people,dc=example,dc=com のようになります。DN パターンは複数の属性で構成されることがあります。その場合は、属性を , (カンマ) で区切るようにしてください。たとえば、DN パターンを uid,country として指定した場合、データビューによって返されるエントリの DN は uid=bjensen,country=America,ou=people,dc=example,dc=com となります。
JDBC オブジェクトクラスの DN パターンに定義されたサブツリーコンポーネントにはすべて、それらのサブツリーコンポーネント用に定義された JDBC オブジェクトクラスを設定するようにしてください。たとえば、JDBC オブジェクトクラスに uid,ou という DN パターンがある場合、JDBC オブジェクトクラス定義に DN パターン ou を設定するようにしてください。これは、Directory Proxy Server で正しい構造の DIT を構築するために必要です。この設定を行わないと、ou=xxx,base-DN のような値を持つサブツリーが検索結果で返されません。
二次テーブルが存在する場合、一次テーブルと二次テーブル間の結合ルールを定義します。
% dpconf set-jdbc-table-prop secondary-table-name filter-join-rule:join-rule |
結合ルールは二次テーブルで定義され、そのテーブルからのデータが一次テーブルのデータにリンクされる方法を決定します。オブジェクトクラスの一次テーブルと二次テーブル間の関係の定義方法は重要です。詳細については、「JDBC テーブル間の関係の定義」を参照してください。
JDBC オブジェクトクラスのスーパークラスを指定します。
% dpconf set-jdbc-object-class-prop view-name objectclass super-class:value |
スーパークラスは、JDBC オブジェクトクラスが継承した LDAP オブジェクトクラスを示します。
もっとも単純な場合、JDBC オブジェクトクラスにはテーブルが 1 つ (一次) しか含まれません。二次テーブルはなく、このため、テーブル間の関係を定義する必要はありません。
オブジェクトクラスに複数のテーブルが含まれる場合、これらのテーブル間の関係を明確に定義します。テーブル間の関係は、常に二次テーブル上で定義されます。二次テーブルの次のプロパティーによって、これらの関係を定義できます。
is-single-row-table は、テーブルで LDAP エントリに一致する行が 1 つだけであると指定します。
contains-shared-entries は、二次テーブルの行が一次テーブルの複数の行に使用されることを指定します。
filter-join-rule は、エントリが一次テーブルに基づいて二次テーブルから取得される方法を示します。
次の例は、最初の 2 つのプロパティーの値に基づいて、フィルタ結合ルールがどのように定義されるかを示しています。以降の例では、オブジェクトクラスに一次テーブルと二次テーブルが 1 つずつあることを前提としています。
それぞれプロパティーのデフォルト値が指定されています。この場合、一次テーブルと二次テーブルの関係は、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}" |
複数の二次テーブルの場合は、二次テーブルごとに filter-join-rule を設定する必要があります。複数の二次テーブルで filter-join-rule を設定する方法の詳細については、手順 11 を参照してください。
この設定の場合、LDAP 操作で次の動作が行われます。
従業員エントリの追加。従業員エントリのマネージャーがテーブルに存在しない場合、新しい行が作成されます。マネージャーが存在する場合は、既存の行が使用されます。
エントリ内の「manager」属性の値の置き換え。MANAGER.NAME 行の値が変更されます。
従業員エントリの削除。マネージャーエントリが共有されているため、二次テーブルの行は削除されません。
エントリから「manager」 属性の削除。二次テーブルの行が削除され、外部キー (EMPLOYEE.FK_MANAGER_ID) が NULL に設定されます。
この場合、一次テーブルと二次テーブルの関係は、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 にポイントさせることでも同等の設定が可能です。
この場合、一次テーブルと二次テーブルの関係は、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} |
これは、現在 Directory Proxy Server でサポートされていません。