■ 1. 発表者の背景とテーマ
- 発表者は横山(ハンドルネーム:ゆずたそ)で、風音屋という会社に所属している
- データウェアハウスやデータ分析系の活動を行っている
- 風音屋はデータ分析、データ基盤の構築を支援する会社である
- 昨年「アジャイルデータモデリング」という訳書を出版した
- テーマはExcelデータ分析でディメンショナルモデリングを扱う
- エントリー向けの内容を紹介する
■ 2. データ分析の前提条件
- 構造化データを扱うことを想定している
- 構造化データとは行や列など表形式で表現されるデータのことである
- これは従来のデータベースが前提としている形式で、最も安定してデータを管理利用しやすい
- テーブル(表形式)で管理するデータの関係性を表現したER図がある
- テーブル名と列名があり、Excelで例えるとシート名とその中に並ぶ列のようなイメージである
- 複数のテーブルをIDや識別値で結合していく
- 細かくテーブルを分けていくとデータの更新箇所が最小限で済む
- モデルの書き方として概念モデル、論理モデル、物理モデルといった書き方がある
- 正規化と呼ばれる概念がある:
- データの重複や不整合を防いで効率的に管理するために行う
- いくつか正規化の形があり、その条件を満たすようにテーブルを分解していく
- 第3正規化された状態のことを第3正規形と呼ぶ
■ 3. Excelでのデータ分析における課題
- ビジネスパーソンは以下のような流れでデータ分析を行っている:
- ローデータ(機関システムから出力したものなど)を一旦貼り付ける
- 注文テーブル、商品のシートなどがある
- それらを元にして別のExcelタブで集計を行う
- 最終的に表示したい形式(例:商品カテゴリー別の毎月の注文数)を出す
- この集計データを作ってからグラフに表示する
- 最終的に見たい形は正規化されたものではなく、分析要件に基づいて集計した結果である
- 営業地域別と業種別の切り替えの問題:
- 多くの会社では日々の業務要件に適した形でデータを管理しがちである
- 営業地域ごとに営業署があり、それぞれの中で管理している場合、営業地域別でデータを管理することになる
- 担当エリアがあり、エリアに合わせてフォルダーが分かれている
- 年月ごとにシート分けしている(例:京都の1月、2月、3月)
- この単位で入力するため、入力しやすい形でシステムが作られていく
- モニタリングも基本的には年月と地域の単位で行われる
- 当初は想定していなかった観点(例:業種別)でレポートを作るニーズが発生することがある:
- マーケット環境が変化した時に適用するため
- コロナのような事態が発生した場合、業種別で数字を見る必要が出てくる
- 飲食店などの店頭サービス業での契約が減っている可能性がある
- 逆にこの状態で伸びている業種があるかもしれない
- Excelファイルごとに分かれていると全部のシートを開いて業種の列を抽出していく作業が発生する
- これはあまり現実的ではない
- 当初の要件を満たすテーブルではなく、切り口を柔軟に変更できるテーブルが求められる
■ 4. データ分析における複数データソースの組み合わせの必要性
- データ分析を行う時は複数の元のデータを組み合わせていくことが一般的である
- 例:駅に近い店舗は雨の時だけ注文が上がった/下がったからクーポンを打つ場合:
- 駅がどこにあるのかという情報が必要
- 店舗がどこにあるのかという情報が必要
- 駅に近いかどうかを判定する必要がある
- 天気の情報が必要
- 注文数がどう変わっているかの情報が必要
- これらを組み合わせて使う必要がある
- 駅と店舗は住所が書いてあるが距離を測るには緯度経度が必要になる可能性がある
- 住所と緯度経度を変換するための前処理が必要で、そのための変換データを引っ張ってくる必要がある
- 店舗マスターは社内にある、駅の情報もどこかにある、住所と緯度経度の変換データもどこかにある、天気のデータは気象庁から引っ張ってくるなど、様々なものを集めてきて組み合わせていく
- データは事前に統合されていて一元管理されている方が分析する側からすると嬉しい
- データ基盤という言葉が一部で注目されている
- 複数のユースケースと複数のデータソース(情報源)をリボンのように結びつけていく一連のサービス群がデータ基盤と呼ばれるものである
■ 5. 正規化の問題点
- 正規化すれば解決するのではないかという考え方がある
- シートを細分化して第3正規形などで作る
- 契約の一覧、相談問い合わせ、契約明細、商品一覧、プロモーション一覧、顧客一覧、業種一覧、都道府県一覧、従業員一覧、所属一覧、部門一覧、担当エリア一覧などに細かく分ける
- 顧客の中に業種IDや都道府県IDがあるため、都道府県IDを見ていたところを業種IDを見るようにすれば集計は簡単にできる
- 理屈上は可能である
- ただし使う側(ビジネスユーザー、ITスキルが必ずしも高くないユーザー)からすると使いにくいポイントがある:
- 毎回分析やモニタリングをするたびにER図を読む必要がある
- そもそもER図の読み方を勉強しなければいけない
- 数十枚あるシートを連携していく必要がある
- 毎回その結合時の注意点をチェックしていく必要がある
- キャンペーンの分析をする場合は日付の曜日や祝日を毎回計算する必要がある
- データをどう組み合わせるかを使う時に考える必要がある
- 使う側のリテラシーを求めてしまう
- 分析の時にこれとこれとこれを結合してというのはややこしい
- 結果として使う側がユーザー手元でカスタマイズして結局自分用の使いやすいシートを作ってしまう
- 顧客一覧、業種一覧、都道府県一覧を3つのシートに分けるのではなく、顧客一覧シートの中で列として業種や都道府県の結果も書いてしまう
- これは使われないモデリングである
- 第3正規形が悪いわけでは当然なく、システム作る上で分けていった方がいい場面はもちろんある
- 記入やインサート・アップデートを考えてももちろん正規化の方がやりやすい
- ただし使う側がこうやって使ってしまうことは起きがちである
- 使う側の立場にちょっと寄り添う必要がある
- 最初から使われるこのシートをモデリングする側が提供するのも一つある
■ 6. ディメンショナルモデリングの基本概念
- トランザクションとマスターで分けるとちょうどいい
- ファクト(トランザクションに近いもの、集計対象となる出来事):
- 例:契約シートが1個ある
- これを見ると合計でいくらの契約になったかが分かる
- ディメンション(マスターに近いもの、比較の切り口となる軸):
- 顧客ディメンション:業種別、エリア別の契約金額などの切り口のヒントになる
- 従業員ディメンション:部署別の契約金額や営業成績などに使える
- カレンダーディメンション:今月の契約金額、祝日や曜日によって効果が違うかを見る
- 日付に対して祝日かどうか判定するフラグがあってもいい
- データ分析の場合、日付は結合キーになることがあり得る
- キャンペーンの取り組みと実際に注文があった時を紐付けて、このキャンペーンには効果があったかを判定することがある
- ファクトとディメンションを組み合わせて使えば使うだけで良い
- 契約の件数がどのくらい増えているか減っているかは、顧客のシートと組み合わせて顧客のシートの方で業種や都道府県を切り替えて見ていけばいい
- 使う側の都合だけを言うとこのくらいシンプルだと分かりやすい
- これがディメンショナルモデリングと呼ばれるものである:
- ディメンション(分析の切り口)とファクト(集計対象となる出来事・事実)を提供するテーブル設計手法である
- これらを組み合わせてデータ分析を行う
- 昨年出版した「アジャイルデータモデリング」という本はこれを紹介する本である
■ 7. データ分析の概念的説明
- 緑のキューブがあり、これが売上累計30億円という大きな事実(ファクト、出来事)の塊である
- データを分析する時はスライスしていく:
- いろんな次元にスライスしていく
- この期間での売上という風に切るとそれが2億円まで減る
- さらに製品で切っていくと5000万円まで減る
- さらに店舗という場所で分けていく
- 全体のキューブの中のこの部分まで絞ると800円になる
- これを比較する:
- この製品とこの製品で比べてどうなのか
- 去年と比べて去年調子良かったのか悪かったのか
- コロナの前と後でどのくらい減っているのか
- こうやって分けて比べていくのがディメンション(次元)である
- 多次元で切っていく、分析していくからである
- 実際の例:倉しコム(数年前に上場した新興企業、ECサイトを提供):
- BIツールを使って画面上でディメンションをポチポチと絞り込んでいく
- 直近90日で日時で見たい、モバイルアプリとウェブサイトで分けて見たい、商品のカテゴリーごとに分けたいなどを指定していってボタンを押すと欲しいデータが出てくる
- 使う側は相当楽である
- ファクトとディメンションの組み合わせをポチポチ選んでいけば集計できる状態が使う側だけからすると理想である
■ 8. BEAMフレームワーク
- BEAMとは:
- ビジネスイベントアナリシス&モデリング(Business Event Analysis & Modeling)の略である
- ビジネス上の出来事から要件分析してテーブルを設計していく
- 結果としてスタースキーマ(真ん中にファクトがあって周りにディメンションがある形)を作る
- スタースキーマは星型に見えるのでスターと呼ばれる
- ステイクホルダーと協力しながらブレインストーミングを行ってデータモデリングを進めるアプローチである
- このモデリングは使う人向けのテーブル設計である
- この本ではモデルストーミングと呼んでいる
- BEAMテーブル:
- どんなデータが欲しいのかを具体的に書いていく
- この人がこれをいつここで買ったみたいな情報が欲しいというのをずらっと実際に書いていく
- なるべく具体的に書いていく
- 最大で10年前まで遡りたい、最短で翌日にはデータを使いたい、物販と自社のECと外部ECまで分析したいなどの要件が見えてくる
- 元のデータベースは違う可能性がある(物販の店舗だとPOSレジにデータがある、自社のECと外部ECでデータベースも違う)
- データをどこに保存するかというモデリングをするとこれらはバラバラになるはず
- しかし使う側からするとこれらはまとめて分析したいので同じディメンションに入れる必要がある
- この差が見えてくる
- クリエイト(作成)やアップデート(更新)をするのとは別にリード(読み取り)に特化したモデルがあるだろう
- そのためにはその要件を顕在化するにはどんな風にデータを使いたいんですかというところの分析をする人がどんなデータが来るといいのかという具体例を書いていくことによって隠された要件を暴り出していく
- イベントマトリックス:
- ファクトとディメンションをマトリックスで書いていく
- 縦にディメンション、横にファクトを書いて、その組み合わせをチェックしていく
- これらを使って定期的なミーティングでこれらの中間成果物を更新したりしながら、次はこれを整備していこうかというTODOリストを作ってそれを対応していくサイクルを回していく
- これをアジャイルのプラクティスに沿ってやっていくことによって変化に対応していく
- これがアジャイルデータモデリング(原書タイトル:アジャイルデータウェアハウスデザイン)でアジャイルという言葉を使っている理由である
■ 9. ファクトのモデル化
- 分析対象の構造を確認する:
- ビジネスの構造、業務フロー、業務の流れ、ユーザーの行動などをまず把握していく
- ファクト(集計対象、トランザクションファクト)は以下に分けられる:
- 出来事
- 指標
- 計算方法
- ビジネスイベントの洗い出し:
- モデル化した図からビジネスイベントを洗い出す
- 来店して注文して発送して返品するみたいな流れがある
- 注文と呼ばれるビジネスの中にも指標がある(件数、人数、商品数、金額など)
- さらに計算方法もメリットがあるかもしれない(合計値、1人当たりの注文件数、1商品あたりの注文件数、YoY(去年に比べて今年がどのくらい増えているか)、増加率、増加数など)
- ビジネスイベント:
- ビジネスにおいて発生する出来事である
- この1つ1つのビジネスイベントが繋がってビジネスは実現される
- ビジネスを改善するのはこの1つ1つのビジネスイベントを改善することとニアリーイコールである
- 例:来店を増やす、注文を増やす、発送を早くするなど
- 指標:
- ビジネスイベントを定量的に評価するための指標を定める
- イベントがどうなって欲しいか、どうなると困るかを見ていくと決まるはず
- 件数、人数、商品数、金額、時間、距離など
- 多い少ない、長い短い、重い軽いなどの観点がある
- 計算方法:
- 注文の中にも合計、1人当たり、1品あたりといったものがある
- 場合によってはツールに任せるケースもある
- テーブルとしてモデルに反映するのか、ツールに任せるのかはやり様がある
■ 10. ディメンションのモデル化
- ディメンションは5W1Hで考えると分かりやすい:
- 誰が、何を、いつ、どこで、なぜ、どのように
- ビジネスにおけるデータ分析の場合、分析軸5W1Hで比較することが多いから
- 例:都心の店舗は郊外の店舗よりも客が多い(Where)、今年は去年より注文が増えている(When)、バッグは靴よりも平均単価が高い(What)
- どんな軸で分けて比べるのかを洗い出していく必要がある
- 洗い出しのヒント:
- 業務フローから洗い出すパターン:
- 誰が何に対してどんな作業をいつするのかが見えてくる
- 店頭スタッフという人がいて、各商品の在庫があって、毎日20時お店が閉まった後に棚卸しをするなどが見えてくる
- スタッフ別の切り口で分析をするかもしれない、商品ごとや在庫ごとに分析をするかもしれない、閉店後か閉店前かによって分析の軸が変わってくるなどが見えてくる
- 具体例(レコード)から洗い出すパターン:
- 同じ商品AとBがあった時に両方とも衣類という共通点がある場合、商品カテゴリー「衣類」がある
- サイズで言うと同じ衣類でも夏物と冬物がある場合、販売時期という観点で見ていくとポイントがあるかもしれない
- 一般的に冬物の方が重くて値段が高かったりすることが多い
- 同じレコードの中のレコードの共通点や差異点を言語化していくと、そこがそのまま切り口になっている可能性が高い
- 階層図:
- 同じ商品でもカテゴリーもあればサブカテゴリーもある
- 衣類があれば衣類の中に夏物というカテゴリーがあるかもしれない
- 価格帯も1円単位の価格よりは1万円単位でまとめるとか
- ユーザーや人間も性別と年齢がある
- 性別と年齢は相互に連動しない概念である
- ただし年齢「◯◯歳」と「◯◯代」はここは階層の粒度がより荒いのと細かいのになっている
- 25歳と20代は粒度の関係になっている
- 荒い方から細かい方に直すことはできないが、細かい方から荒い方に丸めることはできる
- 20代から25歳は言えない(26歳かもしれないから)が、25歳は20代であることは言える
- 細かい方で持っておけば荒く出すことはできる
■ 11. ディメンションテーブルの具体的設計
- 商品ディメンションの作り方:
- 使う側が便利なExcelを作ろうとしたらどうなるか
- 正規化しない状態でどうやって作るか
- 価格という1円単位の列があった後に価格帯1万円単位という列も作っておく
- 27円みたいなのが次は「1万円台」という値が入る
- カテゴリーとサブカテゴリーがあるなど
- 横に必要な粒度で集計できるように1番細かい状態を持たせておきながら、必要な粒度があるんだったらそれも集計できるようにしておく
- カレンダーディメンションの考え方(よくある質問):
- 8月1日13時29分11.55秒をディメンションテーブルでどうやって切り出すか
- ディメンションは単に5W1Hで切ったものではなく、あくまで分析軸である点がポイント
- 0.55秒であることを軸にして何かカウントしたいか集計したいか→大抵の場合ノーである
- たまに工場の産機器や自動車の機器が特定の時にだけ変な挙動をする可能性もあるかもしれないが、それは分析定義はアドホックで都度個別的にクエリを書いた方が良く、毎月毎月Excelシートで役員たちがモニタリングをするのとは違う
- これであればテーブルとして用意するのではなく都度仮説があったらデータを直接見る方がいい
- 8月1日であることを軸にしてカウントしたいか→イエスである(ケースバイケースだが、こういったケースが多い)
- 日付からロールアップして、8月は例年売上が高い、この月曜日は、夏は毎年こうだ、この曜日は毎週こうだという特徴があるかもしれない
- 8月1日を軸にしてこういったいろんな属性をつけていくことはあり得る
- カレンダーディメンションを作っておいて日付ごとに1レコードのテーブルを作っておくのは1つのプラクティスとして有効である
- 13時であることを軸にしてカウントしたいか→三角(UELか)くらいである
- 飲食店だったらこの昼の時間帯や13時代の客数を集計したくなる可能性はある
- シフトを決めるのにどのくらい来るのかによってシフトを決める必要があるから
- 大きな経営計画を立てる時にざっくりとした推定を行うにはこういった情報があった方がいいかもしれない
- ただしこれは8月1日とは関係なくはないかもしれないが、ちょっとまた別の文脈である
- やるとしたらカレンダーディメンションとは別に時計ディメンションを作っておいて日付を付与しないで何時何分だけ持たせるのが1個テクニックとしてはある
- 分析の粒度でこれを本当に1時間単位にするか、細かく1分単位にするか、10分単位や30分単位にするかは分析の粒度に合わせて調整していくのが現実的である
- 5W1Hに囚われるというよりは分析軸を意識して設計する
■ 12. アジャイルデータモデリングの必要性①チームの変化
- チームが変わるからデータモデリングを変えていくことが大事である
- 仮想ケースの例:
- 刑人(経営者):データをモニタリングできるようにしたい
- コンサルタント:ERPを整備しよう、収支や在庫などの経営資源を管理するのが重要
- 取締役:リソース調整はできるようになったが、もうちょっとビジネスを成長させるための中身の話をしていきたい
- 事業部長:うちのメインの事業、Web経由の申し込みで結構予算達成が左右される、ここを見た方がいいんじゃないか、事業成長のエンジンをウォッチするのが大事
- マーケティング担当:アクセス解析ツールで見ましょう、どこの工程で止まっているのか、どの経路が活発なのか見よう
- 経路5はすごく調子がいい、経路3は割と早々に工程2で止まってしまう
- 経路3は一旦捨てて経路5に集中しようという会話ができる
- この日人気YouTuberが商品言及してくれた、SNSですごい話題になった
- アクセス解析ツールを見ると指名検索(商品名で検索してきている)であることしか分からないが、YouTuber効果なんじゃないか
- そしたらもうYouTuberとガンガンコラボしたり広告出した方がいいんじゃないか
- SNSの投稿なども含めていろんな関連データを社内外横断して見たい
- それをできれば社員全員がモニタリングしてどんどん仮説を回していきたい
- データエンジニアやソフトエンジニアがそういった基盤を作ってマーケティング担当がこれを見ながら全社員マーケティングやってくぞという動きになってくるかもしれない
- 会社全体で追うべきデータは当初の想定とはだいぶ違ってくる
- チームが何を重視するかは本人たちでも事前には予測できない
- 当然見るべきデータも変わってくる
- 見るべきデータが変わるということは、データをどこに保存するかを一旦置いといて、どうやって見るか、データを分析する時にどういうデータの形式だと使いやすいかという使う側のデータモデルのあり方は少なくとも変わってくるはず
- アジャイルな仮説検証サイクルは大事だが、今どんなデータがあるといいんだっけというのを言語化して、それを実装してデータを整備して分析してまた色々見えてくるので要求が変わってまた反映していくというサイクルを回す
- このデータモデルを継続的に改善するというサイクルを回して要求の変化に対して迅速に対応していく、適用していくのがポイントである
- だからアジャイルデータモデリングである
■ 13. アジャイルデータモデリングの必要性②ビジネスの変化
- ビジネス自体が変わる話をする(仮想ケース、あえて極端な話):
- 自動車メーカーからゲームメーカーに転進することがあるかもしれない
- 乗り物の部品を作っている町工場のメーカーがあった
- 売上は堅調だが物価高等で苦しくなってきた
- 主要販売先や銀行からプレッシャーを受けている
- 反応を拓の位置を下げるために展示会で新素材を体験してもらおう
- デモンストレーションとして体験型の運転シミュレーションゲームをセットで設置した
- ものづくり好きな技術者が最高のクオリティに仕上げてしまった、レベルが高すぎる
- 展示会にゲスト参加した海外の著名人がSNSで言及して世界中で話題になった
- 試しにゲームを販売したら世界中で飛ぶように売れる
- しかも円安でソフト産業は限界利益が少ない、部品に比べて収益率がすごい高い
- 本当に黒字赤字ギリギリみたいな状態だったら部品の利益を超える可能性もある
- 部品メーカーとして20年使えるはずのデータモデルを設計してERPを導入したところが、今ゲームメーカーとしてどんどん伸びている
- どっちかっていうとゲームのプレイヤーの利用状況やSNSで話題になっている箇所、どこがスクリーンショットで取られているのかを分析する方が実は重要になってくる可能性もある
- さらにCG制作会社、芸能プロダクションになってくることもあるかもしれない
- 物の珍しさで最初はゲームが売れたが、徐々に売れなくなってくる
- むしろ他のゲームメーカーからゲーム内の乗り物のCGを作ってくれないかという相談を受ける
- CG制作会社として大活躍、めちゃくちゃ細かいところまで作り込んでいる
- ゲームだけではなくて映像作品、世界中の映像作品でも引っ張りだこになる可能性もある
- 日本のアニメーション映画が全世界でヒットしているというトレンドに乗って、海外のあらゆる映像関係者が注目するような会社になるかもしれない
- CG制作会社としてモニタリングをすることになるかもしれない
- 映画特集のテレビ番組に社員が出演する、社員の対応が結構いい感じで俳優じゃないかということでまた話題になる
- 各局に呼ばれるかもしれない、結果芸能プロダクションとして有名になる可能性も0じゃない
- 芸能プロダクションとしての形態のモデルになってくる
- 実際にビジネスは結構変わっている:
- 旗売機を作っている会社が自動車を作り始める(トヨタ)
- アニメーション映像を作っている会社がテーマパークも作り始める(ディズニー)
- 花札を作っている会社がビデオゲームを作ってストリーミング販売に対応していく(任天堂)
- 広告の雑誌を作っている会社がPOSレジや結婚相談を始める(リクルート、結婚相談はこの間やめることが発表された)
- 専門書の物販を行っている会社がデータセンターを建設する(Amazon)
- 進学塾を提供していた会社がホテルなどの不動産事業に切り替える(四谷と呼ばれる会社)
- フリマアプリを作っている会社が決済アプリを作る(メルカリ)
- メルペイの立ち上げは1年間で決済を立ち上げる、毎週毎週加盟店が増えていく、当然加盟店ごとにスキームや契約のスキームは違うだろうということでめちゃくちゃ大変だった
- 発表者自身がこれを体験したからこそすごく思うことがある
- マーケットやビジネスが変わり続ける
- 10年後、20年後本当に未来を見通せるんだったら皆様今頃億万長者になっているはず
- そうじゃないんだとしたら自分は10年後、20年後読み通せないと思っていた方がいい
- マーケットやビジネスが変わり続けるという中で当然ながら見るべきデータも変わる
- 当然ながらそうするとデータモデルも変わる
- 継続的に要求を見直して設計を見直してモデリングを見直してそれを実装して整備して分析してまたサイクルを回すのが大事である
■ 14. AIエージェントとディメンショナルモデリング
- 生成AIによってデータ分析の自動化がすごい楽になりつつある:
- ジュニアの分析者よりも正確だし、シニアの分析者よりも安いし早い
- クロードデスクトップといったツールでデータを繋いでやっていけばそれっぽいレポートをすぐに作ってくれる
- BIツール上の対話エージェント機能なども提供されている
- 生成AIがデータを正しく使うにはやっぱりデータの整備が必要である:
- 社内の売上テーブルが50個あったらどの売上で分析すればいいか判断できない
- 売上って何なのか(消費税含むのか含まないのか、途中解約ってどうやって計上するのか、年間契約って月で割り算するのか、割引ってどこで引くのか、返金って後で引くのかそれとも遡って引くのか、通販サイトやアプリ決済の場合決済手数料ってどうやって管理するのか)
- 年間契約の場合、ある分析では今年の今月の売上すごい伸びていると報告しても、別の売上別の分析では月割で割り算したら半分になる
- AIが生成した2つのレポートを見比べると今年の今月の売上が10倍近くずれる
- これは話にならない
- ファクトとディメンションのテーブルが用意されているといい:
- ここに売上テーブルがあり、カラムで消費税データを管理すると嬉しい
- ファクトとディメンションのテーブルは用意されている
- この時点でディメンショナルモデルだとAIは理解してくれる
- この形式を見た瞬間に、これはディメンショナルモデリングで作られたテーブルだと気づける
- こういう集計をするにはファクトのこれとディメンションを組み合わせて使えばいいんだろう、集計対象がファクトだろう、切り口がディメンションだろうということに気づける
- このIDの列で結合すればいいんだろうということが判定できる
- 割り算とか消費税抜きとかという列が仮にあると、こういった条件だったらこれを見ればいいんだろうということが見えてくる
- AIが事業年度を多分日本の企業は4月から翌年3月なんじゃないですかって推測するんじゃなくて、事業年度列が既にあったらそれを使えばいい
- 整備されているほどデータ品質が安定する、データの分析の品質が安定する
- そうすると従業員がカジュアルに生成AIに頼れるようになってくる
- 実際の事例:
- MicrosoftのPowerBIというBIツールを使う場合はディメンショナルモデリング(スタースキーマ)を結構前提としている
- コパイロットの機能を使う場合も当然その前提である
- メルカリ社のソラテスという分析のAIエージェントは、ベーシックテーブルと彼らが呼んでいるテーブルに依存して、このテーブルだけは見るようにという整備をしている
- データ活用の課題:
- 活用効果が期待以上となる要因としてデータ品質が日本・アメリカ共に2位として上げられている
- 国内686社の調査でデータ活用の課題として、セキュアな量を備えたデータの取得・整備ができないことが言われている
- オラクルの2020年の調査で、データが細分化されていて使いにくいということを世界のグローバルの670人のテクノロジー部門の上級決定者とCO的な人達のうち73%が答えている
- シングルソースオブトゥルース(信頼できる唯一の情報源):
- ここを見たら一旦ここを見ればいいんじゃない、ここを見たらデータを分析できるんじゃないという信頼できる軸がある���いい
- 全体売上と言ったらこの箱を見る、こういった切り口で見ていくと見れるというのが概念としては必要なはず
- 画面のイメージで言うとポチポチボタン押していくと欲しいデータが取れるになっていると使いやすいはず
- データパイプライン:
- ファクトとディメンションを作るのはいきなりこれで作るんじゃなくて、機関システムなら機関システム、SNSならSNSからのデータ、スクレイピングしたデータなど各データがあるはず
- それをやっぱり一元で前処理をして集計ロジックをかました上でファクトとディメンションを作っていく
- これは使う側(理由側)のモデルとビューに分けるとしたら、こっちがモデルでこっちがビューみたいな感じ
- DDD的に言ったら永続化とプレゼンテーション層と言ってもいい
- 今回はこっち(ファクトとディメンション)の話をする
- これを作るにはこれらのデータを組み合わせて作っていく必要がある
■ 15. 本書で扱わなかった内容
- 今回はエントリーの内容なので取り扱わなかったポイントがいくつかある:
- 実際にファクトとディメンションをどんな風に設計するのか例をいっぱい知りたい
- 今回ファクトが1個あってディメンションが周囲にあるという紹介をしたが、叩いたの関係もあるはず
- マスターの値が変わる場合(ユーザーが静岡から東京に引っ越した場合、そのままマスターを上書きしちゃうと去年の購入が静岡じゃなくて東京に計上されてしまう)どうするのか
- これらの回答は「アジャイルデータモデリング」の本に書いてある