DSA opdatering

af Joakim Dalby

Indledning

I en ledelsesinformationssystem løsning (LIS) vil Enterprise Data Warehouse (EDW) normalt opsamle, bevare og håndtere aktuelle og historiske data fra kildesystemerne ved indlæsning af data fra Data Staging Area (DSA). DSA har til formål at varetage udvalgte data fra de forskellige kildesytemer inden data indlæses til EDW.

Skema oplysninger for en levering

For hver levering til LIS fra et kildesystem, anbefales det at udarbejde et dokument som beskriver en række forhold om kildesystemet, leveringen og data indholdet samt hvad der skal »gøres« ved data, så de er klar til senere indlæsning til EDW. Når en levering består af flere filer, skal der udarbejdes et dokument for hver fil.

Kildesystem
Navn	et sigende kildesystem navn og typisk en forkortelse.
Sted	firma navn, afdeling, kontor, adresse, telefon, email.
Data indhold ansvarlig	kontaktperson med telefon og email.
Data levering og drift	kontaktperson med telefon og email.

Levering
Navn	filnavn eller tabelnavn i en database. Nogen gange indeholder et filnavn et ugenummer, månedsnummer eller et årstal, hvorved filnavnet ikke er et fast navn, hvilket ETL indlæsningsprocessen skal tage højde.
Sted	ftp, shared mappe, modtaget på email, LIS indlæser gennem en forbindelse f.eks. med Oracle eller DB2 database connection via linked servers i SQL Server (data capture as push or pull).
Format	database backup, csv (Comma Separated Values) eller txt (kolonnenavn og komma/semikolon separator), xml (eXtensible Markup Language) inkl. xsd (xml Schema Definition), Access, Excel, SAS, DB2 m.fl.
Frekvens og tidspunkt	daglig, ugentlig, månedlig m.fl. Aftalt seneste klokkeslæt hvor leveringen er klar og dag i ugen/måneden.
Gyldighedsperiode	hvilken periode eller hvilken til-dato er leveringens data gældende for. Eksempelvis at leveringen om søndagen er til og med fredagen i ugen.
Forventet filstørrelse	forventes f.eks. en database backup fil på 2GB eller mere, kan ETL validere filen ved at forkaste den, når størrelsen er under 2GB, f.eks. 2MB for tom database.
Kontrol	ETL validerer filen for en forventet dato, og når LIS indlæser filen, så slettes filen bagefter, så kildesystemet ved, at filen er indlæst, så der kan leveres en ny fil. En ekstra fil eller tabel med dato og klokkeslæt for generering af data indholdet kan være nyttig for kritiske data i LIS, fordi statistikker ofte er afhængig af, hvornår data er blevet genereret og leveret. I forbindelse med fejl i kildesystemet vil DSA ud fra en data generingsdato kunne vurdere, om data skal indlæses eller ej og derved give fejlmeddelelse til LIS driften. Kildesystemet kan også sende en email til LIS driften, så de ved, at data er blevet genereret og leveret.
Arkiv	gemmer leveret fil i en arkiv mappe, hvor filnavnet får prefix med den dato (ååååmmdd) den gemmes i arkivet, så genkørsel af ETL proces kan muliggøres bag ud i tid.
Data struktur	kolonnenavn og datatype, primærnøgle, sekundærnøgle, fremmednøgle d.v.s relationer mellem data i tabeller, datasets, filer, opstillet i et ER-diagram.
Data indhold	full dump af alle data fra kildesystem eller incremental update af nye data, ændret data og slettet data (statusfelt med N for new data, C for changed data og D for deleted data). Hvad gør full dump ved ændret tekst, og bliver data slettet i kildesystem, så de ikke mere leveres i full dump? En beskrivelse af data indholdet er vigtig for EDW indlæsningen. Se senere.

DSA
Databasenavn	database der repræsenterer DSA i LIS løsningen. Ved flere kildesystemer anbefales en DSA database for hvert kildesystem, så der opnås uafhængig mellem dem og den databehandling der evt. skal foregå på kildedata. De LIS relevante data kan derefter over-føres til en samlet DSA database, som rummer alle de data der skal indlæses i EDW databasen for LIS.
Tabelnavn	en fil importeres til en tabel med samme struktur som filen især kolonnenavn og nærmeste datatype.
Frekvens og ETL proces	indlæsningen er enten daglig, ugentlig, månedlig m.fl. og er en del af en ETL proces.
Log	tabel der har en række for hver gang data er blevet indlæst med en dato og klokkeslæt samt en række andre nyttige oplysninger så som antal rækker i filen.
Data validering	kontrol af data bl.a. antal rækker i tabellen i forhold til sidste levering, tom kolonne, korrekt data i nummer, kode, dato, beløb, antal tegn i tekst oplysning m.fl.
Data behandling	nogen gange vælges det at sætte kolonne datatype til nvarchar(255) der bagefter konverteres til rette datatype (int, float, date, nchar) for derved at kontrollere leveringen og give passende data fejlmeddelelse i en logfil for ETL processen til LIS driften.
Data bearbejdning	fastsættelse af primærnøgle, sekundærnøgle, fremmednøgle, summering af beløb, gør nummer ensartet f.eks. cprnr som ti cifret ddmmååkkkk.
Data berigelse	tilføjelse af ny kolonne som beregning af anden kolonne f.eks. fødselsdato og alder ud fra cprnr. Sammenkøring af flere tabeller for at opstille data, så de er nemmere at indlæse til EDW.
Ny tabelnavn	data placeres i en eller flere NEW tabeller i DSA, der er klar til indlæsning til EDW. Vigtigt at en tabel har en primærnøgle for at opnå hurtig performance i ETL. Når et filnavn ikke er fast f.eks. indeholder et årstal, skal flere tabeller indlæses til samme nye tabel, som derved rummer indholdet fra alle relevante årstalsfiler. Måske skal programmeringen tilrettes hvert år, hvilket skal være beskrevet i LIS drifthåndbogen.

Leveringens data indhold

Data indholdet i en levering er det vigtigste af alle forholdene, fordi LIS skal vide, hvordan de modtagne data i DSA skal håndteres i EDW.

Ved full dump forstås, at kildesystemet leverer alle data d.v.s. et øjebliksbillede af kildedata. Det betyder, at når kildesystemet ændrer en tekst, så leveres den nyeste tekst til DSA, hvis kildesystemet ikke selv har en historik håndtering og derved kan levere alle anvendte tekster med en periode angivelse. Hvad skal LIS gøre ved ændrede tekster, d.v.s. skal ændringen foretages i EDW eller skal tidligere tekst bevares i EDW?

Kan data blive slettet i kildesystemet, så slettet data ikke mere er indeholdt i full dump? I så fald skal det bestemmes, om LIS skal bevare tidligere leveret data. Kildesystemet kunne have en regel om kun at indeholde data for en rullende fem årsperiode, mens LIS skal bevare alle data for at kunne udarbejde statistikker over en meget længere periode.

Et godt tip er at have et Identity felt i den tabel der modtager leverancens data, for med Id feltets fortløbende nummer sikres rækkefølgen af de modtagne data, når de senere skal sendes fra DSA til EDW, da det kan ske via en ORDER BY Id.