はじめに
達人に学ぶDB設計を読んだのでブログで感想等をアウトプットしていきたいと思います。
良かったところ
-
1.DB設計に関しての理解が深まった点
-
2.章の途中に大切なことを要約して書いてある（勘どころ）ので見返すときに大変役立った点
-
3.正規化のやり方について詳しく書いてあったので苦手意識をなくすことができた点
-
4.前回読んだSQLの本のように具体的なコードは少なく、DB設計の考え方について学べたところ
学んだこと
1.論理設計と物理設計
データベース設計は、大きく論理設計（概念スキーマ）と物理設計（内部スキーマ）に分けられます。
論理設計で何を行うこというと、現実世界に存在する数多くのデータから、リレーショナルデータベースにおいて、何を、どのようなフォーマットで保存するかを決めることです。
具体的には4つのタスクに分けられます。
-
1.エンティティの抽出
-
2.エンティティの定義
-
3.正規化
-
4.ER図の作成
物理設計は、論理設計の結果を受けて、データを格納するための物理的な領域や格納方法を決める工程です。
物理設計は5つのタスクに分けられます。
-
1.テーブル定義
-
2.インデックス定義
-
3.ハードウェアのサイジング
-
4.ストレージの冗長構成決定
-
5.ファイルの物理配置決定
論理設計と物理設計の間には強いトレードオフの関係があるが著者曰く基本的に非正規化ではなく正規化を推奨しています。
2.正規化
正規化は論理設計の3番目のタスクに該当します。
正規化は、データの冗長性をなくしていく作業です。その目的は更新時のデータ不整合を防止することにあります。
正規化を理解するためには、関数従属の概念を理解する必要がありますが、これの基礎になっているのが「キー」の概念です。
正規化を進めていくほどデータ整合性は高まりますが、検索性能が劣化します。通常は第3正規形までを考えれば十分です。
下記で第1正規形から第3正規形の詳しい説明をします。
第1正規形
非正規形から、繰り返し部分が取り除かれたものが第1正規形となります。
第1正規化で重要なのは、各繰り返し部分に1つずつ独立したレコードを作ることです。
第2正規形
第1正規形の表から、部分関数従属している列が切り出されたものを第2正規形とされています。
部分関数従属とは、関係データベースにおける属性間の関係性の一種で、ある関係の中で、ある属性群のうち一部の属性が他の属性に関して従属している状態を指します。
第3正規形
第2正規形の表から、主キー以外の列に関数従属している列が切り出されたものを第3正規形とされています。
主キー以外の列に関数従属している列のことを推移的関数従属と呼ばれていたりします。
3.バックアップ
バックアップの方式は三つあり、フルバックアップ、増分バックアップ、差分バックアップに分けられます。
フルバックアップとは全てのデータをバックアップする方式になります。
フルバックアップにはバックアップ時間が長く、ハードウェアリソースへの負荷が高いという欠点があります。
その欠点を補うために「フルバックアップ＋差分バックアップ」または「フルバックアップ＋増分バックアップ」が一般的に使用されています。
差分バックアップと増分バックアップは、ともに変更分のログファイルをバックアップするという方式になります。
違いとしては差分バックアップが前回のバックアップからのデータを累積的に保持するのに対して、
増分バックアップは前回のバックアップからの増分データのみを保持するという点です。
4.統計情報
統計情報はテーブルやインデックスなどデータについてのデータ、すなわち「メタデータ」です。
DBMSはこのメタデータを頼りにSQLのアクセスパスを決定します。
その具体的なプロセスには、ユーザーは基本的に関わらないため、SQLがどのようなアクセスパスで実行されるか、という問題には、ユーザーは統計情報を通してのみ関与することになります。
統計情報を収集すべきタイミングについての基本的指針はデータが大きく更新された後、なるべく早くした方が良いでしょう。
なぜかというとレコード件数が増減するのはもちろんのこと、データの値の分布や偏りが変わることも、アクセスパスの選定に影響するためです。
また、統計情報収集は、ある現象や問題を分析するために利用されるために行われている作業になり、基本的にはシステムの使用者が少ない夜間帯に実施することが原則であります。
5.バッドノウハウ
バッドノウハウとはやってはいけないDB設計のパターンです。
前提としてバッドノウハウは、正規化からは導かれません。
また、非正規化によって生まれるわけでもありません。
なぜなら非正規化はトレードオフを理解している限りバッドノウハウではないからです。
バッドノウハウがダメな理由は２つあります。
１つ目はシステムの品質を左右するうえに、後から変更することが容易でないからです。
いざテーブル構成に後から手を加えようとすると、せっかく作ったアプリケーションにまで修正が及ぶことは必至です。
ある程度アプリケーションの側で柔軟な作りをすることで吸収は可能ですが、原則として「ERモデルの手戻り」はかなり代償が高くつきます
２つ目はバッドノウハウを採用した場合の開発および運用にかかるコストは、そうでない場合に比べて何十倍にも高くなるからです。
その最大の理由は、バッドノウハウが人間の直観に反するものであるため、エンジニアやプログラマの設計に対する理解を妨げるからです。
たとえば、ダブルミーニングや単一参照テーブルは、非常にトリッキーで、最初に設計した人間以外には意図を理解することが困難です。
テーブル分割のように、システムのパフォーマンスを追求するあまり可読性を下げるタイプの設計も同様です。
こうした人間にとって「わかりにくい」システムは、結局のところ開発するエンジニアやプログラマの理解やコミュニケーションを阻害することにつながり、バグを生み出し開発効率を落とす温床になるのです。
論理設計の代表的なバッドノウハウには、非スカラ値、ダブルミーニング、単一参照テーブル、テーブル分割、不適切なキー、ダブルマスタがあります。
難しかったこと
正規化とER図の部分が難しく感じ、どちらも慣れるには実際設計するのが最善だと思いました。
ER図とは「実体（データなど）」と「関係」の組み合わせのことで、システムにおけるデータ間の処理する構造を指します。
ER図を使うメリットは２つあると考えています。
一つ目がER図を設計書の中に記載しておくことで、設計者ではない方でもシステムの設計内容を正確に理解し、システムの仕様の変更などの改修を行う際にスムーズに対応することができます。
二つめが手戻りの必要がないことです。
データベースのテーブル数が多くなると、設計誤りや、プロジェクト関係者がシステムの仕様について理解できないことがあります。
その場合、手戻りが必要なことも多く、余分なコストが発生してしまいます。
特に大規模なシステムの場合は、ER図でデータベース構造などを整理することで、システム全体の構成を俯瞰することができるため、手戻りを起こす可能性を減少させることにつながると思いました。