वेअरहाऊसमधील डेटाची गुणवत्ता

मौल्यवान माहिती मिळविण्यासाठी वेअरहाऊसमधील डेटाची गुणवत्ता ही एक महत्त्वाची पूर्व शर्त आहे. खराब गुणवत्तेमुळे दीर्घकाळात नकारात्मक साखळी प्रतिक्रिया निर्माण होते.
प्रथम, प्रदान केलेल्या माहितीवरील विश्वास गमावला आहे. लोक बिझनेस इंटेलिजन्स ऍप्लिकेशन्सचा कमी वापर करू लागले आहेत;
परिणामी, विश्लेषणात्मक प्रकल्पातील पुढील गुंतवणुकीवर प्रश्नचिन्ह निर्माण झाले आहे.

डेटा गुणवत्तेची जबाबदारी

डेटा गुणवत्ता सुधारण्याशी संबंधित पैलू BI प्रकल्पांमध्ये मोठे-महत्त्वाचे आहे. तथापि, हे केवळ तांत्रिक तज्ञांचे विशेषाधिकार नाही.
डेटा गुणवत्तेवर देखील अशा पैलूंचा प्रभाव पडतो

कॉर्पोरेट संस्कृती

• कामगारांनाच चांगल्या दर्जाचे उत्पादन करण्यात रस आहे का?
• नसेल तर का नाही? हितसंबंधांचा संघर्ष होऊ शकतो.
• कदाचित असे कॉर्पोरेट नियम आहेत जे ठरवतात की गुणवत्तेसाठी कोण जबाबदार आहे?

प्रक्रिया

• या साखळींच्या शेवटी कोणता डेटा तयार होतो?
• कदाचित ऑपरेटिंग सिस्टम अशा प्रकारे कॉन्फिगर केले गेले आहेत की आपल्याला ही किंवा ती परिस्थिती प्रत्यक्षात प्रतिबिंबित करण्यासाठी "ट्विस्ट" करणे आवश्यक आहे.
• ऑपरेटिंग सिस्टीम डेटा पडताळणी आणि सामंजस्य स्वतः करतात का?

अहवाल प्रणालीमधील डेटाच्या गुणवत्तेसाठी संस्थेतील प्रत्येकजण जबाबदार आहे.

व्याख्या आणि अर्थ

गुणवत्ता हे ग्राहकांच्या अपेक्षांचे सिद्ध समाधान आहे.

परंतु डेटा गुणवत्तेची व्याख्या नसते. हे नेहमी वापराचा संदर्भ प्रतिबिंबित करते. डेटा वेअरहाऊस आणि BI सिस्टम ज्या ऑपरेटिंग सिस्टममधून डेटा येतो त्यापेक्षा भिन्न उद्देश पूर्ण करतात.

उदाहरणार्थ, ऑपरेटिंग सिस्टीमवर, ग्राहक विशेषता एक पर्यायी फील्ड असू शकते. रेपॉजिटरीमध्ये, ही विशेषता परिमाण म्हणून वापरली जाऊ शकते आणि ती भरणे आवश्यक आहे. जे, यामधून, डीफॉल्ट मूल्ये भरण्याची गरज ओळखते.

डेटा स्टोरेज आवश्यकता सतत बदलत असतात आणि त्या सामान्यतः ऑपरेटिंग सिस्टमच्या तुलनेत जास्त असतात. परंतु स्टोरेजमध्ये ऑपरेटिंग सिस्टममधील तपशीलवार माहिती संग्रहित करण्याची आवश्यकता नसताना हे उलट देखील असू शकते.

डेटा गुणवत्तेचे मोजमाप करण्यासाठी, त्याचे मानक वर्णन करणे आवश्यक आहे. जे लोक त्यांच्या कामासाठी माहिती आणि आकृत्या वापरतात त्यांना वर्णन प्रक्रियेत सहभागी होणे आवश्यक आहे. या सहभागाचा परिणाम एक नियम असू शकतो, ज्याचे अनुसरण करून एखादी त्रुटी आहे की नाही हे टेबलवर एका दृष्टीक्षेपात सांगू शकते. त्यानंतरच्या पडताळणीसाठी हा नियम स्क्रिप्ट/कोड म्हणून फॉरमॅट केलेला असणे आवश्यक आहे.

