Should I relate a fact table to a fact table to a dimension table?

Hi All,
I'm designing a dimensional data mart for a client and I'm now forced to think about many-to-many relationships, among other complexities I haven't dealt with until now. Said client needs to be able to analyze contracts, subcontracts, bids, and bidders.
Each contract and subcontract can have multiple bids. Each bidder can only submit a single bid for any single contract or subcontract. And each bidder can submit a bid for any number of contracts and subcontracts.
My initial plan is this: FactContracts, with FactContractKey, ContractID, SubContractID; FactBids, with FactBidKey, FactContractKey, and BidderKey; finally, DimBidders, with BidderKey.
I've left out degenerate dimensions and original business keys only to keep this message short. Please let me know if more info is required, I really need a qualified designer or architect to advise me but I don't know anybody else that's accessible.
Thanks,
Eric B.

Thanks, SQLBIGuyMN, you answered our question. It makes sense, too, because bids are only analyzed if they've been accepted and contracted, and they would only be related to the bidder through the contracts fact. I think we've also determined that contracts
needs to be an Accumulating Snapshot Table.
Thanks again,
Eric B.

Similar Messages

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.

Dimension table is associated with N number of fact tables

Hi Expert's,
In case of star schema one fact table is associated with N dimension tables , is it possible to join one dimension table with N number of fact tables...please let my know the your suggestion...
Thank's
Harish

is it possible to join one dimension table with N number of fact tablesYes you can join one dimension table to many fact tables.
Thanks,
Vino

Fact table and dimension table

what is the difference b/w fact table and dimension table

A fact table contains numeric values and also contain composite key(i.e collection of foreign key) e.g.. sales and profit. Typically has two types of columns: those that contain facts and those that are foreign keys to dimension tables.
Dimension tables, also known as lookup or reference tables, contain the relatively static data in the warehouse. It contains character values E.g Customer_name,Customer_city.
Dimension tables store the information you normally use to contain queries. Dimension tables are usually textual and descriptive and you can use them as the row headers of the result set.
Rachna

Problem creating hierarchy based on 2 physical dimension tables

I'm having a problem creating 1 logical dimension with a drill-down hierarchy, based on two separate physical dimension tables. The errors I receive when navigating the drill-down hierarchy is:
"Cannot find logical table source coverage for logical columns" &
"Missing join between logical tables".
I'm using OBIEE 10.1.3.4
Here are the details of what I have setup sofar:
Physical layer:
Dimension table DIM_ORG with columns:
-dimension_key
-org_total_code
-org_total_description
-org_detail_code
-org_detail_description
Dimension table DIM_DEPT with columns:
-dimension_key
-dept_total_code
-dept_total_description
-dept_detail_code
-dept_detail_description
Fact table FACT_SALES with columns:
-fk_org
-fk_dept
-sum_sales
Physical Joins:
FACT_SALES.fk_org = DIM_ORG_dimension_key
FACT_SALES.fl_dept = DIM_DEPT.dimension_key
Business Model & Mapping layer:
I created a logical dimension ORG_DEPT. It contains two logical table sources (DIM_ORG & DIM_DEPT) and the following logical columns:
- All Departments (mapped to dept_total_code)
- Organisation (mapped to org_detail_description)
- Organisation Number (mapped to org_detail_code)
- Department (mapped to dept_detail_description)
- Department Code (mapped to dept_detail_code)
The business logical key is based on the combination of Organisation Number & Department Code
The hierarchy I need is: All Departments -> Organisation -> Department so I created the following hierarchy for ORG_DEPT:
- Total Level containing: All Departments
- Organisation Level containing: Organisation Number (defined as the Logical level key) & Organisation (defined als the Drill level key)
- Detail Department Level containing: Department Code (defined as Logical level key) and Department (defined as Drill level key).
In the LTS of the dimension ORG_DEPT I've set the Content levels for the sources:
DIM_ORG : Organisation Level
DIM_DEPT: Detail Department Level
In the LTS no -inner- joins have been added against related physical tables.
I created a logical fact table SALES (based on the physical fact table) and joined it against the logical dimension table ORG_DEPT.
In the LTS the Content level for ORG_DEPT is set against the Detail Department Level. No - inner- joins have been aded against related physical tables.
When I create a report in Answers to test the hierachy and select only 'All Departments' I get the correct dimension value returned. When I try to drill to the next level I get the following ODBC error:
"Cannot find logical table source coverage for logical columns: [All Departments]. Please check more detailed level keys are mapped correctly".
When I create a report in Answers and select both 'All Departments' and 'Sales' I get the correct result. When I try to drill to the next level I get a different ODBC error:
"Missing join between logical tables DIM_DEPT and DIM_DEPT: There must be at least one physical join link between the underlying physical tables".
Any suggestions are welcome!
Thanks!

