Het datawarehouse van ChipSoft

Het datawarehouse van ChipSoft Op welke manier kan de verversing binnen het datawarehouse van ChipSoft korter en/of frequenter worden gedaan in combinatie met het kunnen rapporteren van rapportages over mutaties in de tijd? 4/29/2009 ChipSoft B.V. Sergio Lie-A-Lien

Samenvatting Deze scriptie beschrijft het onderzoek naar de mogelijkheden om het huidig verversingsproces binnen het datawarehouse van ChipSoft korter en/of frequenter te laten verlopen in combinatie met het kunnen rapporteren van rapportages over mutaties terug in de tijd. Dit onderzoek is verricht bij ChipSoft te Amsterdam, in het kader van het afstuderen van de bachelor opleiding hogere informatica aan de hogeschool van Amsterdam. ChipSoft is een bedrijf dat zich richt op de zorgsector, waarbij vooral ziekenhuizen de belangrijkste klanten vormen. ChipSoft beschikt over haar eigen software genaamd het CS-EZIS (ChipSoft Electronisch Zorg Informatie Systeem). Het CS-EZIS dient ter ondersteuning van de zorgprocessen van ChipSoft ‘s klanten. De verversing van het datawarehouse van ChipSoft wordt door de logica laag van de

CS-EZIS software in plaats van een volledig Microsoft SQL server gebaseerd verversingsproces uitgevoerd. De verversing via de logica van het EZIS vermindert de kans op fouten en levert dus een betere kwaliteit van het datawarehouse op. Hier tegenover staat wel een verlies aan snelheid van de verversing. Om het verlies aan snelheid te compenseren moet er op een andere manier tijdwinst gemaakt worden. Ook is er vanuit de klantzijde van ChipSoft de wens ontstaan om rapportages over mutaties terug in de tijd te kunnen rapporteren. Er is daarom onderzoek verricht naar een opzet om deze twee punten in combinatie met elkaar te realiseren. Dit onderzoek is gericht op het verrichtingenmodel en wordt als pilot gebruikt om het proof of concept op alle modellen toe te kunnen passen. Dit onderzoek geschiedt door middel van een literatuuronderzoek naar de technieken rondom het ‘incrementeel laden’ en het behoud van de historische records van het datawarehouse en vervolgens als optie uit te kunnen programmeren in het CS-EZIS. Er wordt door middel van Microsoft SQL Server Profiler een ‘trace’ uitgevoerd die aantoont of de uitgeprogrammeerde optie, ‘ incrementeel laden’ van een feitentabel sneller verloopt dan een volledige verversing.

2

Inhoudsopgave 1 Introductie ______________________________________________________________ 5 2 Probleemstelling _________________________________________________________ 6 2.1 Onderzoeksvraag __________________________________________________ 7 2.2 Opbouw __________________________________________________________ 7 3 ChipSoft ________________________________________________________________ 9 3.1 CS-EZIS ___________________________________________________________ 9 3.2 De werking van CS-EZIS ______________________________________________ 9 3.3 Samenstelling van het CS-EZIS _______________________________________ 10 4 Datawarehouse _________________________________________________________ 14 4.1 Inleiding _________________________________________________________ 14 4.2 Definitie van een datawarehouse _____________________________________ 14 4.3 Ster-schema ______________________________________________________ 17 4.4 Huidige CS-Datawarehouse verversing _________________________________ 19 4.5 Huidige CS-Datawarehouse obstakels __________________________________ 19 4.6 CS-Dataflow in een notendop ________________________________________ 21 5 Het Onderzoek __________________________________________________________ 22 5.1 Gegevens verzamelen _______________________________________________ 25 5.2 Wanneer en hoe dient de verversing in het datawarehouse te gebeuren? _____ 25 5.3 Incrementeel laden _________________________________________________ 26 5.4 SQL Server 2008 ___________________________________________________ 27 6 Ontwerp datawarehouse__________________________________________________ 31 6.1 Ontwerp incrementele verversing inclusief opslag historische records in de feitentabel ________________________________________________________ 31 6.2 Feitentabel incrementeel laden _______________________________________ 34 7 Uitwerking ‘Incrementeel laden’ ____________________________________________ 36 7.1 Werking van de optie ‘Incrementeel laden’ ______________________________ 36 7.2 ‘Trace’ ____________________________________________________________ 36 Conclusie _________________________________________________________________ 40 Gebruikte software & tools __________________________________________________ 41 Literatuur ________________________________________________________________ 42 Begrippenlijst in alfabetische volgorde _________________________________________ 43 3

Bijlage A _________________________________________________________________ 44 Bijlage B _________________________________________________________________ 45 Bijlage C__________________________________________________________________ 46

4

1. Introductie Vandaag de dag is de informatiebehoefte van organisaties groot en aan veel wisseling onderhevig. De eisen die worden gesteld door bedrijven om snel en inzichtelijk informatie te verkrijgen liggen hoog. Aan deze eisen wordt tegemoet gekomen met een datawarehouse. Een datawarehouse maakt het mogelijk om verschillende bronnen van informatie te ontsluiten. Een datawarehouse integreert de gegevens uit gegevensbronnen zodat er één centrale locatie aanwezig is waar deze kunnen worden geraadpleegd. Het is gebouwd om grote hoeveelheden data op te vragen waarmee snel en complexe rapportages gemaakt kunnen worden. De rapportages zijn van groot belang omdat er hiermee allerlei analyses kunnen worden uitgevoerd. Het grootste deel van de hedendaagse bedrijven heeft al voldoende aan vaste ververstijden van hun datawarehouse. De klanten van ChipSoft bijvoorbeeld hebben genoeg aan een verversing die één keer per dag plaatsvindt en liefst in de nacht wanneer er geen gebruik gemaakt wordt van het datwarehouse door eindgebruikers. Maar in het algemeen is dit afhankelijk van het soort informatie: hoe snel gegevens veranderen en hoe belangrijk deze actuele gegevens zijn voor analyserapportages. Met de huidige technische ontwikkelingen en door dat er steeds meer vraag is naar kortere verversingen en actuele informatie, wordt het interessant om te kijken wat deze ontwikkelingen kunnen bijdragen aan ChipSoft en haar klanten. Het is dus wenselijk en ook de bedoeling dat incrementele (alleen de gemuteerde data) verversing van het datawarehouse gerealiseerd wordt. Een andere aanpak hiervoor is een real-time oplossing. Hier worden er wijzigingen in de bronsystemen direct doorgevoerd in het datawarehouse. De gepresenteerde informatie die door middel van rapportages opgevraagd wordt vanuit het datawarehouse is onmiddellijk zichtbaar. De real-time behoefte en het abstractieniveau binnen de organisatie is afgebeeld in onderstaande grafiek: Detail

Werkvloer

Abstract

Directie/Eindgebruiker

Real-time informatiebehoefte Figuur 1. Real-time behoefte 5

2. Probleemstelling ChipSoft beschikt over haar eigen software, het CS-EZIS1. Binnen de CS-EZIS software wordt data opgeslagen in de brondatabase. Het is niet efficiënt om op de brondatabase rapportage vraagstukken uit te voeren. Het is niet efficiënt omdat de brondatabase van opzet genormaliseerd is en het wenselijk is een minimale belasting op de brondatabase te hebben. Voor het uitvoeren van rapportage vraagstukken is het CS-Datawarehouse2 beschikbaar. Het CS-Datawarehouse is opgezet volgens internationale uitgangspunten (www.kimballgroup.com). Een globaal overzicht van een datawarehouse staat geïllustreerd in het onderstaand figuur.

Management

Datawarehouse

Overzicht

OLTP

Werkvloer

Figuur 2. Globaal overzicht datawarehouse

1

ChipSoft Elektronisch Zorg Informatie Systeem

2

ChipSoft Datawarehouse

6

In het vorige hoofdstuk werd aangegeven dat ChipSoft een kortere of snellere verversing van het CS Datawarehouse wil realiseren. De aanleiding voor een kortere of snellere verversing is ontstaan omdat het ETL3 proces door de logica laag van het CS-EZIS wordt uitgevoerd en niet door een volledig op Microsoft SQL server gebaseerd ETL proces. ChipSoft heeft gekozen om het ETL proces door het CS-EZIS te laten gebeuren, omdat de kans tijdens dit proces op fouten verkleind wordt. Hier tegenover staat dat het ETL proces via het CS-EZIS meer tijd in beslag neemt dan op een microsoft SQL server gebaseerd ETL proces. De tijd is terug te winnen door het ETL proces sneller te laten verlopen. Dit punt is ook ontstaan uit een wens aan de klantzijde van ChipSoft en levert ChipSoft meer tijd en ruimte om andere bewerkingen naast de verversing op het CS datawarehouse uit te kunnen voeren. Als de verversing momenteel bijvoorbeeld vier uren in beslag neemt en deze kan gereduceerd worden naar twee uren, dan is er een tijdwinst van twee uren gecreëerd. In die twee uren kunnen er nog allerlei processen of taken in het CS datawarehouse worden gedraaid. Een voorbeeld van een proces of een taak is het maken van een back-up.

2.1

Onderzoeksvraag

De probleemstelling leidt tot de volgende onderzoeksvraag: Op welke manier kan het huidig verversingsproces binnen het datawarehouse van ChipSoft korter en/of frequenter worden gedaan in combinatie met het kunnen rapporteren van rapportages over mutaties in de tijd? De onderzoeksvraag is op te splitsen als volgt: Ten eerste: Op welke manier kan de huidige verversing binnen het datwarehouse van Chipsoft korter en/of frequenter worden gedaan? Ten tweede: Hoe kunnen er vanuit het CS-Datawarehouse rapportages over mutaties in de tijd gerapporteerd worden?

2.2

Opbouw

