第 2 章   ディレクトリデータの設計


ディレクトリに格納されるデータには、ユーザ名、電子メールアドレス、電話番号、ユーザが所属するグループの情報など含まれます。ほかのタイプの情報が含まれる場合もあります。ディレクトリ内のデータのタイプによって、ディレクトリの構成方法、データへのアクセスが可能なユーザ、およびアクセスの要求方法と応答方法が決まります。

この章では、ディレクトリデータを計画するときの問題点と手法について説明します。この章は、次の節で構成されています。

• ディレクトリデータの概要

• ディレクトリ要件の定義

• サイト調査の実施

ディレクトリデータの概要

---

データのタイプによっては、ディレクトリに適したものとそうでないものがあります。ディレクトリに入れるのに最適なデータには、次のような特性があります。

• 読み取り回数が書き込み回数より多い

  ディレクトリは読み取り操作用にチューニングされているため、書き込み操作はサーバの性能を低下させます。

• 属性 - データの形式で表現可能 (たとえば、surname=jensen)

• 多くのユーザにとって重要である

  たとえば、社員の名前やプリンタが実際に置かれている場所は、多くのユーザやアプリケーションにとって重要です。

• 複数の場所からアクセスされる

  たとえば、ある社員のアプリケーションの環境設定は、そのアプリケーションだけがこの情報にアクセスできればよいため、ディレクトリには適しません。ただし、このアプリケーションにディレクトリから環境設定を読み込む機能がある場合は、環境設定情報をディレクトリに入れておくと、別のサイトでそのアプリケーションを使用するときに自分の環境設定をディレクトリから読み込めるので便利です。

ディレクトリに格納できるデータ

次に、ディレクトリに格納できるデータの例を示します。

• 電話番号、住所、電子メールアドレスなどの連絡先情報

• 社員番号、役職、管理者 ID、業務に関する利害関係などの記述的な情報

• 電話番号、住所、管理者 ID、業務についての説明などの組織の連絡先情報

• プリンタの設置場所、プリンタの機種、プリンタの印刷速度などの機器に関する情報

• 会社の取引先、得意先、顧客などの連絡先情報と明細書情報

• 顧客名、期限、作業内容、価格情報などの契約情報

• ユーザのソフトウェアの環境設定情報や構成情報

• Web サーバへのポインタ、特定のファイルやアプリケーションのファイルシステムなどの資源の場所

サーバ管理以外でも Directory Server を使用する場合は、ディレクトリにどのような情報を格納するかを決定する必要があります。たとえば、次のタイプの情報を含める場合もあります。

• 契約や顧客アカウントに関する情報

• 給与データ

• 物理的なデバイス情報

• 自宅連絡先情報

• 企業のさまざまなサイトに関する職場連絡先情報

ディレクトリに含めないデータ

Directory Server は、クライアントアプリケーションが読み取りや書き込み (頻繁ではない) を行う膨大な量のデータを管理することは得意ですが、画像やほかのメディアなどの構造化されていない大きなオブジェクトを処理するようには設計されていません。このようなオブジェクトは、ファイルシステムで管理する必要があります。ただし、ディレクトリには FTP、HTTP、またはほかのタイプの URL を使用して、このようなタイプのアプリケーションへのポインタを格納することはできます。

ディレクトリは読み取り操作で効果を発揮するので、頻繁に更新させる情報はディレクトリに入れないようにします。ディレクトリで実行される書き込み操作の回数を減らすことにより、検索処理全体の性能が向上します。

ディレクトリ要件の定義

---

ディレクトリデータを設計するときは、現在必要なデータだけでなく、将来含める可能性のあるデータも決定しておきます。設計の段階で将来ディレクトリに必要となる要件を考慮することが、ディレクトリデータを拡張したり分散させる際影響します。

設計時には、次の点を考慮してください。

• 現時点でどのようなデータをディレクトリに入れるか。ディレクトリの導入により解決したい当面の問題は何か。使用するディレクトリ対応アプリケーションですぐに必要となるデータは何か

• 近い将来どのようなデータをディレクトリに入れるか。たとえば、使用している会計パッケージが現時点では LDAP に対応していないが、近い将来 LDAP に対応することがわかっている場合など。この場合、アプリケーションで使用するデータを判別しておき、その機能が利用可能になったときに、データをディレクトリに移行するようにする

