【海外厳選記事】第1回「データの価値を解き放つ」

2023年6月1日　チャーリー・グアリーノ

DB2 for iのコンサルタント、ジョン・ウェスコット氏が次元モデルのビジネス上の利点について語ります。

チャーリー・グアリーノ（以下、チャーリーと略します）：
皆さんこんにちは、チャーリー・グアリーノです。TechTalk　SMBにようこそ。今日は、Db2 for iのコンサルタントであるジョン・ウェスコット氏をお迎えし、次元モデルについてお話する予定です。ジョン、来てくれてありがとう。

ジョン・ウェスコット（以下、ジョンと略します）：
ありがとう、チャーリー。出演できて光栄です。

チャーリー：
前回、次元モデルの話になりましたが、その話題はとても魅惑的で、皆が聞く必要があると思いました。なぜなら、既存のデータから価値を引き出す方法が沢山あるのに、人々はこのデータの価値に気づいていないか、そこから最適なデータ価値を理解するための良い方法を、適切に使っていない可能性があるからです。まず、次元モデルを知らない可能性のある人達のために、次元モデルとは何なのかを教えてください。

ジョン：
次元モデルは、ビジネスに携わる人々が容易に利用できるように、データを別の形に変形する方法です。「ビジネスに携わる人々」は判断を行う人々であり、ビジネストランザクション用に最適化されたリレーショナルデータベースや、それに伴う規則を理解するつもりはありません。しかし、ビジネス上の意思決定に関して、正確で利用可能なデータに彼等がアクセスできるようにする必要があります。この正確で利用可能なデータは、彼等の手段に適した、たった一つの真実の源である必要があります。彼等はどの表がアクセスする必要のあるものか心配するつもりはなく、単に「何々についてあることを実行しなさい」と言うためのモデルを求めるでしょう。

チャーリー：
このビジネス上の意思決定を行う人達はエンドユーザーであり、必ずしもIT的な技術を理解しているとは限りません。

ジョン：
彼等はビジネスユーザーで、明らかに実際のビジネス決定を行う人達です。「どの製品を買うべきか? あるものをビジネスに導入するべきか? 店を開くべきか?それを実施するべきか?」などはビジネス上の決定であり、彼等によってなされるべきです。

チャーリー：
目標は、多分ユーザーにとってもっと問い合わせに使える形にデータを変形することのようですね。

ジョン：
その通りです。データを違う形に変える必要があります。現在のデータは第3正規形、つまり伝統的なタイプのデータベースです。従来のタイプのデータは、大量のトランザクションを高速処理するためのものです。これらすべてのデータは、必ずしもいつもそこから容易にビジネス上の決定を行う何かに翻訳されるわけではありません。ですから、私はこれらのデータすべてを分解し、ユーザーが技術的な観点による私達の言葉ではなく、彼等の言葉でアクセスできる、違うものに見える何かにまとめ直したいのです。

チャーリー：
これらはデータウェアハウスを用います。

ジョン：
そのとおりです。データウェアハウス、データマート、オペレーショナルデータソース、それら優れたものすべてを使います。

チャーリー：
私達は文字通りデータの複製について話していますが、私は複製と厳密なコピーは違うと考えています。複製はデータの別な形式のことで、モデルが参照しているのはそれですか?

ジョン：
そのとおりです。それは単なるコピーではなく、多分高可用性という理由で複製されたものである可能性があります。システムAにデータがあり、それと厳密に同じものをシステムBに複製したとします。それは同等とは言え、少し違います。表のレイアウト、スキーマ、表の間の関係は変わりません。私達が話しているのは、この情報を取得し、それを予め集約された形で伝えているという事です。月次の合計値を知るのはとても大変な事です。もし、過去12か月の毎月の月次合計がどうであったかを計算するために、ユーザーが何千、何万というレコードを合計しなくても済むように、月次合計を既に集計していたらどうでしょうか? 1日を締めたときに、ビジネスの実績はどうだったでしょう? この情報はすべてトランザクションデータベースで利用可能ですが、それはビジネスユーザー向けの適切な形になっていません。

