{"id":65,"date":"2009-03-03T13:02:24","date_gmt":"2009-03-03T12:02:24","guid":{"rendered":"http:\/\/csopro.de\/biblog\/2009\/03\/ssis-binaere-collation-bei-der-suche\/"},"modified":"2009-03-03T13:02:24","modified_gmt":"2009-03-03T12:02:24","slug":"ssis-binaere-collation-bei-der-suche","status":"publish","type":"post","link":"https:\/\/www.csopro.de\/biblog\/2009\/03\/ssis-binaere-collation-bei-der-suche\/","title":{"rendered":"SSIS – bin\u00e4re Collation bei der Suche"},"content":{"rendered":"

In einem fr\u00fcheren Blog-Eintrag habe ich beschrieben, wie die Suche im SQL Server Integration Services (im Standard) abh\u00e4ngig von der Gro\u00df- und Kleinschreibung ist. Das liegt daran, dass der Cache im Integration Services bin\u00e4r angelegt werden, so dass „Martin“, „martin“ und „MARTIN“ 3 unterschiedliche ELemente sind, wohingegen bei einem SELECT DISTINCT Vorname FROM Personen dies (in der Standard-Collation) nur als einen Wert zur\u00fcckliefern w\u00fcrde.<\/p>\n

Dieses Ph\u00e4nomen tritt aber nat\u00fcrlich nicht nur bei Gro\u00df- und Kleinschreibung auf, sondern bei allen Strings, die laut Collation gleich sind.<\/p>\n

Damit f\u00fchrt das Standard-Szenario nicht zum gew\u00fcnschten Ergebnis, wenn ich zum Beispiel Vornamen in eine Dimensionstabelle umsetzen will:<\/p>\n

\"Paket-Beispiel<\/p>\n

\"Laden\"Beispiel<\/p>\n

 <\/p>\n

In meinem Beispiel habe ich die Personen-Tabelle wie folgt gef\u00fcllt:<\/p>\n

\"Inhalt<\/p>\n

Auf der Nachnamen-Spalte habe ich die Standard-Collation (SQL_Latin1_General_CP1_CI_AS) verwendet, die Vornamen-Spalte habe ich so eingestellt, dass auch Akzente ignoriert werden (Collation Latin1_General_CI_AI) (OK, das ist ein bisschen gestellt, aber in der Praxis hatte ich einen \u00e4hnlichen Fall).<\/p>\n

Somit liefert select distinct vorname from person:<\/p>\n

\"SELECT<\/p>\n

und select distinct nachname from person:<\/p>\n

\"SLECT<\/p>\n

Man beachte, dass bei der Standard-Collation \u00df wie ss behandelt wird.<\/p>\n

Nun ist klar, dass beim Lookup nach Vorname im Faktenimport nicht alle Vornamen einen Treffer liefern und somit das ETL einen Fehler schmei\u00dft.<\/p>\n

Au\u00dferdem ist es vermutlich nicht sinnvoll, dass Michel und Mich\u00e9l gleiche Vornamen sind. Deswegen beitet es sich in diesem Fall an, dass alle unterschiedlichen Schreibweisen der Vornamen auch unterschiedliche Dimensionselemente werden. Dazu kann man im Dimensions-SELECT statt „SELECT DISTINCT Vorname FROM Personen“ besser „SELECT DISTINCT vorname COLLATE Latin1_General_BIN as Vorname from person“ verwendet. Damit instruiert man den SQL Server die bin\u00e4re Collation zu verwenden und somit sind beim SQL Server selbst die einzelnen Vornamen nicht mehr gleich – und schon geht’s.<\/p>\n

Eine andere Alternative w\u00e4re gewesen, \u00fcber eine Funktion Strings, die gleich sein sollen, in einen eindeutigen String zu \u00fcberf\u00fchren (wie in meinem letzten Blog-Eintrag mit UPPER()). Bei Akzenten ist das aber nicht so einfach.<\/p>\n

Eine weitere Alternative ist, den Lookup nicht mit vollem Cache zu machen, was aber negative Auswirkungen auf die Performance hat. Also k\u00f6nnte man auch zuerst einen Lookup mit vollem Cache und im Fehlerfall einen nachgelagerten Lookup ohne Cache ausf\u00fchren. Im zweiten Lookup kann man dann \u00fcber die Collation genau definieren, welche Strings gleich sein sollen und welche nicht.<\/p>\n

In einem solchen Fall muss man also auf jeden definieren, welche Strings im DWH als gleich angesehen werden sollen. \u00dcber die COLLATION kann man das – wie gezeigt – sehr fein einstellen.<\/p>\n

Nat\u00fcrlich sind solche Szenarien selten, da in der Regel nicht beliebige Freitextwerte in einer Dimension vorkommen – aber, wie in meinen Projekten geschehen, ab und zu gibt es dann doch solche F\u00e4lle.<\/p>\n","protected":false},"excerpt":{"rendered":"

In einem fr\u00fcheren Blog-Eintrag habe ich beschrieben, wie die Suche im SQL Server Integration Services (im Standard) abh\u00e4ngig von der Gro\u00df- und Kleinschreibung ist. Das liegt daran, dass der Cache im Integration Services bin\u00e4r angelegt werden, so dass „Martin“, „martin“ und „MARTIN“ 3 unterschiedliche ELemente sind, wohingegen bei einem SELECT DISTINCT Vorname FROM Personen dies … SSIS – bin\u00e4re Collation bei der Suche<\/span> weiterlesen →<\/span><\/a><\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[10],"tags":[],"class_list":["post-65","post","type-post","status-publish","format-standard","hentry","category-integrationservices"],"_links":{"self":[{"href":"https:\/\/www.csopro.de\/biblog\/wp-json\/wp\/v2\/posts\/65","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.csopro.de\/biblog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.csopro.de\/biblog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.csopro.de\/biblog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.csopro.de\/biblog\/wp-json\/wp\/v2\/comments?post=65"}],"version-history":[{"count":0,"href":"https:\/\/www.csopro.de\/biblog\/wp-json\/wp\/v2\/posts\/65\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.csopro.de\/biblog\/wp-json\/wp\/v2\/media?parent=65"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.csopro.de\/biblog\/wp-json\/wp\/v2\/categories?post=65"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.csopro.de\/biblog\/wp-json\/wp\/v2\/tags?post=65"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}