• 将来ディレクトリに格納する可能性のあるデータがあるか。たとえば、ホスト環境の場合、新しい顧客が現在の顧客とは異なるデータを要求することも考えられる。新しい顧客が、JPEG 画像の格納にディレクトリを使用する可能性もある。これは予想される中でもっとも困難な場合であるが、考慮しておけば予想しなかった事態に対処できる。少なくとも、このような方法で計画を行っていれば、ほかの方法では思いつかなかったデータソースを特定するのに役立つ

サイト調査の実施

---

サイト調査は、ディレクトリの内容を調べ、その特性を把握するための適切な手法です。ディレクトリに入れるデータはディレクトリのアーキテクチャにとってもっとも重要です。このため、サイト調査には十分時間をかけてください。サイト調査では、次のような作業を実施します。ここでは各作業を簡単に説明し、それから詳しく解説します。

• ディレクトリを使用するアプリケーションを特定する

  導入するディレクトリ対応アプリケーションとそのデータ要件を決定します。

• データソースを特定する

  自社内を調査して、データの取得元 (PBX システム、人事部データベース、電子メールシステムなど) を確認します。

• ディレクトリに入れる必要があるデータの特性を把握する

  ディレクトリに入れる必要のあるオブジェクト (ユーザまたはグループなど) と、ディレクトリ内で管理するオブジェクトの属性 (ユーザ名やパスワードなど) を決定します。

• 提供すべきサービスレベルを決定する

  クライアントアプリケーションにどの程度までディレクトリデータの利用を許可するかを決定し、それに応じてアーキテクチャを設計します。ディレクトリデータをどの程度まで利用可能にするかによって、データの複製方法や、リモートサーバに格納されているデータに接続するための連鎖ポリシーの構成が変わってきます。

  レプリケーションについては、第 6 章「レプリケーションの設計」を参照してください。連鎖については、第 5 章「ディレクトリトポロジの設計」を参照してください。

• データマスターを特定する

  データマスターには、ディレクトリデータのプライマリソースが含まれます。このデータは、負荷均衡と回復の目的のために、ほかのサーバにコピーされている場合があります。各データについて、そのデータのマスターを特定します。

• データ所有者を決定する

  各データについて、データを最新の状態に保つ責任のあるユーザを決定します。

• データアクセスを決定する

  ほかのソースからデータをインポートする場合は、一括インポートと増分更新の両方について計画を立てます。この手法の一環として、どのデータについてもマスターは一か所に配置し、そのデータを変更できるアプリケーションの数を制限します。また、データに書き込みを行えるユーザの数も制限します。このグループのメンバー数が少ないほど、データの整合性が確保でき、管理に伴うオーバーヘッドを低減できます。

• サイト調査の結果を文書化する

多くの組織がディレクトリによって影響を受けるため、影響のある各組織からの代表者によるディレクトリ導入チームを編成することをお勧めします。このチームでサイト調査を実施します。

会社は一般に、人事、経理、製造 (1 つまたは複数)、営業 (1 つまたは複数)、開発 (1 つまたは複数) などの部署から形成されています。これらの各組織からの代表者をチームに加えると、調査を迅速に進めることができます。また、影響を受けるすべての組織が直接参加することで、部署ごとのローカルデータ保管から、ディレクトリによる集中化されたデータ管理へ移行しやすくなります。

ディレクトリ対応のアプリケーションの特定

一般的に、ディレクトリにアクセスするアプリケーションと、それらのアプリケーションで必要となるデータが、ディレクトリの内容を決定する主な原因となります。ディレクトリを使用する一般的なアプリケーションには、次のようなものがあります。

• オンラインの電話帳などのディレクトリブラウズアプリケーション。ユーザが必要とする情報 (電子メールアドレス、電話番号、社員名など) を決定し、それらの情報がディレクトリに含まれるようにする

• 電子メールアプリケーション、特に電子メールサーバ。すべての電子メールサーバで、ディレクトリで利用可能な電子メールアドレス、ユーザ名、およびルーティング情報が必要。ただし、サーバの中には、ユーザのメールボックスが格納されているディスク上の格納場所、休暇通知情報、およびプロトコル情報 (たとえば、IMAP や POP) など、さらに高度な情報を必要とするものもある

• ディレクトリ対応の人事管理アプリケーション。このアプリケーションでは、政府指定の ID 番号、自宅の住所、自宅の電話番号、生年月日、給与、役職など、個人に関する詳細な情報が必要