Deze scriptie is opgebouwd uit zeven hoofdstukken. In hoofdstuk drie wordt de samenstelling en de werking van het elektronisch zorg informatie systeem van ChipSoft 3

ETL staat voor Extraheren, Transformeren en Laden. Zie hoofdstuk 4.3.

7

beschreven. In hoofdstuk vier wordt er een definitie gegeven van wat een datawarehouse is en wat een datawarehouse precies inhoudt. Er wordt tevens aandacht besteed aan de verversingstijden van de verschillende processen in het datawarehouse. Deze processen worden in een figuur afgebeeld zodat deze overzichtelijk zijn. De verversing van het datawarehouse wordt gerealiseerd door de overzichten in de overzichtsgenerator4, dit wordt nader beschreven in dit hoofdstuk. In hoofdstuk vijf wordt het onderzoek beschreven dat een aanleiding vormt voor de aanpak van de probleemstelling. In hoofdstuk zes wordt de aanpak en oplossing van de probleemstelling uitgewerkt. Het conclusie hoofdstuk zal ingaan op de conclusies en aanbevelingen die gedaan kunnen worden aan de hand van het beschreven onderzoek. De gestelde onderzoeksvraag en deelvragen kunnen aan de hand van dit hoofdstuk beantwoord worden. Tot slot geeft het literatuur hoofdstuk een weergave van de literatuur die is gebruikt in het onderzoek.

4

Overzichtsgenerator is een module in het CS-EZIS die het genereren van meerdimensionale rapporten mogelijk maakt. De Overzichtsgenerator kan vanuit het CS-EZIS aangeroepen worden, zowel voor het aanmaken van de overzichten als het opvragen van de overzichten.

8

3. ChipSoft ChipSoft begon in 1986 met het ontwikkelen van softwareproducten voor medisch specialisten en diverse afdelingen binnen het ziekenhuis. In 1994 introduceerde ChipSoft haar eerste ziekenhuisinformatiesysteem. In 2001 speelde ChipSoft een pioniersrol met de lancering van het eerste geïntegreerde, op Windows gebaseerde zorginformatiesysteem: het Elektronisch Zorg Informatie Systeem (CS-EZIS). Sinds de oprichting richt ChipSoft zich als leverancier volledig op de zorgsector. Binnen de Nederlandse ziekenhuizen is ChipSoft inmiddels een begrip als het gaat om krachtige ICToplossingen. De verschillende producten van ChipSoft worden inmiddels in zes Europese landen gebruikt en onlangs ook in België. Desondanks is ChipSoft nog steeds een puur Nederlands softwarebedrijf.

3.1

CS-EZIS

Het CS-EZIS is een zorginformatiesysteem met open standaarden, waarin verschillende instellingen van het systeem gewijzigd kunnen worden. Er kunnen extra opties toegevoegd worden. ChipSoft biedt met het CS-EZIS aan zorginstellingen een totaalpakket van producten en diensten. Hierdoor ontstaat één aanspreekpunt voor alle vragen voor de zorginstellingen rondom automatisering. Het CS-EZIS ondersteunt een aantal zorgprocessen en deze zijn: klinisch, poliklinisch, ordercommunicatie, EPD-vorming (Elektronisch Patiënten Dossier), facturering en verrichtingenadministratie. In het CS-EZIS bestaat ook de mogelijkheid patiëntendossiers, planningschema's, doorstroommogelijkheden, de medicatie en de administratie te verwerken. De zorgprocessen en verschillende functionaliteiten zijn los van elkaar te implementeren. Er hoeft geen complete implementatie van het CS-EZIS plaats te vinden. Het is mogelijk om een specifiek zorgproces en/of functionaliteit te implementeren.

3.2

De werking van CS-EZIS

De kracht van het CS-EZIS ligt bij de volgende basisprincipes: gebruiksvriendelijkheid, ongelimiteerde uitbreiding van functionaliteit, eenduidige gegevensregistratie aan de bron en communicatiemogelijkheden met software van derden. De instellingen in het CS-EZIS zijn 9

aan te passen waarbij elke gebruiker in een eenduidige interface precies de benodigde functionaliteiten ter beschikking krijgt die hij of zij nodig heeft bij het uitoefenen van zijn of haar functie. Het CS-EZIS is gebaseerd uit drie bouwlagen die van elkaar los kunnen staan: • één laag bevat alle data; • de tweede laag bestaat uit de programmatuur waarin de functionaliteit zit; • de derde laag bevat de presentatie aan de gebruiker. Dankzij deze flexibele architectuur kunnen voor elke laag onafhankelijke keuzes worden gemaakt, of het nu gaat om het type database, de in te bouwen functionaliteit (van ChipSoft, dan wel van derden) of de te gebruiken client(s).

3.3

Samenstelling van het CS-EZIS

Het CS-EZIS beschikt over veel functionaliteit. Om dit passend aan de Nederlandse gezondheidszorg aan te kunnen bieden is dit gegroepeerd in modules. Onderstaand heb ik een aantal van de vele modules opgesomd die tezamen het CS-EZIS vormen: CS-Patiënt vormt de basis van het CS-EZIS. Met deze module vindt de registratie en vastlegging plaats van de patiëntgegevens zoals naam, adres en woonplaats, maar ook de verzekeringsgegevens van de patiënt. Wanneer vanuit het verleden patiënten dubbel zijn ingeschreven in het systeem is het ‘doorkoppelen’ van de records hier ook mogelijk. De overige modules van het CS-EZIS, bijvoorbeeld het CS-Faktuur, maken gebruik van de gegevens die in CS-Patiënt worden vastgelegd. CS-Opname is specifiek ontworpen voor de opname-afdeling, die een ondersteuning van alle uitgevoerde activiteiten met betrekking tot opname-planning en -registratie binnen het ziekenhuis aanbied. CS-Afdeling is het verpleegkundige informatiesysteem dat op de afdeling gebruikt kan worden door verpleegkundigen, specialisten en het secretariaat voor het decentraal registreren van opnamegegevens, decentraal plannen van patiënten, ordercommunicatie, raadplegen van standaardprotocollen en het opvragen van verschillende gegevens binnen het CS-EZIS. CS-Agenda is een elektronisch afsprakensysteem. Alle relevante afspraken zijn eenvoudig raad te plegen met dit systeem. Het uitgangspunt is: informatie vastleggen aan de bron, zonder tussenschakels. Op deze manier is de kans op foutieve registratie minimaal. Direct vastleggen of wijzigen van afspraken, daar waar het noodzakelijk is, zorgt voor een betrouwbare en overzichtelijke agenda voor iedereen die ermee moet werken. CS-Agenda is geheel naar eigen wens in te richten.

10

CS-Episode is de module van het CS-EZIS waarmee het mogelijk is om het zorgtraject van de patiënt vast te leggen in de vorm van een diagnose behandelcombinatie (DBC). Op basis van een wijziging in de zorgvraag, het specialisme of de instelling is het verplicht om een DBC en het bijbehorende zorgtraject elektronisch vast te leggen. In het CS-Episode registreert de eindgebruiker alleen de DBC, terwijl het bijbehorende zorgtraject automatisch wordt vastgelegd. CS-Faktuur betreft het factureringssysteem. In CS-Faktuur vindt de afrekening plaats van alle declarabele verrichtingen in het zorgproces en de doorstroming ervan naar het financiële systeem. Uiteindelijk wordt het mogelijk gemaakt om alle declarabele verrichtingen ook daadwerkelijk te factureren. CS-OK is het OK-management en registratiesysteem dat een complete ondersteuning biedt aan het bedrijfsproces zoals dit op operatiekamers voorkomt, maar ook de planning van de OK’s behoort tot de standaardfunctionaliteit. CS-Digitale Dossier Registratie is een module binnen het CS-EZIS die het mogelijk maakt alle zaken rondom de behandeling van een patiënt - van de opnameanamnese5 tot de rapportage - vast te leggen op een gestructureerde wijze. CS-Röntgen biedt de ondersteuning aan de bedrijfsprocessen van de radiologieafdeling. CSFunctieafdeling is een afgeleide van CS-Röntgen, de bedrijfsprocessen zijn grotendeels gelijk. Met de aanleverende apparatuur kunnen koppelingen worden gemaakt. CS-SEH is ontwikkeld om de administratieve handelingen die plaatsvinden op de Spoed Eisende Hulp te automatiseren. CS-SEH zorgt voor oplossingen voor de problemen die op de Spoed Eisende Hulp voorkomen. Doordat het in CS-SEH mogelijk is om op een adequate, snelle manier een patiënt te registreren, wordt de tijdsdruk op de Spoed Eisende Hulp sterk verminderd. Alle bovenstaande modules vormen samen met nog vele andere modules het CS-EZIS dat geïntegreerd een goede oplossing biedt voor de verschillende bedrijfsprocessen in zorginstellingen In de onderstaande figuur is er een patiënten invoerscherm te zien. De CS-Faktuur module heb ik bewust gekozen om als afbeelding op te nemen, omdat ik me voornamelijk zal richten op het verrichtingenmodel. Hier kunnen er nieuwe verrichtingen ingevoerd worden van een patiënt of bestaande verrichtingen worden gewijzigd. Vervolgens kunnen de nieuwe ingevoerde verrichtingen en de reeds nog niet gefactureerde verrichtingen, gefactureerd worden. Let wel, de reeds gefactureerde verrichtingen kunnen niet zomaar gewijzigd worden. De reeds gefactureerde verrichtingen beschikken over een factuurdatum. De 5

Een anamnese komt tot stand doordat de dokter aan de patiënt gericht vragen stelt.

11

desbetreffende verrichting moet eerst gecrediteerd worden en vervolgens kunnen daarin wijzigingen worden aangebracht.

12

Figuur 3. Patiënt invoer scherm faktuur-verrichtingen

13

4. Datawarehouse 4.1

Inleiding

