BI - LIS arkitektur

af Joakim Dalby

 

»Viden er magt«, sagde man en gang. I dag er mantra: »Deling af viden er magt.«

»Drukner i data, savner information i tilvejebringelsen af et beslutningsgrundlag.«

»Stikke en strikkepind gennem alle organisationens data til nye rapport typer.«,

René Spogárd, tidligere adm. dir. og indehaver af Gallup A/S, 1998.

»Informationshåndteringen er det, der afgør om dagens virksomhed er en taber el­ler en vinder.«, Bill Gates, 1998. Læs mere om Informatikfunktionen.

Udgangen af år 2010 havde 988 exabyte digitale data, 988 efterfulgt af 18 nuller.

 

1. Indledning

Hensigten med artiklen er at få en række BI Business Intelligence og LIS Le­del­ses Informations System (ledelses­in­for­ma­ti­ons­sy­stem) begreber kon­kre­ti­seret, indføre en ar­ki­tek­tur og database tabel navn­givning samt kort intro­duk­tion til en metode for implementation af en BI-LIS løsning. LIS har gennem tiden haft mange navne: EIS Executive Information System facilitate and support the information and decision making, MIS Management Information System, DSS Decision Support System eller Beslutnings­støtte­system.

 

En BI Business Intelligence løsning har fokus på brugen af data til at støtte or­ga­ni­sa­tio­nens og ledelsens indsigt, be­slut­nin­ger, opfølgning og indgri­ben gen­nem om­dan­nel­se af data fra forskellige edb-sy­ste­mer i or­ga­ni­sa­tio­nen til på­li­de­lig sty­rings­rele­vant nøgletals in­for­mation.

Data bliver opbevaret i et Data Varehus, Data Warehouse, der er en database, data repository, med fokus på at integrere og sammenstille data fra de forskellige it-sy­ste­mer samt at udregne nye data der dækker forretningens data be­hov og foretage data kvalitet fra de forskellige systemer.

 

Ved op­start af et BI-LIS projekt bør man stille sig spørgs­målene: Hvordan kan BI bi­dra­ge som styrings­redskab til hurtigere, præcise og bedre be­slut­nin­ger i ønsket om at drive, planlægge og styre per­formance? Hvordan kan BI bi­dra­ge til over­våg­­ning af afvigelser fra den ønskede udvikling an­givet gennem budgettering, mål­tal og måle­punk­ter, så der kan foretages opfølg­ning på resultater og op­ti­me­ring her­af? Hvilke forandringer skal der foretages i virksomhedens processer, når nøg­letal­lene bliver præsen­teret og de ikke opfylder de stillede mål eller har store udsving over en periode?

 

Data Warehousing er et samlet udtryk for en data arkitektur og en metode for design, udformning og implementation af et data warehouse.

 

Det anbefales at udarbejde en række kravspecifikationer omhandlende: Infor­mation om data oprin­del­se, datakilder og deres data­ kva­li­tet, for­ret­nings­reg­ler for data udsøgning og data berigelse også kaldet data udvælgelse, data be­hand­ling, data be­ar­bejd­ning, data forædling eller i et samlet udtryk data in­te­gra­tion for at forene forskellig­artede data til en helhed. Det kaldes for Enterprise Information Mana­gement EIM.

Se de tre BI-LIS trekanter.

 

2. Business Intelligence

»Extract your business critical information to increase your profit.«

 

Business intelligence blev første gang defineret i 1958 af H. P. Luhn: A Business Intel­ligence System, IBM Journal October 1958 pdf. Her i artiklen til­lægges BI en alt­fav­nen­de fællesnævner for en bred vifte af komponenter, teknologier og appli­ka­tioner samt metoder til data indsamling og sammenstilling på tværs af IT sy­ste­mer, lagring og hånd­tering af store mængder af data omformet til information for rapportering og tværgående analysering samt give adgang, gøre tilgængelig og praktisk håndterbar som be­slut­ningsgrundlag for be­slut­­nings­tagere og analy­ti­ke­re på alle ni­vea­uer af en orga­ni­sa­tion, der typisk opdeles i strategiske, taktiske og ope­­ratio­nelle brugere. BI-applikationen viser dashboard med speedometer, graf-, søj­le og lagkagediagram samt lyskryds med Grønt: Her går det godt, Gult: Vær opmærksom, Rødt: Pas på, for her går det skidt, for at give et hurtigt overblik. Med intuitivt peg-og-klik kommer man frem til de ønskede informationer og borer sig ned i data gennem standard statistik rappor­ter eller her-og-nu ad hoc rapportering til den efterfølgen­de analyse og dannet be­slut­nings­grundlag, se eksempel. Endvidere kan BI-applikationen grave sig ned i data på egen hånd på jagt efter mønstre, som ingen analytiker kan forestiller sig, det kaldes Datamining og er en slags minedrift i data efter guld. Det kaldes Balanced Scorecard når virk­som­he­den måler sig på en lang række faktorer, hvor der på forhånd er sat mål op for hver faktor.

 

Formålet med BI er at for­vandle for­ret­nin­gens mange data til konkret og brugbar information for at kunne give forretnings­mæssige ef­ter­ret­ninger, så der opnås en bred forretningsmæssig indsigt i forbindelse med pro­cesser og beslutninger, der fører til bedre sammenhæng, over­blik, gennem­sig­tig­hed og sty­ring af forretningen. Og hvor analysering af information og nøgletal giver viden om forretningen integreret med »hvad«, »hvor«, »hvor­når«, »hvor mange« og »hvorfor«. Eksempelvis ved salgs­op­følg­ning: vare, markedsandele, kundetilfredshed, mærkeloyalitet, salgs­­tids­­punkt, salgstal, sæson­ud­sving og sammenhænge i kun­der­nes købs­møn­stre, mar­keds­­førings­kam­pagne eller placering af varer i butikken, antal solgte og returneret varer pr. sted og uge mixet med produktivitet og innovation.

