Data Warehousing

Chapter 2
Enterprise Architecture and Warehouse Models

Post Graduate Program in IT Engineering
Data Warehousing • Post Graduate

Enterprise Architecture and Warehouse Models

Introduction

Data warehousing is not merely the construction of a large database for reporting. It is an architectural discipline concerned with how an organization integrates data, defines business meaning, preserves historical context, supports analytical workloads, and governs access to information. Architecture determines where data is stored, how it is transformed, how quickly it becomes available, who owns its definitions, and how easily the environment can evolve.

At postgraduate level, warehouse architecture should be understood as a set of design choices rather than a single universally correct pattern. An organization may select an enterprise warehouse, a dimensional bus, a hub-and-spoke structure, a federated approach, a virtual warehouse, Data Vault, or a hybrid combination. The correct decision depends on organizational size, regulatory obligations, source-system complexity, analytical priorities, skills, budget, and tolerance for change.

Two influential schools dominate the historical debate. Bill Inmon’s approach emphasizes a centralized, integrated enterprise data warehouse, commonly modeled in normalized form. Ralph Kimball’s approach emphasizes dimensional data marts integrated through conformed dimensions and a bus architecture. Contemporary practice frequently combines these ideas with Data Vault, lakehouse platforms, semantic layers, and virtualization.

The central argument of this chapter is that architecture must be evaluated against requirements. A technically elegant model can fail if it does not deliver timely information, preserve traceability, support governance, or gain organizational adoption.

Learning Objectives

By the end of this chapter, students should be able to:

1. Explain the purpose and major components of enterprise data warehouse architecture.

2. Compare enterprise warehouse, dimensional bus, hub-and-spoke, federated, virtual, and Data Vault approaches.

3. Distinguish the assumptions and strengths of Inmon, Kimball, and hybrid architectures.

4. Select an architectural approach using organizational, technical, and governance criteria.

5. Analyze trade-offs involving integration, agility, performance, history, ownership, cost, and risk.

6. Apply architectural reasoning to a realistic enterprise case.

1. Architecture as an Enterprise Design Decision

A data warehouse architecture describes the logical and physical arrangement of data sources, ingestion mechanisms, storage layers, transformation processes, metadata, security controls, analytical interfaces, and users. It also describes the flow of data and the responsibilities associated with each layer.

A typical analytical environment contains the following elements:

Source systems: operational databases, enterprise applications, files, APIs, sensors, and external data services.
Ingestion and integration: batch extraction, change data capture, streaming, validation, reconciliation, and data-quality handling.
Persistent storage: raw, integrated, historical, curated, or dimensional data stores.
Transformation and modeling: processes that standardize, integrate, aggregate, and expose data for analysis.
Metadata and lineage: descriptions of data structures, definitions, transformations, ownership, and quality.
Consumption layer: dashboards, reports, analytical notebooks, machine-learning pipelines, and ad hoc queries.
Governance and security: access control, privacy protection, retention, auditability, stewardship, and compliance.

Architecture is different from a data model. A data model describes structures and relationships, whereas architecture describes the broader system in which those models operate. Architecture is also different from a technology product. Cloud warehouses, relational database management systems, lakehouses, and query engines are implementation technologies; they do not by themselves determine whether the organization follows a bus, hub-and-spoke, virtual, or hybrid strategy.

Architectural quality attributes

Architectural alternatives should be evaluated using explicit quality attributes:

Integration: Can data from different systems be reconciled using common definitions?
Historical fidelity: Can the organization reconstruct what was known at a previous time?
Timeliness: How quickly can new or changed data become available?
Performance: Can expected workloads meet service-level requirements?
Agility: How easily can new sources, metrics, and business processes be added?
Governance: Are ownership, definitions, lineage, security, and controls clear?
Scalability: Can volume, user populations, and analytical complexity grow?
Maintainability: Can the system be understood and changed without excessive risk?
Cost efficiency: Are platform, development, operations, and opportunity costs acceptable?

No architecture maximizes all these attributes simultaneously. For example, strong central integration may increase consistency but reduce local autonomy and slow delivery. Extensive virtualization may reduce data duplication but place greater demands on source systems and query optimization.

2. Fundamental Warehouse Models

2.1 Enterprise data warehouse

An enterprise data warehouse (EDW) is a centrally managed repository that integrates data across major organizational domains. Its purpose is to provide a consistent, historical, and enterprise-wide information foundation. An EDW normally includes standardized definitions for customers, products, organizations, time, transactions, and other shared concepts.