チャーリー：
長年この仕事をしてきた中で、見えてきた問題の1つは、エンドユーザーに責任が負わされる場合があるということです。データベースに関するもっと詳細な知識は、彼等の守備範囲外で荷が重すぎます。エンドユーザーには複雑過ぎることが時々あり、それが原因でプロジェクトが前に進まないこともあると思います。次元モデルはそれを救うでしょうか?

ジョン：
そのとおりです。つまり、私達がやろうとしているのはデータを取得することだからです。私達はデータを取得して、何か新しいものを作っています。ケーキを焼いているとしましょう。牛乳、卵、小麦粉、チョコレート、その他何でもあります。ケーキを作る場合、これらのものを一緒に混ぜます。これがトランザクションデータベースです。あるいは似たような種類の材料を使って、異なる方法で混ぜるかもしれません。沢山のブラウニーかマフィンを作り上げるつもりです。それが、私達がここでやっていることです。生の小麦粉を食べたい人はいませんが、チョコレートケーキは誰でも食べたいと思うでしょうから。私達はビジネスで利用できるようにデータを再構築しているのです。

チャーリー：
経理担当のサリーというのは、私達が別の会話で使用した仮想の人物です。彼女には、例えば財務分析を行うという要件があります。私達は彼女に総勘定元帳テーブルを理解する責任を押し付けたくありません。テーブルはもっと使いやすい形式でなければなりません。つまり、正規化されたデータについて心配する必要がないという点でこれは完璧な使用例です。

ジョン：
そうです。彼女は正規化されたデータが何であるかさえ気にするべきではありません。彼女の仕事を助けるために何をすればよいでしょうか? 彼女にスプレッドシートを渡し、それを使って必要なことを何でもしてうまくやってくださいと言います。そして彼女は分析を実行し、そのスプレッドシート内のデータを揉みほぐし、チャート、グラフ、要約など、それをベースに加工したものにします。そういった類のものは、すべてデータウェアハウスで入手可能であるべきです。では、次元モデル、データウェアハウス、またはある種のデータマートの適切な使用例は何でしょうか? スプレッドシートを探してください。なぜなら、それは現在すべての決定がオフラインで行われている場所だからです。経理担当のサリーは自分のスプレッドシートを持っており、経理担当のボブも自分のスプレッドシートを持っています。何が起こると思いますか? 同じ答えは得られません。おそらく、ボブは今朝自分のスプレッドシートを実行し、サリーは5分前に自分のそれを実行したからでしょう。ビジネスが進み、データは変化しました。そのせいで、これらすべてのビジネスユーザーは、本当に適切なビジネス上の決定を下そうとしているにもかかわらず、決定を下す前に誰が適切なデータを持っているかを判断しなければなりません。

チャーリー：
そして真実は、ある時点ではどちらも正しかったということです。

ジョン：
ある時点では、おそらく両方とも正しかったでしょう。

チャーリー：
興味深いですね。再度それを言うならば、「正規化されたデータ」ということになります。正規化されたデータは、開発者として私達が達成しようと努力しているものです。第4正規形や第 5正規形がありますが、第3正規形について話します。最終的に私達は常に第3正規形が着地点として適していると言っています。それはシステムを最も効率的に実行するためのものです。しかし、それはここで説明している内容に最適な設計ではありません。

ジョン：
そうですね。リレーショナルデータベースモデルは私達が開発者として慣れ親しんでいるものですよね? これは、大量かつ大規模なビジネストランザクション向けに最適化されたオンライントランザクション処理です。これらはデータの冗長性を減らすために正規化されており、通常ある種のトランザクションロック指向とコミットメント制御があり、「全員が一つの状態に到達しました。何かをしてください」と指示されます。これらはすべて素晴らしいことであり、激動するビジネスや日常の活動で私達が望んでいることですが、それはユーザーが望んでいることではありません。ユーザーは、何かをすぐに評価して次に進むことができる情報を求めています。彼等は判断をする必要があり、ことによるとそれは素早い判断かもしれません。

