Fact to Fact Relationship urgent!!!!!!!

Let us suppose there are 2 dimensions and 2 facts and every dimension is joined with every fact and there is no relation between two facts while selecting columns from both the facts with any dimension column its involving only one fact, we found one solution which is combined sql (union).
can we have any other solution?
Thanks in advance

I hope I got your question.
If you have 2 unrelated facts joined to a common dimension, and if you drag the dimension value and the measures from your fact tables, the data should show up as expected.
For e.g. we have an orders received and an orders fulfilled fact tables that are unrelated, that we can see by day (the common dimension) in a single query without any union. Of course, your measures will need to be aggregated for your fact tables to return a single row for each dimension value, otherwise it would make no sense.
HTH,
Nilanshu.

Similar Messages

How to create Measue Logical Column in fact?- urgent

Hi All,
In BMM Layer i have 2 Fact Tables with Different Sources .
Fact - Fact1
X1
Fact - Fact2
Y1
But now I want to create Logical Column in 'Fact - Fact 2' as follows
Z1 = X1 + Y1
But Once aftre cretaion of that Column , from the Report side i can able to see the data only if the report contains Z1 Attribute alone.
But if the report contains any other attribute along with Z1... that Z1 doesnt have any Data .. its Blank.
How can i resolve this issue ?

Have you all conformed dimensions between the two facts?

Logical Fact Column -Urgent

Hi All,
I have a measure in my production reporsitory which is working fine & giving expected results. I have one more environment which is similar to production, and in that environment the repository is pointing to Production Database.
One Measure is working fine in production but giving different values in another environment. Whereas both the environmnets are pointing to same Production database.
I have checked the calculation of the measure in both the environmnets..its matching. Also i have checked all the Physical & BMM layer joins. Its seems to be same in both the environment.
Please suggest, what else i need to check to identify the issue?
Please reply its really urgent for me.
Regards,
Ashish A.

Hi All,
I figured out the issue. One of the logical column was wrongly mapped.
Thanks anyways.
Regards,
Ashish A.

How to Link two Facts with Different Time Granularity (Year, Quarter) to a Single Time Dimension

Hello All,
I have the below scenario where i have Two Facts Fact Quarterly and Fact Yearly but one Time Dimension which has Quarter grain.
So my question is how do i Establish relationship from Fact Yearly to Time Dimension??
Ex:

Hi naveej,
According to your description, you want to know how to build the relationship with time dimension and fact tables. Right?
Based on your screenshot, it's better to have only one fact table for sales and build the relationship with time dimension. To determine quarterly or yearly data only depends on how you slice the time dimension. However, I notice that the Revenue for year
is different from the aggregated Profit for quarters. If the Revenue and Profit are different measure, you need to have two fact tables. And you should build the relationship (Regular) between TimeDim and FactYearly on YYYY attribute.
Reference:
Defining a Fact Relationship
Best Regards,
Simon Hou
TechNet Community Support

Adding a single table without a logical join to another table (OBIEE 10g)

Sometimes I want to just display a single table without a logical join to another table in the repository. However, everytime I move it to the Business Model and Mapping layer and perform a Global Consistency Check, it tells me that it needs a logical join and I am forced to create another table to join to it. Thus creating a dimension-fact relationship. There are times I don't need this relationship and just want to display some data. Is there anyway to get around this?
Thanks in advance!

Yes,You have to create a join.You cannot take single table to BMM layer.You can create an alias of the table.Join this alias and base table through any common column and take both tables to BMM and desired table to presentation layer.
Another way is to create a view in physcial layer.Write a select statement like
Select primary_key from Table
Where primary_key is primary key of base table.Join this view ith base table and repeat the steps defined for Alias.
Regards,
Sandeep

Modeling an Extension table in OBIEE 11G

Hi, I have the below scenario.
Dim X*
Col1..........Col2
1...............xxx
2...............yyy
3...............zzz
Dim Y*
Col1........Col2
1...............A
1...............B
1...............C
2...............A
2...............B
3...............C
Fact*
Col1..........Col2
1...............$10
1...............$20
1...............$30
2...............$10
2...............$20
Dim and Fact Relationship*
Dim X.Col1= Fact Z.Col1
Dim X.Col1= Dim Y.Col1
Physical Diagram*
Fact ---------------> Dim X <------------- Dim Y
............N to 1......................... 1 to N
BMM:*
I modelled as "Sales Team" logical table has 2 sources (Dim Sales Team and Dim Sales Team Member) to maintain the Star.
Fact -------> Sales Team
I want the report as below (Fact rows to be displayed by Sales Team):
Dim X.Col2 .........._Dim Y.Col2_ ................._Fact.Col2_*
...........................................A
xxx .....................................B...............................$60
............................................C
YYY......................................A ..............................$30
............................................B
But the way I designed as described above, Below is the report that I am getting:
Dim X.Col2.........._Dim Y.Col2_ ..........................._Fact.Col2_*
.............................................A.................................$10
xxx ......................................B..................................$20
............................................C..................................$30
YYY......................................A..................................$10
............................................B..................................$20
Could some one please help on how to model to achieve the desired report?
Thanks in advance.
Edited by: user2307047 on Nov 30, 2012 2:45 PM

