ETL Data warehouse Concepts....Ascential Data Stage,Informatica ,SQL,PL/SQL,Unix

What is the difference between Cognos,BO?.
The loops in BO,
Which version u used cognos and BO?.
The reports developed in Cognos?.
The reports developed in BO?
What is dimension
)What are the types of dimension
)The tools u used in cognos?.
)Cognos supports drilldown,drillacross,drillthru?.
What are the steps to create cube?.
how much size your cube?.
Your cube source?.
What are the sources allowed into the Cube?.
How to select views at the catalolg creation?.
What is cascading promt?.
What is the difference between catalogpick list,report picklist,file picklist?.
how to secure your catalog?.
How to secure your cube?.
How to improve your cube performance?.
Waht is cube groups and uses of that ?.
what is upfront in cognos?.
What is MAcro?.Have u developed any macros in cognos?.
What type od catalog u created in Cognos?.
after creating the cube it will be saved in what extension?.
After creating the model it will be saved in what extension?.
The impromptu report will be saved default extension?.
types of reports in Impropmtu?.
Types of reports in powerplay?.
The modes in powerplay?.What is the default mode?.
Views in transformer?.
How can you hide the dimensions in cube?.
What is the difference between reporter and explorer?.
how to extract the two databes into the one catalog?.
what is catalog?.What it contains?.
The difference between catalog and Datamart?.
what is snapshot?.what is hotfile?.
how many cubes u created in transformer?.
Scheduling in cognos?.
What is OLAP?Is cognos OLAP?.
Webreports in Cognos?.
Linking of reports in cognos?.
what problems u faced at the catalog creation?.
what problems u faced at the cube creation.?
how many windows are come at the creation of model?.
how to send the cube to others?.Is there any option?.
what is the difference between .MDL and .MDC?.
If i want to change database is there any changes in your catalog?.
If I want to change the database is there any changes in your hotfile?.
Is there any changes in your cube if the database Changes?.
what is incremental aggregation in cube?.

Bitmap indexes are widely used in data warehousing environments. The environments typically have large amounts of data and ad hoc queries, but a low level of concurrent DML transactions. For such applications, bitmap indexing provides:

Reduced response time for large classes of ad hoc queries

Reduced storage requirements compared to other indexing techniques

Dramatic performance gains even on hardware with a relatively small number of CPUs or a small amount of memory

Efficient maintenance during parallel DML and loads

Fully indexing a large table with a traditional B-tree index can be prohibitively expensive in terms of space because the indexes can be several times larger than the data in the table. Bitmap indexes are typically only a fraction of the size of the indexed data in the table.

An index provides pointers to the rows in a table that contain a given key value. A regular index stores a list of rowids for each key corresponding to the rows with that key value. In a bitmap index, a bitmap for each key value replaces a list of rowids.

Each bit in the bitmap corresponds to a possible rowid, and if the bit is set, it means that the row with the corresponding rowid contains the key value. A mapping function converts the bit position to an actual rowid, so that the bitmap index provides the same functionality as a regular index. If the number of different key values is small, bitmap indexes save space.

Bitmap indexes are most effective for queries that contain multiple conditions in the WHERE clause. Rows that satisfy some, but not all, conditions are filtered out before the table itself is accessed. This improves response time, often dramatically. Benefits for Data Warehousing Applications:

Bitmap indexes are primarily intended for data warehousing applications where users query the data rather than update it. They are not suitable for OLTP applications with large numbers of concurrent transactions modifying the data.

Parallel query and parallel DML work with bitmap indexes as they do with traditional indexes. Bitmap indexing also supports parallel create indexes and concatenated indexes.

Cardinality

The advantages of using bitmap indexes are greatest for columns in which the ratio of the number of distinct values to the number of rows in the table is under 1%. We refer to this ratio as the degree of cardinality. A gender column, which has only two distinct values (male and female), is ideal for a bitmap index. However, data warehouse administrators also build bitmap indexes on columns with higher cardinalities.

For example, on a table with one million rows, a column with 10,000 distinct values is a candidate for a bitmap index. A bitmap index on this column can outperform a B-tree index, particularly when this column is often queried in conjunction with other indexed columns. In fact, in a typical data warehouse environments, a bitmap index can be considered for any non-unique column.

