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
2024年度 サイバーエージェント新卒社内研修の「データモデリング」の資料公開
Search
chiba_katsu
June 05, 2024
Education
2
3.1k
2024年度 サイバーエージェント新卒社内研修の「データモデリング」の資料公開
chiba_katsu
June 05, 2024
Tweet
Share
Other Decks in Education
See All in Education
情報処理学オリエンテーション
naokikato
PRO
1
130
Introduction - Lecture 1 - Next Generation User Interfaces (4018166FNR)
signer
PRO
0
3.2k
Servizo de correo
irocho
0
450
Matz に頼られたので張り切って2時間ほどドイツと日本の互いの Ruby 学習事情についてディスカッションした話
yasulab
1
300
Switches
irocho
0
250
Educación digital en la adolescencia
gonz1ale1
0
180
Visualisation Techniques - Lecture 8 - Information Visualisation (4019538FNR)
signer
PRO
0
1.8k
SDGsをアシスト! 現地調査データをアーカイブする技術2024|麻布大学デジタルマッピングワークショップ
fullfull
1
210
わたしのメタ学習 / My Own Meta Learning #shinjukurb
expajp
0
270
Case Studies and Course Review - Lecture 12 - Information Visualisation (4019538FNR)
signer
PRO
0
1.4k
Цифровые финансы - магистерская программа Финэка МГИМО 2024 г.
niellony
0
130
Materiales para Marketing Digital
navarromorales
0
1.5k
Featured
See All Featured
How To Stay Up To Date on Web Technology
chriscoyier
784
250k
ParisWeb 2013: Learning to Love: Crash Course in Emotional UX Design
dotmariusz
104
6.7k
The Power of CSS Pseudo Elements
geoffreycrofte
63
5.1k
Fashionably flexible responsive web design (full day workshop)
malarkey
399
65k
Product Roadmaps are Hard
iamctodd
PRO
46
10k
Designing for Performance
lara
603
67k
What's new in Ruby 2.0
geeforr
338
31k
Automating Front-end Workflow
addyosmani
1361
200k
A Tale of Four Properties
chriscoyier
154
22k
Ruby is Unlike a Banana
tanoku
96
10k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
128
32k
Being A Developer After 40
akosma
68
580k
Transcript
データモデリング 2024年度 AI事業本部研修 データアプリケーション研修応⽤編より抜粋
基幹系・情報系による分類 2 分類 基幹系システム OLTP: Online Transaction Processing 情報系システム OLAP:
Online Analytical Processing 要求 データの整合性を担保しながら高速に読み書き 大量のデータを高速に集計・分析 業務におけ る役割 販売管理、在庫管理、生産管理、財務会計といった 特に経営を支える屋台骨となる業務を一元管理して、 効率よく行うためのシステム 社内外のコミュニケーション、事務処理の効率化、 あるいは意思決定支援などに利用されるシステム 操作の特徴 追記に加え、更新も多い 追記が多い アクセス 範囲 読み取らなければいけないデータは全体の一部 データ全体
データモデリングの流れ 要件分析 ˔ データベースで管理したいデータやデータの使われ⽅などを整理 概念設計 ˔ 要件定義をもとに、DBかの対象となる実世界をモデル化 ˔ 特定の DBMS
のデータモデルには依存しない ˔ ER モデルが主流 論理設計 ˔ 概念モデルを DBMS のデータモデルでスキーマに変換(PKなど) ˔ スキーマの改善 物理設計 ˔ インデックス。ファイルフォーマットなどの性能チューニング ˔ この後のステップにはセキュリティ設計などが含まれる 3
ERD︓Entity Relationship Diagram 4 データベースの構造を視覚的に表現したもの エンティティ︓ 実世界のオブジェクトの概念 (例︓商品・メーカ・注⽂) 属性︓ エンティティを詳細に記述するための要素
(例︓商品名・原価・注⽂⽇) リレーションシップ︓ エンティティ間の関連性や相互作⽤ (例︓1:1、1:N、N:M などの関係)
正規化 第⼀正規化 重複したレコードの排除 第⼆正規化 ⾮キー属性が候補キーに完全関数従属 第三正規化 ⾮キー属性が候補キーに推移的関数従属 実務では第3正規化まで ⾏うことが多い 最適化のために物理設計で
⾮正規化を⾏うこともある 5 キー属性は「注文番号」と「商品番号」。 「商品名」、「分類」、「単価」は、 「商品 ID」によって一意に決まるので分割 キー属性は「注文番号」。 「名前」、「住所」、「電話番号」は、 「顧客 ID」によって一意に決まるため分割 注文明細テーブル 注文テーブル 注文テーブル 注文明細テーブル 商品テーブル 注文テーブル 顧客テーブル 注文明細テーブル 商品テーブル
モデリングでのテーブルの分類⽅法 マスタ(システムにとって重要なデータ) • ユーザーが変更できないデータ • あらかじめ登録しておくデータ トランザクション(作業時に発⽣するデータ) • ユーザーが登録するデータ •
⽇報データや売上や活動履歴とか リソース • ユーザや企業、ジョブの状態など • 主に 更新 される イベント • ユーザ登録や削除、ジョブ開始など • 主に 追記 される マスタ・トランザクション (定義は諸説ある) リソース・イベント (最近はこちらの表現が多い) 6
イミュータブルデータモデリング CRUDの中で基本的に 更新 が最も時間がかかり、システムを複雑にする データを変更せず、新しい追記するようにすればパフォーマンスの向上、 さらにデータの⼀貫性と信頼性を向上させることができる (関数型プログラミングの原則をデータ管理にも適⽤) リソース系とイベント系を明確に分け、リソース系を⼩さくする ⽋点︓
ストレージの⼤量消費、データのクリーンアップが⼤変 (スナップショットやアーカイブが必要。クラウドの発達でデメリットにならないケースも) 7
SQL の設計におけるアンチパターンには RDB が苦⼿なデータ構造 (半構造データ・グラフ)に対するおすすめのモデリングなどが書かれている。 おまけ)「SQLアンチパターン」の紹介 例)Jaywalking(信号無視) 半構造データを⽂字列結合で1つのカラムに押し込める 解決策 中間テーブルを⽤意して参照整合性を保つ
8 https://www.oreilly.co.jp/books/9784873115894/
情報系にもいろいろなモデリングがある 9
こんなデータがあったとする🤔 イベント(Fact) 10 購買 店舗 商品 会員 カテゴリ リソース(Demention)
⼤福帳 会員番号 性別 年齢 購買日 店舗コード 店舗名 大カテゴリ名 Janコード 商品名
… 購買金額 購買数量 Customer_1 男性 40 2024/01/01 Store_1 A店舗 カテゴリA Product_1 商品A 10000 1 トランザクションにマスタの情報をすべて結合してして⼀つのテーブルで保持する。 ˔ メリット ˓ 使うときにジョインしなくてもいい ˔ デメリット ˓ 変更に弱い ˓ 1テーブルがデカくなるので過去分全部は持てなかった 11
Fact を中⼼として、Dimension を結合して使⽤する。 Fact ˓ POSデータなどの⽇々増えていくデータ Dimension ˓ 店舗マスタ、商品マスタ、カレンダーマスタなど頻繁に更新をしないデータ スタースキーマ
12
Data Vault ハブ、リンク、サテライトの 3 種類のエンティティで構成される モデルが変更された場合に、ETL ジョブのリファクタリングが少なくて済む ハブ 顧客 ID、製品番号など、ビジネスの中核となるコンセプトを表す。
ユーザーはビジネスキーを使用して、ハブに関する情報を取得する。 ビジネスキーには、ビジネスコンセプト ID やシーケンス ID、ロード日、その他のメタデータ情報の組み合わせを含めることができる。 リンク ハブ間のリレーションシップを表す。 サテライト ハブに属する情報とハブ間のリレーションシップに関するデータを格納する 参考:https://www.phdata.io/blog/how-to-model-and-choose-the-right-data-model/ 13
Data Vault リ ン ク ハ ブ サ テ ラ
イ ト 参考:https://www.phdata.io/blog/how-to-model-and-choose-the-right-data-model/ 14
Data Vault ˔ メリット ˓ データの変更に強い ˙ 項⽬追加の場合はサテライトを追加すれば良い ˙ 変更履歴は全部取っておく
˓ スケーラビリティがある ˔ デメリット ˓ クエリを書く際にジョインが多くなる ˓ 初期構築時にビジネスキーとなる項⽬を定義が必要 ˙ なるべく不変的な項⽬ 参考:https://www.phdata.io/blog/how-to-model-and-choose-the-right-data-model/ 15
情報系データモデリングのまとめ 最適解はビジネスモデルに合った形で選ぶ必要がある とはいえ、いまのところスタースキーマがよく選ばれる (Data Vaultは実績がまだあまり多くない・・・) 16