チャーリー：
私達は複製するという言葉を使っていますが、これは興味深い言葉です。なぜなら、私は明らかにHA（高可用性）環境でデータを複製するつもりだからです。もしシステムが故障したら、私は直ちにフェールオーバーし、いかなる中断もさせることなくシステムを運用し続けます。それは私達の目標ではありませんが、人々がデータマイニングやその類の話をするのを聞いていると、頻繁に「複製ボックスを動かせ」という発言を耳にします。システムに重い負担を掛けたくないので、HAボックスを動かす。しかし、それは常に最善のアプローチでしょうか?

ジョン：
それが常に最善のアプローチかどうかはともかく、多くの場合それは最善のアプローチです。これらのクエリを、複製されたバックアップマシン上の隔離された環境に直接移動すると、通常そのマシンでは他のアクティビティは実行されなくなります。アイドル状態になっているので、その環境を活用してみてはどうでしょう。独自のプロセッサ、コア、メモリ、ディスクを備えています。そうしない理由はありません。問題はビジネス上の決定に役立つかということです。なぜなら、それは単なるトランザクションデータだからです。私達はそれを加工していません。ケーキ作りの例に戻りましょう。卵、小麦粉、牛乳などは独立しており、ユーザーにケーキを作るか決定するよう求めています。それとも、「ここにケーキがあります。意思決定してください」と言いたいだけですか。分離されたワークロードで実行するのは素晴らしいことであり、それが実際の違いです。バックアップ環境は優れた選択肢ですが、ユーザーが使用できるように適切に構成されていません。

チャーリー：
IBM iのデータを取得したいと考えているという話を時々聞きます。確かに次元モデルの議論はできますが、その後それは別のプラットフォームに移ります。まず頭をよぎる疑問は、なぜ IBM i 上のデータベースにアクセスしないのかということです。

ジョン：
あなたは何を達成しようとしていますか? そのワークロードを他のクラウドデータベースに移動すると何が得られると思いますか? 企業がそれを望んでいるという理由がある場合もありますが、それはいかにして私達がその結論に達したのかとはまったく別の議論になります。場合によっては、複数のソースからデータを集約する必要がありますが、多くの場合、IBM iやDb2は閉ざされており、Microsoftの世界やExcel/Oracle、またはSnowflakeなどに参加できないと私達は考えています。でも確かに、構築した次元モデルにその情報を取り込み、他のソース、他のデータベース、他の外部Webサービスからのデータを使用してその能力を増強できます。天気が良い例です。実際に天気を利用してデータを集約、増強しているクライアントもいます。彼等は店のある場所の天気がどうだったかを知りたがっています。これは分析の良い例だと思います。なぜ店の売り上げが下がったのでしょうか?　その日はモンスーンの雨が降っていました。4月に雪が降ったのですが、予想外だったので店も閉めました。客足が無かったのです。その情報をこの次元モデルの形に増強しなければ、4月に店の業績が振るわなかった理由は掴めなかったしょう。

チャーリー：
設計上適切に正規化されたデータベースは、冗長性を排除し、プログラムが最も効率的に動作するように作成されています。しかし、私達がここで話しているのは、保有しているデータの激増についてです。例えば、100万件の履歴レコードがある場合、次元モデルに変換された後の最終結果は 100 万行をはるかに超える可能性があります。

ジョン：
そうです。なぜなら、行単位で見ていくと、次元モデルを構築するときに見落とすことがあります。それは通常データの良い見方ではありません。1000人の顧客がいて、5000 の製品とこれらすべてのトランザクションがあるとします。通常の月にどのくらいのトランザクションが発生するかを確認できるので、データ量が分かり予測は非常に簡単です。しかし、データウェアハウスでそのデータを再構成する場合、最終的に更に多くのレコードが生成されます。おそらく第3正規形を使用しないので、ユーザーがそのデータを利用し、そのデータの意味を理解するのにもっと効率的な方法で、より多くのレコードが得られることになります。実際、それらは非正規化され、多くの場合もっとフラットなものになります。顧客名、製品、販売取引日をすべて同じ行に配置すると、ユーザーが何を決定するにしても、パフォーマンスが向上するからです。ユーザーが顧客、製品、販売日、販売数量、収益をすぐに把握できることが重要な場合は、そのようにデータウェアハウスを構築します。データのモデル化は、ユーザーが適切な決定をくだすために行うものです。万能のモデルはありません。決定を行う実際のビジネスユーザーから情報を得て、そのニーズに合わせてデータをモデル化する必要があります。

