Multiple referenced relationships over the same intermediate dimension - generated processing query

Question

Hi, I know the title is a bit confusing so let me try to explain it:
I have added 3 new dimensions do the AdventureWorks cube - RefA, RefB and RefC:
They are all related to the DimReseller table, and finally, to the FactResellerSales table. In the dimension usage chart, you can see that there are 4 referenced relationships using the Reseller dimension as the intermediate dimension. The Geography
was the existing one, and the other 3 were added.
Now, if I process a partition from the Reseller Sales measure group, the Profiler catches this generated query on the server:
SELECT [dbo_FactResellerSales].[dbo_FactResellerSalesSalesAmount0_0] AS [dbo_FactResellerSalesSalesAmount0_0]
,[dbo_FactResellerSales].[dbo_FactResellerSalesOrderQuantity0_1] AS [dbo_FactResellerSalesOrderQuantity0_1]
,[dbo_FactResellerSales].[dbo_FactResellerSalesExtendedAmount0_2] AS [dbo_FactResellerSalesExtendedAmount0_2]
,[dbo_FactResellerSales].[dbo_FactResellerSalesTaxAmt0_3] AS [dbo_FactResellerSalesTaxAmt0_3]
,[dbo_FactResellerSales].[dbo_FactResellerSalesFreight0_4] AS [dbo_FactResellerSalesFreight0_4]
,[dbo_FactResellerSales].[dbo_FactResellerSalesDiscountAmount0_5] AS [dbo_FactResellerSalesDiscountAmount0_5]
,[dbo_FactResellerSales].[dbo_FactResellerSalesUnitPrice0_6] AS [dbo_FactResellerSalesUnitPrice0_6]
,[dbo_FactResellerSales].[dbo_FactResellerSalesUnitPriceDiscountPct0_7] AS [dbo_FactResellerSalesUnitPriceDiscountPct0_7]
,[dbo_FactResellerSales].[dbo_FactResellerSalesTotalProductCost0_8] AS [dbo_FactResellerSalesTotalProductCost0_8]
,[dbo_FactResellerSales].[dbo_FactResellerSalesProductStandardCost0_9] AS [dbo_FactResellerSalesProductStandardCost0_9]
,[dbo_FactResellerSales].[dbo_FactResellerSales0_10] AS [dbo_FactResellerSales0_10]
,[dbo_FactResellerSales].[dbo_FactResellerSalesEmployeeKey0_11] AS [dbo_FactResellerSalesEmployeeKey0_11]
,[dbo_FactResellerSales].[dbo_FactResellerSalesPromotionKey0_12] AS [dbo_FactResellerSalesPromotionKey0_12]
,[dbo_FactResellerSales].[dbo_FactResellerSalesSalesTerritoryKey0_13] AS [dbo_FactResellerSalesSalesTerritoryKey0_13]
,[dbo_FactResellerSales].[dbo_FactResellerSalesResellerKey0_14] AS [dbo_FactResellerSalesResellerKey0_14]
,[dbo_FactResellerSales].[dbo_FactResellerSalesProductKey0_15] AS [dbo_FactResellerSalesProductKey0_15]
,[dbo_FactResellerSales].[dbo_FactResellerSalesCurrencyKey0_16] AS [dbo_FactResellerSalesCurrencyKey0_16]
,[dbo_FactResellerSales].[dbo_FactResellerSalesOrderDateKey0_17] AS [dbo_FactResellerSalesOrderDateKey0_17]
,[dbo_FactResellerSales].[dbo_FactResellerSalesShipDateKey0_18] AS [dbo_FactResellerSalesShipDateKey0_18]
,[dbo_FactResellerSales].[dbo_FactResellerSalesDueDateKey0_19] AS [dbo_FactResellerSalesDueDateKey0_19]
,[dbo_DimReseller_6].[GeographyKey] AS [dbo_DimResellerGeographyKey5_0] -- 1
,[dbo_DimReseller_22].[RefAKey] AS [dbo_DimResellerRefAKey7_0] -- 2
,[dbo_DimReseller_23].[RefBKey] AS [dbo_DimResellerRefBKey9_0] -- 3
,[dbo_DimReseller_24].[RefCKey] AS [dbo_DimResellerRefCKey11_0] -- 4
FROM (
SELECT [SalesAmount] AS [dbo_FactResellerSalesSalesAmount0_0]
,[OrderQuantity] AS [dbo_FactResellerSalesOrderQuantity0_1]
,[ExtendedAmount] AS [dbo_FactResellerSalesExtendedAmount0_2]
,[TaxAmt] AS [dbo_FactResellerSalesTaxAmt0_3]
,[Freight] AS [dbo_FactResellerSalesFreight0_4]
,[DiscountAmount] AS [dbo_FactResellerSalesDiscountAmount0_5]
,[UnitPrice] AS [dbo_FactResellerSalesUnitPrice0_6]
,[UnitPriceDiscountPct] AS [dbo_FactResellerSalesUnitPriceDiscountPct0_7]
,[TotalProductCost] AS [dbo_FactResellerSalesTotalProductCost0_8]
,[ProductStandardCost] AS [dbo_FactResellerSalesProductStandardCost0_9]
,1 AS [dbo_FactResellerSales0_10]
,[EmployeeKey] AS [dbo_FactResellerSalesEmployeeKey0_11]
,[PromotionKey] AS [dbo_FactResellerSalesPromotionKey0_12]
,[SalesTerritoryKey] AS [dbo_FactResellerSalesSalesTerritoryKey0_13]
,[ResellerKey] AS [dbo_FactResellerSalesResellerKey0_14]
,[ProductKey] AS [dbo_FactResellerSalesProductKey0_15]
,[CurrencyKey] AS [dbo_FactResellerSalesCurrencyKey0_16]
,[OrderDateKey] AS [dbo_FactResellerSalesOrderDateKey0_17]
,[ShipDateKey] AS [dbo_FactResellerSalesShipDateKey0_18]
,[DueDateKey] AS [dbo_FactResellerSalesDueDateKey0_19]
FROM (
SELECT [dbo].[FactResellerSales].[ProductKey]
,[dbo].[FactResellerSales].[OrderDateKey]
,[dbo].[FactResellerSales].[DueDateKey]
,[dbo].[FactResellerSales].[ShipDateKey]
,[dbo].[FactResellerSales].[ResellerKey]
,[dbo].[FactResellerSales].[EmployeeKey]
,[dbo].[FactResellerSales].[PromotionKey]
,[dbo].[FactResellerSales].[CurrencyKey]
,[dbo].[FactResellerSales].[SalesTerritoryKey]
,[dbo].[FactResellerSales].[SalesOrderNumber]
,[dbo].[FactResellerSales].[SalesOrderLineNumber]
,[dbo].[FactResellerSales].[RevisionNumber]
,[dbo].[FactResellerSales].[OrderQuantity]
,[dbo].[FactResellerSales].[UnitPrice]
,[dbo].[FactResellerSales].[ExtendedAmount]
,[dbo].[FactResellerSales].[UnitPriceDiscountPct]
,[dbo].[FactResellerSales].[DiscountAmount]
,[dbo].[FactResellerSales].[ProductStandardCost]
,[dbo].[FactResellerSales].[TotalProductCost]
,[dbo].[FactResellerSales].[SalesAmount]
,[dbo].[FactResellerSales].[TaxAmt]
,[dbo].[FactResellerSales].[Freight]
,[dbo].[FactResellerSales].[CarrierTrackingNumber]
,[dbo].[FactResellerSales].[CustomerPONumber]
FROM [dbo].[FactResellerSales]
WHERE OrderDateKey >= '20080101'
AND OrderDateKey <= '20081231'
) AS [FactResellerSales]
) AS [dbo_FactResellerSales]
/*** One JOIN per Referenced Relationship ***/
,[dbo].[DimReseller] AS [dbo_DimReseller_6] -- 1
,[dbo].[DimReseller] AS [dbo_DimReseller_22] -- 2
,[dbo].[DimReseller] AS [dbo_DimReseller_23] -- 3
,[dbo].[DimReseller] AS [dbo_DimReseller_24] -- 4
WHERE (
([dbo_FactResellerSales].[dbo_FactResellerSalesResellerKey0_14] = [dbo_DimReseller_6].[ResellerKey]) -- 1
AND ([dbo_FactResellerSales].[dbo_FactResellerSalesResellerKey0_14] = [dbo_DimReseller_22].[ResellerKey]) -- 2
AND ([dbo_FactResellerSales].[dbo_FactResellerSalesResellerKey0_14] = [dbo_DimReseller_23].[ResellerKey]) -- 3
AND ([dbo_FactResellerSales].[dbo_FactResellerSalesResellerKey0_14] = [dbo_DimReseller_24].[ResellerKey]) -- 4
As you can see in the comments, the generated query contains 1 join on the referenced table
per referenced relationship. This can slow down the processing if both the Fact table and the Referenced Dimension table are big (and they usually are, otherwise the design would be different). The thing is, all 4 tables are filtered in the
WHERE clause on the same condition, which makes perfect sense. This leads to the conclusion that all 4 columns could have been read from a single join.
I was quite surprised by this kind of query generation and I can't seem to find a reason why this would be so, or how it could be avoided. Naturally, the RefAKey, RefBKey, RefCKey columns could be added to the Fact table, eliminating the need for referenced
relationships, but this would add 3*4 bytes per row to the Fact table. The Fact table in my real example contains around 3 billion rows, so adding extra bytes is painful. (Yes, it's partitioned but still ... )
The referenced relationships could also be "dematerialized" by removing the famous Materialize check in the relationship settings. Then again, this would issue a join to the referenced tables at query time, slowing down the query.
Has anyone been profiling processing queries like this one and stopped to think about it?

Answer 1

I don't believe it's on the Essbase side, as it uses a fairly standard API to allow string input to such things, and it's limitation is well beyond 512 chars even for a direct formula input.<BR><BR>I instead suspect that a carriage return/line feed is being inserted by the ODBC driver as part of it's output formatting, and this is causing the API to consider the input record "completed." I could be wrong, of course, but if you examine the Memo field closely, you may find the formatting to have migrated to the Access database, and even if not, you are still using ODBC to access it on the output side, so we're back to the same issue.<BR><BR>Perhaps it really is an issue related to the ODBC drivers in Essbase, but it's not unique to dim build, to formulas, or Essbase for that matter. Allowing a single field to <i>output</i> more than 512 chars in a single field is where I believe you will find the real issue.<BR><BR>Again, we need an ODBC expert to weigh in on this. <img src="i/expressions/face-icon-small-smile.gif" border="0"><BR>