Hello Robert,
Your suggestions were known to me but I still wanted to combine the two physical dimension tables in one logical dimension. So I've played around a bit more and found the solution: In my original setup I had two seperate logical table sources (one for each physical dimension table). The solution was to combine the two logical table sources in one logical table source. I achieved that by logical joining the DIM_DEPT table to the FACT_SALES table and subsequently to the DIM_ORG within the 1 LTS and using inner joins.
Then I created the logical table key (a combination of org_detail_code & dept_detail_code). After that I could create the hierarchy with no problem.
Edited by: The_Dutchman on Nov 4, 2011 9:43 PM

Difference between Data staging and Dimension Table ?

Difference between Data staging and Dimension Table ?

Data Staging:
Data extraction and transformation is done here.
Meaning that, if we have source data in flat file, we extract it and load into staging tables, we take care of nulls, we change datetime format etc.. and after such cleansing/transformation at then end, load it to Dim/Fact tables
Pros: Makes process simpler and easy and also we can keep track of data as we have data in staging
Cons: Staging tables need space hence need memory space
Dimension Table:
tables which describes/stores the attribute about specific objects
Below is star schema which has dimension storing information related to Product, Customer etc..
-Vaibhav Chaudhari

Cartesian join on 2 dimension tables, with count aggregation?

Hi, I have 2 dimension tables, Students, and Subjects, and a fact table, Marks. (simplified)
the Students and Subjects dimension tables both have a 1-N relationship with Marks, so reporting works fine.
However, there are some students who does not have a score in a certain Subject, so when I generate the report of each Subject's scores by Student it'll be
Subject Students Marks
English A 89
......... C 70
......... D 60
Maths B 30
......... C 80
because Students and Subjects are joined by the Marks table
What I'd like to see is
Subject Students Marks
English A 89
......... B 0
......... C 70
......... D 60
Maths A 0
......... B 30
......... C 80
......... D 0
The joins between the dimension and fact tables are all set to "Left-outer join" (where "left" is the dimension table)
I thought I needed a cartesian/cross join on Subjects and Students, using the dummy table technique here: http://gerardnico.com/wiki/dat/obiee/densification_repository#the_cross_join_between_the_dimensions
But it didn't work, not to mention that I have a feeling that this doesn't really apply to 10g or my problem.
Can someone point me in the right direction on this? Thanks!
Above problem solved, but I also need a column of "Count of students who scored 50 or less" which includes the students who did not have any scores. Adding the dummy column to my report breaks the aggregation in my report, while removing the column will take me back to square one.
How do I generate a report that does aggregation that takes into account the students with no scores?
Edited by: lum on 28-Mar-2012 20:13

