2

リレーショナル データベース (ROLAP) でスター スキーマを使用して、単純な多次元データ モデルを構築したいと考えています。そのために、ファクト テーブルと 2 つのディメンション テーブルを作成します。まず、運用ソースからデータをコピーし、このデータを処理します (簡略化された ETL プロセス)。

date私のモデルでは、との 2 つの次元のみstatusです。測定: 特定のステータスの数 (一定時間)。

時間ディメンション テーブル:

CREATE TABLE [dbo].[tbl_date_dim] (    
    [ID][int]       IDENTITY(1,1) NOT NULL,
    [date_key][int] NOT NULL primary key,
    [Year][int]     NOT NULL,
    [Month][int]    NOT NULL,
    [Day][int]      NOT NULL        
);

tbl_application時間範囲全体 (フィールド ) が格納されているテーブル -- がありますVersionDate。したがって、私がこのように入力している時間ディメンション テーブル:

INSERT INTO [dbo].[tbl_date_dim] 
    ([date_key], 
    [Year], 
    [Month], 
    [Day]) 
(
  SELECT DISTINCT
    CAST(YEAR(VersionDate) as VARCHAR(4)) + 
    RIGHT('00' + CAST(MONTH(VersionDate) as VARCHAR(2)) ,2) +
    RIGHT('00' + CAST(DAY(VersionDate) as VARCHAR(2)), 2) as 'date_key',
    YEAR(inner_data.VersionDate)    as 'Year',
    MONTH(inner_data.VersionDate)   as 'Month', 
    DAY(inner_data.VersionDate)     as 'Day'
  FROM (
        SELECT 
            VersionDate 
        FROM [dbo].[tbl_application]
  ) AS inner_data
);

ステータス ディメンション テーブル: 既存のテーブル全体を使用しますtbl_applicationstatus。

次に、ファクト テーブルを作成します。ディメンション テーブルとメジャーへの外部キーが含まれています。

