正規化のすすめ – 設計編（その３ – 主キー設計）

　今回は設計編 その１で挙げた「正規化してもうまくいかない」という問題について、その理由のひとつとして主キー設計について取り上げたいと思います。

　主キーは単なる検索用のインデックスではなく、極めて重要な意味を持っています。
　この点を理解せずに主キーを定義すると、設計が行き詰まってしまいます。

　主キーについての一般的な知識はご理解いただいているものとして、主キー設計で見落としがちな観点について解説します。

主キーはなぜ更新できないのか

　主キー制約には以下の規則があり、逸脱することはできません。

　1.と2.の意味は分かると思いますが、3.の意味が分かりづらいことで、
　　　「主キーは面倒なので定義したくない」
　　　「主キーが更新できないのはRDBの欠陥だ」
といった意見を見かけます。

　しかしこの規則にはきちんとした理由があり、RDBとして必要不可欠な定義です。

---

　3.の規則は、データの一貫性を保証するための定義です。

　DBのレコードは、無秩序なデータの集合ではありません。それは一定の意味を持つデータのまとまりであり、例えば人・商品・受注といった意味を持つ単位とその属性を表します。
　そして主キーはレコードを一意に特定する情報であり、そのデータそのものを表します。

　例えば個人を定義するマスタでは、レコードはAさん・Bさんといった特定の人を表す情報であり、Aさんの主キーの値は、Aさん自身を端的に表す情報です。
　もし主キーが更新可能であると、最初はAさんを表していたデータが、後から別人に置き換わることを意味します。するとAさんが購入した商品について、Aさんは存在しなかったことになり、別人に対して請求が発生するといった矛盾が発生します。

　これはデータの一貫性が失われた状態です。
　現実の世界では、Aさんの表面的な属性である氏名や住所が変わることはあっても、Aさん自体が全く別人に置き変わることは起こりません。商品や受注といった概念でも同様です。

　このようなデータの本質を変えてしまう更新は矛盾を引き起こすため、設計上あってはなりません。別の本質のデータは、別のレコードと主キーで表されるべきです。

　したがって、いかなる場合でもデータの本質が不変であることを保証するために、主キーは更新不可と定義されています。　

なぜ主キーが必要か

　主キーを設計する上で、主キーの目的を理解することが重要です。

　主キーの目的を「検索用の情報を定義する」と捉えるだけでは不十分です。
　より重要な目的は、以下を定義することにあります。

　下記のER図は、顧客が商品を注文するDBの事例です。これをもとに具体的に説明していきます。

レコードの意味を定義する（1-a）

　前回の記事「正規化のすすめ – 設計編（その２ – テーブル分割）」で、テーブル分割の観点を以下のように説明しました。

　これを主キー設計と組み合わせることで、データの意味や性質を詳しく定義することができます。

---

　具体例として、顧客マスタを次のように定義しています。

他のテーブルとの関係を定義する（2-a）

　主キーに対し別のテーブルから外部キー制約を設定することで、テーブル間の関係を定義できます。
　これはテーブル間の論理的な関係を明示するとともに、データの論理的整合性を保つ必要がある場合に有用です。

---

　具体例として、顧客配送先マスタと顧客連絡先マスタを次のように定義しています。

他のテーブルとの関係を定義する（2-b）

　2-aの「iii.外部キーと主キーの組み合わせで、参照先テーブルとの数関係を定義する」で説明を省略したパターンについて説明します。

　複合主キーと外部キーを組み合わせることで、より複雑なテーブル間の関係と論理的整合性を定義できます。

　具体例として注文明細トランザクションでは、次のように定義しています。

---

　複合主キーを用いた定義は有用ですが、一方で使いすぎると以下の副作用があります。

　そのため複合主キーの設計では、以下の点も考慮すると良いでしょう。

主キー設計がもたらす効果

　以上のパターンを組み合わせて主キーを設計することで、設計の意図を明確にするとともに、論理的整合性が自然に保たれるデータベースを構築できます。
　これは次のような効果をもたらします。

---

　一方で主キー設計に考慮不足や誤りがあると、次のような問題が発生します。

