Olvasási idő: 2 perc
Az adattárház projektek kezdeti (jellemzően már az ajánlati) szakaszában kulcskérdés, hogy “top-down” vagy “bottom-up” haladjon-e a projekt.
A top-down (felülről lefelé haladó) módszer – főzési példával élve – az, amikor minden részében pontosan ismert ételt “bontunk vissza” receptre, majd abból meghatározzuk a hozzávalókat és a mennyiségeket, és utána megyünk vásárolni. (“Apró” gond persze, ha a boltban kiderül, hogy valamilyen hozzávaló éppen nem kapható.)
Ilyenkor azt várjuk a felhasználótól, hogy megmondja, hogy pontosan milyen riportokat akar a rendszerből megkapni, annak alapján kitaláljuk a szükséges adatpiaci táblákat, majd onnan visszafelé kialakítjuk a normalizált adatmodellt, és megnézzük, hogy milyen forrásadatok kellenek hozzá.
Ez – elvileg – minimalizálja a “felesleges” fejlesztési munkát, hiszen csak az készül el, amire ténylegesen szükség van. Az a baj vele, hogy többnyire nem működik. Ugyanis a megrendelő a projekt elején nagyon ritkán tudja megmondani elég pontosan, hogy mit szeretne a végén. (A ritka kivételek egyike a kötelező, pl. felügyeleti beszámolók, ha azok elég jól vannak specifikálva.) A másik probléma tud lenni, hogy kiderül, hogy a szükséges forrásadat nem elérhető; de a gyakorlatban ez általában már elég hamar ki szokott derülni. Ez a fejlesztési modell hosszabb távon szinte biztosan belefut abba a problémába, hogy a megrendelő többet, mást is szeretne – de az adatmodell azt jó eséllyel nem tudja kiszolgálni.
A másik, a bottom-up (alulról felfelé) módszer pedig hasonlatos a gyakorlott háziasszonyhoz: kb. tudja, hogy mit szeretne főzni, majd elmegy a boltba, megveszi amit szükségesnek gondol (meg persze, amit kapni lehet), majd hazamegy és nekiáll. Kicsit ügyeskedik és a végén lesz valami ebéd; többnyire nem pontosan az előre kigondolt étel, de azért finom. (Ha a kisfia rizi-bizit kért, de a boltban nem volt borsó, akkor lesz kukoricás rizs…)
Az adattárházak esetén először összegyűjtjük, hogy milyen hozzáférhető adatok lehetnek értelmesek az adott felhasználásban, ezekre tervezünk normalizált réteget, majd ezekből az adatpiacon kikeverjük a vágyott kimenethez szükséges adat-összefüggéseket. Ezzel nagyobb mozgásteret biztosítunk a rendszerben az igények pontosítása, vagy újak megjelenése esetén, de tesszük ezt azon az áron, hogy jó eséllyel olyan adatokkal (rosszabb esetben adatforrásokkal) is foglalkozunk, amikre végül mégsem lesz szükség. Annak “meghatározása” (mondjuk inkább: megsejtése), hogy melyik adat-elemeket érdemes betölteni a normalizált rétegbe, és hogyan érdemes előkészíteni az adatpiacot a még-nem-is-ismert lekérdezések kiszolgálására, sokkal inkább művészet, mint tudomány.
Mindkét fenti mechanizmusnak megvan a maga helye, de mi sokszor ezek mellett (vagy inkább között) egy harmadik utat járva tudunk a leghatékonyabban haladni; nevezzük ezt mondjuk “kívülről befelé” módszernek.
A tervező csapatot kétfelé osztjuk: az egyik fele azzal foglalkozik, hogy az ügyféllel sok iterációban megtervezi, hogy milyen kimenetet (pl. dashboard-okat) szeretne. Ezzel odáig megyünk, hogy a dashboard-ok el is készülnek, és alájuk az adat lehetőleg adatbázis nézetekből érkezik, amik – ekkor még – ideiglenes táblákra néznek. Ezekbe a táblákba az adat “kézzel-lábbal” kerül, többnyire Excel-ből vagy más előre preparált forrásból, egyedi betöltőkkel vagy kézi betöltéssel. Ezzel párhuzamosan a csapat másik fele feltérképezi, hogy milyen forrásadatok vannak és azokat milyen normalizált szerkezetben lenne érdemes tárolni – de közben folyamatosan szem előtt tartja, hogy végül majd azt a nézetet (“interfészt”) kell előállítaniuk, amit a dashboard-os csapat meghatároz. (Általában itt is igaz, hogy inkább több adat-elemet kell elhozni a forrásokból, mint amennyi pont most pont erre a célra kell, úgyhogy az adattárház építésben jártas “látnokokat” itt sem lehet teljesen megúszni.) Amikor mindkét csapat elkészül és külön-külön ellenőrizték a helyes működést, egy átkapcsolással az átmeneti táblák helyett már a rendes eljárásokkal töltött adatpiaci táblákból veszik az adatokat a dashboard-ok, és kész a rendszer a teljes éles indulásra.
Ennek a kevert módszernek a tapasztalatok szerint a legnagyobb előnye, hogy sokkal rövidebb tervezési visszacsatolási ciklusok vannak, miközben – a párhuzamosság miatt – a tervezés mindkét ága hosszabb átfutási idővel gazdálkodhat. A felhasználó a projekt elejétől az őt igazából érdeklő kimutatásokon dolgozhat, sőt: nemritkán megoldható, hogy sokkal az adattárház elkészülte előtt már használni is tudja azokat valamilyen mértékig. (Persze ebben az időszakban az adatokat kézzel állítják elő és töltik be az átmeneti táblákba.) Az csak egy külön előny, hogy amire az adatpiaci táblákat kialakítják, bizonyos mértékig már a felhasználási mintákat is lehet ismerni, így a teljesítmény-optimalizáció is egyszerűbb.
Zimmer András – CTO