関数従属性とは？種類や正規化との関係をわかりやすく解説

はじめに

関数従属性は、データベース設計や管理において、非常に重要な役割を果たします。少し難しそうに感じる言葉ですが、意味を理解できれば、情報を活用して業務を最適化するための力が身に付くはずです。

この記事では、関数従属性の意味と3つの種類について説明し、具体例を交えてデータベース正規化との関係をわかりやすく解説していきます。

関数従属性とは？

関数従属性（Functional Dependency, FD）とは、ある属性（列）の値が別の属性の値によって一意に決まる関係を指します。属性Aが属性Bを決定する場合、形式的にはA→Bとされ、「Aの値が決まれば、Bの値も一意に決まる」という意味を表しています。

この仕組みはデータベース設計において、情報を無駄なく整理し、データの重複や矛盾を防ぐために欠かせません。効率的なデータ管理の基礎となるため、関数従属性を理解することで、正規化と呼ばれるデータベースの最適化作業もスムーズに行えるようになります。

データベース設計における役割

データベース設計における関数従属性の役割は、データ整理を効率化するために無駄や矛盾を防ぐことです。特に、データの重複を減らせる点は大きなメリットといえるでしょう。

例えば、顧客情報を扱う際に、同じ顧客名や住所を複数の場所に保存すると、更新時に不整合が生じるリスクがあります。しかし、関数従属性を理解して適切にデータを分割すれば、このような問題を回避することができるのです。

関数従属性の種類

関数従属性には、大きく分けて3つの種類があります。それぞれの特性を理解することは、データの関係性を見極めるうえで欠かせない基礎知識であり、データベースの正規化を進める際にも非常に役立ちます。

ここでは、関数従属性の代表的な3つの種類について詳しく解説します。

１．部分関数従属性

部分関数従属性とは、ある列が複合主キー（複数の列で構成される主キー）の一部の列によってのみ決まる状態を指します。この状態はデータの重複や冗長性を引き起こしやすいため、データベース設計において注意が必要です。

以下のような表を考えてみましょう。

注文ID	商品ID	商品名	注文数量
001	A101	ペン	10
002	B202	ノート	5

この場合、「注文ID」と「商品ID」の組み合わせが主キーですが、「商品名」は「商品ID」のみで決まります。このような関係が部分関数従属性であり、解消するためには、表を分割して「商品ID」と「商品名」を独立したテーブルに分ける方法が考えられます。

２．完全関数従属性

完全関数従属性とは、ある列が複合主キーの全ての列によってのみ値が一意に決まる状態を指します。これは、データの冗長性を防ぎ、正規化の第一歩として重要な概念です。

先ほどの例を再度見てみましょう。

注文ID	商品ID	商品名	注文数量
001	A101	ペン	10
002	B202	ノート	5

この表において、「注文数量」は「注文ID」と「商品ID」の両者の組み合わせで決まります。このように、他の列が主キー全体（ここでは「注文ID」と「商品ID」）に完全に依存している場合、完全関数従属性に該当します。

完全関数従属性を持つ状態はデータベース設計において望ましい形であり、データの整合性を保つ基本です。この状態を維持することで、冗長性を減らし、一貫性を確保できるデータベース設計が実現できます。

３．推移的関数従属性

推移的関数従属性とは、ある列が主キーに直接依存せず、別の列を経由して間接的に決定される関係を指します。この状態はデータの冗長性や矛盾を引き起こしやすいため、正規化のプロセスで解消が必要です。

先ほどの例をもとに考えてみます。

注文ID	商品ID	商品名	注文数量
001	A101	ペン	10
002	B202	ノート	5

この表で、「商品名」は主キーの一部である「商品ID」に依存していますが、「注文ID」には依存していません。「注文ID」が「商品ID」を決定し、「商品ID」が決まることで「商品名」も決まるこの関係が推移的関数従属性です。

推移的関数従属性を解消するには、「商品ID」と「商品名」を別のテーブルに分け、商品情報テーブルとして設計します。こうすることで、推移的関数従属性が解消され、データの重複や矛盾を防ぐことが可能になります。

