Kell-e adattárház ODS és DATA MART közé?

.
Egy teljesen természetes interakciós folyamat lehet az, hogy
- STAGE/ODS rétegben gyűlnek a forrásrendszerek napi snapshotjai
- STAGE/ODS rétegből képződik egy adattárház, mondjuk VAULT módszertan szerint.
- VAULT adattárházból készülnek pl.: riporting adatpiacok.
- Ki kell mutatni, hogy az ODS/STAGE minden szükséges adata 100%-ban megjelenik az adatpiacban.
- Mivel a felhasználó csak az adatpiaccal érintkezik, azonnal felmerül benne a laikus kérdés, minek adattárházat finanszírozni fejlesztési és üzemeltetési költségekkel. Neki elég az adatpiac is, úgymond.
- Korrekt STAGE/ODS, korrekt DATA MART valamint korrekt leképezés mellett minek adattárház?

KÉRDÉS: Lehet-e, szabad-e egyből DATA MART-o(ka)t építeni? Mi a hozzáadott értéke egy adattárháznak, mennyiben tekinthető szükséges rossznak?


Pro érvek lehetnek az adattárház ignorálására:

- Elképzelhető olyan scenárió,  amikor egyszerű forrásrendszerek, komoly adattárházépítési logika felmerülési igénye nélkül kvázi egymás mellé önthetők egyetlen adatpiacban. Ilyenkor valóban tűnhet felesleges overhead-nek egy közbülső adattárház.

- Sajnos még mindig sokszor csillagrombolós költségvetésű egy-egy adattárház-fejlesztése, és mellé nagyon lassú, nehézkes, költséges tud lenni az organikus fejlődése, up-to-date-n tartása.

- Felelőtlen forrásrendszer-felelősök könnyen haza tudnak vágni egy adattárházat (használhatóságilag) nem körültekintő fejlesztésekkel, ahogy általában is az OLTP forrásrendszerek könnyen jutnak nagyobb budgethez, nagyobb prioritáshoz üzleti fejlesztések keretében.

- Tipikus forgatókönyv szokott lenni ilyen fent említett adattárház-elmászásoknál, hogy az üzleti user gyorsan megneszeli a problémát, majd a gépén lévő Access/Excel-lel rácsattan a forrásrendszerre, lehúzza a gépére az adatait és kis magászigetecskéjén elemez. Ennél már a versengő adatpiacok is jobb gondolat. ;)

- Az üzleti élet pörög és egyre jobban csak pörög egyre több dolgozónak van szüksége egyre nagyobb mennyiségű adat átfésülésére a napi munkájához, a gyorsítás igénye folyamatosan napirenden szokott lenni, aminek logikus következménye az adattárház létszükségletének megkérdőjelezése.

- Miért ne lehetne "versengő" adatpiacok egymás mellett élése egy vállalatban, szabályozott redundancia és környezet mellett?


Pro érvek lehetnek az adattárház mellett:

-  Régen rossz, ha forrásrendszerek úgymond "összege" kiadja az "analitikus" igények, adatszármaztatási vonzatának 100%-át, ott valami nem kerek jó eséllyel, látatlanban is.

- Képződ(het)nek új adatok, tudni kell aktuálisan még nem is létező új forrásrendszereket integrálni.

- Talán a legfontosabb, hogy az enterprise MDM (mind a master data ~, mind a meta data management) leginkább ebben az esetben tartható valamiféle mederben. A versengő adatpiacok sokkal könnyebben csábítanak vállalaton belüli fegyelmezetlenségekre, dokumentálatlanságokra, párhuzamosságokra, inkonzisztenciákra (lásd pl.: ügyféldeduplikálási problémák => könnyebb káoszt eredményezni, mint rendbetenni).

- A VAULT módszertan már komoly hozzáadott értéket ad az adattárházépítés rugalmasságához, tulajdonképpen kevés overheaddel. Komoly érv kell tehát az ignorálására: nem tűnik triviálisnak a dolog.



Én négy dolgot állítok, konklúzióként:

- Mindkét forgatókönyv lehet életképes, komoly megalapozott tervezés eredményeként csak, persze

- Nincs hüvelykujjszabály melyik a jobb: lokális specifikumok határozzák meg döntéshozatal alapját.

