DBのテーブルって

質問

RDBを設計する際にまずテーブルをいくつか作成して、それらどうしをリレーションしていきますよね。このテーブルをいくつか作成する意味がよくわかっていません。この項目は必ず一つのテーブルで持っておいた方が言いと言いきれる、なにか定義みたいなものはないのでしょうか？DBの知っている人に聞くと経験でわかると言われます。経験のない者はどうしたらいいのでしょう？

回答No.5

katuya · ベストアンサー

正規化自体の手法はきちんと確立されておりますので、誰が正規化しても元が同じなら正規化後も同じ結果になります。

「経験」が必要なのは、正規化の先「逆正規化」です。
第三正規形がデータ格納の観点から見てもっとも効率的で矛盾も生まれにくいのですが、これが必ずしもユーザ用件（レスポンスタイムなど）を満たすものではありません。
経験が必要といっても逆正規化の手法も確立されております。

書籍やRDB専門のサイトなどを参考になさってください。
正規化の手順ぐらいはすぐに見つかると思います。

※EUC程度の規模でしたら、第三正規形で十分ですよ。

お礼

正規化については
http://www.netlaputa.ne.jp/~hijk/study/ae/datnom.html
のサイトが非常にわかりやすかったです。ありがとうございました。理論的にテーブルを作れそうです。

回答No.7

katuya

＞一概には言えないと思いますが・・・。

その通りだと思います。

システム設計者は、利用者の業務内容からネットワークやＤＢサーバへの負荷（各クエリーによるディスクアクセス数やその出現頻度まで）を考慮する必要があります。
が、ある程度高度な知識が必要のため、「正規化という基本はおさえておきましょう」程度の意味で書きました。

質問内容から勝手に規模を推測しての回答です。
誤解があったならお詫びします。
では。お勉強がんばってください。＞　holydevilさん

回答No.6

Binder

> EUC程度の規模でしたら、第三正規形で十分ですよ。

EUCというのはデータウェアハウスの事を言われていると思うのですが、テーブル数やデータ件数の多さ、稼働するサーバーの能力によっては、データウェアハウスでも逆正規化を行わないとレスポンスを確保できない場合もあると思いますので、一概には言えないと思いますが・・・。

必要により、検索に適した結合済の参照専用テーブルを作り、レスポンスを確保する方法もありますので、御参考までに(^o^)　＞　holydevilさん

回答No.4

Binder

Binderです。こんばんは。

ご質問の内容のことを、専門用語で「正規化」と呼びますので、御自身で文献調査などをされるときはこのキーワードで検索を。

正規化には、第１正規形～第３正規形まであり、第３に近づくほど、”綺麗な”もしくは”美しい”データ構造になります。
”経験でわかる”とその方が言われるのは、ある意味で、この正規化の美しさを探求する意味でもあり、それを言葉で伝えにくいのは、美術・芸術作品の良さを言い表しにくいのと似ています。

で、たまたま見つけたサイトで、他のサイトよりはわかりやすいだろうと思うのがこちらです▼
http://ha1.seikyou.ne.jp/home/hidechan/jouhou/seikikariron.html

---

holydevilさんの近い将来の話になりますが、正規化を探求しすぎると、小さいテーブルが多くなり、リレーショナルを通して検索するときに、物凄く検索速度が落ちる場合があります。
いわゆる”正規化の度が過ぎた”状態です。

この度が過ぎた正規化を逆方向に緩和してあげることを、ずばり「逆正規化」といいます。

正規化と逆正規化の間で悩み、落ち着いたところが最終状態のデータ構造になるのです。

参考URL：

http://ha1.seikyou.ne.jp/home/hidechan/jouhou/seikikariron.html

お礼

難しいけど時間かかければ理解できそうです。（たぶん）ありがとうございました。

回答No.3

yaasan

