★連絡のため、勉強宴会のメーリングリストに登録していただけると助かります★ ★「benkyoenkai+subscribe@googlegroups.com」に空メールを送って登録して下さい★

再入門：「正規化崩し」としてのサロゲートキー

Rails、Salesforce、kintone等の開発環境では複合主キーを利用できません。その種の開発環境を使う場合、単独主キー（サロゲートキー、代理キー）を導入することになりますが、その過程が「正規化崩し」であることが認識されていないケースがあります。その場合、「正規化崩しに伴う報い」が仕様化されないため、データの不整合に悩まされるシステムが生み出されます。複合主キー禁止環境を使わないとしても、サロゲートキーはＤＢ設計の重要なテクニックのひとつです。これを導入することの意義と、安全に導入するための注意点について、あらためて学びましょう。

候補キーにもいろいろある

約3年前に「複合主キーは必須なのか」を開催しました。その議論を楽しむためには、以下のような前提知識が必要でした。
・候補キー(candidate key)：レコードを一意に特定するキー。１テーブルに複数存在することがある
・主キー(primary key)：代表として定めた候補キー。項目値の変更は許されない
・単独主キー(single primary key)：１項目で出来ている主キー
・複合主キー(composite primary key)：２つ以上の項目で出来ている主キー
・自然キー(natural key)：業務上意識されている候補キー。単独主キーか複合主キーかは問わない
・サロゲートキー(surrogate key)：業務上意識されていない単独主キー。代理キーともいう
参考：たなかこういち氏のブログ

正規化と正規化崩しとは

ＤＢ設計を語る場合、「正規形」や「正規化」の理解が欠かせません。正規化の目的は更新時異状を防ぐことです。しかしさまざまな理由から、正規形をあえて崩した形に設計する必要が生じるものです。これを「正規化崩し」といいますが、これを行う際には辛気臭い「報い」を引き受けなければなりません。サロゲートキーの導入も正規化崩しの一環で、設計者にはそれに伴う報いを確実に仕様化する責任があります。

Salesforceに関する制約と正規形に関しては、テラスカイブログに書きました。業務設計を意識しながらＤＢ設計を行っている技術者は網羅性はともかくとして必ず考えているはずです。

ところが、複合主キーを使えないプラットフォームを使って開発することからキャリアを始めると、本来必要な正規化や正規化崩しのスキルが身につきません。その場合、「報い」の仕様化に失敗するため、更新時異状を発生させるシステムが納品されます。しかも、その種の更新時異状は気づきにくく対処しにくいものなので、保守担当者やユーザを長期間悩ませることになります。ただし、サロゲートキーそのものは有用なテクニックなので、これを安全に導入するための正規化崩しの手順を理解しておかねばなりません。サロゲートキーを含めた「３種類の正規化崩し」についてあらためて学び、幅広く議論しましょう。

発表者

渡辺幸三さん

タイムテーブル

２０２０年　２月　２８日（金曜日）　１９：００スタート

場所

住所：大阪府東淀川区東中島1-19-11 大城ビル301号室 （ドアの上に部屋番号があります）。

「大城ビル」は、新大阪駅東口を出て正面と右に横断歩道を渡り、道路の右側にあるビルです。 ビル側面上部に建物名の表記がございます。

▼新大阪駅東口からのアクセス（Google map） https://goo.gl/maps/WNcgy9NW1YC2

▼アクセス動画 https://youtu.be/1gDEEJuniJw

参加費用

無料 ※懇親会は割り勘。4000円程度です。

以上