「本ページはプロモーションが含まれています」
こんにちは。前回はMermaidを使って、「モンスターを手に入れる」フローのシーケンス図を描きました。
少しだけ全体像が見えてきた気もしますが、今度はデータベース（DB）の設計をやらないといけません。
「DB設計」はゲームでいう基盤みたいなものなので、いざやろうとすると「これで本当に大丈夫？」と不安になります。ただ、とにかくやってみよう！ということで今回はER図を描いて、SQLiteにテーブルを作ってみるところまでを目指します。
- 1. ざっくり考えるテーブル構成
- 2. MermaidでER図を描いてみる
- 3. SQLiteにテーブルを作成してみる
- 4. これで本当に十分なのか…？
- 5. 次回：FastAPIの環境構築＆フォルダ構成
- 6. まとめ
1. ざっくり考えるテーブル構成
今回のモンスター育成ゲームAPIでは、大きく分けて以下のようなテーブルを想定しています。
- users: ユーザー情報（例: ユーザーID、名前、など）
- monsters: ゲーム内で登場するモンスターの種（例: モンスター名、レア度、ステータス基本値 など）
- user_monsters: 各ユーザーが所有しているモンスター個体（例: ユーザーID、モンスターID、レベル、経験値 など）
さらに拡張するなら：
- battle_logs: バトル履歴を残す
- items: アイテム管理（回復薬や進化石など）
- user_items: ユーザーごとのアイテム所有状況
…など
最初は最低限の3テーブルで、ゲームの「所有」部分が動けばOKかな、という方針です。 もちろん本格的に作るなら認証用テーブルやリレーションが増えていくので、後々拡張していくイメージです。
2. MermaidでER図を描いてみる
2.1 ER図サンプル
Mermaidを使うと、以下のようにテキストベースでER図を描けます。
erDiagram
USERS ||--o{ USER_MONSTERS : "owns"
MONSTERS ||--o{ USER_MONSTERS : "instances of"
USERS {
int id PK
string username
datetime created_at
}
MONSTERS {
int id PK
string name
string rarity
int base_hp
int base_attack
int base_defense
}
USER_MONSTERS {
int id PK
int user_id FK
int monster_id FK
int level
int exp
datetime obtained_at
}
erDiagram
USERS ||--o{ USER_MONSTERS : "owns"
MONSTERS ||--o{ USER_MONSTERS : "instances of"
USERS {
int id PK
string username
datetime created_at
}
MONSTERS {
int id PK
string name
string rarity
int base_hp
int base_attack
int base_defense
}
USER_MONSTERS {
int id PK
int user_id FK
int monster_id FK
int level
int exp
datetime obtained_at
}
2.2 解説
- erDiagram: MermaidでER図を書く際の基本宣言
- USERS ||--o{ USER_MONSTERS : "owns":
- ||--o{ は「1対多」の関係を意味し、「USERS 1 : n USER_MONSTERS」を表現。
- : "owns" はリレーションの説明コメント（読みやすさ向上用）
- テーブル定義ブロックでカラムと型を定義
- PKはPrimary Key、FKはForeign Keyを示すだけで、Mermaid上はビジュアル的に分かりやすくなるという感じ。
- USER_MONSTERSテーブルには user_id と monster_id が外部キーとして入る想定です。
Mermaid Live Editorなどで上記コードをプレビューすると、ER図として表示されます。 本来、ER図には「レア度はenum型を使うか？」とか細かい仕様も盛り込みたいけど、とりあえず最初は大まかに定義しておく程度でOKかな…と思ってます。
3. SQLiteにテーブルを作成してみる
3.1 簡単なDDLの例
FastAPIの実装時にORM（SQLAlchemyなど）を使う予定なら、ORMを通じてテーブルを作るのが主流かもしれません。 ただ、今回はまず素のSQLでもテーブルを作れるよ、ということを確認してみます。（最近DynamoDBばかりだったので、実は素のSQLは忘れているのですが…練習がてら書いてみます！）
SQLLiteは以下でWindowsのToolsをダウンロードしました。
sqlite3.exeのフォルダに行き、ファイルを作成します。
sqlite3 fastapi_monster.sqlite3
-- users テーブル
CREATE TABLE IF NOT EXISTS users (
id INTEGER PRIMARY KEY AUTOINCREMENT,
username TEXT NOT NULL,
created_at DATETIME DEFAULT CURRENT_TIMESTAMP
);
-- monsters テーブル
CREATE TABLE IF NOT EXISTS monsters (
id INTEGER PRIMARY KEY AUTOINCREMENT,
name TEXT NOT NULL,
rarity TEXT,
base_hp INTEGER DEFAULT 10,
base_attack INTEGER DEFAULT 5,
base_defense INTEGER DEFAULT 5
);
-- user_monsters テーブル
CREATE TABLE IF NOT EXISTS user_monsters (
id INTEGER PRIMARY KEY AUTOINCREMENT,
user_id INTEGER NOT NULL,
monster_id INTEGER NOT NULL,
level INTEGER DEFAULT 1,
exp INTEGER DEFAULT 0,
obtained_at DATETIME DEFAULT CURRENT_TIMESTAMP,
FOREIGN KEY (user_id) REFERENCES users(id),
FOREIGN KEY (monster_id) REFERENCES monsters(id)
);
SQLiteの管理ツールやCLIでこれを実行すると、3つのテーブルが作成されるはず。
確認コマンド
.table
3.2 実際にデータを入れてみる
試しにmonstersテーブルに何かデータを挿入しておくと、後々API実装したときに便利です。
INSERT INTO monsters (name, rarity, base_hp, base_attack, base_defense)
VALUES ('Slime', 'common', 10, 5, 5);
INSERT INTO monsters (name, rarity, base_hp, base_attack, base_defense)
VALUES ('Dragon', 'rare', 100, 20, 15);
「Slime」や「Dragon」など、ゲームっぽい名前をテストデータとして入れてみましょう。 ここを「ピカチュウ」とか「リザードン」などにすると著作権的にアレなので、自作っぽい名前に。。。
4. これで本当に十分なのか…？
正直、ゲーム要素を作り込むなら、もっと多くのテーブルを分ける必要があるはず。 • 例: ユーザーのログイン情報、アイテムテーブル、バトルの履歴、モンスター進化条件 など。 今回の例は、最低限の部分をまず形にしただけです。 「今後の拡張を見越して設計をどうするか」 は悩みどころですが、やってみないと分からない部分も大きいので、とにかく動かしてみて改善…の流れでいきたいと思います。
あまり、DB設計書があるゲーム開発は聞きませんが、あると、自分が倒れた時など、引継ぎやすいですよね。
テーブル一覧、DESCで見る！
というツワモノもいるでしょう。が、私のような図を並べて全体のDB構成がわかると嬉しいやからもいるのです。。。
5. 次回：FastAPIの環境構築＆フォルダ構成
ER図とDDLができたので、いよいよFastAPIで実際のAPIをつくる準備に入りたいです。
- 仮想環境の作り方
- ディレクトリ構成案（app/main.py とか routers/ とか）
- ORM（SQLAlchemy）を導入するかどうか
…などを整理してみる予定ですが、また「これで大丈夫？」と自問自答しつつ進めることになりそう。 がんばります。
6. まとめ
- MermaidのER図でテーブル間のリレーションを可視化すると、DB構造がイメージしやすくなる
- SQLiteでまずは簡単にテーブルを作ってみた（素のSQL、あるいはORMでもOK）
- 今後はFastAPIとの連携やORMの導入など、実際にAPIが動く段階に進む予定
- ゲーム要素を足すたびにテーブル定義は増えそうなので、こまめにER図を更新していきたい
DB設計は奥が深いのでまだまだ不安は尽きませんが、いったんこの段階で実装を進めていこうと思います。もし「こうした方が使いやすいよ！」とか「もっとこういうテーブルが必要なんじゃ？」というアイデアがあれば、ぜひ教えてください！
