Felraktam az SQL Server 2012 RC0-át és a collation default beállítása Hungarian_CI_AS. Mutatom:

Miért baj ez? Mert a Hungarian collation használja a dupla mássalhangzókat. Csakhogy szegén SQL Server nem tudja eldönteni, hogy pl. a „Táncstúdió” szavunkban a „Tán” után következő „c” és „s” betű „cs” betű avagy „c” és „s”. És mivel ő „cs”-nek gondolja ezért nem találja meg, ha úgy keresünk rá, hogy  Select * from t where szo like 'Tánc%'

Hogy ezt elkerüljük, meg kell változtatni a collationt Hungarian_CI_AS-ről Hungarian_Technical_CI_AS-re. De most jut eszembe, hogy erről a témáról már egyszer hosszan értekeztem itt: Magyar adattárházak nyelvi problémái I: cs, ty, sz, dzs … betűk

Máshol még nem hallottam pontos dátumot, de az sqlserverlaunch.com oldalon ez olvasható: „Join us on March 7, 2012 and be a part of the SQL Server 2012 Virtual Launch Event.” Meglátjuk. Mindenesetre a számláló szerint 42 nap 20 óra és 30 perc van még az eseményig…

Készülök a jövő heti Önkiszolgáló BI workshopra és felmerült a következő probléma:

Szeretnénk létrehozni ügyfeleinkből egy olyan csoportot, amelybe csak a jó ügyfelek tartoznak. Tegyük fel, hogy a jó ügyfél az, akinek a jövedelme > 200000 Ft, az vásárlásainak száma > 2 és szeme színe = kék

Az ilyen típusú ügyfélcsoportot a PowerPivottal háromféleképpen is létre tudjuk hozni:

-          nevesített halmazokkal (Azokat válogatjuk bele a halmazba, akik a feltételnek megfelelnek)

-          számított oszloppal (létrehozunk az oszlopalapú adatbázisban egy jó ügyfél? számított oszlopot amibe I-t írunk, ha megfelel a feltételeknek, N-et ha nem és utána szűrünk a riporton az I-sekre)

-          Importálás közben a relációs motorral kiszámítatva (Importálás előtt SQL oldalon hozzuk létre a jó ügyfél? oszlopot és a PowerPivotban csak szűrünk rá)

Mindhárom megoldás jó, de teljesítmény szempontjából (Lekérdezés teljesítménye szempontjából) nagyok a különbségek. A legjobb az „Importálás közben a relációs motorral kiszámítatva” aztán következik a „Számított oszloppal” és végül a „nevesített halmazokkal”

Sajnos a megvalósítás egyszerűsége szempontjából viszont pont fordított a sorrend. Ha a felhasználóink informatikai affinitása minimális, akkor az Excelen (Pivot tábla) keresztül a varázslóval építsük fel a nevesített halmazokat. Ha SQL-hez nem értenek de az Excelben tudják használni az (If, then, else) függvényeket, akkor számított oszlopot használjuk a PowerPivot adatbázisában. Ha pedig értenek annyira az SQL-hez, hogy meg tudjanak fogalmazni egy CASE-es lekérdezést, akkor import során számítassuk ki a szűrőfeltételeket.

Ha tehát a teljesítmény a fontos, akkor importálás előtt hozzuk létre az ügyfélcsoportot, ha az egyszerű kezelhetőség, akkor a pivot táblán keresztül hozzuk létre a nevesített halmazt.

14 új T-SQL függvény kerül az SQL Server 2012-be. Ezek listája (és leírásai) megtalálhatóak a következő cikkben: New Built-In TSQL Functions in SQL Server 2012

Január 31.-én a BI consulting félnapos rendezvényt szervez, melynek programja négy nagy blokkból fog állni:

·         Áttekintés és értékelés a 2011-es év legfontosabb eseményeiről, új termékekről, felvásárlásokról

·         Technológiai és alkalmazási trendek: Big Data, mobil BI, szociális analitika, önkiszolgáló üzleti intelligencia

·         Piaci körkép a BI szállítók kínálatáról, a  nagyok és kicsik folyamatos innovációs és üzleti küzdelméről

·         Az üzleti intelligencia helyzete Magyarországon

A konferencián Arató Bence fog beszélni. Érdemes lesz elmenni és végighallgatni merre ment, merre megy a BI.

Jelentkezés és további részletek a konferencia honlapján

