■ 名前付けモデル

おね〜さんと、

ほげたんのっ!!

3 Minutes Networking、

Supplement !!

ん〜。前回、LDAPのモデルについて話をしたわね。

プロトコルモデル、情報モデル、名前付けモデル、機能モデル、セキュリティモデル、だったよね。

そうそう。LDAPを説明するのに、まぁ、簡単に言うと5つの側面から見てみましょうって話ね。
ででで、プロトコルモデル、情報モデルの話をしたところで前回が終わったわけ。

でした。

さて、まず今回は「名前付けモデル」の説明をするんだけど、ほげたん、前回でてきたDITは覚えてる？

[Directory Information Tree]。DNS名前空間みたいな木構造のやつでしょ？

そう、エントリを格納する木構造がDITだったわね。
で、ほげたん？ こういうデータ、LDAPだとエントリって呼ぶわけだけど、エントリを格納するのに必要なことは？

…？ 曖昧すぎてわかんないよ、おね〜さん。

ん〜、そうね。多くのエントリを格納します。格納するのはいいんだけど、識別できないと困るわよね。入れたらお終いじゃないんだから。LDAPは、エントリを検索したりするためにあるんだから。

識別？ DITに格納されているエントリを探し出すために、何か必要ってこと？

そういうこと。って、わけで識別するための「名前」をつける必要があるっていいたいわけなのよ、これが。

まぁ、「名前」をつけるのが一番簡単かな？ 確かに。

■ 相対識別名と識別名

でしょでしょ。そういうわけなので、エントリに名前をつけます。ここで登場する名前は2つ。
まず、RDN。

相対識別名？

うん。同じ上位エントリを持つ下位エントリを識別する属性ね。
もちろん、同じ上位エントリを持つエントリの中で、ユニークな名前じゃなきゃだめよ。

この例だと、同じ「一課」って上位エントリを持つ、2つのエントリがあって、そのエントリの属性の中で、「名前」って属性をRDNにしてるわけね。これで2つのエントリが識別できるようになった、ってわけ。

でも、おね〜さん。同名の人がいる場合はどうするのさ？

ん、そうね。この場合だと「名前」をRDNの属性として選んだのは失敗、ってことになるわね。
もしくは、複数の属性を組み合わせて、RDNにするって方法もあるわね。

へ〜。例えば、「名前」+「住所」でRDNにするとか？

そうそう。上位エントリに所属する中でユニークになればいいわけ。
で、こう考えていくと、「一課」っていうのは「営業部」エントリの中で識別されるRDNだってことになるわね。

そうだね。「営業部」ってのも「ABC商事」エントリ内で識別するためのRDNってことだよね。

そゆこと。つまり、エントリはRDNを持ち、それで上位エントリ内で識別されるってことね。

「同じ上位エントリを持つエントリの中で」「識別する」ための属性が、RDNってことだね。

そうそう、そういうこと。

で、さっき「登場する名前は2つ」って言ってたけど、もう1つは？

うん。で、このRDNを理解した上で、もう1つの名前である、DNの登場となるわけ。

識別名？ RDNは「相対」識別名だけど、相対がつかない識別名？

相対がつかない識別名がDN。相対ってどういう意味？

絶対の反対語で。何か基準があって決まるってこと？ 絶対は基準がなくても「これ」ってきまることだから。

そうよね。つまり、RDNは「上位エントリ」という基準点があって、そこで識別される名前なわけよね。
一方、DNは基準点がなくても、決まる名前、つまり、DITでユニークになる絶対的な名前ってこと。

こんな風に、エントリからルートへ向かう途中にある上位エントリのRDNをすべて記述したものがDN。
これなら、DITの中でユニークな名前になるでしょ？

うん、確かに。RDNは上位エントリの中でユニークだから、それを繋げていけばユニークになるよね。
で、下のエントリを先頭に書いていくんだね。ドメインネームっぽいね。

そうね、考え方としてはドメインネームと一緒でいいかも。
サブドメイン内でユニークな名前がRDN、FQDNがDN。書き方もサブドメインから先頭に書いていくし。

だよね。

■ RDNとDNの表記

ん。でね。図はわかりやすい例で書いているけど、実際の正確な書き方はちゃんと決まってるの。DN、RDN共通で、書き方は次のように書くわけ。

属性型名？

属性には型があるって話は前したわよね。え〜っと、そうコレコレ。

なんだっけ、「属性値が取りうる値や検索の際の条件」を決めておくもの、だっけ？

