În faimoasa dispută dintre Ralph Kimball şi Bill Inmon referitor la construirea unui DWH işi are locul şi întrebarea următoare: construim de sus în jos sau de jos în sus?
Dar ce e sus şi ce e jos?
După ce am citit cărţile ambilor autori, eu zic că sus sunt datele şi jos sunt cerinţele de business procesele de business.
Inmon zice să pornim de la un model de date (care este de fapt o diagramă ERD, 3rd normal form modelată după regulile lui Ted Codd ). Apoi să construim diferite data mart-uri pentru diferite departamente satisfăcând astfel cerinţele venite de la business. Dar oare cum facem să obţinem modelul de date? Oare nu cumva, mai întâi începem cu analiza proceselor de business? 😯
Kimball zice că trebuie să pornim cu identificarea proceselor de business; să construim o matrice (enterprise bus matrix) care identifică toate procesele de business şi toate dimensiunile unde aceastea se intersectează. Apoi să construim modelul de date (star schema, denormalized). Argumentul este că procesele de business se schimbă foarte rar şi nu semnificativ (spre deosebire de cerinţele de business pentru partea de raportare). De exemplu, cât de des se schimbă felul în care înregistrezi clienţi noi, sau felul în care facturezi? Practic, folosim procesele de business ca pe o ancoră.
Ambii autori sunt de accord că cerinţele de raportare se schimbă şi că oamenii de business, gandesc cam asa: dă-mi ce info ai şi apoi îţi spun ce vreau să obţin. Şi e ok să gândească aşa, un DWH (bine modelat) susţine exact acest mod de gândire.
Oricum am construi DWH-ul, cred că ar trebui să fim “business-driven” şi nu cum e la modă azi “data-driven”. Business driven înseamnă că modelarea datelor se face în funcţie de procesele de business si apoi putem lua nişte decizii pornind de la nişte informaţii (obţinute din datele produse de procesele de business).
Data-driven înseamna doar că luăm nişte decizii bazate pe date (pe date! corecte, gresite?). Tot data-driven înseamnă (după Inmon) să construim pe moştenirea istorică de cod şi date pornind de la modelul de date. Inmon însa nu spune nimic despre cum ajungem să avem un model de date.
Gata! Am hotarât, imi fac tricou cu BUSiness driven. Cu scris alb pe tricou negru. Problema e că business driven sună mai urât decât data driven…şi parcă nici nu sună aşa smart…dar nu-i nimic! compensăm prin ceva… atitudine!?