ＲＤＢの正規化する場合の、データモデルの作り方は、手法として確立しているといえます。
正規化して、ＥＲモデルに落とし込むわけですけど、それについては、ここで書きました。
じゃ、ＲＤＢ以外のものに関しては？
最近、NoSQLっていうんですか？それについての、データモデルはどう作るんでしょ。。。
もちろん、ＮｏＳＱＬ＝ＲＤＢ以外ということは、いろんなデータベースが考えられるわけで（ＫＶＳもそうだけど、ネットワーク型だろうが、階層型だろうが、ＸＭＬＤＢだろうが、オブジェクト指向ＤＢ・・・などなど）、いろんなデータベースがあるんだから、それに伴って、いろんなモデルがあることになりますよね。
ということで、「このモデルだあ！」という決定的なモデルが出る・・？？ってことはないと思いますけど、
「ＮｏＳＱＬのこのＤＢにおいては、こーいうデータモデルの出し方も考えられるよね！」というのは、言えそうです。今回は、それを考えます。
で、データベースに関しては、ＸＭＬデータベースを考えます。
ＸＭＬのデータベースを考えるということは、ＸＭＬの定義をしないといけないわけで、
それは、ＸＭＬスキーマになります。
前に書いたように、ＸＭＬスキーマには、デザインパターンがあって、それは、
１．ロシアンドール（ロシア人形）
２．ガーデン・オブ・エデン
３．サラミスライス
４．ベネチアンブラインド
とあるわけですが、とくに、
サラミスライスは、要素（まあ、項目だよね）を全部あげて、グローバルにします。
ベネチアンブラインドは、型（まあ、クラスだよね）を挙げていき、
要素は、ローカルに定義（隠蔽）されます。
要素＝項目を全部あげて、グローバル＝アクセス可能：共有化するっていう
サラミスライスの考えは、
項目を全部挙げてテーブルにいれ、テーブルは基本的にアクセス可能、共有化する
っていうＲＤＢの発想に似ています。
ＲＤＢ項目も、ＸＭＬにできるから、こーいう考えがあって当然なわけです。
一方
ベネチアンブラインドは、クラスごとに定義していき、要素は中に隠蔽できちゃいます。
これは、
クラスを定義して、カプセル化することによって、データ隠蔽する
オブジェクト指向の考え方に似ています。
ということは、ベネチアンブラインドのような、クラス関係で表現するような形の
データモデルが存在しえるということです。
ＸＭＬやたぶん、ＫＶＳでも・・・
図は、ＥＲ図ではなく、クラス図で表現したほうがしやすいです。
クラス図って、ＥＲ図にできるんじゃないの・・？
たしかに・・・でも、表現はできるものの、操作的には、ＥＲ関係だと、めんどっちい
ことがあります。
たとえば、いつもの例で出している電波利用の例
ここに書いてあるように、送信機には、技術基準適合証明を受けた送信機と、そうでない無線機の２種類に分かれます。
技適の無線機と、そうでない無線機では、項目が違うので、
ＥＲ図では、
送信機、
技術基準適合機種、
技術基準適合外機種
と３種類のテーブルを持ち、外部キーでつながっています。
クラス図で表すと、
送信機の下に、
技術基準適合機種、
技術基準適合外機種
の２つのクラスが継承されていることになります。
なので、表現的には、結局３種類のものが出てくる・・・ことは違いません。
ここで、Ａさんが持っている送信機は、１４４Ｍｈｚが出力できるか？というのを検索したいとします。
クラスのほうだと、送信機は、送信周波数を属性として持っているので、
Ａさんの送信機に対して、get送信周波数（）して、１４４Ｍｈｚがあるか？確かめる必要があります。
それに対して、ＥＲ図は、基本的には、集合演算操作であり、送信機の周波数を得るには、技術基準適合機種と、技術基準適合外機種の論理和をとって、そこから送信周波数の射影をとって、１４４Ｍｈｚを選択したとき、レコードがあるかどうかをしらべないといけません。
・・・ってだけでも大変なのですが、これではだめです。技術基準適合機種テーブルに、周波数はありません。
さらに、それと「発射型式周波数等」をＪｏｉｎして、・・・ってことになります。
論理和を取るってことは、Ｕｎｉｏｎをすることになります。つまり、Ｕｎｉｏｎしたり、Ｊｏｉｎしたりってことで、大変です（なので、普通このテーブルを設計するときは、正規化を崩します。崩していいことは、いつものシリーズの次あたりに書くことになります）。
つまり、クラス表現をした場合、親側にとりたいフィールドがあれば、
子供の構造とかを知らなくてもgetすれば値は取れるはずです。
なので、
・すべての構造を知らなくてもいいし（技術基準適合という概念すら知らなくていい）、
・子供の構造は、親に値を返せる限りにおいて、いろいろ変更可能です
（電波の型式によって、変調方法はかわるので、変調方式を発射型式にもって行っても、
送信機の変調方式を検索している人には、影響は出ない）。
それに対して、ＥＲ図で表現した場合、
・関係するすべての関係を知らないといけません。
（技術基準適合も知らないとＪｏｉｎできない）
・子供でも、テーブルを変えたら、大変なことになります。全部修正です
ってことで、操作的には、違いが出てきます。
設計的にも違います。
要素をすべて出す必要があるＲＤＢは、ボトムアップのほうがやりやすいはずです。
トップダウンでも、ボトムまで下がって、全部の資料が出ないと、要素が決定できません。
もし、全部の資料が出ないで、途中の資料をもとに、ＲＤＢを設計、プログラミングしてしまうと、
残りの資料が出てきたとき、「あ、前のテーブル書き換えないと・・・」ってなったときに、
それに関するテーブルのプログラムすべてに影響を与え、二度手間、三度手間、
さらに、それに伴う混乱が生じます。
なので、この手法を行う場合は、すべてのデータが出揃ってから、次の工程に入るという
ウォーターフォールが向いています。
一方、クラスでやるのなら、
トップダウンで、段階的に詳細化していっても、親クラスのメソッドを呼び出している限り、
詳細化した子クラスに変更があっても、適切な値を返せば、変更は吸収できることになります。
なので、この手法を行う場合は、すべてのデータはそろう必要はなく、逐次開発できることになります。
アジャイルが向いています。
っていうことになります。
このことを押さえていなかったから、電子政府は悲惨的な結果になっていくんだけど
（そして、まだまだ悲惨になる可能性を秘めているんだけど）
それについては、またこんど・・・
アクセス
トータル
ランキング
