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