Scribd
Upload
5 views3 pages

AIS Prof 1

The document debunks several myths about dimensional models in data warehousing, emphasizing their importance for detailed data access, scalability, and integration across business processes rather than departmental silos. It advocates for designing models based on stable measurement processes and aligning IT with business management to enhance data utility. Additionally, it highlights the relevance of agile methodologies in delivering business value through iterative development and collaboration with stakeholders.

Uploaded by

Zee 24
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
5 views3 pages

AIS Prof 1

The document debunks several myths about dimensional models in data warehousing, emphasizing their importance for detailed data access, scalability, and integration across business processes rather than departmental silos. It advocates for designing models based on stable measurement processes and aligning IT with business management to enhance data utility. Additionally, it highlights the relevance of agile methodologies in delivering business value through iterative development and collaboration with stakeholders.

Uploaded by

Zee 24
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 3

Myth 1: Dimensional Models are Only for Summary Data

 Unpredictable Queries: Business users often have diverse and unpredictable


questions. Therefore, they need access to the most detailed data. This detailed data
allows them to create custom summaries based on their specific questions.
 Granular Data: Data at the lowest level of detail is highly valuable because it
remains unaffected by changing requirements or unforeseen questions.
 Performance Enhancement: Summary data is useful but should only be used to
enhance the performance of common queries. It should not replace detailed data,
which is essential for comprehensive analysis.
 Historical Data Storage: Another related misconception is that dimensional models
can only handle a limited amount of historical data. In reality, dimensional models are
capable of storing extensive historical data. The amount of history kept should be
determined by the business needs, not by the limitations of the model.

Myth 2: Dimensional Models are Departmental, Not Enterprise

 Dimensional Models Organize Around Business Processes. Instead of creating


data models based on departmental boundaries, the recommendation is to structure
them around business processes, such as processing orders, generating invoices, and
handling service calls.
 Why Business Processes? The reason for this approach is that multiple
departments often need to analyze the same set of metrics that result from these
business processes. For example, both the sales and finance departments might be
interested in analyzing order data, but from different perspectives.
 Avoiding Data Silos. When data models are created separately by different
departments, it can lead to multiple, inconsistent versions of the same data. This
creates what’s known as data silos, where each department has its own isolated data
that may not align with other departments’ data.

Myth 3: Dimensional Models are Not Scalable

 Dimensional Models Are Extremely Scalable. In fact, they can handle a large
volume of data without performance issues. There are reports of fact tables
containing as many as 2 trillion rows.
 Vendor Support. Database vendors have recognized the importance of DW/BI and
have been continuously enhancing their products to support the scalability and
performance of dimensional models.
 Logical Content. Both normalized (traditional relational models) and dimensional
models contain the same information and data relationships. In other words, the
logical content—the data and its relationships—remains the same in both models.
Any data relationship expressed in one model can be expressed accurately in the
other.
They can also answer the same queries. However, the ease of answering these
queries may vary. Dimensional models are often more user-friendly for analytical and
reporting purposes, making it easier to extract insights from the data.

Myth 4: Dimensional Models are Only for Predictable Usage.


 Dimensional models should not be designed with a narrow focus on specific reports or
analyses, because such a design would only be valuable if those reports are needed.
Instead, the design should prioritize the measurement processes that underpin the
organization’s operations. These measurement events are typically more stable over
time, whereas reports and analyses often evolve to meet changing business needs.
 While it’s important to account for the requirements of business intelligence (BI)
applications, including the filtering and labeling of data, the design should not be overly
centered on producing a predetermined set of top reports. A rigid focus on specific
reports can lead to a model that constantly needs revision as new reporting
requirements emerge.

Myth 5: Dimensional Models Can’t Be Integrated.

Definitions across the organization. Achieving this standardization requires


significant effort to reach organizational consensus and implement the corresponding
ETL rules. This effort is necessary regardless of whether you are using normalized
(traditional relational) or dimensional models.
 Avoiding Standalone Solutions. If presentation area databases do not follow the
bus architecture and do not use shared conformed dimensions, they tend to become
standalone solutions. These standalone solutions lack the integration and consistency
provided by the bus architecture.
 Fundamental Tenet of Dimensional Modeling. Dimensional modeling inherently
supports integration when its principles are followed. Therefore, the failure to
integrate dimensional models often results from not embracing the fundamental
tenets of this approach, rather than any inherent limitations of the models
themselves.
MORE REASONS TO THINK DIMENSIONALLY

 Listen for and synthesize findings around business processes: When starting
a DW/BI project, gather requirements by focusing on business processes rather than
predefined reports. Understand the entire process (e.g., sales process from lead
generation to closing deals) to build a comprehensive and flexible data model based
on stable business processes.
 Align IT and business management: Ensure IT and business management
perspectives are aligned by focusing on process-based data organization instead of
departmental boundaries. Collaborate with business leaders to prioritize business
processes based on value and feasibility, ensuring both IT and business management
work towards the same goals for an effective and actionable DW/BI initiative

AGILE CONSIDERATIONS

Agile Development Practices in DW/BI. There is currently a lot of interest in agile


development practices within the data warehousing and business intelligence (DW/BI)
industry. Agile methodologies focus on completing manageable increments of work within
reasonable timeframes, typically measured in weeks. This approach reduces the risk
associated with larger projects that have longer timelines for deliverables.

Many core principles of agile methodologies align with Kimball best practices, including:
 Focus on delivering business value: This principle is fundamental to Kimball’s
approach, which emphasizes that data warehousing and BI initiatives should always
aim to provide tangible benefits to the business.
 Value collaboration between the development team and business
stakeholders: Close partnerships and active collaboration between the
development team and business stakeholders are crucial. Kimball highlights the
importance of understanding business needs and ensuring that solutions align with
those needs.
 Stress ongoing face-to-face communication, feedback, and prioritization
with business stakeholders: Continuous communication and feedback loops with
business stakeholders help ensure that the project remains aligned with business
priorities and can adapt to changing needs.
 Adapt quickly to evolving requirements: Flexibility and agility are key. Kimball
advocates for being responsive to new requirements and changes in the business
environment.
 Tackle development in an iterative, incremental manner: Kimball recommends
an iterative and incremental approach to development. This method involves
delivering small, manageable pieces of functionality in stages, allowing for
continuous improvement and adjustment based on feedback.

You might also like