前へ     目次     索引     DocHome     次へ     
iPlanet Directory Server 5.1 導入ガイド



第 3 章   スキーマの設計


第 2 章で実施したサイト調査により、ディレクトリに格納しようと計画しているデータについての情報を収集できました。次に、格納するデータの表現方法を決める必要があります。ディレクトリスキーマ (schema) は、ディレクトリに格納できるデータのタイプを表します。スキーマの設計時には、各データ要素を LDAP 属性に割り当て、関連する要素を集めて LDAP オブジェクトクラスに入れます。スキーマを適切に設計することで、ディレクトリに格納するデータの一貫性を維持できます。

この章では、ディレクトリスキーマの内容と個々の要件に応じたスキーマを設計する方法について説明します。この章は、次の節で構成されています。

スキーマの複製方法については、「スキーマのレプリケーション」を参照してください。



スキーマ設計の概要


スキーマの設計時には、Directory Server によって格納されるエントリを表すのに使用するオブジェクトクラスと属性を選択および定義します。スキーマの設計は、次の手順で行います。

  • できるかぎり多くの要件を満たす、定義済みのスキーマを選択する

  • Directory Server の標準スキーマを拡張して、残りの要件を満たす新しい要素を定義する

  • スキーマの保守計画

最善の方法は、Directory Server が提供する標準スキーマに定義されている既存のスキーマ要素を使用することです。標準スキーマの要素を選択すれば、ディレクトリを使用するアプリケーションとの互換性を保証できます。また、スキーマは LDAP 標準に基づいているので、多くのディレクトリユーザによってレビューされ、承認されています。



iPlanet 標準スキーマ


ディレクトリスキーマは、データ値のサイズ、範囲、および形式に制限を課すことにより、ディレクトリに格納されるデータの一貫性を維持します。設計者は、ディレクトリに含まれるエントリの種類 (ユーザ、デバイス、組織など) と各エントリで使用できる属性を決めます。

Directory Server に付属している定義済みのスキーマには、標準 LDAP スキーマと、サーバの機能をサポートするために追加された (iPlanet) アプリケーション固有のスキーマが含まれています。定義済みのスキーマは大半のディレクトリの要件を満たしますが、ユーザ独自の要件にも対応できるように、このスキーマを拡張して新しいオブジェクトクラスと属性を追加する必要がある場合もあります。スキーマの拡張方法については、「スキーマのカスタマイズ」を参照してください。

次に、iPlanet 標準スキーマに含まれる形式、標準属性、およびオブジェクトクラスについて説明します。


スキーマの形式

Directory Server は、LDAP プロトコルバージョン 3 (LDAPv3) のスキーマ形式に準拠しています。このプロトコルでは、Directory Server が LDAP 自体を通じてスキーマを公開することによって、ディレクトリクライアントアプリケーションがプログラムを使用してスキーマを検索し、検索したスキーマに基づいて自分の動作を調整できるようにする必要があります。Directory Server のグローバルスキーマセットは、cn=schema というエントリに含まれています。

Directory Server のスキーマは LDAPv3 のスキーマと多少異なり、独自の専用オブジェクトクラスと属性を使用します。また、スキーマエントリ内で X-ORIGIN という非公開フィールドを使用します。このフィールドは、スキーマエントリの定義元を示します。たとえば、スキーマエントリが標準 LDAPv3 スキーマで定義されている場合、X-ORIGIN フィールドの値は RFC 2252 になります。スキーマエントリが、Directory Server 用に iPlanet で定義されている場合は、X-ORIGIN フィールドに iPlanet Directory Server という値が入ります。

たとえば、標準の person オブジェクトクラスはスキーマ内で次のように示されます。

objectclasses: ( 2.5.6.6 NAME 'person' DESC 'Standard Person Object  Class' SUP top MUST (objectlass $ sn $ cn) MAY (description $  seealso $ telephoneNumber $ userPassword) X-ORIGIN 'RFC 2252' )

このスキーマエントリは、クラスのオブジェクト識別子 (OID) (2.5.6.6)、オブジェクトクラス名 (person)、クラスの説明 (Standard Person Object Class)、必須の属性 (objectclass、sn、および cn)、および許可された属性 (description、seealso、telephoneNumber、および userPassword) を示しています。


標準属性