ディレクトリを使用するアプリケーションを調査するときは、各アプリケーションが使用する情報のタイプに注目します。次の表に、アプリケーションと各アプリケーションが使用する情報の例を示します。

表 2-1 アプリケーションが必要とするデータ

アプリケーション	データクラス	データ
電話帳	ユーザ	名前、電子メールアドレス、電話番号、ユーザ ID、パスワード、部署番号、マネージャ、メールの配信停止
Web サーバ	ユーザ、グループ	ユーザ ID、パスワード、グループ名、グループ番号、グループの所有者
Calendar Server	ユーザ、会議室	名前、ユーザ ID、広さ、会議室の名前

アプリケーションおよび各アプリケーションが使用する情報を特定すると、いくつかのタイプのデータが複数のアプリケーションによって使用されていることがわかってきます。データの計画段階でこのような課題に取り組むことで、ディレクトリ内のデータが重複する問題を避けることができ、ディレクトリを利用するアプリケーションが必要とするデータの特定に役立ちます。

ディレクトリで管理するデータのタイプと、そのデータの管理を開始する時期についての最終的な決定は、次の要因に影響されます。

• さまざまな古いバージョンのアプリケーションで必要とされるデータと、そのアプリケーションを使用するユーザの数

• 古いバージョンのアプリケーションが LDAP ディレクトリと通信できるかどうか

データソースの特定

ディレクトリに入れるすべてのデータを調べるには、現存のデータの格納場所について、次のような調査を実施する必要があります。

• 情報を提供する組織を特定する

  企業にとって重要な情報を管理している組織をすべて特定します。通常、この組織には、情報サービス部、人事部、および経理部が含まれます。

• 情報のソースであるツールとプロセスを特定する

  一般的な情報ソースには、ネットワーク用のオペレーティングシステム、電子メールシステム、セキュリティシステム、PBX (電話交換) システム、人事管理アプリケーションなどがあります。

• データの集中化が各データに与える影響を判定する

  データの管理を集中化するときに、新しいツールや新しいプロセスが必要になることがあります。集中化によって、ある組織のスタッフを増員してほかの組織のスタッフを減らすことが必要になる場合もあります。

調査中に、次の表のような雛形を用意して、企業内の情報ソースをすべて特定しておくことをお勧めします。

表 2-2 情報ソース 

データソース	データクラス	データ
人事管理データベース	ユーザ	名前、住所、電話番号、部署番号、マネージャ
電子メールシステム	ユーザ、グループ	名前、電子メールアドレス、ユーザ ID、パスワード、電子メールの環境設定
設備システム	施設	建物の名前、フロアの名前、広さ、アクセスコード

ディレクトリデータの特徴づけ

ディレクトリに含めるために特定したすべてのデータは、次のような一般的な観点から特徴づけることができます。

• 形式

• サイズ

• さまざまなアプリケーションで使用される回数

• データ所有者

• ほかのディレクトリデータとの関係

ディレクトリに含める計画のある各データをよく調査して、ほかのデータと共通している特徴を明確にする必要があります。これにより、第 3 章「スキーマの設計」で詳しく説明しているスキーマの設計段階で、時間を節約することができます。

たとえば、ディレクトリデータの特徴を記載した次のような表を作成することができます。

表 2-3 ディレクトリデータの特徴

データ	形式	サイズ	所有者	関連するエントリ
社員の名前	テキストの文字列	128 文字	人事	ユーザのエントリ
ファックス番号	電話番号	14 桁の数字	施設	ユーザのエントリ
電子メールアドレス	テキスト	多くの文字	情報システム部	ユーザのエントリ

サービスレベルの決定

提供するサービスレベルは、ディレクトリ対応のアプリケーションを利用するユーザが必要とするサービスによって決まります。各アプリケーションで必要なサービスレベルを決定するには、まずそのアプリケーションがいつどのように使用されているかを確認します。

ディレクトリの利用が進むにつれて、通常の運用レベルからミッションクリティカルなレベルまで、さまざまなサービスレベルをサポートする必要が出てきます。ディレクトリの導入後にサービスレベルを上げることは困難なので、将来の要件にも対応できる設計を初期の段階から心がけるようにしてください。

たとえば、システム全体に及ぶような障害が発生する可能性を排除する場合は、同じデータに対して複数のマスターが存在する、マルチマスター構成を使用します。次に、データマスターの特定について詳しく説明します。

