Movatterモバイル変換

イミュータブルデータモデル (入門編) kawasima

背景 •正しくデータモデリングを学んだ人(1NF～5NFの違いがわかる人)がモデルを書くのが理想だが、現実は難しいところもある。 •そういう状況において、モデリングのエキスパートでなくても、致命的な問題を起こしにくいモデルを作るための手法です。

ゴール •モデルの複雑性を増すのは、CRUDのうちのUPDATEに関する要件です。 •モデルに対するデータの更新を極限まで削ることによって、拡張に対して開いていて、修正に対して閉じている堅牢なものにします。

イミュータブル? •実際にはUPDATE全くなしに業務アプリケーションを作るのはハードル高すぎるので、ミュータブルな箇所を特定し、一定の意味付けをおこないUPDATEを許可する、という文脈です。 •「更新日時」という属性を徹底的に排除することにより、イミュータブルなモデルの獲得を目指します。

Step1 エンティティの抽出発送担当者が受注リストをもとに、商品の在庫を確認し、在庫があれば商品を発送する。 ① 要求仕様の「動詞」を抜き出しエンティティとする。 ② ①に関わる「名詞」を抜き出しエンティティとする。 ③ エンティティ間の関連に線を引く ④ 属性や候補キーも分かる範囲で書いておきます。間違い！この段階で実装をプロパティファイルにするとか、Enum にするとか決め打ちでエンティティとして表さないのはやめましょう。まず、はじめにエンティティを抽出します。

エンティティ名の付け方エンティティの名前は、短くその意味を的確に表現するものでなくてはなりません。なくても意味が通じるワードは使わないようにしましょう。なくても意味が通じるワード 情報 データ 処理 ～物 マスタ 記録 管理

ときどき論理設計=日本語名称、物理設計=英語(ローマ字)名称とプロセス定義して、英語名称を付けるのを後工程にまわすプロジェクトがありますが、そんな必要はありません。命名は和名/英名セットでおこないます。名付けには用語辞書を作って、ある程度機械的におこなうのがよくあるパターンですが、安易に短縮名称を使わないようにしましょう。母音を抜いて短くする短縮名付け文化圏があるようですが、これを機械的にやるとヒドイ英名が付けられるもとになります。 QUEUE → Q KIKAKU → KKK 論理設計と物理設計

Step2 エンティティの分類会員ID 姓名郵便番号住所電話番号注文番号注文会員ID 注文日時注文会員リソースイベント洗いだしたリソースとイベントに分類します。基準は属性に”日時” をもつかどうかです。または、Step1の①の動詞から抜き出したエンティティは“イベント”に、②の名詞から抜き出したエンティティは“リソース”になるはずです。

エンティティを分類するのに、未だ“マスタ”“トランザクション”というものを使うプロジェクトがありますが、この定義は曖昧で大抵どっちに分類するかでムダな議論のもとになります。「システムで更新しないものを“マスタ”とします」「マスタメンテ機能でされるんじゃない?」「あぁ、マスタメンテ機能での更新はノーカンです」「日に1回、社員マスタは社員管理システムから送られてきて洗い替えするんだけど」 … その点、リソース/イベントの分類は非常に明快で迷うところがありません。マスタ/トランザクションという分類

Step3 イベントエンティティは1つの日時属性しかもたないようにする受付番号注文会員ID 注文日時注文確認者注文確認日請求書出力フラグ入金予定日入金日時入金者氏名登録日時更新日時キャンセル日時キャンセル取消日時発注注文番号注文会員ID 注文日時注文発送指示ID 発送指示者発送指示日注文番号発送指示 One fact in one place. …

イベント系エンティティは、業務の記録です。すなわちイベント系エンティティに対する更新は、記録の更新、悪いいい方をすれば記録の改ざんになる訳です。したがって、イベント系エンティティは更新が入らないデータが格納されるものと考えることができます。業務の“記録” がイベントである

よく全てのエンティティに一律で登録日時や更新日時を付ける設計ルールを見かけます。あまつさえ、それを自動的に登録してくれるフレームワークもあるようです。これは何のためにあるのか再考してみましょう。おそらく最初の動機としては、何か問題があったときにトレースするためと思われますが、リソース系エンティティにつけても1世代の更新しかわかりません。そして更新前の状態もわかりません。本当に問題をトレースしたいのであれば、変更履歴を別のエンティティとして記録するべきです。一方、イベント系エンティティは登録/変更の日時を属性としてただ1 つもつので、同じ意味の属性を別にもたせる必要はありません。全エンティティに付ける登録日時や更新日時

