Schlüssel sind wichtig. Manchmal aber auch störend.

In unse­ren mit dem Delta­Master Mode­ler auf­ge­bau­ten Daten­ban­ken exis­tie­ren auf allen Dimen­si­ons- und Fak­ten­ta­bel­len Schlüs­sel- und Fremd­schlüs­sel­be­zie­hun­gen. Diese Tat­sa­che ist uner­läss­lich, will man im Anschluss eine funk­tio­nie­rende OLAP Daten­bank­ar­chi­tek­tur auf­bauen. Jedoch kommt es zuwei­len vor, dass gerade in gro­ßen und umfang­rei­chen nächt­li­chen Trans­form­pro­zes­sen genau eine, im Ide­al­fall sogar iso­liert betracht­bare, Befül­lungs­pro­ze­dur eine Schlüs­sel­ver­let­zung her­vor­ruft. wei­ter­le­sen…

SUM-Where OVER the rainbow

Bereits 2007 haben wir uns in unse­rem Blog Gedan­ken gemacht, wie lange OLAP-Daten­ban­ken wohl noch über­le­ben wer­den. Im Zeit­al­ter des Delta­Master Import­Wiz­zard kommt man auch tat­säch­lich ab und an ins Grü­beln, wozu man diese Form der Daten­ban­ken über­haupt noch benö­tigt? Bei genauer Betrach­tung fin­det man aber schnell zahl­rei­che Gründe, warum wir immer noch lie­ber Wür­fel als Tabel­len bauen. Neben dem deut­lich schnel­le­ren Aggre­ga­ti­ons­ver­hal­ten einer mul­ti­di­men­sio­na­len Daten­bank zählt auch die MDX-Zeit­in­tel­li­genz nach wie vor zu den Plus­punk­ten. Rela­tio­nal Kumu­lie­ren bei­spiels­weise erzeugt bei einem T-SQL-Pro­gram­mie­rer nach wie vor ein flaues Gefühl in der Magen­ge­gend.
2012 ist jetzt auch Micro­soft auf die Idee gekom­men und sagt ihrer eige­nen OLAP-Daten­bank den Kampf an. Mit dem neuen Tabu­lar Mode“ und der Abfra­ge­spra­che DAX des SQL Ser­vers 2012 gibt Micro­soft ein deut­li­ches State­ment für rela­tio­nale Daten­ban­ken ab. Im Zuge des­sen wur­den auch Imple­men­tie­rungs­lü­cken bereits exis­tie­ren­der T-SQL-Befehle beho­ben, so dass künf­tig eine rela­tio­nale Kumu­la­tion einem Pro­gram­mie­rer nur noch ein müdes Lächeln ins Gesicht zau­bern wird.
Wenn Sie wis­sen wol­len wie, dann fol­gen Sie mir ein­fach auf dem Weg zum Ende des Regen­bo­gens… wei­ter­le­sen…

Einsatz von Merge bei Historisierung von Attributen (Teil 2)

In mei­nem letz­ten Bei­trag lern­ten wir wie die Inhalte zweier Tabel­len, mit Hilfe von MERGE”, syn­chro­ni­siert wer­den kön­nen. Heute schauen wir uns an, wie MERGE” uns bezüg­lich His­to­ri­sie­rung der Daten behilf­lich sein kann.
Sicher kön­nen Sie sich noch an die His­to­ri­sie­rung von Attri­bu­ten erin­nern? (Bei­trag vom Juni 2011: His­to­ri­sche Betrach­tung von Stamm­da­ten im Data Wareh­ouse).
Dort wurde zusätz­lich zu meh­re­ren Lösungs­an­sät­zen auch der opti­male Ansatz vor­ge­stellt, näm­lich das His­to­ri­sie­ren durch Zeit­be­trach­tung. Dabei kamen Update- und Ins­ert-State­ments zum Zuge.
Die Ansätze, um Ände­run­gen in Dimen­si­ons­ta­bel­len zeit­be­zo­gen zu erfas­sen und gege­be­nen­falls his­to­ri­sch zu doku­men­tie­ren, sind auch unter dem Begriff Slowly Chan­ging Dimen­si­ons” Typ 2 (deut­sch: sich lang­sam ver­än­dernde Dimen­sio­nen) bekannt.
Man kann mit dem MERGE-Befehl von SQL Ser­ver 2008 die Pflege einer Typ 2 Slowly Chan­ging Dimen­sion (SCD) in einem Data Wareh­ouse in nur einem Befehl erle­di­gen.
Schauen wir uns ein­mal alle mög­li­chen Fälle bei einem Slowly Chan­ging Dimen­si­ons” (SCD2) an. wei­ter­le­sen…

