こんにちは。
システムチーム / プログラマーのNです。
先日、「達人に学ぶDB設計徹底指南書」という、データベースの設計に関する本を読んだので
内容と感じたことについて書こうと思います。
そもそもデータベース設計とは何か
データベース設計とは
システムで必要となる情報を、どのように構造化してデータベースに保存・管理するかを計画する作業
と定義されています。
情報というのは、格納するデータのことなのか？
と疑問に思いました。
会社名や電話番号のことを「情報」という言い方はしないと思ったからです。
読み進めていくとデータと情報の違いが書かれてありました。
データとは
「ある形式（フォーマット）に揃えられた事実のこと」
情報とは
「データと文脈を合成して生まれてくるもののこと」
とあります。
なので、データベース設計というのは、
情報をそのままテーブルに保存するのではなく、情報からデータのみを抜き出して保存する
ということなのだと思います。
データは
ある形式（フォーマット）に揃えられた事実
とあるので、何も考えずに必要なデータをごった煮にして保存するのではなく、
同じ種類のデータかどうか判断することが大切
ということだと思います。
正規化について
正規化もテーブル設計の基本だと書かれています。
第一正規化、第二正規化、第三正規化・・・
と段階があるのですが、
正規化とは
データの冗長性を無くしていく作業
とあります。
どういう状態のことを差しているのだろうと思ったのですが、要は
テーブルの中に、そのテーブルの命名や役割からして必要のないデータが存在する
という状態なのかなと思います。
例えば、
tels（電話番号を保存しているテーブル）に、
会社名が混じっている状態
のこと。
そう考えると、「○○master」というテーブル名はすごく都合がいいよなと思います。
ちゃんと正規化したら、住所や会社名や電話番号を別テーブル化して運用することが理想だろうと。
でも、過度な正規化はしてはいけないとも書かれています。
何故なら、保存しているテーブル同士を最終的には結合しなければいけないからです。
かなりパフォーマンスが劣化することは想像できます。
自分は社内ツールを改修することが多いのですが、過去、何回かパフォーマンスチューニングを実施したときに痛感したからです。
正規化とは逆のテーブル構造にしないと、とてもじゃないけど運用できなかったからです。
まとめ
読み終わって
・データベース設計とは、トレードオフの関係にある整合性と、パフォーマンスの平衡点を見つけ出そうとする努力
・正規化が絶対的な正義ではないが、最初は必ず正規化することを考えること
ということが頭に残りました。
AIがすごい勢いで進化しているけど、どんなに進化してもデータを保存する必要性は変わらないんだなと
その代表がデータベース
データ = 事実
事実を未来に残すために必要なもの。
読み終わってそう感じました。