The classic EDW emphasizes centralized control and integration. Data is usually extracted from operational systems, cleansed and standardized, integrated in an enterprise layer, and then delivered to reporting or departmental data marts. The central repository may use normalized structures to minimize redundancy and represent complex enterprise relationships.

The EDW is appropriate when:

regulatory reporting requires reconciled enterprise figures;
many departments must use common definitions;
cross-functional analysis is strategically important;
data lineage and centralized stewardship are essential; and
the organization can support a substantial integration program.

Its principal limitation is that the enterprise model can become a lengthy prerequisite for delivering business value. If every analytical requirement must wait for a complete enterprise design, delivery may be slow. Central governance can also become a bottleneck when decision rights are unclear.

2.2 Dimensional bus architecture

A dimensional bus architecture organizes analytical delivery around business processes and conformed dimensions. A fact table records measurable events at a declared grain, such as one row per order line, claim, shipment, or account-day. Dimension tables provide descriptive context, such as customer, product, location, and date.

The bus is not simply a collection of unrelated data marts. Its integration mechanism is the use of conformed dimensions and, where appropriate, conformed facts. A customer dimension used by sales, service, and finance should have compatible keys, attributes, and meanings. This allows separate marts to be queried together without producing semantic contradictions.

Kimball’s dimensional approach usually delivers business-process-oriented marts rapidly. It favors ease of use, predictable query performance, and direct support for reporting. It is particularly effective when an organization can identify high-value processes and deliver them incrementally.

Its risks include inconsistent dimensions if conformance is weak, proliferation of marts, duplicated transformation logic, and difficulty representing highly complex operational relationships. A dimensional model also requires careful management of changing dimensions, grain, surrogate keys, late-arriving data, and historical rules.

2.3 Hub-and-spoke architecture

In a hub-and-spoke model, a central integrated warehouse acts as the hub, while dependent data marts or analytical stores act as spokes. The hub establishes enterprise integration and governance; spokes tailor data for departments, applications, or performance requirements.

The model can be implemented with normalized or other integrated structures in the hub and dimensional structures in the spokes. It therefore separates enterprise integration from departmental presentation. This is useful where different users require different levels of abstraction but must still rely on a common information foundation.

The hub-and-spoke model is stronger than an uncontrolled collection of marts because spokes depend on a governed center. However, the hub may become a delivery bottleneck, and the architecture can involve significant duplication as data moves from the hub into multiple spokes. Effective service-level agreements and clear ownership are necessary.

2.4 Federated architecture

A federated warehouse coordinates multiple autonomous data environments rather than replacing them with one fully centralized repository. Integration may be achieved through shared metadata, semantic standards, master-data services, common identifiers, data contracts, query federation, or carefully governed data products.

Federation is attractive in large, decentralized organizations, especially after mergers or where business units have strong autonomy. It can preserve local ownership and reduce the disruption of replacing existing platforms. It is also compatible with distributed and domain-oriented data-product strategies.

The principal challenge is semantic consistency. A federated architecture can provide the appearance of integration while leaving unresolved differences in definitions, timing, quality, and identity. Federation therefore requires strong standards, stewardship, metadata, and mechanisms for resolving conflicts. It is not equivalent to merely connecting databases with a query tool.

2.5 Virtual warehouse

A virtual warehouse provides integrated analytical access primarily through views, semantic models, query federation, or virtualization rather than by physically copying all data into a central store. Data remains in source or specialized platforms, and a virtualization layer presents a unified interface.

Virtualization can reduce duplication, accelerate access to existing data, and support exploratory work. It is useful when data must remain in place for legal, operational, or ownership reasons. It can also provide a transitional architecture while persistent integration is being developed.

However, virtual warehouses inherit the availability, performance, structure, and quality limitations of their sources. Complex joins across systems may be slow or unstable. Reproducibility can be difficult if source data changes after a query is executed. A virtual layer should therefore not be treated as a substitute for historical persistence when auditability and point-in-time reconstruction are required.

2.6 Data Vault architecture

Data Vault is a modeling and integration approach designed for auditability, historical tracking, and adaptability. Its core structures are:

Hubs, which represent stable business keys such as customer number or product code;
Links, which represent relationships or transactions between hubs; and
Satellites, which store descriptive attributes, context, source information, and historical changes.

