• ベストアンサー

DBのテーブルって

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

質問者が選んだベストアンサー

  • ベストアンサー
  • katuya
  • ベストアンサー率33% (38/115)
回答No.5

正規化自体の手法はきちんと確立されておりますので、誰が正規化しても元が同じなら正規化後も同じ結果になります。 「経験」が必要なのは、正規化の先「逆正規化」です。 第三正規形がデータ格納の観点から見てもっとも効率的で矛盾も生まれにくいのですが、これが必ずしもユーザ用件(レスポンスタイムなど)を満たすものではありません。 経験が必要といっても逆正規化の手法も確立されております。 書籍やRDB専門のサイトなどを参考になさってください。 正規化の手順ぐらいはすぐに見つかると思います。 ※EUC程度の規模でしたら、第三正規形で十分ですよ。

holydevil
質問者

お礼

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

その他の回答 (6)

  • katuya
  • ベストアンサー率33% (38/115)
回答No.7

>一概には言えないと思いますが・・・。 その通りだと思います。 システム設計者は、利用者の業務内容からネットワークやDBサーバへの負荷(各クエリーによるディスクアクセス数やその出現頻度まで)を考慮する必要があります。 が、ある程度高度な知識が必要のため、「正規化という基本はおさえておきましょう」程度の意味で書きました。 質問内容から勝手に規模を推測しての回答です。 誤解があったならお詫びします。 では。お勉強がんばってください。> holydevilさん

  • Binder
  • ベストアンサー率33% (5/15)
回答No.6

> EUC程度の規模でしたら、第三正規形で十分ですよ。 EUCというのはデータウェアハウスの事を言われていると思うのですが、テーブル数やデータ件数の多さ、稼働するサーバーの能力によっては、データウェアハウスでも逆正規化を行わないとレスポンスを確保できない場合もあると思いますので、一概には言えないと思いますが・・・。 必要により、検索に適した結合済の参照専用テーブルを作り、レスポンスを確保する方法もありますので、御参考までに(^o^) > holydevilさん

  • Binder
  • ベストアンサー率33% (5/15)
回答No.4

Binderです。こんばんは。 ご質問の内容のことを、専門用語で「正規化」と呼びますので、御自身で文献調査などをされるときはこのキーワードで検索を。 正規化には、第1正規形~第3正規形まであり、第3に近づくほど、”綺麗な”もしくは”美しい”データ構造になります。 ”経験でわかる”とその方が言われるのは、ある意味で、この正規化の美しさを探求する意味でもあり、それを言葉で伝えにくいのは、美術・芸術作品の良さを言い表しにくいのと似ています。 で、たまたま見つけたサイトで、他のサイトよりはわかりやすいだろうと思うのがこちらです▼ http://ha1.seikyou.ne.jp/home/hidechan/jouhou/seikikariron.html --- holydevilさんの近い将来の話になりますが、正規化を探求しすぎると、小さいテーブルが多くなり、リレーショナルを通して検索するときに、物凄く検索速度が落ちる場合があります。 いわゆる”正規化の度が過ぎた”状態です。 この度が過ぎた正規化を逆方向に緩和してあげることを、ずばり「逆正規化」といいます。 正規化と逆正規化の間で悩み、落ち着いたところが最終状態のデータ構造になるのです。

参考URL:
http://ha1.seikyou.ne.jp/home/hidechan/jouhou/seikikariron.html
holydevil
質問者

お礼

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

  • yaasan
  • ベストアンサー率22% (2710/12228)
回答No.3

 テーブルを分けることが大事なのは一つのテーブルが 大きくなりすぎないようにするためです。データ量や項目 数によって動作の悪くなる危険性がありますので、 あらかじめ予測できる大きさでテーブルごとに区切ります。  また、一つのテーブルに項目数が多すぎるとデータが 調べにくくなる事もありますので、一つのテーブルあたり の項目数を減らすためにテーブルを複数にすることもある と思います。  では、どうやって分けるかというとDBですから、 データの管理、集計が主な必要作業となってくると思い ます。その集計を一度にする項目ごとでテーブルを作成 するのが、良いかと思います。  例えば、顧客の購入品と住所を管理する場合、購入品に 関係する項目でテーブルを一つ、住所に関係する項目で テーブルを一つ、という感じで作っていっては々でしょうか?  また、なかなか初心者一人ではDBは作成できません ので周りの経験者に聞きながら作っていくのがよいでしょう。

holydevil
質問者

お礼

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

  • ARC
  • ベストアンサー率46% (643/1383)
回答No.2

