2016-08-15 9 views
2

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

私のモデルでは、datestatusの2つの寸法のみです。測定:特定のステータスの数(ある時間)。

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

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]; 

- このフィールド(ステータスの数)

次に、私は、ファクト表とディメンション表の間の関係を追加します。私はモンドリアンを使用しているOLAPサーバーとして

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 
); 

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]); 

は、それから私は、ファクトテーブルを埋めます。多次元データベースの論理モデルを定義しモンドリアンスキーマ:私は斎宮Analyticsを使用していOLAPクライアントとして

<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> 

enter image description here

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

私は情報に非常に感謝します。ありがとうございます。

答えて

1

ここでの免責事項:私はモンドリアンを使ったことは一度もありません。私がここでお伝えするアドバイスは、キンボールのやり方に密着した一般的なものです。 Mondrianがスキーマにいくつかの特別な変更を必要とする場合は、それを行ってください。


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を削除する必要があります。ステータス名は、非ディメンションのメジャーではなく、そのディメンションのビジネスキーです。

ファクトを移入する場合、通常のパターンはビジネスキーで作業し、ディメンション自体またはルックアップテーブルのいずれかから代理キーを取得し、サロゲートだけでファクトをロードすることです次元を指すキー。


さまざまなテクニックの概要を示すreally handy Kimball guideがあります。コンセプトを調べる最初の場所としても、リマインダが必要なときに参照するのも大変便利です。読んだり保存することをお勧めします。

+1

私は言葉がありません!..このような詳細な答えをありがとう!私は慎重に勉強します...あなたの経験を共有してくれてありがとう!それは私のために非常に重要です。 –

関連する問題