Here's what I did:
I created the physical table with 1 column, and did a complex join with expression "1=1" on the 2 tables that my actual fact table was directly joined to (and none of the indirect joins). I'm using 11g, so to do complex joins I had to use Manage->Joins
Then I added the dummy column to my Marks fact table in the BMM layer by just dragging it and set the aggregation rule. And then to the presentation layer too.
After updating the repository onto the server, the table behaviour is still the same as before, and the dummy column didn't do anything and displayed a blank value.
Could it be because of my other joins that make this dummy join not work? I don't even know if this 1=1 complex join work in 11g....!
Has anyone tried this join technique in 11g? Thanks!
PS: My dimension table and fact tables are actually logical tables that join several tables at the logical table source layer. My dummy fact table just joins the most detailed layer of the physical dimension tables.

How and when does a dimension table gets generated

Hi Gurus,
                 I am new into BI and I will be put into a project within 2 months. I have learned that dimension table contains the sid's of all the charateristics in the dimension table. My conclusions are like
1. Dimension table contains the dim id as the primary key.
2. Dimension table contains sid's of the characteristics.
3. Though sid's in the dimension table are primary keys in thier 'S' table they are not key in the dimension table.
My question is
1. Is there any chance to generate new dim id's for the same combination of sid's because sid's are not part of the key?
2. I got confused when and how does the dimension table gets generated ?
I have searched in the forum and google but still my doubts didnt get clarified. If anyone could throw some light on this topic I would really appreciate it.

HI,
All your conclusions are correct.
Now for your questions the answers are in line:
1. Is there any chance to generate new dim id's for the same combination of sid's because sid's are not part of the key?
    No new dim id's will be generated, dim Id is unique for the same combination of sid's .
2. I got confused when and how does the dimension table gets generated ?
    They get generated when you activate the info provider.
Hope this helps.
thanks,
Rahul

Dimension Tables

Hey Guys
How can i check my dimesion tables see the number of recrods or the chars they are storing. Kind of like table structure can i do that for the cube. and If yes anybody has the idea on the transaction code for that.
Thanks

Hi mark,
For every cube Maximum 16 dimension tables can be allocated.In that 16 dimension tables 3 tables are fixed dimensions i.e Datapacket,Time & unit.Remaining 13 dimensions are user can use these dimensions.
To know how many dimension tables are there for each cube,
goto SE11 tcode give /BIC/D"yourcubename"*,it gives you all the dimensions.Userdefined dimension tables are with named as \BIC\D(yourcubename)(1.....13),remaining fixed dimensions will appear as \BIC\D(yourcube name)P[datapacket],\BIC\D(yourcube name)T[time],\BIC\D(yourcube name)U[unit].
Thanks & Regards,
Praveena.

What I should do If I move fact and dimension tables from one server to other server

Hi
I have question like
what all changes need to be done in EPM System if we move the Fact and Dimension tables to a different server.
Reply me asap and thanks in advance

I have fact and dimension tables in one server and i moved those stuff to another server.If I do that what happen to essbase and about totale EPM System.I want to know how to do this and what I can expect?
Please reply

Fact Table and Dimension Tables

Hi Experts, I'm creating custom InfoCubes for data coming from non-SAP source systems. I have two InfoCubes. Tha data is coming from like 10 tables. I have 10 DataSources created fo this and the data will be consolidated in Standard DSO before it will flow into 2 InfoCubes.
Now client wants to know before how much data will be there in InfoCubes in Fact table nad Dimension tables in both the InfoCubes. I have the total size of all the 10 tables from the sources given to me by the DBA. I wan not sure how I can convert that info for Fact table and Dimension table as I have not yet created these Infocubes.
Please help me with this on how I should address this.

hi,
The exact data will be hard to give however you can reach at a round figure in your case.
You are consolidating the data from the tables that means that there is relation between the tables. Arrive at a rough figure based on the relation and the activity you are performing while consolidating the data of the tables.
For example, let us say we want to combine data for sales order and deliveries in a DSO.
Let Sales order has 1000 records and Delivery has 2000 records. Both the tables have a common link (Sales Order).In DSO you are combining the data that means the data will be at the most granular level consist of Delivery data, so the maximum no of records which the consolidated DSO can have is 2000.
regards,
Arvind.

