3.2.1 ディレクトリ情報ツリーの理解

ディレクトリ・サーバーは、ディレクトリ情報ツリー(DIT).と呼ばれる階層化されたネームスペース構造に情報を格納しますこのツリーの各ノードは、エントリと呼ばれます。Oracle Net Servicesは、ツリー構造とツリー内の特定のエントリを使用します。DITは、一般にドメイン・ネーム・システム(DNS)構造などの既存のドメイン構造や地理的および組織的な構造と整合されます。

次の図では、DNSドメイン・コンポーネントに従って構築されたDITを示します。

図3-2 DNSドメイン・コンポーネントDIT

図3-2の説明が続きます
「図3-2 DNSドメイン・コンポーネントDIT」の説明

次の図では、国、組織および組織単位に従って構築されたDITを示します。この構造は、一般にX.500 DITと呼ばれています。

図3-3 X.500 DIT

図3-3の説明が続きます
「図3-3 X.500 DIT」の説明

たとえば、図3-4について考えます。cn=salesエントリとcn=db1エントリは、ネットワーク・サービス名とデータベース・サービスをそれぞれ表します。cn=salesとcn=db1の下に存在する別のエントリには、接続記述子情報が含まれます。それらのエントリは、この図では示されていません。cn=salesエントリとcn=db1エントリによって、クライアントは、接続文字列のCONNECT username@salesおよびCONNECT username@db1を使用してデータベースに接続できます。

図3-4 データベース・サービスとDITのネット・サービス・エントリ

図3-4の説明が続きます
「図3-4 データベース・サービスとDITのネット・サービス・エントリ」の説明

各エントリは、識別名(DN).によって一意に識別されますDNは、ディレクトリ・サーバーの階層内に対象のエントリが存在する場所を正確に示します。db1のDNは、dn:cn=db1,cn=OracleContext,dc=jp,dc=example,dc=comです。salesのDNは、dn:cn=sales,cn=OracleContext,dc=jp,dc=example,dc=comです。DNの形式では、DITの最下位コンポーネントを左側に置いてから、DITを上方向に徐々に移動します。

各DNは、相対識別名(RDN)の列で構成されています。RDNは、cnなどの属性、db1またはsalesなどの値で構成されています。db1のRDNはcn=db1であり、salesのRDNはcn=salesです。属性とその値はエントリを一意に識別します。

親トピック: 集中管理用のディレクトリ・サーバーの使用

3.2.1.1 ドメイン・コンポーネント・ネームスペースの完全修飾名

ドメイン・コンポーネント・ネームスペースの場合、クライアントに定義されたデフォルトのディレクトリ・エントリは、必ず次のいずれかの形式にする必要があります。

dc[,dc][...]
ou,dc[,dc][...]

前述の構文で、[dc]はオプションのドメイン・コンポーネントを表し、[...]は追加のドメイン・コンポーネント・エントリを表し、ouは組織単位エントリを表します。

クライアントが接続識別子で使用する完全修飾名は、必ず次のいずれかの形式である必要があります。

cn.dc[.dc][...]
cn[.ou]@dc[.dc][...]

前述の構文で、[cn]はOracle Netエントリを表しています。

例3-1 組織単位を使用した完全修飾名の使用

cn=sales,cn=OracleContext,dc=jp,dc=example,dc=comというDNを持つデータベース・オブジェクトsalesのエントリが格納されているディレクトリ・サーバーについて考えます。この例では、クライアントにsales.jp.example.comの接続識別子が必要です。

cn=sales,cn=OracleContext,ou=mktg,dc=jp,dc=example,dc=comというDNを持つデータベース・オブジェクトsalesを含んでいる同様のエントリについて考えます。

ドメイン・コンポーネントは必ず組織単位から分離されている必要があるため、クライアントはcn.ou@dc.dc.dcという形式を使用する必要があります。このクライアントは、接続識別子をsales.mktg@jp.example.comにする必要があります。

図3-5に前述の例を示します。

