勉強日記

チラ裏

達人に学ぶDB設計 徹底指南書 ch1 データベースを制する者はシステムを制す

RDB 勉強メモ

www.shoeisha.co.jp

システムとデータベース

データ処理としてのシステム

データベースを使わないシステムは、この世に存在しない。

  • すべてのシステムが「データ」を扱っている
  • 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いろいろ
  • DBMSはモデルの実装にすぎない
  • そのため、DBMSが異なっても、(基本的には)設計の方法は影響を受けない。
  • 「基本的には」から外れて設計が影響を受けるケース
    • DBMSの独自機能
    • DBMSがモデルを十分に表現できていない力不足

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

  • 四つの基本工程(大まか)
    1. 要件定義
    2. 設計
    3. 開発(実装)
    4. テスト
  • ウォーターフォールとかプロトタイピングとかの話
    • 略

設計工程とデータベース

  • 本書で取り上げるのは、基本工程の「設計」
  • そのうち「データベース設計」サブ工程
  • 重要
    • システムにおいて大半のデータはDBに永続化される
      • ここにおいてデータ設計とデータベース設計とはほぼ同義
    • データ設計がシステムの品質を大きく左右する
      • ソフトウェアとは「データの流通機構」

DOAとPOA

最初にデータがある。プログラムはその次にできる。

データベースを制する者がシステムを制す。データベースは、システムの中心であると同時に、システム開発の中心でもある。

  • 昔: POA: Process Oriented Approach
  • 今: DOA: Data Oriented Approach
  • システムは何よりプログラム=処理=processから成るので、POAはある種自然
  • が、うまくいかない
  • プロセスと比べてデータはあまり変化しない(永続的)ので、これを先に決める(DOA)

3層スキーマ

  • ANSIによる定義
スキーマ 別名 DBのオブジェクト 視点
外部スキーマ 外部モデル ビュー ユーザから見えるシステムの姿
概念スキーマ 論理データモデル テーブル 開発者から見たDB
内部スキーマ 物理データモデル ファイル DBMSから見たDB

概念スキーマとデータ独立性

概念スキーマはデータ独立性を保証するためにある。

概念の有効性がわからなかったら、「それがなかったらどうなるか」を考えてみよう。