7

データ ウェアハウジングと SSIS/SSAS に関連する場合に、null または空のデータ値を処理するためのベスト プラクティスについて、ご意見をお聞かせください。

異なる行に NULL 値を含むいくつかのファクト テーブルとディメンション テーブルがあります。

仕様:

1) null の日付/時刻値を処理する最良の方法は何ですか? 時間または日付のディメンションに「既定」の行を作成し、null が見つかったときに SSIS を既定の行にポイントする必要がありますか?

2)ディメンション データ内の null/空の値を処理する最良の方法は何ですか? 例: 「アカウント」ディメンションに、アカウント名列に空の (NULL ではない) 値を持つ行がいくつかあります。列内のこれらの空または null 値を特定の既定値に変換する必要がありますか?

3)上記のポイント 1 と同様 - ディメンション列の 1 つにレコードがない Facttable 行になった場合はどうすればよいですか? これが発生した場合に備えて、各ディメンションの既定のディメンション レコードが必要ですか?

4) SQL サーバー統合サービス (SSIS) でこれらの操作を処理する方法に関する提案やヒントはありますか? 最適なデータ フロー構成または最適な変換オブジェクトを使用すると役立ちます。

ありがとう ：-）

4

4 に答える 4

4

前の回答が述べているように、ディメンションの Null 値には、不明、適用不可、不明など、さまざまな意味が関連付けられている可能性があります。アプリケーションでそれらを区別できると便利な場合は、「疑似」ディメンション エントリを追加すると役立ちます。

いずれにせよ、Null ファクト外部キーまたはディメンション フィールドを使用することは避けます。「不明な」ディメンション値が 1 つでもあれば、データ品質が 100% ではない包括的なグループ化を含むクエリをユーザーが定義するのに役立ちます (そして、決してありません）。

私がこれに使用していて、まだ私を噛んでいない非常に単純なトリックの 1 つは、T-sql で int IDENTITY(1,1) を使用してディメンションの代理キーを定義することです (1 から開始し、行ごとに 1 ずつ増加します)。疑似キー (「利用不可」、「割り当てなし」、「該当なし」) は、負の int として定義され、ETL プロセスの開始時に実行されるストアド プロシージャによって設定されます。

たとえば、次のように作成されたテーブル


    CREATE TABLE [dbo].[Location]
    (
        [LocationSK] [int] IDENTITY(1,1) NOT NULL,
        [Name] [varchar](50) NOT NULL,
        [Abbreviation] [varchar](4) NOT NULL,
        [LocationBK] [int] NOT NULL,
        [EffectiveFromDate] [datetime] NOT NULL,
        [EffectiveToDate] [datetime] NULL,
        [Type1Checksum] [int] NOT NULL,
        [Type2Checksum] [int] NOT NULL,
    ) ON [PRIMARY]

そして、テーブルに値を入力するストアド プロシージャ


Insert Into dbo.Location (LocationSK, Name, Abbreviation, LocationBK, 
                      EffectiveFromDate,  Type1Checksum, Type2Checksum)
            Values (-1, 'Unknown location', 'Unk', -1, '1900-01-01', 0,0)

ディメンションのルックアップが失敗した場合に使用される疑似行をディメンションごとに少なくとも 1 つ用意し、例外レポートを作成して、そのような行に割り当てられたファクトの数を追跡することをルールにしました。

于 2009-06-11T20:21:10.480 に答える
1

ご意見ありがとうございます。

最新のプロジェクトで行った 2 つのことは次のとおりです。

1) 不明/特別なディメンション値の負の ID キーに関する Steve の提案を使用しました。これは完全に機能し、SSAS キューブの構築プロセス中に問題は発生しませんでした。

2) 値が null であるかどうかを確認するための変換を作成し、その場合は -1 (ディメンション内の不明なレコード) に変換するか、メジャー値の場合は 0 に変換します。式は例として以下に示します (これらを派生列変換):

ISNULL(netWeight) ? 0 : netWeight // This is an example of a Measure column
ISNULL(completeddateid) ? -1 : completeddateid // This is an example of a dimension key column

うまくいけば、これは将来誰かを助けるでしょう;-)

于 2009-06-12T18:23:22.720 に答える
1

  1. 適切な意味を持つ日付ディメンションからの NULL または予約済み ID。NULL には実際にはさまざまな意味があることを覚えておいてください。不明、適用外、無効などの可能性があります。

  2. 私は空の文字列（NULL可能ではない）を好みますが、私が取り組んでいるプロジェクトでは、空の文字列をNULLに変換し、データベースで許可しています。議論すべき潜在的な問題は、空白のミドル ネームのイニシャル (ミドル ネームがないため、ミドル ネームのイニシャルは空であることがわかっている) が、未知のミドル ネームのイニシャルまたは同様のセマンティクスと異なることです。お金については、私たちのモデルは NULL を許可しています。事実上、これには大きな問題があります。通常、NULL は実際には 0 である必要があり、常に 0 として使用され、常に ISNULL() でラップする必要があるためです。しかし、空の文字列を NULL に変換するという ETL ポリシーのために、それらは NULL に設定されました。しかし、これは、一部のソース システムからの 0 の代わりにスペースが含まれていた固定幅転送ファイル形式の単なるアーティファクトでした。

  3. 通常、ファクト テーブルにはすべてのディメンションに基づく PK があるため、これは許可されません。ダミーまたは不明なディメンションにリンクされます。

  4. SSIS で、すべての文字列の末尾からスペースを削除するトリム コンポーネントを作成しました。通常、SSIS で多くの日付の検証と変換を行う必要がありましたが、これはコンポーネントで行うのが最適でした。

于 2009-06-10T21:50:45.683 に答える
0

私が提案できる別の解決策はETL-step、転送中に、必要なすべての変換後にインポートされたレコードが一時的に格納されるテーブルが定義されることです。その転送テーブルにいくつかの属性を追加して、誰かを許可します。NULLまたはその他の望ましくない値になる可能性のある元の値属性の隣。一方では問題を識別する「コード化された」値と、誤った値が発生した属性名を挿入します。

それを行っても、後のステップで非正規化および転送されたデータを使用する方法を決定できます...おそらく、誤った値を除外するか、別のエラーディメンションでそれらを言及して、どの値が逸脱しているか、およびそれらがどのように逸脱しているかを示すレポートに含めることができます/集計値に影響を与える可能性があります。

例えば

error-code attribute= -1 = NULL date -2 = NULL numerical value -3 = NULL PK -4 = NULL text value

およびその他の属性 = IdOrder、BirthDate、OrderAmountなど。

もちろん、レコードが 1 つ以上の誤った (NULL) 値を持つことができる場合は、さらに多くの問題が発生しますが、その場合は、「トレース」属性の数を増やすか、「ソースに戻る」ことで、属性の場所と理由を見つけることができます。問題が発生しました（開発部門と一緒に）

これはやや複雑なステップですが、完全性と正確性のために、これは避けられず必要なことだと思います。

多分これも誰かを助けるでしょう;）

于 2011-08-31T13:50:28.637 に答える