Inkrementelles Laden mit relationaler Partitionierung

Ab einer bestimm­ten Größe wird es sehr unhand­lich, eine Fak­ten­ta­belle 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­derte Daten­sätze gela­den wer­den. Das nen­nen wir Inkre­men­tel­les Laden“. Solch ein Laden stellt neue Anfor­de­run­gen an den ver­wen­de­ten SQL-Code und die Per­for­mance-Opti­mie­run­gen. War es z. B. beim Kom­plett­la­den mög­lich, die Fak­ten­ta­belle mit dem sehr schnel­len TRUN­CATE-Befehl zu löschen, ist das jetzt nicht mehr mög­lich, da nur noch die Daten gelöscht wer­den dür­fen, die sich geän­dert haben. Ein ent­spre­chen­der DELETE-Befehl kann aber viele 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önnte 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­jahre blei­ben aber unbe­rührt.

Das bei uns am häu­figs­ten ein­ge­setzte Ver­fah­ren für inkre­men­tel­les Laden, möchte ich hier Meh-rere-Fak­ten­ta­bel­len-Ver­fah­ren“ nen­nen. Dabei wird, um auf das gerade ange­spro­chene Bei­spiel zurück­zu­kom­men, für jedes Geschäfts­jahr eine Fak­ten­ta­belle ange­legt und in der mul­ti­di­men­sio­na­len Daten­bank kann dann für jede ein­zelne rela­tio­nale Fak­ten­ta­belle eine Par­ti­tion 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“ solch ein Modell schnell auf­baut. Für einen Nach­teil die­ses Ver­fah­rens halte ich, dass sobald z. B. ein neues Geschäfts­jahr hin­zu­kommt, eine neue Fak­ten­ta­belle und der ganze zuge­hö­rige Rat­ten­schwanz“ neu ange­legt wer­den muss. Das Modell muss also peri­odi­sch erwei­tert wer­den.

Ich möchte 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­lich mehr Kom­ple­xi­tät, wie noch ersicht­lich sein wird.

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

Schreibe einen Kommentar