達人に学ぶDB設計徹底指南書第2版・読んだまとめpart3
はじめに
本記事では、第3章を読んで得られた学びや感想をまとめました。
※前回記事はこちら
第3章の目次
論理設計と正規化 〜なぜテーブルは分割する必要があるのか？
３ー１ テーブルとは何か？
３ー２ テーブルの構成要素
３ー３ 正規化とは何か？
３ー４ 第１正規形
３ー５ 第２正規形〜部分関数従属
３ー６ 第３正規形〜推移的関数従属
３ー７ ボイスーコッド正規形
３ー８ 第４正規形
３ー９ 第５正規形
３−１０ 正規化についてのまとめ
習得したこと
⚫︎主キー(primary key)
テーブルにおいて必ず一つ存在しないといけないし、かつ、一つしか存在してはならない。
主キーとはその値を指定すれば、必ず1行のレコードを特定できるような列の組み合わせ。
場合によっては、複数列を組み合わせなければ主キーが作れないこともある。
こうした複数列を組み合わせて作るキーを複合キーと呼ぶ
テーブルのサンプルなどを表記するとき、主キーとなる列の見出しに下線を引いて示す表記がよく使われる。
「候補キー（candidate key）」と「スーパーキー（super key）」と呼ばれるキーもある
⚫︎外部キー(foreign key)
二つのテーブルの間の列同上で設定するもの
外部キーの役割は、あるテーブルに対して一種の「制約（constraint）」を課すこと(部署テーブルに存在しないような部署のデータが、間違って「社員テーブルに登録されないよう防止すること)
⚫︎カスケード
親であるテーブルのレコードが変更されたり削除されたりした場合は、親がいない子”もあわせて削除するか、それとも削除SQL文をエラーにするかを選択できる。このあわせて削除する動作を「カスケード」と呼ぶ。
※ 外部キーが設定されている場合、データの削除は子から順に操作するのが吉
⚫︎制約
① NOT NULL制約
NULLというのはSQL上で扱うにはいろいろな問題を引き起こす厄介なもの。
可能な限りデータはNULLにしない、というのがデータベース設計における大方針。
そこで、「この列は絶対にNULLにはならない」ということがわかっている列については、NULLを禁止することが鉄則！
NOT NULL制約が設定された列にNULLのデータを登録しようとしたり、NULLに更新しようとしたりした場合、そのSQL文はエラーとなる。
主キーとなる列には、DBMS側で暗黙にNOT NULL制約が付加される。主キーは重複が許されないため、NULLも当然許されない。
② 一意制約
一意制約は、ある列の組について一意性を求める制約。
主キーと似ているが、主キーがテーブルーつにつき一つしか設定できないのに対し、一意制約は何個でも設定できる。
③ CHECK制約
ある列の取りうる値の範囲を制限するための制約。
例えば年齢列についてなら、20-70までの整数など。
⚫︎正規形とは
正規形とは、一言で言うと、チータベースで保持するデータの冗長性を排除し、一貫性と効率性を保持するためのデータ形式
※冗長性・・一つの情報が複数のテーブルに存在して無駄なデータ領域と面倒な更新処理を発生させてしまう
※非一貫性・・冗長なデータを保持していると、更新処理のタイムラグによってデータの不整合が発生したり、そもそもデータを登録することができないようなテーブルを作ってしまったりすることがある
⚫︎第１正規形とは
第１正規形の定義は「一つのセルの中には一つの値しか含まない」。この値のことを「スカラ値（scalar value）」と呼ぶ。
なぜ、一つのセルに複数の値を入れることがリレーショナルデータベースでは認められないのか？
→セルに複数の値を許せば、主キーが各列の値を一意に決定できないから。
→正規形全体を理解するための鍵になる概念と結びついている。それを「関数従属性（functional dependency）」と呼ぶ。（YはXに従属する、の関数の考え）
⚫︎第2正規形とは
テーブル内で部分関数従属を解消し、完全関数従属のみのテーブルを作ること
※部分関数従属・・主キーの一部の列に対して従属する列がある場合、この関係を部分関数従属と呼ぶ。
これに対して、主キーを構成するすべての列に従属性がある場合を、完全関数従属と呼ぶ。
では、第2正規形のメリットとは？
テーブルを分割することで更新異常を防ぐことができる。
異なるレベルの実体（エンティティ）を、きちんとテーブルとしても分離してやる
※正規化の逆操作は結合。
⚫︎第3正規形とは
テーブル内部に存在する段階的な従属関係のことを、推移的関数従属と呼ぶ。
推移的関数従属によるデータ登録時の不都合を解消するには、第2正規化の時と同じように、テーブルを分割することで、それぞれの関数従属の関係を独立させる。
一般的な業務を設計する場合、ほとんどのケースでは第3正規形までを意識しておけば事足りる。
★正規化の3つのポイント
①正規化とは更新時の不都合/不整合を排除するために行う
②正規化は従属性を見抜くことで可能になる
③正規形はいつでも非正規形に戻せる
感想
第3章に関しては、基礎的な知識の復習から、知らなかった設計の知識を得ました。
特に、３ー３ 正規化とは何か？以降の章に関しては初めて読みました。
普段の業務では、トータル200個ほど存在するテーブルを使用していますが、
それぞれ業務ドメインにおけるデータを細分化した最終形態なのだと思うと、
このデータたちを第１〜５まで正規化させた人すごい・・と率直に感じました。
今回読んでいて、一般的な業務を設計する場合、ほとんどのケースでは第3正規形までを意識しておけば事足りると読んだので、3.5〜5まではさらっと読ませていただきましたが、
慎重にテーブルを分割しないと、非正規形に戻せなくなるパターンなどもあり、
あくまで戻せる状態に戻せないと正規化と呼べないことを知りました。
この正規化の部分は、いずれ自身でも図とかをさくっと書いて説明できるくらい
もう少し知識を深めたいです。
Discussion