とりあえず、必要なテーブルを一つ作ってみてください。作成する場所は、紙の上でも、EXCELの表でも、頭の中でも構いません。 で、そのテーブルに、テストデータを幾つか入力してみてください。 個人テーブル 氏名 都道府県 住所 ああ 鹿児島県 どこそこ いい 鹿児島県 あっち うう 沖縄県  こっち ええ 鹿児島県 むこう 同じデータを何度も入力しなければいけないフィールドはありますか?(上例では「都道府県」) そういったところが、「テーブルを分割してもいい」ポイントです。 上例の場合、分割すると、 都道府県テーブル TID 都道府県 1 北海道 2 青森県 :  : 46 鹿児島県 47 沖縄県 個人テーブル 氏名 TID 住所 ああ 46 どこそこ いい 46 あっち うう 47 こっち ええ 46 むこう のようになります。 分割前は[都道府県]フィールドに8バイト必要だったのが、分割後は1バイトで済むようになりました。また、入力ミスも未然に防げるようになりましたし、都道府県で検索する際の検索速度も上がっている筈です。 「絶対に一つのテーブルにまとめておかなければならないデータ」ってのは、理論上は存在しません。どのようにテーブルをぶった切っても、後から自由に結合して、元のテーブルに再構成できるのがRDBの特徴です。 ですから、まずは必要なフィールドをすべて備えたテーブルを作ってみて、サイズ、速度的にメリットがある部分で、テーブルを分割してやればいいのです。(あまり細かく分割しすぎても、テーブルの管理が大変です。この辺のさじ加減は、実際にやってみて経験の中で覚えるしかないと思います。)

holydevil
質問者

お礼

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

  • mnabe
  • ベストアンサー率33% (427/1283)
回答No.1

