質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

ただいまの
回答率

91.39%

  • PHP

    15129questions

    PHPは、Webサイト構築に特化して開発されたプログラミング言語です。大きな特徴のひとつは、HTMLに直接プログラムを埋め込むことができるという点です。PHPを用いることで、HTMLを動的コンテンツとして出力できます。HTMLがそのままブラウザに表示されるのに対し、PHPプログラムはサーバ側で実行された結果がブラウザに表示されるため、PHPスクリプトは「サーバサイドスクリプト」と呼ばれています。

  • SQL

    1687questions

    SQL(Structured Query Language)は、リレーショナルデータベース管理システム (RDBMS)のデータベース言語です。大きく分けて、データ定義言語(DDL)、データ操作言語(DML)、データ制御言語(DCL)の3つで構成されており、プログラム上でSQL文を生成して、RDBMSに命令を出し、RDBに必要なデータを格納できます。また、格納したデータを引き出すことも可能です。

  • データベース設計

    95questions

    データベース設計はデータベースの論理的や物理的な部分を特定する工程です。

DB設計時、個々の項目についてどんなときにIDを設定するべきか

解決済

回答 5

投稿 2017/11/22 15:50

  • 評価
  • クリップ 1
  • VIEW 344

ark0214

score 36

前提

以下のようなリストがあります。

観光地 住所 電話番号 地域 種類
有馬温泉 xxx xxx-xxxx 近畿 温泉
彦根城 xxx xxx-xxxx 近畿
白浜温泉 xxx xxx-xxxx 近畿 温泉
大原美術館 xxx xxx-xxxx 中国 美術館
道後温泉 xxx xxx-xxxx 四国 温泉
丸亀城 xxx xxx-xxxx 四国
大塚国際美術館 xxx xxx-xxxx 四国 美術館

観光地・住所・電話番号はユニークですが、地域・種類は重複があります。
地域・種類に付随する情報はありません。
最終的に、PHPを使ってリスト状に出力します。
そのとき、地域の項目ごとにリストを分割予定です。
例で言うと、近畿・中国・四国はそれぞれ別のリストになります。

悩んでいること

上の図から地域・種類を取り出して

地域ID 地域
1 近畿
2 中国
3 四国
種類ID 種類
1 温泉
2
3 美術館

にするべきなのか悩んでいます。

SQLの本を読んでいると分割するように書かれていますが、
中身のないテーブルが無限に増殖しそうです。
一方でIDを設定しておいた方が後々条件式などが書きやすそうです。
今回だと最終的に地域名を配列で取得することになりそうなので、そこだけでも別テーブルにしておくべきでしょうか。

併せて、
この件について検索エンジンで調べたいとき、
どのようなワードで検索したらいいのか教えて頂けると非常に助かります。

  • 気になる質問をクリップする

    クリップした質問は、後からいつでもマイページで確認できます。

    またクリップした質問に回答があった際、通知やメールを受け取ることができます。

    クリップを取り消します

  • 良い質問の評価を上げる

    以下のような質問は評価を上げましょう

    • 質問内容が明確
    • 自分も答えを知りたい
    • 質問者以外のユーザにも役立つ

    評価が高い質問は、TOPページの「注目」タブのフィードに表示されやすくなります。

    質問の評価を上げたことを取り消します

  • 評価を下げられる数の上限に達しました

    評価を下げることができません

    • 1日5回まで評価を下げられます
    • 1日に1ユーザに対して2回まで評価を下げられます

    質問の評価を下げる

    teratailでは下記のような質問を「具体的に困っていることがない質問」、「サイトポリシーに違反する質問」と定義し、推奨していません。

    • プログラミングに関係のない質問
    • やってほしいことだけを記載した丸投げの質問
    • 問題・課題が含まれていない質問
    • 意図的に内容が抹消された質問
    • 広告と受け取られるような投稿

    評価が下がると、TOPページの「アクティブ」「注目」タブのフィードに表示されにくくなります。

    質問の評価を下げたことを取り消します

    この機能は開放されていません

    評価を下げる条件を満たしてません

    評価を下げる理由を選択してください

    詳細な説明はこちら

    上記に当てはまらず、質問内容が明確になっていない質問には「情報の追加・修正依頼」機能からコメントをしてください。

    質問の評価を下げる機能の利用条件

    この機能を利用するためには、以下の事項を行う必要があります。

回答 5

+3

このような、「テーブルを分けるかどうか」は、データベース正規化と呼ばれる分野です。

地域や種類に紐づくデータ(たとえば、地域名の英語名など)があれば、正規化すべき理由としてはかなり大きくなりますが、1項目の場合でも、「テーブルにしておいて外部キーを設定すれば、余計なものがリストに入ってくる心配はない」という意味でのメリットがあります。

もちろん、「種類を自由に増やしたい」というモデルだと、合わない可能性はありますし、集計しない列であれば集計のメリットも見込めません。

投稿 2017/11/22 16:05

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2017/11/27 10:51

    ご回答ありがとうございます。
    ずっと全然違う言葉で検索してました。お恥ずかしい…。

    >>「テーブルにしておいて外部キーを設定すれば、余計なものがリストに入ってくる心配はない」
    目からウロコでした。表記ゆれの防止になるのですね。勉強になりました。

    キャンセル

+2

検索するキーワードとしては、正規化 もしくは 正規形 が該当すると思います。

今回書かれている仕様だけで、将来的に拡張の予定が一切無いのであればテーブル分割を行う必要は無いかなと思います。
(IDを付けるべきかどうかは別問題で、意見が分かれるところだと思います。個人的にはつけておいた方が楽が出来ると思います)

ただ、例えば、

例で言うと、近畿・中国・四国はそれぞれ別のリストになります。

