Inkrementelles Laden mit relationaler Partitionierung

Ab einer bestimm­ten Grö­ße wird es sehr unhand­li­ch, eine Fak­ten­ta­bel­le bei jeder Aktua­li­sie­rung kom­plett zu laden. In die­sem Fall muss der Aktua­li­sie­rungs­pro­zess so ver­än­dert wer­den, dass mög­lichst nur neue oder geän­der­te Daten­sät­ze gela­den wer­den. Das nen­nen wir Inkre­men­tel­les Laden“. Sol­ch ein Laden stellt neue Anfor­de­run­gen an den ver­wen­de­ten SQL-Code und die Per­for­man­ce-Opti­mie­run­gen. War es z. B. beim Kom­plett­la­den mög­li­ch, die Fak­ten­ta­bel­le mit dem sehr schnel­len TRUN­CA­TE-Befehl zu löschen, ist das jetzt nicht mehr mög­li­ch, da nur noch die Daten gelöscht wer­den dür­fen, die sich geän­dert haben. Ein ent­spre­chen­der DELE­TE-Befehl kann aber vie­le Res­sour­cen und viel Zeit kos­ten.

Ein wei­te­res Pro­blem ist, dass die Zei­len, die sich geän­dert haben und die­je­ni­gen, die hin­zu­kom­men, nicht immer ein­wand­frei iden­ti­fi­zier­bar sind. Des­halb wird es in der Pra­xis meis­tens auf einen Kom­pro­miss hin­aus­lau­fen. Ein Kom­pro­miss könn­te z. B. so aus­se­hen: Für FIBU-Daten ist nicht erkenn­bar, wel­che Daten­zei­len geän­dert und wel­che hin­zu­ge­fügt wer­den müs­sen. Was aber bekannt ist: Es kön­nen sich nur Daten­zei­len im aktu­el­len Geschäfts­jahr ändern. Also wer­den die Daten­zei­len des aktu­el­len Geschäfts­jah­res kom­plett gelöscht (auch die, die sich gar nicht geän­dert haben) und das Geschäfts­jahr wird kom­plett neu gela­den, die alten Geschäfts­jah­re blei­ben aber unbe­rührt.

Das bei uns am häu­figs­ten ein­ge­setz­te Ver­fah­ren für inkre­men­tel­les Laden, möch­te ich hier Meh-rere-Fak­ten­ta­bel­len-Ver­fah­ren“ nen­nen. Dabei wird, um auf das gera­de ange­spro­che­ne Bei­spiel zurück­zu­kom­men, für jedes Geschäfts­jahr eine Fak­ten­ta­bel­le ange­legt und in der mul­ti­di­men­sio­na­len Daten­bank kann dann für jede ein­zel­ne rela­tio­na­le Fak­ten­ta­bel­le eine Par­ti­ti­on ange­legt wer­den. Das Ver­fah­ren wird auch wun­der­bar durch Delta­Master Mode­ler unter­stützt, der durch die Ein­stel­lung Par­ti­ti­onPer­Source­Table“ sol­ch ein Modell schnell auf­baut. Für einen Nach­teil die­ses Ver­fah­rens hal­te ich, dass sobald z. B. ein neu­es Geschäfts­jahr hin­zu­kommt, eine neue Fak­ten­ta­bel­le und der gan­ze zuge­hö­ri­ge Rat­ten­schwanz“ neu ange­legt wer­den muss. Das Modell muss also peri­odi­sch erwei­tert wer­den.

Ich möch­te in die­sem Bei­trag noch ein ande­res Ver­fah­ren vor­stel­len, dass einer­seits etwas fle­xi­bler an die Anfor­de­run­gen des jewei­li­gen Modells ange­passt wer­den kann, ande­rer­seits aber auch das peri­odi­sche Erwei­tern des Modells über­flüs­sig macht. All das erfor­dert jedoch deut­li­ch mehr Kom­ple­xi­tät, wie noch ersicht­li­ch sein wird.

Den gesam­ten Arti­kel kön­nen Sie hier abru­fen.

Schreibe einen Kommentar