第1章　いいデータモデルの条件
はじめに
本シリーズでは永続化するデータモデルについてまとめいていく
データモデリングはどのモデリングに過程でより深く業務要求を分析し、顧客やチームとの対話で本質的価値を産む
モデリングを通じた対話
システム開発に関わる人たちは共通認識を持つ必要がある。この時、業務内容をコンセプトを抽象化しみえるもに落とし込んだことがモデルという
何を同じとみなし、何を違うと判断するかが議論の核
データモデルとは関係者の頭にある概念をテキストや図で表したもの
適切な抽象化をするためには関係のない具体的なことをそぎ落とす必要がある
本章ではテーブルやクラスにかかわらず、関係者全員がみてわかるデータモデルを書くことを目標とする
エンティティ-一つのもの
データモデルの世界では以下のようにエンティティを定義している
１つのものである（識別子がある）
ほかのものとは区別され独立している
エンティティの設計は単純な概念に属性を付与するのではなくて、複数の利用シーンを考慮して、新たな概念を出すようにする
一冊の本をエンティティすると利用シーンによって、意味合いが変わってくる
code:mermaid
erDiagram
"予約" ||--o{ "図書" : ""
"手配" ||--o{ "図書" : ""
"貸出" ||--o{ "図書" : ""
"返却" ||--o{ "図書" : ""
"予約" o|--o| "手配" : ""
"手配" o|--o| "貸出" : ""
"貸出" o|--o| "返却" : ""
蔵書というエンティティを見出せば、予約時の図書と返却時の図書を同じ概念でみることができずに設計できる
code:mermaid
erDiagram
"予約" }o--|{ "図書" : ""
"手配" ||--o{ "蔵書" : ""
"貸出" ||--o{ "蔵書" : ""
"返却" ||--o{ "蔵書" : ""
"図書" ||--o{ "蔵書" : ""
"予約" o|--o| "手配" : ""
"手配" o|--o| "貸出" : ""
"貸出" o|--o| "返却" : ""
あいまいなエンティティの境界
エンティティを設計するには以下の性質を考慮する必要がある
単一性
何をさしていているのか明確かつ安全に説明すること
記事一覧の一つの記事とみなすか、記事詳細の記事をみなすかはここに認識がずれてくる
どの記事の種類をさして「一つの記事」と定義するのか決断しないといけない
同一性
同じ用語に対する相反する見解を調整すること
すでに公開している記事と編集した記事を同じものとみなすかどうかは、立場によって変わってくる。別ものとみなす場合は、別エンティティでみなす必要がある
カテゴリ
一つのものに正しい名前を割り当てて、データモデル上のエンティティ、関連、属性のいずれであるかを決定する koto
記事一覧と記事詳細を分けて管理したいかは事業側で競技してあって認識を合わせる必要がある。
エンティティのあいまいさを低減させるために、関係者各位で共通認識をとる必要がある
何をソフトウェアで解決するか
データモデルには解決する領域が二つ存在する
解決領域
ソフトウェアを使って解決する領域
ソフトウェアを使って解決したい領域ようにモデルをマッピングする
問題領域
日々業務を携わっている人にわかりやすいよう対象の領域
エンティティの性質などは問題領域をモデル化したもの
百貨店システムを構築したとする。通常は店舗に並べられている商品を管理するが、一部の富裕層は特別に輸入して販売することもある。この富裕層の輸入品をシステムに落とし込む必要があるかは別途、判断しないといけない。場合によっては、システムで管理しなくてもいいこともある
「変更できること」に隠された要求
「変更できる」ということには裏側に業務イベントが隠れている可能性がある。そのため、深掘りをしていく必要がある
仮に会員の情報を変更してほしいと要求に対して、変更できる機能とモデルに変更日時を属性として追加して対応するとする
変更イベントを洗い出す
エンティティに更新されたかを属性として持たせたい場合、関係者で議論するいい機械
一度設計してエンティティ対して、漏れの業務イベントを対応させると設計が複雑化するため、どんな業務イベントがあるかを関係者から聞き出す必要がある
例えば、以下の業務イベントが隠されていたとする
会員プロフィール変更画面から自分自身の変更する
規約に抵触する行為をしたので、オペレータをが強制的に大会する
間違って退会してしまったので、戻して欲しいとの要望を受け、オペレータが復活させる
上記の隠された業務イベントを考慮すると、会員エンティティとは別に「会員変更」「強制退会」「復会」というエンティティが必要になる
一つのエンティティの中に隠された差異
エンティティの属性に区別や種別を持つ場合は、深掘りのポイントになる
なぜなら、区分値や種別コードによってアプリケーションの扱いが変わったり、必要な属性のセットが変わったりすることが多いため。
例えば、学生区分として大学生・高校生・中学生・小学生という区分がある場合、「中学生または小学生であれば」みたいなロジックが分散することがある。こういうとできには学生分類というエンティティを作って、サブエンティティに義務教育という分類を追加したほうがいい
#単一性
#同一性
#カテゴリ