テクニカルアーティストのためのデータベース入門 (4) 「エンティティ」と「リレーション」
アセットの要素分解
冒頭の図を「ER図（Entity Relation Diagram）」と呼ぶ。
詳しい書き方は省略するが、要するにアセットの設計図だ。
ER図自体は本来DBの設計などに使われるグラフだが、よく似た図を、TAなら何度も見たことがあるはずだ。例えばMayaのノードグラフとか。実際のところ、（それが有用かどうかはさておき）Mayaのノードグラフは、MySQLなどのDBにそのまま落とし込むことができる。というか、ノードグラフとはMayaが構築しているデータベースであると、自分なんかは考える。
エンティティ
実際にアーティストがデータを制作するときの手順を考える。
Mayaでモデリングをして、「モデル」を作成する。作成したモデルは、「ファイル」として保存される。Photoshopで「テクスチャ」を描く。描いたテクスチャは、「ファイル」として保存される。Mayaに戻って、作成したテクスチャを読みこんで、モデルに貼り付ける。このとき、これを制作したアーティストは、「成果物としてのモデル」「モデルが参照するテクスチャ」「それらが保存されたファイル」を管理することになる。これらの管理対象のことを、エンティティと呼ぶ。
ノードグラフの「ノード」と考えてしまって差し支えない。
モデリングについて詳しくみてみる。以下は、キューブの1面をエクストルードしたもの。これをつくった人は、「元のモデル」「モデルを押し出すという操作」「出来上がったモデル」の3種類を管理しているはずだ。なので、これら3つをエンティティとして考えることもできる。
リレーション
冒頭の図にある Model / Texture / File の関係性を整理してみると、だいたいこんな感じになると思う。
- 1つの Model は、複数の Texture が設定される可能性がある
- 「0枚以上の Texture が設定される」と言い換えることもできる
- 1つの Model は、1つの File として保存される
- 1つの Texture は、1つの File として保存される
ここでは「設定」という言葉を使ったけど、実際には、モデルがテクスチャを参照するのか、テクスチャがモデルを参照するのかはケースバイケースになると思う。1つのモデルやテクスチャは、基本的には1つのファイルとしてファイルシステム上に表現される、ということにしておく。
この、「ModelとTextureとの関係性」や「TextureとFileとの関係性」を、リレーションと呼ぶ。
ノードグラフの「エッジ」と考えてしまって差し支えない。
ふつうのアセット制作の場合、だいたい以下4つのリレーションを押さえておけば事足りると思う。ネーミングは適当なので、人やチームによって変わるかもしれない。
- 参照（依存）
- モデルはテクスチャを参照する
- ジオメトリキャッシュはアニメの計算結果に依存する
- 構成（細分化）
- 表現形式
- テクスチャの実体はファイルとして表現される
- 制作進行ステータス（「開始」「レビュー」「完了」など）はステータスIDとして表現される
- 状態
- モデルAは「制作中」という状態である
- キャラBは武器Cを装備している状態である
リレーションというのはあくまで概念なので、実際にDB上でどう表現されるかは場合によって異なる。例えば、「モデルはテクスチャを参照する」というのは、「modelsテーブルにtexture_idが保存される」かもしれないし、「texturesテーブルにmodel_idが保存される」かもしれないし、「model_texture_mapsテーブルにmodel_idとtexture_idの組み合わせが保存される」かもしれない。他のやり方ももちろんある。
アセットのER表現
つまり、管理すべきアセットとそれらのアセット同士の関係性を整理する、アセット全体をノードグラフとして表現する、TAが扱うDBというのはそういうものになることが多いと思う。
