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

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

ただいまの
回答率

88.92%

データベースの正規化の程度について

解決済

回答 5

投稿

  • 評価
  • クリップ 1
  • VIEW 2,784
退会済みユーザー

退会済みユーザー

データベースの正規化について質問させて頂きたいのですが、どの程度まで正規化をしたら良いのでしょうか?

これ以上はやりすぎとか、こういう場合は重複する値が同一テーブルに多数生まれるけど、正規化しないみたいな判断基準とかってありますか?

都道府県名とか市区名も都道府県テーブル、市区テーブルをそれぞれ作った方が良いのでしょうか?

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

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

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

    クリップを取り消します

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

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

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

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

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

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

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

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

    質問の評価を下げる

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

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

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

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

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

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

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

    詳細な説明はこちら

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

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

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

回答 5

checkベストアンサー

+6

端的に言えば、使い方次第です。

たとえば、同じ住所でも「緊急連絡先」のような、「保存・確認・削除ができればそれでいい、検索はしない」ような項目であれば、正規化を行ってもあまり値打ちはありません。また、「須恵町/須惠町」とか「鎌ヶ谷市/鎌ケ谷市」のような表記ゆれまで元の通りに再現したい、というのであれば、それは正規化できないことになります。

逆に、「特定の地域だけにセールをかけたい」というような場合には、都道府県・市区町村単位で正規化はしておいたほうがいいかなと思います。総務省が市区町村にコードを振っていますので、特殊な理由がなければそれをマスターにすれば確実です。

なお、市区町村以下の住所は千差万別ですので、GISシステムのような「それ専門のシステム」以外では、パースすら困難な作業となります。正規化など望むべくもありません。

投稿

  • 回答の評価を上げる

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

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

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

  • 回答の評価を下げる

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

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

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

  • 2017/05/11 12:25

    ご回答ありがとうございます!!

    "「緊急連絡先」のような、「保存・確認・削除ができればそれでいい、検索はしない」ような項目であれば、正規化を行ってもあまり値打ちはありません。"



    「検索」というのは、MySQLであれば、"where 緊急連絡先 = 000-000-000"みたいに検索条件として使うという意味でしょうか?

    検索条件対象としないものは正規化のメリットがあまりないという理解でよろしいでしょうか!?

    キャンセル

  • 2017/05/11 12:28

    "市区町村以下の住所は千差万別ですので、GISシステムのような「それ専門のシステム」以外では、パースすら困難な作業となります。正規化など望むべくもありません。"



    市区町村以下の住所は千差万別というのは、どういった意味合いでしょうか?
    都道府県・市区町村単位までであれば、値が長年固定されて変動しない一方で、それ以下の単位は割と変動しやすいということでしょうか?

    つまり、コロコロ変わる値は正規化の対象には向かないということでしょうか?

    キャンセル

  • 2017/05/11 13:12

    「市町村以下の住所」ですが、地域によって「丁目+番地」だけでなく、「大字+小字+番地」、「いきなり番地」、北海道の「条+丁目」「線+号」、京都市内の「通り名住所」、さらには「無番地」や山間の観光地であれば「林班」「通称地名をそのまま住所に転用」などいろいろありすぎて、正規化するためのパターン化自体がほぼ不可能なのが実情です。

    キャンセル

  • 2017/05/11 14:52

    お〜、千差万別ですね!!いきなり番地のやつは知ってましたが他は知らなかったです!

    キャンセル

+6

”正規化”で検索して出てくる通り、論理設計では第三正規化までが基本になります。

ただし、データ容量や検索効率を考え、実際の検索方法で不都合の可能性を許容する場合があります。
この時の基準は、ケースバイケースとしか言えません。


住所に関しては、ユーザーが登録した住所に商品を発送するという業務であれは、正規化しないというのも手段です。地域ごとに細かく統計情報をとったり、配送ルートを考えるなどの業務がある場合は正確性のために正規化することも考えたらよいとおもいます。

投稿

編集

  • 回答の評価を上げる

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

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

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

  • 回答の評価を下げる

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

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

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

  • 2017/05/11 12:22

    ご回答ありがとうございます。第3段階までの正規化を基本とすれば良いのですね!

    入力時の正確性も正規化するか否かのポイントになるということでしょうか。ユーザーに手入力させるような値は正規化の対象せずに、絶対入力ミスが起こらないように選択形式になっているような値の場合は正規化の対象になるという感じですか?(正確性という点においては)

    キャンセル

  • 2017/05/11 12:49

    正確性に関しては運用次第だと思います。というのも郵便物ならば、送り先の表記のブレはある程度許されるし、戻ってきてから電話で問い合わせという手段もあります。ユーザーに入力させれば、責任はユーザーにあるので、入力の問題に関してはユーザー責にできるという点もポイントです。

    また、登録時に正確性をチェックするのと正規化して登録するのでは意味が変わってきます。正規化すると地名変更時に追従しなければならないし、最新の地名に合わせようとすると最終的には1件ずつ地図上で確認する必要が出る場合もあります。

    入力の正確さを保証するには、正規化さた住所情報で選択してもらい、非正規化(連結された文字)で登録するというやり方もあります

    このやり方を取っているある大手宅配業者で、宛先を選んだ際に〇〇町X丁目△番地とは別に〇〇町△番地となっている宛先があったが、システムには後者が存在せず入力ができなかったというケースがありました。実は町名レベルまで行くと構造化しずらいものが存在します。

    正規化を行ってから実装レベルで考えなおすのもてですが、実運用を考えないとよい設計にはならないのでご注意ください。

    キャンセル