を別のリストとして出すだけならテーブルを分割する必要は無いと思いますが、
地域一覧や種類一覧を表示するケース(例えば、地域一覧から表示したい地域を選ぶとか)があったり、今は付随する情報が無くても将来的に発生する可能性があるのであれば、別テーブルとして管理すべきだと思います。

中身のないテーブルが無限に増殖しそうです。

正規化の考えに沿って(もしくは意図的に沿わずに)作られるテーブルであれば、数が増えても管理が難しくなるということにはなりにくく、再利用がしやすくなるのでテーブル数が増えることについてはあまり気にする必要は無いです。

個人的には、
正規化されたテーブルを後で非正規化するのは比較的容易ですが、逆は大変な事が多いので、
最初は「確実に正規化の必要は無い」と言い切れるところ以外は正規化してしまうという方法でDB設計をすることが多いです。

投稿 2017/11/22 16:16

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2017/11/27 10:56

    ご回答ありがとうございます。
    正規化の基準が大変参考になります。付随情報がもし来てしまった時のことを考えると、分けておいた方が無難そうですね。

    キャンセル

+1

こんにちは。もし、大量のデータが溜まった状態で、正規化の必要が出てきたとします。そのとき、たくさんの重複があるのを、正確に分割していくのは、たいへんだと思います。
その時間のかかる作業中にも、あらたなデータを入力することになると、さらにミスが出やすいですし。

最初に正規化しておくと、楽だと思います。

書店で、データーベース、SQL のコーナーに行くと、データモデリング関連の本があります。正規化の詳しい説明が書いてあると思います。

投稿 2017/11/22 19:08

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2017/11/27 10:59

    ご回答ありがとうございます。
    今は少量なので簡単に処理できるけど…ってことですね。DB設計でよく悩むので、そのあたりの本も読んでみたいと思います。

    キャンセル

+1

正規化は大切です。データベース設計全般を扱った内容が公開されているので、じっくり読まれると良いでしょう。
ゼロからのデータモデリング入門

投稿 2017/11/23 03:15

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2017/11/27 10:59

    ご回答ありがとうございます。
    ご提示頂いたURLを時間があるときに読んでみます。

    キャンセル

checkベストアンサー

0

提示されている地域や種類など、単独のマスターにするほどでも無いものは所謂、コードと言われる物です。
DBに定数として登録する方法もありますが、下記のように一つのテーブルに纏めてもおいた方が保守はしやすいですね。

コード識別 コード値 名称
地域 1 近畿
地域 2 中国
地域 3 四国
種類 1 温泉
種類 2
種類 3 美術館

補足

正規化を例にされる方が多いですが、どちらかと言うと正規化の対象から外れたものの扱いに類するものだと思います。
極端に言うと、性別を正規化して別テーブルにはしないでしょう。
一般的には、テーブル定義書などの説明に値の説明として記載されるレベルの話で、コード化してマスター管理するかどうかという話かと。

システム制御の為のコードであればマスター管理までするかどうかというのはありますが、今回の例であれば集計もされるということなので、コード化してマスター管理をお勧めします。
データからの集計だけだと、無いものは集計できませんから、0件で表示などがそのままではできません。
また文字列をコードに置き換えることで、データ量の軽減にもなります。

投稿 2017/11/23 00:44

編集 2017/11/23 14:55

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2017/11/23 02:43

    汎用機をやっていた経験が長い人がオープン系のDB設計を初めてやったシステムで少量のデータを一つのテーブルにまとめた設計をやっていたのを思い出します。

    キャンセル

  • 2017/11/23 13:39

    >Orlofskyさん
    何か弊害があったんですか?

    キャンセル

  • 2017/11/23 13:56

    ER図などが判りにくい、ってのがほとんどメンバーの意見でした。

    キャンセル

  • 2017/11/23 14:33

    成程。
    コード系のマスタはER図に登場することはあっても、リレーション線を引くことは無いですね
    代わりに、レイアウト定義に参照するコードの説明を書いたりします。
    要は辞書扱いなので。

    キャンセル

  • 2017/11/27 11:29

    ご回答ありがとうございます。また、言葉足らずの質問に対して課題を補足してくださりありがとうございます。

    今考えると、悩みは以下の2つのようです。
    ①付随情報がない項目でも正規化すべきなのか
    ②別テーブルにすることで却って読みづらくなる項目でも正規化した方がいいのか(主となるテーブルを読み解くために他のテーブルを1つ1つ参照してIDを調べて回らないといけないのは、設計として間違っているのではないか)

    今回のDBでコード化しても本当に差し支えないのか、もう一度検討してみます。

    キャンセル

15分調べてもわからないことは、teratailで質問しよう!

ただいまの回答率

91.39%

関連した質問

同じタグがついた質問を見る

  • PHP

    15129questions

    PHPは、Webサイト構築に特化して開発されたプログラミング言語です。大きな特徴のひとつは、HTMLに直接プログラムを埋め込むことができるという点です。PHPを用いることで、HTMLを動的コンテンツとして出力できます。HTMLがそのままブラウザに表示されるのに対し、PHPプログラムはサーバ側で実行された結果がブラウザに表示されるため、PHPスクリプトは「サーバサイドスクリプト」と呼ばれています。

  • SQL

    1687questions

    SQL(Structured Query Language)は、リレーショナルデータベース管理システム (RDBMS)のデータベース言語です。大きく分けて、データ定義言語(DDL)、データ操作言語(DML)、データ制御言語(DCL)の3つで構成されており、プログラム上でSQL文を生成して、RDBMSに命令を出し、RDBに必要なデータを格納できます。また、格納したデータを引き出すことも可能です。

  • データベース設計

    95questions

    データベース設計はデータベースの論理的や物理的な部分を特定する工程です。