Vera 3.0. Bijlage - Prestatiemeting. Versie: Datum: Status: Concept. Stichting Vera Veenendaal

Transcriptie

1 5 10 Vera 3.0 Bijlage - Prestatiemeting Versie: Datum: Status: Concept Stichting Vera Veenendaal

2 Inhoudsopgave 1 Inleiding Welk probleem wordt opgelost? Informatie-architectuur Datakluis adapter Ster adapter Methodiek voor stuur-informatie Herhaling CORA-methodiek Uitwerking methodiek binnen Vera Tooling Voorbeelduitwerking indicator Stap 1: Analyse van de indicator Stap 2: Uitbreiding Vera klassen: Basisadapter Stap 3: Ontwerp datakluis adapter Stap 4: Ontwerp steradapter Stap 5: Berekening performance indicator Toepassing in de praktijk Begrippenlijst Bronvermeldingen Bijlage - Prestatiemeting 2

3 Inleiding Een van de focusgebieden van CORA 3.0 (NetwIT, 2012) is prestatiemeting. CORA 3.0 (NetwIT, 2012) wijdt hier dan ook een hoofdstuk aan (Hoofdstuk 7, pag.101 e.v.). Prestatiemeting wordt binnen CORA uitgewerkt door het definiëren van een aantal CORA prestatie-indicatoren. Deze prestatie indicatoren (PI s) kunnen behulpzaam zijn als stuurinformatie voor de corporatie. Tegelijk worden de prestaties van verschillende woningcorporaties beter vergelijkbaar wanneer uniform gedefinieerde prestatie-indicatoren gebruikt worden. Naast de prestatie-indicatoren die binnen CORA zijn gedefinieerd, hebben ook externe toezichthouders een aantal prestatie-indicatoren gespecificeerd die zij gebruiken om het toezicht vorm te geven. Ook de toezichthouders hebben belang bij uniform en helder gedefinieerde prestatie-indicatoren. Bij de definitie van de prestatie-indicatoren wordt binnen CORA gebruik gemaakt van een systematische werkwijze. (Deze werkwijze wordt in dit document kort herhaald in Paragraaf 3.1. ) Deze werkwijze is niet alleen op de CORA indicatoren toepasbaar, maar kan ook worden gebruikt om de extern gedefinieerde prestatie-indicatoren mee uit te werken Samenvattend zijn er twee bronnen van performance indicatoren (CORA en toezichthouders) en is binnen CORA een systematische werkwijze beschreven om de performance indicatoren op een ondubbelzinnige manier uit te werken. CORA kent gegevensdefinities, maar nog geen volledig uitgewerkt gegevensmodel. Binnen Vera is dit uitgewerkte gegevensmodel wel aanwezig. Voor prestatie-indicatoren is het gegevensmodel, met de relaties tussen klassen, minstens even belangrijk als de definities. CORA is gestopt bij uitwerken van de definitie van een indicator met kengetallen. Binnen dit document werken we het verder uit in termen van klassen en attributen, en rekenregels die daarop worden toegepast. Het doel van dit document is het introduceren van een standaard methodiek en een standaard informatie-architectuur ten behoeve van het berekenen van prestatie-indicatoren bovenop het Vera gegevensmodel. De informatie-architectuur beschrijft op welke manier de gegevens worden aangeleverd en opgeslagen; de methodiek beschrijft hoe met deze informatie kengetallen en performance indicatoren worden berekend op basis van de bedrijfsregels en rekenregels. De Vera methodiek borduurt voort op de CORA methodiek maar is een slag concreter. In Figuur 1 is te zien hoe het Vera gegevensmodel zich verhoudt tot de CORA-indicatoren en de externe indicatoren. In dit document wordt achtereenvolgens Bijlage - Prestatiemeting 3

4 70 Beschreven welke informatie-architectuur binnen Vera aanwezig is om PI berekeningen te faciliteren. (Hoofdstuk 2.) Beschreven welke methodiek gehanteerd wordt voor het berekenen van de Vera prestatieindicatoren. (Hoofdstuk 3.) Een voorbeeld-indicator volledig uitgewerkt, waarbij alle stappen toegelicht worden. (Hoofdstuk 4.) Een reeks indicatoren kort uitgewerkt, waarbij alleen de laatste stappen uitgewerkt worden. Ook bevat dit document een begrippenlijst (Hoofdstuk 6) en worden enkele opmerkingen gemaakt over mogelijke toepassing in de praktijk (Hoofdstuk 5). 75 Figuur 1 Prestatie-indicatoren in CORA en Vera Welk probleem wordt opgelost? In de praktijk is het ontsluiten van de bestaande gegevensbronnen arbeidsintensief. Voor het produceren van sturingsinformatie gaat een groot deel van het werk zitten in reversed engineering Bijlage - Prestatiemeting 4

5 om uit verschillende gegevensbronnen de juiste tabellen en velden te vinden met de juiste gegevens voor een meetwaarde. 85 Het introduceren van een standaard methodiek maakt deze reversed engineering overbodig voor de CORA meetwaarden en andere meetwaarden die met de methodiek zijn uitgewerkt. In de toekomst kunnen door het standaardiseren vanuit de informatievraag snel de gegevensonderdelen met hun specifieke kenmerken worden benoemd. Leveranciers kunnen deze gegevens dan vanuit de diverse gegevensbronnen aanbieden conform de methodiek. Bijlage - Prestatiemeting 5

6 90 2 Informatie-architectuur De Vera informatie-architectuur ten behoeve van prestatiemeting bestaat uit een aantal lagen met elk hun eigen verantwoordelijkheid. Dit is weergegeven in Figuur 2. De rode en groene blokken in deze figuur representeren lagen die onderdeel uitmaken van de Vera standaard, de grijze blokken zijn organisatie-specifiek. De verschillende lagen worden later individueel toegelicht. Variant 1 Variant 2 Met eigen datawarehouse Rapportage generatie Rapportage generatie Ster adapter Datawarehouse (black box) datakluis adapter Extract Transform Load (black box) Basis adapter Informatie systeem (black box) Informatie systeem (black box) Informatie systeem (black box) Figuur 2: Vera informatie-architectuur t.b.v. prestatiemeting Zoals eerder gezegd is de informatie-architectuur gericht op het faciliteren van het uitrekenen van prestatie-indicatoren. Voor veel prestatie-indicatoren zijn historische data nodig. De Vera informatie-architectuur is er dan ook op gericht om te voorzien in deze historische informatie en deze op een zodanige manier aan te bieden dat het uitrekenen van de PI s eenvoudig mogelijk wordt. Bijlage - Prestatiemeting 6

