データの断捨離で重複と矛盾を防ぐ正規化

今回はですね、あなたが送ってくださったデータベースの正規化に関する資料、これを深掘りしていきたいと思います。 まず、資料を拝見して思ったんですけど、注文日とか顧客名、住所、商品名ってありますよね。 こういうのって、全部1つの大きな表にまとめた方がパッと見でわかりやすくないですか？ ああ、その気持ちすごくよくわかります。ええ。でもですね、実はそれがデータをゴミ屋敷にしちゃう、まあ最初の大きな一歩なんですよね。 ゴミ屋敷ですか？ええ。ちょっと考えてみてほしいんですけど、もしあなたの会社のあるお客さんが100回注文したらどうなります？ 100回。その人の住所を毎回毎回100回入力することになるわけですよね。うわあ、確かにそれはちょっと。 もう住所、住所、住所。でもしそのお客さんは引っ越したら？ああ、その100カ所全部をこう、きっちり修正しないといけない。 それは大変だ。1つでも忘れたらもうデータに矛盾が生まれる。これが更新不整合っていう、結構恐ろしい問題なんです。 なるほど。このごちゃごちゃを解決する整理術がまさに正規化なんです。データの重複をなくして矛盾を防ぐための、まあ設計手法ですね。 これを使えば、あの住所の変更もたった1箇所で済むんですよ。おお、それは魅力的ですね。1箇所で済むというのは。 ええ。ではその整理術、具体的に見ていきましょうか。どういうステップがあるんですか？ はい。正規化には段階があって、まあ一般的には第三正規形までが重要だと言われています。まずは、第一正規形。 第一、はい。ルールはすごくシンプルで、1つのセルには1つの値だけ。これだけです。1セルに1値。 ええ。例えば商品のセルにリンゴ、バナナって複数の値を入れるんじゃなくて、行を分けてリンゴの行、バナナの行と。 それぞれ1つのデータにする。これを原子値って言います。なるほど。では次のステップは？ 次に、第二正規形です。第二。これはですね、部分関数従属をなくすという作業になります。 部分関数、すみません。ちょっと分かりやすく言うと、どういうことでしょう？あ、失礼しました。えーと、注文明細の表をイメージしてください。 主キーが注文番号と商品コードの組み合わせだとして、商品名とか単価って商品コードさえわかれば決まりますよね。 ああ、確かに注文番号は関係ないですね。ですよね。こういう主キーの一部だけで決まっちゃう情報を。 別の商品マスターみたいな表に切り出すんです。なるほど、注文そのものの情報と商品の詳細な情報を分けるということですね。 その通りです。明細からヘッダーの情報を分離するイメージですね。これでかなりスッキリしますね。 ええ。そして最後の仕上げが、第三正規形。第三ですね。これは、主キー以外の列の関係を整理します。 例えば社員の表で、部署コードがあれば部署名が決まるみたいな関係があったとします。はい、ありますね。 これも部署マスターとして独立させるんです。これでさらにデータの重複がなくなって矛盾も防げると。 なるほど。顧客、注文、商品とそれぞれが独立したリストを持つイメージなんですね。あの、これって実はすごく身近な話じゃないですか？ と言いますと。例えばあなたが普段使ってるスプレッドシートの設計でも全く同じことが言えますよね。ああ、おっしゃる通りです。 売上のシートに毎回お客さんの住所を書き込むんじゃなくて、顧客リストっていう別のシートを作っておいてIDで紐付けるみたいな。 まさにそれです。それこそが正規化の考え方そのものなんですよ。ということは、正規化っていうのは。 散らかった大きな表を関連性のある小さな表に分割して、データの重複とか矛盾を防ぐための、いわばデータの断捨離なんですね。 ええ、完璧なまとめです。ただ、この整理整頓にはまあコストがかかるんです。コストですか？ はい。複数の表に分かれているので、何か情報を取り出す時にはそれらを結合、ジョインする必要があります。 これが時々システムのパフォーマンスを低下させる可能性があるんですね。ああ、なるほど。データの正確さを取ると早さが犠牲になることもあると。 そうなんです。だから実務では何を優先するかで、あえて正規化しないという選択肢もあり得ます。面白いですね。 そこで最後にあなたに考えてみてほしいのですが、完璧に整理整頓されたデータベースが必ずしも常に最高とは限らないのはなぜだと思いますか？ データの正確さと速さ、あなたの業務ではそのバランスについて考えてみるのも面白いかもしれません。