Cookies help us display personalized product recommendations and ensure you have great shopping experience.

By using this site, you agree to the Privacy Policy and Terms of Use.
Accept
SmartData CollectiveSmartData Collective
  • Analytics
    AnalyticsShow More
    image fx (67)
    Improving LinkedIn Ad Strategies with Data Analytics
    9 Min Read
    big data and remote work
    Data Helps Speech-Language Pathologists Deliver Better Results
    6 Min Read
    data driven insights
    How Data-Driven Insights Are Addressing Gaps in Patient Communication and Equity
    8 Min Read
    pexels pavel danilyuk 8112119
    Data Analytics Is Revolutionizing Medical Credentialing
    8 Min Read
    data and seo
    Maximize SEO Success with Powerful Data Analytics Insights
    8 Min Read
  • Big Data
  • BI
  • Exclusive
  • IT
  • Marketing
  • Software
Search
© 2008-25 SmartData Collective. All Rights Reserved.
Reading: Entry Point: Architecture or Crumbling Foundation
Share
Notification
Font ResizerAa
SmartData CollectiveSmartData Collective
Font ResizerAa
Search
  • About
  • Help
  • Privacy
Follow US
© 2008-23 SmartData Collective. All Rights Reserved.
SmartData Collective > Big Data > Data Mining > Entry Point: Architecture or Crumbling Foundation
Data MiningData Warehousing

Entry Point: Architecture or Crumbling Foundation

DataQualityEdge
DataQualityEdge
3 Min Read
SHARE

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:

  1. Data retrieval times will increase
  2. Data retrieval will become more difficult
  3. The integration and migration of projects will become cumbersome
  4. 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.”

More Read

The Napoleonic Wars – Timely and Near Enough was Good Enough
Successful Business Intelligence Projects: The Role of Managers and Leaders
Auto-correlation for time series analysis
Smart grid is attractive on a number of levels. For one thing, a…
Travel funding available for UseR! and DSC 2009

When building your data warehouse, remember to:

  1. Ensure you size it properly and measure future capacity for continuous growth
  2. If bad data does occur, have your data analysts cleanse it; and don’t build overly complicated data models — remember the KISS principle
  3. Improve speed to delivery and reaction time
  4. Improve query and data retrieval times

When defining your architecture and/or database system remember the following…


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:

  1. Data retrieval times will increase
  2. Data retrieval will become more difficult
  3. The integration and migration of projects will become cumbersome
  4. 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:

  1. Ensure you size it properly and measure future capacity for continuous growth
  2. If bad data does occur, have your data analysts cleanse it; and don’t build overly complicated data models — remember the KISS principle
  3. Improve speed to delivery and reaction time
  4. 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:

  1. Define the objective of the data warehouse
  2. Research the data and datasets (understand the business and its processes)
  3. Design the data model
  4. Define the database relationships
  5. Define rules, triggers and constraints
  6. Create views and/or reports
  7. Implement it.
TAGGED:architecturedata quality
Share This Article
Facebook Pinterest LinkedIn
Share

Follow us on Facebook

Latest News

image fx (2)
Monitoring Data Without Turning into Big Brother
Big Data Exclusive
image fx (71)
The Power of AI for Personalization in Email
Artificial Intelligence Exclusive Marketing
image fx (67)
Improving LinkedIn Ad Strategies with Data Analytics
Analytics Big Data Exclusive Software
big data and remote work
Data Helps Speech-Language Pathologists Deliver Better Results
Analytics Big Data Exclusive

Stay Connected

1.2kFollowersLike
33.7kFollowersFollow
222FollowersPin

You Might also Like

Data Quality, Collaboration and Baseball

5 Min Read

The Data-Information Continuum

7 Min Read

DQ-Tip: “Don’t pass bad data on to the next person…”

3 Min Read

5 Lessons Social CRM can Learn from CRM

8 Min Read

SmartData Collective is one of the largest & trusted community covering technical content about Big Data, BI, Cloud, Analytics, Artificial Intelligence, IoT & more.

ai chatbot
The Art of Conversation: Enhancing Chatbots with Advanced AI Prompts
Chatbots
ai in ecommerce
Artificial Intelligence for eCommerce: A Closer Look
Artificial Intelligence

Quick Link

  • About
  • Contact
  • Privacy
Follow US
© 2008-25 SmartData Collective. All Rights Reserved.
Go to mobile version
Welcome Back!

Sign in to your account

Username or Email Address
Password

Lost your password?