Relationship between Dimension without linking Fact table

Hi,
My question is like I have five dimensions connected to a fact table through primary - foreign key(Composite Key) relationship. Will this referential integrity help if I want some information between two dimension which are not linked directly and I am not
including any measures from fact table .
Example: Suppose I have customer, Product and Manufacturer Dimensions all linked to a fact table but not linked to each other directly but can I get right result when I want to know what are the manufacturer for each product? or list of
customers using a particular product. Will the referential integrity work ? since they all are related in fact table.
regards
Sanjoy ghosh

Hi Sanjoy -
The answer to your questions depends on your dimensional design and exactly what the fact table represents. Fact tables naturally capture the intersection of the different dimensions. This is true whether you physically implement a
PK - FK relationship in the relational db.
In your case, since customer is involved, sounds like a sales transaction fact. If that's true, you can easily join from customer, through the fact, to the product dimension, to get the list of customers that purchased a particular product.
For the manufacturer for each product, a sales transaction fact will not necessarily answer this question completely. Particularly in the case of products that have no sales for a given period, and thus, don't have any fact records to join from manufacturer
across to product. If you need to solve this question, you have some other options:
- flatten the Manufacturer directly into the Product dimension as attribute of the product (probably the simplest approach and allows you to remove a key from the fact)
- embed the Manufacturer key directly in the Product dimension (if you need the Manufacturer dimension separate for use with other events / facts and more detailed dimensionality - i.e., detailed attributes about the Manufacturer that wouldn't need
to be flattened onto the product)
- build a factless fact that captures the products offered by a given manufacturer at a given point in time (perhaps representing various products catalogs and associated dates. This would allow you to capture rich details about each dimension separately
and use the factless fact to record)
Let me know if that helps.
Brent Greenwood, MS, MCITP, CBIP
// Please mark correct answers and helpful posts //
http://brentgreenwood.blogspot.com

Similar Messages

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

Dimension usage relationship between dimensions

Hi,
please I have a case where an attribute of a dimension is part of the measure in a report, How can I establish a dimension usage relationship between this table and other dimension that is related as below( whereby the supposed fact table primary key is
appearing as foreign key in the dimension table). Thanks
ACCOUNT TABLE
accid -PK
EXTRAS TABLE
accid -FK

Hi 14QR1A,
According to your description, you want to build the relationship between dimension tables. Right?
In Analysis Services, it can have relationship between dimension like some snowflake schema. In BIDS, you can direct build the relationship between dimension tables in Data Source View. For example, the ProductCategory has relationship with
ProductSubCategory in AdventureWorks sample.
If you have any question, please feel free to ask.
Best Regards,
Simon Hou
TechNet Community Support

3 confirmed Dimensions and 2 fact tables

Hi experts,
how can we connect 3 confirmed Dimensions and 2 fact tables without loops and traps please give me a solution

Hi,
Dimensions Tables : Dimension tables are typically small, ranging from a few to several thousand rows. Occasionally dimensions can grow fairly large, however. For example, a large credit card company could have a customer dimension with millions of rows. Dimension table structure is typically very lean, for example customer dimension could look like following:
    Customer_key
    Customer_full_name
    Customer_city
    Customer_state
    Customer_country
Fact Tables :a fact table consists of the measurements, metrics or facts of a business process. It is often located at the centre of a star schema or a snowflake schema, surrounded by dimension tables.
Fact tables contain keys to dimension tables as well as measurable facts that data analysts would want to examine. For example, a store selling automotive parts might have a fact table recording a sale of each item. The fact table of an educational entity could track credit hours awarded to students. A bakery could have a fact table that records manufacturing of various baked goods.
Context Versus Alias Overview :
http://www.dagira.com/2009/07/22/context-versus-alias-overview/
How to create context :
http://www.bidw.org/business-objects/universe-design/understanding-context-and-its-use-in-business-objects-universe/
You can also look on the eFashion universe for more information.
Thanks,
Amit

How many line item dimensions can a fact table have?

Hi,
How many line item dimensions can a fact table have? Is it tht Max of 16 dimensions(13+3) .Does the 16 dimensions include line items dimensions as well .
Pls reply.
Thanks
Praveen

It includes all dimensios, including line item dimensions.
If you have line item dimension, pl note you cant assign any other characteristic to that dimension.
Ravi Thothadri

Relationship between dimensions

hi everyone,
we are facing slight design issue in our datawarehouse. Is it a fair idea to have relationship between two dimensions? actually one dimension is related to other dimensions in SCD implementation. e.g. customer changes his products over time. so product dim key needs to be present in customer dimension table. is this type of design ok ?
TIA

