レリーショナルな設計

質問

[家族IDテーブル]
(家族ID, 家族名)
kaz001, 佐々木家
kaz002, 黒川家
kaz003, 岡本家

[個人IDテーブル]
(個人ID, 個人名)
koj001, kaz001, 拓也
koj002, kaz001, 啓太
koj003, kaz002, 直樹

[アクセスログ] (個人単位でアクセス数を引いたり家族単位で引いたりもする)
日付け、アクセス回数、家族、個人
?それとも
日付け、アクセス回数、個人

リレーショナルテーブルについて勉強しています。
[家族IDテーブル]と[個人IDテーブル]が有り、[アクセスログ]というテーブルを作る場合に、そのフィールドは
　日付け、アクセス回数、個人
よりも
　日付け、アクセス回数、家族、個人
の方が(家族単位で引く場合)高速に結果を得られると思います。
しかし、個人が分かれば家族も分かるので、前者でも使えはしますが、遅いと思うのです。
リレーショナルテーブルは、リレーショナルでないものと比べて品質が高いものだと思いますが、後者のようにしてリレーショナルでないものにして高速化するのはよい方法ですか？

回答No.1

cse_ri2 · ベストアンサー

ＲＤＢでデータを一元化しなさいと言われる理由は、データを一箇所にまとめて置くと、更新する時に一つのテーブルだけ書き換えれば済むので、システムの障害が発生しにくくなるからです。

例えば、定期的に変更がある会社の部署情報の場合、部署マスタを独立させておけば、部署名が変わっても部署マスタだけ書き換えればよいことになります。

次に質問にあるように、アクセスログに個人ID以外に家族IDも記録する方法ですが、データウェアハウスのＤＢを構築する際によく使う手法です。
データウェアハウスの場合、普通のＤＢと違って書き換えが少ないので、わざとテーブルを非正規化して、検索が高速になるように設計します。

データの変更が頻繁に発生する基幹システムではお勧めできませんが、検索が主な用途の場合は、決して悪い方法ではありません。

お礼

> 部署マスタだけ書き換え
テーブルが以下のようなら、[部署テーブル]の「開発部」を「開発担当部」に変更するだけでシステム全体に適用されるということですね。

[部署テーブル]
(部署id, 部署名)
b001, システム部
b002, 営業部

> 非正規化して、検索が高速
> 悪い方法ではありません
ＲＤＢではない方がよい場合もあるということですね。
ありがとうございます。

回答No.2

neKo_deux

> の方が(家族単位で引く場合)高速に結果を得られると思います。

データを閲覧する場合だけなら、おおむねその通りです。

ただし、データベースとして設計するのなら、データを変更、削除する場合には？って事も考慮する必要があります。

お礼

> おおむね
たとえば、「岡本家」を「岡元家」に変更するなら、後者の
　日付け、アクセス回数、家族、個人
のだと2つのテーブルを変更するので遅くなりますね。
もしかしたら、[アクセスログ] の "家族" というフィールドの各レコートの値を[家族IDテーブル] の "家族名" と同期させるようなテーブル作成の方法があるかもしれません。

> 変更、削除する場合には？
例の場合では、との程度のUPDATEがあるかや、レコード数によって、前者がよいか後者がよいか決まるものですよね？
仕様をしっかり理解しても、前者、後者のどちらがよいかを決めるには、速度のテストをするか経験による知識が必要ですね。