【Wagbyのこだわり】主キーの扱い

Wagbyでは、業務データを「リレーショナルデータベース」で扱います。
リレーショナルデータベースでは「すべてのデータは主キーによって特定できる」というルールが備わっています。

これは次のように解釈してください。ある項目を主キーとしたとき、この項目の値には自動的に次の制約が課せられます。

つまり主キーの項目は「一意であり、必須であり、最初に決めた値から変更されることがない」ことが（アプリケーション全体で）保証されます。

この保証、という点がポイントです。主キーは絶対に重複しませんし、絶対に値をもっていますし、絶対に変更されることはありません。

これらが保証されていることを前提に、開発者はアプリケーションを組み立てることができます。主キーを参照する関係（外部キーといいいます）において、データが整合性を保っていることを信じることができます。

例えば、商品モデルの主キー値1234のデータを参照している、注文伝票というモデルを想定してみましょう。注文伝票から辿れる商品は常に一つ（重複しない）です。商品の主キーが未設定というデータを、注文伝票から参照することは認められていません。商品の主キーがそのあと6789に書き変わって、注文伝票が指していた1234が辿れなくなってしまった、という事故も起こりません。

このような特別な性質をもった「主キー」をモデルの設計にどう活かすか、これがポイントになります。

Wagbyで新しくモデルを作成すると、主キー項目 "ID" が自動的に用意されます。これは1000番から始まる数字となっています。このモデルを新規作成するごとに主キーの値が1000,1001,1002,...のデータが追加されます。

この数字自体に意味はありません。
このように、業務上、意味のない連番を主キーとして使う方法を「サロゲートキー」（代理キー）と呼びます。

サロゲートキーは便利です。深く考えずに主キーの値が定まりますし、問題なく使えます。しかし、だからといってサロゲートキーだけでモデル設計をしていいかどうかは、いったん立ち止まって考えてほしいのです。

ある業界で、固有のコード体系をもつことがあります。このコード体系は値が重複しません。これはモデルの「主キー」として十分、使えそうです。

自社の顧客には、すべて独自の顧客コードを付与しているかもしれません。この顧客コードは値が重複しませんし、顧客コードが割り当てられていない顧客データというものも存在しません。これも主キーとして使えそうです。

ある台帳には管理番号が付与されており、それは「4桁の年度 + 順序値」というルールになっています。例えば 2022-0001 とか 2023-0123 などです。これも主キーとして使えそうです。

このように業務視点でデータを管理しようとしたとき、この値を使うことでデータの特定が簡単に行えるという性質がみつかれば、これを主キーとするのは自然です。これを「自然キー」と呼びます。

自然キーは一般に文字列や数字、日付で構成されます。サロゲートキーは数字のみでしたので、それよりは表現力が高くなります。

複数の値の「組み合わせ」を主キーとするという考え方もあります。それが「複合キー」です。

例えば「販売品」の単価が年月ごとに変化する業務を想定します。「販売単価」というモデルを用意し、その主キーを「販売品コード」と「開始年月」の組み合わせ、つまり複合キーにすることは業務上、自然な発想でしょう。二つの値の組み合わせは決して重複せず、また一度決まった組み合わせの値をあとで変更することは認めないというルールがあると望ましいです。

集計表のような位置付けのモデルも複合キーで管理すると便利な場合があります。例えば「部門コード」と「年度」の組み合わせを複合キーとする「部門別年次集計」のようなモデルがあげられます。

業務の特性にあわせて主キーを決める利点は、データとデータの関係性がわかりやすくなることです。

ある程度以上の業務アプリケーションでは、扱うモデルの数が数十から数百になります。このとき、もしすべてのモデルの主キーが "ID" というサロゲートキーだけで構成されている場合、すべての関連を ID で管理することになります。もちろん、できないことはありません。
しかし、データの関連を直感的に把握するのが難しくなります。
モデル同士が「関連づいている」ことはわかりますが、どういった意図で関連づけられているのかは把握しづらい、ということです。

