dポイントプレゼントキャンペーン実施中!

最近自作サイトを作っているのですが、DBの設計がちゃんと正規化されているか自信がありません。
そこで今考えているDBのテーブル設計を書かかせていただきますので、あっているかどうかチェックしていただきたいと思って投稿しました。

例えば電子書籍のDBを設計するとして、
・漫画IDタイトルタグページ数アクセス数Upload日Update日
こんなテーブルがあったとして、タグには複数の項目が入るので、第一正規化を適用して
・漫画IDタイトルタグIDページ数アクセス数Upload日Update日
・タグID タグ
の2つにわけました。ここで2つ疑問があります。

まずタグIDとタグからなるテーブルですが、これの主キーはタグIDとタグですよね?
これは主キー以外にレコードは無いんですが、こういう設計はまちがっていませんか?

次に、もう一個のテーブルがやけに長いというか第2正規化できるような気がするのですが、
部分関数従属するカラムは見当たりません。(例:ページ数が決まったかといって、アクセス数が決まるわけではない。 つまり全て漫画IDに完全関数従属している)。これであっているでしょうか?

ご回答お待ちしております。

A 回答 (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日))

参考URL:http://www.techscore.com/tech/sql/SQL16/16_02.html
    • good
    • 0
この回答へのお礼

お返事ありがとうございます。

<<いずれにせよ、1つの漫画が複数のタグにひも付くのであれば、下記の様に漫画IDとタグのテーブルを作るのが自然でしょう。
なるほど、確かにわざわざタグIDなんて作ること無かったですね。盲点でした。

<<アプリケーションの仕様まで含めた観点であれば、いくつか考えられます。
なるほど、結局はそのDBがどの様に使われるかを想定して、それに適したようにテーブルを分けるのがいいんですね。

ご丁寧な回答ありがとうございまいした。勉強になりました。

お礼日時:2012/04/01 18:18

お探しのQ&Aが見つからない時は、教えて!gooで質問しましょう!

関連するカテゴリからQ&Aを探す