NOT IN = NOT EXPECTED

Da pro­gram­miert man schon Jahr­zehnte lang T-SQL und erlebt doch noch Über­ra­schun­gen bei ver­meint­lich ein­fa­chen Befeh­len. Jüngst haben wir in einer Kun­den­um­ge­bung ver­schie­dene Opti­mie­run­gen durch­ge­führt und unter ande­rem NOT IN Befehle durch LEFT JOINs aus­ge­tauscht. Erwar­tet haben wir ein iden­ti­sches Abfra­ge­er­geb­nis bei deut­lich bes­se­rer Per­for­mance. Aber weit gefehlt. Aus einem uns zu dem Zeit­punkt noch nicht bekann­ten Grund lie­ferte die linke Ver­bin­dung“ ein voll­kom­men ande­res Ergeb­nis als das zuvor ver­wen­dete IN-Kom­mando. Nach einer lang­wie­ri­gen Suche, mit wie­der­hol­ten Zwei­feln an der eige­nen Fach­kom­pe­tenz, haben wir den Grund schließ­lich gefun­den. Und wie sich her­aus­ge­stellt hat, ist die­ser selbst für viele alte Hasen“ über­ra­schend. Also las­sen auch Sie sich über­ra­schen und nicht trau­rig sein – Sie sind in bes­ter Gesell­schaft… ;o) wei­ter­le­sen…

Partitionierte Tabellen – Faktenladen mit Fast = TRUE” (Teil 2)

Uuuund Action! Wie im ers­ten Teil die­ses Bei­trags­the­mas beschrie­ben, schauen wir uns heute die vor­be­rei­te­ten par­ti­tio­nier­ten Tabel­len in Aktion an. Im ers­ten Teil haben wir im SQL Ser­ver die not­wen­di­gen Par­ti­tio­nie­rungs­ob­jekte ange­legt und diese bereits auf eine Fak­ten­ta­belle ange­wen­det. Im zwei­ten Teil ver­su­chen wir jetzt, neue Daten in die Fak­ten­ta­belle zu impor­tie­ren. Dies geschieht nicht wie sonst üblich per DELETE und INSERT, son­dern mit einem soge­nann­ten Par­ti­tion Swap“. Der vor­lie­gende Arti­kel zeigt die not­wen­dige Syn­tax, beleuch­tet die Restrik­tio­nen und zeigt wie viel Opti­mie­rung die Par­ti­tio­nie­rung wirk­lich bringt. wei­ter­le­sen…

Partitionierte Tabellen – Faktenladen mit Fast = TRUE” (Teil 1)

Das sagen­um­wo­bene Flag Fast = TRUE“ hat sich wohl jeder IT-ler in sei­nem Leben schon ein­mal gewünscht. Micro­soft ver­spricht spä­tes­tens ab SQL-Ser­ver-Ver­sion 2005 eine Option, die die­sem Flag schon ziem­lich nahe kommt. Die Rede ist hier von der Mög­lich­keit, Tabel­len zu par­ti­tio­nie­ren. Dies soll deut­li­che Per­for­man­ce­ge­winne ins­be­son­dere beim Laden und Ver­wal­ten von umfang­rei­chen Fak­ten­da­ten ermög­li­chen. Der Clou daran ist, dass ein­zelne Tabel­len­par­ti­tio­nen einer Fak­ten­ta­belle ein­fach gegen eine struk­tu­ri­den­ti­sche Del­ta­ta­belle aus­ge­tauscht wer­den kön­nen. Bei die­ser Ope­ra­tion wer­den ledig­lich Meta­da­ten ver­än­dert, was nur einen Bruch­teil der Zeit eines ech­ten Daten­im­ports benö­ti­gen soll.
Die Restrik­tio­nen, das all­ge­meine Vor­ge­hen sowie die tat­säch­li­chen Per­for­man­ce­ge­winne beim Par­ti­tio­nie­ren wer­den in Teil 1 und 2 des nach­fol­gen­den Arti­kels betrach­tet. wei­ter­le­sen…