B-tree indexes are most effective for high-cardinality data: that is, for data with many possible values, such as customer_name or phone_number. In a data warehouse, B-tree indexes should be used only for unique columns or other columns with very high cardinalities (that is, columns that are almost unique). The majority of indexes in a data warehouse should be bitmap indexes.

In ad hoc queries and similar situations, bitmap indexes can dramatically improve query performance. AND and OR conditions in the WHERE clause of a query can be resolved quickly by performing the corresponding Boolean operations directly on the bitmaps before converting the resulting bitmap to rowids. If the resulting number of rows is small, the query can be answered quickly without resorting to a full table scan.

Example 6-1 Bitmap Index The following shows a portion of a company's customers table.

SELECT cust_id, cust_gender, cust_marital_status, cust_income_level
FROM customers;

CUST_ID    C CUST_MARITAL_STATUS  CUST_INCOME_LEVEL
---------- - -------------------- ---------------------
...
        70 F                      D: 70,000 - 89,999
        80 F married              H: 150,000 - 169,999
        90 M single               H: 150,000 - 169,999
       100 F                      I: 170,000 - 189,999
       110 F married              C: 50,000 - 69,999
       120 M single               F: 110,000 - 129,999
       130 M                      J: 190,000 - 249,999
       140 M married              G: 130,000 - 149,999
...

Because cust_gender, cust_marital_status, and cust_income_level are all low-cardinality columns (there are only three possible values for marital status and region, two possible values for gender, and 12 for income level), bitmap indexes are ideal for these columns. Do not create a bitmap index on cust_id because this is a unique column. Instead, a unique B-tree index on this column provides the most efficient representation and retrieval.

Table 6-1 illustrates the bitmap index for the cust_gender column in this example. It consists of two separate bitmaps, one for gender. Table 6-1 Sample Bitmap Index :

	gender='M'	gender='F'
cust_id 70	0	1
cust_id 80	0	1
cust_id 90	1	0
cust_id 100	0	1
cust_id 110	0	1
cust_id 120	1	0
cust_id 130	1	0
cust_id 140	1	0

Each entry (or bit) in the bitmap corresponds to a single row of the customers table. The value of each bit depends upon the values of the corresponding row in the table. For instance, the bitmap cust_gender='F' contains a one as its first bit because the region is east in the first row of the customers table. The bitmap cust_gender='F' has a zero for its third bit because the gender of the third row is not F.

An analyst investigating demographic trends of the company's customers might ask, "How many of our married customers have an income level of G or H?" This corresponds to the following SQL query: SELECT COUNT(*) FROM customers WHERE cust_marital_status = 'married' AND cust_income_level IN ('H: 150,000 - 169,999', 'G: 130,000 - 149,999');

Bitmap indexes can efficiently process this query by merely counting the number of ones in the bitmap illustrated in Figure 6-1. The result set will be found by using bitmap or merge operations without the necessity of a conversion to rowids. To identify additional specific customer attributes that satisfy the criteria, use the resulting bitmap to access the table after a bitmap to rowid conversion. Figure 6-1 Executing a Query Using Bitmap Indexes

Bitmap Indexes and Nulls

Unlike most other types of indexes, bitmap indexes include rows that have NULL values. Indexing of nulls can be useful for some types of SQL statements, such as queries with the aggregate function COUNT.

Example 6-2 Bitmap Index

SELECT COUNT(*) FROM customers WHERE cust_marital_status IS NULL; This query uses a bitmap index on cust_marital_status. Note that this query would not be able to use a B-tree index. SELECT COUNT(*) FROM employees; Any bitmap index can be used for this query because all table rows are indexed, including those that have NULL data. If nulls were not indexed, the optimizer would be able to use indexes only on columns with NOT NULL constraints.

Bitmap Indexes on Partitioned Tables You can create bitmap indexes on partitioned tables but they must be local to the partitioned table--they cannot be global indexes. (Global bitmap indexes are supported only on nonpartitioned tables). Bitmap indexes on partitioned tables must be local indexes. Bitmap Join Indexes