Thanks for the response Srini.
Dim Y is an Extension table of Dim X, Therefore I cannot join Dim Y to Fact Z
Consider the below scenario.
Dim X (Sales Team) & Dim Y (Sales Team Member). A single sales team can have multiple sales team members. so the relation between these two dimensions is
Dim X(Sales Team) <------------- Dim Y(Sales Team Member)
-------------------------------1 to N
ultimately, the goal is to display the report in below fashion when fields from Dim X Dim Y and Fact Z are pulled.
Dim X.Col2 .................Dim Y.Col2 .................Fact.Col2
...........................................A
xxx .....................................B...............................$60
............................................C
YYY......................................A ..............................$30
............................................B
I do not want 3 rows of fact table for XXX, it should group by Dim X.Col2 and give only one row for XXX.
Hope you understood the problem. If not, please let me know so that I can try to put in other way
Thanks again.

In How Many ways or Techinques used to have relation beween two factables which dont have common dimesions

Hi folks,
In How Many ways or Techinques used to have relation beween two factables which dont have common dimesions
or
how to establish relation beween two factables.
Thanks
Ravindra KAvali

Hi kavali1985,
According to your description, you want to build relationship between two fact tables without common dimension. Right?
In Analysis Services, to build relationship between two fact tables, at least you need to have "common" column in both tables which can link these two tables. If so, we can create a fact dimension based on one fact table, then build the relationship
with the other fact table. Please refer to link below:
Defining a Fact Relationship
Best Regards,
Simon Hou
TechNet Community Support

Distinct count of role-played dimension attribute

Needed distinct count of AccountGroup attribute of AccountB dimension which is a role played dimension of Account.
Added measure distinct count of the dimension attribute (AccountGroup). In dimension usage added the main fact table as intermediate for other dimensions with many2many relationships.
The two role played Account dimensions must be related to the new AccountFact table with fact relationship.
But then how will I be able to count distinct attribute of
certain Account dimension (out of the two role played dimensions)???
Namnami

Thanks for the links, they are useful. But still they do not explain how to manage a distinct count of
certain role played dimension attribute.
I gave up on this and added that dimension attribute to the fact table so now I do a regular distinct count on a cube fact measure.
Thanks
Namnami

SSAS Cube

Hi ,
I have a star schema cube with a fact table(DrugSalesFact) and a dimension table (DrugDimension) which are directly linked to each other before.
Later we added one more table named DrugNDCVersionsDimension which is linked to
DrugDimension using NDC column.
This new dimension table holds all the versions of a paritiular NDC from
DrugDimension.
My question is , if a user want to see the BilledAmount for drug named "Aceta" and all the versions of its NDC.How can i setup the relation between these three tables in cube, how does the Dimension usage looks like for this?
Somebody is saying that referenced relationship works, but how to set it up in cube.
DrugSalesFact:
DrugKeyNumber(FKey) BilledAmt   DueAmt
1                                  2.5
3
2                                  5.5
6
3                                  10
9
DrugDimension:
DrugKeyNumber(PKey) DrugName NDC(Unique here)
1                                    Aceta
310
2                                    Durox
301
3                                    Cntax
555
DrugNDCVersionsDimension:
DrugSubDimID(PKey) NDC   Version
1                                310    C1.0
2                                310    C1.1

In this case my DrugNDCVersionsDimension and DrugNDCVersionsMeasureGroup will
be one-one right?
Yes
And they both will join to each other on DrugSubDimID which is PKey in DrugNDCVersionsDimension and
this will also be the PKey in DrugNDCVersionsMeasureGroup  table right?
Yes
I guess you have two separate entities (table or view) in your Data Source View, one for DrugNDCVersionsDimension
and other one for DrugNDCVersionsMeasureGroup. Fact Realtionship
is possible only when you build your dimension and measure group using the same entity from the data source view. Therefore in DataSourceView you need to have a single entity DrugNDCVersionsDimension,
using this you will have to build a simple dimension and a measure group.
First create a dimension using DrugNDCVersionsDimension
entity and then add the dimension to your cube, later create a measure group using the same entity. When you do this analysis service by itself defines a fact relationship between dimension and the measure group.
There is one more possibility :
As per the requirement, you may have to create a complex dimension using multiple entities from data source view, wherein your dimension key is DrugSubDimID.
If this is the case then you can define a regular relationship between DrugNDCVersionsDimension
and DrugNDCVersionsMeasureGroup,
wherein DrugSubDimID
will be the Dimensioncolumn and the MeasureGroupColumn (i.e. the join column).
Saurabh Kamath