- Az élet hozhatja úgy, hogy bár jó volt az eredeti választási döntés, de át kell térni a másik verzióra.

- Az a vállalat működik jól üzleti intelligencia értelemben, ahol
* jó adatokkal, jól számolnak az üzleti userek, konszenzusos válaszidőkkel
* nincs divergálás az adatok között DQM-problémákat generálva
* organikus és konszenzusosan gyors a fejlődés
* adatpiacok üzleti intelligencia produktumai össze tudnak adódni vállalati értékké.
* a maximalizált vállalati üzleti intelligencia érték optimális további növelése csak nagy befektetéssel növelhető (magyarán nem éri meg).

Blackbox adatbázis kifehérítése üzleti felhasználóknak

.
FELADAT:  Adva van egy üzleti felhasználók számára totálisan black box Oracle adatbázis. Nem scope annak fejtegetése, hogy ez hogyan eshetett meg a XXI.századra. ;) Természetesen az üzleti felhasználók, szeretnék tudni mi van benne, sőt módosítási igényeik is vannak, sőt ráadásul - horribile dictu - gyorsan szeretnének módosulási eredményeket látni. Azaz dokuemntálni kéne visszamenőleg és minél használhatóbb módon előrefele. Van pénzük a projektre, mi legyen a javasolt technológia?

1.
Erre az egyik kézenfekvő megoldás gyári szoftver vásárlása, horribilis pénzekért végtelenül limitált funkcionalitással. Ilyen például Busines Objects Universum Designere. Aki ezirányban akarna továbbolvasni, annak más site javasolt, nem ez a blogposzt. ;) Magam részéről ezt a megoldást teljességgel elutasítom.

2.
Marad tehát valamiféle "custom" megoldás. Ami nekem hirtelenjében eszembejut az két lehetőség: egy minimális ám gyorsan implementálható brute force  megoldás és egy maximális hiperintelligens. Mindkét megoldás ipari standardeket használna, de csak részben state-of-art termékekkel, részben egyedi fejlesztésűekkel.

Alapelv: elsőrendű prioritás, hogy minél inkább gombnyomásra automatikusan up-to-date legyen a dokumentáció.

(1) A minimális ám gyorsan implementálható brute force megoldás

Oracle adatszótárában megvannak a tárolt-eljárás és táblák függései. Feltehető, hogy egyéb Oracle objektumtípus nincs.

Tegyük fel, hogy elkészül egy alap kifehérítő dokumentáció valahogyan.

Bármilyen ("mérföldköves") fejlesztés elött és után csinálunk (text-alapú) snapshotot
- a struktúrákról.
- a függésekről.

Az érintett módosuló kódokat péládul SVN-be rámoljuk (programból)

SVN-diff programból való hívásának segítségével dokumentáljuk a változásokat, minden változástípusnál értelemszerűen.

Fontos látni, hogy nem-feltétlen csak az Oracle belső adatszótárára/dependenciáira lehetne csak támaszkodni: Külön (meta)sémába lehetne hozzáadott értékekkel kiegészíteni, egyedi custom-fejlesztés révén.

Fontos látni, hogy univerzális terméket nem így kell fejleszteni, viszont a megrendelői igények lokális-specifikus lefedését a legkönnyebb így támogatni.

Mindez relatíve egyszerű, gyors fejlesztésű, gombnyomásra aktualizálható, de ha én üzleti user lennék, bizony húznám a számat rá, hiszen erősen IT-alapú, nekem üzleti userként, üzleti alapú kéne nekem.

(2) A maximális hiperinteligens megoldás

Intelligens „master/meta data management”-es univerzum-építés, jó szoftver hiányában, custom-fejlesztéssel.

A fejlesztés végén, múlhatatlan üzleti igény esetén persze bevethető ilyesmi is, például ha rajzolgatni szeretne az ügyfél (aminek én sose láttam értelmét, a modern kor mennyiségi és komplexitási igényeit nézve).

Blackbox adatbázisunkban
- Vannak az alapadatok és a származtatott adatok.
- Minden adat alapadat, ami kívülről interface-n keresztül jön és nem módosul sose rendszeren belül.
- Minden más származtatott adat.
- Ha egy táblában mindkettő van, azt szét kell bombázni kétfelé (minimum logikai értelemben), az én értelmezésem szerint

