カスタム・スキーマについて

ディレクトリのニーズに対して、標準スキーマでは著しく制限される場合に、標準スキーマを拡張できます。スキーマをカスタマイズする際は、次のガイドラインに従います。

• 可能なかぎり、既存のスキーマ要素を再利用します。

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

• 同じ目的に対して複数のオブジェクト・クラスまたは属性を定義しないでください。

• スキーマはできるかぎり簡潔にします。

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

Directory Serverの内部操作属性は変更しないでください。ただし、外部のアプリケーション用に独自の操作変数を作成できます。

objectClass: extensibleObjectを使用するかわりに、常にオブジェクトクラスを定義しますDirectory Serverでは、オブジェクト・クラスextensibleObjectがあるエントリのスキーマ・チェックを実行しないため、エントリに存在する属性を制限したり、チェックしたりしません。アプリケーションでのタイプ・ミス(givenName属性タイプのgiveNameなど)は、Directory Serverでは認識されません。Directory Serverでは、extensibleObjectエントリの未定義属性はすべて複数値で、大文字/小文字が区別されないことを前提とします。さらに、特定のオブジェクト・クラスを持つエントリに依存するアプリケーションもあります。一般に、オブジェクト・クラスに対して拡張が必要なアプリケーションがある場合は、スキーマ管理を放棄しないでください。そのかわりに、アプリケーションで必要な属性を含む補助オブジェクト・クラスを作成します。

この項では、デフォルトのディレクトリ・スキーマについて、およびカスタムの属性とオブジェクト・クラスの作成について説明します。

デフォルトのDirectory Serverスキーマ

Directory Serverで提供するスキーマについては、instance-path/config/schema/ディレクトリに格納されている一連のファイルで説明しています。

このディレクトリには、Directory Serverと関連製品の共通スキーマがすべて含まれます。LDAP v3ユーザーおよび組織用の標準スキーマは、00core.ldifファイル内に記述されています。旧バージョンのディレクトリで使用された構成スキーマは、50ns-directory.ldifファイル内に記述されています。オブジェクト・クラスや属性など、ユーザーが作成した要素は、99user.ldifに格納されます。

オブジェクト識別子

LDAPの各オブジェクト・クラスまたは属性には、一意の名前およびオブジェクト識別子(OID)を割り当てる必要があります。スキーマを定義する際は、組織に固有のOIDが必要になります。ユーザーのスキーマに対するニーズをすべて満たすには、1つのOIDで十分となります。属性およびオブジェクト・クラスのそのOIDに新しいブランチを追加します。

OIDの取得およびスキーマでの割当てでは、次の処理を行います。

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

  国によっては、企業にすでにOIDが割り当てられています。組織がまだOIDを持っていない場合、IANAよりOIDを取得できます。

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

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

• OIDツリーにスキーマ要素を収容するブランチを作成します。

  OIDブランチすなわちディレクトリ・スキーマの下に2つ以上のブランチ(属性用にOID.1、オブジェクト・クラス用にOID.2)を作成します。独自のマッチング・ルールや制御を定義する場合、必要に応じてOID.3などの新しいブランチを追加できます。

属性およびオブジェクト・クラスのネーミング

新規の属性およびオブジェクト・クラスの名前を作成する場合、スキーマで使用しやすいように、わかりやすい名前を作成します。

カスタム要素に一意の接頭辞を含めることにより、カスタム・スキーマ要素と既存のスキーマ要素の名前の競合を防ぎます。たとえばExample.com社では、各カスタム・スキーマ要素の前に接尾辞Exampleを追加できます。ExamplePersonという特殊オブジェクト・クラスを追加して、ディレクトリ内のExample.comの従業員を識別することもできます。

LDAPでは、属性タイプ名およびオブジェクト・クラス名は大文字と小文字の区別がないことに注意してください。アプリケーションでは、それらを大文字/小文字の区別なしで扱う必要があります。

新しいオブジェクト・クラスを定義する場合

既存のオブジェクト・クラスでは、ディレクトリ・エントリへ格納する必要のある情報のすべてがサポートされていない場合、新しいオブジェクト・クラスを追加します。

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

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

