データモデリング 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 などの関係）

正規化 第⼀正規化 重複したレコードの排除 第⼆正規化 ⾮キー属性が候補キーに完全関数従属 第三正規化 ⾮キー属性が候補キーに推移的関数従属 実務では第３正規化まで ⾏うことが多い 最適化のために物理設計で ⾮正規化を⾏うこともある 5 キー属性は「注文番号」と「商品番号」。 「商品名」、「分類」、「単価」は、 「商品 ID」によって一意に決まるので分割 キー属性は「注文番号」。 「名前」、「住所」、「電話番号」は、 「顧客 ID」によって一意に決まるため分割 注文明細テーブル 注文テーブル 注文テーブル 注文明細テーブル 商品テーブル 注文テーブル 顧客テーブル 注文明細テーブル 商品テーブル

モデリングでのテーブルの分類⽅法 マスタ（システムにとって重要なデータ） ● ユーザーが変更できないデータ ● あらかじめ登録しておくデータ トランザクション（作業時に発⽣するデータ） ● ユーザーが登録するデータ ● ⽇報データや売上や活動履歴とか リソース ● ユーザや企業、ジョブの状態など ● 主に 更新 される イベント ● ユーザ登録や削除、ジョブ開始など ● 主に 追記 される マスタ・トランザクション （定義は諸説ある） リソース・イベント （最近はこちらの表現が多い） 6

イミュータブルデータモデリング CRUDの中で基本的に 更新 が最も時間がかかり、システムを複雑にする データを変更せず、新しい追記するようにすればパフォーマンスの向上、 さらにデータの⼀貫性と信頼性を向上させることができる （関数型プログラミングの原則をデータ管理にも適⽤） リソース系とイベント系を明確に分け、リソース系を⼩さくする ⽋点︓ ストレージの⼤量消費、データのクリーンアップが⼤変 （スナップショットやアーカイブが必要。クラウドの発達でデメリットにならないケースも） 7

SQL の設計におけるアンチパターンには RDB が苦⼿なデータ構造 （半構造データ・グラフ）に対するおすすめのモデリングなどが書かれている。 おまけ）「SQLアンチパターン」の紹介 例）Jaywalking（信号無視） 半構造データを⽂字列結合で１つのカラムに押し込める 解決策 中間テーブルを⽤意して参照整合性を保つ 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 トランザクションにマスタの情報をすべて結合してして⼀つのテーブルで保持する。 ˔ メリット ˓ 使うときにジョインしなくてもいい ˔ デメリット ˓ 変更に弱い ˓ １テーブルがデカくなるので過去分全部は持てなかった 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