El kell kezdeni üzleti objektumokat definiálni, amik egymásra épülnek (hierarchiába).

Akkor jó egy üzleti objektum, ha
- könnyű olvasni és egyértelműen értelmezni (az implementált logikát)
- a ráépülés során komoly hozzáadott érték képződik.

Az üzleti objektum tartalmaz
- Nevet (fizikai és üzleti)
- Kulcsokat, ddl-definiciókat.
- Logikát
- Szöveges leírást
- Data Profile-ingot (NULL, kategória-e, stb).
- Ki határozza meg a számosságot: csomó left join esetén nyilván a base tábla, amihez joinolunk.
- Stb. (mindez rendszerszervezési kérdés)
Ami egyedül fontos,hogy azonosítani kell, mi az ami programból tud jönni, és mi az ami manualitást igényel.

Az üzleti objektum üzleti logikája jellemzően SQL (+opcionálisan 3GL kód)

Az SQL-nek minél egyszerűbbnek kell lennie, de nem feltétlen minden határon túlmenően, csak a józan ész szerint (ez az például, amit a kereskedelmi szoftverek a belátható jövőben NEM fognak tudni univerzálisan támogatni)
- Lehet benne UNIO, de csak akkor ha garantáltan diszjunkt
- Lehet benne összetett logikai feltétel, de csak ha átlátható.
- Lehet benne több join is, de lehetőleg csak egyfélék.
- Meg kell különböztetni a törzsadatokat a tranzakciós adatoktól.
- Master-Detail join például nem lehet már (elvi alapokon se), azt szét kell szedni ketté.
- Lehet két- vagy többféleféle „átlagegyenleg”-típusú üzleti logika (pl.: egy termékfejlesztési és egy riskes), viszont különbséget kell tudni képezni új objektum bevezetésével (dekomponálás).
- Lehet többféle tranzakcióleválogatás, de mindegyiknek legyen értelme, neve.
- Nem baj, ha érkezik egy újabb „átlagegyenleg”-definició, de valami korábbira hasonlítania kell és különbséget kell tudni képezni hozzá.
- Garantálni a konszolidált állapothoz való konvergálást, szabályokkal, szabályrendszerrel

stb.

Az üzleti objektumnok jellemzően JOIN-okkal kapcsolódnak.

Ezek után egy új funkcionalitás úgy tudhat kinézni, hogy egy hierarchia közepén lévő üzleti objektumba jellemzően ÚJ attribútum képződik.
Aki eljárások ezt olvassák azokat ez nem szabad zavarja.
Tehát csak lefelé érdekes a hierarchia
Azonosítani kell az alapadatokat, miből származik
Ha új adatféleség kerül egy lentebbi üzleti objektumba lásd előbbi eljárást.
Az összes módosításos származtatást szintén azonosítani kell.

Alapelv inkább legyen több kisebb (horribile dictu diszjunkt) üzleti objektum, mint kevesebb (na pláne összefüggő/mellékhatásos) komplex

Az iteráció a konszolidált állapotig való eljutásban (top-down és bottom-up kombináltan):
- Veszünk egyetlen nagy blackbox-ot
- Daraboljuk a blackboxokat, és kölcsönhatásokat térképezünk fel (funkcionális klaszterek).
- Ha sikerül azonosítani egy kellően fontos, kellően kicsi, kellően egyszerű funkcionális klaszter, azt meg kell próbálni alulról felépíteni üzleti objektumokból (hierarchiát építve).


Előnyök:


- Igyekszik egymáshoz a lehető legközelebb hozni az egyértelműsítő IT valamint a "projekt-finanszírozó" üzleti személetet.


- Up-To-Date-ség

- Az üzleti objektumok hierarchiája mentén teszőleges lineárisan olvasható olvasmány kigenerálható, tetszőlegesen új kollégának
- Jól-kereshető tud lenni a dokumentum.
- A változásmenedzsmentjének dokumentálása könnyedén megoldható.

A feladat legnehezebb, legrázósabb része - nemkicsit megdöbbentő módon - az üzleti objetumok fizikai és üzleti elnevezése (de ez kereskedelmi szoftver használatánál is így lenne).
Szerintem..........