データマスターの特定

データマスター (data master) は、データのマスターソースになるサーバです。データが複数の場所に存在する場合は、どのサーバをデータマスターにするかを考慮します。たとえば、複製を使用する場合、あるいは LDAP 経由で通信できないアプリケーションを使用する場合は、データが複数のサイトに分散されていることがあります。あるデータが複数の場所に存在する場合は、マスターコピーを置くサーバとこのマスターコピーから更新を受け取るサーバを決定しておく必要があります。

レプリケーション時のデータマスターの作成

iPlanet Directory Server では、複数のサーバに情報のマスターソースを置くことができます。レプリケーションを使用する場合は、どのサーバをデータのマスターソースにするかを決定します。iPlanet Directory Server では、複製のサーバが同じデータのマスターソースとなる可能性があるマルチマスター構成がサポートされています。レプリケーションとマルチマスターレプリケーション (multi-master replication) については、「レプリケーションの設計」を参照してください。

もっとも単純な構成では、すべてのデータのマスターソースを 2 台の Directory Server に置き、そのデータを 1 台または複数のコンシューマ (consumer) サーバにレプリケートするようにします。2 台のマスターサーバがあれば、1 台のサーバが故障してオフラインになったときでも安全が保障されます。より複雑な構成では、データを複数のデータベースに格納し、データの更新または検索を行うアプリケーションの近くにあるサーバが、エントリのマスターを作成するようにします。

複数アプリケーションにわたるデータマスターの作成

ディレクトリと間接的に通信するアプリケーションがある場合には、データのマスターソースについても考慮する必要があります。このような場合は、データの変更処理と、データ変更を実行する場所とを、できる限り単純に保ちます。単一のサイトでデータのマスターを作成することにした場合は、同じサイトでそこに含まれているほかのすべてのデータのマスターを作成します。このようにマスターの作成先を単一のサイトにしておくと、企業内でデータベースの同期がとれなくなった場合の障害追跡が簡単になります。

次に、データマスターの作成方法を示します。

• ディレクトリおよびそのディレクトリを使用しないすべてのアプリケーションの両方でデータマスターを作成する

  多重マスターを管理する場合は、ディレクトリやその他のアプリケーションとの間でデータをやり取りするためのカスタムスクリプトは必要ありません。ただし、一か所でデータが変更されると、ほかのすべてのサイトでもデータを変更する必要があります。ディレクトリおよびそのディレクトリを使用しないすべてのアプリケーションでマスターデータを管理すると、企業全体のデータが同期しなくなることがあります (このような状態をディレクトリが回避しようとする)。

• ディレクトリでデータマスターを作成し、iPlanet MetaDirectory を使用してほかのアプリケーションとデータの同期をとる

  さまざまなディレクトリ対応アプリケーションやデータベースアプリケーションを使用している場合は、ほかのアプリケーションと同期をとるデータマスターを管理する方法がもっとも合理的です。iPlanet MetaDirectory については、iPlanet の販売代理店に問い合わせるか、http://www.iplanet.com/ にある iPlanet の Web サイトをご覧ください。

• ディレクトリ以外のアプリケーションでデータマスターを作成してから、そのデータをディレクトリにインポートするスクリプト、プログラム、またはゲートウェイを作成する

  すでに使用しているアプリケーションの中にデータマスターを作成できるものが 1 つまたは 2 つあり、ディレクトリを検索の目的 (オンラインの企業電話帳など) にのみ使用する場合は、ディレクトリ対応以外のアプリケーションでデータマスターを作成する方法がもっとも合理的です。

データのマスターコピーの管理方法は、個々の要件によって異なります。ただし、どのような管理方法を選択しても、簡単で一貫性のあるものにしてください。たとえば、複数のサイトでデータマスターを作成し、競合するアプリケーション間で自動的にデータを交換するようなことは避けてください。そのような方法では、「最新の変更が優先される」ことになり、管理に伴うオーバーヘッドが増大します。

