1 BTL
1.1 LAADMODUS
3 verschillende laadmodus
: Init, Full en Delta
·
INIT
1x draaien. BTL doeltabel is helemaal leeg. Met draaien
wordt elk allereerste (oudste) record per bkey geladen met een begindatum
‘1-1-1900’.
Dit wordt gedaan zodat niet de allereerste laaddatum als
begindatum gezet wordt want de beginstand geldt ook al eerder dan de eerste
laaddatum.
Waarom het allereerste (oudste) record?
Er zijn 2
situaties
1.
STG--> CM---> BTL (wordt in 1x gedraaid). Dan is er maar 1
oudste record en gaat alles goed
2. STG__>
CM wordt al een half jaar gedraaid en pas nu besluit met om er iets meet e gaan
doen. Dan moet voor het laden van de INIT alleen de allereerste waarde van de
bkey geladen worden. Hier is
dus het oudste record voor nodig
Init wordt dus maar 1x geladen. Daarna krijg je periodiek
draaien (dagelijks, maandelijks,etc)
Dit gebeurt met Delta of Full
PS: audit_sid speelt hier een belangrijk rol. Is een VARCHAR
die oploopt in de tijd.
·
DELTA
Alleen Delta van CM . Op basis van hoogste audit_sid in BTL
wordt gekeken wat er in CM veranderd is. Dat wordt dan geladen.
·
FULL
Hele CM met actief =1 hou je tegen BTL aan. Wanneer een
FULL. Als er meerder CM tabellen voor 1 BTL gebruikt worden dan moet je het met
FULL doen want dan werkt truukje met
audit_sid niet meer
1.2 Template BTL
Hoe moet je Delta en Full gedeelte zien
Er zijn 2 varianten beschrijven. Een delta en een full. Per
dimensie/feit kan je kiezen welke variant je gebruikt. Het kan dus zijn dat je een Delta voor
dimensie 1 hebt en een full voor dimensie 2 en een delta voor Feit1 en een full
voor Feit2
Geeft de mogelijkheid om te kiezen afh. Bijv hoe vaak draait
het , is het een grote tabel etc
FULL/Delta gedeelte
TDF_BTL_INIT_D_DUMMY1 is een voorbeeld van een
transactiefeiten tabel
TDF_BTL_FULL_F_DUMMY1 is een voorbeeld van een gestapelde
feittabel (archieven)
Accumulated wordt niet veel gebruikt.
1.2.1 INIT gedeelte
TDF_BTL_INIT_D_DUMMY1: maakt van attribuut 1 een dimensie
TDF_BTL_INIT_D_DUMMY2: maakt van attribuut 2 een dimensie
TDF_BTL_INIT_F_DUMMY1; is een voorbeeld van een gemaakte
keuze: hier nu periodieke snapshot feitentabel maar kan alles zijn
1.2.2 TDF_BTL_INIT_D_DUMMY1
Init betekent eenmalig, dus maar 1 keer en wel de
allereerste keer. Nadat de INIT dataflow heeft gedraaid wordt vervolgens
periodiek gedraaid met of een DELTA load of een FULL load.
Bij de init dataflow krijgt het eerste record per business
key een geldigheid van 1-1-1900. De
reden om per business key en niet per eerste load te doen, heeft te maken met
het het geval dat je feit eventueel eerder geladen kan zijn waardoor er geen
dimensie waarde gevonden kan worden in geval de BTL opnieuw zou worden
opgebouwd vanuit de CM.
Tevens worden er twee default waarden aan elke dimensie
tabel in de BTL toegevoegd, nl:
1) -1 =>
(Onbekend) bkey is leeg
2) -2 =>
(Ongeldig) bkey is niet bekend in
dimensie tabel
Qx_min : bepaal per BK de allereerste startdatum
Qx_JN :
indien je al historie hebt opgebouwd in de CM alsnog een
init draaien in de BTL waardoor ALLEEN het allereerste record per business key
van de CM een startdatum van 1-1-1900 meekrijgt in de BTL
1.2.3 TDF_BTL_INIT_F_DUMMY1
In template is dit
een voorbeeld van een gemaakte keuze: hier nu periodieke snapshot feitentabel
maar kan alles zijn . Ook transactie of cumulatief.
Bij dimensies wordt alles initieel in 1x verwerkt. Bij de
periodieke snapshot kan dit anders zijn.
Bijv. Stel je CM heeft data opgebouwd van heel 2018 en je
gaat nu initeel laden. En je wil per kwartaal een stand opbouwen. Dan moet deze
dataflow 4 x gedraaid worden, bijv door 4x
deze DATAFLOW achter elkaar te
zetten met steeds een andere peildatum. (31-3-2018, 31-6-2018, 31-9 en 31-12)
F_Dumm1
heeft targettabel met delete records, de volgende 3 hebben Append
1.3 UITWERKING TDF_BTL_FULL _D_DUMMY2
Dit is de
FULL BTL mapping met in dit voorbeeld 1 brontabel. Full houdt in dat alle
actieve rijen (MTA_ACTIEF_INDICATIE=1) uit de bron geselecteerd worden. Dit
houdt in dat de laatste actieve versie van de bkey wordt geselecteerd. Mochten
er ondertussen meerdere versies zijn geweest in de CM dan mis je de
tussenversies op deze wijze. Het is dus zaak om de BTL periodiek te laten lopen
en anders eventueel voor de delta variant te kiezen.
Er is de
keuze gemaakt om de BTL zijn eigen historie preserving uit te laten voeren, om
de volgende redenen:
1) er worden
meestal meerdere brontabellen gecombineerd tot 1 BTL tabel waardoor eigenhandig
nieuwe tijdsloten ontstaan
2) er wordt
vanuit gegaan dat de BTL altijd na of periodiek na de CM wordt geladen.
In dit
geval is wel voor gekozen om de MTA_GELDIG_VAN_DATUMTIJD over te nemen van de
CM tabel. Dit houdt in dat de BTL en de CM qua geldig_van synchroon blijven
lopen.
In de CM
laag worden verwijderingen bijgehouden door een nieuw record aan te maken.
Hierdoor hoeft de TC niet meer op verwijderde rijen te controleren
Stappenplan:
1)
replicate deze dataflow
2) neem je
nieuwe bron tabel op aan de linker kant
als bron
3) neem je
doeltabel 1 keer als doel
4) in
transform QY_SELECT_ATTR1 de volgende MTA velden meenemen: MTA_BKEY,MTA_GELDIG_VAN_DATUMTIJD,MTA_VERWIJDERD_IND
,MTA_BRON_CODE
5) in
transform QY_SELECT_ATTR1 order by op MTA_BKEY en MTA_GELDIG_VAN_DATUMTIJD.
(de laaste
sort kolum MTA_GELDIG_VAN_DATUMTIJD zal in dit geval weinig effect hebben omdat
er maar 1 bkey geselecteerd wordt. Bij Delta is dit wel heel belangrijk)
Where
clause ==> CM_DUMMY_1.MTA_ACTIEF_INDICATIE=1
dus alleen laatste wijziging. Geen tussenresultaten
6) in TC
niet checken op verwijderde records, input contains duplicate keys aanzetten,
als input primary kolom MTA_BKEY selecteren, filter MTA_AKTIEF_INDICATIE=1 en
als compare kolommen alleen de gewone attributen EN MTA_VERWIJDERD_IND
Input
contains duplicate keys staat aan: Betreft duplicate MTA_BKEY (dus niet MTA_SID )omdat per bkey
meerdere rijen kan krijgen
Sorted
input gaat over Bron tabel : bods gaat klagen als er
geen sortering. Door sorted input gaat Bods zelf de target data ophalen met de
zelfde sortering
Zie
Validation/Optimized sql : TCR :
betekent BODS ziet dat er gesorteerde input in een Table Compare komt, is
dezeldfde sortering als brontabel
In de CM
laag worden verwijderingen bijgehouden door een nieuw record aan te maken.
Hierdoor hoeft de TC niet meer op verwijderde rijen te controleren
Principe
mbt velden TC
De velden
die je links aanbiedt gaan overgenomen worden bij een UPDATE of INSERT, dus de
andere velden zijn niet gevuld, dus
Deze velden
worden later in het proces gevuld
Mta_sid --> bij KG
MTA_GELDIG_TOT_DATUMTIJD --> HP
MTA_AANMAAK_DATUMTIJD, MTA_GEWIJZIGD_DATUMTIJD-->
bij MAP
MTA_ACTIEF_INDICATIE --> bij HP
MTA_AUDIT_SID --> bij MAP
7) in HP in
compare columns alleen je eigen attributen zetten EN MTA_VERWIJDERD_INDICATIE
8) in MAP
transform niks veranderen
VELD
|
INSERT/NORMAL
|
UPDATE
|
MTA_AANMAAK_DATUMTIJD
|
$G_LAAD_DATUM
|
|
MTA_GEWIJZIGD_DATUMTIJD
|
$G_LAAD_DATUM
|
$G_LAAD_DATUM
|
MTA_AUDIT_SID
|
$G_JOB_RUNID
|
$G_JOB_RUNID
|
MTA_AANMAAK_DATUMTIJD
9) Key
generation transform de kolom MTA_SID van de doeltabel selecteren
10) op
doeltabel niveau bij options 'include in transactions' op Yes zetten,
transaction order = 0 en 'Commit at the end of insert .. select' op Yes
1.1 UITWERKING TDF_BTL_DELTA _D_DUMMY2
Dit is de
delta BTL mapping met in dit voorbeeld 1 brontabel.
Delta houdt
in dat alleen de gewijzigde rijen obv mta_audit_sid in de bron worden ter
vergelijking aangeboden aan de TC.
Er is de
keuze gemaakt om de BTL zijn eigen historie preserving uit te laten voeren, om
de volgende redenen:
1) er
worden meestal meerdere brontabellen gecombineerd tot 1 BTL tabel waardoor
eigenhandig nieuwe tijdsloten ontstaan
2) er wordt
vanuit gegaan dat de BTL altijd na of periodiek na de CM wordt geladen.
In dit
geval is wel voor gekozen om de MTA_GELDIG_VAN_DATUMTIJD over te nemen van de
CM tabel. Dit houdt in dat de BTL en de CM qua geldig_van synchroon blijven
lopen. Denk er wel aan om in de QY_SELECT_ATTR1 te sorteren op MTA_BKEY EN
MTA_GELDIG_VAN_DATUMTIJD waardoor indien per bkey meerdere records worden
aangeboden, deze records in volgorde van geldigheid worden verwerkt.
!Deze sortering is essentieel voor de goede
werking. Er wordt dus per bkey gesorteerd op MTA_GELDIG_VAN_DATUMTIJD en deze
worden dan ook in deze volgorde verwerkt. Hierdoor worden dus alle wijzigingen
in een Bkey die zijn geweest in de CM en nog niet verwert waren in BTL , netjes
in de juiste volgorde verwerkt
TC
Input
contains duplicate keys staat aan: Betreft de Bkey (dus niet MTA_SID )omdat per
bkey meerdere rijen kan krijgen
Sorted
input gaat over Bron tabel : bods gaat klagen als
er geen sortering. Door sorted
input gaat Bods zelf de target data
ophalen met de zelfde sortering
Zie Validation/Optimized
sql : TCR : betekent BODS ziet dat
er gesorteerde input in een Table Compare komt, is dezeldfde sortering als
brontabel
In de CM
laag worden verwijderingen bijgehouden door een nieuw record aan te maken.
Hierdoor hoeft de TC niet meer op verwijderde rijen te controleren
Stappenplan:
1)
replicate deze dataflow
2) neem je
nieuwe bron tabel op aan de linker kant
als bron
3) neem je
doeltabel 1 keer op als doel
4) in
transform QY_SELECT_ATTR1 de volgende MTA velden meenemen:
MTA_BKEY,MTA_GELDIG_VAN_DATUMTIJD,MTA_VERWIJDERD_IND ,MTA_BRON_CODE
5) in
transform QY_SELECT_ATTR1 order by op MTA_BKEY en MTA_GELDIG_VAN_DATUMTIJD
6) in TC
niet checken op verwijderde records, input contains duplicate keys aanzetten,
als input primary kolom MTA_BKEY selecteren, filter MTA_AKTIEF_INDICATIE=1 en
als compare kolommen alleen de gewone attributen EN MTA_VERWIJDERD_IND
7) in HP in
compare columns alleen je eigen attributen zetten EN MTA_VERWIJDERD_IND
8) in MAP
transform niks veranderen
9) Key
generation transform de kolom MTA_SID van de doeltabel selecteren
10) op
doeltabel niveau bij options 'include in transactions' op Yes zetten,
transaction order = 0 en 'Commit at the end of insert .. select' op Yes