De meningen over de precieze betekenis van een datawarehouse zijn verdeeld. In dit hoofdstuk wordt vastgesteld uit welke onderdelen een datawarehouse bestaat en wat binnen het onderzoek onder datawarehouse wordt verstaan. De huidige situatie en de techniek van het CS- datawarehouse worden ook in dit hoofdstuk beschreven.

4.2

Definitie van een datawarehouse

Zoals eerder aangegeven zijn er verschillende meningen over het begrip datawarehouse. In het onderstaand som ik een aantal definities van bekende auteurs op het gebied van datawarehouse: “A copy of transaction data specifically structured for query and analysis.” Ralph Kimball, The Datawarehouse Toolkit. “A collection of integrated, subject-oriented databases designed to support the DSS(Decision Support System) function where each unit of data is relevant to some moment in time…” Inmon, Imhoff and Sousa, The Corporate Information factory “Datawarehouses combine data from all types of sources and have the following characteristics: subject oriented, integrated, time variant (has a time component), and nonvolatile (no data are deleted..).” Walton and Cline in Datawarhouses/Data Marts: repositories for Data Mining.

Een datawarehouse is in principe een verzamelplaats van gegevens waarin informatie per onderwerp, bedrijfsproces of afdeling is opgeslagen. De informatie wordt uit één -of verschillende bronsystemen geëxtraheerd en geïntegreerd in één systeem. De informatie is historisch en niet vluchtig. Dat wil zeggen dat de informatie één keer wordt ingeladen, opgeslagen en daarna niet meer gewijzigd. Het overzetten van data uit de database naar het datawarehouse is een proces van “recente” data naar historische data, waarbij de data wordt gestructureerd en gegroepeerd zodat er op snelle en efficiënte manier gerapporteerd en geanalyseerd kan worden. Het initiële datawarehouse is opgebouwd uit datamarts. De 14

datamarts zijn afgebakende gegevensverzamelingen, die ieder los van elkaar op een specifiek gebied gegevens bevatten. Doordat deze gegevens specifiek per gebied zijn opgeslagen is het qua informatie-opvraag zeer voordelig wat betreft querie response, integriteit van de informatie en de belasting van het datawarehouse. De gegevens uit de verschillende datamarts worden gecombineerd om vervolgens te komen tot informatie die organisatiebreed nuttig is. De opzet van het CS-datawarehouse is in SQL tabellen. Er is sprake van zogenaamde platte overzichten.

Dimensionaal structuur Bij het modelleren van gegevens voor het ontwikkelen van systemen wordt er gebruik gemaakt van de normalisatieregels van Codd6. Normaliter wordt er eerst begonnen met het onderkennen van entiteiten en vervolgens worden deze genormaliseerd, opdat er geen redundantie7 meer is en de consistentie optimaal kan worden gegarandeerd. De informatiesystemen die meestal worden ontwikkeld, zijn bedoeld ter ondersteuning van een operationeel proces en hiervoor is deze manier van gegevens modelleren bij uitstek geschikt. Een datawarehouse is echter niet bedoeld voor ondersteuning van operationele processen, maar voor het leveren van informatie op strategisch dan wel tactisch niveau. Deze factoren maken het datawarehouse geschikt voor een andere benadering bij het opstellen van de gegevenstructuur. In de feitentabel staan de feiten waarvan we alles willen weten. Een dimensie is een plek waar kenmerken worden gewaarborgd die iets kunnen zeggen over de feiten. Om dit in een voorbeeld uit te leggen kijken we naar de verrichtingen als feit, die in de feitentabel is opgeslagen. Vervolgens kunnen we bepaalde vragen stellen zoals: - Bij welke patiënt hoort “verrichting X”? - Wanneer heeft verrichting X plaatgevonden? - Hoeveel verrichtingen zijn er uitgevoerd? - Waar is “verrichting X” uitgevoerd?

Dimensie patiënt (referentie) Dimensie datum (referentie) Analysevariabele aantal Dimensie Locatie (referentie)

Er wordt gesteld dat gegevens op strategisch niveau het beste multidimensioneel gedenormaliseerd kunnen worden gemodelleerd. In dat geval kunnen de gegevens worden gepresenteerd als ‘kubus’, wat voor de eindgebruiker veel makkelijker te begrijpen is. Een

6

Codd, E.F. "Is Your DBMS Really Relational?" en "Does Your DBMS Run By the Rules?" ComputerWorld, Oktober 14 1985 and Oktober 21 1985.

7

Wanneer gegevens in een niet genormaliseerd datamodel in een database worden opgeslagen, bevat de database informatie die meerdere keren is opgeslagen.

15

kubus is een verzameling van dimensies waarbij de doorsnede van de dimensies op kan worden ingezoomd.

Figuur 4. Kubus opgebouwd vanuit dimensies In de kubussen worden dimensies en meetwaarden gecombineerd zodat vanuit verschillende niveaus informatie samengesteld kan worden. Via Microsoft Analysis Services8 worden vanuit de kubussen overzichten, analyses en het gebruik van vele invalshoeken samengesteld. Groeperen en filteren van gegevens wordt hier eenvoudig gedaan en berekeningen worden direct doorgevoerd en met de gekozen tools kunnen de gegevens op gedetailleerd niveau bekeken worden. Dergelijke tools die hiervoor gebruikt worden zijn: Excel, Cognos, ProClarity en Business Intelligence Portal. In elk boek en artikel dat ingaat op gegevensmodellering voor een datawarehouse wordt dan ook gesteld dat gegevens in het datawarehouse moeten worden gemodelleerd volgens een ster-schema. Een ster-schema zou de volgende voordelen op moeten leveren:

8

•

de structuur kan multidimensioneel worden gepresenteerd wat voor de eindgebruiker makkelijk te begrijpen is en waar de eindgebruiker makkelijker mee kan werken dan met een volledig genormaliseerde structuur;

•

hiërarchieën kunnen gemakkelijk worden gedefinieerd, waardoor eenvoudig op gegevens kan worden ingezoomd naar een lager niveau;

Microsoft Analysis Services is een onderdeel van Microsoft SQL Server. Dit zorgt voor een uniforme en geïntegreerde view voor alle “business data” die gebaseerd is op traditionele rapportering OLAP analyses, scorecards van Key Performance Indicators en datamining.

16

•

de hoogst mogelijke performance kan worden geboden bij het beantwoorden van analytische vraagstukken. Dit is mogelijk doordat: de afgeleide gegevens en aggregatieniveaus9 vooraf kunnen worden berekend en worden opgeslagen. En er hoeven zo weinig mogelijk tabellen samengevoegd te worden

4.3

Ster-schema

Er zal eerst worden beschreven wat een ‘ster-schema’ inhoudt en hoe het wordt opgesteld. Bij het opstellen van een gegevensstructuur ter ondersteuning van organisatorische vraagstukken wordt uitgegaan van een andere informatiebehoefte dan die op operationeel niveau. Bij een vraag die wordt gesteld op operationeel niveau zijn relatief weinig gegevens uit slechts één of misschien enkele informatiesystemen betrokken. Het antwoord op een vraag op operationeel niveau is vaak een getal of een kleine tabel. Bij een vraag op strategisch niveau zijn relatief veel (operationele) gegevens betrokken uit (zo mogelijk) alle informatiesystemen. Een antwoord op strategisch niveau is vaak geen getal, maar een overzicht van een aantal getallen, waarbij gegevens met elkaar vergeleken moeten kunnen worden. Een voorbeeld van een vraag op strategisch of tactisch niveau is: ”Wat is de omzet van zorginstelling X per productgroep per kwartaal?” Als blijkt dat hier een bepaalde productgroep uitspringt, zal de zorginstelling op die omzet in willen zoomen. Het antwoord op een vraag van de organisatie van de zorginstelling zou dan ook zo snel mogelijk gegeven moeten kunnen worden. Als deze informatiebehoefte multidimensioneel moet worden gemodelleerd, zal er allereerst onderscheid gemaakt moeten worden tussen feiten en dimensies. De feiten zijn die gegevens waar de zorginstelling in is geïnteresseerd (omzet, winst). Deze numerieke gegevens worden opgeslagen in de feitentabel. De dimensies zijn die elementen in de vraag waarvoor ‘per’ staat (per product, per locatie, per tijdseenheid). Als de informatie in tabelvorm wordt gepresenteerd, dan komen de getallen in de tabel dus uit de feitentabel en komen de tabelkoppen uit de dimensietabellen. In de definitie van het datawarehouse staat dat de gegevens in een datawarehouse onderwerpgeoriënteerd gemodelleerd moeten worden. ‘Onderwerp’ is in die context de verzamelnaam voor feiten en dimensies. Als deze feiten en dimensies rechtstreeks in een gegevensstructuur worden gezet, ontstaat er een ster-schema:

9

Het samenvoegen van meerdere objecten tot een object. Het samenvoegen gebeurt middels operaties.

17

Figuur 5. Eenvoudige Sterschema In het midden staat de feitentabel: de tabel met de gewenste feiten. Daarop zijn drie dimensies gezet. Deze dimensies zijn aan de feitentabel gekoppeld met een automatisch gegenereerde, numerieke sleutel. Met andere woorden wordt deze sleutel gebruikt om een relatie tussen de feitentabel en dimensietabel te leggen. Voordelen: de sleutel beveiligt het CS-datawarehouse en CS-EZIS tegen veranderingen in de bronsysteem, maakt integratie mogelijk van data uit meerdere bronnen (als deze bijvoorbeeld verschillende sleutels gebruiken), en een nummeriek (integer) als datawarehouse key zorgt voor een hogere performance in analysis services. Op die manier kan de kostprijs bijvoorbeeld worden herleid naar een bepaalde plaats, een bepaalde patiënt en een bepaald kwartaal. Binnen de dimensies zijn hiërarchieën te definiëren: - Locatiedimensie: Zorginstelling; Plaats; Provincie; Land - Patiëntdimensie: Naam; Geslacht; Geboortedatum; Woonplaats; Postcode - Datumdimensie: Dag; Week; Maand; Kwartaal; Jaar Niet alleen iedere zorginstelling heeft een eigen sleutel, maar ook iedere Plaats en iedere Provincie op zich. Op die manier kan de kostprijs voor een kwartaal in de feitentabel worden opgeslagen, zodat op het moment dat de omzet van een bepaald kwartaal wordt opgevraagd, niet de kostprijs van de maanden in het desbetreffende kwartaal opgeteld hoeft te worden.

