Magyar adattárházak nyelvi problémái I: cs, ty, sz, dzs … betűk

Nincs ma Magyarországon olyan ember aki számítógépet használ és ne ütközött volna nyelvi problémákba. Elég csak az ô o ő o betűkre gondolni. Mindegyiket olvashatjuk hosszú ő-nek de valójában ezek különböző karakterek

A mai cikkben mégsem erről, hanem egy sokkal kevésbé szembetűnő és épp ezért sokkal nagyobb galibát okozó magyar nyelvi sajátosságból eredő problémáról, a kettős mássalhangzókról fogok írni.

Talán még emlékszik, hogy hogyan tanultuk az ABC-t az iskolában: a,á,b,c,cs, … és itt meg is állhatunk a felsorolásban. A magyar ABC tartalmaz olyan betűt amely két (vagy három) karakterből áll. Például c-ből és s-ből. Vagy d-ből és zs-ből (mint a bendzsó vagy a dzsoli dzsóker) De ezeket a dupla mássalhangzókat hiába keressük a magyar karaktereket tartalmazó (1250-es) kódkészletben…

Persze ebből még nem következik, hogy ez baj hiszen a cs betűt ábrázolhatjuk és tárolhatjuk úgy is, hogy a c és s betűket összefűzzük. De mikor viselkedik úgy mint cs betű (Mint a Táncsics szóban) és mikor viselkedik mint c és s (mint a Táncstúdió összetett szóban)

Apropó.

• Hány betűből áll a bendzsó szó? 5 vagy 7?
• Ön hogyan választaná el a bodza szót? bo-dza, vagy bod-za?

De kanyarodjunk vissza a táncstúdió és Táncsics szavakhoz:

Próbálja meg rendezni a két szót a magyar ABC szerinti sorrendbe. A helyes sorrend:

1. Táncstúdió
2. Táncsics

Hogy rendezi e két szót az SQL Server:

1. Táncsics
2. Táncstúdió

Szemmel látható, hogy van különbség a két rendezési eredmény között, de erre még legyinthetünk: Kit érdekel, hogy nem tud tökéletesen rendezni az SQL Server.

Most próbálja meg e két szó közül kiválasztani azt amelyik tartalmazza a „tánc” szót. A helyes eredmény:

1. Táncstúdió

Ehelyett mit ad vissza az SQL Server?

• Ha a c és s betűket cs betűként kezeli, akkor semmit,
• ha c és s betűket külön kezeli,akkor mindkettőt.

Csakhogy egyik eredmény sem jó! És itt már sejthető, hogy ebből még komoly problémáink lesznek …

Hungarian vagy Hungarian_Techical collation?

Lelövöm a poént rögtön az elején. Ha az adatbázis nyelvi beállításait (Collation) Hungarian-ra állítjuk akkor a

Select * from t

where szo like 'Tánc%'

lekérdezés a nem fogja visszaadni sem a Táncsics, sem a táncstúdió szavakat! Ugyanis Hungarian collation az egymás mellé került c és s betűket cs-nek fogja értelmezni, függetlenül attól. hogy az a cs betű egy valódi cs betű vagy csak egy összetett szó határán elhelyezkedő c és s betű.

Mégis, az emberek nagy többsége választ Hungarian collation-t Hungarian_Technikal helyett. Tévesen.

Hiszen a Hungarian_Technical collation nem használ dupla mássalhangzókat. A Hungarian_Technical collation a CS betűt C-nek és S-nek veszi, így a

Select * from t

where szo like 'Tánc%'

lekérdezés vissza fogja adni a Táncsics szót is és a táncstúdió szót is. Sokszor hallom érvként, hogy „Azért választottam Hungarian collation-t, hogy helyesen, a magyar ABC-nek megfelelően rendezzen az SQL Server”. Csakhogy – mint azt a fenti példán láthatta – az SQL Server nem rendez helyesen Hungarian collation választása esetén sem.

A másik érv amit gyakran hallok, hogy bár magyar nyelvi beállítású adatbázist használok, de nem használok magyar karaktereket!

A property szó tratalmaz ty betűt? A ’H85CSS’ kód tartalmaz CS betűt? Ha a collation hungarian akkor igen. És amíg a Táncsics szónál az embernek még eszébe juthat, hogy ’Táncs%’-ra kell keresnie nem ’Tánc%’-ra addig a ’H85CSS’ szóra keresve már nem. Ha a lekérdezés a ’H85C%’ –re keresve nem ad vissza semmit akkor biztosra vesszük, hogy nincs ilyen kód. Pedig van.

Hogyan változtathatja meg a collation-t?

Bár létezik rá elvi megoldás de egy nagy adattárház esetén (de még egy kisebb BI rendszer esetén is) olyan nagy munka, hogy nem biztos, hogy érdemes belekezdeni. Nem elég ugyanis csak az adattárház adatbázisának nyelvi beállításait (Collation) megváltoztatni, hanem a master és a modell adatbázisokat is újra kell építeni az új collation-nek megfelelően. Miért?

Mert a tempdb objektumai a model adatbázis nyelvi beállításai szerint jönnek létre, és ha a tempdb-ben tárolt tábla collation-e Hungarian, míg az adattárház collation-e Hungarian_Technical akkor a tempdb és az adattárház táblái collation conflict miatt nem kapcsolhatóak össze.

Persze, ha már az SQL Server telepítéskor a megfelelő collation-t választottuk volna akkor fentiek mind nem okoznak problémát, de ha rossz nyelvi beállításokkal indultunk akkor azt később megváltoztatni már csak úgy lehet hogy jó erősen hátba vágjuk az SQL szervert egy szívlapáttal…

Hogyan ellenőrizheti, hogy adattárháza adatbázisai azonos nyelvi beállításokkal (Collation) rendelkeznek?

Belinkeltem ide Önnek egy SQL scriptet amellyel ellenőrizheti, hogy egy a rendszeradatbázisok és az adattárház adatbázisának, illetve azok tábláinak és oszlopainak nyelvi beállításai (collation) egyeznek-e. Hasznos kis script, próbálja ki!

És még egy apróság. A nyelvi beállításoknak nem csak az adattárház relációs adatbázisai között célszerű azonosnak lennie, hanem a relációs és az OLAP adatbázis között is. Bár jómagam nem tudtam reprodukálni, de azt beszélik, hogy a distinct count measure rosszul számolhat, ha eltér az OLAP és a relációs adtabázis collation-e. De egyébként sem szokás szöveges oszlopra distinct count measure-t definiálni… Úgyhogy aki adatkockái tervezésénél figyelembe veszi ezt az utolsó mondatot, annak nem fog eltérést mutatni a distinct count measure még akkor sem, ha különböznek a collationok.

Összefoglalás

A nyelvi különbségekből eredő problémák mindig fejfájást fognak okozni azoknak a nemzeteknek, amelyek karakterkészlete eltér az angol ABC karakterkészletétől. De ez a fájdalom gondos tervezéssel csillapítható vagy teljesen megszüntethető. Csak egy kis odafigyelés és némi tapasztalat kell hozzá.

Remélem, hogy Önnek már nem fognak fejfájást okozni a dupla mássalhangzók és bízom benne, hogy ebbe a csapdába Ön már nem fog belelépni! Használjon Hungarian_Technical collation-t!

ui.: bendzsó szó 5 betűből áll és a bodza szót úgy kell elválasztani, hogy bo-dza.