たとえば、ある社員の自宅の電話番号を管理する場合を考えてみます。この情報は、LDAP ディレクトリと人事管理データベースの両方に格納されます。人事管理アプリケーションは LDAP に対応しているので、LDAP ディレクトリから人事管理データベースへ、またその逆方向へデータを自動的に転送するアプリケーションを作成することができます。ここで、その社員の電話番号への変更を LDAP ディレクトリと人事管理データの両方でマスタリングすると、最後に変更した電話番号のデータが、もう一方のデータベースの情報を上書きしてしまいます。これは、最後にデータを書き込んだアプリケーションが正しい情報を持っている場合には、適切な処理として許容できます。ところが、この情報が古い場合 (たとえば、人事管理データがバックアップから再読み込みされたものである場合など) は、LDAP ディレクトリ内の正しい電話番号が削除されてしまいます。

データ所有者の決定

「データ所有者」とは、データを最新の状態に維持する責任のある個人または組織のことです。データの設計時に、ディレクトリにデータを書き込めるユーザを決めておきます。データ所有者を決めるには、一般に次の規則に従います。

• ディレクトリの内容を管理する少人数のマネージャグループを除くすべてのユーザに対して、ディレクトリへの読み取り専用アクセスを許可する

• 各ユーザが自分自身に関する重要な情報を管理できるようにする

  この情報には、パスワード、そのユーザに関する情報と組織内での役割、自動車のナンバープレート番号、自宅やオフィスの電話番号などの連絡先の情報が含まれます。

• 人に関する重要な情報 (連絡先情報や役職など) を上司が書き込めるようにする

• 組織の管理者がその組織に関するエントリを作成および管理できるようにする

  この方法では、実質的に組織の管理者が、ディレクトリの内容の管理者にもなります。

• グループ内のユーザに読み取りと書き込みのアクセス権限を与えるロールを作成する

  たとえば、人事、財務、経理などのロールを作成します。これらのロールごとに、給与情報や政府指定の ID 番号 (米国の場合は社会保障番号)、自宅の電話番号と住所など、そのグループが必要とするデータへの読み取りアクセス権、書き込みアクセス権、またはその両方を許可します。

  ロールとエントリのグループ化については、「ディレクトリエントリのグループ化」を参照してください。

データに書き込みを許可するユーザを決定するときに、複数のユーザに対して同じデータへの書き込み権限が必要になることがあります。たとえば、社員のパスワードへの書き込み権限を、情報システムまたはディレクトリ管理グループに許可するとします。同時に、社員にも自分のパスワードへの書き込み権限を許可する場合があります。複数のユーザに同じ情報への書き込み権限を与えなければならない場合がありますが、このような場合はこのグループを少人数に保ち、容易に識別できるようにします。グループを少人数に保つことにより、データの整合性を維持しやすくなります。

iPlanet Delegated Administrator を使用すると、アカウントの管理業務を分割し、組織内のさまざまなロールを持つ個々のユーザに、アカウントの管理責任を委託できます。詳細は、iPlanet の販売代理店に問い合わせるか、http://www.iplanet.com にある iPlanet の Web サイトをご覧ください。

ディレクトリのアクセス制御の設定については、第 7 章の 「安全なディレクトリの設計」を参照してください。

データアクセスの決定

データ所有者を決定したら、各データを読み取ることができるユーザを決定します。たとえば、ある社員の自宅の電話番号をディレクトリに保存することにした場合を考えてみます。このデータは、その社員の上司や人事部など、多くの組織にとって有用です。また、その社員自身が確認のためにこの情報を読み込めるようにしたい場合もあります。しかし、自宅の連絡先情報は機密事項とも考えられます。したがって、この種のデータを企業全体で広く利用可能にするかどうかを決定する必要があります。

ディレクトリに格納する各情報について、次の事項を決定する必要があります。

• データを匿名で読み取れるようにするか

  LDAP プロトコルでは匿名アクセスがサポーされているので、オフィスの場所、電子メールアドレス、会社の電話番号などの一般情報を簡単に検索できます。ただし、匿名アクセスの場合は、ディレクトリへのアクセス権を持つユーザであればだれでも一般情報にアクセスできてしまいます。そのため、匿名アクセスの使用はできるだけ避けてください。

• データを企業全体で広く読み取れるようにするか

  ディレクトリにログイン (あるいはバインド) しないかぎり、特定の情報を読み取れないようにアクセス制御を設定することができます。匿名アクセスとは異なり、この形式のアクセス制御では、ディレクトリの情報を閲覧できるユーザを組織内のメンバーだけに限定できます。また、ログイン情報をディレクトリのアクセスログに取り込めるので、情報にアクセスしたユーザの記録を残すことができます。

  アクセス制御については、「アクセス制御の設計」を参照してください。

