DW FACT table/Structure ??

Hi Everybody,
It is a great forum. Thanks for your replies/suggestions to my earlier posting. I am hitting FACT tables design by several folks over the period of time. It is puzzling me. I like to bounce this table in this forum to get your ideas/thoughts. As per FACT table definition, it need to contain single (instance) of FACT described by multiple dimensions. Here is the FACT structure I found in my situation.
DIM_KEY1 )
DIM_KEY2 )--> Foreign Keys to DIM Table
DIM_KEY2 )
TRANS_ID ----> Degenerate Dims
TRANS_TYP_CD )
TRANS_S_CD )
SRC_TYE_CD ) -----> Type codes derive multiple instances of FACTS from
ADJ_TYP_CD ) single fact table, based on type code combinations
DB_CR_CD )
TRANS_AMT ---> Fact
It looks like multiple fact tables (instances) forced into single fact table, where it fall under single super type/sub type structure of logical data-model. Here are my questions.
1)     Did any one work with such fact tables?
2)     Does it a acceptable design in star schema approach?
3)     What are the impacts in queries/ETL?
Thanks in advance.
RI

Hi,
Not clear with ur explination on the Fact but here are some general tips...
The instance in a fact table is decided by the keys from the DIM table and also the dates (effective and term dates) in case u maintain history.at any point in time (between effective and term date) we should have have only 1 instance live (current record).The type_cd does not matter and should not be used to create or distinctly identify an instance of a fact.
Regards
Bharath

Similar Messages

How to handle 3 different fact tables and measures within a DAX query?

I am writing a DAX query in DAX studio in Excel against a tabular model that has 4 different Fact tables, but they share the same dimensions. (There's some long story I can't get into here, but unfortunately this is the structure) I want to
include measures from the 4 fact tables, summarize by the dimensions in a single query output that can be used for a pivot table. So far I have something like this:
EVALUATE
FILTER
    SUMMARIZE
        FactTable1,
        DimensionTable1[Value],        DimensionTable2[Value],
        DimensionTable3[Value],
        Dimensiontable4[Value],
        'dimDateTime'[Month PST],
        DimDateTIme[FiscalYear PST],
        "Measure Score",
        FactTable1[Measure 1],
        "Measure Score 2",
        FactTable1[Measure 2],
    ,Company[CompanyName]="Company ABC"
What I want to do is summarize the 3 fact tables by the same dimensions, but I am not sure how to do that within a DAX query. I am getting an error if I try to include another table statement in the original SUMMARIZE function, even though the FACTS
do share the same dimension. Is there an easy way to do this?