Error 38015

Hi all,
I have a modeling problem.
Suppose that there i a fact: RELATIONSHIP using twice the dimension NODE.
The dimension NODE is a factless fact merging other dimension: role, product, sw, hd, version, area, etc.
                    +--- SW
                    |
RELATIONSHIP ===== NODE --- ROLE
                    |
                    +--- PRODUCTWhen I try to link the fact twice with the dimension NODE, OBIEE return error 38015 (have multiple joins. Delete new foreign key object if it is a duplicate of existing foreign key).
So I should create an alias for the NODE (NODE_ORG, NODE_DST) and for all other dimensions related
                  +--- SW_ORG                      +--- SW_DST
                  |                                |
ROLE_ORG --- NODE_ORG ----- RELATIONSHIP ----- NODE_DST --- ROLE_DST
                  |                                |
                  +--- PRODUCT_ORG                 +--- PRODUCT_DSTIn my case there are several dimensions and NODE is shared with other facts. So I must duplicate everything connected to NODE.
Is there an elegant solution for bypassing the problem in OBIEE?
Riccardo

If a dimension NODE is joined with diferent facts like F1,F2 etc no need to go with alias for NODE.
If the NODE wants to join with same fact F1 for different join conditions then you have to go alias for NODE.
As per the consistence check rpd will allows a single join between the physical layer objects, so as per the best practices we go for alias tables for each leaving original tables a side.
hope this helps

Degenerate and Junk dimensions

I am new to SSAS. I want to understand degenerate and junk dimensions in detail. It would be good if you provide with practical examples please.
Regards,
Ramu
Ramu Gade

Junk Dimensions
There are certain scenarios where you will find that the source for a fact table contains a bunch of low-cardinality attributes that don’t really relate to any of the other attributes describing these facts. Some of the more common examples are bit/character
based “flags” or “codes” which are useful to the end users for filtering and aggregating the facts. For example, imagine a user who wants to analyze orders from the order fact table that are flagged as “reprocessed”…they can either filter for facts with
the reprocessed flag if they are only interested in that subset…or they can group by the “reprocessed” flag calculate things like the percent of orders that are “reprocessed”…
Instead of building a separate dimension for each of these individual attributes, another option is to combine them and build what’s known as a Junk Dimension based on the Cartesian product of each of these attributes and they’re corresponding range of values.
This technique does 2 important things:
Saves Disk Space
consider a single 4byte integer key linking to the junk dimension vs. a handful of 4byte integer keys each linking to a separate dimension. Might not sound like a lot on a per-record basis, but once you extrapolate out over a 100mm record fact table the
savings really adds up.
Improves End-User Experience
By keeping the total number of dimensions down to a manageable size it will be easier for your end-users to find the attributes they’re looking for during ad-hoc analysis. Kimball recommends <= 26 dimensions per fact table – of course there are always a
few edge-case exceptions.
Degenerate Dimensions
The Degenerate Dimension is another modeling technique for attributes found in the source transaction table. The main differences between these attributes and the ones that would fall into our Junk Dimension are as follows:
Cardinality
these are typically high-cardinality attributes – in some cases having a 1 to 1 relationship with the fact. These are likely to be the business keys of the fact table such as Purchase Order Number, Work Order Number, etc. Another potential candidate
for the degenerate dimension is free-form comment fields.
Use Case for End-Users
these attributes are not going to be used for filtering/aggregating facts. Instead, these are the types of attributes that are typically going to be used in drilldown or data mining scenarios (ex. Market Basket Analysis). For example, imagine a user who is
analyzing purchase orders in the “delayed” status. After drilling down on the delayed POs for a certain supplier in a certain time period…the next step might be to pick up the Purchase Order Number which would allow this user to trace this small subset of
PO’s back to the source system to find out why they are “delayed”.
Storage
Despite the name, these attributes typically remain in the fact table. There really isn’t much point in moving them out to an actual dimension – because of the high-cardinality there’s likely to be zero space savings…in fact it would probably cost you space
due to the additional surrogate-keys. You’ll also likely be paying a heavy price on the join at query time.
Analysis Services Implementation
For Junk Dimensions, you will create a new dimension at the project-level pointing it to the table (or view) in the data warehouse that materializes the distinct combinations of values for the various junk-attributes. After configuring the dimension at
the SSAS project-level, it can be added to the cube(s) and linked up to the measure group(s) via regular relationships (where appropriate).
For Degenerate Dimensions, the process is the same except you base the project-level dimension off of the fact table (or view). Once the project-level dimension is configured, it can be added to the cube(s) and linked up to the measure group(s) using “fact”-relationships
(where appropriate).
Please mark as Answer if this helps!
Rajasekhar.

