DBひでんのしょ
データベース(以下:DB)に関する自分の知見を整理しておきます。
DB秘伝の書という記事タイトルですが、公開した時点でもはや秘伝でもなんでもないですね。
ここにはDB設計に関するごく普通の考え方をまとめて書いています。
前述
なぜDBが必要なのか？
DBを使わないシステムは無い。
データとは、ある形式にそろえられた事実と定義。
企業でのデータは資産である。
種類
1. RDB
2. オブジェクト指向DB
3. XMLDB
4. key-value Store
5. 他
DBを設計することは、システム開発を制する。
「システム開発を制する」というと少し大げさかもしれませんが、あながち間違ってもないかなと思っています。
なぜならDBはアプリケーションの根幹であり、ここが破綻していると全てが破綻していると言っても過言ではないからです。
また、DBのリファクタリングは難しく。一度データが入って本稼働してしまえば変更を加えることは容易ではありません。
システムは、データのフォーマットに合わせられて作られる。
POA(プロセス中心アプローチ)ではなく、DOA(データ中心アプローチ)が基本。
DB破綻を起こすと、プログラムでのリカバリーは、ほぼ絶望的だということを認識しておく。
necojackarcさんのブログでサービス開発を始める上でなぜDB設計が重要かについて、
わかりやすく実際の経験を交えて紹介されています。
こちらの記事を参考にしてみてください。
エンティティとは
組織全体もしくはシステム開発における静的な管理対象(実態という)
6W6Hを定義(表現する)
リソース系
- who 誰が
- whom 誰を
- what 何
- where どこで
- how to 方法
イベント系
- how どのように
- how long 期間
属性候補
- when いつ
- how many どのくらい(定量/たまに定性)
- how much いくら
ビジネス上、正規化対象
- why なぜ (〜のため)
レビュー観点
- how in the future 将来的にどうなるのか
エンティティの種類
独立エンティティ
- 他のエンティティに依存しない(顧客、商品など)
従属エンティティ
- 他のエンティティに依存している(受注、受注明細)
リソース/イベントエンティティ
リソース系エンティティ
- マスタ
簡単にいうと、人、モノ、金、企業組織の活動基盤を表すデータ
イベント系エンティティ
日々の業務など企業組織の活動によって、発生する出来事データ
リレーションシップ
エンティティ同士のつながり
- 依存型
独立エンティティから従属エンティティに向けて引く線
- 非依存型
独立エンティティから他の独立エンティティに向けて引く線
- 凡化型
親子エンティティが凡化関係(あまりおすすめしない)
DBとプログラム(しかも凡化はオブジェクト指向)とは、考え方は別物
DBは集合論
ERDに関しては、こちらの本がおすすめです。2006年に発売されたので10年前になりますが、現在でも十分に使える知識が詰まっています。
上記に記したことはこちらの本を主に参考にしました、
データ・モデル
種類
1. サブジェクトエリアモデル
2. 概念データ・モデル
3. 論理データモデル
4. 物理データモデル
目的
静的なビジネスの全体像を把握すること。
パターンによる抽象化は、ビジネスユーザーによって、わかりにくい。
ビジネスの把握が可能な範囲に適用する。
概念データモデリング
目的
ビジネスの全体像をつかむ(超絶重要！！！)
主な工程
- イベント系エンティティの抽出と定義(必須作業)
- リソース系エンティティの抽出と定義(任意作業・この時点で全くでてこない)
- サブジェクトエリアに分割(仕分けみたいなもの)
- データ・モデル全体を幾つかに区切った場合の各領域(業務、事業単位など)
- 目的
- データ・モデルを見やすくする
- 必要のないのに無理に分割する必要なし(目安は10~30あたり(好みにもよる))
- リレーションシップの線引く
リレーションシップの意味の定義分は '〜する' という動詞句で統一する
矢印の方向に沿って、'親は子を〜する' という書き方(1:Nの関係)
- 必ず定義する！定義しないことは、十中八九破綻する！
- マスタ管理方法を決める！
- ビジネス・ルール整備&定義する！
死守(絶対に守るライン)
概念データ・モデルは余程のことが無い限り作成する。
さもないと、木を見て、森をみないことになり、
後工程で手戻りが生じる恐れあり(見える化できていないため)
結果的に恐ろしいほどの運用コストを跳ね上げることになる。
たとえリリースできたとしても、赤字システム(負の遺産)になるのが関の山
補足
ビジネスの静的側面を管理する指標、設計となるため、
PJ単位ではなく、組織単位で概念データ・モデルを作成したほうがいい。
これを実践している企業は、自社のビジネスモデルを作成維持できている。
業務系とコンシューマ系との垣根がなくなってきており、コンシューマ系でも近年かなり実施されている。
