Q&A
ご回答ありがとうございます。
正規化の基準が大変参考になります。付随情報がもし来てしまった時のことを考えると、分けておいた方が無難そうですね。
###前提
以下のようなリストがあります。
| 観光地 | 住所 | 電話番号 | 地域 | 種類 |
|---|---|---|---|---|
| 有馬温泉 | 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を設定しておいた方が後々条件式などが書きやすそうです。
今回だと最終的に地域名を配列で取得することになりそうなので、そこだけでも別テーブルにしておくべきでしょうか。
併せて、
この件について検索エンジンで調べたいとき、
どのようなワードで検索したらいいのか教えて頂けると非常に助かります。
回答5件
0
このような、「テーブルを分けるかどうか」は、データベース正規化と呼ばれる分野です。
地域や種類に紐づくデータ（たとえば、地域名の英語名など）があれば、正規化すべき理由としてはかなり大きくなりますが、1項目の場合でも、「テーブルにしておいて外部キーを設定すれば、余計なものがリストに入ってくる心配はない」という意味でのメリットがあります。
もちろん、「種類を自由に増やしたい」というモデルだと、合わない可能性はありますし、集計しない列であれば集計のメリットも見込めません。
投稿2017/11/22 07:05
総合スコア145183
0
検索するキーワードとしては、正規化 もしくは 正規形 が該当すると思います。
今回書かれている仕様だけで、将来的に拡張の予定が一切無いのであればテーブル分割を行う必要は無いかなと思います。
（IDを付けるべきかどうかは別問題で、意見が分かれるところだと思います。個人的にはつけておいた方が楽が出来ると思います）
ただ、例えば、
例で言うと、近畿・中国・四国はそれぞれ別のリストになります。
を別のリストとして出すだけならテーブルを分割する必要は無いと思いますが、
地域一覧や種類一覧を表示するケース（例えば、地域一覧から表示したい地域を選ぶとか）があったり、今は付随する情報が無くても将来的に発生する可能性があるのであれば、別テーブルとして管理すべきだと思います。
中身のないテーブルが無限に増殖しそうです。
正規化の考えに沿って（もしくは意図的に沿わずに）作られるテーブルであれば、数が増えても管理が難しくなるということにはなりにくく、再利用がしやすくなるのでテーブル数が増えることについてはあまり気にする必要は無いです。
個人的には、
正規化されたテーブルを後で非正規化するのは比較的容易ですが、逆は大変な事が多いので、
最初は「確実に正規化の必要は無い」と言い切れるところ以外は正規化してしまうという方法でDB設計をすることが多いです。
投稿2017/11/22 07:16
総合スコア18713
0
正規化は大切です。データベース設計全般を扱った内容が公開されているので、じっくり読まれると良いでしょう。
ゼロからのデータモデリング入門
投稿2017/11/22 18:15
総合スコア16415
0
ベストアンサー
提示されている地域や種類など、単独のマスターにするほどでも無いものは所謂、コードと言われる物です。
DBに定数として登録する方法もありますが、下記のように一つのテーブルに纏めてもおいた方が保守はしやすいですね。
| コード識別 | コード値 | 名称 |
|---|---|---|
| 地域 | 1 | 近畿 |
| 地域 | 2 | 中国 |
| 地域 | 3 | 四国 |
| 種類 | 1 | 温泉 |
| 種類 | 2 | 城 |
| 種類 | 3 | 美術館 |
補足
正規化を例にされる方が多いですが、どちらかと言うと正規化の対象から外れたものの扱いに類するものだと思います。
極端に言うと、性別を正規化して別テーブルにはしないでしょう。
一般的には、テーブル定義書などの説明に値の説明として記載されるレベルの話で、コード化してマスター管理するかどうかという話かと。
システム制御の為のコードであればマスター管理までするかどうかというのはありますが、今回の例であれば集計もされるということなので、コード化してマスター管理をお勧めします。
データからの集計だけだと、無いものは集計できませんから、０件で表示などがそのままではできません。
また文字列をコードに置き換えることで、データ量の軽減にもなります。
投稿2017/11/22 15:44
編集2017/11/23 05:55
総合スコア25173
汎用機をやっていた経験が長い人がオープン系のDB設計を初めてやったシステムで少量のデータを一つのテーブルにまとめた設計をやっていたのを思い出します。
>Orlofskyさん
何か弊害があったんですか？
ER図などが判りにくい、ってのがほとんどメンバーの意見でした。
成程。
コード系のマスタはER図に登場することはあっても、リレーション線を引くことは無いですね
代わりに、レイアウト定義に参照するコードの説明を書いたりします。
要は辞書扱いなので。
ご回答ありがとうございます。また、言葉足らずの質問に対して課題を補足してくださりありがとうございます。
今考えると、悩みは以下の2つのようです。
①付随情報がない項目でも正規化すべきなのか
②別テーブルにすることで却って読みづらくなる項目でも正規化した方がいいのか（主となるテーブルを読み解くために他のテーブルを1つ1つ参照してIDを調べて回らないといけないのは、設計として間違っているのではないか）
今回のDBでコード化しても本当に差し支えないのか、もう一度検討してみます。
0
こんにちは。もし、大量のデータが溜まった状態で、正規化の必要が出てきたとします。そのとき、たくさんの重複があるのを、正確に分割していくのは、たいへんだと思います。
その時間のかかる作業中にも、あらたなデータを入力することになると、さらにミスが出やすいですし。
最初に正規化しておくと、楽だと思います。
書店で、データーベース、SQL のコーナーに行くと、データモデリング関連の本があります。正規化の詳しい説明が書いてあると思います。
投稿2017/11/22 10:08
総合スコア200
あなたの回答
tips
プレビュー
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
2017/11/27 01:51