RDBの設計に関しては、それだけで本がかけてしまうくらいの(実際に売られている)量なので、私が教育された時に説明された時の記憶で、説明します。  最初、関係すると思われるデータを横一列に並べてみて、そこにデータを入れてみる。そうすると、縦に見て、同じ内容のデータが続く所があった場合には、その項目は別テーブルにして、リレーションをはるのがベターである。  また、別テーブルにしたフィールドに関し性質を書いてみる。その性質毎にまとめてみる、性質が似ている物が、テーブルを同じく出来るようなら、同じテーブルとして作ってみる。  って事を、繰り返して最適化を行えば、良い設計に近づく事が出来ると教わりました。  結局、最後に必要なのは、どれだけ設計を行って、どれだけ最適化を行ったかの経験だけですけどね(^^;  人が設計した物でも、なんでそう考えるのかを考えるだけでも、十分な勉強にはなると思いますよぉ

holydevil
質問者

お礼

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

関連するQ&A

  • テーブル定義書(Oracle) 【IX】項目

    いままではソフト系の開発を行っていたのですが、 今度、DBまわりの業務を行うことになりテーブル設計書を作成しております。 初めてなので、社内のテーブル定義書を参照しながら作成していると 番号、列名、列ID、データ型、桁数、NULL、PKの次から【IX1】...【IX10】という項目が並んでおり Googleで調べましたがインターネットエクスチェンジの略などの基本情報は載っていましたが、 実際にテーブル設計に関係のある項目かどうかは具体的に理解することは出来ませんでした。 識者の方がいれば、テーブル設計書においてこの項目の意図することはなにかを教えていただきたいです。 以上、よろしくお願いします。

  • 掲示板のDBテーブル設計について

    今phpとmysqlを使って掲示板を作ってみようと考えています。 そこでDBのテーブル設計なのですが、スレッド1つに対してレスポンス用のテーブルを1つ作るか、スレッドとレスポンスのテーブルを1つずつ作成して運用するかどちらがいいか迷ってます。 後者のレスポンステーブルを1つにまとめるのはやはりアクセスが集中しそうなのでよくないでしょうか? よろしくお願いします。

  • DB設計に要する見積もりについて

    新規のシステムで、全体の見積もりを行う中で、DBだけに注目して容量の算出、テーブル作成、正規化等プログラミングする前にいろいろやる事があると思いますが、その部分だけの作成にはどのような情報があれば、工数を算出できるのでしょうか? 勿論、テーブルの数や名前、その中の項目数や項目名、収まるデータ量なんか はDB作成以前の設計段階での工数見積もりに入ってくると思うので、ここでは DB見積もりから除外して考えております。 宜しくお願い致します。

  • テーブル設計において

    データベース(RDB)のテーブルを設計する際に、 データの連結の関係を考えた際に、連結の関係は簡単にしておいたほうがいいのかそれとも実登録データの量をとにかく少なくするように したほうがいいのかで悩んでいます。 今現在やっているのがデータベースのデータ量を少なくするためといって、非常にややこしくなっています。 正直今現在DBに登録するデータというのがテキストおよび数値データのみで、画像や動画といったバカデカイコンテンツデータは登録するようになっていないシステムにおいて、HDDやストレージがパンクするといったことがまずありえないぐらいの容量はあるんじゃないかなとおもっています。これってどうなんだろうと思って質問しています。皆さんはどう考えていますか?

  • PostgreSQLのリンクテーブル?について

    はじめまして、yossy136kgと申します。 下記の件、ご教授をお願いします。 ・TEST1というDBがあったとして、psqlより\dでテーブル一覧を参照すると、「No relations found.」と表示されます。 ・MS AccessからODBC経由でTEST1のDBのリンクテーブルを作成する際、別のDB(TEST2)のテーブルが参照できます。 例)TEST2.HOGE1、TEST2.HOGE2・・・ 【質問】 TEST1のDBからTEST2のDBのテーブルをリンクさせるようなことは可能なのでしょうか? ちなみにPostgreSQL8.2.3、CentOSです。

  • Excelのテーブル定義書からテーブルを作る方法

    Excelで作成したテーブル定義書から、自動的にDBのテーブルを 作成したいのです。 何かよいフリーウェア、または参考情報があれば教えてください。 よろしくお願いします。

  • symfony+Doctrineで複数DB(同名テーブルあり)

    symfony 1.2系でdoctrineを使って ・1つのaction内で複数のDB接続を切り替える (複数DBは同名のテーブルがある(レプリケーションDB)) ということをしたいです。 しかし、ネット上で調査しても ・DB定義をdatabases.ymlに複数書き、schema.ymlの作成を切り替える ようなことしか見つからず、方法を探しています。 もしわかる方がいらっしゃれば教えてください。 また、そもそも方法がない、またはsymfonyで上記のような複数DBを扱うための別の手段があるなど、その他の情報もあれば教えていただきたいです。 よろしくお願いします。

    • ベストアンサー
    • PHP
  • 最適なDB Table作成

    現在以下のシステムを作成しているのですが、データベース設計に悩んでいます。 システムはユーザーが自由に作成&カスタマイズできるアンケートです。 例えばデフォルトはアンケート項目が 名前 数字 年齢 数字 興味のある物 チェックボックス とします。 でユーザーはこのアンケート項目を自由にカスタマイズできます。 デフォルト時のDBでは userform ユーザーID | 変更日 | 項目 | 項目名 | 条件 | 掲載日 userid | 200812 | name/age/interestings/ | 名前/年齢/興味のある物 | num/num/cb/ | allrequired | 200901 と成っています。  ここでユーザーが名前と年齢の間にフリガナを追加した際、DBでは変更日と項目、項目名、条件が書き換えられます。 アンケートを表示すると、PHPで動作するスクリプトがユーザーのレコードを読み込み、各項目をHTMLに変換、表示します。 そしてデータを収集する方ですが、DB構成は以下になります。 ユーザID | データ入力日(int) | 結果(text) | IPアドレス データが入力されると datadb userid | 20081209 | 佐藤/25/computer | 123.123.123 となり、データ集計プログラムをブラウザで表示すると、SELECT * FROM datadb WHERE userid = "userID" と SELECT * FROM userform WHERE userid = "userID"を発行し、PHPでデータをソートし表示します。 しかし以上の構成だと、途中でアンケートの項目を追加&削除したり変更することはできず、使い勝手が悪くなります。 仮にuserformのカラムをユーザーアンケート項目の追加、削除のたびにAlterで追加、削除てしまう方法も頭に浮かびましたが、そうすると別のユーザーにもその追加したカラムを適用してしまうためNGです。 どのようにすればユーザーアビリティも保て、中規模なシステム利用でも耐えることが出来るできるDBを作成できるのでしょうか? よろしくお願いいたします。

    • ベストアンサー
    • MySQL
  • Accessでリンクしたテーブルのリレーションが設定できない

    PostgresへA5SQLとか言うツールを使ってテーブルを2つCreateTableしました。 テストデータも入力しました。 あらためてAccessでPostgresのテーブルをリンクテーブルとして参照しデータを見ることが出来ましたが、Access上でリレーションが未定義でサブフォームを作成することが出来ません。 リレーションを1:多で作成しようと思うのですが、設定フィールドが真っ白でいじれません。 何故でしょうか? 基本的にCreateTableするときに、なにやらリレーション設定する構文が必要だったのでしょうか? 今は、CreateTableしか構文は記述されていません。 どなたかご教授ください。 よろしくお願いします。

  • DB設計について

    DB設計で悩んでいます。 ある商品を評価するシステムを作っているのですが 評価の項目が6つほどあります。 そのうち 4つは数字、残りは最大で全角400字程度です。 商品の数は5000点ほどあります。 この場合5000点全てに対してテーブルを作ったほうが良いのでしょうか?