How fact links to Dimension Tables.

Hi All,
Can any one explain how the ROW_WID of the dimension table and the related column in the fact table both gets populated with same values in different mapping ?
Consider if we want to develop a new fact and dimension tables, then how should i proceed for the ROW_WID and the join between fact and dimension.
Thanks in Advance.
Regards
Vishwanath

Hi
Basically in BI Apps all dims are first populated and every dim table has a row wid column apart from the primary key combination(datasourceid+integration id) .If you open a seeded mapping and you would see this row wid column is populated using a reusable sequence generator transformation.So everytime u run this mapping the row wids change..........
Now coming to the facts............as a normal rule of thumb in ETL u run the facts after all the dimensions........If you open any seeded fact mapping you will observe that every fact has a wid associated the dims it joins to.......so if a fact is joining to 3 dims then there will be 3 wids associated to each dim .These wids are again populated using a lookup on the dimension table and extracting row wid for relavant id of the dim.So u get the value of row wid of the dimension in the wid column of the fact....Please let me know if u hv questions
With Regards
Venkatesh

Issue using one 2 Fact tables with one dimension Table.

Hi,
I have 1 Dimension table X and 2 Fact tables A and B
X is joined to Both A and B for Loan Amount ( with A) and for colleatral amount (with B) when I am selecting the X.Product_Name, A.Loan_Amt, B.Collateral Amount, it is giving an error message
State: HY000. Code: 10058. [NQODBC] [SQL_STATE: HY000] [nQSError: 10058] A general error has occurred. [nQSError: 15018] Incorrectly defined logical table source (for fact table EIP Collateral FACT) does not contain mapping for [EIP Reporting FACT.PD ID]. (HY000)
Any clues???
Is there a Inner or Outer join which needs to be created or set in the RPD to get the desired results???

Ok..
I have one table which is Porfolio Details which has Portfolio name, Product Category , Product Name, Product ID, Product sources code.- This is my Dimension table.
I have another 2 set of fact tables : EIP Reporting FACT and EIP Collateral FACT..
These two tables are joined to Portfolio Details table.
EIP Reprting FACT gives portfolio wise Loan Amount
and EIP Collateral FACT gives Portfolio wise Collateral Amount details for same set of customer..
Now, I am selecting Portfolio Name, Product Category, Product Name,SUM( EIP Reporting FACT.LOAN_AMOUNT), SUM(EIP Collaetral FACT.Collateral_Amt) in a report
Now, on selecting these columns I am getting that error message which is related to mapping.
If I take any column from Portfolio details table and any column from EIP Reporting FACT- It works.
If I take any column from Portfolio details table and any column from EIP Colletral FACT- It works.
But if I take any column from portfolio table and columns from both FACT tables it gives mapping error...
Hope I am able to explain the issue in a better way now..
Edited by: help-required on Mar 11, 2010 6:53 PM
Edited by: help-required on Mar 11, 2010 6:53 PM

[39008] Logical dimension table has a source that does not join to any fact

Dear reader,
After deleting a fact table from my physical layer and deleting it from my business model I'm getting an error: [39008] Logical dimension table TABLE X has a source TABLE X that does not join to any fact source. I do have an other fact table in the same physical model and in the same business model wich is joined to TABLE X both in the physical and business model.
I cannot figure out why I'm getting this error, even after deleting all joins and rebuilding the joins I'm getting this error. When I look into the "Joins Manager" these joins both in physical as well as logical model do exist, but with consistency check it warns me about [39008] blabla. When I ignore the warning and go to answers and try to show TABLE X (not fact, but dim) it gives me the following error.
Odbc driver returned an error (SQLExecDirectW).
Error Details
Error Codes: OPR4ONWY:U9IM8TAC:OI2DL65P
State: HY000. Code: 10058. [NQODBC] [SQL_STATE: HY000] [nQSError: 10058] A general error has occurred. [nQSError: 14026] Unable to navigate requested expression: TABLE X.column X Please fix the metadata consistency warnings. (HY000)
SQL Issued: SELECT TABLE X.column X saw_0 FROM subject area ORDER BY saw_0
There is one *"special"* thing about this join. It is a complex join in the physical layer, because I need to do a between on dates and a smaller or equal than current date like this example dim.date between fact.date_begin and fact.date_end and dim.date <= current_date. In the business model I've got another complex join
Any help is kindly appreciated!