Et andet for­mål med BI er at skabe kon­sen­sus om data via ensartethed i data og enslydende datadefinitioner d.v.s. have et fælles verdensbillede eller en sandhed om stam­data. Eksempelvis kun­de­data der an­ven­­des i mar­ke­tings­afdelingen i forbindelse med kampagner, i salgsafde­lin­gen ifm. med salg og rabat, i øko­nomi­afdelingen ifm. debi­tor­oplysninger samt i serviceafdelingen ifm. med hjælp til kunder om produkter og reparation m.v.

 

BI leverer den rigtige in­for­ma­ti­on i den rigtige form til den rette bruger på det ret­te tids­punkt, hvilket er nøglen til de rigtige beslutninger (»Information at your fin­ger­tips.«).

BI giver feedback til de operative kildesystemer, så det at de stiller data til rå­dig­hed be­tyder, at de selv står stærkt og sågar bliver stær­­ke­re af feedback ved at højne data­ regi­stre­rings­kva­lite­ten og datadisciplinen. BI bliver en del af forret­nin­gens infra­struk­tur.

»Pervasive BI« eller BI i alt, handler om at indsamle data overalt i forretningen.

»BI for the masses« eller BI til alle, handler om at BI når ud til alle i forretningen, hvorved der opnås en demokratisering af viden som giver en bedre data kvalitet og tro­værdige data bl.a. til SOX (Sarbanes Oxley) og Basel II rapporteringer. Endvidere kan chefer og medarbejdere blive selvhjulpne til at overvåge og øge performance.

»Business Performance Management BPM« handler om processer for bl.a. årsag-virkning-forbindelser mellem forretningens områder, markedsføring, for­brugs­møn­ster ved prisnedsættelse, kreditvurdering af kunder, varsling af kun­der på vej væk, risiko for bedrageri, afvigelser fra budget og veldefinerede mål (Key Per­for­man­ce Indicators KPI via Balanced Scorecard).

»Ubiquitous computing BI« handler om at gøre BI allestedsnærværende og glide i bag­grun­den for den enkelte bruger og på naturlig vis understøtte dennes ak­ti­vi­te­ter. Læs mere om Computerstøttet forvarsel.

 

OnLine Analytical Processing (OLAP for multidimensional data analysis) er en fler­di­men­sio­nel kube, som præ­sen­te­rer data via dimen­sio­ner, der er forretningens ind­gang til analysevariable (measures), hvor dimensioner giver vinkler til at belyse ana­lyseva­riable som omsætning, forbrug, antal kunder, sygefravær og rettidighed. En kube kan ses som en Rubiks terning (Rubik’s cube billede), hvor man kan ven­de og dreje de enkelte dele efter behov gennem for­skel­lige funk­tio­na­li­te­ter på di­men­sio­ner, som in­de­hol­der en hierarkisk niveau opdeling af data. En øko­nomi ku­be har typisk di­men­sio­ner­­ne: Art, Bud­get­version, Sted og Tid. Nøgletal er en kom­bi­na­tion af en eller flere dimensioners værdier og en ana­lyse­varia­bel. Funk­tio­na­li­te­ter på dimensioner gen­nem et analyse og rap­por­te­rings­værk­tøj så­som Excel Pivot regne­ark, Office Web Component OWC, Targit, Temtec, Tableau og Business Objects, er:

·   slice-and-dice hvor dimensionsdata skæres til med filter/zoom/kriterier og di­men­sio­ner placeres i forspalten og danner rækker, og som kolonner og danner en kryds­ta­bu­le­ring eller pivot opstilling. Data er »hakket-og-skåret« til analysen.

·   drill-down til præsentation af dimensionsdata i gradvis større detaljeringsgrad.

·   drill-up ser dimensionsdata på højere aggregeringsniveau og summeret (roll-up).

·   drill-through viser de bagvedliggende data fra kildesystemet.

·   drill-across sammenstiller analysevariable fra flere kuber via fælles di­men­sio­ner.

·   ranking or sorting præsenterer dimensionsdata efter en analysevariabel f.eks. kundesegmenter i faldende orden efter salget.

·   top or bottom til præsentation af f.eks. top 5 produkter eller 10 dårligste kunder salgs­mæs­sigt.

·   indtaste cellekommentar på kombinationer af dimensionsdata og analyse­vari­able som for­kla­ring til et nøgletal f.eks. et beløb eller en procent og at kommentarer­ne straks kan ses og læses af andre.

·   indtaste værdi i analysevariabel f.eks. måltal eller budget beløb på kombinatio­ner af dimensionsdata så værdien straks kan ses af andre og indgå i deres ana­lyser.

Se eksempel med OWC inklusiv en række programmeret funktioner.

Data Mining er en proces, hvor computeren finder og klarlægger hidtil ukendte møn­stre og valide sammenhænge for at give et bud på frem­ti­den via hvad-nu-hvis-analyser ud fra fortidens datagrundlag til nærmere vurdering af, hvor forret­nin­gen skal hen og at kunne se fremad. Data bliver til information.

 

3. Lagdelt arkitektur

En beskrivelse af de fire lag i BI-LIS løsningen der kaldes: Kildesystem / Source system, Data Sta­ging Area (DSA), Enterprise Data Warehouse (EDW) og Data Mart Area (DMA), hvor sidst nævnte her i artiklen in­de­hol­der data rettet mod OLAP kuber, som brugere analy­se­rer og rap­por­terer på via et OLAP værktøj så som Excel eller Targit.

Data anskaffelse, da­ta di­stri­bu­tion, data udsøgning, data behandling, data be­ar­bejd­ning og data berigelse er vigtige elemen­ter i al BI for at danne forædlede data, og er den proces der tager over 90% af udviklings­ti­den inkl. kravspecifikation med for­ret­nings­regler, mens OLAP kuber tager under 10%.

 

3.1 Kildesystem / Source system

