dorivenの日記

気がついたら社会人。気になる技術的なことについて少しずつ書いていけたらと思っております。

【書評】楽々ERDレッスン

TL;DR;

  • データベースを「雰囲気」ではなく裏打ちされた「知識」で設計できるようにしたく、本書を取った
  • 筆者の進めるデータベース設計を学び、実際にレッスンという章で実際に体験しながら学べたのでしっかりと頭に残った
  • データベースの詳細な挙動は人によっては読む必要がないかもしれない(パフォーマンスを意識する段階にあるかどうかな気がする)

モチベーションと書籍に期待していた内容

  • 情報技術者系の試験で正規化は知っていたし、実際に業務でテーブル設計を行うこともあった
  • 他方、T字型ERモデルから「イベント系」「リソース系」という言葉を耳にしたり第4,5正規化の言葉を耳にして自身のデータベース設計が「雰囲気」でやっているのではないか、という気持ちになった
  • 過去、データベース設計系の本は SQLアンチパターン しか読んだことがなかった
  • 「雰囲気」ではなく「知識」から裏打ちされた(議論の際の引き出しとしても使える)データベース設計を行えるようになりたいと考えた
  • 先輩社員からデータベース設計についての本がどういうのがいいのか、というので昔評判に上がったという本書を手にとった
  • 基本的なデータベース設計の体系的な知識が手に入ることを期待して読んでみることにした

本書の構成

4章構成に分かれていて、それぞれで以下のような内容を取り上げている。
実際の節は名前が異なり、あくまで自分が読んだ上で捉えた概要を書いている。

  • DB設計総論
    • 伝票表組みを例にした正規化までの流れ
    • ビジネスでのデータベース設計の考え方
    • コード体系(ビジネス上のラベル)、諸口問題(例外顧客に対する設計)への考え方
    • 筆者が進めるデータベース設計手順
  • RDBMS総論
    • RDBMSが出てくる前後のシステム的な課題とメリット
    • データ中心アプローチから見たRDBMSの捉え方
    • アプリケーションから見たRDBMSの捉え方
  • 楽々ERDレッスン
    • 現実にある表組(レシート、申込み表、請求書など)からテーブルを導出する訓練
  • 付録
    • SQLって実際にはどう動いているのかを順次、分岐、反復レベルまで落とし込んで見てみる
    • RDBMSボトルネックと対策
    • 参考書籍

学び

1章のデータベース設計手順を3章のレッスンを通して学べたのが一番デカかった。

データベース設計手順

