170 likes | 308 Views
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
E N D
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 • Performance issues of transaction DB • Reporting is complex • Disparate databases - No integrated view of the whole company • Transaction systems discard history
What we need to solve these • Subject Oriented • Integrated • Time variant • Non volatile
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)
Traditional BI Development Success? $
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
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
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
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) $
Traditional BIArchitecture (e.g. Cognos Rpt Studio) Source DB 1 Point & click to generate SQL Database –Operational or Informational Source DB 2 Format presentation
QlikView Architecture Point & click to generate Query Associative DB Source DB 1 Data Warehouse Format presentation