🎃

【DB設計】テーブル設計はいきなりテーブルから考えてはいけない話

2023/10/13に公開

テーブル設計はいきなりテーブルから考えてはいけない

「テーブル設計って言われても、どんなテーブルを作ればいいかさっぱり分からん・・・」となったことありませんか？

僕はあります。

そうなるのは、いきなりテーブルから作ろうとしているからです。

では何から考えればいいのかというと、まずはオブジェクトから考えるのです。

オブジェクトとは、オブジェクト指向という言葉にも出てくるオブジェクトのことです。
データベースの場合は、テーブルの中にあるレコードがこれに当たります。

あくまでテーブルはレコードを格納する入れ物なので、より具体的なレコードから考えましょうということです。

では具体例を用いて解説していきます。
最近名前が変わったX（Twitter）のフォロー機能を考えてみます。

DB設計をする段階で画面設計（UI設計）はあるはずなので、UIから必要になるオブジェクトを考えていきます。

UIを見て注目すべきなのは、「名詞」と「動詞」です。

まず目についた「Elon Musk（イーロン・マスク）」さんというアカウントを抜き出してみます。

図はdraw.ioを使っています。図を書くツールは最近だとMiroも人気です。とはいえ手書きが一番自由度が高いので、最初は手書きで考えるのがいいと思います。

ここではフォロー機能について考えているので、「フォローする」という動詞を抜き出します。

ここまでで「イーロン・マスクさんがフォローする」まで表現できました。じゃあどのアカウントをフォローしているかというと、「SpaceX」をフォローしています。

ここまでで「イーロン・マスクさんがSpaceXをフォローする」まで表現できました。

この繋がりをデータで表すと、フォローオブジェクトがそれぞれのアカウントIDを持てば表現できます。

イーロン・マスクさんは他にも「Tesla」をフォローしています。

テーブルではなくオブジェクトで表現することで、オブジェクト間のリレーションが1対1なのか1対多なのかもパッと見でわかるようになります。これも大きなメリットです。

ここまでできてやっと、これをテーブルとして表現していきます。

1つのアカウントは0〜n人をフォローすることができ、フォロワーも0〜n人作ることができます。

無事にER図を書くことができました。

実際には、ここから英語に翻訳したりデータ型を考えたり、NOT NULL制約やユニーク制約を考えたりといったことを行います。

以上、テーブル設計はいきなりテーブルから考えてはいけないという話でした。

まずはオブジェクト（レコード）から考えていきましょう。

人間は具体的なことから抽象的なことや共通点を見つけるのは得意ですが、いきなり抽象的なことを考えるのは苦手です。

オブジェクトはUIで目に見えるので具体的ですが、テーブルはそのオブジェクトを格納するものなので少し抽象的です。

なので具体的なオブジェクトから考えてそれをテーブルに直した方が、人間は考えやすいのです。

少しでも参考になれば幸いです。