今更と言わず少し振り返るDBテーブルの部分従属性と推移従属性
部分従属性と推移従属性は、内容を聞けばハッと気づくが、名前を言われるとパッと分かりにくいもの。
それをサンプル含めて記載しておく。
それは何？
DBのテーブルにおける正規化をする上で考えるべき項目。
必ずやらないといけない訳ではないが、やっておく方がメンテナンス性は高まる。
パフォーマンス重視のためにあえて考慮せずに設計する場合もある。
しかし、可能であれば排除しておく方が良いので、設計時には覚えておくと良い。
部分従属性とは
複数のアトリビュートをまとめて主キーとすることができるものを複合キーという。
その複合キーの一部分に従属してるアトリビュートのことを部分従属性という。
以下のようなテーブルだと
注文明細テーブル
主キー: (注文ID, 商品ID)
アトリビュート: 数量, 商品名, 商品単価
商品名と商品単価は、商品IDのみに依存している。
対して、注文IDは依存していない。
なので、部分的に従属していることになる。
何が問題か
単純に無駄な従属になりやすく、「繰り返し」が発生する可能性が高い。
この繰り返しというのも正規化をする上で重要になるが、繰り返しは重複したデータの更新や不整合など、メンテナンス性を著しく下げるため、よっぽどのケースでパフォーマンスを向上の目的でなければやらない方が良い。
推移従属性とは
主キーではないアトリビュートに対して従属したアトリビュートがあることをいう。
以下のようなテーブルだと
社員テーブル
主キー: 社員ID
アトリビュート: 社員名, 部署コード, 部署名, 部署所在地
部署名と部署所在地は、部署コードに依存する。
部署コードは、社員IDに依存する。
社員ID -> 部署コード -> 部署名/部署所在地 という流れになり、部署コードという主キーではないアトリビュートに依存したものが存在することになる。
何が問題か
こちらも、部分従属と同じように繰り返しが発生しがちなのが問題になりがち。
基本的にどちらも同じような問題を持っている。
具体的には以下のようなもの。
冗長性 - 同じ情報が何度も記録される
更新異常 - 1つの事実を変更するのに複数行の更新が必要
不整合リスク - 更新漏れによる矛盾データの発生
挿入/削除異常 - データの独立性がない
それらが解消されるとどうなるか
第3正規形と呼ばれる構成になる。
つまり、正規化された状態のものになる。
そうすることで依存しているものの重複がなくなり比較的メンテナンスがしやすい状態になる。
しかし、先ほども言ったように設計に正解はなく、必ずそれをすべきというものではない。
ユースケースによってはあえてそのルールを破ることも必要になってくる。
Discussion