都道府県コード都道府県名都道府県略名登録日時登録者ID 更新日時更新者ID 思考停止の象徴エンティティ都道府県にすら、更新日時 Σ（ﾟдﾟlll）

Step4 リソースに隠されたイベントを抽出する会員ID 姓名郵便番号住所電話番号会員リソースエンティティに更新日時を持たせたくなるのは、リソースにまつわるイベントが洗い出せていないことが原因と考えます。 •何かトラブル起こった時に原因をトレースするため会員が自分自身で会員情報変更ページから変更する。 •規約に違反した会員であったため、お客様センターのオペレータが強制退会を行う。 •会員からの誤った退会をしてしまったが、取り消してほしいとの問合せを受けて、お客様センターのオペレータが会員の復会を行う。更新日時

会員ID 姓名郵便番号住所電話番号会員会員変更ID 会員ID 姓名郵便番号住所電話番号変更日時変更イベントID 変更理由会員変更大抵の会員を管理するシステムではこういうモデルになるのではないでしょうか?

リソースに対する変更の記録としてのイベント系エンティティは、いわゆる履歴テーブルと言えます。履歴テーブルの実装には、「これが正解！」といえるものはなく、業務要件などに照らしあわせて設計することになります。このイミュータブルデータモデリングの手順のように、リソースに対する変更日時を記録したいと思ったら、これをイベントとして切り出すことを考えると、比較的失敗しにくいように思います。履歴テーブル

リソースは、イベントによって引き起こされる属性の変化の一時点でのスナップショットである。会員ID: 001 姓: Kawashima 名: Yoshitaka 郵便番号: 111-XXXX 住所: 東京都台東区電話番号: 090-xxx-xxx 会員ID: 001 姓: Kawashima 名: Yoshitaka 郵便番号: 111-XXXX 住所: 東京都台東区電話番号: 070-xxx-xxx 会員ID: 001 姓: Kawashima 名: Yoshitaka 郵便番号: 167-XXXX 住所: 東京都杉並区電話番号: 070-xxx-xxx 電話番号変更住所変更業務的に計画された更新がない、または更新のイベントをトレースする必要がない、場合に限り、このスナップショットだけを変更イベントをもたないリソースエンティティとして定義される、と考える。

Step5 非依存リレーションシップを交差エンティティにするリレーションが非依存である場合、外部キーにNULLを許し、後でアップデートすることが可能になってしまいます。こうした要求の裏には、別のイベントが隠れていることがあります。プログラマID 姓名プロジェクトID (FK) プログラマプロジェクトID プロジェクト名プロジェクトプログラマは、担当するプロジェクトがなくても、存在しうる。「アサイン」というリレーションシップが間にあるのでは?

R-R間の交差エンティティ社員ID 姓名部門ID (FK) 社員部門ID 部門名部門新人が部門に配属されたら部門IDに値を入れる。社員ID 姓名社員部門ID 部門名部門部門ID 社員ID 配属日配属配属イベントが潜んでいる。

E-E間の交差エンティティ請求ID 請求日時請求書宛先請求金額受注ID 受注日時請求ID 受注請求請求ID 請求日時請求書宛先請求金額受注ID 受注日時受注請求複数の受注をまとめて請求する。受注ID 請求ID 受注-請求対応する請求のデータができたら請求IDに値を入れる。 (時系列の逆転したリレーション) E-E間の場合は、イベントが潜むのではなく、対応表が必要になる。時系列の逆転が起こらないように設計する。

交差エンティティは多対多の場合だけのものではない B A ER図で、このような形だけみて、「エンティティAとエンティティBは、多対多じゃないんだけどっ！」というカーディナリティだけでリレーションシップを決めてしまう人がいます。重要なのは、非依存リレーションシップということは、互いに独立に存在しえて、何らかのイベントによって、それらに関係性が作られるという、このイベントが何か洗い出せているか? という点です。これをやらずに、カーディナリティだけでリレーションシップを考えると、業務上必要だったイベントエンティティを見落としてしまうことに繋がりかねません。

•更新日時に着目し、それらをエンティティから追い出すだけで、それなりの堅牢なデータモデルが書けるようになる。 •ただ、これだけでは不十分なところあるので、ちゃんと本を読もう。佐藤正美(2005) 『データベース設計論 T字型ER』羽生章洋(2006) 『楽々ERDレッスン』

Movatterモバイル変換

Change Language

イミュータブルデータモデル(入門編)

Recommended

More Related Content

What's hot

Viewers also liked

Similar to イミュータブルデータモデル(入門編)

More from Yoshitaka Kawashima

イミュータブルデータモデル(入門編)