『図解まるわかり データベースのしくみ』坂上 幸大

一言で言うと

型どおりに整然と基礎を学べる本

概要

データエンジニアとしての知識を学習しておきたいと感じ、読んでみました。Power PlatformやExcelでテーブルを作成するときにも、データベースのお作法を理解していた方が安心できると思ったので。

レベル感としては、基本情報技術者試験くらいだと思います。コマンドの細かい説明というよりは、概略を説明してくれる感じです。ダンプやシノニム・ホモニムなど、なんとなくの理解だった箇所が強化できました。ER図の書き方も学びたかったんですが、そこの説明はざっくりだったので別途勉強します。

全てのページで、解説文と図解が見開きで掲載されています。本1冊をテーブル、見開きページで説明されるトピックをレコードと捉えると、解説文と図解がカラムに当たります。1冊通して、左ページには解説文、右ページには図解、という型が徹底して守られています。データベースライクな整然さを感じる一方で、型通りに展開するために入れたような、あまり意義を感じられない図解もありました。型の功罪なのかも。

本稿では、本書からの学びを3点共有します。

① 正規化のデメリットも理解する

データを管理しやすい構造にすることを正規化と言います。基本情報技術者試験で学習した覚えがありましたが、実務でクソみたいな様々なデータを経験してから見返してみると、理解がより深まりました。

• 第1正規形：繰り返し・重複をなくす。Excelで、結合された大項目を各行にバラすイメージ。

• 第2正規形：キー属性→非キー属性の部分関数従属をなくす。従業員ID(キー属性)と従業員名を別のテーブルにするイメージ。

• 第3正規形：非キー属性→非キー属性の推移的関数従属をなくす。従業員テーブルの部署ID(非キー属性)と部署名を別のテーブルにするイメージ。

正規化を進めると、データの整合性を保ちやすくなる一方で、パフォーマンスが落ちる懸念があります。テーブル数が増えると、テーブル結合の頻度も増えるためです。直感的にもわかりにくくなりますね。整合性とパフォーマンスの最適なバランスを取ることが求められます。例えば、書き込みが多いテーブルなら整合性を、読み取りが多いテーブルならパフォーマンスを重視する、といった形になりそうです。

② 図解→リレーション→機械語

データベースを設計する際は、3つのモデルを使って抽象→具体に移行していきます。

• 概念モデル：全体の設計
  部署 → [含む] → 従業員

• 論理モデル：必要なデータを考えて、リレーションを決める
  部署テーブル → [1対多] → 従業員テーブル

• 物理モデル：データベースが管理できる形式にする
  departments[id INT, name VARCHAR]
  → employees[id INT, name VARCHAR, department_id INT]

概念モデルは、図解に近いものがあると感じました。業務プロセスを明確にして、必要なデータを洗い出す作業とも言えそうです。1が起点、多が終点になり、直感と逆になることもあるところは注意が必要です。

③ 命名規則のお作法に従う

テーブル名・カラム名は、半角英数字(小文字)とアンダーバーを使うのがお作法のようです。大文字を使わない、スネークケースと呼ばれる規則ですね。

規則どおりに命名することで、文字列を見るだけで何を表すかが理解できるようになります。データベースに限らず応用が利く知識なので、Power Platformの変数などの命名にも活かそうと思います。

• テーブル名：複数形　ex) departments

• 外部キー：外部テーブル名の単数形_id　ex) department_id

• 日付型：○○_at　ex) created_at

• ブール型：is_○○　ex) is_deleted
  ※delete_flagだと、trueのときにどんな状態かわからない

Amazon.co.jpアソシエイトに参加しています。

#推薦図書 #読書 #書評 #最近の学び #データベース #DB #図解 #図解まるわかり #IT #エンジニア #データマネジメント #データエンジニアリング #SQL #命名規則