• ディレクトリ用に作成する属性をすべてサポートする単一のオブジェクト・クラスを作成します。この種のオブジェクト・クラスは、AUXILIARYオブジェクト・クラスと定義して作成します。

  サイトで属性ExampleDepartmentNumberおよびExampleEmergencyPhoneNumberを作成するとします。これらの属性のいくつかのサブセットを許可するオブジェクト・クラスを複数作成できます。ExamplePersonというオブジェクト・クラスを作成して、それがExampleDepartmentNumberおよびExampleEmergencyPhoneNumber属性を許可するようにします。ExamplePersonの親はinetOrgPersonです。ExampleOrganizationというオブジェクト・クラスを作成し、それもExampleDepartmentNumberおよびExampleEmergencyPhoneNumber属性を許可するようにできます。ExampleOrganizationの親はorganizationオブジェクト・クラスです。

  新しいオブジェクト・クラスは、次のようにLDAP v3スキーマ・フォーマットで表されます。

  objectclasses: (1.3.6.1.4.1.42.2.27.999.1.2.3 NAME 'ExamplePerson'
   DESC 'Example Person Object Class' SUP inetorgPerson STRUCTURAL MAY
   (ExampleDepartmentNumber $ ExampleEmergencyPhoneNumber) )
  objectclasses: (1.3.6.1.4.1.42.2.27.999.1.2.4 NAME
   'ExampleOrganization' DESC 'Example Organization Object Class' SUP
   organization STRUCTURAL MAY (ExampleDepartmentNumber
   $ ExampleEmergencyPhoneNumber) )

  または、これらの属性をすべて許可する単一のオブジェクト・クラスを作成することもできます。これらの属性を使用するエントリで、このオブジェクト・クラスを使用できます。この単一オブジェクト・クラスは、次のように表されます。

  objectclasses: (1.3.6.1.4.1.42.2.27.999.1.2.5 NAME 'ExampleEntry'
   DESC 'Example Auxiliary Object Class' SUP top AUXILIARY MAY
   (ExampleDepartmentNumber $ ExampleEmergencyPhoneNumber) )

  新しいExampleEntryオブジェクト・クラスには、構造的なオブジェクト・クラスに関係なく、任意のエントリで使用できることを示すAUXILIARYというマークが付けられます。

新しいオブジェクト・クラスの実装方法を決定する際には、次のことを考慮します。

• 複数のSTRUCTURALオブジェクト・クラスでは、作成および管理するスキーマ要素も増えます。

  一般に、要素数を少なく抑えると、メンテナンスの必要性が軽減されます。しかし、スキーマに3つまたは4つ以上のオブジェクト・クラスを追加する場合は、単一オブジェクト・クラスを使用する方が簡単な場合があります。

• 複数のSTRUCTURALオブジェクト・クラスでは、より入念かつ厳密にデータ設計をする必要があります。

  厳密なデータ設計では、個々のデータが配置されるオブジェクト・クラス構造を考慮する必要があります。この制約は役立つ場合もありますが、煩雑でもあります。

• 単一のAUXILIARYオブジェクト・クラスでは、複数のタイプのオブジェクト・クラス構造にデータを配置する場合に、データ設計が簡素化されます。

  たとえば、個人およびグループの両方のエントリに、preferredOSを置くとします。このような場合、オブジェクト・クラスを1つのみ作成し、この属性を許可するようにできます。

• 実際のオブジェクトに関連するオブジェクト・クラスと目的に合ったグループ化を構成するグループ要素を設計します。

• 新しいオブジェクト・クラスには、必須属性を回避します。

  属性を必要とすることにより、スキーマに柔軟性がなくなる可能性があります。新しいオブジェクト・クラスを作成する場合は、属性を要求するのではなく許可します。

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

新しい属性を定義する場合

既存の属性で、ディレクトリ・エントリに格納する必要がある情報のすべてをサポートしていない場合、新しい属性を追加します。可能なかぎり標準の属性を使用するようにします。デフォルトのディレクトリ・スキーマにある属性を検索して、それらの属性を新しいオブジェクト・クラスに関連付けて使用します。

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