---

ディレクトリ調査

目的

ディレクトリをRDBのように利用するための検討事項とディレクトリ設計を行う方法の検討を行う。

 

設計手順

ディレクトリを設計する際に必要と思われる手順を下記に示す。ただし、この手順を厳守する必要はなく、重要なのは成果物として、他人に理解できる資料を残すことである。
※セキュリティ、アクセスコントロールに関しては、現在未調査であるため、どの単位でそれらの設定を行えばよいのかは不明である。設定できる単位によっては、ディレクトリ の構造自体もそれらを考慮して設計する必要があり、当設計に入る前にさらなる調査、検討を行うことが望ましい。

DIT構造の設計

システム化する情報をディレクトリ情報ツリー(DIT)で表現する。設計指針としては、月並みだが、ディレクトリの上位階層(ルート)から下の階層に向かって、大分類から小分類に分類していくのがよいと思われる。また、一般にディレクトリサーバは全世界にむけた分散システム(DNSのような仕組み)を指向しているため、世界的に決められているDIT構造に準拠するのが妥当と思われる(ex.上位ディレクトリから国→組織→組織単位→人という様な形が一般的である)。

☆成果物：DIT定義書

 

エントリ設計 　

1. 各ディレクトリの構成要素となるエントリ(ディレクトリにその情報を管理されている実世界のものであるオブジェクトに関する情報の集まりのこと)を抽出する。
2. 次に上記で抽出したエントリは、そのエントリに対応するオブジェクトに関する個々の情報を表した属性の集合として構成されるので、エントリに含まれる属性を抽出する。
3. 上記a.b.の結果からエントリに必要な属性から、エントリに対してオブジェクトクラスを割り当てる。
　 クラス、識別名、属性の概念図  
4. ディレクトリに保持する情報が抽出できた所で、それら(エントリ、属性)をディレクトリに識別名として割り当てる。この際の命名規則はX.520等を参照し、既存の属性型が定義されているものは極力それを使用する。同様にオブジェクトクラスについても定義を行う。(識別名はデータの枠を提供するが、エントリは識別名の中に入るデータの実体である。)

☆成果物：オブジェクトクラス定義書、属性型定義書、エントリ設計書

 

参考

DOA等の手法で導出されたサブジェクトエリアのERモデルを元に、ディレクトリの 表現に必要と思われる代表的なデータ型の実現手段を検討した。
 

1. 1対多

この関連を表す表現方法としては、下記のものがあげられる。

• あるエントリの属性を複数定義することで表現可能。(EX.下記図の(株)Aの場合)
• 通常のディレクトリの階層を上位層を一つにし、下位の層に広げて行く形で表現可能。
(EX.下記図の(株)Bの場合)

2. 多対多

所属と作業員の関係を表す場合。例えば、 一人の作業員が複数の所属に配属されている場合がある。 一つの所属に複数の作業員を配置する場合がある。 この場合、DOA的に言えば、作業員と所属とのエンティティの関連は多対多の関連 があると言える。これをディレクトリで表現するには下記の方法が考えられる。

• ディレクトリの上位階層と下位階層を各々複数持つ関連がある様に作成する。
• 多対多の関連になる各々のエントリに�@と同様に属性を複数作成する。(下記図参照)

3. 再帰型

ある指導員を指導する指導員が存在する場合の関連は、指導員に対して指導員の関連が作成されるため、再帰型となる。このような場合の関係を表す場合は、下記の方法が考えられる。

• 属性にて、同じ識別名を持つエントリを再帰先に指定する。

(seeAlso属性の使用が可能と思われる)
 
4. 外部参照

ここでは、RDBにおけるForeign Key制約と同等の機能の実現性を考えてみる。

• 属性でリンク先を指定することは可能だが、それらに関して参照先のデータの有無等の確認、各々のデータの整合性維持はユーザアプリケーション側の責任となる。

5. 入力必須項目

RDBでいうNot NULLと比較するのは無理があるが、ディレクトリの設定でそれに似た ことが実現可能である。実現方法は下記の通り。

• エントリに設定されたobjectClassによって、必須入力項目、任意入力項目を設定することが可能であり、必須入力項目とすることによって、エントリが生成される時は常に、指定された属性値が、属性に入力される。
 
6. 一意制約

RDBでいうPRIMARY KEY指定に近いものだが、ディレクトリではKeyという言葉は使わ れていない。ディレクトリは、単にエントリ(DN)の一意性をチェックしているため、既に 存在するエントリを追加することはできなかった。尚、一意とみなすチェックルールは 未調査であるため、厳密な一意性がどの程度なのかは不明である。