Hi Yogesh,
I guess the question is really what you intend on doing with this relationship...? I guess there are a couple of ideas on this:
1) The dimension is actually customer products, not so much customer or product. Note you may have a separate customer dimension to store all the addresses. In that case your key to products would duplicate the customer key and you would have to make sure that they are derived from the same records source in order to ensure that the fact record links to the same customer as in customerproducts dim.
2) You really only want to make sure that the product code you store with the customer is a valid one. In that case you just have a reference table (which happens to be a dimension) in the ETL process. You can implement this a ref integrity between the 2 tables...
3) You want to somehow use this in your query tool. Than I think it may be worthwhile to consider option1.
If you are thinking relationships, and you do not necessarily want users to query your model, you may want to consider a slightly normalized data store model.
So I guess you can go many ways, but in the end this is driven by what you need to do with this information.
Hope this makes some sense, feel free to push this discussion along :-)
Jean-Pierre

What is correct way to join a start/end date driven dimension to a fact table in data foundation?

I have a bad universe or a data design issue.
Several versions of hierarchies reporting store entities in reporting Fact measures.
Example of date driven Hierarchy Dimension:   ORG_KEY
                                                                            START_DATE
                                                                            END_DATE
                                                                            STORE_NUMBER
                                                                            ORG_HIERARCHY
                                                                            CURR_FLG   (Y/N)
Fact table :                                                         ORG_KEY
                                                                             CALENDAR_KEY
                                                                             TRANS_DATE
                                                                             $amount
Calendar Dimension:                                            CALENDAR_KEY
                                                                              DAY_DATE
                                                                               FY_WEEK          (201452)
                                                                                FY_PERIOD      (201412)
                                                                                FY_QUARTER   (201401)
                                                                                 FISCAL_YEAR    (2014)
Users WISH:
Wish for store number and org hierarchy to pull as of the last day of each pull without prompt.    The Store(ORG_KEY) as in the fact table; but the ORG_HIERARCHY and other attributes as of the last day they pull.
Daily (Would be Calendar.Day_Date in Filter) ,
Week to date (would be Max Calendar.Day_Date for (201452) FY_WEEK as entered,
Month to date,
Year to date,
AdHoc queries.
My problem is I see how they could manually pull this in Webi.   I have tried everything I know to join to no avail. I have not gotten @Prompts to work in joins, derived tables, etc. in the data foundation. Wonder what is difference between parameter in Data foundation vs. filter in buisness layer.    None of them worked.
Please help!   ANY ideas would be appreciated.   .

{Note that abbrevations in brackets are just for short form further down the answer}
Join Store Dim (SD) to Transaction Fact (TF) on ORG_KEY=ORG_KEY with 1 to Many cardinality
Create an alias of Calendar Dim and call it Transaction Date (TD)
Join TD to TF on TD.CALENDAR_KEY=TF.CALENDAR_KEY with 1 to Many cardinality
Create a predefined condition in your universe called "Return Yesterday's Transactions" as:
TD.DAY_DATE = trunc(sysdate-1) <-- That assumes Oracle database; use whatever is correct for yesterday for your RDBMS
The above predefined condition when added to your data query will return only yesterday's transactions.
However, if you want to return all the different types of sales, you would need an object for each one. To do that, you'd use a case statement. Again, using Oracle syntax, an example of MTD would be:
SUM(CASE WHEN trunc(TD.DAY_DATE,'yyyymm') = trunc(sysdate,'yyyymm') THEN TF.amount END)
If you have any more questions about how this approach would work please shout.
As an alternative, you could create a time hierarchy and add scope of analysis to your report for it and enable drilling at report level.

Link fact tables?

hi all,
I have two fact tables – charges and payments and both these fact tables are in the cube (as measure groups). On the relational side, these two fact tables are “linked” by a column called trans_no. Linking these two tables could be little tricky because
a single charge can have multiple payments.
for example, let’s say there was a charge of 100$ but the payment was done in two installments so there is one row in the charge fact table, but 2 rows in the payment fact table – both rows have the same transaction number but different date.
It is also possible to have two charges in the charge fact table with the same transaction number but one payment in the payment fact table. So I think this is a many-to-many relationship.
How can I link these tables in SSAS? I would to be able to show payments and charges side by side down to the transaction level. Please advise and thanks for the help.

thank you Ken, so i am going to have dimensions then? -
1. off of payments
2. off of charges
3. "Transaction" dimension
The reason i am saying i need #1 and #2 is because i need some other attributes such as "transaction type"(void etc) from both the fact tables. does this sound correct? i feel like i am cluttering the cube :(

Steps to create Universe without using Fact Table

Dear All,
i am confronting with a problem by creating an Universe.
The problem is that we do no have any fact table.
Could you please explain the steps for creating an universe without fatc table?
Thanks
Pat

The first thing to do is identify the tables in your schema that contain measures. These will be your base tables for contexts.
Then identify all the tables that relate to each of your candidate fact tables.
You may identify two related tables, both with facts in, which would give you a fan trap.
Say you have a schema with only three tables and they are related as: T1 -< T2 -< T3
T2 and T3 both have measure columns.
What you would need to do is create an alias of T2 (AT2) and join it to T2.
You would then have two contexts, T1-< T2 , T2-< T3 and T1-<T2, T2- AT2
For objects from T2, derive the dimensions from T2 and the measures from AT2.
Beyond that, it's fairly standard.
If you have a data schema it is going to be much easier for you.

RELATIONSHIP BETWEEN VBAK/VBAP AND V46R_HEAD TABLE

Hi,
can you please tell me that is there any relationship between VBAK and V46R_HEAD TABLE or VBAP and V46R_HEAD TABLE table.
where V46R_HEAD TABLE is a structure and i want to display sme fields of vbak and some of V46R_HEAD and some of VBAP.
I got the relation between VBAK and VBAP ie. the field VBELN. But i am not getting the relation with V46R_HEAD sturcture.
Please help me to solve this problem.

Hi,
the field vbeln is present in V46R_HEAD also.
Please check it!! Please do a CTR+F and look for VBELN.
Regards.

Star schema without a fact table?

Hi,
I'm preparing my warehouse for using with Discoverer and my question is about the star schema.
- Is a star schema directly associated with data warehouse?
- Can I talk about a star schema if a) I do not have a fact table (no summarized values) and b) if I do not have a dimension of time?
The problem is, I'm thinking of usine Discoverer but should I use it if it's not connected to a data warehouse?
As I told, I'd like to modelized my data "like" a star schema but my "center table" will contain only the foreign key of my dimensions; no time dimensions, no aggregate data in the center table (fact table).
Is there another word for the model I'd like to do?
Thank in advance.