CREATE TABLE [dbo].[tbl_olap_fact] (
    [ID][int] IDENTITY(1,1) NOT NULL,    

    [status_id][int] NOT NULL,           // FK  
    [date_dim][int] NOT NULL,            // FK

    [staus_name] varchar(100) NOT NULL, // Non additive measure
    [transaction_id][int] NOT NULL,     // Additive measure

    CONSTRAINT [PK_tbl_olap_fact] PRIMARY KEY CLUSTERED
(
    [ID] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY];

transaction_id- 集計するこのフィールド (ステータスの数)。

次に、ファクト テーブルとディメンション テーブルの間にリレーションシップを追加します。

ALTER TABLE [dbo].[tbl_olap_fact] ADD CONSTRAINT [FK_tbl_olap_fact_tbl_date_dim] FOREIGN KEY([date_dim])
REFERENCES [dbo].[tbl_date_dim] ([date_key]);

ALTER TABLE [dbo].[tbl_olap_fact] ADD CONSTRAINT [FK_tbl_olap_fact_tbl_applicationstatus] FOREIGN KEY([status_id])
REFERENCES [dbo].[tbl_applicationstatus] ([ID]);

次に、ファクト テーブルに次のように入力します。

INSERT INTO [dbo].[tbl_olap_fact] 
    ([transaction_id], 
    [status_id], 
    [staus_name], 
    [date_dim]) 
(
  SELECT DISTINCT
    core.id          as 'transaction_id',
    core_status.ID   as 'status_id',
    core_status.name as 'status_name',
    CAST(YEAR(core.VersionDate) as VARCHAR(4)) + 
    RIGHT('00' + CAST(MONTH(core.VersionDate) as VARCHAR(2)) ,2) +
    RIGHT('00' + CAST(DAY(core.VersionDate)   as VARCHAR(2)), 2) as 'date_dim' 
  FROM 
    [dbo].[tbl_application] as core
        inner join tbl_applicationstatus as core_status
         on core.ApplicationStatusID = core_status.ID
  WHERE IsRaw = 0
);

OLAP サーバーとして Mondrian を使用しています。多次元データベースの論理モデルを定義するモンドリアン スキーマ:

<Schema name="olap_schema">
  <Dimension type="TimeDimension" visible="true" highCardinality="false" name="Date first dim">
    <Hierarchy name="date_hierarchy" visible="true" hasAll="true" primaryKey="date_key" description="">

      <Table name="tbl_date_dim" schema="dbo">
      </Table>

      <Level name="" 
            visible="true" 
            table="tbl_date_dim" 
            column="Year" 
            nameColumn="Year" 
            type="Numeric" 
            uniqueMembers="true" 
            levelType="TimeYears" 
            hideMemberIf="Never" 
            description="">         
      </Level>

      <Level name="" 
             visible="true" 
             table="tbl_date_dim" 
             column="Month" 
             nameColumn="Month" 
             ordinalColumn="Month" 
             type="Numeric" 
             uniqueMembers="false" 
             levelType="TimeMonths" 
             hideMemberIf="Never" 
             description="">
      </Level>

      <Level name="" 
             visible="true" 
             table="tbl_date_dim" 
             column="Day" 
             nameColumn="Day" 
             ordinalColumn="Day" 
             type="Numeric" 
             uniqueMembers="false" 
             levelType="TimeDays" 
             hideMemberIf="Never" 
             description="">
      </Level>

    </Hierarchy>
  </Dimension>

  <Dimension type="TimeDimension" visible="true" highCardinality="false" name="Date second dim">
    <Hierarchy name="date_hierarchy" visible="true" hasAll="true" primaryKey="date_key" description="">
      <Table name="tbl_date_dim" schema="dbo">
      </Table>

      <Level name="" 
             visible="true" 
             table="tbl_date_dim" 
             column="Year" 
             nameColumn="Year" 
             type="Numeric" 
             uniqueMembers="true" 
             levelType="TimeYears" 
             hideMemberIf="Never" 
             description="">
      </Level>

      <Level name="" 
             visible="true" 
             table="tbl_date_dim" 
             column="Month" 
             nameColumn="Month" 
             ordinalColumn="Month" 
             type="Numeric" 
             uniqueMembers="false" 
             levelType="TimeMonths" 
             hideMemberIf="Never" 
             description="">
      </Level>

      <Level name="" 
             visible="true" 
             table="tbl_date_dim" 
             column="Day" 
             nameColumn="Day" 
             ordinalColumn="Day" 
             type="Numeric" 
             uniqueMembers="false" 
             levelType="TimeDays" 
             hideMemberIf="Never" 
             description="">
      </Level>

    </Hierarchy>
  </Dimension>

  <Dimension type="StandardDimension" visible="true" highCardinality="false" name="Status dimension">
    <Hierarchy name="status_hierarchy" visible="true" hasAll="true" primaryKey="ID" description="">
      <Table name="tbl_applicationstatus" schema="dbo">
      </Table>
      <Level name="" 
             visible="true" 
             table="tbl_applicationstatus" 
             column="Name" 
             nameColumn="Name" 
             type="String" 
             uniqueMembers="true" 
             levelType="Regular" 
             hideMemberIf="Never" 
             description="">
      </Level>
    </Hierarchy>
  </Dimension>

  <Cube name="enrollment_cube" caption="" visible="true" description="" cache="true" enabled="true">
    <Table name="tbl_olap_fact" schema="dbo">
    </Table>

    <DimensionUsage source="Date first dim" name="X axis" caption="" visible="true" foreignKey="date_dim" highCardinality="false">
    </DimensionUsage>

    <DimensionUsage source="Date second dim" name="Y axis" caption="" visible="true" foreignKey="date_dim" highCardinality="false">
    </DimensionUsage>

    <DimensionUsage source="Status dimension" name="Z axis" caption="" visible="true" foreignKey="status_id" highCardinality="false">
    </DimensionUsage>

    <Measure name="TotalCount" column="transaction_id" aggregator="count" caption="Total" visible="true">
    </Measure>

  </Cube>

</Schema>

OLAP クライアントとして、Saiku Analytics を使用しています。

ここに画像の説明を入力

基本的に、私は正しいデータを取得しますが、よくわかりません。たとえば、ファクト テーブルにデータを入力するために使用する方法は正しいでしょうか。ETL プロセスを適切に構築していますか? これはテスト モードであり、データ ウェアハウスと多次元モデルの構築でいくつかの実験を行っています。

4

1 に答える 1

0

ここでの免責事項: 私はモンドリアンを使用したことがありません。ここでのアドバイスは一般的なものであり、キンボールのやり方に忠実です。モンドリアンがスキーマに特定の変更を必要とする場合は、それを選択してください。

tbl_date_dim

これは良い出発点です。日付ディメンションは重要です。別の時間ディメンションも必要になる場合があります (たとえば、時間ごとに見たい場合など)。

これを行うには、ID 列を削除します。それはどのような目的に役立ちますか？各 YYYYMMDD 値は一意であり、ここでの標準的なパターンは、そのテーブルの代理キーとして単純に使用することです。

おそらく、このテーブルにも列をいくつか追加したいと思うでしょう。今のところ、実際の日付を含む日付列を追加することをお勧めします。これは、このディメンションのビジネス キーであるためです。各ディメンションには常に代理キーとビジネス キーの両方が必要です。

ビジネス キーという用語にまだ慣れていない場合は、ビジネス キーの概念を読んでください。これは基本的に、組織が特定のディメンション メンバーを参照するときに使用する意味のある名前であり、多くの場合、何らかの名前です。無意味なコードやソース システムの役に立たない省略形を使用するという間違いを犯す人がよくいますが、これらは本当に避けるべきです。

tbl_date_dim を別の方法で入力することをお勧めします。確かに、あなたのやり方は今のところうまくいきますが、日付ディメンションは他の多くのテーブルから参照されることになり、必要な日付が欠落していることに気付くかもしれません. 標準的な解決策は、これをスクリプト化するか、スプレッドシートをまとめてインポートし、過去と未来に適切な範囲の日付を含めることです。決して大きいわけではないので、サイズは問題ありません。スクリプトを作成したい場合は、少し検索するだけで、その作業を行うスクリプトを見つけることができるはずです。

tbl_applicationstatus

DDL を表示しないため、これについてコメントするのは困難です。ただし、ソース テーブル全体を使用するべきではありません。データ ウェアハウスで作成された代理キー (ID 列で問題ありません。application_status_key のような名前を付けます) とビジネス キーがあることを確認してください。これはおそらく status_name です。

tbl_olap_fact

ファクト テーブルは、同じ粒度の 1 つ以上のメジャーであり、ディメンション テーブルへの外部キーである必要があります。グレインを理解することは非常に重要です。グレインとは何かを考え、それを反映する意味のある名前をその事実に付ける必要があります。たとえば、ファクトにトランザクションに関連するメジャーが 1 つ以上ある場合は、tbl_transaction_fact が適切な名前になる可能性があります。

tbl_application ソース テーブルにあるデータが説明されていないため、ここで何を測定しようとしているのかが少し不明確ですが、特定のアプリケーション ステータスがあった間に実行されたトランザクションの数をカウントしようとしているようです。設定？ここには実際には追加の手段がないことに注意してください。加法的尺度は合計できるものです - 金額、項目数など。

例としてこれを行っているだけの場合は、最初にキューブに答えてもらいたい質問について考えることを強くお勧めします。これには、追加的なもの (つまり、「1 月に作成されたすべてのアプリケーションの価値はいくらか」という行に沿ったもの) が含まれます。 ?" アプリケーションに金銭的価値がある場合)、その質問に答えることができる何かをモデル化します。

絶対にカウントすることもできますが、ソースの transaction_id 値をインポートする必要はおそらくありません。ID 列をカウントするだけでかまいません。

status_name をファクト テーブルから削除する必要があります。これは、ステータス ディメンションにリンクし、そこから name 列を使用して取得する必要があるためです。ステータス名は、非加法的メジャーではなく、そのディメンションからのビジネス キーです。

ファクトを入力する場合、通常のパターンは、ビジネス キーを操作してから、ディメンション自体またはルックアップ テーブルから代理キーを取得し、代理キーを指し示すだけでファクトをロードすることです。寸法。

さまざまなテクニックの簡単な概要を説明する、非常に便利な Kimball ガイドがあります。概念を調べるための最初の場所としても、リマインダーが必要なときに参照するためにも非常に便利です。一読して保存することをお勧めします。

于 2016-08-16T16:12:34.393 に答える