7 105 Traditioneel wordt historische informatie in een organisatie verzameld in een zgn. `data warehouse. Sommige corporaties hebben al een data warehouse, anderen niet. Voor corporaties die geen eigen data-warehouse hebben specificeert Vera twee lagen om deze historische dataopslag te verzorgen: De `datakluis adapter en de `ster adapter. Deze zijn onderdeel van `Variant 1 in Figuur 2. Voor organisaties die wel een eigen data warehouse hebben specificeert Vera niet hoe de historische dataopslag vormgegeven moet worden, maar alleen hoe de uiteindelijke PI s uitgerekend moeten worden: Het voorzien in de benodigde gegevens is dan een taak van het corporatie-specifieke data warehouse. Dit is weergegeven in `Variant 2 van Figuur 2. De lagen in de informatie-architectuur hebben de volgende taken: Basis adapter. Deze laag is verantwoordelijk voor het transformeren van een applicatie-specifiek gegevensmodel naar het Vera gegevensmodel. Het Vera gegevensmodel ondersteunt de processen uit CORA en is beschreven in Bijlage B van (Stichting VERA, ). De basisadapter levert gegevens aan per Vera klasse. Het is niet noodzakelijk dat de basisadapter alle klassen aanlevert: De gegevens die aangeleverd worden zijn afhankelijk van het gegevensdomein van het bronsysteem. Als de adapter gegevens over een klasse aanlevert dan dienen alle attributen van die klasse te worden aangeleverd, eventueel met lege waarden. (NULL-waarden.) 1 Datakluis adapter. Deze laag is verantwoordelijk voor het bijhouden van historische gegevens. Deze laag is alleen van toepassing voor corporaties die geen eigen data warehouse hebben. De datakluis adapter leest gegevens uit de basisadapter en slaat deze op in een relationele database volgens een vaste structuur die bekend staat als `datakluis ofwel `datavault. Deze adapter wordt nader beschreven in Paragraaf Ster adapter. De steradapter is bedoeld om op een eenvoudige wijze rapportages te kunnen maken. Hoewel de datakluis-adapter opslag van historische gegevens verzorgt leent deze laag zich niet voor rapportages. Sterschemas vormen een gebruikelijke vorm van data-modellering ten behoeve van rapportages. Een sterschema is een eenvoudig en overzichtelijk model dat bestaat uit een of 1 [RFC: de business keys in het vera gegevensmodel verwijzen naar system keys in de bronsystemen. Tbv de basis adapter en de datakluis hebben we echte business keys nodig die stabiel zijn over systemen. Bijv postcode huisnummer ipv vhe-nummer of BSN ipv klantnummer. Graag definitie business key als zodanig aanpassen. met behulp van indicatoren aangeven welke attributen de business key vormen.] 2 Op basis van het Vera klassenmodel is een prototype datakluis aangemaakt. Het schema hiervan kan bekeken worden op Bijlage - Prestatiemeting 7

8 meerdere feitentabellen die refereren aan dimensie tabellen waarop gebruikers op eenvoudige wijze met bijna iedere willekeurige rapportagetool kunnen rapporteren en analyseren. De steradapter transformeert de gegevens uit de datakluis adapter tot sterschema. Deze adapter wordt nader beschreven in Paragraaf Per performance indicator wordt een stermodel gemaakt. Er zijn dus even veel Steradapters als indicatoren. Het is niet mogelijk om een algemeen recept te geven voor transformatie vanuit de datakluis naar het sterschema: Deze transformatie zal voor elke indicator verschillend zijn. In Hoofdstuk 8 is echter wel per CORA indicator aangegeven welke dimensies en feiten/meetwaarden in de ster aanwezig moeten zijn om het berekenen van de betreffende indicator te ondersteunen. Ook wanneer een corporatie een eigen datawarehouse omgeving gebruikt ligt het voor de hand dat sterschemas gebruikt worden. Deze zijn dan waarschijnlijk uitgebreider dan de micro-sterren die in het kader van Vera worden gedefinieerd en vormen daar een uitbreiding op. Niettemin kan ook in dit geval een sterschema gebruikt worden als basis voor het berekenen van de uiteindelijke indicator. Rapportage generatie In deze laag worden de performance indicatoren uitgerekend op basis van de steradapters uit de vorige laag. Dit behelst doorgaans het aggregeren van gegevens in een steradapter en het uitvoeren van een berekening op de geaggregeerde gegevens. Deze berekeningen zijn in Hoofdstuk 8 weergegeven onder `formule. Samenvattend kan men zeggen dat de basisadapter is bedoeld om op gestandaardiseerde wijze data aan te leveren, de datakluis adapter om hiervan historie bij te houden. De presentatie van deze gegevens in deze lagen is niet gebruiksvriendelijk genoeg voor rechtstreekse rapportages: Dat is de taak van de steradapter. De feitelijke performance indicatoren worden vervolgens in de rapportage generatie-laag berekend. 2.1 Datakluis adapter De datakluis adapter (Linstedt, 2010) volgt een vaste systematiek voor het transformeren van gegevens uit de Vera basisadapter naar een datakluis architectuur. Een datakluis is een relationeel datamodel waarin drie typen tabellen aanwezig zijn: hubs, links en satellites. Zij zijn op eenvoudige wijze te creëren uit het Vera klassenmodel en leveren opslag van historische gegevens. Kortweg kan men zeggen dat hub- en link tabellen de structuur van de gegevens bevatten: Welke objecten (hebben) bestaan in het domein en hoe is de associatie-structuur tussen deze objecten (geweest)? Satellite-tabellen bevatten de attributen van de objecten: De eigenlijke gegevens. Men Bijlage - Prestatiemeting 8

