Adattárházak

Ez az oldal a korábbi SCH wiki-ről lett áthozva. Az eredeti változata itt érhető el.

Ha úgy érzed, hogy bármilyen formázási vagy tartalmi probléma van vele, akkor kérlek javíts rajta egy rövid szerkesztéssel.

Ha nem tudod, hogyan indulj el, olvasd el a migrálási útmutatót

Definíció

Adattárház olyan információs rendszer, melyet jellegzetes szervezeti és stratégiai döntés támogatásra használnak. Négy fő tulajdonsága van:

• subject-oriented : egy helyen jelennek meg az üzleti logikai fogalmak, nem rendszerekben elosztva. Korábban function-oriented-ek voltak
• integrated : konzisztens kód és adatformátumok
• time-variant : Az adatok idősorosan vannak tárolva, bármi áron kiszolgálva a múltbéli adatok elemezhetőségét.
• non-volatile : nincs lehetőség adatmódosításra, csak beolvasási és lekérdezési műveletek adottak. Minden betöltött adatot megőrzünk, még a vélhetően hibás adatok javítására sincs mód. Az ==UPDATE== műveletek kizárását a nagy költségek indokolják. Az adott rekordot érvénytelenné tehető, és helyére betölthetünk egy újat/frissebbet (jelölve az adatok hatályosságát).

Architektúrák

• koncepcionális elvi
• adat (konzisztencia) milyen módszerekkel
• front-end (végfelhasználó hogyan használja), back-end (letöltöget)
• eszközarchitektúra fizikailag milyen eszközök
• üzemeltetési milyen funkciókat
• biztonsági biztonság megteremtése

Az koncepcionális architektúra tervezés elemei:

• forrásrendszerek nincs plusz terhelhetőség, max járatban így szedi ki belőle az adatot
• kinyerés-integrálás úgy kell az adatot kinyerni, hogy a legkisebb terheléssel és módosítással tegyük
• állomásoztató terület ( Staging Area - SA) A back-end nagy része. Itt zajlik az átadott adatok összekapcsolása, transzformációja, módosítása; legtöbb hozzáadott értelmet ez állítja elő.
• elemi adattár
• szakterületi adattár lekérdezés orientált adatstruktúrák tervezése és megvalósítása
• metaadattár
• üzemi adattár (operational data store - ODS)
  • integrált és téma orientált adatok,
  • nem historikus: csak a jelen helyzet olvasható ki
  • aggregált adatok helyett elemieket tárol
  • Célja: megkönnyítse az adatok integrálását, lehetővé tegye a jelen idejű adatok lekérdezését, adatmódosítás végrehajtása több rendszer érintésével (több helyen egyszerre változik az adat) MOM (Message Oriented Middleware) direkt mód
• megjelenítés támogatás

Fejlődése

Összehasonlítási alapok:

• megvalósítás költsége
• megvalósíthatóság
• rugalmasság
• funkcionalitás
• adatkonzisztencia
• illeszkedés a vállalati hierarchiához.

Állomások:

• Nem tervezett döntéstámogatás: Egyszerű (a felmerült igények mentén alakítjuk a felületet) viszont hosszú távon igen drága, hiszen a fizikailag elkülönült front-end-ek káoszt okozhatnak. Rugalmatlan (a forrásrendszerben bekövetkezett változást problémás több helyen lekezelni), inkonzisztens.
• Szakterületi adattár szemantikai integrálása : egységes vállalati adatmodell lekérdezhetősége és a logikai kapcsolatok felépítése. Jóval több erőfeszítést igényel, illetve új szerepkör: adatgondnok. Csökkenti a forrásrendszerek terhelését. A bemeneti adatok konzisztenciája nem biztosított, ugyanis nincs fizikai adatintegrálás.
• virtuálisan integrált szakterületi adattárak: funkcionalitás többletet ad a Middleware használata.
• függő szakterületi adattár: (hub and spoke architektúra) Mind a szemantikai mind a fizikai integritás garantált. Részletes adattárház áll rendelkezésre a beérkező adatok feldolgozása után. Az adatok összekapcsolása megvalósítja, hogy a különbözőképpen megadott lekérdezések azonos eredményt szolgáltatnak. Jól skálázható, kategorikus tiltások.
  • részletes adattárház - nagykereskedő
  • szakterületi adattár - kiskereskedő

üzemeltetési architektúra

CSONK ömlesztett

• adatminőség problematikája
  • soha ne higyjünk annak, ha a megrendelő azt mondja, hogy jó minőségű az adatforrás
  • mit tegyünk a rossz adatokkal?
    • a rekord mögött valami valós cselekmény van
    • ha nem töltöm be, akkor biztos, hogy csalok
    • mitől rossz?
      • valami adat hibás, hiányos, értelmetlen
      • nem ahhoz a klienshez lehet kapcsolni
• ütemezés
  • betöltés, transzformáció...
  • elegáns megoldás
    • éjszaka betöltés
    • nappali lekérdezés
  • mi van, ha naponta többször kell adatot átvenni? hogy segít ebben a koncepcionális architektúra?
    • közös diszk-alrendszer
    • külön node végzi a betöltést
    • külön node végzi a kérések kiszolgálását
    • ha alacsony szinten (tranzakciókezelést és constraint ellenőrzést kihagyjuk), akkor sokkal gyorsabb lehet a betöltés
    • bulk loading
  • kérdés az automatizáltság foka
    • első lépésben a full automatizmus irreális cél
    • legyen benne a potenciál, pl workflow management
    • az üzemeltetés során alakulnak ki a feltételek, amikre a későbbiek során érdemes automatizmust építeni
  • hogyan menedzseljük az összeg táblákat?
  • hogyan monitorozzuk a használatot?
    • ki, mit, mikor kérdezett le a dw-ből?
    • mennyire terhelt a rendszert?
  • hardware, operációs rendszer üzemeltetése
  • fejlesztői - teszt - üzemi környezet szeparálva (teszt és üzemi adatokhoz nem szabad, hogy hozzáférjen a fejlesztő: ugyanis a teszt adatoknak valóságosnak kell lenni)
  • fizikailag vagy logikailag szeparálva

-- adamo - 2007.11.06.