システムとデータベース
DBをマスターしたい
今回はソフト開発に欠かせないDBについて学習したことをまとめました
内容は以下の書籍を自分なりに噛み砕いて要約したものとなっています
同じ悩みのある方や、自分の振り返り用としても活用できればと思います
参考文献
目次
- データベースの概要
- システム開発の設計工程
- 設計工程とデータベース
- スキーマ
1.データベースの概要
データベースとDBMS
データベースは利用可能な状態にしているデータの集まり
DBMSはデータベースを管理するための言葉
「データベース」と「DBMS」では上記のような違いがある
ちなみにここでいう「データ」とは
ある形式（フォーマット）に揃えられた事実のこと
データベースの種類
- リレーショナルデータベース（RDB)
現在最も広く利用されているデータベース
二次元表の形式で管理
- オブジェクト指向データベース（OODB)
データと操作をまとめて「オブジェクト」という単位で管理
オブジェクトをデータベースに保存するため作られた
- 階層型データベース
データを階層構造で表現するデータベース
2.システム開発の工程と設計
####システム開発の設計
- 要件定義
必要な機能やサービスの水準、すなわち要件を決める工程
外部の顧客や社内で定義する
- 設計
定義された要件を満たすために必要なシステムを作るための設計を行う工程
- 開発
設計書に従ってシステムを実際に作る工程
IT業界では「実装する(implement)」という
コーディングやサーバーの構築なども指す
- テスト
実装したシステムが実用にたえる品質であるか試験する工程
設計工程と開発モデル
- ウォーターフォールモデル
要件定義→設計→実装→テストを1つずつ工程を踏んで段階的にシステムを作る
手戻りが難しく、改修が高コストになりがち
- プロトタイピングモデル
サイクルを繰り返す循環的な開発手段
小さな試作品（Prototype)を作ってフィードバックをもらう
要件定義の取りこぼしや意思疎通の齟齬を防げるのがメリット
変更を繰り返すうちに発散して収拾がつかなくなるリスクあり
3.設計工程とデータベース
データ設計の重要性
データ設計は設計工程の中でも重要である。
理由は以下の2点
- システムにおいて大半のデータはデータベース内に保持されるため。
- システムの品質を最も大きく左右する。ソフトウェアは「データの流通機構」
であって、プログラムはデータをどのように設計するかに左右される
DOAとPOA
-
POA(Process Oriented Approach)
プロセス中心アプローチ
業務処理は短期間で変化することも多いため非効率
複数のプロセスで同じデータを別個に持つという冗長性が生じる -
DOA(Data Oriented Approach)
データ中心アプローチ
データはあまり変化しないことを利用
複数のプログラムで共用することも容易で、業務要件の仕様変更にも柔軟に対応可
4.スキーマ
スキーマとは？
データベースのデータ構造やフォーマットという意味
３層スキーマ
-
外部スキーマ
外部モデル＝ビューの世界
システムの利用者であるユーザーから見て、DBがどのような機能と
インターフェースを持っているか定義するスキーマ
いわゆる、「ユーザーから見たデータベース」の姿 -
概念スキーマ
DBに保持するデータの要素および、データ同士の関係を記述するスキーマ
いわゆる、「開発者から見たデータベース」の姿
この概念スキーマの設計を「論理設計」と呼ぶ -
内部スキーマ
概念スキーマで定義された論理データモデルを、どのようにDBMS内部
に格納するかを定義するスキーマ
テーブルやインデックスの物理的定義を含む
内部スキーマの設計を「物理設計」と呼ぶ
概念スキーマとデータ独立性
-
概念スキーマは何のためにあるのか？
外部スキーマはシステムの機能や使い勝手にダイレクトに関係するので必須
内部スキーマはデータを実際にDBMS内部に格納するための形式なので必須
概念スキーマは、、、？ -
もし、概念スキーマがなかったら？
もし、２層だと変更に対する柔軟性がなくなる
外部スキーマを変更する際に、内部スキーマも変更する必要が出てくる（逆も然り）
＝変更に弱いシステムになってしまう
つまり、概念スキーマは外部スキーマと内部スキーマの間の緩衝材の役割 -
データ独立性
スキーマの独立性のことを、データ独立性と呼ぶ
外部スキーマからの独立性を論理的データ独立性、
内部スキーマからの独立性を物理的データ独立性と呼ぶ