Csillag vagy hópehely séma?

A most következő cikk írásához Jesse Orosz Star vs. Snowflake in OLAP Land című blogbejegyzése adta az ihletet. Ő ugyanis azt állítja, hogy gyorsabban fel lehet összegezni egy OLAP dimenziót, ha az hópelyhesítve van. (Ő a saját adatbázisán kb 25%-kal gyorsabb felösszegzési időt kapott). Le is írta, hogy azért gyorsabb a hópehely alakú dimenzió felösszegzése, mert az Analysis Services distinct lekérdezéseket küldözget a relációs adattárház felé és ezek bizony gyorsabban lefutnak, ha az attribútumok ki vannak szervezve külön, kevesebb elemet tartalmazó táblákba. Persze a kommentek között megjelent, hogy nem lett volna ekkora sebesség különbség, ha csillagsémának megfelelő dimenziótáblára raktunk volna pár indexet, és ez valószínűleg igaz is. A lényeg az, hogy ennek kapcsán elgondolkodtam, hogy mikor érdemes csillag- vagy hópehelysémát használnunk.

A legjobb gyakorlat szerint nem használunk hópehely sémát. Nem használunk mert

• A felhasználóknak is és a lekérdezés optimalizálónak is sokkal nehezebb megbirkózni egy soktáblából álló hópelyhes lekérdezéssel, mint egy csillagsémás lekérdezés feldolgozásával
• A helytakarékosság (ami ugye az egyik legfőbb érv a hópehely séma mellett) elenyésző

Vannak azonban olyan esetek, amikor érdemes elgondolkodni a hópehelyséma használatán. Ezek:

Ha a dimenziónk attribútumai között kevés olyan van, amely minden dimenzióelemre értelmezve van. (kevés közös attribútuma van a dimenzió elemeknek) Mondok pár példát, hogy kicsit érthetőbb legyen:

• Bank: Adott egy bank amelynek vannak betét és hitel típusú termékei. A két termékfajta annyira különbözőképpen viselkedik (és annyira eltérő tulajdonságokkal rendelkezik), hogy nem biztos, hogy érdemes összelapátolni őket egy közös dimenzióba. Lehet, hogy érdemes létrehoznunk egy közös termék dimenziót, amely tartalmazza a termékek közös tulajdonságát és mellé külön dimenziótáblákba kiszervezni az egyedi termékjellemzőket
• Kampánymenedzsment: A kampányoknak vannak olyan jellemzőik, amelyek minden kampányra jellemzőek. Ilyen pl, hogy van kezdete, vége, üzleti és technikai eredménye, stb. ugyanakkor kampányokon belül már egy csupa olyan egyedi jellemzőt találunk, amely nincs értelmezve minden kampányra. ilyenkor érdemes lehet a különböző kampánytípusokra külön táblát létrehozni, és ezt kapcsolni az alap kampánydimenzióhoz

Megj: A fenti két eset modellezése egyébként elég nehéz. Sokszor nem is így oldjuk meg a problémát, csak nem akarom félrevinni a cikket a nem témábavágó alternatívák bemutatásával. Megj. vége.

Szintén érdemes elgondolkodni a hópelyhesítésen, ha vannak olyan dimenzióink, amely más dimenzióik attribútumait is használják. Mondok megint pár példát:

• Dátum dimenzió: Adott egy üzletkötő dimenzió belépés-kilépés dátumával. Ahelyett, hogy leíró mezőként betennénk a belépés dátumát, érdemes elgondolkodni azon, hogy a már meglévő dátum dimenziónk kulcsát tegyük bele az üzletkötő dimenzióba. Különösen fontos-ez akkor, ha amúgy is szeretnénk használni a dátum dimenzió egyéb attribútumait (Pl szeretnénk lekérdezni az I. negyedévben belépők forgalmát)
• Cím, régió és egyéb földrajzi dimenziók: Adott egy partner/ingatlan/Értékesítési pont, stb. dimenzió a partner/ingatlan/Értékesítési pont címével. Érdemes ebben az esetben létrehozni egy közös cím dimenziót és ezt a cím dimenziót kötni a dimenziókhoz ahelyett, hogy külön-külön, minden dimenzióban tárolnánk a partner/ingatlan/Értékesítési pont címét.

Összefoglalva: Nagy általánosságban akkor érdemes hópelyhesíteni a csillagsémát, ha általa értetőbbé, logikusabbá, egyszerűbben fogyaszthatóvá tesszük az adatmodellt. Pusztán normalizálási szempontok miatt nem érdemes: Jelentős helyet nem nyerünk vele és csak a megnehezítjük a felhasználóink és az adatbázis-kezelő dolgát.