DBの正規化によって出てきたエンティティは、テーブルに相当するが、
このエンティティをモデル上のクラスとしていい理由というのは、
どこにも書いてないような気がするので、ちょっと書いてみました。
その理由は、正規化理論から来ると思います。以下、DBの正規化から、それを
オブジェクト指向の世界からみると、どーなるかという関係を交えつつ、書きたい
と思います。
■そもそも
そもそも、正規化とは、データベースにおいて、１事実１箇所に纏め上げる作業です。
１事実１箇所に書くために、IDを振って、一意になるように管理します。
一方、オブジェクトというのは、１つの存在であり、IDを振って管理できる
（アイデンティファイできる）ようなものです。
つまり、エンティティもオブジェクトも、IDを振って一意に管理できる存在なわけで、
そのエンティティを導き出す正規化は、同時にクラスを導き出す操作でもあるといえます。
■第一正規形をオブジェクト指向的に見ると・・
第一正規形は、繰り返しを排除しています。
繰り返している要素というのは、１個１個区別できるわけです
(１個目、２個目と区別できるから、繰り返しとわかる）
そーいうものは、繰り返し各要素が、それぞれのオブジェクトともいえます。
そこで、１個１個の存在にとりあえず分けます（分けなくてもいいけど・・）
■第二正規形をオブジェクト指向的に見ると
第二正規形は、主キーを決めています。
主キーは、IDを振って一意にする行為ですが、これはまさに、オブジェクトに
IDを振って一意にして、オブジェクトを管理している行為です。
ということで、これは、オブジェクト(クラス）を決定している行為ともいえます。
その後、第二正規形においては、複合キーの場合、キーを構成する一部のキーが
他項目と従属関係にあるかどうかチェックして、そうなっている場合、分離します。
この行為をオブジェクト指向的に考えると、キーの一部に共通性があり、それを別に
抜き出して定義できるということで、継承できる親を分離している行為になります。
■第三正規形をオブジェクト指向的に見ると
第三正規形は、推移従属関係を抜き出します。
これは、主キーがきまると、ある項目(主キー以外の項目）がきまりますが、
その項目がきまると、値がきまってしまうというものです。
これをオブジェクト指向的に考えると、
主キー項目によって、オブジェクトそのものが定義されるわけですが
そのオブジェクトの構成要素がある場合、構成要素のIDがきまってしまえば、
構成要素の属性値はきまります。そこでこの場合、その構成要素を分離している
ことになります。
つまり、オブジェクトが、他オブジェクトが集まって構成されている場合、
その構成要素ごとに分離している操作ということになります。
ただ、わざわざ、構成要素を分離しなくてもいいこともあります。
車はタイヤから出来ていますが、自動車税の計算をするときに、タイヤに分割する
必要性はありません。これが、第三正規形まで行わない、正規化崩しになってきます。
こんなかんじで、正規化の行為は、クラスを導き出す行為ともいえそうです。
なので、エンティティとモデルのクラスが一致して来るんだと思います。
アクセス
トータル
ランキング
