JDBCデータ・ビューの作成および構成

JDBCデータ・ビューを使用すると、リレーショナル・データベースからLDAPクライアント・アプリケーションにアクセスできます。JDBCデータ・ビューがどのように機能するかについては、Oracle Directory Server Enterprise EditionリファレンスのJDBCデータ・ビューに関する項を参照してください。

JDBCデータ・ビューを作成して構成する方法の詳細は、次の手順を参照してください。

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
```
現在、1つのJDBCデータソースのみが各JDBCデータ・ビューに対してサポートされています。つまり、JDBCデータソース間でロード・バランシングできません。複数のJDBCデータソースにアクセスするために、各データソースにデータ・ビューを作成し、これらを結合データ・ビューと結合できます。
JDBCデータソースを作成するとき、次のプロパティを設定する必要があります。
db-name

リレーショナル・データベースの名前(たとえば、payrolldb)。

db-url

データベースへのURL。形式は、jdbc:vendor:driver://dbhost:dbportです。
db-urlは、データベース名を含んでいないため、完全なJDBCデータベースURLではありません。(データベース名は、db-nameプロパティによって指定されます。)
MySQL、DB2およびDerbyの各データベースに対しては、最後にdb-urlに/を付け、Oracleデータベースに対しては、:を付ける必要があります。

driver-class

JDBCドライバ・クラス(たとえば、org.hsqldb.jdbcDriver)。

driver-url

JDBCドライバへのパス(たとえば、file:///path/to/hsqldb/lib/hsqldb.jar)。
driver-urlプロパティは複数値です。したがって、driver-urlは、JDBCドライバに対して複数のJARファイルをサポートし、異なるプラットフォーム上でJDBCソースに接続できるようにします。

DBベンダーが提供するJDBCドライバ以外のサード・パーティJDBCドライバを使用してRDBMSバックエンドに接続する場合、db-vendorプロパティを設定します。db-vendorプロパティの詳細は、「db-vendor(5dpconf)」を参照してください。

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
```

JDBCデータ・ビューを構成するには:

このタスクの実行には、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-attr-date-format                       :  yyyy-MM-dd
jdbc-attr-time-format                       :  hh:mm:ss
jdbc-attr-timestamp-format                  :  yyyy-MM-dd hh:mm:ss
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 ... ]

(オプション)ISO形式の他に、次のすべての形式で日付、時刻およびタイムスタンプの属性タイプのJDBC属性を設定できます。

日付と時刻を構成するコンポーネントを次にリストします。

Letter      Date or Time Component   Examples
G           Era designator           AD
y           Year                     1996; 96
M           Month in year            July; Jul; 07
w           Week in year             27
W           Week in month            2
D           Day in year              189
d           Day in month             10
F           Day of week in month     2
E           Day in week              Tuesday; Tue
a           Am/pm marker             PM
H           Hour in day (0-23)       0
k           Hour in day (1-24)       24
K           Hour in am/pm (0-11)     0
h           Hour in am/pm (1-12)     12
m           Minute in hour           30
s           Second in minute         55
S           Millisecond              978
z           Time zone                Pacific Standard Time; PST; GMT-08:00
Z           Time zone                -0800

次の例は、日時パターンが米国のロケールでどのように解釈されるかを示しています。指定された日時は、米国太平洋標準時タイムゾーンの2001-07-04 12:08:56ローカル時間です。

Date and Time Pattern                Result
"yyyy.MM.dd G 'at' HH:mm:ss z"       2001.07.04 AD at 12:08:56 PDT
"EEE, MMM d, ''yy"                   Wed, Jul 4, '01
"h:mm a"                             12:08 PM
"hh 'o''clock' a, zzzz"              12 o'clock PM, Pacific Daylight Time
"K:mm a, z"                          0:08 PM, PDT
"yyyyy.MMMMM.dd GGG hh:mm aaa"       02001.July.04 AD 12:08 PM
"EEE, d MMM yyyy HH:mm:ss Z"         Wed, 4 Jul 2001 12:08:56 -0700
"yyMMddHHmmssZ"                      010704120856-0700
"yyyy-MM-dd'T'HH:mm:ss.SSSZ"         2001-07-04T12:08:56.235-0700

