SlideShare uma empresa Scribd logo
1 de 24
Baixar para ler offline
イミュータブル データモデル (入門編) 
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レッスン』

Mais conteúdo relacionado

Mais procurados

それはYAGNIか? それとも思考停止か?
それはYAGNIか? それとも思考停止か?それはYAGNIか? それとも思考停止か?
それはYAGNIか? それとも思考停止か?Yoshitaka Kawashima
 
DDD x CQRS 更新系と参照系で異なるORMを併用して上手くいった話
DDD x CQRS   更新系と参照系で異なるORMを併用して上手くいった話DDD x CQRS   更新系と参照系で異なるORMを併用して上手くいった話
DDD x CQRS 更新系と参照系で異なるORMを併用して上手くいった話Koichiro Matsuoka
 
ドメイン駆動設計サンプルコードの徹底解説
ドメイン駆動設計サンプルコードの徹底解説ドメイン駆動設計サンプルコードの徹底解説
ドメイン駆動設計サンプルコードの徹底解説増田 亨
 
データベース設計徹底指南
データベース設計徹底指南データベース設計徹底指南
データベース設計徹底指南Mikiya Okuno
 
ドメイン駆動設計のための Spring の上手な使い方
ドメイン駆動設計のための Spring の上手な使い方ドメイン駆動設計のための Spring の上手な使い方
ドメイン駆動設計のための Spring の上手な使い方増田 亨
 
本当は恐ろしい分散システムの話
本当は恐ろしい分散システムの話本当は恐ろしい分散システムの話
本当は恐ろしい分散システムの話Kumazaki Hiroki
 
ドメインオブジェクトの見つけ方・作り方・育て方
ドメインオブジェクトの見つけ方・作り方・育て方ドメインオブジェクトの見つけ方・作り方・育て方
ドメインオブジェクトの見つけ方・作り方・育て方増田 亨
 
世界一わかりやすいClean Architecture
世界一わかりやすいClean Architecture世界一わかりやすいClean Architecture
世界一わかりやすいClean ArchitectureAtsushi Nakamura
 
Where狙いのキー、order by狙いのキー
Where狙いのキー、order by狙いのキーWhere狙いのキー、order by狙いのキー
Where狙いのキー、order by狙いのキーyoku0825
 
開発速度が速い #とは(LayerX社内資料)
開発速度が速い #とは(LayerX社内資料)開発速度が速い #とは(LayerX社内資料)
開発速度が速い #とは(LayerX社内資料)mosa siru
 
やはりお前らのMVCは間違っている
やはりお前らのMVCは間違っているやはりお前らのMVCは間違っている
やはりお前らのMVCは間違っているKoichi Tanaka
 
Redisの特徴と活用方法について
Redisの特徴と活用方法についてRedisの特徴と活用方法について
Redisの特徴と活用方法についてYuji Otani
 
世界でいちばんわかりやすいドメイン駆動設計
世界でいちばんわかりやすいドメイン駆動設計世界でいちばんわかりやすいドメイン駆動設計
世界でいちばんわかりやすいドメイン駆動設計増田 亨
 
今からでも遅くないDBマイグレーション - Flyway と SchemaSpy の紹介 -
今からでも遅くないDBマイグレーション - Flyway と SchemaSpy の紹介 -今からでも遅くないDBマイグレーション - Flyway と SchemaSpy の紹介 -
今からでも遅くないDBマイグレーション - Flyway と SchemaSpy の紹介 -onozaty
 
リッチなドメインモデル 名前探し
リッチなドメインモデル 名前探しリッチなドメインモデル 名前探し
リッチなドメインモデル 名前探し増田 亨
 
初心者向けMongoDBのキホン!
初心者向けMongoDBのキホン!初心者向けMongoDBのキホン!
初心者向けMongoDBのキホン!Tetsutaro Watanabe
 
ドメイン駆動設計のためのオブジェクト指向入門
ドメイン駆動設計のためのオブジェクト指向入門ドメイン駆動設計のためのオブジェクト指向入門
ドメイン駆動設計のためのオブジェクト指向入門増田 亨
 
