データベースの正規化について質問させて頂きたいのですが、どの程度まで正規化をしたら良いのでしょうか?
これ以上はやりすぎとか、こういう場合は重複する値が同一テーブルに多数生まれるけど、正規化しないみたいな判断基準とかってありますか?
都道府県名とか市区名も都道府県テーブル、市区テーブルをそれぞれ作った方が良いのでしょうか?
気になる質問をクリップする
クリップした質問は、後からいつでもMYページで確認できます。
またクリップした質問に回答があった際、通知やメールを受け取ることができます。
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
回答5件
0
ベストアンサー
端的に言えば、使い方次第です。
たとえば、同じ住所でも「緊急連絡先」のような、「保存・確認・削除ができればそれでいい、検索はしない」ような項目であれば、正規化を行ってもあまり値打ちはありません。また、「須恵町/須惠町」とか「鎌ヶ谷市/鎌ケ谷市」のような表記ゆれまで元の通りに再現したい、というのであれば、それは正規化できないことになります。
逆に、「特定の地域だけにセールをかけたい」というような場合には、都道府県・市区町村単位で正規化はしておいたほうがいいかなと思います。総務省が市区町村にコードを振っていますので、特殊な理由がなければそれをマスターにすれば確実です。
なお、市区町村以下の住所は千差万別ですので、GISシステムのような「それ専門のシステム」以外では、パースすら困難な作業となります。正規化など望むべくもありません。
投稿2017/05/11 01:04
総合スコア145121
0
”正規化”で検索して出てくる通り、論理設計では第三正規化までが基本になります。
ただし、データ容量や検索効率を考え、実際の検索方法で不都合の可能性を許容する場合があります。
この時の基準は、ケースバイケースとしか言えません。
住所に関しては、ユーザーが登録した住所に商品を発送するという業務であれは、正規化しないというのも手段です。地域ごとに細かく統計情報をとったり、配送ルートを考えるなどの業務がある場合は正確性のために正規化することも考えたらよいとおもいます。
投稿2017/05/11 00:50
編集2017/05/11 00:56総合スコア2883
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
2017/05/11 03:49
0
考え方としては
- HTMLでのセレクトボックスで選ばせるか
- 直接テキストボックスで入力させるか
の差。
UIとしてセレクトボックスで都道府県名を選ばせたほうが入力のブレなどないが
例外要素が発生した場合など柔軟性にかける。
とくに都道府県名は数十年普遍できているので正規化のメリットは高いが
市区町村名になると
- 名称がかわる可能性がある
- 統合や廃止になる可能性がある
- 変更された場合でも古いままの情報を保持したい
など考えるとテキストで持ったほうが有利。
とはいえ統計をとるなら正規化がある程度必須
要求定義・要件定義をするなかで方針はきめていくことです。
投稿2017/05/11 01:14
総合スコア114572
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
退会済みユーザー
2017/05/11 03:30
2017/05/11 03:44
退会済みユーザー
2017/05/11 05:51
2017/05/11 05:59
0
サービス毎に「どこまでデータに関心を持つか」を考えますね。
例えば、あるサービスで会員データを管理する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 01:15
編集2017/05/11 01:23総合スコア5405
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
退会済みユーザー
2017/05/11 03:34
0
メンバー100人くらいの管理ならかなりラフで構いませんが、都道府県や区市町村の管理をきちんとしなければならないシステムではそれなりのコストがかかりますから、使えるものを使います。
全国地方公共団体コード
投稿2017/05/11 03:52
総合スコア16415
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
あなたの回答
tips
太字
斜体
打ち消し線
見出し
引用テキストの挿入
コードの挿入
リンクの挿入
リストの挿入
番号リストの挿入
表の挿入
水平線の挿入
プレビュー
質問の解決につながる回答をしましょう。 サンプルコードなど、より具体的な説明があると質問者の理解の助けになります。 また、読む側のことを考えた、分かりやすい文章を心がけましょう。
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
退会済みユーザー
2017/05/11 03:25
退会済みユーザー
2017/05/11 03:28
2017/05/11 04:12
退会済みユーザー
2017/05/11 05:52