テーブルを分けることが大事なのは一つのテーブルが
大きくなりすぎないようにするためです。データ量や項目
数によって動作の悪くなる危険性がありますので、
あらかじめ予測できる大きさでテーブルごとに区切ります。
　また、一つのテーブルに項目数が多すぎるとデータが
調べにくくなる事もありますので、一つのテーブルあたり
の項目数を減らすためにテーブルを複数にすることもある
と思います。

　では、どうやって分けるかというとＤＢですから、
データの管理、集計が主な必要作業となってくると思い
ます。その集計を一度にする項目ごとでテーブルを作成
するのが、良いかと思います。

　例えば、顧客の購入品と住所を管理する場合、購入品に
関係する項目でテーブルを一つ、住所に関係する項目で
テーブルを一つ、という感じで作っていっては々でしょうか？

　また、なかなか初心者一人ではＤＢは作成できません
ので周りの経験者に聞きながら作っていくのがよいでしょう。

お礼

ありがとうございました。やっぱりDBは経験がいるんですね。単なる知識だけで通らないだけに難しいです。

回答No.2

ARC

とりあえず、必要なテーブルを一つ作ってみてください。作成する場所は、紙の上でも、EXCELの表でも、頭の中でも構いません。

で、そのテーブルに、テストデータを幾つか入力してみてください。

個人テーブル
氏名 都道府県 住所
ああ 鹿児島県 どこそこ
いい 鹿児島県 あっち
うう 沖縄県　 こっち
ええ 鹿児島県 むこう

同じデータを何度も入力しなければいけないフィールドはありますか？(上例では「都道府県」)
そういったところが、「テーブルを分割してもいい」ポイントです。

上例の場合、分割すると、

都道府県テーブル
TID 都道府県
1 北海道
2 青森県
： 　：
46 鹿児島県
47 沖縄県

個人テーブル
氏名 TID 住所
ああ 46 どこそこ
いい 46 あっち
うう 47 こっち
ええ 46 むこう

のようになります。
分割前は[都道府県]フィールドに8バイト必要だったのが、分割後は1バイトで済むようになりました。また、入力ミスも未然に防げるようになりましたし、都道府県で検索する際の検索速度も上がっている筈です。

「絶対に一つのテーブルにまとめておかなければならないデータ」ってのは、理論上は存在しません。どのようにテーブルをぶった切っても、後から自由に結合して、元のテーブルに再構成できるのがRDBの特徴です。

ですから、まずは必要なフィールドをすべて備えたテーブルを作ってみて、サイズ、速度的にメリットがある部分で、テーブルを分割してやればいいのです。(あまり細かく分割しすぎても、テーブルの管理が大変です。この辺のさじ加減は、実際にやってみて経験の中で覚えるしかないと思います。)

お礼

わかりやすい説明ありがとうございました。ネットワーク／WEB系についてはそれなりに知識はあるんですが、DBに関しては素人です。今後もお世話になるかと思いますがよろしくお願いします。

回答No.1

mnabe

RDBの設計に関しては、それだけで本がかけてしまうくらいの(実際に売られている)量なので、私が教育された時に説明された時の記憶で、説明します。

　最初、関係すると思われるデータを横一列に並べてみて、そこにデータを入れてみる。そうすると、縦に見て、同じ内容のデータが続く所があった場合には、その項目は別テーブルにして、リレーションをはるのがベターである。
　また、別テーブルにしたフィールドに関し性質を書いてみる。その性質毎にまとめてみる、性質が似ている物が、テーブルを同じく出来るようなら、同じテーブルとして作ってみる。

　って事を、繰り返して最適化を行えば、良い設計に近づく事が出来ると教わりました。

　結局、最後に必要なのは、どれだけ設計を行って、どれだけ最適化を行ったかの経験だけですけどね(^^;
　人が設計した物でも、なんでそう考えるのかを考えるだけでも、十分な勉強にはなると思いますよぉ

お礼

なんとなくイメージがつかめました。ありがとうございました。