中山テック 代表の中山です。
さて、もうすぐ4月出会いの季節ですね。
新入社員も入社し、CRUD図との出会いの季節でもありますね。
データベースとの出会いはCRUD図との出会いでもあるので必要性を話していきたいと思います。
特に難しい話はありません。
この法則を知っていればどのような設計書かわかると思います。
【C】・・・Create。新規登録、つまりINSERTする場合はCで表現
【R】・・・Read。読み取り、つまりSELECTする場合はRで表現
【U】・・・Update。更新、つまりUPDATEする場合はUで表現（そのまんまですね）
【D】・・・Delete。削除、つまりDELETEする場合はDで表現
CとRがどんなものか？というのがわかれば難しい話ではないと思います。
何のために？
以前、PostgreSQLをインストールしてレコード追加する方法ブログで作った三冠馬を格納するテーブル。
このテーブルがどのような役割を果たしているか、CRUD図を見ることで判定するための指標になります。
例えば
・新しい三冠馬が生まれたら新規登録・・・C、つまりINSERTが必要
・三冠馬が古馬になってから勝ったGⅠレースを知りたい・・・R、つまりSELECTが必要
・登録している三冠馬が古馬GⅠ制覇したら更新・・・U、つまりUPDATEが必要
CRUD図で表現する場合はC、R、Uが必要です。
三冠馬が消えることはないので、Dは必要ありません。
後学のために
データベースを使用するプロジェクトは規模が大きい場合が多いです。
その場合、お金も動くので人も動きます。
熟練の方の場合はデータベースのつながりを気にしますので、この表は必要でしょう。
また、新卒の方であれば「データベースがこのような役割をしている」という教育もしやすくなります。
色々な意味を込めてCRUD図は作るようにしましょう。
証跡として
設計段階で作成しておくことで、お客様が「このテーブルはUとDはないんだな」
また別紙を作って「更新時はUNDOログとREDOログにこれだけ影響がある」まであると完璧です。
UPDATEとDELETEは件数にもよりますが、基本レコードが多い場合はすべきではありません。
トランザクションをコミットする際にサーバ処理に多大な影響を与えてしまいます。
そのようなことのないようにCRUD図は必要不可欠な図になります。
まとめ
いかがでしたでしょうか。
CRUD図が必要な理由を説明しましたが、単純にテーブルの役割を示しています。
派生して、テーブルのUとDの際にログにどこまでの影響を与えるか記載する必要もあるでしょう。
深読みではなく、UNDOログもREDOログも最低限必要な情報になるのです。
出会いの季節にCRUD図との出会いで青春を謳歌して頂ければと思います！