Data Vault separates business keys and relationships from descriptive context. It commonly records load timestamps, record sources, and hash keys or other technical identifiers. This design supports parallel ingestion from multiple sources and preserves the ability to trace how information entered the warehouse.

Data Vault is particularly useful where source systems change frequently, historical auditability is important, and new data sources must be added without repeatedly redesigning a central normalized model. It is often paired with a presentation layer, such as dimensional marts or semantic models, because raw Data Vault structures are not generally the most convenient interface for business users.

Data Vault is not automatically a complete architecture. It is primarily a modeling and integration pattern that must be embedded in an architecture including ingestion, quality management, business rules, and consumption. Its flexibility can also produce a large number of tables and complex queries. Without disciplined naming, metadata, automation, and a well-designed business vault or presentation layer, the model may become difficult to use.

3. The Inmon, Kimball, and Hybrid Perspectives

3.1 Inmon architecture

The Inmon tradition begins with an enterprise-wide, subject-oriented, integrated, time-variant, and non-volatile warehouse. The warehouse is commonly modeled in normalized form, with dimensional marts created for particular analytical communities.

Its conceptual advantages are strong enterprise integration, centralized governance, reduced dependence on departmental definitions, and a clear separation between integrated storage and presentation. It is well suited to organizations that prioritize authoritative information, complex cross-domain analysis, and formal control.

Its major risks are long implementation cycles, high up-front modeling effort, dependence on centralized decision-making, and the possibility that the enterprise model becomes detached from immediate business priorities. The architecture works best when scope is managed incrementally rather than interpreted as a requirement to model the entire organization before delivering any value.

3.2 Kimball architecture

The Kimball tradition begins with business processes and dimensional data marts. Integration is achieved through a bus architecture and conformed dimensions. Delivery proceeds incrementally: a high-value process is modeled, implemented, and then extended to related processes.

Its advantages include fast business value, intuitive models, strong query usability, and alignment with reporting requirements. It supports a portfolio of subject areas without requiring a complete enterprise conceptual model at the beginning.

Its risks are local optimization, inconsistent dimensions, duplicate logic, and difficulty handling requirements that do not fit neatly into business-process marts. Kimball architecture requires an enterprise bus matrix, disciplined conformance rules, shared definitions, and strong stewardship. Without them, incremental delivery can become fragmented departmental development.

3.3 Hybrid architecture

A hybrid architecture combines elements of both traditions. For example, an organization may ingest data into a raw historical layer, integrate it using Data Vault or normalized structures, and publish dimensional marts and governed semantic models for consumption. Another organization may use a dimensional bus for priority reporting while maintaining a centralized integrated store for regulatory history and master data.

Hybrid design is often realistic because different workloads have different requirements. Operational traceability, exploratory data science, executive reporting, and regulatory reconciliation may not be best served by a single model. The critical issue is not whether the architecture is theoretically pure but whether its layers have clear responsibilities and avoid uncontrolled duplication.

A hybrid design should specify:

1. Which layer is authoritative for each type of data.

2. Where business rules are defined and maintained.

3. Which transformations are reusable and which are presentation-specific.

4. How keys, history, lineage, and quality exceptions are managed.

5. Which users should access which layer.

6. How data is reconciled across layers.

4. Comparative Evaluation

|---|---|---|---|---|---|---|

This comparison should not be interpreted mechanically. A dimensional bus may be more centralized in practice than a nominally enterprise warehouse if its conformed dimensions and governance are strong. Conversely, an EDW may deliver poor integration if departments bypass it or if definitions are not actively governed.

5. A Framework for Selecting an Architecture

Architecture selection should begin with requirements rather than vendor preference. A useful process has six stages.

Stage 1: Characterize the organization

Assess geographic distribution, business-unit autonomy, mergers, regulatory exposure, existing platforms, analytical maturity, and available skills. A centralized bank with strict regulatory reporting has different needs from a rapidly growing digital marketplace with independent product teams.

Stage 2: Characterize the data

Assess source-system number and volatility, data volume, velocity, structure, identity quality, history availability, and sensitivity. Highly volatile sources and complex lineage requirements may favor a persistent integration layer such as Data Vault. Stable, well-understood sources with urgent reporting needs may support a dimensional delivery strategy.

Stage 3: Characterize analytical workloads

Identify dashboard latency, ad hoc analysis, regulatory reporting, operational analytics, data science, machine learning, and cross-domain analysis. A single architecture may not optimize all these workloads. Workload isolation and purpose-specific presentation layers may be necessary.

