Az adatok minősége a tárolóban fontos előfeltétele a értékes információk megszerzésének. A gyenge minőség hosszú távon negatív láncreakciót indít el.
Először is, elveszik a bizalom a megadott információk iránt. Az emberek kezdenek kevesebb Business Intelligence alkalmazást használni, az alkalmazások potenciálja kihasználatlan marad.
Ennek következtében kétségessé válik a további befektetések szükségessége az elemzési projektbe.
Az adatok minőségéért felelősség
A minőség javításának aspektusa megaváltozik a BI projektekben. Azonban nem csak a technikai szakemberek privilégiuma.
Az adatok minőségére hatással vannak olyan szempontok is, mint
A vállalati kultúra
- Érdeklik-e magukat a dolgozók a jó minőségű termelés iránt?
- Ha nem, akkor miért? Talán érdekkonfliktus áll fenn.
- Lehet, hogy vannak vállalati szabályok, amelyek meghatározzák a minőségért felelőseket?
Folyamatok
- Milyen adatok keletkeznek ezeknek a láncoknak a végén?
- Lehet, hogy az operációs rendszerek úgy vannak beállítva, hogy 'keresni' kell bizonyos tényezőket a valóság tükrözéséhez.
- Az operációs rendszerek végzik-e az adatok ellenőrzését és egyeztetését?
Az adatok minőségéért a jelentési rendszerekben mindenki felelős a szervezetben.
Meghatározás és jelentés
A minőség az ügyfél elvárásainak megerősített kielégítése.
De az adatok minősége nem tartalmaz meghatározást. Mindig a felhasználás kontextusát tükrözi. A tárolási rendszer és a BI rendszer más célokat szolgál, mint az operációs rendszer, ahonnan az adatok származnak.
Például az operációs rendszerben az ügyfél attribútuma nem kötelező mező. A tárolóban ez az attribútum használható méretezésként, és kitöltése kötelező. Ami viszont bevezeti a kötelező alapértelmezett értékek kitöltését.
A tároló adatok követelményei folyamatosan változnak, és általában magasabbak, mint az operációs rendszereké. De az is lehet, hogy ellenkezőleg, amikor a tárolóban nem szükséges részletes információkat megőrizni az operációs rendszerből.
Ahhoz, hogy az adatok minősége mérhető legyen, szükséges annak szabványai. Azok az emberek, akik információkat és számokat használnak a munkájukhoz, be kell, hogy vonják az adatleírás folyamatába. Ennek a bevonásnak az eredménye lehet egy szabály, amely alapján egy pillantással megállapítható, hogy van-e hiba. Ezt a szabályt script-ként/kódként kell megformálni a jövőbeli ellenőrzéshez.
Az adatok minőségének javítása
A tárolóba történő adatok betöltése során lehetetlen minden hipotetikus hibát kitisztítani és javítani. Jó minőségű adatokat csak a résztvevők szoros együttműködése révén lehet elérni. Azok az emberek, akik adatokat visznek be az operációs rendszerekbe, meg kell, hogy ismerjék, hogy mely tevékenységek vezetnek hibákhoz.
Az adatok minősége egy folyamat. Sajnos sok szervezetnek nincs stratégiája annak folyamatos javítására. Sokan csupán az adatok megőrzésére korlátozódnak, és nem használják ki az analitikai rendszerek teljes potenciálját. Általában a tárolók kifejlesztésénél a költségvetés 70-80%-a az adatintegráció megvalósítására megy el. Az ellenőrzési és javítási folyamat hiányos marad, ha egyáltalán létezik.
Eszközök
A szoftveres eszközök alkalmazása segíthet az adatok minőségének javításának és ellenőrzésének automatizálásában. Például teljesen automatizálhatják a tárolók struktúrájának technikai ellenőrzését: a mezők formátuma, az alapértelmezett értékek megléte, a táblamezők nevére vonatkozó követelményeknek való megfelelés.
Nehézségek merülhetnek fel a tartalom ellenőrzésében. Mivel a tárolóra vonatkozó követelmények változnak, az adatok értelmezése is megváltozhat. Az eszköz önállóan egy hatalmas projektté válhat, amely fenntartást igényel.
Tipp
A relációs adatbázisok, amelyek általában a tárolók tervezésére szolgálnak, kiváló lehetőséggel rendelkeznek nézetek (view-k) létrehozására. Ezeket gyors adatellenőrzésre lehet használni, ha ismerjük a tartalom sajátosságait. Minden egyes esetben, amikor hiba vagy probléma található az adatokban, ezt lekérdezés formájában lehet rögzíteni az adatbázisban.
Így egy tudásbázis fog kialakulni a tartalomról. Természetesen az ilyen lekérdezéseknek gyorsnak kell lenniük. Általában a nézetek kiszolgálása kevesebb emberi időt igényel, mint a táblákra szervezett eszközök. A nézet mindig készen áll a vizsgálat eredményének megjelenítésére.
Fontos jelentések esetén a nézet tartalmazhat egy oszlopot a címzett számára. Érdemes ugyanazokat a BI eszközöket használni az adatminőség állapotának jelentéséhez a tárolóban.
támadásra
A lekérdezés Oracle adatbázisra íródott. Ebben a példában a tesztek numerikus értéket adnak vissza, amelyet a kívánt módon lehet értelmezni. A T_MIN és T_MAX értékekkel lehet szabályozni a riasztás mértékét. A REPORT mezőt valaha üzenetként használták egy kereskedelmi ETL termékben, amely nem tudta megfelelően küldeni az e-maileket, ezért a rpad egy "workaround".
Nagy tábla esetén lehet például AND ROWNUM <= 10, azaz ha összegyűlt 10 hiba, akkor ez elég a riasztáshoz.
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 (-- Teszt önmagában
SELECT
'DIM_PRODUCT' AS TABLE_NAME,
'Üres mezők száma' AS DESCRIPTION,
COUNT(*) AS OUTPUT,
0 AS T_MIN,
10 AS T_MAX
FROM DIM_PRODUCT
WHERE DIM_PRODUCT_ID != -1 -- nem alapértelmezett érték
AND ATTRIBUTE IS NULL ); -- üres mezők számlálása
A kiadványban egy könyv anyagai találhatóak
Ronald Bachmann, Dr. Guido Kemper
Ki a BI csapdájából
Hogyan válik a Business Intelligence sikeressé
Forrás: habr.com