18

4.4

Huidige CS-Datawarehouse verversing

Voordat de gegevens in het datawarehouse terecht komen ondergaan ze een proces. Dit proces is genaamd het ETL proces. ETL staat voor Extraheren, Transformeren en Laden. Het eerste deel van het ETL proces is om de data uit de bronsystemen te halen in dit geval uit de EZIS database. Dit proces is te zien in figuur 9. De extractie is voor een groot deel een kopie van de EZIS database naar het CS-datawarehouse ook wel ‘staging’ genoemd. Het tweede deel betreft het transformeren of omvormen van de geëxtraheerde data die ‘ge-staged’ zijn. Bij transformatie kan er gedacht worden aan: alleen sommige kolommen selecteren, gecodeerde waarden vertalen, verschillende rijen samenvatten naar een rij. Het derde deel betreft het laden van de getransformeerde data in de datawarehouse tabellen. Het laden kan op verschillende manieren geschieden. Het ETL proces wordt uitgevoerd door de logica laag van het Ezis ipv een servers-sided volledig op Microsoft SQL server gebaseerd ETL proces. Een Microsoft SQL server gebaseerd ETL proces verloopt sneller, maar vergt meer programmeerwerk met kans op fouten. ChipSoft kiest voor kwaliteit door ETL via het CS-EZIS te doen en wenst het verlies aan snelheid te compenseren door op een andere manier weer tijdwinst maken. Het laden kan afhankelijk zijn van een gewenste tijd of datum. Bij ChipSoft wordt de extractie, transformatie en lading vanuit de EZIS database als één geheel verversingsproces gedaan. Het ETL proces dat de extractie en bewerking van data realiseert voor de CS-EZIS bronnen binnen het CS-EZIS, is uitgeprogrammeerd en beschikbaar voor de datawarehouse extractie. Dit ETL proces is beschikbaar in de module CS-Datawarehouse inclusief CS-Overzichtsgenerator. Hierbij wordt dezelfde logicalaag van het CS-EZIS voor de ETL gebruikt, die ook wordt gebruikt voor de eindgebruikers-functionaliteiten van het CSEZIS. De huidige ETL opzet is dat iedere nacht het volledige datawarehouse opnieuw wordt ververst. Hiertoe worden iedere nacht alle datawarehouse tabellen en OLAP-Kubussen10 volledig opnieuw opgebouwd. Momenteel worden dus de oude gegevens compleet overschreven, waardoor de mutaties heel lastig of niet beschikbaar gesteld kunnen worden voor rapportage.

4.5

Huidige CS-Datawarehouse obstakels

Het datawarehouse van ChipSoft behoort tot het traditionele datawarehouse, omdat het gewoon weg niet de gegevens/data van vandaag bevat. De verversing vindt ‘s nachts plaats. Tijdens de verversing van het CS-Datawarehouse worden alle datawarehouse tabellen en OLAP-Kubussen volledig opnieuw opgebouwd. De oude gegevens worden compleet overschreven. De mutaties in het CS-Datawarehouse worden op deze manier niet bijgehouden. Het streven is om de datawarehouse tabellen in te richten voor het kunnen

10

On-line analytical processing is een database technologie die speciaal is ontwikkeld voor ad hoc (on-line) analyses met diverse mogelijkheden.

19

bijhouden van historische gegevens waarbij er een minimale impact op de huidige CSDatawarehouse tabellenstructuur plaats vindt. De tijd die het huidige verversingsproces in beslag neemt kan gereduceerd worden door in plaats van alle data, alleen de gewijzigde data te laden. De verzameling van gewijzigde of gemuteerde data wordt incrementele data genoemd. Alle data is een set van records die ook data bevatten die helemaal niet aangepast zijn gecombineerd met records die wel een aanpassing zijn ondergaan of nieuw zijn.

Oude records(voor de verversing)

Alle records(alle data, nieuwe stand)

SecID

Attribuut

Prijs

SecID

Attribuut

Prijs

Wijziging

1

A

€100

1

A

€100

Geen

2

B

€110

2

C

€110

Gewijzigd

3

A

€200

3

A

€200

Geen

4

A

€110

5

D

€210

Nieuw

Figuur 6. oude records

Figuur 7. nieuwe stand van records

Records met SecID ‘1’ en ‘3’ zijn niet aangepast maar komen toch voor tussen de records die de oude stand zou moeten vervangen. SecID

Attribuut

Prijs

Wijziging

2

B

€110

Gewijzigd

4

A

€110

Verwijderd

5

D

€210

Nieuw

Figuur 8. nieuwe stand van records Incrementele data is een set van records waarvan minimaal één aanpassing aan de data is aangebracht of totaal nieuw of verwijderd is. Dit is te zien in figuur 8. Het is belangrijk om als eerste de incrementele data vast te leggen. De vragen die hierbij naar voren komen zijn: •

“Welke techniek kan incrementele data vastleggen?
Hoe kan dit het beste worden gedaan?”

•

“Tijdens welk proces moeten de incrementele data bepaald worden? ”

Vervolgens als de incrementele data zijn vastgelegd: •

“Op welke manier moeten de CS-Datawarehouse tabellen ingericht worden voor een efficiënte verversing?” 20

•

“Op welke manier moeten de CS-Datawarehouse tabellen ingericht worden zodat er over de historische data gerapporteerd kan worden?”

En als laatste wanneer de incrementele data vastgelegd kunnen worden en de CSDatawarehouse tabellen zijn ingericht: •

“Op welke manier moeten de incrementele data geëxtraheerd, getransformeerd en geladen worden?”

4.6

CS-Dataflow in een notendop

In de bronsystemen, beter gezegd de EZIS database, vinden er transacties plaats. Een transactie is een handeling die door middel van een opdracht een wijziging/mutatie van een record tot stand brengt. Van hieruit wordt het ETL proces gestart. De ruwe transactie data worden geëxtraheerd/gekopieerd naar de staging area
staging tabellen. De staging tabellen worden opgeslagen in de CS-Datawarehouse database. De tweede stap heet transformeren. Tijdens dit proces worden bijvoorbeeld “Verrichtingen” gekoppeld aan “DBC’s”11 en records worden aangevuld op basis van of er meerdere velden gevuld zijn. In het algemeen worden hier de data geschoond, gemanipuleerd, gecontroleerd op dubbele, foutieve, etc. records. Maar via de logicalaag worden de verbanden tussen brontabellen aangesproken en uitgeprogrammeerde berekeningen toegepast. De controle op foutieve en dubbele records worden al uitgevoerd bij de invoer in het CS-EZIS of het wordt in het CS-datawarehouse met de onbekend waarden inzichtelijk gemaakt. In de logicalaag is het dus eenvoudig de objectstructuur van het CS-EZIS te betrekken binnen het ETL proces. De laatste stap betreft het laden van de getransformeerde data in de datawarehouse tabellen. Er moet bij deze stap goed nagedacht worden over de inrichting van het laadproces. De structuur van de productie database en de CS-Datawarehouse database verschillen. Het is dus cruciaal dat de gegevens die worden ververst in het CS-datawarehouse correct komen te staan. Een datawarehouse is nutteloos als de datakwaliteit ervan niet goed is. Bij deze stap moet goed in kaart worden gebracht hoe de gegevens het efficiëntst incrementeel geladen kunnen worden. De informatie in het CS-Datawarehouse wordt vervolgens verspreid naar kubussen en datamarts12.

11

Diagnose Behandeling Combinatie - Een DBC typeert het geheel van activiteiten (behandelcontacten, verpleegdagen e.d.) van de instelling en de (medisch) specialist voortvloeiend uit de zorgvraag van de patiënt/cliënt.

12

Een datamart bevat een specifiek gedeelte van de totale gegevens uit een datawarehouse. Een datawarehouse bestaat uit datamarts.

21

De stappen die plaatsvinden binnen het CS-datawarehouse proces staan in figuur 9 geïllustreerd.

22

Figuur 9. CS-Dataflow Datawarehouse

Volgorde verversing van het CS-Datawarehouse model Er is een volgorde aanwezig bij het verversingsproces in het CS-Datawarehouse. Deze volgorde is van groot belang vanwege de afhankelijkheid van de verschillende modellen in het CS-Datawarehouse. Met afhankelijkheid wordt hier bedoeld dat de gegevens van de modellen afhankelijk zijn van andere gegevensmodellen die uiteindelijk aan elkaar gekoppeld zijn. De volgorde tijdens het verversingsproces van de overzichten zijn: •

De volgorde van de instelling Datawarehouse\Modellen\Algemeen\Modellen wordt aangehouden

•

Binnen een model worden de overzichten uitgevoerd per overzichtstatus (CSDatawarehouse / CSDW Dimensie / CSDW Feiten)

•

Binnen de statussen wordt alfabetische volgorde gevolgd

Bij de verversing zijn er een aantal processen(functionaliteit) die plaats vinden, met name: 1. Datum en Tijd dimensies worden aangemaakt 2. Tabellen worden gekopieerd 3. DWH overzichten worden gegenereerd 4. Kubussen verversen

24

5. Het onderzoek 5.1

Gegevens verzamelen