9 kan `hubs en links vergelijken met metadata, `satellites met data. Een gedetailleerdere beschrijving is als volgt: 160 Hubs leggen vast welke objecten een rol spelen in het business domein. Per klasse (entiteit type) is er één hub tabel. Binnen het Vera klassenmodel zijn bijvoorbeeld de klassen Overeenkomst, Huurovereenkomst en Huurgeschil aanwezig. Voor al deze klassen zal een hub-tabel worden aangemaakt. Per object (instantie, record) van een klasse is er één rij in de betreffende hub-tabel. Een hub tabel bevat de volgende typen kolommen: Artificial key. (not null, unique.) Een kunstmatige sleutel (bijvoorbeeld een automatisch gegenereerd nummer) die fungeert als primary key voor de hub tabel. Business key. (not null, unique.) Een sleutel die in het business domein wordt gebruikt om instanties mee te onderscheiden. Het Vera klassenmodel bevat een attribuut `businesskey voor elke klasse 3. Dit attribuut wordt overgenomen in de hub tabel. Verderop in dit document gaan we verder in op de verwerking van business keys. Record source. (not null.) De bron waaruit de betreffende rij het eerst is geladen. Audit id. Een optionele verwijzing naar een tabel met audit informatie. De naamgevingsconventies voor de hub tabel die binnen Vera gehanteerd worden zijn weergegeven in Tabel 1. In deze tabel staan de naamgevingsregels in de linkerkolom en staat een uitgewerkt voorbeeld in de rechterkolom. 175 Tabel 1: Naamgevingsconventies voor hub tabellen. Regel Naamgeving tabel Als Vera klassenaam is <vera klassenaam> dan Hub tabelnaam: H_<vera klassenaam> Voorbeeld H_Betaalgegeven Naamgeving kolommen Artificial key kolom: <hub tabel naam>_id H_Betaalgegeven_ID Business key: businesskey. (Cf. Vera klassenmodel.) businesskey Record source kolom: RSRC Audit id kolom: AUDIT_ID RSRC AUDIT_ID 3 Behalve voor subklassen: deze erven de business key van de superklasse. Bijlage - Prestatiemeting 9

10 Links leggen vast welke associaties (relationships 4 ) er bestaan tussen de klassen. Per associatie tussen twee klassen zijn er één of twee link-tabellen. Een link tabel verwijst naar twee hub tabellen. 5 Een link-tabel die hubs h1 en h2 verbindt bevat de volgende typen kolommen: Artificial key. (not null, unique.) Een kunstmatige sleutel (bijvoorbeeld een automatisch gegenereerd nummer) die fungeert als primary key voor de link tabel. Foreign key h1. (not null.) Verwijzing naar een rij uit hub-tabel h1. Foreign key h2. (not null.) Verwijzing naar een rij uit hub-tabel h2. Record source. (not null.) Bron waaruit de betreffende rij het eerst is geladen. Audit id. Optionele verwijzing naar een tabel met audit informatie. (Het is conceptueel mogelijk dat er meer dan twee hubs verbonden worden met een link tabel. In dat geval zijn er meer dan twee foreign keys aanwezig. Binnen Vera komt dit echter niet voor.) In het Vera klassenmodel zijn associaties binnen een klasse te herkennen als attributen van een type uit het Vera gegevensmodel. Bijvoorbeeld attribuut huurgeschil binnen klasse Huurovereenkomst is van domein specifieke klasse Huurgeschil. In de datakluis bestaat daarom een link tabel die Huurovereenkomst en Huurgeschil met elkaar verbindt. Binnen Vera zijn zowel bi- als unidirectionele associaties tussen klassen aanwezig. In het geval van een bidirectionele associatie is in beide klassen die bij de associatie zijn betrokken een attribuut opgenomen dat de associatie representeert, in het geval van een unidirectionele associatie is zo n attribuut maar aan een zijde aanwezig. 6 Iedere zijde van een associatie wordt in de Vera datakluis gerepresenteerd door een aparte link tabel. Bidirectionele associaties leiden dus tot twee link tabellen, unidirectionele associaties tot een link tabel. Link-tabellen zijn vergelijkbaar met `kruistabellen die in een 3NF database gebruikt worden om N:M associaties mee te modelleren. Merk op dat ook 0-1, 1-1 en 1-M associaties vastgelegd worden met link tabellen, terwijl deze in een 3NF database worden opgenomen als foreign keys in de tabel van een verwijzende klasse samen met de business key (hub) en de overige attributen (satellite). 4 Hier wordt bewust het gebruik van de term `relatie vermeden omdat relatie de aanduiding is voor `tabel in het relationele model, terwijl een `relationship een verband tussen twee of meer entiteit-typen representeert binnen de terminologie van het ER model. 5 In het geval van een recursieve associatie kan een rij uit een link tabel tweemaal naar dezelfde hub tabel verwijzen. 6 Een voorbeeld van een bidirectionele associatie is de associatie tussen Kandidaat en Aanbieding: Kandidaat bevat een attribuut aanbiedingen en Aanbieding bevat een attribuut kandidaat. Bijlage - Prestatiemeting 10

11 De naamgevingsconventies voor link tabellen binnen Vera zijn weergegeven in Tabel 2. Links staat weer de regel, rechts een uitgewerkt voorbeeld. Dit voorbeeld betreft een bidirectionele associatie, die leidt tot twee link tabellen. 205 Tabel 2: Naamgevingsconventies voor link tabellen. Regel Voorbeeld Naamgeving tabel Als vera klasse <vera klasse 1> een attribuut <attribuutnaam> van type <vera klasse 2> bevat dan is er een tabelnaam van de link tabel die deze associatie representeert: L_<attribuutnaam>_<vera klasse 1 naam>_<vera klasse 2 naam> Klassendiagram Vera Bidirectionele associatie, dus twee link tabellen: (1) L_relatie_Betaalgegeven_Relatie (2) L_betaalgegevens_Relatie_Betaalgegeven Naamgeving kolommen (alleen L_relatie_Betaalgegeven_Relatie uitgewerkt) Artificial key: <link_tabel naam>_id Foreign key 1: H_<vera klasse 1 naam>_id_van Foreign key 2: H_<vera klasse 1 naam>_id_naar Record source: RSRC Audit id: AUDIT_ID Betaalgegeven... Relatie relatie... L_relatie_Betaalgegeven_Relatie_ID H_Betaalgegeven_ID_van H_Relatie_ID_naar RSRC AUDIT_ID Relatie 1 *... <Set> Betaalgegeven betaalgegevens... Satellites leggen vast welke gegevens verder van toepassing zijn op de objecten en de associaties uit de hub- en link tabellen. Een satellite tabel verwijst naar één hub tabel of één link tabel. Een satellite tabel bevat de volgende typen kolommen: Artificial key. (not null, unique.) Een kunstmatige sleutel (bijvoorbeeld een automatisch gegenereerd nummer) die fungeert als primary key voor de satellite tabel. Foreign key. (not null.) Verwijzing naar een rij uit hub-tabel of link-tabel waarop de informatie uit dit record van toepassing is. Attr1, Attr2, Attr. etc.: Kolommen met inhoudelijke attributen. Load start date. Begindatum voor de geldigheid van deze rij uit de satellite tabel. Load end date. Einddatum voor de geldigheid van deze rij uit de satellite tabel. Record source. (not null.) Bron waaruit de betreffende rij het eerst is geladen. Audit id. Optionele verwijzing naar een tabel met audit informatie. Bijlage - Prestatiemeting 11

12 220 Voor elke hub wordt een satellite tabel aangemaakt. Bijvoorbeeld voor de Vera-klasse Huurovereenkomst bevat de satellite tabel de volgende kolommen voor de inhoudelijke attributen: waarborgsom, waarborgsomrente, opzegdatum, btw, prolongatieinterval, etc. Ook voor elke link wordt een satellite tabel aangemaakt. Deze bevat informatie over de geldigheid van de associatie. De naamgevingsconventies voor sat-tabellen zijn weergegeven in Tabel 3 en Tabel Tabel 3: Naamgeving voor sat tabellen op hubs. Regel Voorbeeld Naamgeving tabel Hub tabelnaam: H_<vera klassenaam> H_Betaalgegeven Satellite tabelnaam: S_<hub_tabel_naam> S_H_Betaalgegeven Naamgeving kolommen Artificial key: <satellite_tabel naam>_id Foreign key: <hub_tabel_naam>_id Attr1, Attr2 etc. (inhoudelijke kolommen). Naamgeving wordt overgenomen van onderliggende Vera klasse. Load start date: S_LDTS Load end date: S_LEDTS Record source: RSRC Audit id: AUDIT_ID S_H_Betaalgegeven_ID H_Betaalgegeven_ID `bic`, `code`, `iban`, `id`, `rekeninghouder`, `rekeningnummer`, `begindatum`, `einddatum`, `primair` S_LDTS S_LEDTS RSRC AUDIT_ID Tabel 4: Naamgeving voor sat tabellen op links. Regel Voorbeeld Naamgeving tabel Link tabelnaam: L_<rolnaam1>_<rolnaam2> Satellite tabelnaam: S_L_<rolnaam1>_<rolnaam2> L_relatie_Betaalgegeven_Relatie S_ L_relatie_Betaalgegeven_Relatie Naamgeving kolommen Artificial key: <satellite_tabel naam>_id S_L_relatie_Betaalgegeven_Relatie_ID Foreign key: <link_tabel_naam>_id L_relatie_Betaalgegeven_Relatie_ID Attr1, Attr2 etc. (inhoudelijke kolommen). Niet aanwezig Load start date: S_LDTS S_LDTS Load end date: S_LEDTS S_LEDTS Bijlage - Prestatiemeting 12

13 Record source: RSRC Audit id: AUDIT_ID RSRC AUDIT_ID Overerving (superklassen/subklassen) Binnen het Vera klassenmodel bestaan klassen die subklassen zijn van andere klassen. Bijvoorbeeld ` Huurovereenkomst is een subklasse van ` Overeenkomst. In zo n geval wordt een aparte hub en een aparte satellite aangemaakt voor de subklasse. In de hub wordt de businesskey van de superklasse gebruikt als business key. In de satellite voor de hub worden alle simpele attributen uit de superklasse opgenomen. Deze worden dus gedupliceerd. Daarentegen worden de associaties van de superklasse slechts een keer gerepresenteerd: Alleen voor de superklasse. Tijdens het laden van de datakluis worden objecten van een subklasse zowel in de superklassetabellen als in de subklasse-tabellen opgenomen. De overervingsrelaties tussen klassen worden binnen de Vera datakluis vastgelegd in tabel meta_overerving(id, subklassenaam, superklassenaam, hubnaamsubklasse, hubnaamsuperklasse) Meerdere Vera bronnen In de praktijk zal de situatie vaak voorkomen dat er binnen een corporatie meerdere Vera bronsystemen zijn, die een (gedeeltelijk) overlappend gegevensmodel hebben. De gegevens uit de verschillende bronsystemen worden in de Hub-, Link- en Satellite tabellen gezamenlijk opgeslagen, d.w.z. er worden geen aparte tabellen voor de verschillende bronsystemen aangemaakt. De herkomst is immers herkenbaar aan het RSRC veld. Op deze wijze wordt de architectuur van de datakluis zo eenvoudig mogelijk gehouden. In de situatie dat meerdere bronnen gegevens aanleveren over dezelfde objecten moet een rangorde aan de bronnen gegeven worden om te kunnen bepalen welke bron het meest betrouwbaar is voor een bepaald type gegeven. Deze rangorde is organisatie specifiek. Vera faciliteert het vastleggen van deze rangorde door een tabel corpo_rangordebronnen waarin de rangorde kan worden vastgelegd: Tabel 5: corpo_rangordebronnen tabel om rangorde belangrijkheid van bronnen voor attributen vast te leggen wanneer er overlappende bronnen zijn. Kolom Type Betekenis ID Bigint Primaire sleutel van de corpo_rangordebronnen tabel. (Synthetisch.) tabel String Naam van tabel waarop rangordenummer betrekking heeft. kolom String Naam van attribuut waarop rangordenummer betrekking heeft (= naam van een kolom in bovengenoemde tabel.) Bijlage - Prestatiemeting 13

14 255 RSRC String Naam van een bron die gegevens aanlevert voor tabel.kolom rangorde Integer Rangorde die aangeeft hoe betrouwbaar de betreffende bron (RSRC) is voor het betreffende attribuut (tabel.kolom). De laagste rangorde wordt het betrouwbaarst geacht. In deze tabel is de combinatie tabel, kolom, rangorde uniek. Ook is de combinatie tabel, kolom, RSRC uniek. De prefix corpo_ is gekozen om te benadrukken dat deze tabel corporatie-specifiek moet worden ingevuld. Verwerking van business keys De aanwezigheid van meerdere bronsystemen heeft ook implicaties voor de wijze waarop met `business keys omgegaan wordt in de Vera datakluis. Zoals eerder is beschreven is een business key een sleutel die in het domein wordt gebruikt om instanties mee te onderscheiden Business keys zijn niet noodzakelijk natuurlijke sleutels. Het kunnen ook kunstmatige sleutels zijn, zolang ze binnen de business maar gebruikt worden om objecten mee te identificeren. 7 Voor veel entiteit-typen in het corporatiedomein geldt dat natuurlijke sleutels niet voorhanden zijn, waarschijnlijk omdat deze typen buiten het domein geen rol spelen. 8 Een voorbeeld is de Vera klasse Cluster. Een cluster representeert een groep eenheden en wordt bij veel corporaties een Complex genoemd. Vaak worden clusters/complexen aangeduid met een kusntmatige sleutel, bijv. een complexnummer. Natuurlijke sleutels zoals (postcode,huisnummer) bestaan niet voor een cluster. Niettemin is zo n clusternummer of complexnummer dan een business key. Vaak is het zo dat elk systeem zijn eigen business keys gedefiniëerd heeft voor klassen/typen waarvoor een voordehandliggende natuurlijke sleutel ontbreekt. Voor één klasse komen de business keys qua naam en type doorgaans niet overeen tussen verschillende systemen. Een verhuurbaare eenheid heet bijvoorbeeld VHE in een systeem, VHO in een ander en woningnummer in een derde systeem. Deze diversiteit wordt in de datakluis als volgt gefaciliteerd: Elk syteem wordt geacht zijn eigen business key aan te leveren in String-vorm in het veld businesskey. Deze business keys worden verwerkt in de hub tabellen zoals eerder beschreven. Meerdere rijen in de hub tabel kunnen hierbij hetzelfde object in de echte wereld representeren, weergegeven door meerdere business keys uit verschillende systemen. Om de link tussen deze rijen te representeren is in de datakluis voor elke 7 Het onderscheid tussen een natuurlijke sleutel en een kunstmatige sleutel is niet altijd helder; Kunstmatige sleutels kunnen dermate ingeburgerd raken dat zij verworden tot natuurlijke sleutels. Denk aan BSN, postcode of zelfs achternaam. 8 Het Vera klassenmodel is tamelijk gefragmenteerd en voor weinig klassen is een natuurlijke sleutel voorhanden. Hierdoor is de noodzaak voor kunstmatige sleutels binnen Vera groot. Bijlage - Prestatiemeting 14