Hi,
Is a star schema directly associated with data warehouse?Not really, a star schema is just one where there is one large fact table joined to many smaller dimension tables using key fields. You usually see this in data warehouses.
Can I talk about a star schema if a) I do not have a fact table (no summarized values) and b) if I do not have a dimension of time?A star schema must have a fact table but it doesn't need contain summarised values or a time dimension.
You can use Discoverer with any Oracle database, it doesn't have to be a data warehouse.
Rod West

A loop between two or more fact table

Hi,
How Does Discovere solve the loop between tables ? (join between with more fact table in a star schema)
Microstartegy resolve this problem with diffrent select and union the results. Instead BO use the contexts.
Thank you.
null

I don't think Lightroom handles cmyk images.
For rgb and gray, you can stack the images, or make the gray from a virtual copy of the rgb. In this way, simply unstacking the images results in your requested "show corresponding images".

Problem using same dimension in 2 Fact tables

Hi,
I am facing this strange problem with the out-of-box BMM metadata mapping :
The "Dim_W_GL_ACCOUNT_D" is joined to "Fact_W_GL_OTHER_F" and "Fact_W_GL_BALANCE_F" facts. Both these fact tables have a inner join to "Dim_W_GL_ACCOUNT_D". The change I have made in th BMM is - I added 2 new logical dimensions DimA and DimB and joined these to the above 2 fact tables.
The O-O-Box "GL Account Balance" Report works fine which has 3 logical columns (GL Account Number, Financial Statement Item, GL Account Category) from the "Dim_W_GL_ACCOUNT_D" and 1 Fact column "Closing Amount" which points to the "Fact_W_GL_BALANCE_F"."BALANCE_GLOBAL1_AMT" fact.
When I add 1 logical column each from my 2 new Dims I created, the report output shows the Fact column "Closing Amount" as $0.0. Upon investigating the log, the query shows it is using the "Fact_W_GL_OTHER_F" instead of "Fact_W_GL_BALANCE_F" fact which has the "Closing Amount" column. I am not sure how. When I drop the logical column "GL Account Number" and keep my 2 new logical columns in the request, the "Closing Amount" is shown correctly. I also saw there is a Dim Hierarchy for "GL Accounts" --- the "GL Account Number" is on a lower level than the "Financial Statement Item" and "GL Account Category" columns from the same logical dimension table which are 1 level higher.
How do I make the request pull data at the "GL Account Number" level and still have the query fetch data from "Fact_W_GL_BALANCE_F"."BALANCE_GLOBAL1_AMT" (Closing Amount) with my 2 new logical columns included?
Any help is appreciated. Thanks a bunch.

