• Home
  • About
  • Blog
  • Speaking
  • Contact

Creating my first Datawarehouse from scratch: The Analysis!

10 July 2014SQL StijnGeen categorieNo Comments

It all started about a month ago, I got my first big assignment as a junior. The assignment was quite simple, design and implement a datawarehouse from scratch from a production system of an enterprise. Although the description of my assignment was quite simple, putting this assignment into practice proved to be a lot of work.

 

In the upcoming posts I will be discussing the different technologies I used to create my Datawarehouse and I will discuss the more technical aspects of how I designed the DWH. But in this post I would like to talk a bit about the first part of the creation of a Datawarehouse, namely the Analysis with the Business people.

During the first 3 days of my new assignment, the company for which I was going to design the Datawarehouse, arranged for me and a Senior Analyst of my company to meet with the Business people who would be using our Datawarehouse for reporting. The question that instantly popped into my mind before this meeting was, how do you do an analysis of a Datawarehouse? And that’s what I will be explaining in this post.

The first thing you have to realize is that the business people probably have no clue about how a Datawarehouse is designed and how it works, so we started off with giving them an introduction of what we will be designing and why this will make their life a lot easier. Because a Datawarehouse makes reporting much easier, the Business people will be able to know how their company is doing a lot faster than when you are creating reports from a production system. And that are 2 things people from the business side like to hear, it is fast and it is easy. J

We proceeded then by asking them what reports they currently have, and what reports they would like to have in the future. We created a document with all the specs of the reports and used this as a base for the analysis. We started going over this document point by point, and in the process creating the necessary fields in a Visio Entity Diagram on a big screen in the meeting room, so that people could see what we were designing and could comment instantly if there was something we misunderstood or explain what they did not understand. This proved to be a very effective way to create a datawarehouse diagram in a minimum amount of time.

The analysis of the source fields of our datawarehouse is something we did not discuss during these 3-day meeting with Business, as this is a more technical aspect & this is something that is not interesting nor relevant for a Business person.

In my next post I will be talking a bit more about the way I found the source fields of my datawarehouse and how I checked the dataquality.

Thanks for reading and see you soon!

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Recent Posts

  • Building a Modern Lakehouse Data Warehouse with Azure Synapse Analytics: Moving your Database to the lake
  • Azure Synapse Dedicated SQL Pools: Workload Management
  • Synapse Spark – Playing with Data Frames with Python
  • Synapse Spark – Reading CSV files from Azure Data Lake Storage Gen 2 with Synapse Spark using Python
  • Azure Synapse Analytics – Serverless SQL Pools: Data Elimination

Recent Comments

    Archives

    • June 2022
    • December 2021
    • May 2021
    • April 2021
    • March 2021
    • February 2021
    • January 2021
    • December 2020
    • August 2016
    • July 2016
    • March 2016
    • February 2016
    • December 2015
    • October 2015
    • August 2015
    • March 2015
    • December 2014
    • November 2014
    • July 2014
    • February 2014
    • January 2014
    • December 2013

    Categories

    • Azure Synapse Analytics
    • Building a Modern Lakehouse Data Warehouse
    • Geen categorie
    • MS PDW
    • SQL 2016
    • SQL Maintenance
    • SQL Server Migration
    • SQL Server Misconfiguration Chronicles
    • SQL2014
    • Troubleshooting

    Contact Stijn now


    © SQL Stijn 2017 - Privacy Policy - Cookie Policy
    Manage Cookie Consent
    To provide the best experiences, we use technologies like cookies to store and/or access device information.
    Functional Always active
    The technical storage or access is strictly necessary for the legitimate purpose of enabling the use of a specific service explicitly requested by the subscriber or user, or for the sole purpose of carrying out the transmission of a communication over an electronic communications network.
    Preferences
    The technical storage or access is necessary for the legitimate purpose of storing preferences that are not requested by the subscriber or user.
    Statistics
    The technical storage or access that is used exclusively for statistical purposes. The technical storage or access that is used exclusively for anonymous statistical purposes. Without a subpoena, voluntary compliance on the part of your Internet Service Provider, or additional records from a third party, information stored or retrieved for this purpose alone cannot usually be used to identify you.
    Marketing
    The technical storage or access is required to create user profiles to send advertising, or to track the user on a website or across several websites for similar marketing purposes.
    Manage options Manage services Manage vendors Read more about these purposes
    View preferences
    {title} {title} {title}