15 hub een tabel corpo_sal_<hub_tabel_naam> aanwezig. SAL is hierbij een afkorting voor Same As Link. De prefix corpo_ geeft aan dat deze tabel corporatie-specifiek ingevuld moet worden. 280 Tabel 6: Naamgevingsconventies voor same as link (SAL) tabellen. Regel Naamgeving tabel Als hub tabelnaam is <hubnaam> dan corpo_sal_h_betaalgegeven same as link tabelnaam: corpo_sal_<hubnaam> Artificial key: <SAL_tabel naam>_id Foreign key 1: <hubnaam>_id_van Foreign key 2: <hubnaam>_id_naar Audit id: AUDIT_ID Naamgeving kolommen corpo_sal_h_betaalgegeven_id H_Betaalgegeven_ID_van H_Betaalgegeven_ID_naar AUDIT_ID 285 We merken op dat de noodzaak voor same as links niet zou bestaan als de business keys gelijk zouden zijn over alle systemen. Voor systemen waarbij dit nu al het geval is, is het eenvoudig de same as link tabellen te vullen: Men kan dan eenvoudigweg kijken naar identieke waarden. (Dit zou ook geautomatiseerd kunnen.) In andere gevallen zal meer moeite gedaan moeten worden om equivalente business keys te identificeren. De datakluis voorziet tevens in het opslaan van meta informatie over de business keys in de bronsystemen. Hiertoe is tabel corpo_businesskeys aanwezig. Deze is als volgt gedefineerd: Tabel 7: corpo_businesskeys tabel om informatie over business keys in de bronsystemen bij te houden. Kolom Type Betekenis ID Bigint Primaire sleutel van de corpo_businesskeys tabel. (Synthetisch.) tabel String Naam van de hub tabel in de vera datakluis waarover business key informatie wordt vastgelegd. RSRC String Naam van het bronsysteem dat gegevens aanlevert voor de hub tabel. sleutelnaambronsysteem String Naam van het sleutelattribuut in het bronsysteem. (In het Vera klassenmodel is deze sleutel gerepresenteerd als veld businesskey.) Optioneel. rangorde Integer Rangorde die aangeeft hoe betrouwbaar de betreffende bron is voor de business key. De laagste rangorde wordt het betrouwbaarst geacht. Met behulp van dit veld kan Bijlage - Prestatiemeting 15