チャーリー：
それはDASDの追加に繋がります。

ジョン：
DASD を増やすことになりますが、あなたが心配するべきこと、あるいは本当に考慮したいことは、即時にアクセスできたお陰で10万ドルの節約や、何らかの形の純利益につながる1つのビジネス上の判断ができるユーザーが1人いるかどうかだと思います。DASDは元が取れたでしょうか? 間違いなく元は取れたし、それを10人がしていれば確かにそうなりました。

チャーリー：
それゆえ、ROI が非常に早く高まります。ですから、これをしないという議論は、短期的にはとても説得力に欠けると思います。

ジョン：
そうです。私達はIBM iコミュニティの隅っこに閉じ籠もり、状況を改善しようと努めてきました。私はよく人々に「履歴ファイルを持っていますか?」と言います。答えが「はい」なら、ある種のデータウェアハウスに順調に足を踏み入れています。もしかしたら、それは適切に形作られていないかもしれませんし、次元モデルに変形する必要があるかもしれませんが、少なくとも正しい方向を向いています。そして、そのデータを変更したり増強したりする場合、履歴テーブルに入れる日付は文字データではなく、日付型データにしたいです。このようにデータの変換が少しずつ起こります。現在は運用向けのデータストアを構築しているのかもしれませんが、これらの小さくて単純な作業を行うだけで、データウェアハウスという明るい出口に実際に慎重に近づいています。

チャーリー：
では、この点についてもう少し詳しく見てみましょう。履歴データについて話しましたが、それは良い出発点です。良い使用例を教えてください。私が経理担当者で、会社の財務上の決定を下そうとしているとして、それについて説明してください。私には財務履歴テーブルがあり、経理担当のサリーがより適切な決定を行えるようにしたいと考えています。ある種の次元モデルを使用します。まずサリーと話し、ここからどのような情報を得ようとしているのか調べるつもりです。あなたの最終的な目標は何ですか? それがそのためのロードマップですか?

ジョン：
そうです。私はいつも、ユーザーのニーズを聞き出すために彼等の所に行き、彼等のニーズが何であるかを知る必要があると説いています。なぜなら、多くの場合それが何であるか分からないからです。相手が何を必要としているか推測して分かっているつもりでも、実際に話してみるとまったく異なるタイプのものが得られます。私達は片側にIT 脳をもち、そしてその反対側にビジネス脳をもっていると私は考えています。そして何年も、何十年もかけて、それらの脳は互いに接近してきました。しかし、最後の僅かな部分にそれらを持ち込んで結合し、同期させる必要があります。すべてはデータに関するもので、彼等が必要とする情報を入手できれば、それがどの部門の誰であろうと、企業は投資に対する効果を得られるでしょう。それはデータであり、データはビジネスを推進します。多くの場合、私達は技術者として、何がより優れたアプリケーションなのか悩みます。RPG? SQL? それともNode.js または Java を使用する? それは関係ありません。ビジネス上の決定を行わせるのはアプリケーション言語ではなくデータです。

チャーリー：
あなたが今言ったことに対して私が言いたいポイントはそこでした。効率的で有用なデータウェアハウスを構築するという目標を達成するのに、孤立していてはそれはできないし、そうするべきではありません。ビジネスエンドユーザーと協力して、より良いバージョンのデータを作成する必要があると思います。データの正しいバージョンというのは適切な言葉ですか?