Urgent regarding E & F fact table

Hi all,
How and where we find E & F partition fact table having size larger than 30.
It's very urgent.
Thanks & Regards,
Priya.

Hi,
You can find the table related to InfoCube by following the below mention naming convention.
<b>/BI<C OR DIGIT>/<TABLE CODE><INFOCUBE><DIMENSION>
<C or digit>: C = Customer-defined InfoCube
Digit = SAP-defined InfoCube
<table code>: D = Dimension table
E = Compressed fact table
F = Uncompressed fact table
<InfoCube>: The name of the InfoCube without leading digits (if any)
<dimension>: (only used for dimension tables)
P = Package dimension
U = Unit dimension
T = Time dimension
0-9, A, B, C = User-defined dimension tables</b>
And you can find info about the size of infocube:
Calculating size of CUBE & ODS
regards,
Pruthvi R

How to design many to many relationship in the fact and dimension

There is a problem in my project what is the subject.And i wanna know how to implement in owb.I use the warehouse builder 10. Thanks.

You may design and load whatever db model you want to.
But If you set a unique key, you may find some integrity issues. I wouldn't do a many to many relationship between facts and dimensions. This could cause you lots of headaches when users start to submit queries using this tables. You'll probably face performance issues.
Regards,
Marcos

SSAS 2008 snowflake - dimensions with one-to-many relationship (NOT fact table) and hierarchy?

Hi, below is my data model for SSAS 2008 on snowflake schema.
Below is SQL Server DW tables:
DimStudent - StudentID [primarykey], StudentName, DateOfBirth, AddressID
DimStudentAddresses - AddressID [primarykey], StudentID [foreignkey], ddressLine1, AddressLine2, AddressType
FactEnrolment - StudentID, EnrolWeek, EnrolFees
So here FactEnrolement.StudentID is joined to DimStudent.StudentID column,
and relationship between DimStudent & DimeStudentAddresses is one to many I.e. one student can have multiple addresses like primary or secondry address.
To design snowflake schema in SSAS 2008 BIDS project :
[Question-1] how to join one-to-many dimensions (NOT fact table) Like DimStudent & DimAddresses?
[Question-2] At the end I want to have a single dimension only I.e. Student which should have both DimStudent & DimStudentAddresses tables attributes init. So I can create hierarchy from these two table into a single dimension? How
to do this?
Please reply with feedback particular to my above scenario as I refereed other MSDN forums but nothing solid I found.
Any STEP-BY-STEP guideline please. Many thanks.

Hello KM,
Have you solved this issue after refer to Bill's suggestion? Please let us know how things go.
If you have any feedback on our support, please click
here.
Best Regards,
Elvis Long
TechNet Community Support

One to One relationship between Dimensions and Fact Tables

Hi,
Not a real Discoverer question, but seeing as there is such a huge pool of talent here, I thought I'd ask anyway...
Is the concept of having a one to one join between a Dimension and a Fact Table an Acceptable Thing (tm). I'm not talking about a degenerate dimension, as the Dimension would hold additional attributes.
It's something I'm trying to get my head around and would appreciate any viewpoints.
Thanks,
Andy

Hi Andy,
There is of course no distinction in SQL between 1-1 and 1-n joins, but in your database design you would avoid denormalizing data into a dimension table if it was only ever used once.
From a Discoverer perspective setting the join to 1-1 controls how aggregate queries are constructed. Normally, if you have a master-detail 1-n relationship and you aggregate items in both tables then you will get an incorrect result for the master table because the number of rows are multipled by the n detail records. Similarily if you have 2 detail tables in the query and you aggregate items in a detail table you will get incorrect results. Discoverer recognises these situations and raises an error.
Setting the join as 1-1 tells Discoverer that it will get the correct results in these situations and therefore no error is raised. So it is perfectly acceptable to set the joins as 1-1 as long as you know the implications.
Hope that helps,
Rod West

Fact to Fact Relationship urgent!!!!!!!

Similar Messages

Maybe you are looking for