そう。上の図だと、属性型名「名前」はデータの形として文字列で、検索条件は完全一致、部分一致が使えるって意味なわけ。

うんうん、了解。

で、よく使われる属性型として、まぁ、いずれまた説明するけど、次のようなものがあるわ。

他にもあるけど、これぐらいは覚えておいてね。
例えば、上の図の太山田一郎さんを表すRDNはこうなるの。

エントリのRDNは、属性「cn」の属性値「太山田一郎」だってこと？

そうそう。DNの方はこんな感じ。

なるほどだよ。

ちなみに、複数の属性でRDNを作っている場合はこうなったりするわけ。

cn＝012345は太山田一郎さんの社員番号ね。「＋」で複数の属性がRDNになってることを示すってことね。

cnが2つあるけど、いいの？

それは問題ないわ。エントリに名前がいくつあってもいいの。例えば、名前と読みとローマ字表記と…って感じでね。
RDNにするのはどれかを決めておけばいいわけ。詳しくはまた話すわね。

了解です。

■ 別名

さてさて、識別できる名前をエントリにつけるわけだけど。
識別したい名前が複数ある場合とかもあるわけよ。

？ 例えば？

例えば〜、営業一課の部長さんは、営業二課の課長さんも兼務してるとか。

忙しい人だね。

こうなると、営業一課にあるエントリと同じエントリを営業二課の下位エントリとして配置したいわけでしょ？
でも、そうすると同じものが2つできちゃうので望ましくない、と。

まぁ、そうかも。ディレクトリサービス上では同じ人間が2人いることになっちゃうもんね。

そこで使うのが別名エントリ。

営業一課の太山田一郎さんは、営業二課にも所属している？

そう。基本的に別名エントリは、ホンモノのエントリの位置を「参照」する属性が入っているわけね。だから、営業二課の太山田一郎さんを探し出すと、営業一課の太山田一郎の情報が入手できる形になるわけよ。

ふむふむー。

ただし、別名エントリは「葉(リーフ)」であることが絶対条件。

葉って、あれだよね、下に下位エントリをもたないエントリのことだよね。

うん、そうよ。
後はねぇ、名前付けモデルで覚えておいて欲しいことといえば、名前付けコンテキストかな？

コンテキスト？ なにそれ？

コンテキストは本来の意味は「文脈」「文章の前後関係」って意味。

「名前の文脈」？ ますます意味がわからないよ。

LDAPでは、そのディレクトリサーバが管理するエントリの集合体って意味で捉えるのがいいかな？ もしくはそのエントリの集合体での名前とか？

サーバが管理するエントリの集合体？ それってDITと違うの？

DITは、一番上のrootがあるでしょ？ ルートエントリは特別なエントリで、サーバ用の情報エントリだから含まれないの。

例えば、ABC商事のディレクトリサーバは、ABC商事全体、その下位の営業一課、二課をそれぞれ管理する3台のサーバから構成されてるとするわね。
この場合、営業一課の名前付けコンテキストっていったら、緑の範囲を示すのよ。

サーバが管理する範囲？

DITは、ディレクトリ全体を現すけど、名前付けコンテキストはそうじゃない、ってことかな？
名前付けコンテキストはその最上位のエントリのDNで表現されるわ。

ん、んーっと、例えばABC商事全体の名前付けコンテキストは「o＝ABC商事，c＝JP」っていうコンテキスト、とかいう風に表現するってこと？

そうそう。「o＝ABC商事，c＝JP」コンテキストっていったら、橙の範囲のエントリ群のこと、って意味になるわけ。

ははぁ。

これでディレクトリサーバが管理する範囲を決めて、ディレクトリを複製する時なんかに使うのよ。サフィックスって呼んだり、ディレクトリパーティションとも呼んだりするわ。

DNSのゾーン？

ん〜、そうね、それが一番わかりやすいかも。そのネームサーバが管理する範囲を示すのが、DNSでのゾーン。
それと同様に、ディレクトリサーバが管理する範囲が名前付けコンテキスト。うん、いいわね。

ゾーンが管理してる範囲、つまりドメインとして「abc.co.jp」があるように。
名前付けコンテキストだと、「o＝ABC商事，c＝JP」っていうって感じでいいのかな？

そうね、それでいいと思うわ。
さて、他のモデルは次回にしましょ。

あいあい。

じゃ、また次回。
おね〜さんと、

ほげたんのっ!!

3分間ネットワーク、

サプリメントでした〜〜〜っ!!