Et kildesystem løser en bestemt opgave i en afgrænset del af organisatio­nen f.eks. et kontor, en funktion, en afdeling, en division eller en forret­nings­en­hed. Andre betegnelser: OLTP On-Line Transaction Processing, ERP Entreprise Resource Planning for økonomi, salg, produktion, lager, indkøbsstyring d.v.s. indre ressourcer, CRM Customer Re­la­tion­ship Management for kundestyring d.v.s. ydre ressourcer, HRM Human Res­sour­ce Ma­na­ge­ment for personalestyring, SCM Supply Chain Management for logistik samt operationelle system, kil­de­sy­stem, datakilde (data source area). En organisation har ofte en række kildesystemer, der fun­ge­rer som selv­stændige systemer uden nogen integration mellem dem. Normalt inde­hol­der et kildesystem operationelle data og ikke historiske data, d.v.s. data­ba­sens indhold er et øje­bliks­billede af vir­ke­lig­he­den, f.eks. kundens nuværende adresse mens tid­ligere adresser ikke bliver glemt. Der udarbejdes en Data Profiling (data profilering) som giver overblik over kildedata, dens struktur og opbygning og for at afdække evt. problemer og data kvaliteten.

 

3.2 Data Staging Area

Data Staging Area (DSA) (dataforberedelses- eller datarangeringsområde) har til for­mål at varetage og tilrettelægge udvalgte data fra kildesy­ste­mer­ inden data indlæses i selve LIS. DSA er en database der normalt er implementeret i samme miljø som BI-LIS, og da­ta­basen indeholder en ræk­ke tabeller, der repræ­senterer data leverancer fra et kildesy­ste­m. En le­ve­rance kan være en data­ba­se fil, csv fil, txt fil, xml fil, Excel fil m.fl. Det er vigtigt at kende datamodellerne i kildesy­stemer og fo­re­ta­ge kvalitetsvurdering af dem. En tabel i DSA har samme kolon­ner som leveran­cen og tilnærmelsesvis samme da­ta­­typer samt primærnøgle og fremmed­nøgle, så der opnås en præcis afspejl­ning af leve­ran­ce­n fra kildesy­ste­m til DSA (en en-til-en mapning). Jeg anbefaler, at man opbygger en DSA database for hvert kildesystem, så er de forskellige kildedata adskilt i data modtagelsen, og senere i en fælles EDW database bliver de forskellige data i DSA databaserne samkørt og sammenstillet i en fælles datamodel.

 

Den samlede proces i DSA kaldes ETL (Extracting, Transfor­mation, Loading):

·         Extracting omfatter udvinding af data fra kildesystemer og data overfør­sel fra kildesystemer til DSA enten ved at DSA henter data direkte i kilde-system, eller ved modtagelse af en datafil fra kildesystem placeret på et fælles om­råde f.eks. en ftp server, som DSA indlæser. Et kildesy­stem kan også være den der står for overførslen af data til DSA. Udtræks­spe­cifi­ka­­tion, opda­terings­fre­kvens, tidspunkt, data mængde og kanal for leve­ran­cen re­gi­stre­­res som metadata. Der sondres typisk mellem Full dump eller Incre­men­tal update eller Delta data detection leverancer. Full dump om­fat­ter alle data fra kildesystemet (et øjebliksbillede), mens IU/DD kun indeholder op­dateret data siden sidste leverance d.v.s. nye data, ændrede data og slettede data i kildesystemet til DSA databasen.

·         Transformation omfatter data vask og data rensning og mindre berigelse af de indlæste data i DSA gennem en proces for at gøre data mere anvendelig og klar til den videre overførsel til Enterprise Data Warehouse:

o   Data Filtering står for fjernelse af rækker der indebærer dubletter (de-du­pli­ca­tion), hvorved der kan sikres en primærnøgle hvis den ikke al­le­rede er fulgt med fra kildesystemet. Kaldes business key, applica­tion key eller na­tu­ral key.

o   Data Cleansing and Scrubbing står for undersøgelse af data for at fin­de fejl og inkonsistenthed (referential integrity) og manglende data f.eks. blanke kolonner der senere skal indgå i en primærnøgle (where felt is not null), og rette op på fejlene (inconsistent, inaccurate, incomplete or missing value, invalid data and improperly formatted data, in good data quality) d.v.s. kvali­tets­­kontrol og –sikring, konsistenscheck samt hånd­te­rings­pro­ce­du­re i tilfælde af fejl i data gennem en log. De korrekte rensede data kopieres til en række DSA_NEW tabeller og frasorteret fejl data kopieres til en række DSA_ERROR tabeller.

o   Data Default Value står for at tildele en standardværdi til blanke ko­lon­ner/felter f.eks. en dato der kan have en tom værdi i kildesystemet isnull(f1,'19000101')  der senere skal indgå i en opdatering a la denne where f1 <> f2 - virker ikke når et felt har en tom værdi. Eller et be­løb felt der kan indeholde null sættes til 0 eller et tomt tekstfelt sæt­tes til '-' eller 'Ukendt'. Derved opnås at kolonner/felter kan gøres til not null felter d.v.s. altid-har-værdi felter i DSA_NEW tabellen.

o   Data Renaming står for oversæt­telse til sigende kolonnenavne i DSA_NEW tabeller, fordi kildesystemer ofte anvender forkortelser, koder og bruger gamle kolonner til nye formål. Sigende kolonnenavne er vigtige for de forretningsregler der senere skal udarbejdes på data.

o   Data Derivation and Enhancement står for håndtering af afledte data der gemmes i nye kolon­ner f.eks. et Cprnr der leveres fra kildesy­stem som heltal konverteres til en 10-cifret tekststreng der vil star­­te med 0 for de personer som er født i de første 9 dage i måneden og mindre berigelse af ekstra kolonner som Fødselsdato, Alder og Køn udregnet på basis af Cprnr og datoen for indlæsningen. Er dagsdato den 30. januar 2008 og personen er født den 1. februar 1966, så er personens alder 41 år. Der kan også være en dato blandt data som alder beregnes ud fra, så man har alderen på det tidspunkt re­gi­stre­rin­gen blev foretaget.

o   Data Identity står for dannelse af et entydigt nummer pr. data fore­komst eller instans, f.eks. medarbejdere fra tre kildesystemer med forskellige business keys (Cprnr, Lønnummer, BrugerIdent) forenes medarbejderne, så de får et nyt Id-nummer der sendes videre til både test- og produk­tions­miljøets EDW, der derved anvender samme Id.