Eddig nem tudtam, hogy az Integration Services-ből ismert

-          Fuzzy Lookup taszk segít a Bing Map-nek a beírt kérésekhez megtalálni a megfelelő koordinátákat,

-          a Fuzzy Grouping taszk segít a Bing Shopping-nak kiszűrni a duplikált termék neveket és leírásokat,

-          és a Data Profiling taszk segít a PowerPivotnak felfedezni a táblák közti kapcsolatot.

Néha nem, néha viszont elég hatékonyan működik az információáramlás a Microsofton belül ha figyelembe vesszük hogy a Bing Map, Bing Shopping és a PowerPivot fejlesztői ismerik az SSIS adattisztító szolgáltatásait…

Forrás: Microsoft Research: Data Cleaning

OLAP-os fejlesztéskor sokszor felmerült a kérdés, hogy hol hozzuk létre a számított mezőket: a kocka alatt lévő relációs táblákban vagy a kockában magában? OLAP oldalon az általunk használt legjobb gyakorlat az volt, hogy ha a számítás elvégezhető aggregálás előtt, akkor a relációs nézetben a helye! Mondok egy példát: Ha van egy nettó Ft és egy áfa összege FT oszlopunk a relációs táblában, akkor a bruttó Ft-t nem az OLAP oldalon számoltuk, hanem a relációs táblában, vagy az OLAP és a relációs tábla közti nézetben.

Miért? Mert a csillagsémát relációs riporting eszközök is használhatják, így nekik is szükségük lehet rá.

Mi a helyzet a PowerPivottal? ott is igaz a fenti mondás?

A PowerPivot esetében már nem ilyen tiszta a kép. Azt ugyanis nem biztos, hogy IT-sok fejlesztik és nem biztos, hogy módosítani tudják az üzleti felhasználók a forrást, nem biztos hogy van alatta egy csillagsémás adattárház, … Így egyáltalán nem biztos, hogy ez opció. De tudnunk kell arról, hogy a PowerPivot sokkal jobban tudja tömöríteni a relációs oldalon előre kiszámolt mutatókat, mint az általa betöltés közben számítottakat. Így technikai értelemben a sorszintű számításoknak a relációs táblában/nézetben van a helyem de üzemeltetési és egyéb szempontok miatt nem biztos, hogy oda tudjuk/ kéne tenni

Kezdjük ott, hogy a KOCKA.ÉRTÉK (vagy CUBEVALUE) függvény üres sztringet ad vissza, ha olyan dimenzióelem kombinációkat kérdezünk le, amelyek metszéspontjában nem található érték az adatbázisban. Látszólag ezzel nincs is semmi baj, csakhogy az üres sztring nem NULL érték. Így - bár a felhasználóknak ugyanúgy jelenik meg a NULL érték mint az üres sztring, de számolni már nem ugyanúgy tudunk vele. 1 + NULL ugyanis 1, de 1 + ”” = #ÉRTÉK!

Tudjuk kezelni az ilyen típusú problémákat? Részben. Egy Excel függvénynek ugyanis nem lehet üres visszatérési értéke, így nem tudunk olyan függvényt írni, ami NULL értéket ad vissza. Ergó a KOCKA.ÉRTÉK függvénynek sem lehet NULL visszatérési értéke (Valószínűleg azért mert az Excel nem tudja kezelni azt a szituációt, hogy egy cella tartalmaz is valamit, meg nem is. Tartalmazza a függvényt, de azt várjuk tőle hogy néha viselkedjen úgy mint egy teljesen üres cella. Egy olyan, amibe még sosem írt senki semmit).

Marad tehát a nullával való helyettesítés:

HA(KOCKA.ÉRTÉK()=""; 0; KOCKA.ÉRTÉK())

Érdekes gondolat kiegészítőként a Word helyesírás ellenőrzőjét használni adattisztításhoz, de az SQL 2012 Data Quality Services szolgáltatása erre elvben lehetőséget fog biztosítani. Sajnos nem találtam arra vonatkozólag infót, hogy a Data Quality Services Speller nevű alkalmazás csak hasonlóan működik az Office helyesírás ellenőrzőjéhez, vagy tényleges az fog futni a háttérben. Márpedig ez nekünk magyar nyelvterületen élőknek nagyon nem mindegy…

Forrás: SQL Server 2012 RC0 - What's New in DQS?