Let us talk for a moment about architecture.
Good architecture is built to last, to withstand the elements and the test of time. Good data architecture will allow you to extract data quickly, will help prevent data errors from occurring, and promote easy integration of future data assets.
With bad architecture, the following will persist like vermin in your basement:
- Data retrieval times will increase
- Data retrieval will become more difficult
- The integration and migration of projects will become cumbersome
- The creation and spread of bad data will be more likely
Soon the walls around you will begin to crumble as more and more data becomes questionable. Your users will question the data, and eventually your system will become synonymous with the term “poor data quality.”
When building your data warehouse, remember to:
- Ensure you size it properly and measure future capacity for continuous growth
- If bad data does occur, have your data analysts cleanse it; and don’t build overly complicated data models — remember the KISS principle
- Improve speed to delivery and reaction time
- Improve query and data retrieval times
When defining your architecture and/or database system remember the following steps to help prevent bad architecture from occurring:
- Define the objective of the data warehouse
- Research the data and datasets (understand the business and its processes)
- Design the data model
- Define the database relationships
- Define rules, triggers and constraints
- Create views and/or reports
- Implement it.