·         Loading omfatter tilrettelæggelse af data, klar til overførsel til enten et Enterprise Data Warehouse eller nogen gange et Operational Data Store (ODS) der håndterer de historiske data over en længere perio­de, hvorfra data viderebehandles og til sidst overføres til Enterprise Data Warehouse.

Databasenavngivning er <løsningsnavn>_DSA_<kildesystemnavn> da det an­be­fales at have en DSA database for hvert af kildesystemerne til BI-LIS.

Tabelnavngivningen i DSA databasen kan indeholde fem prefix:

·         DSA_SOURCE_<tabelnavn> med et tabelnavn uden mellemrum svarende til kildesystemets leverance navngivning. Tømning ved ETL start.

·         DSA_TMP_<tabelnavn> med et tabelnavn uden mellemrum for de tempo­rærer tabeller der anvendes i transformationen. Tømning ved ETL start.

·         DSA_RULE_<regelnavn> med et regelnavn uden mellemrum indeholdende for­skellige opsætnings- og regeldata til brug for transformationen.

·         DSA_NEW_<tabelnavn> med et tabelnavn uden mellemrum svarende til kildesystemets leverance navngivning. Tømning ved ETL start. Tabellen skal have en primærnøgle (et, to eller flere felter som sammensat primær­nøgle), fordi der ofte skal foretages et link eller join til en tabel i det næste database lag kaldet EDW, samt at primærnøglen sikrer, at der er renset ud for dubletter og ikke va­li­de data hvor felt i primærnøglen er blank.

·         DSA_ERROR_<tabelnavn> med et tabelnavn uden mellemrum svarende til kildesystemets leverance navn­givning med de fejl data der blev identificeret under trans­formationen, klar til fejlmelding til driften eller brugere. Rullende må­neds­vis tømning ved ETL start.

Der bør foreligge en fuld dokumentation af tabellernes kolonner, indhold, forstå­el­se og anvendelse samt af de forretningsregler der ligger til grund for transformatio­nen.

 

Processen kort, at kildesystemernes data leverancer indlæses til DSA_SOURCE tabeller hvis indhold kontrol­le­res via forret­nings­regler i DSA_RULE tabeller og mindre berigelse af nog­le data, så korrekte data ender i DSA_NEW tabeller og fejl data i DSA_ERROR tabeller. Læs mere om kildedata og DSA opdatering.

 

3.3 Enterprise Data Warehouse

Enterprise Data Warehouse (EDW) har til formål at varetage en integreret, samkørt, forædlet, valideret, høj data kvalitet, konsistent, ca. 80% norma­li­seret og redundant fri konsoli­de­ret aktuel og historik relationel database via en sy­ste­ma­tise­ring og har­mo­ni­se­ring af data gen­nem enighed om fælles entydige definitioner på tværs af kildesy­ste­mer. Data kom­mer fra flere DSA databaser og bliver samkørt og sammenstillet i en samlet data­model med en række en­tite­ter (ta­bel­ler) i en række en-til-mange re­la­tio­ner og en-til-mange-til-mange re­la­tio­ner med pri­mær­nøgle som et fort­løben­de nummer Id (sur­ro­ga­te identity key, auto incremental) og tilhørende fremmed­nøgle Id. Da­ta­mo­del­len skal sikre his­to­rik, og vil på flere punkter adskille sig fra data­mo­del­­lerne i kildesy­ste­merne. EDW in­de­holder også kildesy­ste­mer­nes egne pri­mær­nøg­ler (business key, ap­pli­ca­ti­on key, na­tu­ral key) og de anvendes ved ind­læs­ning af data fra DSA. Når kildesystemerne skal skabe en fæl­les enighed og forret­nings­defi­nition af stamdata (master data) f.eks. le­ve­ran­dør, kun­de og pro­dukt kaldes processen Master Data Ma­na­ge­ment (MDM), hvor der opnås en fælles datade­fi­ni­ti­on af en kundens navn­givning og adresse m.fl. som re­gi­stre­res i et meta data re­po­si­tory. Herved opnås en for­be­dring af data­kva­li­tet og dataintegration og en formulering af en data go­ver­nance (forvaltning) der øger datadisciplin i kilde­sy­ste­mer­ne. (Ved dannelse af et XML do­ku­ment an­ven­des et XML sche­ma som er meta data definitioner til at sikre et validt indhold i XML filen.)

 

EDW databasen indeholder alle data for BI-LIS løsningen, og data opdeles i flere data områder inde i EDW databasen:

 

·       Basis data

Kildedata indlæst i data varehuset og klar til brug

·       Bearbejdet data

Opstillet på en form der matcher forretningsregler

·       Behandlet data

Samkørt, sammenstillet og ensartet (konform)

·       Beregnet data

Resultat af beregninger ud fra forretningsregler

·       Beriget data

Danne forædlede data ud fra forretningsregler

·       Nøgletalsdata

Rapporteringsdata klar til forretningens brugere

 

Nøgletalsdata er ofte en foreningsmængde af de andre data områder, og udvalgte data kan blive sendt videre til en data mart i en ny database til forretningens bru­ge­re i form af ad hoc søgninger, rapporter, filer og OLAP kuber med dimensioner. Nor­malt vil en EDW database kende­teg­ne et LIS i en organisation og beskrive LIS virkefelt i organisationen. Nøgle­tals­data omfatter de dannede data baseret på forretningsregler for en data udsøgning i EDW basis data og for en data berigelse, hvilket giver en data forædling på tværs af kildedata fra kildesy­ste­mer og helt nye datasæt til videre beslutninger i organisationen.

Et eksempel på en simpel forretningsregel er data udsøgning blandt flere rækker af data som hver har en dato og der ønskes kun én bestemt række ud fra enten prin­cip a eller b:

a)     Den række med tidligste dato. (eller ældste dato, mindste dato, minimum)

b)     Den række med seneste dato. (eller yngste dato, nyeste dato, maksimum)

