Database Management Systems

Stovepipe data marts are built independently for specific departments or business functions without integration with the enterprise data warehouse or other data marts. They are called independent data marts because each mart operates in isolation, creating data silos that can lead to inconsistent definitions and redundant data across the organization.

Bitmapped indexing is highly efficient for data warehouse applications because it uses bitmaps to represent indexing information, making it ideal for low-cardinality columns (like gender, status, yes/no fields) and complex multi-column queries common in analytical processing. B-tree indexing is better suited for OLTP systems with high-cardinality data, while vector indexing and join indexing are not standard indexing techniques used in data warehouses.

Dormant data refers to data that has been loaded into the data warehouse but is never accessed or used by any queries or reports. This wastes storage space and ETL processing resources. Organizations should identify dormant data through usage monitoring and consider archiving or removing it to optimize warehouse performance and reduce costs.

In the Corporate Information Factory (CIF) architecture, Near Line Storage (NLS) holds the highest volume of data. NLS stores archival and historical data that's not actively used but must be retained. Data warehouses contain current and historical data for analysis but have less volume than NLS. ODS (Operational Data Store) holds current operational data. Data staging areas are temporary. Near Line Storage is designed for cost-effective storage of massive historical data volumes.

In top-down data warehouse architecture (Bill Inmon's approach), the enterprise data warehouse is created first as a single, integrated repository. Then, departmental data marts are derived from the warehouse. This ensures consistency across the organization and avoids data silos. Option B is incorrect because it contradicts the top-down principle. Option C describes independent data marts (bottom-up). Option D is wrong because data marts ARE created in top-down architecture.

In bottom-up architecture (Ralph Kimball's approach), data marts are created first to address specific business needs. These data marts can then be integrated to form an enterprise data warehouse. This is faster to implement initially but can lead to consistency challenges. Option A describes top-down, not bottom-up. Option C suggests independent marts with no integration, which isn't a complete architecture. Option D contradicts the bottom-up approach.

MOLAP (Multidimensional OLAP) uses pre-computed cubes for fast query performance. However, scalability is POOR, not good. MOLAP struggles with large datasets because cubes require extensive pre-computation and storage. Processing overhead for large datasets is high because all aggregations must be pre-calculated. Dimensions are often restricted (commonly to 10 or fewer) due to cube explosion. User interface is good because pre-computed results enable instant responses. Option C is actually NOT true about MOLAP - it's the limitation.

In data warehouse design, each aggregation level should have its own set of fact and dimension tables (Option C). This is because aggregated data has different granularity than detailed data. For example, monthly sales aggregates have different dimensions and grain than daily transactions. Option A is wrong because mixing aggregate and detail data degrades query performance. Option B is incorrect because aggregate data requires appropriate dimension tables at the same grain. Option D is inefficient - storing all aggregation levels together doesn't optimize for different query patterns.

A Business Component in Siebel CRM is the object responsible for data retrieval and manipulation from the database. Views display data, Business Objects contain relationships, and database tables are the underlying storage.

A Business Object in Siebel CRM defines and contains the relationships between different Business Components, linking related data entities together in a logical structure.

The statement is False. When you install iProcess Engines on multiple servers sharing the same database, it creates a Cluster architecture, not a Node Cluster Architecture. The terminology matters - it's simply called a Node Cluster or just a Cluster. The distinction in naming is important for accurate documentation.

The TIBCO iProcess Engine is designed for enterprise resilience, automatically detecting database failures, ensuring transaction integrity through two-phase commits, and resuming seamlessly when connection is restored.

On Oracle databases, the Process Sentinels use Oracle's event system for failure detection. Transparent Application Failover (TAF) is the Oracle feature that enables automatic failover to a backup database instance if the primary fails. MTS is a Microsoft technology, ODBC is a driver interface - neither provide failover support.

PowerCenter Lookup transformations primarily support relational sources (tables, views) and flat files. COBOL files are handled through source definitions and aren't direct lookup sources, and XML files require different handling. The core lookup sources are relational databases and flat files.

Source Qualifier transformations are versatile readers that support relational databases, flat files, COBOL files, and certified ERP sources including PeopleSoft and SAP/R3. This wide compatibility makes them the primary transformation for reading from diverse source systems.