---

ディレクトリ設計

はじめに

基本的な用語

下記にディレクトリに関する基本的な用語を記述する。以降の内容を把握するには、最低限、下記の用語を理解していないと先に進めない。
 
• DIT                     ：Directory Information Treeの略。情報を視覚的に階層化したもの。
• エントリ               ：一つまたは、複数の属性の集まりで、DITの中の一つの階層にあたる。
• DN                     ：エントリを一意に識別する名称。詳細はRFC1779参照。
• 属性名               ：エントリに含まれている属性を識別するためのキーワード。
• 属性値               ：エントリに含まれる属性「cn: ほげ 太郎」の「ほげ 太郎」の部分を指す。
• 属性型               ：属性に使用できるデータ型を記したものとする。
• 属性                  ：エントリ内の属性名と属性値の対を指す。
• オブジェクトクラス ：必須属性と任意属性を定義したもの。
 
 
1. DITとは、エントリという情報の集まりを階層的に配置したものと考えられる。

  図1.DITの概要    
2. エントリは、自身を一意に識別するDN(識別名)を持つ。またエントリは、属性の集まりであり、そのエントリを生成する際に必ず生成する属性、任意で生成する属性を決定するのがオブジェクトクラスである。属性は、属性名と属性値から構成される。属性名はその属性に対する名称になり、属性値は、その属性名に対する実体のデータである。当該エントリが何のオブジェクトクラスに該当するかについても属性として記述する。

 

3. オブジェクトクラスは、親になるクラスをスーパクラスといい、親になるｸﾗｽの性質を引き継いで新たに属性を追加したものをサブクラスという。ディレクトリ上のオブジェクトクラスは、オブジェクトを生成する際に必ず必要な属性を必須属性、任意に必要な属性を任意属性の二種類の属性群を定義したものと考えられる。オブジェクトクラスは何らかの既存のオブジェクトクラスをもとにして生成される。すなわち、スーパクラスで定義した必須属性、任意属性は、そのサブクラスでも同様に必須属性、任意属性として扱われる。さらに、サブクラス独自に必要な必須／任意属性を追加することができる。

※ オブジェクトクラスの継承関係とDITにおける階層関係は、概念的に関連はないことに注意。

上記図から、organizationｵﾌﾞｼﾞｪｸﾄｸﾗｽは、topｵﾌﾞｼﾞｪｸﾄｸﾗｽをｽｰﾊﾟｸﾗｽとし、patentｵﾌﾞｼﾞｪｸﾄｸﾗｽをｻﾌﾞｸﾗｽに持つ。つまり、上記の場合、各ｵﾌﾞｼﾞｪｸﾄｸﾗｽが保持する属性は下記のようになる。
 

表上記オブジェクトクラス概念図でのオブジェクトクラスの関係

オブジェクトクラス	必須属性	任意属性
top	objectClass	なし
organization	objectClass,o	streetAddress,telephoneNumber,userPassword
Private company	objectClass,o,住所	streetAddress,telephoneNumber,userPassword,  全社職員数


 

設計手順概要

設計手順詳細

1. データ項目整理

•  ディレクトリ対象範囲となった既存のデータ項目の抽出。
•  新規業務要件で必要になった項目の抽出。
•  不要項目、重複項目、追加項目等の抽出。
•  冗長なデータの抽出。
•  データ同士の関連(1:N等)の抽出。
•  必須/任意項目の検討。
•  キー項目の検討。
•  etc...

この段階では、対象範囲にある全データを検討対象とする。上記作業結果から、新システムに必要な項目の整理作業を行う。ER図等を使用する方法もあるが、そのまま DITにマッピングできるわけではないので、あくまでも情報の整理手法の一つとして割り切って使用したほうがよい。また、ER図を利用すれば自動的にデータ整理ができるわけではなく、データ自身に対する検討作業は ER図を記述しながら吟味する必要がある。
以降の作業は、この段階で正しくデータ整理ができていることが前提となるので十分注意されたい。

参考までに、ER図で記述した内容は、基本的に以下の様にマッピングできると考えられる。
 
 

表.ER図からディレクトリへのマッピング例

ER図の要素	ディレクトリの要素
エンティティ	エントリの検討要素となる。
アトリビュート	属性名の検討要素となる。
アトリビュートのデータ型	属性型の検討要素となる。ただし、RDBとディレクトリとで利用できるデータ型の違いに注意が必要。
リレーション	エントリの分割、DIT階層の検討要素となる。
カーディナリティ	オブジェクトクラスを決定する検討要素となる。
主キー	エントリのDNを決定する検討要素となり、DNの一部を構成する可能性がある。
外部キー	エントリ間の関連を決定する検討要素となり、他エントリを参照する属性として定義される可能性がある。ただし、整合参照性制約はディレクトリサーバには存在しない。

※上記マッピングはあくまでも基本的な考え方であり、上記の通りに機械的にマッピングすることが必ずしも最良とは言えない。 あくまでも、判断基準の一つとして捉えること。

2. DIT設計

1.の整理結果をツリー構造で表現してみる。また、ディレクトリ構成を作る上では、下記の考え方で作業を進めるとよいと思われる。
 

