- ベストアンサー
データベースの正規化について
- データベースの正規化についての質問です。第一正規化、第二正規化、第三正規化の手順を経て、テーブルがどのように変化していくかについて教えてください。
- 質問者は受注情報のデータベースを正規化する作業を行っていますが、模範解答と自分の結果が異なることに疑問を持っています。どこで間違っているのか、間違えている場合の理由を教えてください。
- 質問者は第一正規化、第二正規化、第三正規化の手順に従ってテーブルを分解していますが、最終的には商品コード、商品名、販売単価のテーブルに受注情報が収納されています。この結果で合っているのか、それとも他のテーブルが必要なのかについて教えてください。
- u_f_o_pech
- お礼率15% (5/33)
- その他(データベース)
- 回答数3
- ありがとう数1
- みんなの回答 （3）
- 専門家の回答
質問者が選んだベストアンサー
実務レベルと、学習レベルだと模範になるモデルはかわってきます。 今回は学習レベルということでよろしいですか？ 実務レベルではご提示のようなデータの持ち方はありません →受注番号 受注日 得意先コード 得意先名 得意先住所 ｛商品コード 商品名 販売単価 受注数量 受注金額｝ (1)受注番号をプライマリとして処理するかどうか 通例、受注番号はユニークですが、特定の受注を修正する必要が出た場合 履歴の問題から受注番号を新たに振りなおす必要がでてきます。 それはビジネス的にはナンセンスなので、プライマリーなIDを別途もたせるか 枝番をつけるかのどちらかになります。 (2)得意先コードと得意先名、得意先住所は学習レベルでは正規化すべき項目ですが 実務レベルでは正規化できません。 つまり得意先の名前や住所は普遍性がなく、変わる可能性が高いからです。 逆に名前や住所がかわるたびに得意先コードを振りなおすケースもありますが そうすると集計性がそこなわれます。場合によってはこれも枝番を発行したりする ケースになるかもしれません。 (3)同様に商品コードは受注番号にひもづくとして、商品名は普遍性があると みて正規化することができるかもしれません、販売単価と受注数量は受注番号 に依存するものなので正規化対象ではないでしょう。 近年の傾向から消費税も変動的なものなので、税金も受注番号ごとに持たせる 必要がでてくると思います。 （実際は期日と税テーブルで対応は可能ですが集計を簡素化するためには有効） 受注金額も集計のため持たせるのが実務的ですが、計算結果なので学習レベルでは もたせる必要はありません。 (4)販売単価についてもマスター化できますが、ビジネスにおいては販売単価は ころころ変わります。当然実務レベルでは個別にもつのが常識で、学習レベルでは 商品マスターに埋め込めるかもしれません。 あわせて粗利なども個別受注ごとに持たせた方が集計はしやすくなります。 総じて・・・きっちりやるなら [販売データテーブル] *オリジナルID 受注番号 受注日 作成日 更新日 得意先コード 得意先名(受注時) 得意先住所(受注時) 商品コード 販売単価 受注数量 受注金額税抜 税額 受注金額税込 削除フラグ [得意先テーブル] *得意先コード 得意先名 得意先住所 注)結局名前と住所は二重でもつことになる [商品テーブル] *商品コード 商品名 となり、ざっくりとするなら [販売データテーブル] *受注番号 受注日 得意先コード 商品コード 受注数量 [得意先テーブル] *得意先コード 得意先名 得意先住所 [商品テーブル] *商品コード 商品名 販売単価 みたいな持ち方になるでしょうか・・・
その他の回答 (2)
- jjon-com
- ベストアンサー率61% (1599/2592)
> 自分が間違えているのでしょうか？ > もし間違えているなら理由を教えて下さい。 間違っています。 「＊商品コード 商品名 販売単価」という表の各項目の関数従属の矢印は， 「ある商品コードに対して，商品名は一意に決まる」 「ある商品コードに対して，販売単価は一意に決まる」 の２つです。この表には推移関数従属が含まれていませんから，第三正規形への変形過程はありません。 部分関数従属性を排除する第二正規形の例 http://itpro.nikkeibp.co.jp/article/lecture/20061128/255079/?SS=imgview&FD=7256014 推移関数従属性を排除した第三正規形の例 http://itpro.nikkeibp.co.jp/article/lecture/20061128/255079/?SS=imgview&FD=9103056
- notnot
- ベストアンサー率47% (4900/10358)
商品名はユニークとは限らないので、キーにするのはおかしいです。 あるいは、ご自分でも、そこをわけてるのに、 ＊得意先コード 得意先名 ＊得意先名 得意先住所 にしなかった理由を考えればわかるのでは？
お礼
詳しい解説ありがとうござます。 納得できました。