ETL(Extraheren, transformeren en laden). Het laden (verversen van gegevens) is een heel belangrijk proces. De bruikbaarheid van de gegevens en geaggregeerde13 brongegevens worden hier bepaald. Het laden van de data gebeurt in de vorm van het aanbieden van de gegevens aan de datamarts in gegevens op presentatielaag. Om de efficiëntie van de verversing te behouden dient rekening gehouden te worden met: •

Applicatie-eisen (versheid van gegevens, nauwkeurigheid van gegevens, berekentijd van queries)

•

Bronbeperkingen (beschikbaarheid, aantal veranderingen)

•

Datawarehouse systeembeperkingen (Opslagruimte)

5.2

Wanneer en hoe dient de verversing in het datawarehouse te gebeuren?

Het hoe deel bestaat uit een keuze uit diverse mogelijkheden, zoals: •

Incrementeel verversen – Tijdens het verversingsproces van het datawarehouse worden alleen de gewijzigde data geextraheerd, getransformeerd en geladen in het datawarehouse vanuit de bron database.

•

Real-time verversen – De verversing van het datawarehouse geschiedt vrijwel direct. Met andere woorden; het datawarehouse is tot op de minuut up to date.

•

Volledig verversen – De data in het datawarehouse worden volledig overschreven.

•

On-line – De verversing van het datawarehouse vindt plaats terwijl het datawarehouse toegankelijk is.

•

Off-line – De verversing van het datawarehouse vindt plaats en het datawarehouse is niet toegankelijk.

De huidige situatie is dat er volledig wordt ververst. Deze verversing vindt ’s nachts plaats buiten kantooruren. Er wordt op dat moment geen gebruik gemaakt van het datawarehouse door de klanten van ChipSoft. Met andere woorden dit proces kan gelijkgesteld worden aan een off-line verversing. De voorkeur gaat uit naar incrementele verversing en dit wordt verder onderzocht in het vervolg van dit document. 13

Aggregaat - Gegevens die zijn omgezet in één enkele waarde door middel van bijv. gemiddelde, maximum, minimum, opsomming etc.

25

Het wanneer heeft betrekking op het tijdstip waarop een view ververst dient te worden. Omdat de gegevens in het datawarehouse één dag oud zullen blijven, betekent dat de tijd waarop de verversing plaats vindt, ’s nachts kan blijven gebeuren. De gegevens die dan gepresenteerd zullen worden blijven dezelfde bruikbare waarde behouden als daarvoor.

5.3

Incrementeel laden

Het laden van data vanuit een databron naar een SQL server is de normale gang van zaken. Maar de data die wordt geëxtraheerd vanuit de bron naar de stage area, is niet voor Business Intelligence doeleinden bedoeld. De data wordt eerst naar de stage area geextraheerd, zodat de transformatie/bewerking niet op de EZIS database hoeft plaats te vinden. De reden hiervoor is dat de EZIS database niet onnodig belast wordt. Business intelligence is gericht op het verzamelen en analyseren van informatie over klanten, beslissingsprocessen, concurrentie om beslissingsondersteunende informatie (intelligence) te verkrijgen. Het kan omschreven worden als het proces om gegevens om te zetten in informatie, die vervolgens leidt tot kennis. De EZIS logica is minder efficiёnt, maar betrouwbaarder. En om bij gebruik van de EZIS logica de verversing van het CS-datawarehouse efficiёnter te maken, dient de hoeveelheid data bij verversing verminderd te worden. Incrementeel laden is dus de oplossing hiervoor. Incrementeel laden is sneller en gebruikt minder “server resources”. Alleen nieuwe en gewijzigde data wordt gebruikt bij incrementeel verversing.

Randvoorwaarden incrementeel verversen •

Incrementeel laden wordt gebruikt wanneer data vanuit een data bron naar een SQL server wordt geladen.

•

Het incrementeel laden wordt op dezelfde wijze gedaan ongeacht welk database platform of ETL tool er gebruikt wordt. Nieuwe en gewijzigde rijen dienen herkend te worden en vervolgens gescheiden te worden van de niet gewijzigde rijen.

Checklist realisatie incrementeel verversen Bij incrementele verversing dient er rekening gehouden te worden met een aantal factoren, namelijk; -

Nieuwe gegevens

26

Om nieuwe gegevens op de server (EZIS database) te achterhalen moet er van ieder gegeven/record bekend zijn wanneer het is aangemaakt. Een goede manier hiervoor is voor iedere record een DatumTijd-kolom te realiseren die aangeeft wanneer het is aangemaakt. -

Gewijzigde gegevens Het is hier van belang om wijzigingen te kunnen achterhalen. Dit kan gedaan worden door bij iedere record ook de DatumTijd van de mutaties vast te leggen.

-

Verwijderde gegevens Van verwijderde gegevens is het niet mogelijk om een datum bij deze records op te slaan. Omdat deze records immers al verwijderd zijn. Hiervoor moet er voor de verwijderde records kunnen worden vastgelegd tot wanneer ze geldig zijn door middel van een VerwijderDatumTijd-kolom.

-

Wanneer Laatste tijdstip van verversing is van belang zodat het systeem(CS-EZIS) weet vanaf wanneer de wijzigingen opgehaald dienen te worden.

-

Triggers De triggers dienen aanmaak DatumTijd en mutatie DatumTijd bij te werken zodat de tabel die de verwijderde gegevens bijhoudt, gevuld wordt.

5.4

SQL Server 2008

Er is een MUTDATUM veld voor de tabellen dat alleen aangestuurd wordt door de CS-EZIS software. Met andere woorden alleen als er via het CS-EZIS transacties worden uitgevoerd, wordt het MUTDATUM veld automatisch gevuld met de datum van de transactie. Dit veld wordt niet automatisch gevuld wanneer er direct op de CS-EZIS database buitenom de CSEZIS software, transacties worden uitgevoerd. De transacties die buiten de EZIS software plaats vinden worden door bijvoorbeeld een ChipSoft consultant uitgevoerd door middel van queries. De consultant maakt hiervan gebruik om verschillende redenen: - Op verzoek van de klant. Als de klant bijvoorbeeld een aantal gegevens gewijzigd wil hebben in haar database die niet aan te passen zijn via het CS-EZIS. Hierbij kan er gedacht worden aan bepaalde velden in de EZIS database die niet aangepast kunnen worden door het CS-EZIS. DBC’s die zijn aangeleverd hebben een aanleverdatum. Het is bij deze DBC’s die zijn aangeleverd niet meer mogelijk wijzigingen via het CS-EZIS aan te brengen. Als er iets gewijzigd dient te worden in een aangeleverde DBC zoals een ontbrekende aanvulling in de diagnose van de DBC. Dan dient de aanleverdatum van de desbetreffende DBC leeggehaald te worden via de EZIS database om achteraf toch die wijziging door te kunnen voeren via het CS-EZIS.

27

-

Ook gemakshalve voor het opzoeken en wijzigen van gewenste data in de EZIS database van de klant. Het is namelijk een efficiëntere methode om de records op te zoeken die gewijzigd dienen te worden.

Dus nogmaals: Bij het uitvoeren van queries rechtstreeks op de EZIS database wordt het veld MUTDATUM dat normaliter automatisch aangestuurd wordt door het CS-EZIS niet of met een mogelijke incorrecte datumwaarde gevuld. Het MUTDATUM veld is hierdoor onbetrouwbaar. Als er een extractie van records op basis van een bepaalde mutatiedatum wordt gedaan, is de kans groot dat er een aantal records niet meegenomen worden of juist onterecht worden meegenomen vanwege een incorrecte waarde of lege waarde in het MUTDATUM veld. Om ervoor te zorgen dat de records altijd voorzien zijn van een geldige mutatiedatum wordt er gebruik gemaakt van de nieuwe functionaliteiten die SQL Server 2008 biedt. SQL Server 2008 biedt een oplossing die op databaseniveau alle transacties die worden uitgevoerd bijhoudt. Dit wordt in de volgende paragraaf beschreven. SQL 2008 biedt een aantal eigenschappen die de verversing aanzienlijk kunnen verbeteren in snelheid. Het opvragen van de laatst gebruikte timestamp14 en rowversion15 is aangepast, zodat het voorzien van een mutatiedatum voor de records correct kan verlopen. Een nieuwe eigenschap die SQL 2008 bevat is “Change Data Capture” (CDC). Het aanzetten van “Change Data Capture” op de database en vervolgens op een tabel zorgt ervoor dat alle transacties inclusief inhoud die plaatsvinden in de tabellen waar CDC aan staat in de database worden bijgehouden. De nieuwe functies worden aangeroepen door: - cdc.fn_cdc_get_all_changes_dbo_Tabelnaam. Dit zijn alle transacties die hebben plaatsgevonden ook binnen een dag. - cdc.fn_cdc_get_net_changes_dbo_Tabelnaam. Dit zijn alleen de laatste transacties op dag basis. Het is de bedoeling door middel van deze techniek de gewijzigde records vast te leggen. Het wordt duidelijk dat door middel van CDC wijzigingen eenvoudiger en efficiënter op database niveau door de database zelf worden bijgehouden. In figuur 12 is dit te zien. Hierna wordt er een concept ontwikkeld hoe de gewijzigde data in de feitentabel(len) en dimensies het snelst en het meest praktisch kunnen worden geladen. Verder bevat SQL 2008 “Change Tracking”. Bij het aanzetten van deze functie, houdt SQL Server 2008 alleen bij dat er wijzigingen hebben plaatsgevonden. Deze wijzigingen zijn eenvoudig op te vragen zonder dat er zelf DatumTijd velden of wijzigingstabellen aangemaakt en beheerd dienen te worden. De 14

Timestamp is een opeenvolging van karakters, die de datum en/of de tijd aanduiden waarop een bepaalde gebeurtenis voorkwam.

15

Is een gegevenstype dat automatisch een uniek binair formaat genereert. Rowversion wordt over het algemeen gebruikt als mechanisme die de rijen binnen een tabel uniek maken.

