ディメンションの重複関係による整合性(conformed rollups) ディメンションテーブルの整合性は、テーブルの共有以外によっても担保することができます。以下の条件を持っている場合は、実体として別のテーブルであっても整合性を確保することが可能です。 片…
ディメンションの整合性(準拠性) ディメンションテーブルが横断検索が可能な条件を持っている場合、整合性があるディメンションといいます。（conformedをあえて、「整合性」と表しています）同一のディメンションを利用している場合は当然、整合性があるこ…
同一のディメンションテーブルである必要はない 前回の受注と返品の例において、商品ディメンションテーブルが「同一の構造」「同一の内容」であったとしてもまだ問題が残っています。ディメンションテーブルが完全に同一でないとき、データ互換性の程度を表…
ディメンションテーブルのデータの違い 前回も紹介した図において、商品テーブルのデータそのものについても違いからくる問題点が存在しています。 データフォーマットの違い(商品名と分類) 受注(order)スターの商品(prduct)についての商品名(product name)…
横断分析とディメンションテーブルの関係 業務プロセスを横断して分析をする際の重要な要素となるのがディメンションテーブルです。ディメンションテーブルのデータ保持方法や内容が異なる場合に横断分析が出来なくなることで、お互いのデータによるシナジー…
複数のススタースキーマがもたらす効果 多次元データモデルは個別に作成されることがほとんどです。どのデータウェアハウスアーキテクチャにおいても、全社レベルのデータを完全に考慮(包含)した一つのデータセットを用意するというプロジェクトとは非現実的…
業務プロセス（スタースキーマ）をまたがった分析というのは非常に有用なものといえます。このことは、エンタープライズ、目的別(subject area)データウェアハウスをまたがる検索についても同様です。前回まで業務プロセス（受注、出荷等のプロセス）を中心…
Intermission 今まで以下のような流れで多次元データモデルについてみてきました。インターミッションも兼ねた振り返りをしておきます。 分析システムにおける多次元データモデル www.dbstories.com 多次元データモデルの基本と構成要素についての解説です。…
スタースキーマ横断検索をSQLで一度に取得する場合 方式CはRDMSにおいて処理を実施し、さらに中間テーブルの利用をなくした方法です。この方式は標準的なSQLの新しい拡張機能によって実施可能となります。動作としては、一つのSQLですべてを実施することにな…
スタースキーマ横断検索の実装 これまでに横断検索における考慮点について説明してきましたが、どのように実装していくかというのはまた別の視点が必要となります。自分でコードを実装する場合やBIツールによる自動検索実装化によっても異なります。以下に3…
「スタースキーマの横断検索」 二つのプロセスを比較する分析を「横断検索(drilling across)」と呼びます。この用語自体が混乱を呼ぶこともあります。「ドリル」という用語が使われてはいるのですが、分析ツールなどで利用される「ドリルアップ(drill-down)…
「複数のファクトテーブルを持つ場合における分析方法」 一つ一つの業務プロセスの分析は当然ながら重要ですが、複数のプロセスの比較というのも同様に重要なものといえます。強力で重要な分析として、「業務を横断した分析」があります。例えば、「予測と実…
個別のファクトテーブルを利用した設計 二つのファクトが異なる粒度を持つとき、これらは別々のプロセスであると言えます。これまで見てきたように、このような場合に一つのファクトテーブルを利用した設計を行った場合、どちらか一つに着目した分析を行う際…
異なる粒度を持つファクトテーブル 複数のファクトが異なる粒度を持つ場合、これらは異なるプロセスであると言えます。一つのファクトテーブルに異なるタイミングで発生するイベントを保持する場合、それぞれのプロセスを分析する場合を妨げます。この時、別…
間が空いてしまいましたが、前回の続きになります。 別々にファクトテーブルを保持する設計 「ゆでガエル」となるもう一つの設計方法としてそれぞれのプロセスを個別にファクトテーブルを作成するというものがあります。受注と出荷の例における例を示します…
異なるタイミングでのファクト 同時に発生しない複数のイベントが存在する場合、それらは異なるプロセスであると言えます。それが一つのファクトテーブルで扱われるとき、それぞれのプロセスを分析する際に混乱を生みます。個別のファクトテーブルで扱う方が…
データウェアハウスについての解説記事の4回目です。 前回までの記事 分析システムにおける多次元データモデル データウェアハウスアーキテクチャ スタースキーマとキューブ 参考書籍は以下を利用しています。 Star Schema The Complete Reference作者: Chri…
キューブとデータウェアハウス データウェアハウスアーキテクチャ(1) データウェアハウスアーキテクチャ(2) で紹介した3つのデータウェアハウスアーキテクチャにおいてキューブを利用することができます。 図を再掲しておきます。 1. 多次元データウェアハウ…
キューブ 多次元データモデルはリレーショナルデータベースだけに適用されるものでありません。多次元データベース(MDB [Multidimensional database])においてはキューブ(cube)と呼ばれるフォーマットでデータを保持します。キューブ自体の基本的な考え方は…
緩やかに変化するディメンション(Slowly Changing Dimensions)のType1、Type2利用の考え方について解説を続けます。 Slowly Changing Dimensionのタイプ選択 スタースキーマ設計の重要な要素の一つにディメンションテーブル変更(穏やかに変化するディメンシ…
緩やかに変化するディメンション(Slowly Changing Dimensions)のType2変更について解説を続けます。 Type2変更 データソースとなる業務システムで行われる多くの変更はスタースキーマにおいてType2変更として扱います。Type2変更はファクトの変更履歴を保持…
ディメンションテーブルに保持すべきデータがデータソースシステム（業務システム）において変化した場合に、多次元データモデルでどのように扱うのかというのが「緩やかに変化するディメンション(Slowly Changing Dimensions)」の論点です。 Type1変更 デー…
ここからはディメンションテーブルの履歴保持の方法について解説していきます。 緩やかに変化するディメンション(Slowly Changing Dimensions) ディメンションテーブルのデータは業務システムにより生成されます。多次元データウェアハウスと個別データマー…
前回に引き続きファクトテーブルについて解説してきます。 非正規化ディメンション(Degenerate Dimensions) 分析したい項目はディメンションテーブルに保持するのが原則ですが、現実的に全てのデータを保持することができない場合があります。そのとき、ファ…
前回に引き続きファクトテーブルについて解説してきます。 ファクトテーブルの粒度(Grain) ファクトテーブルの行が表わすデータの精度はデータ粒度(grain)と呼ばれます。多次元データモデル設計においてファクトテーブルの粒度を定義することは非常に重要な…
ファクトテーブル 前回までにディメンションテーブルについて解説してきました。今回からはファクトテーブルについて解説していきます。 ファクトテーブルの特徴 ファクトテーブルはビジネスプロセスそのものを示すもので、適切な単位でデータを保持している…
ディメンションテーブル設計 前回に引き続きディメンションテーブルについて解説していきます。 ディメンションテーブルのデータモデル ディメンション項目はグルーピングしてテーブルにまとめていくことになります。雑多項目については専用のディメンション…
リッチなディメンションテーブル 前回に引き続きディメンションテーブルについて解説していきます。 www.dbstories.com 上記記事で見てきたように、ディメンションとは、「ファクトを「抽出する条件」と「集約する項目」」を意味しています。つまり、ディメ…
データウェアハウスについての解説記事の3回目です。 前回までの記事 分析システムにおける多次元データモデル データウェアハウスアーキテクチャ 参考書籍は以下を利用しています。 Star Schema The Complete Reference作者: Christopher Adamson出版社/メ…
データウェアハウスアーキテクチャの特徴 前回、3つのデータウェアハウスアーキテクチャについて紹介しました。 インモンのコーポレートインフォメーションファクトリ キンボールのディメンショナルデータウェアハウス（多次元データウェアハウス） 個別デー…