Stage 4: Define governance requirements

Determine requirements for data ownership, privacy, retention, audit, explainability, quality, and data residency. In regulated environments, the ability to reproduce a reported figure and demonstrate its source may be more important than minimizing storage duplication.

Stage 5: Evaluate alternatives explicitly

A decision matrix can make assumptions visible. Organizations may score each architecture against criteria such as integration, agility, usability, history, performance, governance, cost, and implementation risk. Scores should be supported by evidence, prototypes, or stakeholder analysis rather than assigned solely by preference.

Stage 6: Design a transition path

Architecture is not only a target state. It is also a sequence of deliverable states. The transition plan should identify an initial high-value domain, reusable standards, migration constraints, coexistence mechanisms, and retirement criteria for legacy systems.

6. Worked Application: Selecting an Architecture for a Multi-Unit Insurer

The following is an illustrative case.

Background

A national insurer has separate systems for automobile, property, health, and life insurance. Each business unit uses different customer identifiers and policy definitions. The regulator requires reproducible quarterly reports, including the ability to explain changes in reported figures. Executives want a group-wide view of customers, claims, premiums, and risk. Business units also demand rapid delivery of new dashboards.

Problem

The insurer’s existing reports are produced through spreadsheets and departmental extracts. Similar measures differ across units. A centralized EDW proposal has been criticized as too slow, while a purely virtual solution cannot guarantee historical reproducibility because several source systems overwrite changes.

Analysis

The organization has four important requirements:

1. Persistent history and lineage for regulatory reconstruction.

2. Enterprise integration of customer, policy, claim, and financial concepts.

3. Rapid delivery of business-unit reporting.

4. Accommodation of different source systems and future acquisitions.

A purely dimensional approach could deliver dashboards quickly, but it would require substantial discipline to preserve source history and manage differences across business units. A purely virtual approach would not solve the loss of history in source systems. A centralized normalized EDW would support integration but might delay business value. Data Vault offers strong historical and source-traceability properties, while dimensional marts can provide usable reporting.

Approach and solution

The insurer chooses a hybrid architecture:

Source data is ingested into a controlled landing area using batch extraction and change data capture where available.
A Data Vault-oriented integration layer preserves business keys, relationships, descriptive history, load times, and record sources.
Master-data services establish governed mappings for customers, products, organizational units, and geographic areas.
Dimensional marts are created for claims, premiums, policies, and customer service using conformed dimensions.
A semantic layer defines approved measures such as earned premium, incurred claim amount, and active policy count.
Regulatory reports use persisted, versioned data and reconciliation controls rather than live federated queries.
Business-unit dashboards consume dimensional marts, while authorized analysts can use curated detailed data for investigation.

Outcome

The architecture permits the first claims dashboard to be delivered before the complete enterprise model is finished. It also preserves source history needed for audit and supports cross-unit analysis as conformed dimensions mature. The insurer accepts additional storage and operational complexity in exchange for traceability and controlled flexibility.

Learning points

The case illustrates that architecture is a portfolio of responsibilities. Data Vault addresses integration history, dimensional models address usability, master data addresses identity and shared definitions, and semantic governance addresses measure consistency. The solution is successful not because it uses every fashionable pattern, but because each layer has a defined purpose.

7. Governance, Ethics, and Regulatory Considerations

Architecture directly affects ethical and legal treatment of data. Centralization can improve control but can also create a high-value target for unauthorized access. Federation can limit unnecessary movement of sensitive data but may make consistent enforcement more difficult. Virtualization can support data minimization, yet it does not eliminate the need for access monitoring and source-level controls.

Important controls include:

role-based or attribute-based access control;
encryption in transit and at rest;
masking or tokenization of sensitive identifiers;
purpose limitation and least-privilege access;
retention and deletion policies;
lineage and audit logs;
data-quality issue management;
separation of duties for development, approval, and production access;
documented definitions and accountable data owners.

When warehouse data supports automated decisions, organizations should assess whether derived attributes create unfair discrimination, whether individuals can challenge inaccurate data, and whether models rely on historical biases. AI and machine-learning systems also require stable feature definitions, reproducible training data, monitoring for drift, and clear lineage from predictions back to source data. A lakehouse or AI platform does not remove these obligations.

8. Contemporary Developments