डेटा गुणवत्ता सुधारणे

वेअरहाऊसमध्ये डेटा लोड करण्याच्या प्रक्रियेदरम्यान सर्व काल्पनिक त्रुटी साफ करणे आणि दुरुस्त करणे अशक्य आहे. चांगली डेटा गुणवत्ता केवळ सर्व सहभागींमधील जवळच्या सहकार्यानेच प्राप्त केली जाऊ शकते. जे लोक ऑपरेटिंग सिस्टीममध्ये डेटा प्रविष्ट करतात त्यांना हे जाणून घेणे आवश्यक आहे की कोणत्या कृतींमुळे त्रुटी निर्माण होतात.

डेटा गुणवत्ता ही एक प्रक्रिया आहे. दुर्दैवाने, अनेक संस्थांकडे सतत सुधारणा करण्याचे धोरण नाही. बरेच लोक केवळ डेटा संग्रहित करण्यासाठी स्वतःला मर्यादित करतात आणि विश्लेषणात्मक प्रणालीची पूर्ण क्षमता वापरत नाहीत. सामान्यतः, डेटा वेअरहाऊस विकसित करताना, बजेटच्या 70-80% डेटा एकत्रीकरण लागू करण्यासाठी खर्च केला जातो. देखरेख आणि सुधारणेची प्रक्रिया अपूर्ण राहिली आहे.

साधने

सॉफ्टवेअर टूल्सचा वापर डेटा गुणवत्ता सुधारणा आणि मॉनिटरिंग स्वयंचलित करण्याच्या प्रक्रियेत मदत करू शकतो. उदाहरणार्थ, ते स्टोरेज संरचनांचे तांत्रिक सत्यापन पूर्णपणे स्वयंचलित करू शकतात: फील्ड स्वरूप, डीफॉल्ट मूल्यांची उपस्थिती, सारणी फील्ड नावांचे अनुपालन.

सामग्री तपासणे अधिक कठीण असू शकते. स्टोरेज आवश्यकता बदलत असताना, डेटाचे स्पष्टीकरण देखील बदलू शकते. साधन स्वतःच एक मोठा प्रकल्प बनू शकतो ज्यास समर्थन आवश्यक आहे.

टीप

रिलेशनल डेटाबेस, ज्यामध्ये स्टोअर सामान्यतः डिझाइन केलेले असतात, दृश्ये तयार करण्याची उल्लेखनीय क्षमता असते. जर तुम्हाला सामग्रीचे तपशील माहित असतील तर ते द्रुतपणे डेटा तपासण्यासाठी वापरले जाऊ शकतात. डेटामध्ये त्रुटी किंवा समस्या शोधण्याचे प्रत्येक प्रकरण डेटाबेस क्वेरीच्या स्वरूपात रेकॉर्ड केले जाऊ शकते.

अशा प्रकारे, सामग्रीबद्दल ज्ञानाचा आधार तयार केला जाईल. अर्थात, अशा विनंत्या जलद असणे आवश्यक आहे. टेबल-आधारित साधनांपेक्षा दृश्ये राखण्यासाठी सामान्यत: कमी मानवी वेळ लागतो. चाचणीचा निकाल प्रदर्शित करण्यासाठी दृश्य नेहमी तयार असते.
महत्त्वाच्या अहवालांच्या बाबतीत, दृश्यामध्ये प्राप्तकर्त्यासह एक स्तंभ असू शकतो. वेअरहाऊसमधील डेटा गुणवत्तेच्या स्थितीचा अहवाल देण्यासाठी समान BI साधने वापरणे अर्थपूर्ण आहे.

उदाहरण:

क्वेरी ओरॅकल डेटाबेससाठी लिहिलेली होती. या उदाहरणात, चाचण्या अंकीय मूल्य देतात ज्याचा इच्छेनुसार अर्थ लावला जाऊ शकतो. अलार्म पातळी समायोजित करण्यासाठी 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
व्यवसाय बुद्धिमत्ता zum Erfolg wird

स्त्रोत: www.habr.com