　こうした問題はシステムの拡張性と柔軟性を損なうとともに、性能・品質の低下を引き起こします。
　さらに主キーの設計変更には、長時間のシステム停止・大量のデータ更新・大規模なプログラム修正といった大変な困難が伴います。

　したがって主キー設計では、将来的な想定まで含めて考慮不足が起こらないように検討することが重要です。

ナチュラルキーかサロゲートキーか

　主キーを定義する際に、ナチュラルキーとサロゲートキーのどちらを使うかで意見が分かれます。

　ナチュラルキーとサロゲートキーの議論は長年続いており、決着がつかないようです。
　しかし設計上、どちらを使うかを選択しなければなりません。

　一般的には、ナチュラルキー派が多いようです。両方を適宜使い分けるハイブリット派もいます。
　どちらを使うかは自由ですが、ここでは以下のようにサロゲートキーを使用することをお勧めします。

　サロゲートキーを勧める理由を5つ挙げます。

　上記の議論を詳しく解説し出すと非常に長くなるため、ここでは端的にまとめました。もし機会があれば別の記事で解説したいと思います。

　私のここ20年くらいの経験では、a.やb.の問題で行き詰まっているシステムをよく見かけました。
　一方で私はサロゲートキーを選択し続けていますが、特に行き詰まったことはありません。

　個別のノウハウや事情もあると思いますので、絶対にサロゲートキーであるべきとは言いません。特にナチュラルキーで構築したDBをサロゲートキーに切り替えるのは、非常に困難でもあります。
　ナチュラルキーを使いたい方は、a.やb.の点に留意しつつ、採用する選択肢もあるでしょう。

管理コードがもたらす副作用

　システムを設計する上で、顧客が業務上で定義したコードが登場することがよくあります。
　例えば、次のようなコードです。

　これらはナチュラルキーの一種でもあります。ここではこのようなコードを「管理コード」と呼ぶことにします。

　こういった管理コードは、何らかの構造を持っていることが多いでしょう。例えば、次のような構造です。

　こうした管理コードの定義は、業務上の必要や歴史的背景から発生しています。したがって、管理コードの存在自体を問題にすべきではありません。

　しかしながら管理コードを以下のように使い始めると、副作用が発生します。

　1.では逸脱できない仕様上の制限が発生していることが問題です。
　しかしこの制限は顧客にとっては理不尽な内容であり、仕様として受け入れられない可能性があります。
　どうしても対応が必要な場合は、過去データとの一貫性を保つためにデータの再登録が必要になりますが、この対応は一般的に大変な労力を伴います。

　2.では管理コード自体がひとつのテーブルとして機能しており、これは関数従属の状態です。
　この状態で管理コードとリレーションの間で不整合が発生したとき、リレーションに基づき判定する処理は正しく動作しますが、管理コードに基づき判定する処理が混入していると、不具合や想定外の動作を引き起こします。

　こうした副作用に対応するため、影響箇所の精査と対処に奔走する状況をよく見かけます。
　この状態は、せっかくの正規化が破壊されてしまった状態です。

サロゲートキーを用いた解決方法

　管理コードの副作用は、サロゲートキーを用いることで解決します。
　「ER図：サロゲートキーを用いた設計例（図書館）」では、以下のように定義しています。

　このように定義することで、以下の効果があります。

　管理コードの定義は顧客の企業文化でもあり、それ自体を否定することは適切ではありません。しかしその定義に不変性と正確性がなければ、設計として依存すべきではありません。

　ここで挙げた管理コードの扱いはナチュラルキーの議論にもつながりますので、おそらく賛否両論あるかと思います。
　一度決めた主キー設計を見直すことは難しいという事情もあると思いますが、少なくともそれが引き起こす副作用については、理解しておくべきです。

まとめ

　今回は、正規化以外に必要な設計のひとつとして、主キー設計について解説いたしました。

　まとめとして、主キー設計では以下の観点が重要になります。

　ここまでデータベースの正規化について掘り下げてきました。
　「正規化のすすめ – 設計編」はまだ続きますが、データベースの話題ばかりでは面白くないと思いますので、次回は少し趣向を変えてシステム設計全般の話題を扱いたいと思います。

---

(まだ評価がありません)