Immer diese Stammdaten, Teil 2

Will­kom­men zu dem zwei­ten Teil mei­nes Bei­trags über Ände­run­gen von Stamm­da­ten. Wie ich bereits im ers­ten Teil ange­kün­digt habe, wer­de ich mich heu­te der Erwei­te­rung der bis­her bereits erstell­ten Trans­for­ma­ti­on wid­men. Zunächst ein klei­ner Rück­bli­ck, was haben wir schon gemacht.
In Teil I haben wir im BI-Deve­lop­ment Stu­dio (kurz: BIDS) ein Paket mit einem inte­grier­ten Loo­kup-Task (deut­sch: Suche) erstellt. Der Task ver­gli­ch die Quell­da­ten bereits mit den vor­han­de­nen Daten­sät­zen in der Ziel­ta­bel­le auf unse­rem SQL-Ser­ver und mit Hil­fe eines klei­nen Scripts am Ende des Daten­flus­ses konn­ten wir neue Daten­sät­ze in die Tabel­le mit auf­neh­men. Dar­über hin­aus hat­ten wir den Loo­kup-Task bereits so kon­fi­gu­riert, dass die Spal­ten Posi­ti­on“ und Gewicht“ bereits in einer Art Über­wa­chung“ (im BIDS spre­chen wir hier von der Aus­ga­be für Such­über­ein­stim­mun­gen) vor­ge­hal­ten wur­den. Zusätz­li­ch hat das SQL-Script dann noch in die Ziel­ta­bel­le das Import­da­tum ein­ge­tra­gen bzw. aktua­li­siert. Das war schon sehr schön, aber wir wol­len noch mehr, oder?
Typi­sche Fra­gen wie: Wann wur­de der Wert denn geän­dert?“ oder meist noch wich­ti­ger Was hat sich geän­dert?“ kön­nen wir unse­ren Kun­den so lei­der noch nicht beant­wor­ten. Mit nur ein paar klei­nen Ände­run­gen an unse­rem Import­pro­zess brin­gen wir auch hier Licht ins Dun­kel. Und wie gen­au? Ein­fach wei­ter­le­sen und mit­ma­chen, es lohnt sich. wei­ter­le­sen…

Immer diese Stammdaten

In unse­rer schnell­le­bi­gen Welt ändern sich die Daten (Wer­te) so schnell, dass die gro­ße Her­aus­for­de­rung in der Aktua­li­tät die­ser Daten liegt. Nun ken­nen wir dies The­ma prak­ti­sch in jedem Pro­jekt und wie so oft gibt es diver­se Lösungs­we­ge, die mehr oder weni­ger auf­wän­dig und kom­plex zu imple­men­tie­ren sind. Eine Mög­lich­keit sich dem Pro­blem zu nähern ist der Ein­satz einer Trans­for­ma­ti­on im BI Deve­lop­ment Stu­dio (kurz: BIDS), dem Loo­kup-Task (Ach­tung: erst ab SQL-Ser­ver 2008 ein­setz­bar). Ver­ein­facht dar­ge­stellt bie­tet der Loo­kup-Task eine Art Ver­än­de­rungs­lo­gik, sprich: was ändert sich wann, wie und wo. Da die­ser Schritt, je nach Kon­fi­gu­ra­ti­on, unter­schied­lichs­te Kom­ple­xi­tä­ten anneh­men kann, begin­ne ich zunächst mit der ein­fachs­ten, trotz­dem schon sehr nütz­li­chen Vari­an­te. In einem zwei­ten Bei­trag wer­den wir dann die­ses Pro­jekt um wei­te­re Funk­tio­na­li­tä­ten erwei­tern. wei­ter­le­sen…

Historische Betrachtung von Stammdaten im Data Warehouse (DWH)

Der OLAP-Ansatz ist für die Ent­schei­dungs­un­ter­stüt­zung aus­ge­legt. Dabei sind his­to­ri­sche, aggre­gier­te und kon­so­li­dier­te Daten viel wich­ti­ger als die ein­zel­nen detail­lier­ten Daten­sät­ze. Meist sind die­se Daten über ver­schie­den lan­ge his­to­ri­sche Zeit­räu­me vor­han­den. Da also in einem Data-Wareh­ou­se (DWH) übli­cher­wei­se his­to­ri­sche Daten ver­wal­tet wer­den, sind bei­spiels­wei­se bei Ände­run­gen der Zuord­nung von Kun­den zu Kun­den­grup­pen in den Daten­quel­len in Form von peri­odi­schen Snap­shots” im DWH zu spei­chern. In ande­ren Bei­trä­gen konn­ten Sie schon erfah­ren, wie etwa die his­to­ri­sche Betrach­tung von Bestands­wer­ten, die als Bewe­gungs­da­ten gel­ten, imple­men­tiert wer­den kann. In die­sem Bei­trag stel­len wir Ihnen Metho­den zur His­to­ri­sie­rung von Stamm­da­ten vor. wei­ter­le­sen…