Det kan sikkert forekomme blandt data rækkerne, at to eller flere rækker har sam­me dato hvorved principperne ikke udvælger én bestemt række, så for­ret­nings­reg­len må udvides ved at inddrage et nummer (id) som er unik/entydig pr. række:

a)     Den række med tidligste dato og dernæst mindste nummer.

b)     Den række med seneste dato og dernæst største nummer.

 

Tidligst kl. 8:00 d.v.s. ikke tidligere, ikke før.

Senest kl. 8:00 d.v.s. ikke senere, ikke efter, d.v.s. inden eller senest den dag.

 

En organisation behø­ver ikke at have ét EDW, men kan have flere der er af­græn­set til lokal organisatorisk enhed, for­ret­nings­område eller division. Eksempelvis i medicinal­bran­chen vil et EDW dæk­ke forsknings­om­rådet, og et andet EDW står for hvad der sker produktions- og salgs­mæs­sigt.

 

Den samlede proces i EDW kaldes ETL (Extracting, Transformation, Loading):

·         Extracting omfatter data overførsel fra DSA til EDW gennem forretningsreg­ler for data udsøgning:

o   Data Purging står for præcisering af ønskede rækker og kolonner, hvorved der opnås en frasortering af data mængden fra DSA og derved fra kildesystemer.

o   Data Filtering står for fjernelse af rækker der indebærer dubletter (de-duplication) eller jævnfør forretnings­regler for data der skal medtages eller skal frasorteres (fuzzy logic, pattern recognition, matching).

·         Transformation omfatter behandling, bearbejdning og berigelse samt opstil­ling af data gennem en række processer for at opnå ensarte­de data (high data quality, consistentness, accuracy, completeness and va­lid data) og håndtering af historiske data baseret på forretningsregler:

o   Data Integration står for data konvertering til fælles datatyper og dannelse af sigende udtryk der forstås af hele organisationen. En sam­­køring af flere kildesystemer kræ­ver ofte et nyt fælles be­grebs­univers, så forskellige data repræsentationer kan blive forenet til en repræsentation af data for at opnå ensartethed og fælles notation af data.

o   Data Mapning and Migration står for omkodning og oversættelse (trans­lation, standardizing) af data gennem en række mapningsreg­ler for at opnå ensartet data indhold. I økonomi verden anvendes udtrykket en kontobro mel­lem forskellige kontoplaner der skal samkøres til en fælles konto­plan som derved kan benyttes for hele koncernes økonomi data.

o   Data Transposing står for tilpasning af data for at undgå anomalier (anomalous value) og opnå konsistente data f.eks. København eller Cph bliver til Kbh eller 10.000 bliver til 10 jf. forret­nings­regel om at gemme i enheden tons fremfor kg.

o   Data Sources Combining and Merging står for samkøring af data for at tilveje­bringe data der forener kildesystemerne ud fra en række for­ret­nings­regler, så data bliver parret sammen, kaldet kon­so­li­de­ring af data.

o   Data Auditing and Validation står for en række kontroller på data i føl­ge syntaks og forret­nings­­regler, hvor fejl data kopieres til en række EDW_ERROR tabeller.

o   Data Derivation and Enhancement står for håndtering af afledte data og beregninger (calcu­la­tion) der gemmes i nye kolonner jf. for­ret­nings­regler.

o   Data Historical står for håndtering af historiske data jf. forretningsreg­ler.

o   Data Summarization and Ordering står for summering af data til et hø­jere aggregeringsniveau (aggregation, granularity) for at begrænse mængden, f.eks. fra dato- til månedsniveau samt at sortere data på bestemte må­der. Granulering af data fra atomare data til aggregerede data ud fra forret­nings­regler og kendskab til den senere data anven­del­se.

o   Creating Surrogate Identity Keys står for oversættelse af kildesy­ste­mernes primærnøgler til fortlø­ben­de nummer Id (auto in­cre­men­tal) og skabelse af fremmednøgler Id til en-til-mange relationer, så der opnås en uafhængighed til pri­mær­nøg­le-ændringer i kildesystemer. Jeg er tilhænger af, at hvert sæt af data får deres eget fortløbende nummer startende fra nummer 1, fremfor en unik global reference Id ge­ne­re­ring af samtlige data kaldet ref eller globalref tabel, men an­ven­des et arkiv mellem dsa og edw kan det være praktisk med et globalt id nummer per række i arkivet uanset hvilken tabel data er i.

·         Loading omfatter tilrettelæggelse af data til indlæsning i EDW, hvor de hi­sto­riske data skal bibeholdes mens de nye data til EDW enten skal tilføjes eller skal overskrive de eksisterende data i EDW.

Håndtering af historik vil ske via en-til-mange relationer, hvor de historiske data vil blive lagret i mange-tabeller som vil have to datoer: HistorikStartdato og Hi­sto­rik­Slutdato for den periode datum var aktuelt og havde virke i, og det nuvæ­ren­de aktuelle datum vil have HistorikSlutdato 31-12-9999. Når der senere hen kommer et nyere aktuelt datum, opdateres seneste aktuelle datum til i gårsdato, hvis perioden ikke er givet fra kildesystemet, og der bliver indsat en ny række i tabellen med nyeste aktuelle datum med Hi­storikStartdato som dagsdato og med Hi­storikSlutdato 31-12-9999. Indlæsning til EDW gennem DSA er afhængig af kildesystemet leverance data indhold d.v.s. Full dump data eller Incremental update eller Delta data detection. Ved Incremental update vil EDW indeholde data som er blevet slettet i kildesystemet og derved markerer EDW data med en Slettet­dato og sletter ikke selv data, da det formentlig skal bruges til håndtering af historiske data, hvorved EDW også ændrer HistorikSlutdato til dagsdato, så man ved, at data er blevet slettet i kildesystemet og ikke må anvendes efter den dato. Man ser også oplysninger som ErSlettet får værdien True når data er slettet i kildesystemet, og ErAktuel (eller ErNyeste) får værdien True ud for aktuelle data række som også har Hi­storikSlutdato 31-12-9999.