28

performance van deze functie is te vergelijken met de performance van een tabel die een tweede index16 bevat. De verversing is hierdoor krachtiger geworden.

Data wordt gewijzigd/ingevoerd in de bron (EZIS)

Data wordt weggeschreven naar transactie Log

Capture proces leest transactie log en schrijft de data inclusief metadata naar change tables

Gewijzigde data wordt gequeried voor ETL doeleinden Figuur 10. Change data capture proces Het belangrijkste voordeel is misschien wel dat de tabellen niet aangepast hoeven te worden. Het is daarom interessant voor een Database Administrator om deze techniek in gebruik te nemen. Er kan bij databases die niet in eigen beheer zijn nu wel verversing toegepast worden. Kort samengevat is het mogelijk door middel van de bovengenoemde functies van SQL Server 2008 de wijzigingen op database niveau bij te houden. De vastlegging van de gewijzigde gegevens worden door middel van de nieuwe “stored procedures”17 in SQL Server 2008 gedaan. De ingevoerde, gewijzigde en verwijderde records worden voorzien van een mutatiedatum en een type transactie. Het type transactie geeft aan of de gemuteerde records nieuw, gewijzigd of verwijderd zijn. Het is nu mogelijk door de change data capture functie, de laatste gemuteerde records op dagbasis op te vragen. Deze gemuteerde records zijn gereed om geladen te worden in de staging area in het CS-Datawarehouse. Omdat SQL server 2008 momenteel niet officieel in gebruik is voor de CS-EZIS database, worden gemuteerde data gegenereerd. In dit onderzoek wordt met deze gemuteerde data gewerkt die als vervangende uitkomst dient van wat de change data capture functie produceert. In hoofdstuk zes wordt

16

Een index in een database is een (deel)bestand waarin een tabel op volgorde van een aangegeven kolom (of meerdere kolommen) is gesorteerd. Het doel van een dergelijke index is de zoeksnelheid te vergroten.

17

Stored procedures – zijn vooraf geprogrammeerde en gecompileerde database queries die de veiligheid, efficiëntie en bruikbaarheid van database client/server applicaties verbeteren.

29

dieper ingegaan op hoe vanuit dit punt de incrementele verversing van de feitentabellen moet geschieden.

30

6. Ontwerp Datawarehouse 6.1

Ontwerp incrementele verversing inclusief opslag historische records in de feitentabel

De gemuteerde records worden door SQL Server 2008 verzameld en voorzien van een mutatiedatum en type mutatie. Het incrementeel laden in combinatie met het bijhouden van historische records tijdens dit onderzoek beperkt zich tot: de verversing vanuit de mutatietabel naar de feitentabel. De naamgeving van de tabellen in het CS-datawarehouse bestaat uit drie kenmerken. De feitentabel van het verrichtingen model genaamd VerFeiVerrichtingen bestaat uit: •

Ver - Geeft aan welk model het betreft. Het betreft hier het verrichtingen model.

•

Fei - Geeft aan of het een feitentabel of dimensie tabel is. Het betreft hier een feitentabel.

•

Verrichtingen - Geeft het feitentype aan binnen het model. Feiten over de verrichtingen.

Deze naamgeving wordt aangehouden en ook toegepast op de mutatietabellen binnen het CSdatawarehouse. De mutatietabel voor het verrichtingen model wordt gedefinieerd als volgt: VerMutVerrichtingen •

Ver - Betreft het verrichtingen model

•

Mut - Geeft aan dat het gaat om de mutatietabel

•

Verrichtingen - Geeft aan dat het de mutaties van verrichtingen betreft.

Het is van belang dat de naamgeving goed gedefinieerd staat, zodat tijdens de verversing de link tussen mutatietabel en feitentabel in alle modellen gemaakt en herkend kan worden. In dit geval de incrementele lading van VerMutVerrichtingen naar VerFeiVerrichtingen.

Mutatietabel De mutatietabel bevat dezelfde structuur als de feitentabel. De mutatietabel wordt gegenereerd en geladen door een mutatieoverzicht in de overzichtgenerator. Dit mutatieoverzicht is gelijk aan het huidig overzicht van de feitentabel met het verschil dat het mutatieoverzicht alleen een overzicht van gemuteerde records in de mutatietabel laadt. Voordat de mutatietabel voorzien kan worden van gemuteerde records, is het belangrijk dat de dimensietabellen eerst ververst zijn. Hoe de dimensies ingericht moeten worden en van welke type dimensie er sprake is, wordt in bijlage C Slowly Changing Dimensions behandeld. De 31

mutatietabel wordt gegenereerd en voorzien van datawarehouse keys van de dimensies die bij de feiten van de feitentabel horen. Een datawarehouse key is een uniek identificerend numeriek veld in de datawarehouse tabellen. Door middel van dit veld worden de records van de feitentabel verbonden met de bijbehorende records van de dimensietabellen. Als de mutatietabel volledig met de gemuteerde records geladen is, kan de feitentabel pas bewerkt en geladen worden. De mutatietabel bevat twee extra velden namelijk: MutatieDatum_KEY (int) NOT NULL. Dit veld mag niet leeg zijn en dit veld indiceert de datum van de gemuteerde records. Dit veld bevat een waarde van het type integer18. De

•

datum wordt geconverteerd naar deze waarde. Het type integer is sneller en eenvoudiger op te vragen dan een veld met type datetime19. Type_Mut (int) NOT NULL. Dit veld geeft aan wat voor mutatie het desbetreffende record is ondergaan. Dit veld bevat de waardes: ‘1’ = verwijderd record, ‘2’ = nieuw record of ‘4’ = gewijzigd record. ‘3’ komt niet als waarde voor in de Mutatietabel, omdat waarde ‘3’ de records voor de wijziging betreffen. Alleen de daadwerkelijke gewijzigde records zijn van belang. Deze extra velden zijn nodig om de geldigheid, status en type transactie van de records in de feitentabel tijdens en na de lading vanuit de mutatietabel naar de feitentabel te kunnen definiëren. •

Mutatietabel (VerMutVerrichtingen) VerrichtingSecID Attribuut 1 A

Prijs €100

MutatieDatum_KEY 20090701

Type_Mut 4

2

B

€110

20090701

4

4

E

€300

20090702

2

2

A

€110

20090702

1

Figuur 11. Voorbeeld mutatietabel met MutatieDatum_KEY- en Type_Mut veld In figuur 11 is een voorbeeld mutatietabel (VerMutVerrichtingen) weergegeven. In deze tabel is te zien dat er meerdere records met dezelfde VerrichtingSecID (primary key) voorkomen. De reden hiervoor is dat het datawarehouse om een of andere reden niet ververst is gedurende deze dagen. De redenen kunnen zijn:

18 19

•

Er is een fout opgetreden tijdens het verversingsproces van het datawarehouse. Het datawarehouse raakt nog verder “out of date”. Het kan tot meerdere dagen oplopen.

•

De klant heeft besloten om de datawarehouse verversing handmatig uit te zetten vanwege veiligheidsoverwegingen tijdens bijvoorbeeld het factureren etc.

Integers zijn de analogie of representatie van de gehele getallen voor gebruik op een computer. Datetime is van het type datum en tijd. Deze waarde wordt berekend in datum en tijd formaat .

32

De voormalige primary key is niet meer primair. Het toevoegen van de “MutatieDatum_KEY” aan de voormalige primary key maakt de records wederom uniek.

Feitentabel De feitentabel moet ook voldoen aan een bepaalde structuur als het wenselijk is om te kunnen rapporteren over historische gegevens, het type mutatie en de actualiteit van feiten van of gedurende een bepaalde tijd. Om dit mogelijk te maken worden vier kolommen in de feitentabel toegevoegd. Zoals bij de mutatietabel is het een vereiste dat de feitentabel voor de rest dezelfde velden bevat als die van de mutatietabel. De vier toegevoegde kolommen zijn: •

MutatieDatumVan_KEY (int) NOT NULL. Dit veld geeft aan vanaf wanneer het record geldig is. Dit veld mag niet leeg zijn en is ook van het type integer.

•

MutatieDatumTot_KEY (int) NOT NULL. Dit veld geeft aan tot wanneer het record geldig is. Dit veld mag niet leeg zijn en is ook van het type integer.

•

Type_Mut (int) NOT NULL. Dit veld bevat andere waardes dan bij de mutatietabel. Omdat de verwijderde records in de feitentabel alleen worden aangepast, is het niet meer af te leiden wat de type mutatie is geweest voordat deze records verwijderd waren. Door middel van onderstaande omschrijving voor de Type_Mut is het wel mogelijk. ‘101’ = nieuw record, ‘102’ = gewijzigd record, ‘103’ = type mutatie van het record was nieuw en is nu verwijderd ‘104’ = type mutatie van het record was gewijzigd en is nu verwijderd De waarde ‘3’ komt niet voor in de mutatietabel omdat deze waarde van oorsprong

•

Act (int) NOT NULL of true/false: Dit veld mag niet leeg zijn en kent alleen de waardes: ‘0’ = niet actueel of vervallen en ‘1’ = actueel of geldig. Een record dat een: o geldige ‘MutatiedatumTot_key’ waarde heeft, is niet meer geldig; o oneindige ‘MutatiedatumTot_key’ waarde heeft, is geldig. Zie figuur veertien.

Feitentabel (VerFeiVerrichtingen) VerrichtingSecID

Attribuut Prijs

1

A

2

€50

MutatieDatum Van_KEY 20090629

MutatieDatum Type_Mut Act Tot_KEY 20090630 2 0

D

€110

20090629

20090630

2

0

1

A

€70

20090630

99991231

4

1

2

C

€110

20090630

99991231

4

1

3

A

€500

20090629

20090630

1

0 33

