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.