1. 導入：なぜER図を「コード」で管理すべきなのか
データベース設計を行う際、Excelや作図ツールを使ってER図を描いていませんか？しかし、図だけが独り歩きし、実際のテーブル定義（マイグレーションファイル）と乖離してしまうケースは少なくありません。そこで役立つのが「Mermaid」です。コードとしてER図を管理することで、Gitで変更履歴を追跡でき、プルリクエスト（PR）内でテーブル設計の変更を即座にレビューできるようになります。
2. 基礎知識：ER図とMermaidとは
ER図（Entity Relationship Diagram）とは、システム内の「データ（エンティティ）」と、それらの「関係性（リレーション）」を可視化した図面のことです。
Mermaidは、テキストベースの構文から図を描画できるツールです。難しい操作は不要で、直感的な記法でエンジニアが普段使い慣れているエディタから直接ドキュメントを生成できます。
3. 実装・解決策：MermaidでER図を定義する
ER図を記述する際は、主に以下の3要素を定義します。
・エンティティ（テーブル）：格納されるデータの塊
・属性（カラム）：テーブルに含まれる項目と型
・リレーション（関係）：テーブル同士の紐付け（1対多など）
記述の際は、Gitのリポジトリ内に「schema.mmd」のようなファイルを作成し、そこにコードを保存します。GitHubやGitLabはMermaid記法を標準でサポートしているため、ファイルをコミットするだけでPR上に図が自動描画されます。
4. サンプルプログラム
以下のコードをMermaid対応のエディタ（VS Codeの拡張機能など）やGitHubに貼り付けてみてください。ユーザーと投稿の関係を定義したシンプルな例です。
erDiagram
%% ユーザーテーブルの定義
USER ||--o{ POST : "作成する"
USER {
int id PK "ユーザーID"
string name "ユーザー名"
string email "メールアドレス"
}
%% 投稿テーブルの定義
POST {
int id PK "投稿ID"
int user_id FK "ユーザーID"
string title "タイトル"
text content "本文"
}
5. 応用・注意点：現場で陥りやすい罠と対策
・図のメンテナンスを忘れない
コードと図が乖離するのが最大の懸念点です。開発の習慣として「マイグレーションファイルを作成したら、セットでMermaidのコードも更新する」というルールをチーム内で徹底しましょう。
・複雑化しすぎない
一つのファイルにシステム全体を詰め込むと、図が巨大化して読みづらくなります。機能単位でファイルを分割するか、あえて主要なテーブルのみを記載する「概念モデル」と「論理モデル」を分けるなどの工夫が有効です。
・ツールの活用
GitHub上のMarkdownファイルであれば、 というブロックで囲むだけで描画されます。日々の開発フローの中にこの習慣を取り入れるだけで、チームのDB設計に対する意識とレビュー品質が格段に向上します。
コメント