達人に学ぶDB設計徹底指南書の要約 その1

はじめに

このページは達人に学ぶDB設計徹底指南書を読んだ上でアウトプットするために作成した記事です。
当たり前ですが、達人に学ぶDB設計徹底指南書の引用をします。
以下に商品リンクを記載します。
達人に学ぶDB設計徹底指南書

論理設計と物理設計

この本は次の2つのDB設計にフォーカスを当てて説明している。

1. 論理設計
2. 物理設計

論理設計とは、いわゆる正規化やER図といった道具を使ったデータのモデル設計のことである。
一般的に「データベース設計」と聞いて、多くの人が思い浮かぶもの。

物理設計とは、サーバーやストレージといった物理的なハードウェアレベルの設計のことである。データベースもこうしたハードウェアの上で動作するため、物理設計のことも考えなければならない。
特にデータベースはデータの永続化と整合性の担保という使命を課されているミドルウェアであり、ストレージとの結びつきが強固である。

この本では、特に論理設計と物理設計のトレードオフの関係に着目しながらそれぞれの設計手法について説明している。
論理設計を綺麗に行おうとすると、物理設計が犠牲になり、物理設計を優先しようとすると論理設計が犠牲になるのである。

データベースを制するものはシステムを制す

システムとデータベース

今日、私たちの生活にシステムは必須のものとなっている。実際に、これまで数えきれないほどのシステムが世に出てきた。その全てのシステムに共通しているのがデータを取り扱っていることである。
こうしたデータを整合的に保持して、いつでも簡単に利用可能な状態にしておくためのシステムがデータベースである。データベースは、厳密には「データの集まり」を指すために使われる言葉で、そのデータベースを管理するためのシステムをDBMS という。

システム開発の工程と設計

この本ではシステム開発の設計工程についても説明がされている。
DB設計と関わることなので、軽くまとめる。

要件定義

システムが満たすべき機能やサービスの水準、すなわち要件を決める工程である。通常は何らかの形で外部の顧客と要件を合意するが、パッケージソフトやWebサービスの場合は、自社内のみで要件を定義する場合もある。

設計

定義された要件を満たすために必要なシステムを作るための設計(デザイン)を行う工程。

開発

設計書に従ってシステムを実際に作る工程。この工程は、一般的にはプログラマによるコーディングを指すことが多いが、サーバーやネットワーク機器、ストレージといったハードウェアの調達や環境の物理構築といった作業も含まれる。近年ではこうした物理層のタスクの多くがクラウド化によって簡略化することも可能になった。

テスト

実装によって組み上がったシステムが、本当に実用に耐える品質であるかを試験する工程。目的に応じてテストの種類とレベルにも何種類かあるが、大きくは機能的な品質に対するテストと、性能や信頼性といった非機能品質に対するテストの2種類に大別できる。

設計工程とデータベース

この本では設計工程にフォーカスを当てている。この設計にはさらに多くのサブ工程があり、ソフトウェアの提供する機能を決めるアプリケーション設計、ユーザーが使用する画面などのユーザーインターフェース設計が該当する。そして、この本で取り上げるのはこうしたサブ工程の1つである、データベース設計、特にデータベースに保持するデータの設計である。データベース設計が重要な理由は以下の2つである。

1. システムにおいて大半のデータはデータベース内に保持される。そのため、普通、データ設計とはデータベース設計とほぼ同義である。
2. データ設計がシステムの品質を最も大きく左右する。ソフトウェアというのは、「データの流通機構」であって、どのようなプログラムが必要になるかは、どのようなデータをどういうフォーマットで設計するかに左右される。

この2つの理由は近年のソフトウェアでは主流なデータ中心的アプローチという開発手法で重要になってくる。スローガンで言うと、「最初にデータありき」である。

従って、データ設計(データベース設計)はシステムの品質を決める最も重要な要因と言っても過言ではない。このデータ設計においてセオリーを踏み外した設計(アンチパターン)を行ってしまうと、システムの機能／非機能の品質を致命的に損なうことになる。

3層スキーマ

データベース設計を段階に分けて説明する上で大事な概念として「スキーマ」と言うものがある。
データベース設計においては、データベースのデータ構造やフォーマットという意味で使用される。データベース設計のステップは、このスキーマのレベルと密接に結びついている。スキーマは、一般的に以下の3つのレベルに分けられる。

1. 外部スキーマ (外部モデル) = ビューの世界
2. 概念スキーマ (論理データモデル) = テーブルの世界
3. 内部スキーマ (内部モデル) = ファイルの世界