Modern cloud platforms have blurred traditional distinctions between warehouse, data lake, and data mart. Elastic storage and compute make physical duplication less expensive, while query engines can operate across multiple storage formats. Nevertheless, logical architectural questions remain: Who owns the data? Which definition is authoritative? How is history preserved? How are quality and access controlled?

Several developments influence current design:

Lakehouse architectures combine low-cost, flexible storage with warehouse-like management and SQL access.
Data mesh principles emphasize domain ownership, data as a product, self-service platforms, and federated computational governance.
Data contracts make assumptions about schemas, quality, ownership, and change explicit between producers and consumers.
Change data capture and event streaming improve freshness but require handling of ordering, duplicates, late events, and schema evolution.
Semantic layers and metrics stores centralize definitions of measures while allowing multiple physical models.
Metadata automation and active metadata improve discovery, lineage, and impact analysis, although automated metadata must still be validated.
Generative AI assistants can help users discover data, generate queries, and document transformations. They must be constrained by permissions, validated definitions, and human review because plausible generated SQL can be semantically wrong or expose sensitive data.

These developments change implementation possibilities, not the need for architectural reasoning. A cloud-native system can still be fragmented, poorly governed, or historically unreliable.

9. Best Practices and Common Failure Modes

Best practices

1. Declare the grain of every fact structure before adding measures.

2. Define authoritative sources and business owners for important concepts.

3. Establish conformed dimensions, identifiers, and metric definitions early.

4. Preserve source lineage and relevant event or load timestamps.

5. Separate raw preservation, integration, and presentation responsibilities.

6. Deliver incrementally, but maintain an enterprise roadmap and architecture guardrails.

7. Automate repetitive ingestion and testing while retaining human review of business rules.

8. Design security and privacy controls into the architecture rather than adding them later.

9. Measure data quality, query performance, freshness, adoption, and reconciliation success.

10. Document not only the target architecture but also transition and retirement plans.

Common failure modes

treating a collection of departmental marts as an integrated enterprise warehouse;
assuming a virtualization tool resolves conflicting business definitions;
building a detailed technical integration layer without a usable presentation layer;
creating conformed dimensions without assigning ownership;
allowing every team to define metrics independently;
ignoring late-arriving, corrected, or deleted source records;
selecting technology before clarifying requirements;
assuming normalization or dimensional modeling alone guarantees data quality;
over-centralizing decisions and creating a delivery bottleneck; and
underestimating operational costs, metadata work, and change management.

Chapter Summary

Enterprise warehouse architecture determines how an organization integrates, stores, governs, preserves, and exposes analytical data. The enterprise warehouse emphasizes centralized integration; the dimensional bus emphasizes business processes, conformed dimensions, and incremental delivery; hub-and-spoke separates a governed central hub from tailored marts; federated architectures coordinate autonomous environments; virtual warehouses provide integrated access without necessarily persisting all data; and Data Vault emphasizes historical traceability, source lineage, and structural adaptability.

Inmon architecture generally begins with an integrated enterprise warehouse and downstream marts, whereas Kimball architecture begins with dimensional business processes connected through a bus. Hybrid architectures combine these ideas and are often practical when regulatory history, rapid reporting, source volatility, and diverse workloads coexist. Architecture selection must be based on organizational structure, data characteristics, workloads, governance, risk, skills, and transition strategy. Contemporary cloud, lakehouse, data mesh, streaming, semantic, and AI technologies expand implementation options but do not eliminate the need for clear ownership, definitions, lineage, security, and historical reliability.

Key Terms

Enterprise data warehouse: A centrally governed repository integrating historical data across an organization.

Dimensional model: An analytical model built around facts and descriptive dimensions.

Fact table: A structure containing measurable events at a defined grain.

Dimension table: A structure containing descriptive context for analytical facts.

Conformed dimension: A shared dimension whose keys, attributes, and meanings are consistent across marts.

Dimensional bus: An architecture integrating dimensional marts through conformed dimensions and facts.

Hub-and-spoke: An architecture with a central integrated hub and dependent analytical marts or stores.

Federated architecture: A coordinated architecture in which multiple autonomous data environments remain in place.

Virtual warehouse: An analytical access layer based primarily on views, federation, or virtualization rather than full physical consolidation.

Data Vault: A historical integration modeling approach using hubs, links, and satellites.

Hub: A Data Vault structure representing a stable business key.

Link: A Data Vault structure representing a relationship or transaction among hubs.