16 een voorkeurssleutel geïdentificeerd worden uit een verzameling sleutels die d.m.v. same-as links (SAL tabellen) aan elkaar zijn gelinked. De laatste drie tabellen die behandeld zijn (corpo_businesskeys, corpo_sal_<hubnaam> en corpo_rangordebronnen) zijn organisatie-specifiek. Het zinvol invullen hiervan vergt inspanning per corporatie. Alle eerdere tabellen (hubs, links en satellites) kunnen in principe volledig automatisch gevuld worden vanuit de bronsystemen. We merken hierbij op dat het niet nodig is om gelijktijdig al de corporatie-specifieke tabellen te vullen Dat kan worden uitgesteld tot dat noodzakelijk wordt voor het genereren van output. 2.2 Ster adapter Zoals eerder gezegd definieert Vera per prestatie-indicator een stermodel dat de berekening van deze indicator ondersteunt. Per indicator zal de benodigde transformatie vanuit de datakluis verschillen en het is daarom niet mogelijk om hier een algemeen recept voor te geven. In deze paragraaf lichten we echter in algemene termen het stermodel toe. Het stermodel staat ook bekend als `dimensioneel model in de literatuur. Een stermodel is een relationeel datamodel. Binnen een stermodel bestaan twee typen tabellen: Feit-tabellen en dimensie-tabellen. De feit tabellen bevatten informatie over gebeurtenissen die in het domein hebben plaatsgevonden, bijvoorbeeld `verhuringen, `verkopen of `klachten. Een zo n gebeurtenis noemt men een feit. Ook bevatten de feit-tabellen numerieke gegevens die geassocieerd zijn met deze gebeurtenissen, bijvoorbeeld `verkoopopbrengsten. Deze numerieke gegevens worden meetwaarden of measusres genoemd. Dimensie-tabellen bevatten (hoofdzakelijk) niet-numerieke gegevens die met een feit zijn geassocieerd. Bijvoorbeeld postcode, woonplaats, huisnummer, woningtype die van toepassing zijn op een verkochte woning. Vanuit een feit-tabel zijn er doorgaans verwijzingen naar meerdere relevante dimensie-tabellen. Wanneer men dit visueel weergeeft heeft het schema de vorm van een ster, vandaar de naam sterschema. Een voorbeeld is weergegeven in Figuur 4. Binnen Vera hanteren we de conventie dat de naam van feit-tabellen met Feit begint en dat de naam van dimensie tabellen met Dim begint, bijvoorbeeld: DimTijd en FeitAantalLeegstandsDagen in Figuur 4 in Paragraaf 4.4. Feit tabellen. In een feit-tabel worden gegevens op het laagste niveau opgeslagen, geen geaggregeerde gegevens. Wanneer een feit-tabel aantallen bevat dan hebben deze op het laagste Bijlage - Prestatiemeting 16

17 320 niveau veelal waarden 0 of 1, bijvoorbeeld het aantal leegstandsdagen van een specifieke VHE op een specifieke dag. Met behulp van een rapportage-tool kan men dan aggregeren over dimensies. Voor veel van de indicatoren is aggregeren van feiten en meetwaarden over dimensies niet voldoende en moet een ratio berekend worden. (Een voorbeeld is leegstandspercentage.) Het berekenen van deze ratio vindt plaats in de rapportage-laag Dimensie tabellen zijn niet genormaliseerd. Daar waar je een transactiemodel uitnormaliseert doe je dat in een microster-model juist niet; het ster model is juist zoveel mogelijk plat om heel snel data te kunnen selecteren. Het maakt de ster helderder. De attributen in de dimensietabellen binnen een ster zijn één op één gelijk aan de attributen uit specifieke Vera-klassen en dus ook aan de attributen uit de SAT tabellen van de datakluis. Zo is het attribuut DimEenheid.adres gelijk aan het attribuut Eenheid.adres en het attribuut DimEenheid.id is gelijk aan het attribuut Eenheid.id. Dat impliceert dat ook het gegevenstype van deze attributen steeds één op één gelijk is. Gevolg is dat de sleutel van iedere dimensieklasse van het type String is en niet van het meer gebruikelijke type Integer. Het woord micro in de term microster drukt uit dat voor een prestatie-indicator de minimale verzameling attributen is opgenomen die nodig is voor het berekenen van de betreffende PI. Bijlage - Prestatiemeting 17

18 Methodiek voor stuur-informatie Zoals eerder gezegd is in CORA 3.0 is een methodiek voor de uitwerking van prestatie-indicatoren naar kengetallen opgenomen en is voor de processen Verkoop en Verhuur een reeks prestatieindicatoren uitgewerkt (NetwIT, 2012, p. 101). Deze methodiek behelst kortweg het toepassen van `bedrijfsregels en `rekenregels op het CORA-gegevensmodel. (Voor meer informatie verwijzen we naar (NetwIT, 2012).) 3.1 Herhaling CORA-methodiek De CORA methodiek voor het berekenen van een prestatie-indicator laat zich het eenvoudigst uitleggen aan de hand van een voorbeeld. Onderstaand voorbeeld is afkomstig uit (NetwIT, 2012), pg Bijlage - Prestatiemeting 18

19 345 In dit voorbeeld wordt een KPI `Afnamesnelheid van de leegstand gedefinieerd. Deze is gebouwd op twee `Kengetallen : A en B. Elk kengetal wordt gespecificeerd als de uitkomst van een berekening op onderliggende gegevens: Deze berekening is beschreven onder `Rekenregels. Er kunnen condities aan de data die gebruikt worden in de berekening worden opgelegd onder `Bedrijfsregels Uitwerking methodiek binnen Vera Zoals eerder opgemerkt volgt Vera de CORA methodiek voor het berekenen van performance indicatoren, d.w.z. het maakt gebruik van bedrijfsregels, rekenregels, kengetallen en formules. Binnen Vera wordt deze methodiek echter concreter uitgewerkt dan in CORA omdat de relatie met Bijlage - Prestatiemeting 19

20 355 het onderliggende Vera klassenmodel tot stand wordt gebracht. De term kengetal wordt binnen Vera vervangen door `meetwaarde om aansluiting te verkrijgen bij de standaard terminologie binnen het data-warehousing vakgebied: De CORA kengetallen komen als `meetwaarden in de feitentabellen van Vera terecht. De methodiek voor het uitwerken van een indicator bestaat uit de volgende stappen, die voor elke indicator afzonderlijk uitgevoerd worden: Analyse van de indicator. In deze stap wordt de vraag beantwoord welke gegevens nodig zijn voor de bedrijfs- en rekenregels en voor de dimensies. Dit is om te toetsen of de bestaande gegevensmodellen uit Vera voldoen om waarden van CORA-kengetallen te kunnen tonen. Immers, om die waarden te tonen is het nodig dat vanuit de CORA-gegevensdefinities de juiste attributen in de Vera-modellen aanwezig zijn. 2. Uitbreiding Vera-klassenmodel (ontwerp Basisadapter). Voor de Basis adapter wordt het Vera-klassenmodel uitgebreid met klassen en attributen die ontbreken voor de betreffende indicator. 3. Ontwerp datakluis adapter. Op basis van het aangepaste klassenmodel wordt volgens de systematiek uit Sectie 2.1 de structuur voor een datakluis gegenereerd. In de datakluis wordt de opslag van historische gegevens verzorgd. 4. Ontwerp Steradapter. Vervolgens wordt een sterschema gespecificeerd ter ondersteuning van de berekening van de betreffende indicator. De transformatie van datakluis naar stermodel is per indicator verschillend en wordt dus per indicator uitgewerkt. Elke ster bevat een of meer `meetwaarden in de feiten tabel. Deze meetwaarden komen tot stand door het toepassen van bedrijfsregels en rekenregels op de onderliggende gegevens uit de datakluis. De meetwaarden zijn dus het Vera equivalent van de CORA kengetallen. 5. Berekening performance indicator. Als laatste stap wordt de uiteindelijke indicator berekend o.b.v. de in het stermodel aanwezige gegevens. Dit berekenen gebeurt door het toepassen van een formule op de onderliggende meetwaarden. Ad 5: Binnen Vera bestaan rekenregels en bedrijfsregels los van de toepassing in de berekening van een performance indicator. Rekenregels en bedrijfsregels hebben binnen Vera een nummer. Bijv. BR182 = Overeenkomst is een huurovereenkomst of RR161 = Som van aantal overeenkomsten. Dit komt herbruikbaarheid ten goede: Bij gebruik van zo n reken- of bedrijfsregel in een berekening Bijlage - Prestatiemeting 20