外部スキーマ

外部スキーマとは、システムの利用者であるユーザーから見て、データベースがどのような機能とインターフェースを持っているかを定義するスキーマである。
いわば「ユーザーから見たデータベース」の姿である。

概念スキーマ

データベースに保持するデータの要素及び、データ同士の関係を記述するスキーマ。概念スキーマは「開発者から見たデータベース」。データベース設計において重要な位置を占めることになる。
概念スキーマの設計のことを論理設計とよぶ。データベース設計で中心となるスキーマである。

内部スキーマ

概念スキーマで定義された論理データモデルをどのようにDBMS内部に格納するかを定義するスキーマ。いわば「DBMSから見たデータベース」。テーブルやインデックスの物理的定義を含む。リレーショナルデータベースもコンピュータ上で動く以上は必ず「ファイル」の形で管理されるわけで、その「ファイル」で表現される世界だと考えるとわかりやすい。

論理設計と物理設計

概念スキーマと論理設計

先述の通り、概念スキーマを定義する設計を論理設計という。システムの世界では論理という言葉がよく登場するが、それは「物理層の制約にとらわれない」という意味で使う。つまり論理設計とは、物理的制約にとらわれない設計ということである。

論理設計には以下のステップがある。

1. エンティティの抽出
2. エンティティの定義
3. 正規化
4. ER図の作成

エンティティの抽出

エンティティとは日本語で「実体」という意味である。現実世界に存在するデータの集合体を指す言葉で、「顧客」や「社員」といった物理的実体を伴ったものもあれば、「税」や「会社」といった単なる概念としてしか存在しないものも含まれる。
リレーショナルデータベースではこうした現実世界のエンティティを、最終的に「テーブル」という物理的単位で格納していくことになる。そのため、まずはシステムのためにどのようなエンティティ(=データ)が必要になるかを抽出することが論理設計の第1ステップである。この工程は要件定義とかぶっている。そのためこの工程は、ある程度、顧客やシステム利用者と要件を詰めていく中で実施していくことになる。

エンティティの定義

エンティティを抽出したあとは、各エンティティがどのようなデータを保持するかを決める必要がある。エンティティはデータを「属性」という形で保持する。これは二次元表でいう「列」と同義だと考えてほしい。リレーショナルデータベースでは二次元表に近い「テーブル」という形でエンティティを保持するが、各表がどのような「列」を持つかということを定義するのがこの作業である。
ここで特に重要なのは「キー」という列を定義することである。キーとは、ある特定の列の値を決定するための列(複数列でも可)のことである。

正規化

正規化はエンティティ(テーブル)について、システムでの利用がスムーズに行えるように整理する作業のことである。特に、正規化は更新(データの登録、変更、削除)が整合的に行えるように、エンティティのフォーマットを整理することが重要な目的である。
裏を返すと、単にエンティティを抽出し、属性を定義しただけの状態では、まだそのエンティティはシステムでの利用に耐える状態ではないということである。
リレーショナルデータベースの論理設計では、この正規化が最も重要な土台をなす。

ER図の作成

正規化を行うと、エンティティの数が増える。正規化とはエンティティを細かく分割する作業だからである。それらを把握しやすくするためにER図を作成する。
ER図がなければ、テーブル同士の関係が複雑になり、理解が困難になるだろう。

内部スキーマと物理設計

物理設計は、論理設計の結果を受けて、データを格納するための物理的な領域や格納方法を決める工程。最近ではクラウドで置き換わることが多いが、オンプレミスでの考え方を学んでおくとクラウドの仕様に関する理解も深まるため、オンプレミスでの考え方を中心に記載する。

物理設計のステップ

物理設計には以下のステップがある。

1. テーブル定義
2. インデックス定義
3. ハードウェアのサイジング
4. ストレージの冗長構成決定
5. ファイルの物理配置決定

テーブル定義

論理設計で定義された概念スキーマをもとに、それをDBMS内部に格納するための「テーブル」の単位に変換していく作業。

インデックス定義

インデックス(索引)は、なくても機能的には何の問題もないが、データベースのパフォーマンスにおいて大事な要素である。インデックスは本の索引のようなものである。本では、特定の単語を探す際に、その単語が何ページに書かれているかを索引で調べ、直接該当ページに移動すると思うが、インデックスもキー(単語)をもとにデータ(該当ページ)を探すものである。
そのため、インデックスがあった方がデータ探索が効率的になり、データベースのパフォーマンスが上がる。

