こんにちは、やまだたいし( やまだ たいし (@OrotiYamatano) / X )です。
今回はマスターデータの構造の定義についてです。
目次
なぜ今回マスターデータの定義について書くのか
普段マスターデータを作ることがあるのですが、
他の方が書かれたマスターが微妙なことが多い気がします。
そもそもとしてエンジニアではなく企画が書くことも多いため仕方がないのかなと思っていたのですが、
どうやらエンジニアが定義する場合も微妙になってしまうことが少なくないと最近知りました。
そこでエンジニアとして業務DB設計も行ったことがある私がマスターデータの定義の行い方を解説することにしました。
ここで言うマスターデータとは
ここでいうマスターとは業務エンジニアがよく言う元データ、初期データの意味ではなく
ゲーム業界で言われる必ずしもDBでもつ訳では無いデータ群、ユーザーによって変化する事のないデータ群のコト。
例えばアイテムテーブルなどがそれに該当します。
実際にマスター設計をしていく
実際にマスターの設計をしていってみましょう。
1.要件を洗い出す
何かしらデータが必要になったとします。
例えばRPGであればHP、防御力、攻撃力などです。
まず洗い出しやすい要件としては画面表示に必要なデータです。
次に、その上で表示しているデータが計算や複合情報によって成り立っているなら、
目に見えないデータも存在することになります。
一つ一つ洗い出しましょう。
キャラクター表示名は一意なのか、省略名称はないのか?
レベルテーブルはいちレベルごとに定義するのか、それとも計算式で出すのか……。
とにかく項目を洗い出します。
この項目をカラム、そして一つ一つのデータをレコードと呼びます。
2.正規化
一覧を出したらココから正規化というものを行います。
きれいにデータを扱うためのルールを適用するというぐらいの認識でOKです。
これは一般的にデータをきれいに作る上で一般的なものになります。
2.1 第一正規化
第一の条件は一つのセルには一つの値です。
例えばキャラクターの二つ名とキャラ名が同じレコードに入っている場合はルール違反です。
二つ名カラムとキャラ名カラムにわけましょう。
また、Jsonデータを1レコードにいれてるところを見たことがありますが、よほどのことが無い限り辞めましょう。
2.2 第二正規化
第二の条件は一意にレコードを検索できるようにすることです。
いわゆる主キーが一意に決められていればOKです。
そうでないものは検索した時に複数出てきてしまい、困ることになります。
主キーとサブキーで特定出来る場合は一応OKですが、極力一つの検索で済む方が良いかもしれません。
2.3 第三正規化(と第四正規形)
第三の条件は縦の列に同じ値を使い回す必要をなくすことです。
例えば属性とかはキャラクターのレコードごとに属性を入力するのではなく、
属性に対して属性テーブルを定義し、IDで入力が終わるようにするのがベストです。
いわゆる別レコードで持つべき値をカラムに持つのもやめるべきです。
特に企画陣営が出来ていないレコードの正規化です。
とはいえ、コレはゲーム業界においては嫌われるケースも存在します。
理由としてはIDではなんの値が入力されているかわからないなどです。
値に関しては文字列IDを使うなどで回避することもできますが
またプランナーはエクセルで入力することが多く、複数テーブルに分かれると複数のエクセルに対して入力をしなければならず、
それを嫌う人がいます。
正直プログラマーとしては正しく第三正規形を行ってほしいですが、分割すべきレコードが少ないのであれば
第二正規形で止めてしまうのもゲーム業界においてはありだと思います。
(まぁそもそもとしてDBで絞り込みを出来るようなツールがあればプランナーさんも不便なく
マスターデータの入力が出来ると思うので今後そういったDBがゲーム業界には必要だと感じています)
ただし、この場合、後から2つ属性を持たせたいなど要件が後から発生した場合、
属性セットテーブルを作れば良いところ、改変が大変になりますので、要件が増えそうな場合はやはり、しっかりと正規化しておくとよいです。
2.4 不必要な分割はやめよう(第五正規化)
逆に必要ない分割を行っているケースも見ます。
例えば、横に長い、カラム数が多いテーブル定義を2つのデータにわける行為です。
横に長いテーブルはデータ定義としてNGではありません。
一意に決定できるのならばテーブルをわける必要はありません。これらを統合しましょう。
そもそもとして横に長過ぎる場合は第三正規化/第四正規化がうまく出来ているかというチェックは必要だと思います。
以上！
単純にDB設計と同じですが、当たり前のことを当たり前に書いている記事が無かったので書かせて貰いました。
これらについて気をつけて設計してくれるときれいに作れるのかなと私は思いました。
関係データベースの正規化で検索すると正規化についてはいくつも記事が出てくるので参考にすると良いでしょう。
例えば↓とかがわかりやすかったです。
talosta.hatenablog.com
皆さんきれいな設計を心がけて言ってください!
以上、やまだたいしでした。
