目的
「達人に学ぶDB設計 徹底指南書」を読んで学んだことをアウトプットするために記事を投稿する。
今回は第1章についての内容をまとめる。
システムとデータベース
- データ
- ある形式（フォーマット）に揃えられた事実
- データベース（Database）
- 身近にあふれる「データ」を整合的に保持して、いつでも簡単に利用可能な状態にしておくためのシステム
- DBMS（Database Management System）
- データベースを管理するためのシステム
- 情報
- データと文脈を合成して生まれてくるもの
| 名前 | 年齢 | 年齢 |
|---|---|---|
| 山田 | 22 | 男 |
| 鈴木 | 40 | 女 |
データベースについて
データベースの代表的なモデル
- リレーショナルデータベース（RDB）
- 別名、関係データベースと呼ばれる
- 現在最も広く利用されているデータベース
- データを人間が理解しやすい二次元表の形式で管理
- オブジェクト指向データベース（OODB）
- データと操作をまとめて「オブジェクト」という単位で管理し、それをデータベースに保存するために作られたもの
- XMLデータベース（XMLDB）
- XML形式（HTMLのようにタグで管理されたもの）のデータを扱うことのできるデータベース
- キー・バリュー型ストア（KVS）
- データをKey（識別キー）とValue（値）の組み合わせだけのデータ型で表現するデータベース
- 単純なデータ問い合わせを高速化することが目的で、Webサービスで多用される
- 複雑なデータ操作は苦手
- 階層型データベース
- データを階層構造（木構造）で表現するデータベース
モデルが異なれば設計技法も異なる。
主なDBMS
- Oracle Database
- SQL Server
- DB2
- PostgreSQL
- MySQL
DBMSが異なっても、（基本的には）設計の方法は影響を受けない。
システム開発の設計工程
1. 要件定義
2. 設計
3. 開発（実装）
4. テスト
要件定義
システムが満たすべき機能やサービスの水準＝要件を決める工程
設計
定義された要件を満たすために必要なシステムを作るための設計（デザイン）を行う工程
開発（実装）
設計書に従ってシステムを実際に作る工程
テスト
組み上がったシステムが本当に実用にたえる品質であるかを試験（テスト）する工程
設計工程と開発モデル
- ウォータフォールモデル
- 要件定義→設計→開発→テスト、というように一つずつ工程を踏んで、段階的にシステムを作るモデル
- 基本的に工程が逆戻りすることはない
- 手戻りが難しく、改修が高コストになりがち
- プロトタイピングモデル
- 最初に小さな試作品を作ってフィードバックをもらい、それを取り入れた形で改良版を作って再度フィードバックをもらい、...を繰り返すモデル
- 早い段階からシステムの具体的なイメージを開発者や顧客と共有できる→認識齟齬を防ぐ
- 変更を繰り返すうちに発散して収拾がつかなくなるリスクもある
設計工程とデータベース
データベース設計が重要な理由
1. システムにおいて大半のデータはデータベース内に保持される→データ設計とはデータベース設計とほぼ同義
2. データ設計がシステムの品質を最も大きく左右する
上記のことを踏まえ、近年のソフトウェア開発では データ中心アプローチ（Data Oriented Approach：DOA） という考え方が主流。プログラムよりも前にデータの設計から始める方法論。
※かつてのシステム開発の主流の考え方は正反対＝プロセス中心アプローチ（Process Oriented Approach）
- DOA：データ→プログラム
- POA：プログラム→データ
POAが主流ではなくなった理由
自分たちが想定しているより非効率で、不都合な点も多い。
1. プロセス（業務処理）は短期間で大きく変わることは頻繁にある
2. プロセス単位で同じデータを別個に持つという冗長性が生じる
DOAが主流となった理由
データはあまり変化しない（永続的である）ため、データの意味や形式があらかじめ決まっていれば複数のプログラムで共用することも容易。また、業務要件の仕様変更にも柔軟に対応できる。
３層スキーマ
- スキーマ
- 「枠組み」や「構図」という意味の単語
- データベース設計においては、データベースのデータ構造やフォーマットという意味で使う
- 一般的に、外部スキーマ、概念スキーマ、内部スキーマの三つのレベルに分けられる
- 外部スキーマ
- システムの利用者であるユーザーから見て、データベースがどのような機能とインタフェースを持っているかを定義するスキーマ
- ユーザーから見たデータベース
- 概念スキーマ
- データ同士の関係を記述するスキーマ
- 開発者から見たデータベース
- 内部スキーマ
- 概念スキーマで定義された論理データモデルを、具体的にどのようにDBMS内部に格納するかを定義するスキーマ
- DBMSから見たデータベース
概念スキーマの必要性
もし概念スキーマがなかった場合（２層スキーマの場合）、変更に対する柔軟性を失う。
外部スキーマや内部スキーマに変更が加わる場合、両者に大きな影響を与えてしまう。
→概念スキーマは、外部スキーマと内部スキーマの間に立って、両者の変更が影響し合わないようにするための緩衝材のような役割を果たす。
感想
- システム設計の際にデータ中心で考えるのは意外だった
- 概念の有用性を考える際に、「もしそれがなかったらどうなるのか」を想定するとイメージしやすい