ウェアハウス内のデータの品質は、価値のある情報を取得するための重要な前提条件です。 品質が悪いと、長期的には負の連鎖が起こります。
まず、提供される情報に対する信頼が失われます。 ビジネス インテリジェンス アプリケーションを使用する人が減り始めていますが、アプリケーションの可能性は依然として活用されていません。
その結果、分析プロジェクトへのさらなる投資が疑問視されています。
データ品質に対する責任
データ品質の向上に関連する側面は、BI プロジェクトにおいて非常に重要です。 ただし、それは技術専門家だけの特権ではありません。
データ品質は次のような側面にも影響されます。
企業文化
- 労働者自身が高品質のものを生産することに関心を持っていますか?
- そうでない場合は、なぜそうではないのでしょうか? 利益相反が発生する可能性があります。
- おそらく、品質に対する責任者を決定する社内規則があるのではないでしょうか?
Процессы
- これらのチェーンの最後にはどのようなデータが作成されるのでしょうか?
- おそらく、オペレーティング システムは、現実のさまざまな状況を反映するために「ひねる」必要があるように構成されているのでしょう。
- オペレーティング システム自体がデータの検証と調整を実行しますか?
組織内の全員がレポート システムのデータの品質に責任を負います。
定義と意味
品質とは、顧客の期待に応えることが証明されたものです。
しかし、データ品質には定義が含まれていません。 常に使用状況を反映します。 データ ウェアハウスと BI システムは、データの取得元であるオペレーティング システムとは異なる目的を果たします。
たとえば、オペレーティング システムでは、顧客属性がオプションのフィールドである場合があります。 リポジトリでは、この属性はディメンションとして使用でき、その値を入力する必要があります。 そのため、デフォルト値を入力する必要が生じます。
データ ストレージの要件は常に変化しており、通常はオペレーティング システムの要件よりも高くなります。 ただし、その逆、オペレーティング システムからの詳細情報をストレージに保存する必要がない場合も考えられます。
データ品質を測定可能にするには、その基準を説明する必要があります。 仕事で情報や図を使用する人は、記述プロセスに参加する必要があります。 この関与の結果は、テーブルを見ればエラーがあるかどうかが一目でわかるようなルールになる可能性があります。 このルールは、後で検証できるようにスクリプト/コードとしてフォーマットする必要があります。
データ品質の向上
データをウェアハウスにロードするプロセス中に、すべての仮定上のエラーをクリーンアップして修正することは不可能です。 良好なデータ品質は、すべての参加者間の緊密な協力によってのみ達成できます。 オペレーティング システムにデータを入力する人は、どのような操作がエラーにつながるかを学ぶ必要があります。
データ品質はプロセスです。 残念ながら、多くの組織には継続的な改善のための戦略がありません。 多くはデータの保存のみに限定されており、分析システムの可能性を最大限に活用していません。 通常、データ ウェアハウスを開発する場合、予算の 70 ～ 80% がデータ統合の実装に費やされます。 監視と改善のプロセスは、たとえあったとしても不完全なままです。
ツール
ソフトウェア ツールの使用は、データ品質の向上と監視を自動化するプロセスに役立ちます。 たとえば、フィールド形式、デフォルト値の存在、テーブルフィールド名の準拠など、ストレージ構造の技術的検証を完全に自動化できます。
内容の確認が難しくなる場合がございます。 ストレージ要件が変化すると、データの解釈も変化する可能性があります。 ツール自体がサポートを必要とする大規模なプロジェクトになる可能性があります。
協議会
通常、ストアが設計されるリレーショナル データベースには、ビューを作成する優れた機能があります。 コンテンツの詳細を知っている場合は、データをすばやく確認するために使用できます。 データ内でエラーや問題が見つかった場合は、それぞれデータベース クエリの形式で記録できます。
このようにして、コンテンツに関する知識ベースが形成されます。 もちろん、そのようなリクエストは高速でなければなりません。 通常、ビューはテーブルベースのツールよりも保守にかかる時間が少なくなります。 ビューは常にテストの結果を表示できる状態にあります。
重要なレポートの場合、ビューには受信者を示す列が含まれる場合があります。 同じ BI ツールを使用して、ウェアハウス内のデータ品質の状態をレポートすることは理にかなっています。
例
クエリは Oracle データベース用に作成されました。 この例では、テストは必要に応じて解釈できる数値を返します。 T_MIN および T_MAX 値を使用してアラーム レベルを調整できます。 REPORT フィールドは、かつて電子メールを適切に送信する方法を知らなかった商用 ETL 製品でメッセージとして使用されていたため、rpad は「松葉杖」です。
大きなテーブルの場合は、たとえば AND ROWNUM <= 10 を追加できます。 エラーが 10 個ある場合、これはアラームを引き起こすのに十分です。
CREATE OR REPLACE VIEW V_QC_DIM_PRODUCT_01 AS
SELECT
CASE WHEN OUTPUT>=T_MIN AND OUTPUT<=T_MAX
THEN 'OK' ELSE 'ERROR' END AS RESULT,
DESCRIPTION,
TABLE_NAME,
OUTPUT,
T_MIN,
T_MAX,
rpad(DESCRIPTION,60,' ') || rpad(OUTPUT,8,' ') || rpad(T_MIN,8,' ') || rpad(T_MAX,8,' ') AS REPORT
FROM (-- Test itself
SELECT
'DIM_PRODUCT' AS TABLE_NAME,
'Count of blanks' AS DESCRIPTION,
COUNT(*) AS OUTPUT,
0 AS T_MIN,
10 AS T_MAX
FROM DIM_PRODUCT
WHERE DIM_PRODUCT_ID != -1 -- not default value
AND ATTRIBUTE IS NULL ); -- count blanks
この出版物は書籍の素材を使用しています
ロナルド・バックマン博士グイド・ケンパー
Raus aus der BI-Falle
Wie Business Intelligence zum Erfolg wird
出所： habr.com