【読書メモ】達人に学ぶDB設計徹底指南書-第１章

こんにちは，ふわせぐです．
現職ではフルサイクルエンジニアと言って，要件定義から設計から開発から運用まで，プロダクトのサイクルを一人で回す（もちろんチームで動くので実際に一人だけで回しているわけではないですが）仕事をしています．とは言え，データベースについての知識がほとんど無く（失念），大学で受けた「データベースシステム論」の講義を思い出すことすら難しいので，達人から学んでみました．

達人に学ぶDB設計 徹底指南書

しっかりと内容をまとめるというよりかは，知らなかったことをメモしたり，予備知識を追加したり，所感を書いたり，思考を垂れ流したりと，学校の授業ノートみたいに書いていけたらと思います．用語の意味をしっかり書き留めるようなこともしないと思うので，【読書メモ】がついている記事はインプットには活用できないと思います笑

1-1 システムとデータベース

「データと情報」という小見出しがありました．
この本で，データとは次のように定義されています．

データとはある形式（フォーマット）に揃えられた事実のこと

データベースはこれら”事実”の蓄積ですね．

一方，情報は次のように表現されています．

情報とはデータと文脈を合成して生まれてくるもの

例えばコンビニが蓄積したデータを利用するシステムがあるとします．扱えるデータとして，「若い男性が昨日お酒を買った」「中年の女性が今日弁当を買った」などがあるとします．これらは，単なる”事実”でしかありません．しかし，システムの利用者は「週末には何が売れるか」，「オフィス街の店舗には何を多めに入荷すべきか」などの問いに対する答え（＝”情報”）を要求します．
これらの答えを導くには，「どんな人が買っているか」「どんな日に買っているか」などの”文脈”による分析が必要になるわけですね．

1-2 データベースあれこれ

僕らがイメージするいわゆる「データベースは」Relational Databese(RDB)と呼ばれる，二次元表の形式で管理されるデータベースです，僕はこの名前を知りませんでした．
他にもオブジェクト指向データベースや，XMLデータベース，階層型データベースなどがあるそうですが，しばらく使うことは無いでしょう．

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

システム開発の設計工程は次のように大きく分類できます

1. 要件定義→システムが満たすべき機能やサービスの水準を決定
2. 設計→定義された要件を満足させるシステムを作るための設計
3. 開発（実装）→設計に基づいて実際にシステムを作成
4. テスト→実装されたシステムが要求される品質であるかの試験

まぁこれくらいは知ってましたが，意外と要件定義を疎かにしたり，テストを端折ったりしがちなので戒めの意味も込めて．

システム開発モデルが，大きく分けて２つあって，ウォーターフォールモデルと，プロトタイピングモデルと言います．後者は知らなかった．アジャイルの方が有名な気がします．

ウォーターフォールはその名の通り，滝のように一直線に上記の４肯定を走り抜けるのに対して，プロトタイピングモデルは行ったり来たりして，詰めていくタイプですね．
モダン開発はアジャイルっしょ！ってなんかよく聞く気もしますが，それぞれいいとこ悪いとこあります．
ウォーターフォールモデルはそれぞれの工程をしっかりやれば戻ってやり直すコストが節約できるって感じでしょうか．その分各工程をきっちり精密に行う必要があります．大規模システムにはよく採用されているようで，確かにでっけえシステムを作った後で「やっぱりアレじゃ無くてソレ」ってなるとキツいですね．
プロトタイピングモデルは，スピード感が出るので早い段階からシステムの具体的なイメージが湧くっていう点では良いと思います．要件定義のとりこぼしや意思疎通の齟齬も防げると書いてありました．一方で，要件定義からテスト・フィードバックを何度も繰り返していくうちに訳わからん！ってならないように気をつけてねとも書いてありました．したがって基本的には小規模システムに採用されがちなようです．

1-4 設計工程とデータベース

データベース設計が重要な理由は以下の２つ．

