達人に学ぶDB設計8章

達人に学ぶDB設計第8章を要約してみた

論理設計のグレーノウハウ

• 主キーを決めるケースが容易ではないケースが存在する
  • 入力データに主キーにできるような一意キーが存在しない
  • 一意キーはあるが、サイクリックに使いまわされる
  • 一意キーはあるが、途中で指す対象が変化する
• これらのケースは代理キーを利用することで解決できる
  • 代理キーは入力データに最初から存在しているキーの「代理」として新たに追加するキーのこと
  • 代理キーは便利であるものの、極力自然キーを使用するべきである
  • 代理キーに求められる要件は、一意で連続性があること
  • 代理キーの実装にはしばしば、１レコードに一意な数値を自動的に割り振るオートナンバリングが利用される
• 自然キーで解決する方法
  • いつ時点でのデータであるかを示すタイムスタンプを用いれば、直近の情報だけではなく、過去に遡ってデータを調べることが可能である。このキーはシステム上意味のあるデータとしても活用することができる。デメリットとしてレコード数が増える
  • もう一つの方法として、データの有効な期間を表すインターバルを用いる。データの断面ごとにデータを持つ必要がなく、タイムスタンプの欠点を克服することができる。データ変更が頻繁に行われる場合にも大きな利点となる。一方、欠点としてSQL文に範囲指定の条件をい入れる必要があるので複雑になる
• バッドノウハウである配列型の模倣をした論理設計である「列持ちテーブル」がそんざい　する。シンプルな設計、入出力のフォーマットが列持ちテーブルの利点に挙げられる。欠点として、列の増減が難しいこと（拡張性に乏しい）、nullを許容してしまうことが挙げられる。基本的には行持ちテーブルを採用するべきである
• 場当たり的な（アドホックな）キーは、コード体系が短いスパンで変わったり、別のコード体系が必要になったりする。アドホックなキーは、巨大になってパフォーマンスを劣化させやすい
• ユーザーはビューを介して実データである基底テーブルにアクセスする
• ビューを幾重も介して実データにアクセスする多段ビューは、パフォーマンスを悪くするだけでなく、仕様が複雑になる（KISSの法則、Keep It Simple, Stupidに反している）
• 業務で利用されていたデータをデータベースに登録できる状態にする作業をデータレンジングと言う
• データレンジングは設計に先立って行う
• データレンジングでは、まず一意キーの特定を行う。一意キーの存在しないデータは、バッドノウハウ「不適切なキー」を生み出してしまう。
• 次に名寄せを行う。名寄せが発生する根本的な原因は標準的なフォーマットを使用せず、フリーハンドの入力で作ってしまうことである（ダブルマスタを生み出す原因にもなる）。別の情報と組み合わせて確度を高めるか、情報の出現頻度で判断する。
• 演習
  • アプリケーション側とデータベース側どちらで難しいビジネスロジックを実装するべきか、人によってはアプリケーション側での実装を嫌う人もいるが、DB側で実装する（表明）だと複雑なロジックが書けない問題が生じる。また、エラーハンドリングが難しい。
  • しかし、テーブルの機能を使わなくて良いということではなく、永続的な制約や高速なアクセスパスを形成できることから、基本的なルールはデータベース側で実装するべきである