Submit Search
Upload
イミュータブルデータモデル(入門編)
•
375 likes
•
188,917 views
Yoshitaka Kawashima
Follow
更新日時を排除していくことでそこそこのモデルを書けるようになる手法です。
Read less
Read more
Software
Report
Share
Report
Share
1 of 24
Download now
Download to read offline
Recommended
SQLアンチパターン 幻の第26章「とりあえず削除フラグ」
SQLアンチパターン 幻の第26章「とりあえず削除フラグ」
Takuto Wada
イミュータブルデータモデルの極意
イミュータブルデータモデルの極意
Yoshitaka Kawashima
イミュータブルデータモデル(世代編)
イミュータブルデータモデル(世代編)
Yoshitaka Kawashima
世界一わかりやすいClean Architecture
世界一わかりやすいClean Architecture
Atsushi Nakamura
ドメイン駆動設計 ( DDD ) をやってみよう
ドメイン駆動設計 ( DDD ) をやってみよう
増田 亨
SQLアンチパターン - 開発者を待ち受ける25の落とし穴 (拡大版)
SQLアンチパターン - 開発者を待ち受ける25の落とし穴 (拡大版)
Takuto Wada
エンジニアの個人ブランディングと技術組織
エンジニアの個人ブランディングと技術組織
Takafumi ONAKA
それはYAGNIか? それとも思考停止か?
それはYAGNIか? それとも思考停止か?
Yoshitaka Kawashima
Recommended
SQLアンチパターン 幻の第26章「とりあえず削除フラグ」
SQLアンチパターン 幻の第26章「とりあえず削除フラグ」
Takuto Wada
イミュータブルデータモデルの極意
イミュータブルデータモデルの極意
Yoshitaka Kawashima
イミュータブルデータモデル(世代編)
イミュータブルデータモデル(世代編)
Yoshitaka Kawashima
世界一わかりやすいClean Architecture
世界一わかりやすいClean Architecture
Atsushi Nakamura
ドメイン駆動設計 ( DDD ) をやってみよう
ドメイン駆動設計 ( DDD ) をやってみよう
増田 亨
SQLアンチパターン - 開発者を待ち受ける25の落とし穴 (拡大版)
SQLアンチパターン - 開発者を待ち受ける25の落とし穴 (拡大版)
Takuto Wada
エンジニアの個人ブランディングと技術組織
エンジニアの個人ブランディングと技術組織
Takafumi ONAKA
それはYAGNIか? それとも思考停止か?
それはYAGNIか? それとも思考停止か?
Yoshitaka Kawashima
Dockerからcontainerdへの移行
Dockerからcontainerdへの移行
Kohei Tokunaga
ドメイン駆動設計サンプルコードの徹底解説
ドメイン駆動設計サンプルコードの徹底解説
増田 亨
マイクロサービス 4つの分割アプローチ
マイクロサービス 4つの分割アプローチ
増田 亨
なぜ、いま リレーショナルモデルなのか(理論から学ぶデータベース実践入門読書会スペシャル)
なぜ、いま リレーショナルモデルなのか(理論から学ぶデータベース実践入門読書会スペシャル)
Mikiya Okuno
ドメインオブジェクトの見つけ方・作り方・育て方
ドメインオブジェクトの見つけ方・作り方・育て方
増田 亨
境界付けられたコンテキスト 概念編 (ドメイン駆動設計用語解説シリーズ)
境界付けられたコンテキスト 概念編 (ドメイン駆動設計用語解説シリーズ)
Koichiro Matsuoka
DDD x CQRS 更新系と参照系で異なるORMを併用して上手くいった話
DDD x CQRS 更新系と参照系で異なるORMを併用して上手くいった話
Koichiro Matsuoka
PostgreSQLアンチパターン
PostgreSQLアンチパターン
Soudai Sone
例外設計における大罪
例外設計における大罪
Takuto Wada
Goのサーバサイド実装におけるレイヤ設計とレイヤ内実装について考える
Goのサーバサイド実装におけるレイヤ設計とレイヤ内実装について考える
pospome
45分間で「ユーザー中心のものづくり」ができるまで詰め込む
45分間で「ユーザー中心のものづくり」ができるまで詰め込む
Yoshiki Hayama
オブジェクト指向エクササイズのススメ
オブジェクト指向エクササイズのススメ
Yoji Kanno
Apache Avro vs Protocol Buffers
Apache Avro vs Protocol Buffers
Seiya Mizuno
イベント・ソーシングを知る
イベント・ソーシングを知る
Shuhei Fujita
ドメイン駆動で開発する ラフスケッチから実装まで
ドメイン駆動で開発する ラフスケッチから実装まで
増田 亨
ドメイン駆動設計 本格入門
ドメイン駆動設計 本格入門
増田 亨
Tackling Complexity
Tackling Complexity
Yoshitaka Kawashima
オブジェクト指向プログラミングのためのモデリング入門
オブジェクト指向プログラミングのためのモデリング入門
増田 亨
やはりお前らのMVCは間違っている
やはりお前らのMVCは間違っている
Koichi Tanaka
ツール比較しながら語る O/RマッパーとDBマイグレーションの実際のところ
ツール比較しながら語る O/RマッパーとDBマイグレーションの実際のところ
Y Watanabe
MySQLで論理削除と正しく付き合う方法
MySQLで論理削除と正しく付き合う方法
yoku0825
[AKIBA.AWS] EC2の基礎 - パフォーマンスを100%引き出すオプション設定 -
[AKIBA.AWS] EC2の基礎 - パフォーマンスを100%引き出すオプション設定 -
Shuji Kikuchi
More Related Content
What's hot
Dockerからcontainerdへの移行
Dockerからcontainerdへの移行
Kohei Tokunaga
ドメイン駆動設計サンプルコードの徹底解説
ドメイン駆動設計サンプルコードの徹底解説
増田 亨
マイクロサービス 4つの分割アプローチ
マイクロサービス 4つの分割アプローチ
増田 亨
なぜ、いま リレーショナルモデルなのか(理論から学ぶデータベース実践入門読書会スペシャル)
なぜ、いま リレーショナルモデルなのか(理論から学ぶデータベース実践入門読書会スペシャル)
Mikiya Okuno
ドメインオブジェクトの見つけ方・作り方・育て方
ドメインオブジェクトの見つけ方・作り方・育て方
増田 亨
境界付けられたコンテキスト 概念編 (ドメイン駆動設計用語解説シリーズ)
境界付けられたコンテキスト 概念編 (ドメイン駆動設計用語解説シリーズ)
Koichiro Matsuoka
DDD x CQRS 更新系と参照系で異なるORMを併用して上手くいった話
DDD x CQRS 更新系と参照系で異なるORMを併用して上手くいった話
Koichiro Matsuoka
PostgreSQLアンチパターン
PostgreSQLアンチパターン
Soudai Sone
例外設計における大罪
例外設計における大罪
Takuto Wada
Goのサーバサイド実装におけるレイヤ設計とレイヤ内実装について考える
Goのサーバサイド実装におけるレイヤ設計とレイヤ内実装について考える
pospome
45分間で「ユーザー中心のものづくり」ができるまで詰め込む
45分間で「ユーザー中心のものづくり」ができるまで詰め込む
Yoshiki Hayama
オブジェクト指向エクササイズのススメ
オブジェクト指向エクササイズのススメ
Yoji Kanno
Apache Avro vs Protocol Buffers
Apache Avro vs Protocol Buffers
Seiya Mizuno
イベント・ソーシングを知る
イベント・ソーシングを知る
Shuhei Fujita
ドメイン駆動で開発する ラフスケッチから実装まで
ドメイン駆動で開発する ラフスケッチから実装まで
増田 亨
ドメイン駆動設計 本格入門
ドメイン駆動設計 本格入門
増田 亨
Tackling Complexity
Tackling Complexity
Yoshitaka Kawashima
オブジェクト指向プログラミングのためのモデリング入門
オブジェクト指向プログラミングのためのモデリング入門
増田 亨
やはりお前らのMVCは間違っている
やはりお前らのMVCは間違っている
Koichi Tanaka
ツール比較しながら語る O/RマッパーとDBマイグレーションの実際のところ
ツール比較しながら語る O/RマッパーとDBマイグレーションの実際のところ
Y Watanabe
What's hot
(20)
Dockerからcontainerdへの移行
Dockerからcontainerdへの移行
ドメイン駆動設計サンプルコードの徹底解説
ドメイン駆動設計サンプルコードの徹底解説
マイクロサービス 4つの分割アプローチ
マイクロサービス 4つの分割アプローチ
なぜ、いま リレーショナルモデルなのか(理論から学ぶデータベース実践入門読書会スペシャル)
なぜ、いま リレーショナルモデルなのか(理論から学ぶデータベース実践入門読書会スペシャル)
ドメインオブジェクトの見つけ方・作り方・育て方
ドメインオブジェクトの見つけ方・作り方・育て方
境界付けられたコンテキスト 概念編 (ドメイン駆動設計用語解説シリーズ)
境界付けられたコンテキスト 概念編 (ドメイン駆動設計用語解説シリーズ)
DDD x CQRS 更新系と参照系で異なるORMを併用して上手くいった話
DDD x CQRS 更新系と参照系で異なるORMを併用して上手くいった話
PostgreSQLアンチパターン
PostgreSQLアンチパターン
例外設計における大罪
例外設計における大罪
Goのサーバサイド実装におけるレイヤ設計とレイヤ内実装について考える
Goのサーバサイド実装におけるレイヤ設計とレイヤ内実装について考える
45分間で「ユーザー中心のものづくり」ができるまで詰め込む
45分間で「ユーザー中心のものづくり」ができるまで詰め込む
オブジェクト指向エクササイズのススメ
オブジェクト指向エクササイズのススメ
Apache Avro vs Protocol Buffers
Apache Avro vs Protocol Buffers
イベント・ソーシングを知る
イベント・ソーシングを知る
ドメイン駆動で開発する ラフスケッチから実装まで
ドメイン駆動で開発する ラフスケッチから実装まで
ドメイン駆動設計 本格入門
ドメイン駆動設計 本格入門
Tackling Complexity
Tackling Complexity
オブジェクト指向プログラミングのためのモデリング入門
オブジェクト指向プログラミングのためのモデリング入門
やはりお前らのMVCは間違っている
やはりお前らのMVCは間違っている
ツール比較しながら語る O/RマッパーとDBマイグレーションの実際のところ
ツール比較しながら語る O/RマッパーとDBマイグレーションの実際のところ
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
片手間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
(10)
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
データモデルは時空を越える
データモデルは時空を越える
良いコードとは
良いコードとは
エスイーが要件定義でやるべきたったひとつのこと
エスイーが要件定義でやるべきたったひとつのこと
片手間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
システムダウンのひみつ
システムダウンのひみつ
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
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