属性は、名前やファックス番号などの特定のデータ要素を保持します。Directory Server はデータを属性とデータのペア、つまり特定の情報に関連付けられた説明属性 (attribute) で表します。たとえば、commonName (cn) のようにユーザ名と標準属性をペアにして、データをディレクトリに格納できます。したがって、Babs Jensen という名前のユーザのエントリは、次の属性とデータのペアを持ちます。

cn: Babs Jensen

実際には、エントリ全体は一連の属性とデータのペアで表されます。たとえば、Babs Jensen のエントリは次のようになります。

dn: uid=bjensen, ou=people, dc=siroe,dc=com
objectClass: top
objectClass:person
objectClass: organizationalPerson
objectClass:inetOrgPerson
cn: Babs Jensen
sn: Jensen
givenName: Babs
givenName: Barbara
mail: bjensen@siroe.com

Babs のエントリでは、いくつかの属性に複数の値があります。属性 givenName は 2 回使用され、それぞれ固有の値が指定されています。この例にあるオブジェクトクラスについては、次の節「標準オブジェクトクラス」で説明します。

スキーマの各属性定義には、次の情報が含まれます。

  • 一意の名前

  • 属性のオブジェクト識別子 (object identifier) (OID)

  • テキストによる属性の説明

  • 属性構文の OID

  • 属性が単一値と複数値のどちらであるか、そのディレクトリそのもので使用されるか、属性の作成元、属性に関連付けられた追加のマッチング規則

たとえば、cn 属性の定義はスキーマ内で次のように示されます。

