アクセスのテーブルを分ける理由に関して質問です。

質問

アクセスのテーブルを分ける理由に関して質問です。
現在参考書を利用してデータベースの勉強をしてます。
試行錯誤中で弱っています。

受注テーブル（受注コード、受注日、締切日、出荷日、顧客コード）
受注明細テーブル（受注コード、商品コード、数量）

とテーブルが分かれている例題がありました。

テーブルを２つに分ける理由がよくわかりません。
もし１つのテーブル
（受注コード、受注日、締切日、出荷日、顧客コード、商品コード、数量）
などとまとめたら何か問題があるのでしょうか？

どうぞよろしくお願いします。

回答No.5

layy

補足）
システムの核となるテーブルは分ける
受注テーブル（受注コード、受注日、締切日、出荷日、顧客コード）
受注明細テーブル（受注コード、商品コード、数量）

入力用の１次的なテーブルは１つにする。
（受注コード、受注日、締切日、出荷日、顧客コード、商品コード、数量）
という使い方はあります。

更新に必要な情報は１テーブルに格納し、個々のテーブルへはこの情報から更新させる。

別々で
更新用受注テーブル（受注コード、受注日、締切日、出荷日、顧客コード）
を入力した２日後に
更新用受注明細テーブル（受注コード、商品コード、数量）
を入力とすると同期がとれませんので
（受注コード、受注日、締切日、出荷日、顧客コード、商品コード、数量）
を一度に入力させるという意味です。

基本的には無駄のないよう正規化します。
テーブルというものなんでもかんでも分けるかというとそうでもないです。
用途によって、どういう構造にするかは変わります。

回答No.4

riveron77

顧客コードという項目があるので、顧客情報が入るテーブルがあると思いますが、いかがでしょうか？

あるとしたら…どうして顧客情報を別テーブルに入れるのか。

受注ごとに顧客の名前や住所、電話番号を受注テーブルとかに入れるのは、入力者も、また処理的にも負担がありますよね。

でも顧客コードで紐付けられれば、入力者も処理的にも楽ですよね。

#2さんとかぶりますが、要するに「また住所を入力するのかョ…」といった面倒くささが解消されますよね、入力者も処理的にも。

また顧客コードで紐付けられれば、顧客の名前や住所を受注テーブルに入れる必要がないので、
データ量のエコにも。

お礼

顧客情報が確かに別であります。
そういった意味合いだったのですね！
大変勉強になりました。
ありがとうございます！

回答No.3

nda23

実業務に就くと分かるのですが、よくあるパターンは
一つの受注で複数の製品を出荷するというものです。
例えば、プリンタの注文を貰ったとして、予備のインクや
用紙も一緒に注文されることはよくありますね。
この場合は注文：明細が１：ｎになります。質問者さんの
設計だと、一つの注文で一つの商品しか管理できません。
しかし、受注本体と明細を分け、受注コードで紐付けする
ことにより、１：ｎが実現できるのです。

お礼

実務というほどまだ勉強できていませんでしたので、
わかりやすい例をありがとうございます。
一つのテーブルでは色々制限や面倒が生じることがわかりました。
ありがとうございます！

回答No.2

root_16

簡単に言うと、分けた方が楽で便利だからです。

例の場合、1つのテーブルだと、
商品1つごとに、受注コード、受注日、締切日、出荷日等を入力しないといけませんが、
分けておけば、
受注コード、受注日、締切日、出荷日、顧客コード
は商品ごとに入力する必要がありません。

簡単なフォームを作って、
サブフォームを受注明細にしてみれば
実務的に良く分かると思います。

お礼

早々の回答をありがとうございます。
利便性を考えて作られていたのですね。
まだまだ実績が足らないのがよくわかりました。
ありがとうございます。

回答No.1

kotoby2003

リレーショナルデータベース理論を勉強してください。

そうやってテーブルを分けたりすることを正規化と呼びます。

正規化について、ここで説明するには、無理があります。

ちなみに、上記の例ではなぜダメか。

ひとつの注文に対して複数商品があったとします。
テーブルをひとつにしていたとします。
出荷日を更新するときは、さて、どうなりますか？

お礼

そうそうのご返答ありがとうございます。
リレーショナルデータベース理論の勉強もしてみます！
正規化という言葉も参考書に出てきていましたが、それに関してももう少し勉強が必要なようです。
ありがとうございました。