Hatékony SQL Server 2005 Analysis Services (SSAS)-alapú BI rendszerek tervezése Kővári Attila BI tanácsadó, SQL Server MVP www.biprojekt.hu Kovari.Attila@biprojekt.hu

Az előadásról Kinek szól az előadás: Az előadás célja Akik már ismerik valamennyire az Analysis Services-t. Tudnak dimenziót, kockát építeni. Az előadás célja Hogy segítséget adjon Önöknek hatékony OLAP-alapú vezetői információs Rendszerek, vagy BI megoldások tervezéséhez.

Tematika Miért használjunk OLAP-ot? Hatékony OLAP rendszerek alapkövetelményei Hatékony Dimenziók Attribútumok Hierarchiák tervezése Az idő dimenzió jelentősége és problémái Adatkockák tervezési kérdései

Miért használjunk OLAP-ot? Egy jól megépített csillagséma és egy OLAP kocka elemei egymásnak kölcsönösen megfeleltethetőek. (1:1 mapping) Dimenzió tábla = dimenzió (Adatkocka éle) Ténytábla = Adatkocka cellája Csillag séma = Adatkocka Akkor miért használjuk? Lényegesen jobb lekérdezési sebesség (és nehéz úgy megfektetni, mint a relációst) Klasszisokkal jobb riportkészítő és lekérdező eszközök léteznek hozzá, mint a relációshoz Lényegesen jobb elemzési támogatást nyújt (idősor összehasonlítások) Jogosultság kezelés: A relációs oldalon nehéz olyan jogosultság kezelést kialakítani, hogy valaki láthatja az összegző szint adatait, de részletező sorokat már nem (ad-hoc lekérdezések esetén)

Tematika Miért használjunk OLAP-ot? Hatékony OLAP rendszerek alapkövetelményei Hatékony Dimenziók Attribútumok Hierarchiák tervezése Az idő dimenzió jelentősége és problémái Adatkockák tervezési kérdései

Hatékony OLAP rendszerek alapkövetelményei Építsünk jó csillagsémát! Ne bízzuk az Analysis Services-re a csillag séma vagy az ETL folyatat hibáinak, hiányosságainak kijavítását!!! Ismeretlen dimenzióelem, duplikált dimenzióelem, ismeretlen szülő, … Mind-mind ETL probléma, ott kell megoldani! Hiányzó elsődleges kulcsok, kalkulációk mind-mind csillagséma probléma, ott kell megoldani! Ha ezen követelményeknek megfelelünk, akkor a problémák java részét kiküszöböltük 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 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 (és az adatpiacon definiált relációs riportok) az adatpiac 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. És view-k használata esetén könnyen tudunk szerepjátszó dimenziókat származtatni meglévő dimenziók meta adataiból… 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…

Tematika Miért használjunk OLAP-ot? Hatékony OLAP rendszerek alapkövetelményei Hatékony Dimenziók Attribútumok Hierarchiák tervezése Az idő dimenzió jelentősége és problémái Adatkockák tervezési kérdései

Dimenziók – Attribútumok – Hierarchiák (alapfogalmak) Vizsgálati szempontok (idő, termék, vevő, …) A dimenziók attribútumokból, és hierarchiákból épülnek fel. Attribútumok Felfogható, mint egy hierarchia szintjei (Év, negyedév, hónap, nap,…) Felfogható, mint dimenzió elemek tulajdonsága (egyszintű hierarchia) (Hét napjai, Munka-, vagy szabadnap) Attribútumok kapcsolata 1:1 es attribútum (pl. egy ügyfél e-mail címe, telefonszáma, …) (ex member property) 1:M-es attribútum (Hét napjai) Hierarchiák Az attribútumok láncolata (év alatta negyedév, alatta hónap, …) Fajtái Természetes (natural) Reporting. (Sió, alatta 1 literes, alatta 12% gyümölcstartalom, ..)