１．システムにおいて大半のデータはDB内に保持される．そのため，データ設計とはデータベース設計とほぼ同義
２．データ設計がシステムの品質を最も大きく左右する．ソフトウェアは「データの流通機構」で，必要なプログラムは設計するデータのフォーマットに左右される．

こういう考え方をデータ中心アプローチ（DPA）と言い，対義語はプロセス中心アプローチ（POA）です．

システムはデータありきなんだからまずはデータ設計をしっかりせよ，と言われると確かに，となりますが，実際はなぜそうした方が良いのでしょうか．システムをとりあえず作ってしまって，それに合わせてDBを作る方が早くて簡単な気もします．
POAの欠点として，意外と非効率な点が挙げられます．プロセスは短期間で大きく変わっていくことが頻繁にあるし，プロセス単位でデータ設計を行うことになるため複数のプロセスで似たようなデータをそれぞれが持ってしまう状態（冗長）が生まれかねないからです．
DOAは，「プロセスとは対照的に，データはあまり変化しない」という点に注目しました．データの意味や形が先に決まっていれば複数のプログラムで供用できるという考え方ですね．プロセスの仕様が変わっても，データ構造は変えなくて済むかもしれません．

さて，ここからは３層スキーマという考え方が出てきます．
スキーマは，データベースの設計をしていく上で大切な概念で，データの構造やフォーマットという意味で使われます．スキーマは一般的に以下に示す３つのレベルに分けられます．

1. 外部スキーマ＝ビューの世界
2. 概念スキーマ＝テーブルの世界
3. 内部スキーマ＝ファイルの世界

この３つのスキーマに基づいてシステムを記述したモデルを「３層スキーマモデル」と呼びます．

外部スキーマは，ユーザーから見たデータベースの姿です．データベースと言われて一般的に思い浮かべるのは二次元表のような物でしょうか．このスキーマは，データベースそのものだけでは無くユーザーインターフェースを含んだシステムの見た目に相当するものや，その機能を定義するスキーマです．

概念スキーマは，開発者から見たデータベースの姿です．開発者はシステムで用いられるデータベースのテーブル定義を知っていますし，データの依存関係なども知っています．概念スキーマでは，データベースが保持するデータの要素やデータ同士の関係を定義するスキーマです．概念スキーマの設計を「論理設計」と呼ぶこともあります．

内部スキーマは，DBMS（データベースを管理するシステム）から見たデータベースの姿です．概念スキーマで定義されたデータモデルを実際どのようにファイルとして保存するかを定義するスキーマで，概念スキーマでの論理的な定義に対して，内部スキーマは物理的な定義を行います．したがって内部スキーマの設計は「物理設計」と呼ぶこともあります．

さて，このようにデータベースの設計を３つの層に分けたわけですが，どうしてこのように分ける必要があるのでしょうか．
これは，システムの規模が大きくなると顕著になりますが，変更に対する柔軟性を持たせるため，というのが大きな理由です．特に，これは概念スキーマを定義する理由に相当します．
内部スキーマと外部スキーマのみのモデルでデータベースを設計した場合，どちらか一方を変更したい場合，例えばデータの見え方（外部スキーマ）を変えたいとなったとき，もう片方のスキーマにも影響を及ぼします．内部スキーマと外部スキーマが直接つながっているからです．これを防ぐためのインターフェースとして概念スキーマを定義します．
このように，概念スキーマを緩衝材にして内部スキーマと外部スキーマの依存性が低くなった状態，その独立性をデータ独立性と呼びます．

あとがき

しっかりまとめないとか言いながら，結局結構しっかり読みながらまとめてしまったので反省（毎回してたら時間がかかりすぎる）です．
しっかりまとめるのも大事ですが，まとめることが目的になってはいけないので，程よいアウトプットの粒度を模索しながら，読み進めたいと思います．
三日坊主にならないように，投稿頻度は低めですが継続して頑張ります．