A raktárban lévő adatok minősége fontos előfeltétele az értékes információk megszerzésének. A rossz minőség hosszú távon negatív láncreakcióhoz vezet.
Először is, a megadott információkba vetett bizalom elveszett. Az emberek egyre kevésbé használják az üzleti intelligencia alkalmazásokat; az alkalmazásokban rejlő lehetőségek továbbra is kihasználatlanok.
Ennek eredményeként megkérdőjeleződik az elemző projektbe történő további befektetés.
Felelősség az adatok minőségéért
Az adatminőség javításával kapcsolatos szempont nagyon fontos a BI projektekben. Ez azonban nem csak a műszaki szakemberek kiváltsága.
Az adatminőséget olyan szempontok is befolyásolják, mint pl
Vállalati kultúra
- Maguk a dolgozók is érdekeltek a jó minőség gyártásában?
- Ha nem, miért nem? Összeférhetetlenség állhat fenn.
- Talán vannak olyan vállalati szabályok, amelyek meghatározzák, hogy ki a felelős a minőségért?
A folyamatok
- Milyen adatok jönnek létre e láncok végén?
- Talán az operációs rendszerek úgy vannak beállítva, hogy „csavarni” kell, hogy tükrözze ezt vagy azt a helyzetet a valóságban.
- Az operációs rendszerek maguk végeznek adatellenőrzést és egyeztetést?
A szervezet minden tagja felelős a jelentési rendszerekben található adatok minőségéért.
Definíció és jelentés
A minőség a vásárlói elvárások bizonyított kielégítése.
Az adatminőség azonban nem tartalmaz definíciót. Mindig tükrözi a használati kontextust. Az adattárház és a BI-rendszer más célokat szolgál, mint az az operációs rendszer, amelyből az adatok származnak.
Például egy operációs rendszeren az ügyfél attribútum lehet opcionális mező. A repository-ban ez az attribútum használható dimenzióként és kitöltése kötelező. Ami viszont bevezeti az alapértelmezett értékek kitöltésének szükségességét.
Az adattárolási követelmények folyamatosan változnak, és általában magasabbak, mint az operációs rendszereké. De lehet fordítva is, amikor nincs szükség az operációs rendszer részletes információinak tárolására a tárolóban.
Ahhoz, hogy az adatminőség mérhető legyen, le kell írni a szabványait. A leírási folyamatba be kell vonni azokat az embereket, akik információkat és számadatokat használnak munkájukhoz. Ennek az érintettségnek az eredménye lehet egy szabály, amelynek betartása mellett a táblázatból egy pillantással meg lehet állapítani, hogy van-e hiba vagy sem. Ezt a szabályt szkriptként/kódként kell formázni a későbbi ellenőrzéshez.
Az adatok minőségének javítása
Lehetetlen minden feltételezett hibát kijavítani és kijavítani az adatok raktárba történő betöltése során. Jó adatminőség csak az összes résztvevő szoros együttműködésével érhető el. Az operációs rendszerekbe adatokat beíró embereknek meg kell tanulniuk, hogy milyen műveletek vezetnek hibákhoz.
Az adatminőség egy folyamat. Sajnos sok szervezetnek nincs stratégiája a folyamatos fejlesztésre. Sokan az adatok tárolására korlátozódnak, és nem használják ki az analitikai rendszerekben rejlő lehetőségeket. Jellemzően az adattárházak fejlesztésekor a költségvetés 70-80%-át az adatintegráció megvalósítására fordítják. A nyomon követési és fejlesztési folyamat továbbra is hiányos, ha egyáltalán van.
Tools
A szoftvereszközök használata segíthet az adatminőség javításának és nyomon követésének automatizálásában. Például teljes mértékben automatizálhatják a tárolási struktúrák műszaki ellenőrzését: mezőformátum, alapértelmezett értékek jelenléte, táblamezőneveknek való megfelelés.
A tartalom ellenőrzése nehezebb lehet. A tárolási követelmények változásával az adatok értelmezése is változhat. Maga az eszköz hatalmas projektté válhat, amely támogatást igényel.
Tanács
A relációs adatbázisok, amelyekben általában az üzleteket tervezik, figyelemre méltó képességgel rendelkeznek nézetek létrehozására. Segítségükkel gyorsan ellenőrizhetők az adatok, ha ismeri a tartalom sajátosságait. Minden olyan eset, amikor hibát vagy problémát találunk az adatokban, adatbázis lekérdezés formájában rögzíthető.
Így kialakul egy tudásbázis a tartalomról. Természetesen az ilyen kéréseknek gyorsnak kell lenniük. A nézetek karbantartása általában kevesebb emberi időt igényel, mint a táblázatalapú eszközök. A nézet mindig készen áll a teszt eredményének megjelenítésére.
Fontos jelentések esetén a nézet tartalmazhat egy oszlopot a címzettel. Célszerű ugyanazokat a BI-eszközöket használni a raktár adatminőségének állapotáról szóló jelentésekhez.
Példa
A lekérdezés az Oracle adatbázishoz készült. Ebben a példában a tesztek egy tetszőlegesen értelmezhető numerikus értéket adnak vissza. A T_MIN és T_MAX értékek segítségével beállítható a riasztási szint. A REPORT mezőt valamikor üzenetként használták egy kereskedelmi ETL-termékben, amely nem tudta, hogyan kell megfelelően küldeni az e-maileket, így az rpad „mankó”.
Nagy tábla esetén hozzáadhat pl. ÉS SORSZÁM <= 10, azaz. ha 10 hiba van, 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 (-- 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
A kiadvány a könyv anyagait használja fel
Ronald Bachmann, Dr. Guido Kemper
Raus aus der BI-Falle
Wie Business Intelligence zum Erfolg wird
Forrás: will.com