attributetypes: ( 2.5.4.3 NAME 'cn' DESC 'commonName Standard  Attribute' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

SYNTAX は属性値の構文の OID です。属性で使用できる構文は、Directory Server のバージョン 4.x から名前が変更され、拡張されています。次の表では、すべての構文の新しい名前の OID を示します。


表 3-1 属性の構文の定義 

構文と OID

定義

Binary (以前は bin)
1.3.6.1.4.1.1466.115.121.1.5  

属性値がバイナリ形式であることを示す  

Boolean
1.3.6.1.4.1.1466.115.121.1.7  

属性値が True と False のいずれかであることを示す  

Country String
1.3.6.1.4.1.1466.115.121.1.11  

属性値が印刷可能な 2 文字に制限されることを示す (fr など)  

DN (以前は dn)
1.3.6.1.4.1.1466.115.121.1.12  

属性値が DN (識別名) であることを示す  

DirectoryString
(以前は cis)
1.3.6.1.4.1.1466.115.121.1.15  

属性値が大文字と小文字を区別しないことを示す  

GeneralizedTime
1.3.6.1.4.1.1466.115.121.1.24  

属性値が印刷可能な文字列として符号化されることを示す。タイムゾーンを指定する必要がある。GMT を使用することを強く推奨する  

IA5String (以前は ces)
1.3.6.1.4.1.1466.115.121.1.26  

属性値が大文字と小文字を区別することを示す  

INTEGER (以前は int)
1.3.6.1.4.1.1466.115.121.1.27  

有効な属性値が数字であることを示す  

OctetString
1.3.6.1.4.1.1466.115.121.1.40  

binary と同じ  

Postal Address
1.3.6.1.4.1.1466.115.121.1.41  

属性値が次のように符号化されていることを示す。

dstring[$ dstring]*

各 dstring コンポーネントは DirectoryString 構文の値と同様に符号化される。dstring 内のバックスラッシュとドル記号は、区切り文字と間違えられることがないように、引用符で囲む。多くのサーバで、postal address は 最大 30 文字の 6 行に制限されている。たとえば、次のようにする

1234 Main St.$Anytown, TX 12345$USA  

TelephoneNumber (以前は tel)
1.3.6.1.4.1.1466.115.121.1.50  

属性値が電話番号の形式であることを示す。国際形式の電話番号を使用することを推奨する  

URI
1.3.6.1.4.1.250.1.57  

属性値が http://、https://、ftp、LDAP などの文字列で始まる URL の形式であることを示す。URI は IA5String と同じである。RFC 2396 を参照  

LDAPv3 のスキーマ形式については、『LDAPv3 Attribute Syntax Definitions document (RFC 2252)』を参照してください。


標準オブジェクトクラス

オブジェクトクラスは関連情報をグループ化するために使用します。通常、オブジェクトクラス (object class) は、個人や FAX 機器などの実際の対象を表します。オブジェクトクラスとその属性をディレクトリで使用するには、それらがスキーマ内で識別される必要があります。ディレクトリはデフォルトでオブジェクトクラスの標準リストを認識します。詳細は、『iPlanet Directory Server スキーマリファレンス』を参照してください。

各ディレクトリエントリは、1 つ以上のオブジェクトクラスに所属します。スキーマ内で識別されるオブジェクトクラスをエントリに配置することで、そのエントリにはある属性値のセットがあり、通常はそのセットよりも少ない別の属性値のセットがあることを Directory Server に知らせます。

オブジェクトクラスの定義には、次の情報が含まれます。

スキーマに示される標準オブジェクトクラスの例については、「スキーマの形式」を参照してください。

iPlanet Directory Server のすべてのスキーマと同様に、オブジェクトクラスは直接 Directory Server で定義され、格納されています。これは、ディレクトリのスキーマを標準の LDAP 操作で問い合わせたり、変更したりできるということです。



デフォルトスキーマへのデータの割り当て


「サイト調査の実施」で説明したように、サイト調査で識別したデータを既存のデフォルトディレクトリスキーマに割り当てる必要があります。この節では、既存のデフォルトスキーマを表示する方法と、適切な既存のスキーマ要素にデータを割り当てる方法について説明します。

既存のデフォルトスキーマとマッチしない要素が独自のスキーマ内にある場合は、カスタマイズしたオブジェクトクラスと属性を作成する必要があります。詳細は、「スキーマのカスタマイズ」を参照してください。


デフォルトのディレクトリスキーマの表示

iPlanet Directory Server 5.1 で提供されるスキーマは、次のディレクトリに保存される一連のファイルに記述されています。

/var/ds5/slapd-serverID/config/schema

このディレクトリには、iPlanet 製品の共通スキーマがすべて入っています。LDAPv3 標準のユーザスキーマと組織スキーマは、 00core.ldif ファイルに記述されています。旧バージョンのディレクトリで使用された設定スキーマは、50ns-directory.ldif ファイルに記述されています。

ディレクトリにある各オブジェクトクラスと属性については、『iPlanet Directory Server スキーマリファレンス』を参照してください。スキーマファイルとディレクトリ設定属性については、 『iPlanet Directory Server 構成、コマンド、およびファイルのリファレンス』を参照してください。


データとスキーマ要素の対応付け

サイト調査で識別したデータを既存のディレクトリスキーマに割り当てる必要があります。この作業は、次の手順で行います。

  • データを表すオブジェクトのタイプを識別する

    サイト調査に記載されているデータにもっとも適したオブジェクトを選択します。データで複数のオブジェクトを記述できる場合があります。必要に応じて別の要素をディレクトリスキーマに入れるかどうかを決める必要があります。たとえば、電話番号に社員の電話番号と会議室の電話番号を記述できます。これらの電話番号データを、ディレクトリスキーマで異なるオブジェクトとみなすかどうかは設計者が決めます。

  • デフォルトスキーマから類似のオブジェクトクラスを選択する

    最善の方法は、groups、people、organizations などの共通オブジェクトクラスを使用することです。

  • 対応するオブジェクトクラスから類似の属性を選択する

    対応するオブジェクトクラスから、サイト調査で識別したデータにもっとも適した属性を選択します。

  • サイト調査で収集したデータの中で対応しないデータを識別する

    デフォルトのディレクトリスキーマで定義されているオブジェクトクラスと属性に対応しないデータがある場合は、スキーマをカスタマイズする必要があります。詳細は、「スキーマのカスタマイズ」を参照してください。

次の表に、ディレクトリスキーマの要素を第 2 章のサイト調査で識別したデータに割り当てた例を示します。


表 3-2 デフォルトディレクトリスキーマに割り当てられたデータ

データ

所有者

オブジェクトクラス

属性

社員名  

HR  

person  

cn(commonName)  

ユーザパスワード  

IS  

person  

userPassword  

自宅の電話番号  

HR  

inetOrgPerson  

homePhone  

社員の所属場所  

IS  

inetOrgPerson  

localityName  

会社の電話番号  

Facilities  

person  

telephoneNumber  

表では、社員名で個人を表しています。デフォルトのディレクトリスキーマには、top オブジェクトクラスから継承する person オブジェクトクラスがあります。このオブジェクトクラスには複数の属性が許可されており、その中に個人の氏名を記述する cn (commonName ) という属性があります。この属性は、社員名データを入れる目的にもっとも適しています。

ユーザパスワードも person オブジェクトに関連付けることができます。person オブジェクトの許可された属性に userPassword が含まれています。

電話番号も個人を表すものですが、person オブジェクトクラスに関連付けられたリストに該当する属性はありません。自宅の電話番号で考えると、これは組織の企業ネットワークにおける個人を表すものといえます。このオブジェクトは、ディレクトリスキーマの inetOrgPerson オブジェクトクラスに対応します。inetOrgPerson オブジェクトクラスは organizationPerson オブジェクトクラスから継承し、organizationPerson オブジェクトクラスは person オブジェクトクラスから継承します。inetOrgPerson オブジェクトの許可された属性の中に、社員の自宅の電話番号を入れるのに適した homePhone 属性があります。



スキーマのカスタマイズ


標準スキーマの制限が多すぎて、ディレクトリの要件に対応できない場合は、標準スキーマを拡張できます。Directory Server Console は、スキーマ定義の管理に役立ちます。詳細は、『iPlanet Directory Server 管理者ガイド』を参照してください。

スキーマをカスタマイズするときは、次の規則に留意してください。

  • できるかぎり既存のスキーマ要素を再利用する

  • 各オブジェクトクラスに定義する必須の属性の数を最小限にする

  • 同じ目的で複数のオブジェクトクラスまたは属性を定義しない

  • できるかぎりスキーマを簡潔にする


    注  

    スキーマをカスタマイズする場合は、標準スキーマの属性またはオブジェクトクラスの既存の定義の変更、削除、および置換は行わないでください。標準スキーマを修正すると、ほかのディレクトリや LDAP クライアントアプリケーションとの互換性に問題が生じます。  

カスタムのオブジェクトクラスと属性は、次のファイル内に定義されます。

/var/ds5/slapd-serverID/config/schema/99user.ldif

次の項目ごとに、ディレクトリスキーマのカスタマイズについて詳しく説明します。


スキーマの拡張が必要な場合

Directory Server が提供するオブジェクトクラスと属性は、ユーザのほとんどの要件を満たしますが、既存のオブジェクトクラスによっては組織の特殊な情報を格納できない場合もあります。また、LDAP 対応アプリケーションの独自のデータ要件に適したオブジェクトクラスや属性をサポートできるように、スキーマを拡張しなければならない場合もあります。


オブジェクト識別子の取得と割り当て

各 LDAP オブジェクトクラスまたは属性には、一意の名前とオブジェクト識別子 (object identifier) (OID) が割り当てられている必要があります。スキーマを定義するときは、組織に固有の OID が必要です。1 つの OID ですべてのスキーマ要件に対応できます。別の階層レベルを追加するだけで、属性とオブジェクトクラスに新しい分岐を作成できます。OID の取得とスキーマでの割り当ては、次の手順で行います。

  • IANA (Internet Assigned Numbers Authority) または国内の機関から組織の OID を取得する

    国によっては、企業にすでに OID が割り当てられてます。所属する組織がまだ OID を持っていない場合は、IANA から取得できます。詳細は、IANA の Web サイト http://www.iana.org/cgi-bin/enterprise.pl を参照してください。

  • OID の割り当てを追跡できるように、OID レジストリを作成する

    OID レジストリは、ディレクトリスキーマで使用する OID と OID の説明を提供するリストで、作成者が保持します。このレジストリにより、OID が複数の目的に使用されないようにすることができます。次に、スキーマで OID レジストリを公開する必要があります。

  • スキーマ要素を入れるために、OID ツリーに分岐を作成する

    OID 分岐またはディレクトリスキーマの下に少なくとも 2 つの分岐 (1 つは属性用の OID.1、もう 1 つはオブジェクトクラス用の OID.2) を作成します。独自のマッチング規則や制御を定義する場合は、必要に応じて OID.3 などの新しい分岐を追加できます。


属性とオブジェクトクラスの命名

新しい属性やオブジェクトクラスに名前を付けるときは、できるかぎりわかりやすいものにします。わかりやすい名前にすると、Directory Server の管理者がスキーマを使いやすくなります。

作成するすべての要素に固有の接頭辞を付けて、作成したスキーマ要素と既存のスキーマ要素間での名前の衝突を防ぎます。たとえば、siroe.com 社では、各カスタムスキーマ要素の前に siroe という接頭辞を追加しています。また、ディレクトリ内の siroe.com 社員を識別するために siroePerson という特別なオブジェクトクラスを追加しています。


新しいオブジェクトクラスの戦略

新しいオブジェクトクラスを作成するには、次の 2 つの方法があります。

  • 属性を追加するオブジェクトクラス構造ごとに 1 つずつ、多数の新しいオブジェクトクラスを作成する

  • ディレクトリ用に作成するすべての属性を含む 1 つのオブジェクトクラスを作成する。このオブジェクトクラスは AUXILIARY オブジェクトクラスとして定義して作成する

2 つの方法を併用するのがもっとも簡単です。

たとえば、属性 siroeDateOfBirth、siroePreferredOS、siroeBuildingFloor、および siroeVicePresident をサイトに作成するとします。これらの属性にいくつかのサブセットを許可する複数のオブジェクトクラスを作成できます。siroePerson というオブジェクトクラスを作成し、そのオブジェクトクラスが siroeDateOfBirth と siroePreferredOS を許可するようにします。siroePerson の親は inetOrgPerson であるとします。siroeOrganization というオブジェクトクラスを作成し、そのオブジェクトクラスが siroeBuildingFloor と siroeVicePresident を許可するようにします。siroeOrganization の親は organization オブジェクトクラスであるとします。

新しいオブジェクトクラスは、LDAPv3 スキーマ形式では次のようになります。

objectclasses: ( 2.16.840.1.17370.999.1.2.3 NAME 'siroePerson'  DESC 'Siroe Person Object Class' SUP inetorgPerson MAY (siroeDateOfBirth  $ siroePreferredOS) )

objectclasses: ( 2.16.840.1.17370.999.1.2.4 NAME  'siroeOrganization' DESC 'Organization Object Class' SUP  organization MAY (siroeBuildingFloor $ siroeVicePresident) )

このようにする代わりに、これらの属性のすべてを許可する 1 つのオブジェクトクラスを作成して、これらの属性を使用する任意のエントリでこのオブジェクトクラスを使用できるようにします。1 つのオブジェクトクラスは、次のようになります。

objectclasses: (2.16.840.1.17370.999.1.2.5 NAME 'siroeEntry' DESC  'Standard Entry Object Class' SUP top AUXILIARY MAY
 (siroeDateOfBirth $ siroePreferredOS $ siroeBuildingFloor $
 siroeVicePresident) )

新しい siroeEntry オブジェクトクラスには、構造上のオブジェクトクラスに関係なく任意のエントリで使用できることを示す AUXILIARY が付いています。


注  

例にある新しいオブジェクトクラスの OID は、iPlanet OID 接頭辞に基づいています。独自の新しいオブジェクトクラスを作成するには、独自の OID を取得する必要があります。詳細は、「オブジェクト識別子の取得と割り当て」を参照してください。  

目的に合った、新しいオブジェクトクラスを定義する方法を選択してください。新しいオブジェクトクラスを実装する方法を決めるときは、次の点に留意します。

  • 複数のオブジェクトクラスを作成すると、作成および管理するスキーマ要素の数も増える

    一般に、要素の数が少なければ、管理の手間も少なくて済みます。しかし、スキーマに 2 〜 3 つのオブジェクトクラスを追加する場合は、1 つのオブジェクトを使用する方が簡単です。

  • 複数のオブジェクトクラスを作成する場合は、より厳密かつ注意深いデータ設計が必要となる

    データを厳密に設計するには、個々のデータを配置するオブジェクトクラス構造を考慮する必要があります。この手間を有用と思う人もいれば、面倒だと思う人もいます。

  • 複数のタイプのオブジェクトクラス構造に入れたいデータがある場合は、1 つのオブジェクトクラスを使用した方がデータ設計が簡単になる

    たとえば、preferredOS 属性をユーザエントリとグループエントリの両方に設定するとします。このような場合は、1 つのオブジェクトクラスを作成して、そのクラスでこの属性が許可されるようにします。

  • 新しいオブジェクトクラスに必須の属性を設定しない

    必須の属性を設定するとスキーマに柔軟性がなくなります。新しいオブジェクトクラスを作成する場合は、必須の属性より許可の属性にするようにします。

新しいオブジェクトクラスを定義したら、そのオブジェクトクラスの許可された属性と必須の属性、および継承するオブジェクトクラスを決める必要があります。


新しい属性の定義方法

ディレクトリのエントリに格納する必要がある情報の中に既存のオブジェクトクラスがサポートしていないものがある場合は、新しい属性とオブジェクトクラスを追加します。

できるかぎり、標準属性を使用するようにします。デフォルトのディレクトリスキーマにある属性を探し、それらを新しいオブジェクトクラスに関連付けて使用します。対応する属性がデフォルトのディレクトリスキーマにない場合は、新しい属性を作成します。

たとえば、person、organizationalPerson、または inetOrgPerson の各オブジェクトクラスがサポートしている以外の情報を、個人のエントリに格納したい場合があります。ディレクトリに誕生日を格納する場合、iPlanet Directory Server の標準スキーマには対応する属性がありません。したがって、dateOfBirth という新しい属性を作成し、この属性を許可する新しい補助クラス siroePerson を定義して、個人を表すエントリでこの属性を使用できるようにします。


スキーマ要素の削除

Directory Server に含まれているスキーマ要素は削除しないでください。未使用のスキーマ要素は、Directory Server の動作や管理において、オーバーヘッドになることはありません。ただし、標準 LDAP スキーマの一部を削除すると、将来提供される新しいバージョンの Directory Server や LDAP 対応アプリケーションとの互換性に問題が生じる可能性があります。

拡張したスキーマの新しい要素を使用しないときは、その使用しない要素を削除してもかまいません。オブジェクトクラスの定義をスキーマから削除する前に、そのオブジェクトクラスを使用する各エントリを変更する必要があります。先に定義を削除すると、そのオブジェクトクラスを使用するエントリを変更できなくなる場合があります。不明なオブジェクトクラス値をエントリから削除しないかぎり、変更されたエントリに関するスキーマ検査も失敗します。


カスタムスキーマファイルの作成

Directory Server に含まれている 99user.ldif ファイルのほかに、独自のカスタムスキーマファイルを作成できます。ただし、カスタムスキーマファイルの名前には、文字コードの昇順で並べたときに「99user.ldif」よりもあとになるものを使用すると、サーバに問題が発生する場合があります。

99user.ldif ファイルには X-ORIGIN 'user defined' という属性が含まれています。99zzz.ldif という名前のスキーマファイルを作成すると、次回に LDAP または Directory Server Console を使用してスキーマを更新したときに、X-ORIGIN 'user defined' を持つすべての属性が 99zzz.ldif に書き込まれます。ディレクトリがそれらの属性を 99zzz.ldif に書き込むのは、内部のスキーマ管理において、数字そして英字の順にもっとも後にくる英数字の名前をディレクトリが使用するためです。その結果、重複した情報を持つ 2 つの LDIF ファイルが存在し、99zzz.ldif ファイル内のいくつかの情報が削除される可能性があります。

カスタムススキーマファイルに名前を付けるときは、次の形式を使用します。

[00-99]ユーザ名.ldif

ディレクトリはこのようなスキーマファイルを英数字の順で読み込みます。したがって、数字が最初に読み込まれます。そのため、ディレクトリの定義済み標準スキーマより大きい数字のスキーマを使用する必要があります。たとえば、siroe.com 社で 60siroecorp.ldif という名前の新しいスキーマファイルを作成したとします。作成したスキーマファイルに文字コードの昇順で並べたときに標準スキーマファイルより前にくる名前を付けると、サーバがスキーマを読み込むときにエラーが発生することがあります。また、すべての標準属性とオブジェクトクラスが読み込まれるのは、カスタムスキーマ要素の読み込み後になります。

'user defined' は、スキーマが LDAP 経由で追加されたときにディレクトリが内部で使用するので、カスタムスキーマファイルの X-ORIGIN フィールドには 'user defined' を使用しないでください。'siroe.com Corporation defined' などのように、もっとわかりやすい記述を使用します。

カスタムスキーマファイルを作成したら、次のいずれかを実行できます。

  • 作成したカスタムスキーマファイルをすべてのサーバに手動でコピーする。この場合は、各サーバを再起動する必要がある

  • レプリケーションを使用して、この情報を各コンシューマに複製する

作成したカスタムスキーマファイルをすべてのサーバにコピーしなかった場合は、スキーマ情報は、LDAP または Directory Server Console を使用してサプライヤ上のスキーマを変更した場合にのみ、コンシューマに複製されます。

スキーマ定義がすでに存在していないコンシューマサーバに複製された場合、その定義は 99user.ldif ファイルに格納されます。ディレクトリはスキーマ定義が格納された場所を追跡することはありません。スキーマ要素をコンシューマの 99user.ldif ファイルに格納しても、マスターサーバだけでスキーマを管理しているかぎり、問題はありません。

カスタムスキーマファイルを各サーバにコピーした場合は、スキーマファイルを変更したときに、変更したスキーマファイルを各サーバにコピーし直す必要があります。コピーし直さないと、変更がコンシューマ上の 99user.ldif ファイルにレプリケートおよび格納される可能性があります。変更が 99user.ldif ファイル内に格納されると管理がむずかしくなります。これは、一部の属性が、コンシューマ上の 2 つのスキーマファイル (サプライヤからコピーした元のカスタムスキーマファイルとレプリケート後の 99user.ldif ファイル) の両方に現れるためです。

スキーマの複製については、「スキーマのレプリケーション」を参照してください。


最適なカスタムスキーマの作成

カスタムのスキーマ要素を作成するときは、次の点に留意します。

  • LDAP または Directory Server Console を使用してスキーマを管理する場合は、複数のファイルでスキーマ要素が重複しないように、すべてのスキーマ定義を 99user.ldif に追加する。LDAP 経由で追加および更新されたスキーマ要素は、自動的に 99user.ldif ファイルに書き込まれる


    注  

    たとえば、60siroecorp.ldif というカスタムスキーマファイルを定義し、これらのスキーマ要素を LDAP を使用して更新した場合、新しい定義はカスタムスキーマファイルにではなく 99user.ldif ファイルに書き込まれ、元のカスタムスキーマ定義が上書きされます。たとえば、 60siroecorp.ldif への変更は 99user.ldif に格納されている定義で上書きされます。  

  • スキーマ要素を手動で 99user.ldif に追加する場合は、必ず 'user defined' の値を持つ X-ORIGIN を使用する。'user defined' 以外の値を使用すると、サーバは、99user.ldif ファイルからスキーマを読み込むときに、X-ORIGIN 用に指定したその値に加えて、定義の X-ORIGIN 部に 'user defined' 値を追加する。その結果、'user defined' ではない属性が Directory Server Console の読み取り専用セクションに表示され、Console を使用して 'user defined' 以外の X-ORIGIN を含むオブジェクトクラスを編集できなくなる

    'user defined' の値を持つ X-ORIGIN を使用すると、99user.ldif ファイル内のスキーマ定義がディレクトリによってファイルから削除されることはありません。ディレクトリは 'user defined' という X-ORIGIN に基づいて 99user.ldif ファイルに残す要素を判別しているため、これらの定義を削除しません。

    たとえば、次のようなスキーマエントリを 99user.ldif 内に手動で作成したとします。

    attributetypes: ( siroeContact-oid NAME 'siroeContact' DESC
     'Siroe Corporate contact' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
     X-ORIGIN 'Siroe defined')

    ディレクトリがスキーマのエントリを読み込むと、次のようになります。

    attributetypes: ( siroeContact-oid NAME 'siroeContact' DESC
     'Siroe Corporate contact' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
     X-ORIGIN ('Siroe defined' 'user defined') )

  • 新たに追加したスキーマ要素をオブジェクトクラスで使用するためには、事前にすべての属性が定義されている必要がある。属性とオブジェクトクラスは同じスキーマファイル内で定義できる

  • 作成する各カスタム属性またはオブジェクトクラスは、1 つのスキーマファイル内でだけ定義されている必要がある。これにより、サーバが最新のスキーマを読み込むときに、前の定義を上書きするのを防ぐことができる (サーバが最初に数字順、次にアルファベット順にスキーマを読み込むため)



データの整合性の維持

Directory Server 内のスキーマの一貫性を維持すると、LDAP クライアントアプリケーションがディレクトリのエントリを検出しやすくなります。ディレクトリに格納している情報のタイプごとに、その情報をサポートするために必要なオブジェクトタイプと属性を選択し、常に同じものを使用する必要があります。一貫性のないスキーマオブジェクトを使用すると、ディレクトリツリー内の情報を効率よく検出できなくなります。

次のようにすると、一貫性のあるスキーマを維持できます。

  • スキーマ検査を使用して、属性とオブジェクトクラスが必ずスキーマ規則にマッチしていることを確認する

  • 一貫性のあるデータ形式を選択して適用する

次に、スキーマ内で一貫性を維持する方法について詳しく説明します。


スキーマ検査

スキーマ検査は、すべての新しいまたは変更したディレクトリエントリが、スキーマ規則にマッチしているかどうかを検査します。規則にマッチしていない場合、ディレクトリは変更要求を拒否します。


注  

スキーマ検査では、適切な属性があるかどうかだけを検査します。属性値が当該属性について正しい構文で記述されているかどうかは検査しません。  

スキーマ検査 (schema checking) はデフォルトで有効になっています。スキーマ検査は無効にしないことをお勧めします。スキーマ検査の有効と無効の切り替えについては、『iPlanet Directory Server 管理者ガイド』を参照してください。

スキーマ検査を有効にする場合は、オブジェクトクラスで定義されている必須の属性と許可された属性に注意する必要があります。通常、オブジェクトクラス定義には少なくとも 1 つの必須の属性と 1 つ以上の省略可能な属性が含まれています。省略可能な属性とは、ディレクトリのエントリに追加できるが必須ではない属性のことです。エントリのオブジェクトクラス定義で必須でなく許可されてもいない属性をエントリに追加しようとすると、Directory Server はオブジェクトクラス違反メッセージを返します。

たとえば、エントリで organizationalPerson オブジェクトクラスを使用するように定義した場合は、commonName (cn) と surname (sn) がそのエントリの必須の属性になります。これらの属性にはエントリの作成時に値を指定する必要があります。さらに、オプションとしてエントリで使用できる属性の長いリストがあります。このリストには、telephoneNumber、uid、streetAddress、userPassword などの説明属性が含まれています。


一貫性のあるデータ形式の選択

LDAP スキーマを使用して、必要なデータを任意の属性値に格納できます。ただし、LDAP クライアントアプリケーションとディレクトリユーザに適切な形式を選択して、ディレクトリツリー内で一貫性を維持するようにデータを格納することが重要です。

LDAP プロトコルと iPlanet Directory Server を使用する場合は、RFC 2252 で規定されているデータ形式でデータを表す必要があります。

また、電話番号の正しい LDAP 形式は、次の ITU-T 勧告ドキュメントで定義されています。

  • ITU-T 勧告 E.123

    国内および国際電話番号に関する注記

  • ITU-T 勧告 E.163

    国際電話サービスの番号計画

たとえば、米国の電話番号は次のような形式になります。

+1 555 222 1717

postalAddress 属性には、区切り文字としてドル記号 ($) を使用する複数行文字列形式の属性値が必要です。適切に形式化されたディレクトリエントリは次のようになります。

postalAddress: 1206 Directory Drive$Pleasant View, MN$34200


レプリカされたスキーマでの一貫性の維持

レプリケート環境で iPlanet Directory Server を使用する場合は、レプリケーションに含まれるすべての Directory Server にわたってスキーマの一貫性を維持する必要があります。このレベルの一貫性を確保するための唯一の方法は、1 つのマスターサーバでのみスキーマの変更を行うことです。

ディレクトリのスキーマを変更すると、その変更は更新履歴ログに記録されます。複製時には、更新履歴ログ内の変更がスキャンされ、すべての変更が複製されます。レプリケート環境で一貫性のあるスキーマを維持するには、次の点に留意します。

  • コンシューマサーバのスキーマを変更しない

    コンシューマサーバのスキーマを変更すると、マスターサーバのスキーマよりも新しいスキーマとなります。したがって、マスターがレプリケーションで更新をコンシューマに送信すると、コンシューマのスキーマが新しいデータをサポートできないため、多数のレプリケーションエラーが発生します。

  • 2 つのマスターサーバのスキーマを変更しない

    2 つのマスターサーバのスキーマを変更すると、最後に更新されたマスターのスキーマがコンシューマに伝達されます。これは、コンシューマのスキーマと他方のマスターのスキーマとの間に一貫性がないことを意味します。

  • マルチマスターレプリケーション環境の場合も、必ず 1 つのマスターサーバでスキーマを変更する

スキーマレプリケーションについては、「スキーマのレプリケーション」を参照してください。



その他のスキーマ関連資料


標準 LDAPv3 スキーマについては、次のドキュメントを参照してください。


前へ     目次     索引     DocHome     次へ     
Copyright © 2001 Sun Microsystems, Inc. Some preexisting portions Copyright © 2001 Netscape Communications Corp. All rights reserved.

Last Updated March 02, 2002