1章 RDBMS総論
Webシステムの構築に必要不可欠なRDBSがどういうものなのかを追求していく。
🚩RDBMSの必要性とは
RDBSのシステム開発のメリットで一般的に言われるのは次のようなものを示す。
- 標準化されたSQLの存在
- 物理情報と論理情報の分離
- データ整合性保持の容易性確保
- 複数ユーザーによる同時利用の実現
☑︎標準化されたSQLの存在
データと各プログラムのインターフェイスを取り持つ役割を担うのがSQLです。このSQLによって、どんなプログラムからでも同一のRDBSにアクセス可能にするという利点があります。SQLは需要が大きいため、有益な情報が入手しやすく勉強しやすい。
☑︎物理情報と論理情報の分離
RDBSの特徴として「論理情報と物理情報の分離」という、非常に大きな項目がある。プログラム内のデータの物理的な配置を気にしなくても論理的データとしての名称を設定するだけで項目名でアクセス可能になります。仮にRDBMS側で定義されていない項目であればメッセージが通知されるだけなのでデータ破壊などの心配はないらしい。(C言語やJavaを扱ったことがないので少しイメージしにくいがこれらの言語でデータを扱う際はかなり神経を使うらしい)
☑︎データ整合性保持の容易性確保
データを管理するシステムとしてとても優秀で、RDBMSに接続や切断を行う際にデータが破壊されるということはありません。また文字列型や数値型というデータ型の論理情報を管理できるためにチェックも自前で実装しなくて良いので実現したい機能そのものに集中できるので生産性や品質の向上につながる。
☑︎複数ユーザーによる同時利用の実現
RDBMSを使う最大の目的は、複数ユーザーからの同時アクセスを実現することです。これによりプログラミングで考慮すべき課題のいくつかを解決することを可能にしました。一言で言うならデータの交通整理のような仕組みをRDBMSが補っています。
🚩構造化技法に対するアンチテーゼとしてのRDBMS
RDBMSは「リレーショナルモデル」という理論専攻で生まれたものです。なぜRDBMSが生まれたのかを背景に遡ります。RDBMSが生まれる前の情報システムの時代では、構造化技法というものが発展していました。構造化技法とは、ざっくり言えば連接・分岐・繰り返しなどの処理をサブルーチン化しそれを呼び出す構造にすることでプログラムを理解しやすい構造にすることを指します。下記のリンクにより詳細に書かれています。しかし、構造化技法の発展によってより効率的にプログラムが大量に作られシステムは複雑化の一途を辿りはじめました。構造化技法は「入出力データの構造」から機能分割を行う方法が主力で、入力データに対してのデータ構造変換プログラムを多く必要にしていました。ある調査結果では、当時のシステム稼働の7割が変換抽出処理のためでアウトプットの出力は3割未満に過ぎないと言われていました。このような問題を解決するためにRDBMSが生まれました。構造化技法は「いかに効率よくプログラムを作るか」に対して、RDBMSは「いかに効果的なプログラムを作るか」ということに着目しています。なので、プログラミングツールのためではなくビジネスにおける情報という価値を、簡単により効果的に作り出していくための仕組みとして生まれたわけです。
🚩業務プロセス再編と情報ロジスティクス
データベース設計において「業務プロセスをいかに最短に終わらせることが出来るか」が重要になってくる。つまり、「ビジネスプロセスの最短化を実現できるような」データの提供ができなければならない。この考え方は情報ロジスティクスという考え方に到達する。この考え方を実際に適応させるには、統合データベースを用いることです。統合データベースとは、企業の全員が統合されたデータを共有することで、ビジネスプロセスの再編、最適化を一番短くします。統合データベースの重要性を理解している企業はビジネス・業務プロセスの再編に成功しています。
2章 経営資産に基づくDB設計
この章では、データ中心アプローチというものを確認し、実務上のRDBMS設計をどのように行っていけば良いかということに触れていく。
🏴データ中心アプローチの本質
データ中心アプローチの本質は、「データという客観的なものを通じて、企業のあり方を見直そう」というもの。一般的な正規化理論からデータ中心アプローチの本質と言うのは、木を見て森を見ずの典型でありもっとマクロ的な視点からくる概念として捉える。
☑︎データライフサイクルと正規化
データは、プロセスの中で活用され流れていく中でどんどん移り変わっていく。これをDLC(データライフサイクル)と呼び、要はデータの寿命を指す。DLCという観点で見ると大きく分けて4つの状態が存在する。
| C | Create(生成)。データが誕生するということ。 |
| R | Refarence(参照)で、見られるということ。データベースの最も重要な役割であるアウトプットを出す時にフルに活用される時点。 |
| U | Updateでは、変化を加えられる。 |
| D | 寿命を尽きて、ほいする必要がないという状態になればDropされる。 |
このCRUDを行っていく処理との関係をマトリックスとして表現することが出来る。処理とデータ構造の関係を二次元に表にしたCRUDマトリックスを下記に示す。
| テーブル\トランザクション | 処理1 | 処理2 | 処理3 | 処理4 | … |
|---|---|---|---|---|---|
| テーブル1 | C | R | D | … | |
| テーブル2 | C | R | U | … | |
| テーブル3 | C | R | … | ||
| テーブル4 | C | U | … |
☑︎データだけを考えるのではない
上のマトリックスからあちこちのトランザクションで同じデータ構造に対して同じ操作していることが見出しやすくなると思います。そこで、無駄なトランザクションを排除していくトランザクションの正規化を図ることで無駄なプログラムをより作らずに済みます。そして、トランザクションが実行されるきっかけはユーザーが処理を行うUIがほとんどです。さらに、UIとトランザクションの正規化を図ることもできます。ここから、UIの無駄が省かれていけばUIとそれを利用するユーザー、ユーザーと組織の正規化と全体的な戦略的正規化として多くの無駄が省かれていきます。こうして流れを推進していくのがデータ中心アプローチの本質です。
🏴数学的正規化と業務的正規化
売上伝票テーブルから、様々なビジネスのあり方によって単純な正規化だけではテーブル設計はできない。あくまでビジネスのバリューを生み出すためのものであるから。「ERDをかく」というのは、「ビジネスの写像を行う」ということ。テーブル設計のパターンは、本読んだほうが早いので項目別に超簡潔に要約。
- 実際の販売時に単価が値下げするような場合は、新たに売上明細テーブルに販売価格というカラムを置く
- 一回の販売でまとまった時に端数を値引きするという場合は、新たに売上テーブルに合計テーブルを置く
- 顧客によっては値引きするようなことがある場合、新たに顧客別契約単価エンティティを置く
- 期間限定で単価が変更する場合は、新たに期間別商品単価テーブルを置く
🏴論理設計と物理設計
ここまでは論理設計というものを行ってきましたが、実際にDBを実装していく場合は「物理設計」というものを行なってきます。昔まではコンピュータの都合に合わせてあえて非正規形を行わなければならない時代でしたが、現在はハードウェアの高性能化によりその心配はなくなりました。しかし、物理設計は非正規形にすることだけでなく、スペックをより有効に引き出せるような配置にすることも含まれます。その際に重要なのは、インデックス設計です。