Dimenziók – Attribútumok – Hierarchiák (Tervezés) Termékcsoport Gyümölcstart Kiszerelés EAN (Cikk kód) Termék Attribútumok: Termékcsoport Termékek ALL (User) Hierarchia Gyümölcstart Kiszerelés Attribútum hier: (1:M Attribútum) EAN (Cikk kód) Attribútum reláció (1:1-es Attribútum) AttributeHierarchyEnabled=false Célszerű minden dimenzión legalább egy (user) hierarchiát építeni. (Általában nem létezik az üzleti életben olyan dimenzió amin nem definiálható legalább egy (user) hierarchia) Egyébként hatékonysági szempontból is fontos, mert az aggregáció tervező csak két dolgot vesz figyelembe alapértelmezettként a tervezésnél: a kulcs attribútumot és azokat, amelyeket tartalmaz a hier

Hatékony dimenziók tervezése Használjunk kevés dimenziót (5-10/kocka) sok-sok attribútummal és hierarchiával Építsünk egy „conform” dimenziót (pl. Dátum), és ezekből származtassunk sok-sok szerepjátszó dimenziót (rendelés dátuma, szállítás dátuma, …) Csak azokat az elemeket válogassuk be a szerepjátszó dimenzióba, amelyre az adott téma elemzőjének szüksége lesz (Belföldi vevők, export vevők) Érdekes, hogy az emberek relációs oldalon meg tudnak tervezni egy dimenzió táblát, de ha átülnek a többdimenziós oldalra, akkor mindent elfelejtenek és neki állnak százdimenziós kockákat gyártani.

Hatékony attribútumok tervezése Egy attribútum ne legyen egyszerre eleme egy attribútum hierarchiának (Attribute hierarchy), és egy felhasználói hierarchiának (user hierarchy). Csak a szükséges információkból képezzünk attribútumot! Minden attribútum rendelkezzen EGYEDI kulccsal! (Q1 helyett Q1 2007, Q1 2006) A kulcsok legyenek egész számok (mint a surrogate key-k) Állítsuk Rigid-re azon attribútumok RelationshipType tulajdonságát, amelyek nem változnak az időben. (pl. az ügyfél neme) Használjunk default membert a nem aggregálható attribútumokra!

Hatékony attribútum relációk tervezése Használjunk tranzitív relációkat! Azon attribútumokat kössük össze, amelyek között a valóságban is létezik KÖZVETLEN kapcsolat! Az Analysis Services felismeri és megfelelően használja a tranzitív relációkat A tranzitív reláció segít az aggregáció tervezőnek! Az analysis Services felismeri és megfelelően használja a tranzitív relációkat! A tranzitív reláció olyan reláció, amely szerint ha az első és második elem, továbbá a második és harmadik elem azonos viszonyban áll egymással, akkor ez a viszony az első és harmadik elem között is fennáll. Ez segít az aggregáció tervezőnek, hatékony aggregációkat készíteni. A tranzitív reláció olyan reláció, amely szerint ha az első és második elem, továbbá a második és harmadik elem azonos viszonyban áll egymással, akkor ez a viszony az első és harmadik elem között is fennáll.

Hatékony attribútum relációk tervezése kerüljük a redundáns relációkat! Megnövelik a dimenzió méretét Megnehezítik az aggregáció tervezést Megnövelik a felösszegzések időszükségletét Speciális esetben csupa NULL értéket adhat vissza a lekérdezés Ha van olyan measure group-unk amely nem a member key-vel csatlakozik a dimenzióhoz, akkor előfordulhat, hogy az Analysis Services nem összegzi fel a kocka adatait az adott attribútum szerint, és ha ezt az attribútumot választjuk lapozó dimenziónak, akkor csupa NULL értéket ad vissza. A figyelmeztető ablak hibaüzenete: This dimension contains one or more redundant attribute relationships. These relationships may prevent data from being aggregated when a non-key attribute is used as a granularity attribute in a cube. Verify the following relationships and delete those that are not needed: [Day] -> [Year]; [Day] -> [Quarter].

Hatékony hierarchiák tervezése A hierarchiák csak az attribútumok közti kapcsolatot írják le (előre definiált bejárási útvonal) Az attribútumok beágyazásával előállíthatunk ad-hoc hierarchiákat is Akkor miért használjuk? Mert az ember is használ hierarchiákat fogalmai rendezéséhez. Mert a kliens alkalmazások még hierarchiákra (és nem attribútumokra) vannak optimalizálva Mert segít az aggregáció tervezőnek optimalizálni Madár-e a kanári? 75 ezredmásodperc? Állat e a madár? 75 ezredmásodperc Állat-e a kanári? 150 ezredmásodperc