関数従属性の知識が欠かせない、データベース正規化の目的やメリット・デメリットについて詳しく知りたい方は、こちらの記事をご覧ください。

関数従属性と正規化の関係

ここからは、顧客データベースを例に、非正規形から第3正規形まで正規化を進めるプロセスを説明します。非正規形は未整理な状態のデータですが、関数従属性の考え方を活用することで、整理されたデータ構造に変えることが可能です。

実際の手順を具体的に説明していきますので、データベース設計や運用の際はぜひ参考にしてください。

１．非正規形

非正規形では、データが重複していたり、複数の値が1つのセルに格納されていたりします。

顧客ID	名前	住所	電話番号
1	UT 太郎	東京都港区	090-○○○○-○○○○, 080-××××-××××
2	アンカバ 花子	大阪府大阪市北区	070-△△△△-△△△△
3	UT 太郎	東京都港区	090-○○○○-○○○○

非正規形のデータでは以下のような問題点が考えられます。

２．第1正規形（1NF）

第1正規形（1NF）では、すべての属性が「単一の値」を持つようにします。つまり、セル内に複数の値を持たない形です。

また、第1正規形とした時点で、主キーを定義します。この手順では顧客IDと電話番号からなる、複合主キーとする場合で説明を進めます。

顧客ID	名前	住所	電話番号
1	UT 太郎	東京都港区	090-○○○○-○○○○
1	UT 太郎	東京都港区	080-××××-××××
2	アンカバ 花子	大阪府大阪市北区	070-△△△△-△△△△
3	UT 太郎	東京都港区	090-○○○○-○○○○

単一の値を持つ形とした第1正規形ですが、まだ以下の問題点が残っています。

３．関数従属性の確認

ここで、関数従属性について確認してみましょう。第1正規形に変換したデータの関数従属性は以下のようになっています。

・顧客ID→名前、住所

　顧客IDが決まれば、名前と住所が一意に決定します。

・顧客ID、電話番号→名前、住所

　顧客IDと電話番号の組み合わせが決まれば、名前と住所が一意に決定します。

４．第2正規形（2NF）

第2正規形（2NF）では、部分関数従属性を排除します。先ほど確認したとおり、名前と住所は顧客IDのみで一意に決まるため、電話番号の分割を行います。

顧客テーブル（顧客IDを主キーとする）

顧客ID	名前	住所
1	UT 太郎	東京都港区
2	アンカバ 花子	大阪府大阪市北区
3	UT 太郎	東京都港区

電話番号テーブル（顧客IDと電話番号を主キーとする）

顧客ID	電話番号
1	090-○○○○-○○○○
1	080-××××-××××
2	070-△△△△-△△△△
3	090-○○○○-○○○○

分割を行うことで、顧客テーブルでは「顧客ID→名前、住所」の関係のみが残り、部分関数従属性が無くなりました。

５．第3正規形（3NF）

第3正規形（3NF）では、推移関数従属性を排除します。

第2正規形の顧客テーブルでは、顧客IDで住所が一意に決定し、それに伴って都道府県や市区町村が一意に決まります。このような推移関数従属性を排除するため、住所の分割を行いましょう。

顧客テーブル

顧客ID	名前	住所ID
1	UT 太郎	1
2	アンカバ 花子	2
3	UT 太郎	1

住所テーブル

住所ID	住所
1	東京都港区
2	大阪府大阪市北区

電話番号テーブル

顧客ID	電話番号
1	090-○○○○-○○○○
1	080-××××-××××
2	070-△△△△-△△△△
3	090-○○○○-○○○○

分割後は、顧客テーブル・住所テーブルともに、直接的な従属性のみであるため、第3正規形の条件を満たす形になりました。なお、住所が都道府県や市区町村に依存している場合は、住所をさらに分割します。

まとめ

関数従属性は、データベース設計の基盤を支える重要な概念であり、データを効率的に整理し、一貫性を保つために欠かせない知識です。部分関数従属性・完全関数従属性・推移的関数従属性の違いを理解することで、どのようにデータを分割すべきかが明確になります。

この記事の内容を参考に、業務で扱うデータがどのように当てはまるのかを考えてみてください。少しずつ理解を深め、より適切なデータベース設計を目指してみましょう。