In addition to a bitmap index on a single table, you can create a bitmap join index, which is a bitmap index for the join of two or more tables. A bitmap join index is a space efficient way of reducing the volume of data that must be joined by performing restrictions in advance. For each value in a column of a table, a bitmap join index stores the rowids of corresponding rows in one or more other tables. In a data warehousing environment, the join condition is an equi-inner join between the primary key column or columns of the dimension tables and the foreign key column or columns in the fact table. Bitmap join indexes are much more efficient in storage than materialized join views, an alternative for materializing joins in advance. This is because the materialized join views do not compress the rowids of the fact tables.

Example 6-3 Bitmap Join Index: Example 1

Using the example in "Bitmap Index", create a bitmap join index with the following sales table:
SELECT time_id, cust_id, amount FROM sales;

TIME_ID   CUST_ID    AMOUNT
--------- ---------- ----------
01-JAN-98      29700       2291
01-JAN-98       3380        114
01-JAN-98      67830        553
01-JAN-98     179330          0
01-JAN-98     127520        195
01-JAN-98      33030        280
...

CREATE BITMAP INDEX sales_cust_gender_bjix ON sales(customers.cust_gender)
FROM sales, customers WHERE sales.cust_id = customers.cust_id LOCAL;

The following query shows how to use this bitmap join index and illustrates its bitmap pattern:

SELECT sales.time_id, customers.cust_gender, sales.amount
FROM sales, customers
WHERE sales.cust_id = customers.cust_id;

TIME_ID   C AMOUNT
--------- - ----------
01-JAN-98 M       2291
01-JAN-98 F        114
01-JAN-98 M        553
01-JAN-98 M          0
01-JAN-98 M        195
01-JAN-98 M        280
01-JAN-98 M         32
...
Table 6-2 illustrates the bitmap join index in this example:

Table 6-2 Sample Bitmap Join Index

	cust_gender='M'	cust_gender='F'
sales record 1	1	0
sales record 2	0	1
sales record 3	1	0
sales record 4	1	0
sales record 5	1	0
sales record 6	1	0
sales record 7	1	0

You can create other bitmap join indexes using more than one column or more than one table, as shown in these examples. Example 6-4 Bitmap Join Index: Example 2

You can create a bitmap join index on more than one column, as in the following example, which uses customers(gender, marital_status): CREATE BITMAP INDEX sales_cust_gender_ms_bjix ON sales(customers.cust_gender, customers.cust_marital_status) FROM sales, customers WHERE sales.cust_id = customers.cust_id LOCAL NOLOGGING;

Example 6-5 Bitmap Join Index: Example 3

You can create a bitmap join index on more than one table, as in the following, which uses customers(gender) and products(category): CREATE BITMAP INDEX sales_c_gender_p_cat_bjix ON sales(customers.cust_gender, products.prod_category)FROM sales, customers, products

Example 6-6 Bitmap Join Index: Example 4

You can create a bitmap join index on more than one table, in which the indexed column is joined to the indexed table by using another table. For example, we can build an index on countries.country_name, even though the countries table is not joined directly to the sales table. Instead, the countries table is joined to the customers table, which is joined to the sales table. This type of schema is commonly called a snowflake schema.

CREATE BITMAP INDEX sales_c_gender_p_cat_bjix ON sales(customers.cust_gender, products.prod_category) FROM sales, customers, products WHERE sales.cust_id = customers.cust_id AND sales.prod_id = products.prod_id LOCAL NOLOGGING; Bitmap Join Index Restrictions Join results must be stored, therefore, bitmap join indexes have the following restrictions:

Parallel DML is currently only supported on the fact table. Parallel DML on one of the participating dimension tables will mark the index as unusable.

Only one table can be updated concurrently by different transactions when using the bitmap join index.

No table can appear twice in the join.

You cannot create a bitmap join index on an index-organized table or a temporary table.

The columns in the index must all be columns of the dimension tables.

The dimension table join columns must be either primary key columns or have unique constraints.

If a dimension table has composite primary key, each column in the primary key must be part of the join.

ETL Data warehouse Concepts....Ascential Data Stage,Informatica ,SQL,PL/SQL,Unix

Tuesday

Cognos Questions,Cognos FAQ's -II

Monday

Cognos Questions,FAQ's

Sunday

Bitmap Index,c,Bitmap Join Indexes

Useful Sites

Translate