Dimension key in a fact table should be repetitive?

Hi All,
We do have one to one relationship between a FACT table and Dimension table? Is it correct to have this kind of dimensional model.

You may find this link of some help.
How to Model Fact table having 1:1 relationship with key Dimension attributes

Similar Messages

How to determine the logical Keys of logical fact table in BMM layer?

Hello guys
I'd like to know more about how to know what columns of the logical fact table should be used as key in BMM layer. How OBIEE behaving differently when different keys are selected?
In my situation, I have 1 fact table that physically joins to 20 dimensions in physical layer. Therefore, in physical layer, this fact table has about 20 foreign keys but no primary keys..
In the logical layer, this fact table is logically joined to the same group of dimension tables. So in this case, how do I know what columns in logical fact table I should use as keys?
Please advice
Thanks

thanks for the reply...
The interesting thing I notice is that, when I start using fragmentation with the fact tables in its LTS, if not primary key is defined in the logical fact table, then I will be getting errors:
[nQSError: 10058] A general error has occurred. [nQSError: 14023] None of the fact sources for columns are compatible with the detail filter []. (HY000)
When I create the key by choosing random columns from the fact table as the logical key columns, this error goes way and the correct SQL is generated according to the frag..
Because of such behavior, I'd really like to know how logical key really works in BMM layer.

How can we know that size of dimension is more than fact table?

how can we know that size of dimension is more than fact table?
this was the question asked for me in interview

Hi Reddy,
This is common way finding the size of cube or dimensions or KF.
Each keyfiure occupies 10 Bytes of memory
Each Char occupies 6 Bytes of memory
So in an Infocube the maximum number of fields are 256 out of which 233 keyfigure, 16 Dimesions and 6 special char.
So The maximum capacity of a cube
= 233(Key figure)10 + 16(Characteristics)6 + 6(Sp.Char)*6
In general InfoCube size should not exceed 100 GB of data
Hope it answer your question.
Regards,
Varun

Few dimension values used in FACT tables.

Hello all,
We are trying to know if somebody faced this issue earlier. We have dimension tables containing 5 million records, but the fact table uses hardly 30k of these dimension values. The fact table contains 350 million records, so is there any way to improve the performance of the query in such a scenario, where hardly 20% of dimension values are actually used by the FACT tables.
Thanks and Regards,
Upendra

nilanjan chatterjee wrote:
Hi,
>
> The data for the parent members should be available in the SQL tables.
> For example, 2011.TOTAL is parent member. You should not have any data for this member in your database. If it is there, it might have come somehow (may be an import). But this is not right. You might want to remove these records. But be sure that you dont delete the records for the base level members.
>
> Hope this helps.
I guess you meant should not, right ?

Conformed dimension and query multiple fact tables

Hello,
Please if someone can guide me on this requirement.
Requirement - I have a conformed dimension D1 and two fact tables F1 and F2. Both fact tables have many columns so I cannot merge
the two fact tables into one logical table. Currently both these fact tables have logical tables F1 and F2 respectively.
As per design the conformed dimension is a simple logical table in the rpd and not a dimension.
Can someone guide me how should i proceed so that i'll be able to fetch information from both the fact tables?
Edited by: 930542 on Apr 26, 2012 12:28 PM

Hi,
Currently the dimension table is taken as a simple logical table in rpd as it does not have have any levels or hierarchy.
Its a flat dimension. Can you guide me how can I implement a flat dimension in OBIEE? Because this dimension is taken as simple logical table
I am not able to set appropriate level for fac tables. This dimension does not appear in the list of dimensions.

Same dimension in two different fact tables

Hi,
I have one same dimension in two different fact tables. I would like to know how BI server choose the fact table when I do a request in this dimension.
I know that is always using the same fact table, but I would like to know why choose this table and not the other.
Thanks

Sorry,
But it doesn't seem to me.
I reorded the tables in the BMM layer and it continues to use the same table, regardless this table is in last.
After, I droped that table in the BMM layer and it continued to use the same.
Thanks for your reply

SSAS 2008 Linking two cubes on the foreign key between two fact tables