Figuur 12. Voorbeeld feitentabel met MutatieDatumVan_KEY-, MutatieDatumTot_KEY-, Type_Mut- en Act veld. Doordat de geldigheid van de records in de feitentabel bekend is, is de actuele stand van de records op te vragen gedurende een willekeurige tijd in het verleden. Het Type_Mut veld maakt het mogelijk het soort transactie van de records af te leiden. Uit het Act veld is eenvoudig af te leiden welke records actueel of geldig zijn. Uit het MutatieDatumTot_KEY veld is ook af te leiden welke records actueel en niet actueel zijn. Er is sprake van redundantie die voordelen met zich meebrengt. Het opvragen van geldige- of vevallen records aan de hand van het ‘Act’ veld wordt sneller gerealiseerd dan het ‘MutatiedatumTot_key’ veld omdat: • Het ‘Act’ veld bestaat uit maar twee waardes van een klein numeriek formaat, ‘0’ of ‘1’ en ‘MutatieDatum_key’ veld bestaat uit een groter numeriek formaat. • Er zit een index op het ‘Act veld’. Wilt men bijvoorbeeld weten vanaf- en/of tot wanneer een record actueel of niet actueel is, moeten de MutatieDatumVan_KEY en MutatieDatumTot_KEY velden geraadpleegd worden. Deze velden hebben een geconverteerde waarde die afgeleid is van een datum. Het bepalen van actuele- en niet actuele records doormiddel van deze velden verloopt dus trager en minder eenvoudig dan bij het Act veld. Het eindresultaat van de verversing moet geschieden vanuit de mutatie tabel (VerMutVerrichtingen) naar de feitentabel (VerFeiVerrichtingen). De inhoud van de feitentabel wordt niet verwijderd. Alle records blijven bewaard. Alleen de geldigheid en actualiteit van de records worden aangepast bij het incrementeel laden zodat er rapportages over mutaties terug in de tijd gerapporteerd kunnen worden. In figuur 12, VerFeiVerrichtingen is af te leiden bij records die een MutatieDatumTot_KEY waarde hebben van “99991231” dat deze records actueel zijn. De waarde “99991231” geeft de datum: “9999-12-31” oftewel “31 december 9999” aan. De andere data geven aan tot wanneer de records geldig zijn. De mutatietabel wordt gevuld door middel van een overzicht in de overzichtgenerator door de consultant. Hoe dit overzicht door de optie ‘incrementeel laden’ aangestuurd wordt, wordt verder in hoofdstuk zeven uitgelegd.

6.2

Feitentabel incrementeel laden

De inrichting van de mutatietabel en feitentabel zijn gedefinieerd. Het incrementeel laden van de feitentabel kan gestart worden.

34

VerrichtingSecID

Attribuut Prijs

MutatieDatum Van_KEY

MutatieDatum Type_Mut Act Tot_KEY

1

A

€50

20090629

20090630

2

0

2

D

€110

20090629

20090630

2

0

1

A

€70

20090630

20090701

4

0

2

C

€110

20090630

20090701

4

0

3

A

€500

20090629

20090630

1

0

1

A

€100

20090701

99991231

4

1

2

B

€110

20090701

99991231

4

1

4

E

€300

20090702

99991231

2

1

Figuur 13. feitentabel na incrementeel laden De velden die rood gemarkeerd zijn, zijn aangepast zodat de geldigheid en oude stand van de records af te leiden is. De ‘VerrichtingSecID’s’ die geel gemarkeerd zijn, zijn fysiek nieuwe records die toegevoegd zijn aan de feitentabel. Dat de records fysiek nieuw zijn is af te leiden van de ‘MutatieDatumVan_key’-, ‘MutatieDatumTot_key’ of ‘Act’ velden. Deze nieuwe records zijn tevens ook de geldige records nadat de datawarehouse verversing succesvol heeft plaatsgevonden.

35

7. Uitwerking ‘Incrementeel laden’ Het incrementeel laden vanuit de mutatietabel naar de feitentabel wordt gedaan door middel van SQL scripts. De SQL scripts bewerkstelligen: •

Een selectie van de records met de minimale mutatiedatum binnen de mutatietabel.

•

De records met een gewijzigde status in de mutatietabel worden vergeleken met records die overeenkomen in de feitentabel. De overeengekomen records in de feitentabel krijgen een vervallen datum en een niet actuele status.

•

Vervolgens krijgen de records die verwijderd zijn in de feitentabel ook een vervallen datum en een niet actuele status. De verwijderde records worden net als bij de gewijzigde records ook eerst met elkaar vergeleken voordat dit tot stand gebracht kan worden.

•

Uiteindelijk worden alle nieuwe en gewijzigde records toegevoegd aan de feitentabel waarvan de geldigheid op oneindig wordt gezet.

Bovenstaande stappen zijn uitgeprogrammeerd in de CS-EZIS software. Het incrementeel laden van de feitentabel geschiedt door middel van de extra optie ‘Incrementeel laden’. Er is rekening gehouden met de software tijdens het programmeren zodat ‘Incrementeel laden’ toepasbaar is op alle modellen binnen het CS-datawarehouse.

7.1

Werking van de optie ‘Incrementeel laden’

Bij het maken van een overzicht dat de feitentabel incrementeel laadt, wordt er aandacht vereist bij de volgende punten: • In het overzicht wordt de naam ingevuld van de feitentabel die uiteindelijk incrementeel wordt geladen. In figuur zestien is te zien dat de naam van de feitentabel in het veld met de naam ‘Tabel’ wordt gedefinieerd. Maar in feite wordt er in dit overzicht de mutatietabel ingericht.

36

Figuur 14. Definiëren naam feitentabel bij incrementeel laden Bij het selecteren van ‘Incrementeel laden’ worden de opties ‘Tabel leegmaken’ en ‘DWH key behouden’ uitgeschakeld: De optie ‘Tabel leegmaken’ zorgt ervoor dat de tabel die in het ‘Tabel’ veld staat gedefinieerd, leeggemaakt wordt. Het betreft hier de feitentabel en deze dient niet leeggemaakt te worden. De feitentabel moet blijven bestaan. De optie ‘DWH key behouden’ zorgt ervoor dat de datawarehouse key van de records in de feitentabel behouden blijft als dezelfde records ook in de mutatietabel voorkomen. Voor de mutatietabel wordt er geen datawarehouse key gegenereerd. Deze optie werkt daarom niet in combinatie met ‘Incrementeel laden’. • Om de records uniek te maken dient de mutatiedatum_key aan de voormalige primaire sleutel van de records toegevoegd te worden. In figuur zeventien is te zien dat dit bij het tabblad ID’s wordt gedaan. Bij het genereren van dit overzicht wordt het woord ‘Fei’ in VerFeiVerrichtingen vervangen met het woord ‘Mut’. De naam van de mutatietabel wordt VerMutVerrichtingen waarin de gewijzigde records worden gegenereerd. Als de mutatietabel succesvol is gegenereerd, wordt de feitentabel daarna direct incrementeel geladen en bewerkt met de gewijzigde records.

•

37

Figuur 15. Uniciteit van records in de mutatietabel De mutatietabel wordt vervolgens verwijderd. De feitentabel is nu incrementeel geladen en bevat historische records.

7.2

‘Trace’

Door middel van Microsoft SQL Server Profiler is het mogelijk een ‘trace’ uit te voeren. Een ‘trace’ stelt de eigenschappen van een proces (bijvoorbeel het genereren van een overzicht) dat op database niveau in de vorm van SQL scripts wordt uitgevoerd, vast. Een aantal van de eigenschappen die worden vastgesteld om een vergelijking te maken tussen de oude manier van laden en het incrementeel laden van VerFeiVerrichtingen zijn: - De duur van het proces - Aantal records die gelezen en geschreven worden van en naar de databases - CPU gebruik etc VerFeiVerrichtingen op de oude manier laden met een aantal van 7131224 records neemt een tijd van 22 minuten en 50 seconden in beslag. En het incrementeel laden van VerFeiVerrichtingen die 7131224 records bevat met een aantal van 152928 gemuteerde records neemt 1 minuut en 20 seconden in beslag. Zie figuur 16 voor een ‘trace’ overzicht van het incrementeel laden van VerFeiVerrichtingen.

38

Figuur 16. Overzicht ‘trace’ van het incrementeel laden van VerFeiVerrichtingen

39

Conclusie Door dit onderzoek kan vastgesteld worden dat het incrementeel laden van een feitentabel in combinatie met rapportages over mutaties terug in de tijd kunnen rapporteren mogelijk is. De mogelijkheid tot het kunnen rapporteren van rapportages over mutaties terug in de tijd wordt tot stand gebracht door de historie van de feitentabel bij te houden en beschikbaar te stellen voor rapportages. Het incrementeel laden is mogelijk gemaakt doordat het generiek is uitgeprogrammeerd in het CS-EZIS. Verder is de doorlooptijd bij het laden van de feitentabel op de huidige manier groter dan de doorlooptijd bij het incrementeel laden van de feitentabel die gepaard gaat met het behoud van de historische records. Dit wordt bevestigd door metingen die worden verricht op beide manieren aan de hand van een ‘trace’. Deze ‘trace’ wordt gestart op basis van het ‘proof of concept’; incrementeel laden. Deze doorlooptijden zijn gebaseerd op de resultaten uit de ‘trace-logs’ die uitgevoerd zijn op de feitentabel (VerFeiVerrichtingen). VerFeiVerrichtingen bevat 7131224 records. Bij het laden van VerFeiVerrichtingen zonder de optie ‘incrementeel laden’ is de doorlooptijd 22 minuten en 50 seconden. Als test is er ruim een aantal van 152928 gemuteerde records gebruikt om de incrementele verversing van VerFeiVerrichtingen te realiseren. De doorlooptijd bedraagt 1 minuut en 20 seconden. Hieruit is af te leiden dat het incrementeel laden van VerFeiVerrichtingen gebaseerd op een reёle set gemuteerde records 17 keer sneller is dan de huidige lading van VerFeiVerrichtingen. Echter moeten de volgende punten getest worden voordat het proof of concept in productie kan worden genomen: - of het incrementeel laden sneller en efficiёnt blijft ongeacht de groei van de feitentabel en/of de aantal gemuteerde records. - De buffer read op de server zoveel mogelijk na te bootsen als bij de klanten. Dit kan gedaan worden om de buffer read van de server op te schonen voordat het incrementeel laden gestart wordt.