You can use ADDCOLUMNS to add the data from other tables, but you need to use within the SUMMARIZE the fact table that determines the cardinality of the output. If you are not sure (e.g. you project cost and revenues from two fact tables by month and there
could me months with cost and no revenues, but also months with revenues and no costs), then you should use CROSSJOIN and then FILTER.
You query might be written as (please note CALCULATETABLE instead of FILTER to improve performance):
EVALUATE
CALCULATETABLE (
    ADDCOLUMNS (
        SUMMARIZE (
            FactTable1,
            DimensionTable1[Value],
            DimensionTable2[Value],
            DimensionTable3[Value],
            Dimensiontable4[Value],
            'dimDateTime'[Month PST],
            DimDateTIme[FiscalYear PST]
        "Measure Score", FactTable1[Measure 1],
        "Measure Score 2", FactTable1[Measure 2]
    Company[CompanyName] = "Company ABC"
Marco Russo http://www.sqlbi.com http://www.powerpivotworkshop.com http://sqlblog.com/blogs/marco_russo

Mapping the Fact table to different levels of a dimension

Hi,
I have a fact table which stores the data for 4 levels of the dimensions. The aggregation method was taken care by PL/SQL and the fact table will have the data for all the 4 levels. When im trying to map all the levels to a column in the fact table using the OEM, it is generating the F KEY constraints referncing the columns mapped for the various levels of the dimension.
The problem is that im using a denormalised table for maintaing the values of the dimension. So the columns mapped for the levels(Except for the lowest) can't have the unique key defined on it. The cube is not getting created because of the error in creating the F KEY.
Can u please suggest how to map this fact table.
Thnks,
Manohar Vanama

I am not exactly clear on your schema but I believe you are trying to map tables which are not strict star or snowflake. This means that you cannot use CWM1 (and OEM), unless you change the structure of the tables. You might be able to map the tables with CWM2. The document below will assist you:
Oracle9i OLAP User's Guide
Chapter 4. Designing Your Database for OLAP
Chapter 5. Creating OLAP Catalog Metadata

Multiple Fact Tables and Dimension Tables

I have been having some problems trying to model the data from Oracle E-Business Suite maintenance. I will try to give the best description of how the data is held in the tables. The structure is such that a work order can have multiple operations and an operation can have multiple resources as well. I believe the problem comes in the fact that an operation doesn't necessarily need to have a resource. I could not attach an image so I have written out an example below. I am not saying this is right or that it works, but just to give you an idea of what I am thinking. The full dimension would be Organization -> WorkOrder -> Operation -> Resource. Now, the fact tables all hold factual data for the three different levels, with the facts being at each corresponding level. This causes an obvious problem in combining the tables into one large fact table through the ETL process.
Can anyone tell me if they think this can be done? Am I way off? I am sure that there is a solution as there always is but I have been killing myself trying to figure this one out. I currently have the entire solution in different Business Models. I would like however to be able to compare facts from multiple areas such as the Work Order level and the Resource level.
Any help is greatly appreciated. I realize that the solution may also require additional work on the ETL side so I am open to any and all suggestions.
Thank you in advance for anyones time. :)
Dimension Tables
WorkOrder_D
Operation_D
Resource_D
Organization_D
Fact Tables
WorkOrder_F
Operation_F
Resource_F
Joins
WorkOrder_D -> Operation_D
Operation_D -> Resource_D
WorkOrder_D -> WorkOrder_F
Operation_D -> Operation_F
Resource_D -> Resource_F
Organization_D -> WorkOrder_D
Organization_D -> Operation_D
Organization_D -> Resource_D

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.

SSAS 2008 Using multiple (three) fact tables in the same cube

Hi, I have three fact tables in my cube,
Actions
Events
Visits
Events captures anything that happens, any transaction. It contains parent actions and parent visits, plus other things that business deems as "actions" that change all the time.
Actions captures a subset of Events and has its own transactional structure. Each action has an event, but not every event has an action.
Visits is a completely different subset of Events with a very different transactional structure from both events and actions. Each condition can have an event, but not every event has a condition.
These facts don't have many overlapping dimensions, perhaps a couple of outrigger look-up dimensions, like Codes and Dates.
I am struggling to reorganize the cube in such a way that I don't have to process with errors and unknown dimension members. Is there any specific guidance re: what to do in these situations?

@Victor Rocca
Some dimensions are common, like Dates and Codes, but mostly they are their own dimensions. Visits
and Actions facts have foreign keys from Events in them, so I would prefer to join directly, anyway.

Fact table showing incorrect quantity measure

Hi,
I have a scenario where i have a fact table with multiple rows and two quantity fields. My source system holds sales by "package" which can contain any number of components. The grain of my invoice table is component level. See
structure below:
PACKAGE1
- Component1 - each package contains 2 of these
- Component2 - each package contains 1 of these
So if i am reporting a sale of PACKAGE1, for a quantity of 2 - component1 had a total sales quantity of 4 and component2 has a total sales quantity of 2. However the package was only sold 2 of, but because of the sum aggregation, i see a total quantity
sold for PACKAGE1 of 6, but it should only show 2 at that level. I have looked at semi-additive measures but am unsure of how this would work in this scenario, or which option would work best for me here.
My fact table has 2 rows, each of which reference the component as one dimension and the package as another dimension.
As a workaround, I have created a calculation to divide the quantity by the number of package components (so it would show a 1 for each of the component lines in my fact table), but then the sales quantities of the components reported are incorrect.
What is the best approach for this?
Thanks in advance,
Dom

Hi Dominic,
Thank you for your question.
I am trying to involve someone more familiar with this topic for a further look at this issue. Sometime delay might be expected from the job transferring. Your patience is greatly appreciated.
Thank you for your understanding and support.
Thanks,
Simon Hou
TechNet Community Support

Problem with populating a fact table from dimension tables

my aim is there are 5 dimensional tables that are created
Student->s_id primary key,upn(unique pupil no),name
Grade->g_id primary key,grade,exam_level,values
Subject->sb_id primary key,subjectid,subname
School->sc_id primary key,schoolno,school_name
year->y_id primary key,year(like 2008)
s_id,g_id,sb_id,sc_id,y_id are sequences
select * from student;
S_ID UPN FNAME COMMONNAME GENDER DOB
==============================
9062 1027 MELISSA ANNE       f 13-OCT-81
9000 rows selected
select * from grade;
      G_ID GRADE      E_LEVEL         VALUE
        73 A          a                 120
        74 B          a                 100
        75 C          a                  80
        76 D          a                  60
        77 E          a                  40
        78 F          a                  20
        79 U          a                   0
        80 X          a                   0
18 rows selectedThese are basically the dimensional views
Now according to the specification given, need to create a fact table as facts_table which contains all the dim tables primary keys as foreign keys in it.
The problem is when i say,I am going to consider a smaller example than the actual no of dimension tables 5 lets say there are 2 dim tables student,grade with s_id,g_id as p key.
create materialized view facts_table(s_id,g_id)
as
select s.s_id,g.g_id
from   (select distinct s_id from student)s
,         (select distinct g_id from grade)gThis results in massive duplication as there is no join between the two tables.But basically there are no common things between the two tables to join,how to solve it?
Consider it when i do it for 5 tables the amount of duplication being involved, thats why there is not enough tablespace.
I was hoping if there is no other way then create a fact table with just one column initially
create materialized view facts_table(s_id)
as
select s_id
from student;then
alter materialized view facts_table add column g_id number;Then populate this g_id column by fetching all the g_id values from the grade table using some sort of loop even though we should not use pl/sql i dont know if this works?
Any suggestions.

Basically your quite right to say that without any logical common columns between the dimension tables it will produce results that every student studied every sibject and got every grade and its very rubbish,
I am confused at to whether the dimension tables can contain duplicated columns i.e column like upn(unique pupil no) i will also copy in another table so that when writing queries a join can be placed. i dont know whether thats right
These are the required queries from the star schema
Design a conformed star schema which will support the following queries:
a. For each year give the actual number of students entered for at A-level in the whole country / in each LEA / in each school.
b. For each A-level subject, and for each year, give the percentage of students who gained each grade.
c. For the most recent 3 years, show the 5 most popular A-level subjects in that year over the whole country (measure popularity as the number of entries for that subject as a percentage of the total number of exam entries).
I written the queries earlier based on dimesnion tables which were highly duplicated they were like
student
=======
upn
school
school
======
school(this column substr gives lea,school and the whole is country)
id(id of school)
student_group
=============
upn(unique pupil no)
gid(group id)
grade
year_col
========
year
sid(subject id)
gid(group id)
exam_level
id(school id)
grades_list
===========
exam_level
grade
value
subject
========
sid
subject
compulsory
These were the dimension table si created earlier and as you can see many columns are duplicated in other tables like upn and this structure effectively gets the data out of the schema as there are common column upon which we can link
But a collegue suggested that these dimension tables are wrong and they should not be this way and should not contain dupliated columns.
select      distinct count(s.upn) as st_count
,     y.year
,     c.sn
from      student_info s
,     student_group sg
,     year_col y
,     subject sb
,     grades_list g
,     country c
where      s.upn=sg.upn
and     sb.sid=y.sid
and     sg.gid=y.gid
and     c.id=y.id
and     c.id=s.school
and      y.exam_lev=g.exam_level
and      g.exam_level='a'
group by y.year,c.sn
order by y.year;This is the code for the 1st query
I am confused now which structure is right.Are my earlier dimension tables which i am describing here or the new dimension tables which i explained above are right.
If what i am describing now is right i mean the dimension tables and the columns are allright then i just need to create a fact table with foreign keys of all the dimension tables.

OBIEE Query not hitting the other fact table

Hi All,
I am trying to create report based on two fact column and one dimension. Dimension is connected with these two facts table. When i create report using one column from dimension and one column from respective facts so i get two scenerio...
For example let say..
D1 is dimension and F1 and F2 are two fact tables.
First i used a column which have aggregation rule from one fact and one column from other fact which also have aggregate column.
That is report like...
D1.c1,Agg(F1.c2),Agg(F2.c3)
When i run the report I get the data from dimension and only from first fact table. When i check the query, Query contain only one fact table and it doesnt hit the other one.
Now in second scenerio i used one column from dimension, one column from first fact which have aggregation rule and one column from second fact which doesnt have any aggregation rule.
like...
D1.c1,Agg(F1.c2),F2.c3
When i run the report i got the error. It says
State: HY000. Code: 10058. [NQODBC] [SQL_STATE: HY000] [nQSError: 10058] A general error has occurred. [nQSError: 14026] Unable to navigate requested expression: F1 -C2 . Please fix the metadata consistency warnings. (HY000).
But there is no warning in RPD.
I am amazed that it is not taking both the fact columns even the dimension is confirmed dimension and have joined with both the fact tables.
As i am just started to learn OBIEE, So i am find it bit difficult that how OBIEE select the tables and formed physical query.
Waiting for your help.
Regards
Suhail

Aadi-Wasi,
Thumb rule, OBIEE BMM layer must contain a simple star schema.
Did your BMM layer suffice the above condition? If hope, Not.
My prediction of your BMM layer structure contains 3 logical tables, i.e. dimension & 2 logical facts...which is not a simple star.
Thus to make it a simple star collapse 2 logical fact tables into 1 logical fact table. As you mentioned dimension is linked to both facts, collapsing 2 logical fact tables into 1 logical fact table will provide the result for your query1.
regarding your second error:
All aggregations must be contained within Fact tables with few exceptions.
Let us know If I did resolve your issue
mark posts promptly...
J
-bifacts
http://www.obinotes.com

Can we Join 2 fact tables ?

Hi All,
We are trying to join 2 fact tables using a logical dimension. Let me explain my structure fact1 dim1 and fact2 dim2 another dim dim3 which is joined to Fact1. Other dim contains only columns for joining fact1 and fact2.
When I pick columns from fact1 and dim3,dim1,dim2 it works good. Either Fact2,dim1,dim2,dim3 works good but does not wrok when using columns for both fact1 and fact2.
Here we are using couple of materialized views both on Oracle Apps tables and some Custom tables.
Can any one have some kind of solution when using multiple fact tables.
Thanks,

Yo can join as the same joins mentioned as per your physical joins.
But you need to set dimensions hierarchy & aggregation level in BMM layer for sure.
In Reports set the aggregation rule to complex server level.
Regards,
Darwin
Edited by: Darwin S on Dec 24, 2009 1:13 PM

Populating Fact tables

Hi,
First time working on DW. Have got my staging and Dimension table setups.
About to start working on Fact tables and all examples I see online are using SSIS packages with several lookup tables.
Is there any reason that this cannot be done using Stored procedure or I have to develop SSIS package to populate fact tables.
Thanks,

Hello,
In fact we are using stored procedure for all our manipulations and populating fact table. The fact table is partitioned and works great with no issues.
We are calling the stored procedure and PL/SQL procedure from Informatica. I don't find any issue in processing but I feel difficulty in debugging 5000 lines of code.
If the transformation are simple and it can be handle in stored procedure than you can go for it But SSIS is designed for ETL.
In considering maintenance overhead SSIS gives better control over the data flow because business logic and debugging is much easier than doing the same in stored procedure.
If you've partitions and properly designed data structures definitely you can think of using SP.
-Prashanth

Unexpected transaction data in fact table

Hi,
I have created customized table having field
SWISSEMPID SWEMPNAME SWADDRESS SWDESIGNATION
SWHIREDATE SUPERVISOR SWISSCOMP ETHNICITY LANGUAGE CURRENCY
On the basis of table , I have created generic data source for text ( empname ) and attr ( empid)
dtp excetuded successfully
but for transaction data , in extract structure I have taken empid and empname for connecting dimension
table to fact table , compensation also selected ( transaction data)
after exectuing dtp i am getting 426000 value , it is repeated for each record
which does not exist in table
Regards,
Vivek
Edited by: Vivek Srivastava on Jan 13, 2010 9:07 AM

You need to explain your requirement a bit more. Why you want to add type or rejection reason in fact table.
In general you should avoid adding textual data in fact.
Fact tables are only supposed to store keys and measures. It can hold textual data in case of degenerate dimension ( i.e if the number of records are same in dimension as well as fact ).
Type or Rejection reason are going to have much less records. You can create a new dimension for them having probably 20 or 30 records.
Disadvantages of adding textual data in fact is, once the fact has millions of records the fact table updates are going to take huge time and also your reports will take long time.
If you have a rejection reason dimension with some 20 records, you can use rejection reason in prompts.
But if the same rejection reason is coming from fact table your prompts performance is going to be very slow since it has to fetch 20 distinct records from millions of records.
Consider these before adding textual data in facts.
Thanks
Edited by: Maqsood Hussain on Dec 5, 2012 9:40 PM

Users selecting "All Choices" on columns in fact table

We have a dimensionalised data structure in our Oracle DW and the fact table contains 750million rows. I'm finding the users are selecting a column in the fact table to filter on, and selecting the "All Choices" option. This then runs an SQL like:
select distinct(column_name) from column_table
Which kills the DW server.
Does anyone know of a way of stopping this? to only allow the All Choices option on one of the dimension tables?
Oracle 11g
BI 10.1.3.4.1
both on Redhat LINUX
Thanks in advance.

Thanks to all for advice/suggestions. In the end I resolved this ( rather a brute force method ) by hacking adjusting one of the XML message documents, standardviewtemplates.xml, that I'd copied into the customMessages directory.
Its a real shame as it removes that function for all users on every table, but some users keep selecting the "All Choices" option even after being told not to.

Model with 2 fact tables

Hi all,
i have a model with two fact tables, both of them containing these columns:
- some measures
- foreign keys for dimensional tables
- column year
- column month
I have to build a model with both of these two tables, including a unique time dimension. Do anyone knows how i can do to make a unique dimension for both of the tables?
Thanks in advance,
Regards

A time dimension (or date dimension for that matter) are quite independent and you can find N good generic time/date dim structures out there (with proper Y/M/DAGO keys, calendar vs fiscal rollups etc etc).
But if you only want to create a single common time/date dim based on what you have in your facts, you can just follow (as a quick win before thinking about how to structure a physical time/date dim) Stewarts basic example here:
http://www.rittmanmead.com/2012/12/obiee-transactional4/
"Building a Date Dimension" a bit further down the page.

OBIEE-can we link two dimension tables belonging to different fact tables?

Hi ,
I have just started with OBIEE concepts....need your views on this issue:
Fact 1 -> Dim 1, Dim2,Dim3 and so on..
Fact 2 -> Dim a, Dim b,Dimc and so on...
If I link Dim1 and Dim a with a valid key ,would that distort the star schemas to slowflake in BMM layer?
Thanks in advance!
Neha

I don't see this that would make it snowflake more like what I think as conforming dimensions. You need to make sure the grain of the measures is at what level , the they are same grain then you should be good however if they are different then you would start seeing null values.
Fact Measures use the same, conformed dimensions like Dim1 and Dim a if you trying to generate from multiple facts, the BI server was able to automatically stitch them together into a single result set. If they came from the same fact table that's easy as its only one single table, but if you are pulling from different fact tables, the conformed dimensions would allow them to be stitched into the same report
Conformance means that these sources can be mapped to a common structure – the same levels – and also the same data members.
Mark if helps.
Thanks,
SVS

Datamart as set of fact table and dim

i have to develop the etl procedures for loading the data from flat file to datamart which consist of several dimensions and fact tables. please tell me how this technology work or what r the steps to proceede further, one imp question that my user ask me is if he has multiple value for reject field x,y,z for customer A and x,v, c for customer B in flat file can that be loaded to datamart and how it will work. i guess bw can load only single value for one field please help me soon i will reward all points.
thanks
soniya

Soniya,
Dimensions and facts are loaded by the system on its own. THe source has to be one flat structure in which the fields can have any number of values.
Create a flat file datasrouce and a transformation/infosource + update rules to the cube.
Aneesh

DW FACT table/Structure ??

Similar Messages

Maybe you are looking for