株式会社リゾーム 技術部 システム開発 第1グループの岩﨑です。今回は「スッキリわかるSQL入門」読書会の第11回レポートです。
過去のレポートはこちらからご覧いただけます。
書籍について
前回に引き続き「スッキリわかるSQL入門 第3版」を題材としています。
第11回レポート
第12章「テーブルの設計」の前半部分（1～4節）のレポートになります。前回まで様々なSQLの文法やDBMSの機能について学んできましたが、今回は少し異なり「概念設計」「論理設計」などのテーブル設計の手順について学習しました。
参加者は4名でした。
12.1 システムとデータベース
まずデータベース設計作業の一通りの流れをざっくりと学習しました。データベース設計は多くの場合、以下の流れで行われます。
実際にSQLを書くのは5番目の段階であることから、これまでに学習したSQL文法やDBMSの機能を理解し扱えることとシステムを適切に設計できるということは、関連があるにしてもイコールではないということがわかりました。
参加者の意見・感想
12.2 家計管理データベースの要件
システムには利用者がいるため、利用者側の要件をしっかりと洗い出すことが大切です。本節では「家計管理データベース」という具体的な例から、要件の聞き取りにおいての注意点を学習できました。
参加者の意見・感想
- 関係者間の意識合わせをしておかないと、後々仕様が大きく変わる可能性がある
- 複数の要件間で矛盾が出ないよう注意する
- 「お客様の要望＝お客様が本当に必要なもの」とは限らないため、難しいけど注意する必要がある
12.3 概念設計
概念設計では、要件を実現するためにデータベースで管理する情報を抽象化します。概念設計は結局どうすれば正解なのかとつい考えてしまいますが、唯一の正解があるわけではないため、練習や実践を重ねたり実例を沢山見て慣れていくことが重要そうです。
参加者の意見・感想
- 資格試験で学習したときには概念的なもののイメージを掴むのにかなり苦戦した覚えがあるが、本書で書かれているヒントをもとにイメージしていくことで理解が進んだ
- 最初の頃はエンティティが何を指しているのか理解するのが大変だった思い出
- 本書では「情報の塊」「テーブルの原石」という表現で書かれており、イメージしやすい
- 各エンティティの関係を明らかにしておくと全体の構造が分かりやすくなる
- 形のない概念をエンティティにするのが難しそう……
- 二重構造エンティティ（エンティティの中に別のエンティティを作ること）はできない
- 今まで自然とやっていたが、そういう場合は別のエンティティとして外部に取り出す必要があるということを改めて学んだ
また、意見交換ではデータベースからER図を自動生成するツール「A5:SQL Mk-2」についての話も挙がりました。ER図を一から書かなくとも良いというのはとても便利ですね！
12.4 論理設計
論理設計では、概念設計で抽象化したものをデータベースが扱いやすい構造に変換するため、キーの整理、正規化（詳しくは次回レポート）などを行います。本節では「主キーは重複しないだけでなく、非NULL性、不変性も満たす必要がある」など、普段自然とやってきたことを例をもとに改めて学習することができました。
参加者の意見・感想
- きれいに正規化されたテーブルだとアプリ画面での操作も楽なはず
- 多対多になっているエンティティは中間テーブルを追加することで1対多になるよう変換する
- 主キーはちゃんと考えて付けないと、いざ運用が始まってから主キーを変えるとなるとかなり大変
- RailsはデフォルトでIDが主キーになるので主キーを考える手間が省ける
まとめ
今回はデータベース設計の要望聴取～論理設計を学習しました。「SQLの学習」といえばどうしても文法ばかりになってしまうため、今回の範囲でデータベースの設計作業を学習することができて良かったです。今後データベースの設計作業に関わることもあるかと思いますが、苦手意識を持たずポジティブな気持ちで挑みたいと思います。
次回の範囲は第12章「テーブルの設計」の後半（5～7節）です。
