はじめに
はじめまして、2022年3月中旬にコミューン株式会社に入社した西山です。
普段はフロントエンドのエンジニアとして開発業務に携わっています。
この記事では、私がERモデルを使ったDBのデータモデリング（以下、データ設計）を行う際、特に意識していることを3つ紹介します。
尚、具体的にユースケースからエンティティを抽出する方法や、チューニングなどの物理設計については触れません。
前提
まずは私がデータ設計とどのように関わってきたかについて紹介します。
前職までのキャリアでは、フルスクラッチの受託開発案件をごく少人数で開発しており、利用者に業務を伺ってデータ設計をする、ということも度々行なっていました。
システムの用途としては一般公開されない、所謂「業務アプリ」「業務システム」といった企業内での利用を想定したものや、限定された一部の利用者に向けたものです。
また規模としては大きくなく、多くてもテーブルが30程度、レコードは数万件で収まっていました。
目標とするデータ設計
データ設計においては「一事実一箇所(one fact in one place)」が原則になります。
ERモデルではこの考え方に従ってデータを正規化する事により、矛盾のない（少ない）データ設計を実現できるとされています。
また、ERモデルはモデル化対象（実世界）を“実体”とその“関連”からなるものとして定義、構造化とありますので、ここではシステムやDBがなくても成り立つような設計を目指します。
データ設計を行う際に意識していること
1. 現実を扱っていることを意識する
システムやDBが無くても成り立つので、「表」「行」「列」と言った概念とは別のものでそれぞれを考えます。
管理対象（以下、エンティティ）は存在すると定義したモノ、それ自体です。つまり表ではなく、行や列もありません。
少し違和感もありますが、表よりは「集合にデータがない状態」の方がまだ近いのではないでしょうか。
ちなみに、私なら下の画像を「従業員エンティティに複数の組がある」と表現します。
2. プログラムを意識しないこと
先ほどの画像で「複数の組」と書いた通り、ここではデータ一つ一つを「組（タプル）」とします。また、表で言うところの列は「属性」とします (この呼び方は「データベースシステム概論 6版」 にも記載があります）。
さて従業員エンティティから組を一つ抜き出して属性について考えます。
仮に名前を「Aさん」にした場合、Aさんに質問しても文章として違和感のないものがそのエンティティの属性だと思っています（プライバシーなどは考慮しません！）。例えば「現住所」「血液型」「出身地」などです。
逆に、「Aさんの閲覧フラグ教えて！」「AさんのcreatedAtって何だっけ？」などのように、文章として違和感がある場合は適切ではないと考えます。
それでも解決できない場合はエンティティやリレーションシップが抜け落ちている可能性も高いです。「ログを出力したいのでcreatedAtを付けたい」というのであれば、ログ出力のエンティティやリレーションがあるか、また、そちらのエンティティに属性を移すべきではないか、改めて見直すと良さそうです。
3. サロゲートキーは必ず付けること
こちらについてはアンチパターンとされていることを認識しつつも、早い段階でID列（サロゲートキー）を主キーとして設定していました。
よくない理由は「SQLアンチパターン」や「達人に学ぶDB設計 徹底指南書」でも説明されています。共に「使っても良い場合がある」「グレーゾーン」との表記ですし、そもそもデータ制約であってデータ型ではない、と言う指摘も尤もだと思います。
www.oreilly.co.jp www.shoeisha.co.jp
それでも私が使っていた主な理由は以下の通りです
- 主キーの不変性を確保したい為
- ORマッパーで都合が良い為
- 複合主キーは、リレーションシップを考慮する際に使いづらい為
まとめ
一言でまとめると「データ設計のときは業務やユースケースに注力して、DBやシステムのことはできるだけ考えないようにしよう」と言うことです。
一つ一つは小さな違いかもしれませんが、こういった積み重ねがより高い抽象化やデータ独立性に繋がるのではないかな、と私は考えています。
さいごに
データ設計の良し悪しはコード、延いてはシステムの良し悪しにも繋がります。
また、システムやDBがリプレースされてもデータ設計はそのままと言ったケースも見聞きしてきました。
寿命が長くなりがちなデータ構造なので、最初の一歩を大切にしたい/して欲しいと思っています。
