Submit Search
Upload
イミュータブルデータモデル(入門編)
•
375 likes
•
188,332 views
Yoshitaka Kawashima
Follow
更新日時を排除していくことでそこそこのモデルを書けるようになる手法です。
Read less
Read more
Software
Report
Share
Report
Share
1 of 24
Download now
Download to read offline
Recommended
イミュータブルデータモデルの極意
イミュータブルデータモデルの極意
Yoshitaka Kawashima
イミュータブルデータモデル(世代編)
イミュータブルデータモデル(世代編)
Yoshitaka Kawashima
イベント・ソーシングを知る
イベント・ソーシングを知る
Shuhei Fujita
SQLアンチパターン - 開発者を待ち受ける25の落とし穴 (拡大版)
SQLアンチパターン - 開発者を待ち受ける25の落とし穴 (拡大版)
Takuto Wada
エンジニアの個人ブランディングと技術組織
エンジニアの個人ブランディングと技術組織
Takafumi ONAKA
PostgreSQLアンチパターン
PostgreSQLアンチパターン
Soudai Sone
ドメイン駆動設計のためのオブジェクト指向入門
ドメイン駆動設計のためのオブジェクト指向入門
増田 亨
開発速度が速い #とは(LayerX社内資料)
開発速度が速い #とは(LayerX社内資料)
mosa siru
Recommended
イミュータブルデータモデルの極意
イミュータブルデータモデルの極意
Yoshitaka Kawashima
イミュータブルデータモデル(世代編)
イミュータブルデータモデル(世代編)
Yoshitaka Kawashima
イベント・ソーシングを知る
イベント・ソーシングを知る
Shuhei Fujita
SQLアンチパターン - 開発者を待ち受ける25の落とし穴 (拡大版)
SQLアンチパターン - 開発者を待ち受ける25の落とし穴 (拡大版)
Takuto Wada
エンジニアの個人ブランディングと技術組織
エンジニアの個人ブランディングと技術組織
Takafumi ONAKA
PostgreSQLアンチパターン
PostgreSQLアンチパターン
Soudai Sone
ドメイン駆動設計のためのオブジェクト指向入門
ドメイン駆動設計のためのオブジェクト指向入門
増田 亨
開発速度が速い #とは(LayerX社内資料)
開発速度が速い #とは(LayerX社内資料)
mosa siru
DDDのモデリングとは何なのか、 そしてどうコードに落とすのか
DDDのモデリングとは何なのか、 そしてどうコードに落とすのか
Koichiro Matsuoka
SQLアンチパターン 幻の第26章「とりあえず削除フラグ」
SQLアンチパターン 幻の第26章「とりあえず削除フラグ」
Takuto Wada
ドメイン駆動設計 ( DDD ) をやってみよう
ドメイン駆動設計 ( DDD ) をやってみよう
増田 亨
ドメイン駆動設計サンプルコードの徹底解説
ドメイン駆動設計サンプルコードの徹底解説
増田 亨
DDD x CQRS 更新系と参照系で異なるORMを併用して上手くいった話
DDD x CQRS 更新系と参照系で異なるORMを併用して上手くいった話
Koichiro Matsuoka
なぜ、いま リレーショナルモデルなのか(理論から学ぶデータベース実践入門読書会スペシャル)
なぜ、いま リレーショナルモデルなのか(理論から学ぶデータベース実践入門読書会スペシャル)
Mikiya Okuno
マイクロサービス 4つの分割アプローチ
マイクロサービス 4つの分割アプローチ
増田 亨
Java ORマッパー選定のポイント #jsug
Java ORマッパー選定のポイント #jsug
Masatoshi Tada
ドメイン駆動設計 本格入門
ドメイン駆動設計 本格入門
増田 亨
オブジェクト指向プログラミングのためのモデリング入門
オブジェクト指向プログラミングのためのモデリング入門
増田 亨
3週連続DDDその1 ドメイン駆動設計の基本を理解する
3週連続DDDその1 ドメイン駆動設計の基本を理解する
増田 亨
世界一わかりやすいClean Architecture
世界一わかりやすいClean Architecture
Atsushi Nakamura
コンテナの作り方「Dockerは裏方で何をしているのか?」
コンテナの作り方「Dockerは裏方で何をしているのか?」
Masahito Zembutsu
強いて言えば「集約どう実装するのかな、を考える」な話
強いて言えば「集約どう実装するのかな、を考える」な話
Yoshitaka Kawashima
Tackling Complexity
Tackling Complexity
Yoshitaka Kawashima
それはYAGNIか? それとも思考停止か?
それはYAGNIか? それとも思考停止か?
Yoshitaka Kawashima
目grep入門 +解説
目grep入門 +解説
murachue
例外設計における大罪
例外設計における大罪
Takuto Wada
ツール比較しながら語る O/RマッパーとDBマイグレーションの実際のところ
ツール比較しながら語る O/RマッパーとDBマイグレーションの実際のところ
Y Watanabe
SQL大量発行処理をいかにして高速化するか
SQL大量発行処理をいかにして高速化するか
Shogo Wakayama
MySQLで論理削除と正しく付き合う方法
MySQLで論理削除と正しく付き合う方法
yoku0825
[AKIBA.AWS] EC2の基礎 - パフォーマンスを100%引き出すオプション設定 -
[AKIBA.AWS] EC2の基礎 - パフォーマンスを100%引き出すオプション設定 -
Shuji Kikuchi
More Related Content
What's hot
DDDのモデリングとは何なのか、 そしてどうコードに落とすのか
DDDのモデリングとは何なのか、 そしてどうコードに落とすのか
Koichiro Matsuoka
SQLアンチパターン 幻の第26章「とりあえず削除フラグ」
SQLアンチパターン 幻の第26章「とりあえず削除フラグ」
Takuto Wada
ドメイン駆動設計 ( DDD ) をやってみよう
ドメイン駆動設計 ( DDD ) をやってみよう
増田 亨
ドメイン駆動設計サンプルコードの徹底解説
ドメイン駆動設計サンプルコードの徹底解説
増田 亨
DDD x CQRS 更新系と参照系で異なるORMを併用して上手くいった話
DDD x CQRS 更新系と参照系で異なるORMを併用して上手くいった話
Koichiro Matsuoka
なぜ、いま リレーショナルモデルなのか(理論から学ぶデータベース実践入門読書会スペシャル)
なぜ、いま リレーショナルモデルなのか(理論から学ぶデータベース実践入門読書会スペシャル)
Mikiya Okuno
マイクロサービス 4つの分割アプローチ
マイクロサービス 4つの分割アプローチ
増田 亨
Java ORマッパー選定のポイント #jsug
Java ORマッパー選定のポイント #jsug
Masatoshi Tada
ドメイン駆動設計 本格入門
ドメイン駆動設計 本格入門
増田 亨
オブジェクト指向プログラミングのためのモデリング入門
オブジェクト指向プログラミングのためのモデリング入門
増田 亨
3週連続DDDその1 ドメイン駆動設計の基本を理解する
3週連続DDDその1 ドメイン駆動設計の基本を理解する
増田 亨
世界一わかりやすいClean Architecture
世界一わかりやすいClean Architecture
Atsushi Nakamura
コンテナの作り方「Dockerは裏方で何をしているのか?」
コンテナの作り方「Dockerは裏方で何をしているのか?」
Masahito Zembutsu
強いて言えば「集約どう実装するのかな、を考える」な話
強いて言えば「集約どう実装するのかな、を考える」な話
Yoshitaka Kawashima
Tackling Complexity
Tackling Complexity
Yoshitaka Kawashima
それはYAGNIか? それとも思考停止か?
それはYAGNIか? それとも思考停止か?
Yoshitaka Kawashima
目grep入門 +解説
目grep入門 +解説
murachue
例外設計における大罪
例外設計における大罪
Takuto Wada
ツール比較しながら語る O/RマッパーとDBマイグレーションの実際のところ
ツール比較しながら語る O/RマッパーとDBマイグレーションの実際のところ
Y Watanabe
SQL大量発行処理をいかにして高速化するか
SQL大量発行処理をいかにして高速化するか
Shogo Wakayama
What's hot
(20)
DDDのモデリングとは何なのか、 そしてどうコードに落とすのか
DDDのモデリングとは何なのか、 そしてどうコードに落とすのか
SQLアンチパターン 幻の第26章「とりあえず削除フラグ」
SQLアンチパターン 幻の第26章「とりあえず削除フラグ」
ドメイン駆動設計 ( DDD ) をやってみよう
ドメイン駆動設計 ( DDD ) をやってみよう
ドメイン駆動設計サンプルコードの徹底解説
ドメイン駆動設計サンプルコードの徹底解説
DDD x CQRS 更新系と参照系で異なるORMを併用して上手くいった話
DDD x CQRS 更新系と参照系で異なるORMを併用して上手くいった話
なぜ、いま リレーショナルモデルなのか(理論から学ぶデータベース実践入門読書会スペシャル)
なぜ、いま リレーショナルモデルなのか(理論から学ぶデータベース実践入門読書会スペシャル)
マイクロサービス 4つの分割アプローチ
マイクロサービス 4つの分割アプローチ
Java ORマッパー選定のポイント #jsug
Java ORマッパー選定のポイント #jsug
ドメイン駆動設計 本格入門
ドメイン駆動設計 本格入門
オブジェクト指向プログラミングのためのモデリング入門
オブジェクト指向プログラミングのためのモデリング入門
3週連続DDDその1 ドメイン駆動設計の基本を理解する
3週連続DDDその1 ドメイン駆動設計の基本を理解する
世界一わかりやすいClean Architecture
世界一わかりやすいClean Architecture
コンテナの作り方「Dockerは裏方で何をしているのか?」
コンテナの作り方「Dockerは裏方で何をしているのか?」
強いて言えば「集約どう実装するのかな、を考える」な話
強いて言えば「集約どう実装するのかな、を考える」な話
Tackling Complexity
Tackling Complexity
それはYAGNIか? それとも思考停止か?
それはYAGNIか? それとも思考停止か?
目grep入門 +解説
目grep入門 +解説
例外設計における大罪
例外設計における大罪
ツール比較しながら語る O/RマッパーとDBマイグレーションの実際のところ
ツール比較しながら語る O/RマッパーとDBマイグレーションの実際のところ
SQL大量発行処理をいかにして高速化するか
SQL大量発行処理をいかにして高速化するか
Viewers also liked
MySQLで論理削除と正しく付き合う方法
MySQLで論理削除と正しく付き合う方法
yoku0825
[AKIBA.AWS] EC2の基礎 - パフォーマンスを100%引き出すオプション設定 -
[AKIBA.AWS] EC2の基礎 - パフォーマンスを100%引き出すオプション設定 -
Shuji Kikuchi
Dependency injection in PHP 5.3/5.4
Dependency injection in PHP 5.3/5.4
Fabien Potencier
データモデルは時空を越える
データモデルは時空を越える
terahide
良いコードとは
良いコードとは
Nobuyuki Matsui
エスイーが要件定義でやるべきたったひとつのこと
エスイーが要件定義でやるべきたったひとつのこと
Yoshitaka Kawashima
Goのサーバサイド実装におけるレイヤ設計とレイヤ内実装について考える
Goのサーバサイド実装におけるレイヤ設計とレイヤ内実装について考える
pospome
片手間MySQLチューニング戦略
片手間MySQLチューニング戦略
yoku0825
If文から機械学習への道
If文から機械学習への道
nishio
データ履歴管理のためのテンポラルデータモデルとReladomoの紹介 #jjug_ccc #ccc_g3
データ履歴管理のためのテンポラルデータモデルとReladomoの紹介 #jjug_ccc #ccc_g3
Hiroshi Ito
Spring Bootの本当の理解ポイント #jjug
Spring Bootの本当の理解ポイント #jjug
Masatoshi Tada
Viewers also liked
(11)
MySQLで論理削除と正しく付き合う方法
MySQLで論理削除と正しく付き合う方法
[AKIBA.AWS] EC2の基礎 - パフォーマンスを100%引き出すオプション設定 -
[AKIBA.AWS] EC2の基礎 - パフォーマンスを100%引き出すオプション設定 -
Dependency injection in PHP 5.3/5.4
Dependency injection in PHP 5.3/5.4
データモデルは時空を越える
データモデルは時空を越える
良いコードとは
良いコードとは
エスイーが要件定義でやるべきたったひとつのこと
エスイーが要件定義でやるべきたったひとつのこと
Goのサーバサイド実装におけるレイヤ設計とレイヤ内実装について考える
Goのサーバサイド実装におけるレイヤ設計とレイヤ内実装について考える
片手間MySQLチューニング戦略
片手間MySQLチューニング戦略
If文から機械学習への道
If文から機械学習への道
データ履歴管理のためのテンポラルデータモデルとReladomoの紹介 #jjug_ccc #ccc_g3
データ履歴管理のためのテンポラルデータモデルとReladomoの紹介 #jjug_ccc #ccc_g3
Spring Bootの本当の理解ポイント #jjug
Spring Bootの本当の理解ポイント #jjug
Similar to イミュータブルデータモデル(入門編)
OpenSpan_PreMarketing_Reference
OpenSpan_PreMarketing_Reference
motani_kamakura
IDC 電子ブック 『マイクロソフト モダン パートナー シリーズ 2016』パート 4: 業務の最適化
IDC 電子ブック 『マイクロソフト モダン パートナー シリーズ 2016』パート 4: 業務の最適化
MPN Japan
経営情報フォーラム2009
経営情報フォーラム2009
guest5ad17cf
経営情報フォーラム2009発表資料
経営情報フォーラム2009発表資料
Keiichi Hashimoto
非開発者のためのアジャイル開発入門
非開発者のためのアジャイル開発入門
Kiro Harada
X_顧客事例
X_顧客事例
motani_kamakura
Asahikawa_Ict 20120726
Asahikawa_Ict 20120726
kspro
Salesforce crm over_view_2012_0301
Salesforce crm over_view_2012_0301
Kohei Nishikawa
Microsoft 365 で NoOps を考える
Microsoft 365 で NoOps を考える
祥子 松山
MySQLで学ぶ機械学習ことはじめ.pdf
MySQLで学ぶ機械学習ことはじめ.pdf
Machiko Ikoma
Process base
Process base
Daisuke Sugai
[B23] 事例で語る、社会インフラを支えるNonStop SQL ~見えないところで凄いんです~by Tetsuya Shinohara
[B23] 事例で語る、社会インフラを支えるNonStop SQL ~見えないところで凄いんです~by Tetsuya Shinohara
Insight Technology, Inc.
アジャイルにモデリングは必要か
アジャイルにモデリングは必要か
Hiromasa Oka
Share Point Online 会社のデータしっかり管理のススメ
Share Point Online 会社のデータしっかり管理のススメ
kumo2010
20111212勉強会資料
20111212勉強会資料
株式会社インサイト
大規模データに対するデータサイエンスの進め方 #CWT2016
大規模データに対するデータサイエンスの進め方 #CWT2016
Cloudera Japan
enterprise social network sales use case ja
enterprise social network sales use case ja
BroadVision
Citrix eco new
Citrix eco new
Naotaka Jay HOTTA
第11回SIA例会プレゼン資料
第11回SIA例会プレゼン資料
Tae Yoshida
Tech Ed 2009 Japan T3-309 Microsoft Business Productivity Online Services 技術概要
Tech Ed 2009 Japan T3-309 Microsoft Business Productivity Online Services 技術概要
kumo2010
Similar to イミュータブルデータモデル(入門編)
(20)
OpenSpan_PreMarketing_Reference
OpenSpan_PreMarketing_Reference
IDC 電子ブック 『マイクロソフト モダン パートナー シリーズ 2016』パート 4: 業務の最適化
IDC 電子ブック 『マイクロソフト モダン パートナー シリーズ 2016』パート 4: 業務の最適化
経営情報フォーラム2009
経営情報フォーラム2009
経営情報フォーラム2009発表資料
経営情報フォーラム2009発表資料
非開発者のためのアジャイル開発入門
非開発者のためのアジャイル開発入門
X_顧客事例
X_顧客事例
Asahikawa_Ict 20120726
Asahikawa_Ict 20120726
Salesforce crm over_view_2012_0301
Salesforce crm over_view_2012_0301
Microsoft 365 で NoOps を考える
Microsoft 365 で NoOps を考える
MySQLで学ぶ機械学習ことはじめ.pdf
MySQLで学ぶ機械学習ことはじめ.pdf
Process base
Process base
[B23] 事例で語る、社会インフラを支えるNonStop SQL ~見えないところで凄いんです~by Tetsuya Shinohara
[B23] 事例で語る、社会インフラを支えるNonStop SQL ~見えないところで凄いんです~by Tetsuya Shinohara
アジャイルにモデリングは必要か
アジャイルにモデリングは必要か
Share Point Online 会社のデータしっかり管理のススメ
Share Point Online 会社のデータしっかり管理のススメ
20111212勉強会資料
20111212勉強会資料
大規模データに対するデータサイエンスの進め方 #CWT2016
大規模データに対するデータサイエンスの進め方 #CWT2016
enterprise social network sales use case ja
enterprise social network sales use case ja
Citrix eco new
Citrix eco new
第11回SIA例会プレゼン資料
第11回SIA例会プレゼン資料
Tech Ed 2009 Japan T3-309 Microsoft Business Productivity Online Services 技術概要
Tech Ed 2009 Japan T3-309 Microsoft Business Productivity Online Services 技術概要
More from Yoshitaka Kawashima
ブルックスのいう銀の弾丸とは何か?
ブルックスのいう銀の弾丸とは何か?
Yoshitaka Kawashima
Are Design Patterns Dead?
Are Design Patterns Dead?
Yoshitaka Kawashima
ソフトウェアにおける 複雑さとは何なのか?
ソフトウェアにおける 複雑さとは何なのか?
Yoshitaka Kawashima
ソフトウェア開発における『知の高速道路』
ソフトウェア開発における『知の高速道路』
Yoshitaka Kawashima
ソフトウェア設計における 意思決定とそのレビューの秘訣
ソフトウェア設計における 意思決定とそのレビューの秘訣
Yoshitaka Kawashima
本番障害に至る病
本番障害に至る病
Yoshitaka Kawashima
システムダウンのひみつ
システムダウンのひみつ
Yoshitaka Kawashima
Mavenの真実とウソ
Mavenの真実とウソ
Yoshitaka Kawashima
アンチフラジャイルの世界
アンチフラジャイルの世界
Yoshitaka Kawashima
Atomic Architecture
Atomic Architecture
Yoshitaka Kawashima
思考停止しないアーキテクチャ設計 ➖ JJUG CCC 2018 Fall
思考停止しないアーキテクチャ設計 ➖ JJUG CCC 2018 Fall
Yoshitaka Kawashima
ウォーターフォールとアジャイルのフェアな比較
ウォーターフォールとアジャイルのフェアな比較
Yoshitaka Kawashima
How to find tech books
How to find tech books
Yoshitaka Kawashima
Antifragile Java - Java Day Tokyo 2017 D1-E1
Antifragile Java - Java Day Tokyo 2017 D1-E1
Yoshitaka Kawashima
たとえ日本人同士でも必要な異文化理解力
たとえ日本人同士でも必要な異文化理解力
Yoshitaka Kawashima
SIerにとっての越境 @ DevLOVE 199
SIerにとっての越境 @ DevLOVE 199
Yoshitaka Kawashima
なぜデータモデリングが重要なのか?
なぜデータモデリングが重要なのか?
Yoshitaka Kawashima
Antifragile Clojure
Antifragile Clojure
Yoshitaka Kawashima
Boilerplate vs Magic
Boilerplate vs Magic
Yoshitaka Kawashima
既婚プログラマの時間捻出術
既婚プログラマの時間捻出術
Yoshitaka Kawashima
More from Yoshitaka Kawashima
(20)
ブルックスのいう銀の弾丸とは何か?
ブルックスのいう銀の弾丸とは何か?
Are Design Patterns Dead?
Are Design Patterns Dead?
ソフトウェアにおける 複雑さとは何なのか?
ソフトウェアにおける 複雑さとは何なのか?
ソフトウェア開発における『知の高速道路』
ソフトウェア開発における『知の高速道路』
ソフトウェア設計における 意思決定とそのレビューの秘訣
ソフトウェア設計における 意思決定とそのレビューの秘訣
本番障害に至る病
本番障害に至る病
システムダウンのひみつ
システムダウンのひみつ
Mavenの真実とウソ
Mavenの真実とウソ
アンチフラジャイルの世界
アンチフラジャイルの世界
Atomic Architecture
Atomic Architecture
思考停止しないアーキテクチャ設計 ➖ JJUG CCC 2018 Fall
思考停止しないアーキテクチャ設計 ➖ JJUG CCC 2018 Fall
ウォーターフォールとアジャイルのフェアな比較
ウォーターフォールとアジャイルのフェアな比較
How to find tech books
How to find tech books
Antifragile Java - Java Day Tokyo 2017 D1-E1
Antifragile Java - Java Day Tokyo 2017 D1-E1
たとえ日本人同士でも必要な異文化理解力
たとえ日本人同士でも必要な異文化理解力
SIerにとっての越境 @ DevLOVE 199
SIerにとっての越境 @ DevLOVE 199
なぜデータモデリングが重要なのか?
なぜデータモデリングが重要なのか?
Antifragile Clojure
Antifragile Clojure
Boilerplate vs Magic
Boilerplate vs Magic
既婚プログラマの時間捻出術
既婚プログラマの時間捻出術
イミュータブルデータモデル(入門編)
1.
イミュータブル データモデル (入門編)
kawasima
2.
背景 •正しくデータモデリングを学んだ人(1NF~5NFの違いがわかる人)がモデルを書く のが理想だが、現実は難しいところもあ
る。 •そういう状況において、モデリングのエ キスパートでなくても、致命的な問題を 起こしにくいモデルを作るための手法で す。
3.
ゴール •モデルの複雑性を増すのは、CRUDのうち のUPDATEに関する要件です。
•モデルに対するデータの更新を極限まで 削ることによって、拡張に対して開いて いて、修正に対して閉じている堅牢なも のにします。
4.
イミュータブル? •実際にはUPDATE全くなしに業務アプリ ケーションを作るのはハードル高すぎる
ので、ミュータブルな箇所を特定し、一 定の意味付けをおこないUPDATEを許可す る、という文脈です。 •「更新日時」という属性を徹底的に排除 することにより、イミュータブルなモデ ルの獲得を目指します。
5.
モデリングの手順
6.
Step1 エンティティの抽出 発送担当者が受注リストをもとに、商品の在庫を確認し、在庫が
あれば商品を発送する。 ① 要求仕様の「動詞」を抜き出しエンティティとする。 ② ①に関わる「名詞」を抜き出しエンティティとする。 ③ エンティティ間の関連に線を引く ④ 属性や候補キーも分かる範囲で書いておきます。 間違い! この段階で実装をプロパティファイルにするとか、Enum にするとか決め打ちでエンティティとして表さないのはや めましょう。 まず、はじめにエンティティを抽出します。
7.
エンティティ名の付け方 エンティティの名前は、短くその意味を的確に表現するものでなくて はなりません。なくても意味が通じるワードは使わないようにしま
しょう。 なくても意味が通じるワード 情報 データ 処理 ~物 マスタ 記録 管理
8.
ときどき論理設計=日本語名称、物理設計=英語(ローマ字)名称とプロ セス定義して、英語名称を付けるのを後工程にまわすプロジェクトが ありますが、そんな必要はありません。命名は和名/英名セットでおこ
ないます。 名付けには用語辞書を作って、ある程度機械的におこなうのがよくあ るパターンですが、安易に短縮名称を使わないようにしましょう。 母音を抜いて短くする短縮名付け文化圏があるようですが、これを機 械的にやるとヒドイ英名が付けられるもとになります。 QUEUE → Q KIKAKU → KKK 論理設計と物理設計
9.
Step2 エンティティの分類 会員ID
姓 名 郵便番号 住所 電話番号 注文番号 注文会員ID 注文日時 注文 会員 リソース イベント 洗いだしたリソースとイベントに分類します。 基準は属性に”日時” をもつかどうかです。 または、Step1の①の動詞から抜き出したエンティティは“イベ ント”に、②の名詞から抜き出したエンティティは“リソース”に なるはずです。
10.
エンティティを分類するのに、未だ“マスタ”“トランザクション”とい うものを使うプロジェクトがありますが、この定義は曖昧で大抵どっ ちに分類するかでムダな議論のもとになります。
「システムで更新しないものを“マスタ”とします」 「マスタメンテ機能でされるんじゃない?」 「あぁ、マスタメンテ機能での更新はノーカンです」 「日に1回、社員マスタは社員管理システムから送られてきて洗い替えするんだけ ど」 … その点、リソース/イベントの分類は非常に明快で迷うところがありま せん。 マスタ/トランザクションという分類
11.
Step3 イベントエンティティは1つの日時属性 しかもたないようにする
受付番号 注文会員ID 注文日時 注文確認者 注文確認日 請求書出力フラグ 入金予定日 入金日時 入金者氏名 登録日時 更新日時 キャンセル日時 キャンセル取消日時 発注 注文番号 注文会員ID 注文日時 注文 発送指示ID 発送指示者 発送指示日 注文番号 発送指示 One fact in one place. …
12.
イベント系エンティティは、業務の記録です。すなわちイベント系エ ンティティに対する更新は、記録の更新、悪いいい方をすれば記録の 改ざんになる訳です。
したがって、イベント系エンティティは更新が入らないデータが格納 されるものと考えることができます。 業務の“記録” がイベントである
13.
よく全てのエンティティに一律で登録日時や更新日時を付ける設計 ルールを見かけます。あまつさえ、それを自動的に登録してくれるフ レームワークもあるようです。
これは何のためにあるのか再考してみましょう。 おそらく最初の動機としては、何か問題があったときにトレースする ためと思われますが、リソース系エンティティにつけても1世代の更新 しかわかりません。そして更新前の状態もわかりません。本当に問題 をトレースしたいのであれば、変更履歴を別のエンティティとして記 録するべきです。 一方、イベント系エンティティは登録/変更の日時を属性としてただ1 つもつので、同じ意味の属性を別にもたせる必要はありません。 全エンティティに付ける登録日時や更新日時
14.
都道府県コード 都道府県名 都道府県略名
登録日時 登録者ID 更新日時 更新者ID 思考停止の象徴エンティティ 都道府県にすら、更新日時 Σ(゚д゚lll)
15.
Step4 リソースに隠された イベントを抽出する
会員ID 姓 名 郵便番号 住所 電話番号 会員 リソースエンティティに更新日時を持たせたくなるのは、リソースにまつ わるイベントが洗い出せていないことが原因と考えます。 •何かトラブル起こった時に原因をトレースす るため会員が自分自身で会員情報変更ページ から変更する。 •規約に違反した会員であったため、お客様セ ンターのオペレータが強制退会を行う。 •会員からの誤った退会をしてしまったが、取 り消してほしいとの問合せを受けて、お客様 センターのオペレータが会員の復会を行う。 更新日時
16.
会員ID 姓 名
郵便番号 住所 電話番号 会員 会員変更ID 会員ID 姓 名 郵便番号 住所 電話番号 変更日時 変更イベントID 変更理由 会員変更 大抵の会員を管理するシステムではこういうモデルになるのでは ないでしょうか?
17.
リソースに対する変更の記録としてのイベント系エンティティは、い わゆる履歴テーブルと言えます。 履歴テーブルの実装には、「これが正解!」といえるものはなく、業
務要件などに照らしあわせて設計することになります。 このイミュータブルデータモデリングの手順のように、リソースに対 する変更日時を記録したいと思ったら、これをイベントとして切り出 すことを考えると、比較的失敗しにくいように思います。 履歴テーブル
18.
リソースは、イベントによって引き起こされる属性の変化の 一時点でのスナップショットである。 会員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 電話番号変更 住所変更 業務的に計画された更新がない、または更新のイベントをトレースする必 要がない、場合に限り、このスナップショットだけを変更イベントをもた ないリソースエンティティとして定義される、と考える。
19.
Step5 非依存リレーションシップを 交差エンティティにする
リレーションが非依存である場合、外部キーにNULLを許し、後でアップ デートすることが可能になってしまいます。 こうした要求の裏には、別のイベントが隠れていることがあります。 プログラマID 姓 名 プロジェクトID (FK) プログラマ プロジェクトID プロジェクト名 プロジェクト プログラマは、担当するプロジェク トがなくても、存在しうる。 「アサイン」というリレーション シップが間にあるのでは?
20.
R-R間の交差エンティティ 社員ID 姓
名 部門ID (FK) 社員 部門ID 部門名 部門 新人が部門に配属されたら部門IDに 値を入れる。 社員ID 姓 名 社員 部門ID 部門名 部門 部門ID 社員ID 配属日 配属 配属イベントが潜んでいる。
21.
E-E間の交差エンティティ 請求ID 請求日時
請求書宛先 請求金額 受注ID 受注日時 請求ID 受注 請求 請求ID 請求日時 請求書宛先 請求金額 受注ID 受注日時 受注 請求 複数の受注をまとめて請求する。 受注ID 請求ID 受注-請求 対応する請求のデータができたら請求IDに 値を入れる。 (時系列の逆転したリレーション) E-E間の場合は、イベントが潜むのではなく、対応表が必要に なる。時系列の逆転が起こらないように設計する。
22.
交差エンティティは多対多の場合だけのものではない B A
ER図で、このような形だけみて、「エンティティAとエンティティBは、 多対多じゃないんだけどっ!」というカーディナリティだけでリレー ションシップを決めてしまう人がいます。 重要なのは、非依存リレーションシップということは、互いに独立に 存在しえて、何らかのイベントによって、それらに関係性が作られる という、このイベントが何か洗い出せているか? という点です。 これをやらずに、カーディナリティだけでリレーションシップを考え ると、業務上必要だったイベントエンティティを見落としてしまうこ とに繋がりかねません。
23.
まとめ
24.
•更新日時に着目し、それらをエンティ ティから追い出すだけで、それなりの堅 牢なデータモデルが書けるようになる。
•ただ、これだけでは不十分なところある ので、ちゃんと本を読もう。 佐藤正美(2005) 『データベース設計論 T字型ER』 羽生章洋(2006) 『楽々ERDレッスン』
Download now