主キーは自然キーまたは複合キーにすることで、全体像の把握がしやすくなるでしょう。
例えば、アルバイトのシフト管理業務を想定したとき、「シフト申請」は「スタッフコード」と「年月」の組み合わせによる複合キーとします。このシフト申請に紐づく明細データ「シフト申請明細」があり、これは「スタッフコード」「年月」「日付」を複合キーとします。すると「シフト申請」が親で「シフト申請明細」が子、これらは「スタッフコード」と「年月」で関連づけられているという情報だけでも、全体の見通しがよくなります。

さらに、データの関連を主キーで紐づけることで、このデータの関連は何かおかしい、というような気づきも早めに得られる可能性があります。 どの項目を主キーにするかという着想だけでひとまず複雑なモデル群の関係性を整理することができるのです。それほど主キーの設計は重要であり、最初の段階で行うべきものといえます。

このように「何を主キーにするか」という考え方は重要なのですが、これらを吟味した上で、あえてサロゲートキーを使うという選択もあります。

一つは、現実問題として管理しているデータが整理されておらず、主キーになりそうだが、ならなかった、という場合です。例えば「商品コード」という概念があるのだが、過去のデータに（データとしては異なるものの）なぜか商品コードが重複しているものがあり、主キーとして使えなかった。

もう一つは、その商品コードが30年前は7桁だったのだが、20年前にECサイトを開設したタイミングで8桁になり、さらに10年前に企業合併で10桁かつコード体系が変わったという経緯があり、主キーとして使うのが難しいという場合です。主キーとして使っていたコード体系が変わった場合、すべてのデータの主キー値を再設定する必要があります。一般に「洗い替え」と呼ばれるもので、非常に面倒です。

これらは業務経験上、主キーとして使えないことがわかったという知見があってサロゲートキーにしたという判断です。この過程は重要なので、是非とも設計書に記録してください。設計書には「決まったこと」だけでなく「理由があって採用しなかったこと」も記録すると、将来のシステム改修のときに大いに役立ちます。

残念なことに、採用する技術基盤がそもそもサロゲートキーしか受け付けない、という場合があります。

それでも主キーの設計、特に自然キーまたは複合キーを探すという設計作業は行うべきです。その上で、サロゲートキーとして "ID" 項目を付与するものの、主キーとなりえたであろう項目には少なくとも必須属性を指定します。その技術基盤が許せば、一意性（ユニーク性）の属性も指定します。これで疑似的に主キーの意味合いを持たせます。更新時に主キー項目を隠し項目または読み込み専用とすることで、主キーの値が更新できないような工夫も行うといいでしょう。

これらは本来、データベースが保証していた主キーの性質（一意性、必須、更新不可）をアプリケーションが担保するように工夫するということです。アプリケーションの対応漏れによるデータ異状の可能性が残るため、これをカバーするためのテスト工数が増えることは仕方ありません。技術基盤の不備を開発者がカバーするということです。

「採用しようとしている技術基盤がサロゲートキーにしか対応していない＝自然キーや複合キーを考慮したモデル設計を行うのは古い方法なんだ！」とは解釈しないでください。これは明らかに間違いです。

データ設計の観点からは、どのような主キーが望ましいかをきちんと把握することは欠かせません。その工程をよく考えずに省略し、ただデータには ID 項目を付与すればいい、というのは危険です。規模が大きくなったときにデータの関連性を把握しづらくなり、ひいては不具合の温床になります。主キーとして管理すべき項目への配慮を怠ることで、必須性や一意性、変更不可性を担保できないシステムになると、運用後のデータ異状を引き起こす恐れまで生じます。

Wagbyはサロゲートキー、自然キー、複合キーのいずれにも対応した技術基盤です。

Wagbyを使う開発者が、どのような主キー設計をするかは強制しません。ただ、サロゲートキーしか使えないというのは基幹業務の基盤としては力不足といえます。

基幹系を担う技術基盤は、できるだけその業務を違和感なくアプリケーションとして実装できるよう、主キーの設計に自由度をもたせることが望ましいと考えています。