The dimensions I added are aliases of their respective W_XXX_D tables and I have the content levels set for the LTS of my Dims (DimA and DimB) at the detail level. One thing I am not able to figure out is why is it going after "W_GL_OTHER_F /* Fact_W_GL_OTHER_F */" when it should go to W_GL_BALANCE_F and W_GL_BALANCE_A.
The "GL Account Number" is sourced from the W_GL_ACCOUNT_D table and the other columns "Fin Statement Item" (FIN_STMT_ITEM_CODE) and "GL Account Category" (GL_ACCOUNT_CAT_CODE) are sourced from that same table too. But these 2 cols are on a higher level of hierarchy than the "GL Account Number" in the "GL Accounts" Dim-Hierarchy. But, as soon as I remove the "GL Account Number" logical column from the report the closing amounts show fine although the "Fin Statement Item" and "GL Account Category" cols from the W_GL_ACCOUNT_D table remain. Then the query does not show the W_GL_OTHER_F table in the log. Is there something I need to do to this dim-hierarchy?

Conformed dimensions across several fact tables

Hi, not exactly sure how to phrase my question, so I'll just start babbling and maybe it'll come across. In our OBIEE repository (from BI applications "project analytics"), we have dimensions of CONTRACT, CONTRACT LINE, PROJECT, and TASK (CONTRACT and CONTRACT_LINE really come from a single dimension table, but are different rows and so really can be thought of as coming from two different dim tables). TASKs are really children of projects - but they were broken out into a separate dimension in the data model (no idea why....). Also, in our business, a task can be tied to one and only one contract line.
Now here's the rub - because TASK is a separate dimension from PROJECT, there is really nothing that relates them except through a fact table. This is a real pain, as it has two limitations:
1) If a "fact" for that combination of PROJECT / TASK hasn't happened yet, then no row in fact table = nothing that says they are related
2) Even if you do have a fact for everything - now our query is scanning through a fact table of (in our case) 300+ million rows, just to say which task is tied to which project
I'd like to solve this by creating a very simple "factless fact" which has columns for CONTRACT, CONTRACT LINE, PROJECT, and TASK, and simply inserts the appropriate surrogate IDs (wids) into this. Thus, instead of a 300+ million row fact table, we should be down to only 400,000 or so task / project / line / contract combos.
Now here's my question: I have a "combined" subject area that includes a project cost, project revenue, project billing, and in theory this new fact table I'm talking about. I'd want to set the new fact table to be the "implicit" fact - so that if someone just asks a questions like "show me contract lines, and which projects and tasks are assigned to it" - it would go to the new, slim, fast fact table.
But I'm concerned about what happens when someone then throws in a cost amount, revenue amt, etc. onto the query. I'm assuming that OBIEE will be smart enough to understand it should forget the implicit fact, and start using the "real" facts. Or maybe use all of them including the new fact.
I'm just trying to see if I can anticipate this causing any issues.
Thx,
Scott

You are correct, the implicit fact will only be used when there isn't any other fact measure defined in your query. Unfortunatelly you can only define an implicit fact per SA, we would love to be able to have more flexibility such as defining them per dimension etc. Another way to "force" OBIEE to select from an specific fact is to select a column from it in your Answers query. You don't to see this column in output so you can hide it. Of course this "hack" is not really very user friendly as it makes adhoc query building much more complex.

How to find the table relationship between BSEG-BELNR with CE11000 table.

Hi,
Please help me to find out the table relationship between BSEG with CE11000 table.
I have BSEG-BELNR value.
Thanks in Advance
Shankar

Hello,
BAsically the relationship can be foundon the basis of cost centre it will be good if you paste the structure ce11000.
I have worked on it and as far i as i can recall it contain value fields right...like vv205,vv305 etc?
Provide me more details.
Are you preparing some reconcillation report for costing based COPA or Account based COPA..?
Hopefully will help you out..
Regards,
Nabheet

Relationship between Dimension without linking Fact table

Similar Messages

Maybe you are looking for