21 kan dan volstaan worden met een verwijzing naar het nummer. Dit is compacter dan volledig uitschrijven. Ook is het op deze wijze eenvoudig om aanpassingen in een reken- of bedrijfsregel `uit te rollen over alle plaatsen waar die regel gebruikt wordt. Een voorbeeld-situatie waarin dit zinvol zou kunnen zijn, is wanneer de definitie van Daeb woningen zou wijzigen en deze gewijzigde definitie geëffectueerd moet worden in verschillende meetwaarden. Hoofdstuk 8 bevat een aantal uitgewerkte performance indicatoren. In deze uitwerkingen worden de bovenstaande stappen doorlopen. Hierbij moet de kanttekening worden gemaakt dat de datakluis laag (stap 3) en de aansluiting tussen de datakluis en het stermodel (stap 4) nog niet volledig uitgewerkt zijn. Dit is een gevolg van het verloop van het Vera-traject. Voor deze uitwerking doet de werkgroep een RFC, zodat in een volgende versie de stermodellen aansluiten op de onderliggende datakluis. Bij wijze van voorbeeld zijn alle stappen uitgewerkt met toelichting voor een eenvoudige performance indicator in Hoofdstuk Tooling De reken- en bedrijfsregels, en de formules die gebruikt worden om de performance indicatoren te berekenen zijn in het kader van het huidige traject bijgehouden in een MS-access database. Op deze wijze kon de consistentie worden gewaarborgd. 405 De werkgroep concludeert dat voor het beheren van de definities (dwz rekenregels, bedrijfsregels en formules en de onderliggende adapters) het noodzakelijk is dat hiervoor een geautomatiseerd platform wordt ingericht. De functionele eisen van een dergelijk platform dienen nog te worden uitgewerkt. Hiervoor doet de werkgroep een RFC. Bijlage - Prestatiemeting 21

22 410 4 Voorbeelduitwerking indicator Als voorbeeld is de indicator Aantal leegstandsdagen uitgewerkt. Onderstaande tabel is overgenomen uit (NetwIT, 2012) Tabel 4.1 Opbouw indicator aantal leegstandsdagen volgens CORA Voor deze indicator worden alle stappen doorlopen Stap 1: Analyse van de indicator Van elk van de genoemde bedrijfsregels en rekenregels is het volgende getoetst: welke klasse wordt geraakt, wat zijn de benodigde attributen en zijn die aanwezig in Vera? Deze toetsing wordt per meetwaarde herhaald. (In het voorbeeld is maar een meetwaarde nodig voor het uitrekenen van de performance indicator.) Met het resultaat van deze toetsing kan stap 2 worden uitgevoerd. Bijlage - Prestatiemeting 22

23 420 Meetwaarde A: Aantal leegstandsdagen. (Aantal dagen in de meetperiode dat verhuurbare of verkoopbare eenheden leeg hebben gestaan.) De inventarisatie van benodigde attributen voor de rekenregel is in onderstaande tabel gegeven. 9 Rekenregel Klasse.attribuut Aanwezig in Vera Som van aantal leegstandsdagen in de meetperiode. EenheidToestand.begindatum EenheidToestand.einddatum EenheidToestand.status ja ja ja 425 De inventarisatie van benodigde attributen voor de bedrijfsregels is in onderstaande tabellen gegeven. Bedrijfsregel Klasse.attribuut Aanwezig in Vera Eenheid is in exploitatie in de periode (geheel of gedeeltelijk) Eenheid.inExploitatiedatum Eenheid.uitexploitatiedatum Ja Ja Eenheid is een verkoopbare eenheid. Eenheid.soort Eenheid.bestemming ja ja Eenheid is een verhuurbare eenheid. Eenheid.soort Eenheid.bestemming ja ja Geconcludeerd mag worden dat het Vera klassenmodel toegerust is om te voorzien in de informatie die nodig is voor deze performance indicator Stap 2: Uitbreiding Vera klassen: Basisadapter In de vorige stap zijn geen benodigde attributen naar voren gekomen die ontbreken binnen Vera. De Vera klassen hoeven daarom niet uitgebreid te worden. Deze stap kan dus overgeslagen worden. Wanneer er wel ontbrekende attributen aan het licht komen worden deze d.m.v. een RFC aan Spoor 1 gecommuniceerd. 4.3 Stap 3: Ontwerp datakluis adapter Het ontwerp van de datakluis adapter behelst het toepassen van de in Paragraaf 2.1 genoemde regels en naamgevingsconventies. 9 De inventarisatie van benodigde attributen komt tot stand door een informele regel op te stellen om de performance indicator uit te rekenen obv het Vera klassenmodel. Bijlage - Prestatiemeting 23

24 In het kader van dit voorbeeld beperken we de opbouw van de datakluis tot de hierboven geïdentificeerde klassen: Eenheid en EenheidToestand. Van deze klassen zijn slechts zeven attributen nodig voor het berekenen van de performance indicator. In de datavault worden echter alle attributen opgenomen. De attributen in het Vera klassenmodel kunnen verwijzen naar andere Vera klassen, in het geval van associaties, of het kunnen enkelvoudige attributen zijn. (Simple attributes.) In het kader van deze voorbeelduitwerking worden de enkelvoudige attributen in de data vault opgenomen maar van de associaties wordt alleen de associatie tussen Eenheid en EenheidToestand opgenomen. De resterende attributen zijn deels weergegeven in Tabel 2 en Tabel 3. Voor de betekenis van deze velden en de overige attributen verwijzen we naar de Vera documentatie. Tabel 2: Enkelvoudige attributen (simple attributes) van de Eenheid-klasse gebruikt in het voorbeeld voor de datakluis. Nr Naam Type 1 id string 2 bronsysteem Referentiedata.Bronsysteem 3 businesskey string 4 code string 10 naam string 11 omschrijving string 14 kadastraalnummer string 30 volgnummer string 31 etage integer 38 inexploitatiedatum date 39 uitexploitatiedatum date 42 bewoonbarevertrekkentotaalinhoud integer etcetera... Tabel 3: Enkelvoudige attributen (simple attributes) van de klasse EenheidToestand. Nr Naam Type 1 id string 2 bronsysteem Referentiedata Bronsysteem 3 businesskey string 4 code string Bijlage - Prestatiemeting 24

25 begindatum date 7 einddatum date 8 status Referentiedata EenheidStatus 9 detailstatus Referentiedata EenheidDetailStatus 10 eenheid Eenheid Met deze klassen en attributen wordt het database schema gemaakt dat is weergegeven in Figuur 3. Het is belangrijk om te vermelden dat deze figuur slechts een klein deel van de volledige Veradatakluis laat zien: In de volledige datakluis zijn hub-tabellen met veel andere tabellen verbonden afhankelijk van de associaties in het datamodel. Het is dus niet zo dat voor elke indicator een aparte datakluis gemaakt wordt, zoals dat voor de sterschemas (volgende stap) wel gebeurt. Figuur 3: Schema voor datakluis adapter voorbeeld indicator Stap 4: Ontwerp steradapter In deze paragraaf wordt een `sterschema gedefinieerd waarmee de indicator `aantal leegstandsdagen uitgerekend kan worden. De meetwaarden in de ster worden berekend op basis van de in de datakluis aanwezige gegevens. Zoals eerder gezegd is de aansluiting tussen de datakluis en het stermodel nog niet uitgewerkt in deze versie van Vera. Wel is de definitie van de meetwaarden in de feiten-tabel op basis van het Vera gegevensmodel uitgewerkt voor alle Bijlage - Prestatiemeting 25

26 465 voorbeelden in de bijlagen. De eerste uitgewerkte indicator in deze paragraaf is `Aantal Leegstandsdagen. Met betrekking tot de definities van de meetwaarden verwijzen we op dit punt naar de uitwerking in de bijlagen. We volstaan hier met het tonen van het resulterende sterschema. Dit schema is weergegeven in Figuur 4. Figuur 4: Resulterende ster voor indicator AantalLeegstandsdagen. dimtijd id Datum Maand Kwartaal Trimester Jaar feitaantalleegstandsdagn id dimtijdid dimleegstandsredenid dimeenheidid aantalleegstandsdagen dimeenheid id businesskey code adres eigenaar rayon buurt wijk corporatiebuurt corporatiewijk daeb_niet_daeb dimleegstandsreden 470 id eenheid status detailstatus begindatum einddatum 4.5 Stap 5: Berekening performance indicator De performance indicator wordt vervolgens berekend op basis van de in de microster aanwezige meetwaarden. Hiervoor moet een formule worden toegepast in de rapportagelaag. Ook hiervoor verwijzen we naar de bijlage met uitgewerkte prestatie indicatoren. Bijlage - Prestatiemeting 26

