例えば、前回までにテーブル設計を考えた、図書館の貸出履歴システムでは、「同じ利用者が一度に何冊も本を借りる場合」が、容易に予想できます。
(1)すると、貸出日と利用者CDが、重複する可能性のあることがわかります。
重複するデータは、別テーブルに分けることを検討するのが基本だと、前に説明しましたね。
(2)本来なら、以下の様な形式のほうが、無駄がありません。
(3)そのためには、貸出履歴テーブルを、さらに正規化して、2つのテーブルに分ける必要があります。
・貸出No、貸出日、利用者CDで1つのテーブルにする
・書籍CDは複数あるので、明細として別のテーブルに分ける
しかしこのままでは、貸出履歴テーブルと明細テーブルに関連性がありません。また明細テーブルにも、主キーとなるフィールドが必要です。
そこで、最終的には以下のようなテーブルに分けます。
・貸出No(主キー)、貸出日、利用者CD(外部キー)
・明細CD(主キー)、貸出No(外部キー)、書籍CD(外部キー)
このような考え方は、後に学ぶ「売上伝票」を参考にすると、よく理解できます。
実は、まだまだ他にも改善点があります。
例えば、同じタイトルの本が複数冊ある場合も考えられます。これはレンタルビデオでも同じです。人気のある映画なら、同じタイトルのビデオが、たくさん入荷することはよくありますよね。
でも、今回はデータベースの基礎編なので、これくらいにしておきます。
もっと本格的なテーブル設計については、次の「売上伝票」で学ぶことにします。
