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

RDB勉強メモ

出典: 


システムとデータベース

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

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

  • すべてのシステムが「データ」を扱っている

    • 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がモデルを十分に表現できていない力不足

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

  • 四つの基本工程(大まか)

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

設計工程とデータベース

  • 本書で取り上げるのは、基本工程の「設計」
  • そのうち「データベース設計」サブ工程
  • 重要

    • システムにおいて大半のデータはDBに永続化される

      • ここにおいてデータ設計とデータベース設計とはほぼ同義
    • データ設計がシステムの品質を大きく左右する

      • ソフトウェアとは「データの流通機構」

DOAとPOA

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

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

  • 昔: POA: Process Oriented Approach
  • 今: DOA: Data Oriented Approach
  • システムは何よりプログラム=処理=processから成るので、POAはある種自然
  • が、うまくいかない

    • データの冗長化などがおこる
  • プロセスと比べてデータはあまり変化しない(永続的)ので、これを先に決める(DOA)

3層スキーマ

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

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

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

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

  • 概念スキーマで上下層の変更を吸収する

    • 論理的データ独立性

      • 外部スキーマが代わっても内部スキーマは影響を受けない
    • 物理的データ独立性

      • 内部スキーマが代わっても外部スキーマは影響を受けない