Data Warehouse Architecture and Implementation
No doubt Data Warehouse solutions is a widespread, mainline, best practise way to go.
And there are many good examples across all types of businesses and size of companies.
The principal approach to Data Warehouse is - without doubt - the
Kimball approach (cf. the list of books in the sidebar to the right). If you are not familiar with it - I urge you to buy his books (cf. to the right) and maybe also attend some of courses / seminars on the subject.
Note that Data Warehouse and Business Intelligence are not synonymous. One might consider Business Intelligence as the encompassing part. Whichever way you prefer to see it, Data Warehouse is the foundation for Business Intelligence.
The role of the Data Warehouse is to collect data, turn it into information and provide said information to end-users, who are using Business Intelligence tools.
I have a separate page on Data Warehouse challenges
here.
Best practise Data Warehouse
I will not repeat the comprehensive literature, courses and conferences on the subject of Data Warehouse. Instead I provide a simple checklist of what I consider best practise:
Basic recommandations / features
- Alignment with the Business (Concept Model)
- Multidimensional modelling
- The Kimball approach
- Data Warehouse Bus architecture (part of the Kimball approach)
- Enterprise Data Warehouse architecture (hub-and-spoke)
- Users have access to data marts (only)
- Persistent data staging area
- Data profiling and quality assurance
- Full version history on all dimensions
- Fully automatated ETL-processes
- Mappings, validations and calculations fully documented(!)
Advanced recommandations / features
- Incremental load where necessary
- Full support for slowly changing dimensions (cf. Kimball)
- Data Governance described and implemented
- Automated Data Profiling (eg. using ProfileToSQL with Microsoft SQL Server)
- Master Data Management
- Metadata administration
- Data lineage