ジョン：
ええ、私はバージョンの代わりにモデルという言葉を使用しますが、そうです。これは私達が構築したいモデルであり、それを単独で行うことはできません。私達はビジネスが本当に必要としているものを理解する必要があります。そしてそれはおそらく経理担当のサリーであり、おそらく他の数人であり、これらの人々全員を集めて、彼等が何を達成しようとしているのかを本当に理解する必要があります。何がビジネスを進展させるでしょうか? そして、それが何であるかが分かれば、それをモデル化し、データを使用して何らかの方法で形にすることができ、おそらくそのモデルは成功するでしょう。そうなると、時間をかけて別のモデルを作成する必要があるかもしれませんね? 私達は新しい問題を学び直し、それらの新しい問題を解決するための新しいモデルを開発する必要があります。一度やったらすぐに終わってしまうようなものではありません。それは継続的に進化するタイプの状況です。

チャーリー：
つまり、いわば生き物です。

ジョン：
そのとおり、生き物です。データは生きた実体であり、時間の経過とともに成長します。ビジネスの一部の問題が解決し、これ以上解決するべき問題がなくなることで、ビジネスのこの小さな部分が消滅することがあります。おそらく、その小さなデータモデルは時間が経つにつれて衰退し、廃止され、新しいモデルがそれに取って代わるでしょう。

チャーリー：
最初に私は財務分析について考えましたが、実際には、そこから得られるものの範囲は事実上無制限です。製造現場、流通、サプライチェーン、その他のビジネスの側面に目を向けない理由はありません。

ジョン：
まさにその通りです。例を挙げましょう。私は 2つの異なるクライアントから電話を受け、多数の出荷を逃した彼等の荷物について洞察を得る方法を話したいと考えていました。彼等はなぜこれらの出荷がうまく行かないのかを理解する必要がありますよね? 根本的な原因は何でしょうか? 彼等はデータを持っていましたが、それは非常に入り組んでいました。これらのクライアントの1つは、System/36に起源をもつレガシーシステムを有しており、長年引き継がれてきた多くの悪いデータベース設計が残っています。それでも最終的には、これらの荷物がどこにあるのかを把握し、管理する必要がありました。このような出荷遅れや、出荷忘れの原因は何でしょうか? データをモデル化しなければならず、出荷に問題があることが分かりました。データを取り出して集計し、理解するべき情報のタイプや事実が何であり、これらの事実を調べるにはどのような視点やカテゴリーが必要かを考えます。これらが何であるかを理解したら、「この種の情報を得るにはおそらくこれが必要だろう」という話を始めることができました。

チャーリー：
この対談の前に、他の使用例を調べましたが、結果は非常に興味深いものでした。それはヘルスケアですが、これはまったく別の巨大な業界で、サプライチェーン分析、ソーシャルメディア分析、不正行為検出、在庫管理、人事など事例のリストは限りないようです。

ジョン：
ええ、これらはすべて結びついているので、私はそれを主要な質問として取り上げています。それは生きた文書です。それは変化し、進化し、成長しており、これらすべての情報を把握する必要があります。世の中にはこの種のものが存在しており、それを怖いと思う人もいます。こうした人工知能や機械学習が存在しますが、僅かでもそれに懸命に取り組み、私達に展望を与える分析への洞察を得ることができます。もしかしたら、尋ねる必要があると思っていなかった質問に対する答えが得られるかもしれません。それはすべてデータを通じて集められますが、集められる先はビジネス上の選択が意味を持つ場所でなければなりません。

チャーリー：
実稼働環境で実行されている1つのデータセットから、データの非常に多くの異なる側面が生み出されるように思えます。

ジョン：
そうです。ですから、通常データの次元を設定するときは、具体的なニーズを検討し、次元に基づいてファクトと呼ばれるものを構築します。これは伝統的なスタースキーマです。私達はおそらく何年にも渡って、真ん中に１つの言葉が書かれた五芒星の絵を見てきました。それが事実であり、各点は、このデータをスライス、ダイスに切り分けて見ることのできるさまざまなカテゴリーであり、その星を中心とする次元です。ですから、通常特定の種類の質問に答えるために、これらの次元に関連付けられた複数のファクトが存在します。これらのさまざまな事実を結び付け、データに関するより大きな答えやより大きな視点が作成できます。