+5

考え方としては

  • HTMLでのセレクトボックスで選ばせるか
  • 直接テキストボックスで入力させるか

の差。

UIとしてセレクトボックスで都道府県名を選ばせたほうが入力のブレなどないが
例外要素が発生した場合など柔軟性にかける。
とくに都道府県名は数十年普遍できているので正規化のメリットは高いが
市区町村名になると

  • 名称がかわる可能性がある
  • 統合や廃止になる可能性がある
  • 変更された場合でも古いままの情報を保持したい

など考えるとテキストで持ったほうが有利。
とはいえ統計をとるなら正規化がある程度必須
要求定義・要件定義をするなかで方針はきめていくことです。

投稿

  • 回答の評価を上げる

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

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

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

  • 回答の評価を下げる

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

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

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

  • 2017/05/11 12:30

    ご回答ありがとうございます!

    値が変わらないような普遍性の高いものは正規化の対象ということでよろしいでしょうか!?
    それに反して、値がよく変わったり、削除されたりするようなものは正規化の対象にはしない、またはメリットが少ないということでしょうか?

    キャンセル

  • 2017/05/11 12:44

    若干意味合いがちがいます

    普遍性の高いものは正規化をした際のデメリットの影響を受けにくいということです
    値が変わるものも正規化する意味はあって
    商品コード:100 商品名:ほげほげ
    だったとして、商品名をふがふがに変更したい場合、
    各レコードに商品コードが埋め込まれていれば、商品マスタを1箇所修正すればすべての
    該当箇所であたらしいふがふがが参照されます。

    なので正規化のための正規化をするのではなく、何か運用上の目的があって
    必要に応じて正規化をしていく・・・というのが正しいやり方です

    キャンセル

  • 2017/05/11 14:51

    その点で言えば、一括で変更することが可能性としてあるものは正規化候補になるということですね。

    キャンセル

  • 2017/05/11 14:59

    マスター管理をする意味はそうなります。
    また統計データを取る必要がある場合は、集計単位毎に条件が必要になるため
    正規化をするメリットがでてきます。
    例えば都道府県であれば県別に何件登録があるとか単純なものから、
    県別の年齢分布や購入傾向を時系列的に集計するなど正規化されていれば
    さまざまな指標がとれます

    キャンセル

+4

サービス毎に「どこまでデータに関心を持つか」を考えますね。

例えば、あるサービスで会員データを管理するUserテーブルを持つ場合。
「仮会員」「本会員」「退会会員」の3種別ある場合に、User.typeカラムに対し、1:仮会員、2:本会員、9:退会会員と定義された値を入れるとします。

この時、UserTypeテーブルを作り、このUser.typeを管理する必要があるか?と言えば、たいていの場合はNoと言えるでしょう。
typeが増減する事は考えにくく、UserTypeのカラムとしてもlabel程度しか持たないと思える故です。

仮に、UserType.id=8:ブラックリスト会員 と言うものを用意し、8と9はサービスが利用できない、と言う事にしたいとして。

id label isValid
1 仮会員 1
2 本会員 1
9 退会会員 0
8 BL会員 0

とするのであれば、UserTypeテーブルを持つ意味も出てくるとは思います。
が、「将来こういう会員種別が増える可能性があるかも知れない」と判断して、BL会員の実装前からテーブルを用意する必要はないのではないでしょうか。
(そこまで思いを馳せるのであれば、サービス事業の運営側にそういった機能の要望を要件定義時点で確認できるはず)

都道府県等の話に関しては、「神奈川県横浜市のデータ一覧」等を利用する場合は必要ですが、単にデータとして持つだけの場合は不要かと思われます。
ECサービス等で、商品の発送に利用されるのであれば正確な情報である必要もあり、細かく市区町村等切り分けて妥当性の検証を行う事も出来ますが、個人的にはそれよりも郵便番号から住所を逆引きし、それ以降のみ手入力させる形とした方が良いかと思います。

もう一つの観点としては、ユーザーの利便性を優先するという事もあります。
データの登録を分けるという事は、一般的にはデータ入力時にもそれぞれ個別に入力させる必要があります。
住所の場合、「○○県○○市○○1-1-1」等と一気に書ける項目なのに、「○○県」「○○市」「○○」「1-1-1」等とそれぞれで入力しなければならない場合、入力が面倒になってユーザーが離脱する可能性も考えられます。
住所の間違いが100件に1件程度であれば、離脱されるよりマシじゃないかなと私は考えてしまいますね。

投稿

編集

  • 回答の評価を上げる

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

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

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

  • 回答の評価を下げる

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

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

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

  • 2017/05/11 12:34

    ご回答ありがとうございます!

    会員種別の例に関してですが、増減するようなものであれば正規化の対象になるが、数が変わらないものは正規化の対象にしないでOKという理解でよろしいでしょうか?

    キャンセル

0

メンバー100人くらいの管理ならかなりラフで構いませんが、都道府県や区市町村の管理をきちんとしなければならないシステムではそれなりのコストがかかりますから、使えるものを使います。
全国地方公共団体コード

投稿

  • 回答の評価を上げる

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

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

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

  • 回答の評価を下げる

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

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

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

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

  • ただいまの回答率 88.92%
  • 質問をまとめることで、思考を整理して素早く解決
  • テンプレート機能で、簡単に質問をまとめられる

関連した質問

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