Security Task/Object
|
OBIEE 10g
|
OBIEE 11g
|
Define Users and Groups in RPD file using
OBIEE Admin Tool
|
Default
|
N/A. By default, users are defined in
embedded WLS LDAP via FMW EM Console, or alternatively, in external LDAP.
|
Defining security policies
|
Policies in the catalog and repository
can be defined to reference groups within a directory
|
Policies are defined in terms of
application roles, which map to users and groups in a directory.
|
“Administrator” user
|
Unique user with full administrative
privileges
|
No single user named for full
administrative privileges. Administration can be performed by any user who is
member of BIAdministrators group.
|
Repository encryption
|
Available on sensitive elements only –
i.e. user passwords, connection pool passwords, etc.
|
Entire RPD encrypted via a password.
|
External Authentication and OBIEE
Initialization (Init) Blocks
|
Init blocks are required for external
LDAP or external table authentication.
|
Init blocks not required for WLS embedded
LDAP. Init blocks are
required for external LDAP or
external table authentication.
|
Catalog Groups
|
Defined in Presentation Server
Administration link
|
Available for backward compatibility. Use
of Application Roles in FMW EM Console recommended.
|
SA System Subject Area
|
Optional
|
Available for backward compatibility and
requires init blocks and external tables. Use of Embedded LDAP is
recommended.
|
“Everyone” Presentation Server Group
|
Default
|
Replaced with AuthenticatedUser role
|
A blog where you can explore everything about Datawarehouse, OBIEE, Informatica, Power BI, QlikView, Hadoop, Oracle SQL-PLSQL, Cognos and much more....
Friday, 29 June 2012
Differences between OBIEE 10g and 11g security models?
Types of Views in OBIEE
Difference between Star & Snowflake Schema
Star Schema: It has single fact table
connected to dimension tables like a star. In star schema only one join
establishes the relationship between the fact table and any one of the
dimension tables.A star schema has one fact table and is associated with
numerous dimensions table and depicts a star.
Snowflake Schema: It is an extension of the star schema.In snowflake schema, very large dimension tables are normalized into multiple tables. It is used when a dimensional table becomes very big.In snow flake schema since there is relationship between the dimensions Tables it has to do many joins to fetch the data.Every dimension table is associated with sub dimension table.
The main difference between star schema and snowflake schema is that
Snowflake Schema: It is an extension of the star schema.In snowflake schema, very large dimension tables are normalized into multiple tables. It is used when a dimensional table becomes very big.In snow flake schema since there is relationship between the dimensions Tables it has to do many joins to fetch the data.Every dimension table is associated with sub dimension table.
The main difference between star schema and snowflake schema is that
- The star schema is highly denormalized and the snowflake schema is normalized. So the data access latency is less in star schema in comparison to snowflake schema. As the star schema is denormalized, the size of the data warehouse will be larger than that of snowflake schema.
- Performance wise, star schema is good. But if memory utilization is a major concern, then snow flake schema is better than star schema.
- A dimension table will not have parent table in star schema, whereas snow flake schemas have one or more parent tables.
- The dimensional table itself consists of hierarchies of dimensions in star schema,whereas hierarchies are split into different tables in snow flake schema. The drilling down data from top most hierarchies to the lowermost hierarchies can be done.
What are Dimension and Fact?
Dimensions are categories by which
summarized data can be viewed. E.g. a profit summary in a fact table can be
viewed by a Time dimension (profit by month, quarter, year), Region dimension
(profit by country, state, city), Product dimension (profit for product1,
product2).
A fact table is a table that contains summarized numerical and historical data (facts) and a multipart index composed of foreign keys from the primary keys of related dimension tables.
In data warehousing, a dimension is a collection of reference information about a measurable event. These events are known as facts and are stored in a fact table. Dimensions categorize and describe data warehouse facts and measures in ways that support meaningful answers to business questions. They form the very core of dimensional modeling.
Dimension tables are referenced by fact tables using keys. When creating a dimension table in a data warehouse, a system-generated key is used to uniquely identify a row in the dimension. This key is also known as a surrogate key. The surrogate key is used as the primary key in the dimension table. The surrogate key is placed in the fact table and a foreign key is defined between the two tables. When the data is joined, it does so just as any other join within the database.
A fact table is a table that contains summarized numerical and historical data (facts) and a multipart index composed of foreign keys from the primary keys of related dimension tables.
In data warehousing, a dimension is a collection of reference information about a measurable event. These events are known as facts and are stored in a fact table. Dimensions categorize and describe data warehouse facts and measures in ways that support meaningful answers to business questions. They form the very core of dimensional modeling.
Dimension tables are referenced by fact tables using keys. When creating a dimension table in a data warehouse, a system-generated key is used to uniquely identify a row in the dimension. This key is also known as a surrogate key. The surrogate key is used as the primary key in the dimension table. The surrogate key is placed in the fact table and a foreign key is defined between the two tables. When the data is joined, it does so just as any other join within the database.
Thursday, 28 June 2012
Normalizer Transformation In Informatica
Normalizer
transformation normalizes records from COBOL & relational sources allowing
you to organize the data according to your needs.A normalizer transformation
can appear anywhere in a data flow when you normalize a relational source.
The Normalizer transformation receives a row that contains multiple-occurring columns and returns a row for each instance of the multiple-occurring data. The transformation processes multiple-occurring columns or multiple-occurring groups of columns in each source row.
For example, a relational table contains quarterly sales totals by store. You need to create a row for each sales occurrence. You can configure a Normalizer transformation to return a separate row for each quarter.
The following source rows contain four quarters of sales by store:quarters of sales by store:
The Normalizer transformation receives a row that contains multiple-occurring columns and returns a row for each instance of the multiple-occurring data. The transformation processes multiple-occurring columns or multiple-occurring groups of columns in each source row.
For example, a relational table contains quarterly sales totals by store. You need to create a row for each sales occurrence. You can configure a Normalizer transformation to return a separate row for each quarter.
The following source rows contain four quarters of sales by store:quarters of sales by store:
Store1
|
100
|
300
|
500
|
700
|
Store2
|
250
|
450
|
650
|
850
|
The Normalizer
returns a row for each store and sales combination. It also returns an index
that identifies the quarter number:
Store1
|
100
|
1
|
Store1
|
300
|
2
|
Store1
|
500
|
3
|
Store1
|
700
|
4
|
Store2
|
250
|
1
|
Store2
|
450
|
2
|
Store2
|
650
|
3
|
Store2
|
850
|
4
|
Subscribe to:
Posts (Atom)