リポジトリに格納するデータ(エントリ)と、エントリ間の階層構造などのディレクトリ情報ツリーの設計方法について説明します。
リポジトリに格納するデータを決定します。
リポジトリの一般的な利用方法は、電話帳のような情報検索と、Webサーバの利用者管理です。リポジトリは、参照(情報検索)に適していますので、以下のようなデータは入れないようにします。
頻繁に更新(書き込み)させるデータ
画像、オーディオなどの大きなデータ
1つのデータ（エントリ）に極端に多くの属性を含んだデータ
また、現在必要なデータだけではなく、将来格納する可能性のあるデータについてもあらかじめ考慮しておくことで、データ量の増加によるデータベース格納域の拡張などの保守を削減することができます。
エントリ間の階層構造、エントリの名前など、ディレクトリ情報ツリーの構造を決定します。
以下の3つを決定します。
エントリの名前
エントリの名前は、リポジトリ内で一意である必要があります。名前には、1つ以上の属性値を使用します。
たとえば、ユーザエントリには、cn属性(氏名)を使用するのが一般的ですが、同じ名前のユーザがいる場合は、一意になりません。この場合は、uid(ユーザID)属性や、employeeNumber(従業員番号)属性を使用します。
エントリの名前には、管理者用DNと同一のDNは使用できません。
ツリーのルート(公開ディレクトリ)
ツリーの最上位(ルート)にするエントリです。リポジトリ固有のエントリで、すべてのエントリは、このエントリの下に格納されます。
ルートエントリの名前には、任意の属性を使用できますが、ドメイン名(dc(domainComponent))、組織(o(organization))、国(c(country))にすることを推奨します。
エントリ間の関係
ツリーの階層構造は、できるだけ浅くフラットにします。名前の変更をできるだけ避けるためです。
分岐点には、会社の組織や部門は使用しないようにします。組織名は変更されることが考えられるためです。「ユーザ情報」、「サービス」などで分類すると、名前の変更を避けることができます。
なお、エントリをLDIFファイルに出力して保守作業を行う予定がある場合は、1つのツリー配下のエントリ数が、1～10万件程度になるようにツリーの階層構造を分割し、複数のLDIFファイルに分割して出力できるように設計することを推奨します。
階層が深く複雑な例。所属を変更すると名前の変更が必要になる。
階層が浅く単純な例。所属を変更しても名前を変更する必要がない。