チャーリー：
そして最終的に、データウェアハウスは必ずしもIBM Db2からのデータだけに依存する必要はありません。それは多くの異なるソースに由来している可能性があります。

ジョン：
ええ、他のソースからデータを取り入れることができない理由はありません。データパイプラインと呼ばれるものがあり、データは場所から場所へ移動し、途中で変換されて最終的な到達点に至ります。私達はそのパイプラインに参加してそのチェーンの単なる歯車になることも、最終地点となってOracle、Snowflake、Azure、Microsoft SQL Serverなどあらゆる場所からデータを取得し、それを私達のウェアハウスに取り込み、データのエンタープライズビューを作成することもできます。

チャーリー：
あなたとの議論から得た大きな教訓は、私達がすでに持っているものから得られる付加価値がたくさんあるということです。重要なのは、より意味のあるものに適切に形を整える方法を知ることだけです。キューブという言葉を耳にしますが、それは適切な言葉ですか?

ジョン：
キューブはデータモデリングといつも一緒で、その大きな部分を占めています。通常キューブは、データについて事前に集計された次元の観点、つまり特定のニーズに対する特定の答えを提供します。

チャーリー：
私が言いたいのは、今こそデータベースに目を向け、エンドユーザーと実際にコミュニケーションを取り、彼等に力を与え、彼等が本当により多くの価値を引き出し、IT部門にあまり依存しなくてもデータベースから価値を得られるようにするには何が必要か理解する時期に来ているということです。

ジョン：
まったくそのとおりです。1年ほど前ある人と話したのですが、その人は「そんなことは必要ない」と言っていました。なぜそれが必要ないのでしょうか? 私は彼等に報告書を出しました。印刷されたコピーではある程度までしかできません。彼等はその印刷コピーを受け取って、それをスプレッドシートに変換するソフトウェアを持っているので、それを使ってやりたいことは何でもできるという感じです。それは私達がもつ必要があると私が信じている視点ではありません。私達は人々にチャートやグラフ、視覚化ダッシュボードなどの情報を簡単に提供できるようにする必要があります。誰もが同じ情報を持っていてアクセス可能です。データサイロ内で12個のスプレッドシートを実行しているわけではありません。誰もが同じ場所に来て、同じ情報を入手し、うまくいけば誰もが同じ決定を下せるようになり、もっと迅速でより良い判断ができるでしょう。それはすべてビジネスにとって良いことです。

チャーリー：
真実の1つのバージョンを使って。

ジョン：
1つのバージョン。唯一の真実の情報源です。

チャーリー：
唯一の真実の情報源。そうですね、ここで氷山の一角に触れたような気がします。私達はおそらくこのテーマについて何時間でも話せると思います。

ジョン：
私は次元モデルが大好きです。データウェアハウスはビジネスにとって非常に重要であり、私達はそれを多く目にしています。Tableau、Snowflake、Azureなどのクラウドデータベースが台頭しています。これらすべてのデータベースが登場しているのは、ビジネスでこの種の情報が必要であり、外部ソースにアクセスできるからです。Azureに移行したいのであればそれは素晴らしいことですが、そうする必要はありません。これはIBM i上で実行でき、IBM i環境のみに参加することも、他のデータベースを含む環境に参加することもできます。私達は情報を自身にもたらすことも、他の人に情報を送ることもできます。

チャーリー：
とても興味深いですね。これは非常に魅力的なテーマであり、人々は自分たちが既にオンプレミスまたはクラウドで実行させているマシンから、より多くの価値を引き出すことができると思います。

ジョン：
まったくそのとおりです。データこそが価値であり、プラットフォーム上には膨大な量のデータ履歴があります。System/36、38、AS/400、iSeries があり、今日ではIBM iですね。私達のシステムには35年分のデータが閉じ込められています。真のビジネス価値を得るには、それを解き放つ必要があります。

チャーリー：
「閉じ込められた価値を解き放つ」ですか。今日のポッドキャストにぴったりのタイトルかもしれません。ジョン、今日は貴重なお時間をありがとうございました。