IN2BI, Microsoft Business Intelligence
data, stories & insights
rss | email | twitter

Category: 'Business Intelligence'

  • do
    jul 12

    Things I Learn(ed) From My First Data Warehouse

    Some fifteen years ago I created my first data warehouse. This was after a decade in several financial functions like auditing, controlling and reporting.

    The experienced consultant that reviewed my data warehouse had a lot of comments. Why didn’t I incorporate more attributes he asked? There must be more information in the source systems … what about age, gender, occupation, marital status of the people in this dimension?

    more_attributesHe was right of course but as the business expert I didn’t feel the need. I hadn’t needed this information in my reports and I had my doubts as to the data quality of these attributes in the source systems.

    Learning from criticism

    But of course I learned from his advice and in later projects I found myself convincing customers that they needed these attributes or would probably need them in the future. And if we didn’t add them now it would cost much more in a future update.

    Revisiting my learned behavior

    So me and my team spend a lot of time extracting attributes, cleansing them and loading them in dimensions. Spending a lot of time and customer’s money on adding attributes they didn’t need in the first place. Nowadays I will suggest a more agile approach: loading the data as is in an historical staging area or a data vault and only cleanse/add them to the dimensional model when needed.

  • ma
    mei 12

    Four Approaches to Data Warehousing

    The requirements of a Data Warehouse solution continually change during its life time. For some organizations you’ll typically expect more changes than others. Think of maturity, history of organizational changes: mergers, acquisitions etc.

    You should adopt a solution type that will yield the best value taking these things into account.

    Data Warehouse Solutions

    When confronted with a new data warehouse solution that I am going to design or redesign I will typically choose between one of the following four approaches:

    1. One-Shot Data Warehouse
    2. Keeping History in Dimensions
    3. Historical / Persistent Staging Area
    4. Data Vault

    In this blog post I’ll briefly dive into these approaches and discuss some of the implementation issues.

    The choice for a specific approach depends on a number of circumstances, notably:

    • The expected total size of the solution
    • The number of source systems and how the information in them overlap
    • The average expected life-time of source systems: source system volatility
    • Current user requirements
    • Expected number of changes in user requirements: requirements volatility


    1. One-Shot Data Warehouse (small- and mid-sized solution)

    gunCurrent computing possibilities will typically enable the complete build (from scratch) of a data warehouse solution for small- and mid-sized solutions within the typically nightly maintenance window. This can be a very efficient solution with a high return on investment. Some people call it the destroy and rebuild approach since you are removing all previous data from the data warehouse before rebuilding it.

    An obvious disadvantage of this approach is that there is no track of changes in the source system: If a customer moves from London to Paris all the historical sales will be reported as Paris sales. Another disadvantage is the sheer amount of data that is transferred every night. That can accumulate to an amount that can not been loaded in the nightly maintenance window.

    2. Keeping History in Dimensions

    The problem of keeping track of history has been a major issue in data warehousing. In the theories  by Ralph Kimball Slowly Changing Dimensions play an import role. In his books he mentioned some patterns to handle history in dimensions.

    Type 1: Change history

    For some attributes the business isn’t interested in keeping historical information. This of course is most appropriate when correcting previous errors. Or in other situations where there is no business value in keeping track of historical information. For example when a person’s name changes due to marriage. The rows that were imported earlier in the dimension table are corrected by an UPDATE statement.

    Type 2: Keep history

    In this pattern history is preserved because a new record is entered for every change in a dimension attribute. The old row is marked as inactive and an end date is added to the row. Any new fact tables records that are inserted after this dimension row is changed will link to the newly added row.

    Other types

    Type 1 and Type 2 are the most commonly used. However there are some alternatives. They are described in this Wikipedia article.

    Other advantages

    Besides the tracking of history another major advantage is that you’ll only need changed and new rows (the delta rows) from your source system. And thus diminishing the time you need to load the data in your data warehouse. However getting only these delta rows can be challenging.

    3. Historical / Persistent Staging Area

    In this approach you’ll typically get a copy of all relevant source tables and add temporal information in a ‘StartDate’ and a ‘EndDate’ column. Again you’ll only process the delta rows: loading new and changed rows. And whenever a row has changed you’ll end date the old row.

    Based upon this historical staging area you can adopt method 1 or 2 to load the data in your dimensional model.

    What are the reasons for having a persistent staging area?

    In an earlier blog post I gave this answer:

    Well …first of all it could be a demand from auditors or data governance initiatives. Possible driven by external regulations.(Sarbanes-Oxley, Basel I, Basel II, HIPAA, ..)

    A second reason which can be tied to the first has to do with keeping control of / reporting on data quality issues in the source systems and thus:

    • Identify possible improvements in processes. (e.g. same data entered twice)
    • Increase / decrease confidence in the data, information and decisions

    The third reason has to do with agility. The ability to respond to changes rapidly. Small changes like changing a dimension attribute from type 1 to 2 or adding additional attributes to a dimension. But also large changes like big organizational changes, mergers, new ERP implementations. By having a persistent staging area  it’ll be far easier to respond to these changes and rebuild the data marts (with history). Resulting in quicker, better reporting after such a change.

    4. Data Vault

    The Data Vault is a special implementation of a persistent staging area. Source tables are split based on column aspects separating the structural items (business keys and the associations between the business keys) from the descriptive attributes.

    And thus the same advantages apply to the Data Vault as well. The power of the Data Vault comes from the integration on business keys. This approach is therefore especially suitable if you have source systems with overlapping information and/or if source systems change frequently over time.

    This wiki article by Ronald Kunenberg gives a nice overview of the Data Vault Methodology with a lot of additional references.


    In this article I discussed some aspects that you should consider when you choose an approach for (re)designing your Data Warehouse. This table summarizes these aspects:

    Aspect /  Approach: 1 2 3 4
    Simple, fast solution x      
    Only process delta rows   x x x
    Keep track of historical information   x x x
    Solve auditing / data governance issues     x x
    Control over data quality in source systems     x x
    Easily adapt to changing user requirements     x x
    Source systems with overlapping information       x
    Frequently changing source systems       x
  • ma
    sep 11

    Dimensional modeling and Data Vault – a happy marriage?

    A lot of emphasis on the Internet lately has been placed on the difference between both methods. This blogpost from Dan Linstedt and this discussion on the Kimball forums are examples of this strange focus.

    A focus I don’t totally understand since both techniques serve different purposes and can happily live together in most data warehouse solutions:

    • Data Vault is all about the back-room, efficiently collecting, integrating and preserving data from the source systems.
    • Dimensional modeling is all about the front-room, publishing the organization’s data assets to effectively support decision making.

    From a Dimensional modeling (Kimball) perspective Data Vault is an implementation of a persistent staging area. Problems that some people have with this view/name seem to boil down to the definition of what a data warehouse is. I personally don’t have a problem with this name nor do I consider it to be less important. And yes it will qualify as a data warehouse.

    Furthermore Dimensional modeling is generally acknowledged to be the best way to publish data to the business users and has a wide-spread adoption. A focus for further acceptance of Data Vault could be that it is the best implementation of a persistent staging area.

    So let’s try to make this case … but first:

    What are the reasons for having a persistent staging area?

    Well …first of all it could be a demand from auditors or data governance initiatives. Possible driven by external regulations.(Sarbanes-Oxley, Basel I, Basel II, HIPAA, ..)

    A second reason which can be tied to the first has to do with keeping control of / reporting on data quality issues in the source systems and thus:

    • identify possible improvements in processes. (e.g. same data entered twice)
    • increase / decrease confidence in the data, information and decisions

    The third reason has to do with agility. The ability to respond to changes rapidly. Small changes like changing a dimension attribute from type 1 to 2 or adding additional attributes to a dimension. But also large changes like big organizational changes, mergers, new ERP implementations. By having a persistent staging area (preferably integrated on business keys) it’ll be far easier to respond to these changes and rebuild the data marts (with history). Resulting in quicker, better reporting after such a change.

    Of course you need to balance these advantages against the extra costs. Before we take a look at these extra costs and other raised disadvantages let’s examine some …

    Similarities between Data Vault and Dimensional modeling

    Let’s first focus on the methodology of both approaches. They both advocate a bottom-up iterative implementation: Identify scope, select business area, build the solution and .. focus on a new iteration.

    Both use a limited number of strict table types with a well-defined function: Dimension- and fact tables in Dimensional modeling and hub-, link- and satellite tables in Data Vault modeling. Where a hub tables and its satellites typically roll-up into a dimension and a link tables and its satellites typically roll-up into a fact table.

    Another “fit” is the use of a volatile staging area as a synchronization- and recovery point.

    Focus on the extra costs

    Some would argue that since you are building two data warehouses you’ll end up with twice the costs. That’s seems far fetched … remember both use a staging area and the existence of the Data Vault area will make it easier to construct the Dimensional model on top of that. Furthermore Data Vault modeling lends itself (as does Dimensional Modeling to some extent) to automation, which greatly reduces costs of building and maintaining the data warehouse solution.

    Others complain about the extra storage that is needed to support this solution. Why store an extra copy of the source? Well I hope the described reasons for having a persistent staging area answer these questions. However you should of course take the extra storage costs into account when evaluating your choices. But please look at opportunity costs: Do you need an extra DBA or an extra SAN to support the extra layer?

    A third complaint has to do with query performance. It is suggested that the extra joins introduced with Data Vault modeling will impact query performance. This of course depends on size, hardware, database and indexing strategy. But even if there is a significant impact in most cases it won’t have a major effect. After all we are only using these queries to populate the Dimensional model and this will only apply to new and changed rows.


    Consider the combination of both methods when you are (re)building your data warehouse. In this blogpost I have given you some handles to evaluate this option. Do you need to keep control on data quality issues or do you want the agility to respond to changes quicker? Can you quantify these advantages? Compare them to the extra costs and make a better informed decision.

    And of course you can cont(r)act me if you want any help in this evaluation.

  • di
    apr 11

    Integration in the data vault

    And how we handle it in the DWH Deck

    One of the key characteristics of using the Data Vault modeling and methodology is the shift of a large part of the ETL work upstream in the data flow. In pictures:

    simple etl schema traditioneel datawarehouse

    Fig 1. Simple ETL schema in a traditional data warehouse


    simple etl schema datawarehouse with datavault

    Fig 2. Simple ETL schema in a data warehouse with the data vault architecture

    This shift comes with several advantages like:

    • auditable/traceable: we can recreate the source on a given day/time
    • flexibility: supporting (possible) multiple versions of the truth (e.g. when business rule change)

    Dan Lindstedt in his article: Data Vault series 5 - Loading practices even argues that you shouldn't touch or change the data on the way into the Data Vault, but manipulate it according to business rules on the way out - to the Data Marts. However there is still some ETL from the sources to the data vault:

    • The typical conversion into the data vault structure with hubs, links and satellites.
    • Some acceptable minor changes and default values (article 2.1.3 and 2.1.4 of the Data Vault loading specification)
    • Integration based on business keys.

    This integration based on business keys is a very powerful  aspect and sometimes overlooked. Consider the example of a large wholesaler with warehouses around the globe. By using a uniform business key for 'product' a lot of the integration already happens in a smooth way in the data vault. Creating the data marts and answering questions like what's the total stock for product xyz gets a lot easier this way.
    For more information on this subject, see the blogpost of Ronald Damhof and the discussions in the comment area.


    So how do we handle this integration in the DWH Deck?

    1. You can identify the business keys as described in Part 6 of the series describing DWH Deck's functionality.
    2. And make sure you use the same DWHName in de table section of the main application screen for all tables that describe the same object (e.g. Product)

    When you do this the SQL statement to create the data vault table will only be generated once. The SQL statements to create the view and ETL stored procedure to import the data will be generated for each table.

  • di
    dec 09

    Wat gaat goed en wat kan beter?

    Het nieuwe gratis e-book "What Matters Now" van Seth Godin en 70 meer of minder bekende vrienden bevat evenveel kort uitgewerkte ideeen steeds rond een woord. 
    Een mooi alternatief voor de bekende kerst- en nieuwjaars wensen.
    What matters now

    Het betoog hierin van Chip en Dan Heath, de schrijvers van "Made to stick" rond het woord "Change" bleef bij mij plakken:
    Het is het verhaal van Bobby een moeilijke leerling die naar de leerlingenbegeleider wordt gestuurd. Bobby is al zo vaak in problemen geweest dat de school op het punt staat om hem over te plaatsen naar een school voor moeilijk opvoedbare tieners.
    De meeste begeleiders zouden met Bobby zijn problemen besproken hebben. Zijn begeleider Murphy doet dat niet  maar vraagt: In welke klassen gaat het wel goed? Het antwoord en de uitleg waarom het zo goed gaat in de klas van juf Smith is de basis voor Murphy advies aan de leerkrachten. Die dit advies vervolgens opvolgen  waarna Bobby' zich inderdaad beter gaat gedragen.
    Deze focus op "Wat gaat goed?", "Hoe komt dat?" en "Hoe  kunnen we dat succes herhalen?" deed me denken aan  de pitchline die we gebruikten om uit te leggen wat we nou precieus doen met Business Intelligence: "Wat gaat goed en wat kan beter?" Met Business Intelligence kan je vaak goed antwoord geven op die twee vragen. Met rode en groene indicatoren brengen we ze extra onder de aandacht in onze rapporten en dashboards.

    In het vervolg traject hierop zijn het echter vaak de gebruikers van het BI systeem die hun aandacht richten op "Wat kan beter" Waar gaat het niet goed? Waar moeten we bijsturen... mensen aanspreken, hun bonus korten, ontslaan.

    Op zich niet verkeerd natuurlijk maar het echte goud krijg je pas als je je aandacht richt op de vraag "Wat gaat goed?" en "Hoe kunnen we dat succes herhalen?". Het antwoord op deze vragen leidt ongetwijfeld tot succesvollere producten, projecten en meer winstgevende klanten.

  • ma
    jul 09

    To datavault or not to datavault

    Toen ik een jaar geleden ofzo voor het eerst in aanraking kwam met het Data Vault concept voor het bouwen van een datawarehouse was ik niet onder de indruk. Het grote aantal relatief kleine tabellen leek me niet handig. Daarnaast had ik de indruk dat voor deze methode eerst  een volledige ontwerp van het datawarehouse gemaakt moest worden.
    En dat laatste ging wel erg tegen het principe  "Think Big, Start Small" in. Een principe waar ik veel waarde aan hecht.

    Na de diverse discussies in het Nederlandse BI wereldje en verdere verdieping in de materie kwam ik er achter dat ik behoorlijk fout zat met die eerste indruk.  Die kleine tabellen zorgen juist voor een grotere flexibiliteit waardoor het datawarehouse beter schaalbaar wordt maar vooral ook eenvoudiger aan te passen. Aanpasbaar aan nieuwe wensen, veranderende inzichten en gewijzigde bronsystemen.

    Had ik dat eerder geweten dan hadden mijn klanten fors bespaart op de onderhoudskosten van hun business intelligence oplossing.
    Daarom heb ik de cursus van Daniel Linstedt gevolgd, het examen gedaan en ben ik nu een "Certified Data Vault  Modeler"

  • ma
    jul 09

    Blind door gebrekkige managementinformatie?

    "Blinde trots breekt ABN AMRO" is de subtitel van het boek de Prooi van Jeroen Smit.

    Het is een reconstructie van bijna 20 jaar ABN AMRO geschiedenis en beschrijft de teloorgang van DE BANK. Het boek leest als een spannende whodunnit .. maar aan het einde weet je het nog niet echt.
    Wie is nu de schuldige?

    • De commissarissen, die half slapend genoten van de status van hun bijbaantje?
    • De besluitloosheid vanwege de ABN AMRO cultuur verschillen... Laten we vooral niet op elkaars tenen stappen… of wat vestigingen/functies  bij elkaar trekken.
    • De tomeloze -blinde- ambitie van een aantal kernfunctionarissen die duidelijk kwaliteiten bezaten maar onvoldoende om de toko te leiden.
    • Of toch die blinde trots die vaak leidde tot idiote voorwaarden bij fusie-/overnamegesprekken.

    Blind lijkt een sleutel woord.

    In het boek staan veel verwijzingen naar gebrekkige managementinformatie. Zo was het niet duidelijk waar het meeste geld verdiend werd en werden hierdoor verkeerde strategische keuzes gemaakt. Zoals de belangrijke, misschien wel cruciale beslissing in 2000 om fors in te zetten op de dienstverlening aan de grootzakelijke klanten. De klanten waarvan uit later onderzoek bleek dat er het minst op verdiend werd.
    Blind door gebrekkige managementinformatie dus.

    Laten we er daarom met onze Business Intelligence projecten ervoor zorgen dat onze klanten iets minder blind worden. Laten we ze inzicht geven in succesvolle klanten, producten, projecten en medewerkers en ook datgene en diegene die niet succesvol zijn. 

  • do
    jun 09

    Google's wave - rimpel of tsunami?

    Zo aan het begin van de zomer worden we overstroomd met nieuwe technische vindingen:

    • Filmen met je iPhone
    • Comeback van Palm met de Pre 
    • Microsoft's alternatief voor de mislukte Yahoo overname: Bing
    • En natuurlijk Google's Wave.

    Deze laatste is vanuit meerdere perspectieven waaronder business intelligence het meest interessant.

    Wat is het precies?
    Het is google's antwoord op de vraag "Hoe zou e-mail eruit zien als we het nu zouden uitvinden?"
    Een combinatie van e-mail, IM, twitteren, bloggen en discussie forum's en ziet er veelbelovend uit.

    Uit bovenstaand filmpje blijkt dat wave meer is dan een product. Het is ook een platform en een protocol en ... open source. Hierdoor is het door derden eenvoudig uit te breiden.

    Het business intelligence systeem van een willekeurige autoleverancier zou dan de volgende wave kunnen starten. Vervolgens de juiste personen binnen het bedrijf hier aan kunnen koppelen. Zodat ze volgens onderstaande manier hun bijdrage aan de wave kunnen leveren:

    Sterke stijging verkoop van oranje auto's in EMEA Regio

    Periode: 01-05-2009 tm 31-05-2009
    Signaal: stijging verkoop (+26%)
    Product: Oranje auto's
    Regio: EMEA

    Report Robot
    Ik wist het … het heeft even geduurd maar oranje wordt het helemaal deze zomer.
    Ik zal snel oranje verf bij bestellen en het produktieplan aanpassen.

    O'Carr - Product manager
    Ho ho … niet zo snel!!
    Deze stijging is een direct gevolg van een prijsactie van onze dealers.
    Zij zijn bang om met die "lelijke" auto's te blijven zitten.

    Mees - Sales manager EMEA Regio

    Zo'n discussie is natuurlijk nu al mogelijk op een apart discussie platform. (maar worden die voldoende bezocht?) Het voordeel van deze wave technologie is dat het de diverse communicatie kanalen combineert en dat de gebruiker nog maar één tool voor zijn communicatie met de rest van de wereld nodig heeft.

    Zal deze wave technology daarmee ooit e-mail vervangen?
    Is het een tsunami of een rimpel in de e-mail vijver?
    Ik weet het niet. 
    Maar als er een bedrijf is die dat voor elkaar kan krijgen dan is het Google.

  • ma
    feb 09

    Goed voor elkaar

    De controller van prospect BV M te W heeft het goed voor elkaar. Elke maandag verzamelt hij alle benodigde informatie en produceert een handzaam rapport met de belangrijkste kerncijfers over de voorgaande week. Het rapport wordt op dinsdag onder de MT-leden verspreid en vormt een belangrijk gespreksonderwerp in het MT-overleg van woensdag.

    Wij hadden het ook goed voor elkaar. Onze propositie met een centraal data warehouse, een wekelijkse inleesslag in het weekend, dashboards aangevuld met rapportages die voor elke gebruiker toegankelijk waren via het Intranet en dat alles tegen een alleszins redelijke prijs. Zeker als je die afzette tegen de vele voordelen:

    • Betere datakwaliteit;
    • Vernieuwde inzichten door de combinatie van informatie uit diverse bronsystemen;
    • Betere analyse mogelijkheden;
    • Snellere beschikbaarheid van informatie waardoor eerder beslissingen genomen kunnen worden;
    • Minder belasting voor de transactiesystemen die bij het opvragen van sommige rapporten nu vaak voor een irritante traagheid zorgen. Deze rapporten zouden sneller draaien op ons data warehouse en de transactiesystemen niet belasten.
    • (Hopelijk) minder papierverspilling;
    • Minder 'simpel' werk bij productie- en verspreiding van rapporten waardoor meer tijd voor analyses en ander 'zinvoller' werk.

    We dachten dat we het goed voor elkaar hadden: deze opdracht konden we niet verliezen.
    Totdat we de reactie van de controller kregen. Hij opende nogal kwaad de kast achter zich met daarin de 26 ordners van het afgelopen half jaar. Dus jullie bedoelen dat ik die niet meer nodig heb!  ..euh, Ja dat bedoelen we... En het is ook niet meer nodig dat ik elke maandag overwerk!? ..euh, Ja.

    Helaas sommige mensen houden van overwerk.

  • di
    feb 09

    Immateriële waardecreatie en le roi

    Louis XIVUit onderzoek van McKinsey blijkt dat de beurswaarde van de 150 grootste ondernemingen in 2005 gemiddeld 260% van hun boekwaarde bedroeg. In 1985 was dit nog slechts 160%.

    De gigantische immateriële waardecreatie van deze bedrijven tot $ 7,5 miljard in 2005 is voor een groot deel toe te schrijven aan een gestegen productiviteit van werknemers: Deze bedrijven realiseerden in 2005 $ 66.000 netto winst per werknemer. In 1985 was dat nog maar $ 24.000.

    Kantoorautomatisering, ERP en ook BI hebben ongetwijfeld bijgedragen aan deze verbeterde productiviteit.

    Gezien de grote omvang van de immateriële  waarde van veel bedrijven komt het bij mij vreemd over dat bij de beoordeling van (IT) projecten roi nog steeds koning is. Een beoordeling op hun mogelijkheid om waarde te creëren zou een belangrijker rol moeten spelen.
    Minder aandacht dus voor zekere kostenbesparingen en meer voor de onzekere kansen die door bijvoorbeeld beter inzicht en transparantie ontstaan.

    Bron cijfertjes: Talent aan zet van Bryan en Joyce ISBN:9789047000235