Hatékony hierarchiák tervezése folytatás… Csak természetes hierarchiákat definiáljunk (ország-város; év-negyedév-hónap) Ne definiáljunk reporting hierarchiákat! Ezt bízzuk a felhasználókra (Összes termék, alatta 1 literes kiszerelésűek, alatta alma ízűek, alatta 12%-os gyümölcstartalmúak) klasszikus hiba: ország, alatta vevő Csak olyan attribútumokra definiáljunk hierarchiát, amelyek között létezik élő (üzletileg létező) kapcsolat! És a hierarchiával csak erősítsük meg ezt a kapcsolatot, hogy az aggregáció tervező és a felhasználók munkáját is könnyítsük.

Tematika Miért használjunk OLAP-ot? Hatékony OLAP rendszerek alapkövetelményei Hatékony Dimenziók Attribútumok Hierarchiák tervezése Az idő dimenzió jelentősége és problémái Adatkockák tervezési kérdései

Hatékony idő dimenzió tervezése Az idő dimenzió az OLAP-alapú rendszerek lelke Mind a dimenziónak, mind attribútumainak Time típusúnak kell lennie! Az attribútumait rendezni kell! (OrderBy tulajdonság) Mindig teljes évet vegyünk fel! Kódok: Member key (Mesterséges kulcs: 20070516) Member value (természetes kulcs: 2007-05-16) Member name (május 16, 2007) Az Excel 2007 fel tudja használni a member value tulajdonság értékét, ha az dátum!

Hatékony idő dimenzió tervezése Hierarchia szintenként 2 attribútum Hónap attribútum Elemei: január, 2007; február, 2007; Elemszáma = évek száma * 12 Ebből építsünk hierarchiát! Az év hónapjai attribútum Elemei: január, február, március, … Elemszáma = 12 Ez legyen független attribútum (Ezt használjuk szezonalitás vizsgálathoz.)

Hatékony idő dimenzió tervezése YTD, YoY, … Hova tegyük a YTD, YoY, … kalkulációkat? Measures? Idő dimenzióba mint attribútum? Hozzunk létre külön idősor kalkulációk dimenziót!

Hatékony idő dimenzió tervezése a problémák: Gyémánt alak (Diamond shape) Egy dimenzión belül két olyan legfelső szint, ahol nincs ALL member http://www.sqljunkies.com/WebLog/mosha/archive/2006/10/25/time_calculations_parallelperiod.aspx

Hatékony idő dimenzió tervezésének problémái: ALL level Az idő dimenzióra nem teszünk ALL szintet, mert üzletileg nincs értelme! De ha két hierarchiát is használunk, (Pénzügyi, naptári) akkor kénytelenek vagyunk. Megoldás: Vagy ALL szint, vagy csak egyféle hierarchia.

Hatékony adatkockák tervezése Használjuk a forrásadat collation-jét Válasszuk a szükséges legkisebb adattípust A collation szükséges a helyes rendezési sorrendhez, de karakter sorozatok összehasonlításához is. Különösen akkor kell figyelnünk ha distinct count measure-t építünk rá! A collaction-öket adatbázis, kocka, dimenzió vagy kapcsolódó oszlop szinjén is meghatározhatjuk! A szükséges legkisebb adattípust ALL szinten kell mérni!

Összefoglaló Építsen jó csillagsémát, és erre ültessen egy OLAP kockát! Használjon kevés „conform” dimenziót sok attribútummal Fordítson extra figyelmet az attribútum kapcsolatok tervezésére Csak természetes hierarchiákat definiáljon

További információk OLAP Design Best Practices for Analysis Services 2005 http://www.microsoft.com/technet/prodtechnol/sql/bestpractice/olapdbpssas2005.mspx Analysis Services 2005 Performance Guide http://download.microsoft.com/download/8/5/e/85eea4fa-b3bb-4426-97d0-7f7151b2011c/SSAS2005PerfGuide.doc Project REAL: Analysis Services Technical Drilldown http://www.microsoft.com/technet/prodtechnol/sql/2005/realastd.mspx Magyar nyelvű anyagok http://www.biprojekt.hu/blog/Analysis_Services_2005.htm