ここでいうデータベース設計とは「ビジネスの流れをどのようにテーブルに落とし込んでいくか」を指している。
本書では以下の手順を推奨していた。

  1. 業務単位、部門単位(ブロックと本書では呼称していた)で分割する
    • 例: 図書館を例にあげるなら「貸出業務」「資産管理(書籍の購入や廃棄など)業務」と分割
  2. ブロック毎にイベント系エンティティを抽出
    • イベント系とは本書では業務上で「〜する」と置き換えられるものを指している
    • 例: 図書館であれば「貸出」「購入リクエスト」などがそれに当たる
  3. イベント系エンティティの正規化
    • 2で抽出したイベントに必要な項目をなるべく素朴に抜き出す(最初から正規化しようとすると混乱するため)
    • イベントと結びつくリソース系エンティティがざっくり見えてくる
      • 本書では「誰に」「誰が」「何を」「どこで」「どのように」という項目で考えるのが良い、という話が書いてある
      • 例: 「貸出」であれば「従業員に」「利用者に」「書籍を」貸し出す、という流れでリソースが見えてくる
    • 更にイベントに結びつくイベントも見えてくる
      • 例: 「購入リクエスト」であればその後、「購入」というイベントも見えてくる
    • 繰り返し項目をざっくり正規化する(まだリソース系が完全に見えている訳ではないので、やりすぎ注意とのこと)
  4. リソース系エンティティの分類を整理
    • ここでいう「分類」とは顧客であるなら「個人」「法人」といったカテゴリのようなものを指す
    • この「分類」を別エンティティ(テーブル)として分けるのか、はたまた「顧客」エンティティの中にカテゴリとして持たせるのか、という判断が必要になる*1
      • 例: 図書館が学校などの公共機関への貸出もしている場合や、税金を収めていない他地区の市民も利用できるようにしている場合、「利用者」の分類を「市民」「他地区」「公共機関」などに分類させる場合
    • 本書が説明しているリソース系に手を付けるのは後にしたほうが良い理由
      • 「分類」が規模の大きなシステムであればあるほど出てくる
      • 「分類」は外部のデータを取り扱っている場合に組織変更などで早ければ半年のサイクルで変化が訪れる可能性がある(ゆえに交差エンティティをもたせると柔軟性があがる)
    • このとき、あるべき姿を設計として落とし込みたいので性能を気にするはやめる(それを気にしだすと設計を崩すことになるため)
  5. ブロック間でのリソース統合*2
    • 2~4まではブロック毎に行ったものを統合していく
    • 基幹系のデータはここで統合が行われていくようになる
      • 例: 「書籍」は貸出業務の「貸出」でも関係を持っているし、資産管理業務の「購入」でも関係を持っている
    • このブロック間のリソースの統合でそれぞれの業務システムの要件にあうように統合した後に、エンティティの分割や関連エンティティの定義を行うことで使いやすいデータになるのでプログラムの設計も楽になる
      • 部門間、業務間の調整力が問われる
      • ここをしっかりしないとどちらかにしわ寄せがいくので、技術力とはまた異なった側面の調整力が必要になりそう
  6. 導出系の整理
    • 5が終了したリソース全体に対して、第2, 3正規形を行えばよい

その他

  • One fact in one place の考え
    • なんとなくわかってはいたけど、言葉として出てきたので改めて理解。
  • RDBMS以前のデータ基盤の話
    • 自分は最初からRDBMSがある世代なので昔がしれて面白かった(小並感
    • 闇の時代だったことが分かった
  • 筆者が遭遇した赤裸々な問題への対応
    • コードを主キーにするな(コード体系問題)
    • 変化があるコード体系は交差エンティティで柔軟性を持たせる
    • 諸口のような例外ケースに対する考え方
  • 設計はユーザインターフェイスからという話
    • 学びというより筆者と考え方共感できたのは良かった

知っていた話

  • 2章後半、4章全般
    • データベースの挙動はパフォーマンスチューニング経由で把握しているので大体読み飛ばした
    • forに対して1件ずつfetchとかも敢えてやる場合を除いて基本しない
    • データベースボトルネック周りの話

疑問

  • 1章の明細別や全体での「まとめ買い割引」
    • 自分は別テーブルに割引する額や理由を管理してLEFT JOINして金額を導出する方向にすると思った
    • 筆者はテーブル毎にそれぞれの価格を定義していた
    • これだと割引の有無の事実があったかを出すのが大変なイメージがあるがどうなのだろうか?*3

全体として

1章のDB設計総論にあるデーベース設計手順の流れを、3章の楽々ERDレッスンで触れながらデータベース設計できるため、技術書を読んで発生する「分かった気がするけど、どうやって仕事に落とし込んでいいかがわからない」といった事態にはならないのが非常に良かった。
データベース自体の細かな挙動の解説は筆者がDBAエンジニアとして理解してほしいという気持ちを感じたが、万人に挙動の理解が必要かどうかは難しいところではある。

*1:個人的な解釈だが別エンティティにするかどうかの判断は、持っている項目が一緒であり今後も変わることがないならカテゴリとして持たせ、そうでなければ別エンティティにしたほうがよいのではないか、と思っている

*2:自分は大規模なシステムを取り扱った経験がないので、ここらへんの腹落ち感は低め

*3:そういった事実を出すことがあるかは業務要件によるので結局ののところ要件としてあるかどうか次第なのだろうけど