MDX: CrossJoin of generations same dimension

Hi all!
How in Essbase MDX get CrossJoin generations of same dimension? to get result like this:
Gen2     Gen3     Sales
Qtr1     Jan     49 896
Qtr1     Feb     45 668
Qtr1     Mar     45 681
Qtr2     Apr     45 018
Qtr2     May     45 186
Qtr2     Jun     45 989
Qtr3     Jul     44 674
Qtr3     Aug     48 832
Qtr3     Sep     51 986
Qtr4     Oct     48 842
Qtr4     Nov     62 758
Qtr4     Dec     73 372
My MDX query
SELECT
{ CrossJoin({[Year].Generations(2).Members}, [Year].Generations(3).Members) } ON ROWS,
{ [Sales] } ON COLUMNS
FROM [Demo].[Basic]
return error Dimension signature mismatch in function [CROSSJOIN] ...

You can't get CROSSJOIN to work this way. CROSSJOIN has two parameters, Set1 and Set2, per documentation, "set2 - A set to cross with set1. Must not include any dimension used in set1."

Similar Messages

MDX : How to use filter on a dimension without showing it OR merge 2 attributes of the same dimension?

Hello everyone,
I'm kind of newbie with MDX language, I'm trying to get filtered measures from a cube with a specific layout.
Here is my exemple :
I want to get all the "order numbers" where the "invoice" cost is more than 300. Each invoice is linked with an ID, one order number can have several invoices.
So what I do is a select request with 2 dimensions : "order num" and "id_invoice"
Here is the result : I get all the cost sorted by "order num" and I can easealy identify those who are above 300
order num
Id_invoice
cost
Total
Total2
15450307
10032013094498
1671
1737
ok
15450307
10032013099835
66
1737
KO
15450596
10032013094078
8524
8524
ok
15451214
10032013094119
228
4348
KO
15451214
10032013097069
978
4348
ok
15451214
10032013097071
3142
4348
ok
15542434
10032013101736
142
142
KO
15550064
10032013097016
1261
1261
ok
15550346
10032013097586
2252
2252
ok
15550353
10032013098446
2617
2617
ok
What i need : In "cost", I need to have the sum of each cost which are above 300 in one line (without showing the invoice id)
order num
cost
Total
Total2
15450307
1671
1737
ok
15450596
8524
8524
ok
15451214
4120
4348
ok
15550064
1261
1261
ok
15550346
2252
2252
ok
15550353
2617
2617
ok
How is it possible to use a filter on a dimension without showing it or merge 2 attributes of the same dimension ?
The problem is that if I show "id" column, the filter doesn't work properly : it compares 300 with the total cost of the whole order and does not compare with each invoice (which could be under 300 ! - see "KO" in Total2 column)
Here is the request I use to generate this result :
with
member [Measures].[Total]
as (
[TP].[ID INVOICE].[All],
[TP].[ORDER NUM].currentmember,
[Measures].[COST]
member [Measures].[Total2]
as (
IIF([Measures].[COST] >
300, "ok",
"KO")
select
{[Measures].[COST],[Measures].[Total],[Measures].[Total2]}
on
columns,
Filter
             [TP].[ORDER NUM].[ORDER
NUM].members *
             [TP].[ID INVOICE].[ID
INVOICE].members
             ,[Measures].[COST]
> 0
on
rows
FROM [MYCUBE]
Thank you for your help !
Kind regards,
Olivier.

Hi Olivier,
hereunder a similar query against the AW. For all order numbers, we sum all lines above 30 without diplaying the line numbers:
WITH
MEMBER [Measures].[lines above 30] AS
IIF(
[Measures].[Internet Sales Amount] > 30,
[Measures].[Internet Sales Amount],
null
MEMBER [Measures].[aggr lines above 30] AS
SUM(
exists(
[Internet Sales Order Details].[Sales Order Line].[Sales Order Line],
[Internet Sales Order Details].[Sales Order Number].currentmember
[Measures].[lines above 30]
SELECT
[Measures].[Internet Sales Amount],
[Measures].[aggr lines above 30]
} ON 0,
[Internet Sales Order Details].[Sales Order Number].[Sales Order Number] ON 1
FROM ( SELECT
[Product].[Category].[All Products] ON 0,
[Internet Sales Order Details].[Sales Order Number].&[SO51177]:
[Internet Sales Order Details].[Sales Order Number].&[SO51178]
} ON 1
FROM [Adventure Works] )
I reduced the cube with a subselect.
Philip,

Querying last element in a dimension based on another level in the same dimension using MDX

Summary: I need to write an MDX that returns the last date available in the level in the date dimension based for each month in the same dimension.
Details: i have the a dimension which has the following levels.
Dim_Date : Date (key) , Month (name of month), Quarter, Year.
The query i m trying to come up with would return the result something like
Month || Max_date || measure1
Jan 2014-01-25 100
Feb 2014-02-28 200
Please let me know if the above makes sense. Basically i m trying to get the max date for each month.
Thanks
Sri

Hi SrikanthGS,
Assuming that with the last date available for the measure you mean the last date with non-empty figures, consider the following against the AW:
SELECT [Measures].[Internet Sales Amount] ON 0,
Generate (
[Date].[Calendar].[Month].Members,
( Exists ( [Date].[Month of Year].[Month of Year], [Date].[Calendar].CurrentMember ),
Tail (
NonEmpty (
Descendants ( [Date].[Calendar].CurrentMember, [Date].[Calendar].[Date] ),
[Measures].[Internet Sales Amount]
1
) ON 1
FROM [Adventure Works]
WHERE [Product].[Product Categories].[Subcategory].&[1]
Philip,

Performance issue:Show id and Description for same dimension member

Hi,
I am connecting a cube to another reporting system and i need to show the id of member resulting of a query.My first thought was to use this kind of code (bellow) however when i do the same thing with many dimension (many cross join ),it slow down a lot
my query.So how can i have in the same DImension member showing a description and id ? I also have a lot of statement,so i can't have just two columns in the dimension or i will need to duplication the mdx and i could drop down the performance.
So i am trying to get as a result
Dim1 | Dim2| Dim3| Measure
1 50
32 25.2
and also be able to get
Dim1 | Dim2 | Dim3
| Measure
NameElement1Dim1 NameElement50Dim2
NameElement32Dim3 25.2
Thanks in advance
with MEMBER [Measures].[IdElement] as
<element>.currentmember.properties("KEY")
select
CROSSJOIN({[Measures].[IdElement]},{[METRIC].[Description].[All]}),
CROSSJOIN({[Measures].[value]},{<listmetricmdx>})
} on columns,
<pointofview>
<element_and_function>
<TimeBreakdown>
} on rows
<list_filter_clause>
) as list
where ((ElementName is null AND IdElement=0) OR (ElementName is not null))
<list_condition_metric>
but i have multiple

Hi Vincent,
In your query, you use CrossJoin in it. Crossjoin function will cause the performance issue if there are a lot of properties that need to be displayed. If you cross-join medium-sized or large-sized sets (e.g., sets that contain more than 100 items each),
you can end up with a result set that contains many thousands of items—enough to seriously impair performance. For the detail information, please see:
http://sqlmag.com/data-access/cross-join-performance
In your MDX query, ensure only retrieval the required data. Here are some useful links for your reference.
Configure memory setting:
http://social.msdn.microsoft.com/Forums/en/sqlanalysisservices/thread/bf70ca19-5845-403f-a85f-eac77c4495e6
Performance Tuning:
http://www.microsoft.com/downloads/details.aspx?FamilyID=3be0488d-e7aa-4078-a050-ae39912d2e43&displaylang=en
http://www.packtpub.com/article/query-performance-tuning-microsoft-analysis-services-part2
Regards,
Charlie Liao
TechNet Community Support

Multiple columns from the same dimension table as row labels performing slowly

(Working with SSAS tabular)
I'm trying to figure out what the approach should be for the following scenario:
Lets say we have a Customer table. The table has columns such as account number, department number, name, salesperson, account manager, number of customers, delivery route, etc
A user of the model could want to see any permutation of that information as the row labels. How should that be handled?
What we've been doing so far is that the user adds each column they want into the "ROWS" section in Excel. This works fine with smaller tables (for example, "Department" table with a "Department Code" and "Department Name",
but on large tables this quickly chokes. I understand why this is happening, I just haven't found a better way to accomplish the same thing.
I can add a calculated column to the model through VS, but obviously this is unsupportable and unscalable when each person needs their own permutations of the data. Can something similar be done in Excel?
This question seems to be what I need:
http://social.msdn.microsoft.com/Forums/en-US/97d1157a-1402-4227-b96a-79524401ddcd/mdx-query-performance-when-selecting-multiple-attributes-from-same-dimension?forum=sqlanalysisservices
However I can't find any information on how to add those properties (is it a multidimensional-only thing?)

Thanks for the help. Sorry but i'm a self-taught developer, and i may be missing some basics :)
Anyway i've done what you suggested but i get this error:
[nQSError: 15011]The dimension table source Dimension Services.DM_D_SERVIZI_SRV has an aggregate content specification that specifies the level Product. But the source mapping contains column COD_PRODUCT with a functional dependency association on a more detailed level .
where:
- DM_D_SERVIZI_SRV is the physical alias for the Service Dimension (and the name of the LTS too)
- COD_PRODUCT is the leaf of the hierarchy, the physical primary key, but it hasnt to be included in the hierarchy
Do i have to add another level with the primary key and hide it to the users?
I tried to solve this going to the logical tables source properties, on the tab contents, setting "logical level" to null for the hierarchy, but i don't know if this is correct.
Thanks

Are the 30Gh and 60Gh Video iPod the same dimension?

I'm wondering if the 30gig and the 60gig video iPods are the same dimensions? I'm looking to buy that Video iPod protective case, and the item's description says: "Fits a 30G iPod" Is there a size difference between the two of them??
Thank you,
Andre

"But here’s the kicker: At under half an inch thin, the new 30GB iPod takes up about 45 percent less room than the original iPod. Even the new 60GB model is over 10 percent thinner than the fourth-generation 30GB iPod. More features in less space? Sounds like iPod."
Its a bit thicker than the 30gb.

Why is the Star Transformation using two indexes for the same dimension?

Hi,
Recently, I have made an investigation about the Star Transformation feature. I have found a strange test case, which plays an important role in my strategy for our overall DWH architecture. Here it is:
The Strategy:
I would like to have the classical Star Transformation approach (single column Bitmap Indexes for each dimension foreign key column in the fact table), together with additional Bitmap Join Indexes for some of the dimension attributes, which would benefit from the materialization of the join (bitmap merge operation will be skipped/optimized).
The query:
select dp.brand, ds. region_name, dc.region_name
     , count(*), sum(f.extended_price)
from fact_line_item f
     , dim_part       dp
     , dim_supplier   ds
     , dim_customer   dc
where dp.mfgr        = 10                 -- dimension selectivity = 1/10 --> acttual/fact selectivity = 6/10
   and f.part_dk      = dp.dk
   and ds.region_name = 'REGION #1' -- dimension selectivity = 1/9
   and f.supplier_dk = ds.dk
   and dc.region_name = 'REGION #1' -- dimension selectivity = 1/11
   and f.customer_dk = dc.dk
group by dp.brand, ds. region_name, dc.region_name
The actual plan:
| Id | Operation                              | Name                        | Starts | E-Rows | Cost (%CPU)| A-Rows |   A-Time   | Buffers | Reads |
|   0 | SELECT STATEMENT                       |                             |      1 |        | 3247 (100)|      1 |00:01:42.05 |     264K|    220K|
|   1 | HASH GROUP BY                         |                             |      1 |      2 | 3247   (1)|      1 |00:01:42.05 |     264K|    220K|
|* 2 |   HASH JOIN                            |                             |      1 | 33242 | 3037   (1)|    217K|00:01:29.67 |     264K|    220K|
|* 3 |    TABLE ACCESS FULL                   | DIM_SUPPLIER                |      1 |   1112 |   102   (0)|   1112 |00:00:00.01 |     316 |      4 |
|* 4 |    HASH JOIN                           |                             |      1 | 33245 | 2934   (1)|    217K|00:01:29.10 |     264K|    220K|
|* 5 |     TABLE ACCESS FULL                  | DIM_CUSTOMER                |      1 |    910 |   102   (0)|    910 |00:00:00.08 |     316 |      8 |
|* 6 |     HASH JOIN                          |                             |      1 | 33248 | 2831   (1)|    217K|00:01:28.57 |     264K|    220K|
|* 7 |      TABLE ACCESS FULL                 | DIM_PART                    |      1 |     10 |     3   (0)|     10 |00:00:00.01 |       6 |      0 |
|   8 |      PARTITION RANGE ALL               |                             |      1 | 36211 | 2827   (1)|    217K|00:01:28.01 |     264K|    220K|
|   9 |       TABLE ACCESS BY LOCAL INDEX ROWID| FACT_LINE_ITEM              |      6 | 36211 | 2827   (1)|    217K|00:01:33.85 |     264K|    220K|
| 10 |        BITMAP CONVERSION TO ROWIDS     |                             |      6 |        |            |    217K|00:00:07.09 |   46980 |   3292 |
| 11 |         BITMAP AND                     |                             |      6 |        |            |     69 |00:00:08.33 |   46980 |   3292 |
| 12 |          BITMAP MERGE                  |                             |      6 |        |            |    193 |00:00:02.09 |    2408 |   1795 |
| 13 |           BITMAP KEY ITERATION         |                             |      6 |        |            |   4330 |00:00:04.66 |    2408 |   1795 |
| 14 |            BUFFER SORT                 |                             |      6 |        |            |     60 |00:00:00.01 |       6 |      0 |
|* 15 |             TABLE ACCESS FULL          | DIM_PART                    |      1 |     10 |     3   (0)|     10 |00:00:00.01 |       6 |      0 |
|* 16 |            BITMAP INDEX RANGE SCAN     | FACT_LI__P_PART_DIM_KEY_BIX |     60 |        |            |   4330 |00:00:02.11 |    2402 |   1795 |
|* 17 |          BITMAP INDEX SINGLE VALUE     | FACT_LI__P_PART_MFGR_BJX    |      6 |        |            |   1747 |00:00:06.65 |     890 |    888 |
| 18 |          BITMAP MERGE                  |                             |      6 |        |            |    169 |00:00:02.78 |   16695 |    237 |
| 19 |           BITMAP KEY ITERATION         |                             |      6 |        |            |   5460 |00:00:01.56 |   16695 |    237 |
| 20 |            BUFFER SORT                 |                             |      6 |        |            |   5460 |00:00:00.02 |     316 |      0 |
|* 21 |             TABLE ACCESS FULL          | DIM_CUSTOMER                |      1 |    910 |   102   (0)|    910 |00:00:00.01 |     316 |      0 |
|* 22 |            BITMAP INDEX RANGE SCAN     | FACT_LI__P_CUST_DIM_KEY_BIX |   5460 |        |            |   5460 |00:00:02.07 |   16379 |    237 |
| 23 |          BITMAP MERGE                  |                             |      6 |        |            |    170 |00:00:03.65 |   26987 |    372 |
| 24 |           BITMAP KEY ITERATION         |                             |      6 |        |            |   6672 |00:00:02.23 |   26987 |    372 |
| 25 |            BUFFER SORT                 |                             |      6 |        |            |   6672 |00:00:00.01 |     316 |      0 |
|* 26 |             TABLE ACCESS FULL          | DIM_SUPPLIER                |      1 |   1112 |   102   (0)|   1112 |00:00:00.01 |     316 |      0 |
|* 27 |            BITMAP INDEX RANGE SCAN     | FACT_LI__S_SUPP_DIM_KEY_BIX |   6672 |        |            |   6672 |00:00:02.74 |   26671 |    372 |
The Question:
Why is the Star Transformation using both indexes FACT_LI__P_PART_DIM_KEY_BIX and FACT_LI__P_PART_MFGR_BJX for the same dimension criteria (dp.mfgr = 10)?? The introduction of the additional Bitmap Join Index actually make Oracle to do the work twice !!!
Anybody, any idea ?!?

Dom, here it is the plan with the predicates:
| Id | Operation                              | Name                        | Starts | E-Rows | Cost (%CPU)| A-Rows |   A-Time   | Buffers | Reads |
|   0 | SELECT STATEMENT                       |                             |      1 |        | 3638 (100)|      1 |00:06:41.17 |     445K|    236K|
|   1 | HASH GROUP BY                         |                             |      1 |      2 | 3638   (1)|      1 |00:06:41.17 |     445K|    236K|
|* 2 |   HASH JOIN                            |                             |      1 | 33242 | 3429   (1)|    217K|00:08:18.02 |     445K|    236K|
|* 3 |    TABLE ACCESS FULL                   | DIM_SUPPLIER                |      1 |   1112 |   102   (0)|   1112 |00:00:00.03 |     319 |    313 |
|* 4 |    HASH JOIN                           |                             |      1 | 33245 | 3326   (1)|    217K|00:08:17.47 |     445K|    236K|
|* 5 |     TABLE ACCESS FULL                  | DIM_CUSTOMER                |      1 |    910 |   102   (0)|    910 |00:00:00.01 |     319 |    313 |
|* 6 |     HASH JOIN                          |                             |      1 | 33248 | 3223   (1)|    217K|00:08:16.63 |     445K|    236K|
|* 7 |      TABLE ACCESS FULL                 | DIM_PART                    |      1 |     10 |     3   (0)|     10 |00:00:00.01 |       6 |      0 |
|   8 |      PARTITION RANGE ALL               |                             |      1 | 36211 | 3219   (1)|    217K|00:08:16.30 |     445K|    236K|
|   9 |       TABLE ACCESS BY LOCAL INDEX ROWID| FACT_LINE_ITEM              |      6 | 36211 | 3219   (1)|    217K|00:08:40.89 |     445K|    236K|
| 10 |        BITMAP CONVERSION TO ROWIDS     |                             |      6 |        |            |    217K|00:00:32.00 |   46919 | 19331 |
| 11 |         BITMAP AND                     |                             |      6 |        |            |     69 |00:00:34.50 |   46919 | 19331 |
| 12 |          BITMAP MERGE                  |                             |      6 |        |            |    193 |00:00:00.58 |    2353 |      1 |
| 13 |           BITMAP KEY ITERATION         |                             |      6 |        |            |   4330 |00:00:00.10 |    2353 |      1 |
| 14 |            BUFFER SORT                 |                             |      6 |        |            |     60 |00:00:00.01 |       6 |      0 |
|* 15 |             TABLE ACCESS FULL          | DIM_PART                    |      1 |     10 |     3   (0)|     10 |00:00:00.01 |       6 |      0 |
|* 16 |            BITMAP INDEX RANGE SCAN     | FACT_LI__P_PART_DIM_KEY_BIX |     60 |        |            |   4330 |00:00:00.07 |    2347 |      1 |
|* 17 |          BITMAP INDEX SINGLE VALUE     | FACT_LI__P_PART_MFGR_BJX    |      6 |        |            |   1747 |00:01:23.64 |     882 |    565 |
| 18 |          BITMAP MERGE                  |                             |      6 |        |            |    169 |00:00:09.14 |   16697 |   7628 |
| 19 |           BITMAP KEY ITERATION         |                             |      6 |        |            |   5460 |00:00:02.19 |   16697 |   7628 |
| 20 |            BUFFER SORT                 |                             |      6 |        |            |   5460 |00:00:00.01 |     316 |      0 |
|* 21 |             TABLE ACCESS FULL          | DIM_CUSTOMER                |      1 |    910 |   102   (0)|    910 |00:00:00.01 |     316 |      0 |
|* 22 |            BITMAP INDEX RANGE SCAN     | FACT_LI__P_CUST_DIM_KEY_BIX |   5460 |        |            |   5460 |00:00:08.78 |   16381 |   7628 |
| 23 |          BITMAP MERGE                  |                             |      6 |        |            |    170 |00:00:21.46 |   26987 | 11137 |
| 24 |           BITMAP KEY ITERATION         |                             |      6 |        |            |   6672 |00:00:10.29 |   26987 | 11137 |
| 25 |            BUFFER SORT                 |                             |      6 |        |            |   6672 |00:00:00.01 |     316 |      0 |
|* 26 |             TABLE ACCESS FULL          | DIM_SUPPLIER                |      1 |   1112 |   102   (0)|   1112 |00:00:00.01 |     316 |      0 |
|* 27 |            BITMAP INDEX RANGE SCAN     | FACT_LI__S_SUPP_DIM_KEY_BIX |   6672 |        |            |   6672 |00:00:20.94 |   26671 | 11137 |
Predicate Information (identified by operation id):
   2 - access("F"."SUPPLIER_DK"="DS"."DK")
   3 - filter("DS"."REGION_NAME"='REGION #1')
   4 - access("F"."CUSTOMER_DK"="DC"."DK")
   5 - filter("DC"."REGION_NAME"='REGION #1')
   6 - access("F"."PART_DK"="DP"."DK")
   7 - filter("DP"."MFGR"=10)
15 - filter("DP"."MFGR"=10)
16 - access("F"."PART_DK"="DP"."DK")
17 - access("F"."SYS_NC00017$"=10)
21 - filter("DC"."REGION_NAME"='REGION #1')
22 - access("F"."CUSTOMER_DK"="DC"."DK")
26 - filter("DS"."REGION_NAME"='REGION #1')
27 - access("F"."SUPPLIER_DK"="DS"."DK")
Note
   - star transformation used for this statement

How do I make all the pages in the document to be the same dimension?

I have created a new PDF by merging several files together. How do I make pages to be all the same dimension?

Acrobat takes your files and merges them together, and uses the original dimensions of each document for the finished PDF file. I recommend changing the page size of the original document before converting to PDF.

Same dimensions in one application

Hi experts;
My question is about the same dimensions in one application. I have customer dimension and customer_z dimension.There is no problem when enter bpc for excel. If i want to open dynamic table screen or evdre function in blank sheet , the system has been blocked and not opennig.
P.S. : There are 15k ID in customer and customer_z dimensions. ( Is the root of problem?)
What can i do in this situation? Have you ever had this problem before? How did u fix it ?
Thanx for your help..
Best Regards.

Hi Breathe
No single Application will accept duplicate type of dimensions.
Please check, if the dimensions you mentioned Customer and Customer_Z are similar type of dimensions you created, there will be confilict in creating the Appliction.
In your case, please create tow diffrent Applications and put these Customer and Customer_Z dimensions in each Applications, seperately.
for more information, please go through the below document available in the link of our SDN Help:
http://help.sap.com/saphelp_bpc75_nw/helpdata/en/f8/aac4ccf5a34fcdb40ba3e508a0ae0e/frameset.htm
wich may be very helpful to you.... .....
Thanks for giving me the opportunity to suggest you.
Regards
Raghu

Illegal cross join within the same dimension caused by incorrect subject ar

hi!
Imagine the following BMM:
There is one Logical Dimension Table "Service Account" with the following LTS:
- LTS "D_SERVICE"
- LTS "D_SERVICE_CLASS"
- LTS "D_SERVICE_STATUS"
This Logical Tabe "Service Account" joins (One-to-many) with several Fact Tables (other Logical Tables).
In the Physical Layer the joins for the "Service Account" LTS are:
- One-to-many between D_SERVICE_CLASS and D_SERVICE
- One-to-many between D_SERVICE_STATUS and D_SERVICE
The problem is that when I build a report in Answers using only the following columns of the Logical Table "Service Account":
- Service Class Desc (which exists in the Logical Table "Service Account" and in the Physical Table D_SERVICE_CLASS)
- Service Status Desc (which exists in the Logical Table "Service Account" and in the Physical Tabl D_SERVICE_STATUS)
- MSISDN (which existis in the Logical Table "Service Account" and in the Phsyical Table D_SERVICE)
the following error appears:
Estado: HY000. Código: 10058. [NQODBC] [SQL_STATE: HY000] [nQSError: 10058] A general error has occurred. [nQSError: 14065] Illegal cross join within the same dimension caused by incorrect subject area setup: [ (select * from prd.D_SERVICE where SOURCE_SYS in ('ARBOR','PPB') and DW_SERV_ST_ID in (100000003,100000009)) as T1836, D_SERVICE_CLASS T1916] with [ D_SERVICE_STATUS T1948] (HY000)
SQL emitido: SELECT "SERVICE ACCOUNT"."TLC MSISDN9" saw_0, "SERVICE ACCOUNT"."IWS Service Class Desc" saw_1, "SERVICE ACCOUNT"."TLC Service Status Desc" saw_2 FROM "VFPT - Upgrade Siebel" WHERE "SERVICE ACCOUNT"."TLC MSISDN9" = '917330340' ORDER BY saw_0, saw_1, saw_2
Help, please!
Thanks.

Physically, only D_SERVICE is joined to the facts. Then D_SERVICE_CLASS is joined to D_SERVICE (one-to-many) and D_SERVICE_STATUS is joined also to D_SERVICE (one-to-many).
In the BMM, there is only one Logical Dimension Table for those 3 physical tables. This Logical Dimension Table is called "Service Account" and has 3 LTS: D_SERVICE, D_SERVICE_CLASS, D_SERVICE_STATUS. The Logical Dimension Table has several logical columns that are associated to those 3 LTS: SERVICE_KEY, SERVICE_CLASS_KEY, SERVICE_STATUS_KEY, SERVICE_MSISDN, SERVICE_CLASS_DESC, SERVICE_STATUS_DESC.
The Logical Dimension Table "Service Account" is then joined to a fact table (one-to-many).
I didn't understand the suggestion about the 3 LTS... Aren't we doing that already? Can you explain it better, please?
thanks.

Same dimension in two different fact tables

Hi,
I have one same dimension in two different fact tables. I would like to know how BI server choose the fact table when I do a request in this dimension.
I know that is always using the same fact table, but I would like to know why choose this table and not the other.
Thanks

Sorry,
But it doesn't seem to me.
I reorded the tables in the BMM layer and it continues to use the same table, regardless this table is in last.
After, I droped that table in the BMM layer and it continued to use the same.
Thanks for your reply

Load scd 1 and scd 2 in the same dimension

Hi
is there any order for load of customer dimension, when you have in the same dimension fields scd1 and scd2. which one it is better load first, scd type 2 and then, scd type 1 for each customer with state = 1?
thanks

hi Mark,
but I have one field that I want maintain the historic and then, more some fields that I want to update, always that it's possible. both case, in the same (customer) dimension.
(the state it is for scd type 2, if state=0 inactive , if state=1 active)
thanks,
David
Actually that will part of same task itself in SSIS
If you're using standard SCD task in SSIS, it will take care of all these aspects by itself. You just need to identify the attributes as Type and Type2
If you're planning to use another method like say lookup, you need to add the logic in data flow to handle the type2 cases also in the required branch
See this as an example where I've used lookup based on hash values for applying SCD type 1 and type 2 logic
http://visakhm.blogspot.in/2014/06/ssis-tips-implementing-scd.html
Please Mark This As Answer if it helps to solve the issue Visakh ---------------------------- http://visakhm.blogspot.com/ https://www.facebook.com/VmBlogs

[nQSError: 14065] Illegal cross join within the same dimension

Hey guys,
I'm stumped. I have two dimension tables that are joined 1:N (there is NOT an M:N relationship between them) and I have them joined in the Physical Layer and the Business Model and Mapping Layer. The two tables are F4101 (the "1") and F4102 (the "N") in the 1:N relationship. F4102 then joins to a fact table, and F4101 joins to NOTHING else. So I don't believe I have a circular condition or a need for a bridge table. Both tables are published to the Presentation Layer for reporting.
The error occurs in Answers when I want to do something as trivial as display the three primary key columns together from F4101: F4101.col1, F4101.col2, F4101.col3 (all three make up the PK). When I do that, the following error occurs:
"nQSError: 14065] Illegal cross join within the same dimension caused by incorrect subject area setup: [ F4101 T28761] with [ F4102 T1805] "
What I can't figure out is WHY the F4102 table is listed in this error. I didn't try to report on it at all. See the logical SQL below from my query:
"SQL Issued: SELECT "Item Master (F4101)".IMITM saw_0, "Item Master (F4101)".IMLITM saw_1, "Item Master (F4101)".IMAITM saw_2 FROM "Sales Analysis" ORDER BY saw_0, saw_1, saw_2"
As soon as I take out one of the three PK columns and add in another non-PK column from F4101, it works just fine. And reporting on each of the three PK columns individually works as well in Answers.
Any ideas? I would greatly appreciate it.
Thanks.

Try this;
1. In the logical layer, create one folder called F4101_F4102.
2. Map both F4101 and F4102 as logical table sources in that folder.
3. Join from the folder F4101_F4102 to the fact using a Logical (new complex join) join.
Chris.

Unable to use same dimension multiple time for a MOLAP cube?

Hi,
I am designing a MOLAP cube that uses the date dimension twice (start/end) but when selecting dimensions for the cube, it doesn't accept the 2nd time I select the date dimension.
In the date dimension design I gave it 2 role names for this purpose.
The error that comes up is: The MOLAP storage type does not support multiple references to the same dimension.
Now I just found out that the User Guide states: Dimension roles can be created for dimensions that have a relational implementation only.
So how does OWB support implementation of a startdate and enddate in one cube?
Do we have to duplicate the date dimension in MOLAP multiple times? (Multiple deployment and population using the name of the role??)
What solutions/work-arounds are in use out there? Any help is appreciated.
Thanks,
Ed
(Oracle 10gR2, OLAP with A patch on Suse Linux x86-64)

It keeps asking because they are recorded in the database and it can't find them. So they have been delete from outside iPhoto, and iPhoto doesn't know this.
Simple fix: put the files back where iPhoto expects them to be. Otherwise...
Try these in order - from best option on down...
1Download iPhoto Library Manager and use its rebuild function. (In Library Manager it's the FIle -> Rebuild command)
This will create an entirely new library. It will then copy (or try to) your photos and all the associated metadata and versions to this new Library, and arrange it as close as it can to what you had in the damaged Library. It does this based on information it finds in the iPhoto sharing mechanism - but that means that things not shared won't be there, so no slideshows, books or calendars, for instance - but it should get all your events, albums and keywords, faces and places back.
Because this process creates an entirely new library and leaves your old one untouched, it is non-destructive, and if you're not happy with the results you can simply return to your old one.
2. If this doesn't work then you'll need to create and populate a new library.
To create and populate a new *iPhoto 6* library:
Note this will give you a working library with the same Rolls and pictures as before, however, you will lose your albums, keywords, modified versions, books, calendars etc.
Move the iPhoto Library to the desktop
Launch iPhoto. It will ask if you wish to create a new Library. Say Yes.
Go into the iPhoto Library on your desktop and find the Originals folder. From the Originals folder drag the individual Roll Folders to the iPhoto Window and it will recreate them in the new library.
When you're sure all is well you can delete the iPhoto Library on your desktop.
In the future, in addition to your usual back up routine, you might like to make a copy of the library6.iPhoto file whenever you have made changes to the library as protection against database corruption.

Reference same dimension multiple times in a cube

Hi,
I'm creating a cube with Analytic Workspace Manager. The cube needs to reference same dimension more than once. For example, in a movie ticket booking cube, there's a booking date and a show date , both should reference same pre-created TIME dimension. Because one dimension can be added to a cube only once, now my solution is to define 2 dimensions, i.e. BOOKING_TIME and SHOW_TIME, both are based on same underlying table and have exactly same levels/hierarchies/mapping, and then add them to the cube. I believe there must be smarter approaches out there, please advise.
Thanks!
Jim
Edited by: user11955172 on 2012-12-10 上午2:36

For hand written/custom sql going against the Cube:
You're right that you can use one of the 3 time dimension based views (duplicated 4 times for time1/2/3/4 dimensions).
If you need to use 2 out of 4 time dimensions in your query (by applying an application based filter/restriction) then you would need to alias the relevant view(s) 2 times and get your result.
If you needed to use all 4 time attribute dimensions, then you need to alias the time dimension view 4 times.
12 views represent the full spectrum of possible report/query usage scenarios available to users via these 4 time dimension views. A typical session with various reports/queries is unlikely to refer to all of them (possible but not likely).
In different scenarios, any one of the 3 views - dimension view, h1, h2 view - comes into play for each dimension.
In every query/report scenario, only 1 out of the 3 applicable views would be needed or suitable based on the query/report specifics.
E.g:
* If your query is at lowest level and is also referencing attributes/descriptions which pertain to >1 hierarchies, then the view v_time<N>d is the appropriate view to use. Neither vtime<N>h1 or vtime<N>_h2 will be able to give you the results you require if you have attributes defined exclusively in either hierarchy h1 or h2.
* Setting the default hierarchy to either h1 or h2 determines which hierarchy view is expected to be used/preferred in cases where dimension is not referenced or where Top level of dimension is desired in query/report. E.g: Top level is same for both hierarchies h1 and h2 but read the Top Level values from h1 view as h1 is marked as the default hierarchy for dimension.
* The level of the query is generally determined by the lowest level of the attributes/fields in your query. If you have attributes like Long_Desc, Short_Desc (available at all levels/all hiers) and you have 2 attributes from Hierarchy H1 and from levels L1 (one level above leaf) and L3 (higher than L1 by 2 levels)... then the query uses v_time<N>h1 and will apply a filter to choose/constraint levelname field = 'L1'.
* Reporting tools like OBIEE etc. have security filters defined to ensure that the joins to missing dimensions and the appropriate dimension level filters appended to the query in a transparent "behind the scenes" manner.
NOTE: By modeling the time based fields as different dimensions, you get the benefit of time series analysis along any of the 4 dimensions. You can create a Month-to-Date Revenue measure along "Show Biz Time" dimension and also create a Year-to-Date Revenue Measure based on "Booking Time" dimension. Also compare % variance of "MTD - Revenue - Show Biz Time" with corresponding value for Last year "MTD LY - Revenue - Show Biz Time". This is the benefit you get by breaking out the 4 columns in relational fact and modeling them as explicit time dimensions. You pay a small price in terms of cube space expansion, time dimension load increase but as acknowledged earlier, this dimension can be loaded incrementally, the full load process is done only initially. It is an offline process (batch) and does not hamper query performance.
Regd
3) In the underlying star schema, we have only one time dimension table, in the ticket booking fact table, we have 4 dimension columns referencing the same time dimension table. So it's intuitive to expect similar design in the cube. Current approach seems like replicating the dimension table for each dimension column.Do you have parentage along h1/h2 laid out in terms of different parent columns ... 06:30am should have parent D1 in h1 hierarchy (regular day) and parent=D1-1 in h2 hierarchy (business day)?
h1=regular day hierarchy
h2=biz day hierarchy
In that case, perhaps you want "Booking Time" (Time1) to use view: v_time1_h1 by default and "Booking Biz Time" (Time3) to use v_time3_h2 by default.
Using h2 hierarchy for Time1 or h1 hierarchy for Time3 would be illogical/invalid. Maybe you can simplify things by removing the hierarchies from olap model which dont apply to the dimension.
HTH
Shankar

MDX: CrossJoin of generations same dimension

Similar Messages

Maybe you are looking for