En-tabellen (hovedtabellen) kan også med fordel have to datoer: Gæl­dende­Startdato og Gæl­den­de­­Slut­dato, hvor sidstnævnte sættes til dagsdato når kildesystemet ikke mere leverer det datum, f.eks. en udgået vare. Ved delta data leverancer fra et kildesystem vil der typisk være en status op­lys­ning a la: N for new data, C for changed data og D for deleted data, som ind­læsningen (in­cre­men­tal up­da­te) til EDW orienterer sig mod for at opdatere da­toer og data i EDW. Når EDW ikke skal håndtere historik på et datum, f.eks. et navn på en vare i kildesystem, kan tabellen have en Oprettetdato og Opda­te­ret­dato så man ved, hvor­når data er blevet oprettet (indsat), og hvornår data sidst er blevet opdateret (ændret) som følge af en ændring af varens navn i kildesystemet. Der kan også være en Slettetdato så man ved, hvornår data ikke mere findes i kildesy­ste­met. Se eksempel på EDW opdatering.

 

Databasenavngivning er <løsningsnavn>_EDW.

Tabelnavngivningen i EDW databasen kan indeholde syv prefix:

·         EDW_TMP_<tabelnavn> med et tabelnavn uden mellemrum for de tempo­rærer tabeller der anvendes i transformationen. Tømning ved ETL start.

·         EDW_RULE_<regelnavn> med et regelnavn uden mellemrum indeholdende forskellige opsætnings- og regeldata til brug for transformation, d.v.s. data udsøgning og data berigelse.

·         EDW_MAP_<mapningsnavn> med et mapningsnavn uden mellemrum in­de­hol­den­de forskellige omkodninger og oversættelser til brug for transformation.

·         EDW_ERROR_<tabelnavn> med et tabelnavn uden mellemrum for de fejl data der blev identificeret under transformationen, klar til driften eller bru­gere. Rullende månedsvis tømning ved ETL start.

·         EDW_NEW_<tabelnavn> med et tabelnavn uden mellemrum svarende til enti­teter­ i datamodel og indeholdende de nye data fra kildesystemer inden overførsel til EDW_DB der også indeholder de histo­riske data som ikke findes i EDW_NEW. Tømning ved ETL start, og kan få tildelt højeste fort­løbende Id + 1 fra EDW_DB tabeller eller man lader Id genereringen ske ved indsættelsen i de enkelte EDW_DB tabeller.

·         EDW_DB_CURRENT_<tabelnavn> med et tabelnavn uden mellemrum sva­rende til entiteter i datamodel, der ikke håndterer historisk data, og har op­lys­­nin­­ger om GældendeStartdato og GældendeSlutdato samt Opdateret­dato. Omfatter både basis data og nøgletalsdata, hvor nøgletalsdata igen kan fun­gere som basis data for andre nøgletalsdata. Nøgletalsdata har et tids­stem­pel f.eks. en ÅrUge der angiver, for hvilken uge i året data er gæl­den­de for, eller en ÅrMåned der angiver måneden i året som data re­præ­sen­te­rer eksempelvis listen over kunder og salget til dem i en bestemt måned. En ETL vil gendanne nøgletalsdata for tidligere perioder i året, når kildesystemer ofte er lang tid om at være op­da­te­ret med alle månedens regi­stre­ringer.

·         EDW_DB_HISTORICAL_<tabelnavn> med et tabelnavn uden mellemrum sva­rende til entiteter i datamodel, der håndterer historisk data via oplys­nin­ger om HistorikStartdato og HistorikSlutdato. Omfatter basis data, og nøg­letalsdata har tids­stem­pel og bliver ikke gendannet ved senere ETL grundet rapporte­rings­grund­laget ønskes bibevaret, så der opnås en data skive pr. periode baseret på periodens forretningsregler der ofte ændrer sig over tid.

Der bør foreligge en fuld dokumentation af tabellernes kolonner, indhold, forstå­el­se og anvendelse samt af de forretningsregler der ligger til grund for trans­for­ma­tio­nen.

 

Processen kort, at DSA_NEW tabellernes indhold transformeres gennem en række EDW_TMP tabeller via forretningsregler i EDW_RULE og EDW_MAP tabeller, så korrekte data ender i EDW_NEW tabeller og fejl data i EDW_ERROR tabeller, hvor­ef­ter data fra EDW_NEW tabeller indlæses til EDW_DB tabeller.

 

3.4 Data Mart Area

Data Mart Area (DMA) har til formål at varetage en række konkrete anvendelser af data fra EDW gennem data udsøgning, data behandling, data bearbejdning og data berigelse baseret på forretningsreg­ler til præsentation. Fra EDW anvendes både basis data og nøgletalsdata i DMA kombineret med yderligere data forædling afhængig af opgaven og forretningsområdet. DMA er be­græn­set og fokuseret på et emne orienteret an­ven­delsesområde til en afgrænset gruppe af brugere or­ga­ni­sa­to­risk og funktionelt. Der kan sagtens være flere data marter til udstilling og præsentation af forskellige nøgletal. DMA kan levere data til eksempelvis et regne­ark, rapporter, ad hoc søgninger i SAS eller til en OLAP kube med dimensioner. Et DMA kan også levere data til flere OLAP kuber inde­hol­den­de flere mea­suregroups med fælles di­men­sioner (sha­red di­men­­sions). Når DMA skal an­ven­des til at levere data fra EDW til en OLAP kube, bliver data i DMA opstillet i en data­model­ kaldet dimensionel modeling med di­men­sio­ner og factdata. Fact­data be­skri­ver det faktum der er sket, og di­men­sio­ner beskriver de tilhørende data. Ek­sem­pelvis hændelsen: »Den 7. februar 2006 sælges fire lap­top computere til Novo Nordisk.« Fak­tum er salget med tilhørende målbar op­lys­ning: antal varer som kaldes en ana­lyse­variabel (mea­sure). Dimensioner er Tid, Kun­de og Vare, der typisk er hierarki niveau ind­delt f.eks. Tid i År Halvår Kvartal Måned Uge Dato, Kunde i forskellige segmenter og Vare i forskellige sortimenter.

 