27 Toepassing in de praktijk De methodiek die hiervoor is uitgewerkt is een aanzet om te komen tot standaardisatie voor sturingsinformatie binnen Vera. De methodiek toont aan dat het standaardiseren van de gegevensoverdracht voor performance indicatoren kan plaatsvinden door het introduceren van een drietal adapters; de Basisadapter, de datakluis atapter en de Steradapter. Voor deze adapters wordt gebruik gemaakt van standaard Vera ingrediënten. De adapters zijn logisch uitgewerkt. Om hiermee in de praktijk te kunnen werken moet meer worden geregeld. Er dienen ook technische keuzes te worden gemaakt. Vera gaat daar niet over. Wel geven we een paar adviezen en overwegingen voor toepassing in de praktijk. Voor de gegevensoverdracht (push of pull) geven we een aantal mogelijkheden: Webservices: Niet de voorkeur, aangezien dit veel overhead geeft in het geval van bulk data. CSV: Vanuit de operationele systemen wordt een set met CSV bestanden opgeleverd ten behoeve van rapportages. De set CSV bestanden bestaat uit bestanden conform het Vera datamodel: Per klasse één bestand. Databaseviews: De operationele systemen bieden middels een view laag toegang tot tabellen en velden, de viewlaag bevat views conform het Vera datamodel. Per klasse één view. 495 Er bestaat overlap tussen Vera prestatie indicatoren en XBRL. XBRL is een methode voor gegevensoverdracht van financiële gegevens waarbij aangeleverde data op interne consistentie getoetst kan worden en op basis van deze gegevens automatisch afgeleidde gegevens berekend kunnen worden. Een advies over de plaatsing van XBRL binnen Vera wordt apart opgeleverd door de vera 3.0 werkgroep. De relatie tussen prestatie-indicatoren en XBRL moet in een later stadium opgehelderd worden. Bijlage - Prestatiemeting 27

