Download presentation
Presentation is loading. Please wait.
1
1 Seasar Conference 2006 Spring © The Seasar Foundation and the others 2006. all rights reserved. EJB3 時代の ERD レッスン ～ Activity Based Datamodel 2006.05.14 The Seasar Foundation 株式会社スターロジック 羽生 章洋
2
2 Seasar Conference 2006 Spring © The Seasar Foundation and the others 2006. all rights reserved. 自己紹介 羽生 章洋（はぶ あきひろ）と申します。 – 昭和 43 年生まれの今年 38 歳です。 – 受託電算業務の伝票打ちから始まりました。 – プログラマ～システムエンジニアを経てコンサルタント をやってきました。 – 様々な業種・業務に関わってきました。 – 今はスターロジックという会社の経営をやっています。 –Seasar ファウンデーションの理事もやっています。 今日のお話にご興味を持たれた方は、お気軽にご 連絡くださいませ。 –http://www.starlogic.jp/ –habu@starlogic.jp –http://d.hatena.ne.jp/habuakihiro/ （はぶにっき）
3
3 Seasar Conference 2006 Spring © The Seasar Foundation and the others 2006. all rights reserved. とっても大事な DB 設計 DB 設計とは何か？ – プログラムが終了したときに消えちゃうと困 るデータをどのように保存しておくか決める 作業のこと 何故 DB 設計が重要なのか？ 超グローバル変数 – アプリケーション（場合によってはシステム も）をまたがる 「 超グローバル変数 」だから！
4
4 Seasar Conference 2006 Spring © The Seasar Foundation and the others 2006. all rights reserved. 所詮は DB 設計 器だけあってもさ … – プログラムがなければ何もできないよ –SQL だってプログラムのひとつ データモデル＝ビジネスモデリング？ – 上流？ ちゃんちゃらおかしくって。 – 事業計画書にデータモデルが書いてるのなん て見たことがない。 業務プロセス – ゼロから会社作るとわかる。 先に 業務プロセス ありき！
5
5 Seasar Conference 2006 Spring © The Seasar Foundation and the others 2006. all rights reserved. だけどやっぱり DB 設計 じゃあ DB がなけれ ばどうなるの？ じゃあ DB がなけれ ばどうなるの？ あったとしても、 でたらめな設計だっ たら？ あったとしても、 でたらめな設計だっ たら？
6
6 Seasar Conference 2006 Spring © The Seasar Foundation and the others 2006. all rights reserved. DB って何なのさ そもそも DB って何？ データって何？ – 結果の記録を一箇所に集めたもの （レコードとはよく言ったもので） – 予定データとか計画データとかあるじゃん ・・・それって、 「予定を立てた」結果でしょ 「計画を立てた」結果でしょ 記録って何？ 結果って何？ – 何かを行ったから結果が生じる – 結果を忘れないために記録をする
7
7 Seasar Conference 2006 Spring © The Seasar Foundation and the others 2006. all rights reserved. 業務とシステムの関係 １．注文があると・・・ ２．商品を準備して・・・ ３．商品をお届けします お客様 はぶ商店
8
8 Seasar Conference 2006 Spring © The Seasar Foundation and the others 2006. all rights reserved. 注文がどんどん増えてきた！ １．注文があると・・・ ２．注文を受け付けて・・・ ４．商品をお届けします お客様 はぶ商店 ３．商品を準備して・・・ これを出 荷してね ♪ 注文の内容 を忘れると まずいので メモしてお く
9
9 Seasar Conference 2006 Spring © The Seasar Foundation and the others 2006. all rights reserved. さらに注文が増えてきた！！ １．注文があると・・・ ２．注文を受け付けて・・・ ５．商品をお届けします お客様 はぶ商店 ３．商品を箱詰めして・・・ これを出 荷してね ♪ 注文の内容 を忘れると まずいので メモしてお く 荷物でき たよ ♪ ４．運送屋に依頼して・・・ 配送依頼の 控えを保管 しておく
10
10 Seasar Conference 2006 Spring © The Seasar Foundation and the others 2006. all rights reserved. トラブル続出！ １．注文があると・・・ お客様 はぶ商店 注文したのが届かない！ 違うものが届けられた！ ちゃんと 出荷した の？ 配送っていつ 依頼したの？ そもそも注文 どうなってる の？ 箱詰めしたの あってるの？
11
11 Seasar Conference 2006 Spring © The Seasar Foundation and the others 2006. all rights reserved. 口頭をやめよう！ お客様 はぶ商店 受注記録 梱包記録 梱包依頼 出荷記録 出荷依頼
12
12 Seasar Conference 2006 Spring © The Seasar Foundation and the others 2006. all rights reserved. 紙が溢れて大変！⇒ IT 化！ お客様 はぶ商店 ビジネスプロセス
13
13 Seasar Conference 2006 Spring © The Seasar Foundation and the others 2006. all rights reserved. 改めてよく見てみると・・・ 保存するデータには 2 種類ある – 行為の記録 受注記録 梱包記録 出荷記録 – 行為の際の参照用 梱包依頼：梱包作業の際に参照する 出荷依頼：配送作業の際に参照する
14
14 Seasar Conference 2006 Spring © The Seasar Foundation and the others 2006. all rights reserved. さらに参照用には別のものが 受注記録について・・・ – 誰からの注文？： 顧客情報 – 何を注文された？： 商品情報 ⇒ 俗に言う「マスタ系」というもの お客様からの注文 顧客 情報 商品 情報 受注 記録
15
15 Seasar Conference 2006 Spring © The Seasar Foundation and the others 2006. all rights reserved. プロセス間の参照 受注記録を梱包時に参照する お客様からの注文 顧客 情報 商品 情報 受注 記録 梱包 記録 梱包がまだのもの 実はフラグ だったり・・・ 受注とい う「業 務」 梱包とい う「業 務」
16
16 Seasar Conference 2006 Spring © The Seasar Foundation and the others 2006. all rights reserved. DLC あるいは CRUD ということ 顧客情報の保守も業務のひとつ 顧客 情報 誰が記 録する の？ 何を元 に記録 する の？ いつ記 録する の？ データライフサイクル Create, Reference, Update, Drop
17
17 Seasar Conference 2006 Spring © The Seasar Foundation and the others 2006. all rights reserved. モデルに溺れない！ DB は所詮システムの一部 ユーザにとって大切なのは UI ！
18
18 Seasar Conference 2006 Spring © The Seasar Foundation and the others 2006. all rights reserved. UI も業務フローの一部 UI の操作にもシナリオがある シナリオに沿った動きが必要 動きの「結果」が DB に入る 顧客 情報 商品 情報 受注 記録 お客様からの注文 受注業務 受注画面 R R C
19
19 Seasar Conference 2006 Spring © The Seasar Foundation and the others 2006. all rights reserved. UI も業務フローの一部 (2) 業務の流れに沿って、前工程の結果を参照す ることもある 受注 記録 受注 記録 あるタイミングで・・・ 梱包業務 梱包結果 登録画面 R U 梱包 記録 C
20
20 Seasar Conference 2006 Spring © The Seasar Foundation and the others 2006. all rights reserved. テーブルの見分け方 業務と対になるのが「イベント系」 – 行為の記録 それ以外は「リソース系」（入力支援系ともいえるかも） イベントは – 「ｘｘする」といえる。「ｘｘ日」といえる – 受注する、受注日＝ OK – 顧客する、顧客日＝ NG リソースは – 「ｘｘ名」といえる。 – 顧客名＝ OK – 受注名＝ NG （案件名ならわかるけどさ⇒「案件」というリソース） 「ｘｘする」「ｘｘ名」両方いえないと？ – それは属性 – 「数量する」「数量名」＝ NG 乱暴にいうと 「ｘｘ別」という風 に 集計したくなるのは リソース系 「案件」を「受注」する、だよね。
21
21 Seasar Conference 2006 Spring © The Seasar Foundation and the others 2006. all rights reserved. UI はアウトプットから攻める！ 業務フローの後ろから順番に攻める！ – 実は業務フローそのものもゴールからさかのぼっ て作成するほうが良い 帳票から順番に攻める！ ① 出力に必要な 項目が DB にないと駄目！ ② 出力に必要な 項目を埋めないと駄目！
22
22 Seasar Conference 2006 Spring © The Seasar Foundation and the others 2006. all rights reserved. 楽々 ERD レッスンのポイント ・・・と、ここまでの話を踏まえて IDID の導入 業務の視点に基づく正規化 イベント系 イベント系 エンティティ こそが重要 交差エンティティ イベント系とは 交差エンティティ である
23
23 Seasar Conference 2006 Spring © The Seasar Foundation and the others 2006. all rights reserved. 交差エンティティとビジネスモデル イベント系だと・・・ 交差エンティティも ID 必須！ – 交差エンティティを参照するものもある 例えば、出会い系の例とか・・・
24
24 Seasar Conference 2006 Spring © The Seasar Foundation and the others 2006. all rights reserved. １： Codd のリレーショナルモデル A B C ポチ タマ ペロ \300 \90 ♀ ♂ 商品コード 商品名 単価 性別 Table （ Relation) Column （ Domain) 値の重複は存在しない！
25
25 Seasar Conference 2006 Spring © The Seasar Foundation and the others 2006. all rights reserved. １： Codd のリレーショナルモデル A ポチ \300 ♂ 商品コード 商品名 単価 性別 B タマ \300 ♀ C ペロ \90 ♂ 敢えて言えば Class （ Tuple ： Domain の 組み合わせ ) Instance （ Record)
26
26 Seasar Conference 2006 Spring © The Seasar Foundation and the others 2006. all rights reserved. １： Codd のリレーショナルモデル A ポチ \300 ♂ B タマ \300 ♀ C ペロ \90 ♂ ID を主キーにするというのは・・・ Instance に連番を 振るということ！ １ 2 3
27
27 Seasar Conference 2006 Spring © The Seasar Foundation and the others 2006. all rights reserved. １： Codd のリレーショナルモデル 商品コード 商品名 単価 性別 1. 各 Domain は集合である。 2.Table も Record の集合である。 3. では、 Domain も Table であるとすれば！？ RDB の R は Relationship(FK) の ことではない！ One Fact “IN” One Place
28
28 Seasar Conference 2006 Spring © The Seasar Foundation and the others 2006. all rights reserved. ２： Chen の ER モデル Codd さんは図表現には反対だった そこに出てきたのが、 Chen の ER モデル ER モデルとは 「世の中に存在するあらゆるものは、 具象的なものであれ抽象的なものであれ、 実体と関連という 2 つの概念で表現可能である」 という考え方 実体 （ Entity ） 関連 （ Relationship ） 実体 （ Entity ） 属性 （ Attribute ） 属性 （ Attribute ）
29
29 Seasar Conference 2006 Spring © The Seasar Foundation and the others 2006. all rights reserved. ２： Chen の ER モデル いつの間にか、関連が FK だけで表現される ようになってしまった だから、ｍ：ｍだけ特殊になってしまう。 実体 （ Entity ） 関連 （ Relationship ） 実体 （ Entity ） 実体 （ Entity ） 実体 （ Entity ） １：ｍ 実体 （ Entity ） 実体 （ Entity ） １：ｍ 実体 （ Entity ） ｍ：１ ｍ：ｍ
30
30 Seasar Conference 2006 Spring © The Seasar Foundation and the others 2006. all rights reserved. ２： Chen の ER モデル 抜け落ちた関連とは一体何か？ 顧客 販売 商品 よくある例：「顧客」と「商品」の間には「販売」という関係が成立する 顧客 販売商品 単なる１：ｍには決してしない。つまり・・・ 業務システムにおいて、単なる１：ｍの議論など本来はあり得ない！
31
31 Seasar Conference 2006 Spring © The Seasar Foundation and the others 2006. all rights reserved. ２： Chen の ER モデル ということは、よくある売上伝票も・・・ 本来はこうなるのでは？
32
32 Seasar Conference 2006 Spring © The Seasar Foundation and the others 2006. all rights reserved. １．と２．を改めて統合してみると・・・ ３：そして ABD FK のあり方が変わる！ つまり DB 設計の 難易度が変わる！
33
33 Seasar Conference 2006 Spring © The Seasar Foundation and the others 2006. all rights reserved. ３：そして ABD 商品企画生産計画資材購買製造営業出荷配送納品 売上 回収 ・・・ 業務プロセスとデータモデルの連携 活動（ Activity ）の 存在を示す 活動で発生した 事実（ Fact ）を 記録する
34
34 Seasar Conference 2006 Spring © The Seasar Foundation and the others 2006. all rights reserved. ABD 的 DB 設計とは 業務単位で行う –UI 最重要！ おしごとマジカ – 業務の洗い出しには「 おしごとマジカ 」を是 非！ Activity と Fact を分けて考える –Fact は UI に現れる 必要なテーブルをバラバラに定義する –FK で悩まない！ 「同じタイミング」で使うものを IRE （ Inter Relation Entity ）に対して、 FK 指定する イメージとしては、各テーブルがコンポーネント で、 IRE が設定ファイル（ DI をイメージする）
35
35 Seasar Conference 2006 Spring © The Seasar Foundation and the others 2006. all rights reserved. 必ず出てくる実装問題 実装が不便なのでは？ –SQL 書き方ドリルをまずはクリアしてね – 設計と実装のどちらのほうがスキルアップが簡 単か とはいえ面倒なのは嫌 そこで JPA
36
36 Seasar Conference 2006 Spring © The Seasar Foundation and the others 2006. all rights reserved. JPA と ABD JPA : Java Persistence API EJB3 の一番のセールスポイント 次世代の JDBC 的な位置づけと捉えられる 実は ABD と相性の良い JPA –@Id とか・・・ –@ManyToMany とか・・・ ABD の一番面倒な「リレーションシップの 解決」を自動的にやってくれる WEB+DB PRESS Vol.28 を参照
37
37 Seasar Conference 2006 Spring © The Seasar Foundation and the others 2006. all rights reserved. @Id アノテーション プライマリキーとなるフィールドを指定する。 generate 属性において、列挙子である TABLE,SEQUENCE,IDENTITY,AUTO,NONE から指定する。 次の例は RDBMS 上のシーケンスを使用する場合です。シーケンス名は SEQ_HOGE です。 @Entity @Table(name="t_hoge") public class Hoge implements Serializable { private Long id; @Id(generate=GeneratorType.SEQUENCE, generator="SEQ_HOGE") @Id(generate=GeneratorType.SEQUENCE, generator="SEQ_HOGE") public Long getId() { return id; } public setId(Long id) { this.id = id; }... }
38
38 Seasar Conference 2006 Spring © The Seasar Foundation and the others 2006. all rights reserved. @ManyToMany アノテーション テーブル間の多 : 多の関係を表す。 このアノテーションを使う場合は、組み合わせを管理するいわゆる交差エンティティとしてのテーブルが必要になる。 そのため登場するのはふたつのクラスだがテーブル自体は 3 つ必要になる。 次の例では、クラス名とテーブル名が一致している Employee,Task というふたつが記載されていますが、 更に EMPLOYEE_TASK という名前のテーブルも使用しています。 @Entity public class Employee implements Serializable {... @ManyToMany( targetEntity=Task.class, targetEntity=Task.class, cascade={CascadeType.CREATE, CascadeType.MERGE} cascade={CascadeType.CREATE, CascadeType.MERGE} ) @JoinTable( @JoinTable( table=@Table(name="EMPLOYEE_TASK"), table=@Table(name="EMPLOYEE_TASK"), joinColumns={@JoinColumn(name="EMPLOYEE_ID")}, joinColumns={@JoinColumn(name="EMPLOYEE_ID")}, inverseJoinColumns={@JoinColumn(name="TASK_ID")} inverseJoinColumns={@JoinColumn(name="TASK_ID")} ) public Collection getTasks() { return tasks; }... } @Entity public class Task implements Serializable {... @ManyToMany( cascade={CascadeType.CREATE, CascadeType.MERGE}, cascade={CascadeType.CREATE, CascadeType.MERGE}, mappedBy="employees" mappedBy="employees" targetEntity=Employee.class targetEntity=Employee.class ) public Collection getEmployees() { return employees; }... }
39
39 Seasar Conference 2006 Spring © The Seasar Foundation and the others 2006. all rights reserved. でも JPA ってさ・・・ 結局、 JPA の不自由さに振り回されるんじゃ ないの？ SQL をガリガリ書きたいシチュエーションっ てあるよね。 JPA のメリットと SQL のメリットの両立を！ – それが・・・
40
40 Seasar Conference 2006 Spring © The Seasar Foundation and the others 2006. all rights reserved. Kuina 襲来 S2JDBC S2Dao S2Hibernate-JPA KuinaDao S2Hibernate-JPA KuinaDao KuinaCore 現在近未来未来
41
41 Seasar Conference 2006 Spring © The Seasar Foundation and the others 2006. all rights reserved. Summary ABD は DB 設計の難易度を変える – 最終的には難易度は下がる – 但し、まだまだ列の横持ちテーブル設計がはびこってい るように、パラダイムシフトはなかなか進まないだろう ABD は JPA との相性がいい！ – つまりインピーダンスミスマッチ問題を低減する ゼロにはならない – アプリケーション生産性に影響を与える となると JPA の出来が重要 – まだまだ不自由な面はある – そこで次世代 S2Dao である Kuina ですよ！
42
42 Seasar Conference 2006 Spring © The Seasar Foundation and the others 2006. all rights reserved. Thank you!! ありがとう ございまし た
Similar presentations