DMA dimensionaliseret data model dimensional modeling består af tre skemaer:

·         Star schema består af flere dimensions tabeller og en factdata tabel, d.v.s. en measuregroup i en kube. En dimension med flere niveauer i hierarkiet er de­nor­ma­li­se­ret og repræsenteret ved en dimensions tabel. Alle dimensions tabeller er forbundet til factdata tabellen. Stjerne skema. Eksempel

·         Constellation schema består af flere dimensions tabeller og flere factdata ta­bel­ler der deler en række dimensions tabeller, d.v.s. flere measuregroups i en eller flere kuber med fælles dimensioner. En dimen­sionstabel kan være for­bun­det til forskellige factdata tabeller. Constellation betyder stjer­ne­­bil­le­de d.v.s. flere stjerne skemaer der anvender samme fælles dimensioner (sha­red dimensions). Eksempel

·         Snowflake schema består niveauer i hierarkiet af en dimension af flere norma­li­se­ret dimensions tabeller, således at ikke alle dimensions tabeller er forbundet til factdata tabellen. Når et hierarki er opdelt i flere dimensions tabeller, kan de hver for sig være forbundet til forskellige factdata tabeller. Eksempel

Star schema vedrører et afgrænset emne, mens Constellation schema vedrører en ræk­ke emner som har fælles dimensioner hvorved der opnås en samkøring af information på tværs af emner og de forskellige funk­tio­ner i or­ga­ni­sa­tio­nen.

Læs mere om dimensional modeling.

DMA er en database som normalt er implementeret i samme miljø som LIS.

 

Den samlede proces i DMA kaldes ETL (Extracting, Transformation, Loading):

·         Extracting omfatter data overførsel fra EDW til DMA gennem forretningsreg­ler for data udsøgning:

o   Data Purging står for præcisering af ønskede rækker og kolonner f.eks. begrænses de historiske data til de sidste fem år.

·         Transformation omfatter behandling, bearbejdning og berigelse samt opstil­ling af data gennem en række processer for at opnå den ønskede an­ven­del­se baseret på forretningsregler:

o   Data Integration står for håndtering af »ukendte« og »uden« (mang­ler, blank, tom, null) data værdier i dimension og factdata.

o   Data Derivation and Enhancement står for udsøgning af data til dimen­sionsdata ved sammenstilling og gruppering af værdier, antals­beregning pr. en periode, netto bevægelse og andre analyse­variable til factdata til senere udstilling og præsentation i kube.

o   Data Mapning and Migration står for omkodning og oversættelse (trans­lation) af data gennem en række mapningsreg­ler for at opnå bestemte dimensionsværdier og tilretning af factdata.

o   Slowly Changing Dimensions står for håndtering af dimensionsdata som øjebliksbillede og/eller med historiske data d.v.s. tidligere vær­dier og hierarkiske placeringer. Læs artikel om dimensioner.

o   Data Summarization and Ordering står for summering af data til et højere aggregeringsniveau (granularity) for at begrænse data mængden, f.eks. fra dato- til månedsniveau samt at sortere data på bestemte måder i dimension og factdata.

o   Reuse EDW Identity Keys Id per dimensionsdata i dimensionstabeller skal som udgangspunkt komme fra EDW databasen og indgå som fremmednøgler i factdata tabeller. En kalender, tid eller periode dimension kan med fordel an­ven­de en yyymmdd talværdi som Id, som factdata kan være clustered efter til sikring af hurtigere svartider (performance) fordi data ofte skal afgrænses inden for en periode.

o   Creating Surrogate Identity Keys står for fortløbende nummer Id hvilket kan være nødvendigt ved nogle særlige dimen­sions­data der ikke findes i EDW databasen.

o   Data Auditing and Validation står for en række kontroller på data f.eks. at alle dimensions­kolonner i factdata er udfyldt og findes i di­men­sions ta­bel­ler (referential integrity). Fejl data flyttes til en række DMA_ERROR tabeller.