28 500 6 Begrippenlijst In het uitwerken van meetwaarden in de Vera standaard worden het onderstaande begrippenkader gebruikt. Deze lijst staat in logische volgorde van gebruik. Begrip Meetwaarde Feit Omschrijving Een meetwaarde is 1 enkele waarde die onderdeel uitmaakt van een feit. De waarden van dit attribuut hebben een specifieke numerieke betekenis. Op de meetwaarde kunnen bewerkingen worden uitgevoerd die betekenisvol zijn. Een meetwaarde is bijvoorbeeld aantal en verkoopprijs. (Kimball & Ross, 2013) Een feit is een verzameling verschillende bij elkaar horende meetwaardes die een onlosmakelijke gegevens set vormt van een enkele gebeurtenis. Bijvoorbeeld bij een gebeurtenis verkoop hoort een feit met meetwaarden aantal en verkoopprijs van die en verkoop gebeurtenis. Op feiten kan worden gerapporteerd. Aan het feit zijn dimensies gekoppeld die de context van het feit vastleggen zoals wie, wat, hoe waar en wanneer het feit zich heeft voorgedaan. Met de dimensies wie en wanneer kan bijvoorbeeld worden bepaald hoeveel iemand in een bepaalde periode verkocht heeft met de totale verkoopprijs. Dimensie Attributen Object Sterschema Een dimensie die bij vrijwel alle gebeurtenis terugkomt is de kalender dimensie met de datums. (Kimball & Ross, 2013) Een dimensie geeft nadere informatie over datgene waarop feiten betrekking hebben, de context van het feit. Enkele voorbeelden van dimensies zijn datum, product en klant. Dimensies bestaan uit attributen die de dimensie beschrijven. De dimensie datum heeft bijvoorbeeld de attributen jaar, kwartaal, maand en dag. (Kimball & Ross, 2013) Gegevens in een klasse. Instantie van een klasse. Schema dat bestaat uit een centrale klasse met de feiten (objecten met meetwaardeattributen), met daaromheen klassen die de dimensies (objecten met beschrijvende attributen) bevatten om feiten te groeperen en te filteren. Een feit bevat referenties naar de bijbehorende dimensie regels in de elke dimensie. Hiervoor wordt vaak de volgende weergave gebruikt: Bijlage - Prestatiemeting 28

29 Begrip Omschrijving Figuur 5 Sterschema Vanwege de vorm wordt dit een sterschema genoemd. Een sterschema is een gedenormaliseerde structuur, dat wil zeggen dat in een dimensie gegevens meerdere keren voor kunnen komen. Zo kan bijvoorbeeld bij een dimensie Eenheid het gegeven Wijk opgenomen zijn; aangezien een Wijk doorgaans meerdere eenheden heeft komt het gegeven Wijk meerdere keren voor. Men kan er voor kiezen om het gegeven Wijk uit de dimensie te halen en in een aparte klasse te stoppen, de dimensie Eenheid krijgt dan als het ware een satelliet object Wijk. In dat geval spreekt met van een sneeuwvlok model (snowflake). Het doel van een ster schema is om heel eenvoudig gegevens te kunnen benaderen en filteren. Bij een ster schema is alleen sprake van feiten en dimensies en is dus eenvoudiger dan het werken met het koppelen van klassen in een sneeuwvlok model. De hogere performantie en bruikbaarheid van het ster model zijn daardoor vrijwel altijd belangrijker dan de redundantie. De gegevens in een dimensie zijn vaak statisch waardoor de redundantie doorgaans geen enkel probleem is. Beide technieken vinden hun oorsprong bij Ralph Kimball, auteur van diverse boeken over datawarehousing en business intelligence. Micro ster Een minimalistische invulling van een sterschema waarbij het sterschema gebouwd is voor een specifiek doel, bijvoorbeeld een bepaald rapport of een bepaalde meetwaarde. Het bevat alleen de gegevens die nodig zijn voor dat doel. Daardoor is de microster veel minder omvangrijk dan een sterschema voor algemeen gebruik, maar ook veel gemakkelijker te gebruiken voor het specifieke doel. Datawarehouse Verzameling gegevens die zodanig is opgeslagen dat er gemakkelijk op kan worden gerapporteerd, gezocht en gefilterd. De gegevens worden vaak direct opgeslagen als sterschema s (Kimball & Ross, 2013) of als verzameling gegevens (Data Vault) waaruit later sterschema s worden afgeleid (Data Mart). (Inmon, 2005) Bijlage - Prestatiemeting 29

30 Begrip Tabel Technische sleutel Bedrijfssleutel Foreign key Meetwaarde Prestatie-indicator (PI) Omschrijving Lijst in een relationele database; feiten en dimensie klassen worden gewoonlijk als tabel in een datawarehouse database gemodelleerd. Een tabel bevat kolommen met gegevens waarbij de kolommen de weergave zijn van de attributen van de klasse. Eén kolom is speciaal en bevat de sleutel. De sleutel in een unieke identificatie van één regel in de kolom (waarbij een regel overeenkomt met een instantie van een klasse, een object); de sleutelwaarde kan in andere tabellen worden gebruikt om naar een specifieke regel te verwijzen. Een sleutel die meerdere kolommen beslaat is ook mogelijk maar wordt voor rapportage doeleinden zelden gebruikt. Een type sleutel in een klasse om een object van een bepaalde klasse uniek te identificeren. Een technische sleutel is een kunstmatige, betekenisloze sleutel; het enige relevante van een dergelijke sleutel is dat hij uniek is. Verder kunnen aan een dergelijke sleutel geen eigenschappen worden ontleend. Een type sleutel in een klasse om een object van een bepaalde klasse uniek te identificeren. Een bedrijfssleutel is een sleutel die afgeleid is van een gegeven die van nature in een gegevensdomein voor komt. Bijvoorbeeld een burgerservicenummer voor het identificeren van een persoon of een klantnummer voor het identificeren van een klant relatie. Attribuut in een klasse die een sleutelwaarde bevat van een andere (of dezelfde) klasse. Hiermee wordt in een instantie van die klasse (een object) een relatie gelegd naar een ander object. De sleutelwaarde is de identificerende sleutel van de instantie van de klasse waarnaar verwezen wordt (primaire sleutel); dit kan een bedrijfssleutel zijn of een technische sleutel. Welk attribuut de primaire sleutel is, is een keuze die bij die andere klasse is gemaakt bij het modelleren. De verwijzende sleutel (foreign key) bevat dus de waarde van de bedrijfssleutel of technische sleutel van de klasse waar naar verwezen wordt. Welke klasse bedoeld wordt is gedefinieerd in het bijbehorende klasse diagram (gegevensmodel). Een meetwaarde is een getal dat is uitgedrukt in geld- of in fysieke eenheden en dat de toestand van of de ontwikkeling op een bepaald beleidsterrein weergeeft. (NetwIT, 2012) Een prestatie-indicator is een meetbare vertaling van een veelal niet direct meetbare business doelstelling. (NetwIT, 2012) Een prestatie-indicator is te beschouwen als een 'meetlat' die de prestatie van personen of organisaties in beeld brengt. Voor een Bijlage - Prestatiemeting 30