やわらかテック

興味のあること。業務を通して得られた発見。個人的に試してみたことをアウトプットしています🍵

スプラトゥーン3のER図について考える【キャラクター編】

こちらの記事を見て、自分も別のテーマでやってみたいと思います。
ちょうど同じ任天堂のスプラトゥーン3にドハマりしているので、スプラトゥーン3を題材にやってみます。

qiita.com

なかなか、新規にデータベース設計をすることはないので、良い練習になりそうです。

1.出したい画面

スプラトゥーン3はキャラクターの作成から始まります。
ここでキャラクターのスタイル(見た目)を決定します。後に変更することも可能です。

決定する項目

  • イカ or タコ
  • 性別
  • 目の色

etc...

決定したスタイルはメニュー画面の「スタイル」のタブから確認することができます。 今回、出したい画面はこちらの画面です。キャラクター作成時に選択したヘアスタイルなども、ここに表示されています。

画面下には選択中のブキ・アタマ・フク・クツが表示されます。アタマ・フク・クツには登録しているギアの情報も表示されます。

2.どんなデータ必要か列挙する

思いつく限り、バンバン出してみました。
表示値とは別にキャラクターに設定された目の色などの値も含んでいます。

キャラクター作成

  • プレイヤー名
  • イカ or タコ
  • 性別
  • 目の色
  • 肌の色

メニュー画面

  • 選択中のヘアスタイル・マユゲ・ボトムス
  • ヘアスタイル・マユゲ・ボトムスの一覧
  • 選択中のブキ・アタマ・フク・クツ
  • ブキ・アタマ・フク・クツなど装備の一覧
  • アタマ・フク・クツのレア度(☆で5段階表示)
  • ブキの熟練度(☆で5段階表示)
  • アタマ・フク・クツに付いてるギアの一覧
  • ギアの一覧
  • マイコーデ

3.時系列に並べる

1. メニュー画面を開く(開いた時点で表示されないものは不要データとします)

  • イカ or タコ
  • 目の色
  • 肌の色
  • ヘアスタイル
  • マユゲ
  • ボトムス
  • 選択中のブキ・アタマ・フク・クツ
  • ブキ・アタマ・フク・クツ・エモートの一覧
  • マイコーデ

2. その他: スタイルの画面を開く

  • 選択中のヘアスタイル
  • 選択中のマユゲ
  • 選択中のボトムス
  • ヘアスタイルの一覧
  • マユゲの一覧
  • ボトムスの一覧

4.データのかたまり毎に分類してみる

エンティティに分解して、それぞれまとめてみました。
主にスタイルに関するエンティティと装備に関するエンティティに分けました。スプラトゥーン3では装備を購入、解放していく必要がありプレイヤーが所持している装備の一覧を管理する必要があります。

スタイルに関するエンティティ

装備に関するエンティティ

唯一、ボトムスには副項目が存在しています。
別のテーブルにするにも項目が完全に一致してしまうので、1つのテーブルで親レコードIDを記録する形にしました。やろうと思えばツリー構造を表現できるため汎用性が高い気がしますが、1階層しか使わない想定なのでOKとしました。

5.エンティティ同士の関係性を線でつなぐ

リレーションを書き込みます。装備側を書くのが難しかったので2枚に分割しました。
ブキにはサブウェポン、スペシャル。装備にはブランドやつきやすいギアといった概念があるのですが、今回は簡単のためにエンティティは削除しました。

https://asset.watch.impress.co.jp/img/gmw/docs/1433/828/0_l.jpg

引用: 「スプラトゥーン3」、ブキの買い方や「カンブリアームズ」の情報&画像公開! - GAME Watch

スタイルに関するエンティティのリレーション

装備に関するエンティティのリレーション

装備と装備一覧

装備と共通項目・ギア

6.それらしいカッコイイ項目名を付けてあげる(英語)

特に特筆すべきことはありません。7の作業でまとめてやってしまいます。

7.図に落とし込む

Lucidchartを使いました。サイズが大きくなったので、画像にするのは諦めて埋め込み形式にしました。
こうしてみると、メニュー画面を出すだけでも、かなり多くのエンティティが登場していることに驚きます。サブウェポンやスペシャル、ブランドなどの概念を省略してこの量なので、実際はもっと多くて複雑だと思います。

感想

とりあえず形になったので一安心しました。
最近、データベース関連の書籍を何冊か読みましたが実際の業務でテーブルを設計するということはなかったので、良い練習になりました。この方法だといくらでも題材を作れるので練習にはピッタリです。SQLを書いて実際にデータを登録すれば、実際に使うに十分なテーブルかを確かめることが出来ます。

実際にSQLを書いてみました。かなり多くのテーブルを作ってサンプルデータを入れるのに時間がかかりましたが、目当ての情報を取得することが出来ました。JOINの発行回数が多いのが難点です。正規化の代償です。まさにトレードオフ...。

 プレイヤーid |   名前   | 性別 | 種別 |    目の色    |    肌の色     | ヘアスタイル  |   マユゲ    | ボトムス  | ボトムスサブ 
--------------+----------+------+------+--------------+---------------+---------------+-------------+-----------+--------------
            1 | ぎょうざ |    1 |    1 | eye_colors/1 | skin_colors/1 | hair_styles/1 | eye_brows/1 | bottoms/1 | 
(1 row)

 プレイヤーid |  ナマエ  |     アタマ     |   フク    |       クツ       |       ブキ       
--------------+----------+----------------+-----------+------------------+------------------
            1 | ぎょうざ | ギョウザヘッド | ギョウザT | ギョウザサンダル | わかばシューター
(1 row)

スプラトゥーン3のER図を考える【キャラクター編】の装備側のSQL · GitHub

スプラトゥーン3のER図を考える【キャラクター編】のスタイル側のSQL · GitHub

今回の悩みポイント

  • 1.アタマ・フク・クツのテーブル構造が似ているため、共通化するかどうか -> アプリケーション側で制御したくないのでテーブルを分割
  • 2.所持している装備をどうやって表現するか -> 中間テーブル(got_xxxx)を作成して管理
  • 3.登録しているギアを中間テーブルで表現するかどうか -> スプラトゥーンの仕様上4つで固定なため不採用
  • 4.装備の共通項目をどう表現するか -> 外部テーブル(equipment_commons)に記録

例えば、3に関してはアンチパターンとして書籍「SQLアンチパターン」で紹介されていますが、登録できるギアは4つまでという仕様があるため問題なしとしました。こうしたトレードオフの選択は実際に設計しなければ体験することが難しいですね。

www.okb-shelf.work

今回、自分が設計したテーブルにもまだまだ改善点があると思いますが、皆さんもぜひ身近な題材でテーブル設計にチャレンジしてみてください。

少しでも「ええな〜」と思ったらイイネ!・シェア!・はてなブックマークを頂けると励みになります。