株式会社リゾーム 技術部 システム開発 第1グループの小田です。今回は「スッキリわかるSQL入門」読書会の第12回レポートです。 過去のレポートはこちらからご覧いただけます。
書籍について
前回に引き続き「スッキリわかるSQL入門 第3版」を題材としています。
第12回レポート
今回は第12章「テーブルの設計」の後半部分（5～7節）のレポートになります。 前回は正規化の概要について触れましたが、今回は正規化の具体的な手順やテーブルの物理設計について学習しました。
参加者は5名でした。
12.5 正規化の手順
正規化によってテーブルが適切に分割された状態を正規形と言います。 正規形は第1正規形から第5正規形まで存在しますが、本書では通常のシステム開発業務で求められる第3正規形までを解説されていました。 第1～第3正規形に変形するための具体的な手順は以下になります。
- 非正規形 → 第1正規形：繰り返し列の排除
- 第1正規形 → 第2正規形：複合主キーの一部への関数従属の排除
- 第2正規形 → 第3正規形：間接的な関数従属の排除
また、正規化後にはER図を作成するのが一般的です。 ER図にはお客様の理想・要件を起点とする設計の流れで作成するものと、お客様の今の現実を起点とする設計の流れで作成するものの2種類があり、それぞれ「トップダウン・アプローチ」と「ボトムアップ・アプローチ」と呼ばれています。 前者のER図を基本にしつつ後者のER図から得られる情報を適切に取り込んでいくことで、新たな要件を満たしつつも可能な限り仕様漏れを防ぐことが出来ます。
参加者の意見・感想
- 「きたない関数従属*1」は2種類あって、それぞれを解消するのが第2正規形と第3正規形という説明が図で整理されていてわかりやすかった
- 今まで「ここ、冗長だから別テーブルにしたほうが良いのでは？」という感じで正規化をやっている部分があった。「ここが部分関数従属で～」とか、「ここが推移関数従属で～」とかはあんまり考えていなかったので、今後は意識してみようと思う
- トップダウン・アプローチとボトムアップ・アプローチはどちらも重要。理想と現実をうまくすり合わせていくことが大事なんだな
12.6 物理設計
物理設計とは論理設計後に行う工程です。物理設計では論理モデルを元に、使用するDBMS製品独自の制約を考慮しつつ全テーブルの物理モデルを作成します。 また、作成した物理モデルはそのままDDL（主にCREATE文）に変換できる内容になります。 具体的には以下のような内容を確定させていきます。
- テーブルやカラムの物理名の決定
- カラムの型や制約の決定
- インデックスの決定
参加者の意見・感想
- 数値なら精度、文字列なら長さを決める必要があるし、DBMSによって型の仕様も違ったりする。よく考えて決めなければ
- テーブル名、列名を英語で名前付けする際、たとえ意味が正しくてもマイナーな単語を使うとかえって分かりづらくなることがある。名前の正確さとわかりやすさのバランスを取るのが難しい
- 書籍に書いてある「性能のためにあえて正規化を崩す」というのは聞いたことがある。参照頻度の高いカラムなどはキッチリ正規化して別テーブルに持たせるより、ある程度正規化を崩して同一テーブルに持たせた方がJOINの回数を減らせるので結果的にパフォーマンスが上がることもあるらしい
12.7 正規化されたデータの利用
整合性を維持しつつ効率よくデータを管理するためには、データを複数のテーブルに分けて格納する必要があります。 一方でデータを便利に利用してもらうためには、複数のテーブルの内容を1つの結果として見せたり、それをさらに集計したりする必要があります。 それら2つの形態を変換する技術が正規化と結合です。 正規化や結合といった技術を駆使することで、データベース上では整合性を保ちやすい効率的で安全なデータ管理ができ、お客様からはデータを見やすく分かりやすいシステムを作ることができます。
参加者の意見・感想
- データの管理は複数テーブルで行い、利用時には1つのテーブルに見える形にするのがよい
- 書籍の「そもそも私たち人間は、曖昧で、ある程度の冗長を含む情報に取り囲まれて生活しています。(...) 人間にとってはあまり正規化されていない情報のほうが取り扱いやすいのでしょう。」という内容について、Excelシートの結合を見かけるたびにうすうすそんな気がしていた
- Excelや紙だと集計しにくくなるのを承知の上で見やすさや把握しやすさ優先のキタナイ表にすることもあるが、DBの場合はビューなどを使用した人間向けの画面と、正規化された中身で分けて運用できる
まとめ
今回は論理設計や物理設計の具体的な手順について学習しました。 この辺りの内容については体系的に学習したことのない参加者も居たため、非常に良い機会となりました。 また、書籍に書かれていた「性能のためにあえて正規化を崩す」というのは、SQLのパフォーマンス面で躓いた際に手段の1つとして思い出せるようにしておこうと思いました。
今回の第12回レポートで「スッキリわかるSQL入門」の内容は終了となります。 他にも本書の巻末には陥りやすいエラーや落とし穴とその対処法であったり、SQLのドリルも付いています。 それらも含め、特にSQL初学者には非常にオススメできる1冊だったように思います。 今後私が新入社員教育を担当することがあれば、SQLの学習にはぜひ本書を採用したいと思います。
*1:本書独自の言い回し。第2正規形の場合は複合主キーの一部への関数従属、第3正規形の場合は主キーへの間接的な関数従属がそれぞれ「きたない関数従属」に当たる。
