システムとデータベース
データ処理としてのシステム
データベースを使わないシステムは、この世に存在しない。
-
すべてのシステムが「データ」を扱っている
- Googleの各サイトのキャッシュ
- FacebookやTwitterの友人間のメッセージ
- Amazonの購入履歴
-
DBMS
- データをいつでも簡単に利用可能な状態にしておくためのシステム
-
データベース
- データの集まり
- システムの部分的なプログラムはデータベースを持っていないこともある
- が、サービス全体として見た場合は必ずデータベースがある
データと情報
情報はデータと文脈を合成して生まれる。
-
データ
-
ある形式(フォーマット)に揃えられた事実
- RDBなら2次元の表
-
-
情報
- ある文脈なり観点なりにしたがってデータを加工したもの
-
データと情報の区別という観点から見たシステム
- ユーザのサービス利用によりシステムにデータが登録される
- それを取り出して情報を引き出す
データベースあれこれ
データベースの代表的なモデル
データベースのモデルが異なれば、データフォーマットも異なる。
モデルが異なれば設計技法も異なる。
代表的なモデル
RDB: Relational Database
- 1969年~
- 特に断りなく「データベース」といえばこれ
- 人間が理解しやすい二次元表
OODB: Object Oriented Database
- OOP言語のオブジェクトを保存するために生まれたやつ
XMLDB: XML Database
- XML形式のデータを扱うことのできるデータベースとして開発
-
階層構造データの扱いを得意とする
- RDBが苦手な部分
KVS: Key-Value Store
- Key - Value の単純な構造
-
単純なデータ問い合わせを高速化することを目的とする
- 大量データを高速に処理する必要のあるWebサービスで多く利用される
- 複雑なデータ操作は不向き
Hierarchical Database
- データを木構造で表現
- RDBより一世代前の主流
- 現在は一般的には利用されない
モデルの違いと設計技法
- モデルが異なればデータフォーマットも異なる
-
設計の方法も異なる
-
例
- RDBの正規化
-
-
が、設計の方法の目的は共通
-
例
- データ整合性の保持
- 冗長性排除
-
DBMSの違いは設計に影響するか?
DBMSが異なっても、(基本的には)設計の方法は影響を受けない。
- 本書では特に断らない限り「DBMS」は「RDBMS」のことを指す
-
DBMSいろいろ
- Oracle
- SQL Server
- DB2
- PostgreSQL
- MySQL
- DBMSはモデルの実装にすぎない
- そのため、DBMSが異なっても、(基本的には)設計の方法は影響を受けない。
-
「基本的には」から外れて設計が影響を受けるケース
- DBMSの独自機能
- DBMSがモデルを十分に表現できていない力不足
システム開発の工程と設計
-
四つの基本工程(大まか)
- 要件定義
- 設計
- 開発(実装)
- テスト
-
ウォーターフォールとかプロトタイピングとかの話
- 略
設計工程とデータベース
- 本書で取り上げるのは、基本工程の「設計」
- そのうち「データベース設計」サブ工程
-
重要
-
システムにおいて大半のデータはDBに永続化される
- ここにおいてデータ設計とデータベース設計とはほぼ同義
-
データ設計がシステムの品質を大きく左右する
- ソフトウェアとは「データの流通機構」
-
DOAとPOA
最初にデータがある。プログラムはその次にできる。
データベースを制する者がシステムを制す。データベースは、システムの中心であると同時に、システム開発の中心でもある。
- 昔: POA: Process Oriented Approach
- 今: DOA: Data Oriented Approach
- システムは何よりプログラム=処理=processから成るので、POAはある種自然
-
が、うまくいかない
- データの冗長化などがおこる
- プロセスと比べてデータはあまり変化しない(永続的)ので、これを先に決める(DOA)
3層スキーマ
- ANSIによる定義
スキーマ | 別名 | DBのオブジェクト | 視点 |
---|---|---|---|
外部スキーマ | 外部モデル | ビュー | ユーザから見えるシステムの姿 |
概念スキーマ | 論理データモデル | テーブル | 開発者から見たDB |
内部スキーマ | 物理データモデル | ファイル | DBMSから見たDB |
概念スキーマとデータ独立性
概念スキーマはデータ独立性を保証するためにある。
概念の有効性がわからなかったら、「それがなかったらどうなるか」を考えてみよう。
-
概念スキーマで上下層の変更を吸収する
-
論理的データ独立性
- 外部スキーマが代わっても内部スキーマは影響を受けない
-
物理的データ独立性
- 内部スキーマが代わっても外部スキーマは影響を受けない
-