Cilësia e të dhënave në depo është një kusht i rëndësishëm për të marrë informacion të vlefshëm. Cilësia e dobët çon në një reagim zinxhir negativ në afat të gjatë.
Fillimisht humbet besimi në informacionin e ofruar. Njerëzit fillojnë të përdorin më pak aplikacionet Business Intelligence, potenciali i aplikacioneve mbetet i pamarrë parasysh.
Si pasojë, vihen në pikëpyetje investimet e mëtejshme në projektin analitik.
Përgjegjësia për cilësinë e të dhënave
Aspekti i lidhur me përmirësimin e cilësisë së të dhënave është mega i rëndësishëm në projektet BI. Megjithatë, ai nuk është privilegj vetëm i specialistëve teknikë.
Cilësinë e të dhënave e ndikon gjithashtu aspekte të tilla si
Kultura korporative
- A janë punonjësit vetë të interesuar në prodhimin e cilësisë së mirë?
- Nëse jo, atëherë pse? Ndoshta ka një konflikt interesi.
- Ndoshta ka rregulla korporative që përcaktojnë përgjegjësitë për cilësinë?
Proceset
- Cilat të dhëna krijohen në fund të këtyre zinxhirëve?
- Ndoshta sistemet operuese janë tjetërsoj të konfiguruara, aq sa duhet "të manipulojnë" për të reflektuar këtë apo atë situatë në realitet.
- A i kryejnë sistemet operuese vetë verifikimin dhe krahasimin e të dhënave?
Të gjithë në organizatë janë përgjegjës për cilësinë e të dhënave në sistemet raportuese.
Definimi dhe kuptimi
Cilësia është konfirmimi i plotësimit të pritshmërive të klientit.
Por cilësia e të dhënave nuk përmban një definicion të saktë. Ajo gjithmonë pasqyron kontekstin e përdorimit. Depo e të dhënave dhe sistemi BI kryejnë qëllime të ndryshme se sa sistemi operativ nga ku janë marrë të dhënat.
Për shembull, në sistemin operativ atributi i klientit mund të jetë një fushë jo e detyrueshme. Në depo, ky atribut mund të përdoret si përmasë dhe plotësimi i tij është i obligueshëm. Kjo, në anën tjetër, krijon nevojën për të mbushur me vlera përkatëse.
Kërkesat për depo të dhënash vazhdimisht ndryshojnë dhe zakonisht janë më të larta se ato për sistemet operuese. Por mund të ndodhë e kundërta, kur në depo nuk kërkohet ruajtja e informacionit të detajuar nga sistemi operativ.
Për të bërë cilësinë e të dhënave të matshme, standardet e saj duhet të përshkruhen. Njësitë që përdorin informacionin dhe numrat për punën e tyre duhet të përfshihen në procesin e përshkrimit. Rezultati i këtij angazhimi mund të jetë një rregull, sipas të cilit, me një shikim në tabelë mund të thuhet nëse ka gabim apo jo. Ky rregull duhet të formalizohet në formën e një skripti/kodi për verifikim të mëvonshëm.
Përmirësimi i cilësisë së të dhënave
Nuk është e mundur të pastrohen dhe korrigjohen të gjitha gabimet hipotetike gjatë procesit të ngarkimit të të dhënave në depo. Cilësia e mirë e të dhënave mund të arrihet vetëm nëpërmjet një pune të ngushtë të të gjithë pjesëmarrësve. Njerëzit që futin të dhëna në sistemet operative duhet të mësojnë se cilat veprime çojnë në gabime.
Cilësia e të dhënave është një proces. Fatkeqësisht, në shumë organizata nuk ka një strategji për përmirësimin e vazhdueshëm të saj. Shumë e kufizojnë veten në ruajtjen e të dhënave dhe nuk e shfrytëzojnë të gjithë potencialin e sistemeve analitike. Si rregull, gjatë zhvillimit të depozita të dhënash, 70-80% e buxhetit shpenzohet për realizimin e integrimit të të dhënave. Procesi i kontrollit dhe përmirësimit mbetet i papërfunduar, nëse në të vërtetë mbetet.
Mjetet
Aplikimi i mjeteve softuerike mund të ndihmojë në procesin e automatizimit të përmirësimit dhe monitorimit të cilësisë së të dhënave. Për shembull, ato mund të automatizojnë plotësisht kontrollin teknik të strukturave të depozitës: formati i fushave, prania e vlerave të parazgjedhura, përputhshmëria me kërkesat e emrave të fushave të tabelave.
Më e vështirë mund të jetë kontrolli i përmbajtjes. Meqenëse kërkesat për depozitat ndryshojnë, mund të ndryshojë gjithashtu interpretimi i të dhënave. Vegla vetë mund të shndërrohet në një projekt të madh, që kërkon mbështetje.
Këshillë
Baza tĂ« dhĂ«nash relacione, nĂ« tĂ« cilat zakonisht projektohen depozitat, kanĂ« njĂ« mundĂ«si tĂ« shkĂ«lqyer pĂ«r tĂ« krijuar pamje (views). Ato mund tĂ« pĂ«rdoren pĂ«r njĂ« kontroll tĂ« shpejtĂ« tĂ« tĂ« dhĂ«nave, nĂ«se dihen veçoritĂ« e pĂ«rmbajtjes. Ădo rast i gjetjes sĂ« njĂ« gabimi apo problemi nĂ« tĂ« dhĂ«na mund tĂ« regjistrohet nĂ« formĂ«n e njĂ« pyetjeje nĂ« bazĂ«n e tĂ« dhĂ«nave.
Kështu do të formohet një bazë njohurish për përmbajtjen. Sigurisht, kërkesat e tilla duhet të jenë të shpejta. Në përgjithësi, shërbimi i pamjeve merr më pak kohë njerëzore sesa mjetet e organizuara në tabela. Pamja është gjithmonë e gatshme për të shfaqur rezultatin e kontrollit.
Në rastin e raporteve të rëndësishme, pamja mund të përmbajë një kolonë me adresat. Ka kuptim që të përdoret e njëjta mjet BI për të raportuar mbi cilësinë e të dhënave në depo.
Shembulli
Kërkesa është shkruar për bazën Oracle. Në këtë shembull, testet kthejnë një vlerë numerike që mund të interpretohet siç duhet. Vlerat T_MIN dhe T_MAX mund të rregullojnë nivelin e alarmit. Fusha REPORT dikur ishte përdorur si mesazh në një produkt komercial ETL, i cili nuk dinte të dërgonte email-e siç duhet, dhe prandaj rpad është një 'patch'.
Në rastin e një tabele të madhe, mund të shtoni, për shembull, AND ROWNUM <= 10, pra nëse ka pasur 10 gabime, kjo është e mjaftueshme për alarm.
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 (-- Testi vetë
SELECT
'DIM_PRODUCT' AS TABLE_NAME,
'Numri i boshllëqeve' AS DESCRIPTION,
COUNT(*) AS OUTPUT,
0 AS T_MIN,
10 AS T_MAX
FROM DIM_PRODUCT
WHERE DIM_PRODUCT_ID != -1 -- jo vlera e paracaktuar
AND ATTRIBUTE IS NULL ); -- numri i boshllëqeve
Në publikim janë përdorur materiale nga libri
Ronald Bachmann, Dr. Guido Kemper
Dalja nga rrethi BI
Si Inteligjenca e Biznesit bëhet e suksesshme
Burimi: habr.com