ソーシャルゲームのためのデータベース設計
ソーシャルゲームのためのデータベース設計ソーシャルゲームのためのデータベース設計
ソーシャルゲームのためのデータベース設計Yoshinori Matsunobu
 

Mais procurados (20)

それはYAGNIか? それとも思考停止か?
それはYAGNIか? それとも思考停止か?それはYAGNIか? それとも思考停止か?
それはYAGNIか? それとも思考停止か?
 
Tackling Complexity
Tackling ComplexityTackling Complexity
Tackling Complexity
 
DDD x CQRS 更新系と参照系で異なるORMを併用して上手くいった話
DDD x CQRS   更新系と参照系で異なるORMを併用して上手くいった話DDD x CQRS   更新系と参照系で異なるORMを併用して上手くいった話
DDD x CQRS 更新系と参照系で異なるORMを併用して上手くいった話
 
ドメイン駆動設計サンプルコードの徹底解説
ドメイン駆動設計サンプルコードの徹底解説ドメイン駆動設計サンプルコードの徹底解説
ドメイン駆動設計サンプルコードの徹底解説
 
データベース設計徹底指南
データベース設計徹底指南データベース設計徹底指南
データベース設計徹底指南
 
ドメイン駆動設計のための Spring の上手な使い方
ドメイン駆動設計のための Spring の上手な使い方ドメイン駆動設計のための Spring の上手な使い方
ドメイン駆動設計のための Spring の上手な使い方
 
本当は恐ろしい分散システムの話
本当は恐ろしい分散システムの話本当は恐ろしい分散システムの話
本当は恐ろしい分散システムの話
 
ドメインオブジェクトの見つけ方・作り方・育て方
ドメインオブジェクトの見つけ方・作り方・育て方ドメインオブジェクトの見つけ方・作り方・育て方
ドメインオブジェクトの見つけ方・作り方・育て方
 
世界一わかりやすいClean Architecture
世界一わかりやすいClean Architecture世界一わかりやすいClean Architecture
世界一わかりやすいClean Architecture
 
Where狙いのキー、order by狙いのキー
Where狙いのキー、order by狙いのキーWhere狙いのキー、order by狙いのキー
Where狙いのキー、order by狙いのキー
 
開発速度が速い #とは(LayerX社内資料)
開発速度が速い #とは(LayerX社内資料)開発速度が速い #とは(LayerX社内資料)
開発速度が速い #とは(LayerX社内資料)
 
やはりお前らのMVCは間違っている
やはりお前らのMVCは間違っているやはりお前らのMVCは間違っている
やはりお前らのMVCは間違っている
 
Redisの特徴と活用方法について
Redisの特徴と活用方法についてRedisの特徴と活用方法について
Redisの特徴と活用方法について
 
世界でいちばんわかりやすいドメイン駆動設計
世界でいちばんわかりやすいドメイン駆動設計世界でいちばんわかりやすいドメイン駆動設計
世界でいちばんわかりやすいドメイン駆動設計
 
今からでも遅くないDBマイグレーション - Flyway と SchemaSpy の紹介 -
今からでも遅くないDBマイグレーション - Flyway と SchemaSpy の紹介 -今からでも遅くないDBマイグレーション - Flyway と SchemaSpy の紹介 -
今からでも遅くないDBマイグレーション - Flyway と SchemaSpy の紹介 -
 
リッチなドメインモデル 名前探し
リッチなドメインモデル 名前探しリッチなドメインモデル 名前探し
リッチなドメインモデル 名前探し
 
Hadoop入門
Hadoop入門Hadoop入門
Hadoop入門
 
初心者向けMongoDBのキホン!
初心者向けMongoDBのキホン!初心者向けMongoDBのキホン!
初心者向けMongoDBのキホン!
 
