I’m working on the “reporting” team that uses Business Objects XI (and soon to be “BI Suite”), against an Oracle database.
It’s a legacy system, and it has your traditional reports, plus the users create their own reports. But there’s not much in the way of dashboards, business intelligence, and analytics. The data is straightforward - it’s an education institution with military instruction - no financials.
So I’m looking for some good resources for overall BI strategy (and principles), before one even gets to architecting a solution. One principle that I see that needs addressed is “who owns the data?” (as I see, it the users own the data. IT then provides tools to access the data, and to secure the data).
And then need to learn how to implement a strategy with BI Suite.
No, it’s not SCN, it’s more of an open discussion board so you’re not spammed with 15 hopeful but not always helpful replies! You’ll find most people on here reply because they have something to offer rather because there are points on offer.
also, in a cursory review of Kimball’s books, my observation is that BI/DW is all about dimensional modeling ? Is that right ?
I have been doing traditional normalized d.b. development for years, I can write wicked Sql statements, but never made the leap to BI / dimensional modeling.
Yes, data warehouse building is about building dimensional models - your model will reflect the bus matrix that Kimball discusses rather than the transactional model of your OLTP. After all, it’s likely that your data will be sourced from more than one place in the long term. Short term, Kimball-based approach is data mart → data warehouse and it may initially be from one source. Longer term, or Inmon-based design the whole data warehouse at the start would identify multiple sources.
So I’ve never made the leap to DW / BI (Dimensional Modeling), but since DW / BI translates to dimensional modeling, then
I need to learn dimensional modeling
the organization needs to understand the need for it
then users have to be trained . . .
Also, as I see it, users are happy to write ugly, list based reports from a normalized d.b., so they wouldn’t know dimensional modeling if it hit them over the head. And I can spell it . . . but I’m the IT guy.
And it kind of sounds like a major overhaul, a new paradigm, and also a way of thinking . . .
Key things to consider. Let’s say you want to determine the percentage (or value) of mortgage payments successfully made by marital status.
In your relational system, you probably won’t have a history of marital status, you’ll just change it in a drop-down field. (It’s probably not a great example because you generally wouldn’t keep track, but it’s an example).
Over the last ten years, Dave has been single for three years, married for five and widowed for two (in that order you’d expect!). Therefore you’d need to assign three different rows in the customer dimension to Dave, reflecting his marital status at the time of the mortgage payment. With dimensional modelling you’d use an apporach called “Slowly Changing Dimensions” and each of Dave’s entries would have a unique surrogate key (with all entries having the same customer key and different effective dates). You’d have a payments fact table and each of Dave’s payments would be tagged with one of the three surrogate keys, depending upon when the transaction took place. As such, you’d be able to join quickly (inner equi-join on indexed integer columns) and report quickly on Mortgage performance.
So, the two go hand in hand. Is there a business requirement to move from basic lists to trend reports and behaviour analysis? There was the beer and nappies breakthrough back in the 90s; a retail company’s data warehouse established that there was a strong correlation between people buying nappies and canned beer (presumably due to staying in more). There could be other breakthroughs in your industry that you might not be able to make without trend data. Have a look (google) at trend data in your industry and see what other organisations/publications have done. You may be able to use these as part of a business case to get a warehouse started. Again, think of linking two systems together and reporting off them without hundreds of vlookup formulae in Excel. Think of other balancing exercises and decision making that could be done - a data warehouse is built to answer business questions; do you have enough questions to justify one?
or just dive in to Kimball and hope no one asks what about Inmon’s approach ?
This get’s back to my original question / concern. If I just started whacking away at Kimball, might I be missing something entirely ? like what is the right approach for my organization ?
If a data warehouse is an unknown concept, it’s cheaper and safer to start with the Kimball approach. Inmon pretty much is the opposite. Open budget, nail the whole data warehouse design and do it all. Kimball will allow you to deliver more quickly - as soon as you’ve delivered a single fact table and its dimensions you can put a universe over it. You can then have universe design lag one phase behind warehouse build; as they start the next fact table design and load, you can add the fact that they’ve just delivered to the universe.
So, we get to the magic question. What order do you build the fact tables in? The simplest answer is build the ones which can be the source for most reports first. I’d suggest starting with a fact table that can be built and populated easily and can be used for a meaningful report on its own - sales or some other popular transaction within your organisation. The other option is to prioritise the reports and then determine what fact tables are needed for the highest priority reports.
I’d personally suggest that you go with the Kimball approach - delivering early and steadily throughout the whole data warehouse build will give people confidence. Make sure reports go out correctly though; come 2018 people won’t remember if you were two months late delivering in 2015 but they still won’t be using a data warehouse that they cannot trust.
Business intelligence seems to be a vast subject to learn. While to know about its strategies you have to go in deep for this. The numerous concept allied to this you have to focus on are .
1 .Data Sourcing
2. Data warehousing.
3. Business Analytics.
4. Dashboards.
5. Performance.
5. ROI’s
Gadsden_Consulting. Where do you start? Start by reading The Datawarehouse toolkit by Kimball. It will give you many first principles for data modelling and many principles adopted by many BI tools. Then read his ETL book. Unless you want to go down the Inmon route in terms of datawarehousing. It`s all good grounding.
(BOB member since 2015-06-18)
(BOB member since 2006-02-08)
(BOB member since 2003-11-27)
(BOB member since 2015-09-22)