ハードウェアのサイジング

サイジングとは「大きさを決める」という意味だが、システム開発では2種類の意味で使用する。
1つ目は、データの規模を問題にする場合で、「システムで利用するデータサイズを見積り、それに十分な容量のストレージを選定する」という意味。
2つ目はパフォーマンスに関わる使い方。この場合、サイズを測る対象はCPUやメモリのことである。
実際のところ性能問題のほとんどは、ストレージのI/Oネックによって引き起こされる。

ストレージの冗長構成

次に行う物理ステップはストレージの冗長構成の決定である。データベースのデータを保持する媒体(HDDやSSD)やデータの保存技術を決める工程である。
ここでまず登場する技術が「RAID」である。複数のディスクを束ねて仮想的に1つのストレージとする技術で、この単位でまとめられたディスクをRAIDグループという。以下に本書で紹介されているRAIDのレベルを記載する。各レベルについては自分で調べること推奨。

1. RAID0 (=ストライピング) 複数のディスクにバラバラになるようにデータを保存
2. RAID1 (=ミラーリング) 複数のディスクに同じデータを複数保存
3. RAID5 (=パリティ分散) パリティ(データ復元用データ)を使用した保存方法
4. RAID10 RAID1とRAID0を組み合わせた保存方法

基本的に上記の保存方法を使用することが多い。この中でどれを採用するべきかというと、基本的にはRAID10を採用するべきである。しかし、構成に必要なコストが高いというデメリットがあり、予算に余裕がないと採用できない。
逆に最も採用するべきでないのはRAID0である。
RAID0はパフォーマンスは上がるが、バックアップは取らないので、データの復元ができない。ディスクの1本が壊れたら障害発生である。多くの人に影響を与えるシステム開発において、間違ってもこのようなセーフティネットがない方式を使用してはならない。
RAID1は信頼性は強固だが、パフォーマンス向上はできない。一方、RAID5は信頼性と性能をある程度向上させられる(RAID1とRAID0の中間択)。従って、データベースサーバーのストレージにおけるRAIDの推奨構成は「データベースのRAIDは少なくともRAID5で構成する。お金に余裕があればRAID10かRAID6。RAID0は論外」となる。

データベースファイルの物理配置

データベースのストレージの冗長構成を決めたら、物理設計の最終ステップは、データベースのファイルをどのディスク(またはRAIDグループ)に配置するかを考える。実は、このファイルの配置については、最近のDBMSが自動的に配置してくれることもある。
データベースに格納されるファイルは、用途別に以下の5種類に大別できる。

1. データファイル
2. インデックスファイル
3. システムファイル
4. 一時ファイル
5. ログファイル

このうち、開発者がその存在を意識するのは、データファイルとインデックスファイルだけである。

レプリケーション

レプリケーションとは、現用系と待機系からなる複数のデータベースを用意し、現用系から待機系へ更新データの情報を送信してデータベースのレベルでデータが同じになるようにする技術である。これにより、現用系のデータベースに障害があった場合も待機系で処理を継続できるようにしたり(可用性向上)、リードレプリカを増やすことで読み込みスループットを向上させたりできる(性能向上)。

レプリケーションとバックアップとの違い

レプリケーションは、データを複数の箇所に分散して持つ冗長構成による可溶性向上を目的としている。その利点は、現用系のデータセンターが被災するような大規模災害に襲われたとしても、遠隔地の待機系を使って素早くサービス復旧ができるという機動性の高さが向上することがある。一方、待機系のデータが常に最新に上書きされていくという特性上、データを任意のある時点に戻すということはできない。これはバックアップの仕事である。

###クラウドにおける推奨RAIDレベルの謎
はじめに言っておくと、クラウドのRAIDレベルとして、RAID5やRAID6は推奨されない。また、推奨レベルはRAID0やRAID1である。
これはオンプレミス(先ほどまでの記述)とは逆である。これは、クラウドでは自動的に同じAZ(アベイラビリティーゾーン:データセンターの集合)内部にレプリケートされてデータが分散配置されるため、わざわざRAIDでデータ冗長性を担保する必要はないという考え方である。クラウドはデフォルトでレプリケート機能がある便利なものなのである。詳しい話は本を買ってみてください。
他にもバックアップ構成についても完全、差分、増分について詳しく書いてありますが、ここでは記載しません。

おわりに

結構省略しましたが、2章までの内容を自分なりにまとめました。次は3章からです。