- ベストアンサー
正規化したDB設計のチェックをお願いします
- 自作サイトのDB設計について正規化が適切かどうか検証してください。
- 漫画のDBを例にとって、テーブルの設計に疑問があります。
- タグIDとタグからなるテーブルの主キーについてと、第2正規化についての疑問があります。
- みんなの回答 (1)
- 専門家の回答
質問者が選んだベストアンサー
確認ですが、最初のテーブルは下記の様な7つのカラムを持つという事で良いでしょうか?その前提で書きます。 漫画ID(主キー) | タイトル | タグ | ページ数 | アクセス数 | Upload日 | Update日 分割の際に導入したタグIDは、漫画IDと1対1、タグとは1対多の関係になるという事でしょうか?そうだとすると「タグID」という名前は非常に不適切かと思います。(例えば漫画IDは1つの漫画について1つですよね?) そうでなく、タグに対して1対1になるのでしょうか?そうであれば、タグIDカラムに複数のIDが入る事になるので第一正規化にはなりません。 いずれにせよ、1つの漫画が複数のタグにひも付くのであれば、下記の様に漫画IDとタグのテーブルを作るのが自然でしょう。 漫画ID(主キー) | タイトル | ページ数 | アクセス数 | Upload日 | Update日 漫画ID | タグ (全カラムが主キー) なお、主キーしか無いテーブルが有っても問題有りません。 > これであっているでしょうか? 各カラムがどの様な意味でどの様な値を持つのか分かりませんので、以下はあくまで憶測です。 上に書いたとおり↓の様に分割したとします。 漫画ID(主キー) | タイトル | ページ数 | アクセス数 | Upload日 | Update日 漫画ID | タグ (全カラムが主キー) タイトル、ページ数、アクセス数、Upload日、Update日 は漫画IDに完全関数従属しているようには思えます。 ですので、正規化という観点からはこれ以上、分割出来ないのはないでしょうか。 アプリケーションの仕様まで含めた観点であれば、いくつか考えられます。 日ごとのアクセス数を記録するのであれば、アクセス数のカラムを除去して↓の様なテーブルを追加することでしょう。 漫画ID | 日付 | アクセス数 (主キーは(漫画ID, 日付)) また、Upload日やUpdate日の履歴を記録するのであれば、↓の様なテーブルが出来るでしょう。 漫画ID | Upload日 | 備考 (主キーは(漫画ID, Upload日)) 漫画ID | Update日 | 備考 (主キーは(漫画ID, Update日))
お礼
お返事ありがとうございます。 <<いずれにせよ、1つの漫画が複数のタグにひも付くのであれば、下記の様に漫画IDとタグのテーブルを作るのが自然でしょう。 なるほど、確かにわざわざタグIDなんて作ること無かったですね。盲点でした。 <<アプリケーションの仕様まで含めた観点であれば、いくつか考えられます。 なるほど、結局はそのDBがどの様に使われるかを想定して、それに適したようにテーブルを分けるのがいいんですね。 ご丁寧な回答ありがとうございまいした。勉強になりました。