真野 正 著
データベースは、システムの中心に位置し、さまざまなデータの保持・更新・整合性の維持を担当する重要なミドルウェアです。本書では、各テーブルに格納するデータの選定やテーブル形式への落とし込み方など、業務を正しく表現するデータベースの設計方法を具体的に即して学ぶことができます。また、できるだけ実務的な内容を盛り込むことに勤め、データのネーミング方針、モデリングツールの活用、データベースの維持管理などについても実践的な解説を行っています。
第1章 なぜデータベースを利用するのか
1.1 データ一元管理の手段として
1.2 データの一貫性維持
1.3 排他制御
1.4 トランザクション管理
1.5 データアクセス言語(SQL)
まとめ
演習
第2章 データ中心の考え方
2.1 DOAの定義
2.2 DOAの特徴
2.3 DOAを実現するための技術
2.4 DOAにおけるデータモデルの役割
2.5 オブジェクト指向との相違
まとめ
演習
第3章 データモデルの表現方法
3.1 3つの要素
3.2 IDEF1X記法のまとめ
3.3 他のモデリング記法
まとめ
演習
第4章 モデリングツール
4.1 ツールの役割・目的 ―ツールは必須か―
4.2 基本機能
4.3 DB以外の設計情報との連携
4.4 代表的なツール
4.5 ツールを効果的に使うために
まとめ
演習
第5章 データベース設計手順
5.1 開発プロセスの中での位置づけ
5.2 概念設計
5.3 論理設計
5.4 物理設計
5.5 DB設計の3つの側面
まとめ
演習
第6章 概念設計:トップダウンモデリング
6.1 事例説明
6.2 エンティティの抽出(把握)
6.3 エンティティの類別
6.4 エンティティの抽出元
6.5 エンティティの抽出と関連付け
まとめ
演習UML
第7章 概念設計:識別キーによる認識
7.1 エンティティモデルへのキー付加
7.2 主キーコード定義
7.3 属性の抽出
7.4 リソース関連の見直し
7.5 イベント関連の見直し
7.6 トップダウンモデリングの進め方(考察)
まとめ
演習
第8章 ネーミング関連
8.1 ネーミングルールの意義
8.2 ネーミングルール・用語集
8.3 ドメイン管理
8.4 ドメイン・ネーミングルール適用例
まとめ
演習
第9章 概念設計:ボトムアップモデリング
9.1 ボトムアップDB設計の進め方
9.2 画面単位の分析
9.3 正規化とモデルの変遷
9.4 リソース管理の徹底
9.5 データ項目命令
まとめ
演習
第10章 概念設計:モデルの洗練
10.1 トップダウンモデルとの対比
10.2 リソースの断面管理
10.3 顧客をイベントからリソースとして管理
10.4 データの移行性検証
まとめ
演習
第11章 データライフサイクル分析
11.1 プロセス分析
11.2 CRUD分析
11.3 エンティティオーナーとサブシステム分割
まとめ
演習
第12章 論理設計
12.1 倫理モデル変換パターン
12.2 アクセスパス分析(トランザクション分析)
12.3 更新系処理の性能向上策
12.4 処理特性分析
12.5 DBの排他制御機能
12.6 データ呼び出しのコンポーネント化
まとめ
演習
第13章 物理設計
13.1 物理構造
13.2 テーブル設計
13.3 ルール定義
13.4 インデックス設計
13.5 ビュー設計
13.6 キャパシティプランニング
13.7 アクセスパス解析
まとめ
演習
第14章 データベースの維持管理
14.1 管理対象
14.2 モデルの変更管理
14.3 物理DB管理
14.4 運用ルールと体制
まとめ
演習
演習問題解答・解説
参考文献・Web
索引
内容についてのお問い合わせは、正誤表、追加情報をご確認後に、お送りいただくようお願いいたします。
正誤表、追加情報に掲載されていない書籍内容へのお問い合わせや
その他書籍に関するお問い合わせは、書籍のお問い合わせフォームからお送りください。
本書の書影(表紙画像)をご利用になりたい場合は書影許諾申請フォームから申請をお願いいたします。
書影(表紙画像)以外のご利用については、こちらからお問い合わせください。
周藝傑 さん
2014-08-31
知識の制限より、全部読んだ後、自分もあまり良くわからない。内容と書き方から見れば、一応良い本だと思う。
Q さん
2021-03-10
リレーショナルデータベースを中心にすえた製品を新規設計する際にモデリングツールを使って考えをまとめながら設計しましょう本。本書が主張するように新規に設計する際なら整った論理構造を作れる可能性はある。しかし現実は時とともに製品に対する要求が変化し、当初の設計を変えなければならなくなる。またこの時の工数は小さく抑える圧力がビジネス上かかることも稀ではない。その結果当初の綺麗な設計はどんどん崩れ、技術負債が溜まっていってしまう。この負債を少しずつ返済する話を読みたいと感じた。