40

Gebruikte Software & Tools CodeGear Delphi – programmeertaal CS-EZIS – Electronisch Zorg Informatie Systeem van ChipSoft EZIS database Microsoft SQL Management Studio Microsoft SQL server 2005 Microsoft SQL server 2008 Microsoft Visual Studio debugger SQL Server Profiler

41

Literatuur 1. Karien Verhagen, “Datawarehousing[Een inleiding]” 2. www.olapreport.com, “The OLAP report” 3. www.olap.com, “Your source to learn about OLAP” 4. Andreas Seufert University of Applied Science Ludwigshafen & Josef Schiefer Institute for Software Technology and Interactive Systems,“Enhanced Business Intelligence - Supporting Business Processes with Real-Time Business Analytics” 5. www.kimballgroup.com, •

“Dimensional Modeling”

•

“Fact Tables and Dimension Tables”

•

“The soul of datawarehouse part 1-3”

•

“Divide and Conquer”

•

“Two Powerful ideas”

•

“Design Constraints and Unavoidable Realities”

•

“An Engineer's View”

•

“TCO Starts With the End User”

6. Paul S. Randal, “Wijzigingen bijhouden in de database van uw onderneming” 7. Rick F. van der Lans, “Het SQL leerboek[5de herziene uitgave]” 8. http://vsteamsystemcentral.com, “Applied Business Intelligence - SSIS Design Pattern Incremental Loads.” 9. Ralph Kimball, “The datawarehouse lifecycle toolkit” 10. ChipSoft, “Migratie CS-Datawarehouse - Versie 4.10 FP” 11. Justin Langseth, Founder and CTO of Claraview: “Real-Time Data Warehousing: Challenges and Solutions” 12. Vincent Rainardi, “Building a Data Warehouse with examples in SQL Server”

42

Begrippenlijst in alfabetische volgorde  CS – ChipSoft  DBC – Diagnose Behandeling Combinatie  DWH – datawarehouse  ETL – Extraheren, Transformeren, Laden  EZIS – Elektronisch Zorg Informatie Systeem  Incrementeel verversen – gemuteerde data bijwerken  OLAP – On Line Analytical Processing  RDBMS – Relational database management system

43

Bijlage A De doorlooptijden van de overzichten met hun status op volgorde van CS-Datawarehouse Hieronder is een overzicht te zien van de doorlooptijden van de stappen tijdens de verversing van het CS-Datawarehouse. Deze verversing heeft op dinsdag 20 mei 2009 plaatsgevonden. Per model zijn er overzichten die een status hebben. Aan de hand van de statussen is het vast te stellen tot welk deel in het verversingsproces deze overzichten behoren en hierdoor de doorlooptijden te berekenen zijn van de stappen in het verversingsproces van het CSDatawarehouse. Het is overzichtelijk welke stappen tijdens de verversing veel tijd in beslag nemen. Voor een duidelijkere beeldvorming waar de doorlooptijden van onderstaande processen thuis horen, is figuur 9 (CS-Dataflow Datawarehouse) een goede illustratie voor.

Staging/Transofrmatie (EZIS
Staging area) totale tijdsom van de status: Staging = 0:19:59 totale tijdsom van de status: CSDatawarehouse = 0:55:19 1:15:18

Laden/Bewerking (Staging area
DWH tabellen/datamarts) Transformatie/ Loading totale tijdsom van de status: CSDW Dimensies = 1:39:12 1:39:12

Bewerking van Feiten (Staging area
DWH tabellen/datamarts) Transformatie/ Loading totale tijdsom van de status: CSDW Feiten = 0:50:35 0:50:35

44

Bijlage B De doorlooptijden van de database-kubussen van CS-Datawarehouse De kubussen worden per database kubus ververst binnen hun eigen model. Het verversen van de kubussen binnen een model worden ook gelijktijdig gestart, hierdoor is af te leiden dat de kubus binnen een kubus-model die het langst duurt ook in principe de gehele doorlooptijd vormt van de database kubus. Het afzonderlijk verversen/”processen” van de kubussen resulteert in een veel kortere tijd. De reden hiervoor is dat de afzonderlijke “processing” van de kubussen ingesteld staat op “incremental load”. Dit is een optie binnen Microsoft Visual Studio 2005. De huidige “processing” van de kubussen gebeurt volledig. De dimensie attributen, dimensie codes en dimensie hiërarchie worden opnieuw opgebouwd/overschreven. Onderstaand is er een overzicht te zien van de doorlooptijden van de kubussen versie 4.10. Laden/Bewerking (DWH tabellen/datamarts
Kubussen versie 4.10) Database Kubussen

Doorlooptijd

Agenda DBC DCR OK Opname Rontgen SEH Verrichtingen

0:01:40 0:06:16 0:01:58 0:00:18 0:01:07 0:01:45 0:03:05 0:05:17

Totaal

0:21:26

45

Bijlage C Slowly Changing Dimensions (SCD) Er moet rekening gehouden worden met de dimensies die wijzigingen ondergaan. Alhoewel het “slowly changing” dimensies betreft, moet er toch goed over nagedacht worden welke stappen er ondernomen dienen te worden, willen we mutaties terug in de tijd kunnen rapporteren. Het begrip “Slowly changing Dimension” betekent dat er wel wijzigingen kunnen plaats vinden door bijzondere omstandigheden binnen de dimensie. Deze omstandigheden zijn bijzonder, omdat ze niet dagelijks of frequent optreden of horen op te treden. Bijvoorbeeld een verkoper patient verandert van naam. Ten eerst zal het niet regelmatig voorkomen dat een verkoper patient van naam verandert. De bijzondere omstandigheden die hiertoe kunnen leiden zijn onder andere; - De patiënt is getrouwd en heeft zodoende zijn/haar naam gewijzigd. - De patiënt is gescheiden en verandert van naam etc. Het kan ook zijn dat de patiënt is komen te overlijden is. Het record van de patiënt in de dimensie ‘Patiënt’ is niet meer geldig. Er zijn een aantal methoden die toegepast kunnen worden om met deze “Slowly changing Dimension” om te gaan. Het is van belang welke informatie voor het soort rapportage beschikbaar dient te zijn. De verschillende type SCD’s verklaar ik nader: - SCD type 1: Hier worden de oude waardes van de attributen overschreven, de oude waardes worden dus niet bijgehouden. - SCD type 2: De oude waardes van de attributen worden behouden doordat de nieuwe waardes van de attributen als extra rij worden toegevoegd in de tabel. - SCD type 3: De oude waardes van de attributen worden behouden doordat de nieuwe waardes van de attributen als extra kolom(men) worden toegevoegd in de bestaande record. Bij ChipSoft is er sprake van een SCD type 1. Ook de dimensietabellen worden momenteel volledig overschreven bij een verversing van het CS-datawarehouse. Over het algemeen is een SCD type 2 toepasselijker en flexibeler voor het opslaan van de historische attributen in de dimensies. De mogelijkheid voor de hoeveelheid opslag van historische records heeft geen beperkingen tenzij de ondersteunende hardware voor de opslagcapaciteit zijn limit bereikt en er geen ‘upgrade’ plaatsvindt. Dit gebeurt zonder dat de structuur van de tabel aangepast hoeft te worden.

46

Patiënt

Naam

Woonplaats DatumVan

DatumTot

Status

1111

AAA

Nederland

01-01-2009

01-02-2009

Niet Actueel

1111

BBB

Nederland

01-02-2009

31-12-9999

Actueel

Figuur 13. Voorbeeld SCD type 2 Bij een SCD type 3 worden er kolommen toegevoegd aan de betreffende tabel. Deze kolommen bevatten de oude waardes van de records en in de meeste gevallen ook attributen die wat zeggen over de oude waardes. Deze extra attributen zijn van belang voor het kunnen realiseren van specifiekere rapportages. Patiënt

Actuele Naam

Oude Naam

Mutatiedatum

Woonplaats

1111

BBB

AAA

01-02-2009

Nederland

Figuur 14. Voorbeeld SCD type 3 SCD type 3 is ideaal bij niet meer dan vijf historische attributen. De kolomlengte van een record wordt anders veel te lang en onoverzichtelijk. Verder is SCD type 3 ook ideaal wanneer de wijziging die het attribuut betreft, invloed heeft op een groot aantal rijen. Met andere woorden een groot aantal van de rijen in de dimensie dienen ook bij dit attribuut gelijktijdig gewijzigd te worden. Er kan dus verondersteld worden dat het begrip “Slowly Changing Dimensions” een relatief begrip is. Een uitgangspunt om te kunnen classificeren wanneer en wanneer het niet om een SCD gaat kan gedaan worden door middel van te kijken hoeveel keren de attributen in de dimensietabellen gewijzigd worden in verloop van tijd. Hier is tijd de meetgraad. Als de dimensietabellen bijvoorbeeld één of meer keren per maand gewijzigd worden, is er geen sprake meer van SCD maar RCD (Rapidly Changing Dimension). Hoe traag deze wijzigingen eigenlijk zijn, wordt mede bepaald door de grootte van de feitentabel en de dimensie zelf. Bij het classificeren of het wel of niet een SCD betreft, wordt dus gekeken naar de grootte (aantal rijen) die de dimensietabel bevat. Hoe groter het aantal, hoe meer er verondersteld kan of zal worden dat het geen SCD betreft.

47