Hi, all --
I have two cubes:
Cube 1 has Fact1 (F1, "Events") and 3 dimensions (D1, D2, D3)
Cube 2 has Fact2 (F2, "Sales") and 3 dimensions (D4, D1, D6)
As you can see, two cubes reuse D1 as their common dimension. In addition, F2 foreign keys into F1, e.g. F1 is "Events", and F2 is "Sales". Every "sale" is an "event", but not every "event" is
a "sale".
The question is, how to I link the two cubes and their two respective fact tables on the foreign key?
Thanks, Austin.

Hi Austin,
According to your description, you want to retrieve data from two different cubes, right? In Analysis Services, to query multiple cubes from a single MDX statement you can use the LOOKUPCUBE function (you can't specify multiple cubes in your FROM statement).
The LOOKUPCUBE function will only work on cubes that utilize the same source database as the cube on which the MDX statement is running. For the detail information about it, please refer to the link below to see the blog.
Retrieving Data From Multiple Cubes in an MDX Query Using the Lookupcube Function
If I have anything misunderstood, please point it out.
Regards,
Charlie Liao
TechNet Community Support

Adding Dimension field ($) in measures (fact) table in logical layer

Hi,
I have a field (amount) in the dimension table. I would like to add this field in the fact table at the logical layer. Dimension table and fact table had physical joins. Can I add into fact table and still do aggregation on that field based on the other dimensions linked to fact table. I working on Siebel Analytics version 7.8. Any help would be greatly appreciated.
Thanks in advance,
RK

Check here : How to create a measure from data that is stored in a dimension table
http://gerardnico.com/wiki/dat/obiee/bi_server/design/fact_table/obiee_measures_dimension
Cheers
Nico

Two Filter on Two dimensions without constraining the fact table

Hi All,
does anybody know how to avoid the fact constraint when creating a report with two filters on different dimensions?
I have a big fact table with more than 10 Million rows. In the starmodel the is the dimension customer and products. I create a filter on the customer atrribute "Status" and choose the value "Active". Now I add the column "Product Type" from the dimension "Product" to the filter section. When I want to choose a value OBIEE executes a select statement within the fact table. So I have to wait very long to select a value. Is there any way to say OBIEE only to select the dimension table without joining the fact table?
Thank you very much in Advance.
Regards,
Stefan

Hi Stefan,
Generally queries on the dimensions (across dimesions also) always go through a fact. In case, you would like the queries not be through fact table, but just the dimension tables right away, you can set up a separate subject area for them.
You can create a separate subject area based on a dummy fact table to get these prompt values.
Please refer to http://gerardnico.com/wiki/dat/obiee/presentation_service/obiee_parameter_prompt_subject_area for more details on this setup.
Hope this helps.
Thank you,
Dhar

Multiple Date Keys in a Fact Table

Do you guys see a problem with having multiple date keys (all date keys are referencing one date demension table) on a fact table?
RESERVATION_DATE_KEY
SHIP_DATE_KEY
CONTRACT_DATE_KEY
SHIP_DATE_KEY
CANCEL_DATE_KEY
APPLICANT_KEY
BRANCH_KEY
ENLST_CAT_KEY

Nope, this is 100% natural for the type of fact table you are building. Happens all the time.
Scott
use the "role" to define the multiple ways the time dime is used.

Add primary key column to fact tables?

Our datawarehouse folks asked me if they could add a primary key column in the BPC fact tables. Anyone know if this is possible??
Edited by: Shawn Freundschuh on Apr 3, 2009 12:27 PM

Well.. based on my expeirence, it is not possible.
When you run admin console, sometimes it will return error message.
I tried it before but you can try it again. Maybe developer changed its behavior.
Thanks.

Oracle Administration Tool (RPD) One Dimension linked with many fact tables

How to connect One dimension with many table facts in the Lgical level of RPD without having an error about connection between table facts?

It's not about "linking two catalogs". That's Siebel Marketing stuff. Forget about it. Just create your models and put them in their respective presentation catalogs.
Whatever you fire from answers will hit that specifc presentation catalog and search its way through the metadata to contruct the query.
Hence conforming dimensions as a technical concept are definitely the thing you want...not the rpd object type "conformed dimension links".

Two Fact tables with Different set of Dimension Tables

Here is my scenario:
I got two fact tables: X and Y (actually, they are the same tables, but with different level of data)
and four dimension tables: A, B, C, D
X joins relationship to all dimensions (A, B, C, D).
Y joins relationship to only A, B, C, but no D.
When I select dimension A, B and C together with fact tables X and Y in BI Answer, result is displayed and compared.
However, if I select dimension D together with fact tables X and Y, only data from fact table X is displayed. There is no result displayed for fact table Y. I know that this is because fact table Y does not join to dimension D.
If the above relationship unchanged, how can I display both X and Y's result in BI Answer when dimension D is selected?

Thanks for all your replies.
Actually, I've tried the solutions you guys mentioned. Generally speaking, the result should be displayed. However, my scenario is a little bit tricky.
table Y's figures are not the aggregation of table X for D dimension. Instead, table Y's figures include not only D dimension total, but also others (others do not mean A, B, C dimension). For example, table Y stores all food's figure, while table X stores only drink's figure. D dimension is only about drink's detail. In my scenario, other foods' figure is not provided.
So, even if I set D dimension to all/total for table X, table X's result is still not the same as table Y.
Indeed, table Y does not have a column key to join to D dimension's key. So, if I select D dimension and table Y's measures at the same time in BI Answer, result returns no data. Hence, I can't compare table X and table Y's results with selection of D dimension.
Is there any solution to solve this problem?
Edited by: TomChan on Jun 3, 2009 9:36 AM

How to design a fact table to keep track of active dimensions?

I would like to design a classic OLAP facts table using a star scheme. The SQL model of the facts table should be independent of any concrete RDBMS technology and portable between different systems.
The problem is this: users should be able to select subsets of the facts based on conjunctive queries on the dimension values defined for the facts. However, the program that provides the interface for doing this to the user should only present those dimensions where anything is still selectable at all. For example, if a user selected year 2001 and for dimension contract code there is only a single value for all records in the fact table for that year, this dimension should not be shown to the user any more. This should be solved in a generic way. So for n dimensions in total, if the current set of facts is based on constraints from j dimensions, I want to know for which of the remaining n-j dimensions there is still something to select from and only show those.
The obvious way is to make a count(*) query on the distinct foreign keys of each of the dimensions on the fact table, using the same where clause. That means that one would need (n-j) such queries on the whole facts table and that sounds like an awful waste of resources given that the original query for selecting the facts could have done it internally "on the fly".
How can this be achieved in the most performant way? Is there a "classical" way of how to approach this problem? Is there tool support for doing this efficiently?
Any help or pointers to where one could find out more about this would be greatly apreciated - thank you!

>
Did you get the counts for each value of each dimension by doing a separate query with the current "WHERE" clause on each dimension?
>
My method doesn't apply to your use case. I wrote a Java class to create my own bit-mapped indexes on CSV files. So each attribute value was a one million bit binary raw.
I don't know, and don't want to know, what your particular requirements are. But I can show you a basic process that will work for large numbers of rows. Get a simple process working and then explore to see if it will meet your particular needs. Not going to answer questions here about anything but about my example code
1. Assume a single fact table with one primary key column and multiple single-value attribute columns.
2. The table is not subject to DML operations AT ALL - truncate and load if you want apply changes. Meaning it will be useful for research purposes on archived data.
3. The purpose of the table is to select the fact table ROWIDs for records of interest. So the only value selected is a result set of ROWIDs that can then be used to get any of the normal FACt table data and other linked data as needed.
Create the table - insert some records, create a bitmap index on each dimension column and collect the statistics
ALTER TABLE SCOTT.STAR_FACT
DROP PRIMARY KEY CASCADE;
DROP TABLE SCOTT.STAR_FACT CASCADE CONSTRAINTS;
create table star_fact (
    fact_key varchar2(30) DEFAULT 'N/A' not null,
    age      varchar2(30) DEFAULT 'N/A' not null,
    beer    varchar2(30) DEFAULT 'N/A' not null,
    marital_status varchar2(30) DEFAULT 'N/A' not null,
    softdrink varchar2(30) DEFAULT 'N/A' not null,
    state    varchar2(30) DEFAULT 'N/A' not null,
    summer_sport varchar2(30) DEFAULT 'N/A' not null,
    constraint star_fact_pk PRIMARY KEY (fact_key)
INSERT INTO STAR_FACT (FACT_KEY) SELECT ROWNUM FROM ALL_OBJECTS;
create bitmap index age_bitmap on star_fact (age);
create bitmap index beer_bitmap on star_fact (beer);
create bitmap index marital_status_bitmap on star_fact (marital_status);
create bitmap index softdrink_bitmap on star_fact (softdrink);
create bitmap index state_bitmap on star_fact (state);
create bitmap index summer_sport_bitmap on star_fact (summer_sport);
exec DBMS_STATS.GATHER_TABLE_STATS('SCOTT', 'STAR_FACT', NULL, CASCADE => TRUE);Now if you run the 'complex' query for the example from my first reply you will get
SQL> set serveroutput on
SQL> set autotrace on explain
SQL> select rowid from star_fact where
2   (state = 'CA') or (state = 'CO')
3 and (age = 'young') and (marital_status = 'divorced')
4 and (((summer_sport = 'baseball') and (softdrink = 'pepsi'))
5 or ((summer_sport = 'golf') and (beer = 'coors')));
no rows selected
Execution Plan
Plan hash value: 1934160231
| Id | Operation                      | Name                  | Rows | Bytes |
|   0 | SELECT STATEMENT               |                       |     1 |    30 |
|   1 | BITMAP CONVERSION TO ROWIDS   |                       |     1 |    30 |
|   2 |   BITMAP OR                    |                       |       |       |
|* 3 |    BITMAP INDEX SINGLE VALUE   | STATE_BITMAP          |       |       |
|   4 |    BITMAP AND                  |                       |       |       |
|* 5 |     BITMAP INDEX SINGLE VALUE | AGE_BITMAP            |       |       |
|* 6 |     BITMAP INDEX SINGLE VALUE | MARITAL_STATUS_BITMAP |       |       |
|* 7 |     BITMAP INDEX SINGLE VALUE | STATE_BITMAP          |       |       |
|   8 |     BITMAP OR                  |                       |       |       |
|   9 |      BITMAP AND                |                       |       |       |
|* 10 |       BITMAP INDEX SINGLE VALUE| SOFTDRINK_BITMAP      |       |       |
|* 11 |       BITMAP INDEX SINGLE VALUE| SUMMER_SPORT_BITMAP   |       |       |
| 12 |      BITMAP AND                |                       |       |       |
|* 13 |       BITMAP INDEX SINGLE VALUE| BEER_BITMAP           |       |       |
|* 14 |       BITMAP INDEX SINGLE VALUE| SUMMER_SPORT_BITMAP   |       |       |
Predicate Information (identified by operation id):
   3 - access("STATE"='CA')
   5 - access("AGE"='young')
   6 - access("MARITAL_STATUS"='divorced')
   7 - access("STATE"='CO')
10 - access("SOFTDRINK"='pepsi')
11 - access("SUMMER_SPORT"='baseball')
13 - access("BEER"='coors')
14 - access("SUMMER_SPORT"='golf')
SQL>As you can see Oracle is combining bitmap indexes on columns in a single table to implement the same AND/OR complex conditions I showed earlier. It doesn't need any other table to do this.
In 11g you can create virtual columns and then index them.
so if you find that the condition 'young' and 'divorced' is used frequently you could create a VIRTUAL 'young_divorced' column and create an index.
alter table star_fact add (young_divorced AS (case
   when (age = 'young' and marital_status = 'divorced') then 'TRUE' else 'N/A' end) VIRTUAL);
create bitmap index young_divorced_ndx on star_fact (young_divorced);
exec DBMS_STATS.GATHER_TABLE_STATS('SCOTT', 'STAR_FACT', NULL, CASCADE => TRUE);Now you can query using the name of the virtual column
SQL> select rowid from star_fact where young_divorced = 'TRUE'
2 and (state = 'CA') or (state = 'CO')
3 /
no rows selected
Execution Plan
Plan hash value: 2656088680
| Id | Operation                    | Name               | Rows | Bytes | Cost
|   0 | SELECT STATEMENT             |                    |     1 |    28 |
|   1 | BITMAP CONVERSION TO ROWIDS |                    |       |       |
|   2 |   BITMAP OR                  |                    |       |       |
|* 3 |    BITMAP INDEX SINGLE VALUE | STATE_BITMAP       |       |       |
|   4 |    BITMAP AND                |                    |       |       |
|* 5 |     BITMAP INDEX SINGLE VALUE| STATE_BITMAP       |       |       |
|* 6 |     BITMAP INDEX SINGLE VALUE| YOUNG_DIVORCED_NDX |       |       |
Predicate Information (identified by operation id):
   3 - access("STATE"='CO')
   5 - access("STATE"='CA')
   6 - access("YOUNG_DIVORCED"='TRUE')
SQL>
----------------------------------------------------------------Notice that at line #6 the new index was used. The VIRTUAL column itselfl doesn't create data for the fact table; the definition only exists in the data dictionary.
The YOUNG_DIVORCE_NDX is real and does consume space. The tradeoff is additional space for the index but you make the query easier because you don't have to recreate the complex condition every time.
Oracle can work with the complex condition and combine the indexes so this really only helps the query writer. Your UI should be able to hide the query construction from the user so I would avoid the use of VIRTUAL columns and an additional index until you demonstrate you really need it.
If you provide users with their own RESULT table to store custom query results you could just store the query name and the set of primary keys from the result set. I used ROWIDs in the example but don't use rowid for a real application - use a primary key value that won't change.
So your UI would let users construct complext dimension queries for 'young_sportsters' and get a result set of primary keys for that. They could save the label 'young_sportsters' and the primary keys in their own work table. Then you can let them run queries that use the primary keys to query data from your active data warehouse to get any other data it contains.
>
Did you get the counts for each value of each dimension by doing a separate query with the current "WHERE" clause on each dimension?
>
For an Oracle implementation you need to do a count select for each dimension. I haven't tried it but you might be able to do multiple dimensions in a singe query. One query would look like this>
-- get the dimension counts
SQL> select beer, count(*) from star_fact group by beer;
BEER                             COUNT(*)
N/A                                 56977
Execution Plan
Plan hash value: 1692670403
| Id | Operation                | Name        | Rows | Bytes | Cost (%CPU)| Ti
|   0 | SELECT STATEMENT         |             |     1 |    12 |     3   (0)| 00
|   1 | SORT GROUP BY NOSORT    |             |     1 |    12 |     3   (0)| 00
|   2 |   BITMAP CONVERSION COUNT|             | 56977 |   667K|     3   (0)| 00
|   3 |    BITMAP INDEX FULL SCAN| BEER_BITMAP |       |       |            |
SQL>Notice that Oracle uses only the index to gather the data.

What is the best practice for creating primary key on fact table?

what is the best practice for primary key on fact table?
1. Using composite key
2. Create a surrogate key
3. No primary key
In document, i can only find "From a modeling standpoint, the primary key of the fact table is usually a composite key that is made up of all of its foreign keys."
http://download.oracle.com/docs/cd/E11882_01/server.112/e16579/logical.htm#i1006423
I also found a relevant thread states that primary key on fact table is necessary.
Primary Key on Fact Table.
But, if no business requires the uniqueness of the records and there is no materilized view, do we still need primary key? is there any other bad affect if there is no primary key on fact table? and any benifits from not creating primary key?

Well, natural combination of dimensions connected to the fact would be a natural primary key and it would be composite.
Having an artificial PK might simplify things a bit.
Having no PK leads to a major mess. Fact should represent a business transaction, or some general event. If you're loading data you want to be able to identify the records that are processed. Also without PK if you forget to make an unique key the access to this fact table will be slow. Plus, having no PK will mean that if you want to used different tools, like Data Modeller in Jbuilder or OWB insert / update functionality it won't function, since there's no PK. Defining a PK for every table is a good practice. Not defining PK is asking for a load of problems, from performance to functionality and data quality.
Edited by: Cortanamo on 16.12.2010 07:12

Dimension key in a fact table should be repetitive?

Similar Messages

Maybe you are looking for