こんにちわ、みけです。
しょぼちむにデータモデル設計について教えてくださいの会 #syoboben - connpass
上記の勉強会に出られない残念な気分(大してないけど)による憂さ晴らしに適当にデータベース設計について、言いたい放題を書き綴るエントリーの第三弾です。
なお、このエントリーは僕の経験と無知と誤解と独断と偏見によるエントリーであって、正しい(?)とかこうするべきとかみたいなエントリーではないので、読む人は本当にここに書かれていることが作成するアプリケーションにとって有用なのかどうか考えてから参考にしてください。
で、今日はそろそろリソースについてって思ってたんだけど、初回、二回目で意識的に無視してきた、ユーザーにとって重要なデータについて書こうと思います。
ユーザーにとって重要な項目たち
前回のアスリートを題材としたテーブルが最終的なリレーションになった時に、元々あった項目がER図上ではなくなっていました。
元々のアスリートエンティティ
| 項目 | データ型 |
|---|---|
| アスリートID | 数値 |
| アスリート氏名 | 文字列 |
| 所属先ID | 数値 |
| 登録年度 | 数値 |
| 登録日 | 日付 |
元々の所属先エンティティ
| 項目 | データ型 |
|---|---|
| 所属先ID | 数値 |
| 所属先名 | 文字列 |
| 登録日 | 日付 |
最終的なアスリートエンティティ
| 項目 | データ型 |
|---|---|
| アスリートID | 数値 |
| 登録日 | 日付 |
最終的なアスリート-所属先エンティティ
| 項目 | データ型 |
|---|---|
| アスリートID | 数値 |
| 所属先ID | 数値 |
| 登録年度 | 数値 |
| 登録日 | 日付 |
最終的な所属先エンティティ
| 項目 | データ型 |
|---|---|
| 所属先ID | 数値 |
| 登録日 | 日付 |
なんか、「アスリート氏名」とか「所属先名」とかユーザーにとって必要な項目がなくなっていますね……
ユーザーにとって重要な項目であるこれらの名前とかは僕は別のエンティティに分けてしまいます。
みなさんなら信じられない！ありえない！とおっしゃるかもしれませんね。
バーチャルエンティティ
各テーブルとそのリレーションにとって最も重要なのはキーであって、アスリート名とか所属先名というのは全く必要ありません。
一方でユーザーやアプリケーションの利用者にとって重要なのはアスリート名であり、所属先名です。
データベースの第三正規形においては、テーブル内で推移的関数従属を排除して、テーブル内の項目は主キーに完全に従属するようにすること(だったかな)です。で、前回はさらにリレーションそのものを外部化して、今回は主キーに従属する項目そのものを外部化してしまいます。こうすることで純粋にエンティティの関連(業務フロー)と、業務で使われていく項目(ユーザーが目にする項目)が分割されていきます。
一緒のテーブルにあったほうが見やすいじゃんっていう人もいると思いますし、業務フローは業務フローで追いやすくしておいたほうがプロジェクトに新規参画した人にとっては優しいこともあります。もちろん分割しておくとデータ容量が増えるので、あれだと思う人もいますし、どうするかは読む人におまかせです。
では、昨日のように分割したER図に、「アスリート氏名」「所属先名」を付与するとこうなります。
このようにエンティティとリレーションに1対1でくっついてくるエンティティをT字型ER手法ではバーチャルエンティティと呼ぶらしいです(よく知らんけど)。
僕がこういう設計すると、1対1でできるテーブルなんて、くっつけちゃえばいいじゃんと言う人、必ずいます。
僕としては、こういうテーブルはくっつけないほうがフローが見やすくて好きです。
以上、めっちゃ適当に書いた。