図3-5 ドメイン・コンポーネント・ネームスペースの完全修飾名

図3-5の説明が続きます
「図3-5 ドメイン・コンポーネント・ネームスペースの完全修飾名」の説明

親トピック: ディレクトリ情報ツリーの理解

3.2.1.2 X.500ネームスペースの完全修飾名

X.500ネームスペースの場合、クライアントに定義されたデフォルトのディレクトリ・エントリは、必ず次のいずれかの形式にする必要があります。

[ou],o
[ou],o,c

前述の形式で、[ou]はオプションの組織単位名を表し、oは組織を表し、cは国を表します。

クライアントが接続識別子として使用する完全修飾名は、必ず次のいずれかの形式である必要があります。

cn[.ou].o
cn[.ou].o.c

前述の形式で、cnはOracle Netエントリを表しています。

たとえば、ディレクトリにcn=sales,cn=OracleContext,ou=mktg,o=example,c=jpというDNを持つデータベース・オブジェクトsalesが格納される場合、クライアントは接続識別子sales.mktg.example.jpを必要とします。図3-6にこの例を示します。

図3-6 X.500ネームスペースの完全修飾名

図3-6の説明が続きます
「図3-6 X.500ネームスペースの完全修飾名」の説明

親トピック: ディレクトリ情報ツリーの理解

3.2.1.3 エントリの相対名の使用

クライアントがデフォルトのレルムOracleコンテキストで構成されている場合、エントリを相対名で識別することが可能であり、サービスを共通名で参照できます。相対名を使用できるのは、クライアントのOracleホームでデフォルトのOracleコンテキストとして構成されたOracleコンテキスト内に、エントリがある場合です。

図3-7に示すように、DNがdn:cn=sales,cn=OracleContext,o=example,c=usで、salesというデータベースのエントリが格納されているディレクトリ・サーバーについて考えます。クライアントがcn=OracleContext,o=example,c=usというデフォルトのレルムOracleコンテキストで構成されている場合の接続識別子は、salesです。

図3-7 相対ネーミング

図3-7の説明が続きます
「図3-7 相対ネーミング」の説明

ノート:

JDBC OCIドライバは、完全修飾ネーミングと相対ネーミングの両方をサポートしています。JDBC Thinドライバは、完全なDNが使用される場合にのみ、完全修飾ネーミングをサポートします。

関連トピック

親トピック: ディレクトリ情報ツリーの理解

3.2.1.4 エントリの完全修飾名の使用

図3-7と同じディレクトリ構造について考えます(ただし、クライアントのOracleホームは、cn=OracleContext,o=example,c=jpというデフォルトのレルムOracleコンテキストで構成されています)。

クライアントは、ディレクトリ・サーバー内のsalesの位置とは一致しないデフォルトのOracleコンテキストで構成されているため、salesを使用する接続文字列は機能しません。そのかわりに、クライアントは必ず次のいずれかの方法を使用して、salesの位置を特定する必要があります。

  • エントリの完全なDNを接続文字列に使用します。たとえば:

    CONNECT username@"cn=sales,cn=OracleContext,o=example,c=us"
Enter password: password

    JDBC Thinドライバは、完全なDNが使用される場合にのみ、完全修飾ネーミングをサポートします。ただし、多くのアプリケーションで、DNの使用はサポートされていません。

  • エントリは完全修飾DNSスタイル名で参照できます。完全修飾DNSスタイル名は、ディレクトリ・ネーミング・アダプタによってLDAPディレクトリにあるデータベース・オブジェクトの完全x.500 DNにマッピングされます。たとえば:

    CONNECT username@sales.example.us
Enter password: password

ノート:

JDBC OCIドライバでは、完全修飾ネーミングがサポートされています。JDBC Thinドライバでは、完全なDNが使用される場合にのみ、完全修飾ネーミングがサポートされます。詳細は、『Oracle Database JDBC開発者ガイド』を参照してください。

親トピック: ディレクトリ情報ツリーの理解