JDBC表、属性およびオブジェクト・クラスを構成するには:

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になります。
データソースに重複エントリがあり、重複エントリが不要な場合、次のコマンドを使用して、perform-distinct-selectをtrueに設定します。
```
% dpconf set-jdbc-object-class-prop view-name objectclass perform-distinct-select:true
```
JDBCオブジェクト・クラスのDNパターンで定義されるすべてのサブツリー・コンポーネントでは、JDBCオブジェクト・クラスをコンポーネントに対して定義する必要があります。たとえば、JDBCオブジェクト・クラスにDNパターンuid,ouがある場合、DNパターンouを含むJDBCオブジェクト・クラス定義が必要です。これは、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表の関係の定義

最も単純な例では、JDBCオブジェクト・クラスには、1つ(プライマリ)の表のみが含まれています。セカンダリ表はなく、したがって、表間の関係を定義する必要はありません。

オブジェクト・クラスに複数の表が含まれている場合、これらの表の間の関係を明確に定義する必要があります。表間の関係は、常にセカンダリ表で定義します。セカンダリ表の次のプロパティを使用すると、これらの関係を定義できます。

is-single-row-tableは、LDAPエントリが表に一致する行を1つしか持たないことを指定します。
contains-shared-entriesは、セカンダリ表の行がプライマリ表の複数の行によって使用されることを指定します。
filter-join-ruleは、プライマリ表のなんらかの値に基づいてエントリがセカンダリ表からどのように取得されるかを示します。

次の例は、最初の2つのプロパティの値に基づいて、どのようにフィルタ結合ルールが定義されるかを示しています。これらの例は、オブジェクト・クラスが1つのプライマリ表と1つのセカンダリ表を持っていることを前提にしています。

例22-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}"

複数のセカンダリ表の場合、それぞれのセカンダリ表に対してfilter-join-ruleを構成する必要があります。複数のセカンダリ表に対するfilter-join-ruleの構成方法の詳細は、手順12を参照してください。

この構成では、LDAP操作で次の動作が発生します。

従業員のエントリの追加。従業員エントリの管理者が表に存在しない場合は、新しい行が作成されます。管理者が存在する場合は、既存の行が使用されます。
エントリの「管理者」属性の値の置換。行MANAGER.NAMEの値が変更されます。
従業員のエントリの削除。管理者エントリが共有されているため、セカンダリ表の行は削除されません。
「管理者」属性のエントリからの削除。セカンダリ表の行が削除され、外部キー(EMPLOYEE.FK_MANAGER_ID)がNULLに設定されます。

属性が削除されると、属性の値はNULLに設定されます。ただし、属性が表定義でNOT NULL属性に定義されている場合、削除できません。

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

この場合、プライマリ表とセカンダリ表の関係は、1->1または1<-1です。つまり、プライマリ表の1つの行がセカンダリ表の1つの行に参照されます。

リレーショナル・データベースで、外部キー(FK)は、プライマリ表またはセカンダリ表で定義されます。

たとえば、従業員のUIDがある表に格納されていて、従業員の名字が2番目の表に格納されている組織について考えてみます。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}

これは、dpconfコマンドを使用して、次のように使用できます。

dpconf set-jdbc-table-prop SN filter-join-rule:ID=\${UID.FK_SN_ID}

この構成は逆に、外部キーFK_UID_IDがセカンダリ表に格納され、UID.IDを指すようにすることもできます。

例22-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}

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

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

ナビゲーション・リンクをスキップ
印刷ビューの終了
	Oracle Directory Server Enterprise Edition管理ガイド 11gリリース1(11.1.1.5.0)