[技術書籍レビュー] 達人に学ぶDB設計徹底指南書

データベースの設計って、開発現場であーだこーだやりながら学んでいくというのが、自分的にはこれまでの学習方法だったのですが、 他の現場での設計は見ることがあっても、設計思想などを聞くことって、あまりありませんでした。 データベースに全く触れたことがない、デザイナーやライター系の開発の人には、あまり読んでも意味がないかもしれませんが、 今時のフロントエンジニア、ガチドストライクのバックエンドエンジニアの人で、仕事でデータベースに少しは触れることがある人は、 この書籍は見ておいた方がいいと思いました。

書籍レビュー

★★★★☆

専門用語のオンパレードですが、少なくてもデータベースを仕事で触る人は、全ての単語を調べてでも読み進めた方がいいです。 最初の方は説明が多く、読みづらい箇所もありますが、そのあとは、著者の方のドキュメントセンスで、まあまあわかりやすい例をあげてくれているので、意味がわかってくると非常に参考になりました。 特に個人的にこれまで、耳にしていたけど、実際に自分でシステム設計（DB設計）をする時には意識してこなかった「正規化」について、徹底的に説明されていたので、これは本当にありがたかったです。 ただ、この本に、「データベースは正規化すべき」ということと「正規化しすぎると破綻する」という矛盾的な書き方が後半に多発していて、 「一体どっちなんだい！！！！」と言いたくkなると思います。 これは、「適正適所」という事で、負荷対応ができて、運用対応に問題がない、トラブルを極力避けられる状態であれば、「現場の判断命」でいいという事ですね。 重要なのは、「正規化の意味を知っている」状態で、こうした設計ができるという点でしょう。

この書籍での学びポイント

今日のシステムでデータベースを持っていないシステムは存在しない

データベースの定義と、今日のシステムの定義にもよりますが、一般的に何かしらのユーザーが使うシステムであれば、確かにデータベースを使ってデータ管理が行われています。 一般的なRDBMSから、少し軽度なSQLite、JSONやCSVなど、ファイルに直接データを保存するのも、データベースと言ってもいいかもしれません。 ここでいうデータは、「ある形式（フォーマット）に揃えられたモノ」で、 エクセルなどの表でお馴染みの二次元表で表すもので考えるとわかりやすいでしょう。

データベースの代表的なモデル

1. リレーショナルデータベース (RDB) 関係データベースとも呼ばれ、一般的に「データベース」と言われると、このRDBのことを指します。 データの取り扱い方が、他のデータベースと比べて、最も直感的でもあります。 2. オブジェクト指向データベース(OODB) プログラミング言語の「オブジェクト指向」をデータベースに保存するために作られたデータベースです。 3. XMLデータベース (XMLDB) 一昔前には、Web上でやり取りするデータ形式に、XMLを利用するという動きがありました。 RDBが苦手とする、階層構造のデータを扱うのを得意としているのが特徴です。 4. キー・バリュー型ストア (KVS) MongoDBに代表される、「ドキュメント型データベース」です。 JSON形式で、データを保存するのが特徴で、NoSQLとも呼ばれています。 5. 階層型データベース データを、木構造で表現するデータベースです。 RDBの1世代前の主流データベースでしたが、最近ではあまり使われなくなっています。

ER図の構築

Entry-Relationalship Diagram の略であるER図は、データベースの視覚的な設計図です。 エンティティ（データベースの値）がどういう組み合わせで構築されているか、 他のテーブルとの関係性などを分かりやすく表すのが特徴です。

物理設計の5つのタスク

1. テーブル定義 ER図では、出来上がったテーブルを参照することが多いですが、設計においては、エンティティの概念をER図にすることを「論理設計」で、 実際にテーブルのスキーマを構築していく作業を「物理設計」と言います。 2. インデックス定義 インデックスは、RDBにおいて、テーブル設計と並んで重要な概念です。 インデックスは、定義しなくても機能的には問題はありませんが、データレコードの釣果により速度向上をする際にインデックスは必要になります。 3. ハードウェアのサイジング サイジングという言葉は、「キャパシティ」と「パフォーマンス」の2つの意味で使われます。 データベースそのものの容量の定義、 速度を速くするためのCPUなどの容量の定義、 要するに、ストレージの定義と処理速度エンジンの定義の両方で行いますが、予算との兼ね合いで、苦労することが多いでしょう。 4. ストレージの冗長構成 物理のデータのRAID構成について設計するフェイズです。 最近のクラウドサーバーやクラウドDBなどにより、あまり意識しなくなっているかもしれませんが、レプリカ構成や、バックアップなどは、仕事で扱うシステムであれば、設計していないととんでもないことになる可能性があるので、必須な思考でもあります。 5. データベースファイルの物理配置 以下のファイルを意識しましょう。

・データファイル ・インデックスファイル ・システムファイル ・一時ファイル ・ログファイル

正規化のレベル

正規化は、第3レベルまで、ちゃんと把握して守れていれば、基本的には問題はないようです。 第1正規形 〜スカラ値の減速 「1つのセル（カラムの中の値）には、1つの値しか含まない」 この値のことを「スカラ値」と言われます。 また、「スカラ値は、Nullを含んではいけない」というルールもあるので合わせて覚えておきましょう。 第2正規形 〜部分関数従属 主キーの一部の列に対して従属する列がある場合、この関係を「部分関数従属」と呼びます。 これに対して、主キーを構成する全ての列に従属性がある場合を「完全関数従属」と呼びます。 第2正規形は、部分関数従属を解消して、完全関数従属のみのテーブルを作ることです。 第3正規形 テーブル内部に存在する段階的な従属関係のことを「推移的関数従属」と呼びます。 第2正規形を拡張させるような形で、マスターテーブルへのリレーションを複数組むことが「第3正規」です 第4正規形 エンティティ（値）同士の関連を表現するエンティティを「関連エンティティ」と呼びます。 このようなテーブルを、以下のように分割するイメージです。 第5正規形 第5正規形は、第4正規形を少し発展させた形です。 関連エンティティもテーブルとしてリレーションさせるという意味になります。

正規形の関連レベル表

あとがき

RDBの種類や、開発における設計工程など、初心者向けの内容もありましたが、読者は中級バックエンドエンジニア（またはデータベースエンジニア）が大半だと思うので、 ターゲット層に合わせた、ポイントの抽出をしてみました。 個人的に、データベースの設計をする作業は比較的楽しく感じる部類なんですよ。 どうやって効率的にするか、API構築などにおいて、

- 分かりやすい - スピードが速い - 想像しやすい

これができたら、いいシステムだと思うので、これを作る面白さを感じているんでしょうね。