読書まとめ『図解まるわかり データベースのしくみ』→型どおりに整然と基礎を学べる本
『図解まるわかり データベースのしくみ』坂上 幸大
一言で言うと
型どおりに整然と基礎を学べる本
概要
データエンジニアとしての知識を学習しておきたいと感じ、読んでみました。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 #命名規則
いいなと思ったら応援しよう！