Satellite: A Data Vault structure storing descriptive, contextual, and historical attributes.

Data lineage: The documented path of data from origin through transformations to consumption.

Semantic layer: A governed representation of business concepts, measures, and relationships for users and tools.

Master data: Shared core entities, such as customer or product, requiring consistent identification and management.

Grain: The precise meaning of one row in a fact or other analytical structure.

Historical fidelity: The ability to preserve and reconstruct data states or changes over time.

Federated governance: Shared standards and controls applied across otherwise autonomous data domains.

Review Questions

Short Answer Questions

1. What is the main purpose of an enterprise data warehouse?

2. What makes a dimension conformed in a dimensional bus architecture?

3. Distinguish a virtual warehouse from a physically persisted warehouse.

4. What are the three principal structures in Data Vault?

5. Why is architecture selection an organizational decision rather than only a technology decision?

Long Answer Questions

1. Compare the strengths and limitations of Inmon and Kimball architectures.

2. Explain how a hub-and-spoke architecture separates enterprise integration from departmental presentation.

3. Discuss the conditions under which a federated architecture is preferable to a fully centralized warehouse.

4. Explain why Data Vault is frequently paired with dimensional or semantic presentation layers.

5. Evaluate the governance, security, and historical implications of virtual warehouse implementations.

Analytical / Application Questions

1. A university has independent faculties, a central finance office, inconsistent student identifiers, and a legal requirement to reproduce annual financial reports. Recommend an architecture and justify the choice.

2. An online retailer requires sub-minute inventory dashboards, detailed historical price analysis, and machine-learning features from clickstream data. Design a layered architecture and identify key trade-offs.

3. A multinational acquired four companies, each with separate customer and product systems. Develop a decision framework for choosing between an enterprise warehouse, dimensional bus, federated, and hybrid approaches.

Multiple Choice Questions with Answers

Question 1

What is the principal integration mechanism in a dimensional bus architecture?

A. Conformed dimensions and facts

B. Independent departmental databases

C. Unmanaged source-system views

D. Only real-time event streams

Correct Answer: A. Conformed dimensions and facts

Question 2

Which Data Vault structure represents a stable business key?

A. Satellite

B. Hub

C. Link

D. Fact

Correct Answer: B. Hub

Question 3

Which approach primarily provides analytical access through views or query federation rather than copying all data?

A. Enterprise warehouse

B. Dimensional bus

C. Virtual warehouse

D. Data Vault

Correct Answer: C. Virtual warehouse

Question 4

A major risk of a purely virtual warehouse is that it may have difficulty with which requirement?

A. Creating any user interface

B. Preserving reproducible historical states

C. Connecting to existing systems

D. Displaying descriptive attributes

Correct Answer: B. Preserving reproducible historical states

Question 5

In the Inmon tradition, dimensional marts are generally created from which foundation?

A. An integrated enterprise warehouse

B. Uncontrolled spreadsheets

C. Independent source systems only

D. A collection of unrelated dashboards

Correct Answer: A. An integrated enterprise warehouse

Question 6

Which architecture uses a central integrated hub and dependent departmental marts?

A. Federated architecture

B. Hub-and-spoke architecture

C. Virtual warehouse

D. Standalone data-mart architecture

Correct Answer: B. Hub-and-spoke architecture

Question 7

What is the main purpose of declaring the grain of a fact table?

A. To identify the exact meaning of one row

B. To select a cloud vendor

C. To remove all historical data

D. To define user passwords

Correct Answer: A. To identify the exact meaning of one row

Question 8

Which combination best describes a practical hybrid architecture?

A. Data Vault integration with dimensional presentation marts

B. Only spreadsheets with no persistent storage

C. Only source-system queries with no governance

D. Independent marts with deliberately conflicting definitions

Correct Answer: A. Data Vault integration with dimensional presentation marts

Question 9

What is a central challenge of federated architecture?

A. It cannot contain any local ownership

B. It guarantees identical definitions automatically

C. Semantic consistency across autonomous domains

D. It always requires one physical database

Correct Answer: C. Semantic consistency across autonomous domains

Question 10

Which quality attribute concerns the ability to reconstruct what was known at a previous time?

A. Historical fidelity

B. Query syntax

C. Interface usability

D. Compute elasticity

Correct Answer: A. Historical fidelity

Data Warehousing
Chapter 2 of 15

Chapter 2 Enterprise Architecture and Warehouse Models