Hol tároljuk az OLAP kockák felépítéséhez szükséges üzleti logikát?
Hagy osszak meg Önnel egy keserű tapasztalatot: A minap OLAP kockákat kellett ráültetnem az adattárházra. A csillagsémákat egy-az egyben fel lehetett használni az OLAP kockák elkészítésére, ezért úgy döntöttem, hogy eltérek a megszokott gyakorlattól: nem fogok view-kat építeni az adattárház és az OLAP adatbázis közé, hanem mindent az adatforrás nézetek (Data Source View) segítségével valósítok meg.
Működött a dolog mindaddig, amíg nem kellett szerepjátszó (role playing) dimenziót létrehoznom…
Korábban, - amikor view-kat használtam az OLAP adatbázis és az adattárház között -, úgy hoztam létre új szerepjátszó dimenziót, hogy lemásoltam az eredetit, és alatta kicseréltem view-t az új szerepnek megfelelő view-ra (pl idő dimenzió variációk).
Ha nem view-kat használunk, hanem az adatforrás nézetekben definiált úgynevezetett named query-ket (amelyek funkciója egyébként ugyanaz), akkor a dimenzió lemásolása után nem fogjuk tudni kicserélni a named query-t az új szerepnek megfelelő named query-re. Helyette kézzel, elölről kell felépítenünk a szerepjátszó dimenziót…
Konklúzió
Bár, az adatforrás nézetek lehetőséget biztosítanak komplex sémák kialakítására, az OLAP és a relációs adatbázis között továbbra is célszerű view-kat használni az üzleti logika megfogalmazására:
- Az adatbázisban definiált csillagsémát elérhetik távoli alkalmazások, szerverek és adatbázisok. Ugyanez az adatforrás nézetekről nem mondható el.
- Az adatforrás nézetben létrehozott csillag sémát sajnos még a Reporting Services sem látja. Hiába alakítunk ki képleteket, felhasználó barát megnevezéseket, üzleti logikát az adatforrás nézetben, ha azt nem tudjuk máshol használni. Ellenben ha ugyanezt a relációs oldalon, view-kal oldjuk meg, akkor mind az Analysis Services, mind a Reporting Services látni fogja.
- A view-k definiálásával egyszerűsíthető a jogosultság kezelés, szépíthető a táblák, oszlopok megnevezése, függetleníthető az OLAP az adattárház fizikai szerkezetének változásától,
- Könnyebb, jobban kezelhető felületek léteznek az adatbázis nézetek (view-k) szerkesztéséhez, mint az adatforrás nézetek szerkesztéséhez.
- Nézetek (view) használata esetén könnyen tudunk szerepjátszó dimenziókat származtatni meglévő dimenziók meta adataiból,
- A nézetekbe tudunk lekérdezés hinteket tenni (mint pl. a NOLOCK) amivel gyorsíthatjuk az adatkockák felösszegzését, de az adatforrás nézetbe nem
- És fejlesztés közben a nézetet átírva egy backup adatbázison építhetjük OLAP kockáinkat, míg a többiek dolgoznak a ténytáblán...
Persze, ha OLAP kockát nem a saját adatbázisunkra, hanem mások adatbázisára kell építenünk, és nem engedik meg nekünk a view-k létrehozását (pl idegen, vagy nem MSSQL alapú adattárház), akkor nincs más választásunk, mint az adatforrás nézetben definiált named query-k használata. De minden más esetben célszerűbb view-kat használni…
Apropó view-k. Ön szerint érdemes adatbázis nézeteket definiálni az adattárház és az OLAP közé, ha erre egyébként nem lenne szükség? A válasz igen, hiszen egy új üzleti logikát (pl képzett aggregációs csoportok) beépíthetünk a view-k ba az adattárház módosítása nélkül.
Kővári Attila - BI projekt
Új hozzászólás