Hi,
Have you specified the Content level of the Fact table and mapped it with the dimension in question? Ideally this should be done by default since one of the main features of the Oracle BI is its ability to determine which source to use and specifying content level is one of the main ways to achieve this.
Another quick thing that you might try is creating a dimension (hierarchy) in case it is not already present. I had a similar issue few days back and the warning was miraculously gone by doing this.
Regards

Mapping dimension table to fact table in admin tool 10g

Hi
I have a criteria when it is run uses fact 1 as fact table and gives result, and when I add new column to this criteria an extra dimension(dim1) gets added to query backend and fact 1 changes to fact2.
The problem I am facing over here is both should result same amount for records. but due to new column from dim1 and new fact table fact2the amount varies and inaccruate results have come.
When I have checked the sources for Fact in logical layer i can find these facts(fact1,fact2) where fact 1 is not mapped with dim 1 and fact 2 is mapped with dim1.
Will mapping dim1 to fact1 will solve my problem.. And what would be the steps to add/map dim1 to fact1.
Please suggest.

I just checked back the setting and here are the changed details again.
I have a criteria where when it is run, the backend query is formed with f1 fact table.
And for the same criteria when I add a column c1, the backedn query is formed with f2 fact table and f1 is no more here and one new dimension d1 consisting c1 is getting added.
In both the cases results are different..the expected thing is same results.
Note:
d1 is connected to f2 checked in physical diagram
d1 is not connected to f1 checked in physical diagram.
when I checked the connection between three table in physical diagram. Only d1 and f2 are connected and f1 is not connected to either of table. How to go about this issue.
Please suggest.

Regarding Dimension Table and Fact table

Hello,
I am having basic doubts regarding the star schema.
Let me explain first regarding star schema.
Fact table containes Key fiigures and Dim IDs,Ok,
These DIm ids will be connected to my dimension tables.The Dimension table contains Characterstics and these Dim ids ,Ok.
Then My basic doubt
1.How does DIm id will be linked to SID tables
2.If I have not maintained any master data or text or Heirachies then SID tables will it be generated or not?
3.If it is generated I think there is use of This SID now..as we have not maintained Master data.
4.I am haing 18 characterstic which are no way related to each other in that scnerio how does Dimensions have to identified.?or we need to inclued whole chracterstics in one dimensions or we need to create seprate dimesnions for each of them..?(max is 13 dimensions)
5.If Dimension table contains dim ids and characterstics then where does the values for characterstics will be stored...?
( for ex..sales rep is characterstics for this we will be giving values some names where does these values will be stored..)

hi Vasu,
e.g we have infocube with
- dimension 'location' -> characteristic 'sales rep', 'country'
- dimension 'partner'.
fact table
dim-id('sales person') dim-id('partner') revenue
1001                   9001              500
1002                   9002              300
1003                   9004              200
dimenstion table 'location'
dim-id sid-id(sales rep) sid-id(country)
1001    3001              5001
1002    3004              5004
1003    3005              5001
'sales rep' sid table
sid   sales rep
3001 abc
3004 pqr
3005 xyz
'country' sid table
5001      country1
5004      country2
so from the link dim-id and sid, we get
"sales rep report"
sales-rep   revenue
abc        500
pqr        300
xyz        200
"country report"
country    revenue
country1   700
country2   300
hope it's clear.

Should I relate a fact table to a fact table to a dimension table?

Similar Messages

Maybe you are looking for