·         Loading omfatter tilrettelæggelse af data til indlæsning i DMA, hvor det må vur­de­res om dimen­sion og factdata tabeller tømmes eller der kun indlæses delta data. DMA kan sagtens indeholde dimensions tabeller, hvis indhold er faste og ikke ændres af ETL f.eks. en kalender og forskellige serie grup­pe­rin­ger (discretization) (rød, gul, grøn for status eller 0-12, 13-19, 20-29, 30-66, 67-199 for aldersgrup­pe­r.

Databasenavngivning er <løsningsnavn>_DMA_<evt. et præciserede navn>.

Tabelnavngivningen i DMA databasen kan indeholde syv prefix:

·         DMA_TMP_<tabelnavn> med et tabelnavn uden mellemrum for de tempo­ræ­rer tabeller der anvendes i transformationen. Tømning ved ETL start.

·         DMA_RULE_<regelnavn> med et regelnavn uden mellemrum indeholdende for­skellige opsætnings- og regeldata til brug for transformation af både di­men­sions­værdier og factdata, d.v.s. for data udsøgning og data berigelse.

·         DMA_MAP_<mapningsnavn> med et mapningsnavn uden mellemrum indeholdende forskellige omkodninger og oversættelser til brug for transformation af di­men­sions­værdier.

·         DMA_ERROR_<tabelnavn> med et tabelnavn uden mellemrum for de fejl da­ta der blev identificeret under transformationen, klar til driften og brugere. Tømning ved ETL start.

·         DMA_DIM_<tabelnavn> med et tabelnavn uden mellemrum som er en dimen­sions tabel til en OLAP kube. Dimensions tabel skal have samme navn som dimension i kuben.

·         DMA_FACT_<tabelnavn> med et tabelnavn uden mellemrum som er en factdata tabel til en OLAP kube. Factdata tabel skal have samme navn som measure­group i kuben.

·         DMA_DB_<tabelnavn> med et tabelnavn uden mellemrum som står for en data leverance f.eks. til et regneark til brugere eller et xml dokument til visning af data på en hjemmeside eller til indlæsning i et andet system. Tabellen an­ven­des også til at indeholde summeret data som brugere ofte fore­spørger på for at opnå hurtig svartid (materialized view).

Viewnavngivningen i DMA mod kubens dimensioner og measuregroups:

·         DIM_<dimensionnavn> svarende til dimensions tabel. View kan sammensætte Kode + Værdi til et Navn f.eks. Per Hansen - 120980-3271, hvor cprnr er Kode og Per Hansen er Værdi kolonner i dimensions tabellen.

·         FACT_<factdatanavn> svarende til factdata tabel og evt. indeholdende beregninger f.eks pris inkl. moms.

Der bør foreligge en fuld dokumentation af tabellernes kolonner, indhold, forstå­el­se og anvendelse samt af de forretningsregler der ligger til grund for trans­for­ma­tio­nen. Se eksempel på DW/DMA opdatering.

 

Processen kort, at EDW_DB tabellernes indhold transformeres gennem en række DMA_TMP tabeller via for­ret­nings­regler i DMA_RULE og DMA_MAP tabeller, så di­men­sions­data ender i DMA_DIM tabeller hvor data får en pri­mær­­nøgle Id, factdata ender i DMA_FACT tabeller med fremmednøgle Id og fejl data i DMA_ERROR tabeller. Afhængig af data mængden og ETL forløbet foretages der enten en tømning af DMA_DIM og DMA_FACT tabeller eller der sker en delta opdatering, d.v.s. der foretages en tilføjelse af nye data, opda­te­ring af eksisterende data og sletning af ikke mere eksisterende data. Det vigtigste er, at der sikres reference integritet mellem dimensionsdata og factdata, så factdata tabellen ikke refererer til en dimensionsdata der ikke findes i dimensionstabellen (referential integrity).

 

4. Navngivning af løsning og projekter

En samlet løsning for BI-LIS kunne være:

Løsningsnavn: <Løsningsnavn>_LIS.

Databaserne skal prefixes med løsningsnavn, så der er sporbarhed mellem ele­men­ter­ne i den samlede BI-LIS løsning.

Projekter i løsningen får prefix løsningsnavn og derefter et prefix AS, IS, RS for projekt­typen for h.h.v. Analysis Services, Integrated Services og Report Services.

Et AS projekt indeholder fælles dimensioner og en eller flere kuber (superkuber) som hver indeholder en eller flere measuregroups. En measuregroup indeholder analyse­variabel (nøgletal, measure) som prefixes med navnet på measuregroup og en ana­lyse­variabel placeres i en mappe (display folder). Det gælder også be­reg­net analyse­variabel (calculated measure), som kan gå på tværs af measuregroups ved at anvende analysevariable fra forskellige measuregroups. Analysevariabel kan over­sæt­tes til et sigende navn for brugerne i Excel og Targit m.fl. Dimensioner og analyse­variable kan samles i perspektiver, så brugerne ser på et perspektiv af gan­gen og frit kan kom­bi­ne­re dimensioner og analysevariable inden for et per­spek­tiv.

Et IS projekt inde­hol­der en eller flere IS-pakker, og deres navne skal ligeså være unikke, derfor prefixes IS-pakke navnene med løsningsnavn og projektnavn. Et IS projekt indeholder en række modulopdelte IS pakker, der bliver afviklet fra en master IS pakke der bliver starter af et job på et bestemt tidspunkt. XML konfigurationsfil til con­nec­tions anvendes for hurtig idrift­sæt­telse af IS pakker fra ud­vik­lings­mil­jø over testmiljø til pro­duk­tions­­miljø.

Et RS projekt indeholder en række rapporter til Report Services der tilgås fra web, sharepoint eller en applikation.

 

Eksempel på ønsket navngivning i en XXX løsning som består af to dele (solutions) for frontend og backend opdelt i projekter.

 

Løsning frontend

 

Projekter

Formål

XXX_LIS_AS_CUBES

med (super)kuber og deres egne measure­groups og fælles dimensioner. Undgå en stor kube, der­for implementer flere emne kuber i dette projekt.

Ved deployment bliver projektnavnet til olap da­ta­base navnet, som brugerne forbinder sig til via Excel, Targit m.fl., derfor indgår løsnings­navnet, fordi der kan være flere løsninger og olap da­ta­baser på ser­ve­­ren. Anvendes perspektiver i de enkelte kuber, bliver navnet på perspektivet lig med den kube som brugerne ser, og de tilvalgte analysevariable fra flere measuregroups og di­men­sio­ner vises som en samlet kube, der letter brugerne fremfor de kan se flere measuregroups.

XXX_LIS_RS_Report

med design af udskrifter til deploy i Report Services og tilgås via browser.

XXX_LIS_IS_AS_PROCESS

med IS pakke for processering af dimensioner og kuber i projektet XXX_LIS_AS_CUBES.

Løsning backend

 

Projekter

Formål

XXX_LIS_DB_DSA

Database struktur til DSA.

XXX_LIS_DB_EDW

Database struktur til EDW.

XXX_LIS_DB_DMA

Database struktur til DMA.

XXX_LIS_IS_DSA_ETL

med IS pakker for ETL fra kildesystem til DSA.

XXX_LIS_IS_EDW_ETL

med IS pakker for ETL fra DSA til EDW.

XXX_LIS_IS_DMA_ETL

med IS pakker for ETL fra EDW til DMA.

XXX_LIS_IS_FILE_ETL

Dannelse af Excel og txt filer til brugerne, hvor et 64-bit miljø ikke kan danne filer, så der laves et nyt projekt med 32-bit Run64BitRuntime = False.

XXX_LIS_IS_MAIL_ETL

Mail til brugere med eksempelvis ETL genereret Excel regneark og til driften med status af ETL forløbet.

XXX_LIS_IS_Maintenance

med IS pakker til backup af alle databaser og alle de ovenstående løsninger (solutions). Det burde dog være unødvendigt, fordi driften af SQL Ser­ve­ren skal sikre backups af databaser og kilde­kode­filer.