• データを読み取る必要があるユーザグループまたはアプリケーションを特定できるようにするか

  一般に、データへの書き込み特権を持つユーザには読み取り権限も必要です (パスワードへの書き込み権限は例外)。また、特定の組織やプロジェクトグループだけが必要とするデータが存在することがあります。これらのアクセス要件を特定しておくと、ディレクトリで必要となるグループ、ロール、およびアクセス制御を決める際に役立ちます。

  グループとロールについては、第 4 章「ディレクトリツリーの設計」を参照してください。アクセス制御については、第 7 章の「安全なディレクトリの設計」を参照してください。

ディレクトリの各データに対してこれらの事項を決定する際には、ディレクトリのセキュリティポリシーを定義していることが前提となります。これらの決定は、サイトの性質と、サイトですでに利用可能なセキュリティのタイプによって異なります。たとえば、サイトにファイアウォールが使用されている場合や、インターネットに直接アクセスしていない場合は、インターネット上に直接ディレクトリを配置している場合に比べ、匿名アクセスをサポートしやすくなります。

多くの国では、データ保護に関する法律によって個人情報をどのように管理すべきかが規定されており、個人情報にアクセスする人を制限しています。たとえば、法律によって住所や電話番号への匿名アクセスが禁止されていたり、住所や電話番号を表すエントリ内の情報を閲覧、訂正する許可をユーザに与えなければならない場合があります。必ず社内の法務部に問い合わせて、ディレクトリの導入が、業務拠点としている国々の該当する法律に違反していないことを確認してください。

セキュリティポリシーの作成と導入方法については、第 7 章の「安全なディレクトリの設計」で詳しく説明します。

サイト調査の記録

データの設計は複雑なため、サイト調査の結果は文書に記録しておきます。サイト調査の各段階で、データを把握するための簡単な表を作成することをお勧めしました。決定事項と未解決の問題を概説する簡単な表を作成することを検討してください。使い慣れたワードプロセッサでこの表を作成したり、表の内容を簡単に保存・検索できるようにスプレッドシートを使用することもできます。

次に、この簡単な表の例を示します。表には、データ所有者と、サイト調査で特定した各データについてのデータアクセス権限が示されています。

データ名	所有者	マスターサーバ / アプリケーション	本人による読み取り / 書き込み	全員による読み取り	人事部 (HR) による書き込み	情報システム部 (IS) による書き込み
社員名	HR	People Soft	読み取り専用	(匿名)	○	○
ユーザパスワード	IS	Directory US-1	読み取り / 書き込み	×	×	○
自宅の電話番号	HR	People Soft	読み取り / 書き込み	×	○	×
社員の所属場所	IS	Directory US-1	読み取り専用	(ログインが必要)	×	○
会社の電話番号	施設	電話スイッチ	読み取り専用	(匿名)	×	×

社員名を表す行には、次の項目が含まれています。

• 所有者

  人事部がこの情報を所有し、この情報の更新と変更の責任を負います。

• マスターサーバ / アプリケーション

  PeopleSoft というアプリケーションで社員名に関する情報を管理します。

• 本人による読み取り / 書き込み

  ユーザは自分の名前の読み取りはできますが、書き込み (変更) はできません。

• 全員による読み取り

  ディレクトリへのアクセス権を持つすべてのユーザは、匿名で社員名を読み取ることができます。

• 人事部 (HR) による書き込み

  人事グループのメンバーは、ディレクトリ内の社員名を変更、追加、および削除できます。

• 情報システム部 (IS) による書き込み

  情報サービスグループのメンバーは、ディレクトリ内の社員名を変更、追加、および削除できます。

サイト調査の繰り返し

サイト調査は数回実施した方が良い場合があります。特に、複数の都市や国にオフィスを持つ企業の場合は、これが当てはまります。情報に関する要件があまりにも複雑なため、中央のサイトで情報を一元的に管理するよりも、複数の組織がそれぞれの現地オフィスで情報を保管するようにしなければならない場合もあります。このような場合は、情報のマスターコピーを保管する各オフィスで、独自のサイト調査を実施するようにします。この過程の完了後、中央のチーム (各オフィスの代表者で構成される) に各調査結果が戻され、企業全体のデータスキーマモデルとディレクトリツリーの設計に使用します。