Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
業務システム構築におけるデータモデリング
Search
Recruit Technologies
June 24, 2019
Technology
13
46k
業務システム構築におけるデータモデリング
2019年度リクルート新人ブートキャンプ エンジニアコースの講義資料です
Recruit Technologies
June 24, 2019
Tweet
Share
More Decks by Recruit Technologies
See All by Recruit Technologies
障害はチャンスだ! 障害を前向きに捉える
rtechkouhou
1
640
Flutter移行の苦労と、乗り越えた先に得られたもの
rtechkouhou
3
11k
ここ数年間のタウンワークiOSアプリのエンジニアのチャレンジ
rtechkouhou
1
1.5k
大規模環境をAWS Transit Gatewayで設計/移行する前に考える3つのポイントと移行への挑戦
rtechkouhou
1
1.9k
【61期 新人BootCamp】TOC入門
rtechkouhou
3
41k
【RTC新人研修 】 TPS
rtechkouhou
1
41k
Android Boot Camp 2020
rtechkouhou
0
41k
HTML/CSS
rtechkouhou
10
50k
TypeScript Bootcamp 2020
rtechkouhou
9
45k
Other Decks in Technology
See All in Technology
Shopifyアプリ開発における Shopifyの機能活用
sonatard
4
250
The Rise of LLMOps
asei
7
1.7k
Amazon CloudWatch Network Monitor のススメ
yuki_ink
1
210
Amplify Gen2 Deep Dive / バックエンドの型をいかにしてフロントエンドへ伝えるか #TSKaigi #TSKaigiKansai #AWSAmplifyJP
tacck
PRO
0
390
DynamoDB でスロットリングが発生したとき/when_throttling_occurs_in_dynamodb_short
emiki
0
250
SREが投資するAIOps ~ペアーズにおけるLLM for Developerへの取り組み~
takumiogawa
1
420
複雑なState管理からの脱却
sansantech
PRO
1
150
DynamoDB でスロットリングが発生したとき_大盛りver/when_throttling_occurs_in_dynamodb_long
emiki
1
430
VideoMamba: State Space Model for Efficient Video Understanding
chou500
0
190
テストコード品質を高めるためにMutation Testingライブラリ・Strykerを実戦導入してみた話
ysknsid25
7
2.7k
RubyのWebアプリケーションを50倍速くする方法 / How to Make a Ruby Web Application 50 Times Faster
hogelog
3
950
[CV勉強会@関東 ECCV2024 読み会] オンラインマッピング x トラッキング MapTracker: Tracking with Strided Memory Fusion for Consistent Vector HD Mapping (Chen+, ECCV24)
abemii
0
220
Featured
See All Featured
What's new in Ruby 2.0
geeforr
343
31k
Product Roadmaps are Hard
iamctodd
PRO
49
11k
Embracing the Ebb and Flow
colly
84
4.5k
Facilitating Awesome Meetings
lara
50
6.1k
Build The Right Thing And Hit Your Dates
maggiecrowley
33
2.4k
5 minutes of I Can Smell Your CMS
philhawksworth
202
19k
Mobile First: as difficult as doing things right
swwweet
222
8.9k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
28
9.1k
The Art of Programming - Codeland 2020
erikaheidi
52
13k
Art, The Web, and Tiny UX
lynnandtonic
297
20k
Principles of Awesome APIs and How to Build Them.
keavy
126
17k
Ruby is Unlike a Banana
tanoku
97
11k
Transcript
業務システム構築における データモデリング 2019年4月10日 タワーズ・クエスト(株)和田省二
目次 1. 業務システムとは 2. データモデリングとは 3. 業務システム構築の考え方(従来の方法)
4. 業務システム構築の考え方(データモデリング) 5. データモデリングの手順 6. 演習課題
1.業務システムとは 1.1 業務システムの例 ・ 機能システム(〇〇管理システム) 売上 受発注 物流 在庫
予約受付 貸出返却 生産 人事給与 勤怠 部品 商品 顧客 資産 不動産 • 統合システム • 小売業 • 製造業 • サービス業 • 学校 • 病院 • 図書館 • 旅館ホテル • 介護サービス • 予約代行 機能システムを統合化 (サイロ化の問題)
1.業務システムとは 1.2 なぜ業務システムを構築するのか • ルーティンワーク • 業務効率化(ムダ、ムラ、ムリの排除) •
業務精度向上(モレなくダブリのない業務の遂行) • 既存データの有効再利用による業務(サービス)拡大 • クリエイティブワーク • 有益かつ信頼性の高い様々な情報取得による意思決定支援 • マーケティング(新商品企画・市場開拓(地理、購買層)etc) • マーチャンダイジング(販売促進・セールス企画etc) • リソースの再配置 等の実現のため。
1.業務システムとは 1.3 どうすれば有効な業務システムを構築できるか • いろいろな業務遂行に必要な正しい【情報】を簡単に引き出せる。 • 正しい(信頼性が高い) 【情報】とは、
• 情報に欠落がない。 • 同時期のすべての情報間に矛盾がない。(整合性がとれている。) • それまでに無い新しい情報を取得しても、既存の情報との間に矛盾がない。 このために、全ての情報生成の出所【データ】が同じ(一つ)であることが必須。 (一つ)であることを担保するのがデータベースである。
1.業務システムとは 1.4 業務システム構築のために重要なポイント • リレーショナルデータベース構築が命 • データ定義の一本化(重複定義の排除、正規化) • データの信頼性向上
(ダブリチェック、参照チェック、必須項目チェック、ルールチェック) • データの登録・記録、保管、読み出しの一括管理 • データの共有 が実現する。
1.業務システムとは 1.5 「データベース」と「ファイル」 リレーショナルデータベース ファイル データベース管理システム 個別のプログラムのアクセスを前提に(隷属して)存在する。 データベース管理システムによって統合管理され、多数のユー ザから同時アクセス可能。ユーザにとって唯一無二の共有資源。
データベース 個別のプログラムのアクセスとは無関係に(独立して)存在する。
2.データモデリングとは 2.1 データモデリングとは データモデリングとはデータベースを構築する手法である。 • データ • データと情報は異なる。
• データ中心のデータモデリングとプロセス中心のデータベース設計。 • モデリング • データを集合(En0ty)として捉える。 • En0ty間を関連(Rela0onship)で結び付ける。 • 最終的にER図(En0ty Rela0onship Diagram)にモデルとして表現する。
2.データモデリングとは 2.2 「データ」と「情報」 「データ」 • いつ、誰が、どの店で、何を、いくら、購入したという【事実】を表す。6W2H (ex. ある会員が、どの店で、ある商品を、何年月日時分、いくら、現金で買物した) •
〇〇したという事実は一過性で二度と再現しない。(捉え損ねたら、捨ててしまったら、永遠 に事実【データ】を失う) • 事実【データ】はそれ自体に意味はなく、記録として残しておくもの。 「情報」 • 「データ」を選択・加工して、当事者が必要とする知識(新たな価値)を取り出したもの。 (ex. ここ数年の各月ごとの、ある商品の店別売上の推移) • 情報の必要性と価値は、当事者によって、時期によって様々に変化する。 (10年前には誰も思ってもいなかった情報を、今私は欲しい。 今誰も思い付いていない情報が、10年後には誰かが必要になるかもしれない。) 私達が欲しいのは役に立つ「情報」、そのために「データ」が必要! 「データ」は、貴重な「情報」を生み出す可能性を秘めた宝の山である!
2. データモデリングとは 2.3 システム構築の流れ プロセス中心アプローチ(従来方法) ある特定の問題解決(ソリューション)を最適 化する仕組としてシステムを設計する。 ①外部設計 問題解決のための出力、そのための入力を決める。
②内部設計 ①を基にその入出力に最適なデータベース(ファイル) 設計を行う。 ②モジュール設計 入出力情報とファイル情報を結び付ける。 プロセスが変わると、データの持ち方も変わる。 データモデリングアプローチ システム化対象領域の実世界をデータの視点 からモデル化し、実世界の物事を表現する。 ①論理データモデリング ・実世界の物事を、モノ(Resource)とコト(Event)に 分けてEn0tyとして抽出する。 ・ERD(En0ty Rela0onship Diagram)ツールにより En0tyを登録し、En0ty間をRela0onshipで関連付ける。 ・En0tyの正規化を図り、Rela0onshipを見直す。 ・これを繰り返す。 ②物理ERD設計 論理ERDにEn0tyの更新履歴を保持する仕組等、 実世界とは関係ない項目とかEn0tyを追加する。 プロセスが変わっても本質的なデータ構造は変わらな いので、データの資産的価値は変わらない。
2. データモデリングとは 2.4 システム構築の流れ(データモデリングアプローチ) ① システム化対象領域の実世界をデータの視点からモデル化(見える化)する。【論理ERD作成】 ② ①を基に実装向けの属性(カラム)とかEn0tyを加える。【物理ERD作成】 ③ ②からDDLを出力してRDBを生成する。
①の成果は、②③を経て、RDBの定義にシームレスにつながる。 システムとはデータ貯蔵器(RDB)であり情報生成機(SQL)である。 システム化 対象領域の 実世界 情 報 ① 論理データモデリング ② 物理設計 ー ー 論理 ERD 物理 ERD ー SQL ③ En0ty Rela0onship Diagram システム RDB
2. データモデリングとは 2.5 ER図(En$ty Rela$onship Diagram)の一例
2. データモデリングとは 2.6 論理ERD(En$ty Rela$onship Diagram)の役割・メリット • システムの全体を一望できる。(木も森も見られる) •
表記法が定義されている図解なので見る者に依って解釈が分かれることがなく、 当事者間で共通の正しい認識が得られる。 (従来方法では、設計者の主観的意図が正しいかではなく、良いか悪いかになる。) • 現実世界の物事をモデリングして(En0ty とRela0onship)に定着させるので、ERDの上で 現実世界をシミュレーションできる。 (モデルが現実世界を正しく表現できていれば、En0tyに蓄えられるデータは正しい。 そこから生成される情報はどれも正しい。) • ERDに定着させると、複数のEn0tyが関連とともに一度に見られるので、En0tyの正規化 が図り易くなる。 • 論理ERDの成果は、物理設計を経て、RDBの定義に洩れなく反映できる。
3.業務システム構築の考え方(従来の方法) 3.1 システム化対象領域の様々な属性を集める 属性 異音同義 同音異義 異音同義 入力画面
入力帳票 出力画面 出力帳票 管理資料 異音同義 発注日付/注文日付 同音異義 同じ納品日付でも (納入先への)/(仕入元からの)
3.業務システム構築の考え方(従来の方法) 3.2 属性を処理単位にまとめる 〇 〇 〇 〇 〇 〇 〇
〇 〇 〇 〇 〇 〇 〇 〇 〇 〇 〇 〇 〇 〇 属性1 属性2 属性3 属性4 属性5 属性6 属性7 属性8 属性9 処理に使う属性を集めたファイルを設 計してしまう。 例) •入力画面項目をそのままファイル属性として 持つ。(ファイル2) •出力項目の全てを1つのファイルにまとめて 持つ。(ファイル4) •このため一つの同じ属性(の値)が複数個所 に存在してしまう。(属性4がファイル2と4に 存在する。) ある属性の値が更新されたら、その属 性を持つ全てのファイルを更新しなけ ればならない。 •一部の更新を忘れるとシステムに不整合を 起こしてしまう。
3.業務システム構築の考え方(従来の方法) 3.3 従来方法の問題点 • 問題解決の課題・仕様が、 正しく伝わらない。(間違って理解される) 開発途中で変わってくる。(初期に固まりきれない)
と、手戻りが発生する。 • 問題解決の課題のみを追求するあまり、課題外に潜む本質的に重要な考慮点を見落とす危 険がある。 • データ構造の冗長性のために、更新不具合が発生するとシステムの信頼性を損ねる。 • 新たな問題解決が起きると、対応済みの問題解決部分にも修繕が必要になる場合があり、 後ろ向き保守作業が続く。 • 保守のたびにデータベース、プログラムとも煩雑の度を加え、ますます保守作業を増やしてし まう。
4.業務システム構築の考え方(データモデリング) 4.1 システム化対象領域の様々な属性(ドメイン)を集める ドメイン 異音同義の一本化 同音異義の 分解独立1 同音異義の
分解独立2 異音同義の削除 入力画面 入力帳票 出力画面 出力帳票 管理資料 •複数の異音同義ドメインを一つに寄せる。 •一つの同音異義ドメインを複数の個別ドメイ ンに分解独立させる。 (名前というドメインでなく、教師氏名・学生氏 名・店舗名称・商品名称等に分けるべき。) •ドメインは一つの型(文字列、数値、日付 等)と値の範囲を持つ。 集合論・RDBでは属性のことをドメインと呼ぶ。
4.業務システム構築の考え方(データモデリング) 4.2 ドメインをまとめてリレーション(集合)を定義する 〇 〇 〇 〇 〇 〇 〇
〇 〇 ドメイン1 ドメイン2 ドメイン3 ドメイン4 ドメイン5 ドメイン6 ドメイン7 ドメイン8 ドメイン9 ー ー ー ー ドメインの中には互いに密接な関係があるもの 同士がある。 (それらドメインを集めた集合のことをリレーションと呼 ぶ。) ドメインはいずれか一つのリレーションに収まり、 複数のリレーションに収まることはない。 この状態を One Fact One Place と呼ぶ。 データベースはリレーションの集まりとなる。 リレーション間は関連(rela0onship)によって関 係づける
4.業務システム構築の考え方(データモデリング) 4.3 一つのリレーションの構造 リレーションは、 • 共通に定義されたドメインの集まり(横)と、 • それらに具体的な値を持った組の集まり(縦)
の2次元表である。すなわち集合である。 データモデリングでは、 システム化対象領域を〇〇と□□の集合として 捉える。 集合なので、 • 同じ〇〇が2つ以上在ることはない。 • 同じ□□は2度と起こらない。 属性1 属性2 集合とは2次元の表で表され、 • タプル(組、行)に上下の順序がない。 • ドメイン(属性、列)に左右の順序がない。 • 重複行を許可しない(唯一無二) キー属性が存在し、その値に重複がない。 • 全ての列は1つの型を持ち、各行に1つの値 を持つ。 • キー属性の値が決まるとその他の属性の値 が決まる。(非キー値はキー値に関数従属す る。)
5.データモデリングの手順 5.1 Entityを抽出する(1) データモデリングでは、 システム化対象領域での現実世界を物事(ものごと:モノとコト)の集合として捉える。 (すなわち前ページの、◦◦は物事のモノ、□□は物事のコトである。) モノ集合をResource
En0ty、コト集合をEvent En0tyと称する。 コト システム化対象領域で本業(生業)として繰り返し為される行為(Event) ・6W2Hを属性に持つ。(特にWHEN【時点】は必須。) ・How much(数量、金額等)をもつことが多く、【期間】で集合演算される。 ・システムはコト(Event)をデータとして逐一『記録』していく。 モノ ある【期間】存在し、コトに直接・間接に投入される資源(Resource) ・システムには発生【時点】に『登録』し、消滅【時点】まで存在する。 ・モノは、ある【期間】一定の属性値を持ちながら状態遷移していく。 ・【時点】を指定することにより、その時のモノの属性値を得る。
5.データモデリングの手順 5.2 En$tyを抽出する(2) Event En0tyの抽出 • 現実世界のコトを表す。
• キーは単一の伝票番号とかが通常。 • En0ty数はそんなに多くない。 • 非キー属性には 6W2H の内のいくつかを持つ。 (起きたコトの事実を明確にするため。) • When(発生時点が必ずある) (発生と計上を分けることもある) • What • Who(主体者) • Whom(主体者以外の関係者 to Whom, by Whom, with Whom等) • Where • Why • How to • How much(数量、単価、金額等) Resource En0tyの抽出 • 現実世界のモノを表す。 • キーは複合とか複雑な場合もある。 • En0ty数はシステム化対象領域によって千差万 別。(システムの特徴を表す。) • 非キー属性も多種多様。 • モノを識別するための名称が必ずある。 • 発生時点と消滅時点を属性に持てば、モノの存 在期間を示しているのでResourceと言える。 • Eventの When, How much 以外の6W2H属性に 外部参照先としてResourceのPK(またはAK)を 関連付けることが多い。 • Resourceの二律背反性 (一過性vs反復性、概念的vs実体的等)
5.データモデリングの手順 5.3 Entityのキー属性を見つける(1) Entityは集合だから • 必ずキー属性を持つ。 • En0ty内でキー属性の値が重複することはない。
• 非キー属性はキー属性に関数従属する。 Entity内のキー属性以外の属性をまとめて非キー属性と呼ぶ。 キー属性の値が決まると全ての非キー属性の値が決まる。 以上を考慮して、Entityのキー属性と非キー属性を決める。
5.データモデリングの手順 5.4 Entityのキー属性を見つける(2) 主キー(primary key PKと略す) 行を一意にするためのキー。 主キーがないことは無い。(唯一無二を明示できなければそのEn0tyは集合ではない。)
主キーを宣言すると、それには一意制約とnot NULL制約が自動的に付される。 • 行を識別する属性を見つけて、主キーを付与する。 • 一つの属性だけでは一意にならない場合、複数の属性を組み合せて主キーにする。 (複合キー:composite key) • 主キー候補が複数見つかる場合、それらを候補キー(candidate key)と呼び、その内の一つを 主キーとし、残りは代替キー(alternate key)となる。 代替キー(alternate key AKと略すことが多い) 行を一意にするためのキー。(主キーと同等) ボイスコッド正規形違反を免れるためには代替キーを付すのが便利。 代替キーには一意制約とnot NULL制約を付す。 (一意性を担保するだけで、代替キーにしないなら、not NULL 制約は無くても可。)
5.データモデリングの手順 5.5 En0tyのキー属性を見つける(3) 主キー(または代替キー)の持ち方に2つの方法がある。 • 自然キー(natural key)
集合を構成する属性の中から行を識別する属性を見つけて、キーとする。 • 代理キー(surrogate key) システムに絶対にダブらない連続番号を発生させ、それを代わりにキーとする。 (En0tyが本来持っていない属性をシステムに追加することになる。) (アクセスログデータ等キーとすべき属性が無い場合に使う。) • 互いを代替キーにすることは可能である。(代理キーをPK、自然キーをAKとする。または逆) 《注意》 • 論理データモデリングのフェーズでは、代理キーを許さないか無視する!! (自然キーでないと、集合の正規化違反(特に高次正規化)は検証できない。)
5.データモデリングの手順 5.6 En0ty間に関連(Rela0onship)を付ける(1) • Rela0onshipは、参照する相手のPKまたはAKを取り込むこと。この取り込んだ相手側のキーを FK(foreign key)と称する。 •
En0ty間にRela0onshipを付すことにより、外部参照制約を付すことになる。 相手側に存在しないPKまたはAKを取り込もうとすると外部参照制約の違反となる。 • もし、外部参照制約を付さないで相手側に存在しないPKまたはAKを持つと、それを結合の キーとしている場合、結合できなくて結合結果から漏れてしまう。 (気が付かないままだと、その行が迷子データとなる。それから作成する情報に欠落が生じる。) • それに気付くと、以後、疑心暗鬼に陥って外部結合しか使わないという本末転倒なことになる。 • システムの信頼性を確保するために、外部参照制約を担保として利用すべき。
5.データモデリングの手順 5.7 En0ty間に関連(Rela0onship)を付ける(2) ERDでRela0onshipを示す線には意味がある。 • 向き(どちらが出発点か。親エンティティ・子エンティティを表す) • 種類(実線は親のPKが子のPKに入るため子の存在は親に依存
する。点線は非依存を表す。) • 始点側のマーク、終点側に付く z とか p とかの記号(cardinality: 多重度と言う) IDEF1X方式 IE方式
5.データモデリングの手順 5.8 En0ty間に関連(Rela0onship)を付ける(3) 特殊な関連 • 親子関連 ・子は親のPKを自分のPKに含める。子の存在は親に依存する。(子がない親もない。)
・第1第2正規化により、共通部分を独立させることにより生まれる。 • 交差関連(交差En0ty) ・複数(主に2つ)の他En0tyのPKを組み合せた複合キーをPKとする。 ・組合せの制約を表す。(それぞれ一方から見れば、他方は重複を許さない子を表す。) ・3つ以上の組合せの複合キーは、第4正規形違反および第5正規形違反に注意する。 • スーパー/サブ関連 ・親(スーパー)が複数のそれぞれ属性構成が異なる子(サブ)を持つ。 ・子(サブ)の間は、排他か共存可能かのどちらかである。
5.データモデリングの手順 5.9 En0ty間に関連(Rela0onship)を付ける(4) 交差エンティティ スーパー/共存サブ関連 スーパー/排他サブ関連
5.データモデリングの手順 5.10 En0tyの正規化違反チェック • 繰り返し属性の排除 En0tyが持つ属性は全て異ならなければならない。(第1正規形違反) •
関数従属性に関する正規化違反 非キー属性の中に、複合キーの一部にだけ従属する属性がある。(第2正規形違反) 非キー属性の中に、他の非キー属性に従属する属性がある。(第3正規形違反) 複合キー属性の中に、非キー属性に従属する属性がある。(ボイスコッド正規形違反) これ以上高次は、複合キーのみ(非キー属性が一つもない)の属性のEn0tyだけに起こり得る。 • 結合従属性(多値従属性)に関する正規化違反 複合キーで、1つのキーとそれ以外の組合せもキーになる。(第4正規形違反) 複合キーで、任意の複数の組合せもキーになる。(第5正規形違反) 第6正規形違反もあるが、違反があっても実害はない。
第1正規形
第2正規形
第3正規形
ボイスコッド正規形
6.演習課題 6.1 小売店の売上管理(1) step1 次ページに示すEn0ty(第1次正規化済)を第2、第3正規化する。 step2 売上処理に関わるレジとレジ担当者をモデルに加える (レジもレジ担当者も、店に所属するものとする。)
step3 買物明細(単品)ごとに値引きがあれば、その率と金額を記録する。 step4 お買い上げ客を特定できるようにする。 (会員カードを発行し、会計時に会員を特定する。) step5 カード会員には1回の買上額に応じてポイントを発行する。 ポイントは貯めるか、今回買上の支払いに充当できる。 (カードを提示しない場合は、ポイント制度対象外とする。) (支払いは、現金、クレジットカード、ポイント利用で行う。併用可。) (現金支払い分にのみ、100円につき1ポイント付与する。) (ポイント利用時は、1ポイント1円の扱いとする。)
6.演習課題 6.2 小売店の売上管理(2) 演習課題のER図
6.演習課題 6.3 小売店の売上管理(3) step6 お買い上げ品の配達サービスをする。 (配達地域は近隣に限る。)
(配達料金は、買物総額に応じて決まる。) (配達サービス利用会員に登録してもらう。カード会員でなくとも可。) • 買物客は、配達依頼品も持ち帰り品も合わせて会計を済ませる。 • 買物客は、配達依頼品を店のレジ袋に自分で詰める。 • 買物客に、配達サービス利用会員番号、配達依頼袋数、配達希望 日付・時間帯を告げてもらい、配達依頼袋を預かる。 • 配達料を徴収して配達依頼データを登録し、控えを買物客に渡す。 • 配達依頼データから、配達希望日付・時間帯を指定して配達依頼袋を まとめ、買物客の登録された指定場所に配達し、受領サインを貰う。 • 受領サインのある配達依頼データを消し込む。 • 受領されなかった配達依頼袋を保管し、再配達までフォローする。