← メディア一覧

DBの断捨離:正規化

6分48秒 | DB設計FE

基本情報技術者試験の頻出テーマを解説した動画コンテンツです。

トランスクリプト(字幕テキスト)

こんにちは。今日のテーマはデータベースの正規化。まあ、一言で言うとデータの断捨離ですね。 一見きれいにまとまっているように見えて、実はいつ爆発するかわからない爆弾を抱えているデータを、 安全で効率的な形に変える、そんなテクニックです。さあ、一緒に見ていきましょう。 でもぶっちゃけこう思いません?え?全部ひとつの大きな表にまとめておいた方が、 パッと見て分かりやすいじゃんって。わざわざ表を分けるなんて、逆に管理が面倒くさくなりそうな気もしますよね。 例えばこの表、学生のIDに名前、科目に成績、担当の先生の名前と部屋番号まで、全部入っててすごく便利そう。 ですよね。でもよく見てください。この重複している教授のデータ。そう、ここです。ここ、赤く光ってるところ。 ここを直すとなると、こっちもあっちも直さなきゃいけない。面倒ですよね。実はこれが時限爆弾のスイッチになってるんです。 そうなんです。データが重複してるってことは、もう爆弾を抱えちゃってるのと同じなんですよ。なぜかって、 この重複が「更新異常」っていう、とんでもなく危険な状況を引き起こすからです。 更新異常っていうのは、データの修正漏れでデータがぐちゃぐちゃになっちゃうことです。 例えば、ある教授の部屋が変わったとしますよね。そしたら、この教授が教えてる学生100人分のレコードを、 全部1個ずつ手で直さなきゃいけないんですよ。もし、たった一つでも直し忘れたら? はい、その瞬間データの信頼性はゼロ。これが爆弾の正体です。じゃあ早速、この爆弾、解体していきましょうか。 最初のステップは、爆弾の配線を1本1本丁寧に整理していくイメージです。つまり、セルの整理整頓からですね。 第1正規形、1NFって呼ばれます。ルールはめちゃくちゃシンプルです。「1つのセルには、1つのデータだけを入れる」 というルール。複数の値をカンマ区切りで入れることは許されない。入れちゃダメ。ただそれだけ。 例えば電話番号をカンマで区切って、1個のセルに入れるみたいなのはもう絶対ダメってことですね。 はい、これがまさにそのダメな例です。電話番号の列に、電話Aと電話Bがいっしょくたに入っちゃってますよね。これはNGです。 で、これを1NFに直すとこうなります。1行だったのを2行に分けて、それぞれのセルに電話番号を一つずつ入れました。 1マス、1データ。これが鉄則です。さて、次のステップです。ここでは主役、つまりキーにちゃんと従っていないデータ、 いわば「関係者以外立ち入り禁止」みたいな感じで、別の場所に移動させちゃいます。第2正規形、2NFですね。 こいつの目的は、部分的な依存をなくすことです。どういうことかというと、 例えば主キーが学生IDと科目コードの2つでワンセットなのに、データの中に「いや、私は学生IDだけで決まりますんで」 みたいなちょっと中途半端なやつがいる。そういうのをなくすためのルールです。この表を見てみてください。 主キーは学籍番号と科目コード、この2つでセットです。この2つが決まれば成績がピタッと1つに決まる。 でも、学生名ってどうでしょう。これって、科目コード関係ないですよね。学生IDさえわかれば決まっちゃう。 これが問題の部分的な依存なんです。ほら、こうやって見ると分かりやすいですよね。成績は主キー全体にちゃんとくっついてる。 でも、学生名は主キーの一部部分である学生IDにしかくっついてない。このちょっといびつな関係を断ち切る必要があるわけです。 そこで、この表をえいっと2つに分けちゃいます。こんな感じに。片方には主キー全体に関係する情報だけ。 そして、もう片方には学生IDと学生名っていう、純粋な学生だけの情報をまとめるんです。どうです。すっきりしましたよね。 さあ、いよいよ最後のステップですよ。ここでは、主キーから見たらなんだか寄り道してるみたいな間接的なデータをバッサリ整理していきます。 第3正規形、3NFが狙うのは、推移的依存です。これ何かって言うと、主キー以外の列同士で決まる関係をなくすルール。 「郵便番号→住所」のような関係が対象です。なんか勝手に「私たち付き合ってます」みたいな関係になっちゃってる状態。面白いですよね。 この表だと、主キーは学生IDです。でも、住所って学生IDで直接決まるわけじゃないですよね。そう、郵便番号で決まる。 つまり、学生ID、郵便番号、住所っていうまさに寄り道が発生しちゃってるわけです。これが推移的依存ですね。 この図を見てもらうと、その寄り道ルートがはっきり見えますよね。主キーとは直接関係ないところで郵便番号と住所が勝手にペアを組んじゃってる。 この関係もちゃんと整理してあげないといけません。というわけで、ここもスパッと分けちゃいましょう。 学生の情報テーブルと郵便番号と住所の対応表。こうやって分けることで、やっと全ての列がそのテーブルの主キーだけに直接くっつくという、 めちゃくちゃ綺麗な状態になったわけです。ここまでひたすら表を分割してきましたが、何でこんな面倒臭そうなことが、 最終的に、より強くて頑丈なシステムにつながるんでしょうか。ちょっと振り返ってみましょうか。データ爆弾を解体した3つのステップです。 ステップ1で、ごちゃごちゃの配線を1本ずつ整理して1NF。ステップ2で関係ない部品を取り除いて2NF。 そしてステップ3で、遠回りしてる回路を断ち切った3NF。この3段階でデータは完全に安全になるんです。 で、ここが一番大事なポイントです。一見バラバラになったように見えるこの構造こそが、実はたった1箇所直せば、 関係するところ全部が正しくなるっていう最強の砦になるんですよ。教授の部屋が変わった?大丈夫。直すのはたったの一箇所だけ。 もうデータの食い違いなんて起きようがないんです。さて、今回の解説はここまでです。最後にあなたに聞いてみたいと思います。 あなたの扱っているデータ。その中に、まだ誰も気づいていない爆弾、隠れていませんか?

このコンテンツは Web society で視聴・学習できます。