• 情報の集まりをエントリとして捉える、それらを階層的に配置して行く。
• 現実に存在する実オブジェクトとの関連に着目して階層を作ると利用者側からは分かり易い。
• ディレクトリの上位エントリには、大分類を配置し、下位エントリには小分類を配置していく。
• 性能を重視する場合、階層的にエントリを配置する。メンテナンス性を重視する場合、フラットにエントリを配置する。
• ただし、階層が深すぎるとINDEX文字列が長くなりすぎるため、性能劣化を引き起こす要因となりうる。
• ディレクトリ構成が度々変更される構成は問題がある(DNが度々変わるため、関連データ項目の整合性維持をAP側でその都度行う必要有り)。
• DN は一意になるように命名する。
• 分散管理を行う場合、それらの情報を分離できる様に設計するとよい。
• 頻繁に一覧情報を取得するデータは同一階層に登録する必要がある。これは後にアクセスパターンを整理すれば、その必要性が分かるので、
• その時点で、検討しても遅くはない。
• ディレクトリに対して、アクセス権限管理、制限を行う場合、それらを付与する情報毎に階層化できていると扱いやすい。
• DIT構成の維持は基本的にAP側の責任になるので、AP開発者は、DIT構成を崩さない様に考慮する必要がある。
 
3. エントリ設計

 
3-1.属性抽出

1.2.の作業によって、ある程度の情報の固まりが、階層的に配置されるので、各エントリに属性をマッピングしてみる。
 

• 対象範囲の情報が、属性としてすべて表現できているかチェックを行う。
• 一つのエントリ内にマルチバリューの繰返し項目を属性として持つことができないので、その項目はそのエントリの下位エントリとして分割する。
• 一つのエントリ内に一項目の繰返し項目を持つことは可能だが、その中で順番を考慮してデータハンドリングする必要がある場合は、下位エントリとして分割した方がよい。
• 実体が一つでそれに対するポインタを属性として保持したい場合、その属性の属性型を DN文字列として定義するとよい。
• エントリと属性との関係が必須／任意なのか検討する。これは後のオブジェクトクラス定義に生かせる。
• エントリと属性との関係が1対複数なのかを検討する。
• 属性に対してどういった検索を行うのかを検討する(大文字小文字を同一視するのか？DN文字列を使用した検索なのか等)。
• 各属性がどういった情報を扱うのかを決定する。その結果として、属性型、属性サイズ等が決定する。
 
3-2.オブジェクトクラス定義

上記作業から、各エントリに必要な属性が抽出される。その中で、エントリが生成される際に必須／任意である属性を分別する。必要な属性が含まれている既存のオブジェクトクラス(ディレクトリサーバのマニュアル参照)を継承して、サブクラスを定義する(既存のクラスを変更することなく使用できる場合はそのまま利用してもよい)。導出されたサブクラスは、スーパクラスの必須／任意属性を引き継ぐ。
 

• あるクラスのサブクラスとしてクラス定義をする場合、スーパクラスの必須、任意属性をサブクラス側にも記述しなければならない。
• オブジェクトクラスの識別子としてオブジェクト識別子 (OID) を付与する。OID は、全ディレクトリ内で一意でなければならない。
 
4. アクセスパターン調査

 1.〜3.までの結果に基づいて、業務APからのアクセスパターンを作成する。
 

5. ディレクトリ精査作業

 1.〜3.の結果と4.の調査結果に性能要件、メンテナンス性等の物理的な要件を加味して、検討する。
 

• 検討後のモデルが必ずしも一つになるとは限らない。その場合は、各モデルの比較検討が必要。
• 各要件を実現することが難しい場合、?から再検討を行う。
• この作業で前の工程に戻ることになったとしても、手戻り作業ではない。むしろ、より精査されたモデルを作るために前進したと考えられる。
 
6. INDEX設計

5.で精査されたモデルに対して、性能要件上INDEX付与が必要な属性の洗い出しを行う。
尚、この作業結果は、ディレクトリサーバ環境構築の担当者に提供されるべき情報である。
 
 
 

成果物イメージ

オブジェクトクラス定義書
 
 

オブジェクトクラス定義書      項番 OID objectClass objectClass名 必須属性 オプション属性 スーパクラス 1 10001 トップ top オブジェクトクラス     2 10678 別名 alias 別名先エントリ名   トップ    3 19674 国 country 国名 記述、検索ガイド    トップ    4 12271 地域 locality 地域名または都道府県名 記述、検索ガイド、他参照、地域属性集合    トップ    5 11078 組織  organization 組織名 組織属性集合    トップ    6 10997 組織単位(組織の一部門) oraganizationalUnit 組織単位名 組織属性集合    トップ    7 29789 人 person 一般名、姓 記述、他参照、電話番号、ユーザパスワード    トップ        表．オブジェクトクラス定義書の意味定義 項目 意味 項番  項目の番号 OID  オブジェクトクラスのオブジェクト識別子 objectClass 一つのエントリに必要なデータ項目の集まりを一つの器として定義したものの名前 objectClass名 属性にobjectClassの記載が必要な際の名称。日本語のobjectClass名が利用可能かどうかは実装依存のため、英語名称にする。基本的なobjectClassは標準として、定義されているため、基本的なものは既存に定義されているものをスーパークラスとして、そのサブクラスに新たなobjectClassを定義するのが望ましい。 必須属性 objectClassの中に複数の属性が存在することになるが、そのobjectClassで定義されているエントリが生成される場合、必ず値を設定する必要がある属性名を記述する。 オプション属性  objectClass中の属性で、このobjectClassで定義されているエントリが生成される場合に必ず値を生成する必要のない属性名を記述する。 スーパークラス 当該objectClassがここで記述されたスーパークラスを元に定義されたことを示す。