1 / 17

The Death of the Data Warehouse

The Death of the Data Warehouse. Michigan Oracle User Summit 14 November 2012. The Business Problems We’re Trying to Solve w/ DW & BI?. Business people can’t get to their data Running summary reports out of transaction databases is very slow P erformance issues of transaction DB

glenda
Download Presentation

The Death of the Data Warehouse

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. The Death of the Data Warehouse Michigan Oracle User Summit 14 November 2012

  2. The Business Problems We’re Trying to Solve w/ DW & BI? • Business people can’t get to their data • Running summary reports out of transaction databases is very slow • Performance issues of transaction DB • Reporting is complex • Disparate databases - No integrated view of the whole company • Transaction systems discard history

  3. What we need to solve these • Subject Oriented • Integrated • Time variant • Non volatile

  4. What we create

  5. The Traditional DW Model • Complexities • Technologies to master • Data modeling • ETL • BI • DBA • Workplan steps to complete • Design data mart databases • Design DW databases • Design BI tool metadata • Build flows from source systems to DW • Build flows from DW to data marts • Build BI metadata • Result • Time consuming • Brittle (e.g. change to one column in the source ripples through architecture)

  6. Traditional BI Development Success? $

  7. Data Warehouse Definition – The Physical DB Implications • Subject Oriented • Integrated • Time variant • Non volatile This is a LOGICAL definition, not a physical one – it says nothing about how the data must be stored or accessed

  8. New Generation of BI Tools (QlikView, Tableau, etc.) • They contain their own, non-relational, self-managing data stores. • They can import data from multiple sources into a single, accessible data store. • They join related data together, like a relational database. • They provide predictable, blisteringly fast query performance • They provide very easy, user-friendly user interfaces. • They can contain, and rapidly summarize, atomic-level, granular data. • They can be incrementally refreshed, enabling the storage of history. These tools meet the definition of a data warehouse but are far more efficient

  9. The Traditional DW Model TRADITIONAL • Complexities • Technologies to master • Data modeling • ETL • BI • DBA • Workplan steps to complete • Design data mart databases • Design DW databases • Design BI tool metadata • Build flows from source systems to DW • Build flows from DW to data marts • Build BI metadata • Result • Time consuming • Brittle (e.g. change to one column in the source ripples through architecture) NEW WORLD • Complexities • Technologies to master • In memory tool • Workplan steps to complete • Build flows from source systems to DW • Build reports • Result • Agile • Easily revised

  10. Preferred Model of BI Development User Input Dev & Rvw Yes User Input Dev & Rvw Yes User Input Dev & Rvw No No Quit Quit Develop DW in Parallel with Input from BI (If Necessary) $

  11. In Memory Advantages & Disadvantages

  12. Questions?

  13. Traditional BIArchitecture (e.g. Cognos Rpt Studio) Source DB 1 Point & click to generate SQL Database –Operational or Informational Source DB 2 Format presentation

  14. QlikView Architecture Point & click to generate Query Associative DB Source DB 1 Data Warehouse Format presentation

  15. Demo

More Related