ドメイン駆動設計のためのオブジェクト指向入門
ドメイン駆動設計のためのオブジェクト指向入門ドメイン駆動設計のためのオブジェクト指向入門
ドメイン駆動設計のためのオブジェクト指向入門
 
ソーシャルゲームのためのデータベース設計
ソーシャルゲームのためのデータベース設計ソーシャルゲームのためのデータベース設計
ソーシャルゲームのためのデータベース設計
 

Destaque

MySQLで論理削除と正しく付き合う方法
MySQLで論理削除と正しく付き合う方法MySQLで論理削除と正しく付き合う方法
MySQLで論理削除と正しく付き合う方法yoku0825
 
[AKIBA.AWS] EC2の基礎 - パフォーマンスを100%引き出すオプション設定 -
[AKIBA.AWS] EC2の基礎 - パフォーマンスを100%引き出すオプション設定 -[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.4Dependency injection in PHP 5.3/5.4
Dependency injection in PHP 5.3/5.4Fabien Potencier
 
データモデルは時空を越える
データモデルは時空を越えるデータモデルは時空を越える
データモデルは時空を越えるterahide
 
エスイーが要件定義でやるべきたったひとつのこと
エスイーが要件定義でやるべきたったひとつのことエスイーが要件定義でやるべきたったひとつのこと
エスイーが要件定義でやるべきたったひとつのことYoshitaka Kawashima
 
Goのサーバサイド実装におけるレイヤ設計とレイヤ内実装について考える
Goのサーバサイド実装におけるレイヤ設計とレイヤ内実装について考えるGoのサーバサイド実装におけるレイヤ設計とレイヤ内実装について考える
Goのサーバサイド実装におけるレイヤ設計とレイヤ内実装について考えるpospome
 
片手間MySQLチューニング戦略
片手間MySQLチューニング戦略片手間MySQLチューニング戦略
片手間MySQLチューニング戦略yoku0825
 
If文から機械学習への道
If文から機械学習への道If文から機械学習への道
If文から機械学習への道nishio
 
データ履歴管理のためのテンポラルデータモデルとReladomoの紹介 #jjug_ccc #ccc_g3
データ履歴管理のためのテンポラルデータモデルとReladomoの紹介 #jjug_ccc #ccc_g3 データ履歴管理のためのテンポラルデータモデルとReladomoの紹介 #jjug_ccc #ccc_g3
データ履歴管理のためのテンポラルデータモデルとReladomoの紹介 #jjug_ccc #ccc_g3 Hiroshi Ito
 
Spring Bootの本当の理解ポイント #jjug
Spring Bootの本当の理解ポイント #jjugSpring Bootの本当の理解ポイント #jjug
Spring Bootの本当の理解ポイント #jjugMasatoshi Tada
 

Destaque (11)

MySQLで論理削除と正しく付き合う方法
MySQLで論理削除と正しく付き合う方法MySQLで論理削除と正しく付き合う方法
MySQLで論理削除と正しく付き合う方法
 
[AKIBA.AWS] EC2の基礎 - パフォーマンスを100%引き出すオプション設定 -
[AKIBA.AWS] EC2の基礎 - パフォーマンスを100%引き出すオプション設定 -[AKIBA.AWS] EC2の基礎 - パフォーマンスを100%引き出すオプション設定 -
[AKIBA.AWS] EC2の基礎 - パフォーマンスを100%引き出すオプション設定 -
 
Dependency injection in PHP 5.3/5.4
Dependency injection in PHP 5.3/5.4Dependency injection in PHP 5.3/5.4
Dependency injection in PHP 5.3/5.4
 
データモデルは時空を越える
データモデルは時空を越えるデータモデルは時空を越える
データモデルは時空を越える
 
良いコードとは
良いコードとは良いコードとは
良いコードとは
 
エスイーが要件定義でやるべきたったひとつのこと
エスイーが要件定義でやるべきたったひとつのことエスイーが要件定義でやるべきたったひとつのこと
エスイーが要件定義でやるべきたったひとつのこと
 
Goのサーバサイド実装におけるレイヤ設計とレイヤ内実装について考える
Goのサーバサイド実装におけるレイヤ設計とレイヤ内実装について考えるGoのサーバサイド実装におけるレイヤ設計とレイヤ内実装について考える
Goのサーバサイド実装におけるレイヤ設計とレイヤ内実装について考える
 
片手間MySQLチューニング戦略
片手間MySQLチューニング戦略片手間MySQLチューニング戦略
片手間MySQLチューニング戦略
 
If文から機械学習への道
If文から機械学習への道If文から機械学習への道
If文から機械学習への道
 
データ履歴管理のためのテンポラルデータモデルとReladomoの紹介 #jjug_ccc #ccc_g3
データ履歴管理のためのテンポラルデータモデルとReladomoの紹介 #jjug_ccc #ccc_g3 データ履歴管理のためのテンポラルデータモデルとReladomoの紹介 #jjug_ccc #ccc_g3
データ履歴管理のためのテンポラルデータモデルとReladomoの紹介 #jjug_ccc #ccc_g3
 
Spring Bootの本当の理解ポイント #jjug
Spring Bootの本当の理解ポイント #jjugSpring Bootの本当の理解ポイント #jjug
Spring Bootの本当の理解ポイント #jjug
 

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

OpenSpan_PreMarketing_Reference
OpenSpan_PreMarketing_ReferenceOpenSpan_PreMarketing_Reference
OpenSpan_PreMarketing_Referencemotani_kamakura
 
IDC 電子ブック 『マイクロソフト モダン パートナー シリーズ 2016』パート 4: 業務の最適化
IDC 電子ブック 『マイクロソフト モダン パートナー シリーズ 2016』パート 4: 業務の最適化IDC 電子ブック 『マイクロソフト モダン パートナー シリーズ 2016』パート 4: 業務の最適化
IDC 電子ブック 『マイクロソフト モダン パートナー シリーズ 2016』パート 4: 業務の最適化MPN Japan
 
経営情報フォーラム2009発表資料
経営情報フォーラム2009発表資料経営情報フォーラム2009発表資料
経営情報フォーラム2009発表資料Keiichi Hashimoto
 
経営情報フォーラム2009
経営情報フォーラム2009経営情報フォーラム2009
経営情報フォーラム2009guest5ad17cf
 
非開発者のためのアジャイル開発入門
非開発者のためのアジャイル開発入門非開発者のためのアジャイル開発入門
非開発者のためのアジャイル開発入門Kiro Harada
 
Asahikawa_Ict 20120726
Asahikawa_Ict 20120726Asahikawa_Ict 20120726
Asahikawa_Ict 20120726kspro
 
Salesforce crm over_view_2012_0301
Salesforce crm over_view_2012_0301Salesforce crm over_view_2012_0301
Salesforce crm over_view_2012_0301Kohei Nishikawa
 
Microsoft 365 で NoOps を考える
Microsoft 365 で NoOps を考えるMicrosoft 365 で NoOps を考える
Microsoft 365 で NoOps を考える祥子 松山
 
MySQLで学ぶ機械学習ことはじめ.pdf
MySQLで学ぶ機械学習ことはじめ.pdfMySQLで学ぶ機械学習ことはじめ.pdf
MySQLで学ぶ機械学習ことはじめ.pdfMachiko Ikoma
 
[B23] 事例で語る、社会インフラを支えるNonStop SQL ~見えないところで凄いんです~by Tetsuya Shinohara
[B23] 事例で語る、社会インフラを支えるNonStop SQL ~見えないところで凄いんです~by Tetsuya Shinohara[B23] 事例で語る、社会インフラを支えるNonStop SQL ~見えないところで凄いんです~by Tetsuya Shinohara
[B23] 事例で語る、社会インフラを支えるNonStop SQL ~見えないところで凄いんです~by Tetsuya ShinoharaInsight Technology, Inc.
 
アジャイルにモデリングは必要か
アジャイルにモデリングは必要かアジャイルにモデリングは必要か
アジャイルにモデリングは必要かHiromasa Oka
 
Share Point Online 会社のデータしっかり管理のススメ
Share Point Online 会社のデータしっかり管理のススメShare Point Online 会社のデータしっかり管理のススメ
Share Point Online 会社のデータしっかり管理のススメkumo2010
 
大規模データに対するデータサイエンスの進め方 #CWT2016
大規模データに対するデータサイエンスの進め方 #CWT2016大規模データに対するデータサイエンスの進め方 #CWT2016
大規模データに対するデータサイエンスの進め方 #CWT2016Cloudera Japan
 
enterprise social network sales use case ja
enterprise social network sales use case jaenterprise social network sales use case ja
enterprise social network sales use case jaBroadVision
 
第11回SIA例会プレゼン資料
第11回SIA例会プレゼン資料第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 技術概要Tech Ed 2009 Japan T3-309 Microsoft Business Productivity Online Services 技術概要
Tech Ed 2009 Japan T3-309 Microsoft Business Productivity Online Services 技術概要kumo2010
 

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

OpenSpan_PreMarketing_Reference
OpenSpan_PreMarketing_ReferenceOpenSpan_PreMarketing_Reference
OpenSpan_PreMarketing_Reference
 
IDC 電子ブック 『マイクロソフト モダン パートナー シリーズ 2016』パート 4: 業務の最適化
IDC 電子ブック 『マイクロソフト モダン パートナー シリーズ 2016』パート 4: 業務の最適化IDC 電子ブック 『マイクロソフト モダン パートナー シリーズ 2016』パート 4: 業務の最適化
IDC 電子ブック 『マイクロソフト モダン パートナー シリーズ 2016』パート 4: 業務の最適化
 
経営情報フォーラム2009発表資料
経営情報フォーラム2009発表資料経営情報フォーラム2009発表資料
経営情報フォーラム2009発表資料
 
経営情報フォーラム2009
経営情報フォーラム2009経営情報フォーラム2009
経営情報フォーラム2009
 
非開発者のためのアジャイル開発入門
非開発者のためのアジャイル開発入門非開発者のためのアジャイル開発入門
非開発者のためのアジャイル開発入門
 
X_顧客事例
X_顧客事例X_顧客事例
X_顧客事例
 
Asahikawa_Ict 20120726
Asahikawa_Ict 20120726Asahikawa_Ict 20120726
Asahikawa_Ict 20120726
 
Salesforce crm over_view_2012_0301
Salesforce crm over_view_2012_0301Salesforce crm over_view_2012_0301
Salesforce crm over_view_2012_0301
 
Microsoft 365 で NoOps を考える
Microsoft 365 で NoOps を考えるMicrosoft 365 で NoOps を考える
Microsoft 365 で NoOps を考える
 
MySQLで学ぶ機械学習ことはじめ.pdf
MySQLで学ぶ機械学習ことはじめ.pdfMySQLで学ぶ機械学習ことはじめ.pdf
MySQLで学ぶ機械学習ことはじめ.pdf
 
Process base
Process baseProcess base
Process base
 
[B23] 事例で語る、社会インフラを支えるNonStop SQL ~見えないところで凄いんです~by Tetsuya Shinohara
[B23] 事例で語る、社会インフラを支えるNonStop SQL ~見えないところで凄いんです~by Tetsuya Shinohara[B23] 事例で語る、社会インフラを支えるNonStop SQL ~見えないところで凄いんです~by Tetsuya Shinohara
[B23] 事例で語る、社会インフラを支えるNonStop SQL ~見えないところで凄いんです~by Tetsuya Shinohara
 
アジャイルにモデリングは必要か
アジャイルにモデリングは必要かアジャイルにモデリングは必要か
アジャイルにモデリングは必要か
 
Share Point Online 会社のデータしっかり管理のススメ
Share Point Online 会社のデータしっかり管理のススメShare Point Online 会社のデータしっかり管理のススメ
Share Point Online 会社のデータしっかり管理のススメ
 
20111212勉強会資料
20111212勉強会資料20111212勉強会資料
20111212勉強会資料
 
大規模データに対するデータサイエンスの進め方 #CWT2016
大規模データに対するデータサイエンスの進め方 #CWT2016大規模データに対するデータサイエンスの進め方 #CWT2016
大規模データに対するデータサイエンスの進め方 #CWT2016
 
enterprise social network sales use case ja
enterprise social network sales use case jaenterprise social network sales use case ja
enterprise social network sales use case ja
 
Citrix eco new
Citrix eco newCitrix eco new
Citrix eco new
 
第11回SIA例会プレゼン資料
第11回SIA例会プレゼン資料第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 技術概要Tech Ed 2009 Japan T3-309 Microsoft Business Productivity Online Services 技術概要
Tech Ed 2009 Japan T3-309 Microsoft Business Productivity Online Services 技術概要
 

Mais de Yoshitaka Kawashima

ブルックスのいう銀の弾丸とは何か?
ブルックスのいう銀の弾丸とは何か?ブルックスのいう銀の弾丸とは何か?
ブルックスのいう銀の弾丸とは何か?Yoshitaka Kawashima
 
強いて言えば「集約どう実装するのかな、を考える」な話
強いて言えば「集約どう実装するのかな、を考える」な話強いて言えば「集約どう実装するのかな、を考える」な話
強いて言えば「集約どう実装するのかな、を考える」な話Yoshitaka Kawashima
 
ソフトウェアにおける 複雑さとは何なのか?
ソフトウェアにおける 複雑さとは何なのか?ソフトウェアにおける 複雑さとは何なのか?
ソフトウェアにおける 複雑さとは何なのか?Yoshitaka Kawashima
 
ソフトウェア開発における『知の高速道路』
ソフトウェア開発における『知の高速道路』ソフトウェア開発における『知の高速道路』
ソフトウェア開発における『知の高速道路』Yoshitaka Kawashima
 
ソフトウェア設計における 意思決定とそのレビューの秘訣
ソフトウェア設計における 意思決定とそのレビューの秘訣ソフトウェア設計における 意思決定とそのレビューの秘訣
ソフトウェア設計における 意思決定とそのレビューの秘訣Yoshitaka Kawashima
 
システムダウンのひみつ
システムダウンのひみつシステムダウンのひみつ
システムダウンのひみつYoshitaka Kawashima
 
アンチフラジャイルの世界
アンチフラジャイルの世界アンチフラジャイルの世界
アンチフラジャイルの世界Yoshitaka Kawashima
 
思考停止しないアーキテクチャ設計 ➖ JJUG CCC 2018 Fall
思考停止しないアーキテクチャ設計 ➖ JJUG CCC 2018 Fall思考停止しないアーキテクチャ設計 ➖ JJUG CCC 2018 Fall
思考停止しないアーキテクチャ設計 ➖ JJUG CCC 2018 FallYoshitaka Kawashima
 
ウォーターフォールとアジャイルのフェアな比較
ウォーターフォールとアジャイルのフェアな比較ウォーターフォールとアジャイルのフェアな比較
ウォーターフォールとアジャイルのフェアな比較Yoshitaka Kawashima
 
Antifragile Java - Java Day Tokyo 2017 D1-E1
Antifragile Java - Java Day Tokyo 2017 D1-E1Antifragile Java - Java Day Tokyo 2017 D1-E1
Antifragile Java - Java Day Tokyo 2017 D1-E1Yoshitaka Kawashima
 
たとえ日本人同士でも必要な異文化理解力
たとえ日本人同士でも必要な異文化理解力たとえ日本人同士でも必要な異文化理解力
たとえ日本人同士でも必要な異文化理解力Yoshitaka Kawashima
 
SIerにとっての越境 @ DevLOVE 199
SIerにとっての越境 @ DevLOVE 199SIerにとっての越境 @ DevLOVE 199
SIerにとっての越境 @ DevLOVE 199Yoshitaka Kawashima
 
なぜデータモデリングが重要なのか?
なぜデータモデリングが重要なのか?なぜデータモデリングが重要なのか?
なぜデータモデリングが重要なのか?Yoshitaka Kawashima
 

Mais de Yoshitaka Kawashima (20)

ブルックスのいう銀の弾丸とは何か?
ブルックスのいう銀の弾丸とは何か?ブルックスのいう銀の弾丸とは何か?
ブルックスのいう銀の弾丸とは何か?
 
Are Design Patterns Dead?
Are Design Patterns Dead?Are Design Patterns Dead?
Are Design Patterns Dead?
 
強いて言えば「集約どう実装するのかな、を考える」な話
強いて言えば「集約どう実装するのかな、を考える」な話強いて言えば「集約どう実装するのかな、を考える」な話
強いて言えば「集約どう実装するのかな、を考える」な話
 
ソフトウェアにおける 複雑さとは何なのか?
ソフトウェアにおける 複雑さとは何なのか?ソフトウェアにおける 複雑さとは何なのか?
ソフトウェアにおける 複雑さとは何なのか?
 
ソフトウェア開発における『知の高速道路』
ソフトウェア開発における『知の高速道路』ソフトウェア開発における『知の高速道路』
ソフトウェア開発における『知の高速道路』
 
ソフトウェア設計における 意思決定とそのレビューの秘訣
ソフトウェア設計における 意思決定とそのレビューの秘訣ソフトウェア設計における 意思決定とそのレビューの秘訣
ソフトウェア設計における 意思決定とそのレビューの秘訣
 
本番障害に至る病
本番障害に至る病本番障害に至る病
本番障害に至る病
 
システムダウンのひみつ
システムダウンのひみつシステムダウンのひみつ
システムダウンのひみつ
 
Mavenの真実とウソ
Mavenの真実とウソMavenの真実とウソ
Mavenの真実とウソ
 
アンチフラジャイルの世界
アンチフラジャイルの世界アンチフラジャイルの世界
アンチフラジャイルの世界
 
Atomic Architecture
Atomic ArchitectureAtomic Architecture
Atomic Architecture
 
思考停止しないアーキテクチャ設計 ➖ JJUG CCC 2018 Fall
思考停止しないアーキテクチャ設計 ➖ JJUG CCC 2018 Fall思考停止しないアーキテクチャ設計 ➖ JJUG CCC 2018 Fall
思考停止しないアーキテクチャ設計 ➖ JJUG CCC 2018 Fall
 
ウォーターフォールとアジャイルのフェアな比較
ウォーターフォールとアジャイルのフェアな比較ウォーターフォールとアジャイルのフェアな比較
ウォーターフォールとアジャイルのフェアな比較
 
How to find tech books
How to find tech booksHow to find tech books
How to find tech books
 
Antifragile Java - Java Day Tokyo 2017 D1-E1
Antifragile Java - Java Day Tokyo 2017 D1-E1Antifragile Java - Java Day Tokyo 2017 D1-E1
Antifragile Java - Java Day Tokyo 2017 D1-E1
 
たとえ日本人同士でも必要な異文化理解力
たとえ日本人同士でも必要な異文化理解力たとえ日本人同士でも必要な異文化理解力
たとえ日本人同士でも必要な異文化理解力
 
SIerにとっての越境 @ DevLOVE 199
SIerにとっての越境 @ DevLOVE 199SIerにとっての越境 @ DevLOVE 199
SIerにとっての越境 @ DevLOVE 199
 
なぜデータモデリングが重要なのか?
なぜデータモデリングが重要なのか?なぜデータモデリングが重要なのか?
なぜデータモデリングが重要なのか?
 
Antifragile Clojure
Antifragile ClojureAntifragile Clojure
Antifragile Clojure
 
Boilerplate vs Magic
Boilerplate vs MagicBoilerplate vs Magic
Boilerplate vs Magic
 

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