7. 索引

slapd付属ドキュメントの記述には、indexを付与することは、可能と記述されているが、 詳細な調査は実施してないので割愛する。

8. データのメンテナンス

エントリの属性の追加、変更はRDBでSQLを使用する場合と大差はないが、slapdの場合(ldapadd、ldapmodifyユーティリティを使う場合)、LDIFの書式で書く 必要があるので、メンテナンス性という面から見るとSQL言語とLDIFとどちらが難解であるかという比較になる。また、ディレクトリツリーの階層自体を変更することは可能であるが、一括変更というユーティリティが見当たらなかったため、ディレクトリサーバの機能に大きく依存する部分であろう。頻繁にディレクトリ階層を変更する可能性がある場合には、ディレクトリの設計に問題があるか、ディレクトリを使用すること自体問題があることが考えられるため、根本的な見直しが必要と思われる。

問題点

• 基本的に属性を複数持たせて複雑なデータ構造を表現していたが、それらの関連を維持す るのは、ユーザアプリケーションの責任になる。この点がRDBと大きく異なる。ただし、 実装段階のRDBでは、参照整合性制約をはずして使用する場合もあり、一概に欠点とはいえない。
• slapdの場合はGNUのgdbmをdbとして利用している(他のDBも利用可能)。その場合の障害回復は、どのレベルまで可能なのかが未知数である。商用RDBのようなトランザクション単位の回復は難しいのではないかと予想される。ただし、RDBをバックエンドとするディレクトリサーバでは、この辺りが不明であるため、調査が必要と思われる。
• アクセス権設定等を行う場合(庁内職員に作業権限を与えたりする場合)の調査は未調査であり、権限設定の制限によっては、ディレクトリ情報ツリーの構成が制限されることもあり得る。調査要。
• 設計手法に関する文献が不足している。逆に言うと、一般には、複雑なディレクトリ を構成しないのではないかと思われる。
• 日本語識別名、日本語属性名、特殊文字エントリが可能かどうかについては未調査である。(->LDAPv3で日本語識別名、日本語属性値の利用は可能なようだが、日本語識別名は不可と考えた方が良い。)
• 別名(alias)クラスがエントリ同士のリンクを表すカギになる可能性があるがこれも未調査である。(->Windowsのショートカット的なものであるようだ。具体的な利用方法はいまだ未調査)
• 多対多の関連は、DOAでは連関エンティティとして表現できるが、当実験の方法ではその関連を示す情報が2箇所に分散されている。よって、このデータの更新時の整合性をユーザアプリケーションが意識する必要がある。回避策としては、異なるディレクトリに連関エンティティに見立てたものを構築すれば可能であるが、ディレクトリィ本来の使い方ではない様に思える。
• 各階層に同じ属性を持つことが可能なため、更新時に同期更新を意識する必要がある。(例：組織、組織単位、人の属性に国名を指定した場合等)このあたりは、DBにおける正規化に近い検討が必要と思われる。
• RDBと比較した場合、同時更新制御、複数トランザクション制御等の性能は未知数であり、頻繁に更新を行うデータをディレクトリに配置する場合は、十分検討の上、採用することを希望する。
• スキーマのメンテナンスは、RDBに付属するコマンドインタプリタ(OracleでいうSQL*Plus)等が付属しないツールが多いため、スキーマの変更が発生する可能性が高いデータに関しても十分検討が必要である。
• 基本的にツリー構造でデータ構造を表現するため、ツリー構造で表現しにくいデータをディレクトリに採用するには、十分検討が必要である。
• ディレクトリを設計するための明確な方法論が現時点では見つかっていない。RDBの様な確固たる設計手法が存在するわけではないので、慎重に設計することを期待する。
• 調査したディレクトリサーバにデータ入力するには、LDIF形式のファイルから読み込む必要がある。LDIF形式のファイルはASCIIテキストであり、内容を見ることは可能だが、視覚的にディレクトリ構造を捉えて作成することはできず、テキストエディタ等から生成するしか現状では方法がない(データ一件毎の追加削除を行うAPIは提供される)。
• 一般のディレクトリサービス関連の書籍は、まず最初に、ディレクトリサービスとRDBが異なることを論じていることに注意されたい。


 

結論

調査の結果からは、ディレクトリには認証に必要な最低限の情報を保持するのがよいと思われる。ディレクトリ構成も下記の図の様な形で表現でき、属性間に複雑なリンク関係がない程度に範囲を限定するとよいと思われる。